网硕互联帮助中心中文 Prompt 不能用“字数除以固定比例”得到可靠的 Token 数。同一句话使用不同分词编码，结果可能不同；标点、空格、英文、JSON 和 emoji 也会改变切分方式。正确做法是先确认目标模型采用的编码，再对准备发送的原始文本计数。
先给结论
字符数、字节数和 Token 数分别回答什么
页面的“Unicode 码点”统计文本包含多少个码点，空格、换行和组合字符中的各个码点也会计入，因此它不等于肉眼看到的字数。“UTF-8 字节数”回答文本编码后占多少字节；“Token 数”回答特定分词器如何把文本拆成编号序列。
例如，中文通常需要多个 UTF-8 字节，emoji 也可能由多个码点组合而成。一个英文单词可能是一个 Token，也可能被拆成多个词片段。空格和标点有时会与相邻文本合并，有时会单独成 Token。因此，下面几种估算都不适合作为最终值：
- 一个汉字等于一个 Token；
- 一个英文单词等于一个 Token；
- UTF-8 字节数除以某个常数等于 Token 数；
- 上一版 Prompt 的比例可以直接套到新版本。
已知测试样例 antidisestablishmentarianism 使用 cl100k_base 会拆成 6 个 Token，其 ID 为：
[519, 85342, 34500, 479, 8997, 2191]
这个例子说明，即使文本只有一个连续英文单词，分词器也可能把它拆成多个片段。ID 只对所选编码有意义，不应拿去和另一套编码直接比较。
中文也不能按字数直接推算。以 你好，世界！ 为完整输入，不包含引号和末尾换行为例：它有 6 个 Unicode 码点、18 个 UTF-8 字节；2026 年 9 月 9 日按项目当前分词依赖复算，cl100k_base 得到 7 个 Token，o200k_base 得到 4 个 Token。同一输入只因编码不同就出现不同结果，所以估算前必须先确定目标编码。
o200k_base 和 cl100k_base 应该选哪个
先查目标模型的官方说明，再选择对应编码。编码名称相同，也只说明使用该分词规则计算原始文本，不代表已经模拟了完整 API 请求。
如果供应商没有说明使用 o200k_base 或 cl100k_base，就不要强行套用。Claude、Gemini、DeepSeek 或其他模型可能采用不同分词方式；用这两种编码得到的结果最多只能作为参考，不能写成准确计费量。
需要查看具体切分时，可以把文本放入 AI Token 计数器，分别选择两种编码并观察 Token 总数、片段和 ID。工具最多展示前 500 个 Token 的片段，但总数与复制出的 ID 序列仍覆盖完整输入。输入上限按 UTF-16 编码单元计算，与结果中的码点数不同；例如，50,001 个 😀 占 100,002 个编码单元，会超过 100,000 个编码单元的输入限制。
为什么页面片段里会出现替换字符
分词器可能在一个多字节字符的 UTF-8 字节中间切开边界。单独解码某个 Token 时，页面可能显示替换字符；这不表示完整文本已经损坏。把完整 Token 序列按原顺序解码，仍可还原原文。
排查时应先比较完整输入和完整序列，不要根据某一个片段的显示结果删除原文字符。尤其是中文和 emoji，单片段预览只是帮助理解切分，不是文本清洗建议。
计算一次完整请求要包括哪些文本
假设一次请求由以下完整文本组成，代码块中的标签与空行均属于输入：
系统指令：你是一名技术文档审校员，需要保留原文中的数字与来源。
任务要求：检查以下发布说明，列出事实错误和缺失前提。
待审材料：
版本 2.4 将默认超时时间从 15 秒调整为 30 秒，重试次数保持为 2 次。
计数时至少应覆盖系统指令、任务要求和待审材料。多轮会话还要考虑被再次发送的历史消息。使用工具调用时，工具定义和参数结构也可能占用上下文，但纯文本计数器不会自动添加这些内容。
预算输出时，要从模型上下文上限中预留回答空间。输入刚好塞满上限，并不代表请求能够按预期返回完整答案。图片、音频和推理用量有各自的计量方式，也不能通过粘贴一段占位文字来等价计算。
Token 数怎样用于 API 费用估算
先用对应编码估算输入文本，再把输入 Token 数带入费用计算。这里必须区分三件事：
缓存 Token 不能只凭“前缀看起来一样”自行认定。是否命中、命中多少，以及用量字段如何返回，都取决于服务商和实际请求。本文的文本计数结果不包含缓存命中判断。
怎样减少 Token 又不破坏指令
先删重复信息，再考虑缩短表达。比较两版 Prompt 时，优先检查以下位置：
- 多处重复的输出格式要求；
- 已经在结构化字段中提供、正文又重复一遍的背景；
- 与当前任务无关的历史对话；
- 大段示例中没有参与判断的字段；
- 同义反复但没有新增边界的说明。
不要为了减少 Token 删除约束中的条件、例外和验收标准。一段更短但含义模糊的 Prompt，可能带来更多重试，最终成本反而更高。合理目标是减少不参与决策的内容，同时保持稳定指令的顺序和含义。
提交前检查顺序
常见错误清单
| 中文字数不多，Token 却偏高 | 标点、空格、英文和词表共同影响切分 | 用目标编码直接计数 |
| 两个计数器结果不同 | 使用了不同编码或计算范围不同 | 对齐编码与完整输入范围 |
| 页面片段出现替换字符 | Token 边界落在多字节字符内部 | 检查完整序列，不删改原文 |
| 本地计数低于 API 用量 | 未计入角色包装、工具定义或历史消息 | 以响应中的用量数据复核 |
| 费用估算仍不准确 | 使用了过期价格或混淆输入、输出、缓存单价 | 核对调用时的官方价格与分类 |
| 缩短后回答质量下降 | 删除了必要约束或验收标准 | 只移除重复和无关内容 |
Token 计数的价值在于建立可比较的长度口径。它能告诉你文本在某套编码下如何切分，却不能替代模型文档、真实用量数据和效果评估。
评论前必须登录！
注册