小模型竞技场横评：从评测标准到部署的完整指南-平芜编程栈

最近社区里关于小模型（Small Language Model）的讨论明显多了起来。大模型虽然能力强，但部署成本和推理延迟让很多团队开始重新审视“够用就好”的路线。karminski 发布的小模型竞技场横评，把 8 款主流小模型放到同一套评测框架下对比，涵盖基础能力、推理速度、显存占用和中文支持等维度，对后端开发、端侧部署和 AI 应用集成都有直接参考价值。

本文不会只搬运结论，而是结合这份横评的评测思路，完整拆解小模型选型时需要关注的指标、部署环境和测试方法。无论你是刚接触小模型的新手，还是已经在做私有化部署的工程师，都能在文中找到可复用的方案。涉及代码和命令的地方，我会尽量给出可以直接复制运行的示例，并解释每一步的用途。

1. 小模型为什么越来越受关注

1.1 什么是小模型

小模型通常指参数量在 0.5B 到 13B 之间的语言模型。相比动辄 70B、上百 B 的大模型，小模型的参数量少、权重文件小，对显存和内存的要求低很多。常见的 7B 模型在 FP16 精度下权重约 14GB，经过 INT4 量化后可以压到 4GB 以内，很多消费级显卡和开发板都能运行。

但小模型并不是“缩小版的大模型”那么简单。它在训练数据配比、上下文长度、量化策略和推理引擎选择上都有自己的一套逻辑。用得好，小模型在垂直场景中的表现可以接近大模型；用不好，可能连基本的对话流畅度都保证不了。

1.2 小模型解决了什么问题

小模型最核心的价值是降低部署门槛。

成本可控：单台普通服务器或 GPU 工作站即可运行，不需要多卡集群。
数据隐私：模型在本地运行，敏感数据不需要上传到云端。
低延迟：没有网络传输开销，推理请求在本地即可完成。
离线可用：适合内网环境、移动设备、嵌入式设备等场景。

这也是为什么“微信小程序运行深度学习模型”这类话题会越来越热。小程序端如果直接调用云端大模型 API，一方面要考虑网络波动，另一方面还有数据合规和费用问题。如果在端侧运行一个小模型，处理部分简单任务，体验会稳定很多。

1.3 竞技场评测的意义

在 karminski 的小模型竞技场评测中，“竞技场”这个词借鉴了 Chatbot Arena 的思路，即把不同模型放在相同的提示词和评分规则下进行横向比较。但是小模型竞技场有一个天然难点：小模型的能力边界差异很大，同一个测试集下，模型擅长的任务类型可能完全不同。

因此，评测不能只看一个总分，还要拆开看。语言理解、逻辑推理、代码生成、数学计算、中文问答、长文本处理，每一项都分开打分，才能还原一个模型的真实画像。本文后面的评测框架，就是按照这个思路设计的。

2. 参评模型范围与版本说明

2.1 8 款模型的选择标准

karminski 的横评选取了社区中较具代表性的 8 款小模型。选择标准大致有三点：

参数量在 0.5B 到 9B 之间，属于典型小模型区间。
开源权重可下载，方便本地部署复现。
覆盖不同技术路线，包括整体预训练、增量预训练、蒸馏模型和 MoE 结构。

这里需要说明一点：模型迭代速度非常快，你在实际部署时拿到的版本可能已经更新。横评中的结论反映的是评测时间点的表现，建议你部署时以官方仓库最新稳定版本为准。

2.2 模型列表与基本特点

以下为通常纳入小模型竞技场对比的模型类型，每个模型的侧重点不同：

模型	参数量范围	特点
Qwen 系列	0.5B / 1.8B / 3B / 7B	中文能力强，社区生态完善，工具调用支持好
Llama 3.2	1B / 3B	英文为主，多语言能力和工具调用不错
Phi-3	3.8B	微软出品，在较小参数下推理表现稳定
Mistral	7B	欧洲模型，英文和代码能力均衡，支持多种量化格式
Gemma 2	2B / 9B	Google 出品，指令遵循和安全性做得比较细
DeepSeek 蒸馏系列	1.5B / 7B	由大模型蒸馏得到，推理和编程表现突出
GLM 系列	4B / 9B	中文场景针对性强，支持联网检索和工具调用
Yi 系列	1.5B / 6B / 9B	中文和数学能力不错，社区量化版本多

