Token Counting

中英文翻译工作流中的 Token 统计方法

2026年7月27日TokenTest Team
English中文

一次中英文翻译请求，通常不只是“输入一句原文，输出一句译文”。在生产环境中，请求里还可能包含 System Prompt、术语表、翻译记忆示例、格式规则、JSON 字段，以及后续的质检与修改步骤。这些内容都会消耗 Token。

因此，翻译团队应该为完整工作流做预算，而不是只根据用户看得见的原文字数估算成本。

最实用的原则是：

针对实际模型统计完整请求，为输出单独预留预算，再用接近生产环境的测试核对端点返回的真实用量。

本文将拆解英译中与中译英两种方向的 Token 预算方法，并提供可以直接放进 TokenTest 测试的示例，用于评估 OpenAI-compatible 或 Anthropic 风格的模型端点。

为什么中英文翻译的 Token 数不对称

两段中英文可能表达相同含义，阅读时间也接近，但 Token 数不一定相同。

Tokenizer 统计的不是“意思”、单词数或可见字符数，而是根据特定模型的词表和编码方式切分文本。以下因素都会改变结果：

翻译方向也会影响预算。英文原文与中文译文可能形成一种比例，中文原文与英文译文则可能是另一种比例。英文译文虽然可见长度更长，但常见英文片段可能被高效合并；中文句子虽然字符更少，也可能因字符和词表差异被拆成多个 Token。

所以，“一个汉字等于一个 Token”或“中文一定比英文更贵”都不能作为可靠的生产规则。

如果需要进一步了解“可见长度”和模型用量为什么会分离，可以阅读 Token 数量与字符数量有什么区别 与 为什么中文 Prompt 的 Token 预算可能和英文不同。

翻译 Token 预算的六个部分

与其只记录一个总数，不如把翻译请求拆成六类预算。

预算部分 包含内容 为什么会变化
指令 System Prompt、角色、语气、地区、禁止事项 常在每个分段中重复出现
原文 需要翻译的内容 受语言、长度、名称与格式影响
参考上下文 术语表、风格指南、翻译记忆、示例 有时比原文本身更长
请求结构 Message、JSON Key、工具 Schema、分隔符 纯文本计数器可能漏掉这些开销
译文输出 模型生成的目标语言内容 必须在请求前预留空间
质检与重试 审校、修改、回译、失败重试 会放大整个流程的总用量

单次翻译可以用下面的结构做规划：

计划 Token = 指令 + 原文 + 参考上下文 + 请求结构开销 + 预留输出

如果还包含质检与修改，可以使用：

工作流 Token = 翻译请求 + 质检请求 + 修改请求 + 预计重试余量

这些公式只是预算框架，不是 Tokenizer。每一项都应该来自目标模型的官方计数方式，或来自真实端点返回的用量数据。

英译中的实用测试流程

先看一段可以直接测试的英文原文：

Translate the following product update into Simplified Chinese for enterprise software buyers. Preserve the product name, keep the tone concise, and return only the translation.

Source:
TokenTest checks whether a model endpoint reports plausible input, output, total, and cached token usage before a team relies on it in production.

最小测试应该统计上面整段 Prompt，并为中文译文预留足够空间。生产请求还可能加入术语表：

Terminology:
model endpoint = 模型端点
cached token usage = 缓存 Token 用量
production = 生产环境

术语表可以提升一致性，但也会增加每次请求的 Input Token。如果要翻译 500 个分段，并在每次请求里重复发送完整术语表，术语表的成本可能超过被翻译的正文。

可以考虑：

  1. 每个分段只发送相关术语。
  2. 按领域合并相近分段，共用更小的术语表。
  3. 在模型供应商支持、行为稳定且价格合适时使用 Prompt Caching。
  4. 将缓存 Token 证据与普通输入用量分开记录。

TokenTest 的 D4 Token 计量可信度检查会验证 Input、Output、Total、截断联动与 Cache Token 证据是否存在且合理。因此，它更适合用来验证真正执行翻译的模型端点，而不只是孤立地估算一段字符串。

中译英的实用测试流程

再把方向反过来：

请将以下产品说明翻译成适合企业软件采购人员阅读的英文。保留产品名，语气简洁，只输出译文。

原文：
TokenTest 会在团队将模型端点用于生产环境之前，检查其输入、输出、总量与缓存 Token 用量是否合理。

不要直接复用英译中的 Output Token 余量。英文译文可能在可见长度上扩展，而且目标模型对英文译文与中文原文的切分方式可能不同。

两个方向都应该单独测试，并至少记录：

这样得到的是“方向性基线”，而不是适用于所有内容的语言换算比例。

要统计整个请求包装，而不只是正文

翻译应用经常发送这样的结构化请求：

{
  "source_language": "en",
  "target_language": "zh-CN",
  "tone": "concise enterprise software",
  "preserve_terms": ["TokenTest", "API", "JSON"],
  "source_text": "Paste the source text here"
}

Key、引号、括号、Locale 标签和保留词列表都是请求的一部分。工具 Schema 还可能增加更多 Token。只统计 source_text 会低估真实输入。

短文本场景尤其容易出现偏差。对于只有两个词的按钮文案，请求包装消耗的 Token 可能是正文的很多倍。

上线前至少要测试三类分段：

分段类型 示例 主要风险
短 UI 文案 按钮、菜单、校验提示 固定请求包装主导成本
中等分段 帮助中心段落、产品说明 术语表和示例显著增加输入
长文档章节 政策、指南、报告章节 上下文窗口与输出上限成为关键

