端侧 LLM 推理：何时将 AI 迁出云端

大多数团队只有在亲身碰壁后，才会发现云端运行 AI 推理的棘手之处：追溯到个人健康信息（PHI）跨越 API 边界的 HIPAA 审计；在预发布环境中表现良好，直到处于不稳定连接环境下的用户反馈“一直在转圈”的延迟数据；或者是每天 10,000 次请求时看似合理，但在 1,000 万次请求时却变成灾难的单次推理 API 账单。设备端推理通常是正确的答案 —— 但团队选择它的原因以及他们遇到的问题，很少与博客文章对比中提到的相同。

这是一个关于该决策的实用指南：本地执行何时优于云端 API、哪些小模型真正具备交付能力，以及在基准测试演示结束后，部署生命周期是什么样的。

为什么团队转向设备端推理

有三个驱动因素，每个因素都有不同的特征。

隐私和监管合规性是最让团队感到意外的一点。HIPAA 要求受保护的健康信息（PHI）在没有商业伙伴协议（BAA）的情况下不得跨越不可信边界 —— 而将患者笔记发送到第三方推理 API（即使是进行摘要）通常也属于此类。GDPR 的数据最小化原则为在有选择的情况下将个人数据保留在本地提供了强有力的依据。CCPA 引入了关于 AI 推断属性（医疗状况、财务状况、行为模式）的披露义务，当推理从未离开设备时，这些义务更容易履行。对于在这些制度下运行的医疗、法律和金融应用，设备端推理通常不是一种优化，而是合规的前提条件。

延迟限制的形态与云端延迟不同。在生成单个 token 之前，云端往返会增加 100–200ms 的网络开销。对于自动完成、语音识别和实时标注任务，这种开销是无法接受的。更根本的是，云端推理在离线环境中根本无法工作：飞机、船舶、偏远工业现场、农村医疗诊所。混合系统 —— 由轻量级设备端模型处理常见情况，云端处理升级情况 —— 可以为低连接环境下的用户提供服务，而纯云端产品则无法做到。

规模化成本是吸引团队注意力最快的原因。在中等规模下，自托管开源模型与领先的云端 API 相比可节省 60–70%。一旦考虑到完整的 GPU 折旧成本，高吞吐量工作负载的本地部署运行效率比云端高出 2.1–2.6 倍，且随着推理量的增加，盈亏平衡的计算会进一步改善。在硬件效率提升（每年约 30%）和软件优化（每年约 40%）的推动下，整个行业的推理成本在 2022 年底至 2024 年底之间下降了约 280 倍。以前只能在大型 GPU 上运行的模型，现在可以在消费级硬件上运行。

质量差距正在缩小，但并未消失

关于质量论点的真实情况是：对于在生产环境中部署设备端推理的任务，与前沿模型（frontier models）的质量差距已经缩小到几乎可以忽略不计。对于质量差异仍然至关重要的任务，无论你在哪里运行，小模型仍然是错误的选择。

当前这一代小模型已经达到了一个有意义的门槛。Llama 3.2 3B 在 MMLU 上的表现优于 Gemma 2B（63.4 对比 57.8）。Phi-3.5-mini 在 Apple 的内部评估中击败或持平了规模大得多的模型。2025 年 4 月发布的 Qwen 3-4B 在多项数学和推理基准测试中与 Qwen2.5-72B 旗鼓相当 —— 一个 40 亿参数的模型在特定任务上匹配了 720 亿参数的模型。部署在 iOS 18.1+ 设备上的 Apple 3B 设备端模型，在它处理的指令遵循任务上达到了 GPT-3.5 级别的性能。

量化（Quantization）在两年前还是一个痛苦的折衷，现在已成为常规。INT8 量化在内存减少 50% 的情况下，与 BF16 相比准确度仅下降 0.04%。INT4 在 MMLU-Pro 上保留了 98.1% 的基线推理能力。新的 ATOM 量化技术在 batch 为 128 时实现了比 INT8 快 1.8 倍的提速。这些不是理论数字 —— 而是从业者在生产环境中交付的实际数据。

质量差距依然显著的领域：复杂的步骤推理、长上下文下的细微指令遵循、高资源语言之外的多语言任务，以及任何需要只有在前沿规模训练数据中才会出现的通用世界知识的任务。如果你的应用需要前沿模型来保证质量，那么将较小的模型放在设备端并不能改变这一需求。

边缘端推理真正胜出的场景

在以下这些工作负载类别中，本地执行不是一种妥协，而是正确的架构：

