小模型竞技场横评：看清评测逻辑，指导本地部署与选型

小模型竞技场横评这两年越来越值得关注。原因很直接当大多数人还在调用云端大模型 API 时已经有开发者在认真研究怎么把模型塞进手机、电脑桌面工具甚至微信小程序里跑。karminski 发布的小模型竞技场横评把 8 款模型放在一起做全面对比本质上是在回答一个问题在不依赖高成本算力的前提下哪款小模型能帮你把真实任务顺利跑起来。这篇内容适合谁看一类是正在做选型的人比如要给微信小程序、本地离线工具、文档助手或者边缘设备挑一个小模型另一类是已经跑过一两个开源模型但对评测指标一头雾水的人还有一类是看完横评报告后想在自己的环境里复现验证的人。如果你属于其中任意一类这篇可以帮你省掉不少盲目试错的时间。先说一个基本判断横评结果只能当参考不能直接照搬到你的项目里。评测环境、量化方式、输入 prompt、批次参数每一项发生变化最终排名都可能变动。所以我下面不会只复述“哪个模型好”而是把这类横评背后的评测逻辑拆开讲清楚每个判断标准是怎么来的。这样你拿到任何一份横评报告都能快速判断它靠不靠谱也能在自己的环境里复现出有参考价值的结论。1. 小模型横评到底在评什么1.1 横评不是跑分榜先看任务场景8 款模型放在一起对比第一件事不是看谁总分高而是看它们各自适合什么任务。小模型通常指参数量在 0.5B 到 8B 之间的模型但不同尺寸之间的能力差距非常明显。0.5B 到 1B 的模型适合做文本分类、意图识别、关键词抽取这类轻量任务1B 到 3B 的模型可以处理中等难度的文本生成和多轮对话7B 到 8B 的模型已经接近一个可用的通用助手但和 70B 以上的大模型相比仍有明显差距。横评的价值就是把这种能力差异量化出来。常见的评测任务包括开放问答、指令理解、代码补全、数学推理、多轮对话、结构化输出等。不同模型的强项差异很大。有的模型中文文案流畅但数学能力薄弱有的模型代码能力突出但对话不够自然有的模型第一轮回答很好聊到第五轮就开始跑题。如果没有横评选型的人得把 8 款模型挨个跑一遍成本会高很多。但这里有个关键问题任务场景选得不一样结论可能完全反过来。比如横评如果全用英文 prompt 测试中文开发者的参考价值就打折扣如果全是单轮问答没有多轮对话测试那么对话型应用就没法据此选型。我的建议是拿到横评后先看它的任务构成再看它是否覆盖了你的核心场景。如果覆盖了排名靠前的模型值得进一步验证如果没覆盖那么总分排名对你基本没有意义。1.2 8 款模型来自不同定位综合排名要谨慎看小模型竞技场里的 8 款模型大概率不属于同一个定位。一类是通用对话模型主打日常问答和多轮聊天一类是指令微调模型主打服从指令、格式化输出还有一类是专用模型比如专门做代码补全或摘要生成。把不同定位的模型放进同一张榜单确实方便对比但也容易出现“田忌赛马”式的误判。举例来说如果一款模型是专门针对代码任务微调的你拿它和通用对话模型比中文写作它必然输反过来通用模型在代码生成任务上也未必占便宜。所以看横评时不能只看综合排名一定要看每个子任务的单项排名。综合排名权重是怎么算的、各子任务占比多少这些细节直接决定榜单顺序。还要注意模型版本。同一个系列的不同尺寸、不同微调版本性能可以差一大截。8 款模型可能来自不同系列、不同发布时间如果横评发布几个月后你再看到里面的结论可能已经部分过时。小模型迭代速度非常快横评更适合当作“初筛工具”而不是长期选型依据。2. 复现横评前先确认硬件和依赖环境2.1 CPU 与 GPU 决定了评测口径如果你打算自己复现一份小模型横评第一个要确定的问题就是评测跑在什么硬件上。同样是 3B 模型GPU 推理和 CPU 推理的耗时可以差好几倍。横评报告如果没有标明测试硬件那么所有速度、吞吐、显存数据都缺乏参照系你很难判断结果是否适用于自己的部署环境。我一般在本地复现时会先确认三件事显卡型号和驱动、推理框架版本、操作系统环境。不要小看框架版本同样的模型在特定版本的推理框架上可能快 20%也可能直接报错。常见的推理框架比如 llama.cpp、Ollama、vLLM它们支持的模型格式和量化方式各不相同混用容易出兼容性问题。如果只有 CPU也不是不能跑小模型评测但要把预期降下来。建议优先选择 GGUF 格式的量化模型批次大小设为 1先用一条短文本确认能跑通再逐步扩大评测集。很多人在这里踩坑一上来就加载原版 FP16 模型显存或内存不够导致进程直接被系统杀掉回头还以为是模型本身有问题其实只是没按资源条件调整加载方式。2.2 量化版本和推理框架必须统一量化是横评里最容易产生误解的点。同一个模型原始 FP16 版本、4bit 量化版、8bit 量化版跑出来的速度、内存占用和回答质量都不一样。如果横评里有的模型用原版跑有的模型用量化版跑那这轮对比本身就是不公平的。我建议做评测前把所有模型统一到同一个量化级别再用同一个推理框架、同一组推理参数去跑。如果横评报告没有说明精度默认就按“同精度、同框架、同批次”的标准来审视。现实中很多小模型是为了边缘部署而存在的量化后的表现反而比原版更有参考价值但你必须知道量化带来的损失边界简单任务上 4bit 量化几乎看不出差别长文本和复杂推理任务上短板就会暴露出来。这里还有个容易被忽略的依赖问题不同推理框架对量化格式的支持不一样。同一个 GGUF 文件在 llama.cpp 能正常加载换到其他框架可能不兼容。评测时最好固定一个推理框架否则模型文件本身的差异和框架差异会混在一起最后很难定位是哪一环导致的性能变化。3. 评测流程要按“单条、批量、复测”三步走3.1 先跑单条任务确认输入输出链路启动完整评测之前一定要先跑一条最小样例。样例不需要多难可以是“你好请介绍一下你自己”这类简单指令。目标是确认三件事模型能正常加载、输出能正常打印、日志里没有隐藏的 error 或 warning。这一步不能省。很多批量评测脚本看起来能跑实际上一大半任务因为输出格式解析失败被静默跳过你还以为已经成功。先跑单条任务就是为了确认输入、输出、日志三条链路都是通的再扩大评测规模。如果单条任务跑通后速度明显偏慢先别急着怀疑模型不行先看资源占用。用系统监控工具查看 CPU、内存、显存使用率同时确认模型是否真的加载到了预期设备上。很多人以为模型跑在 GPU 上实际因为驱动或框架配置原因模型悄悄退回了 CPU 推理。这种情况下的速度差异和模型能力无关。3.2 批量评测的 prompt 设计与结果记录批量评测的核心是把 8 款模型放在同一组输入之下输出统一保存。这一步最需要留意的就是 prompt 设计。不同模型对 prompt 格式的敏感度差异很大有的模型在完整指令格式下表现好有的在简洁问句格式下反而更自然。严格来说一款模型的真实水平应该用它的官方推荐格式来测。但横评本身要求对比就必须使用统一格式否则结果差异无法归因到模型本身。折中做法是先用统一格式跑完全部模型看结果差异然后对排名靠前或者差异异常的模型再用各自的官方格式复测一遍评估格式影响有多大。这个流程能帮你识别哪些结论是稳定成立的哪些只是 prompt 写法带来的假象。结果记录至少要包含这些字段模型名称、模型版本、量化级别、输入 prompt、输出原文、耗时、显存峰值、是否成功、异常信息。不要只记录分数。否则遇到输出被截断、复现失败、某项指标异常的情况你根本不知道是哪一步出的问题。评测日志本身就是排查问题的第一手依据。3.3 四组指标分开看速度、资源、效果、稳定性横评通常报告一大串指标我建议把它们分成四组来理解。第一组是速度类首次 token 延迟、生成速度、端到端耗时。首次 token 延迟影响交互体验生成速度影响批量任务的吞吐。两者不能混用首次 token 快不代表生成速度快。第二组是资源类显存峰值、内存占用、模型文件大小。这组数据决定模型能不能在你的目标设备上跑起来。如果目标设备只有 4GB 显存那评测里一个显存占用 5GB 的模型哪怕效果再好也和你无关。第三组是效果类任务完成率、回答正确性、文本连贯性、格式合规率。效果类指标需要人工抽查不能只看自动指标。自动评估经常出现“答案格式合格但内容完全不可用”的情况必须抽样人工读几份输出。第四组是稳定性连续跑 10 次任务的成功率、失败重试率、输出波动幅度。小模型的稳定性问题尤其突出同一个输入可能两次输出差异巨大。横评如果每个任务只测一次很容易被单次运气干扰所以复测时至少跑三次取稳定表现。4. 横评报告里的关键参数应该怎么读4.1 显存、延迟和吞吐量背后的选型含义很多人看横评只盯着最终总分但真正的选型决策通常是从资源约束倒推的。比如你的目标是把模型部署到用户的电脑上那就要先排除那些内存占用超过 8GB 的模型你的目标环境是微信小程序这类移动端那参数量超过 3B 的模型基本不用考虑。资源指标是硬门槛效果指标是软门槛先过硬的再谈软的。显存和内存一定要看峰值不是平均值。推理过程中显存会波动尤其当上下文长度不断增长时KV cache 会持续膨胀。如果横评只用短文本测试报出的显存值会明显偏低放到长文本场景下同样的配置很可能直接 OOM。首次延迟和吞吐量也是一个容易误读的组合。首次延迟低说明模型“开口”快适合聊天机器人吞吐量高说明模型“持续输出能力强”适合批量生成和离线处理。你的场景偏实时交互还是偏批量产出决定了这两个指标哪个权重更高。看横评时不要希望一款模型两个指标都领先现实中往往需要取舍。4.2 指令遵循能力比总分更贴近真实使用小模型在标准测试里可能表现不错但实际使用时常出现一个典型问题不听话。你要求它输出 JSON它给你一段解释你限制不超过 200 字它写了一页。这种“指令遵循能力”是横评里最值得关注的子项比综合总分更接近你的真实使用体验。判断指令遵循能力时建议重点看几类场景结构化输出、长度限制、角色设定、多步指令、格式要求。一款模型如果能在这些场景下稳定按要求输出那它比一个“话痨但总分高”的模型更适合接进生产系统。尤其在做接口封装、批量处理时输出格式不稳定会直接浪费你的解析和后处理成本。还需要注意小模型在长上下文下的指令保持能力。当输入变长、对话轮次变多小模型的注意力机制会更容易“抓不住重点”。如果横评只测短对话这个短板很难暴露。你自己复测时建议额外加一个长对话场景记录模型从第几轮开始出现重复、跑题或遗忘指令的情况。这个表现在实际聊天场景里影响很大。5. 小模型落地受限环境的典型思路微信小程序场景5.1 小程序跑模型先解决体积和算力约束微信小程序运行深度学习模型是最近讨论度很高的一个方向也是小模型最有代表性的应用场景之一。小程序环境有几个天然限制包体体积有上限、内存紧张、不能随意调用 GPU 算力、网络请求有延迟和成本。这意味着把小模型塞进小程序本质上是在做“预算内选型”。先看包体体积。模型文件本身就是最大的体积来源一个 1B 模型量化后大约 500MB 到 1GB对小程序的包体限制来说几乎不可接受。要做端侧推理通常只能选择更小的模型或者干脆把模型放在服务端小程序只负责请求和渲染。再看推理方式。小程序里跑模型需要依赖能编译到微信运行时环境的推理引擎同时还要考虑 WASM 或 WebGL 等加速方案的兼容性。这不是简单把模型文件放进去就能跑的需要针对小程序的运行环境做适配和分包处理。如果你看到某个项目号称“小程序直接跑模型”先问清楚一个问题模型到底在哪一端是完整模型在端上推理还是只是把后端推理结果通过接口返回两种方案的体积、延迟、成本完全不一样。5.2 任务拆分和量化取舍比模型排名更关键如果一定要把模型跑在小程序端侧通常的策略不是选一个“全能小模型”而是做任务拆分。比如做一个聊天助手可以把流程拆成三部分端上跑一个轻量意图识别模型把用户问题归到几个预设类别简单常见的固定问答由端上小模型直接回复复杂问题走后端大模型接口。这种架构既控制了包体体积也能把一部分流量留在端上降低服务端调用成本。任务拆分的关键是明确每个任务的复杂度边界。意图识别、关键词抽取、短文本分类这类任务0.5B 到 1B 的模型已经完全够用开放式长文本对话、代码生成、复杂推理小模型无论如何优化都顶不上必须交给大模型。横评结果在这个场景里的意义就是帮你判断不同模型在处理哪一类任务时最接近“可用”而不是非要找一个万能模型。另一个重要取舍是量化深度。小程序场景下如果 4bit 量化版模型体积仍然超标可以继续尝试更激进的压缩方式但效果下降会更明显。我的建议是先确认体积和延迟达标再看输出质量。质量可以靠 prompt 工程和任务约束补一部分但体积不达标意味着这个功能根本没办法上线。不要为了追求高质量而选一个塞不进去的模型那是白费功夫。6. 自己复现横评时最容易踩的几个坑6.1 模型版本和文件来源不对结论全废复现横评最常踩的坑是下载模型时没注意版本。同一个系列模型可能同时存在 base、chat、instruct 等多个版本它们的行为差异非常大。base 版本没有经过对话微调你拿它做聊天测试结果当然很差。横评报告说“8 款模型全面对比”你要先确认每一款具体用的是哪个版本再讨论排名。还要注意模型文件的来源和更新时间。开源模型仓库经常更新你今天下载的文件和横评发布时使用的文件可能已经不是同一个版本。建议在评测记录里保存模型仓库的 commit ID 或文件哈希保证以后可以精确还原。没有这个习惯的话几个月后回来看同一个模型名字内容可能已经完全变了结论自然对不上。6.2 prompt 不公平结果没法归因prompt 不公平是横评里最隐蔽的问题。同样的题目给模型 A 使用详细指令格式给模型 B 使用简短问句格式模型 B 表现差不一定代表它能力弱而是它没有获得足够清晰的指令引导。我的做法是自己复现时最少准备三套 prompt 模板详细指令版、简洁询问版、带上下文的对话版。每套模板都把全部模型跑一遍再对比结果。如果某款模型只在特定模板下表现出色说明它明显依赖 prompt 格式真实部署时需要专门设计提示词如果某款模型在三套模板下都稳定那才是真正值得考虑的稳健选手。6.3 只看输出不看日志会漏掉关键异常评测不能只看最终输出。模型打印的结果可能只是“最终回答”但中间可能发生过重试、截断、超时、格式转换失败等事件。如果不看日志这些异常根本不会进入你的视野。我在批量评测时一般会开两层日志一层是推理框架的日志记录模型加载耗时、生成参数、token 数量另一层是自动化脚本的日志记录每个任务的状态、耗时、失败原因。评测结束后先统一扫一遍日志再分析结果。如果某款模型的成功率明显偏低先看失败原因是超时、内存不足还是输出解析失败。很多时候问题出在评测脚本或运行环境上直接把它归咎于“模型效果差”会误导选型。评测期间的机器状态也要保持干净。不要把下载任务、视频转码、大型编译任务和评测同时跑。模型推理对资源占用很敏感满载状态下速度会明显下降导致横评数据失真。评测时 CPU、GPU、内存的占用越稳定结果越能反映模型本身的能力。6.4 横评有时效性最终选型必须回测最后强调一个容易被忽略的点横评结论有很强的时效性。小模型领域迭代非常快同一个系列可能每隔几个月就发布新版本旧版横评很快就会过时。看完横评先确认发布时间和模型版本如果已经过去超过半年把它当成背景知识就够了不要直接作为选型依据。真正靠谱的流程是把横评当初筛工具选出 2 到 3 款候选模型然后放到自己的数据集、自己的硬件、自己的任务场景里跑一轮小样本回测。回测数据量不需要很大几十条真实样本就能看出明显差异。重点在于让候选模型面对真实输入分布而不是躺在通用测试集里比较。小模型横评的价值不在于告诉你哪一款“天下第一”而在于帮你把选择范围缩小到值得深入验证的候选集合。karminski 这轮 8 款模型对比给社区提供了一个不错的参考起点。但任何横评都只是半成品真正决定选型的还是你自己的设备条件、任务类型和稳定性要求。看完横评想动手试的话我建议从单条任务开始先确认模型能加载、输出能读取、日志没有异常再考虑批量测试和部署上线。先把这条路走通再谈排名高低。很多看起来像模型差距的问题其实把环境、版本和输入格式处理好之后自己就消失了。