小模型横评怎么选？从端侧推理到小程序部署的实用指南

最近，AI 圈又掀起一股“小模型热”。karminski 发布的小模型竞技场横评，把 8 款主流小模型拉到同一套评测流程里，比能力、比速度、比体积，在开发者群里引起了不少讨论。

为什么一次横评能引起关注？因为市面上的小模型太多，Qwen、Phi、Llama、Gemma，每家宣传语都像“最强”，但真正放到业务里，问题立刻变成三个：它跑得动吗？它跑得快吗？它放在我的设备上会不会卡？相比大模型看榜单分数，小模型更需要横评——因为大家关心的不是智商天花板，而是工程地板。

这篇文章不打算逐个复述榜单数值，而是以这次横评为切入点，把“小模型横评”这件事拆开讲清楚：横评到底在评什么、8 款主流模型各自擅长什么、你是做微信小程序端侧推理还是做私有化服务，该如何在横评数据之外做选型决策。无论你是在调研端侧 AI 方案，还是被“微信小程序运行深度学习模型”这类需求裹挟着往前走，这篇都值得花十分钟读完。读完你会明白：小模型横评的最大价值不是告诉你“谁最强”，而是告诉你“该选谁”。

1. 为什么小模型横评突然重要了？

三年前，提起大模型，所有人的目光都在千亿参数模型身上。今天，行业的注意力第一次认真转向了 1B 到 7B 的小模型。这个转变不是模型圈的审美变化，而是工程倒逼的结果。

第一个现实是成本。千亿级模型跑一次推理，需要高性能 GPU，成本按小时计；而一个 1.5B 或 3B 的模型，量化后可以跑在普通 CPU、移动端，甚至一台小型边缘设备上。很多企业内部工具、客服摘要、表单抽取、日志分类场景，并不需要一个能写诗的大模型，只需要一个判断稳定、响应快、好维护的小模型。

第二个现实是端侧需求。越来越多的产品希望把 AI 能力放到用户设备上。手机助手、离线翻译、智能摄像头，以及被反复提到的微信小程序运行深度学习模型，都属于这一类场景。设备端存储有限、算力有限、功耗敏感，唯一承受得起的，就是小模型。

第三个现实是私有化。很多企业数据不能出内网，不能调云端 API。他们需要把模型部署到自己的服务器、国产化硬件、边缘设备上。在这样的环境里，模型体积、推理延迟、资源占用，往往比分数更重要。

把这些因素放在一起，就能理解小模型竞技场横评为什么会有讨论度：它第一次把“模型智能高低”和“能不能落地”放到同一张评测表里，让开发者不用再靠宣传文案做技术选型。

2. 小模型是什么？为什么参数小也能打？

在很多开发者印象里，模型参数量越大越聪明，小模型是不是意味着能力打折？这种理解只对了一半。小模型的定义不是“能力残缺的模型”，而是在模型结构、训练数据和推理开销之间做了重新平衡的产物。

小模型通常指 10B 参数以下的模型，最主流的是 1B 到 7B。它们的智能来自三个方面：更强的训练数据、更高效的模型结构，以及从大模型身上学来的能力。尤其是“蒸馏”技术，可以让小模型继承大模型的一部分推理能力，解决很多单一任务完全够用。

与“直接训练一个小的模型”不同，当前主流小模型更像是“大模型能力的压缩版”。这里有三条技术路线值得了解：

• 知识蒸馏：用大模型的输出去训练小模型，让小模型学习大模型的推理方式和答案偏好。
• 结构化剪枝：删掉模型中影响较小的神经元或注意力头，减小参数量。
• 量化：把模型权重从 FP16 降到 INT8 或 INT4，显著减小体积，提升推理速度，虽然会有少量精度损失。

更直白的比喻是：大模型像一台服务器，什么任务都能跑；小模型像一台专用终端，常用任务跑得又轻又快。选择小模型，本质上是你确认业务场景的任务边界清晰，不需要动用大模型的全部能力。

大模型与小模型的差异，可以简单对比：

容易被忽略的一点是：小模型的“小”是相对的。1.5B 和 7B 之间的体验差距，可能比 7B 和 70B 之间的体验差距还要明显。在横评里，参数量相同的模型跑出的结果可能差异很大，训练数据、微调策略、对齐方式都会影响最终表现。这也是为什么横评必须跑同一套评测任务，而不是直接比对官方宣传页。

3. 竞技场横评的关键指标：不只是跑分

传统大模型评测看的是 MMLU、GSM8K、HumanEval 这类基准分数，分数越高代表知识量和推理能力越强。但小模型横评不可能只看这些。对于一个要部署到端侧或 CPU 场景的模型，工程指标和智能指标同样重要。

