2 篇博文 含有标签「on-device」

过去，那种“在标签页中运行模型”的故事很容易被忽视：小模型、新奇的演示、在笔记本电脑风扇狂转前只能运行 30 秒的 Whisper 语音转录。现在，那个时代已经结束了。量化技术得到了改进，WebGPU 已经在所有主流浏览器中发布，设备端缓存获得了持久配额，现在 4-bit 3B 模型在价值 500 美元的笔记本电脑上输出 token 的速度，已经快到让用户感到“流畅”。“这是否应该在服务端运行？”不再是一个默认选项 —— 这是一个关键的架构决策，如果你的产品团队每次都直接接受平台团队的第一个方案，那么他们就在无意中做出了这个决定。

随之而来的错误比演示效果变差更严重。团队为整个产品选择一种后端 —— 通常是服务端推理，有时是浏览器推理 —— 然后在每个不匹配的功能上付出错误的代价。对隐私敏感的功能输给了对延迟敏感的功能，因为架构强制给出了单一答案。或者更糟，团队因为演示时的惊艳效果选择了浏览器原生方案，然后发布了一个“机群级”的体验，导致长尾设备群体中 30% 的用户获得了一个性能降级的产品，而仪表盘却无法察觉。

浏览器原生 AI 并不是更快的 TensorFlow.js。它是一个具有不同 SRE 逻辑、不同成本模型以及四个无法坍缩为单一答案的权衡维度的不同运行时。将其视为“API 调用的廉价版本”是 2026 年最典型的架构错误。

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

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