混合云边 LLM 推理：端侧模型何时优于云端

你的 LLM 在云端生成的每一个 Token 都在产生费用，增加延迟，并跨越网络边界传输用户数据。在设备端生成的每一个 Token 都避开了这三个问题——但受限于手机或笔记本电脑 GPU 的处理能力。有趣的工程挑战发生在边界上：决定哪些查询值得调用云端的前沿能力，而哪些更适合由运行时间不到 20 毫秒的 3B 参数本地模型来处理。

混合云边推理模式并非理论。Apple Intelligence 在端侧模型和私有云计算 (Private Cloud Compute) 之间进行路由。Google 的 Gemini Nano 直接在 Pixel 和三星设备上运行，同时将复杂的请求升级到云端 Gemini。这些不是演示项目——它们正以数十亿设备的规模进行交付。而底层架构现在正被任何愿意仔细思考“延迟-隐私-成本”三角形的团队所采用。

延迟-隐私-成本三角形

每一次推理决策都在平衡这三种力量，你可以牺牲第三种来优化前两种。

延迟 是最直观的。在看到第一个 Token 之前，云端往返会增加 200–500ms 的延迟。对于语音助手、实时翻译、AR 叠加或任何人类感知延迟超过 100ms 的界面，这种惩罚都会破坏体验。端侧推理在短上下文中生成每个 Token 的时间不到 20ms——速度快到让用户感觉模型是即时的，而不是在“加载”。

隐私 是最二元的。从未离开设备的数据不会在传输中被拦截，不会被记录在服务器上，也不会被供应商传唤。对于医疗、金融和法律应用——或者仅仅是为了赢得用户信任——这种保证是基于结构的，而非基于政策。本地推理自动满足数据驻留要求，消除了让云端 AI 合规变得昂贵且脆弱的跨境传输担忧。

成本 是最容易被误解的。云端推理按查询计算看起来很便宜，但累积速度很快。在大规模应用下，每一次 API 调用都要花钱，而对于高吞吐量的应用（自动补全、文档摘要、移动助手），经济效益会发生反转。端侧推理将成本转移到了用户已拥有的硬件上。一项 2025 年的长期分析发现，可在本地处理的查询比例在两年内从 23% 跃升至 80% 以上——这意味着对于大多数生产流量来说，云端变得不再必要。

大多数团队犯的错误是将其视为一次性的架构决策。其实不然。这是一个路由问题，应该针对每个查询进行评估。

现在的边缘端究竟能运行什么

端侧 LLM 的硬件和软件栈在 2025 年跨越了生产就绪的门槛。以下是现实与愿景的对比。

硬件能力 已收敛到一个实用的范围。Apple 的 M4 Max 提供 128GB 统一内存——足以在本地运行一个 70B 的量化模型。高通的 Snapdragon X2 在笔记本电脑上提供 80 TOPS 的算力，而 Snapdragon 8 Gen 4 为旗舰手机带来了 60 TOPS。NVIDIA 的 Jetson AGX Orin 为嵌入式系统提供 64GB 统一内存。像 RTX 5090 (32GB VRAM) 这样的消费级 GPU 能以每秒 150–260 个 Token 的速度运行 7B Q4 模型。

模型能力 已与硬件匹配。当前这一代小语言模型 (SLM)——3.8B 参数的 Phi-3 Mini、1B 和 3B 的 Llama 3.2、Gemma 2、Qwen 2.5——处理分类、摘要、提取和简单的问答任务，其质量在两年前还需要 13B 以上的模型。超紧凑模型 (500M–2B 参数) 可装入 1–4GB 的内存，并在智能手机处理器上运行。

推理运行时 已达到生产级。Meta 的 ExecuTorch 在 2025 年 10 月发布了 1.0 GA 版本，提供 50KB 的基础占用空间，支持 CPU、GPU、NPU 和 DSP 后端。llama.cpp 在桌面和服务器边缘部署方面继续成熟。Apple 的 CoreML 和 Google 的 MediaPipe LLM 处理特定平台的路径。

实际天花板：8B 参数模型在智能手机上以每秒 30+ Token 的速度运行。多模态模型以低于 5ms 的延迟同时处理视觉、语言和音频。对于任何符合这些约束的任务，云端只会增加成本和延迟，而不会带来质量收益。

压缩而不崩溃：让模型具备边缘就绪能力