各模型实际表现会随版本变化。本文不展开具体的冠军排名，而是提供一个评测框架。把你自己选中的模型放到这套框架里跑一遍，就是一个符合你业务场景的专属“横评”。

2.3 为什么不直接看官方 Benchmark

很多模型的 README 里都贴了 MMLU、GSM8K、HumanEval 等榜单分数。这些分数当然有参考意义，但直接套用到自己业务里会有几个问题。

榜单测试集是固定的，和你的业务数据分布可能差异很大。
官方测试使用的推理框架和量化位数，不一定和你生产环境一致。
同一模型在不同推理引擎（比如 llama.cpp、Ollama、vLLM、MLC）下的表现可能差很多。
中文场景的评测集覆盖不够，尤其缺乏中文业务指令评测。

所以更推荐的做法是：参考官方分数做初步筛选，再用自己的评测集做第二轮测试。karminski 的横评本质上也是在“官方分数”之外补一份可复现的社区测试。

3. 评测环境与部署准备

3.1 硬件与系统

小模型评测对硬件要求不算高，但如果你想一次跑完全部 8 款模型，一台拥有 16GB 以上显存的显卡会更省心。常见的组合有：

NVIDIA RTX 3090 / 4090（24GB 显存）
RTX 4070 Ti Super（16GB 显存）
Mac Studio / MacBook Pro（Apple Silicon 统一内存）
纯 CPU 环境（适合 3B 以下模型，速度较慢）

操作系统方面，Windows、Linux、macOS 都支持主流推理框架。生产环境更推荐 Linux，尤其是 Ubuntu 20.04 / 22.04 LTS，因为驱动和 CUDA 环境更稳定。

3.2 推理框架选择

评测环境和生产环境尽量保持一致，这样测试结果才有意义。目前社区使用最多的小模型推理方案有三种。

Ollama 适合快速启动和体验，一条命令拉起模型服务，内置 OpenAI 兼容接口，对大多数人来说是最友好的选择。

llama.cpp 适合需要精细化控制推理参数和量化格式的场景，纯 C/C++ 实现，CPU 上也能跑，移动端和嵌入式设备常用它来做底层引擎。

vLLM 适合需要高并发和较大吞吐量的生产服务，依赖 GPU，显存管理比前两者高效，但部署复杂度稍高。

考虑到大部分开发者先做评测，再从评测结果中选型，本文以 Ollama 为主，因为它在“快速横向对比”这个场景下效率最高。

3.3 安装 Ollama

如果你还没安装 Ollama，可以先按照下面的命令操作。Linux / macOS 用户直接在终端执行：

curl -fsSL https://ollama.com/install.sh | sh

Windows 用户可以从 Ollama 官网下载安装包，安装后命令行输入ollama --version验证是否成功。

不同版本号可能会影响部分命令参数，但基础用法通常保持兼容。示例中以常见版本为准，具体以官方文档为准。

3.4 拉取模型

Ollama 中拉取模型使用ollama pull命令，格式为模型名:标签。例如：

ollama pull qwen2.5:7b ollama pull llama3.2:3b ollama pull phi3:mini ollama pull mistral:7b ollama pull gemma2:9b

拉取默认是 Q4_K_M 量化版本，即 INT4 量化，质量和体积比较均衡。如果你的显存充足，可以改为半精度版本，例如：

ollama pull qwen2.5:7b-fp16

这里要提醒一下：不同模型在 Ollama 仓库中的标签名不完全一致，拉取前可以用ollama search或者直接去 Ollama 模型库页面确认最新标签。

3.5 验证服务是否启动

