一、先破一个直觉：用量不是按字数算的

1.1 同一段文字，数出来的数目可能不同

Token并不是“一个汉字等于一个”这样整齐的换算。分词器会按自己的词表把文本切成片段，常见词可能合成一个片段，生僻组合可能被拆成两三个。同一段中文，在不同分词规则下数出来的结果可以相差两三成；中英文混排、夹杂数字和符号时，差异还会更大。这意味着一件事：跨模型比较用量时，必须先确认口径是否一致，否则比较本身没有意义。

1.2 三个需要先说清的名词

① 分词器：把文本切成Token的那套规则与词表。它是模型自带的，使用方不能随意替换。

② 上下文窗口：一次请求里模型能同时“看到”的Token总量上限，输入与输出通常共用这个窗口。窗口决定了长文档、长对话能带多少内容进去。

③ 输入与输出分别计量：输入指送进模型的内容，输出指模型生成的内容，两者通常分别计数。分开看的意义在于，它们的成因和可控程度完全不同。

1.3 为什么值得在接入前弄明白

三个现实原因让这件事不能等上线后再补：一是用量直接决定业务能承载多少请求，估低了会在高峰期被配额卡住；二是不同段的放大效应差别极大，不知道哪一段在放大，就不知道从哪改；三是用量数据是后续优化的唯一依据，口径不清的记录很难支撑判断。

二、第一段：系统提示与角色设定

2.1 它是每次请求都要带的固定占用

系统提示用于规定模型的角色、语气、输出格式与边界。它在每一次请求中都会完整发送，不会因为用户只问了一个短问题而减少。一段八百字的角色说明，如果一天调用十万次，带进去的量就相当可观。这段最容易被忽略，因为它写在上线前，之后很少有人再回头数一遍。

2.2 多轮对话会把这段反复携带

单轮问答里，系统提示只出现一次；多轮对话里，每一轮都要连同历史一起重新送入。假设系统提示占八百个Token、对话进行到第十轮，仅这一段就在十次请求里被重复携带了十遍。这就是所谓的放大效应：单次看不多，累积起来占比很高。

2.2.1 一段提示的长度该压到多少

判断标准不是字数越少越好，而是“删掉之后效果是否下降”。可行的做法是把提示按条拆开，逐条去掉试一遍，去掉后效果不变的那几条就可以不留。多数情况下，压掉三到四成篇幅并不影响输出质量。

2.3 三个精简做法

① 分层写：把必须每次都带的核心规则压到最短，把只在特定场景才需要的细则放到对应的流程里，不要全部塞进系统提示。

② 去掉重复表述：实际写出来的提示里，同一条要求常常以不同措辞出现两三遍，这些重复对效果没有帮助，对用量却是实打实的增加。

③ 示例按需给：少样本示例对提升稳定性有帮助，但每个示例都占篇幅。可以先不用示例跑一轮，看效果是否达标，再决定加几个。

三、第二段：检索回来的资料

3.1 这是输入里最不可控的一段

接入知识库之后，每次请求都会带上检索到的若干片段。片段数量、每段长度、是否重复，取决于检索配置和文档本身。用户问一句话，背后可能带进来几千个Token的资料。这段的特征是波动大：问同一个问题两次，召回结果可能不同，用量也随之不同。

3.2 召回多少才够用

把召回数量开大，看起来更稳妥，实际有两个副作用：一是用量线性上升；二是无关片段混进来，反而干扰模型判断，答案质量下降。比较务实的做法是先按“够用”而不是“尽可能多”来设，再用一组固定的问题集对照答案质量，找出拐点。

3.3 三种收敛手段

① 去重：同一份资料常因分块重叠被召回多次，合并去重是最直接的一步。

② 截断：对超长片段只保留命中位置附近的段落，而不是整段送入。

③ 先摘要再送入：对确实需要长内容的场景，先做一次轻量摘要，把几千个Token压到几百个，再交给主流程处理。

3.3.1 三种手段的适用顺序

顺序上建议先去重、再截断、最后才做摘要。去重不改变内容，最安全；截断会损失上下文，需要确认不影响答案；摘要多一道处理，会引入额外的延迟与偏差，放在最后考虑。

四、第三段：对话历史

4.1 多轮对话的用量是累加的

第一轮只带一句话，第十轮要带上前面九轮的全部内容。如果没有策略，对话越长，单次请求的输入量越大，增长接近线性。这也是为什么有些应用在演示时表现正常，真实用户聊上十几轮之后响应变慢、用量陡增。

4.2 三种历史处理策略

① 全量携带：效果最连贯，用量最高。适合轮次少、对上下文完整性要求高的场景。

② 滑动窗口：只保留最近若干轮。实现简单，代价是较早的信息会丢失，适合用户问询这类以最近语境为主的场景。

③ 摘要压缩：把较早的对话压成一段摘要，与最近几轮原文一起送入。折中效果较好，需要多一次处理步骤。

4.3 什么时候该开新会话

