企业官网建设流程全解析

1. 为什么现在聊开源模型对比，时机刚刚好

过去一年多，我几乎每个月都要重新做一轮模型选型。原因很简单：闭源模型的能力天花板虽然还在往上走，但开源这一侧的迭代速度已经完全不是当年 LLaMA 一代那种"追着跑"的节奏了。现在的情况是，很多开源模型在特定任务上已经能打平甚至超过一些闭源的中量级模型，而成本却低了一个数量级。这个变化对做产品、做研究、做企业内部工具的人来说，意义非常大。

我自己踩过的坑是：早期盲目追榜单，看到某个模型在 Open LLM Leaderboard 上排名靠前就直接上生产，结果发现它在中文长文本理解上表现稀烂，工具调用格式也经常跑偏。后来我才慢慢建立起一套自己的对比框架——不只看分数，还要看量化后的实际表现、推理框架的兼容性、上下文窗口的真实可用长度、以及社区维护的活跃度。这套框架帮我省了大量返工时间。

这篇内容适合三类人：一是正在做模型选型的技术负责人，二是想本地部署开源模型但不知道从哪下手的开发者，三是做 RAG、Agent 这类应用、需要判断"底座模型该换哪个"的工程师。我会把对比的维度拆开讲清楚，每个维度为什么重要、怎么测、常见误区在哪，最后给出一套可以直接抄的对比流程。

2. 开源模型对比到底在比什么

2.1 先搞清楚"开源"这两个字的含金量

很多人把"权重可下载"等同于"开源"，这其实是个误区。严格来说，开源模型之间在开放程度上差异巨大。有的只放权重，训练数据、训练代码全闭；有的放权重加推理代码；还有的连数据配方和训练脚本都给。这个差异直接影响你能不能做继续预训练、能不能做领域微调、能不能商用。

我一般会按这几个档位来分类：

• 仅权重开放：能推理、能做 LoRA 微调，但没法复现训练过程，商用条款要看具体协议。
• 权重加推理代码：多了推理侧的参考实现，部署时省事。
• 权重加训练代码：可以做全参数继续预训练，适合有算力的团队。
• 全开放（含数据配方）：极少，但研究价值最高。

注意：商用许可一定要逐字读。有些模型标着"开源"，但月活超过一定规模就要单独授权，或者禁止用于某些特定场景。这个坑我见过太多团队踩。

2.2 参数量不是越大越好，要看你的场景

参数量决定了模型的"基础智力上限"，但也直接决定了你的硬件成本和推理延迟。我通常把开源模型按参数量分成四档来对比：

这里有个反直觉的经验：在很多垂直任务上，一个精调过的小模型比通用大模型更好用。比如中药处方审核这种场景，7B 模型用高质量领域数据微调后，准确率和稳定性往往超过直接调用 70B 通用模型。原因是通用大模型对领域术语的理解不够细，容易"一本正经地胡说"。

2.3 榜单分数只能当参考，不能当结论

Open LLM Leaderboard 这类公开榜单我每周都会看，但我从不拿它做最终决策。原因有三：

第一，榜单任务和真实任务分布不一致。榜单考的是 MMLU、GSM8K 这类标准化题目，而你的业务可能是"从 ERP 系统里检索产品并生成报价单"，两者差得远。

第二，榜单容易被"刷"。有些模型针对榜单任务做了特定优化，分数虚高，换个任务就露馅。

第三，榜单很少反映量化后的表现。你生产环境大概率跑的是 4bit 量化版本，而榜单测的是全精度。这两者之间的性能差距，有时候能到 10 个点以上。

我的做法是：榜单用来做初筛，把候选从几十个缩到五六个，然后自己搭一套贴近业务的评测集做终选。

3. 核心对比维度拆解与实操要点

3.1 能力维度：怎么测才靠谱

能力对比不能只看一个总分，要拆成几个子维度分别测。我一般拆成六块：

• 通用知识与推理：用 MMLU、ARC 这类题，或者自己出几十道业务相关的选择题。
• 中文理解：这个必须单独测，很多英文强的模型中文很拉胯。用 C-Eval 或者自己构造中文长文本问答。
• 代码能力：HumanEval、MBPP，或者直接让它写你项目里的真实函数。
• 数学与逻辑：GSM8K、MATH，重点看多步推理的稳定性。
• 指令遵循：给它复杂格式要求，看它能不能严格照做。这个对 Agent 场景极其关键。
• 长上下文：把关键信息埋在长文档中间，看它能不能捞出来（俗称"大海捞针"测试）。

