大模型 API 与订阅套餐比价指南：从定价规则到成本试算

做一个大模型 API 和订阅套餐的比价目录，这个想法其实一开始挺冲动的。我当时的处境是：项目要控制成本，得从一堆国内大模型厂商里选一个主力 API，结果把各个官网的价格页打开对着看了整整一个下午，越看越头大——有的按千 token 报价，有的按百万 token，有的输入输出分开计价，还有的打完折包装成"教育版""初创扶持版"。最要命的是，大多数比价网站只有一张静态价格表，而且口径经常和官网对不上，根本没法回答"我这个调用量到底该选哪家"这种具体问题。所以我干脆自己搭了一个比价目录，核心思路很朴素：把大模型 API 和订阅套餐的价格规则按官网原样建模，不手动抹平、不四舍五入，让规则自己说话。这篇就是我做完之后对选型、建模、踩坑的完整复盘，适合正在做模型选型、控成本的开发者和团队负责人参考。

1. 为什么比价目录要"按官网原样建模"而不是抄一张价格表

1.1 官方价格页的真实样子：口径混乱才是常态

我一开始以为比价就是收集数据，后来发现真正的难点是"数据结构化"。国内主流大模型厂商的计费口径五花八门，几乎没有两家是完全一致的。

拿最简单的一层来说，计费单位就各不相同。有的厂商在官网上写"每千 tokens 0.002 元"，有的写"每百万 tokens 2 元"，还有的用"每万 tokens 0.3 元"。如果做目录的人不统一单位，这本身就是个坑。更麻烦的是计费结构不同：有的模型只有一口价，输入和输出同价；有的输入一个价、输出一个价，输出往往是输入的三到五倍；还有的引入"缓存命中价"，说缓存命中的输入只要十分之一的价格；再有就是阶梯定价，当月调用量超过某个阈值后单价打折。

这还不包括订阅套餐那一侧。订阅套餐有的是按月度固定金额给"点数"，有的限制每日对话次数，有的干脆是"长上下文专用包"，里面按文档页数或者字符数折算。玩过一圈之后你就会发现，官网价格页上那个"原价"和实际结算之间，可能隔着好几条隐藏规则。

所以我做比价目录的第一条原则是：不能把官网价格抄到表格里就完事，得把每条价格后面的"规则"也抄下来。这就是我说的"按官网原样建模"——模型、单位、阶梯、缓存、活动、配额，全部分开记录。只有这样，后面才能拿它做真正的试算。

注意：任何比价目录如果不能解释"这个价格在什么条件下生效"，那它本质上只是一张旧截图。

1.2 直接抄表的问题：没法横向换算，更没法推演成本

假设现在有两家模型厂商，A 家写"输入 0.8 元 / 百万 tokens，输出 1.2 元 / 百万 tokens"，B 家写"输入输出统一 1.0 元 / 百万 tokens"。只看单价，A 的输出比 B 贵，但输入比 B 便宜。到底谁划算？这取决于你的业务输入输出比。

一个典型对话机器人的场景里，输入和输出的比例大概是 4:1，因为用户问题、上下文背景、工具返回结果都会算进输入，而模型只要生成答案。这种情况下 A 和 B 的差异可能很小。但换成一个总结类应用，输出占比升高，A 就明显不划算了。这个账，静态价格表算不出来，必须把输入输出分开、按业务特征去算。

更进一步，有些厂商的"便宜"建立在缓存命中上。你看到官网写"缓存命中价格低至 0.1 元/百万 tokens"，比普通输入便宜 10 倍。但你的业务里缓存命中率到底有多少？如果每次请求的上下文都不重复，这个低价对你来说就是画饼。真正负责的比价目录，应该允许你把预期缓存命中率录进去，然后算一个"预期实际单价"，而不是被官网那个最醒目的低价带走。

1.3 这个目录能做什么、不能做什么

做完之后我很清楚它的边界。它能做的：把云厂商、AI 厂商几套完全不同的计费语言翻译成一套统一口径，提供按调用量试算、按套餐点数折算、按模型对比的能力。它尤其适合两类人：一类是在做技术选型之前想先掐指算算成本的人，另一类是已经接了某个 API、但觉得账单不对劲、想找一个参照系来对账的人。

