大模型性能追上来了,但 API 账单追得更紧

大模型性能追上来了,但 API 账单追得更紧
7 月 19 日早上我照例打开月之暗面的开放平台想把刚发布的 Kimi K3 接进一个 Agent 工作流。结果页面上弹出一则通知C 端新用户订阅已暂停。不是限量预售不是营销套路是服务器负载真的接近上限推理排队时间已经被拉长到影响体验。一款国产大模型因为“太受欢迎”而主动限流这在国内 AI 行业并不常见。上一次让行业有类似记忆的还是 DeepSeek。但和 DeepSeek 主打性价比不同K3 是往高端打2.8 万亿参数、Artificial Analysis 智能指数 57 分、Code Arena 前端开发测试 76% 胜率登顶。横向看它的输出定价是 100 元 / 百万 tokens输入缓存未命中 20 元 / 百万 tokens是国内最贵的一档。性能追上 Claude Fable 5 和 GPT-5.6 Sol定价也向海外头部看齐——这本身是个好消息。但与此同时B300 服务器采购价在 4 个月内从 400 万涨到 1350 万算力成本翻了 3 到 4 倍。模型能力越往上走每一次 API 调用背后的资源消耗就越夸张。一、Token 需求跑在算力前面账单开始“反噬”K3 发布 48 小时就限流表面看是单模型的事件实际上是整个行业供需错配的缩影。根据公开数据字节豆包大模型在 2026 年 6 月的日均 Token 调用量已经突破 180 万亿。如果按每百万 Token 综合成本 4 元估算单日成本高达 7.2 亿元。即便保守测算一天也要 1.3 到 2.4 亿元。字节 2026 年的资本开支已经上调到 2000 亿元其中大部分砸向 AI。当利润被算力投入吞噬商业化就从“可选项”变成了“必选项”。不只是国内。Uber 到 4 月份就已经花光了 2026 全年的 AI 预算随后把员工月度使用额度限制在 1500 美元Meta 设置支出上限要求员工改用更便宜模型腾讯 6 月宣布全员 Token 额度改为按工作任务动态分配不搞排名。过去两年大家习惯了“模型越来越便宜、能力越来越强”但现在出现一个新变量调用量增长的速度超过了价格下降的速度。智谱 GLM 涨价 83% 后调用量反而增长了 400%DeepSeek V4 Pro 把价格降到原来的四分之一需求又被进一步放大。这就是典型的杰文斯悖论——单位成本下降带来的使用量膨胀最终让总支出曲线掉头向上。对开发者来说这意味着“选最便宜的模型”已经不够用了。你要算的不再是每百万 Token 多少钱而是完成一个任务要消耗多少 Token、.retry 几次、峰值时会不会被限速、失败后 fallback 到哪一家。二、从“免费试用”到“路径依赖”换模型的隐性成本被低估7 月 21 日腾讯混元 Hy3 结束免费期正式转入付费输入 0.14 美元 / 百万 token输出 0.58 美元 / 百万 token。价格本身不算离谱但让很多 Agent 开发者后背一凉。原因不是贵而是“耦合”。过去两个月里不少人把 Hy3 免费版塞进工作流当兜底模型高峰期主力模型限速时小任务扔给它处理。为了适配它的输出格式、响应速度和常见幻觉提示词、retry 策略、上下文分配比例甚至 guardrail 都围绕它写了一遍。现在突然收费换模型相当于重写一套调用逻辑。这类隐性成本从来没有被真正算进 TCO。显性成本是账单隐性成本是团队为某个模型定制的全部工程资产。再加上不同厂商的接口、认证方式、返回格式、缓存策略、额度体系各不相同迁移一次的人力投入往往比几个月的 API 费用还高。所以现在的市场出现一个分裂现象一边是 Kimi K3、Claude Fable 5 这类旗舰模型持续涨价用高价筛选高价值场景另一边是 DeepSeek V4 Pro 缓存命中低至 0.02 元 / 百万 token、小米 MiMo 最高降价 99%用极致低价锁住长尾需求。6 月底 DeepSeek 还推出了峰谷定价高峰时段价格翻倍——Token 计费开始像电费一样分时计价。这种“涨降价并存”不是混乱而是行业正在从“统一按 Token 计价”走向“按任务和能力计价”。高价值场景愿意为可靠性和效果付溢价通用任务则只看性价比。对开发者来说真正的课题变成了怎么在同一套系统里把不同价位、不同能力的模型用得恰到好处。三、把“算着用”做成默认配置别让团队从头造轮子解决这个问题的思路并不复杂缓存、路由、降级三板斧。先看缓存。很多团队没意识到自己的 API 调用里有大量重复 Token。系统提示词、few-shot 示例、历史上下文每天被重复发送成千上万次。一个日均 5000 次调用的客服系统引入语义缓存后命中率稳定在 35% 到 45%月均成本直接降了 40%。提示缓存对开发者也几乎是零门槛——OpenAI、Anthropic、Google 2026 年都已支持缓存读取通常只需原价的 10% 左右。再看路由。不同任务交给不同模型是成本优化的最大杠杆。一个每天处理 50 万条客服查询的 SaaS 公司先用分类器把 68% 的简单查询路由到低价模型复杂问题才走 Claude Opus立刻砍掉 41% 成本再叠加提示压缩和多级缓存六个月后单查询成本从 0.0094 美元降到 0.0025 美元降幅 73%。还有降级和批量。非实时任务走 Batch API通常能拿到 50% 折扣高峰期自动 fallback 到响应更快的模型保住可用性预算告警和按任务动态配额避免某条工作流把一个月额度一夜烧光。这些能力听起来基础但自己搭一套完整的网关并不轻松。要对接多家厂商的 SDK、处理不同的鉴权格式、做失败重试、统一计费、监控每个模型的质量衰减——对中小团队来说维护成本很容易超过节省下来的 API 费用。这也是为什么我现在更倾向于在项目中保留一个聚合层入口。像EasyAPI这类平台核心价值不在于“多一个调用渠道”而在于把多模型路由、统一计费、自动降级、预算上限做成默认配置。接入时基本只改一个 base URL后续切换模型、加缓存、设告警都变成配置项而不是工程重构。当然LiteLLM、OpenRouter 也能走通类似路线关键是别让自己每次换模型都重写一遍调用栈。结语K3 限流和 Hy3 转付费其实释放了同一个信号大模型的“免费尝鲜期”正在结束API 调用正在从“成本可忽略”变成“必须被设计的资源”。未来半年的竞争可能不再是哪家模型参数最大而是谁能在“效果足够好”和“成本足够低”之间找到最稳的动态平衡。对开发者来说这意味着 prompt 要更省、缓存要更准、路由要更细、降级要更果断。换句话说模型能力追上来了工程能力才是下一步真正的护城河。