Token 成本优化：比换便宜模型更有效的几招
数据截至 2026-07，价格与限额以各官网为准。
如果你的 token 账单让人肉疼，第一反应通常是”换个便宜模型”，但这往往是收益最小的一招。换模型最多把单价压低一个系数，而重复发送的长前缀、没人清理的对话历史、让旗舰模型去做字段抽取这类结构性浪费，压下去能省一个数量级。顺序应该是：先量出来钱花在哪，再改请求结构，最后才考虑动模型。
有个很常见的误解：以为 token 成本主要由”模型贵不贵”决定。实际做过账的人会发现，同一个功能，两个团队用完全一样的模型，月账单可能差好几倍，差别全在怎么组织请求。更麻烦的是，这类浪费在开发阶段完全看不出来——本地调试几十次请求，钱少到没感觉，等上线跑起量才发现每一次对话都在重发那份三千字的系统提示。
先把账拆开：不知道钱花在哪就别动手
优化之前必须有一份账。最少要拆到三个维度：
- 按功能拆。哪个入口在烧钱？是聊天主流程、后台的批量打标，还是那个没人用的”智能总结”按钮？很多时候前三名功能占了八成以上的消耗，剩下的优化不优化影响都不大。
- 按输入/输出拆。绝大多数模型的输出单价比输入单价高，但典型 RAG 或长上下文应用里输入 token 的绝对量往往远大于输出。先看你的账单里到底哪边是大头，方向完全不同：输入大头就去砍上下文和吃缓存，输出大头就去管生成长度。
- 按单次请求的分布拆。看的不是平均值而是分位数。平均 2000 token 的接口，可能有 5% 的请求飙到 10 万 token，这些长尾请求经常是真正的成本黑洞，也往往对应着某个没做长度保护的输入路径。
实现上不复杂：每次调用把返回里的 usage 字段（输入、输出、缓存相关的计数）连同功能标识一起写日志，跑一周就能出图。别嫌麻烦，缺了这份数据，后面每一招你都不知道有没有生效。
第一招：让前缀稳定下来，把缓存吃满
主流 API 大多提供某种形式的提示词缓存：把请求开头一段固定不变的内容缓存住，后续命中时这部分的计费显著低于原价。这是投入产出比最高的一招，因为它不牺牲任何效果——同样的内容，只是不用重复付全价。
关键在于理解它的机制：缓存是前缀匹配的。从请求开头逐段比对，一旦某处内容变了，这一处之后的全部失效。所以真正要做的事只有一件——把不变的放前面，把变的放后面。
具体怎么排：系统提示、角色设定、工具/函数定义、少样本示例、需要反复引用的长文档，这些放最前面，且字节级固定；用户的当次输入、检索到的片段、对话历史增量，放最后面。
几个高频翻车点：
- 把当前时间戳、请求 ID、随机打乱的示例顺序写进系统提示开头——每次都不一样，缓存永远命中不了，还倒贴写入成本。
- 工具定义的 JSON 序列化顺序不稳定（比如用了无序字典），肉眼看着一样，字节不一样，照样打不中。
- 在长文档中间插入用户名之类的动态变量，把一整块本来能缓存的内容切成了不可缓存。
缓存的具体折扣倍率、有效期长度、以及”多少 token 以上才会触发缓存”的门槛，各家不同且会调整，以你所用平台官方定价与文档的当前版本为准，这篇不给具体数字。但有个通用的验证方法：发两次相同前缀的请求，看第二次返回的 usage 里缓存读取相关的计数是不是大于零。是零就说明没生效，通常要么前缀没到最小长度，要么就是上面那几个翻车点。
第二招：给上下文瘦身，别把”塞得越多越准”当默认
上下文窗口变大之后，很多人养成了一个习惯：反正塞得下，就全塞进去。这既费钱，效果也未必更好——无关内容多了，模型抓错重点的概率反而上升。
可操作的几件事：
- 检索而不是全量。文档问答用向量检索取相关片段，而不是把整份手册贴进去。相关做法可以看什么是 RAG。
- 对话历史滚动摘要。超过 N 轮之后，把早期轮次压成一段结构化摘要，只保留关键结论、用户偏好和未完成事项。注意摘要一变，缓存前缀就断了，所以摘要更新的频率不要太高。
- 工具返回值先清洗再喂。抓来的网页别把整个 HTML 丢进去，日志别把百兆原文丢进去，先做提取和截断。Agent 类应用里，工具输出常常是 token 消耗的第一名。
- 给每条链路设长度上限。用户能上传的文本、检索能返回的条数、单次工具输出的字符数，都要有硬上限，否则总有一天会撞上那个把整本 PDF 粘进输入框的用户。
想系统了解怎么组织上下文，可以看上下文工程怎么做和上下文窗口是什么。
第三招：按任务分层路由，而不是一把梭旗舰模型
这才是”换模型”的正确打开方式：不是全局换成便宜的，而是按任务难度分层。
一个粗糙但好用的分层：意图分类、字段抽取、格式转换、简单改写这类任务，小模型足够；需要多步推理、写代码、做复杂决策的，才上旗舰模型。前者往往占请求量的大头，占账单的小头——但换过来之后，省下的是大头的钱。
分层落地的难点不在技术，在于你得有个评测集。挑 50 到 100 条真实样本，人工标好期望结果，换模型之后跑一遍看准确率掉了多少。没有这套东西，降级就是拍脑袋，出了问题也说不清是模型的锅还是提示词的锅。
工程上要做的是把”模型选择”从业务代码里抽出来，收成一个可配置的路由层，这样调整策略不用改代码。自己写一层也行，用现成的网关也行。
用开源网关做统一入口和回退链
以 OmniRoute 为例，它是一个 MIT 协议的开源 AI 网关，起源是从 9router fork 而来，同时是 Go 项目 CLIProxyAPI 的 TypeScript 移植。它的定位是：一处配置 http://localhost:20128/v1，让 Claude Code、Codex、Cursor、Cline、OpenCode、Copilot 等各种 AI IDE 和 CLI 都走同一个本地端点。
按仓库自述，它接入 290+ 家供应商、500+ 个模型，其中 90+ 家带免费档、40+ 家标注为永久免费，覆盖 Kimi、Claude、GPT、Gemini、GLM、DeepSeek、MiniMax 等。启动方式是 npx omniroute@latest，或者用 Docker 跑 docker run -p 20128:20128 diegosouzapw/omniroute，然后打开 http://localhost:20128 进面板。常用命令有 omniroute setup（首次向导）、omniroute doctor（自检）、omniroute models --search <term>（查某个模型在哪些供应商可用）。
跟成本直接相关的有三点：
- 配额感知的自动回退。接了多个供应商之后，某一家额度用尽或报错时自动切到下一家。仓库给的零成本组合示例是
gemini-cli/gemini-3-flash-preview（每月 180K 免费）→if/kimi-k2（无限免费）→qw/qwen3-coder-plus（无限免费）。 - 模型填
"auto"时由网关自动挑选，适合不想手工维护路由表的场景。指定具体模型时要用供应商原生格式的模型 ID（仓库示例形如claude-opus-4-8、gpt-5.5、glm-5.1、kimi-k2.5，有的带点号版本号是因为上游 API 就这么要求）。 - 内置的 RTK+Caveman 压缩，仓库称可省 15-95% token。这个区间跨度极大，实际能省多少完全取决于你的负载形态，当作”可以试试”而不是承诺。
必须说清楚的几件事：免费额度类信息变动极快，上面这些供应商数量、免费档数量、组合示例，都是仓库文档当前版本的自述，用之前请以仓库文档为准，别把”无限免费”当成可以写进架构设计的前提。另外这是第三方聚合网关，你要把各家平台的凭证交给一个本地代理进程，凭证保管、审计和公司合规要求自己评估，这篇不做背书。
想进一步了解可以看OmniRoute 上手和用 OmniRoute 拼零成本模型组合，网关方案的横向取舍在AI 网关怎么选。
关于访问，有个不能含糊的前提：OpenAI、Anthropic、Google Gemini 等厂商目前都没有面向中国大陆的官方开放渠道，不管中间套了几层网关，都不改变这个事实——网关解决的是”统一入口和路由”，不是”准入”。市面上确实存在第三方中转服务声称可直连，这类服务的合规性、计费透明度和数据安全需要你自己核实并承担风险，这篇不推荐具体渠道。做技术选型时，把这条当成硬约束提前排进去，别等接完一半才发现整条路走不通。
第四招：管住输出，输出通常比输入贵
输入端优化谈得多，输出端常被忽略，但输出单价往往更高，而且它还直接影响响应延迟。
- 给 max_tokens 设合理上限，不要图省事一律给个很大的值。真被截断了会有明确信号，比放任模型写八百字客套话强。
- 要求结构化输出。让模型直接返回 JSON 或短标签，而不是”先解释一下我的思路，然后……”。分类任务只要一个词，就在提示里明确说只输出那个词。
- 禁止复述输入。很多提示词没约束，模型会先把用户问题原样重复一遍再回答，这部分纯属白花钱。
- 推理类输出按需开启。带思考过程的模式在难任务上确实有效，但在简单任务上是纯成本，别全局打开。
顺带澄清一个误解：流式返回不省钱。它只是把同样数量的 token 分批推给你，改善的是首字延迟的体感，账单一分不少。
第五招：不着急的活走批处理，能复用的结果做应用层缓存
批处理：不需要实时响应的任务——离线打标、历史数据清洗、批量摘要——很多平台提供异步批量接口，价格低于同步调用，代价是延迟从秒级变成分钟到小时级。具体折扣比例和最长等待时间各家不同，以官方定价页为准。这类任务从同步改异步，通常是改动最小、收益最直接的一笔。
应用层缓存：这一层完全在你自己手里，也最容易被忽略。同一个问题一天被问三百遍，没有理由调三百次模型。做法是对”提示词 + 参数 + 相关数据版本”做哈希当缓存键，命中直接返回；embedding 更是应该长期缓存，同一段文本没变就不该重复算。要注意设好失效策略，别让用户拿到过期答案。
代价和不适用场景
每一招都有成本，说清楚才不至于优化完了后悔：
- 稳定前缀会限制灵活性。为了吃缓存，你的提示词组织方式会被约束住，A/B 测试提示词时缓存命中率会掉，这段时间成本反而上升。
- 降级模型需要持续验证。评测集要跟着业务变，否则半年后你根本不知道当初的降级还成不成立。
- 上下文瘦身可能砍掉关键信息。摘要压缩尤其容易丢掉后面才用得上的细节，上线前拿真实会话回放测一遍。
- 免费额度不适合进生产。它随时可能调整或取消，用来学习、做原型、跑个人项目很好，用来撑线上服务就是把稳定性押在别人的运营决策上。
- 量太小就别优化。月账单几十块的时候，工程师花两天做缓存架构，成本远高于省下的钱。先看绝对金额，值不值得做心里要有数。
小结
先量后改，没有账单拆解的优化都是猜。收益排序大致是：稳定前缀吃缓存 > 上下文瘦身 > 按任务分层路由 > 控制输出 > 批处理与应用层缓存，换便宜模型排在最后而不是最前。开源网关这类工具能帮你把路由和回退统一起来，但要清楚它给的免费档信息变动很快，且要求你把凭证交给本地代理，这两点的风险自己评估。还有一条硬约束绕不过去：部分海外厂商对中国大陆没有官方开放渠道，做架构设计时提前把它算进去，比后面推倒重来便宜得多。最后提醒一句，优化的目标是单位业务价值的成本，不是账单数字本身——为了省钱把效果做砸，返工的代价通常远超省下的那点 token 钱。