模型拉取完成后，可以用一个最简单的请求测试服务状态。

ollama serve

如果服务没有启动，上面的命令会在前台启动服务。然后新开一个终端，执行：

ollama run qwen2.5:7b "你好，请简单介绍一下你自己。"

能够正常返回文本，说明环境没问题，可以开始评测了。

4. 小模型竞技场的评测维度设计

评测维度是整个竞技场的灵魂。如果维度设计不合理，即使模型跑完，结论也没有说服力。karminski 的横评把评测拆成了 7 个维度，下面逐一说明每个维度的评测思路和测试方式。

4.1 基础语言理解

这个维度主要测模型的语义理解、常识问答和信息抽取能力。

测试方式：准备 20 到 50 道中文问答题，包含常识、因果、指代消解、观点识别等类型。例如：

“小明比小红高，小红比小刚高，请问三个人中谁最矮？”

参考答案应该是“小刚”。这种题不需要复杂推理，但能反映模型对中文长句的理解能力。

4.2 逻辑推理

逻辑推理是区分模型好坏的关键维度。小模型在这里经常翻车。

测试方式：使用包含假言推理、类比推理、归纳推理的题目。例如：

“所有 A 都是 B，所有 B 都是 C，那么是否能推出所有 A 都是 C？”

同时可以加入一些“反常识”问题，观察模型是否会被带偏。

4.3 数学计算与解题

数学题对模型的符号运算和分步推理能力要求更高。

测试方式：准备 20 道小学到初中水平的数学题，既有纯计算，也有应用题。例如：

“一个水池进水管 4 小时注满，出水管 6 小时放空，同时打开两个管子，多久能注满？”

与上一节逻辑题不同，数学题需要模型输出完整的解题步骤，而不是只给答案。步骤的合理性也要纳入评分。

4.4 代码生成与理解

代码能力是很多开发者最关心的维度。

测试方式：准备 10 个到 15 个编程题目，覆盖 Python、JavaScript、Java 或 SQL。要求模型生成可运行代码，并解释代码思路。

示例题目：

“用 Python 写一个函数，输入一个整数列表，返回列表中第二大的数，列表可能包含重复元素。”

评分时不仅看代码能不能跑，还要看有没有处理边界条件，比如输入为空、只有一个元素、全是重复值等情况。

4.5 中文理解与生成

小模型大多以英文语料为主，中文能力参差不齐。这个维度需要单独测。

测试方式：包含中文成语解释、古诗词理解、中文歧义句分析、中文摘要生成等任务。例如：

“请解释‘塞翁失马，焉知非福’的含义，并用它造一个句子。”

这个维度可以结合你自己的业务场景扩展，比如你是做客服系统的，就该多准备一些客服问答数据。

4.6 指令遵循能力

同一个模型，对不同措辞的指令反应差异很大。指令遵循能力直接关系到模型在业务系统中的可用性。

测试方式：给出明确格式要求的指令，看模型是否严格遵守。

“请用 JSON 格式回复，包含 name、age、city 三个字段，其中 age 必须是数字。”

模型输出必须是合法 JSON，而且字段类型正确，才算通过。还可以测试多步指令，比如“先总结这段文字，再用表格输出，最后给出三个关键词”。

4.7 推理速度与资源占用

速度与资源是选型的关键指标，一般用三个数据衡量。

首 Token 延迟：从发送请求到返回第一个 Token 的耗时。
生成速度：每秒生成的 Token 数，单位 tokens/s。
显存占用：加载模型并生成过程中的峰值显存。

记录方式如下，在 Ollama 中可以通过环境变量拿到耗时，或者直接观察 GPU 显存：

# 使用 nvidia-smi 监控显存 watch -n 1 nvidia-smi

生成速度可以用官方脚本或ollama run配合测试提示词来估算。更精确的方式是使用 OpenAI 兼容接口调用，在代码里记录耗时。

5. 完整实战：搭建一个小模型竞技场评测脚本

5.1 项目结构

为了便于后续扩展和复现，建议把评测代码按结构组织起来。示例目录如下：

