从 Token 到中转站：一文讲清大模型计费、缓存与倍率

从 Token 到中转站：一文讲清大模型计费、缓存与倍率

这篇文章想回答的，其实只有一个核心问题：为什么同样是调用一次大模型，有的平台按美元计费，有的平台显示的是"点数""余额""倍率"，而且开启缓存、开启 thinking 之后，扣费逻辑还会明显变化？

要把这件事讲明白，最好的顺序不是直接从"中转站倍率"讲起，而是先回到最底层：Token 是什么，模型到底按什么计费。只有先把官方的计费结构看清楚，后面再理解中转站为什么要引入倍率、配额和折算系数，才不会混淆。

---

一、Token 的定义与基本内涵

在大模型的世界里，模型并不是按"字数""句子数"或者"消息条数"来计费，而是按 Token 来计费。

你可以把 Token 理解为：模型处理信息时使用的最小计量单位之一。在最常见的文本场景里，它既不是严格意义上的一个汉字，也不一定等于一个英文单词，而是模型在内部切分文本后得到的一段段片段。

举个直观的例子：

• 一段中文文本，通常会被拆成若干个 Token；
• 一段英文文本，可能一个单词对应一个 Token，也可能一个单词被拆成多个 Token；
• 标点、空格、换行、代码符号，很多时候也都会占用 Token。

所以，Token 更像是模型的"计算字节"。你给模型输入的内容，要先变成 Token；模型生成的回答，也会以 Token 的形式逐步输出。

这也是为什么大模型的价格表几乎都不是写"每千字多少钱"，而是写"每百万 Token 多少钱"。因为对模型厂商来说，真正稳定、可计算、可计费的单位是 Token，而不是自然语言里的"字"或"词"。

1. Token 与字数、词数的区别

Token 不是字数，而是模型处理单位

这是最容易误解的一点。

很多人会下意识地认为：

• 中文 1 个字 = 1 个 Token；
• 英文 1 个单词 = 1 个 Token。

但真实情况通常没有这么简单。

因为模型使用的是分词器（tokenizer）来切分内容，而不是按照自然语言语法来数数。于是：

• 常见短词可能就是 1 个 Token；
• 生僻词、很长的单词，可能被拆成多个 Token；
• 数字串、URL、JSON、代码、表格，往往会产生比想象中更多的 Token；
• 同样一段内容，在不同模型上，Token 数也可能不完全一样。

所以，Token 更准确的理解方式不是"文字长度"，而是模型内部处理内容时的离散单位。

2. Token 数差异的形成原因

Token 数并不是只由"内容长度"决定，还和内容形态有关。

比如下面几类内容，通常都会让 Token 结构发生明显变化：

• 代码：符号多、结构碎，Token 往往增长得很快；
• 表格 / JSON：键名、标点、引号、缩进都会占用 Token；
• 中英混合文本：切分粒度更复杂；
• 长上下文对话：历史消息会被反复带入输入侧；
• 工具调用 / 函数调用描述：参数定义、schema、返回结构也都要算 Token。

这也是为什么很多人实际使用时会发现：看起来字数不多，但账单并不低。因为模型看到的不是"字数"，而是经过切分后的 Token 序列。

3. 多模态场景下 Token 的扩展含义

当模型进入多模态场景之后，Token 的概念并没有消失，只是它不再只对应"文本片段"。

更准确地说：多模态模型会把图片、音频、视频等输入，先转换成模型可以处理的内部表示，再映射到可计费的 Token 或 Token 等价单位。

因此，多模态里的 Token 可以粗略分成几类理解：

• 文本 Token：提示词、系统消息、OCR 文本、工具返回文本；
• 图像 Token：图片经过切块、缩放、编码后形成的视觉计算单位；
• 音频 Token：音频片段经过声学编码后形成的时间序列单位；
• 视频 Token：通常是"抽帧后的图像单位 + 音频单位 + 可能的文本上下文"的综合消耗。

这里最关键的一点是：多模态并不是不按 Token 计费，而是把非文本信息也折算成了模型可处理的 Token 结构。

