上个月月底对账的时候，我盯着后台的费用明细看了很久。团队在跑一套内部知识问答服务，日调用量峰值在二十多万次，日常也有七八万次，用的是某云厂商大模型服务平台的按量付费。账单出来那一刻我的第一反应不是贵，而是"这个数跟我自己算的差了快三成"。差在哪儿？重试、上下文累积、还有我没算进去的推理型模型的思考 Token。刚好平台在推预付费的Token 资源包，销售给的折扣看起来挺香，我就买了一个中等面额的，然后花了两个晚上把账重新算了一遍。

这篇不替任何平台站台，也不做购买推荐，只做一件事：把"预付费 Token 包到底划不划算"从一句模糊的感觉，拆成几个能填数字的公式。Token 计价的坑不在于单价高不高，而在于你用哪种口径去比价。你会发现，同样一个"八折"，落在不同的调用结构上，有的团队是实打实省下两成，有的团队反而比按量付费贵了一截。文中出现的金额、单价、用量全部是测算示例，不是任何平台的真实报价，你把它当成一套算账方法论就行，数字换成你自己的。

1. 把"划算"拆成三个可以量化的变量

1.1 Token 计价的三层结构，决定了你不能只看一个单价

很多人比价的方式是打开定价页，看"每百万 Token 多少钱"，然后拿预付费包的折算单价去减，得到一个百分比，结束。这个做法错得很彻底，因为大模型 API 的计价从来不是一个数字，而是一个三维结构：模型档位 × 上下文长度区间 × 输入输出方向。这三个维度里任何一个变化，你的加权平均单价都会跳。

先说模型档位。同一个平台上，轻量档、标准档、旗舰档的单价可能差十倍甚至更多。如果你的业务是"意图识别 + 简单改写"，跑在轻量档上，那你的实际加权单价可能只有旗舰档的十分之一。这种情况下你去买一个按"旗舰档单价"宣传折扣的资源包，看起来折扣力度大，实际上你的用例根本吃不到那个档位，包内额度抵扣时按实际调用模型的单价扣，你省下的绝对值远小于宣传数字。

再说上下文长度区间。这是最容易被忽略的一刀。多数平台的定价表上会把上下文切成几段，比如 0 到 32K 一档、32K 到 128K 一档、128K 以上一档，价格逐档递增。关键在于，很多平台是"整单晋级"计价，不是"超出部分单独计价"。也就是说，一个 33K 的请求，不是前 32K 按低价、后 1K 按高价，而是整个 33K 全部按高价档算。你的 RAG 检索如果习惯性塞十个文档块进去，很容易把一批原本 20K 的请求推到 40K，单价直接翻倍，而这个翻倍在你买包之前完全无感。

最后是输入输出方向。输入 Token 便宜，输出 Token 贵，这个比例在业内常见区间是 1 比 2 到 1 比 4。有些平台做预付费包的时候，抵扣规则是按"金额"抵扣的，那没问题；但也有按"Token 数量"抵扣的包，这时候输入输出比例就成了决定因素——你的业务如果输出占比高（比如长文生成、报告撰写），Token 数量型包的性价比会明显低于金额型包。

提示：比价前先确认一件事——你买的包是"金额型"还是"Token 数量型"。金额型包抵扣的是费用，输入输出按各自单价扣，逻辑简单；Token 数量型包抵扣的是 Token 计数，输入输出可能按不同系数折算，一定要翻到计费说明的那一页看清楚折算比例。

1.2 预付费包的真实折价率，藏在有效期和发放方式里

资源包宣传的"省 20%"，通常是这么算出来的：包价 ÷ 包内额度 = 折算单价，然后再除以按量付费单价。这个算法本身没错，但它默认了一个前提——你能在有效期内把额度用干净。用不干净，折价率就要打折。

举个具体的测算例子。假设你买了一个 6000 元的包，包内可用额度折算下来相当于按量付费 8000 元的量，账面折扣是 75 折。有效期 12 个月。你的月度按量消耗稳定在 500 元左右，那么 12 个月你能消耗掉 6000 元按量等价的量，只占包内容的 75%，剩下 25% 到期作废。这时候你的真实折扣是多少？你花了 6000 元，实际用掉了价值 6000 元（因为你的年消耗刚好是 6000 元按量等价），等于一分没省，还额外承担了资金占用和被平台锁定的风险。

