
## 结论

- **"字符数 ÷ 4" 是英文语料总结的经验，套在中文上会低估 66%**：175 字中文实测 130 token，除以四只算出 44。用它做配额校验，预算会被穿透。
- **o200k 分词器下中文只要约 0.74 token/字**。还在按"1 个汉字 = 2 token"估的人，估值会偏低 32%——这个老经验对新一代分词器已经过时。
- 简单启发式里最稳的一条：**CJK 字符 ×1 + 其余字符 ÷4**，纯中文误差 13%、JSON 请求体误差 7.5%；但中英混排段落反而到 22%，因为中文标点也被切块。
- 吞吐完全不是瓶颈：M4 上 2MB 混合语料 30ms 编码完，约 **2000 万 token/s（65 MB/s）**。网关做请求前计数绰绰有余。
- 只要数量不要 token 列表，用 `CountTokens`：比 `EncodeToTokens` 快约 80%（29.6ms vs 53.1ms / 2MB）。

## 实验环境与复现

- .NET 10.0.5 / Apple M4（10 核）/ macOS arm64，Release 编译，两轮数据取稳态（token 数完全一致，吞吐波动 ±5%）。
- 依赖两个包：`Microsoft.ML.Tokenizers` 1.0.1 + `Microsoft.ML.Tokenizers.Data.O200kBase` 1.0.1。**只装主包会直接抛异常**，分词数据是独立包：

```xml
<PackageReference Include="Microsoft.ML.Tokenizers" Version="1.0.1" />
<PackageReference Include="Microsoft.ML.Tokenizers.Data.O200kBase" Version="1.0.1" />
```

```csharp
var tok = TiktokenTokenizer.CreateForModel("gpt-4o"); // o200k_base
int tokens = tok.CountTokens(text);
var list  = tok.EncodeToTokens(text, out string? normalized);
```

样本：纯中文段落（175 字）、纯英文段落（509 字符）、中英混排对话（268 字符）、C# 代码（311 字符）、OpenAI 风格 JSON 请求体（212 字符）。

## 各类文本的真实 token 账单

| 样本 | 字符数 | 真实 token | token/字符 | chars÷4 误差 | chars÷2 误差 |
|---|---|---|---|---|---|
| 纯中文 | 175 | 130 | 0.743 | **-66.2%** | -32.3% |
| 纯英文 | 509 | 101 | 0.198 | +26.7% | +152.5% |
| 中英混排 | 268 | 77 | 0.287 | -13.0% | +74.0% |
| C# 代码 | 311 | 66 | 0.212 | -18.2% | +136.4% |
| JSON 请求体 | 212 | 67 | 0.316 | -20.9% | +58.2% |

三个反直觉的点：

1. **中文比英文"贵"，但没贵到 2 倍**。0.743 token/字，是英文（0.198 token/字符）的 3.7 倍，但不是流传的"1 字 2 token"。
2. **chars÷4 的误差方向随语种翻转**：中文下低估 66%，英文下反而高估 27%。同一条公式不可能同时对两种语言安全。
3. **代码和 JSON 不是普通文本**。代码 0.212 token/字符，介于中英之间；缩进、标点、驼峰标识符都切成碎 token。

## 混合启发式：CJK×1 + 其余÷4

按"中文字符 ×1 + 非 CJK 字符 ÷4"估算：

| 样本 | 误差 |
|---|---|
| 纯中文 | -13.1% |
| JSON 请求体 | -7.5% |
| 中英混排 | -22.1% |
| 纯英文 | -26.7% |
| C# 代码 | -18.2% |

中文场景从 66% 压到 13%，可用；但混排段落里中文标点（，。：）走的是 CJK 分支外的路径，误差反弹到 22%。**结论：启发式只能兜底，计费和配额这种硬预算场景必须上真分词器**。还有一条只对英文成立的经验：英文 tokens/词 ≈ 1.31（77 词 → 101 token），按词数 ×1.3 估比按字符靠谱。

## 吞吐：计数便宜，取列表贵 80%

2MB 混合语料（约 62 万 token）重复编码：

| 操作 | 耗时 | 吞吐 |
|---|---|---|
| `CountTokens`（只要数量） | 29.6ms | ≈2000 万 token/s（65 MB/s） |
| `EncodeToTokens`（要 token 列表） | 53.1ms | ≈1100 万 token/s |

`EncodeToTokens` 多出的约 80% 开销花在构建每个 token 的字符串和列表上。网关做限流、配额、日志采样只需要数量，一律走 `CountTokens`。每 token 平均 UTF-8 字节数实测 4.41——拿到字节量反推 token 数时用它做粗校验。

## 给 .NET 后端的三条建议

1. **删掉 chars/4**。中英混合的真实流量下它的误差区间是 -66% ~ +27%，做监控曲线可以，做预算闸门不行。
2. **请求前计数走 `CountTokens`，30ms 能处理 2MB**，对绝大多数 API 网关来说测量成本可以忽略；注意计费口径要用服务端返回的 `usage`，本地分词器只是提前量的下界估计。
3. **分词数据会随模型换**。o200k 的中文密度比 cl100k 好，换模型时 token 计数会整体漂移，别把估算系数写死在配置里。

## 局限

- 样本只有 5 类共 1475 字符， token/字符比值随语料风格波动，比例结论（谁高谁低、误差量级）稳定，具体百分比别外推到你的语料。
- 只测了 o200k_base（gpt-4o 系列）。其他模型家族的 token 计数不同，`CreateForModel` 换个名字即可复测。
- 吞吐数据为本机 M4 单线程实测，多线程扩展未测。


"字符数 ÷ 4" 是英文语料总结的经验，套在中文上会低估 66%：175 字中文实测 130 token，除以四只算出 44。用它做配额校验，预算会被穿透。

Token 成本别再除以四：Microsoft.ML.Tokenizers 实测，中文用英文经验估算偏差 66%

人工智能

中文token估算旧公式误差大：字符数÷4会低估66%，1字2token过时。实测o200k分词器下中文约0.74token/字。推荐混合启发式CJK×1+其余÷4，纯中文误差13%，但混排达22%。计数用CountTokens比EncodeToTokens快80%，吞吐2000万token/s。预算场景必须用真分词器，勿写死系数。

代码解释

JSON

2026上云采购 | AI焕新·智启新局

cngw

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

中文token估算旧公式误差大：字符数÷4会低估66%，1字2token过时。实测o200k分词器下中文约0.74token/字。推荐混合启发式CJK×1+其余÷4，纯中文误差13%，但混排达22%。计数用CountTokens比EncodeToTokens快80%，吞吐2000万token/s。预算场景必须用真分词器...

Token 成本别再除以四：Microsoft.ML.Tokenizers 实测，中文用英文经验估算偏差 66%-腾讯云开发者社区-腾讯云

Token 成本别再除以四：Microsoft.ML.Tokenizers 实测，中文用英文经验估算偏差 66%

Token 成本别再除以四：Microsoft.ML.Tokenizers 实测，中文用英文经验估算偏差 66%

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