1. 这个比价目录到底解决了什么问题国内大模型这两年的价格战打得比菜市场还热闹。我去年帮公司做技术选型的时候光是整理各家 API 的计费规则就花掉了整整三天——不是查不到价格而是查到了也看不懂。DeepSeek 的缓存命中怎么算、通义千问的阶梯计费从哪一档开始跳、智谱的套餐包和按量付费哪个更划算、Kimi 的上下文长度超了之后单价怎么变这些信息散落在各个官网的定价页、文档角落、甚至更新公告里格式还都不一样。有的用表格有的用文字描述有的把输入和输出分开列有的把缓存单独拎出来算一档。更麻烦的是这些价格规则不是静态的。几乎每个月都有厂商调价、出新套餐、改计费粒度。你上周算好的成本模型这周可能就失效了。我试过用 Excel 手动维护结果维护到第三周就放弃了——不是懒是实在跟不上变化的速度。所以当我看到有人做了一个国内大模型 API 和订阅套餐的比价目录价格规则按官网原样建模的时候第一反应是这东西要是做得靠谱能省掉技术选型阶段至少一半的扯皮时间。它的核心价值不在于比价这个动作本身而在于把非结构化的价格规则翻译成可计算、可对比、可追溯的结构化模型。这跟普通的价格汇总表有本质区别——汇总表只告诉你多少钱而这个目录告诉你在什么条件下、按什么规则、算出来多少钱。这个项目适合谁用三类人最刚需一是做技术选型和成本预算的架构师或技术负责人需要快速估算不同方案的年化成本二是独立开发者或小团队预算敏感需要在免费额度、低价档位和性能之间找平衡三是做 AI 应用层产品的团队API 成本直接决定毛利需要持续监控价格变化并动态调整路由策略。2. 价格规则建模的核心思路拆解2.1 为什么不能只做一张价格对比表很多人第一反应是不就是把各家价格列出来吗一张 Excel 就够了。我一开始也这么想直到我真正动手算了一次某项目的月度成本。假设你有一个应用日均调用 50 万次平均输入 800 token平均输出 400 token其中 30% 的请求命中缓存。这时候你会发现不同厂商的计费维度完全不在一个层面上有的厂商输入和输出统一定价有的分开定价输出通常是输入的 2 到 4 倍缓存命中的折扣力度从 5 折到 1 折不等有的甚至免费阶梯计费有的按月累计用量跳档有的按单次请求量跳档套餐包有的是预付费买 token 包有的是包月不限量但限并发有的是包月送一定额度超出另算。你把这些规则硬塞进一张表里结果就是列数爆炸、行数爆炸而且每加一个厂商就要重新调整表结构。更致命的是你没法用这张表做自动化计算——每次算成本都要人工判断这个请求落在哪个档位。所以这个比价目录的核心设计决策是把价格规则抽象成计费维度 计费单元 阶梯规则 约束条件的四元组模型。每个厂商的每个模型都用这四元组来描述而不是用一张扁平的表。这样做的好处是计算逻辑和展示逻辑分离——展示层可以渲染成表格计算层可以用同一套代码跑所有厂商的成本估算。2.2 计费维度怎么拆才合理我见过一些比价工具把计费维度拆得很粗只分输入和输出两档。这在早期够用但现在完全不够。国内主流厂商的计费维度至少包括以下几类维度说明典型厂商做法输入 token用户发送的 prompt 部分大部分厂商按此计费输出 token模型生成的内容部分单价通常是输入的 2-4 倍缓存命中输入命中上下文缓存的输入部分折扣 1-5 折不等缓存写入首次写入缓存的部分部分厂商单独计费思考过程 token推理模型的思维链部分有的计入输出有的单独算图片/多模态输入图片、视频等非文本输入按张或按 token 折算工具调用Function Calling 的额外开销少数厂商单独计费这个目录的做法是每个维度独立建模但允许厂商配置哪些维度合并计费。比如某厂商把思考过程 token 计入输出 token那就在配置里标记为合并另一厂商单独计价就拆成两个维度。这样既保证了灵活性又不会让展示层变得过于复杂。2.3 阶梯规则的建模难点阶梯计费是比价里最容易踩坑的地方。我举个例子某厂商的定价是月累计用量 0-100 万 token 按 0.008 元/千 token100 万-500 万按 0.006 元/千 token500 万以上按 0.004 元/千 token。这看起来简单但实际计算时有几个关键问题第一阶梯是全额累进还是超额累进全额累进是指一旦超过 100 万所有用量都按 0.006 算超额累进是指前 100 万仍按 0.008 算超出部分按 0.006 算。这两种算法的结果差异巨大而很多厂商的文档里并没有写清楚需要从计费示例里反推。第二阶梯的累计周期是什么是按自然月、按账单周期、还是按合同周期有的厂商按月重置有的按季度有的按年。这个信息直接影响成本估算的时间粒度。第三阶梯是否跨模型共享有的厂商所有模型共享一个月度累计额度有的每个模型独立累计。这决定了你多模型混用时的实际单价。这个目录的建模方式是每个阶梯规则显式标注累进类型和累计周期并在计算引擎里实现两种累进算法。我实测下来超额累进是更常见的做法但全额累进在某些厂商的套餐包里也会出现所以两种都得支持。3. 核心细节解析与实操要点3.1 数据采集怎么从官网原样提取规则按官网原样建模这句话说起来简单做起来极其繁琐。我自己的经验是一个厂商的定价页通常包含以下信息源而且它们之间可能互相矛盾定价页的主表格通常是最新的标准价格但可能不包含套餐包和优惠活动文档里的计费说明有时比定价页更详细包含阶梯规则和计费示例控制台的计费预览最准确但需要登录且不一定对所有用户开放更新公告调价时发布但旧公告可能没有及时归档。这个目录的采集策略是以定价页为主以文档计费说明为辅以计费示例为校验。具体操作时我建议按以下步骤走先截取定价页的完整表格包括所有脚注和小字说明。很多关键约束比如缓存命中仅限特定模型都藏在脚注里。在文档里搜索计费、价格、阶梯、缓存等关键词找到计费说明章节。如果文档里有计费示例用示例数据反推规则验证是否与定价页一致。把提取到的规则填入四元组模型标注数据来源和采集日期。注意厂商调价频繁建议每次采集都记录时间戳并在展示层标注价格最后更新于 X 年 X 月 X 日。我踩过的坑是有一次用了一个月前的数据做预算结果厂商已经调价了预算偏差超过 20%。3.2 套餐包的建模比按量付费复杂三倍订阅套餐的建模难度远高于按量付费。按量付费的核心是单价 × 用量套餐包则涉及预付费金额、包含额度、超出单价、有效期、并发限制、模型范围等多个参数。我整理了一下国内常见的套餐包至少有以下几种形态套餐类型计费逻辑适合场景建模要点Token 包预付费买固定 token 量用完为止用量可预测需计算实际单价 包价 / token 量包月套餐月付固定费用含一定额度超出另算用量稳定需建模额度内 额度外两段包月不限量月付固定费用不限量但限并发高并发低单价需建模并发上限和超限策略阶梯套餐用量越大单价越低按月结算中大型团队与按量付费的阶梯规则类似混合套餐基础包月 按量叠加波动大的场景需建模两部分的优先级这个目录的做法是把套餐包也抽象成计费规则 约束条件的组合而不是单独建一套模型。比如包月套餐可以表示为固定费用 包含额度 超出部分按某单价计费这跟按量付费的阶梯规则在计算逻辑上是同构的只是多了一个固定费用项。3.3 计算引擎怎么保证算出来的价格可信比价目录最核心的功能是成本估算而成本估算的可信度取决于计算引擎的准确性。这个目录的计算引擎设计有几个关键点第一输入参数标准化。用户输入的用量数据输入 token 数、输出 token 数、缓存命中率等需要统一单位避免千 token和百万 token混用导致的错误。我建议统一用token作为基础单位展示时再换算。第二计算过程可追溯。每次估算都要输出中间结果比如输入费用 输入 token 数 × 输入单价 X 元、缓存折扣 缓存命中 token 数 × 输入单价 × 折扣率 Y 元。这样用户能看懂钱花在哪了也方便排查异常。第三边界条件显式处理。比如用量为 0 时、缓存命中率为 100% 时、超出套餐额度时这些边界情况要有明确的处理逻辑不能靠默认值蒙混过关。我实测下来一个可靠的估算引擎至少需要以下输入参数# 成本估算输入参数示例 estimate_params { input_tokens: 800, # 单次请求平均输入 token output_tokens: 400, # 单次请求平均输出 token cache_hit_rate: 0.3, # 缓存命中率 daily_requests: 500000, # 日均请求数 monthly_days: 30, # 月计费天数 model_name: deepseek-chat, # 模型名称 provider: deepseek # 厂商 }计算引擎根据这些参数结合厂商的价格规则输出月度成本估算和费用明细。这个过程中阶梯规则的累进计算是最容易出错的地方建议单独写单元测试覆盖。4. 实操过程与核心环节实现4.1 从零搭建比价目录的完整流程如果你也想自己搭一个类似的比价目录我把自己走过的流程整理一下供参考。整个项目可以拆成五个阶段数据采集、规则建模、计算引擎、展示层、维护机制。第一阶段数据采集。先确定要覆盖的厂商和模型范围。我的建议是不要贪多先覆盖 5 到 8 家主流厂商的核心模型把规则跑通再扩展。采集时用统一的模板记录信息包括厂商名称、模型名称、计费维度、单价、阶梯规则、套餐信息、数据来源、采集日期。这个模板可以用 YAML 或 JSON 存储方便后续程序读取。第二阶段规则建模。把采集到的数据翻译成四元组模型。这一步的关键是定义好 schema确保不同厂商的规则能用同一套结构描述。我用的 schema 大致如下# 价格规则 schema 示例 provider: deepseek model: deepseek-chat billing_dimensions: - name: input unit: per_1k_tokens price: 0.001 - name: output unit: per_1k_tokens price: 0.002 - name: cache_hit_input unit: per_1k_tokens price: 0.0001 condition: cache_hit true tiers: - min_tokens: 0 max_tokens: 1000000 multiplier: 1.0 - min_tokens: 1000000 max_tokens: 5000000 multiplier: 0.75 - min_tokens: 5000000 max_tokens: null multiplier: 0.5 tier_type: progressive # progressive 超额累进 / flat 全额累进 billing_cycle: monthly source: https://example.com/pricing collected_at: 2025-01-15第三阶段计算引擎。用 Python 或 TypeScript 实现计算逻辑。核心函数包括单次请求成本计算、月度成本估算、套餐包对比、阶梯累进计算。我建议把计算逻辑写成纯函数输入参数和价格规则输出费用明细方便测试和复用。第四阶段展示层。展示层可以是一个静态网页、一个 CLI 工具、或者一个 API 服务。我倾向于先做 CLI因为开发快、调试方便等规则稳定了再做网页。展示时重点突出同等用量下的成本对比和不同用量下的最优选择而不是简单罗列单价。第五阶段维护机制。这是最容易被忽视但最重要的环节。价格会变规则会变模型会下架。我建议建立一个简单的维护流程每月固定时间检查各厂商定价页发现变化就更新数据并在展示层标注变更记录。如果可能的话用脚本自动抓取定价页并对比差异能省不少人工。4.2 一个完整的成本估算实例光说流程可能还是抽象我拿一个具体场景走一遍。假设你有一个客服机器人应用日均请求 30 万次平均输入 600 token平均输出 300 token缓存命中率 25%想对比 DeepSeek、通义千问和智谱三家的月度成本。第一步整理三家的价格规则。这里我简化一下只列核心维度厂商输入单价元/千 token输出单价元/千 token缓存命中折扣阶梯规则DeepSeek0.0010.0021 折月累计超额累进通义千问0.0020.0065 折无阶梯智谱0.00150.0043 折月累计全额累进第二步计算月度 token 用量。日均请求 30 万次月按 30 天算总请求数 900 万次。输入 token 总量 900 万 × 600 54 亿 token。输出 token 总量 900 万 × 300 27 亿 token。缓存命中输入 token 54 亿 × 25% 13.5 亿 token未命中输入 token 40.5 亿 token。第三步按各家规则计算费用。以 DeepSeek 为例假设月累计用量落在第二档100 万到 500 万 token 区间这里用量远超实际会落到最高档超额累进计算未命中输入费用40.5 亿 token 405 万千 token按阶梯累进计算缓存命中输入费用13.5 亿 token 135 万千 token按 1 折计算输出费用27 亿 token 270 万千 token按输出单价计算。具体计算过程略复杂但计算引擎会自动处理。最终结果会输出一个费用明细表让你清楚看到每一部分的成本占比。提示实际估算时阶梯规则的累进计算建议用代码实现手工算容易出错。我试过手工算一次结果因为把全额累进和超额累进搞混了偏差超过 30%。4.3 套餐包对比的实现要点套餐包对比比按量付费对比更复杂因为涉及预付费和用量不确定性。这个目录的做法是用盈亏平衡点来对比套餐包和按量付费。具体来说对于每个套餐包计算在什么用量下套餐包比按量付费更划算以及在什么用量下套餐包会浪费钱。举个例子某厂商的包月套餐是 500 元/月含 1000 万 token超出部分按 0.002 元/千 token 计费。按量付费是 0.003 元/千 token。那么盈亏平衡点是500 / 0.003 16.67 万千 token也就是约 1.67 亿 token。如果你的月用量低于 1.67 亿 token按量付费更划算高于这个值套餐包更划算。但还要考虑套餐包含的 1000 万 token 是否能用完——如果用不完实际单价会更高。这个目录会在展示层直接给出推荐方案和盈亏平衡点而不是让用户自己算。我实测下来这个功能对预算敏感的小团队特别有用。5. 常见问题与排查技巧实录5.1 价格规则理解偏差的典型场景做比价目录最大的坑不是技术实现而是对价格规则的理解偏差。我整理了几个自己踩过的坑以及排查方法问题现象可能原因排查方法估算成本远低于实际账单漏算了某个计费维度对照账单明细逐项核对阶梯计算后单价没变累进类型判断错误用计费示例反推验证累进类型缓存折扣没生效缓存命中条件未满足检查模型是否支持缓存、命中判定规则套餐包估算偏差大包含额度未用完或超出计算实际用量与套餐额度的关系多模型混用成本异常阶梯是否跨模型共享确认厂商的累计规则我遇到最坑的一次是某厂商的缓存命中定义——它要求请求的 prefix 完全一致才算命中而不是语义相似就算。这个细节在定价页里只提了一句藏在脚注里。结果我按 50% 命中率估算实际只有 10%成本偏差巨大。所以采集数据时一定要把脚注和小字说明看全这是血泪教训。5.2 数据更新与版本管理价格数据会变这是比价目录最大的维护挑战。我的做法是每次更新都保留历史版本并在展示层提供价格变更记录。这样用户能看到某个厂商什么时候调过价、调了多少而不是只看到当前价格。具体实现上可以用 Git 管理数据文件每次更新提交一个 commitcommit message 写清楚变更内容。展示层读取当前版本和历史版本渲染变更记录。这个做法简单有效我用了半年多没出过问题。注意不要覆盖旧数据一定要保留历史版本。我有一次偷懒直接覆盖了结果用户问上个月的价格是多少时答不上来很尴尬。5.3 计算引擎的测试策略计算引擎的准确性是比价目录的生命线。我建议用以下策略保证准确性第一单元测试覆盖所有计费维度。每个维度单独测试确保单价计算正确。第二集成测试覆盖典型场景。用真实账单数据反推验证估算结果与账单一致。第三边界测试覆盖极端情况。用量为 0、用量极大、缓存命中率 100%、套餐额度刚好用完等边界情况都要测试。我自己的做法是每接入一个新厂商先用它的计费示例跑一遍确认结果一致后再上线。这个步骤不能省我试过跳过结果上线后发现某厂商的阶梯规则理解错了不得不紧急修复。5.4 展示层的用户体验要点比价目录的展示层不需要花哨但有几个要点必须做到同等用量对比不要只列单价要按用户的实际用量估算总成本这样才有可比性费用明细可展开用户能点开看每一部分的费用构成而不是只看到一个总数数据来源可追溯每个价格都标注来源链接和采集日期方便用户核实变更记录可查看价格调过几次、每次调多少一目了然推荐方案要谨慎不要轻易说某厂商最便宜因为不同用量下最优选择不同应该给出在你的用量下推荐 X 方案。我见过一些比价工具直接给一个性价比排名这其实误导性很强。因为性价比取决于用量、模型能力、稳定性、生态等多个因素单纯按价格排名没有意义。这个目录的做法是只做成本估算不做综合排名把选择权交给用户。6. 这个目录后续可以怎么扩展做了一段时间之后我发现这个比价目录的价值远不止比价。它其实是一个大模型成本知识库可以往几个方向扩展。第一个方向是成本优化建议。基于用户的用量特征给出具体的优化建议比如你的缓存命中率只有 10%如果提升到 30%月度成本可以降低 X 元、你的输出 token 占比过高建议优化 prompt 减少输出长度。这些建议比单纯的价格对比更有价值。第二个方向是动态路由策略。根据实时价格和用户用量自动推荐或切换最优模型。比如简单任务用便宜模型复杂任务用贵模型缓存命中率高的请求走支持缓存的厂商。这个方向技术难度较高但价值也最大。第三个方向是价格预警。当某厂商调价时自动通知用户并估算对用户成本的影响。这个功能对长期使用某厂商的用户特别有用。我自己在实际操作中的体会是比价目录的核心竞争力不在于覆盖多少厂商而在于价格规则的准确性和更新速度。覆盖 20 家但规则经常出错不如覆盖 8 家但规则准确、更新及时。这个项目如果能把按官网原样建模这件事做到极致就已经很有价值了。