11 篇博文 含有标签「edge-ai」

上一季度发布的端侧 AI 演示在单台测试手机上运行了一个 4-bit Llama 变体，表现出色。六个月后，同样的功能却收到了一连串的一星差评，用户抱怨发热、耗电，或者更糟糕的是——无声的质量下降，用户只觉得“老手机上的 AI 变傻了”。模型没变，但机群（fleet）变了。那些原本以为是在交付模型的团队后来才发现，他们交付的其实是一个机群。

这就是导致大多数端侧 AI 发布失败的鸿沟：策略是围着选择“那个”模型转，而真正的难点在于如何为每类设备交付“合适的模型”，观察其运行情况，并在出问题时回滚。弥合这一鸿沟的学科更像是 CDN 运营，而非 ML 研究——清单驱动（manifest-driven）的交付、按分群的遥测、解耦的发布渠道，以及能从一个训练好的检查点生成 N 个量化分级的模型变体流水线。大多数团队并不具备这些，他们只有一个模型卡（model card）和一个构建产物。

大多数构建端侧 LLM 功能的工程师，将时间花在解决那些显而易见的问题上：量化、延迟、内存限制。模型能装进手机，推理速度够快，演示效果也很好看。然后他们向数百万台设备发布，才发现一个更难的问题——从来没人提前告诉他们：你现在有数百万个独立的计算节点，运行着你 AI 模型的不同版本，而你根本没有可靠的方式知道任何一个用户运行的是哪个版本。

云端推理在最好的意义上是无聊的。你更新模型，重新部署服务器，几分钟内整个用户群就都在运行新版本了。端侧推理则彻底打破了这个假设。一个三个月前最后一次打开你应用的用户，仍在运行那时当前的模型——而且没有干净的方法强制更新，没有服务器端回滚，也没有简单的方法在没有你从一开始就构建的监控埋点的情况下检测到版本不匹配。

这种版本碎片化是端侧 AI 的核心运营挑战，其后果远不止缓慢的发布。它造成无声的能力漂移，使事故响应复杂化，并将你的"AI 功能"变成一个由独立运行的异构系统组成的庞大集群——你对其负责，却无法直接控制。

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

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

大多数AI推理决策都遵循同一逻辑：模型部署在云端，因为只有在那里才能运行，仅此而已。但这一算法正在迅速改变。旗舰智能手机现在搭载了能够以交互速度运行70亿参数模型的神经引擎。骁龙8 Elite可以以约每秒10个token的速度从30亿参数模型生成内容——足够流畅的对话体验——而高通Hexagon NPU在预填充阶段可达到每秒690个token。问题不再是"我们能否在设备上运行？"，而是"我们应该这样做吗，什么时候该这样做？"

答案很少是显而易见的。将推理迁移到边缘端会引入真实的权衡：量化带来的质量损耗、设备机群更新的维护负担，以及跨设备SKU的硬件碎片化。但留在云端也有其代价：数百毫秒的往返延迟、随规模扩展而累积的云GPU账单，以及没有任何SLA能完全解决的数据主权问题。本文为应对这些权衡提供了一个实用框架。

模型路由是大多数团队首先采用的优化手段：将简单查询路由到小型廉价模型，复杂查询路由到大型强力模型。它在控制成本和吞吐量方面效果良好。但当云端推理的物理限制与 100ms 以内的延迟需求发生碰撞时，路由便无能为力了。从中间层数据中心发出的一次网络往返，在生成第一个 token 之前就已消耗 30–80ms。此时路由毫无意义——你要么需要将模型运行得更靠近用户，要么需要运行一个规模大幅缩减的模型。这两条路都需要压缩决策，而大多数团队对此并没有清晰的框架。

本文是一份做出这些决策的指南。量化、知识蒸馏和端侧部署这三种技术解决的问题有所重叠，但它们的成本结构、质量表现和运营影响各不相同。

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

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

一个在单张 RTX 4090 上运行的经过微调的 7B 参数模型，可以在特定领域任务上超越 GPT-4，同时在初始硬件投资之后每个 token 的成本为零。这不是理论上的说法——Diabetica-7B，一个专注于糖尿病的模型，在临床查询上达到了 87.2% 的准确率，在同一基准测试中击败了 GPT-4 和 Claude 3.5。但前提是什么？你需要准确理解边缘推理何时有意义，何时只是昂贵的干扰。

大多数团队默认使用云端 API，因为它们简单。你发送一个 HTTP 请求，就能得到 token 返回。但这种简单性有一个成本，它的扩展方式是许多工程师在为时已晚之前没有预料到的——而且成本并不总是以金钱来衡量的。

大多数团队都会面临选择：要么在云端运行一切，要么压缩模型以适配设备端。这两种选择都会造成成本浪费和性能损失。在 2025-2026 年获得最佳效果的团队两者都不选 —— 他们正在构建混合架构，根据复杂度、延迟预算和数据敏感性，将每个推理请求路由到合适的层级。

核心洞见简单但被低估了：70-80% 的生产查询并不需要前沿模型。它们需要来自靠近用户的模型提供的快速回答。剩下的 20-30% 则真正受益于云端托管的重量级模型。工程上的挑战在于构建路由层，使这种切分对用户无感。

大多数团队都会选择一个阵营：要么将所有任务运行在云端，要么将所有任务推向边缘。对于大多数生产负载来说，这两种做法都是错误的。有趣的工程挑战发生在它们之间的路由层（routing layer）——这个组件根据每个请求来决定：该查询是需要 H100 上的 70B 前沿模型，还是在本地芯片上运行的 3B 量化模型。

这种路由决策不仅仅关乎延迟。它是一个涉及成本、隐私和能力的三变量优化过程——而最优的分配方案会根据你的流量模式、监管环境以及对每种查询类型“足够好”的定义而改变。正确处理路由的团队在降低 60–80% 推理成本的同时，还能优化 p95 延迟。处理不当的团队要么在简单的查询上过度消耗云端 GPU，要么让无法处理复杂任务的边缘模型提供质量下降的回答。

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

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

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

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