先看懂 token 与价目表
模型计费的单位是 token，而不是字数或请求次数。token 是文本被切分后的处理片段。Kimi 官方文档说明，一般英文文本中 1 个 token 大致相当于 3 到 4 个英文字符。中文与韩文等非拉丁文字切得更细，同样意思往往消耗更多 token。
价目表写的是每一百万 token 的价格，通常分三列。输入是你送进去的提示词与附加文档，输出是模型写回来的内容，缓存命中是重复发送与此前完全相同的前缀时适用的折扣价。像智能体这类反复送入相同指令与相同代码库的工作，缓存命中所占比重会更大。
有一点容易误读：表上的价格是每百万 token 的单价，不是调用一次要付的钱。账单永远等于单价乘以数量，而本文谈的正是数量这一侧发生的事。
三个模型的官方单价差多少
以 2026 年 7 月 26 日各家官方文档所载为准，数据如下。三者的上下文窗口都在百万 token 量级，能处理的工作规模相当。
只看单价，次序很清楚：Fable 5 是 Kimi K3 的 3.3 倍，而真正精确的是输入与输出适用同一个倍数；与 Sol 相比则是输入 2 倍、输出 1.7 倍，差距略窄。值得盯住的是缓存命中一列，三家都设为各自输入价的 10%。也就是说缓存会让三者一起变便宜，却不会让其中任何一个相对占优。很多人一想到成本就先想到缓存，但在这道比较题里它给不出答案。
| 模型 | 输入（1M） | 缓存命中（1M） | 输出（1M） | 上下文 |
|---|---|---|---|---|
| Claude Fable 5 | $10 | $1 | $50 | 100 万 token |
| GPT-5.6 Sol | $5 | $0.50 | $30 | 约 105 万 token |
| Kimi K3 | $3 | $0.30 | $15 | 1,048,576 token |
同样的文字，为什么 token 数会不同
分词器是把文本切成 token 的规则。规则一变，同一句话的 token 数就会变。Anthropic 在官方价目文档中写明，Claude 4.7 及之后的模型与 Mythos Preview 使用新的分词器，对同样文本会多产生约 30% 的 token，并说明这是为换取性能而做的取舍。
这 30% 是与什么比较，必须说清楚：它是与 Anthropic 自家上一代分词器相比的数字，跨厂商的 token 数官方对比数据并未公开。因此不能把这个数字直接拿去做跨公司的成本乘算。
但落到实务上的结论依然明确：价目表上的倍数是支出差距的下限，而不是上限。既然同一份文档在不同模型上可能计为不同数量，真正的比较办法就是把同一项工作各跑一次，再看各家控制台记录的用量。三家都会随响应返回 token 用量，这个核对并不难做。
有一段长度区间，费率本身会变
OpenAI 对 Sol 设有基于长度的加价。输入一旦超过 272,000 token，整个请求按输入 2 倍、输出 1.5 倍计费，折合每百万 10 美元与 45 美元。关键在于这不是只对超出部分加价，而是对整个请求生效。
这个区间比想象中容易触及：让模型读完整个代码仓库做重构，或者把一批长会议记录与合同一次性送进去，都属此类。相对地，Fable 5 与 Kimi K3 的价目表没有长度分档。Anthropic 写明整个 100 万 token 上下文都按标准单价计费，Kimi K3 的价目表也只对 1,048,576 token 的上下文列了一行。
所以同样这三个模型，排序会随工作形态而变。跑大量短请求时，价目表的次序保持不变；而在一次推入数十万 token 的智能体工作中，Sol 的实际单价会向 Fable 5 靠拢。
能否一次到位——重试会乘在单价上
有一份评测给三个模型各下同一条提示词、只跑一次，再比较产出。人一旦中途介入，衡量的就不再是模型本身，所以用单条提示词作为控制条件。三项任务在相同条件下进行：城市交通模拟器、智能体 UI、网页格斗游戏。
结果分了高下。交通模拟器中，Fable 做出了车辆通过路口的物理处理以及信号灯表现；Sol 把车画成方块且没有碰撞处理，车辆彼此叠在一起。Kimi 居中：道路表现优于 Sol，重叠问题则与 Sol 相仿。智能体 UI 中 Fable 最好、Kimi 次之，Sol 的连接线接错了位置。评测者对 Sol 的判断是，缺少自我核对完成度并回头修正的那一轮循环。
这一点正好接回成本。结果若不能一次做对，就得重跑，而每一次重跑都会重新计入输入与输出。同一项作业再跑一次，便宜模型的实际单价就翻倍。3.3 倍的差距大约要多试三次才会被抹平，所以便宜的一侧仍有相当宽的优势区间；但照价目表算出的节省，并不会原样兑现。
还可以补充一点：同一位评测者发现，即便是同一个模型，经由不同的执行工具运行，产出的完成度也有肉眼可见的差别。这正是换模型之前先检查现有执行环境的理由。
那么该怎么选
先弄清自己的工作会撞上哪一项。单次请求的输入是否逼近 272,000 token？是否频繁重复送入相同指令、以致缓存占比很高？结果是拿来就用，还是要改上两三次？这三问有了答案，选择就变成一道算术题。
举个例子。一次不带缓存、输入 20 万 token、输出 2 万 token 的作业，Fable 5 是 2 美元加 1 美元，共 3 美元；Sol 是 1 美元加 0.6 美元，共 1.6 美元；Kimi K3 是 0.6 美元加 0.3 美元，共 0.9 美元。到这里，表上的 3.3 倍原样成立。可一旦把输入提到 30 万 token，只有 Sol 进入加价区间，变成 3 美元加 0.9 美元、共 3.9 美元；同样的作业 Fable 5 为 4 美元，两者差距几乎消失。20 万 token 时 Sol 相对 Fable 的 1.9 倍优势缩到 1.03 倍，而与同样作业只需 1.2 美元的 Kimi K3 之间，差距从 1.8 倍拉大到 3.3 倍。次序并未颠倒，但照价目表算出的节省，在这一区间蒸发殆尽。
如果用的是订阅制，还有一条判断标准：当前模型的用量若还有余，就没有更换的理由；反之若额度经常见底、每次都要等上几个小时，用更便宜的模型去补这些空档就很划算。无论哪种情况，依据都是自己的使用记录，而不是价目表。
组织还要再看一件事。返工次数不只取决于模型，也取决于指令给得是否精确、是否有验证结果的环节。同一个模型把重试减半，效果等同于把单价降到三分之一——通常比换模型更便宜也更快。