跳到主要内容

混合云边 LLM 推理:决定模型运行位置的延迟-隐私-成本“黄金三角”

· 阅读需 14 分钟
Tian Pan
Software Engineer

大多数团队通过云端 API 运行每一次 LLM 调用。这是阻力最小的路径:无需管理硬件,无需优化模型,而且最新的前沿能力只需一个 HTTP 请求即可获得。但随着 AI 深入生产环境 —— 处理敏感文档、支持实时交互、在移动设备上运行 —— 云端始终是正确答案的假设开始出现裂痕。

裂痕同时出现在三个地方。时延:在聊天机器人中察觉不到的 200 ms 网络往返,在语音 AI 或实时代码补全中变得不可接受。隐私:离开设备的数据会产生合规风险,法律团队越来越不愿签字。成本:在请求量大且利用率波动低的情况下,你正在为你完全可以拥有的基础设施支付高额溢价。

答案并非放弃云端推理 —— 前沿推理模型和长上下文任务确实需要它。答案是停止将模型部署视为二选一,而是将其视为一种路由决策。混合云-边缘架构根据查询复杂度、时延要求和数据敏感性,将推理分摊到设备端模型和云端 API。做得好,这种方法可以将成本降低 80% 并消除大部分请求的网络时延。做得不好,它会产生两种故障模式而非一种。

时延-隐私-成本三角

每个推理请求都处于由时延容忍度、数据敏感性和可接受成本定义的三维空间中。大多数团队犯的错误是优化了一个维度而忽略了另外两个。

时延分为两个截然不同的问题。首字延迟 (TTFT) 决定了应用程序的响应速度 —— 语音 AI 需要 LLM 阶段在 150 ms 以内,而仅云端往返就消耗了其中 20–80 ms 的预算。吞吐量决定了处理批处理工作负载的速度。在交互式用例中,边缘端在 TTFT 方面具有决定性优势。在可以摊销设置成本的批处理中,云端在吞吐量方面胜出。

隐私并非非黑即白。某些数据永远不能离开设备(健康记录、受监管行业的财务文档)。某些数据受到合同限制(企业协议下的客户数据)。某些数据只是足够敏感,以至于你倾向于不将其发送给第三方。每个类别都意味着不同的部署约束。

成本在很大程度上取决于利用率模式。云端 GPU 在持续利用率达到 70% 以上时具有成本竞争力,因为你只需为实际使用的部分付费。低于该阈值时,设备端硬件胜出,因为你已经支付过费用了。将 80% 的查询路由到边缘模型、20% 路由到云端 API 的混合架构已被证明比纯云端部署降低了超过 80% 的成本。

核心洞察:这三个维度在生产流量中是相关的。低复杂度查询(占大多数)往往对时延敏感,涉及常规数据,且本地服务成本低。真正需要前沿模型的高复杂度查询较少,对时延的容忍度更高,且值得支付云端成本。这种相关性正是混合架构可行的原因。

现在有哪些模型真正运行在边缘端

设备端模型的格局已经发生了巨大变化。曾经 7B 参数似乎是连贯生成的最低门槛,而现在亚十亿参数模型已经能胜任实际任务。当前这一代适用于边缘端的模型包括 Llama 3.2 (1B/3B)、Gemma 3 (低至 270 M 参数)、Phi-4 mini (3.8B)、SmolLM2 (135M–1.7B) 以及 Qwen2.5 (0.5B–1.5B)。

这些不是玩具模型。在 Apple M4 芯片或 Qualcomm Snapdragon 8 Elite 上运行的量化良好的 3B 模型可以处理文本格式化、实体提取、短文档摘要、分类和简单的问答 —— 这涵盖了生产环境 LLM 流量中惊人的比例。

硬件端也同步趋于成熟。像 RTX 5090 这样的消费级 GPU 运行量化后的 7B 模型速度可达每秒 150–260 个 token。Apple Silicon 的统一内存架构让 M4 Max 机器能够运行 30B+ 参数的模型,而没有 CPU-GPU 传输瓶颈。移动 NPU 现在提供了可观的 TOPS 数值,接近 2017 年的数据中心 GPU 能力。Meta 的 ExecuTorch 在 2025 年 10 月发布了 1.0 GA 版本,支持 12 种以上的硬件后端,标志着生产级设备端部署的转折点。

但原始能力并不能告诉你边缘推理对于你的工作负载是否可行。关键问题更加具体:

  • 内存带宽而非计算能力通常是瓶颈。LLM 推理在生成 token 过程中受限于内存。一个能装进内存但无法快速流式传输权重的模型,无论可用 FLOPS 有多少,生成 token 的速度都会很慢。
  • KV 缓存大小随上下文长度增长,并决定了边缘设备可以支持多少并发会话。具有 4K 上下文的 3B 模型是可控的。同样的模型如果具有 32K 上下文,可能会在单个请求中耗尽可用内存。
  • NPU 兼容性因芯片组而异。每个制造商实现的算子集不同,这意味着为某个 NPU 优化的模型在另一个 NPU 上可能需要修改或回退到 CPU/GPU。如果 NPU 支持的算子与你的模型架构不完全匹配,这种转换过程可能会降低性能。

保持任务准确性的模型压缩

要在边缘硬件上运行前沿质量的模型,必须进行压缩。然而,能够保持基准测试 (benchmark) 准确性的压缩方法往往无法保持特定任务的准确性。这种区别在生产环境中至关重要。

压缩工具包包含四种主要技术,通常结合使用:

量化 (Quantization) 降低了数值精度 —— 将 FP32 转换为 INT8 可以将模型体积缩小 4 倍,并按比例加速计算。实际问题在于选择哪种量化方法。训练后量化 (Post-Training Quantization, PTQ) 速度快但有损:你在模型训练完成后降低其精度。量化感知训练 (Quantization-Aware Training, QAT) 在训练期间融入精度约束,通常能达到原始 FP32 的准确度,但需要访问训练基础设施。对于大多数使用开源权重模型的生产团队来说,现实的路径是进行带有精细校准的 PTQ,接受 1–3% 的准确度损失。

动态量化根据层来调整位宽,因为它意识到注意力层和 MLP 层对精度损失的敏感度不同。这种灵活性让你可以在安全的地方进行激进压缩,并在关键的地方保持精度。

加载中…
References:Let's stay in touch and Follow me for more thoughts and updates