大模型API比价目录实战：统一诡异计费规则的建模之道

大概半年多前，我在折腾一个给内部团队用的模型选型评估工具，遇到了一个让我极其烦躁的问题：各家大模型 API 的定价规则完全不统一，同一个模型，官网写着“每千 token 0.002 元”，换个入口变成“每百万 token 2 元”，再换个渠道又变成“输入 1 元 / 输出 3 元 / 百万 token”。那段时间我每天都要打开四五个厂商的定价页来回换算，算得头大。

后来我索性做了个比价目录，把所有国内主流大模型厂商的 API 价格和订阅套餐按官网原样建模，装进一个统一的计算框架里。今天这篇就聊聊这个目录是怎么做的，为什么“按官网原样建模”这件事听起来简单、做起来全是坑，以及我在维护过程中踩过的那些雷。

这个项目最核心的产出，不是一堆价格表格，而是一套能把各家诡异计费规则统一表达出来的数据模型。我做这个目录的初衷很简单：市面上已有的模型比价工具，几乎都是人工填个“每百万 token 均价”就完事，用于日常吹水够了，但真要拿来算成本、做选型，根本不能用，因为它们在建模时抹掉了太多关键细节。

1. 为什么做这件事：定价目录不是比价，是建模

1.1 一个 API 而已，为什么让我算账算了三天

先说个具体场景。你是一个做 AI 应用的开发者，想在两个模型之间选一个做客服摘要，一个是模型 A，一个是模型 B。官网查到的价格分别长这样：

• 模型 A：输入 0.5 元 / 千 token，输出 2 元 / 千 token，缓存命中按输入的 10% 收费
• 模型 B：按 100 万 token 计价，输入 4 元，输出 12 元，但调用次数超过 50 万次 / 月后，价格打 8 折

这俩怎么比？如果你只比“均价”，模型 A 大约 1.25 元 / 千 token，模型 B 大约是 8 元 / 百万 token，换算之后 A 反而贵了。但你的真实请求里，用户消息会被系统提示词重复消耗，缓存命中率可能高达 60%，算上缓存折价，模型 B 的实际单次成本可能反超 A。这就意味着，比价工具如果只看“展示价”，而不把缓存、阶梯、输入输出拆分这些规则建模进去，算出来的结论大概率是错的。

我做目录时遇到的第一关，就是搞清楚一件事：我不能只记录“一个数字”，我要记录的是“一套规则”。这也是为什么我把项目命名为比价目录，而不是简单的“价格表”。

从需求端来说，这个目录主要服务三类人：一类是像我这样要频繁评估模型成本的应用开发者；一类是给团队做技术选型、要出成本评估报告的技术负责人；还有一类是大模型 API 的渠道代理商，他们要拿这个目录做下游报价的底表。这三类人的共同痛点是：需要一个既足够准确、又能快速给出“如果我的场景是这样的，应该花多少钱”的答案。

1.2 官网原样建模是什么概念

“按官网原样建模”这几个字，是我在项目定义阶段反复推敲后定下来的原则。它包含三句话：

第一，价格数字必须以官网实时公示为准，坚决不参考那些二手整理帖。二手信息的问题在于，它往往会为了排版好看而忽略“适用条件”。比如某家官网标注“新用户赠送 500 万 token 体验额度”，二手帖可能直接写成“送 500 万 token”，但没写“仅限实名认证且首次开通 API 的用户”“有效期 90 天”“不适用于某些特定模型”。这些条件我必须在模型里表达出来。

第二，计费单位必须跟官网保持一致，再另做一层统一换算。官网写“每千 token”我就存“每千 token”，官网写“每小时 0.5 元”我就存“每小时 0.5 元”。推导出来的“每百万 token 价格”只是展示层的换算结果，绝不能反过来污染底层数据。

第三，任何“活动价”“限时折扣”都要单独标记，不能混入标准价。有一家厂商曾经做过 1 分钱体验 100 万 token 的活动，如果我把这个价格当成标准价存入目录，三个月后活动结束，我的比价数据就会全线失真。所以活动价必须作为独立的价格事件挂到模型上，有生效起止时间，过期自动失效。

我把这三句话写成了一个数据校验规则：任何一条价格记录，必须带来源 URL、采集时间、生效时间范围、币种、计费单位。只要这些字段不全，数据就不允许入库。这套约束看起来矫情，但它保证了目录里每一条价格真相都有据可查。

2. 价格规则怎么建模才算“原样”

2.1 计费单位统一与展示取舍

我观察下来，国内大模型厂商的计费单位大致分成四类：每 token、每千 token、每百万 token、按次调用。前三种本质上一样，只是倍数不同；按次调用则完全不同，常见于图片生成模型或专用向量模型。