4. 图像 Token 的常见计量方式

图片 Token 的计算方式，不同厂商差异很大，但底层思路通常相似：

先把图片标准化，再按视觉块（patch / tile / region）或分辨率等级折算成若干视觉 Token。

常见的影响因素包括：

• 图片分辨率；
• 图片是否会被缩放；
• 是低清模式还是高精细模式；
• 是否需要 OCR、表格理解、图表理解；
• 厂商是否按固定档位计费，而不是按原始像素逐点计费。

所以在很多视觉模型里，并不存在一个简单通用的公式说"1 张图 = 固定多少 Token"。更常见的情况是：

• 一张小图，可能被折算成较少的视觉 Token；
• 一张高分辨率图片，可能会先缩放后再按块计费；
• 同一张图在 low detail 和 high detail 模式下，Token 消耗可能差很多。

也就是说，图片真正影响的不是'张数'，而是图片经过模型预处理之后，需要多少视觉计算单元。

5. 音频 Token 的常见计量方式

音频场景和图片类似，也不是简单按"文件个数"收费，而更接近按时间长度 × 编码粒度来折算。

常见逻辑是：

• 音频会被切成连续的小时间片；
• 每个时间片会被编码成模型可处理的声学表示；
• 最终再转换成音频 Token 或等价计费单位。

所以音频成本通常主要受这些因素影响：

• 音频时长；
• 采样率和编码方式；
• 是否要做实时处理；
• 是否同时输出逐字转写、说话人分离、时间戳等增强结果。

很多时候你看到"语音模型更贵"或"实时语音特别耗费"，本质上并不是平台在乱加价，而是模型需要持续处理高密度时间序列数据。

6. 视频 Token 的计量复杂性

视频往往是多模态里最复杂的一种，因为它通常不是单一输入，而是三部分叠加：

• 帧图像；
• 音频轨道；
• 提示词 / 上下文文本。

所以一个视频请求的消耗，很多时候可以近似理解为：

视频成本 ≈ 抽帧后的图像成本 + 音频成本 + 文本上下文成本

如果平台对视频做的是"定时抽帧"而不是逐帧分析，那么成本会和：

• 视频时长；
• 每秒抽多少帧；
• 每帧按什么分辨率处理；
• 是否同步分析音轨；

直接相关。

因此，视频不是"一个文件一次计费"这么简单，而是一个组合型的 Token 消耗体。

7. 多模态 Token 难以横向比较的原因

到了多模态阶段，Token 更不能简单横向比较了。原因在于：

• 不同厂商的视觉编码方式不同；
• 不同模型的预处理策略不同；
• 有的平台按 patch 数计，有的平台按档位计；
• 有的平台会把图片 / 音频先折算成文本等价 Token，再统一结算；
• 有的平台则直接给出独立的 image/audio pricing。

所以，当你看多模态价格表时，最稳妥的理解方式不是强行追问"1 张图到底等于多少 Token"，而是先看厂商到底公布的是哪一种计费口径：

• 文本 Token 单价；
• 图像输入单价；
• 音频输入 / 输出单价；
• 视频或实时流式单价；
• 是否存在 detail mode、cache、reasoning 等附加维度。

8. 面向用户的实用理解框架

如果只想留下一句最实用的话，那么可以这样记：

文本模型里的 Token，是文本被切分后的处理单位；多模态模型里的 Token，则是文本、图像、音频、视频等信息被模型编码后形成的统一计算单位或等价计费单位。

所以，无论是纯文本还是多模态，厂商真正计费的都不是"你发了几句话、几张图、几个文件"，而是：模型为了理解这些输入、并生成输出，实际消耗了多少可计算的内部单位。

---

二、大模型采用 Token 计费的原因

从厂商视角看，Token 是最适合做计费单位的，因为它直接对应了模型推理时的实际消耗。

一次调用模型，至少会发生两件事：

1. 模型读取你输入的内容；
2. 模型生成它输出的内容。

这两部分都会消耗算力，因此绝大多数模型厂商都会把账单拆成两类：