3.1 能力类指标

能力类指标回答的是“这个模型能不能干好活”。常见维度包括：

• 通用知识问答准确率。
• 文本分类、信息抽取等任务上的 F1 或准确率。
• 摘要任务的内容完整性和关键信息保留率。
• 指令跟随能力，也就是模型能否严格按用户要求输出格式。
• 多轮对话的一致性，这在小模型上往往是短板。

能力指标不能只看绝对数值，还要看任务类型。小模型在分类、抽取等判别式任务上，经常能逼近大模型；在开放式生成、复杂推理任务上，会迅速拉开差距。

3.2 工程类指标

工程类指标回答的是“这个模型能不能在我的环境里跑起来”。横评对比中，以下指标通常会被重点关注：

• 模型体积：包括原始权重、量化后权重分别多大，是否适合下载和分包。
• 生成速度：一般用每秒生成的 token 数（token/s）衡量，也可以换算成单条请求延迟。
• 首 token 延迟：用户发出请求到看到第一个输出字符的时间，影响交互体验。
• 显存占用：GPU 环境下推理时的峰值显存。
• 内存占用：CPU 环境下常驻内存开销。
• 端侧 CPU 友好度：在不依赖 GPU 的环境里能不能流畅运行。

“能力很强但部署不了”的模型在横评里会非常吃亏，这也正是竞技场横评和普通榜单最大的不同。它提醒开发者一个容易忽略的事实：同样一个模型，在不同硬件上、用不同推理框架、开不开启量化，体验可能是两个世界。

3.3 为什么不能只看总分

有些横评会给出一个加权总分，方便传播，但开发者不要只盯着总分。不同业务对指标权重的要求完全不同：做实时对话，延迟权重高；做离线批量处理，吞吐权重高；做小程序端侧，体积权重高。把一个总分套用到自己的场景里，往往会产生选型偏差。正确做法是：找到横评的原始指标数据，按自己的业务权重重新排序。

4. 8 款主流小模型全景速览

在讨论选型之前，先整理一份常见小模型清单。需要说明的是，这份清单主要以公开资料整理，目的是帮你建立横向对比的框架，具体横评中的 8 款模型名单和得分，请以 karminski 发布的内容为准。

4.1 常见小模型清单

从公开信息来看，当前开发者讨论度较高的小模型主要集中在以下几个系列：

4.2 如何理解横评中的模型组合

上面列出的只是常见候选，不是横评的全部名单。在实际横评中，同一系列可能同时出现多个参数版本，比如 Qwen 的 1.5B 和 3B 会被视为两款参赛模型。所以“8 款模型”可能包含不同系列、不同参数量的组合，这份清单可以帮助你快速定位它们的技术定位。

从社区反馈来看，这批小模型已经能稳定完成文本分类、信息抽取、关键内容摘要、简单问答、意图识别等任务。它们还扛不住复杂的多轮 Agent 编排，但在“专用任务 + 局部智能”的工程构架下，性价比极高。

5. 复现横评：不能只看结论，还要看评测方式

一份横评值不值得信任，关键看评测方法。这里给出一套小模型横评的参考方法论，如果你想把这次横评的数据用在自己的选型决策中，建议对照这个方法复核。

5.1 固定评测环境

评测环境必须固定。CPU 型号、内存大小、是否使用 GPU、推理框架版本、线程数、量化精度，任何一个变量都会影响结果。开发者应该优先关注和自己生产环境一致的配置，而不是只看最高分。例如，你的线上环境是 Intel 至强 CPU 且无 GPU，那么横评中基于 A100 的测试数据对你来说只有参考价值，没有直接替代价值。

5.2 统一评测任务与超参

评测任务要贴近真实。通用基准分数有意义，但不如你的业务场景数据更有说服力。更实际的横评方式是：准备一份业务样本，跑同一批输入，比较输出质量和延迟。解码方式、max_new_tokens、温度、top_p 等参数不统一，输出质量和耗时就没有可比性。真正的横评会把完整参数写入报告，而不是只给一句“使用默认参数”。

5.3 用脚本记录延迟和显存

下面是一个简单的单模型评测脚本，记录生成延迟，方便你理解横评的计时方式：

