把 token 烧明白：vibe 项目的 LLM 推理成本工程

2026 年 9 月的价格战把价目表彻底改写了：OpenAI 连发 GPT-6 Sol（输入 $2/百万 token、输出 $10/百万 token）和 Luna（$0.10/$0.50），Anthropic 的 Opus 5.5、Sonnet 5.5 把缓存读做到 0.05 倍。但多数独立开发者的成本优化还停留在"换个便宜模型"——这是 2026 年最贵的误解。

真相是：同一模型下，调用方式的选择比模型选择更能决定毛利率。同一个 Sonnet 5.5，有人月烧 $20,000，有人只花 $4,450，差的不是模型，是调用层工程。本文以下价格均按 2026 年 10 月核实的官网价计算（价格以官网为准，动手前请复核），给你六个可落地的压降杠杆。

一、先算账：一个 AI 功能的 token 构成

优化之前先拆账。拿一个典型的 AI 文档问答功能举例：月 100 万次调用，平均每次输入 8000 token（其中系统提示词 + 工具定义 + RAG 模板约 6000 token 是固定前缀），输出 400 token。用 Sonnet 5.5（输入 $2/百万、输出 $10/百万）：

• 输入：8000 token × 100 万次 = 80 亿 token × $2/百万 = $16,000
• 输出：400 token × 100 万次 = 4 亿 token × $10/百万 = $4,000
• 合计：$20,000/月——这就是"什么都不做"的标准价。

注意输入是输出的 4 倍账单占比，但几乎所有人的优化注意力都在"让模型少说点话"上。输入侧才是金矿：那 6000 token 的固定前缀，每次调用都在按全价重算一遍——这就是第一个杠杆要吃掉的部分。

先看 2026 年 10 月的价目表速览（官网价，动手前请复核）：GPT-6 Sol 输入 $2、输出 $10；Luna 输入 $0.10、输出 $0.50；旗舰 Astra 输入 $10、输出 $50；Claude Sonnet 5.5 输入 $2，Opus 5.5 输入 $4。同档能力下价格能差出 5~20 倍——但价目表只是起点，下面要讲的是：拿到价目表之后，怎么把账单打下来。

二、杠杆一：Prompt Caching——最被低估的印钞机

原理一句话：LLM 对 prompt 的前缀只算一次，后续相同前缀直接读缓存。Anthropic 的定价（2026-10 核实）：缓存写是 1.25 倍输入价（5 分钟 TTL）或 2 倍（1 小时 TTL），缓存读默认 0.1 倍，在 Opus 5.5 和 Sonnet 5.5 上是 0.05 倍——95% 的减免。OpenAI 侧是自动缓存（1024 token 以上），缓存读约 1 折，写 1.25 倍。

Anthropic 的写法很简单，在要缓存的内容块上加标记：

{
  "model": "claude-sonnet-5-5",
  "system": [
    {"type": "text", "text": "…6000 token 的系统提示词…",
     "cache_control": {"type": "ephemeral"}}
  ],
  "messages": [{"role": "user", "content": "…本次问题…"}]
}

关键细节有三处，踩坑的全在这：

• TTL 是 5 分钟，从请求开始算，且每次命中自动续期。高频应用第一次写之后基本不用再付写费用；但低频应用（比如一小时才调几次）会反复"写→过期→重写"，写放大的 1.25 倍反而比不缓存更贵——实测过期后重写的那一次，比全程不缓存贵约 25%。低频场景要么选 1 小时 TTL（写 2 倍，算好盈亏），要么干脆别缓存。
• 前缀必须逐 token 相同。缓存断点之后有一个 token 变了，后面全部重算。所以结构原则是：稳定的放前面，变量放后面——系统提示词、工具定义、few-shot 示例放最前，用户问题、RAG 检索结果放最后。把时间戳、request_id 这种每次都变的东西塞进前缀，等于亲手杀死缓存。
• 用 usage 字段验证，别靠感觉。Anthropic 看 usage.cache_read_input_tokens 是否大于 0；OpenAI 看 usage.input_tokens_details.cached_tokens。上线第一周每天看一次，确认命中率真的上来了。

缓存和 RAG 是天作之合，但有个前提：检索结果必须拼在缓存断点之后。正确结构是 [系统提示词｜工具定义｜few-shot] → 缓存断点 → [RAG 检索结果｜用户问题]。检索结果每次都变，放在断点后不影响前缀命中；反过来，如果把检索结果塞进系统提示词前面，缓存命中率直接归零。很多人的"RAG + 缓存没效果"，病根都在这一行顺序上。