我的做法是：在数据库里为每一种“计费单位”建立独立的换算系数表，所有计算统一换算到“元 / 百万 token”这个基准上来，但每条原始记录永远保留官网原单位。比如某厂的官网价格是“0.002 元 / 1k token”，数据库里存储的计费单位字段是per_k_token，货币单位是CNY，数值是0.002。计算层读出来以后，再按照per_k_token的换算系数乘以 1000 得到基准价格。

这个设计的好处是，当官网把单位从“1k token”改成“百万 token”时，我只需要改一条换算系数，不用改所有历史数据。坏处是展示层要花点心思，不能直接大字显示“均价 X 元”，而要告诉用户“这个 X 是拿输入输出价格加权平均后算出来的，权重默认是输入:输出 = 1:1，你可以自己调”。

实际使用中，我强烈建议在比价页面上同时展示“原始价格”和“换算价格”两列。只展示换算价格会让用户不放心，因为他们去官网核对时对不上；只展示原始价格又会让用户算得头大。两者都展示，再配一个“换算说明”的 tooltip，基本能满足绝大多数人的需求。

2.2 输入输出双轨计价与缓存折价怎么进模型

现在国内主流大模型 API，基本都区分输入价格和输出价格，有家甚至拆成“命中缓存输入价”“未命中缓存输入价”“输出价”三档。建模时最忌讳的就是只存一个“输入+输出均价”。

我的解决方案是建立“价格分量表”，每个模型对应至少 3 个价格分量：

查询价格时，用户可以输入三个参数：输入 token 量、期望输出 token 量、缓存命中率。系统自动算出单次成本：

成本 = 输入token × 未命中占比 × 输入未命中价 + 输入token × 命中占比 × 输入命中价 + 输出token × 输出价

这套公式不复杂，但很多比价工具不做，因为默认大家“只看单价”。可我后来发现，缓存命中率对真实成本的影响极大——尤其在 RAG 场景里，系统提示词和检索文档是相对固定的，一旦上了缓存，输入成本能降一半还多。如果不把缓存折扣建模进去，你看到的“便宜模型”很可能是“假便宜”。

另外还有一类产品比较特殊：它在同一个模型下区分“推理时调用”和“知识库索引调用”，价格不同。我把这类也拆成两个价格记录，用usage_scenario字段区分。

2.3 免费额度、限速与套餐之间的换算关系

做比价目录，最难处理的不是单价，而是免费额度和订阅套餐。

先说免费额度。现在很多厂商新用户注册后会送体验额度，比如“赠送 500 万 token，有效期 180 天”。这个额度不是直接抵扣现金，而是要按实际调用消耗。建模时我把它设计成“额度包”，字段包括：总 token 量、适用模型范围、有效期、是否可与付费调用混合使用。注意最后一个字段，非常坑——我之前以为免费额度用完后自动切换付费模式，结果某家平台是免费额度没耗尽之前，你充了钱也花不出去，白白浪费了充值优惠。

订阅套餐就更复杂了。我统计了一下，目前国内大模型订阅套餐大概分三类：

1. 纯 API 预付费套餐：充值对应金额，获得一定量 token 额度，用量超了按单价扣除
2. 会员订阅制套餐：按月付费，包含一定 API 调用额度，同时解锁 Web 端会员功能
3. 企业专属协议：包年包季谈一口价，附带并发和 SLA 承诺

比价目录里如果只展示“这个套餐 99 元 / 月”，用户根本看不出来它和“API 按量计费”哪个划算。我的做法是，为每个订阅套餐建立“等效单价计算器”：输入你的月度 token 消耗量，计算器自动对比按量计费和订阅套餐哪个更省。一开始我觉得这属于过度设计，但后来发现，大多数个人开发者和中小团队的真实需求其实就在这里——他们不关心绝对价格，只关心“我一个月用 3000 万 token，买哪个套餐最划算”。

实现时有个细节：套餐里的 token 额度是否区分输入输出。部分套餐直接写“每月含 1 亿 token”，不分输入输出，这就让建模变得很别扭。我的折中方案是：默认按输入:输出 = 1:1 的比例估算套餐综合成本，同时在 UI 里允许用户自己拖动比例权重。这样模型不会为了表面统一而扭曲真实规则。

3. 目录系统的实现：从 JSON Schema 到对比展示

3.1 数据模型设计：把价格规则变成可计算的格式

整个目录最底层的结构我用了一套“价格事件”模型。一套标准的价格记录长这样：

{ "model": "glm-4-plus", "vendor": "zhipu", "price_events": [ { "effective_at": "2025-01-15", "expired_at": null, "source_url": "https://open.bigmodel.cn/pricing", "currency": "CNY", "unit": "per_million_token", "input_miss_cny": 50, "input_hit_cny": 5, "output_cny": 100, "notes": "API 通道价格，不包含渠道加价" } ], "limits": { "rate_limit_rpm": 120, "concurrency": 10, "max_context_tokens": 1048576 }, "free_quotas": [ { "amount": "5000000", "unit": "token", "expires_in_days": 180, "applicable_models": ["glm-4-flash", "glm-4-plus"], "activation_conditions": "新用户实名认证后自动到账" } ] }

