端侧模型部署的 4 个坑：一份踩坑实录

踩坑实录系列。端侧推理的热潮起来了，教程遍地都是「三行命令跑起来」——但真把模型部署到边缘设备上跑业务，坑都在教程结束之后。这篇整理 4 个真实踩过的坑，每个都带现场和修复方案，给准备下场的人一份避坑图。

坑 1：量化后的精度塌方——只在某些语言上

现场：7B 模型 Q4 量化部署，英文测试全绿。上线后中文场景质量投诉——长句的「张冠李戴」型错误（主语指代错乱）显著增多，英文错误率 2%，中文冲到 9%。

原因：量化损失不是均匀的——中文 token 的分布更密，量化后的区分度损失集中在高频相近 token 上，指代词（他/她/它/这）首当其冲。

修复：①混合量化——首层和末层保持 FP16（对质量影响最大的层不量化），中间层 Q4，模型大 300MB 但中文错误率回落到 3% ②上线前测试集必须覆盖目标语言，只用英文 benchmark 验收就是盲飞。

坑 2：内存够了，但分配不出来

现场：8GB 设备，模型 4GB，加载时报 OOM——明明空闲内存 6GB。

原因：边缘设备的内存分配器对「单次大块连续内存」有限制（尤其安卓生态和某些嵌入式 SoC），碎片化的空闲内存拼不出 4GB 连续页。

修复：①启动时机——设备重启后第一时间加载（内存最干净）②模型分片加载+ mmap（不要求物理连续）③别在后台挂其他大内存应用——边缘设备的「多任务」幻觉要打破。

坑 3：首 token 延迟的冷启动陷阱

现场：测试时首 token 200ms，上线后用户反馈「要等 2 秒」。

原因：测试是热模型（权重已在内存）；线上经过系统休眠，权重被换出到 flash，首请求要先把 4GB 拿回内存——这个「冷首包」在低端 flash 的设备上要 1.5~2 秒。

修复：①保活心跳（每 30 秒一次空推理，代价是待机功耗）②明确的产品预期——唤醒场景给「正在唤醒」状态提示，比硬扛体验好③配置权重常驻标记（mlock 类机制），可用时优先用。

坑 4：同一模型，不同设备的速度差 5 倍

现场：两台都标「8 核」的设备，一台 14 tokens/s，另一台 2.8 tokens/s。

原因：端侧性能不是核数决定的——内存带宽（LPDDR4x vs LPDDR5）和大核架构（有没有专用 NPU/是否有大小核调度坑）才是推理速度的主变量。推理是访存密集型，带宽差 3 倍速度就差 3 倍，核数一样多也没用。

修复：①选型看内存带宽 spec，不看核数②大小核设备要绑定大核（推理线程亲和性设置），否则系统把任务调度到小核上，速度直接腰斩③同批次设备跑同一个基准脚本再部署，不要信厂商的「AI 算力 TOPS」宣传值——那是峰值，不是推理实测。

四坑合一的元教训

端侧部署的坑有个共同结构：测试环境与真实环境的差异被低估——量化精度（测试语言 vs 目标语言）、内存（开发板 vs 量产设备）、延迟（热模型 vs 冷唤醒）、速度（spec vs 实测）。解法也同构：验收标准全部换成目标设备上的真实指标，开发环境的数字只做参考。这一条做到了，四个坑至少避开三个。

（踩坑实录系列·端侧篇）