llm-arena/ ├── data/ │ ├── questions.json │ └── answers_reference.json ├── scripts/ │ ├── run_eval.py │ └── collect_metrics.py └── results/ └── eval_result.csv

5.2 准备测试题目

在data/questions.json中按维度组织题目，每个题目包含id、category、question和reference字段。

{ "questions": [ { "id": "logic_001", "category": "logic", "question": "所有 A 都是 B，所有 B 都是 C，那么是否能推出所有 A 都是 C？请回答能或不能。", "reference": "能" }, { "id": "math_001", "category": "math", "question": "一个水池进水管 4 小时注满，出水管 6 小时放空，同时打开两个管子，多久能注满？", "reference": "12小时" }, { "id": "code_001", "category": "code", "question": "用 Python 写一个函数，输入一个整数列表，返回列表中第二大的数，列表可能包含重复元素。", "reference": "def second_largest(nums): return sorted(set(nums))[-2]" } ] }

5.3 编写评测脚本

评测脚本的核心逻辑是：读取题目，调用模型接口，记录输出和耗时。Ollama 提供 OpenAI 兼容接口，所以我们可以用openaiPython 库来调用。

pip install openai pandas

下面是一个完整的评测脚本示例。文件路径：scripts/run_eval.py

import json import time import csv from openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama" # Ollama 本地接口不校验 key，但参数不能为空 ) MODEL_NAME = "qwen2.5:7b" def load_questions(path): with open(path, "r", encoding="utf-8") as f: data = json.load(f) return data["questions"] def ask_model(question): start = time.time() response = client.chat.completions.create( model=MODEL_NAME, messages=[{"role": "user", "content": question}], temperature=0.2, max_tokens=1024, stream=False ) elapsed = time.time() - start answer = response.choices[0].message.content usage = response.usage return { "answer": answer, "elapsed": round(elapsed, 2), "prompt_tokens": usage.prompt_tokens, "completion_tokens": usage.completion_tokens } def evaluate(): questions = load_questions("../data/questions.json") results = [] for q in questions: print(f"\n正在处理题目: {q['id']} [{q['category']}]") try: result = ask_model(q["question"]) results.append({ "id": q["id"], "category": q["category"], "question": q["question"], "reference": q["reference"], "answer": result["answer"], "elapsed": result["elapsed"], "prompt_tokens": result["prompt_tokens"], "completion_tokens": result["completion_tokens"] }) except Exception as e: print(f"调用失败: {e}") results.append({ "id": q["id"], "category": q["category"], "question": q["question"], "reference": q["reference"], "answer": f"ERROR: {e}", "elapsed": -1, "prompt_tokens": 0, "completion_tokens": 0 }) with open("../results/eval_result.csv", "w", newline="", encoding="utf-8-sig") as f: writer = csv.DictWriter(f, fieldnames=["id", "category", "question", "reference", "answer", "elapsed", "prompt_tokens", "completion_tokens"]) writer.writeheader() writer.writerows(results) print(f"\n评测完成，共 {len(results)} 道题，结果已保存到 results/eval_result.csv") if __name__ == "__main__": evaluate()

这个脚本会自动遍历所有题目，把模型的回答和耗时记录到 CSV 文件。encoding="utf-8-sig"是为了让 Excel 打开 CSV 时中文不乱码。

5.4 批量对比多个模型

上面脚本只测一个模型，如果想把 8 个模型都跑一遍，可以在脚本外层加一个模型列表循环。

MODELS = [ "qwen2.5:7b", "llama3.2:3b", "phi3:mini", "mistral:7b", "gemma2:9b" ] for model in MODELS: MODEL_NAME = model print(f"\n==================== 正在评测模型: {model} ====================") evaluate()

每次运行会生成一份独立的 CSV，文件名可以加上模型名加以区分。

5.5 生成速度统计

除了记录单题耗时，还需要统计生成阶段的 Token 速度。可以这样改造请求部分：

