AI Token 是什么？中文一个字算几个 token 与省钱技巧

同样一段 1000 字的内容，用英文写消耗约 250 个 token，用中文写要 700 个——中文的 token 效率大约只有英文的三分之一到二分之一，这直接反映在 API 账单上。这篇文章讲清楚 token 到底是什么、BPE 分词为什么对中文不友好、各主流模型的实际差异和价格，最后给 6 个能立刻用上的压缩技巧。

Token 不是字，也不是词

大模型看不懂文字，它只认识数字。Token 就是把文本切分后得到的最小处理单位，每个 token 对应词表里的一个 ID。

以 GPT 系列使用的 BPE（Byte Pair Encoding，字节对编码）为例，切分过程大致是这样的：

1. 初始词表只有 256 个字节（所有可能的单字节值）
2. 在训练语料中统计相邻字节对的出现频率
3. 把出现频率最高的那一对合并成一个新 token，加入词表
4. 重复第 2-3 步，直到词表达到目标大小（GPT-4o 约 20 万）

结果就是：高频出现的字符串会被合并成一个 token，低频的则保持零散。

看几个实际的切分例子（以 GPT-4o 的 o200k_base 编码器为例）：

关键观察：英文的常用完整单词往往只占 1 个 token，而中文的常用词占 1-2 个 token，生僻字甚至要 2-3 个 token。

中文为什么更费 token

根本原因是编码字节数的差异。

在 UTF-8 编码下：

• 一个 ASCII 英文字母 = 1 字节
• 一个常用汉字 = 3 字节
• 一个 emoji = 4 字节

BPE 是在字节层面做合并的。英文单词 "the" 只有 3 个字节，很容易被合并成 1 个 token；而汉字「的」本身就是 3 个字节，要合并成 1 个 token 需要词表专门为它留位置。

对于词表中没有的生僻汉字，模型只能按字节拆开处理，一个字就变成了 2-3 个 token。这就是为什么「薅」「饕」「餮」这类字特别烧 token。

各语言的经验系数（每个字符平均消耗的 token 数）：

一个实用的估算法则：中文按「字数 × 0.7」估算 token 数，英文按「单词数 × 1.3」估算。 需要精确数值时，用 Token 计数器贴进去实测，不同模型的分词器差异可以直接看到。

注意 Base64 特别费 token（0.75/字符），因为它是随机性很强的字符序列，BPE 几乎无法有效合并。所以千万不要把图片转成 Base64 塞进 prompt——一张 100 KB 的图片转 Base64 后约 133 KB 字符，会消耗约 10 万 token，成本远高于用多模态接口直传。

主流模型的分词差异与价格对照

不同厂商用不同的分词器，同一段中文的 token 数可能相差 40%。

以「人工智能技术正在快速发展，深刻改变着各行各业的运作方式。」这句 27 个汉字（含标点）为例的大致表现：

规律很清晰：国产模型因为训练语料以中文为主，词表里给中文留的位置多，中文 token 效率明显更高。 GPT-3.5 时代的 cl100k 编码器对中文最不友好，升级到 o200k 后改善了约 35%。

价格方面（截至 2026 年上半年的公开定价，单位：元 / 百万 token，实际以官网为准）：

两个必须注意的定价规律。

第一，输出比输入贵 3-5 倍。 这不是厂商随意定的——输入可以批量并行处理（prefill 阶段），输出必须逐 token 自回归生成（decode 阶段），后者对显存带宽的占用大得多。所以控制输出长度的省钱效果，是控制输入长度的 3-5 倍。

第二，价格差异可以达到 20 倍。 同样的任务，GPT-4o 输入 ¥18/百万 token，通义千问 Plus 只要 ¥0.8。做简单的分类、抽取、格式转换任务，用小模型完全够用，没必要上旗舰模型。

上下文窗口：不是越长越好

上下文窗口指模型单次能处理的最大 token 数，包含输入 + 输出。

一个常见误解是「把所有相关资料都塞进去，模型效果更好」。实际上有三个问题：

第一，成本随长度线性增长，但每一轮对话都要重发全部历史。

多轮对话的成本是累积的。假设 system prompt 是 500 token，每轮用户输入 200 token、模型输出 300 token：

10 轮对话的累计输入是 29,500 token，而用户实际只输入了 2,000 token。 这是长对话成本失控的根本原因。

第二，「大海捞针」效应真实存在。 多项研究表明，模型对上下文开头和结尾的信息记得最牢，中间部分的召回率明显下降。把关键指令放在 50K token 的中间位置，模型很可能忽略它。正确做法是把最重要的指令放在最前面或最后面。

第三，长上下文会拖慢首字响应时间（TTFT）。 prefill 阶段的计算量与输入长度大致成正比，128K 的输入可能让首字延迟从 0.5 秒变成 5 秒以上。

压缩 prompt 的 6 个实操技巧

按节省效果从大到小排序。

技巧一：明确限制输出长度

这是性价比最高的一条，因为输出单价是输入的 3-5 倍。

不加限制时，模型倾向于生成完整、详尽、带铺垫的回答。同一个问题：

• 无限制：模型输出约 800 token
• 加一句「用不超过 100 字回答，不要解释」：输出约 130 token

节省 84% 的输出成本。

具体写法：

- 「直接给结论，不要解释过程」
- 「用不超过 3 个要点回答」
- 「只输出 JSON，不要任何其他文字」
- 「回答控制在 200 字以内」