• 输入 Token（Input Tokens）：你发给模型的内容；
• 输出 Token（Output Tokens）：模型返回给你的内容。

于是，最基础的计费逻辑就成立了：

Cost = 输入成本 + 输出成本

进一步写成标准公式，就是：

Cost = Tin / 1,000,000 × Pin + Tout / 1,000,000 × Pout

其中：

• Tin：输入 Token 数量
• Tout：输出 Token 数量
• Pin：输入单价（每百万 Token）
• Pout：输出单价（每百万 Token）

这就是大模型最原始、最通用的官方计费框架。

---

三、大模型计费规则的基本结构

理解计费时，有三个结论必须先记住。

1. 输入与输出价格的差异

大多数厂商都会把输入价格和输出价格分开，而且输出往往比输入更贵。原因很简单：生成内容比单纯读取内容更消耗推理资源。

所以，同样是 1 万个 Token：

• 如果它们主要出现在输入侧，费用可能较低；
• 如果它们主要出现在输出侧，费用通常更高。

这也是为什么很多人会误以为"我明明只问了一个简单问题，为什么扣费不低"------因为真正贵的，可能不是你发出去的那段提示词，而是模型生成出来的大段回答。

2. 计费依据是 Token 数而非消息条数

不是说你只发了一条消息，费用就一定低；也不是说多轮对话就一定更贵。真正决定成本的，是每一轮累计消耗了多少 Token。

如果你的提示词很长、上下文很多、模型输出很长，那么哪怕只调用一次，也可能比多轮短对话更贵。

3. 历史上下文对输入成本的影响

在多轮对话中，模型并不是"记住了你上一次说过的话"这么简单。更准确地说，系统通常会把前面的消息重新整理后再传给模型，于是这些历史内容也会继续占用输入 Token。

因此，对话越长，上下文越大，输入成本往往也会越来越高。这也是后面谈缓存和中转站时必须关注的前提。

---

四、缓存机制下的计费变化

当模型厂商支持缓存之后，输入侧就不再只有一种价格了。

缓存的核心思路是：如果你每次请求里都有一大段重复的前缀内容，比如系统提示词、固定知识库上下文、工具定义、统一模板等，那么这些内容没必要每次都按完整成本重复处理。于是厂商会把其中命中的部分，按更低的价格计费。

这时，输入 Token 通常要拆成两部分：

• 未命中缓存的输入 Token
• 命中缓存的输入 Token

对应的公式也会变成：

Cost = Tuncached / 1,000,000 × Pin
     + Tcached / 1,000,000 × Pcache
     + Tout / 1,000,000 × Pout

其中：

• Tuncached：未命中缓存的输入 Token
• Tcached：命中缓存的输入 Token
• Pcache：缓存命中部分的输入单价

这里最重要的一点是：缓存优化的是输入侧成本，不是整次请求的全部成本。

也就是说：

• 命中缓存的输入会变便宜；
• 没命中的输入仍按原价计算；
• 输出 Token 依然按输出价格计算。

所以，缓存命中不等于"这次调用几乎不要钱"，它只是让重复输入这部分更便宜了。

---

五、Thinking / Reasoning 模式下的成本变化

除了缓存，另一个经常让人困惑的变量，是 thinking / reasoning 模式。

它本质上意味着：模型在输出最终答案之前，可能会先生成一部分用于推理、规划、分析的中间 Token。这些 Token 有时对用户可见，有时部分可见，有时只体现在统计口径里，但它们通常都会带来额外成本。

因此，thinking 模式和普通模式的差别，可以先粗略理解为：

普通模式：

Cost_normal = 输入成本 + 输出成本 + 缓存相关成本

thinking 模式：

Cost_thinking = 输入成本 + 输出成本 + 缓存相关成本 + 思考 Token 成本

更直白地说，thinking 模式之所以更贵，往往不是因为"模型换了一套完全不同的收费体系"，而是因为它在原本的输入/输出结构之外，又额外产生了更多需要计费的 Token。