# 文件路径：eval_model.py import time import torch from transformers import AutoModelForCausalLM, AutoTokenizer model_id = "Qwen/Qwen2.5-1.5B-Instruct" tokenizer = AutoTokenizer.from_pretrained(model_id) model = AutoModelForCausalLM.from_pretrained( model_id, torch_dtype=torch.float16, device_map="auto" ) prompt = "请用一句话解释什么是小模型。" inputs = tokenizer(prompt, return_tensors="pt").to(model.device) # 预热，避免首次加载影响计时 with torch.no_grad(): model.generate(**inputs, max_new_tokens=8) start = time.time() with torch.no_grad(): output = model.generate(**inputs, max_new_tokens=64, do_sample=False) elapsed = time.time() - start text = tokenizer.decode(output[0], skip_special_tokens=True) print("生成耗时(秒):", round(elapsed, 3)) print("输出:", text)

这段代码只测量生成阶段的耗时，不包含模型加载时间。在横评中，模型加载时间通常单独统计，因为端侧场景有时是常驻进程，有时是冷启动，两者对延迟的体验完全不同。

如果在 GPU 环境上运行，还可以同时记录显存：

nvidia-smi --query-gpu=memory.used,utilization.gpu --format=csv -l 1

运行上述 Python 脚本时另开一个终端执行这条命令，就能看到模型运行过程中的显存峰值。这一步在横评中非常关键，因为很多小模型的宣传文案不会告诉你它在 GPU 上占了多少显存。

6. 从横评到落地：端侧与小程序的部署思路

横评数据最终要回答的问题是：这个模型能不能跑进我的业务？这里以两个最常见的落地路径为例：CPU 端侧服务和微信小程序运行深度学习模型。

6.1 CPU 端侧部署：转 ONNX + ONNX Runtime

小模型在 CPU 上运行的推荐路径是转成 ONNX，再使用 ONNX Runtime 推理。转换命令可以参考：

pip install transformers optimum onnx optimum-cli export onnx --model Qwen/Qwen2.5-1.5B-Instruct onnx_model/

不同版本的工具命令略有差异，如果optimum-cli不可用，请以官方文档提供的 ONNX 导出方式为准。模型导出后，输入输出张量名会因模型而异，不能照搬别人代码里的 feed 名称，以实际导出模型为准。

转换完成后，可以用 ONNX Runtime 做一个最小推理验证：

# 文件路径：onnx_infer.py import onnxruntime as ort from transformers import AutoTokenizer # 这里用 HuggingFace 的 tokenizer 对文本做预处理 tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2.5-1.5B-Instruct") session = ort.InferenceSession( "onnx_model/model.onnx", providers=["CPUExecutionProvider"] ) prompt = "将下面内容分类为：技术/生活/其他。内容：微信小程序运行深度学习模型需要注意包体积。" inputs = tokenizer(prompt, return_tensors="pt") input_ids = inputs["input_ids"].numpy() attention_mask = inputs["attention_mask"].numpy() input_names = [inp.name for inp in session.get_inputs()] feed = { input_names[0]: input_ids, input_names[1]: attention_mask, } outputs = session.run(None, feed) # 输出张量的具体结构取决于导出配置，这里只演示取值思路 print(outputs[0].shape)

ONNX 导出后的输入名称不固定，常见格式是 input_ids、attention_mask，也可能合并成一个 inputs，实际要以模型注册信息为准。跑通这一步后，可以继续做 INT8 / INT4 量化，压缩体积，提升 CPU 推理速度。

6.2 微信小程序运行深度学习模型的工程链路

再谈微信小程序场景。微信小程序运行深度学习模型的工程链路，本质上要把 AI 推理压缩到用户端，最核心的矛盾有两个：包体积和算力。开发者通常的路线是：

1. 拿到小模型后先转 ONNX，再量化到 INT8 或 INT4，把权重压到几十到几百 MB。
2. 在端侧用 WebAssembly 或小程序插件方式加载推理引擎，而不是直接在 JS 里跑 Python。
3. 把模型文件放到 CDN 或分包加载，避免主包体积超标。
4. 离线能力优先，模型加载后常驻内存，减少重复下载。

需要提醒的是：小程序端侧推理的具体实现依赖微信官方提供的能力范围和版本，不同平台的 WebAssembly 支持情况不完全一致。更稳妥的实践是先做技术验证（PoC），用最小的模型跑通“输入文本 -> 端侧推理 -> 输出结果”的完整链路，再逐步替换成更大或更准的模型。这一步的核心目的是验证链路，而不是验证模型智商。

6.3 先跑通链路，再优化模型

很多团队上来就选一个 7B 模型，结果在端侧要么装不下，要么推理延迟高到不可用。更合理的顺序是：先用 1B 或量化后的模型把整条链路跑通，确认模型分发、内存管理、推理引擎集成、错误处理都没有问题，再根据效果需求决定是否升级到更大参数版本。链路问题比模型效果问题更难排查，先解决链路，再解决效果，排错成本会低很多。

7. 选型落地建议：不同场景选不同模型

