生产环境中的端侧 LLM 推理：何时选择边缘模型以及它们的实际成本

大多数团队决定使用端侧 LLM 推理的方式，就像他们决定重写数据库时一样：冲动行事，仅仅是为了应对原本可以用更廉价方案解决的问题。推介词总是令人心动——无需网络往返、完全隐私、零推理成本——而且初始原型也验证了这一点。然而，在发布六个月后，模型开始悄无声息地输出更差的结果，新的操作系统更新打破了量化兼容性，而那些使用廉价安卓手机的用户正在运行一个你无法推送更新的版本。

本指南旨在让你在看清现实的情况下做出决策。在特定场景下，端侧推理确实是正确的选择，但其成本结构与团队预期的不同，且生产环境中的失效模式与云端 LLM 部署几乎完全不同。

端侧推理真正胜出的三种情况

在以下三个特定场景中，端侧模型在经济和技术上是合理的。除此之外，使用云端 API 或托管的开放权重端点几乎总是更好的选择。

无法通过合同保证满足的隐私需求。 医疗、法律和金融应用通常要求数据绝不离开设备——这并非因为云服务商不可信，而是因为合规体系（HIPAA、GDPR、特定行业法规）要求将其作为一种硬性的架构属性，而非仅仅是政策承诺。端侧推理无需谈判即可提供这种保障。没有传输，没有存储，设备本身之外不存在审计表面。

离线优先的功能。 外场技术人员、飞行员、海事操作员以及用于工厂车间的企业级工具需要推理在无网络连接时也能工作。一个在本地以每秒 15 个 token 运行的 7B 模型，其体验远好于一个永远无法完成的尖端模型 API 调用。对于需要同步、低延迟行为的应用——如打字助手、搜索自动补全、实时翻译——这也是正确的模式，因为即使是 200 毫秒的网络往返也会让用户感到明显的卡顿。

按 token 计费的云端成本变得高昂的规模化场景。 这是最容易被误解的情况。端侧推理将成本从按 token 计费转变为用户设备上的固定硬件成本。如果你的功能每天为每个用户运行数百万次短推理，且任务不需要尖端模型的推理能力，那么将这些任务路由到设备端可以完全消除一个成本中心。只有在利用率持续保持时，这种计算才成立；闲置的 GPU 小时在你的硬件上是昂贵的，但在用户的手机上是免费的。

质量与尺寸的权衡并非如基准测试所示

模型基准测试针对的是在标准化评估下表现良好的任务。而生产环境中的任务并非标准化的。按参数量划分的实际能力临界点如下：

1B 模型 运行速度快（在现代移动芯片上 TTFT 低于 200 毫秒），且能轻松装入过去三年发布的任何设备。它们适用于意图分类、垃圾邮件检测、短文本的简单摘要以及语言识别。但在多步推理、复杂指令遵循以及任何需要广泛事实知识的任务中，它们会可靠地失败。

3B 模型（如 Gemini Nano, Llama 3.2 3B）达到了许多消费级应用的理想平衡点。情感分析、基础客户支持路由、短内容生成和提取任务都变得可行。一份 2025 年对比安卓端小模型的基准测试发现，Gemma2-2B 提供的答案明显优于同级别的 1B 和 3B 模型，这表明在这一规模下，架构与参数量同样重要。

7B 模型 是对质量敏感任务中最常用的部署尺寸。它们可以处理代码补全、文档摘要和中等难度的推理。存储是硬约束：一个采用 Q4 量化的 7B 模型需要 4–5GB 空间，这在高端设备上是可行的，但排除了大部分安卓安装基数。此外，在大多数手机上持续运行 7B 模型产生的热量足以在几分钟内触发热过载降频。

量化选择会加剧这些约束。INT8 是生产安全的默认选择——与 FP32 相比尺寸缩小约 75%，且在正确校准后精度损失通常小于 1%。INT4（特别是 AWQ 格式）进一步缩小了尺寸，但在推理和数学任务上会引入明显的质量下降。正确的方法是在投入使用前，根据你实际的任务分布对量化模型进行基准测试，而不是看排行榜。一个在 MMLU 基准测试中 INT4 表现良好的模型，在你特定的提取或摘要工作负载中可能会大幅退化。

框架选择无关性能，而是关乎部署表面

你选择哪种端侧推理框架，很大程度上取决于你需要支持哪些平台。

如果你专门为 iOS 和 macOS 构建应用，CoreML 是正确选择。它可以获得原生的神经网络引擎（Neural Engine）加速，且 Apple 芯片能很好地处理 LLM 推理——在 M1 Max 上，Llama 3.1 8B 在 CoreML 下可达到约 33 tokens/秒。缺点是完全锁定在 Apple 的生态系统和转换流水线中。

ExecuTorch（Meta 的生产级框架，于 2025 年底正式发布）是跨平台移动部署的正确选择，特别是如果你需要针对特定芯片进行优化。它支撑着 WhatsApp、Instagram、Messenger 和 Facebook 的生产规模——在各种硬件上处理数十亿用户的端侧推理。其 50KB 的基础占用空间和对 NPU 调度的支持，使其成为消费级应用中最经生产验证的选择。

ONNX Runtime 对于需要单一模型格式支持安卓和 iOS 且运维开销中等的团队来说，是一个务实的选择。虽然它缺乏 ExecuTorch 那样的芯片级优化深度，但其互操作性（直接从 PyTorch 或 TensorFlow 导出，在 iOS 上委派给 CoreML，在安卓上委派给 NNAPI/QNN）简化了模型流水线。

WebLLM/WebGPU 不再是实验性的。截至 2026 年初，WebGPU 已在所有主流浏览器中默认启用，WebLLM 可达到原生性能的 80%。对于无法承担应用商店摩擦，或需要无需应用发布周期即可即时部署模型更新的网页优先（web-first）应用来说，这是正确的路径。

