很多人接 ChatGPT 接口时只看一个单价，上线一个月才发现账单翻了几倍——输入输出比例、缓存、长上下文、重试和流式连接都影响成本。这篇不讲协议怎么配，只讲钱：钱花在哪几项、下单前怎么估、跑起来之后怎么盯、什么情况下你根本不需要按量付费。所有具体数字都给你站内核对位置。
接 ChatGPT 接口的时候，很多人第一眼只盯一个单价，觉得便宜就上了。上线一个月看账单才发现翻了好几倍，回头查也查不出问题在哪。其实钱是分散花掉的：输入输出比例、上下文有没有裁剪、失败重试、流式连接断线重发，每一项都在悄悄加钱。
这篇不讲怎么配协议、怎么调 SDK，只讲账。钱花在哪几项、动手前怎么估、跑起来之后怎么盯、什么场景下你压根不用按量付费，一条条说清楚。所有具体数字不写死，给你站内核对位置，因为价目表和模型档位会变，写死的数字第二天就可能过期。
先搞清钱是按什么口径收的
按量计费的核心口径是 token，不是请求次数。你发一次请求，模型读进去的内容算输入 token，它吐出来的内容算输出 token，部分模型还会产生推理类 token 也计入账单。还有缓存命中这一档，命中部分通常单价更低，但它是否生效取决于你的请求前缀是否稳定。这几个字段的当下定义和计费方式，到 /official-api/providers/openai 核对官方价目表里的字段说明。
- 输入 token
- 你发过去的所有内容：系统提示、历史对话、用户问题、塞进去的文档，全部计入
- 输出 token
- 模型生成的内容，通常单价高于输入，长回答比长提问更烧钱
- 缓存命中
- 前缀重复的部分可能走缓存价，前提是每次请求的开头一段保持高度一致
- 推理类 token
- 部分模型会额外产生思考过程的用量，预算时别漏掉这一项
- 分清输入、输出、缓存三种口径的计价差异，别拿一个混合单价去乘总 token 数
- 一次请求的真实花费等于输入加输出，长系统提示和历史对话会被重复计入输入
- 订阅制和 API 按量是两套账，订阅档位对照见 /plans/chatgpt-plus，别混着算
- 如果你只是自己聊天用、没有程序化调用，订阅往往比按量划算，本文的估算法是给写代码的人的
一笔调用费到底由哪几块拼出来
把一笔调用的费用拆开看，其实是几块拼起来的。固定块是系统提示和工具定义，每次请求都要重发一遍，调用越频繁这块占比越高；变动块是用户输入加模型输出，输出单价通常更高；隐藏块是重试和重放，一次失败等于付两次钱，超时后手动重发的请求同理。批量任务里失败重投的部分也归隐藏块。
| 成本块 | 是什么 | 什么情况下会变大 |
|---|---|---|
| 固定块 | 系统提示、工具定义、固定前缀 | 调用频率高、系统提示写得长 |
| 变动块 | 用户输入加模型输出 | 长回答、长文档、多轮对话 |
| 隐藏块 | 重试、超时重放、失败重投 | 网络不稳、超时设太短、无退避重试 |
| 缓存块 | 前缀命中缓存的部分 | 前缀频繁变动导致缓存失效 |
把这几块写成一张对照表，再逐项套用站内当时的单价，你才知道哪块最该优化。多数人的账单问题不是出在单价上，而是出在固定块重复太大、隐藏块浪费太多。先定位再动手，别一上来就换模型。
动手前怎么估一个月要用多少
估算需要两个输入参数：日均请求数、每次请求的平均 token 数，而且输入和输出要分开估，因为单价不一样。很多人凭感觉猜平均长度，结果偏差巨大。正确做法是拿真实业务文本跑一轮接口，看返回里的实际用量字段，再按比例外推。
- 收集样例挑三到五条真实业务文本，覆盖短、中、长三种长度，别只用理想情况下的短文本
- 跑一轮看真实用量过一遍接口，记录每次返回的输入和输出 token 数，算出平均值
- 外推月用量用日均请求数乘以平均长度，输入输出分开算，得到月度 token 总量
- 套计算器得区间把结果乘进 /tools/model-cost-calculator 和 /tools/token-price-calculator，得到按量口径的区间
什么情况下这套估算不适用？流量波动大的产品，比如有活动峰值、有早晚高峰的，要按峰值估而不是按平均值估，否则预估只覆盖了平淡日子，一到高峰账单就爆。
哪些工程选择会悄悄把账做大
有些成本不是业务量涨上来的，是你自己的工程选择带上来的。最常见的是上下文不裁剪：历史对话全量重发、整篇文档塞进去，每一轮都在为重复内容付费。这类开销不会在单次请求里特别扎眼，但乘以请求数就很可观。
- 上下文长度失控：不裁剪历史、整篇塞文档，每轮重复付费，先做摘要或截断
- 模型档位选太高：同一任务换更高档模型，单价可能成倍变化，换之前到 /models 看规格、到 /price-watch 看变动记录
- 重试没有退避：暴力重试、超时设太短导致重复提交，纯浪费，加退避和幂等判断
- 流式连接被打断后重发整段请求，成本等于翻倍，排查思路可参考站内流式相关的现有文章
换档位之前先想清楚任务复杂度是不是真的需要。很多场景用低一档的模型效果差异用户感知不到，但账明显轻。判断依据不能只靠感觉，到 /models 对比规格，再到 /price-watch 看历史调价，两次核对再决定。
做预算的执行清单
预算不是算一个数就完事，它是一份能回头对账的清单。每条业务链路单独估、单独记，别把所有调用揉成一个总账，否则超支了你也定位不到是哪条链路。
- 列链路把每条业务链路列出来，标注使用模型、日调用量、平均输入输出长度
- 分链路算钱每条链路单独乘单价得到保守值，再加一档上浮空间应对波动
- 设额度和告警设月度额度上限和告警阈值，超了先降档而不是先加钱
- 两周后对账上线两周拿真实用量回头对账，偏差大的链路重新估，真实用量可到 /usage 横向参考
上浮空间留多少？没有标准答案，取决于你业务的波动幅度和容错能力。保守一点宁可多留，因为超支的代价通常比多留预算的代价大。
跑起来之后怎么盯、怎么降
上线之后要盯四个指标：日 token 总量、日均请求数、失败重试占比、单次请求平均成本。前两个看趋势，后两个看质量。只盯总量的话，你只知道账单涨了，不知道是业务涨了还是在漏钱。
| 指标 | 看什么 | 异常时先查什么 |
|---|---|---|
| 日 token 总量 | 整体趋势和突发跳变 | 是否有链路上下文膨胀或循环调用 |
| 日均请求数 | 业务量是否自然增长 | 是否被重试或爬虫放大 |
| 失败重试占比 | 调用质量 | 超时设置、退避策略、上游稳定性 |
| 单次平均成本 | 单位效率 | 模型档位、输入输出比例、缓存是否生效 |
降本有优先级：先砍重复上下文和无效重试，再考虑换档位或换供应商，最后才动业务逻辑。顺序反了容易白干，业务逻辑改动风险大、收益还不一定高。把每次请求的用量和链路标识写进日志，这是所有优化的前提。
官方直连和中转渠道，账怎么算才公平
比价要同口径：同一模型、同样的输入输出比例、算不算重试和失败请求。很多对比帖拿官方标价去比中转的实际结算价，口径都不一样，结论自然没参考价值。公平的做法是把重试、失败、运维成本一起算进去。
- 比价先统一口径：模型、输入输出比例、是否含重试和失败请求
- 中转渠道的问题多出在稳定性和售后，不一定是单价，判断依据到 /sites 和 /rankings 看检测与口碑维度
- 自建或走代理会多一层运维和带宽成本，别只比 token 单价
- 小团队调用量不大时，省下的钱常常不如省下的排障时间值钱，结论要按场景分
什么情况下中转渠道值得考虑？你的业务容错能力较强、能接受偶发失败并有兜底逻辑时，多一条路由等于多一层保险。反过来，如果你的业务对稳定性要求极高、失败代价很大，那省下的那点差价可能还不够一次故障的损失，这时候优先看稳定性和售后响应。
下一步：把当前价目和检测记录核一遍模型档位和价目会变，动手前到 /price-watch 看变动记录、到 /official-api/providers/openai 核对当前字段，再到 /sites 看渠道检测结果，三处对完再定方案，比凭记忆报价靠谱。→常见问题
ChatGPT 接口是按次收费还是按字数收费？
按 token 收费，输入和输出分开计价，输出通常更贵。请求次数本身一般不单独收费，但次数越多、每次带的上下文越长，总 token 就越多。具体单价请到站内官方 API 价格页核对当时的数字，别用记忆里的老价格做预算。
我只想大概估个数，最少要准备哪几个信息？
三个就够：每天大概多少次调用、每次请求的输入大概多长、输出大概多长。拿一段真实业务文本跑一次接口，读返回里的用量字段最准。然后把这三个数丢进站内的模型成本计算器，得到一个区间，再留点上浮空间当预算。
为什么我实际账单比预估高出一大截？
最常见的原因是上下文没裁剪（历史对话一轮轮累积）、失败后无退避地重试、以及超时重发导致同一请求付了两次钱。先去日志里看单次请求的平均 token 和重试比例，这两项通常就是缺口所在。
订阅 ChatGPT 和调 API，哪个更适合我的项目？
有程序化调用、要接进自己产品里的，只能走 API 按量。纯人工聊天、写文案、查资料的，订阅通常更省事也更便宜。两者是不同计费体系，对照口径站内都有页面，先明确自己是哪一类再比价。
换到更便宜的渠道或更低档模型，一定能省钱吗？
不一定。低档模型可能要多轮追问才达到同样效果，总 token 反而更高；便宜渠道如果稳定性差、失败重试多，实际花费也会上去。判断标准是看同一个任务在两条路径下的完成总成本和返工率，而不是看单 token 单价。
