★ FEATURED ARTICLE 做一个大模型 API 和订阅套餐的比价目录这个想法其实一开始挺冲动的。我当时的处境是项目要控制成本得从一堆国内大模型厂商里选一个主力 API结果把各个官网的价格页打开对着看了整整一个下午越看越头大——有的按千 token 报价有的按百万 token有的输入输出分开计价还有的打完折包装成教育版初创扶持版。最要命的是大多数比价网站只有一张静态价格表而且口径经常和官网对不上根本没法回答我这个调用量到底该选哪家这种具体问题。所以我干脆自己搭了一个比价目录核心思路很朴素把大模型 API 和订阅套餐的价格规则按官网原样建模不手动抹平、不四舍五入让规则自己说话。这篇就是我做完之后对选型、建模、踩坑的完整复盘适合正在做模型选型、控成本的开发者和团队负责人参考。1. 为什么比价目录要按官网原样建模而不是抄一张价格表1.1 官方价格页的真实样子口径混乱才是常态我一开始以为比价就是收集数据后来发现真正的难点是数据结构化。国内主流大模型厂商的计费口径五花八门几乎没有两家是完全一致的。拿最简单的一层来说计费单位就各不相同。有的厂商在官网上写每千 tokens 0.002 元有的写每百万 tokens 2 元还有的用每万 tokens 0.3 元。如果做目录的人不统一单位这本身就是个坑。更麻烦的是计费结构不同有的模型只有一口价输入和输出同价有的输入一个价、输出一个价输出往往是输入的三到五倍还有的引入缓存命中价说缓存命中的输入只要十分之一的价格再有就是阶梯定价当月调用量超过某个阈值后单价打折。这还不包括订阅套餐那一侧。订阅套餐有的是按月度固定金额给点数有的限制每日对话次数有的干脆是长上下文专用包里面按文档页数或者字符数折算。玩过一圈之后你就会发现官网价格页上那个原价和实际结算之间可能隔着好几条隐藏规则。所以我做比价目录的第一条原则是不能把官网价格抄到表格里就完事得把每条价格后面的规则也抄下来。这就是我说的按官网原样建模——模型、单位、阶梯、缓存、活动、配额全部分开记录。只有这样后面才能拿它做真正的试算。注意任何比价目录如果不能解释这个价格在什么条件下生效那它本质上只是一张旧截图。1.2 直接抄表的问题没法横向换算更没法推演成本假设现在有两家模型厂商A 家写输入 0.8 元 / 百万 tokens输出 1.2 元 / 百万 tokensB 家写输入输出统一 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 怎么统一口径统一口径这件事我建了一张辅助换算矩阵。平时大家见到的计费单位大概有四类统一换算的逻辑如下官网报价写法例句统一换算为元 / 百万 tokens的方法每千 tokens 计价0.002 元 / 千 tokens数值 × 1000每万 tokens 计价0.3 元 / 万 tokens数值 × 100每百万 tokens 计价2 元 / 百万 tokens数值不变每次请求固定计价0.01 元 / 次需结合上下文长度估算另作处理最后一种每次请求固定计价很少见多出现在某些文档解析、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_rate0): 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% 左右。用统一口径的试算器跑了一遍数据如下价格为参考示例请以官网实时价为准模型输入价元/百万输出价元/百万缓存命中价元/百万月估成本元模型 A0.52.00.1约 120模型 B0.51.50.1约 105模型 C0.30.60.05约 45模型 D12.012.010.0约 1560差距大到啥程度同一个业务场景最贵和最便宜之间差了 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 常见问题速查表问题原因与对策目录里某家价格和官网显示不一样官网可能刚改价或存在促销价/标准价之分。先核对来源 URL 抓取时间再看是不是不同页面。为什么有的模型试算特别便宜但生产爆账单多半是低估了输入 tokens 或缓存命中率。建议压测时记录真实 token 消耗回填试算器。套餐会员显示能用来 API 调用实际不行订阅套餐权益与 API 额度通常独立购买前看条款里的usable_as_api字段。调用时报 context length exceeded输入加输出超过了模型上下文窗口。处理办法压缩上下文、截断历史消息、调低 max_tokens。免费额度用不完但充值之后反而扣费更快免费额度往往有并发和计费优先级限制超限后立刻按标准价扣费。建议实时看用量面板。官网说有阶梯折扣但账单没打折阶梯可能按自然月全账号累计而不是按单一模型累计联系平台确认计算范围。最后一个我想特别展开的是context length exceeded这类报错。很多开发者把上下文长度当成一个纯技术参数但在比价场景里它直接影响成本。举个实际例子如果你选了上下文只有 8K 的便宜模型你的业务又经常要传长文档那你会面临两个选择——要么把文档截断影响效果要么换更长上下文的贵模型成本上升。我见过团队因为没提前评估这个问题上线两周后被迫从便宜的短上下文模型迁到贵的长上下文模型重构成本远高于一开始选贵模型的差价。所以在比价目录里我把context_window这个字段放在非常显眼的位置绝不只看价格高低。写在最后的一个实用建议这个比价目录做下来我个人最大的收获不是数据本身而是建立了一套用规则思考成本的习惯。现在每次看到厂商宣传史上最低价我不会直接冲动下单而是先打开自己的试算器把输入输出比、缓存命中率、上下文窗口这些参数填进去看看那个最低价到底适不适合我的场景。建议你也试着维护一份自己的价格规则表不用做得太复杂哪怕只是一个表格加一个换算脚本下次面对各家 API 报价时你就能从容地说让我先算一下。
阅读完成 · 觉得有帮助？
