1. 这波降价到底降了多少为什么不是一次普通小促销下午看到 Anthropic 的模型更新公告Haiku 5.5 正式上线输入和输出价格比上一代直接腰斩。说实话这几年各家发新模型我基本都麻木了跑分涨几个点已经很难刺激到我。但这次不一样——不是能力数字又大了多少而是价格数字一变很多业务的算账逻辑跟着变。Haiku 系列在 Claude 家族里从来都是跑量担当主打低延迟、低成本、高并发专干生产环境里的高频脏活。5.5 把每百万 token 的输入价压到 0.5 美元、输出价压到 2.5 美元缓存命中再打九折批量任务还能再对半折。这个价位下以前那些算了算不划算的用法突然就成立了。如果你正在做 AI 应用选型、在优化 API 账单或者纠结要不要把一部分 Sonnet 流量切到轻量模型这篇文章按我的实操经验把定价、能力边界、迁移步骤和踩过的坑一次讲明白。1.1 小模型的成本账从舍不得用到随便用先说一个很多人没意识到的点大模型的算力成本这几年一直在降但真正影响业务决策的从来不是单次调用贵不贵而是单价乘以调用量这条总账线。Haiku 5.5 的官方定价是输入 0.5 美元每百万 token、输出 2.5 美元每百万 token。上一代 Haiku 5 是 1 美元和 5 美元等于整体砍掉一半。别小看这 50%在规模效应下它改变的是产品能不能活的问题。举个例子。我想给每一条用户反馈都跑一遍情感分类每条平均输入 800 token。按上一代价格100 万条反馈光输入费用就是 800 美元换成 Haiku 5.5只要 400 美元。如果再配合批量接口还能再对半。这个量级一旦滚到千万、上亿条就是实打实能写进预算表的大钱。所以这次降价我第一反应不是又发模型了而是赶紧把手上几个跑 Sonnet 的批量任务重新拿出来算了一遍。1.2 价格表逐项拆解官方价格表拆开看主要计费项有五个我整理成了一张表计费项Haiku 5上一代Haiku 5.5降幅标准输入每百万 token$1.00$0.50-50%标准输出每百万 token$5.00$2.50-50%缓存命中输入每百万 token$0.10$0.05-90%批量输入每百万 token$0.50$0.25-50%批量输出每百万 token$2.50$1.25-50%这里最容易漏看的是缓存项。缓存命中输入只有标准输入的十分之一意味着凡是能复用的 prompt 前缀都应该想办法复用后面我会专门讲怎么把缓存命中率做上去。批量接口则是把不紧急的任务丢进队列官方承诺一定时间内返回结果但延迟不可控适合离线任务而不是实时交互。1.3 什么样的业务先受益降价之后最先受益的是这么几类业务高调用量的分类与抽取任务比如工单分类、评论打标、实体抽取Agent 内部的工具调用循环每轮都要付钱单价砍半等于循环成本砍半客服场景的实时意图识别和话术生成量大且对延迟敏感日志、事件流的在线分析以前舍不得让模型逐条看现在可以小团队的 MVP 验证预算有限低单价意味着可以多试几个方向。但也有业务不急着换比如复杂多步推理、长文创作、需要严格事实核查的场景这些还是得靠更高级别的模型。把 Haiku 5.5 当成便宜但不万能才不会在后面踩坑。2. 先别急着欢呼Haiku 5.5 的能力边界在哪里2.1 Haiku 不是弱化版 Sonnet是另一个物种我见过很多人把 Haiku 当小号 Sonnet用这是一个认知误区。Haiku 从架构设计上就不是为了追平 Sonnet而是为了在延迟和吞吐两个维度做到极致。Sonnet 的强项是深度推理、复杂指令拆解Haiku 的强项是快速响应、高并发、格式输出的一致性。它不是同一能力打折出售而是为不同场景做的两条产品线。说个实测体感。同样一段 2000 token 的输入Haiku 5.5 的首 token 延迟明显低于 Sonnet输出速度落在每秒 40 到 90 token 之间具体看服务器负载和上下文长度。这意味着做实时客服、流式输出、Agent 内部频繁调用工具时用户的体感完全不一样。我自己的项目里凡是需要快的地方全切 Haiku凡是需要准的地方才留给 Sonnet一开始这就不是替代关系。2.2 官方参数清单与我的实测体感把这次发布的规格整理如下指标Haiku 5.5上下文窗口200K token最大输出长度8192 token标准输入/输出$0.50 / $2.50 每百万 token缓存命中输入$0.05 每百万 token批量输入/输出$0.25 / $1.25 每百万 token知识截止时间较上一代有更新以官方文档为准核心能力文本生成、工具调用、结构化输出、代码生成上下文 200K 意味着一次可以塞进去接近 50 万汉字对绝大多数业务场景都够用。最大输出不用贪多实际业务里设 1024 到 2048 最常见输出长度拉满只会拖慢延迟、提高失败率。至于知识截止以官方文档为准别凭印象传话。2.3 别迷信榜单自己跑一轮评估模型发布都会配一堆基准测试数字但厂商挑的测评集和你的业务场景大概率不是一回事。我在任何模型上线后都会花半天时间做一件事从生产环境里抽 30 到 50 条真实样本组成一个固定评测集然后新旧模型分别跑一遍人工打分。重点看三样格式遵循率、工具调用参数正确率、幻觉率。为什么这么强调有个团队朋友把 Sonnet 的一批流量切到 Haiku 后官方跑分看着几乎没差但自家私有场景里工具调用参数格式的错误率从 2% 涨到了 7%。这种问题只有拿真实数据测才能暴露。评测集不用复杂几十条样本足够筛掉明显不合适的方案远比盯着一张榜单靠谱。3. 迁移实操从模型名到账单的全流程3.1 API 切换一行代码的事但不只是换名字Haiku 5.5 的接入方式跟同家族其他模型完全一致换模型名就能跑。代码层面真的很简单以 Python 为例from anthropic import Anthropic client Anthropic() response client.messages.create( modelclaude-haiku-5-5, # 从 claude-sonnet-5-x 改成这里 max_tokens1024, system你是一个工单分类助手仅输出 JSON。, messages[ {role: user, content: 客户反馈支付成功但订单状态一直未更新。} ], ) print(response.content[0].text)但真正要改的不是这行代码而是 prompt 里的期望值。注意小模型的指令遵循是有上限的别拿写给 Sonnet 的 prompt 原样丢给它。我现在的做法是给 Haiku 写系统提示词时把话说得特别死明确输出 schema给出两三个 in-context 示例禁止任何解释性输出只要求返回结果。看起来啰嗦但小模型对明确约束的响应要可靠得多。3.2 缓存与批量接口的正确打开方式既然缓存命中输入只要 0.05 美元这笔钱不捡白不捡。缓存命中前提是 token 前缀完全一致包括空白字符。所以正确姿势是把固定不变的 system 内容和对话历史前缀放进缓存块把动态字段用户输入、时间戳、会话 ID放在缓存块之外。代码里加上缓存标记system[ { type: text, text: 你是一个客服助手所有回答必须依据政策文档...此处为固定长文本, cache_control: {type: ephemeral}, } ]批量接口则是另一条省钱路子。把不要求实时返回的任务打包提交收到结果再轮询适合夜间离线清洗、批量打标。我手上有一个内容审核任务每天几十万条白天等不了结果全部走批量成本直接降到标准价的五折。3.3 一个客服场景的完整账单光说单价没有感觉我拿一个真实业务形态算一遍账。假设某个客服系统每天调用 10 万次每次请求平均输入 1500 token其中 1000 token 是固定的 system prompt 加历史前缀输出平均 200 token。一个月按 300 万次计算。先看完全不优化的情况。输入总量是 300 万乘以 1500 token等于 45 亿 token也就是 4500 个百万 token按 0.5 美元算输入费用 2250 美元。输出总量 300 万乘以 200等于 6 亿 token、600 个百万 token按 2.5 美元算输出费用 1500 美元。合计 3750 美元。如果把那 1000 token 的固定前缀做缓存假设命中率 80%那么 300 万次里 240 万次的 1000 token 走缓存价。此时新输入 token 变成 300 万乘以 500等于 1500 个百万 token费用 750 美元缓存 token 是 300 万乘以 1000等于 3000 个百万 token费用 150 美元输出还是 1500 美元。合计降到 2400 美元省了 36%。对照一下就更有概念了。同样流量跑上一代 Haiku 5不缓存不批量时是 7500 美元跑 Sonnet 级别输入按 3 美元、输出按 15 美元算直接飙到 2.25 万美元。Haiku 5.5 这 3750 美元等于给业务的模型预算直接换了档。4. 生产环境落地三类场景的真实姿势4.1 Agent 循环高频决策的成本底线Agent 类应用的成本大头从来不是单次调用而是循环次数。一个复杂任务往往要跑三到五轮工具调用每一轮都要把历史上下文重新塞回去token 越滚越大。Haiku 5.5 把单价砍半之后Agent 内循环的成本压力小了很多。我在一个信息整理 Agent 里做过估算单个任务平均输入 40K token、输出 2K token按新价格一次任务约 0.025 美元。跑十万次任务就是 2500 美元。同样流量切到 Sonnet成本直接翻到五倍以上。这个差距在规划阶段就能决定产品模式能不能成立。我的经验是把低风险的循环步骤放在 Haiku 上比如调用检索、整理草稿、格式转化把需要判断的最终决策交给 Sonnet按需升级而不是全程用贵模型。4.2 信息抽取与分类结构化输出才是主场小模型最擅长的事情是让人把话说明白、把格式定死之后的抽取分类任务。Haiku 5.5 支持工具调用和结构化输出我用强制工具参数的方式约束模型解析失败率能降到很低。resp client.messages.create( modelclaude-haiku-5-5, max_tokens512, tools[{ name: classify_ticket, description: 对工单进行分类, input_schema: { type: object, properties: { category: {type: string, enum: [login, payment, order, other]}, priority: {type: string, enum: [high, medium, low]}, summary: {type: string} }, required: [category, priority] } }], tool_choice{type: tool, name: classify_ticket}, messages[{role: user, content: 工单内容客户说登录后页面一直转圈无法加载订单列表。}] )生产里跑电商评论分类时我给自己的要求是宁可少输出也不能乱输出。工具强制输出比让模型自由生成 JSON 靠谱得多配合枚举值约束后处理基本不用兜底。同样的逻辑放在任何结构化任务上都成立。4.3 RAG 初筛便宜模型干粗活贵模型干细活RAG 场景里最常见的浪费是召回二十篇文档全塞给贵模型做总结。我的做法是把流程拆成两段先用 Haiku 5.5 对召回文档逐篇打相关性分输出 0 到 1 的分数再挑出得分最高的两三篇交给 Sonnet 做最终综合。Haiku 干这种粗活又快又便宜而且中间结果不需要给用户看。实测下来初筛阶段能省掉约八成流向贵模型的 token。召回的准确率没有明显下降因为第一段过滤考的是这篇文档和问题有没有关系这是小模型完全能胜任的判断。把粗活和小活摊给便宜模型把精活留给贵模型这是 RAG 成本优化最好上手的一招。5. 踩坑实录从 Sonnet 切到 Haiku 后最容易翻车的地方5.1 输出质量下降怎么定位先看任务类型再看 prompt切换后效果变差九成不是模型坏了而是提示词没有适配。我的排查顺序是固定套路先看格式层有没有按 schema 输出再看内容层分类对不对、有没有幻觉最后才看逻辑层复杂推理是不是跳步了。每一层对应不同的修法。格式层出问题大概率是约束给得不够加 schema、加枚举、加示例内容层出问题往往是上下文信息不足补背景文档或少样本示例逻辑层出问题那就是任务难度超出了小模型的能力老老实实升级模型。朋友公司有个支付风控的触发判断从 Sonnet 切到 Haiku 后准确率掉了不少排查下来发现 prompt 里全是如果不是 A 且不是 B 则拒绝这种复合否定句式Haiku 理解起来明显吃力。改成把条件枚举成白名单列表之后效果基本追平。5.2 缓存命中不了那些我不说你可能一直找不到的原因缓存是省钱利器但命中不了的时候特别难受。我踩过的高速缓存不命中原因有这么几类前缀里有动态字段比如时间戳、会话 ID 拼进了 system换行符或空格不一致肉眼看不见但 token 不认messages 列表顺序发生变化导致前缀被打断还有个别客户端框架自动注入字段把固定内容挤到了后面。排查方法很朴素把实际发送出去的请求体打出来和上一次做逐字节对比。多数时候一眼就能看到问题。另外官方对缓存有最小长度和有效期限制前缀太短不值得缓存有效期也就几分钟所以每次会话复用同一个长 system 前缀才是命中率高的前提。5.3 429 限流与重试策略几乎没有团队在切到 Haiku 后不撞 429 的原因很简单单价便宜了调用量自然翻倍限流阈值先顶不住。我的处理经验是三层防御第一层客户端配指数退避重试间隔从几百毫秒起步退避上限拉到几十秒第二层把非实时流量全部挪到批量接口跟实时请求抢配额是浪费第三层如果业务确实需要高并发再考虑申请更高配额而不是在代码里无限循环重试。有个容易被忽略的点重试本身也在烧钱。如果重试的是输出阶段失败请求的 token 可能已经计费。重试前一定要看错误码429 和 5xx 处理方式不同别一刀切。6. 关于选型我的几点私人经验6.1 别被单价迷惑要看综合成本单价便宜是好事但综合成本才是全部的账。综合成本等于 token 费用加上重试成本、后处理成本、人工兜底成本。我见过有人把全部流量切到便宜模型结果解析失败率升高后处理脚本越写越长人工二次处理量飙升总账反而更贵。正确的姿势是让便宜模型干便宜模型擅长的活而不是逼它在所有场景里顶上。6.2 灰度切换与影子评测我的习惯是不搞大爆炸式切换。先放 10% 流量出去同时开影子模式新旧模型并行跑输出都留档人工抽检一周。重点盯两个指标格式层的失败率以及内容层的二次转人工率。这两个数字没有明显恶化才逐步放大流量比例。这个流程看着慢但能避开很多上线后发现不对再回滚的狼狈。6.3 最后再分享一个小技巧给 Haiku 写系统提示词时我会在末尾固定加一句如果信息不足直接说不知道不要编造。小模型的幻觉比大模型好治一些但必须主动堵。另外把 prompt 版本号写在注释里模型一更新整个评测集重跑一遍比凭感觉调参高效得多。这些年换过好几次模型我最深的体会是当每百万 token 的价格从 1 美元变成 0.5 美元很多以前觉得成本不允许的想法就突然获得了活下来的资格。Haiku 5.5 这波降价真正的价值不在便宜本身而在于它把 AI 功能的准入门槛又往下拉了一截逼着我们重新审视手里的每个业务场景。