「你的账单单位可能是假的」：token 不是标准计量单位，比价要看 $/task 不是 $/token

← 返回技术博客

一个反直觉的事实正在反复上演：大模型 API 的单位 token 单价一路下跌，可很多团队的 AI 账单不降反升。

原因很多（上一轮我们聊过 Agent 的「Tokenmaxxing」会把消耗量放大）。但还有一个更隐蔽、也更被忽略的根因——你用来比价的「单位」本身，可能根本不可比。

token 不是度电、度斤那样的标准计量单位。它是一把「厂商自己定的尺子」，同一段话，在不同厂商的分词器（tokenizer）下会被量出不同的数字。尺子不一样，单价再低，也比不出真实成本。

一、token 不是标准计量单位：同一段话，数出不同的 token

我们从小被教「计量单位要统一」：一斤就是一斤，一度电就是一度电。但 token 不是。

大模型靠「分词器」把文本切成一个个 token 再计费。每家厂商的分词器是自己训练的，规则完全不同：

OpenAI 用 tiktoken 系列；
Anthropic、Google 各自有专有分词器；
国产模型又是一套中文友好的切法。

结果就是：同一段中文（甚至同一段代码），丢给不同模型，切出来的 token 数量可能差出 20%–40%。 行业公开评测里反复出现一个现象——某些闭源模型在「同样的任务」上，表面牌价只比竞品贵约 2 倍，但因为它的分词器把同一段内容「数」出更多 token（有评测把这种现象叫 tokenizer tax，甚至观察到同一段文本在不同模型间有约三成的「分词损耗」），真实账单能贵出 3–5 倍。

换句话说：「每百万 token 单价」前面的数字，分母用的是各家自己的尺子。 你拿 A 家的尺子和 B 家的尺子比单价，等于拿「厘米」和「英寸」比长短——数字越小，不代表真的更省。

二、输出 token 才是大头：输出通常是输入的 4–10 倍

更坑的是，token 单价还分「输入」和「输出」两本账，而且输出贵得多。

行业通行规则是：输出 token 单价通常是输入的 2–5 倍。原因也好理解——模型每生成一个字都要重新算一遍注意力，成本高。

而真实业务里，输出体积往往数倍于输入：

让模型写一份报告，你给 200 字指令，它回你 2000 字；
让 Agent 跑一个多步任务，上下文越滚越大，最后吐出来的汇总、日志、结构化 JSON 可能比原始 prompt 大一个数量级；
代码生成、长文翻译、文档摘要，天然是「小进大出」。

所以「输入单价很便宜」常常是个假象。压住账单的关键，是压输出——而输出恰恰是大多数比价页面最不显眼的那一行。

三、缓存、批次、长上下文：隐形的三道折/扣

除了尺子和输入输出，还有三道「看不见的变量」，让「单价」和「实付」之间出现巨大落差：

提示缓存（prompt caching）：把反复出现的系统提示、知识库上下文缓存后，命中缓存的部分通常打 5–9 折甚至更低；没命中就全价。同一套 prompt，会不会用缓存，成本能差出几倍。
批次（batch）折扣：非实时、可延后排队的请求，很多平台给约 5 折；但实时链路用不了。
长上下文跳价：超过某个上下文窗口阈值（比如 128K、200K），单价可能突然跳一档。你以为用的是「标准价」，其实已经踩进「长上下文档」。

这三道变量叠加起来，才构成你账单上真正的数字。而比价页面上那个孤零零的「¥X / 百万 token」，往往只代表了「最理想条件下、输入、不缓存、短上下文」的极值——它几乎永远不等于你会付的钱。

四、所以正确的比价单位是什么？—— $/task 不是 $/token

行业里越来越形成一个共识：别比 $/token，比 $/task（完成一个真实任务花了多少钱）。

同样是「帮我审完一份 50 页合同」，A 模型牌价低但分词器把合同数出更多 token、输出又长，实付可能比 B 模型还高；
同样是「跑通一个 Agent 工作流」，用不用缓存、给不给 max_tokens 上限、上下文收不收敛，成本能差出一个数量级。

真正该问的是：「我这个活儿，在你们这儿做完，到底要花多少？」 把单价、分词器、输入/输出比、缓存命中率、上下文长度全部折算进一个任务的总价，才有可比性。

这也解释了为什么「越比越便宜、账单越贵」：你比的是尺子不一样的单价，付的是真实任务的总价。

五、Yady 怎么把「不可比」变成「可预期」

我们改不了上游模型的分词器（那是模型本身的客观事实），但我们可以不让「尺子不一样」变成你的成本黑洞。Yady 的做法是三件事：

1）倍率透明、不玩「换把尺子」的把戏。 报价 = 方舟官方通道价 × 固定 1.27 倍，不随峰谷、不随分词器、不随调用时段浮动。上游涨我们就提前公告、不做静默变更，上游峰谷差价由我们承担。你看到的倍率，就是实付的倍率。

2）逐笔明细可导出，把「不可比」拆成「可归因」。 每一次调用都留一行账：时间、用了哪个模型、输入 token、输出 token、request_id、单价、金额。你拿这份明细，自己就能把任何任务的实际 $/task 算得一清二楚——不用猜，不用被审计时拿不出数。

3）额度上限 + 环境隔离，从机制上防失控。 New API 原生支持「按密钥设额度上限」「开发/生产环境用不同 key 隔离」。配合上一步的明细，你能在账单爆掉之前就看见苗头。

再叠加阶梯充值折扣（amount_discount：充 50 打 9.5 折、100 打 9 折、200 打 8.5 折、500 打 8 折），用量越大单价越可预期。

六、四步自检：把账单算到最后一分钱

第一步：别只看「每百万 token 单价」。 把输入价、输出价、缓存命中价分开问清楚，重点看输出那一行。
第二步：用你自己的真实任务测 $/task。 拿一段你业务里最典型的 prompt，跑一遍，记下输入输出 token 和实付，算「这个活儿花了多少」。
第三步：打开逐笔明细对账。 确认每一笔都能导出（时间/模型/token/request_id/单价/金额）。拿不出明细的平台，再便宜也先打个问号。
第四步：设额度上限 + 收口上下文。 给不同环境不同 key、设好上限；Agent 场景务必给 max_tokens、做上下文收敛——把「不可控的用量」挡在账单外面。

---

诚实边界先讲在前面：方舟当前仅激活 1 个模型（不掩饰），不承诺全网最低价；token 分词差异是上游模型的客观事实，我们不会为了「数字好看」去改写上游分词器。 我们能给的，是一条「倍率透明 + 逐笔可归因 + 额度可封顶」的干净链路，让你无论怎么比，都站在同一把尺子下。Agent 层怎么优化 token，是你应用层自己的事（见上一轮《Agent Tokenmaxxing》）。

把「比单价」换成「比任务总价」，你才会发现：真正省钱的，从来不是最便宜的那把尺子，而是最说得清的那张账单。