企业官网建设流程全解析

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 的错峰折扣机制在圈内被叫做“梁文谷时间”，本质是鼓励开发者在低峰时段跑批量任务。具体规则是每天 UTC+8 的 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 比价视图与决策辅助

光有计算还不够，决策时需要横向对比。目录里提供了一个比价视图，把多个模型在相同调用场景下的成本并排展示。这个视图的关键是场景一致性——所有模型必须用同一组调用参数计算，否则对比没有意义。

比价视图的输出大概是这样：

但比价不能只看价格。我在目录里加了一列“能力标签”，标注每个模型擅长的任务类型。有些模型便宜但只适合简单分类，复杂推理任务上表现差，换模型后可能需要重试多次，实际成本反而更高。这个标签是我根据公开评测和自己的实测经验打的，仅供参考，你最好用自己的业务数据验证。

5. 常见问题与排查技巧实录

5.1 价格数据过期怎么办

这是最高频的问题。我的建议是建立一个“价格巡检”机制：每周花十分钟，打开目录里列出的厂商定价页面，核对关键价格是否有变动。目录里有个last_verified字段，记录每个模型价格的最后核对日期，超过 30 天没核对的会标黄提醒。

如果你不想手动巡检，可以写个简单的爬虫脚本，定期抓取定价页面的关键数字，和 YAML 里的值对比，不一致就发通知。但要注意，有些厂商的定价页面是动态渲染的，爬虫可能抓不到，这时候还是得人工确认。我试过用无头浏览器抓，稳定性一般，后来还是回归人工加提醒的方式。

5.2 实际账单和预估对不上

这个问题我遇到过好几次，排查下来通常是三个原因。第一，输入输出比例估错了。你以为输入输出是 3:1，实际可能是 1:1，输出贵，成本自然超。解决办法是跑一批真实调用，统计实际的 token 分布。第二，缓存命中率没算准。如果你的 prompt 前缀有动态内容（比如时间戳、用户 ID），缓存命中率会远低于预期。第三，阶梯计价没触发。你以为用量到了第二阶梯，实际差一点，单价还是第一阶梯的。

排查顺序建议是：先看账单里的 token 明细，确认输入输出比例；再看缓存命中数据，确认命中率；最后看计费阶梯，确认是否跨档。目录里提供了一个“账单差异分析”模板，你把实际账单数据填进去，它会逐项对比预估和实际的差异来源。

5.3 低峰时段任务调度踩坑

把任务挪到低峰时段省钱，这个思路没问题，但有几个坑要注意。第一，时区问题。DeepSeek 的低峰时段是按 UTC+8 定义的，如果你的服务器在其他时区，调度脚本要换算。第二，任务超时。低峰时段虽然便宜，但如果任务量太大，跑到高峰时段还没结束，超出部分就按高峰价算了。建议给批量任务设置一个“截止时间”，到点没跑完就暂停，下一个低峰时段继续。

第三，也是最容易忽略的——低峰时段的稳定性。虽然大多数时候没问题，但偶尔会有维护或限流。如果你的任务对时效性有要求，不要把所有任务都押在低峰时段，留一部分在高峰时段跑作为缓冲。我一般建议低峰时段承担 70% 到 80% 的批量任务，剩下的放高峰时段。

5.4 免费额度用不完的浪费

新用户赠送的 token 有有效期，用不完就作废。我见过一个团队，注册了五个厂商的账号，每个都有几百万免费 token，结果只用了其中一家的，其他四家的额度全过期了。目录里有个“免费额度追踪”功能，你填入各账号的赠送额度和到期日，它会提醒你哪些快过期了，建议优先使用。

但要注意，免费额度通常只抵扣输入和输出的基础费用，缓存费用、存储费用可能不在抵扣范围内。用之前看清楚规则，别以为免费额度能覆盖所有开销。

6. 这个目录后续可以怎么扩展

我目前把重点放在文本模型的 API 计费上，但国内多模态模型的 API 也在快速降价。图像输入、视频理解的计费规则和文本不一样，通常是按图片数量或分辨率计费，这块我还没建模，后续可以加一个多模态计费模块。

另一个方向是成本优化建议引擎。现在目录只能告诉你“多少钱”，不能告诉你“怎么省”。如果结合你的调用日志，分析出哪些请求可以合并、哪些可以缓存、哪些可以换更便宜的模型，给出具体的优化建议，那价值就大得多。我试过用规则引擎做了一版，效果还行，但规则维护成本高，后面考虑用轻量模型来做建议生成。

还有一个实用的扩展是预算告警。你设置一个月度预算上限，目录每天根据实际调用量预估月底成本，超过阈值就发提醒。这个功能对团队用户特别有用，避免月底账单出来才发现超支。实现上也不复杂，定时任务加一个邮件或 webhook 通知就行。

最后再分享一个小技巧：如果你同时用多家 API，建议把调用日志统一格式，记录每次调用的模型、输入输出 token 数、缓存命中情况、调用时间。这些数据积累下来，就是你做成本优化的金矿。我自己的日志表跑了三个月，靠分析这些数据把整体 API 成本压低了 40% 多，比单纯比价有效得多。