GLM 按输入长度分段计价是什么意思：怎么把单次输入量算准

数据截至 2026-08，价格与限额以各官网为准。本文只讲计费与接入机制，不列具体价格数字。

先说结论，也把边界说清楚：本文抓取的智谱官方文档页面里，跟「分段计价」直接相关的说法只有一条——用户权益 FAQ 提到，若推理模型配置了阶梯定价，则以阶梯定价的逻辑生效，且用户权益带来的价格优惠比例对这类模型不实际生效。至于阶梯按什么变量分、一共几档、每档边界划在哪、每档单价多少，官方文档里没有找到相关说明，只能以产品定价页为准。所以真正值得花时间的不是猜档位，而是把「这一次请求实际发出去多少 token」量准——智谱开放平台提供了官方的文本分词器接口 /paas/v4/tokenizer，它接收和对话补全同样结构的 messages，返回 usage 里的 prompt_tokens、image_tokens、video_tokens 和 total_tokens，官方文档写明它的适用场景就包括文本长度评估、模型输入预估、对话上下文截断、费用计算。下面讲的全是这条线：什么东西会被算进输入、输入量为什么会不知不觉变大、怎么在调用之前就把它算出来。

官方文档里核得到什么，核不到什么

很多人第一次看到分段计价，会本能地往「阶梯电价」上想——用得越多单价越低。先别急着把这套直觉套上去，因为官方文档并没有说这个阶梯的自变量是什么。

能核到的是计费的底层单位。智谱的官方 FAQ 说得很直白：以 token 为单位，按模型输入和输出的总 token 数计费；向量大模型 embedding-2 是个例外，仅按输入 token 量计费；图像大模型则按模型产出的图片数量计费。这是「拿什么去乘单价」的那一层，清清楚楚。

核不到的是「单价怎么被选出来」的那一层。前面提到的用户权益 FAQ，是这批官方文档里唯一承认「阶梯定价这回事存在」的地方，但它只交代了一个优先级关系——阶梯定价的逻辑优先生效，用户权益的价格优惠比例对配置了阶梯定价的模型不实际生效——对分档规则本身只字未提。既没说自变量是单次请求的输入量，也没说是账户的累计消费。

所以本文不会告诉你「输入超过多少就跳到下一档」，那个说法在官方文档里不存在，编一个出来对你没有任何好处。能做的是把不确定性圈小：单价那一层去定价页查，输入量这一层自己量准。后者完全在你手里，而且不管计价口径怎么变，它都是要乘进去的那个量。

先把单次请求的输入 token 数量准

不管档位怎么分，输入 token 数都是绕不开的那个自变量，所以第一件事是别再用「大概几千字」来估。中文的字符数和 token 数不是一个东西，官方在 max_tokens 的参数说明里确实给过一个英文单词与中文字符的粗略换算口径（具体比例以官方文档当前版本为准），但那句话本身用的措辞就是「通常约等于」——它是个量级参考，不是可以拿来对账的公式。

真正能对账的是分词器接口。它的请求体和对话补全高度一致：必填 model 和 messages，model 的取值是个枚举，官方文档当前列出的可选项包括 glm-5.2、glm-5.1、glm-5-turbo、glm-5、glm-4.7、glm-4.6、glm-4.6v、glm-4.5、glm-4.5-air（以官方文档当前版本为准）。messages 支持 system、user、assistant 三种角色，官方对它的描述是「对话消息列表，包含当前对话的完整上下文信息」，并且明确要求至少要有一条消息、不能只包含系统或助手消息。这个约束值得单独记一下：想单独量一段系统提示词占多少 token 时，光传一条 system 消息是不合规的，得配一条内容很短的 user 消息一起发，再把那条 user 消息的量减掉。

视觉模型的 content 还可以传多模态条目，官方列出的条目类型是 text、image_url、video_url、file_url 四种（以官方文档当前版本为准），其中 file_url 只有部分视觉模型支持，而且不能和 image_url、video_url 同时传。请求体里另外还可以带 tools 和 request_id——request_id 由客户端传递，官方给了长度上下限的约束并建议用 UUID 格式，不传则由平台自动生成。做批量量算的时候把它填上，回头才对得上是哪一条请求量出来的。

响应里的 usage 对象是关键：prompt_tokens 是本次输入的 prompt token 数，image_tokens 和 video_tokens 分别是图片和视频输入换算出来的 token 数，total_tokens 是本次输入的总量。注意这里的 total 指的是输入总量，不是「输入加输出」——分词器只做切分和计数，它不会去生成内容，自然也算不出输出会有多长。这个字段名和对话补全响应里的 total_tokens 同名但含义不同，拿它去对账单很容易算错。

实操上的做法是：把线上真实流量里的请求体采样一批，原样丢给分词器接口跑一遍，得到 prompt_tokens 的分布，再拿这个分布去对照定价页上对应模型的计价口径，就知道自己的钱主要花在哪一类请求上了。这比事后看账单反推要早一步，也更容易定位到是哪一类请求把成本抬上去的。

哪些东西会被悄悄算进输入