在设备上运行模型需要将其缩小，同时不破坏使其有用的能力。标准配方已趋于一致：以 16 位进行训练，量化为 4 位进行部署。但细节决定了你得到的是一个有用的模型，还是一个自信地胡说八道的模型。

训练后量化 (PTQ) 是主流方法，因为它不需要重新训练。GPTQ 和 AWQ 都能实现 4 位量化，内存占用减少约 4 倍。通常更倾向于使用 AWQ，因为它能识别显著权重——这些权重在推理过程中最活跃——并以更高的精度对它们进行量化，同时积极压缩次要权重。这在最关键的地方减少了量化误差。

准确度下降程度取决于模型大小。 较大的模型 (7B+) 对激进量化的耐受性较好。Q4_K 格式的 Qwen3 7B 仍保持着具有竞争力的准确度。但较小的模型退化得更快——与高精度变体相比，Q3_K 格式的 Llama 3.2 1B 准确度下降了约 40%。经验法则：对于 3B 参数以下的模型，不要量化到 Q4 以下。

知识蒸馏 提供了另一条路径。你不再压缩模型权重，而是训练一个较小的模型来模仿较大模型的输出。据报道，Apple 正在将 Google 拥有 1.2 万亿参数的 Gemini 蒸馏成适合端侧处理的小模型。优势在于学生模型可以针对目标硬件进行架构优化。风险在于蒸馏模型在边缘案例上会继承老师那种“自信地犯错”的特质。

量化感知训练 (QAT) 能产生最佳的单位比特质量，但需要访问训练基础设施。对于拥有资源的团队，4 位 QAT 的表现始终优于同等精度的 PTQ。对于其他所有人，Q4_K_M 格式的 AWQ 是务实的默认选择。

压缩决策并非纯粹的技术问题。一个以每秒 30 个 Token 运行但错误率高出 15% 的模型并不便宜——它只是将成本转移到了下游的纠错环节。

路由层：决定请求的去向

在混合架构中，杠杆率最高的组件不是模型，而是决定哪个模型处理每个查询的路由器。如果路由出错，你不仅会在简单的查询上过度支出云端推理成本，还会让无法胜任的模型去处理复杂的查询，从而导致服务质量不足。

基于复杂度的路由是最常见的模式。一个轻量级的分类器评估传入的查询，并根据估计的难度进行路由。简单的分类、提取和格式化任务交给边缘模型。多步推理、长上下文综合和创意生成则交给云端。研究表明，这种方法可以在保持前沿模型 95% 性能的同时，降低 85% 的成本。

基于置信度的级联增加了第二个决策点。边缘模型首先尝试处理每一个查询。如果它的置信度分数（通过 Token 级熵或校准概率测量）低于阈值，查询就会升级到云端。这是 CE-CoLLM 和类似协作推理框架背后的模式。边缘模型使用提前退出机制在本地生成高置信度的 Token，只将不确定的 Token 发送到云端。其优势在于不需要单独的分类器——模型自身的不确定性成为了路由信号。

带有退修至人工的分级升级为高风险领域扩展了这一模式。边缘模型处理常规查询，云端大语言模型 (LLM) 处理复杂查询，只有最不确定的情况——即连云端模型的置信度也很低的情况——才路由给人工专家。这种三层模式在电信、医疗和法律应用中特别有效，因为在这些领域，错误答案的代价远超人工审核的成本。

一致性感知路由解决了一个更微妙的问题。当用户进行跨会话交互时，将同类型的查询路由到不同的模型会产生不一致的行为，从而损害信任。ConsRoute 和类似的框架保持了路由的一致性——确保昨天问过类似问题的用户今天能从同一级别的模型获得响应——同时仍然对成本和延迟进行优化。

路由层本身必须是轻量级的。如果你的路由器在决定查询去向时增加了 50 ms 的延迟，你就已经消耗了通过边缘推理节省下来的四分之一的延迟预算。在实践中，路由器通常是一个小型分类器或一组启发式规则，而不是另一个 LLM 调用。

可交付的架构模式

三种具体的架构涵盖了大多数生产环境中的混合部署。

模式 1：边缘优先且云端升级。 默认路径是在设备端。每个查询首先命中本地模型。只有未通过置信度检查或超过复杂度阈值的查询才会升级到云端。这最大限度地降低了云端成本并保护了隐私。当 60% 以上的查询都在边缘模型的能力范围内时（对于大多数消费级应用来说确实如此），这种模式效果最好。

