同一段超长输入，各家 API 怎么计价？长上下文成本对比
事实依据为 2026-08-24 抓取的各厂商官方文档。文中不写具体单价与档位数值，这类数字变动频繁，请以官方定价页为准。
把一份很长的文档丢进模型，各家收你的钱可能差出好几倍，但差距的来源往往不是单价高低，而是计价形态不一样。最容易吃亏的一种是阶梯计价——不是「超出的部分贵一点」，而是整次请求全部按更贵的那一档重新结算。差一个 token 越过临界线，账单就跳一级。
四种计价形态
把几家官方定价页的表格结构摆在一起看，长输入的计价大致分成四种形态，它们的表头列就不一样。
形态一：按单次请求的输入长度分阶梯。 阿里云百炼的计费文档里有一节专门讲阶梯计费规则，原文说明部分模型实行阶梯计费，单价取决于单次请求的输入 token 总量，并且关键的是下一句——该请求的所有 token 均按对应阶梯的单价结算。文档还给了一个例子：某模型设两档区间，若输入落在第二区间，则所有 token 都按第二档单价结算。同一份文档里，也有模型在这一列直接标注为「无阶梯计价」，所以同一个平台上不同模型的形态都可能不同，不能按厂商一刀切地判断。
形态二：全程一个价。 Kimi K3 的官方定价页表格列是模型、计费单位、输入价格（缓存命中）、输入价格（缓存未命中）、输出价格、上下文窗口——没有「输入 token 区间」这一列，也就是说在它标称的上下文窗口范围内，长输入和短输入是同一个单价，区别只在命中缓存与否。
形态三：按调用时段分档。 DeepSeek 的模型与价格页把价格拆成了空闲时段和高峰时段两套，注释里说明空闲时段价格是高峰时段的一半，高峰时段按北京时间的工作日时间窗划定（具体时间窗以官方页面为准，其余时间均为空闲时段）。这是唯一一种和输入长度完全无关的分档方式——它奖励的是「你愿意什么时候跑」，而不是「你喂了多长」。对可以离线处理的长文档任务来说，这条比什么优化都直接。
形态四：把缓存拆成独立的价格位。 智谱国际站 Z.AI 的定价表里，文本模型有 Input、Cached Input、Cached Input Storage、Output 四列。缓存存储被单列成一列（当前标注为限时免费）。长上下文场景下缓存的内容体量本来就大，一旦存储位开始计费，它是按「驻留时长」而不是「调用次数」走的，成本模型跟前三种完全不同。
阶梯计价的杀伤力在临界点
形态一值得单独展开，因为它最容易把预算算错。
关键在于「全量重算」这四个字。假设某模型的第一档到 32K，第二档到 128K。你的请求输入 33K，那么这 33K 全部按第二档单价结算，而不是「32K 按第一档、多出来的 1K 按第二档」。这和阶梯电价、阶梯个税的直觉正好相反——那两个是分段累进，这个不是。
由此推出三个非常实际的结论：
第一，临界点附近的边际成本是负的。 从 32K 增加到 33K，你多喂了 3% 的内容，账单却整体跳了一级。**在临界点上方一点点的位置，是整条曲线上性价比最差的地方。**如果你的请求长度经常在某个档位边缘徘徊，做一次内容裁剪的收益会远超预期。
第二，你要量的是分布，不是平均值。 平均输入长度 20K 完全不能说明问题——如果有三成请求落在 40K，那三成请求全部按更贵的档位结算。**正确的做法是量 P95、P99 的输入长度，看看它们落在哪一档。**token 长度怎么量，见token 是怎么算的。
第三，多轮对话是会自己长大的。 每追加一轮，输入都在变长。一个上线时稳稳待在第一档的对话应用，跑上几个月、对话轮次变多之后，可能有相当比例的请求悄悄进了第二档，而代码一行都没改。对多轮场景，必须有主动的历史裁剪策略，否则成本曲线会自己往上爬。
长输入还有几笔容易漏算的账
输出侧也可能跟着跳档。 阿里的计费表格里，输入档位那一列变化时，输出单价也跟着变——也就是说长输入不只让输入变贵，输出也一并涨价。做预算时如果只把阶梯规则套在输入上，会系统性低估。
思考模式的思维链算输出。 同一份计费表里，思考模型的输出单价一列明确标注为「思维链+回答」。这意味着那些你很可能根本不展示给用户的推理过程，照样按输出 token 收费，而输出单价通常明显高于输入。**长上下文任务如果同时开了深度思考，两个昂贵项会叠在一起。**Kimi 那边则提供了推理强度参数，官方文档说明它用来在几个档位之间调节推理深度、延迟与 token 消耗——推理深度是可以当成成本旋钮来用的。
文档抽取出来的内容照样按输入计费。 Kimi 的定价说明页里有一句很容易被略过的话：如果你上传并抽取文档内容，再把抽取的内容作为输入传给模型，那么文档内容也将按量计费；文件相关接口（内容抽取、文件存储）本身在官方标注为限时免费。「文件接口免费」和「把文件内容喂给模型免费」是两回事，长文档场景下这笔才是大头。
地域会影响单价。 阿里的计费文档里，同一个模型 ID 在不同的服务部署范围下有不同的单价，海外地域的单价普遍高于中国大陆地域。长上下文任务本来单次消耗就大，地域选错会把差价放大。这条的完整讨论见下一节提到的国际站与大陆站的选择。
缓存在长输入上的表现也不一样
长上下文和缓存是强相关的：如果你反复对同一份长文档提问，缓存是省钱幅度最大的手段；但各家的规则决定了它到底能不能生效。
DeepSeek 的缓存文档里有一条专门针对长内容的设计：除了在请求结束位置和检测到公共前缀时落盘，系统还会按固定的 token 间隔截取缓存前缀单元，避免长前缀因迟迟未达到结束位置而完全无法被缓存。这条规则就是为长输入长输出场景准备的。
阿里的显式缓存则要注意回溯范围——系统以 cache_control 标记位置为终点向前回溯有限个内容块，超过这个块数就够不着更早的缓存块了。长对话累积的消息条数很容易超过这个上限。
各家缓存规则的完整对比，见大模型 API 的缓存计费差在哪。
别把三个数字混为一谈
长上下文话题里有三个数字经常被当成同一个用，其实完全不同：
- 上下文窗口：模型能接收的最大输入长度，写在模型详情页；
- 计费档的区间上限：价格分档分到多长，写在计费页；
- 最大输出长度：单次能生成多少，通常远小于上下文窗口——DeepSeek 的价格页就把上下文长度和输出长度分成了两行来标。
一个模型可能上下文窗口很大，但计费档只分到某个长度；也可能窗口很大而单次输出上限不高。**做方案时这三个数字要分别去对应的页面查，不能互相推断。**跨厂商的窗口与档位对照，见国产大模型 API 价格对比。
一套可以照着做的长文本降本顺序
按收益从高到低排：
- 先量分布。 P95 输入长度落在哪一档，是所有决策的前提。没量过就谈优化都是猜。
- 看能不能不越档。 如果 P95 只比某个临界点高一点，优先做输入裁剪：去掉重复的模板文字、压缩历史轮次、把附件里用不上的部分先过滤掉。这一步的投入产出比通常最高。
- 看时段能不能挪。 如果目标厂商有时段定价，且你的任务能离线跑，把批量任务挪到便宜时段是零改造成本的降价。
- 再上缓存。 前缀稳定、复用密度高才划算，还要确认你的长输入符合对方的缓存规则。
- 最后才是换模型或换厂商。 换厂商的迁移成本、限流口径变化、字段名变化都是隐性代价，放在最后考虑。
把这些代入月度预算的算法，见大模型 API 月成本怎么算。
核实边界
- 本文依据 2026-08-24 的抓取，逐字核到正文的官方页面包括：阿里云百炼的计费文档（阶梯计费规则一节与各模型价格表）、DeepSeek 的模型与价格页及上下文硬盘缓存文档、Kimi 开放平台的模型推理价格说明页与 K3 定价页、Z.AI 的定价页、阿里云百炼的上下文缓存文档。
- 未核到的厂商：火山方舟（豆包）官方文档站为前端渲染，正文未逐字核到，未纳入本文对比；OpenAI 官方文档站本次网络不可达，本文不涉及其长上下文计价。
- 本文没有写任何具体单价、档位边界数值、时段起止时间和上下文窗口大小。档位边界和时段窗口都属于厂商可随时调整的参数，正文一律改写为机制描述，示例中的档位数字仅用于说明「全量重算」这一规则本身，不代表任何厂商的现行档位。
- 笔者没有上述厂商的付费账号，未做过长文本调用的成本实测，全文结论来自官方文档阅读。