它不能做的：替你判断模型质量、响应速度、稳定性、客服响应。比价目录本质上回答的是"同一档位下谁更便宜"，至于这个模型是否适合你的业务，还得靠你自己去压测、去试跑。我见过有人拿着价格表选了最便宜的一家，结果业务效果不达标，回炉重写，那才是最大的成本。

2. 定价模型拆解：API 按量、订阅套餐、混合模式的区别

2.1 API 按量计费的完整结构

API 按量计费看着简单，实际要记录的字段不少。我做目录的时候给每个 API 模型单独建了一条记录，字段包括：模型名称、上下文窗口长度、输入价格、输出价格、缓存命中价格、计费单位、是否有阶梯价、是否有免费额度。

免费额度是个很微妙的存在。很多厂商注册就送多少万 token 的体验包，看起来很香，但往往绑定限制条件：有的限并发，有的只能用低配模型，有的有效期只有一个月。我发现不少团队上了生产之后才发现所谓"免费额度"根本撑不住流量，一核算，比直接付费还贵。在目录里，我把免费额度单独标成"营销资源"而不是"价格规则"，就是为了防止它干扰真实成本对比。

阶梯价同样需要建模。最常见的规则是：累计调用量超过某个区间后，超出部分打折。问题在于，这个累计是按自然月、按账号还是按模型维度算的，官网经常含糊其辞。建模时我特意加了一个"阶梯计算范围"字段，避免发生"我按模型维度估算，结果厂商按整个账号所有模型合计来计费"这种乌龙。

2.2 订阅套餐的规则设计

订阅套餐比 API 计价更复杂，因为它不是按 token 明码标价。国内几家主流厂商的套餐通常包含几个要素：月费、每日对话次数上限、单次回复长度上限、高优先级模型使用权、联网搜索次数等。

为了能横向比较，我做了一个非常讨巧的建模方式：把套餐里的"点数"折算成 token。比如一个厂商说 49 元/月包含 1000 点，而它的深度思考模型一次对话扣 50 点，单次生成上限是 2000 tokens，那么折算下来，这 49 元大约是 40000 tokens 的生成量。这个折算不公平吗？其实蛮粗略的，但好在它至少让订阅套餐和按量 API 之间有了一个可比的桥梁。

另一个值得注意的字段是"超额费用"。很多套餐在用量超出后并不是直接停机，而是自动切换到按量计费，这个按量价格往往比普通 API 价格贵。我见过有人买了套餐，觉得自己已经付费了，结果月底收到一笔超额账单，金额比套餐费还高。所以目录里必须把套餐的超额单价也记录清楚，否则容易误导。

2.3 混合模式：充值返赠、资源包和代金券

比价目录里还应该考虑混合模式。国内厂商很喜欢做"充 1000 送 100"或者"资源包"这类活动。资源包的逻辑是：你花一笔钱买一定量的 token 额度，通常比按量便宜，但有有效期，过期作废。

建模的时候要小心一个陷阱——返赠金额的适用范围。有的代金券只能用于特定模型，有的不能叠加 VIP 折扣，有的需要在新用户注册后 7 天内用完。我处理的办法是：把这些促销规则单独放一张表，不混入标准价格。用户在试算器里可以选择"是否叠加活动优惠"，默认关闭。原因很简单：活动规则随时变，如果你把比价目录的底价建立在一次性促销上，那个目录的生命周期会很短。

实操心得：比价目录一定要区分"标准价"和"活动价"。我推荐目录维护者建立两套价格，活动价标注有效期。否则下次官网调价，你的目录可能瞬间过时。

3. 数据结构设计：把"官网价格"变成"可计算模型"

3.1 模型表：最小必要字段

为了让读者能直接复现，我把建模的核心表结构写一下。模型表的长这样：

{ "vendor": "deepseek", "model": "deepseek-chat", "context_window": 128000, "pricing_unit": "1M tokens", "input_price": 0.5, "output_price": 2.0, "cache_hit_input_price": 0.1, "free_quota": "无", "rate_limit_rpm": 60, "tiered_pricing": false, "source_url": "https://api-docs.deepseek.com/quick_start/pricing" }

这里pricing_unit统一成"1M tokens"最省事。官方写"每千 token 0.0005 美元"或者"每百万 token 0.5 元"，拉到目录里全改写成"每百万 token 多少人民币"。至于汇率换算，我的处理是直接不做，因为国内厂商 API 基本都以人民币计价，少数美元计价模型保持原币种，对比时单列一列。

