先交代一个前提：本文的价格是按 Haiku 档位上一代的公开定价推算的区间，不是我对 Claude Haiku 5.5 官方价目表的逐项核对。文中数字用来建立估算框架，下单前请对照控制台里的 Pricing 页面，把变量替换成实际值。算账的方法不会因为单价浮动而失效。
价格口径提醒：下文假设输入约 $1 / 百万 token，输出约 $5 / 百万 token。这是 Haiku 档位近期的常见量级，5.5 的实际单价可能上下浮动。如果官方价格与此相差超过 30%，请直接改后面脚本里的常量重算。
一、单价：先搞清楚四个计价项
Haiku 这类小模型的账单不止“输入 + 输出”两项。一次请求最多涉及四类 token，对应响应 usage 里的四个字段：
input_tokens：没命中缓存的普通输入，按基础输入价计费。output_tokens：模型生成的内容，单价通常是输入的 约 5 倍。cache_creation_input_tokens：首次写入缓存的部分，通常比基础输入价贵 约 25%（5 分钟 TTL 档）。cache_read_input_tokens：命中缓存的部分，通常只有基础输入价的 约 10%。
| 计价项 | 相对基础输入价 | 按假设单价折算（每百万 token） |
|---|---|---|
| 普通输入 | 1x | 约 $1 |
| 缓存写入（5 分钟） | 约 1.25x | 约 $1.25 |
| 缓存命中 | 约 0.1x | 约 $0.1 |
| 输出 | 约 5x | 约 $5 |
| Batch API（异步） | 输入输出均约 5 折 | 输入约 $0.5 / 输出约 $2.5 |
看这张表要抓住一点：输出才是大头。同样 1000 token，输出的钱够买 5000 token 的输入。所以先压输出长度，再去抠输入。
二、算一笔真实的账：10 万次分类请求
假设一个工单分类服务：system prompt 加分类规则共 约 3000 token，用户内容约 200 token，输出一个 JSON 标签，约 100 token。每天 10 万次调用。
- 不开缓存：输入 3200 × 10 万 = 3.2 亿 token，约 $320；输出 1000 万 token，约 $50。合计约 $370 / 天。
- 开缓存（命中率接近 100%）：3000 token 走缓存读取，约 $30；200 token 走普通输入，约 $20；输出仍约 $50。合计约 $100 / 天。
- 再叠加 Batch（可以接受小时级延迟时）：部分场景可以再降一截，但 Batch 与缓存的叠加规则要以官方文档为准，别默认能 1+1。
折到单次请求，开缓存后约 $0.001，也就是一千次才一块钱出头。这个量级下，模型费用基本不是瓶颈，工程时间和重试开销更值钱。
背景补充：缓存有最小长度门槛。Haiku 档位的最小可缓存 prompt 大致在 2048 到 4096 token 之间，具体看模型。prompt 太短时即使加了 cache_control 也不会生效，cache_creation_input_tokens 和 cache_read_input_tokens 会一直是 0。
三、缓存怎么接：三步跑通
- 把不变的内容放前面system prompt、分类规则、few-shot 示例放在请求最前，变化的用户输入放最后。缓存按前缀匹配，前缀里混进时间戳或请求 ID 就全部失效。
- 在最后一个静态块上加标记给该 content block 加
cache_control: {"type": "ephemeral"}，标记之前的内容都会被缓存。 - 用 usage 验证命中连发两次相同前缀的请求，第二次的
cache_read_input_tokens应当大于 0。仍然是 0 就先查前缀是否真的完全一致。
{
"model": "<以模型列表返回的 id 为准>",
"max_tokens": 150,
"system": [
{
"type": "text",
"text": "你是工单分类器。可选标签：billing / bug / feature / other ……（约 3000 token 的规则）",
"cache_control": {"type": "ephemeral"}
}
],
"messages": [
{"role": "user", "content": "我上个月被重复扣费了"}
]
}注意 max_tokens: 150。分类任务输出就几十个 token，把上限卡住，既防模型啰嗦，也防异常输出把账单拉高。
省钱小技巧：TTL 默认只有 5 分钟，流量稀疏的服务（比如每 10 分钟才来一单）会反复付缓存写入的溢价，反而比不开更贵。判断标准很简单：同一前缀每 5 分钟内至少被命中一次，才值得开缓存。
四、吞吐：别信宣传，自己测三个数
我这里不给具体的 tokens/s 数字，因为它随地区、时段、prompt 长度波动很大，引用别人的数字没意义。选型前建议自己测三个指标：
- TTFT（首 token 延迟）：决定对话类产品的体感。
- 输出速度（tokens/s）：决定长输出场景的总耗时。
- 429 出现频率：决定你能开多少并发。
import time, anthropic
client = anthropic.Anthropic()
MODEL = "<模型 id>"
IN_P, OUT_P = 1.0, 5.0 # 美元 / 百万 token，按官方价改
t0 = time.time()
first = None
with client.messages.stream(
model=MODEL, max_tokens=300,
messages=[{"role": "user", "content": "用 100 字介绍 HTTP/2"}],
) as s:
for _ in s.text_stream:
if first is None:
first = time.time() - t0
msg = s.get_final_message()
total = time.time() - t0
u = msg.usage
print("TTFT:", round(first, 2), "s")
print("out tok/s:", round(u.output_tokens / (total - first), 1))
print("cost $:", (u.input_tokens * IN_P + u.output_tokens * OUT_P) / 1e6)每个并发档位（比如 5、20、50）跑 100 次取 P50 和 P95。看 P95 而不是平均值，线上超时是被长尾拖垮的。
压测时如果遇到下面两种报错，处理方式不同：
429 rate_limit_error：触发了账号速率限制。读响应头里的retry-after，按它等待，并且把重试做成指数退避加抖动。529 overloaded_error：服务端过载，不是你的配额问题。别猛重试，退避并保留降级路径。
重试风暴是最常见的踩坑点：429 之后立刻无限重试，会让每个失败请求被反复计入速率窗口，越重试越被限。重试上限设 3 到 5 次，超过就走降级或入队。
五、够不够用：适合与不适合的边界
| 场景 | 建议 | 理由 |
|---|---|---|
| 文本分类、意图识别、路由 | 推荐 | 输出短、规则固定，缓存命中率高，成本最低 |
| 字段抽取、JSON 结构化输出 | 推荐 | 上线前用 100 条以上真实样本校验格式合规率 |
| 摘要、改写、翻译 | 推荐 | 输出偏长时要盯 max_tokens 和输出成本 |
| 简单工具调用（单步） | 可用 | 工具少、参数明确时稳定，工具超过 10 个要实测选错率 |
| 多步 Agent 规划、复杂代码重构 | 不建议 | 一步出错后面全错，返工成本高于省下的单价 |
| 法务、医疗、资金相关的最终判断 | 不建议 | 错误代价远大于 token 费用，应上大模型加人工复核 |
Haiku 单独扛
- 任务边界清晰、输出可被程序校验
- 日调用量大，单次预算压得很低
- 能接受个别样本需要重试或人工兜底
Haiku 前置 + 大模型兜底
- 输入复杂度参差不齐，难样本占 10% 到 30%
- Haiku 先处理，校验不过或置信度低再升级
- 整体成本通常仍远低于全量上大模型
我的判断：如果你的任务能被程序校验输出（JSON schema、枚举标签、正则），直接用 Haiku；如果输出只能靠人读才知道对不对，就别只靠它，至少要有升级通道。
六、上线前的检查清单
- 用 100 到 200 条真实线上样本跑通，统计格式合规率和人工抽检准确率，不要只用自己编的样例。
- 把
usage四个字段全部落日志，按天汇总真实单次成本，对照上面的估算。 - 确认缓存命中率：
cache_read_input_tokens占总输入的比例低于 50% 时，回头查前缀是否被污染。 - 设置
max_tokens上限和月度预算告警，避免异常输入造成成本失控。 - 保留切换模型的开关，模型 id 放配置而不是写死在代码里。
总结一句：Haiku 5.5 这类小模型的价值在于把高频、简单、可校验的任务的单次成本压到千分之一美元量级。至于它在你的数据上够不够准，只有拿自己的样本测一轮才知道，别靠别人的评测分数下结论。
