跑得最快的模型，长文本全部超时。参数最多的模型，总分垫底。最终胜出的是参数最少的那个——76.6% vs 69.7% vs 69.1%。这篇记录 160 道题、6 个维度的完整评测过程，以及为什么"参数大 ≠ 质量好"。
评测设计
参考了 Artificial Analysis 和主流 benchmark 的方法论，设计了 6 个维度、160 道题的评测集：
| 维度 | 题数 | 数据来源 | 考察能力 |
|---|---|---|---|
| 通识基础 | 50 | MMLU-Pro | 多领域知识 |
| 高级推理 | 30 | GSM8K + ARC-Challenge | 数学 + 逻辑 |
| 指令跟随 | 30 | IFEval | 格式约束遵循 |
| 模型幻觉 | 25 | TruthfulQA + SQuAD v2 | 拒答 + 事实性 |
| 工具调用 | 10 | BFCL v3 | Function Calling |
| 长文本 | 15 | K8s 文档 | 8K-32K 上下文理解 |
为什么不直接用公开 benchmark
公开 benchmark 的问题：
- 数据污染——模型训练数据可能包含测试题
- 场景不匹配——我们需要的是工具调用、长文本理解，不是做高考题
- 量化影响——FP8 量化后的表现和原始精度不同，需要实测
所以我从公开数据集中抽样，加上自己构造的工具调用和长文本题目，确保评测贴近实际使用场景。
评测流程
1. Collect：向每个模型发送 160 道题，收集原始回复
2. Auto-Score：规则引擎自动评分（MCQ 精确匹配、数学答案提取、格式检查）
3. Manual Review：人工审核自动评分结果，修正误判
关键配置：
temperature=0.6，开启 thinking mode（Qwen3.5/3.6 支持）max_tokens=4096- 超时 300 秒/题
自动评分规则
不同题型用不同评分逻辑：
- MCQ：精确匹配选项字母（A/B/C/D）
- 数学：从回复中提取
\boxed{}或加粗数字，和标准答案比较 - 指令跟随：逐条检查约束（JSON 格式、字数限制、语言要求、关键词包含等）
- 幻觉/可回答：语义匹配预期答案
- 幻觉/不可回答：检测拒答模式（"I don't know"、"无法确定"等）
- 工具调用：解析模型输出的 tool call 格式，匹配函数名和参数
评测结果
| 维度 | Qwen3.5-27B | Qwen3.6-35B | Gemma4-31B |
|---|---|---|---|
| 通识基础 (50) | 52.0% | 50.0% | 60.0% |
| 高级推理 (30) | 93.3% | 86.7% | 86.7% |
| 指令跟随 (30) | 71.7% | 61.7% | 68.3% |
| 模型幻觉 (25) | 100% | 100% | 100% |
| 工具调用 (10) | 100% | 80.0% | 90.0% |
| 长文本 (15) | 80.0% | 60.0% | 0.0% ⚠️ |
| 总分 (160) | 76.6% | 69.7% | 69.1% |
逐维度分析
通识基础：Gemma4 领先
Gemma4 在 MMLU-Pro 多选题上表现最好（60%），可能因为 Google 的训练数据在百科知识方面更全面。Qwen3.5 和 3.6 都在 50% 左右，说明 FP8 量化对知识类任务有一定影响。
高级推理：Qwen3.5 碾压
Qwen3.5 在数学推理上达到 93.3%，远超其他两个模型。Qwen3.6 虽然有 thinking mode，但倾向于过度推理——在复杂数学题上写了很长的推导过程，结果被 max_tokens 截断，最终答案没输出完。
这是 MoE 架构的一个隐性问题：Expert 路由增加了推理路径的不确定性，模型更容易"跑偏"。
指令跟随：所有模型都不够好
IFEval 的约束非常严格（"用 JSON 格式回答"、"不超过 50 个词"、"必须包含关键词 X"），三个模型都只有 62-72%。这是当前开源模型的普遍短板。
模型幻觉：全部满分
三个模型在幻觉测试上都是 100%——该拒答的拒答，该引用的引用。FP8 量化没有影响模型的事实性判断能力。这是个好消息。
工具调用：格式差异
Qwen3.5 满分，Gemma4 90%，Qwen3.6 只有 80%。
问题出在格式：
- Qwen3.5/3.6 用
<function=name>XML 格式 - Gemma4 用
<|tool_call>call:name{...}格式
Qwen3.6 的 2 道错题是参数格式不对（JSON 里多了引号转义），不是逻辑错误。这种问题在实际使用中可以通过 prompt 工程缓解。
长文本：Gemma4 全军覆没
Gemma4 的 15 道长文本题全部超时（300 秒）。原因：Dense 31B 模型在单卡 L40S 上处理 8K-32K 的 prefill 太慢，TTFT 超过 300 秒。
这不是模型能力问题，是硬件限制。如果给 Gemma4 双卡 TP=2，长文本性能会好很多。但在单卡方案里，它不适合长文本场景。
最终选型
综合性能和质量：
| 指标 | Qwen3.5-27B | Qwen3.6-35B | Gemma4-31B |
|---|---|---|---|
| 质量总分 | 76.6% | 69.7% | 69.1% |
| 单请求速度 | 18.1 tok/s | 11.0 tok/s | 17.4 tok/s |
| 并发吞吐 | 130.3 tok/s | 83.6 tok/s | 132.0 tok/s |
| 长文本支持 | ✅ 128K | ⚠️ 64K | ❌ 32K OOM |
| 工具调用 | 100% | 80% | 90% |
结论：Qwen3.5-27B-FP8 是单卡 L40S 上的最佳选择。
它在质量、速度、长文本、工具调用四个维度上都是最优或接近最优。唯一的短板是通识知识（52% vs Gemma4 的 60%），但这对我们的业务场景（代码生成、文档问答、工具调用）影响不大。
复盘
整个评测过程中学到的几点：
- 不要同时跑 throughput 和 eval——我犯过这个错误，两个测试互相干扰，数据全废了
- MoE 模型的"活跃参数"是个陷阱——3B 活跃参数不代表 3B 的速度，Expert 路由有开销
- 量化对不同能力的影响不同——FP8 对推理能力影响小，对知识记忆影响大
- 硬件限制比模型能力更重要——Gemma4 的长文本能力不差，是单卡显存不够
这个系列到此结束。从基础设施搭建、显存优化、性能测试到质量评测，完整记录了在单卡 L40S 上部署大模型推理服务的全过程。希望对同样在做企业内部大模型部署的同学有帮助。