回到上面的算账例子：6000 token 固定前缀，缓存读 6000×100万×$0.10/百万 = $600；写按 2% 摊销（98% 命中）约 $300；剩下 2000 token 变量输入 $4,000；输出 $4,000。小计 $8,900——还没上 Batch 就已经砍掉一半还多。

三、杠杆二：Batch API——能等 24 小时就别走实时

OpenAI、Anthropic、Gemini、Bedrock 的 Batch API 统一 50% off，代价是异步：24 小时内返回结果。独立开发者对"实时"有执念，但很多 workload 根本不需要实时：

• 适合：离线文档处理、批量翻译、内容审核、embedding 回填、评测集跑分、定时报告生成。
• 不适合：用户在线等的对话、实时补全、任何 SLA 要求分钟级的链路。

实操建议：把 workload 按"用户是否在等"一切两半。在等的走标准接口，不在等的全部进 Batch 队列。很多项目的现状是 100% 走标准接口——光是把离线部分切出来，账单直接对半。上面例子里的 $8,900 再套 Batch 50%，就是 $4,450/月，相对标准价 $20,000 节省 77.75%（见文首瀑布图）。

编排上注意：Batch 是 24 小时窗口，不是"越晚越好"。设置一个每日固定提交时间（比如凌晨），让结果在第二天开工前回来，形成稳定的离线管线节奏。

Batch 有两个隐藏细节：第一，Batch 折扣和缓存折扣是可叠加的（文首瀑布图就是这么算的）——"二选一"是误解，正确姿势是全都要；第二，Batch 的 50% 是按标准价打的，如果你的 workload 已经高度缓存，Batch 的绝对节省额会变小，但依然是正收益，别因为"已经省了很多"就懒得切。

四、杠杆三：上下文剪枝——别把整本词典塞进 prompt

RAG 应用最常见的浪费：检索回 20 个文档块，全塞进 prompt，模型只用了前 3 个。上下文不是越多越好——每多一个 token 都是钱，而且长上下文还会稀释注意力、拉低质量。

• RAG 注入量设上限：按相关性分数截断，top-k 不是越大越好。从 k=8 开始测，逐步下调到质量拐点。多数问答场景 k=4~5 就够了，token 直接砍半。
• 历史消息做压缩：多轮对话不要全量回放。用摘要滚动窗口：保留最近 N 轮原文，更早的压缩成一段摘要。Anthropic 有 compaction 机制，OpenAI 有 /responses/compact，原理都是"旧历史变摘要"。
• 结构原则：稳定前缀放前、变量放后（和缓存杠杆是同一套结构，一次重构吃两份红利）。工具定义尤其要注意：几十个 tool 的 JSON schema 是巨大的固定前缀，精简工具描述、合并同类工具，既省 token 又提命中率。

再算一笔剪枝的账：RAG 问答每次注入 20 个文档块、约 12000 token，top-k 从 20 砍到 5，单次输入从 12000 降到约 4000（含固定前缀 3000）。按月 100 万次、Sonnet 5.5 输入 $2 算：原来 120 亿 × $2 = $24,000，砍后 40 亿 × $2 = $8,000，月省 $16,000。代价是花一下午跑评测找拐点——一下午换 $16,000/月，这是独立开发者能找到的最高时薪。

五、杠杆四：级联与降级——小模型先行，大模型兜底

不是每个请求都值得用旗舰模型。级联（cascade）的做法：先用便宜小模型（比如 Luna $0.10/$0.50，或 Haiku 级别）处理，设一个置信度门槛——模型自评置信度低、或输出触发质量检查失败时，才升级到大模型。

落地三件套：

• 分流规则：按任务类型硬分流（分类、提取、摘要走小模型；复杂推理走大模型）比"全走小模型再回退"更稳定，先上硬分流，再上动态级联。
• 置信度门槛：让模型输出置信度分数，或用"自我检查" prompt（"你对这个答案有多大把握？只答数字"）。阈值从 0.7 开始调，看回退率和质量。
• 回退链：小模型 → 大模型 → 人工/降级回复，三级写死。降级回复不是认输，是成本工程的一部分：对低价值请求，"暂时无法处理，请换个问法"比烧 $50/百万 token 的输出体面得多。

实测经验：客服、内容分类这类场景，70~80% 的请求小模型完全能处理，级联后整体成本是全量旗舰模型的 1/4 到 1/5，而用户感知的质量几乎不变。

