2026年7月27日作者：Lei阅读 --

主模型明明是 Fable 5，账单里为什么冒出 Haiku 4.5？

这不是投机解码。从 Claude Code 官方文档找到 Haiku 后台调用的直接证据，再借 RouteLLM、FrugalGPT 与 Leviathan/Chen 的投机采样论文，把"小模型替大模型干活"拆成应用层分派、服务层路由、解码层投机三层，并给出一条判别原则：看它会不会以自己的名义出现在你的账单里。

AI AI Infra LLM Serving

你把 Claude Code 的模型切到 Fable 5——那个 $10/$ 50、Mythos 级的旗舰——干了一下午活。打开用量统计，主模型的消耗都对得上，但列表里赫然多了一行：claude-haiku-4-5。你从没选过它。第一反应很自然：是不是 Claude 内部判断”这个场景简单”，偷偷换了小模型？或者，这就是传说中的投机解码——小模型起草、大模型验证？

先给答案，再展开：

这是应用层的任务分派：Claude Code 自己会把会话摘要、命令处理这类后台杂活交给 Haiku 槽位，官方文档写得明明白白。
这一定不是投机解码：投机解码发生在推理引擎内部，输出分布在数学上严格等于目标模型，token 计费全部归属目标模型——它永远不会以另一个模型的名义出现在统计里。
这两件事背后，是”小模型替大模型干活”的三个不同层次。分清它们，只需要问一个问题：它会不会以自己的名义出现在你的账单里？

这篇文章就沿这条线走：先用官方文档还原现场，再把三层地图铺开，最后回到投机解码的数学，解释为什么它天然”隐身”。

一、现场还原：Haiku 是谁叫来的

不用猜，Claude Code 的文档里有直接证据。

证据一：后台功能明确用 token。 官方成本文档的 Background token usage 一节写道，即使你不操作，Claude Code 也在消耗 token：

Conversation summarization: Background jobs that summarize previous conversations for the claude --resume feature. Command processing: Some commands like /usage may generate requests to check status.

也就是说：为 --resume 准备的会话摘要、/usage 这类命令处理，都是后台悄悄发出的独立请求。文档同时给了量级：这类后台消耗通常每个会话不到 $0.04。

证据二：这些后台请求走的就是 Haiku 槽位。 模型配置文档对环境变量 ANTHROPIC_DEFAULT_HAIKU_MODEL 的定义是：

The model to use for haiku, or background functionality.

这个槽位当前解析到 Haiku 4.5。换句话说，你选 Fable 5 只是选了主线程的模型；围绕主线程的脚手架工作——摘要、状态检查、部分子代理（如果 subagent/skill 配了 model: haiku）——由 Haiku 承担，并且作为独立的 API 调用独立计费、独立出现在统计里。

所以你看到的 Haiku 4.5 不是”场景判断后的降级”，更不是解码加速的副产品，而是一个分工明确的双模型架构：贵的模型回答你，便宜的模型伺候会话本身。

顺带一句：你的主回答不会被静默换成 Haiku。Claude Code 里主模型的变更路径都是显式的——/model 手动切换、配置了 fallback 链且触发时有通知。唯一一个”服务端替你换模型”的真实案例反倒值得单独说：按 Anthropic 官方发布说明，Fable 5 在网络安全、生物化学等高风险请求上会由分类器判定并自动回退到 Claude Opus 4.8（官方称超过 95% 的会话完全不触发回退）。注意方向：回退到的是另一个旗舰，不是 Haiku——它是安全设计，不是省钱设计。

二、三层地图：“小模型替大模型干活”的三种长相

把视野拉开，你会发现”小模型辅助大模型”这个想法在整个技术栈里出现了三次，但出现在完全不同的层，解决完全不同的瓶颈。

flowchart TB
    subgraph L1["应用层 · 任务分派 (Delegation)"]
        A1["主任务 → Fable 5"]
        A2["会话摘要 / 命令处理 / 轻量子代理 → Haiku 4.5"]
    end
    subgraph L2["服务层 · 查询路由 (Routing)"]
        B1["路由器判断 query 难度"]
        B2["难 → 强模型"]
        B3["易 → 弱模型"]
        B1 --> B2
        B1 --> B3
    end
    subgraph L3["解码层 · 投机解码 (Speculative Decoding)"]
        C1["draft 模型起草 γ 个 token"]
        C2["目标模型一次前向并行验证"]
        C1 --> C2
        C2 -->|"接受/拒绝重采样"| C1
    end
    L1 -.->|"两次独立调用，各自计费"| BILL["你的账单"]
    L2 -.->|"一次调用，但回答者可能不同"| BILL
    L3 -.->|"引擎内部，只有目标模型出现"| BILL

第 1 层：应用层任务分派——“让实习生订会议室”