更隐蔽的是"按月发放、当月清零"这种形态。有些包不是一次性给一大坨额度，而是每月 1 号发放固定额度，月底清零。这种设计对稳定型业务是友好的，对脉冲型业务则是灾难：某个月你做了一次推广，流量翻三倍，月度额度两下用完，超出的部分走按量付费；下个月流量回落，额度用不完，清零。一年下来你会发现，你付了全年的包钱，实际只用了六成的量，另外四成被"平均"掉了。

所以第一个可以量化的变量是额度消耗率，定义为"有效期内实际消耗的额度 ÷ 包内总额度"。这个值低于某个阈值（我的经验线是 85%），预付费的账面折扣基本就被吃干净了。算法很朴素：

真实折扣率 = 包价 ÷ (按量等价额度 × 额度消耗率)

代入上面的例子：6000 ÷ (8000 × 0.75) = 1.0，也就是原价。你感受一下这个落差。

1.3 一个必须乘进去的系数：失败请求和重试放大

第三个变量最容易被漏掉，但它在工程上极其常见。你的账单里，有多少 Token 是花在最终没有产出有效结果的请求上的？包括超时重试、JSON 解析失败重跑、内容审核不通过重生成、以及流式输出中断后的整段重发。

我做了一次抽样统计，在没做任何优化的状态下，团队的服务里有效请求的 Token 占比只有 78%，剩下的 22% 全是"无效消耗"。这个比例在业务早期很常见，因为大家都在忙着跑通功能，没人管重试策略。它对预付费测算的影响是：你按"有效请求量"算出来的月度消耗，会系统性低估真实消耗两成左右。低估导致的直接后果是——你以为自己一年能用完的包，实际上半年就用完了，然后你不得不在额度耗尽后继续按量付费，或者再买一个包，资金效率反而变差。

反过来说，如果你的无效消耗比例很高，那说明真正该做的事不是买包，而是先把重试逻辑和失败兜底做好。把这 22% 压到 8%，比任何折扣都值钱。我在买包之前先做了一轮失败治理，把超时重试改成带抖动的指数退避、把 JSON 输出改成结构化输出模式、把流式中断改成可续传，月度账单直接降了一截，然后再去谈包，谈判的基础数字才是真实的。

这三个变量——加权平均单价、额度消耗率、有效请求占比——构成了后面所有测算的骨架。缺任何一个，算出来的结论都是假的。

2. 我拉了一份真实账单，把用量拆到每千 Token

2.1 从网关日志反推月度消耗的四个步骤

比价的前提是有自己的真实数据。如果你的调用全部走平台控制台，那你只能看到总额，看不到结构，比价就只能靠猜。我的做法是在应用和模型服务之间加一层薄薄的自建网关，所有请求都过网关，日志落一份，这件事花了我半天时间，但后面所有的成本优化都建立在这份日志上。

具体四步：

第一步，在网关记录每次请求的元数据。需要的字段不多：时间戳、模型档位标识、输入 Token 数、输出 Token 数、是否命中缓存、是否重试、请求耗时、业务线标签。这些字段平台返回体里基本都有，直接落库就行。

第二步，按天聚合。用一张按天按模型档位分组的汇总表，算出每天的输入 Token 总量、输出 Token 总量、请求次数、平均单次输入长度。这张表跑一周，你就能看出业务的周期规律——工作日和周末的差异、白天和夜间的差异，这些决定了你需要的是"稳定额度"还是"弹性额度"。

第三步，分层计价。把每天的用量按上下文长度区间重新切一遍，因为整单晋级计价意味着你的费用不是"总 Token × 单价"，而是"各档位 Token × 各档位单价"之和。这一步必须逐个请求判断档位，不能拿平均值近似，否则误差会很大。

