大模型 API 定价比较

· 固定用量：日均 100 次调用 · 单次输入 2000 / 输出 800 Token · 每月 30 天；
· 错峰口径：分时段模型按低谷价计（DeepSeek 低谷约为高峰一半，高峰窗口为工作日 9:00-12:00、14:00-18:00）；
· 缓存：命中率 30%，输入有效单价 = 30% × 缓存命中价 + 70% × 未命中价；官方未公开缓存价的模型按未命中价计；
· 分档：按输入长度分档的模型，2000 Token 落入其低档；
· 币种：单价保留官方原币种（人民币或美元 / 百万 Token）；月成本统一按参考汇率折算人民币后排序，折算仅供参考；
· 公式逐步推导见 《如何计算 LLM API 成本》，口径规则见 定价方法论。

· 输出单价主导账单：示例用量下输出项约占月成本 55%~65%（输出 800 Token × 输出单价），只比输入价会系统性低估；
· 缓存价是数量级差异：DeepSeek 两款的缓存命中价（低谷 ¥0.02/百万）比其未命中输入价（低谷 ¥1/百万）低约 50 倍，高命中率场景下输入成本趋近缓存价；
· 低谷半价是可预期收益：分时段模型按低谷口径估算，批量任务移到低谷时段成本直接减半，这不是假设性优化而是计费规则；
· 长上下文档位不"补价"：GPT-6 系列 >272K 档费率官方未公开，该范围估算会显示"无法估算"，本站不按低档价格填充。

把估算月成本排序之后，最常见的错误动作是"从最便宜的一行往上选"。这张表的用途是排除明显不适用的候选，而不是直接给出答案。原因有三层，且都与价格表本身无关。

第一层：价格结构与任务结构不匹配。输入价便宜、输出价贵的模型适合"读得多、写得少"的任务——检索问答、分类打标、抽取字段、批量摘要；反过来，输出价占比低的模型更适合长文生成、代码补全、多轮改写。示例用量（输入 2000 / 输出 800）只是一个折中，如果你的实际比例是 30:1 或 1:5，同一张表的排序会翻转。判断方法很直接：先用自己日志里的输入输出比例替换示例比例，再看名次变化；变化大的模型就是"对这个任务价格结构不匹配"的模型。

第二层：长上下文会把分档价格提前引爆。按输入长度分档计价的模型，档位边界是台阶不是斜坡：单次输入一旦越过边界，整次请求的单价跳到高档（本站 模型库 在各模型档案里列出全部档位与边界，例如 MiniMax M3 以 512K 输入为界、Claude Haiku 5.5 以 100K 提示为界，核验日期见档案页）。示例用量里 2000 Token 的输入永远落在低档，所以对比表看不出这个风险。要评估长文档任务，请把单次输入设成你的真实 P95 值再重算一次，并且注意：分档看的是单次请求长度，不是月累计量。

第三层：缓存命中率是乘数，不是常数。示例统一按 30% 命中率折算输入有效单价，但真实命中率取决于业务形态：固定系统提示词 + 固定知识库前缀的客服机器人可能跑到 70% 以上，而每次请求都带不同用户上下文的应用可能接近 0。更关键的是缓存命中价的相对折扣差距大于未命中价的差距——同一份表里，不同厂商"命中价 / 未命中价"的比值并不相同，有的接近 1/50，有的只有 1/10 上下，命中率越高，这个比值带来的输入侧成本差越被放大。反过来，官方未公开缓存价的模型只能按未命中价计，它在高命中率场景里会被系统性高估，不能据此判它"贵"。

把这三层叠加起来，得到的结论很朴素：先用自己的真实输入输出比例、P95 输入长度与实测命中率重算一遍成本，再进入质量评估。用 成本计算器 改这四个参数比读任何排名都有效。

成本只是约束条件之一。下面这张决策表把选型时需要回答的问题摊开，每一行都对应一类可以在上线前验证、而不是靠印象回答的问题：

评估维度	关注问题	怎么验证
成本	输入、输出、缓存读写、分档边界与真实月成本	用日志里的比例与 P95 输入重算（本文第四节）
质量	任务准确率、结构化输出能否稳定解析、工具调用成功率	自建测试集跑通过率，见本文第六节
延迟	首 Token 延迟（流式）与完整响应时间（非流式）	同地区、同输入长度压测，记录 P50/P95
稳定性	限流维度与配额、错误率、超时行为、是否支持幂等重试	读官方限流文档 + 生产前小流量观察
上下文	业务实际所需输入长度、最大输出、是否跨档	统计真实输入分布，与模型规格对齐
安全	数据处理位置、日志留存、密钥管理与合规边界	读服务条款与数据处理说明，见 定价方法论 的数据口径

