Token 是什么?为什么大模型按 Token 计费?

#入门 #基础概念 #token是什么 #大模型token计费 #tokenizer分词

搜索「提示工程」匹配到口述回答，相关段落已展开。查看匹配内容 ↓

完整题目

大模型里的 Token 是什么?为什么中英文 Token 数量差异很大,各家 API 又为什么按 Token 计费?

本文目录

答案要点

Token 是大模型处理文本的最小单位,由分词器(Tokenizer)切出来,可能是一个词、半个词或一两个汉字
模型的输入输出、上下文窗口、计费全部以 Token 计量,而不是字符或单词
中英文差异:主流词表偏英文,1 个英文单词约 1~1.3 token,1 个汉字常需 1~2 token
按 Token 计费是因为计算量与 Token 数直接成正比,每生成一个 token 都要完整跑一遍前向计算
估算成本先估 Token:输入和输出都收费,输出单价通常更贵

核心概念

Token 是大模型读写文本时的最小处理单位,由分词器(Tokenizer,把文本切分成小片段的组件)按照训练好的词表把句子切开。它不等于「字」也不等于「词」:常见英文单词可能整体就是 1 个 token,生僻词会被拆成几段,一个汉字可能对应 1~2 个 token。主流切分算法是 BPE(字节对编码)一类:高频片段合并成一个 token,低频内容拆碎处理。

中英文 Token 差异

文本	大致换算
英文	1 个单词 ≈ 1~1.3 token,100 词 ≈ 130 token

学习内容与项目面试，在同一条路上。

站内 RAG 在线实战

换一种问法，检查是否真正理解

场景切入

你要给公司做成本预算:每天 1 万次调用,平均每次输入 500 个汉字、输出 300 个汉字,你怎么估算一天大概消耗多少 token?

概念辨析

Token、字符、单词这三个概念有什么区别?为什么模型的上下文长度不用字符数来定义,而要用 token 数?

练习口述回答 · 约2分钟

一句话定位：Token 是大模型的基本计价和计算单位
中英文差异源于词表偏向英文，中文更费 Token
按 Token 计费因为算力和 Token 数成正比，输出更贵
落地时估算 Token 是关键，注意上下文窗口限制

这道题其实是在问大模型怎么理解文本、怎么定价，背后是同一个东西，Token。Token 是大模型处理文本的最小单位，由 [[Tokenizer]] 切出来。它不一定是完整的词，可能是半个词、一个汉字，甚至一个字节。模型的所有操作，输入、输出、上下文窗口、计费，全按 Token 算，而不是字符数。

中英文差异很明显，主要原因是词表大多在英文语料上训练。英文高频词能整词进词表，一个单词大概 1 到 1.3 个 Token；中文汉字数量庞大，很多词没在词表里，就得拆成字节，一个汉字大概 1 到 2 个 Token。同样一段话，中文往往更费 Token，上下文窗口能装的内容更少，调用成本也更高。不过新一代模型已经把中文词表扩充了，差距在缩小。

再说计费。为什么按 Token 而不是字数？因为模型的计算量和 Token 数成正比。每生成一个 Token，都要完整跑一遍前向计算，所以输出单价通常比输入贵好几倍。Token 是和算力成本最对齐的单位。

举个例子，你做一个客服退款场景的问答系统，用户问一句“我的订单还没退款”，大概 10 个汉字，按 1.5 倍算就是 15 个 Token。模型回复“您好，请提供订单号”，又是十几个 Token。如果上下文窗口只有 4K，那对话几轮就可能超限。所以落地时，估算 Token 是第一步，既要算输入也要算输出，还要留足窗口给历史。

这里有个坑：很多人以为上下文窗口越大越好，但窗口越大，计算成本越高，而且模型对长距离信息的注意力会衰减。实际项目中，我会根据业务场景设定窗口上限，比如客服场景 2K 到 4K 就够，文档分析才需要 8K 以上。

所以我会把 Token 看成大模型的“货币”，理解了它，你才能准确估算成本、设计提示词、选择模型。进一步，如果你对 Tokenizer 的细节感兴趣，可以聊聊 BPE 算法的合并策略，它直接影响词表大小和推理效率。