我自己的评测集一般控制在 100–200 题，覆盖上面六块，每题都有标准答案或评分标准。跑一遍大概半小时，但能筛掉大量"看起来很强实际不能用"的模型。

实操心得：评测集一定要包含"负样本"——就是那些模型容易过度自信、编造答案的题目。看它在不知道的时候会不会说"我不确定"，比看它答对多少题更能反映真实可用性。

3.2 量化维度：生产环境的真实门槛

全精度模型在生产里几乎没人跑，因为太贵。量化是绕不开的一步。常见的量化档位有 FP16、INT8、INT4（又分 GPTQ、AWQ、GGUF 等多种格式）。量化档排名这几年越来越受关注，因为它直接决定了"我这张卡能不能跑得动"。

我的经验是：

• FP16：效果最好，但显存占用是 INT4 的约 4 倍。7B 模型大概要 14G 显存。
• INT8：效果损失很小，显存减半，7B 大概 7–8G。
• INT4：显存再减半，7B 大概 4–5G，消费级显卡就能跑。但效果损失因模型而异，有的模型掉点很少，有的直接崩。

关键点是：不同模型对量化的敏感度差异极大。有的模型 INT4 之后几乎无损，有的 INT8 就开始胡言乱语。所以对比时一定要把"量化后表现"作为独立维度，而不是假设量化损失是均匀的。

我一般会这样测：同一个模型，分别跑 FP16 和 INT4，用同一套评测集，看分数差多少。如果差在 3 个点以内，我就认为这个模型的 INT4 版本可用。

3.3 工程维度：能不能顺利跑起来

这一块经常被忽略，但实际影响巨大。一个模型能力再强，如果推理框架不支持、格式不兼容、社区没人维护，你部署起来会非常痛苦。

我关注的工程维度包括：

• 推理框架支持：vLLM、TensorRT-LLM、llama.cpp、Ollama 这些主流框架支持不支持？支持得好不好？
• 对话模板：每个模型的 prompt 格式不一样，有的用特殊 token，有的用系统提示词。格式搞错，效果直接打折。
• 工具调用支持：做 Agent 的话，模型能不能稳定输出结构化的函数调用格式？这个必须实测。
• 上下文窗口真实性：标称 128K，实际能不能用满？很多模型超过 32K 就开始丢信息。
• 社区活跃度：GitHub issue 响应速度、有没有人持续出量化版本、微调生态丰不丰富。

踩坑记录：我曾经选了一个榜单分数很高的模型，结果它的对话模板特别刁钻，vLLM 默认配置跑出来效果比官方 demo 差一大截。后来手动改了 chat template 才恢复正常。这个教训让我现在选型时一定先跑通"官方推荐配置"再对比。

3.4 成本维度：算清楚每一百万 token 的钱

成本对比不能只看显卡价格，要算综合账。我一般按"每百万 token 的推理成本"来算，包含：

• 硬件折旧（按 3 年摊）
• 电费
• 运维人力
• 量化带来的效果损失折算

举个粗略的例子：一张 4090 跑 7B INT4 模型，吞吐大概每秒几十个 token，满载功耗 400W 左右。按电费算，每百万 token 的电费成本其实很低，主要成本在硬件折旧。而如果租云 GPU，成本结构又不一样。

对于大多数团队，我的建议是：先用 API 验证需求，需求稳定后再考虑自部署。自部署的固定成本高，只有当你每天的 token 消耗量足够大时，单位成本才会低于 API。

4. 完整对比流程：从候选到定稿

4.1 第一步：明确你的任务画像

在开始对比之前，先回答几个问题：

1. 你的任务是什么类型？对话、抽取、生成、代码、还是 Agent？
2. 输入输出大概多长？需不需要长上下文？
3. 延迟要求是多少？实时对话和离线批处理的要求完全不同。
4. 部署环境是什么？本地、私有服务器、还是云？
5. 有没有合规或数据不出域的要求？

这几个问题决定了你的候选范围。比如你要做本地部署且只有一张 16G 卡，那 70B 模型直接排除，候选就锁定在 7B–14B 的量化版本。

4.2 第二步：用榜单做初筛

打开 Open LLM Leaderboard 或者类似的公开榜单，按你的任务类型筛选。比如做代码就重点看 HumanEval 和 MBPP，做中文就重点看 C-Eval。把候选缩到 5–8 个。

这一步不要纠结排名先后，只要在合理区间内就都留下。因为榜单的误差和你的真实场景差异，足以让排名发生翻转。

4.3 第三步：搭建自己的评测集

这是最关键的一步。评测集要满足：