横评结论落到业务时，不能只看总分。我的建议是先给自己的场景分类，再反推模型选择。

7.1 场景与模型匹配

7.2 小模型与大模型的分工

这里要展开说一下 Agent 场景。很多人看到 Agent 火了，就想用小模型驱动工具调用，省成本。但实际上，小模型在多轮工具调用、长上下文记忆、错误恢复这些环节上，稳定性还不足以支撑复杂 Agent。更务实的方式是：把 Agent 的复杂编排留在大模型侧，把高频、低难度的子任务用专门的小模型承接。一句话，小模型做执行者，大模型做决策者，这是目前成本与效果平衡较好的架构。

另外，不要为了“参数越小越好”而牺牲效果。建议的选型顺序是：先用中等尺寸（3B~7B）模型在真实样本上做效果基线，再测试量化到 1B 或 INT4 能否接受，最后才确定生产版本。直接选最小模型，很容易在项目后期因为效果不达标返工。

8. 小模型横评中的常见问题与排查思路

在实际评测和部署小模型时，团队经常会在下面几个问题上卡住。整理成表格，方便排查。

小模型评测最容易踩的坑，是把 HuggingFace 上的评测分数直接当成业务效果。模型在通用评测集上的表现，只能说明它的知识面和基础能力，到了垂直领域，必须用真实的业务数据重新评。这也是为什么经验丰富的团队会自建评测集，而不是只看别人的横评表格。

9. 最佳实践与团队落地建议

把横评用在真实项目中，有几个工程层面的建议值得单独说。

9.1 建立自己的评测基线

哪怕只有几十条真实样本，也比完全依赖外部榜单强。把每条样本的预期输出写清楚，模型版本、参数量、量化级别、推理框架全部记录下来，形成可回归的评测报告。以后模型升级或切换，直接跑同一套基线，沟通成本会低很多。评测基线应该放在代码仓库里，用脚本自动执行，而不是依赖成员手动记录。

9.2 量化要反复验证

量化带来的体积和速度收益是实打实的，但精度损失在不同任务上表现不同。分类任务可能损失很小，生成任务可能明显变差。务必备份原始精度模型，方便随时回退。在量化之前，先做一组小样本效果对比，确认损失在可接受范围内。量化后还要在完整评测基线上回归，而不是抽样看几条结果就下结论。

9.3 安全合规先于性能

在端侧部署模型，要注意用户输入输出可能包含敏感信息。如果模型从开放社区下载，要关注许可协议，区分商用允许和学术允许。涉及个人信息的处理，要遵循隐私合规要求。特别是小程序场景，用户数据要遵循平台的数据安全规范，不能因为端侧推理就不做数据保护。

9.4 版本锁定与链路监控

生产环境要把模型版本、推理引擎版本、依赖库版本全部锁定，避免“昨天还好好的，今天变了”这类问题。同时记录每次推理的模型版本和耗时，出现质量波动时能快速定位是哪次变更引起的。建议在日志中输出带模型版本号的标识，并把评测数据和线上数据分开存储。

9.5 用制度防止过度优化

小模型的迭代速度很快，团队容易陷入“追逐新模型”的循环。更合理的节奏是：新模型发布后，先在评测基线上回归，只有业务指标稳定提升时才升级，否则保持当前版本。升级也遵循灰度逻辑，先让部分流量试用，再全量。记住，模型升级本身有成本，业务不变的场景下，频繁换模型不会带来收益，只会增加风险。

10. 总结：小模型竞技场的真正打开方式

这次小模型竞技场横评让我们重新理解了选型的逻辑：小模型的价值不在于它能在学术榜单上拿多少分，而在于它能把 AI 能力压进一个可以接受的成本、体积和延迟范围，真正跑进业务里。横评的价值也正在于此——它把能力、速度、体积、成本放在同一张表里，逼着开发者从“谁更强”转向“谁更合适”。

对于读者，接下来的行动建议很直接：先确定你的部署环境，再挑两到三款候选小模型，用你自己的业务样本跑一次小规模对比，把延迟、体积、效果记录成表格。很多时候你会发现，真正适合你的模型并不是横评第一名，而是在你的硬件上最顺手、在你的数据上最稳定的那一款。

这轮小模型竞争的受益者是所有做端侧和私有化应用的开发者。模型越来越小，能力越来越够用，工具链也越来越成熟。下一步值得深入的方向包括量化技术、RAG 与小模型的结合，以及在小程序等端侧环境中的推理引擎调优。如果你正在规划端侧 AI 方案，建议先把这篇笔记收藏，按照章节里的方法跑一次自己的横评，再把结果放进技术方案评审会，会比你引用任何一份外部榜单都有说服力。