所有任务都调最大的模型，账单翻三倍——这是成本问题，但解法不是"统一换小模型"，而是先把任务按能力需求拆开。小模型能省下的钱，取决于任务对知识广度、推理深度、格式稳定性的要求落在哪一档；搞错档位，省下的成本会以返工和人工复核的形式还回去。
1. 能力需求的三维拆解
| 维度 | 小模型的位置 | 大模型的位置 | 判断信号 |
|---|---|---|---|
| 知识广度 | 训练语料覆盖窄，冷门实体易错 | 覆盖面宽，长尾实体可答 | 任务是否需要"没见过也知道" |
| 推理深度 | 单步/两步可靠，多步易断链 | 多步链式稳定 | 是否需要中间推导 |
| 格式稳定性 | 指令跟随好、结构输出可靠（微调后更强） | 零样本也稳 | 是否需要严格 schema |
关键差异不在"聪明程度"，而在这三个维度的分布：分类、抽取、格式化这类任务只吃第三维，小模型往往够用；多步推理和长尾知识吃前两维，小模型会稳定地错。
按 1B–8B 量级开源模型核对：格式稳定性已优于早期版本，短板集中在多步推理与长上下文。
2. 能胜任与失效的任务形态
| 任务形态 | 小模型表现 | 说明 |
|---|---|---|
| 分类（含多标签） | 好 | 标签集固定、语义边界清晰时接近大模型 |
| 结构化抽取 | 好（配 schema 约束） | 字段少、文本规整时稳定 |
| 改写/润色 | 中偏好 | 风格约束越具体越稳 |
| 格式化转换 | 好 | 规则明确，本质是模式匹配 |
| 短答问答 | 中 | 事实性问题受知识广度限制 |
| 多步推理 | 差 | 链一长就丢中间状态 |
| 长上下文归纳 | 差 | 有效注意力覆盖不足 |
| 边界判断/歧义裁决 | 差 | 缺"知道该说不确定"的能力 |
最后一行最易被低估：小模型往往给确定答案而非承认模糊，在审核、合规、风控里比错误本身更贵。
3. 分级路由与升级判据
先小后大是通用做法，但"什么时候升级"必须有可执行判据，否则升级条件会退化成"看着不对就重试"。
routing:
default: small
escalate_if:
- schema_invalid: true # 结构化输出解析失败
- self_confidence: "<0.6" # 模型自评或 logprob 阈值（按实现核对）
- output_truncated: true # 触及 max_tokens
- task_class: [multi_hop, long_context_summary, ambiguity]
max_escalations: 1 # 只升一级，避免无限重试放大成本
log: [task_class, model, escalated, latency_ms, cost]
三个易错点：升级判据必须是可观测的（解析失败、长度截断这类硬信号优于"感觉不好"）；升级次数要设上限；升级率本身是核心指标——若超过两三成，说明路由规则或任务分类有问题，而不是小模型不行。
4. 蒸馏与微调的成本结构
| 路径 | 数据需求 | 评估成本 | 维护成本 | 适用 |
|---|---|---|---|---|
| 提示工程 + 小模型 | 无 | 低 | 低 | 先试这个 |
| 蒸馏（大模型造数据） | 数千至数万条 | 中 | 中（教师模型变更需重蒸） | 任务形态稳定、量大 |
| 监督微调 | 千级标注样本 | 中高 | 中高（需版本管理） | 有明确格式/风格要求 |
| 继续预训练 | 领域语料 | 高 | 高 | 领域词汇差异极大时 |
顺序建议：提示 → 蒸馏 → 微调。多数团队跳过前两步直接微调，结果花了两周标注，收益不如改提示加 schema 约束。
蒸馏的隐性成本是教师依赖：教师模型升级或下线，数据集与效果都要重做，这笔账要提前算。
5. 上下文长度的真实约束
| 口径 | 含义 | 工程含义 |
|---|---|---|
| 窗口大小 | 模型能接收的 token 上限 | 只是准入条件 |
| 有效注意力 | 中段信息被利用的程度 | 决定答案质量 |
| 成本随长度 | 输入 token 线性计费 | 长上下文直接抬单价 |
小模型的"长上下文"标注往往只是窗口扩容。实际表现是中段信息被忽略（首尾效应明显），所以把 3 万字文档整篇塞进去归纳，不如先分段抽取再汇总——这条在小模型上不是优化，是必需。
6. 延迟与成本的量级差
| 指标 | 小模型（1B–8B） | 大模型（旗舰） | 备注 |
|---|---|---|---|
| 首 token 延迟 | 数十毫秒量级 | 数百毫秒至秒级 | 受并发与硬件影响 |
| 单请求成本 | 低一到两个数量级 | 基准 | 按供应商定价核对 |
| 吞吐 | 单卡可承载较高 QPS | 需多卡或配额 | 自托管时差异更明显 |
量级差不是"省一点"，而是能否支撑某些产品形态：实时补全、逐条打标、批量清洗里，延迟与单价直接决定方案是否成立。
7. 质量下降的隐性成本
| 成本项 | 表现 | 何时超过模型账单差 |
|---|---|---|
| 返工 | 输出需重跑或人工改写 | 返工率 > 成本差比例时 |
| 人工复核 | 每条都要看一遍 | 复核工时单价高时 |
| 用户信任 | 错误率上升导致弃用 | 面向终端用户的场景 |
| 事故成本 | 错误进入下游系统 | 有资损/合规后果时 |
判据很直接：把返工与复核工时折成钱，和账单差对比。若返工率 15%、单条返工成本等于 5 次调用成本，小模型的价格优势已经被吃掉。
8. 用任务级成功率做选择口径
单步准确率会骗人。三步串联，每步 90%，端到端只有约 73%。
# 串联衰减：steps 越多，端到端成功率下降越快
def chain_success(p_step, steps):
return p_step ** steps
for p in (0.99, 0.95, 0.90, 0.80):
print(p, [round(chain_success(p, n), 2) for n in (1, 3, 5, 10)])
# 0.9 → 0.9 / 0.73 / 0.59 / 0.35
所以选型口径应当是任务级成功率（端到端正确），而不是"抽 50 条看单步准确率"。同一个模型在单步任务上 95%、在五步流程上可能只有 60%——后者才决定能不能用。
这也解释了为什么"分级路由"更适合放在步骤级：把多步流程拆开，简单步骤交小模型，难的步骤才升级。
9. 混合策略：起草 + 审校
比"整任务二选一"更省的做法是分工：小模型出草稿，大模型只做校验或修正。
| 模式 | 成本 | 质量 | 适用 |
|---|---|---|---|
| 小模型全包 | 最低 | 中低 | 容错高、可后验 |
| 混合（起草+审校） | 中 | 接近大模型 | 输出可被快速核验 |
| 大模型全包 | 最高 | 高 | 质量不可妥协 |
pipeline:
draft: {model: small, max_tokens: 800, schema: strict}
verify: {model: large, mode: critique_and_fix, only_if: [schema_ok, low_confidence]}
accept: {rule: "no_diff_after_verify"} # 审校无改动即通过，省一次大模型调用
fallback: human_review
审校的 prompt 要只允许改错，不允许重写，否则大模型会把小模型的风格整体换掉，成本等于全包。
10. 本地部署小模型的适用面
| 场景 | 适配度 | 原因 |
|---|---|---|
| 隐私敏感（数据不出内网） | 高 | 无外部调用 |
| 离线/边缘环境 | 高 | 无网络依赖 |
| 延迟敏感的交互 | 中高 | 省掉网络往返，但受本地算力限制 |
| 高并发批量打标 | 中 | 单位成本低，但需自建吞吐 |
| 需要最新知识 | 低 | 权重静态，知识滞后 |
| 复杂推理 | 低 | 能力天花板明确 |
本地部署的真实成本在运维：量化、显存预算、批处理调度、版本升级，这些都要人。调用 API 时这些是供应商的事。
# 本地部署小模型：先量吞吐，再谈替换
vllm serve ./small-model-4b --max-model-len 8192 \
--gpu-memory-utilization 0.85 --max-num-seqs 64
# 要看的三个数：tokens/s、P99 延迟、显存余量（参数名按框架版本核对）
11. 评估方法：按任务类型分组比
同一评测集上比较不同规模模型，必须分组，否则平均值会掩盖结论。
# 分组评测：每类任务单独出分，附样本量
for task in classify extract rewrite multihop; do
bench --model "$SMALL" --set "eval/$task.jsonl" --report "out/small-$task.json"
bench --model "$LARGE" --set "eval/$task.jsonl" --report "out/large-$task.json"
done
# 汇总为：任务类型 × 模型 → 端到端成功率 + 单条成本，再看谁在哪一档可用
| 任务类型 | 小模型 | 大模型 | 结论 |
|---|---|---|---|
| 分类 | 接近 | 基准 | 可全面下放 |
| 抽取 | 略低（长文本下降明显） | 基准 | 加 schema 约束后可下放 |
| 改写 | 中等差距 | 基准 | 分场景 |
| 多步推理 | 明显低 | 基准 | 不下放 |
结论要落到**"哪类任务下放、哪类保留"**，而不是"小模型行不行"这种整体判断。
12. 排错
| 现象 | 判断 | 处理 |
|---|---|---|
| 账单没降 | 升级率过高，请求又回到大模型 | 看升级率指标，先修任务分类 |
| 小模型结构化输出常失败 | 缺 schema 约束或未用函数调用 | 加约束解码/函数调用，别靠提示词 |
| 长文档归纳漏中段 | 有效注意力不足 | 分段抽取 + 汇总，而非整篇塞入 |
| 单步测得好、上线差 | 口径错，看的是单步准确率 | 改测端到端任务成功率 |
| 微调后不如提示 | 数据量或分布不匹配 | 回退提示方案，先补数据再训 |
| 本地吞吐不够 | 未做批处理调度 | 上连续批处理与量化 |
13. 边界
| 场景 | 判断依据 | 更合适的做法 |
|---|---|---|
| 任务本身是多步推理 | 端到端成功率随步数衰减 | 用大模型，或拆成步骤分别路由 |
| 需求量极小 | 成本差绝对值很小 | 直接用大模型，省掉工程成本 |
| 质量不可妥协 | 错误有资损/合规后果 | 大模型 + 人工复核 |
| 知识更新极快 | 权重知识滞后 | 检索增强，而不是换更大的模型 |
| 已有稳定提示词流程 | 迁移风险高于收益 | 保持现状，只对新任务分级 |
| 团队无评估能力 | 无法判断下放是否安全 | 先建评测集，再谈降本 |
一句话选择：成本差只在"任务形态简单 + 量大 + 可后验"三条件同时成立时才拿得到；缺一条，省下的钱都会被返工吃掉。
14. 自测
- 小模型与大模型的差异，应该按哪三个维度拆，为什么不是"聪明程度"？
- "边界判断"类任务为什么不适合下放，代价在哪？
- 分级路由里最该被监控的指标是什么，它异常说明什么？
- 三步流程每步 90%，端到端是多少，这个数字改变什么决策？
- 混合策略里，审校环节最容易犯的错是什么？
- 什么情况下"需求量极小"会让小模型方案不划算？