第四步，算出加权平均单价。公式是：月度总费用 ÷ 月度总 Token 数。这个数字才是你和预付费包比价时应该用的基准，而不是定价页上那个旗舰档的标价。

我把这套流程跑完之后，得到的结论有点反直觉：我们团队的加权平均单价，只有旗舰档标价的 34%。因为 80% 的请求跑在轻量档和标准档上，只有 20% 的复杂问答走了旗舰档。如果我拿旗舰档标价去对比资源包折扣，会严重高估自己的节省金额。

2.2 输入输出比例，决定了你该买哪种形态的包

把日志按输入输出拆开看，我发现了一个很有意思的分布：输入 Token 占总量的 82%，输出只占 18%。这个比例在 RAG 类应用里很典型——你每次都要把检索到的文档片段、系统提示词、对话历史一起塞进去，输入自然会膨胀。

这个分布对选购的影响是决定性的。假设输入单价是 1 个单位，输出单价是 3 个单位，那么我的加权单价是 0.82×1 + 0.18×3 = 1.36，而不是简单平均的 2。如果某个 Token 数量型的包在折算时对输入输出采用 1:1 的抵扣系数，那我实际上是亏的——我消耗的输入 Token 便宜，它按统一系数扣，等于我拿贵的额度去抵了便宜的量。

所以买之前一定要做这张表：

这张表最后一行是关键：用简单平均去估算成本，误差可能接近一半。我见过不少团队就是在这里算错的，然后拿着错误的基准去谈折扣，谈下来的数字看着漂亮，落地一算根本没省。

2.3 用一张表算出自己的盈亏平衡调用量

有了加权单价和额度消耗率，就可以算盈亏平衡点了。所谓盈亏平衡，指的是"买包和按量付费花的钱一样多"时的月度调用量。低于这个量，买包亏；高于这个量，买包省。

设：

• P= 包价
• V= 包内按量等价额度（用加权单价折算出来的金额）
• U= 你的月度按量消耗金额
• T= 有效期月数
• r= 额度消耗率

当U × T ≥ V时，理论上能用完；再乘上消耗率r，实际能用完的条件是U × T × r ≥ V。把它解出来：

盈亏平衡月消耗 U* = V / (T × r)

代入一组示例数字：包价 6000 元，包内按量等价额度 8000 元，有效期 12 个月，消耗率 0.9。那么U* = 8000 / (12 × 0.9) = 741 元/月。也就是说，你的月度按量消耗必须稳定在 741 元以上，买这个包才不亏。低于这个数，你付的 6000 元里有相当一部分是在买"用不完的额度"。

我建议把这个公式做成一张小表，把不同的包面额、不同的有效期、不同的消耗率都代进去，形成一个矩阵：

看到没有，同样一个 2 万元的包，消耗率从 95% 掉到 50%，盈亏平衡点从 2456 元涨到 4667 元，接近翻倍。这就是为什么我一直强调消耗率是核心变量——它不是一个"锦上添花"的修正项，它是能直接把结论翻转的项。

3. 决定买不买的分水岭：哪些用量适合预付费

3.1 稳定基线用量和脉冲式流量，要分开对待

做完上面的测算，我意识到一个更本质的问题：预付费包本质上是一种用量承诺，它适合的是"可预测的稳定基线"，而不是"全部用量"。

一个健康的采购结构应该长这样：把过去 12 周的周用量拉出来，找到那个"最差周也能达到"的水平线，这条线以下的量用预付费覆盖，线以上的波动部分继续走按量付费。这样你既吃到了基线的折扣，又不用为峰值多买额度。

我自己的数据是：周用量在 4200 到 9800 元之间波动，中位数 5600，最低周 4200。那么合理的预付费覆盖量大约是 4200 × 4.3 ≈ 18000 元/月的等价额度，对应的实际按量消耗按消耗率折算，取一个略低于这个数的包面额。剩下的 30% 到 50% 的波动量，老老实实按量付费。

这套"基线包 + 弹性按量"的组合，比"全量买包"的确定性高得多。因为业务增长是不可预测的，如果全量买包，业务没起来，额度作废；业务暴涨，额度不够用，还得临时补包，而临时补包通常拿不到好折扣。

