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

最近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显著减小体积提升推理速度虽然会有少量精度损失。更直白的比喻是大模型像一台服务器什么任务都能跑小模型像一台专用终端常用任务跑得又轻又快。选择小模型本质上是你确认业务场景的任务边界清晰不需要动用大模型的全部能力。大模型与小模型的差异可以简单对比对比维度大模型小模型参数量级70B 以上1B ~ 7B硬件要求多卡 GPU / 专用集群CPU、移动端、边缘设备推理延迟相对较高显著更低部署体积数十 GB 以上量化后几百 MB 到 2GB单次推理成本高低泛化能力强适合开放任务适合边界清晰的任务典型场景复杂创作、多轮 Agent分类、抽取、摘要、定时任务容易被忽略的一点是小模型的“小”是相对的。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 常见小模型清单从公开信息来看当前开发者讨论度较高的小模型主要集中在以下几个系列模型参数量级机构特点与常见用途Qwen2.5-1.5B / 3B1.5B / 3B阿里中文能力强生态完善适合中文业务和微调Llama-3.2-1B / 3B1B / 3BMeta英文通用能力均衡社区生态好许可宽松Phi-3-mini3.8BMicrosoft高数据质量训练代码和数学相对突出Gemma-2-2B / 9B2B / 9BGoogle结构新颖英文和多语言表现稳定Mistral-7B7BMistral AI英文能力扎实部署资料丰富DeepSeek-R1-Distill-Qwen-1.5B1.5B深度求索推理链蒸馏产物适合逻辑推理类任务InternLM2.5-1.8B1.8B上海人工智能实验室中文场景覆盖面广学术和社区贡献活跃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_dtypetorch.float16, device_mapauto ) prompt 请用一句话解释什么是小模型。 inputs tokenizer(prompt, return_tensorspt).to(model.device) # 预热避免首次加载影响计时 with torch.no_grad(): model.generate(**inputs, max_new_tokens8) start time.time() with torch.no_grad(): output model.generate(**inputs, max_new_tokens64, do_sampleFalse) elapsed time.time() - start text tokenizer.decode(output[0], skip_special_tokensTrue) print(生成耗时(秒):, round(elapsed, 3)) print(输出:, text)这段代码只测量生成阶段的耗时不包含模型加载时间。在横评中模型加载时间通常单独统计因为端侧场景有时是常驻进程有时是冷启动两者对延迟的体验完全不同。如果在 GPU 环境上运行还可以同时记录显存nvidia-smi --query-gpumemory.used,utilization.gpu --formatcsv -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_tensorspt) 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 推理压缩到用户端最核心的矛盾有两个包体积和算力。开发者通常的路线是拿到小模型后先转 ONNX再量化到 INT8 或 INT4把权重压到几十到几百 MB。在端侧用 WebAssembly 或小程序插件方式加载推理引擎而不是直接在 JS 里跑 Python。把模型文件放到 CDN 或分包加载避免主包体积超标。离线能力优先模型加载后常驻内存减少重复下载。需要提醒的是小程序端侧推理的具体实现依赖微信官方提供的能力范围和版本不同平台的 WebAssembly 支持情况不完全一致。更稳妥的实践是先做技术验证PoC用最小的模型跑通“输入文本 - 端侧推理 - 输出结果”的完整链路再逐步替换成更大或更准的模型。这一步的核心目的是验证链路而不是验证模型智商。6.3 先跑通链路再优化模型很多团队上来就选一个 7B 模型结果在端侧要么装不下要么推理延迟高到不可用。更合理的顺序是先用 1B 或量化后的模型把整条链路跑通确认模型分发、内存管理、推理引擎集成、错误处理都没有问题再根据效果需求决定是否升级到更大参数版本。链路问题比模型效果问题更难排查先解决链路再解决效果排错成本会低很多。7. 选型落地建议不同场景选不同模型横评结论落到业务时不能只看总分。我的建议是先给自己的场景分类再反推模型选择。7.1 场景与模型匹配业务场景推荐思路关注指标中文客服摘要优先中文优化模型1.5B~3B摘要质量和中文准确率英文邮件分类通用小模型即可1B~3B分类准确率与延迟代码补全/格式化关注训练数据质量3B 以上代码语义保持能力端侧离线推理量化后体积优先1B 起体积、CPU 延迟、RAM 占用私有化服务器7B 模型 中级 GPU 或高性能 CPU吞吐、显存、稳定性多轮对话 Agent暂不建议小模型除非边界极窄多步推理准确率7.2 小模型与大模型的分工这里要展开说一下 Agent 场景。很多人看到 Agent 火了就想用小模型驱动工具调用省成本。但实际上小模型在多轮工具调用、长上下文记忆、错误恢复这些环节上稳定性还不足以支撑复杂 Agent。更务实的方式是把 Agent 的复杂编排留在大模型侧把高频、低难度的子任务用专门的小模型承接。一句话小模型做执行者大模型做决策者这是目前成本与效果平衡较好的架构。另外不要为了“参数越小越好”而牺牲效果。建议的选型顺序是先用中等尺寸3B~7B模型在真实样本上做效果基线再测试量化到 1B 或 INT4 能否接受最后才确定生产版本。直接选最小模型很容易在项目后期因为效果不达标返工。8. 小模型横评中的常见问题与排查思路在实际评测和部署小模型时团队经常会在下面几个问题上卡住。整理成表格方便排查。问题现象可能原因排查方式解决方案模型加载非常慢未量化或模型体积过大查看模型目录大小和文件格式转 ONNX 后做 INT8/INT4 量化GPU 显存溢出batch size 或 max_new_tokens 过大用 nvidia-smi 观察峰值显存降低 batch、限制生成长度或改 CPU 推理CPU 推理延迟过高未设置线程数或框架未启用加速查看 CPU 占用和单 token 延迟设置 intra-op 线程使用优化推理引擎量化后效果明显下降量化粒度或校准数据不合适对比量化前后同批样本的输出换用更合适的量化方案或微调后量化小程序包体积超标模型文件直接放在主包检查构建产物体积模型放 CDN、分包加载或进一步量化输出结果不稳定解码参数未固定检查 temperature、do_sample 配置评测时固定超参生产可开保守解码榜单分数高但业务效果差评测任务和业务分布不一致用业务样本单独评测建立业务评测集回归到业务指标小模型评测最容易踩的坑是把 HuggingFace 上的评测分数直接当成业务效果。模型在通用评测集上的表现只能说明它的知识面和基础能力到了垂直领域必须用真实的业务数据重新评。这也是为什么经验丰富的团队会自建评测集而不是只看别人的横评表格。9. 最佳实践与团队落地建议把横评用在真实项目中有几个工程层面的建议值得单独说。9.1 建立自己的评测基线哪怕只有几十条真实样本也比完全依赖外部榜单强。把每条样本的预期输出写清楚模型版本、参数量、量化级别、推理框架全部记录下来形成可回归的评测报告。以后模型升级或切换直接跑同一套基线沟通成本会低很多。评测基线应该放在代码仓库里用脚本自动执行而不是依赖成员手动记录。9.2 量化要反复验证量化带来的体积和速度收益是实打实的但精度损失在不同任务上表现不同。分类任务可能损失很小生成任务可能明显变差。务必备份原始精度模型方便随时回退。在量化之前先做一组小样本效果对比确认损失在可接受范围内。量化后还要在完整评测基线上回归而不是抽样看几条结果就下结论。9.3 安全合规先于性能在端侧部署模型要注意用户输入输出可能包含敏感信息。如果模型从开放社区下载要关注许可协议区分商用允许和学术允许。涉及个人信息的处理要遵循隐私合规要求。特别是小程序场景用户数据要遵循平台的数据安全规范不能因为端侧推理就不做数据保护。9.4 版本锁定与链路监控生产环境要把模型版本、推理引擎版本、依赖库版本全部锁定避免“昨天还好好的今天变了”这类问题。同时记录每次推理的模型版本和耗时出现质量波动时能快速定位是哪次变更引起的。建议在日志中输出带模型版本号的标识并把评测数据和线上数据分开存储。9.5 用制度防止过度优化小模型的迭代速度很快团队容易陷入“追逐新模型”的循环。更合理的节奏是新模型发布后先在评测基线上回归只有业务指标稳定提升时才升级否则保持当前版本。升级也遵循灰度逻辑先让部分流量试用再全量。记住模型升级本身有成本业务不变的场景下频繁换模型不会带来收益只会增加风险。10. 总结小模型竞技场的真正打开方式这次小模型竞技场横评让我们重新理解了选型的逻辑小模型的价值不在于它能在学术榜单上拿多少分而在于它能把 AI 能力压进一个可以接受的成本、体积和延迟范围真正跑进业务里。横评的价值也正在于此——它把能力、速度、体积、成本放在同一张表里逼着开发者从“谁更强”转向“谁更合适”。对于读者接下来的行动建议很直接先确定你的部署环境再挑两到三款候选小模型用你自己的业务样本跑一次小规模对比把延迟、体积、效果记录成表格。很多时候你会发现真正适合你的模型并不是横评第一名而是在你的硬件上最顺手、在你的数据上最稳定的那一款。这轮小模型竞争的受益者是所有做端侧和私有化应用的开发者。模型越来越小能力越来越够用工具链也越来越成熟。下一步值得深入的方向包括量化技术、RAG 与小模型的结合以及在小程序等端侧环境中的推理引擎调优。如果你正在规划端侧 AI 方案建议先把这篇笔记收藏按照章节里的方法跑一次自己的横评再把结果放进技术方案评审会会比你引用任何一份外部榜单都有说服力。