gpt3.5 token 价格

很多人算 GPT-3.5 的花费时，只记住了一个「每百万 token 多少钱」，结果一到对账就对不上——输出比输入贵、缓存和普通输入又不同价、中转站还叠了倍率。这篇不背数字，只教你怎么在站内页面把当期单价翻出来，把输入和输出分开算，并给出按单价估算月花费的步骤和排查顺序。

算 GPT-3.5 的花费，最容易出问题的地方不是记不住单价，而是记错单价的口径。很多人脑子里只存了一个「每百万 token 多少」的印象，真去对账发现差了将近一倍，回头才发现输出那一档比输入贵不少，自己一直拿输入价乘了全部 token。还有个更隐蔽的坑：单价是每千还是每百万，抄错一次结果就差三个数量级。

这篇不打算给你背任何数字，因为价格页面本身会变，写死在文章里反而害你。下面只讲一件事：怎么到站内把当期单价翻出来，怎么把输入和输出拆开算，以及算出来和账单对不上时按什么顺序排查。你要是正在做预算或者准备给团队报数，照着走一遍基本能把大致量级框住。

「token 价格」到底指的是哪几个数字

问「GPT-3.5 的 token 价格是多少」，这个问题本身就不完整。一个模型的计价条目往往不是单一数字，而是一组并列的档位：普通输入、输出，部分平台还会额外拆出缓存读和缓存写，各自的价格并不相同。你只盯着一个数字，就等于默认其他几档不存在，后面必然对不上。

普通输入

你发给模型的提示词、上下文、历史对话所占的 token 档位。

输出

模型生成返回内容所占的 token 档位，通常高于输入档。

缓存读 / 缓存写

部分平台对重复前缀提供缓存机制，命中和写入走另外的价，不按普通输入算。

计价单位

同一页面可能按每千 token 或每百万 token 标价，两者相差三个数量级。

• 先确认页面标的是每千还是每百万，这一步做错后面全错，别嫌麻烦。
• 把输入档和输出档分开记，不要看成一个平均价。
• 留意是否有缓存相关的独立档位，长对话场景这块占比不低。
• GPT-3.5 属于老一代对话模型，不少平台还在挂，但页面数字会调整，别拿记忆或旧截图当依据。
• 确认你查的是官方口径还是中转站报价，两者的数字结构和倍率逻辑不同。

输入和输出为什么不是一个价

输出的生成是逐 token 推进的，占用的推理时间和算力比读取一段现成的输入要高，所以同一个模型的输出档通常比输入档贵。这不是某一家平台的特殊定价，而是大多数平台共有的结构。你把这个前提记住，就不会再问「为什么我按单价乘总 token 算出来的数偏低」。

单次调用花费 = 输入 token 数 × 输入单价 + 输出 token 数 × 输出单价

这个式子看起来简单，但实操里最容易踩的坑就是把两个乘项合并成一个平均价。一旦你用输入单价乘上全部 token，输出那一半的成本就被系统性低估了。输出占比越高，偏差越大。摘要、改写、代码生成这类任务，输出占的比例往往比你想的要高。

去哪里查当期单价，别背数字

站内把官方价格和模型资料归到了一起，你要做的第一件事是分清自己需要的是官方口径还是中转站口径。官方口径用来做基准估算，中转站口径用来做实际成本预判，两者别混着比。

1. 查官方分列单价到 /official-api 找到 GPT-3.5 相关条目，重点看输入和输出是不是分列展示，把两个数字各记一份，不要只记其中一档。
2. 按厂商细分页再核对一次到 /models 里对应厂商的细分页面核对同一条目，确认口径一致，避免某一页只是概览、数字不够准。
3. 让工具替你算到 /tools/token-price-calculator 把单价和你的 token 量代进去，工具会把输入输出分开算，省掉手抄出错的可能。
4. 对价格变动记录到 /price-watch 看这段时间有没有调价记录，如果你的估算基于旧数据，这里能帮你发现。
5. 验证结论把你算出来的单次成本跟最近一次真实账单做个粗略比对，量级对得上再用它做预算。

这里补一句：别用搜索引擎里抓到的旧截图或者别人博客里的数字，那些东西没有更新机制。站内页面至少有人维护，对不上的时候还能去 /price-watch 找原因。

走中转站时，单价为什么又变了一层

如果你不是直连官方，而是走中转站，那么你看到的报价通常是在官方单价基础上乘了一个倍率。麻烦的地方在于，输入和输出的倍率未必相同，有些中转站对输入加得少、对输出加得多，有些干脆给一个打包价。你如果只问到一个「倍率是多少」，很可能只覆盖了其中一档。

• 问价时把输入和输出分开问，要求对方分别给出对应的倍率或单价。
• 确认计价单位是不是和官方一致，有的中转站按条、按次或者按额度计价，口径不同不能直接比。
• 看清楚倍率是乘在官方价上，还是已经是一个独立的打包价，这两种结构的比较方式不一样。
• 不适用的情况：如果你的月调用量很小，倍率差异带来的绝对差额可能还不如一次充值门槛高，这时候不必为一个百分点纠结半天。
• 比价时别只看单价表，把充值门槛、最低消费、有效期这些一起看，否则容易算出好看但落不了地的结论。

按单价估月花费的四步流程

有了当期单价，接下来就是把它换算成一个月大概花多少。这个动作看着简单，但顺序错了返工很烦，下面四步按先后顺序做，不要跳。

1. 拆出输入和输出的量从你的调用日志里分别统计输入 token 总数和输出 token 总数。只统计总 token 的话，后面还是没法分档计算，这一步必须拆开。
2. 分别套当期单价输入总量乘输入单价，输出总量乘输出单价，两项相加得到基础成本。单价到 /official-api 现查，不要用本文或任何文章里的数字。
3. 把缓存和调用次数补上如果你的请求有重复前缀，命中缓存的那部分走的是另一档价，要单独算；再把调用次数乘进去，得到周期内的量级。
4. 留出重试余量失败重试、超时重发、调试期间的试跑都会计入实际消耗，纸面估算一般会略低于真实账单，按经验留一部分余量再对外报数。

算出来的数和账单对不上，按这个顺序排查

估算和账单不一致是常态，不一定是哪里出了大错，很可能只是少考虑了一档。下面这个顺序按出现频率从高到低排，从上往下查，基本能定位到问题。

• 第一查：是不是只用了输入单价乘全部 token，漏掉了输出档，这是最常见的一类偏差。
• 第二查：计价单位有没有搞混，每千和每百万混用会让结果差上千倍，先去页面确认单位。
• 第三查：是否有缓存、批处理、阶梯折扣等另一套计价规则参与，这些不走标准单价。
• 第四查：中转站的倍率、充值折算、有效期有没有叠进去，这部分站内另有文章专门讲，这里不重复。
• 第五查：日志统计口径和账单口径是否一致，有的账单按请求计、有的按 token 计，先确认再比数。

排查时建议一次只改一个变量，改完对一次账单。同时动几个地方，就算数字对上了你也不知道是哪个原因起的效。

什么时候「单价便宜」不等于「总花费低」

单价表只能告诉你每一档 token 多少钱，它管不了你要用多少 token。有些场景里单价低的模型总花费反而更高，原因通常出在两点：输出啰嗦、以及一次做不对要反复重试。

判断标准其实只有一个：拿同一批真实任务，在候选方案上各跑一遍，比总花费，不要比单价表格。单价表是起点不是结论。如果任务量太小、跑一轮的成本还不如你花时间比较的功夫，那就直接选一个能跑通的，不必为了单价纠结。