很多人在准备接入 GLM5 2 时，第一件事是搜「官方 API 价格」，结果点进去看到一堆单价数字，却不知道自己一个月到底要花多少——因为输入输出是否分开算、缓存命中和未命中是不是一个价、有没有按量阶梯，这些口径没对齐，估出来的数只能算参考。这篇把查价、对齐口径、按用量折算成本三步串起来，最后给一张可以照着填的自查清单。
很多人准备接 GLM5 2 的时候，第一反应是搜「官方 API 价格」，点进去看到一串单价，还是不知道自己一个月要掏多少。原因不复杂：输入和输出分开算、缓存命中与未命中不是一个价、有没有按量阶梯，这些口径没对齐，估出来的数只能算参考。
这篇不替你算出一个固定数字，因为数字会变。要做的是把查价路径、计价口径、按自己用量折算成本这三步串起来，最后给一张能照着填的清单。看完你至少能回答一个问题：我这个用法，成本主要花在哪一项上。
官方价格去哪看，别在二手转述里对数字
网上一堆文章写「某模型多少钱一千 token」，这些数字大概率是写的时候抄的，过一阵就过期了。官方按量价以厂商页面为准，站内对应的入口是 GLM 那一页，先去那里看第一手口径。
- 找对页面打开站内 价格追踪（/price-watch），定位到 GLM 这条模型线，确认你看的是官方按量价而不是中转站的倍率价。
- 两处对照再去 厂商目录（/sites） 里核一遍同一个模型名，确认两处指的是同一条产品线，避免把不同档位混在一起算。
- 看更新时间价格会有调整，看到数字时先扫一眼页面上的更新标记，别拿一张旧截图做预算，尤其是要写进立项文档的时候。
一次调用到底按哪几项收钱
很多人默认「一次请求一个价」，实际不是。一次调用里可能同时产生输入 token、输出 token，如果命中缓存，价格又和未命中不一样。分不清这几项，估出来的成本会偏得很离谱。
- 输入 token
- 你发过去的提示词、历史对话、知识片段，按量计费，长系统提示词是主要来源。
- 输出 token
- 模型生成的内容，通常单价更高，所以「回复越啰嗦越贵」不是玩笑。
- 缓存命中
- 同一段前缀被反复发送时可能命中缓存，命中与未命中价格不同，长提示词场景差距明显。
- 附加能力
- 图像理解、工具调用、长上下文档位等，部分情况下有单独口径，接之前先确认自己用不用得到。
判断标准很简单：如果你的请求里有一段几百上千字、每次都原样发送的系统提示词，那缓存命中与否就是你成本的第一变量，先算这一项，再看别的。
按量、阶梯、批处理：三条省钱口子适不适用你
省钱的口子通常就三条，但每一条都有前提，不是所有人都能用。判断顺序建议是先看业务能不能等，再看量够不够，最后才考虑是不是换个通道。
| 方式 | 适合什么情况 | 什么情况下不适用 |
|---|---|---|
| 按量计费 | 调用量不稳定、还在验证阶段的项目 | 长期稳定大流量，可能有更划算的谈法 |
| 阶梯价 | 月度累计量能稳定跨过档位 | 小团队用量小，根本摸不到高阶档位，按阶梯价做预算反而失真 |
| 批量或异步通道 | 任务能等、不要求即时返回 | 交互式产品、客服机器人、需要秒回的场景 |
有个常见的误判：看到阶梯价的最低档就按那个价算预算，结果自己一个月根本用不到那个量。稳妥做法是按当前实际档位算，阶梯部分当潜在优化空间，不写进基线预算。
把单价换成一个月的账单：三步折算
单价本身没意义，有意义的是「我这个用法一个月大概多少」。下面三步不需要任何工具，纸笔或者一个表格就能做。
- 第一步，取一次典型请求，记下它的输入 token 量和输出 token 量，用平均值而不是最大值，极值会把预估撑大；
- 第二步，估算日调用量，乘以一个月的天数得到月调用量，再按官方口径把输入和输出分开相乘；
- 第三步，在结果上留出余量，用于重试、调试、多轮对话导致的上下文膨胀，这部分最容易被漏掉。
具体单价和档位到 价格追踪（/price-watch） 核对当时的数字，别用记忆里的旧值。第三步的余量比例按你的业务波动来定，接口重试多、对话轮次长的场景要留得更宽。
和同类国产模型比的时候，口径要先对齐
拿两家模型的单价直接比大小，是最容易得出错误结论的做法。问题出在展示口径：有的页面只展示输入价，有的把输入输出混在一起给一个数，有的是给一个区间。数字看起来能比，实际不可比。
| 对齐项 | 怎么对齐 | 不对齐会怎样 |
|---|---|---|
| 计价项 | 确认两边是否都区分输入和输出 | 只比一个数，可能把输出贵的那家看成便宜 |
| 任务形态 | 用同一份提示词、同样的输出长度要求分别测算 | 按各自的样例算，比出来的是两个不同任务 |
| 通道性质 | 分清是官方按量价还是中转站倍率价 | 把两种计价方式并列，结论没有意义 |
如果你的项目已经在走中转站，注意中转站的倍率和官方按量是两个体系，不要直接把两边数字放在一张表里对比。要对比，就统一换成「跑同一个任务的单次成本」再比。
三种典型用法的成本结构长什么样
同样是调用 API，不同业务的成本结构差别很大。知道自己属于哪一类，就知道该优化哪一头。
- 客服问答类
- 输入长、输出短，成本主要集中在提示词和检索回来的知识片段上，优化方向是压缩上下文和提升缓存命中。
- 内容生成类
- 输入短、输出长，成本几乎全在输出 token 上，控制生成长度和避免重复生成比什么都管用。
- 代码助手类
- 上下文反复携带，同一段代码可能在多轮里重复出现，缓存命中率直接决定成本高低。
判断自己属于哪一类，看两个数就够了：平均输入 token 和平均输出 token 谁更大。输入明显大，就往上下文优化；输出明显大，就往生成控制优化。
这套算法什么时候不适用
不是所有情况都值得按上面的方式精算。以下几种场景，算出来的结果和实际账单对不上，或者算的成本还不如你花的时间值钱。
- 有免费额度或赠送额度时，账单不等于用量乘单价，要先把抵扣顺序和使用期限弄清；
- 签了包量合同或企业协议时，实际结算价和公开按量价不同，公开页面的数字只能当参考；
- 调用量小到一个月只有几百次，时间成本高于省下的钱，估个大概够用就行，不必逐项拆；
- 模型能力或计价口径刚调整过的窗口期，旧数据和新口径混用会让估算失真。
一句话判断标准：如果你的月用量小到不值得做一张表，或者你的结算方式根本不是按量，那就别套这套算法，直接看合同或控制台的实际数字。
接入前照着走一遍的清单
下面是接入前可以直接照着勾的清单，每条都对应一个具体动作，不是概念。
- 确认档位先明确自己要用的是哪一档 GLM 能力，去 厂商目录（/sites） 确认名称，别把不同档位的价格混着算。
- 取真实 token 量拿一次真实请求的输入输出 token 量，而不是凭感觉估，这一步决定后面所有数字的准确度。
- 单独算缓存场景把长提示词、固定前缀的场景单独算一遍，看命中缓存能带来多大差别，再决定要不要为它调整提示词结构。
- 留余量并设定告警在预算上留出重试和调试的余量，同时在控制台设一个用量告警阈值，避免调试期用量跑飞。
- 定期复核价格和口径会变，把复核周期写进项目节奏里，到期去 价格追踪（/price-watch） 重新对一遍数字。
常见问题
官方按量价格会经常变吗？
模型厂商调价比较常见，尤其是新模型上线初期。稳妥做法是不背数字，每次做预算前到站内对应页面看当时的数字，并确认页面标注的更新时间。已经写进合同的量价和公开按量价通常也不是一回事。
输入和输出为什么要分开看？
因为两者单价不同，而且输出通常更贵。如果你的场景是长输入短输出（比如摘要、分类），成本结构和长输出场景完全不一样。算预算时把两项分别乘各自的量，再相加，才接近真实账单。
走中转站会不会比官方便宜？
不一定，而且两者口径不同：中转站按倍率折算，还可能有最低消费或限速。要判断是否划算，得先把自己的月用量算出来，再分别按官方按量和中转倍率折算，同口径比较才有意义。
只有小规模调用，还需要算这么细吗？
用量很小时，单价差异对总花费影响有限，重点是别因为调试死循环或重试把量跑飞。这种情况下把精力放在设用量上限和告警上，比反复比价更有效。
批量通道的折扣值得用吗？
取决于你的任务能不能等。离线跑数据清洗、批量打标这类可以接受延迟的任务，走批量通道通常更省；面向用户的实时对话、代码补全就不合适，省下的钱抵不上体验损失。