这就是 Claude Code 在做的事。系统里存在多种性质不同的任务：回答你的问题需要旗舰模型，但”把这段对话总结成 200 字的标题”用 Haiku 绰绰有余。应用开发者按任务类型静态分工，不同任务发不同的 API 请求。

谁做决定：应用开发者（写死在代码里的分工）。
输出归属：各归各，两个模型各自完成各自的任务。
账单可见性：完全可见，每个模型独立列出——这正是你看到 Haiku 4.5 的原因。

第 2 层：服务层查询路由——“分诊台决定你挂专家号还是普通号”

再进一步：如果同一类任务（比如”回答用户问题”）也按难度分流呢？这就是模型路由（model routing）和级联（cascade）这一支研究：

FrugalGPT (arXiv:2305.05176) 提出 LLM 级联：先让便宜模型答，用一个打分器判断答案是否可靠，不可靠再升级到贵模型，宣称在多个任务上以 2% 的成本逼近 GPT-4 的质量。
RouteLLM (arXiv:2406.18665) 用 Chatbot Arena 的人类偏好数据训练路由器，在保住约 95% GPT-4 质量的同时把成本降到 1/2 以下（细节我在《RouteLLM 深度解读》里拆过）。
Hybrid LLM (arXiv:2404.14618) 把”这条 query 交给小模型损失多少质量”建模成可学习的难度估计，按质量容忍度动态调阈值。
谁做决定：一个学出来的路由器，按 query 难度动态决定。
输出归属：真的来自不同模型——路由错了，质量就真的降了。这是它和第 1、3 层的本质区别：路由是拿质量换成本的赌注。
账单可见性：取决于服务商是否披露。诚实的路由系统会告诉你这条请求谁答的（Fable 5 的高风险回退就在系统响应里注明由 Opus 4.8 接管）。

第 3 层：解码层投机解码——“打字员先盲打，作者只管改”

最深的一层，也是最容易被误会的一层。投机解码不改变”谁来回答”，只改变”这个回答生成得多快”。

背景约束一句话讲完：自回归解码一次只出一个 token，每步都要把全部权重从显存搬进计算单元，瓶颈在内存带宽而不在算力（这条主线我在《Medusa 深读》里展开过）。既然搬一次权重的成本是固定的，那就想办法让每次搬运验证多个 token：

便宜的 draft 模型先串行猜 $\gamma$ 个 token（它小，猜得快）；
目标模型一次前向把这 $\gamma$ 个 token 并行验证；
对每个位置按概率 $\min\left(1, \frac{p(x)}{q(x)}\right)$ 接受（ $p$ 是目标模型分布， $q$ 是 draft 分布），第一个被拒绝的位置从残差分布 $\mathrm{norm}(\max(0, p - q))$ 重采样。

这套接受-拒绝规则是这层的灵魂。Leviathan et al. (arXiv:2211.17192) 和 DeepMind 的 Chen et al. (arXiv:2302.01318) 各自独立证明了同一件事：最终输出序列的分布与目标模型单独采样严格相同。不是近似相同，是逐 token 的分布恒等。如果 draft 平均接受率为 $\alpha$ ，每轮期望产出