这套模型的优点在于，每个模型节点下面挂着的不是一条价格，而是多条“价格事件”。当官网改价时，我新增一个price_events条目，而不是修改原来的条目。这样目录天然自带历史价格追踪能力，用户能看出来“这个模型这个月涨了还是跌了”。

存储层我用的是一个 PostgreSQL 数据库加一个 JSONB 字段来存free_quotas和limits，因为这两个结构不同厂商差异实在太大，搞严格关系模型反而痛苦。价格事件本身是核心数据，不能塞 JSONB，必须拆成正式表格，因为要频繁做数值查询和叠加计算。

3.2 更新机制：人工核对 + 自动巡检 + 用户反馈

比价目录最难的不是“建”而是“养”。大模型厂商调价非常频繁，我见过有厂商两周内调三次价。为了让目录不至于沦为“历史文物”，我设计了三级更新机制。

第一级是自动巡检。我写了一个定时任务，每周对每个厂商的公开定价页面做一次抓取，计算页面内容的 hash，只要 hash 有变化就产生告警。抓取只做“变更检测”，不做“自动解析”。为什么不多做一步？因为定价页的样式我试过，各家改版频率高，DOM 选择器根本不稳定，而且用 LLM 做结构化抽取看似可行，实际准确率也就七成，价格这种东西 70% 准确率等于不可用。

第二级是人工核对。告警产生后，我会人工打开页面，确认变更内容，再手动录入到后台。这个过程看起来原始，但胜在稳。我后来加了一个小优化：把常见的价格解析操作做成半自动表单，页面上抓到的文本会自动填进字段，人只需要核对一下单位和小数点。这个半自动流程让一次改价录入从 10 分钟压缩到 2 分钟。

第三级是用户反馈。目录里每个模型的价格卡片上都有一个“报错/更新”按钮，用户看到实际账单金额和目录对不上，可以直接提交。这个功能帮我抓到了好几处官网口径没说明的隐藏价格。用户反馈的数据，我会进入“待人工复核”队列，而不是直接修改主数据，防止误报污染。

3.3 对外展示：比价目录应该给出什么，不该给出什么

比价目录的展示层，我做了三个核心界面：模型价格总览、双模型对比、订阅套餐推荐。

模型价格总览页，默认按“综合价格”升序排列。综合价格的计算方式是：假设一个标准请求包含 2K 输入 token、1K 输出 token，缓存命中率为 50%，换算出来一个“标准单次调用成本”。这个指标仅作为排序依据，页面上加粗的是“标准调用预估成本”，旁边用小字展示原始官网价。不少用户一进来就问我“这个综合价格怎么算的”，这正说明排序必须透明，不然工具就失去了公信力。

双模型对比页是用户用得最多的功能。它并排展示两个模型的参数表格，同时提供一个可以拖动的“场景模拟器”：滑动条控制输入 token 量、输出 token 量、缓存命中率、调用次数。拖完之后，下方实时显示两个模型在指定场景下的总成本曲线。这个功能的起源是我自己的需求——每次算账都要拿着计算器按半天，干脆做成交互式组件。

订阅套餐推荐入口做得相对克制。我深知“推荐套餐”很容易变成带货，所以页面上只做纯计算对比：输入你的月调用量，系统列出“按量计费成本”“套餐 A 包月等效成本”“套餐 B 包月等效成本”三列，由用户自己判断。我甚至刻意不做“最划算”标签，因为套餐往往包含一些非 API 权益（比如 Web 端会员优先排队），这些权益没法量化，强行推荐不厚道。

我要特别强调一个不该做的事：不要显示“历史最低价”“全网最低价”这类诱导性标签。国内各厂商的 API 价格差异经常是一种渠道策略，不是单纯的“谁更便宜”，加这种标签只会让用户产生错误认知，也会让厂商觉得你的目录在做不公正对比。

4. 踩过的坑与排查记录

4.1 官网页面结构改版，自动巡检告警淹没了正常变更

有一次我对三家厂商的定价页做了自动巡检，第二天早起一看告警队列里躺了 200 多条，全是同一家官网改版导致的“页面变化”。但实际价格并没有变，只是 HTML 结构重排了。

这次事件让我意识到，hash 检测只能告诉你“页面变了”，不能告诉你“价格变了”。我随后加了一个白名单过滤：只保留页面中包含“价格”“¥”“元/token”“千 token”“百万 token”等关键字的文本块，对这几个文本块单独做 hash。如果整页 hash 变化但价格块 hash 不变，不产生告警，只记录“页面结构更新”。从此巡检告警的数量从一个月 200 多条降到了平均每周 3~4 条，终于恢复到人工能处理的量级。