3.2 上下文长度分档，可能让你的包一夜之间性价比崩塌

前面提过整单晋级计价。这个机制对资源包的影响是放大器级的。举一个我听来的真实场景（细节做了模糊化）：某团队做合同审查，原本每个请求塞 3 个条款片段，平均 12K 上下文，跑在低价档。后来产品要求"提高召回率"，把片段数从 3 个提到 12 个，平均上下文涨到 45K。这一改动让所有请求从低价档跳到了高价档，单价翻倍，月度消耗直接超了预算的三倍。

他们当时手里有一个按"低价档单价"估算购买的资源包，结果包内额度两周就扣完了，剩下的时间全部按量付费，整体成本反而比不买包更高——因为包钱已经付了，等于是双重支出。

这件事给我的教训是：买包之前必须确认你的请求长度分布是稳定的。如果你正在做检索策略优化、提示词精简、历史对话截断这类工作，上下游的任何改动都可能让请求长度大幅漂移，那么在这个阶段买长期包是不明智的，先按量跑三个月，等长度分布稳定下来再说。

反过来，如果你已经做了上下文压缩、历史摘要、分段检索，请求长度稳定在一个窄区间里，那预付费包的风险就小得多。稳定性本身就是折扣的一部分。

3.3 多模态、Embedding、精调不能混在一个包里算

还有一类坑，属于"账算对了但口径错了"。

大模型平台上的计费项远不止文本生成。图片输入按分辨率折算 Token，音频按时长折算，向量化（Embedding）单独计价，精调训练按 Token 计费且价格体系完全不同，有的平台还有专门的重排序模型、OCR 模型。这些计费项的单价差异很大，而且很多资源包只覆盖基础文本模型的调用，不覆盖 Embedding 和精调。

我做过一次分解，团队月度账单里 Embedding 占了 11%，但这个 11% 是完全无法用资源包抵扣的。如果你的业务里 Embedding 占比更高（比如大规模文档入库、语义检索为主的应用），那么资源包能覆盖的部分就更小，账面折扣要按覆盖比例再打折一次。

计算方式：

有效折扣 = 资源包覆盖部分的折扣 × 覆盖比例 + 未覆盖部分的原价 × (1 - 覆盖比例)

举个例子，包覆盖的那部分打了 75 折，覆盖比例 89%，那么整体有效折扣是 0.75 × 0.89 + 1.0 × 0.11 = 0.7775，也就是 78 折，而不是宣传的 75 折。差距不大但真实存在，如果你的 Embedding 占比是 35%，那有效折扣就变成 0.75 × 0.65 + 0.35 = 0.8375，折扣力度缩水一半。

注意：买包之前把过去三个月的账单按"计费项"拆一遍，标出哪些计费项能被资源包抵扣、哪些不能。这个动作花不了半小时，但能避免你按全量账单去估算折扣。

4. 买完之后才发现的五个坑

4.1 包内额度不锁定单价，模型升级后可能重新计价

这是我踩得最实在的一个坑。我一直以为买了包就等于"锁定了价格"，实际上多数平台的资源包锁定的是额度，不是单价。当平台上线新版本模型、调整定价体系，或者你自己把业务从旧模型切到新模型时，额度抵扣的单价是按当前的定价页执行的。

这意味着什么？假设你买包时旗舰档是每百万 Token 20 元，包内额度按这个价格折算。半年后平台上线了更强的新档位，定价 40 元，你为了效果把业务切过去，那么同样的额度，能抵扣的 Token 数直接减半。包的账面价值没变，但购买力被稀释了。

这个风险无法完全规避，但可以缓解：优先覆盖那些"价格体系已经稳定、短期内不会大改"的中低档模型。轻量档和标准档的定价通常比较稳定，因为它们已经打到成本线附近了；旗舰档和推理型档位迭代快，价格波动大，这部分用量用按量付费更灵活。

4.2 缓存命中率会把账面折扣吃掉一半