\mathbb{E}[\#\text{tokens}] = \frac{1 - \alpha^{\gamma+1}}{1 - \alpha}

个目标模型 token——加速比来自这里，质量一分不少。后续的 Medusa (arXiv:2401.10774) 干脆去掉独立 draft 模型、在目标模型上加解码头，EAGLE (arXiv:2401.15077) 在特征层做自回归起草，思路百变，但”目标模型验证、分布不变”这条底线没人敢动（想看全景可读综述 arXiv:2401.07851）。

谁做决定：推理引擎，逐 token 决定。
输出归属：全部归属目标模型——被接受的 token 在统计意义上”就是”目标模型自己会生成的 token。
账单可见性：零。这是下一节的重点。

三、为什么投机解码永远不会出现在你的账单里

两个理由，一个数学的，一个工程的。

数学上，没有”Haiku 的 token”这回事。 接受-拒绝规则保证输出分布恒等于目标模型分布，所以从产出看，draft 模型没有贡献任何”属于自己的” token——它贡献的是猜测，猜测被目标模型验证后才成为输出，验证不过就被扔掉重采样。把这些 token 记在 draft 模型名下，就像把作者改定的稿子记在打字员名下。

工程上，draft 模型是服务端的私有实现细节。 它跑在推理引擎内部（同一批 GPU、同一个 serving 进程），对 API 层不可见。你按目标模型的牌价为输出 token 付费；服务商用投机解码省下的是自己的 GPU 时间，赚的是吞吐和延迟，这笔账不经过你。API 合同里根本没有让 draft 模型露面的接口。

由此得到一条干净的判别原则：

用量统计里能看到另一个模型的独立条目，当且仅当存在一次显式的、以该模型为目标的 API 调用。 投机解码不产生这样的调用，所以你看到的 Haiku 4.5 必然来自任务分派（或你自己配置的路由/子代理）。

反过来这条原则也能当排查清单用。统计里出现意外模型时按序检查：

检查项	对应机制	去哪确认
1. 后台功能消耗（摘要、命令处理）	应用层分派	金额是否在 ~$0.04/会话量级
2. subagent / skill / 定时任务配的 `model`	应用层分派	agent frontmatter、`CLAUDE_CODE_SUBAGENT_MODEL`
3. fallback 模型链	显式配置的降级	`fallbackModel` 设置、切换时的通知
4. 服务端安全回退	服务层路由	系统响应里的接管说明（如 Fable 5 → Opus 4.8）
5. 投机解码	——不可能是它	无需检查

四、三层对照表：一眼分清

	应用层 · 任务分派	服务层 · 查询路由	解码层 · 投机解码
解决的瓶颈	杂活不配用旗舰（成本）	简单 query 不配用旗舰（成本）	解码受限于内存带宽（延迟/吞吐）
决策者与时机	开发者，按任务类型静态分工	路由器，按 query 难度动态分流	推理引擎，逐 token 验证
输出质量	各任务各自负责	可能下降（路由错了是真的错）	严格不变（分布恒等有证明）
对用户可见	可见：独立调用独立计费	应当可见（取决于披露）	不可见：服务端实现细节
代表	Claude Code 后台 Haiku	RouteLLM、FrugalGPT、Hybrid LLM	Leviathan/Chen、Medusa、EAGLE

这张表值得带走的一个灰度判断：三层并不互斥，一个成熟的 serving 栈往往三层全开——应用层把杂活分给小模型，服务层把简单请求路由出去，解码层再给每个模型加投机加速。你账单上看得见前两层，永远看不见第三层。

五、给怀疑者：会不会是”偷偷降级”？

一个合理的怀疑：既然服务商有动机省钱，怎么确定主回答没被偷偷换成 Haiku？

三个可核查的回应：

计费透明性本身就是证据。 如果要偷偷降级，最不该做的事就是把 Haiku 4.5 单独列在你的用量统计里。独立条目恰恰说明这是光明正大的分工，而不是伪装。
降级藏不住质量差异。 Fable 5 和 Haiku 4.5 的能力差距（以及 Fable 5 强制开启的 extended thinking 行为特征）在复杂任务上肉眼可辨。真被换了模型，你先感知到的是回答变笨，而不是账单变化。
投机解码不是降级通道。 就算服务端对 Fable 5 用了投机解码（用不用是它的自由），Leviathan/Chen 的分布恒等定理保证你拿到的仍是 Fable 5 的输出分布。投机解码在设计上就不可能被用来”以小充大”——draft 猜得再多，目标模型不点头一个 token 也出不去。

结语：带走一个心智模型

回到开头的问题——“是 Claude 内部判断场景用了 Haiku 么？是投机解码么？“现在可以精确作答：

是任务分派：Claude Code 把伺候会话的杂活（摘要、命令处理）交给 Haiku 槽位，独立调用、独立计费，官方文档有明文。
不是场景路由：你的主回答始终由你选的模型生成，模型变更都有显式通知（唯一的服务端例外是 Fable 5 高风险回退，方向是更强的 Opus 4.8）。
更不是投机解码：它蜷在解码层，输出分布恒等于目标模型，token 全部计入目标模型，在账单上天然隐身。

下次在任何产品的用量统计里看到意外的模型名，都可以套用这条原则：看得见的，是显式调用（分派或路由）；看不见的，才轮到解码层的魔法。

参考来源

工程实践

Claude Code 官方文档 · Manage costs effectively — Background token usage
Claude Code 官方文档 · Model configuration — ANTHROPIC_DEFAULT_HAIKU_MODEL
Anthropic · Introducing Claude Fable 5 and Claude Mythos 5

arXiv 论文

投机解码：Leviathan, Kalman & Matias, Fast Inference from Transformers via Speculative Decoding — arXiv:2211.17192
投机采样：Chen et al., Accelerating Large Language Model Decoding with Speculative Sampling — arXiv:2302.01318
Medusa：Cai et al., Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads — arXiv:2401.10774
EAGLE：Li et al., EAGLE: Speculative Sampling Requires Rethinking Feature Uncertainty — arXiv:2401.15077
投机解码综述：Xia et al., Unlocking Efficiency in Large Language Model Inference: A Comprehensive Survey of Speculative Decoding — arXiv:2401.07851
模型路由：Ong et al., RouteLLM: Learning to Route LLMs with Preference Data — arXiv:2406.18665
LLM 级联：Chen, Zaharia & Zou, FrugalGPT: How to Use Large Language Models While Reducing Cost and Improving Performance — arXiv:2305.05176
质量感知路由：Ding et al., Hybrid LLM: Cost-Efficient and Quality-Aware Query Routing — arXiv:2404.14618

站内相关