如果你过去两年一直在关注 AI 应用开发一定会有这种感觉大模型很强但真正让你敢在业务里直接用的反而是那些参数量不大、资源占用可控的小模型。小模型不是“大模型的缩小版”它已经形成了自己的技术路线量化、蒸馏、端侧推理、私有化部署、低成本调用。最近karminski 发布的 8 款小模型竞技场横评正好踩中了很多团队在选型时的核心痛点——面对一堆小模型到底该怎么比、怎么选、怎么落地。这篇文章不打算只转述评测结果而是把“小模型横评”这件事拆开讲清楚。我们会先解决一个更根本的问题小模型评测到底在看什么然后给出 8 款常见小模型的横向对比视角再通过可复制的部署示例、评测脚本和问题排查帮你真正跑通一个本地小模型。如果你正在做端侧 AI、私有化部署或者正准备把深度学习模型塞进微信小程序这篇文章尤其值得读完。先说一个明确判断小模型横评的价值不在于“谁的分数最高”而在于帮你建立一套自己的选型坐标系。没有这套坐标系你看到的所有横评都只是排行榜上的数字和你实际的项目场景毫无关系。1. 这篇文章真正要解决的问题很多开发者第一次接触小模型都会陷入两个极端。要么觉得“参数这么少能力肯定不行”要么觉得“反正 N 款模型都能下载随便挑一个用就行”。这两种想法都容易踩坑。先说第一个误区。现在的 1B 到 9B 小模型在垂直任务上的表现已经远超很多人的预期。代码补全、分类抽取、文本改写、函数调用、简单问答这些场景中小模型完全能胜任。尤其是经过蒸馏和量化之后的小模型推理速度可以做到大模型的好几倍而精度损失控制在可接受范围内。相反如果你不需要复杂推理硬上一个大模型反而是成本的浪费。再说第二个误区。小模型选错比大模型选错更隐蔽。大模型之间能力差异明显你很容易通过几个测试用例判断好坏。但小模型各有各的“性格”有的中文能力强有的代码格式规范有的长文本稳定有的对工具调用支持好。只看单项指标根本无法判断它适不适合你的业务。所以这篇文章要解决的问题非常具体karminski 这类小模型竞技场横评到底在评测哪些维度哪些维度对你真正重要8 款常见小模型各自适合什么场景为什么不能只看排行榜在本地部署一个小模型需要什么环境如何用 Ollama、Transformers、llama.cpp 快速跑通如何从一个评测数据集中抽取任务验证模型在你业务场景中的真实表现如果要把小模型部署到微信小程序或移动端需要关注哪些能力边界读完这篇文章你会得到一套可以复用的“小模型选型 部署 评测”方法论。我们不保证帮你选出绝对最好的模型因为最好的模型取决于你的任务、数据和硬件。2. 小模型竞技场评测的核心概念与适用场景2.1 什么是小模型小模型Small Language ModelSLM并没有一个严格的参数边界。从当前的生态来看0.5B 到 13B 参数量之间的模型都可以归入“小模型”或“轻量模型”的讨论范围。相比动辄百亿、千亿参数的大模型小模型的训练成本、推理成本、部署门槛都低了一个量级。但这里要注意小模型不等于“效果差”。现代小模型通常会用到蒸馏Distillation、剪枝Pruning和量化Quantization三种技术。蒸馏是指让大模型当老师把大模型的输出行为迁移给小模型剪枝是指删除网络中不重要的参数或连接量化是指把模型参数从 FP16 降到 INT8 或 INT4以大幅减少内存占用。一个经过量化蒸馏的小模型可能在数学能力上不如大模型但在特定任务上却能做到 90% 以上的效果同时推理速度提升数倍。2.2 什么是“竞技场”评测“竞技场”这个词来自 Chatbot Arena 这类众包评测方式。与传统离线数据集不同竞技场评测让多个模型在相同输入下生成输出由用户或自动脚本打分排序。karminski 发布的小模型竞技场横评本质上也是一种竞技场评测只是更聚焦小模型赛道。它的核心优势是让模型在尽可能一致的条件下比较减少“不同评测环境导致结果虚高”的问题。在实际项目中你可以把它理解为“赛马”把几匹候选马放到同一条赛道上统一起跑、统一终点、统一计时。你看到的并不是简单的胜率而是每个模型的完整行为画像。2.3 为什么小模型评测值得关注小模型评测和大模型评测有一个非常重要的区别小模型部署的目标环境差异极大。大模型评测通常只关注能力分数因为大模型的部署环境相对统一都是 GPU 集群。但小模型可能跑在 16GB 内存的笔记本上跑在树莓派上跑在手机浏览器里甚至跑在微信小程序里。同样的模型在不同环境下表现出来的速度和稳定性完全不同。因此真正有用的“竞技场横评”一定不能只看模型能力的 MMLU、GSM8K、HumanEval 分数还要覆盖以下工程维度参数量和显存占用不同量级INT8、INT4下的性能表现CPU 推理速度和 GPU 推理速度对中文、英文、代码等不同语料的支持工具调用、函数输入输出格式的稳定性端侧模型格式ONNX、MNN、TensorFlow Lite的转换成本。这些维度才是影响你能否“用起来”的关键。3. 8 款小模型横评的典型对比维度这一部分我们不直接给出某个模型的“绝对分数”而是从公开资料和常见评测中整理一份“小模型能力画像”。你可以把它理解为一个选型起点而不是最终结论。3.1 8 款候选模型当前小模型赛道比较有代表性的模型包括模型参数规模开源程度主打场景典型特点Qwen2.5-1.5B / 3B1.5B / 3B开源中文场景、通用助手中文能力强工具调用 API 较规范Llama 3.2-1B / 3B1B / 3B开源通用英文场景、边缘设备英文生态完善社区工具链丰富Phi-3-mini3.8B开源推理、代码、数学微软出品训练数据经过严格过滤Gemma-22B / 9B开源通用场景Google 出品与生态工具集成好MiniCPM2.4B / 4B开源端侧、移动端中文表现突出端侧适配做得早Mistral-7B7B开源欧美场景、开发者工具性能均衡但 7B 对资源有要求DeepSeek-R1-Distill-Qwen-1.5B / 7B1.5B / 7B开源推理任务蒸馏路线数学和逻辑表现不错GLM-4-Flash / GLM-4-9B9B接口/开源中文通用中文大模型思路延续API 访问成本低请注意这里的参数规模和特性只是参考具体模型版本更新很快你不能把它当作固定结论。选型时一定要基于你下载到的实际版本和评测结果。3.2 对比维度如何设计一份高可用的横评应该从业务视角出发而不是从学术排行榜出发。建议你把对比维度分成四组第一组是能力维度。包括常识问答、数学逻辑、代码生成、中文理解、指令跟随。参考基准可以用 MMLU、GSM8K、HumanEval、C-Eval 等但更重要的是用你自己的业务问题。第二组是资源维度。包括模型文件大小、启动所需最小内存、不同量化级别下的显存占用、单次推理耗时。这一组直接决定你能不能用现有服务器跑起来。第三组是工程维度。包括 Hugging Face 生态兼容性、ONNX 转换难度、量化工具支持度、Ollama 支持度、端侧框架支持度。这一组决定你接入成本和升级成本。第四组是稳定性维度。包括长文本生成是否断裂、代码块是否完整输出、JSON 输出是否合法、多轮对话是否崩溃。这一组决定了生产环境要不要加一堆防御代码。3.3 怎样看待横评中的“胜出”模型任何横评都有测评者的主观取舍。karminski 的横评可能更看重推理能力和资源效率而另一个评测者可能更看重中文写作能力。所以更稳妥的判断是没有绝对最好的小模型只有最适合你任务的小模型。你在看横评时不要问“哪款最强”而要问四个问题我的业务是中文为主还是英文为主推理跑在 GPU 上还是 CPU 上我需要复杂工具调用还是纯文本生成我的延迟容忍度是多高响应时间要求是 200 毫秒还是 2 秒带着这四个问题去看任何竞技场榜单你都能得到更准确的结论。4. 本地部署环境准备与三套主流路线4.1 硬件与系统要求要部署一个 7B 以下的小模型最低配置其实不高内存16GB 起步32GB 更稳妥磁盘模型文件普遍在 1GB 到 5GB 之间量化后更小预留 10GB 空间操作系统Windows 11、Ubuntu 20.04、macOS 均可GPU有 NVIDIA 显卡最好没有也能用 CPU 跑只是速度慢一些。如果你打算用 Python 直接加载模型还要准备 Python 3.9 以上环境以及 PyTorch 或 ONNX Runtime。4.2 路线一Ollama 一键部署Ollama 是目前本地运行小模型最友好的工具。它把模型管理、下载、推理 API、命令行交互全部封装好适合快速验证。# 安装 OllamamacOS/Linux curl -fsSL https://ollama.com/install.sh | sh # 拉取模型以 Qwen2.5 为例 ollama pull qwen2.5:3b # 启动服务 ollama serve4.3 路线二Hugging Face Transformers 加载如果你需要精细控制推理过程比如调整采样参数、改模型输出层或者要加载特定量化版本可以用 Transformers。# 创建虚拟环境 python3 -m venv sllm-env source sllm-env/bin/activate # 安装依赖 pip install transformers torch accelerate4.4 路线三llama.cpp 量化推理如果目标设备是 CPU 或苹果 M 系列芯片llama.cpp 是效率最高的选择之一。它支持 GGUF 格式量化模型内存占用比 PyTorch 版本小很多。git clone https://github.com/ggerganov/llama.cpp cd llama.cpp make # 用 Ollama 拉取 GGUF 模型文件 # 然后用 llama-server 启动 HTTP 服务 ./llama-server -m models/qwen2.5-3b-q4_k_m.gguf -c 4096 --port 8080三条路线不冲突。我的建议是先用 Ollama 跑通全流程再用 Transformers 或 llama.cpp 做定制化调整。5. 完整示例从部署到小规模评测这一节我们用一个完整流程把小模型从部署到评测串起来。以 Qwen2.5-3B 为例但在每一步你都可以替换成其他模型。5.1 示例一用 Ollama 运行模型并调用 API启动服务后默认监听 11434 端口。你可以直接用 curl 做一次推理请求。curl http://localhost:11434/api/generate -d { model: qwen2.5:3b, prompt: 请用一句话解释什么是小模型, stream: false }返回的 JSON 中会包含 response 字段这就是模型生成的文本。如果一切正常说明模型已经跑通。5.2 示例二用 Transformers 实现带参数的推理脚本# 文件路径scripts/run_inference.py from transformers import AutoModelForCausalLM, AutoTokenizer model_name Qwen/Qwen2.5-3B tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained( model_name, torch_dtypeauto, device_mapauto ) prompt 你是一个技术助手。请用三句话说明小模型在大模型时代的意义。 messages [ {role: system, content: 你是一个严谨的技术助手。}, {role: user, content: prompt} ] text tokenizer.apply_chat_template( messages, tokenizeFalse, add_generation_promptTrue ) inputs tokenizer([text], return_tensorspt).to(model.device) generated_ids model.generate( **inputs, max_new_tokens512, temperature0.7, top_p0.9, do_sampleTrue ) generated_ids generated_ids[:, inputs.input_ids.shape[1]:] response tokenizer.batch_decode(generated_ids, skip_special_tokensTrue)[0] print(response)运行命令python scripts/run_inference.py这段代码的关键点在于使用 chat 模板而不是直接拼接提示词这能让模型保持更稳定的回复格式。max_new_tokens 控制生成长度temperature 控制随机性。如果你的显存不够可以把 torch_dtype 改成int8并安装bitsandbytes。5.3 示例三构造一个最小评测脚本选型时我们经常需要对比多个模型的同一能力。下面是一个用 Python 编写的最小评测脚本它会同时向多个模型发起同样的问题并保存输出结果。# 文件路径scripts/eval_small_models.py import requests import json import time MODELS [qwen2.5:3b, llama3.2:3b, phi3:mini, gemma2:2b] OLLAMA_URL http://localhost:11434/api/generate EVAL_PROMPT 请用一句中文回答如果要运行一个小模型最少需要多少内存 def query_model(model: str, prompt: str) - dict: payload { model: model, prompt: prompt, stream: False } start time.time() resp requests.post(OLLAMA_URL, jsonpayload) elapsed time.time() - start data resp.json() return { model: model, output: data.get(response, ).strip(), latency: round(elapsed, 2) } if __name__ __main__: results [] for model in MODELS: print(f正在评测模型: {model}) result query_model(model, EVAL_PROMPT) results.append(result) with open(eval_results.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) print(json.dumps(results, ensure_asciiFalse, indent2))运行命令python scripts/eval_small_models.py这个脚本本身不判断谁对谁错它只是一个“录制工具”。你可以把输出结果交给人工或再用另一个规则模型做打分。5.4 评测数据集怎么选真正有业务价值的评测不能只靠一个提示词。建议你准备 20 到 50 条业务样本分成四类摘要类给一段业务文章要求生成 100 字摘要抽取类从客服对话中抽取订单号、用户诉求、情绪倾向生成类根据商品属性生成宣传文案结构化输出类要求模型输出合法的 JSON包含指定字段。这四类任务基本覆盖了大多数小模型落地场景。最终选型时你可以计算每个模型在业务样本上的“通过率”和“平均耗时”这就是最实用的横评标准。6. 运行结果与效果验证6.1 如何判断推理成功运行示例一后如果返回的 JSON 里 response 字段有内容说明模型已经成功运行。首次运行可能需要下载模型文件之后会走本地缓存。判断成功不止看“有没有输出”还要看输出质量回复是否和问题相关是否出现乱码或者重复死循环中文是否通顺是否有明显 AI 模板痕迹回答是否满足格式要求。6.2 预期输出与 Benchmark上面那个评测脚本会生成 eval_results.json。预期输出大致是[ { model: qwen2.5:3b, output: 运行一个小模型通常需要至少 8GB 到 16GB 内存具体取决于模型参数和量化方式。, latency: 1.53 }, { model: llama3.2:3b, output: 最少 8GB 内存如果使用 INT4 量化可以进一步降低。, latency: 1.82 } ]注意不同机器性能不同延迟差异会很大。关键是看模型输出内容是否稳定以及延迟是否满足你的业务要求。6.3 如何验证“提速”收益小模型最常见的优势是“资源消耗低”但这个优势必须用数据证明。建议你做一组对比实验同一个模型在不同量化级别FP16、INT8、INT4下的延迟同一个模型在 CPU 和 GPU 上的延迟不同并发数下的吞吐量每秒请求数。只有做过这组实验你才能说真正理解了某个小模型在你自己环境中的表现。任何横评报告都替代不了这一步。6.4 失败时的第一步排查方向如果脚本报错先看日志。最常用的三个排查方向是模型名是否写错Ollama 使用的名称需要和ollama list输出一致端口是否被占用确认 11434 端口没有被其他进程占用显存或内存是否不足量化模型可以显著降低内存压力。7. 常见问题与排查方法问题现象可能原因排查方式解决方案Ollama 拉取模型超时网络问题或官方源不稳定检查网络连接重试拉取使用国内镜像源或离线下载模型文件Transformers 加载模型报错 CUDA out of memory显存不足nvidia-smi查看显存占用换 INT8/INT4 量化模型或改用 CPU 推理模型回答乱码加载了非对应 tokenizer 的模型版本确认模型名和 tokenizer 是否完全匹配统一使用同一个模型仓库中的 tokenizerJSON 输出不合法模型没有遵循结构化指令打印原始输出检查字段缺少情况在提示词中给出 JSON 样例并增加输出约束中文回答夹杂英文模板模型本身中文能力偏弱对比多款模型中文输出改用中文预训练更充分的模型如 Qwen 或 MiniCPMCPU 推理速度很慢没有使用量化版本观察 CPU 使用率和内存占用使用 llama.cpp GGUF INT4 模型速度会快很多多轮对话上下文失效没有拼接历史消息查看是否只传了最后一轮问题按 chat 模板传入多轮 messages徽信小程序场景模型加载失败包体积超限或 wasm 文件无法加载查看小程序控制台/network 面板使用更小量化模型把模型放到托管 CDN 或后端推理8. 小模型部署到微信小程序/端侧的最佳实践8.1 端侧部署为什么越来越常见“微信小程序运行深度学习模型”已经成为 2025 年前后非常热门的实践方向。原因并不神秘小模型量化后可以做到几十 MB 甚至十几 MBWebAssembly 可以在小程序容器中运行 ONNX Runtime 或类似推理引擎端侧推理不需要把用户数据上传到服务器隐私友好一次部署后的边际推理成本接近于零。8.2 端侧部署的技术路线选择如果你要在一个小程序或移动端 App 里运行小模型常见路线有三种第一种是 ONNX Runtime Web WASM。把 PyTorch 模型导出为 ONNX在浏览器端或小程序 WebView 中运行。适合 1B 以下或经过强量化的模型。第二种是直接调用后端推理 API。模型部署在服务器上小程序只负责收集输入和渲染输出。适合对延迟和成本容忍度较高、但模型能力要求较高的场景。第三种是偏传统的端侧推理框架如 TensorFlow Lite、MNN、NCNN 等。它们对小模型支持好但需要按平台做集成适合原生 App 而非纯小程序。8.3 选型与工程建议针对小程序部署场景我的建议比较务实如果只是演示或 MVP优先做后端 API不要一开始就试图在端侧跑模型如果确实要端侧运行优先选择 1B 以下或 INT4 量化模型保证包体积可控把模型发布到 CDN并用首次加载缓存策略避免每次启动都重新下载对模型生成结果做长度限制和内容校验避免生成流程失控留一条“端侧失败自动转后端”的降级通道。这是我在多次端侧实践中确认过的原则端侧 AI 的核心不是“能不能跑”而是“在资源受限时能不能稳定跑”后者需要大量异常处理。8.4 生产环境的几条红线无论是本地部署、服务器部署还是小程序部署有一些安全与运维红线必须遵守不要在生产环境用默认端口且不加鉴权地开放模型服务不要用 root 账号运行模型服务避免模型解析漏洞影响宿主机涉及用户数据时确保数据脱敏并且明确告知用户数据用途对模型输出做内容过滤或人工抽查不能完全信任模型生成结果任何模型替换、量化版本升级都要先在测试环境跑完整评测再上线保留旧版本模型文件做好回滚预案。这些不是可有可无的“最佳实践”而是当你把模型真正跑进业务之后迟早要面对的问题。9. 总结与后续学习方向这篇文章没有逐条重复 karminski 那份 8 款模型横评的分数表而是想把更重要的东西讲清楚小模型评测这件事本身该怎么看、怎么用。你读完这篇文章至少应该能回答以下几个问题小模型和大模型的边界在哪里为什么小模型值得单独评测一份有用的横评应该覆盖能力、资源、工程、稳定性四组维度如何在本地用 Ollama、Transformers、llama.cpp 三条路线部署小模型如何写一个最小评测脚本用业务样本判断模型的真实表现在小程序和端侧场景中做小模型选型和部署有哪些实用原则。下一步你可以按这样的路径实践把文中的 Ollama 示例跑通选 2 到 3 款候选模型准备 20 条自己业务中的真实样本跑一遍评测脚本记录每款模型在同一个问题下的输出、延迟和稳定度根据结果选一款主力模型再做量化与部署验证最后结合你的目标平台服务器、桌面端、小程序等完善上线方案。小模型领域变化非常快今天推荐的版本可能下个月就被新模型超越。保持横评的方法论比记住某一个排行榜更重要。建议收藏备用等你需要做模型选型时再回来对照这套流程重新跑一遍它会帮你少走很多弯路。