提示词缓存是个好东西，命中缓存的部分单价通常只有正常输入价的 10% 到 25%。但它在和资源包组合时会产生一个微妙的效应：包内额度是按标准价抵扣的，而缓存命中的请求本来就应该享受低价。

这里要看平台的具体实现。如果资源包抵扣的是"实际产生的费用"，那没问题，缓存命中就是少扣。但如果资源包抵扣的是"按标准价折算的额度数量"，那就意味着你为缓存命中的请求付出了过高的额度消耗，等于白买了缓存优化的收益。

我实测下来，系统提示词固定、检索结果高度重复的场景，缓存命中率能到 40% 以上。这么高的命中率下，缓存带来的节省可能比资源包折扣还大。这时候正确的策略是：先把缓存用满，再考虑包。因为缓存的节省是确定性的、无资金占用的、随用随省的，而包的节省是有条件的。

4.3 并发上限和额度是两回事，别指望买包能提额

很多人（包括我一开始）会误以为买大额资源包能顺带提升调用配额。不会。额度是"你能花多少钱"，并发限制是"你每分钟能发多少请求"，这两个是完全独立的维度。平台的 RPM（每分钟请求数）和 TPM（每分钟 Token 数）限制，通常按账号等级或者单独申请提额，跟你买没买包无关。

这一点在做容量规划时特别重要。你的业务峰值如果被 TPM 卡住，买再多包也没用，请求照样被限流，然后走重试，重试又消耗 Token，形成恶性循环。我在压测阶段就遇到过这个问题：额度充足，但 TPM 到顶，客户端疯狂重试，实际有效吞吐上不去，账单反而因为重试涨了 30%。

解决办法是提前申请提额，或者做客户端侧的令牌桶限速加排队，让请求平滑发出，而不是集中爆发。这块的工程投入比买包更值得。

4.4 退款、结转和抵扣顺序，条款里都写着但没人看

三个必须提前问清楚的问题：

第一，未使用的额度能不能退。多数平台的资源包一经购买不支持退款，或者只支持在极短时间内无理由退。这意味着你买的包本质上是一笔预付的沉没成本，买之前必须按最悲观的用量估算。

第二，额度能不能跨周期结转。如果包是"每月发放、当月清零"，那额度不能结转，你必须按单月的最低用量去买，不能按年均值买。这个差别在季节性业务上能差出好几千块。

第三，抵扣顺序是什么。常见顺序是：免费额度 → 资源包 → 按量付费。这个顺序意味着免费额度会先被消耗，听上去是好事，但如果你的免费额度有独立的有效期，先消耗它反而可能造成浪费。另外有些平台的资源包分"通用包"和"专属包"，专属包只能抵扣指定模型，抵扣顺序会更复杂。我建议直接在测试环境发一笔小额请求，然后看账单明细里扣的是哪一项，比读文档快。

4.5 到期清零那天，你不会有任何提醒

最后一个坑是运营层面的。资源包到期前，平台通常会在控制台显示剩余额度，但不会主动给你发强提醒，尤其是按月清零的那种小额包。我有个朋友（真的不是我）买的包在第三个月忘了续，业务照跑，全走按量付费，一个月下来账单翻了一倍多，等到发现已经过去两个月。

我的做法很简单：把包的到期日写进日历，提前两周提醒；同时在网关里加一个监控指标，每天统计"资源包抵扣金额占总费用比例"，这个比例如果突然从 90% 掉到 10%，说明包用完了或者失效了，立刻告警。这个监控加起来的代码量不到五十行，但它是所有成本治理里性价比最高的一个。

5. 一套可以抄走的测算模板

5.1 表结构：三张表搞定全部输入

我把这套测算固化成了三张表，任何人都能填。

第一张是用量事实表，从网关日志直接导出：

第二张是价格表，从定价页手工录入，一个季度更新一次：

第三张是包参数表，记录你手上所有候选包的规格：

三张表凑齐，剩下的就是纯计算。

5.2 用一段脚本跑敏感性分析

手工算一个数字没意义，你要看的是"在不同假设下结论稳不稳"。这段脚本可以直接跑，改动里面的常量就能用：