def ask_model_with_speed(question): start = time.time() response = client.chat.completions.create( model=MODEL_NAME, messages=[{"role": "user", "content": question}], temperature=0.2, max_tokens=1024, stream=False ) elapsed = time.time() - start completion_tokens = response.usage.completion_tokens speed = completion_tokens / elapsed if elapsed > 0 else 0 return speed

注意，这里计算的是“平均生成速度”，包含了首 Token 和网络传输时间。如果你需要精确到排除首 Token，可以使用流式接口stream=True做更细统计，后面会提到。

5.6 运行结果解读

运行完脚本后，CSV 中会包含模型原始回答。你可以采用打分制来量化：每题根据参考答案，人工或使用自动脚本打 0 到 2 分，最后按维度汇总。

这里要特别强调：小模型的回答经常“格式对但内容偏”，自动评分时不要只看关键词，最好结合人工抽检。建议至少抽检每个维度的前 5 道题，确认自动评分标准没有跑偏。

6. 横评中常见的关键差异点分析

6.1 量化版本对结果的影响

在竞技场对比中，所有模型都使用默认的 Q4_K_M 量化，这保证了各模型运行在相对接近的资源水平上。但不同模型对量化的敏感度不同，有的模型 Q4 下依然稳定，有的模型则明显出现“胡说”现象。

如果你在评测中发现某个模型表现异常差，先不要急着否定模型，可以尝试 FP16 或 Q8 版本再跑一遍。量化对 3B 以下的模型伤害更大，因为参数量少，信息冗余度低。

在实际选型时，建议把“量化后表现”作为决策依据，因为生产环境大概率不会用 FP16 部署。

6.2 上下文长度的影响

小模型虽然支持长上下文，但真实处理能力会随长度衰减。竞技场评测中，如果测试题目包含长文档，需要额外观察模型在 2K、4K、8K 不同长度下的表现。

测试方式很简单：把一段 5000 字的中文文本输入模型，要求它回答文本中的细节问题。不同模型对长上下文的关注能力差别很大，有的模型开头部分能记住，但中后段信息容易混淆。

6.3 中文能力的赛道差异

很多模型在英文榜上分数很高，但一到中文场景就明显下滑。

Qwen 系列中文表现最稳定，这和预训练语料中中文占比大有直接关系。
Llama 和 Mistral 中文能力偏弱，但在加了中文微调后也可以使用。
Gemma 2 对中文理解不错，但在中文生成风格上偏向书面语。
Yi 系列数学和中文能力均衡，适合中文数学题场景。

所以，如果你的业务是纯中文，那么横评中的中文维度权重应该调高。如果你的业务以代码为主，代码能力权重可以占到 40% 以上。

6.4 指令遵循的“不听话”问题

小模型在指令遵循上的问题比大模型严重得多。常见表现有：

要求输出 JSON，结果输出了一段解释文字。
要求只回答“是/否”，结果把推理过程也写了。
要求使用中文，结果一半中文一半英文。

这些问题的根源在于模型的指令跟随能力弱，本质上是对“输出约束”的理解不足。在评测时，这一项分数需要真实记录，因为部署到业务中，解析失败就是事故。

7. 从横评到落地：以微信小程序运行小模型为例

7.1 端侧推理的可行性

“微信小程序运行深度学习模型”之所以能成为热点，是因为端侧推理的硬件基础已经具备。手机端的 NPU、GPU 性能逐年增强，加上 WebAssembly 和 WebGPU 技术的普及，让浏览器和小程序环境跑轻量模型成为可能。

但也要清醒认识一个问题：微信小程序不是一个完整的浏览器环境，它的 WebAssembly 支持有一定限制，直接加载 PyTorch 模型不现实。常见的做法是：

将模型转为 ONNX 或 TFLite 格式。
使用 Transformer.js 或 TensorFlow.js 的适配版本。
在服务端完成模型转换，把 WebAssembly 产物打包进小程序。

7.2 一个可行的实现思路