在实际产品里，这些思考 Token 往往更接近输出侧开销；而在多轮对话中，如果上一轮的思考内容被完整回传到下一轮，它又可能再次进入输入侧成本。

所以，thinking 模式的本质不是"神秘加价"，而是 Token 结构更复杂了。

---

六、官方计费结构的核心要点

到这里，其实可以先把官方计费逻辑浓缩成一句最实用的话：

大模型官方计费，本质上就是在计算三类东西：未缓存输入、缓存命中输入、输出；如果开启 thinking，再额外考虑思考 Token 带来的成本。

也就是说，官方世界关心的核心变量始终是：

• 输入多少；
• 其中多少命中了缓存；
• 输出多少；
• thinking 额外增加了多少 Token。

只要这一层搞清楚，后面看中转站的"倍率""点数""配额"，就会顺很多。因为中转站并没有发明一套脱离官方规则的物理定律，它只是把这些官方成本，重新包装成了自己的结算体系。

---

七、中转站的角色与功能定位

讲完 Token 和官方计费，再来看"中转站"就容易多了。

所谓中转站，通常可以理解为：位于用户和上游模型厂商之间的一层聚合与转发服务。

它一般会做几类事情：

• 统一接入不同模型厂商的接口；
• 提供兼容层，让不同模型尽量用相似的调用方式访问；
• 管理密钥、额度、分组、渠道、限流、日志等运营能力；
• 把上游按美元或人民币计费的模型成本，转换成平台自己的余额、点数或配额系统。

所以，中转站并不等于模型本身，它更像是一个"流量分发与结算层"。

从用户角度看，中转站的价值往往在于：

• 可以在一个面板里切换多个模型；
• 可以用更统一的方式管理不同渠道；
• 可以把费用、倍率、权限、配额统一配置。

但也正因为它处于"中间层"，所以它展示出来的扣费方式，未必和上游厂商价格表一模一样。

---

八、中转站倍率机制的来源

很多人第一次看中转站面板时，最困惑的并不是价格本身，而是"倍率"这个概念。

因为在 OpenAI、Anthropic、Google 这类上游厂商的价格页里，更常见的是：

• Input
• Cached input / Cache read
• Output
• Reasoning / thinking 相关统计

它们描述的，本质上都是每百万 Token 的官方单价。

而到了中转站里，界面语言往往会变成：

• 模型倍率
• 分组倍率
• 补全倍率
• 缓存倍率
• 扣费倍率

这说明一件事：倍率通常不是上游厂商的原生计费单位，而是中转站为了把官方成本折算成平台内部余额、点数或配额，而人为引入的一层结算抽象。

说得更直接一点：

官方世界在算货币成本，中转站世界在算平台额度；倍率，就是连接这两套计量体系的换算系数。

因此，中转站并不是创造了一套脱离官方价格的全新物理定律，而是把官方的输入、缓存输入、输出、thinking 成本，重新包装成了自己的扣费语言。

---

九、倍率机制的折算逻辑

如果再往深一层看，所谓"倍率"，本质上是在回答下面这个问题：

同样消耗 1 个 Token，不同模型、不同渠道、不同用户组，应该从平台余额里扣掉多少"内部单位"？

于是，中转站通常不会直接把"美元价格"原样展示给用户，而是会先选定一个内部计费基准，再把不同成本映射进去。

你可以把它理解成下面这种抽象：

平台内部单价 = 官方单价 × 平台折算系数

如果进一步写成输入 / 输出分离的形式，就是：

内部输入单价 = 官方输入单价 × 折算系数
内部输出单价 = 官方输出单价 × 折算系数

但很多中转站并不直接展示"内部输入单价"和"内部输出单价"，而是把它继续拆成几个更方便运营配置的变量：

• 模型倍率：决定这个模型整体贵不贵；
• 补全倍率：决定输出 Token 按输入 Token 的多少倍折算；
• 分组倍率：决定不同用户等级是否加价或打折；
• 缓存倍率：决定缓存命中的输入是否按更低权重结算。

所以，倍率真正折算的并不是一个抽象标签，而是不同 Token 类型在平台内部的结算权重。

