摘要: 用两套词表的实际计数解释Token、字符数和上下文的区别,说明为什么不能用统一的中文换算比例估算所有模型。
Token是模型处理文本时使用的离散单位。它可能对应一个完整词、一段词、一部分字符或符号。你在编辑器里看到的字数与Token数属于不同计量方式,不能简单互换。
这会影响两个实际问题:一次请求能放进多少内容,以及按量调用服务时如何估算消耗。但聊天产品的订阅权益与API按量计价,也需要分别看,不能因为模型名称相同就默认共享额度。
先看一组实际计数
本站使用tiktoken 0.14.0,对以下四段原文分别采用cl100k_base与o200k_base词表编码。字符数采用Python的len(text),这里不涉及复杂组合表情;表内Token只包含原始文本,没有消息角色、工具定义或服务包装。
| 原始文本 | 字符数 | cl100k_base | o200k_base |
|---|---|---|---|
| 你好,世界! | 6 | 7 | 4 |
| AI工具导航 | 6 | 6 | 3 |
| Hello, world! | 13 | 4 | 4 |
| 订单号0078,金额15360元。 | 17 | 10 | 10 |
“你好,世界!”有6个字符,在两套词表中分别得到7和4个Token。这足以说明,同一句中文不存在跨所有模型固定成立的“一个字等于几个Token”。英文例子也不能反过来证明所有英文都有相同比例。
为什么同一句话会切成不同数量
Tokenizer有自己的词表和编码规则。常见片段可能被合并成一个单位,不常见片段可能被拆开。不同模型或版本可能配套不同的Tokenizer;语言、标点、空格、数字和代码结构也会改变分段。
Token ID是词表中的编号,不是字义编码,也不是对内容重要性的打分。某个字被拆成多个Token,不代表模型必然理解不好;用量和能力需要分别评估。
可复制的计数方法
import tiktoken
text = "你好,世界!"
for name in ["cl100k_base", "o200k_base"]:
ids = tiktoken.get_encoding(name).encode(text)
print(name, len(ids), ids)
这个例子明确指定词表,用于复现本页结果。要估算某一真实服务,应使用该模型官方支持的计数方式,不能随意选一套词表当作所有模型的用量表。包含图片、音频或特殊工具消息时,纯文本本地计数尤其可能不等于服务报告的消耗。
输入、输出与上下文分别是什么
输入Token:模型本次接收到的内容,可能包含系统指令、历史消息、检索片段和工具定义,不只你刚打的那一句。输出Token:模型生成的内容;某些服务还区分其他计量类别,应以实际用量字段为准。
上下文窗口:一次计算可处理内容的容量约束。输入已经很长时,还需要为生成留空间;服务也可能分别限制输入与最大输出。窗口足够容纳文件,不表示其中每一处内容都一定被正确利用,更不等于永久记忆。
为什么上传文件大小也不能直接换算
PDF可能包含可提取文字、扫描图片和版面结构。服务可能先OCR、分块、检索,只把部分结果放入请求。文件的MB数、页面数和实际进入上下文的Token是三个不同指标。先看产品如何处理文件,再判断是否需要拆分。
怎样估算成本更接近实际
分别统计输入与输出,并按照所选服务当日的单价及计量单位计算。若单价按每百万Token给出,就将相应数量除以一百万再乘单价;缓存、批量调用或其他计量类别要单列,不能默认都用同一价格。
使用真实资料抽样试跑,再查看服务报告的用量,是比“每页大约多少字”更稳妥的估计方式。本文没有列当前模型价格,避免将某个时点的价目表误作长期规则。
降低消耗时,先删无关内容
减少重复历史、删除无关附件、把需要的字段说清,通常比强行压缩每个汉字更可控。若为省Token把关键定义删掉,后续错误重试可能抵消节省。稳定输出格式可参考JSON、表格与自由文本选择。
资料来源与核查日期
资料核查:2026年10月22日至23日。产品条件可能调整,具体操作以当前官方页面为准。