上一季度发布的端侧 AI 演示在单台测试手机上运行了一个 4-bit Llama 变体，表现出色。六个月后，同样的功能却收到了一连串的一星差评，用户抱怨发热、耗电，或者更糟糕的是——无声的质量下降，用户只觉得“老手机上的 AI 变傻了”。模型没变，但机群（fleet）变了。那些原本以为是在交付模型的团队后来才发现，他们交付的其实是一个机群。
这就是导致大多数端侧 AI 发布失败的鸿沟：策略是围着选择“那个”模型转，而真正的难点在于如何为每类设备交付“合适的模型”，观察其运行情况，并在出问题时回滚。弥合这一鸿沟的学科更像是 CDN 运营，而非 ML 研究——清单驱动（manifest-driven）的交付、按分群的遥测、解耦的发布渠道，以及能从一个训练好的检查点生成 N 个量化分级的模型变体流水线。大多数团队并不具备这些，他们只有一个模型卡（model card）和一个构建产物。
一个在单张 RTX 4090 上运行的经过微调的 7B 参数模型，可以在特定领域任务上超越 GPT-4，同时在初始硬件投资之后每个 token 的成本为零。这不是理论上的说法——Diabetica-7B，一个专注于糖尿病的模型，在临床查询上达到了 87.2% 的准确率，在同一基准测试中击败了 GPT-4 和 Claude 3.5。但前提是什么？你需要准确理解边缘推理何时有意义，何时只是昂贵的干扰。
大多数团队默认使用云端 API，因为它们简单。你发送一个 HTTP 请求，就能得到 token 返回。但这种简单性有一个成本，它的扩展方式是许多工程师在为时已晚之前没有预料到的——而且成本并不总是以金钱来衡量的。
你的 LLM 在云端生成的每一个 Token 都在产生费用，增加延迟，并跨越网络边界传输用户数据。在设备端生成的每一个 Token 都避开了这三个问题——但受限于手机或笔记本电脑 GPU 的处理能力。有趣的工程挑战发生在边界上：决定哪些查询值得调用云端的前沿能力，而哪些更适合由运行时间不到 20 毫秒的 3B 参数本地模型来处理。
混合云边推理模式并非理论。Apple Intelligence 在端侧模型和私有云计算 (Private Cloud Compute) 之间进行路由。Google 的 Gemini Nano 直接在 Pixel 和三星设备上运行，同时将复杂的请求升级到云端 Gemini。这些不是演示项目——它们正以数十亿设备的规模进行交付。而底层架构现在正被任何愿意仔细思考“延迟-隐私-成本”三角形的团队所采用。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