---

十、同一模型倍率差异的形成原因

很多人看到某个平台的 GPT-4o 倍率是 10，另一个平台是 3，第一反应是"前者更贵"。但这其实未必成立。

因为倍率本身不是统一货币单位，它至少会受到四层因素共同影响。

1. 渠道来源差异

同样是某个模型，平台接入的可能是：

• 官方直连渠道；
• Azure / AWS / GCP 等云渠道；
• 区域代理或企业采购渠道；
• 非官方逆向或代充渠道。

这些渠道的真实成本、稳定性和可持续性都不一样，因此倍率自然不会一样。

2. 服务质量差异

有些平台卖的不只是"能不能调用"，还包括：

• 更高的并发上限；
• 更稳定的可用性；
• 更低的延迟；
• 更少的限流和封禁风险。

于是你看到某些模型后面带 -official、-fast、-stable 之类的标记，本质上往往是在告诉你：这不仅是模型名差异，更是服务等级差异。 服务质量越高，倍率通常也越高。

3. 平台定价策略差异

中转站不是单纯的"成本搬运工"，它还会做运营策略：

• 对热门模型加价；
• 对新模型补贴引流；
• 用低倍率吸引注册；
• 用高倍率覆盖售后、风控、坏账和带宽成本。

因此，倍率里通常不只有"技术成本"，还包含平台自己的商业策略。

4. 充值汇率与货币结算差异

如果平台是人民币充值、美元成本，那么它还要处理：

• 汇率波动；
• 支付手续费；
• 提现或结算风险；
• 余额单位与真实货币之间的映射关系。

这就是为什么有些平台会出现一种表面上看起来很奇怪的现象：

充值 1 元，却给你记 1 美元口径的余额；为了把这个差额补回来，就会把模型倍率整体抬高。

所以，倍率不是纯技术参数，而是"上游成本 + 服务质量 + 运营策略 + 货币体系"共同叠加后的结果。

---

十一、中转站倍率体系的主要类型

这一节最容易混淆的地方在于：补全倍率、缓存倍率，和分组倍率并不是同一个层级的概念。

很多中转站会把这些词都统一写成"倍率"，再配合站内余额、点数、额度这些内部单位一起展示，于是用户很容易误以为：它们全都是平台自己发明出来的收费规则。

但更准确地说，这里至少要分成两层：

• 上游大模型原生计费维度：Input、Output、Cache；
• 中转站平台运营维度：模型倍率、分组倍率、余额折算。

也就是说，补全和缓存首先是上游模型本身就存在的计费方式；而分组倍率，才是平台为了统一调价而额外叠加的一层运营参数。

1. 上游原生计费项：输入、补全、缓存

先把最底层说清楚。

对绝大多数主流大模型来说，官方计费本来就会区分：

• 输入（Input）：你发给模型的 Token；
• 补全 / 输出（Completion / Output）：模型生成给你的 Token；
• 缓存（Cache）：命中缓存的输入 Token，按更低价格计费。

所以，很多中转站面板里所谓的"补全倍率""缓存倍率"，本质上并不是平台凭空创造出来的新概念，而是在映射上游 input / output / cache 的价格差异。

换句话说：

• 输入就是大模型官方的 input；
• 补全就是大模型官方的 output；
• 缓存就是命中缓存后的 input 计费口径。

在绝大多数模型里，缓存命中通常大约按普通输入价格的 1/10 结算；但也有少数模型会进一步细分成：

• **缓存写入（cache write）**价格；
• **缓存读取（cache read）**价格。

因此，如果一个中转站把"补全倍率""缓存倍率"单独拿出来强调，很多时候它讲的并不是站内独创规则，而只是把上游大模型原本就有的计费结构，用站内配额语言重新包装了一遍。

2. 模型倍率：把上游成本折算成站内单位

真正进入中转站自己的体系后，才会出现"模型倍率"这类平台侧参数。

模型倍率决定的是：同样一组 input / output / cache 消耗，在这个站里最终按多高的站内权重结算。

它本质上承接的是：

