大模型 API 的价格战打了两年，价目页上的数字一直在动，但计费结构比单价稳定。看懂结构，你才能判断账单为什么涨、能从哪省。下面这张表不列具体单价，因为各厂调价频繁，写死的数字很快过期；它列的是计费维度，这些维度决定了同样一次请求在不同平台上的费用差几倍。
单价只是价目表的一行
一份完整的价目表至少有四层：计费单位、输入输出差价、上下文分档、优惠方式。只看“每百万 token 多少元”这一行，容易得出错误结论：甲平台输入便宜，但输出贵；乙平台单价高，缓存折扣大。真实账单由你的请求结构决定，不由单价决定。
所以比较两个平台，要拿自己的一条典型请求去算：系统提示多长、历史对话几轮、检索片段多少、输出多少字，再套各自的计价规则。
输入与输出为什么分开计价
输入是一次前向计算，输出是逐 token 生成，每多一个 token 都要再跑一次完整前向。生成量随长度累积，输出单价通常高于输入，倍数因厂商和模型而异。这决定了省钱方向：控制输出长度，比压缩输入更有效。
输入侧也要算。系统提示、历史对话、检索片段每次随请求重新送进去，全部计入输入。多轮对话聊到二十轮，前面十九轮的内容可能一直在重复计费。做法是定期摘要：把早期对话压成几句结论，替换掉原文。
缓存命中：降价里容易漏掉的一项
多数平台对重复的前缀提供折扣：同一段系统提示、同一份长文档，再次请求时命中缓存，这部分按更低的价计。要用上它，提示词结构要稳定：固定内容放前面，变量放后面，前缀一个字都别改。
缓存通常有有效期，隔一段时间不用就失效；具体时长和折扣以官方说明为准。另一个坑是顺序：用户问题放在系统提示之前，每次前缀都不同，缓存永远命中不了。
七类计费维度对照
| 计费维度 | 计费单位 | 计价方式 | 适合场景 | 容易忽略的坑 |
|---|---|---|---|---|
| 输入 token | 每百万 token | 按请求实际送入的内容计 | 长文档问答、检索增强 | 系统提示、历史对话、检索片段都算输入 |
| 输出 token | 每百万 token | 按生成内容计，单价通常高于输入 | 写作、代码生成、摘要 | 输出长度不受控，截断阈值设得过松 |
| 缓存命中 | 每百万 token | 命中前缀缓存的部分按折扣价计 | 固定系统提示、多轮同一文档 | 缓存有有效期；前缀改一个字就失效 |
| 长上下文 | 按输入长度分档 | 超过阈值后按更高档计价 | 长报告、代码库分析 | 分档规则各厂不同，超一档可能整单涨价 |
| 免费额度 | 按账号或按模型 | 有效期内的赠送 token 或调用次数 | 验证可行性、小流量测试 | 额度到期和限流是两件事，免费档常有并发上限 |
| 预付费包 | 按包年或包月 | 先买额度，再抵扣调用量 | 调用量稳定的生产业务 | 包未必跨模型通用，剩余额度能否退要看条款 |
| 批处理任务 | 按任务或按 token | 非实时任务按更低价格结算 | 数据清洗、批量标注 | 有周转时间要求，不适合在线请求 |
对照表的用法：先看你的请求落在哪几行，再看那几行的规则。多数应用的账单由输入、输出、缓存三行决定。
长上下文按长度分档
上下文窗口大，不等于同样价格。不少平台按输入长度分档，超过某个阈值后，超出部分或整段请求按更高档计价。阈值和规则各家不同，唯一可靠的做法是查当前价目页的说明。
反直觉的判断是：长文档问答未必要把整篇塞进去。先用检索定位到相关章节，只送那几段，费用可能更低，准确率还更高。上下文塞满还会稀释注意力。
免费额度和预付费包怎么算
免费额度适合验证可行性，不适合跑生产。它通常有有效期，也有并发和速率限制；额度没用完和能不能稳定调用是两件事。做压力测试时，免费档的限流会把问题掩盖成“偶发失败”。
预付费资源包适合调用量稳定的业务，单价通常低于按量付费，但要注意三条：包是否限定模型、额度是否有有效期、剩余额度能不能退。模型升级换代时，旧包的适用范围可能变窄，这笔钱就压住了。
便宜模型出错后的隐性成本
单价低三倍，如果返工率高两倍，总成本反而更高。隐性成本包括人工复核、失败重试、错误结果流到下游的修复成本。选型时要把这三项折进去，而不是只比单价。
可行的做法是分层：简单分类、格式转换、短文本摘要用便宜模型；多步推理、长文理解、代码生成用强模型。关键是路由规则按任务类型分流，写下来，账单才可控。
还有一项不写在价目表上：稳定性。限流阈值、峰值可用性、模型版本会不会悄悄更新，决定了系统要不要加重试和降级。低价往往是获客手段，能否持续要看厂商的长期策略；怎么看懂一次价格战讲的就是这个视角。
选型时看三件事
先看计费结构是否匹配你的请求形态。价目表的读法比单价本身重要：输入输出比例、缓存规则、分档阈值，这三项决定你的实际单价。
再看稳定性与合规。有没有服务等级约定、数据是否用于训练、日志留存多久、能不能开专有实例。这些条款在低价档里经常收紧，签约前要逐条看。
再看可替换性。把模型调用抽象成一层接口，请求格式、重试、降级都收在这里，换模型只改配置。价格一变就能换，才谈得上吃到降价的好处；API 计费和订阅计费的区别也影响这层怎么设计。
需要说明的是，本文不列具体单价，因为调价太快，任何写死的数字都会误导。具体单价随厂商调整，以各官网价目页为准；做预算时留出两成浮动空间。
读价目表的顺序
- 确认计费单位：按 token、按次、还是按字符
- 算一条典型请求的输入输出构成
- 查缓存规则和上下文分档阈值
- 确认免费额度的有效期与限流
- 把返工和复核时间折进总成本
价格战给的是谈判空间，不是免费午餐。把计费结构吃透、把调用层做成可替换的，降价才真正落到你的账单上。若要在自部署和调 API 之间做选择，可控与省心的取舍是另一条要算的账。