• 贴近真实任务：直接从你的业务日志里抽样本，脱敏后作为测试题。
• 覆盖边界情况：空输入、超长输入、格式错误输入、需要拒答的输入。
• 有明确评分标准：能自动评分的用脚本，不能的用人工打分表。
• 规模适中：100–200 题足够，太多跑不完，太少不显著。

我一般会准备两套：一套"能力集"测通用水平，一套"业务集"测真实场景。两套都过，才进入下一轮。

4.4 第四步：统一环境跑分

对比时环境必须统一，否则结果不可比。统一的东西包括：

• 推理框架和版本
• 量化档位（都用 INT4 或都用 FP16）
• 采样参数（temperature、top_p 等）
• 对话模板（用各自官方推荐的）
• 硬件（同一张卡）

跑分时记录每个模型的：准确率、平均延迟、显存峰值、吞吐量。这四个指标一起看，才能做出平衡的决策。

4.5 第五步：小流量灰度验证

评测集过了不代表生产没问题。上线前一定要做灰度，用真实流量跑一周，观察：

• 用户反馈（有没有变差）
• 异常率（格式错误、拒答、超时）
• 成本（实际 token 消耗和预期差多少）

灰度期间保留回滚能力，一旦发现问题立刻切回旧模型。

5. 常见问题与排查技巧实录

5.1 模型输出格式不稳定怎么办

这是 Agent 和结构化抽取场景最常见的问题。表现是：同样的 prompt，有时候输出 JSON，有时候输出带解释的文字，有时候字段名还变了。

排查思路：

1. 先确认对话模板用对了。很多格式问题根源是 chat template 配错。
2. 检查采样参数。temperature 太高会导致格式漂移，做结构化任务时建议调到 0.1 以下。
3. 用 few-shot 示例固定格式。给两三个输入输出样例，模型会稳定很多。
4. 如果还不行，考虑用支持工具调用的模型，或者加一层输出解析和重试。

独家技巧：我会在 prompt 里明确写"只输出 JSON，不要任何解释"，并且在解析失败时自动重试一次，重试时把上次的错误输出也塞回去让它修正。这个组合拳能把格式错误率压到很低。

5.2 量化后效果明显下降怎么处理

先确认是不是量化的问题，而不是 prompt 的问题。方法是用同一个 prompt 分别跑 FP16 和 INT4，对比输出。如果 FP16 正常 INT4 崩，那就是量化损失。

应对方案：

• 换量化格式。GPTQ 换成 AWQ，或者换成 GGUF 的 Q5_K_M，往往能救回来。
• 提高量化精度。INT4 换 INT8，显存翻倍但效果回来。
• 换模型。有些模型天生对量化不友好，换一个对量化鲁棒的。

5.3 长上下文用不满怎么办

标称 128K 但实际用不到，通常有几个原因：

• 推理框架的 KV cache 配置没开满。
• 模型本身在长上下文上训练不足，超过某个长度就开始丢信息。
• 位置编码外推没做好。

我的做法是：用"大海捞针"测试确定这个模型的实际可用长度。把关键信息放在不同位置（开头、中间、结尾），看哪个位置开始捞不到。然后按实际可用长度来设计应用，而不是按标称长度。

5.4 常见问题速查表

6. 我自己的选型心得与几个实用建议

做了这么多轮对比，我最大的体会是：没有最好的模型，只有最适合你当前任务的模型。同一个模型，在 A 任务上封神，在 B 任务上可能完全不能用。所以对比这件事，一定要带着具体任务去做，不要泛泛地比"谁更聪明"。

第二个体会是：量化版本的表现要单独评估。我见过太多团队拿全精度分数做决策，结果上线跑量化版本翻车。把量化测试纳入标准流程，能省掉大量返工。

第三个建议是：保持候选池的更新。开源模型迭代太快，半年前的最优解现在可能已经落后。我一般每季度重新跑一轮对比，把新出的模型加进来，把明显落后的踢出去。这个习惯让我总能用到当下最合适的模型。

最后分享一个我常用的快速验证方法：拿到一个新模型，先别急着搭评测集，用十个你自己最熟悉的业务问题问它一遍。如果这十个问题答得让你满意，再进入正式对比流程；如果连这十个都答不好，直接跳过，省时间。这个方法虽然粗糙，但筛选效率极高，帮我省了大量无效对比的时间。

对于刚开始接触开源模型的朋友，我的建议是从 Ollama 这类工具入手，先跑起来几个 7B 模型感受一下，建立直观认知，再逐步深入到量化、微调、部署这些环节。上手门槛比想象中低，但要做好，确实需要一套系统的方法。