同时在 API 层面设置 max_tokens 作为硬性上限，防止意外的长输出。想核对生成内容的实际长度，用字数统计工具可以同时看到字数和字符数。

技巧二：删掉所有客套话

对模型说「请」「谢谢」「麻烦你」「你是最棒的助手」不会提升效果，只会增加 token。

反例（78 token）：

你好！我想麻烦你帮我做一件事情，如果可以的话，
请你帮我把下面这段文字翻译成英文，非常感谢你的帮助！
文字如下：...

正例（12 token）：

翻译成英文：
...

省了 66 token。 单次不多，但如果这是一个每天调用 10 万次的线上服务，一天就是 660 万 token，按 ¥18/百万算是 ¥119/天、¥43,000/年。

技巧三：用结构化标记代替自然语言描述

自然语言啰嗦，结构化标记紧凑且模型解析更准确。

反例：

接下来我会给你一段文章，然后我希望你能从这段文章里面
提取出所有提到的人名、地名和时间，并且按照 JSON 的
格式返回给我，其中人名放在 person 字段里...

正例：

从<text>中抽取实体，输出JSON：
{person:[], location:[], time:[]}
<text>...</text>

从约 90 token 压缩到约 35 token，而且指令更清晰。 XML 标签（）在 Claude 上效果尤其好，官方文档明确推荐。

技巧四：控制 few-shot 示例的数量和长度

给示例（few-shot）能显著提升输出质量，但示例是纯输入 token，且每次调用都要重发。

经验规律：

• 0 → 1 个示例：效果提升最大
• 1 → 3 个示例：仍有明显提升
• 3 → 10 个示例：边际收益急剧下降

多数任务用 2-3 个精选示例就够了。 挑选原则是覆盖边界情况而非罗列相似案例——3 个各不相同的示例，好过 10 个大同小异的。

另外，示例本身也要精简。把 200 字的完整示例压缩成 50 字的核心片段，效果往往不受影响。

技巧五：利用 Prompt Caching 复用 system prompt

主流厂商都支持提示词缓存：把固定不变的前缀（system prompt、知识库、few-shot 示例）标记为可缓存，后续请求命中缓存时按大幅折扣计费。

Anthropic 和 DeepSeek 的 90% 折扣非常可观。 假设你的 system prompt 有 5000 token，每天调用 1 万次：

• 无缓存：5000 × 10000 = 5000 万 token
• 有缓存（90% 命中）：500 万 + 4500 万 × 10% = 950 万 token

成本降到 19%。 使用条件是：缓存内容必须放在 prompt 最前面且完全一致，任何一个字符的变动都会导致缓存失效。所以要把变化的部分（用户输入）放在最后。

技巧六：长文档先摘要再处理

要对一份 5 万字的文档做问答，直接全文塞进去每次都要花 3.5 万 token。

更经济的做法是两阶段处理：

1. 第一阶段：用便宜的小模型（如 GPT-4o mini、通义 Plus）把文档分段摘要，5 万字压缩到 5 千字
2. 第二阶段：用摘要 + 原文相关片段回答具体问题

成本对比（假设问 20 个问题）：

成本降到约 11%。 更进一步可以做 RAG（检索增强），只把与问题最相关的 3-5 个段落送进模型。批量摘要这类活儿用AI 摘要工具先跑一遍，比自己写脚本调 API 快。

一个完整的成本优化案例

某客服机器人，原始配置：

• System prompt：2,000 token（含公司介绍、语气要求、8 个 few-shot 示例）
• 平均对话 6 轮，每轮用户 150 token、模型输出 400 token
• 日均 5,000 次对话
• 使用 GPT-4o（输入 ¥18、输出 ¥72 / 百万 token）

优化前：

单次对话累计输入 = (2000+150)×6 + 400×(1+2+3+4+5) = 12,900 + 6,000 = 18,900 token
单次对话输出 = 400 × 6 = 2,400 token
日成本 = 5000 × (18900×18 + 2400×72) / 1,000,000 = 5000 × (0.34 + 0.173) = ¥2,565

优化措施：

1. system prompt 精简客套话、示例从 8 个减到 3 个 → 2000 降到 700 token
2. 启用 prompt caching（命中率 85%）→ 缓存部分按 5 折
3. 限制输出「不超过 150 字」→ 输出 400 降到 200 token
4. 简单意图分类改用 GPT-4o mini 前置路由，40% 的对话不再进入主模型

优化后日成本约 ¥620，降幅 76%，年省约 ¥71 万。

总结

Token 是模型处理文本的最小单位，由 BPE 算法按字节频率合并生成。中文一个字约占 0.6-0.7 个 token（生僻字更多），英文一个单词约 1.3 个 token，差异来自 UTF-8 编码下汉字占 3 字节而英文字母占 1 字节。国产模型（DeepSeek、通义、文心）的中文 token 效率明显优于 GPT-3.5 时代的编码器。

价格上要记住两条：输出单价是输入的 3-5 倍，所以限制输出长度是最有效的省钱手段；不同模型价差可达 20 倍，简单任务用小模型。

六个技巧按效果排序：限制输出长度（省 80%+）> 用 Prompt Caching（省 80%）> 长文档先摘要（省 90%）> 用结构化标记 > 精简 few-shot 到 3 个以内 > 删掉客套话。这些叠加起来，把线上服务成本降到原来的四分之一是很现实的目标。

动手前先用 Token 计数器测一下现有 prompt 的实际消耗，找到最肥的那块再动刀，比全面优化更高效。