• 上游真实采购成本；
• 站内余额单位被放大或缩小后的折算关系；
• 平台自己的利润、汇率和风控策略。

这也是为什么很多中转站会先把站内金额单位调大，再在倍率层面做文章。表面上看倍率很多、结构很复杂，但其中有一部分其实只是把上游官方成本重新折算成站内内部单位。

所以，模型倍率更接近平台折算系数，而不是上游模型的原生价格字段。

3. 分组倍率：给一组统一调倍率

分组倍率的定位要单独拎出来，因为它和补全、缓存不是一个概念。

分组倍率决定的是：平台要不要对某一组用户、某一类套餐、某一个渠道分组做统一加价或打折。

例如：

• 普通用户组：1.0
• VIP 用户组：0.8
• 企业用户组：0.95

这类倍率并不对应 input、output 或 cache 的物理成本差异，而是平台运营层面对一整组流量做统一调整。

所以它的本质不是"模型怎么收费"，而是：平台准备让哪一组用户按什么系数结算。

4. 更准确的理解方式：先分层，再看扣费

如果把这些概念放在一起看，更准确的理解顺序应该是：

1. 先看上游模型怎么收费：input、output、cache，必要时再看 cache read / cache write；
2. 再看中转站怎么折算：是否放大了站内金额单位，是否设置了模型倍率；
3. 最后看平台怎么统一调价：是否对某个分组额外乘上分组倍率。

一句话总结就是：

补全和缓存，首先是上游大模型的计费维度；模型倍率和分组倍率，才是中转站在这些上游成本之上额外叠加的站内折算与运营参数。

十二、中转站扣费公式的完整表达

有了上面的定义后，就可以把中转站的扣费逻辑写得更完整。

1. 基础输入输出计费公式

如果先不考虑缓存和 thinking，只保留最常见的输入/输出结构，那么可以写成：

Quota_basic = (Tin + Tout × Rout) × Rmodel × Rgroup

其中：

• Tin：输入 Token
• Tout：输出 Token
• Rout：补全倍率 / 输出倍率
• Rmodel：模型倍率
• Rgroup：分组倍率

这正对应很多 OneAPI / NewAPI 系统里最常见的基础扣费表达。

2. 纳入缓存后的计费公式

如果平台支持缓存命中折算，那么更准确的形式应该写成：

Quota_cache = (Tuncached + Tcached × Rcache + Tout × Rout) × Rmodel × Rgroup

其中：

• Tuncached：未命中缓存的输入 Token
• Tcached：命中缓存的输入 Token
• Rcache：缓存倍率

这条公式比"输入 + 输出 × 补全倍率"更完整，因为它能解释：为什么同样是 10 万输入 Token，有的人扣得很多，有的人扣得很少------差别往往就在缓存命中率。

3. 纳入 Thinking 的计费公式

如果模型开启了 thinking / reasoning，那么输出侧通常还会多出一部分推理 Token，于是可以进一步写成：

Quota_thinking = (Tuncached + Tcached × Rcache + (Tvisible + Tthink) × Rout) × Rmodel × Rgroup

其中：

• Tvisible：用户可见输出 Token
• Tthink：thinking / reasoning 额外产生的 Token

这条式子能够解释一个很常见的现象：

为什么有些问题看起来不复杂，但一开 reasoning，平台消耗会立刻明显上升。

因为从平台视角看，它并不关心这些 Token 是"用户看见的回答"还是"模型内部思考过程"，只要上游按 Token 收费，平台就必须把它折算进去。

---

十三、仅比较倍率数字的局限性

这一点其实是中转站里最容易踩坑的地方。

很多用户会把不同平台的倍率数字直接横向比较，比如：

• A 站某模型倍率 = 1
• B 站某模型倍率 = 10

于是就得出"B 站贵了 10 倍"的结论。

但这个结论常常并不成立，因为你忽略了另一个变量：平台余额单位本身是什么。

真正应该比较的，不是"倍率的绝对值"，而是单位 Token 最终折合成了多少真实货币成本。

可以把它抽象成：

