1. 模型选型这件事为什么每次价格调整都值得重新算一遍做AI应用开发的同行应该都有体会模型选型从来不是一锤子买卖。每次API价格调整尤其是主力轻量模型出现大幅降价的时候之前算好的成本模型基本就作废了。我这次重新做选型核算起因就是Haiku 5.5这轮降价——幅度直接拉到90%这个数字放在任何一家云服务的定价史上都算得上激进。先把这个事情说清楚Haiku 5.5是某AI平台旗下的轻量级模型定位是快、便宜、够用主要面向高并发、低延迟、成本敏感的调用场景。这次降价之后它的输入输出Token单价降到了原来的十分之一左右。对于每天跑几十万甚至上百万次调用的业务来说这不是省点钱的问题而是直接决定了某些功能能不能从赔本赚吆喝变成有毛利可算。我自己的项目是一个内容处理类的工具核心链路里有两块调用一块是长文本的摘要和结构化提取另一块是短文本的分类和意图识别。之前这两块都混用同一个中档模型因为轻量模型在结构化输出上偶尔会翻车重试成本反而更高。但价格一变整个账本就得重算——不是简单地便宜了就换而是要算清楚降价之后轻量模型在哪些任务上已经够用且划算哪些任务仍然必须用中档甚至高档模型兜底。这篇文章就是把这轮重新选型和成本核算的完整过程拆开讲。适合谁看如果你正在做AI应用的成本优化、正在纠结模型分层策略、或者单纯想知道降价90%到底意味着什么下面的内容应该能直接拿去用。我会把核算表格、分层逻辑、实测踩坑都摆出来不玩虚的。2. 先把账算明白Token成本核算的底层逻辑2.1 Token计费的基本盘输入、输出、缓存三块很多人算成本只盯着每百万Token多少钱但实际账单出来往往对不上。原因是Token计费至少有三个维度输入Token、输出Token、以及缓存命中/写入的Token。这三块的单价完全不同输出通常比输入贵好几倍缓存命中则便宜到几乎可以忽略。以这次降价的Haiku 5.5为例降价后的价格结构大致是这样的具体数字以官方页面为准我这里用的是核算时的口径计费项降价前单价每百万Token降价后单价每百万Token降幅输入Token较高约为原来的1/10约90%输出Token较高约为原来的1/10约90%缓存写入中等同步下调约90%缓存命中极低进一步降低约90%这个表格里最关键的信息不是绝对数字而是输入和输出之间的倍率关系。假设输出单价是输入的5倍那么一个输入长、输出短的任务比如分类和一个输入短、输出长的任务比如生成成本结构完全不一样。降价90%对前者的影响远大于后者因为前者主要成本在输入侧。我踩过的第一个坑就在这里早期做核算时只按平均每次调用消耗多少Token估算结果实际账单比预估高了40%。后来拆开看才发现输出Token的占比被严重低估了——模型在结构化输出时经常多吐一些解释性文字这些全按输出计费。2.2 单次调用成本的计算公式把上面三块拼起来单次调用的成本公式是单次成本 输入Token数 × 输入单价 输出Token数 × 输出单价 缓存相关费用看起来简单但实操中有几个变量必须实测才能确定输入Token数不只是你的prompt长度还包括系统提示词、few-shot示例、历史对话。系统提示词如果写得很长每次调用都在重复计费。输出Token数模型的实际输出长度往往比预期长尤其是没有严格约束格式的时候。重试率如果模型输出格式不对需要重试重试的那次调用也是全额计费。轻量模型的重试率通常比中档模型高这是隐性成本。我建议的核算方法是先跑一批真实样本至少200条统计出输入、输出的Token分布取P50和P95两个值分别算。P50代表典型成本P95代表最坏情况成本。只算平均值会误导决策因为成本超支往往发生在长尾上。2.3 降价90%对不同任务类型的实际影响这里要泼一盆冷水降价90%不等于你的总成本降90%。总成本降多少取决于轻量模型能承接多少比例的任务。举个具体的例子。假设你原来所有任务都用中档模型单次成本是X。现在把其中60%的任务切给降价后的Haiku 5.5这60%的成本变成0.1X剩下40%仍是X。新的平均成本是新平均成本 0.6 × 0.1X 0.4 × X 0.06X 0.4X 0.46X也就是说即使降价90%如果只能切换60%的任务总成本也只降到原来的46%。要真正吃到降价红利核心工作是提高轻量模型的可承接比例而这靠的是任务拆分和输出约束不是单纯换个模型名。这个认知直接改变了我后面的选型策略不是选一个模型而是设计一套分层路由。3. 分层选型策略什么任务交给Haiku 5.5什么任务必须升级3.1 任务分层的第一原则按容错成本而不是任务难度划分很多人分层是按任务难度来的——简单的给轻量模型复杂的给高档模型。但实际操作中难度是个很模糊的概念。我后来改成按容错成本划分清晰得多。容错成本的意思是如果这个任务模型输出错了会造成多大损失损失包括重试成本、人工复核成本、以及错误结果带来的业务影响。按这个标准任务可以分成三档低容错成本输出错了重试一次就行或者有自动校验能兜住。典型如意图分类、标签提取、简单摘要。这类任务大胆交给Haiku 5.5。中容错成本输出错了需要人工介入但频率不高可以接受。典型如结构化数据提取、多轮对话中的信息抽取。这类任务可以交给Haiku 5.5但必须加校验和重试机制。高容错成本输出错了直接影响业务结果或者人工复核成本极高。典型如长文档的深度分析、需要多步推理的决策建议。这类任务保留中档或高档模型。我实测下来我自己的项目里低容错成本任务占了约70%中容错成本占20%高容错成本只占10%。这意味着理论上可以把90%的调用切到Haiku 5.5但实际因为中容错成本任务需要重试有效切换比例大概在75%到80%之间。3.2 实测对比Haiku 5.5在各类任务上的表现光算成本不够得看质量。我拿同一批测试集300条真实样本跑了Haiku 5.5和中档模型的对比结果如下任务类型样本数Haiku 5.5准确率中档模型准确率差距是否可切换短文本分类10096%97%1%可切换意图识别8093%95%2%可切换结构化提取6085%94%9%需加校验长文本摘要4088%93%5%可切换多步推理2072%91%19%不切换这张表是我这次核算里最有价值的东西。它清楚地告诉我分类和意图识别这类任务Haiku 5.5和中档模型的差距在2个百分点以内完全可以切换结构化提取差距9个点需要加一层格式校验和重试多步推理差距19个点坚决不切。注意这个准确率是在我的特定测试集上跑出来的你的任务分布不同结论可能不一样。强烈建议自己跑一遍再决策不要直接抄。3.3 路由层的设计怎么让请求自动落到合适的模型分层策略定下来之后落地靠的是路由层。我的做法是在调用入口加一个轻量级的规则引擎根据任务类型和输入特征决定用哪个模型。路由规则大致是这样的请求进来先打标签标签来自业务侧的显式声明比如调用方指定task_type。如果task_type属于可切换列表走Haiku 5.5。如果task_type属于需加校验列表走Haiku 5.5但输出必须过校验器校验失败则升级到中档模型重试。如果task_type属于不切换列表直接走中档模型。这个路由层本身不复杂几十行代码就能实现。关键是要把task_type的声明做规范不能让调用方随便传。我一开始没做约束结果有些调用方把复杂任务标成简单任务导致质量事故。后来改成白名单机制task_type只能从预定义列表里选问题就解决了。路由层还有一个隐藏收益它让成本变得可观测。每个task_type的调用量、Token消耗、重试率都能单独统计哪块成本高、哪块可以继续优化一目了然。4. 实操落地从核算到上线的完整流程4.1 第一步采集真实调用数据建立成本基线在动任何代码之前先花两三天采集真实调用数据。需要采集的字段包括task_type、输入Token数、输出Token数、使用的模型、是否重试、响应时间。采集方式很简单在现有的调用封装层加一段日志就行。关键是不要采样全量记录。因为成本核算对长尾很敏感采样容易漏掉高消耗的调用。采集周期建议至少覆盖一个完整的业务周期比如一周这样能捕捉到工作日和周末的差异。我采集了7天总共约12万次调用数据量足够做决策了。采集完之后按task_type分组统计算出每组的日均调用量、平均输入Token、平均输出Token、P95输入Token、P95输出Token、重试率。这张统计表就是成本基线后面所有优化都跟它对比。4.2 第二步用基线数据算清楚切换收益有了基线数据就可以算切换收益了。算法是原成本 Σ(task_type调用量 × (平均输入Token × 中档输入单价 平均输出Token × 中档输出单价)) 新成本 Σ(可切换task_type调用量 × (平均输入Token × Haiku输入单价 平均输出Token × Haiku输出单价)) Σ(不可切换task_type调用量 × 原单价) 重试成本重试成本要单独算因为Haiku 5.5在需加校验任务上的重试率比中档模型高。我实测下来结构化提取任务的重试率从3%升到了12%这部分额外成本必须计入。算完之后我得到一个关键数字切换后总成本降到原来的21%。这个数字比单纯降价90%听起来保守但它是真实的、可复现的。原因就是前面说的只有约75%的调用能真正切换加上重试成本最终降幅是79%而不是90%。提示如果你的业务里可切换任务占比更高降幅会更接近90%。反之如果复杂任务多降幅会小很多。所以核算一定要基于自己的数据。4.3 第三步灰度上线与质量监控算清楚收益之后不要一次性全量切换。我的做法是灰度先切10%的流量到Haiku 5.5观察一周没问题再切到50%再观察一周最后全量。灰度期间要盯的指标有三个质量指标准确率、重试率、校验失败率。任何一个指标恶化超过阈值就回滚。成本指标实际账单 vs 预估账单。差异超过10%就要查原因。延迟指标Haiku 5.5的响应时间通常比中档模型快但如果路由层引入额外开销整体延迟可能反而上升。我灰度期间遇到过一次质量波动某个task_type的校验失败率突然从5%跳到18%。排查发现是那批输入里有一类特殊格式Haiku 5.5处理不好。解决办法是在路由规则里加了一条前置判断遇到这类格式直接走中档模型。这种问题只有灰度才能发现全量切换就晚了。4.4 第四步建立持续的成本监控看板切换完成不是终点。模型价格会变、业务量会变、任务分布也会变成本核算必须持续做。我搭了一个简单的监控看板每天更新几个核心数字总调用量、各模型调用占比、总成本、单次平均成本、重试率。看板不复杂但能让我在成本异常时第一时间发现。看板里我特别关注一个指标单次平均成本的变化趋势。如果它突然上升通常意味着任务分布变了比如复杂任务占比增加或者某个task_type的重试率上升了。这两个原因对应的处理方式完全不同需要进一步下钻分析。5. 常见问题与排查技巧实录5.1 成本核算类问题问题一预估成本和实际账单对不上差20%以上。排查思路先看是不是漏算了缓存费用。缓存写入和命中的单价虽然低但量大时也会累积。再看是不是漏算了重试调用。最后检查Token计数口径——有些平台的Token计数和你的估算方式不一样比如对特殊字符的处理。我的经验是预估和实际差异在10%以内算正常超过15%一定要查。我遇到过一次差异25%最后发现是系统提示词被重复计入了——每次调用都带上了完整的系统提示词而我在估算时只算了用户输入部分。问题二降价后总成本没降多少。这通常是因为可切换任务占比低。解决办法不是硬切而是优化任务拆分。比如把一个复杂任务拆成提取推理两步提取部分交给Haiku 5.5推理部分交给中档模型。这样能提高轻量模型的承接比例。我试过把一个长文档分析任务拆成分段摘要Haiku 汇总推理中档成本降了60%质量几乎没损失。5.2 质量类问题问题三Haiku 5.5在结构化输出上格式不稳定。这是最常见的坑。解决办法有三层第一层是在prompt里给严格的格式示例第二层是加输出校验器格式不对就重试第三层是重试两次仍失败就升级到中档模型。我实测下来加了这三层之后结构化提取的有效成功率从85%提升到了97%接近中档模型的水平。代价是重试成本但算总账仍然划算。问题四某些输入类型上Haiku 5.5表现明显差。不同模型对输入类型的敏感度不一样。我遇到的是超长输入超过8000 Token时Haiku 5.5的质量下降明显。解决办法是在路由层加输入长度判断超过阈值直接走中档模型。这个阈值需要自己测。我的做法是拿一批不同长度的输入跑对比找到质量开始明显下降的拐点把阈值设在拐点之前。5.3 速查表问题现象可能原因排查动作解决方向成本预估偏差大漏算缓存/重试/系统提示词逐项核对计费口径补全核算公式总成本降幅小可切换任务占比低统计各task_type占比拆分任务提高承接率格式不稳定prompt约束不足检查输出校验器加校验重试升级特定输入质量差模型对输入类型敏感分类型跑对比测试路由层加前置判断延迟上升路由层开销大测量路由耗时优化路由逻辑或缓存决策这些坑我基本都踩过一遍。最深的体会是模型选型不是选一个最好的而是设计一套最合适的组合。降价只是给了你重新组合的机会能不能吃到红利取决于你的工程能力。6. 几个容易被忽略的细节和我的实操心得6.1 系统提示词的长度直接决定成本下限这一点值得单独拎出来说。系统提示词每次调用都会重复计费如果你的系统提示词有2000 Token每天调用10万次那就是2亿Token的输入消耗。降价之后这部分成本虽然低了但绝对量仍然可观。我的优化做法是把系统提示词里每次都一样的部分和随任务变化的部分拆开。固定部分尽量精简能删的删能合并的合并。我把自己项目的系统提示词从1800 Token压到了600 Token光这一项就省了三分之二的输入成本。6.2 输出长度约束是最有效的省钱手段输出Token通常比输入贵所以控制输出长度是省钱的关键。方法是在prompt里明确要求只输出结果不要解释并且给出字数上限。我实测过加了输出约束之后平均输出Token从320降到了180降幅44%。而且质量没有下降因为那些被砍掉的都是冗余的解释性文字。6.3 缓存策略要跟着模型切换一起调整不同模型的缓存行为可能不一样。切换模型之后原来的缓存命中率可能下降。我切换后第一周就发现缓存命中率从35%掉到了22%原因是Haiku 5.5对某些输入的归一化处理和原模型不同。解决办法是重新设计缓存键把模型标识也纳入缓存键的一部分避免不同模型的缓存互相污染。同时针对Haiku 5.5的输入特征重新调优缓存策略命中率慢慢回到了30%以上。6.4 不要忽略小模型多次调用的组合有时候一次中档模型调用能完成的任务用两次Haiku 5.5调用也能完成而且总成本更低。比如一个需要提取判断的任务可以拆成两次调用第一次提取第二次判断。两次Haiku调用的成本可能只有一次中档调用的三分之一。但这种做法会增加延迟和工程复杂度适合对延迟不敏感、对成本敏感的场景。我自己的项目里批处理类的任务用了这个策略实时类的任务还是单次调用。6.5 价格会再变核算框架要能复用最后说一个心态层面的东西。这次Haiku 5.5降价90%下次可能别的模型降价或者涨价。重要的不是记住这次的具体数字而是建立一套能复用的核算框架。我的框架就是前面说的四步采集基线、算切换收益、灰度上线、持续监控。这套框架跟具体模型无关跟具体价格无关换任何模型都能用。下次价格再变我把新价格填进去半天就能算出新的选型方案。这套框架我用了大半年中间经历过两次价格调整每次都能快速响应。比起每次重新拍脑袋效率高太多了。如果你也在做类似的成本优化建议先把框架搭起来再谈具体选型。