为质检、修改与重试预留预算

高质量翻译通常不止调用一次模型。

常见流程包括：

  1. 生成第一版译文。
  2. 使用审校 Prompt 检查漏译、误译与术语违规。
  3. 根据审校意见修改译文。
  4. 对校验失败、超时或 JSON 格式错误的请求进行重试。

质检请求可能同时包含原文、第一版译文、术语表与审校标准。修改请求还可能再次携带这些内容，并加入审校意见。因此，一个三次调用的流程，总 Token 往往远高于原文 Token 的三倍。

建议把翻译、质检与修改作为不同的请求类型分别统计。这样才能看出质量提升来自少量审校开销，还是来自过大的上下文包。

用真实样本建立翻译 Token 基线

不要只用一句经过精心挑选的演示文本。样本集应该覆盖真实生产内容：

然后执行以下流程。

1. 固定请求模板

保存准确的 System Prompt、术语表格式、Message 角色、JSON 结构与输出规则。很小的格式变化也可能改变 Token 数。

2. 预统计完整输入

使用供应商针对目标模型提供的官方统计方式。OpenAI 提供面向 Responses API 输入的 Token 统计接口；Anthropic 提供面向 Messages 输入的 Token Counting Endpoint；Gemini 也提供针对模型输入的 Token 统计方法。

3. 按方向和内容类型预留输出

不要使用统一的输出倍数。分别计算英译中 UI、英译中长文本、中译英 UI 与中译英长文本的实际分位数。

4. 运行接近生产环境的端点测试

使用真实 Message 结构、Temperature、工具和输出限制。在 TokenTest 中评估端点，并同时检查 Token 用量、协议与输出行为。建议使用测试专用 API Key；TokenTest 明确说明不会存储该 Key。

5. 核对预估值与端点用量

比较预统计结果与接口返回的 Input Token。如果差异较大，应先找到原因，再把预算应用到成千上万个翻译分段。

6. 根据真实波动设置安全余量

安全余量应该来自真实样本和失败案例。更换模型、Tokenizer、Prompt、术语表、工具 Schema 或分段策略后，都要重新计算。

值得保留的指标

每个翻译任务都应该保留足够的聚合数据，用于解释成本与失败，同时避免不必要地保存敏感原文。

指标 用途
按组件拆分的 Input Token 判断成本主要来自原文、指令还是术语表
Output Token 建立不同方向和内容类型的基线
Total Token 核对请求级总用量
Cached Token 判断重复上下文是否真正获得缓存收益
每个原文字符对应的 Token 适用于同一模型和稳定内容类型的内部监控
每个译文字符对应的 Token 帮助为特定方向预留输出
修改率 将翻译质量与额外调用关联起来
截断率 发现输出预算不足或上下文压力

比例只能用于监控，不能当作通用常数。从软件 UI 文案学到的比例，不应直接套用到法律文本、用户评论或包含大量代码的文档。

可直接放进 TokenTest 的测试样例

将下面的内容分别作为测试用例，运行在你计划使用的模型端点上。

测试 A：相同任务，翻译方向相反

EN → ZH: Translate into Simplified Chinese: Our support team will review your request within two business days.

ZH → EN: 翻译成英文：我们的支持团队将在两个工作日内审核你的请求。

检查两段含义接近的文本，在方向相反时 Input 与 Output 用量是否不同。

测试 B：术语表开销

Translate into Simplified Chinese. Preserve these terms exactly: TokenTest, API, JSON, SLA, P95, TTFT.

The evaluation report compares protocol integrity, token usage, latency, and output stability.

分别测试“包含保留词指令”和“不包含保留词指令”的版本，对比 Input Token 变化与译文一致性。

测试 C：结构化输出开销

Translate into English and return valid JSON with keys translation, terminology_warnings, and needs_review.

原文：如果模型返回的总 Token 数与输入和输出之和不一致，请标记为需要复核。

检查 Total Token、JSON 有效性，以及输出上限能否容纳所有必填字段。

常见错误

上线前检查清单

在扩大中英文翻译规模前，请确认已经：

翻译 Token 统计的目标，不是找到一个永久有效的“中英文换算比例”，而是建立可重复的测量流程：调用前统计，调用后验证，再用真实工作流的数据规划下一批预算。

常见问题

中文一定比英文消耗更多 Token 吗？

不一定。结果取决于具体措辞、模型、Tokenizer、请求结构与翻译方向。应该用目标模型测试语义接近的真实样本。

每次请求都要统计术语表吗？

只要术语表被发送，就应该计入。如果供应商支持 Prompt Caching，还要检查是否真的返回缓存 Token 证据，以及缓存是否符合成本预期。

翻译应该预留多少 Output Token？

根据每个翻译方向和内容类型的真实 Output Token 分位数设置。如果要求返回 JSON 字段或解释，还要为这些结构预留空间，并持续监控截断率。

TokenTest 可以替代供应商的官方 Tokenizer 吗？

不可以。预统计应优先使用供应商提供的官方方法。TokenTest 用于评估真实模型端点，并检查返回的 Token 用量与相关行为是否合理。

什么变化会触发重新建立 Token 基线？

更换模型、Tokenizer、Prompt 模板、术语表、工具、输出 Schema、分段规则或翻译质检流程后，都应该重新统计。

参考资料