键盘自动完成和写作辅助需要低于 50ms 的响应。云端往返在物理上与用户预期的打字体验不兼容。Meta 通过 ExecuTorch 在 Instagram 和 WhatsApp 的消息建议中运行设备端预测。

语音和设备端音频处理需要实时运行。唤醒词检测和初级语音识别一直是本地运行的；现在，本地运行的门槛正在向常见查询模式的全对话响应生成迈进。

处理 PHI 的医疗和临床应用。本地系统在保持患者数据本地化的同时，在异常检测任务上实现了 95% 以上的准确率。对于受监管的应用，这是基本要求，而非优化。

企业文档处理，其中敏感业务数据（法律合同、财务记录、人力资源文档）不能发送到外部 API。AnythingLLM 和类似工具可以在没有数据外流的情况下实现完全离线的文档问答。

离线优先应用，适用于外勤服务、远程操作以及连接不稳定的环境。一个依赖云端的 AI 功能会变成一个依赖云端的产品，这涉及到不同层面的可靠性问题。

高吞吐量的分类和提取，其中单次推理的 API 成本会不断累积。在每天 1,000 万次分类的规模下，即使质量略低，自托管的成本账也变得非常有吸引力。

硬件版图比看起来更加碎片化

经验丰富的团队所面临的部署难题是硬件碎片化。“在设备端运行”对于不同设备而言，其含义大相径庭。

CPU 执行具有通用性，但速度较慢。llama.cpp 的 CPU 优化路径在移动级硬件上大约能达到每秒 1–5 个 token —— 这对于非交互式任务是可以接受的，但对于实时生成来说太慢了。

移动端 GPU（Apple Metal、Qualcomm Adreno）比 CPU 提速 5–10 倍。但发热导致的降频（Thermal throttling）是一个现实的约束：在 iPhone 16 Pro 上的测试显示，由于散热限制，GPU 吞吐量在持续推理后会下降 50%。生产系统需要考虑这种在长时间运行中的性能下降，而不仅仅是看前 10 秒的基准测试。

NPU / 神经网络引擎（Neural Engine） 是移动端生产环境的理想目标。在骁龙 8 Elite Gen 5 上的高通 Hexagon NPU 处理 1024×1024 图像时，首个 token 生成时间（Time-to-first-token）仅为 0.12 秒 —— 比 CPU 快 100 倍，比 GPU 快 10 倍。与 GPU 相比，功耗降低了 35–70%，这对于持续使用中的电池续航至关重要。权衡之处在于：NPU 需要针对特定后端的量化方案，且在不同芯片系列之间不具备移植性。

Apple Silicon（M 系列和 A 系列）已经相当成熟。Metal GPU 路径在 2025 年已具备生产可用性。MLX 作为 Apple 的数组框架，在 Apple 硬件上实现了最高的持续生成吞吐量。对于针对 macOS 和 iOS 的应用，通过 Core ML 或 ExecuTorch 集成神经网络引擎可以提供最高效率。

从实际操作来看：如果你正在为特定的设备系列（如 Apple 设备、高通安卓旗舰机）进行开发，你可以针对该硬件的最佳执行路径进行优化。如果你在进行跨平台开发，则需要管理一个由 CPU 回退方案、GPU 路径和 NPU 后端组成的矩阵，且每个都需要进行验证。

选择你的运行时（Runtime）

运行时的选择与其说取决于原始性能，不如说取决于你的目标设备以及你的工程团队能够维护什么。

llama.cpp 是大多数团队的切入点。它针对 CPU 进行了优化，具有极强的可移植性，且 GGUF 格式已成为模型分发的行业标准。对于在 macOS 或 Linux 上进行研发，它是默认首选。由于它缺乏一流的 GPU 或 NPU 后端支持，因此生产环境的移动部署通常会转向其他方案。

MLX（Apple 的框架）利用类似 PyTorch 的编程模型，在 Apple Silicon 上实现了最高的持续吞吐量。它仅支持 Apple 设备，这限制了其可移植性，但对于 macOS 原生应用来说，它是最佳选择。

ExecuTorch（Meta 出品，2025 年 10 月发布 1.0 GA 版）是目前生产环境移动部署的最佳选择。它仅有 50KB 的运行时占用，支持 12 个以上的硬件后端（Apple、Qualcomm、Arm、MediaTek、Vulkan），并且 80% 以上的 HuggingFace 模型可以开箱即用。Meta 已在 Instagram、WhatsApp、Messenger 和 Facebook 的生产环境中运行它。对于 iOS 和 Android 生产级应用，这是首选评估的框架。

