企业官网建设流程全解析

如果你过去两年一直在关注 AI 应用开发，一定会有这种感觉：大模型很强，但真正让你敢在业务里直接用的，反而是那些参数量不大、资源占用可控的小模型。小模型不是“大模型的缩小版”，它已经形成了自己的技术路线：量化、蒸馏、端侧推理、私有化部署、低成本调用。最近，karminski 发布的 8 款小模型竞技场横评，正好踩中了很多团队在选型时的核心痛点——面对一堆小模型，到底该怎么比、怎么选、怎么落地。

这篇文章不打算只转述评测结果，而是把“小模型横评”这件事拆开讲清楚。我们会先解决一个更根本的问题：小模型评测到底在看什么；然后给出 8 款常见小模型的横向对比视角；再通过可复制的部署示例、评测脚本和问题排查，帮你真正跑通一个本地小模型。如果你正在做端侧 AI、私有化部署，或者正准备把深度学习模型塞进微信小程序，这篇文章尤其值得读完。

先说一个明确判断：小模型横评的价值，不在于“谁的分数最高”，而在于帮你建立一套自己的选型坐标系。没有这套坐标系，你看到的所有横评都只是排行榜上的数字，和你实际的项目场景毫无关系。

1. 这篇文章真正要解决的问题

很多开发者第一次接触小模型，都会陷入两个极端。要么觉得“参数这么少，能力肯定不行”，要么觉得“反正 N 款模型都能下载，随便挑一个用就行”。这两种想法都容易踩坑。

先说第一个误区。现在的 1B 到 9B 小模型，在垂直任务上的表现已经远超很多人的预期。代码补全、分类抽取、文本改写、函数调用、简单问答，这些场景中小模型完全能胜任。尤其是经过蒸馏和量化之后的小模型，推理速度可以做到大模型的好几倍，而精度损失控制在可接受范围内。相反，如果你不需要复杂推理，硬上一个大模型，反而是成本的浪费。

再说第二个误区。小模型选错，比大模型选错更隐蔽。大模型之间能力差异明显，你很容易通过几个测试用例判断好坏。但小模型各有各的“性格”：有的中文能力强，有的代码格式规范，有的长文本稳定，有的对工具调用支持好。只看单项指标，根本无法判断它适不适合你的业务。

所以，这篇文章要解决的问题非常具体：

• karminski 这类小模型竞技场横评，到底在评测哪些维度？哪些维度对你真正重要？
• 8 款常见小模型，各自适合什么场景？为什么不能只看排行榜？
• 在本地部署一个小模型需要什么环境？如何用 Ollama、Transformers、llama.cpp 快速跑通？
• 如何从一个评测数据集中抽取任务，验证模型在你业务场景中的真实表现？
• 如果要把小模型部署到微信小程序或移动端，需要关注哪些能力边界？

读完这篇文章，你会得到一套可以复用的“小模型选型 + 部署 + 评测”方法论。我们不保证帮你选出绝对最好的模型，因为最好的模型取决于你的任务、数据和硬件。

2. 小模型竞技场评测的核心概念与适用场景

2.1 什么是小模型

小模型（Small Language Model，SLM）并没有一个严格的参数边界。从当前的生态来看，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 款候选模型

当前小模型赛道比较有代表性的模型包括：

请注意：这里的参数规模和特性只是参考，具体模型版本更新很快，你不能把它当作固定结论。选型时一定要基于你下载到的实际版本和评测结果。

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、命令行交互全部封装好，适合快速验证。

# 安装 Ollama（macOS/Linux） curl -fsSL https://ollama.com/install.sh | sh # 拉取模型，以 Qwen2.5 为例 ollama pull qwen2.5:3b # 启动服务 ollama serve

4.3 路线二：Hugging Face Transformers 加载

如果你需要精细控制推理过程，比如调整采样参数、改模型输出层，或者要加载特定量化版本，可以用 Transformers。

# 创建虚拟环境 python3 -m venv sllm-env source sllm-env/bin/activate # 安装依赖 pip install transformers torch accelerate

4.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_dtype="auto", device_map="auto" ) prompt = "你是一个技术助手。请用三句话说明小模型在大模型时代的意义。" messages = [ {"role": "system", "content": "你是一个严谨的技术助手。"}, {"role": "user", "content": prompt} ] text = tokenizer.apply_chat_template( messages, tokenize=False, add_generation_prompt=True ) inputs = tokenizer([text], return_tensors="pt").to(model.device) generated_ids = model.generate( **inputs, max_new_tokens=512, temperature=0.7, top_p=0.9, do_sample=True ) generated_ids = generated_ids[:, inputs.input_ids.shape[1]:] response = tokenizer.batch_decode(generated_ids, skip_special_tokens=True)[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, json=payload) 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", encoding="utf-8") as f: json.dump(results, f, ensure_ascii=False, indent=2) print(json.dumps(results, ensure_ascii=False, indent=2))

运行命令：

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. 常见问题与排查方法

8. 小模型部署到微信小程序/端侧的最佳实践

8.1 端侧部署为什么越来越常见

“微信小程序运行深度学习模型”已经成为 2025 年前后非常热门的实践方向。原因并不神秘：

• 小模型量化后可以做到几十 MB 甚至十几 MB；
• WebAssembly 可以在小程序容器中运行 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 三条路线部署小模型；
• 如何写一个最小评测脚本，用业务样本判断模型的真实表现；
• 在小程序和端侧场景中，做小模型选型和部署有哪些实用原则。

下一步，你可以按这样的路径实践：

1. 把文中的 Ollama 示例跑通，选 2 到 3 款候选模型；
2. 准备 20 条自己业务中的真实样本，跑一遍评测脚本；
3. 记录每款模型在同一个问题下的输出、延迟和稳定度；
4. 根据结果选一款主力模型，再做量化与部署验证；
5. 最后，结合你的目标平台（服务器、桌面端、小程序等）完善上线方案。

小模型领域变化非常快，今天推荐的版本可能下个月就被新模型超越。保持横评的方法论比记住某一个排行榜更重要。建议收藏备用，等你需要做模型选型时，再回来对照这套流程重新跑一遍，它会帮你少走很多弯路。