大概半年多前我在折腾一个给内部团队用的模型选型评估工具遇到了一个让我极其烦躁的问题各家大模型 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 计费input_miss_cny_per_mtok 1.0输入价格-命中缓存通常为未命中价的 10%~50%input_hit_cny_per_mtok 0.1输出价格按输出 token 计费output_cny_per_mtok 3.0调用次数价格部分功能按次收per_call_cny 0.01查询价格时用户可以输入三个参数输入 token 量、期望输出 token 量、缓存命中率。系统自动算出单次成本成本 输入token × 未命中占比 × 输入未命中价 输入token × 命中占比 × 输入命中价 输出token × 输出价这套公式不复杂但很多比价工具不做因为默认大家“只看单价”。可我后来发现缓存命中率对真实成本的影响极大——尤其在 RAG 场景里系统提示词和检索文档是相对固定的一旦上了缓存输入成本能降一半还多。如果不把缓存折扣建模进去你看到的“便宜模型”很可能是“假便宜”。另外还有一类产品比较特殊它在同一个模型下区分“推理时调用”和“知识库索引调用”价格不同。我把这类也拆成两个价格记录用usage_scenario字段区分。2.3 免费额度、限速与套餐之间的换算关系做比价目录最难处理的不是单价而是免费额度和订阅套餐。先说免费额度。现在很多厂商新用户注册后会送体验额度比如“赠送 500 万 token有效期 180 天”。这个额度不是直接抵扣现金而是要按实际调用消耗。建模时我把它设计成“额度包”字段包括总 token 量、适用模型范围、有效期、是否可与付费调用混合使用。注意最后一个字段非常坑——我之前以为免费额度用完后自动切换付费模式结果某家平台是免费额度没耗尽之前你充了钱也花不出去白白浪费了充值优惠。订阅套餐就更复杂了。我统计了一下目前国内大模型订阅套餐大概分三类纯 API 预付费套餐充值对应金额获得一定量 token 额度用量超了按单价扣除会员订阅制套餐按月付费包含一定 API 调用额度同时解锁 Web 端会员功能企业专属协议包年包季谈一口价附带并发和 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 比价目录的边界以及它后来帮我做成了什么做这个目录的过程中我最大的认知变化是模型选型不能只看价格。目录里有不少模型价格非常诱人但真要接到生产环境立刻暴露出各种各样的问题——限流太严导致高峰时段任务排队上下文窗口不够长导致长文档处理被截断某个版本不稳定导致推理结果偶发异常。价格只是选型的一个维度它很重要但永远不是唯一重要的维度。后来的实际应用里我把这个比价目录嵌进了一个内部评估流程新项目立项时技术负责人可以基于目录数据输入预估调用量自动产出候选模型的预算是多少。这个流程至少帮我们排除了两三次“拍脑袋选模型”的冲动决策。最后再分享一个我在维护过程中沉淀下来的小技巧给每一个模型价格记录都加上“价格置信度”字段。哪条数据是官网直接确认过的标为高置信度哪条是通过帮助文档推测出来的标为中置信度哪条是用户反馈但还没复核的标为待核验。这个字段看起来简单但在跟厂商核对、跟团队解释成本口径的时候能省下大量扯皮时间——因为任何一条数据你都说得清它的来源和可靠程度。比价目录这类工具拼到最后就是“信得过”三个字而这个信字是靠每一个细节挣出来的。