rate_limit_rpm这个字段很容易被忽略，但我强烈建议加上。因为比价之后你很可能真的去调用，结果发现某家便宜但每分钟只允许 60 次请求，对生产环境根本不够。限流这个字段不参与价格计算，但它直接影响"真实可用性"，选型时非常重要。

3.2 价格单位换算表：千 token、百万 token 怎么统一口径

统一口径这件事，我建了一张辅助换算矩阵。平时大家见到的计费单位大概有四类，统一换算的逻辑如下：

最后一种"每次请求固定计价"很少见，多出现在某些文档解析、OCR 类 API 上。它的 token 成本没法直接换算，我一般会在目录里标注"按次计费，不适合 token 口径对比"，避免强行比价。

单位换算看起来很简单，但我踩过一个小坑：有的官方文档用英文缩写，把"1K tokens"和"1M tokens"混在一起，爬虫抓下来容易把 1M 当成 1K，导致价格差一千倍。后来我在解析层加了一个强校验：如果某个模型的价格换算后比同类模型贵出 100 倍以上，就自动标记为异常，等人来复核。

3.3 试算器核心逻辑：一段可直接抄的估算脚本

目录做出来后，最有价值的东西是一个试算器。它做的事很简单：你给我输入量、输出量、缓存命中率，我告诉你按哪家的规则算，一个月大概多少钱。

核心逻辑我放在一个函数里：

def calc_api_cost(price_info, input_tokens, output_tokens, cache_hit_rate=0): input_price = price_info["input_price"] output_price = price_info["output_price"] cache_price = price_info.get("cache_hit_input_price", input_price) cache_input = input_tokens * cache_hit_rate normal_input = input_tokens - cache_input input_cost = (cache_input * cache_price + normal_input * input_price) / 1000000 output_cost = (output_tokens * output_price) / 1000000 return input_cost + output_cost

这段代码当然简化了阶梯价、套餐折算等逻辑，但主体思路是这样：先把输入拆成"缓存命中部分"和"普通部分"，分别计价，再加上输出部分的费用。这里的关键是，cache_hit_rate必须来自实际业务，不能拍脑袋。我见过有人把缓存命中率设成 80%，算出一个月一千块，结果上了生产发现实际只有 15%，账单瞬间翻了几倍。

对订阅套餐的折算，我写的是另一段逻辑，核心是"套餐点数 × 模型单次消耗点数 = 可调用次数，再乘单次输出长度上限，得到近似 token 总量"。这个模型很粗糙，但对于快速决策已经够了。真要精确，那得实际跑一个月看账单。

4. 真实对比：同一业务跑在不同模型上的成本差异

4.1 一个具体的成本试算场景

为了验证目录有用，我拿自己做的一个 AI 客服项目做了真实试算。这个项目的特征很典型：输入量远大于输出量，因为每次请求都要携带用户历史对话和商品知识库片段。日均输入约 200 万 tokens，日均输出约 50 万 tokens，月调用 30 天，缓存命中率在 20% 左右。

用统一口径的试算器跑了一遍，数据如下（价格为参考示例，请以官网实时价为准）：

差距大到啥程度？同一个业务场景，最贵和最便宜之间差了 30 倍以上。但这不是说便宜的就一定好，模型 D 在复杂意图识别上的效果确实强于模型 C，这个项目里部分功能还真的必须用模型 D。所以比价目录给我的真正价值不是"直接选最便宜的"，而是"把差价量化出来"——有了这个差价，业务方才能判断：为了那部分效果提升，每月多付这几千块值不值。

4.2 上下文长度对价格的影响：容易被忽略的隐藏变量

试算的时候我还发现一个容易算漏的点：上下文长度。很多模型按输出的 max_tokens 控制成本，但输入才是最容易被低估的。当你的上下文窗口从 8K 提升到 128K，单次请求携带的输入 token 数会急剧增加，如果用户平均输入长度增加了三倍，那么即使单价不变，成本也涨三倍。

更隐蔽的是，部分厂商对超长上下文有限制规则。比如某个模型最大上下文是 1M tokens，但超过 128K 后可能触发长文本额外计费，或者在超长输入时处理速度明显下降导致 token 生成被截断，结果你为生成的部分继续付费。这种"截断也计费"的现象是成本超支的常见原因，建议在做试算时永远往输入侧多留 20% 的余量。

4.3 订阅套餐和 API 怎么选：一个算到最后的结论