输入量变大，往往不是因为用户的问题变长了，而是因为请求体里被塞进了用户看不见的东西。有几处是官方文档里有明确说法的：

对话历史。 这是最大的一块。官方对 messages 的描述是「包含当前对话的完整上下文信息」，也就是说每一轮都要把此前的消息一起发过去；上下文缓存那页的说明也是同一个前提——「在复杂的对话中，历史消息往往包含大量重复信息」。所以一段聊了二十轮的会话，第二十一轮的输入量是前二十轮内容的累加。很多项目的成本失控就发生在这里：调用次数一直没涨，单次输入量在悄悄往上爬。

工具定义。 tools 参数里的函数名、描述、JSON Schema 参数定义，全都是要序列化进输入的文本。官方对函数对象的要求是 name、description、parameters 三项全部必填——描述省不掉，意味着每挂一个工具就必然带一段文字进来；函数名还有字符集和长度上限的约束，参数则必须用 JSON Schema 对象来定义。官方文档也给出了单次请求可传函数数量的上限（具体值以官方文档为准），但真正影响成本的不是函数个数，而是每个函数 description 和 parameters 写得有多长。分词器接口本身就接受 tools 参数，这一点很有用——你可以把工具定义单独喂进去量一次，看看这套工具在每一次调用里固定要占掉多少输入预算。

搜索结果。 官方 FAQ 写得很清楚：如果开启了搜索服务，搜索结果作为输入也会被计费。这是很多人漏算的一块——搜索回来的网页正文体量往往比用户问题大一个数量级，开了联网之后单次请求的输入量会明显抬上去，而且这部分内容你事先看不到，也没法控制它有多长。

图片和视频。 分词器响应里单列 image_tokens 和 video_tokens 两个字段，说明多模态输入在计费口径上是要换算成 token 的。官方 FAQ 也给出了单张图片大致消耗的 token 量级（具体数值以官方文档为准）。做图文混排的应用，图片那部分基本是固定开销，很难通过改提示词压下来。

至于输出 token 和阶梯定价之间是什么关系、输出侧是否也参与分档，本文抓取的官方文档页面里没有找到相关说明，需要以定价页上的口径为准。

缓存命中的 token 单独走一套计费

上下文缓存和阶梯定价是两件事，很容易搞混。缓存这部分官方文档写得比阶梯定价详细得多，可以放心引用。

官方文档对缓存的定义是隐式缓存：系统对输入的消息内容做计算，识别出与之前请求相同或高度相似的内容，自动复用之前的计算结果，不需要手动配置。计费上它采用「差异化计费策略」——新内容 token 按标准价格计费，缓存命中的 token 按更低的价格计费，输出 token 按标准价格计费。具体的优惠比例以官方定价页为准，本文不列。

有两条边界值得单独记住。一是官方明确标注：缓存的这套计费仅适用于标准 API 计费，不包括资源包和 GLM Coding Plan 套餐。二是命中情况是可观测的，响应里的 usage.prompt_tokens_details.cached_tokens 字段会给出本次命中的 token 数，这个字段是你判断缓存有没有真正生效的唯一凭据，不要靠感觉。

那么，命中缓存的 token 在阶梯定价的口径里算不算「输入」的一部分？官方文档里没有找到相关说明。能确定的只有一条：缓存改变的是这部分 token 的单价，不改变你实际发出去的请求体积——想让请求变小，还是得真的把 messages 拼短。关于怎么让缓存稳定命中，可以看GLM 上下文缓存怎么才能命中，跨厂商的通用规律则在API 缓存计费机制里。

按次计费的那几类，别硬往 token 口径里套

不是所有模型都走 token 计费。官方 FAQ 里有一条专门解释「图像模型怎么不返回 tokens 消耗」：图像模型、视频模型、搜索模型按次收费，不消耗 tokens。

这条对排查很有用。如果你在账单里看到某个模型的调用量不小、但 token 统计是空的，那不是统计漏了，是这类模型本来就不按 token 走，自然也谈不上输入长度这回事。把它们和文本模型混在一张表里做成本分摊，会得出完全错误的结论。

同理，embedding-2 只按输入 token 计费，它没有输出侧的费用，做向量化的批量任务时成本模型要单独建。

权益等级和资源包，会让账单更难读

官方的用户权益 FAQ 里还有几条和成本核算直接相关，值得一并记住，因为它们决定了「你以为的价格」和「实际结算的价格」之间会差在哪。

积分只在特定条件下产生：消耗资源包里的 token 不会增加积分，只有消耗现金余额、或者通过三方支付购买产品时才会产生积分。这意味着一个长期靠资源包跑量的团队，权益等级可能一直上不去，因为它的消耗根本不进积分口径。

Batch API 是个需要单独拎出来的情况：如果 Batch 调用消耗的是现金余额（不含赠金），是会累积积分的，但官方明确说明，用户权益升级后的价格优惠对 Batch API 不生效。

再叠加上前面那条——用户权益的价格优惠比例对配置了阶梯定价的模型也不实际生效——就出现了一个挺容易踩的坑：你按权益等级预期的那部分价格优惠，在这两类调用上都可能不兑现。做预算的时候，别把权益等级当成一个对所有调用一视同仁的降价系数。