实际输入单价 ≈ 余额单位价值 × Rmodel × Rgroup
实际输出单价 ≈ 余额单位价值 × Rout × Rmodel × Rgroup

如果再把充值口径算进去，那么跨平台比较时，更接近现实的判断方式是：

实际人民币成本 ≈ 充值汇率 × 平台倍率体系 × Token 消耗结构

这也就是为什么会出现这样一种情况：

• 平台 A 的倍率数字小；
• 但平台 A 的"每 1 元可兑换余额"也更少；
• 最终折算下来，反而并不便宜。

4. 缓存率对跨平台比较的影响

很多人在跨平台比较价格时，还会漏掉一个非常关键的变量：缓存率（或缓存命中率）。

因为平台展示给你的往往只是：

• 充值汇率；
• 倍率；
• 标称 Token 额度。

但你真正"花出去"的有效成本，还取决于请求里有多少输入命中了缓存。

在编程场景里，如果是固定账号持续使用，例如自己用 Max 或稳定拼车，常见会出现 90% ～ 95% 的输入 Token 走缓存 。换句话说，缓存 Token 数可能达到写入 Token 数的 10 ～ 20 倍 。这时，实际费用往往不会等于"全部按普通输入 Token 原价结算"，而更接近 按标称 Token 价格的 80% ～ 85% 来理解。

反过来说，如果某个中转站表面倍率不高、兑换比例也不差，但因为号池轮询、账号频繁切换或缓存技术做得一般，导致你的缓存率明显偏低，那么你的实际单位成本就会上升。于是就会出现一种常见感受：

不是平台给的 Token 数是假的，而是因为缓存率低，同样的 Token 更"不抗用"。

从实践上看，可以把常见模式粗略分成三类：

• 固定账号 / 固定会话型：缓存率理论上最接近官方，适合长期连续编程。
• 按次数限额型产品：例如部分 IDE / 工具订阅，通常不展示缓存 Token，也就很难直接谈缓存率。
• 号池轮询反代型 ：用户缓存率波动最大，是否能做到 80% 以上，很大程度取决于中转站自己的缓存与路由技术。

所以，跨平台比较时，更接近真实的判断方式应该是：

实际人民币成本 ≈ 充值汇率 × 平台倍率体系 × Token 消耗结构 × 缓存率修正

或者换句话说：

比较价格，不能只看"¥多少 = $1" 或倍率数字，还要看这个平台能不能把你的高重复上下文真正缓存住。

所以，倍率只能在同一平台内部比较模型相对贵贱，不能脱离充值规则和缓存率去跨平台直接比较。

---

十四、官方成本与平台配额的对照示例

假设某次请求中：

• 未缓存输入 Tuncached = 20,000
• 缓存输入 Tcached = 80,000
• 可见输出 Tvisible = 5,000
• thinking Token Tthink = 3,000

再假设上游官方价格是：

• 输入 Pin = 2.50 / 1M
• 缓存输入 Pcache = 0.25 / 1M
• 输出 Pout = 15 / 1M

那么按官方计费估算：

Cost = 20000/1,000,000 × 2.50
     + 80000/1,000,000 × 0.25
     + (5000 + 3000)/1,000,000 × 15

计算后得到：

Cost = 0.05 + 0.02 + 0.12 = 0.19 美元

现在假设某个中转站进一步定义：

• Rcache = 0.1
• Rout = 6
• Rmodel = 1.2
• Rgroup = 1

那么它的配额消耗就可能写成：

Quota = (20000 + 80000 × 0.1 + (5000 + 3000) × 6) × 1.2
      = (20000 + 8000 + 48000) × 1.2
      = 76000 × 1.2
      = 91200

这时你在平台面板里看到的，可能就不是"0.19 美元"，而是"扣除了 91200 点额度"。

单位虽然变了，但底层逻辑没有变：

• 官方在算货币成本；
• 中转站在算平台额度；
• 倍率就是两者之间的折算桥梁。

---

十五、倍率体系的可靠性判断

如果把"怎么理解倍率"进一步落到实践层面，那么判断一个平台是否靠谱，至少要看三件事。