LiteRT（2024 年由 TensorFlow Lite 更名而来，现在除了 TensorFlow 外还支持 PyTorch 和 JAX）是成熟的跨平台选项，拥有最广泛的硬件后端支持。目前最大的现有生产部署基础都在 LiteRT 上。

Core ML 是仅限 iOS 应用的正确选择，尤其是在对 Xcode 的深度集成和神经网络引擎的访问权限比可移植性更重要时。

WebLLM 通过 WebGPU 实现基于浏览器的推理。其质量是真实可靠的 —— 但 WebGPU 并非普遍可用，且基于浏览器的推理对于生产负载有明显的局限性。

那些无人提及的部署与更新问题

让模型在设备上跑起来只是个 Demo。在生产环境中维护它则是另一回事。

不中断运行中会话的 OTA 更新是一个固件级别的问题，大多数 AI 框架在设计时并未考虑解决这一问题。在用户正在使用时向设备推送新的模型版本，需要协调活跃的推理会话，管理新模型性能退化时的回滚，并处理一些设备处于版本 N 而另一些处于版本 N-1 的异构更新状态。移动固件更新的模式在此同样适用：按设备群组进行阶段性发布、激活前的能力检测，以及在切换前将新模型与旧模型进行影子测试（Shadow-testing）。

版本偏移（Version skew） 是一种特定的失效模式。如果你应用程序的 Prompt 和工具 Schema 是针对模型版本 N 调优的，而某些设备在验证兼容性之前就更新到了版本 N+1，你就会遇到看起来像应用程序代码 Bug、但实际上是模型行为变化的差异。标准做法是将模型和应用程序代码作为一个带版本的包（Bundle）一起交付，而不是将模型视为可独立更新的基础设施。

存储和内存限制需要持续的约束。一个 INT4 量化的 4B 参数模型大约占用 2GB 磁盘空间。一个 8B 模型大约占用 4GB。在用户总存储空间只有 32GB 且有数十个应用竞争空间的设备上，模型大小是一个用户可见的问题，会影响安装率和留存率。延迟加载（Lazy loading） —— 即模型权重从存储中进行内存映射并根据需要调入内存 —— 可以减少工作集占用，但需要硬件支持快速存储访问。

碎片化的硬件性能意味着你的性能表征需要覆盖不同的设备层级，而不仅仅是设备类别。在骁龙 8 Elite 上能跑出 20 token/秒的模型，在三年前的中端设备上可能只有 3 token/秒。自适应行为 —— 降低生成参数、截断上下文或回退到云端 —— 需要构建在应用层，而不是假设这些问题不存在。

坦诚的决策框架

端侧推理（On-device inference）在以下情况下是正确选择：

• 隐私或合规性要求禁止数据离开设备或本地网络
• 延迟要求低于云端往返所能达到的水平（实时语音、自动补全、交互式标注）
• 应用程序必须在没有网络连接的情况下运行
• 规模经济使得单次推理的 API 成本无法接受
• 任务处于当前小模型的能力范围内（分类、摘要、提取、常见问题解答）

在以下情况下它是错误选择：

• 任务需要前沿模型（frontier-model）的质量，而小模型无法企及
• 你的工程团队没有能力维护部署和更新基础设施
• 设备集群过于分散，无法在不同硬件层级间进行验证
• 监管环境实际上要求外部推理提供商的可审计性（某些合规制度更倾向于可审计的云端供应商，而非本地模型）

中间情况——即你为了延迟或离线需要某些端侧能力，但在质量敏感的任务中可以回退到云端——这是混合架构（hybrid architectures）体现其复杂性价值的地方。构建一个根据查询复杂度和连接状态在本地与云端推理之间切换的自适应路由层（adaptive routing layer），会增加显著的运维开销。对于对这两种约束都有切身体会的应用来说，这是正确的选择。而对于大多数产品而言，权衡的一侧通常占据主导地位，答案会更简单。

结论

端侧 LLM 推理在 2024 年不再仅仅是一个研究项目。它现在是一个具有实际框架、可衡量质量和明确约束集的生产工程决策。如今在本地运行的模型，在两年前还需要数据中心级别的硬件。部署问题——硬件碎片化、OTA 更新、版本偏差、存储限制——虽然真实存在，但可以通过团队在移动开发中已掌握的技术来解决。

当隐私要求严苛、延迟要求极高、规模化成本至关重要或连接不可靠时，将推理移出云端是正确的决定。问题不再是它是否可行。问题在于，拥有端侧模型部署的运维开销，是否比你通过这种方式解决的问题更廉价。