import itertools # 价格表：档位 -> (输入单价, 输出单价, 缓存输入单价) PRICE = { "light": (0.5, 1.0, 0.1), "std": (2.0, 6.0, 0.4), "flag": (8.0, 24.0, 1.6), } # 你的实测结构：各档位占比、输入输出占比、缓存命中率 MIX = {"light": 0.55, "std": 0.30, "flag": 0.15} IN_RATIO, OUT_RATIO = 0.82, 0.18 CACHE_HIT = 0.25 def weighted_unit_price(mix=MIX, in_r=IN_RATIO, cache_hit=CACHE_HIT): """算出每 Token 的加权平均成本（单位：元/千Token）""" total = 0.0 for tier, share in mix.items(): p_in, p_out, p_cache = PRICE[tier] # 输入部分：命中缓存按缓存价，未命中按标准输入价 in_cost = (cache_hit * p_cache + (1 - cache_hit) * p_in) * in_r out_cost = p_out * OUT_RATIO total += share * (in_cost + out_cost) return total def break_even(pack_price, pack_value, months, consume_rate): """盈亏平衡的月消耗金额""" return pack_value / (months * consume_rate) def real_discount(pack_price, pack_value, months, monthly_spend, coverage, consume_rate): """真实折扣率，1.0 表示与按量持平""" usable = min(pack_value, monthly_spend * months * consume_rate) * coverage return pack_price / usable if usable > 0 else float("inf") if __name__ == "__main__": base_unit = weighted_unit_price() print(f"加权平均单价: {base_unit:.4f} 元/千Token") # 敏感性分析：月度消耗 × 消耗率 × 覆盖比例 spends = [300, 600, 1000, 2000, 4000] rates = [0.5, 0.7, 0.9, 1.0] coverages = [0.6, 0.85, 1.0] print(f"\n{'月消耗':>8} {'消耗率':>6} {'覆盖率':>6} {'真实折扣':>8} 结论") for s, r, c in itertools.product(spends, rates, coverages): d = real_discount(6000, 8000, 12, s, c, r) verdict = "值得" if d < 0.9 else ("持平" if d < 1.0 else "不划算") print(f"{s:>8} {r:>6.2f} {c:>6.2f} {d:>8.3f} {verdict}")

这段脚本的输出会让你对"折扣"这个词彻底祛魅。在月消耗 300 元、消耗率 0.5、覆盖率 0.6 的组合下，真实折扣能到 5 以上，也就是你花了五倍的钱去买同样的量。

我的经验阈值是：真实折扣率 < 0.88 才值得买。0.88 到 0.95 之间属于"买了也没错，但意义不大"，超过 0.95 就是纯粹的资金占用，不如把这笔钱留着做工程优化。

5.3 结论之后的动作：先优化，再采购

算完这一圈，我最终没有把所有用量都塞进包里，而是做了一个组合：基线用量买中额包，弹性用量走按量，同时把工程侧的三个优化先做完——失败重试治理、上下文压缩、提示词缓存启用。

顺序很重要。如果先买包再优化，你优化下来的用量会变成"用不完的额度"，白省了；如果先优化再买包，你是拿优化后的真实基线去谈，谈下来的量刚好匹配，不会有浪费。前者是我第一年犯的错，后者是我现在的做法。

还有一个心得：谈包的时候把你自己的数据摆出来。你告诉对方"我的加权平均单价是这个数，输入输出比例是这个比例，缓存命中率是这个水平，我的基线用量是这么多"，对方给的条件会比"我要一个折扣"具体得多。这不是什么谈判技巧，纯粹是因为你把问题定义清楚了，双方在同一个口径上对话。我这次拿到的条件，比最初报价好了不少，靠的就是那份拆到每千 Token 的明细表。

如果你现在正准备买第一个包，我的建议是：别急着买大的。先买一个最小面额、最短有效期的包，跑一个月，看额度消耗曲线和你的预测差多少。这个"试买"的成本不高，但它给你的是真实数据，比任何测算模型都靠谱。第二个月再按真实曲线去买，那时候你算出来的折扣，才是你能真正拿到手的折扣。