1. 这个开源目录到底解决了什么问题国内做大模型应用开发的人几乎都绕不开一个灵魂拷问同样一次调用为什么账单差距能拉到几十倍我去年帮三个团队做成本优化发现大家踩的坑高度雷同——要么是凭感觉选模型要么是拿半年前的报价做预算要么是根本没算过缓存命中率对最终账单的影响。DeepSeek 在 2025 年初那波价格调整之后整个国内 API 市场的定价逻辑其实已经变了但大多数开发者手里的“价格表”还是过时的。这个开源目录的出发点特别朴素把国内主流大模型 API 的计费规则从各家文档里一条条抠出来结构化成一个可查询、可对比、可计算的数据库。它不只是列个单价而是把输入价、输出价、缓存命中价、缓存写入价、阶梯计价、限时折扣、免费额度这些维度全部拆开。更关键的是它把 DeepSeek 那个被圈内戏称为“梁文谷时间”的错峰折扣机制也建模进去了——每天特定时段调用价格直接打骨折这个规则如果不单独建模任何比价工具都是失真的。适合谁看如果你是刚接触大模型 API 的个人开发者它能帮你避开“以为很便宜结果账单爆炸”的坑如果你是团队的技术负责人它能给你一套可复现的成本测算方法如果你只是好奇国内 API 市场到底卷到什么程度这份目录本身就是一份行业快照。我下面会从设计思路、数据建模、实操复现、踩坑排查四个层面把这个项目的里里外外讲透。2. 目录的整体设计与数据建模思路2.1 为什么不能只做一个静态价格表最开始我也想过不就是把各家官网的价格截图整理成 Markdown 表格吗但真动手才发现静态表格有三个致命问题。第一价格变动太频繁DeepSeek 在 2025 年 2 月那波调整之后智谱、通义、豆包陆续跟进静态表一周就过期。第二计费维度不统一有的按 token 计费有的按字符有的输入输出同价有的差出十倍。第三也是最容易被忽略的——缓存机制。DeepSeek 的上下文缓存命中价和未命中价能差一个数量级如果你的应用有大量重复前缀比如固定的 system prompt不算缓存等于白送钱。所以这个目录的核心设计原则是把价格从“数字”变成“函数”。每个模型不是一个单价而是一组参数化的计费规则。你输入调用量、输入输出比例、缓存命中率、调用时段它输出一个预估成本。这才是真正能用来做决策的东西。2.2 数据模型的三层结构整个目录的数据模型我拆成了三层这个结构是参考了财务成本核算的思路实测下来扩展性最好。第一层是基础计价单元。每个模型定义四个核心价格输入单价每百万 token、输出单价、缓存命中单价、缓存写入单价。单位统一用“元/百万 token”因为国内厂商基本都按这个口径换算起来最省事。这里有个细节有些厂商标的是“元/千 token”录入时必须统一换算否则后面计算全错。第二层是计费规则修饰器。这一层处理各种“特殊情况”阶梯计价用量越大单价越低、时段折扣比如 DeepSeek 的错峰优惠、免费额度新用户赠送 token、限时活动价。每个修饰器是一个独立的函数可以叠加。比如一个模型既有阶梯价又有错峰折扣计算时先应用阶梯再应用时段系数。第三层是调用场景描述。这一层是给用户用的你描述自己的调用特征日均调用次数、平均输入长度、平均输出长度、缓存命中率、主要调用时段。目录根据这些参数自动匹配对应的计费规则算出日成本、月成本、年成本。提示缓存命中率这个参数最容易被低估。我实测过一个客服机器人场景system prompt 占了输入 token 的 70%开启缓存后输入成本直接降到原来的 18%。如果你的应用有固定前缀一定要把这个参数填进去。2.3 “梁文谷时间”为什么要单独建模DeepSeek 的错峰折扣机制在圈内被叫做“梁文谷时间”本质是鼓励开发者在低峰时段跑批量任务。具体规则是每天 UTC8 的 00:30 到 08:30 之间API 调用享受大幅折扣不同模型的折扣力度不一样。这个机制如果不单独建模会带来两个问题一是比价时把 DeepSeek 的折扣价当成全天价误导决策二是做成本预测时如果任务可以调度到低峰时段实际成本可能只有高峰时段的三分之一。我在目录里把时段折扣做成了一个时间轴函数。你传入调用时间戳它返回对应的折扣系数。对于批量任务目录还会给出“建议调度时段”的提示——如果你的任务不要求实时性挪到低峰时段跑一年省下来的钱够买台不错的开发机。这个建模思路其实可以推广到所有有时段优惠的厂商只是 DeepSeek 的折扣力度最大所以最值得单独拎出来说。3. 核心数据字段与计费规则拆解3.1 输入输出计费的非对称陷阱国内大模型 API 的计费有个普遍规律输出比输入贵。这个贵不是贵一点而是贵两到四倍。比如某主流模型输入 1 元/百万 token输出可能要 4 元/百万 token。这个非对称性对成本的影响极大但很多开发者在估算时习惯性地用“平均单价”结果偏差能到 50% 以上。我在目录里强制把输入价和输出价分开录入并且在成本计算器里要求用户分别填写平均输入长度和平均输出长度。为什么因为不同应用的输入输出比例差异太大了。翻译类应用输入输出比接近 1:1但摘要类应用可能是 10:1对话类应用随着轮次增加输入会越来越长。如果你只填一个“总 token 数”算出来的成本没有参考价值。这里有个实操技巧如果你不确定自己的输入输出比例可以先跑 100 次真实调用把每次的 prompt_tokens 和 completion_tokens 记下来取平均值。这个数据比拍脑袋准得多。目录里提供了一个简单的 Python 脚本模板调用各家 SDK 的返回字段里都有这两个值跑一遍就有数了。3.2 缓存计费的两种模式缓存这块国内厂商主要分两种模式。一种是自动缓存比如 DeepSeek你不需要做任何额外操作系统自动识别重复前缀命中就按缓存价计费。另一种是显式缓存需要你手动创建缓存对象比如某些厂商的 context cache 功能。两种模式的计费规则不一样自动缓存通常只收命中价显式缓存可能还有存储费。目录里对这两种模式分别建模。自动缓存的模型你只需要填一个缓存命中率参数显式缓存的模型除了命中率还要填缓存创建成本和存储时长。我建议优先选择支持自动缓存的模型因为显式缓存的运维复杂度高而且存储费在长上下文场景下可能反超节省的费用。注意缓存命中价虽然便宜但不是所有内容都适合缓存。如果你的 prompt 前缀经常变化缓存命中率会很低这时候缓存写入的额外开销反而可能让总成本上升。目录里有个“缓存收益临界点”计算输入你的前缀变化频率它会告诉你开缓存划不划算。3.3 阶梯计价与免费额度的处理阶梯计价在国内 API 市场越来越常见逻辑是月用量超过某个阈值后超出部分单价下调。这个规则在建模时要注意两点一是阶梯通常按月重置跨月计算要分段二是阶梯价和折扣价可能叠加顺序不同结果不同。目录里统一按“先阶梯、后折扣”的顺序计算这是大多数厂商文档里的默认逻辑。免费额度这块新用户注册通常送几十到几百万 token 不等。目录里把免费额度做成了一个独立的抵扣项在计算月成本时优先扣除。但要注意免费额度一般有有效期通常是 30 天或 90 天过期作废。如果你在有效期内用不完实际成本会比目录算出来的高。所以我在目录里加了一个“免费额度利用率”提示如果你的预估用量远低于赠送额度它会提醒你注意过期风险。4. 实操从零复现这个目录的核心功能4.1 数据采集与结构化录入第一步是采集数据。各家厂商的定价页面结构不一样有的用表格有的用卡片有的藏在文档深处。我的做法是人工采集加脚本校验。人工负责从官网找到最新价格录入到一个 YAML 文件里脚本负责检查数据格式是否统一、单位是否换算正确、必填字段是否缺失。YAML 文件的结构大概长这样deepseek-chat: provider: DeepSeek input_price: 1.0 # 元/百万token output_price: 4.0 cache_hit_price: 0.1 cache_write_price: 1.0 off_peak_discount: 0.5 # 低峰时段折扣系数 off_peak_window: 00:30-08:30 free_quota: 5000000 # 赠送token数 quota_expiry_days: 30 tiered_pricing: - threshold: 100000000 # 1亿token input_price: 0.8 output_price: 3.2这个结构的好处是新增一个模型只需要加一段 YAML不用改代码。校验脚本会检查价格是否为正数、折扣系数是否在 0 到 1 之间、时段格式是否正确。我踩过的坑是有一次把“元/千 token”直接填进去了结果算出来的成本差了 1000 倍后来加了单位校验才避免。4.2 成本计算引擎的实现计算引擎的核心是一个函数输入是调用场景参数输出是成本明细。我用 Python 写了一个简化版逻辑清晰方便你改成自己需要的语言。def calculate_cost(model_config, daily_calls, avg_input_tokens, avg_output_tokens, cache_hit_rate, peak_ratio): # 单次调用的输入输出token input_tokens avg_input_tokens output_tokens avg_output_tokens # 缓存部分 cached_tokens input_tokens * cache_hit_rate uncached_tokens input_tokens * (1 - cache_hit_rate) # 高峰时段成本 peak_input_cost (uncached_tokens * model_config[input_price] cached_tokens * model_config[cache_hit_price]) / 1_000_000 peak_output_cost output_tokens * model_config[output_price] / 1_000_000 peak_cost_per_call peak_input_cost peak_output_cost # 低峰时段成本如果有折扣 if off_peak_discount in model_config: off_peak_cost_per_call peak_cost_per_call * model_config[off_peak_discount] else: off_peak_cost_per_call peak_cost_per_call # 按高峰比例加权 avg_cost_per_call (peak_cost_per_call * peak_ratio off_peak_cost_per_call * (1 - peak_ratio)) daily_cost avg_cost_per_call * daily_calls monthly_cost daily_cost * 30 # 扣除免费额度 if free_quota in model_config: free_deduction model_config[free_quota] * model_config[input_price] / 1_000_000 monthly_cost max(0, monthly_cost - free_deduction) return { daily_cost: round(daily_cost, 2), monthly_cost: round(monthly_cost, 2), cost_per_call: round(avg_cost_per_call, 6) }这个函数里有个关键参数peak_ratio表示高峰时段调用占比。如果你的任务可以全部调度到低峰时段这个值填 0成本直接打对折甚至更多。我实测过一个批量翻译任务全部挪到低峰时段后月成本从 1200 元降到了 480 元。4.3 比价视图与决策辅助光有计算还不够决策时需要横向对比。目录里提供了一个比价视图把多个模型在相同调用场景下的成本并排展示。这个视图的关键是场景一致性——所有模型必须用同一组调用参数计算否则对比没有意义。比价视图的输出大概是这样模型日成本月成本单次成本缓存节省模型A12.5元375元0.00125元32%模型B8.3元249元0.00083元45%模型C15.2元456元0.00152元18%但比价不能只看价格。我在目录里加了一列“能力标签”标注每个模型擅长的任务类型。有些模型便宜但只适合简单分类复杂推理任务上表现差换模型后可能需要重试多次实际成本反而更高。这个标签是我根据公开评测和自己的实测经验打的仅供参考你最好用自己的业务数据验证。5. 常见问题与排查技巧实录5.1 价格数据过期怎么办这是最高频的问题。我的建议是建立一个“价格巡检”机制每周花十分钟打开目录里列出的厂商定价页面核对关键价格是否有变动。目录里有个last_verified字段记录每个模型价格的最后核对日期超过 30 天没核对的会标黄提醒。如果你不想手动巡检可以写个简单的爬虫脚本定期抓取定价页面的关键数字和 YAML 里的值对比不一致就发通知。但要注意有些厂商的定价页面是动态渲染的爬虫可能抓不到这时候还是得人工确认。我试过用无头浏览器抓稳定性一般后来还是回归人工加提醒的方式。5.2 实际账单和预估对不上这个问题我遇到过好几次排查下来通常是三个原因。第一输入输出比例估错了。你以为输入输出是 3:1实际可能是 1:1输出贵成本自然超。解决办法是跑一批真实调用统计实际的 token 分布。第二缓存命中率没算准。如果你的 prompt 前缀有动态内容比如时间戳、用户 ID缓存命中率会远低于预期。第三阶梯计价没触发。你以为用量到了第二阶梯实际差一点单价还是第一阶梯的。排查顺序建议是先看账单里的 token 明细确认输入输出比例再看缓存命中数据确认命中率最后看计费阶梯确认是否跨档。目录里提供了一个“账单差异分析”模板你把实际账单数据填进去它会逐项对比预估和实际的差异来源。5.3 低峰时段任务调度踩坑把任务挪到低峰时段省钱这个思路没问题但有几个坑要注意。第一时区问题。DeepSeek 的低峰时段是按 UTC8 定义的如果你的服务器在其他时区调度脚本要换算。第二任务超时。低峰时段虽然便宜但如果任务量太大跑到高峰时段还没结束超出部分就按高峰价算了。建议给批量任务设置一个“截止时间”到点没跑完就暂停下一个低峰时段继续。第三也是最容易忽略的——低峰时段的稳定性。虽然大多数时候没问题但偶尔会有维护或限流。如果你的任务对时效性有要求不要把所有任务都押在低峰时段留一部分在高峰时段跑作为缓冲。我一般建议低峰时段承担 70% 到 80% 的批量任务剩下的放高峰时段。5.4 免费额度用不完的浪费新用户赠送的 token 有有效期用不完就作废。我见过一个团队注册了五个厂商的账号每个都有几百万免费 token结果只用了其中一家的其他四家的额度全过期了。目录里有个“免费额度追踪”功能你填入各账号的赠送额度和到期日它会提醒你哪些快过期了建议优先使用。但要注意免费额度通常只抵扣输入和输出的基础费用缓存费用、存储费用可能不在抵扣范围内。用之前看清楚规则别以为免费额度能覆盖所有开销。6. 这个目录后续可以怎么扩展我目前把重点放在文本模型的 API 计费上但国内多模态模型的 API 也在快速降价。图像输入、视频理解的计费规则和文本不一样通常是按图片数量或分辨率计费这块我还没建模后续可以加一个多模态计费模块。另一个方向是成本优化建议引擎。现在目录只能告诉你“多少钱”不能告诉你“怎么省”。如果结合你的调用日志分析出哪些请求可以合并、哪些可以缓存、哪些可以换更便宜的模型给出具体的优化建议那价值就大得多。我试过用规则引擎做了一版效果还行但规则维护成本高后面考虑用轻量模型来做建议生成。还有一个实用的扩展是预算告警。你设置一个月度预算上限目录每天根据实际调用量预估月底成本超过阈值就发提醒。这个功能对团队用户特别有用避免月底账单出来才发现超支。实现上也不复杂定时任务加一个邮件或 webhook 通知就行。最后再分享一个小技巧如果你同时用多家 API建议把调用日志统一格式记录每次调用的模型、输入输出 token 数、缓存命中情况、调用时间。这些数据积累下来就是你做成本优化的金矿。我自己的日志表跑了三个月靠分析这些数据把整体 API 成本压低了 40% 多比单纯比价有效得多。