用同一批工作分别在Sonnet 4.6和其他候选模型上跑了超过100个样本后，数据就比较好懂了。只要记录下每个任务消耗的总代币数、一次性解决率还有响应延迟，再把任务复杂度和总代币量画成一条曲线，就能找出性价比最高的那个模型。 为什么说Sonnet 4.6是个“大胃王”？原因其实很简单。单价便宜了40%，听起来是省钱了，但每次请求消耗的代币量往往翻了好几倍。这种增长不是魔术变的，而是模型变得更聪明了。更强的自适应推理能力会展开更多中间步骤来避免误解；上下文保留能力变强让对话能承载更多历史信息；调用浏览器和函数时又会产生一堆日志和状态描述。这些原本隐形的思考过程全都转化成了实打实的流量。 在实际落地的时候要算账：总成本是（系统提示+历史上下文+中间思考+工具调用日志+最终回答）的总代币量乘以单价。如果单价降低40%，但每次请求的代币量从2千涨成了6千，那成本其实是从2元变成了6元乘以0.6，反而涨了差不多80%。有的报告说在扩展推理的场景下，消耗能达到4.5版的近4倍。 性能提升和代币消耗并不是线性的关系。如果只是简单的客服问答或者改改FAQ，这种短平快的活儿用Sonnet 4.6挺划算；可一旦任务变成了多步骤推导或者跨文档写报告，那长出来的显式思路和中间过程就会让利润和延迟的波动变大。还有一个常被忽视的问题是API平台的差异。官方的API和第三方API在调用工具、上下文长度还有特性开关上可能不太一样。这种异构的技术栈会带来额外的适配工作和冗余调用，进一步把代币和集成成本推高了。 简单的建议是：把每任务总消耗的代币量当成KPI来看，别光盯着单价看。客服和轻量自动化适合优先用Sonnet 4.6；要是搞研究型的长链推理或者复杂多工具编排的工作，最好还是谨慎一点，或者先考虑Opus 4.6这种更稳定的方案。还有一些具体的控费实操办法：系统提示模板化瘦身、先写提纲再展开内容、检索时分块并限制Top-K的数量、定期用对话摘要代替全文、控制工具调用的次数、要求“结论优先、少显性推理”、短任务用轻量模型、做好缓存与去重、流式早停，还有为每类任务设定一个代币预算。 Sonnet 4.6就像是一台高性能发动机——动力很强劲，但油门确实不能随便踩。对中小团队或者个人开发者来说，更实用的做法是先把提示工程、检索还有缓存这些基础工作做好再去评估模型。否则那便宜的单价可能只是账单陷阱上的一层糖衣。