模式 2：入口处的路由器分流。 在入口点的一个轻量级分类器在推理开始前将每个查询路由到合适的层级。对于那些注定需要云端处理的查询，不会在边缘端浪费计算量。当查询类型可预测且可分类时（例如，“总结这封邮件” vs. “分析这份法律合同”），这种模式效果最好。

模式 3：推测性边缘与云端验证。 边缘模型乐观地生成响应。对于高风险查询，云端模型异步地对边缘端的响应进行评分或验证。如果云端不认同，用户会在短暂延迟后看到云端的答案。这在保持质量的同时提供了即时的感知响应速度——这相当于用户体验 (UX) 中的乐观并发控制。

这三种模式都需要相同的基础设施原语：本地推理运行时、云端推理端点、路由/置信度机制以及回退路径。区别在于决策点的位置，以及你愿意在那些可能最终仍需升级的查询上投入多少边缘计算资源。

没人提醒你的失效模式

混合架构引入了纯云端系统所没有的失效模式。

模型版本偏差。 当你的边缘模型和云端模型对同一个查询产生分歧时，用户会注意到。如果边缘模型是三个月前更新的，而云端模型是上周更新的，它们的行为差异将无法通过任何路由逻辑来掩盖。你需要一套针对边缘模型的版本控制和更新策略，其严谨程度应与你的云端部署流水线一致。

无告知的离线性能降级。 当设备失去连接时，系统会静默回退到仅边缘模式。如果边缘模型无法处理该查询，失败是隐蔽的——表现为给出一个较差的答案而非不予回答。用户并不知道他们得到的是降级服务。修复方法是显式的能力告知：当用户处于离线模式时，告知他们以及哪些功能已受限。

量化引起的行为漂移。 一个在 Q4 量化下基准测试得分很高的模型，在你的特定任务分布上可能表现不同。基准测试的准确率是在数千个不同提示词上取的平均值。而你的生产流量会反复命中相同的狭窄模式，这些特定区域的量化误差会累积。请务必根据你的实际查询分布评估量化模型，而不是依赖通用基准测试。

电池和热降频。 在移动设备上，持续推理会导致热降频，从而随着时间的推移降低性能。你的模型在处理第一个查询时可能每秒生成 30 个 Token，但到第十个查询时，每秒可能只生成 15 个 Token。生产环境中的移动端推理需要考虑热预算，而不仅仅是峰值吞吐量。

路由博弈。 如果用户发现某些措辞会被路由到能力更强的云端模型，他们会调整自己的行为来触发云端路由。这是混合架构中相当于提示词注入的攻击——路由层变成了一个攻击面。监控路由模式，以发现异常的分布偏移。

决策框架

使用此框架来确定你的分工：

在以下情况下路由至边缘：

• 任务是分类、提取、格式化或简单的问答
• 延迟要求在 100ms 首个 token 以内
• 数据不能离开设备（合规、隐私或信任要求）
• 用户可能处于离线状态或连接不稳定
• 查询量大到云端成本变得显著

在以下情况下路由至云端：

• 任务需要多步推理或长上下文综合
• 输出质量比延迟更重要
• 查询涉及超出边缘模型训练数据范围的知识
• 任务是多模态的，且具有超出边缘内存的高分辨率输入
• 你需要最新的模型能力（前沿模型更新速度快于边缘端部署）

将 “从云端开始，迁移至边缘” 作为一种部署策略。先通过云端推理启动以验证产品。衡量你的查询分布。识别出那 60–80% 足够简单的查询，并将其交给边缘模型处理。针对这些查询部署边缘模型，保留云端处理长尾需求。这比从第一天起就构建混合架构更便宜，因为你可以在投入架构设计之前了解实际的流量模式。

云边混合模式是生产级 AI 的发展方向——这并不是因为边缘模式在绝对意义上更好，而是因为大多数现实世界的查询分布都是双峰分布（bimodal）。少数难题需要前沿模型（frontier models）的能力，而其他所有查询都在为它们并不需要的处理能力支付延迟和成本代价。工程上的挑战在于构建能可靠分离这两者的路由层，而运营上的挑战在于随着模型的演进保持两层同步。解决这两个问题的团队，其交付速度更快、成本更低，并且能提供比那些仍在将每个查询发送到云端的团队更好的用户体验。