这张表里没有"综合评分"一列，是刻意的。本站不对模型质量做排名：没有可复现的实测基准，任何评分都是编的。质量只能由你自己的测试集回答，而测试集的构建成本远低于选错模型半年的返工成本。

延迟与限流值得单独提醒：RPM/TPM 这类限额是账号、套餐、模型与服务条件相关的，官方文档给出的示例值不是"所有用户的固定上限"；把某个数字当作常量写进容量规划，是最常见的生产事故来源之一。选型阶段至少要确认：限流命中时返回什么状态码、是否带 Retry-After、超额是排队还是直接拒绝。这些决定你能不能靠重试撑过峰值。

模型质量在你自己的任务上，与它在公开榜单上的位置往往关系不大。可操作的路径是抽一批真实请求做小测试集，规模不必大，30~100 条就足够区分明显不合适的候选。构建要点：

· 抽样要覆盖分布的两端：既要有典型请求，也要有最长的输入与最刁的输出格式，否则测出来的通过率没有参考价值；
· 为每条样本写"可判定的期望"：能自动判定的（字段是否齐全、JSON 能否解析、枚举值是否合法、数值是否落在区间）优先自动判，不能自动判的（措辞质量、摘要忠实度）抽样人工过一遍，不要给自己造一个需要全量人工的评测；
· 把成本与延迟一起记：同一批样本跑每个候选模型，记录通过率、单次平均成本、P50/P95 延迟，三列并排才能做取舍；
· 固定版本与参数：温度、最大输出、系统提示词全部冻结，否则差异无法归因；厂商更新模型时用同一批样本复跑，这就成了回归测试。

三个维度怎么合成结论？不要算加权总分，用支配关系判断更稳：如果候选 A 在成本、通过率、延迟三项上都不差于 B，且至少一项更好，就淘汰 B；剩下的候选构成一条"前沿"，最终选择取决于你的业务更怕哪一种失败——怕超支就选前沿上成本最低的，怕答错就选通过率最高的。这个判断没法外包给排名表。

把前面的内容收拢成七步，任何一次换模型都可以照着走一遍：

· 1. 明确约束：单次输入 P95、输出上限、并发峰值、可用预算上限、数据能否出境或离开内网；
· 2. 用硬约束先筛：上下文不够、模态不支持、区域不合规的候选直接出局，不要先比价格；
· 3. 用真实比例重算成本：替换示例用量，把分档与缓存命中率按实测值代入，得到候选集的月成本区间；
· 4. 建小测试集跑质量与延迟：同批样本、同参数、同地区，记录通过率与 P50/P95；
· 5. 在成本-质量-延迟上找前沿：淘汰被支配的候选，剩下的 2~3 个进入决策；
· 6. 验证工程可用性：限流返回形态、重试与超时语义、流式是否可用、错误码是否稳定可编程；
· 7. 留退路：抽象出可替换的调用层、双供应商灰度开关、以及"换模型后成本会不会失控"的监控口径。

第 7 步最容易被跳过，但它决定了这次选型是一次性决策还是可持续决策。切换成本主要不在代码，而在提示词与解析逻辑对某个模型行为的隐式依赖——把这两者与调用层解耦，换模型的代价才降到可以按季度重新评估的水平。

· 数据来自本站唯一数据源 models.json，每条记录标注官方来源链接；价格核验日期见表内"核验日期"列与各模型档案页（/models/ 目录）；
· 页脚汇总全部官方来源；价格核验时间 ≠ 页面内容更新时间：仅重新核验而价格未变时，页面与 sitemap 的更新日期保持不变（规则见定价方法论第六节）；
· 跨币种折算使用中国外汇交易中心人民币汇率中间价（静态参考汇率，非交易汇率）；
· 估算未计入免费额度、资源包、套餐折扣与限时活动，不等于服务商实际账单，不构成采购建议。

· 第四至第七节的档位边界与缓存倍率均为定性引用，具体数值请以模型档案页与厂商官方页面为准。本文在 2026-10-31 实际访问核验了 Claude 定价页（缓存读取/写入价格、100K 分档、5 分钟 TTL 基准）与 DeepSeek 价格页（上下文长度、最大输出与并发示例值）； OpenAI 与 Google 的官方文档在本次核验中无法访问（分别返回 403 与请求超时），因此本文不引用这两家的门槛与倍率，也不对模型质量做任何排名。

· 代入真实用量重算：成本计算器（可勾选任意多款模型并排比较）；
· 查单款模型的完整价格档案：模型库；
· 两款候选逐项对比：模型对比，例如 GLM-5.3-Flash 对比 GPT-6 Luna（低价轻量跨厂商）；
· 按业务场景估月成本：场景成本案例；
· 回到 计算指南目录。