1. 是否对应官方成本结构

一个靠谱的平台，哪怕不用"美元单价"直接展示，也至少应该能让你看出：

• 输入怎么算；
• 输出怎么算；
• 缓存是否单独折算；
• thinking 是否有额外消耗。

如果这些都说不清，只给一个笼统倍率数字，那透明度通常不够。

2. 是否公开模型计费明细

正规的中转站，通常会公开：

• 模型倍率；
• 补全倍率；
• 分组倍率；
• 余额兑换关系；
• 渠道说明或模型说明。

如果平台只有一个模糊的"倍率很低"，却没有明细页、模型页或计费页，那么风险通常更高。

3. 低价是否具备合理性

如果某个平台价格长期明显低于官方理论成本，就要提高警惕。因为这往往意味着它可能依赖：

• 逆向网页接口；
• 不稳定代充渠道；
• 混合池或不透明转发；
• 随时可能失效的临时资源。

这种平台也许适合测试或体验，但未必适合生产环境。

---

十六、常见误区辨析

为了避免混淆，最后把几个最常见的误区集中说清楚。

1. 缓存命中并不意味着整体成本显著下降

缓存只会降低命中的输入部分，不会把未命中的输入和输出一起变便宜。真正昂贵的部分，很多时候依然是输出和 reasoning。

2. 补全倍率并非任意设定的参数

它通常对应的是官方"输出比输入更贵"的现实，只不过平台把这种差异，用一个更容易运营配置的比例表达出来。

3. Thinking 并非凭空增加的收费项

thinking 本质上仍然是 Token 消耗，只不过这些 Token 来自模型的推理过程，因此会额外抬高输出侧成本。

4. 同名模型倍率差异不必然意味着不合理收费

也可能是渠道不同、QoS 不同、汇率不同、补贴策略不同。倍率差异本身并不自动等于平台不正规。

5. 跨平台比较不能脱离充值规则

跨平台比较时，真正重要的是"最终单位 Token 折合多少钱"，而不是后台写了一个多大的倍率数字。

---

十七、可直接使用的四条核心公式

如果你只想留下最有用的结论，那么记住下面四条就够了。

1. 官方普通模式公式

Cost_normal = 未缓存输入 / 1,000,000 × 输入单价
            + 缓存命中输入 / 1,000,000 × 缓存单价
            + 可见输出 / 1,000,000 × 输出单价

2. 官方 Thinking / Reasoning 模式公式

Cost_thinking = 未缓存输入 / 1,000,000 × 输入单价
              + 缓存命中输入 / 1,000,000 × 缓存单价
              + (可见输出 + 思考 Token) / 1,000,000 × 输出单价

3. 中转站基础倍率公式

Quota_basic = (输入 Token + 输出 Token × 补全倍率)
            × 模型倍率 × 分组倍率

4. 中转站完整配额公式

Quota_full = (未缓存输入 + 缓存输入 × 缓存倍率 + (可见输出 + 思考 Token) × 输出倍率)
           × 模型倍率 × 分组倍率

这四条公式，基本就能把"官方怎么计费"和"中转站为什么这么扣费"完整串起来。

---

十八、结论：从 Token 到中转站的理解路径

整件事最值得记住的，其实就是一句话：

官方计费看的是 Token 结构------输入、缓存输入、输出，以及 thinking 带来的额外 Token；中转站做的，则是在这套结构之上，再叠加模型倍率、补全倍率、分组倍率和缓存倍率，把官方成本映射成自己的余额与配额规则。

所以，理解大模型计费最好的路径永远是：先理解 Token，再理解官方价格，再理解中转站倍率。顺序一旦反过来，很多概念就很容易越看越乱。

写在最后🧪

这里是言萧凡的 AI 编程实验室 。 我会在这里持续记录和分享 AI 工具、编程实践 ，以及那些值得沉淀下来的高效工作方法。 不只聊概念，也尽量分享能直接上手、能够复用的经验。 希望这间小小的实验室，能陪你一起探索、实践和成长。 2026 年，一起进步。