假设我们已经训练或选好了一个 0.5B 或 1B 的小模型，在小程序端做文本分类或情感分析，流程可以设计为：

模型转换：将 PyTorch 模型导出为 ONNX，再转为适合移动端的格式。
模型压缩：使用 INT8 或 INT4 量化，把模型体积控制在 100MB 以内。
小程序集成：通过 WebAssembly 模块加载模型，在本地完成推理。
云端兜底：模型无法处理的复杂问题，再转发到服务器上的大模型。

下面是一个前端加载 ONNX 模型的示例片段（使用 onnxruntime-web）：

// pages/model/model.js const ort = require('onnxruntime-web'); Page({ async loadModel() { const session = await ort.InferenceSession.create('/models/text_classifier.onnx'); this.session = session; console.log('模型加载成功'); }, async predict(text) { const inputTensor = new ort.Tensor('float32', this.tokenize(text), [1, this.maxLen]); const feeds = { input_ids: inputTensor }; const results = await this.session.run(feeds); const logits = results.output.data; const label = logits[0] > logits[1] ? '正面' : '负面'; return label; }, tokenize(text) { // 这里需要接入分词器，简化示例中直接返回固定长度的 Array return new Array(128).fill(0); } });

注意，上面的tokenize方法只是一个占位实现。在实际项目中，你需要把 Hugging Face Tokenizer 转换为 JavaScript 版本，或者提前在服务端把文本转成 token ID 再下发到小程序，后者更简单，但会引入网络请求。

7.3 小程序端部署的坑点

小程序包体积有大小限制，单个分包压缩包不能超过 2MB，整个小程序所有分包大小不超过 20MB（不同平台政策可能会调整）。量化后的小模型动辄几十 MB，直接放到小程序包里不现实。

更常见的方案有两种：

模型放在服务器，小程序首次启动时下载到本地缓存，通过wx.getFileSystemManager().saveFile持久化。
使用小程序的插件机制或云开发能力，把模型作为云函数的一部分，但这样推理就在云端了，不是纯粹的端侧推理。

所以在“微信小程序运行深度学习模型”这个方向上，建议优先考虑 0.5B 以下且经过 INT4 量化的超小模型，并且把模型加载做成异步、带进度条的体验，避免小程序闪退或白屏。

8. 小模型竞技场评测中的常见问题

8.1 模型拉取失败或速度很慢

问题现象	常见原因	解决思路
`ollama pull`卡住	网络连接不稳定	配置代理或镜像源，确认网络畅通
模型下载到一半失败	磁盘空间不足	清理磁盘或更换下载路径
模型文件名找不到	标签名拼写错误	用`ollama search`查看可用模型列表

8.2 推理速度忽快忽慢

问题现象	常见原因	解决思路
首次请求特别慢	模型需要从磁盘加载到显存	预热请求，提前发一个空请求
多轮请求后变慢	显存不足触发换页	缩小模型版本或降低并发数
速度不稳定	其他进程占用 GPU	用`nvidia-smi`检查进程，闲置资源释放

8.3 模型回答质量明显偏低

问题现象	常见原因	解决思路
答非所问	量化精度太低	改用 Q8 或 FP16 版本
中文乱码	模型本身中文能力弱	选择 Qwen、GLM 等中文向模型
输出不符合格式要求	指令遵循能力不足	在提示词中增加示例，适当降低 temperature
JSON 解析失败	模型输出了多余文字	使用约束解码功能，例如 Ollama 的`format: json`参数

8.4 不同框架下结果不一致

同一个模型在 Ollama、llama.cpp、vLLM 中采样逻辑不同，输出会有细微差异。评测时要固定一个推理框架，并在报告中注明框架和版本，否则结果不可复现。

这就是为什么本文前面强调“评测环境和生产环境保持一致”。如果你打算用 vLLM 上线，评测就在 vLLM 上跑；如果你只是在调研，可以先用 Ollama 快速出结果，但对最终结论保持谨慎。

8.5 评测集过小导致结论不稳定