真实的成本结构

云端 API 成本是显性的，且按请求计费。设备端推理成本则是隐形的，由你的用户的硬件承担。这种不对称性在两个方向上都扭曲了成本计算。

对于在自有 GPU 基础设施上运行中等推理规模的团队来说，要达到与中端云端 API（如 GPT-4o-mini 级别）持平的盈亏平衡点，需要在持续 70% 以上的 GPU 利用率下运行 18–24 个月。而在 10% 的利用率下，同样的硬件每 Token 成本比直接调用 API 高出 10 倍。这就是扼杀自托管部署的算账逻辑：团队为峰值预留资源，却在为闲置买单。

设备端推理则完全规避了这一点——GPU 就是用户的手机。但它引入了不会出现在 API 账单中的成本：模型大小会影响应用商店的下载转化率，推理会影响电池寿命和散热表现，而且在旧设备上，你还在与设备正在运行的其他所有程序竞争资源。

Google 的 Pixel 10 Pro 在特定的 Gemini Nano 任务中能达到近 1,000 token/s。Pixel 9 Pro 的运行速度大约为 510 token/s。而在 Snapdragon 8 Gen 3 上的三星 S24 Ultra 在运行较大模型时的基准测试约为 10 token/s——慢了一个数量级——因为过热降频（thermal throttling）会在持续负载的几分钟内强制降低 GPU 频率。你心目中的“平均移动设备”并不是 M 系列芯片；而是一部在中等 LLM 工作负载下会过热的中端 Android 手机。

没人预料到的更新难题

这是大多数生产环境中的设备端部署悄然失败的地方。

当你部署云端 API 调用时，更新底层模型只是一个配置更改。当你发布一个内置在 App 中的模型时，更新它需要发布新版本、经过应用商店审核，以及用户愿意更新。你的 90% 安装基数完成 App 更新的中位时间通常以周甚至月来计算。在此期间，你必须同时支持多个模型版本，且无法对旧版本进行热修复。

与全量模型替换相比，增量更新（Delta updates）可以将下载大小减少 80% 或更多，但它们需要基础设施来对比版本并分发差异文件——大多数团队直到危机发生才会构建这种系统。Android 的硬件碎片化加剧了这一问题：分布在 1,300 多个制造商手中的 39 亿台 Android 设备意味着行为在不同设备系列中存在不可预测的差异，而旧设备可能永远无法接收到你的更新。

更隐蔽的失败模式是能力漂移（capability drift）。LLM 模型是分布的静态快照。你的用户查询在进化，你的产品功能面在扩大，而在发布后的 90 天内，你通常会在那些自训练以来发生偏移的任务上看到明显的输出质量下降。云端部署隐藏了这一点，因为提供商会持续更新底层模型，你会获得隐性的改进。设备端部署则暴露了这一点，因为你的模型版本冻结在那些尚未更新的用户手中。

特定硬件的量化失败是另一个陷阱。一个在某代 NPU 上测试过的 INT4 模型，可能会在不同芯片上加载时静默转换为 FP16——因为运行时（runtime）在该硬件上不支持 INT4——这会在没有任何错误或警告的情况下抵消所有内存节省。你会通过用户反馈的电池耗尽发现这一点，而不是通过监控。

生产级加固的设备端部署是什么样的

可靠运行设备端推理的团队会做一些框架文档中很少提及的事情。

他们会显式管理模型版本，并跟踪每个设备运行的版本。 这是检测特定模型版本是否与某个设备系列的质量退化相关的基本要求。

他们针对输出质量进行埋点，而不仅仅是可用性。 一个能返回响应的模型并不代表是一个健康的模型。持续针对一小部分留存评估集（held-out evaluation set）对生产流量进行采样，是检测用户报告前的静默能力漂移的唯一可靠方法。

他们会规划热预算（thermal budget）。 仅在设备充电时运行推理，或者在推理调用之间构建冷却期，可以防止表现为“AI 在旧手机上变慢”的会话期间性能下降模式。

他们将 Web 视为逃生舱。 对于模型质量重要到需要频繁更新的任务，采用 WebGPU 推理可以完全避开 App 发布周期。浏览器的更新机制比应用商店的分发更快、更可靠，而且模型可以按需获取而不是捆绑打包。

他们从第一天起就设计混合路由层。 简单、延迟敏感、隐私敏感的任务路由到设备端。复杂的推理、需要最新信息的任务以及来自不具备相应硬件能力的设备的请求路由到云端。做好这种路由——包括当设备端模型失败或热限制阻止推理时的回退机制——比独立构建其中任何一个端点都要难。

诚实的决策框架

当你具有强烈的隐私需求、需要可靠的离线功能，或者正在运行高容量、低复杂度的推理以至于云端成本不可持续时，设备端推理是正确的架构选择。当你需要频繁的模型更新、你的目标设备覆盖整个 Android 生态系统，或者任务复杂度需要前沿模型（frontier-model）的推理能力时，它是错误的选择。

成功的团队将模型视为基础设施：有版本管理、有监控、有明确的弃用时间表和回退路径。失败的团队将其视为一种优化——在云端版本运行后才添加的东西——并在发布六个月后发现他们交付了一个无法更新的静态模型，运行在他们无法测试的硬件上，面向他们无法触达的用户。

硬件正在变得更快。Pixel 10 Pro 和 A18 级别的芯片能以交互级延迟处理 7B 模型。WebGPU 已使浏览器推理成为现实选择。框架生态正在成熟。设备端 LLM 推理已不再是实验性的——但可靠运行它所需的生产纪律对于大多数团队来说仍然是一个未解决的问题。