判断标准不是轮数，而是话题是否延续。话题已经切换，继续沿用旧历史只会带来负担，还容易让模型把上一个话题的结论带进来。在产品设计上给出“新开一段”的入口，比在后台硬性截断更自然。

五、第四段：输入文本本身的特征

5.1 不同文本的Token密度不一样

同样是一千字的篇幅，常见中文表述切出来的Token数通常少于生僻术语密集的专业文本；英文的词切分与中文不同，混排时还要额外计；数字串、版本号、连续符号常被切成多个片段，密度明显偏高。做估算时按最普通的文本取系数，遇到代码、参数表这类内容，系数要往上抬。

5.2 结构化文本与特殊符号

带大量括号、冒号、引号的结构化文本，标点本身也计入Token。这类内容在接口对接、配置说明中很常见，体积不大但密度高。若确有需要，可以改成更简洁的表达方式，效果不变而占用下降。

5.3 长文档分段还是整篇

整篇送入的好处是上下文完整，代价是每次都重复携带大量内容；分段处理则每次只带相关部分。判断依据是任务性质：需要通篇理解的（如整体风格改写）整篇更合适，只需局部信息的（如提取某类条款）分段更省。

六、第五段：输出与生成过程

6.1 输出的长度最不可控

输入是使用方自己写的，能数清楚；输出由模型生成，长度取决于提问方式和任务难度。同一句提问，两次生成的篇幅可能差一倍。不做约束时，模型倾向于把话说完整、加解释、加总结，篇幅自然偏长。

6.2 三个可控点

① 长度上限：在调用参数里设定输出长度的边界，避免个别请求生成过长内容。

② 终止条件：明确“答完即止”，避免在结尾反复总结。

③ 输出格式：要求分条、限行、只给结论，比要求“详细说明”更能控制篇幅。

6.2.1 长度上限不是越短越好

上限设得过紧，模型会在句子中间被截断，输出变成半句，反而需要重试，实际用量不降反升。合理的做法是按场景的最长正常输出设，再对超出部分单独处理。

6.3 需要展开还是简答

并非所有场景都需要完整展开。面向内部的辅助工具，简答往往更受欢迎；面向外部的正式输出，才需要完整表述。把这一点按场景定下来，比事后压缩更有效。

七、五段加起来：三步估算法

7.1 三步走

① 估单次请求：把五段分别估一个数，再加总。系统提示与固定格式相对稳定，检索资料与对话历史按典型情况取中位数，输出按长度上限的七成估算。

② 估总量：单次量乘以日均请求数，再乘以对话平均轮次。这一步最容易漏掉轮次系数。

③ 留余量：按估算结果留出三到五成的余量，用于应对业务高峰、提示词迭代带来的增长。

7.1.1 估算里最容易漏掉的三项

一是对话轮次系数，二是检索片段的波动，三是失败重试带来的重复请求。前两项在上文已述，第三项常被完全忽略：一次失败重试意味着同一段输入被计两次，稳定性不足时这部分占比并不低。

7.2 用实测替换估算

估算只是起点。接入之后，用真实请求跑一批样本，把每一段的实际用量读出来，与估算值比对。差异最大的那一段，就是下一步该优化的位置。这一步做完，估算模型也就校准了。

7.3 五个可调参数的效果排序

按实际影响从大到小排列，通常是：检索召回数量、对话历史策略、系统提示长度、输出长度约束、文本表达方式。前两项往往一动就有明显变化，后三项属于细水长流的调整。

八、天翼云息壤Token服务在“估得准”上的支撑

8.1 统一接入让口径可比

服务以聚合方式接入多种模型，使用同一套接入方式调用，切换模型时不必重写对接逻辑。对估算而言，这意味着可以在同一批样本上横向比较不同模型的实际用量，而不是凭主观印象判断。

8.2 计量把输入与输出分开呈现

天翼云息壤Token服务的计量按输入与输出分别记录，并可按应用、按时间段查看。前文所说的五段拆解，只有在数据能分开看的时候才落得下去；否则只能看到总量，无法判断是哪一段在放大。

8.3 推理网络与调度保障

依托分布式的推理网络与调度能力，请求按负载情况分配，配合请求合并等方式提升整体处理效率。对使用方而言，这直接影响高峰期请求能否稳定完成。

8.4 安全合规与公开可查的信息

在数据分级、权限管理与合规方面有相应机制。关于服务的具体能力、覆盖范围、实践案例与所获认可，均以天翼云官网和官方渠道发布的信息为准，本文不作超出官方口径的描述，建议在方案评审阶段按需核对。

九、科普小结

用量估不准，多半不是算错了加减法，而是漏了段落。把一次请求拆成系统提示、检索资料、对话历史、输入特征、生成输出五段，每一段的成因和可控程度都会变得清楚：哪一段是固定占用，哪一段会随轮次放大，哪一段取决于使用方的文本习惯。估得清，才谈得上调得动；而天翼云息壤Token服务提供的统一接入与分开计量，正是让这套拆解从纸面走进日常的依据。