20 道题可能看不出差距，至少每个维度准备 30 道以上题目，8 个维度加起来至少 200 道题，才能得到一个相对可信的横向对比。如果时间有限，优先保证“逻辑推理、代码、中文理解”这三个维度题量充足。

9. 基于横评结果的选型建议与最佳实践

9.1 按场景选型

根据竞技场评测的维度差异，可以给出以下选型参考。注意，这只是通用建议，具体还是要以你自己的测试结果为准。

业务场景	推荐的模型方向	理由
中文客服/对话	Qwen、GLM 系列	中文语料充分，指令遵循相对稳定
代码辅助/自动补全	DeepSeek 蒸馏、Qwen-Coder	代码能力经过专项优化
英文内容生成	Llama、Mistral 系列	英文自然度和多样性更好
端侧部署（手机/小程序）	Qwen 0.5B/1.8B、Llama 3.2 1B	体积小，量化后可控性好
数学题目解答	Yi、DeepSeek 蒸馏系列	数学推理能力相对突出

9.2 评测数据管理

小模型迭代速度快，评测数据要版本化。

建议在项目仓库里维护一个eval_sets/v1/目录，如果题目有调整就创建v2/，不要原地覆盖。每次评测记录：

评测集版本
模型名称和标签
推理框架和版本
量化位数
硬件配置
运行时间
评测结果文件

这样后续模型更新时，可以直接用同一套评测集复测，对比前后差异。

9.3 提示词设计的一致性

横向对比时，所有模型必须使用完全相同的提示词。不同模型对提示词格式的敏感度不同，但竞技场对比看的是“默认通用提示词下的表现”，这是最公平的比较方式。

如果需要为某个模型专门优化提示词，建议单独记录“最优提示词”版本，不要混在横评里。

9.4 部署时的量化策略

如果你已经通过横评选定了一个模型，部署前建议做一次“量化敏感性测试”：

用 Q4 量化模型跑一遍业务核心场景的 50 道题。
记录分数和失败案例。
改用 Q8 或 FP16 跑同样 50 道题。
对比差异是否在可接受范围内。

如果 Q4 和 FP16 差异很小，可以直接上 Q4 省显存。如果差异明显，可能需要增加量化位数，或改用更大的模型。

9.5 安全与合规建议

小模型本地部署在数据安全方面有优势，但也要注意几个问题：

模型可能生成不合规内容，需要加一层输出过滤或敏感词检测。
不要在模型微调数据中包含未经脱敏的个人信息。
对模型的输出进行日志留存，方便问题回溯。
涉及生产环境变更时，先在测试环境完整验证，再灰度上线。

10. 总结与下一步学习建议

本文围绕 karminski 的小模型竞技场横评，梳理了小模型评测的方法论和完整落地流程。从评测维度设计、环境准备、脚本编写到结果解读，覆盖了一次横向对比评测的全部环节。同时补充了小模型在微信小程序这类端侧场景中的部署思路和注意事项。

如果你接下来想继续深入，可以从这几个方向入手。

先动手复现一次横评。按照本文第 5 章的脚本，选 3 到 5 款模型跑一遍完整评测。不用追求题目数量多，先跑通流程，再逐步扩充你自己的业务评测集。

接着研究量化技术。理解 Q4、Q8、FP16 对模型效果和速度的影响，是部署环节的重要技能。建议从 llama.cpp 的量化工具入手，自己动手转换一个模型。

然后学习推理引擎的优化。对比 Ollama、llama.cpp、vLLM 在不同场景下的性能差异，尤其是并发请求下的表现。

最后关注端侧推理。如果你对微信小程序运行深度学习模型感兴趣，可以先从 ONNX Runtime Web 或 TensorFlow.js 入手，把一个小文本分类模型跑通。

小模型的价值不在于“复刻大模型”，而在于用更低的成本解决实际业务问题。希望这份横评框架能帮你找到适合自己业务的那一款模型。如果本文对你有帮助，可以先收藏备用，后续做模型选型时直接对照执行。