你大概遇到过这种场面：老板问「接 GPT-4 跑一小时要花多少钱」，你手上有单价表，却不知道怎么把 token 单价折成小时。这篇不背数字，只讲换算链路——先量出你每小时打多少请求、每次进出多少 token，再乘当期单价。中间哪些量容易取错、哪些情况下「每小时」这个口径根本不成立，都会一并说清。
你大概遇到过这种场面：老板在群里问一句「接 GPT-4 跑一小时要花多少钱」，你手上明明有单价表，却不知道怎么把 token 单价折成小时。因为计价单位是 token，不是时间，小时价从来没有人直接标过，只能自己折算。这篇不背数字，只讲换算链路——先把「每小时打多少请求、每次进出多少 token」量出来，再乘当期单价，答案自然就出来了。
中间哪些量最容易取错、哪些情况下「每小时」这个口径根本不成立，会一并说清。所有价格类数字本文一律不写死，需要取值时到站内官方 API 页面核对当时的价格，因为价格会变，记死的数字迟早坑你。
为什么没人直接标「一小时多少钱」
因为按量计费的计价单位从头到尾都是 token，供应商只会告诉你每百万 token 收多少，不会告诉你每小时收多少。小时价是一个你必须自己合成的指标，供应商没义务也没法替你合成，因为同样跑一小时，聊天问答和批量长文生成的消耗能差出数量级。
所以想回答「一小时多少钱」，先得接受一个结论：小时成本 ＝ 每小时请求数 × 每次 token 量 × 当期单价。这三个量缺一不可，少任何一个，算出来的数都是拍脑袋。下面逐节把这三个量的取法讲清楚。
折算需要的三个量，各自从哪来
- 每小时请求数
- 从你自己的调用日志或压测结果里数出来，别凭感觉估；没有日志就先加一层调用记录
- 每次 token 量
- 输入和输出分开统计，接口返回里通常有用量字段，直接读比切词估算准
- 当期单价
- 到 /official-api 和 /official-api/providers/openai 核对，注意价格会调整，别沿用旧记忆
三个量的来源性质完全不同：请求数是你自己的业务特征，token 量一半由业务决定一半由提示词写法决定，单价才是外部变量。前两个量必须自己测，第三个量必须现查。很多人算错不是因为公式难，而是把「我以为的请求量」当成了实测值。
- 请求数：抓一段真实流量，按分钟粒度统计后折算到小时，避免用峰值当常态
- token 量：至少区分三种请求形态——短问答、带长系统提示的对话、长文生成，各测一组
- 单价：输入和输出是两套价格，分别记录，不要合成一个平均单价
- 口径记录：把每个量的取样时间和来源写下来，下次复算时有据可查
把公式摆出来：一小时成本怎么算
小时成本 ≈（每小时请求数 × 单次输入 token × 输入单价）＋（每小时请求数 × 单次输出 token × 输出单价）。注意输入和输出必须分开乘再相加，因为两者单价不同，混着用一个平均值会系统性低估，尤其在输出远多于输入的场景里误差很明显。
小时成本 = 请求数_每小时 × (输入token_每次 × 输入单价 + 输出token_每次 × 输出单价)
其中单价取自 /official-api 当期页面，输入、输出分别取，不要合并如果单次 token 量拿不准，先用 /tools/token-price-calculator 和 /tools/model-cost-calculator 做几组对比，把「短问答、长提示词、长输出」三种典型请求各算一遍，得到一个小范围而不是一个点。范围比点值有用得多，因为真实流量本来就是混合的。
单次请求的 token 到底怎么数
最靠谱的做法是直接读接口返回里的用量字段，它统计的是实际计费口径，比你自己按字数或切词估算准得多。自己做分词估算的问题在于，不同模型的切分规则不一样，中文和代码的切分差异尤其大，估出来的数经常偏出一截。
另一个高频漏项是长提示词。系统提示、角色设定、历史对话轮次、检索回来的参考资料，这些都会计入输入 token。很多人只统计了用户这一句话，结果输入侧少算一大半，最后和账单对不上又回头找原因。
| 容易漏的输入项 | 为什么会计入 | 怎么处理 |
|---|---|---|
| 系统提示与角色设定 | 每次请求都会随消息一起发送 | 按实际发送内容统计，不要只算用户那句话 |
| 历史对话轮次 | 多轮对话会把前文重复带上 | 按轮次记录，或改用会话摘要压缩 |
| 检索/工具返回的上下文 | 作为输入拼进了提示词 | 单独标记这类请求，成本通常高于普通问答 |
| 重试与限速重发 | 失败请求同样可能产生消耗 | 日志里按状态码分开统计，别只数成功的那部分 |
不适用的情况也要说清：带缓存命中或批处理折扣的账，实际单价和标价不是一回事，这时候回到账单口径看，别拿公开单价硬套。缓存命中率高的服务，按标价算会明显高估。
小时口径什么时候有用，什么时候会坑你
小时口径在几种场景下很顺手：压测时看瞬时消耗、跑单次批量任务时估总账、给非技术同事做粗略体感换算。它的价值是把抽象的 token 单价翻译成对方能听懂的时间单位，仅此而已。
但它也有明确的不适用场景。流量随业务时段波动明显的服务，小时均值会被高峰和低谷互相抵消，看起来平稳其实峰值很凶；存在重试、限速重发的服务，小时值会忽高忽低。这两种情况下，小时值只能当拆分粒度，跨小时看总量时用日或月做单位更稳。
- 适合：压测、单次批量任务估算、跨部门沟通时的体感换算
- 不适合：流量波峰波谷差距大的在线服务、重试率高的调用链
- 折中做法：先按小时测，再乘以业务时段的权重，加权得到日成本
- 判断标准：如果同一小时测两次结果相差很大，说明这个口径本身就不稳定
一套可复用的四步测算流程
- 第一步：抓一小时的调用日志统计请求条数、输入 token 总量、输出 token 总量。没有日志就先加调用记录，不要用估算值代替。
- 第二步：按当期单价分侧计算输入侧和输出侧分别乘当期单价再相加，得到这一小时的实测值。单价来源写清楚是哪天对的。
- 第三步：换典型时段再跑一遍至少覆盖高峰和低谷各一次，看波动范围。两次结果差得远，就要分析差异来源，而不是取平均了事。
- 第四步：和账单扣费对账把测算结果和当期充值扣费记录对一次量级，差得远就回头查口径，通常是漏统计或单价用错档位。
整个流程的关键是「先测后算」。跳过测量直接套公式，等于把三个变量全用猜的，结果自然不可信。跑完一轮后把这套记录存下来，下次价格或业务量变化时只需替换单价和请求数，几分钟就能更新。
估算时最容易踩的四个坑
- 把订阅套餐的月费直接除以小时数，混淆了订阅和按量两种计费模式，两者根本不是一回事
- 只算成功请求，忽略失败重试和限速重发产生的消耗，真实账单往往高于测算值
- 用标价算账，却没看账单里实际适用的档位与折扣，缓存和批量的折扣差别尤其大
- 拿着几个月前记的单价继续算，价格已经调整过，到站内官方页面重新核对当时的数字
这四个坑的共同点是：都不是公式错，而是取值错。公式本身很简单，难的是每个输入量的口径一致——你测的是哪段流量、单价是哪天对的、算的是标价还是折后价，这些必须前后统一，否则对账时一定对不上。
上线前的小时成本自查清单
- 单次输入和输出的 token 量有实测值，不是猜的，且来源能说清
- 单价来源是站内官方页面，能说清是什么时候核对的，不是凭记忆
- 至少覆盖高峰和低谷两个时段各测一次，给出的是区间而不是单点
- 算出的小时值和当期账单扣费能对上量级，偏差有合理解释
- 日志里失败和重试请求单独统计过，没有混进成功请求里一起算
这份清单适合在报价、做预算或给老板回话之前过一遍。如果其中任何一条答不上来，说明这个小时数字还不该对外说，先补数据再报。需要对照各家单价和当前档位时，到 /official-api 与 /price-watch 看当时的数字，那些页面会持续更新。
下一步把公式记住没用，手里还得有能直接查的当期单价和好用的计算工具。先到价格追踪页确认你正在用的那档价格是什么时候的，再用站内计算器把你的三种典型请求各算一遍，得到自己的成本区间。→常见问题
GPT-4 一小时到底多少钱？
没有固定答案，它取决于你这一小时发了多少请求、每次输入输出多少 token。正确做法是先抓一小时的调用日志统计总量，再乘当期单价。单价到站内官方 API 价格页核对，别用记忆里的数字。
用订阅版是不是就能按小时折算了？
不建议。订阅是按周期收费、有额度上限，和按 token 计费的 API 是两套口径，硬除小时数会误导决策。要算小时成本，就用 API 调用的日志来算，两者混在一起比会失真。
输入和输出的钱要分开算吗？
要。输入和输出的单价通常不同，输出往往更贵，直接用一个平均单价乘总 token 会低估成本。分开乘再相加，结果才贴近实际账单。
估算值和实际账单对不上怎么办？
先查三个地方：单次 token 量是不是只算了成功请求、有没有重试的重复消耗、实际适用的单价是否和标价一致。逐项排除后，再看账单的计费周期划分口径。
压测时用哪个数字当基准？
用实测的每小时 token 总量当基准，而不是用请求条数。同一批请求条数一样，内容长度差一倍，成本就差一倍。跑之前把日志字段准备好，事后才能倒推。