我还用同样的输入输出数据，把订阅套餐也跑了进去。结论其实蛮有意思：如果你的调用量波动很大，一天几十次、另一天几万次，那订阅套餐更划算，因为套餐能兜底，固定月费不会因为某天流量暴涨而失控；如果调用量稳定且持续很大，那 API 按量计费往往更便宜，因为高用量通常能谈到阶梯折扣，或者直接申请专属配额价。

另外还有一个容易忽略的点：套餐通常绑定厂商的聊天 App 或特定客户端，不能当 API 用。如果你要的是程序化调用，绝大多数订阅套餐根本不适用，这个啊，购买之前一定要看清楚条款，别把"会员额度"和"API 调用额度"搞混。我在目录里专门给每条订阅记录打了一个标签：usable_as_api: true/false，就是为了避免这种误解。

5. 数据更新、踩坑实录与常见问题速查

5.1 价格获取与更新机制：别指望官网主动通知你

大模型 API 的价格变动非常频繁，尤其是 2024 年之后，几乎每个月都有厂商宣布降价或推出新模型。我一开始是手动更新，后来发现根本跑不过来，于是做了一个半自动更新机制：每周抓一次各官网的价格页，对比历史版本，生成 diff，再人工确认一次。确认后的数据才进入线上目录。

抓取本身也有坑。很多官网价格页是动态渲染的，直接用简单请求拿不到数据，得用无头浏览器。还有的页面价格藏在 JS 变量里，普通文本解析看不到。折腾下来，我发现最省力的方案是用厂商官方 API 文档里的价格 JSON 文件，比如 DeepSeek 和智谱都把价格维护在 API 文档里，这种格式最稳定，也最好解析。

人工复核环节不能省。我遇到过一次，某个厂商官网首页写的是促销价，点进 API 文档页才发现是原价，两个页面差了 15%。如果我不设复核机制，这份目录就会带着一个过期价格坑到不少人。所以现在我的原则是：目录里任何价格，必须能回溯到"来源 URL + 抓取时间"两个字段，没有来源的价格一律不收录。

注意：比价目录价格不是永久有效的合同，它只是某个时间点的快照。验收目录能不能用，第一件事就看它能不能告诉你"这个价格是哪天从哪个页面拿到的"。

5.2 踩过的坑：四类问题最耽误时间

第一类是单位混淆，前面提过 1M 和 1K 的坑。第二类是官方网站改版导致抓取规则失效，这个只能靠监控告警解决——我发现价格页连续两次抓不到数据，就自动发警报，说明页面结构变了。第三类是“价格为含税价还是未税价”的问题，部分厂商列出的价格不含税，发票另算，这在企业采购场景下差别不小。第四类是隐藏的“限定向客户开放价格”，比如"联系销售获取专属价格"，这类通常不在官网页面上，但是对中大型用量反而最关键，直接导致目录里的价比对不了大客户真实成本。

此外还有一个经验：不要完全相信第三方博客或社区整理的价格表。我拿这些表做交叉验证，经常发现它们缺了缓存价、缺了阶梯条款。官方文档虽然阅读体验差，但它是唯一可信的原始事实源。任何二手来源最多只能当线索，不能当数据。

5.3 常见问题速查表

最后一个我想特别展开的是"context length exceeded"这类报错。很多开发者把上下文长度当成一个纯技术参数，但在比价场景里，它直接影响成本。举个实际例子：如果你选了上下文只有 8K 的便宜模型，你的业务又经常要传长文档，那你会面临两个选择——要么把文档截断，影响效果；要么换更长上下文的贵模型，成本上升。我见过团队因为没提前评估这个问题，上线两周后被迫从便宜的短上下文模型迁到贵的长上下文模型，重构成本远高于一开始选贵模型的差价。所以在比价目录里，我把context_window这个字段放在非常显眼的位置，绝不只看价格高低。

写在最后的一个实用建议

这个比价目录做下来，我个人最大的收获不是数据本身，而是建立了一套"用规则思考成本"的习惯。现在每次看到厂商宣传"史上最低价"，我不会直接冲动下单，而是先打开自己的试算器，把输入输出比、缓存命中率、上下文窗口这些参数填进去，看看那个"最低价"到底适不适合我的场景。建议你也试着维护一份自己的价格规则表，不用做得太复杂，哪怕只是一个表格加一个换算脚本，下次面对各家 API 报价时，你就能从容地说：让我先算一下。