选模型不是找"最强"的那个，是找"刚好够用且最省资源"的那个。

为什么要做这么细的对比？

两个延迟敏感路径：工具选择要求 <100ms，信息提取要求 <500ms。云端 API 的 p99 延迟抖动（500ms+）不可接受。另外本地模型零 API 成本——每天 1 万次工具选择，不用模型 = 每年省 ¥2,800-¥8,500。

---

实验设计

• 模型：Qwen2.5-0.5B / 1.5B / 3B + Qwen3-1.7B
• 设备：CPU (FP32) / GPU (FP26 CUDA)
• 信息提取：30 条真实电商消息 × 5 种意图
• 工具选择：50 条标注 query × 10 个工具

---

信息提取：0.5B 在编造字段

模型	设备	字段 F1	值匹配率	p50
Qwen2.5-0.5B	GPU	0.723	70%	344ms
Qwen2.5-0.5B	CPU	0.723	70%	1.6s
Qwen2.5-1.5B	GPU	0.784	83%	570ms
Qwen2.5-1.5B	CPU	0.784	83%	4.9s
Qwen3-1.7B	GPU	0.984	100%	703ms
Qwen3-1.7B	CPU	0.984	100%	5.5s
Qwen2.5-3B	GPU	0.969	100%	922ms
Qwen2.5-3B	CPU	0.969	100%	9.1s

0.5B 的最大问题不是精度低——而是它在"编造"字段。不该输出任何参数的意图，它硬塞了一个不存在的字段。1.5B 同样有"空 Schema 填充"问题：5 条错误中 3 条是"不该输出却输出了"。

---

工具选择：3B 的意外登顶

模型	设备	Top-1	p50
Qwen2.5-0.5B	GPU	56%	63ms
Qwen2.5-0.5B	CPU	58%	476ms
Qwen2.5-1.5B	GPU	92%	94ms
Qwen2.5-1.5B	CPU	92%	1.3s
Qwen3-1.7B	GPU	88%	109ms
Qwen3-1.7B	CPU	88%	1.5s
Qwen2.5-3B	GPU	96%	156ms
Qwen2.5-3B	CPU	96%	2.6s

3B 的完全匹配率只有 78%——它倾向于多选（如"我的订单到哪了"同时输出 query-order + check-shipping）。好消息是所有多选 case 的正确答案都在输出中，加一句"只选 1 个"的 prompt 约束即可修复。

---

CPU vs GPU，加速比的真相

模型	信息提取 CPU	信息提取 GPU	加速比	工具选择 CPU	工具选择 GPU	加速比
0.5B	1.6s	344ms	4.7x	476ms	63ms	7.6x
1.5B	4.9s	570ms	8.7x	1.3s	94ms	13.6x
1.7B	5.5s	703ms	7.8x	1.5s	109ms	13.3x
3B	9.1s	922ms	9.9x	2.6s	156ms	16.4x

结论：本系统必须有一个 GPU。 CPU 上信息提取最快也要 1.6s（0.5B），最慢 9.1s（3B），全部突破 500ms 的延迟红线。工具选择同样——CPU 上 3B 需要 2.6s，是 GPU 的 16 倍。CPU 降级只是"系统还能跑"的兜底，不是正常使用路径。

---

SFT 微调决策树：不是所有模型都值得微调

选型结果出来了，下一步是"要不要做 SFT"。这是一笔投入产出的账：

场景	当前精度	SFT 后预期	数据量	ROI
3B 信息提取	F1=0.969, 值匹配 100%	0.98-0.99	—	❌ 改 prompt 即可
1.5B 信息提取	F1=0.784, 值匹配 83%	0.92-0.95	200 边界标注	✅ ROI 最高
1.5B 工具选择	Top1=92%	95-97%	50 边界标注	✅ 数据量小
0.5B 全部	不可用	不可预期	—	❌ 放弃

决策逻辑：

• 3B 不改：96% Top1、100% 值匹配，天花板够高，SFT 的边际收益几乎为零。问题在 prompt 层面（多选倾向加一句"只选 1 个"即可）
• 1.5B 是甜点：精度接近 3B 但显存省 2.87G（5.75G → 2.88G）。当前 83% 值匹配的差距主要集中在"空 Schema 填充"——LLM 对不该输出的意图硬塞了参数。这类错误模式固定、边界清晰，200 条标注数据即可覆盖
• 0.5B 放弃：基础语义理解不够，SFT 无法弥补底层能力缺失

LoRA 参数：1.5B rank=8 alpha=16 ≈2M 参数 ≈8MB 适配器，训练约 20min。

SFT 数据构造方案

如果决定对 1.5B 做 SFT，数据配方如下：

1. SFT 指令微调：~800 条（200 边界标注 + 500 LLM 蒸馏 + 50 真实日志）
   • 200 条边界标注：从第六篇的错误分析中挑出"空 Schema 填充"“字段名拼错”"误提取不存在的字段"三类 case，人工写标准输出
   • 500 条 LLM 蒸馏：用 Qwen2.5-3B 批量生成（输入→标准输出），筛掉质量差的。成本 ≈ 3B API 调用 500 次，几毛钱
   • 50 条真实日志：线上人工审核过的正确 case，保底不漂移
2. DPO 偏好对齐：~100 对（进阶，SFT 后再做），同一输入给正确输出和典型错误输出做对比
3. RLAIF 规则奖励：可选，但 RL 训练不稳定，不推荐在当前阶段引入

---

部署矩阵

方案	配置	工具选择	信息提取	显存
⭐ 最佳单模型	Qwen2.5-3B GPU	96%	100%	5.75G
轻量方案	Qwen2.5-1.5B GPU	92%	83%	2.88G
极致精度	Qwen3-1.7B + 1.5B	92%	100%	6.1G
CPU 兜底	Qwen2.5-0.5B	58%	70%	2.59G