4.2 阶梯价不在同一张表里，藏得比你想象深

比较痛苦的一次排查，是一家模型厂商推出的“用量超过 1000 万 token / 月后，超出部分打 7 折”阶梯价。这个规则不在定价页上，而是在控制台“费用管理”的某个折叠面板里。我的巡检系统压根没抓到它，直到有一位用户提交反馈说：“你们目录上没算阶梯价，我的账单对不上。”

后来我把这家厂商的控台费用页面截图翻了个底朝天，才找到那行小字。这个教训让我养成了一个习惯：人工核对时不能只看“定价 tab”，要把“计费说明”“帮助文档”“API 文档的计费节”全部过一遍。为了让这个流程可复用，我在后台做了一个“厂商价格信息来源台账”，记录每一个价格事件是从哪个页面捞的，每条记录必须能回答“官网哪里说了这个规则”。

4.3 同一个模型名，新旧版本价格并存

还有一类坑是模型版本管理。某家模型厂商把同一个模型名升级到了新版本，新版价格降了 30%，但旧版本仍在服务老用户，官网页面上新旧两个价格并存。如果不加版本维度，用户很容易混淆。

解决办法是在数据模型里给模型名加版本标签，比如glm-4-plus和glm-4-plus:latest作为两条记录。比价时用户默认只看latest，但也可以在设置里打开“显示全部版本”。另外，当旧版本进入“即将下线”状态时，我在记录上加一个deprecation_status字段，避免用户拿一个快要退市的价格去跟别家做长期比较。

4.4 渠道价格和官方价格混在一起，怎么处理

目录上线一段时间后，有用户问我怎么不收录某聚合平台的 API 价格，那里很多模型价格比官方低不少。这个问题我想了很久。

我的结论是：目录只收录“官方直营渠道的价格”，不收录二级代理渠道价。原因很直白：代理渠道的价格规则不透明，折扣力度经常是线下谈的，同一家平台不同客户拿到的价都不一样，这种数据收录进来既无法验证，又会让目录失去“以官网为准”的公信力。但我在页面底部加了一个声明：如果你用的是聚合平台，实际扣费可能低于或高于官方价，建议以控制台账单为准。

5. 维护节奏与边界感，比价目录值不值得做

5.1 我目前的维护节奏

现在这个目录已经稳定运行了一段时间，我的维护节奏大概是这样的：

• 每天花 15 分钟看一遍用户反馈和自动巡检告警
• 每周抽出 60~90 分钟，做一次全量人工抽查，重点看几家调价频繁的厂商
• 每月做一次价格趋势简报，统计哪些模型降价了、哪些隐藏收费项目浮出水面

这个节奏不算重，但一天不盯就可能出问题。印象最深的是有一次我出差三天没看后台，回来发现一家头部厂商悄悄调整了缓存命中定价，从“10% 折扣”改成“30% 折扣”，后台堆了十几条“价格更新”提醒。幸好目录的模型全部带生效时间，我复核后一键发布，影响范围也就是那几天用旧价算出来的报告，没有造成更坏的结果。

如果你也想做类似的东西，我的一句真心话：不要低估“持续维护”的工作量。比价目录这类工具，80% 的价值在数据的新鲜度上，建模写代码只占两成。如果只是想自己用，建议别走“全量收录”这条路，挑几个你高频使用的模型维护就行；如果是要做成公开产品，你就要做好长期运营的心理准备。

5.2 比价目录的边界，以及它后来帮我做成了什么

做这个目录的过程中，我最大的认知变化是：模型选型不能只看价格。目录里有不少模型价格非常诱人，但真要接到生产环境，立刻暴露出各种各样的问题——限流太严导致高峰时段任务排队，上下文窗口不够长导致长文档处理被截断，某个版本不稳定导致推理结果偶发异常。价格只是选型的一个维度，它很重要，但永远不是唯一重要的维度。

后来的实际应用里，我把这个比价目录嵌进了一个内部评估流程：新项目立项时，技术负责人可以基于目录数据，输入预估调用量，自动产出候选模型的预算是多少。这个流程至少帮我们排除了两三次“拍脑袋选模型”的冲动决策。

最后再分享一个我在维护过程中沉淀下来的小技巧：给每一个模型价格记录都加上“价格置信度”字段。哪条数据是官网直接确认过的，标为高置信度；哪条是通过帮助文档推测出来的，标为中置信度；哪条是用户反馈但还没复核的，标为待核验。这个字段看起来简单，但在跟厂商核对、跟团队解释成本口径的时候，能省下大量扯皮时间——因为任何一条数据你都说得清它的来源和可靠程度。比价目录这类工具，拼到最后就是“信得过”三个字，而这个信字，是靠每一个细节挣出来的。