端侧小模型排名

你可能遇到过这种情况：榜单上排前面的小模型，下载到板子或手机上跑不起来；换一个参数更小的，效果又掉得厉害。问题不在模型本身，而在于排名是按通用条件测的，你的设备、量化档位和内存带宽跟测试环境不是一回事。这篇给一条可执行的筛选路线：先量自己的硬指标，再定量化档位，最后拿少量真实样本验收。

榜单上排前面的小模型，下到板子或手机上跑不动，换个小点的效果又掉一截——这种落差基本都出在同一件事上：排名是按统一算力和统一精度测出来的，你的设备、量化档位、内存带宽跟测试环境压根不是一回事。所以正确的顺序不是先翻名次，而是先量自己的硬指标，再定量化档位，最后拿少量真实样本验收。

下面这条路线是给做端侧部署的人用的，目标是把「能跑到稳态」和「效果够用」这两件事同时满足。榜单可以当候选池，但最终决定权在你手里的设备上。

榜单名次为什么搬到端侧就不准

通用榜单通常在固定算力、统一精度、稳定供电的条件下跑，比的是模型本身的天花板。端侧的真实瓶颈往往不在算力峰值，而在内存带宽和散热：跑一会儿就降频，带宽不够导致加载权重的时间远大于计算时间。这些因素榜单不会替你在意。

• 同一模型换个量化档位，排名顺序可能整体洗牌，看名次前先确认它测的是哪一档；
• 任务不匹配最要命：通用问答靠前，未必在关键词抽取、意图分类这类窄任务上占优；
• 榜单很少告诉你冷启动耗时和连续运行后的内存增长，而这两项端侧最敏感；
• 想看不同人实测口径差在哪，去 看多人多时段交叉验证的做法，别只信单次分数。

先量自己的硬指标，再谈排名

把可用内存（或显存）、可持续占用的算力、功耗与散热上限列清楚，注意要稳态数值，不是峰值。峰值只说明「能撑一下」，端侧产品要的是「能一直撑住」。内存估算别只看权重文件大小，运行时的临时占用经常被忽略。

具体换算口径和现成表格到 和 里核对，站内给的是方法论，实际数字随设备型号变化，别直接抄。

量化档位怎么定，直接决定你能跑哪个

正确的顺序是：先定量化档位，再看这个档位下谁的效果好。因为同一模型在不同档位之间的效果差，往往比相邻两名之间的差距还大。端侧优先看内存占用和首字延迟，只要效果损失在你任务可接受的范围内，就往下压一档。

档位与排名

看名次前先确认它是在哪个量化档位下测的，跨档位比较没有意义

压缩的代价

压得越狠，某些能力退化越明显，要按你的具体任务验证，而不是看通用榜单

取舍依据

端侧通常牺牲一点效果换内存和延迟，云端部署则反过来

参考口径

量化相关对照到 同分区页面看，以站内当时的说明为准

不适用的情况：如果你的端侧只是做兜底、主逻辑走云端，那本地效果可以放宽，优先保延迟和可用性，不必为了几个点硬压档位。

一套可执行的筛选顺序

1. 从任务出发列候选按你的任务类型列 3-5 个候选，而不是从排名第一往下翻；候选来源可以是站内模型库按能力标签筛。
2. 用硬指标做减法拿上一步量出的内存、带宽、稳态算力，把跑不到稳态的候选直接划掉，别抱侥幸。
3. 小样本验收每类任务准备少量真实样本，跑一遍看错例长什么样；错例模式比总分更有信息量。
4. 留备用方案保留一个备选模型，防止主选模型后续更新后设备跑不动，端侧换模型成本比云端高。

这套顺序的价值在于：先把不可能跑起来的排除掉，再把精力放在少数几个真能落地的候选上，避免在榜单名次上反复纠结。

上线前的核对清单与不适用场景

• 冷启动耗时、连续运行后的内存增长、断电重启后能否恢复、日志体积
• 模型与分词器版本要配套，单独换权重容易出乱码或截断
• 许可证是否允许你的分发方式，端侧产品常常涉及随硬件出货
• 异常输入下的表现，比如超长文本、空输入、特殊字符
• 降频后的延迟是否仍在可接受区间，别只在满血状态测

不适用的场景：端侧只做兜底、主逻辑走云端的架构，不必死磕本地效果，优先保延迟和可用性；设备形态频繁变化的项目，也要重新跑一遍上面的筛选，不能沿用上一版结论。