选模型不是找"最强"的那个，是找"刚好够用且最省资源"的那个。
为什么要做这么细的对比？
两个延迟敏感路径：工具选择要求 <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，数据配方如下：
- SFT 指令微调 ：~800 条（200 边界标注 + 500 LLM 蒸馏 + 50 真实日志）
- 200 条边界标注：从第六篇的错误分析中挑出"空 Schema 填充""字段名拼错""误提取不存在的字段"三类 case，人工写标准输出
- 500 条 LLM 蒸馏：用 Qwen2.5-3B 批量生成（输入→标准输出），筛掉质量差的。成本 ≈ 3B API 调用 500 次，几毛钱
- 50 条真实日志：线上人工审核过的正确 case，保底不漂移
- DPO 偏好对齐：~100 对（进阶，SFT 后再做），同一输入给正确输出和典型错误输出做对比
- 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 |