算一笔级联的账：工单分类月 30 万次，每次输入 2000 token、输出 100 token。全走 Sonnet 5.5：输入 6 亿 × $2 = $1,200，输出 3000 万 × $10 = $300，合计 $1,500。级联后 75% 走 Luna（输入 $0.10、输出 $0.50）：$45 + $11.25；25% 回退 Sonnet：$375。合计约 $431，省 71%。回退率每降 5 个点，多省约 $70——这就是为什么置信度阈值值得花一下午调。

六、杠杆五/六：输出预算与 effort 参数——管住隐形成本

输出 token 通常比输入贵 5 倍（Sol $2/$10，Sonnet 5.5 $2/$10），但大家只盯着输入优化。两个动作：

• 输出预算：给每个功能设 max_tokens 上限。摘要功能要 4000 token 输出？先问一句"用户真的会读 4000 token 的摘要吗"。多数场景 500~800 token 足够，一刀砍掉 80% 的输出账单。结构化输出（JSON）天然省 token：要字段不要散文。
• effort 参数：推理模型的 effort（none/low/medium/high/xhigh/max）直接决定推理 token 量——这是 2026 年最大的隐形成本。分类、提取这种任务用 low；开放式推理才上 high。OpenAI 自己的数据：Sol 在 AutomationBench 上 max effort 完成任务 $0.27/个，low effort 便宜一个数量级。默认 medium 是一种懒惰，每个功能都值得单独调一次 effort。

举个具体的输出预算账：你的"智能摘要"功能默认 max_tokens=4000，实测用户平均只读前 600 token。把上限砍到 800，输出 token 直降 80%：按月 50 万次、原来平均输出 1500 token 算，原来 7.5 亿 × $10 = $7,500，砍后 4 亿 × $10 = $4,000，月省 $3,500——改的只是一个数字。effort 同理：把工单分类从默认 medium 降到 low，推理 token 通常降 60~80%，质量几乎不动。这两个是全篇改动成本最低的杠杆，加起来 10 分钟。

七、成本归因仪表盘：知道钱花在哪，才知道刀砍向哪

（划界：这里只讲"怎么搭仪表盘"的做法，记账分摊体系是 token-cost-accounting 那篇指南的地盘，不重复。）

最小可用的归因仪表盘只需要三列数据，每个 API 调用打三个标签：功能（哪个产品功能触发的）、模型（实际用的哪个）、用户分群（免费/付费/内部）。实现方式：在调用 LLM 的统一出口包一层，把 model、input/output/cached token 数、功能名、用户 id 写进日志或时序库。

每周看一次三个数字：单个功能的总成本、单个付费用户的平均成本、缓存命中率。决策全从这三个数字长出来：某个功能成本畸高→看是调用量大还是单次 token 大→对应用上面的杠杆。没有归因的优化都是玄学——你甚至不知道省下来的钱是从哪个功能省的。

举个例子，你的仪表盘第一周可能是这样三行：AI 问答——月 100 万次，成本 $20,000，缓存命中率 0%；工单分类——月 30 万次，成本 $1,500，命中率 0%；周报生成——月 2 万次，成本 $800，命中率 0%。一眼就能看出：问答是缓存改造的第一目标，工单分类是级联试点的第一目标，周报生成是 Batch 的第一目标。归因的价值不在于数字多精确，而在于它把"先干哪件"从问答题变成了选择题。

八、反模式：省钱省出的三个坑

反模式一：缓存了从不命中的前缀。开了缓存但前缀每次都变（时间戳塞前面、用户 id 放系统提示词里），结果每次都在付 1.25 倍的写费用，命中率 0%。症状：cache_read_input_tokens 恒为 0。药方：结构重排 + 每日看命中率。

反模式二：全量走标准接口。离线 workload 和实时混在一起，图省事全走实时。 Batch 50% 是白捡的钱，不捡等于每月给云厂商捐款。药方：按"用户是否在等"切分，一周就能改完。

反模式三：为省输入 token 砍掉关键上下文。把 RAG 的 k 值砍到 2、把 few-shot 全删，账单降了 30%，质量崩了 50%，用户流失了。这是最蠢的省钱：省的是 token，亏的是留存。药方：任何剪枝动作必须配质量回归测试（固定评测集，剪枝前后跑分），质量跌超阈值就回滚。

九、一页纸检查清单

