端侧大模型上线 8 个月,给我们上了 4 课
📖 摘要:把大模型搬上端侧(手机/浏览器/嵌入式)是 2026 年最热的方向之一------低延迟、隐私、离线可用。但"端侧"不等于"纯离线"。本文以某后台服务接入端侧推理的 8 个月实践为引,复盘 4 个真实教训:混合路由才是正解、显存不是银弹、首字延迟比吞吐更影响体验、OTA 与回退不能省。附端云协同路由的可运行示例,帮你少走弯路。
🏷️ 关键词:端侧推理,边缘 AI,混合路由,模型量化,WebLLM,端云协同
目录
- 一、起点:为什么要把模型搬上端侧
- [二、第 1 课:端侧不等于离线,混合路由才是正解](#二、第 1 课:端侧不等于离线,混合路由才是正解)
- [2.1 一个端云协同路由器](#2.1 一个端云协同路由器)
- [三、第 2 课:显存/内存是硬约束,量化不是银弹](#三、第 2 课:显存/内存是硬约束,量化不是银弹)
- [四、第 3 课:首字延迟比吞吐更影响体验](#四、第 3 课:首字延迟比吞吐更影响体验)
- [五、第 4 课:OTA 与回退机制不能省](#五、第 4 课:OTA 与回退机制不能省)
- 六、总结
一、起点:为什么要把模型搬上端侧
我们把一个"语音助手"能力接入某后台服务时,最初全走云端:延迟高、隐私顾虑大、弱网直接不可用。于是尝试把小模型(约 1.5B 参数)放进端侧,目标很朴素------常见请求本地秒回,复杂请求再上云。
8 个月后我们收回一句当初的傲慢:"端侧很简单,塞进去就行。"
二、第 1 课:端侧不等于离线,混合路由才是正解
纯端侧能力有限(小模型知识窄、推理慢),纯云端延迟与隐私受限。按任务难度/网络状况动态选路才是主流架构。
2.1 一个端云协同路由器
ts
// 混合路由(示意):简单意图走端侧,复杂/敏感走云端
type Route = 'on-device' | 'cloud';
function routeRequest(input: string, net: { online: boolean }): Route {
if (!net.online) return 'on-device'; // 离线强制端侧
const complexity = estimateComplexity(input); // 关键词/长度/意图分类
if (complexity < 0.3) return 'on-device'; // 简单问答本地答
return 'cloud'; // 复杂推理上云
}
async function answer(input: string) {
const route = routeRequest(input, { online: navigator.onLine });
return route === 'on-device'
? runOnDevice(input) // WebLLM / ONNX Runtime Web
: runOnCloud(input); // 云端大模型 API
}
💡 经验:别追求"全端侧",把端侧当默认低延迟通道 ,云端当兜底能力,体验最稳。
三、第 2 课:显存/内存是硬约束,量化不是银弹
4-bit 量化能塞下更大模型,但会带来精度下降与特定任务崩坏 。我们踩过:量化后数学推理正确率掉一截,且某些长上下文直接 OOM。对策是做分层量化 + 硬上限保护:
- 按设备档位选模型(高配跑 4-bit 1.5B,低配退 0.5B 或纯云端);
- 显存超阈值立即拒绝加载并回退云端;
- 量化版本必须跑回归集,不能只看"能跑起来"。
四、第 3 课:首字延迟比吞吐更影响体验
用户感知的是"多久出第一个字",不是"每秒多少 token"。端侧首字慢(要加载权重、预热)比云端更明显。我们做了三件事:
- 预加载 + 常驻:应用启动即懒加载模型到显存,别等用户提问才加载;
- 流式输出:先吐字再补全,体感快一倍;
- 缓存热路径:高频意图结果缓存,跳过推理。
五、第 4 课:OTA 与回退机制不能省
端侧模型是"发版即定型",但模型会迭代、会出坏版本。必须能做远端下发新权重 + 一键回退旧版本,否则一个坏模型要等应用商店审核才能修。我们的最终结构是:
端侧模型 ← OTA 下发(带版本号 + 校验和)
← 回退开关(远端配置,秒级生效)
云端兜底 ← 端侧加载失败/超时时自动切换
六、总结
端侧大模型不是"把云模型缩小扔进手机"那么简单。4 课浓缩成一句话:混合路由定架构、量化要带回归、首字延迟定体验、OTA 回退定生死。把这套想清楚再动手,8 个月的坑你三个月就能跨过。
觉得有用就点个赞/收藏,评论区说说你端侧推理踩过最痛的坑。