自己的积分和权益等级可以在用户中心的用户权益页面查。这套逻辑官方标注了生效的起始时间点，具体规则以官方页面为准。

估自己月成本的顺序

把上面几件事串起来，估算的顺序应该是这样：

先分类。把线上请求按形态分成几类——短问答、带历史的多轮会话、长文档分析、带工具的 Agent 调用、开了联网搜索的调用。不同形态的输入分布差得非常远，混在一起平均没有任何意义。

再量。每一类各采样一批真实请求体，用分词器接口跑出 prompt_tokens，看的是分布不是平均值。特别要看尾部：多轮会话那一类的最长会话有多长，这条尾巴往往就是成本的大头，也是平均值最会骗人的地方。

然后对表。拿每一类的输入分布去比对定价页上对应模型的计价口径，算出每一类请求的单次成本区间。这一步的产出应该是一张按请求形态拆开的表，而不是一个笼统的平均单价。

最后乘量。用各类请求的日调用次数去乘，加上输出侧的估算量，得到月度区间。给的应该是区间不是点值，因为多轮会话的历史长度、搜索结果的体量、模型思考的长短都有波动。

上线之后就不用再估了，直接看真实数据：财务总览页面能看今日消费和最近数月的消费统计，费用账单页面能看详细的使用记录，导出记录页面可以下载汇总账单。更系统的成本监控做法在API 成本监控里有整理。

账单和你的预期对不上时

先排除一个非成本因素：扣费顺序。官方 FAQ 说明，调用模型时优先扣除满足模型适用场景的资源包余额，再扣现金账户余额；如果有多个适用场景相同的资源包，优先扣最快过期的那个。所以现金余额没怎么动、不代表没花钱，得把资源包的消耗一起看。另外欠费状态下有效期内的资源包仍然可以使用，资源包过期后不支持延期、续费或重新激活。

然后再看是不是单次输入变长了。典型的三种情况：会话历史没有做截断，跑了一段时间之后每一次请求都在背一大段上下文；某次上线给工具定义加了一大段说明文字，导致每一次调用的固定开销都涨了一截；或者是给某个入口开了联网搜索，搜索结果把输入撑大了。这三种在账单上的表现是一样的——调用次数没怎么变，消耗却明显上去了——只能靠分词器接口把各类请求回头量一遍，才分得清是哪一种。

还有一个容易忽略的口径问题：体验中心的计费规则和 API 调用一致，在网页上试模型同样会产生费用。团队里有人拿体验中心跑批量测试，账单是会体现出来的。

另外两条政策性口径也建议先知道。一是平台暂时不支持任意形式的退款，官方的原话是让用户充分预估实际需求再确定充值金额，所以宁可分次充、也别一次性押太多。二是 API Key 删除之后将无法再成功调用接口，也不会再产生扣费——排查「是不是某个早该废弃的 Key 还在偷偷跑量」时，删掉是干净利落的止血手段。

想把单次输入压下来，能动的地方

按「见效快慢」排一下：

截断历史是性价比最高的。多轮会话保留最近若干轮加一段摘要，比全量重发要省得多，而且立刻生效。代价是模型对早期上下文的记忆变弱，需要按业务容忍度调。

把稳定的部分固定下来。系统提示词、长文档这类不变的内容，官方最佳实践建议放在 system 消息里并保持字面稳定——官方也提醒过，轻微的格式差异就可能影响缓存效果。这一招降的是那部分 token 的单价，不改变请求体积，但方向是对的。

该用 Batch 就用 Batch。官方文档说明 Batch API 通过文件提交大量任务，适用于无需即时反馈的场景，按低于标准 API 的价格计费，具体比例见官方定价页。离线的分类、抽取、批量改写这类任务走 Batch 明显更划算；同时记住前面那条，用户权益升级后的价格优惠对 Batch API 不生效，算账时别把两份好处叠着算。

长文档改成检索。与其每次把整份文档塞进 system，不如先切片检索，只把相关片段发进去。这是这几条里唯一能真正把请求体积降下来的做法，其余几条要么是复用已算过的内容、要么是换一条通道。

不要用 max_tokens 去控输入。这个参数限制的是模型单次生成的最大 token 数量，属于输出侧，改它不会让你的输入少掉一个 token。想控输入只能在拼 messages 的时候控。

最后

这件事上最容易栽的坑，是把「便宜的模型」和「便宜的调用」当成一回事。选一个单价低的模型，但每次都把二十轮历史加一份长文档发过去，最后的账单未必比用好模型加严格截断更好看。成本的杠杆在请求体的组织方式上，不在模型选型上。

下一步建议做两件具体的事：第一，找一个真实请求，原样发给分词器接口跑一次，看看 prompt_tokens 到底是多少——第一次跑完基本都会被结果吓一跳；第二，去费用账单页面按模型和时间维度拉一遍明细，确认自己的请求主要压在哪一档。这两步做完，再去看定价页的数字才有意义。GLM 计费的其他基础口径可以看GLM API 计费。