按顺序做，每完成一项打勾。清单打印出来贴在墙上，每周五对照着过一遍——成本工程不是一次性项目，是每周 15 分钟的习惯：

• □ 拆账：列出 top3 烧钱功能的输入/输出/缓存 token 构成
• □ 缓存：固定前缀加 cache_control，结构改成"稳定在前、变量在后"，验证命中率 >80%
• □ Batch：把"用户不在等"的 workload 切到 Batch API（50% off）
• □ 剪枝：RAG top-k 调到质量拐点，历史消息上压缩
• □ 级联：小模型先行 + 置信度门槛 + 三级回退链
• □ 输出：每个功能设 max_tokens 上限，effort 按功能单独调（默认 medium 是懒惰）
• □ 归因：调用出口打标签（功能/模型/用户分群），每周看一次
• □ 回归：任何压降动作配质量评测，跌超阈值回滚

矩阵的阅读方法是：左上"速胜区"（Prompt Caching、Batch API、effort 参数）本周就能做；右上（级联与降级、上下文剪枝）排进下个迭代。独立开发者的时间最贵，先捡地上的钱。

十、两周落地计划：从 $20,000 到 $4,450 的路线图

六个杠杆都知道了，但"从哪下手"决定了你是真省钱还是收藏夹吃灰。按下面这个两周计划走，每一步都有明确的交付物和可预期的节省——数字沿用文首的算账口径（月 100 万次调用，Sonnet 5.5）。

第 1~2 天：拆账 + 打标签。给 LLM 调用出口加上功能/模型/用户分群三个标签，跑 48 小时，拉出 top3 烧钱功能。交付物：一张表——每个功能的月调用量、平均输入/输出 token、缓存命中率（大概率是 0）。这一步不省一分钱，但它是后面所有决策的地基。没有这张表，你连"前缀有多固定"都不知道，缓存改造就是盲改。

第 3~5 天：缓存改造。按"稳定在前、变量在后"重排 prompt 结构，把时间戳、request_id 之类的变量赶出前缀；在系统提示词和工具定义上加 cache_control；上线后每天看 cache_read_input_tokens，目标命中率 80% 以上。预期效果：以前文的 workload 为例，输入账单从 $16,000 降到约 $4,900（$600 缓存读 + $300 写摊销 + $4,000 变量输入），三天工作量，月省 $11,100——这是全计划里 ROI 最高的三天。

第 6~7 天：切分 Batch。把 workload 按"用户是否在等"一切两半：离线文档处理、批量任务、定时报告进 Batch 队列，设置每天凌晨固定提交。预期效果：离线部分（假设占 60% 调用量）账单直接对半。注意别贪心——第一周先切"明显离线"的，边界模糊的（比如"用户 10 分钟内要看的报告"）留到第二周再定。

第 8~10 天：剪枝 + effort 调优。RAG 的 top-k 从当前值每次下调 2，配固定评测集跑分，找到质量拐点；同时把每个功能的 effort 档位单独调一遍（分类提取类直接降到 low）。预期效果：输入再降 20~30%，推理 token 降一个数量级。这一步最考验耐心——调 effort 时一次只动一个功能，动完跑评测，质量跌超 2% 就回滚。

第 11~14 天：级联试点。选一个调用量最大、任务类型最单一的功能（比如工单分类）做级联试点：小模型先行 + 置信度 0.7 门槛 + 三级回退。跑一周看两个指标：回退率（目标 <25%）和用户投诉率。试点成功再推广到第二个功能，不要一次性全上——级联的复杂度是六个杠杆里最高的，值得用两周换稳定。

两周后的账单长这样：缓存改造省 $11,100，Batch 再省约 $4,450，剪枝和 effort 省 $1,500~2,000，级联试点省约 $1,000（单功能）。合计月省约 $18,000，账单从 $20,000 降到 $2,000 上下——比瀑布图的 $4,450 还低，因为剪枝和级联是瀑布图没算进去的额外红利。

最后提醒一句：这个计划里没有"换便宜模型"这一步。不是便宜模型不好，而是在调用层工程做完之前换模型，你只是在用更便宜的模型重复浪费。先把调用方式改对，再谈模型选择——顺序反了，省的钱会从指缝里漏掉。

最后一句：同一模型下，调用方式的选择比模型选择更能决定毛利率。价格战会过去，模型会换代，但调用层工程的手艺——缓存、批量、剪枝、级联——是每一代模型都通用的。下次再看到降价新闻，别只换模型，先问自己：我的调用方式配得上这个价格吗？