LLM如何处理文本：我的i18n系统教会我的Token经济学

当我为网站构建i18n翻译系统时，我发现将一篇1500词的英文博客翻译成韩语所消耗的token是英文原文的2.8倍。相同的语义内容，相同的含义，却带来2.8倍的API成本。日语为2.4倍，繁体中文为2.1倍，西班牙语为1.15倍。多语言内容的token经济学让我措手不及，因为我之前并不了解分词器的工作原理。¹

TL;DR

分词将人类可读的文本转换为语言模型处理的数字token。在将27篇博客翻译成6种语言后，我获得了真实的成本数据：非拉丁文字每个语义单元消耗的token是英语的2-3倍。下方的交互式可视化工具让您可以粘贴任意语言的文本并查看token分解情况。理解分词帮助我准确预算翻译流水线的成本，优化提示词以降低35%的费用，并调试了一个格式问题——韩语翻译丢失了Markdown结构，因为分词器将脚注标记拆分到了不同的token边界上。

我的i18n Token成本数据

我使用Claude将27篇博客翻译成了6种语言。翻译质量要求使用Opus级别的模型（绝不使用更便宜的模型——这是我在Haiku产出读起来像机器翻译的译文后学到的教训）。各语言的token消耗令我惊讶：

拉丁文字语言（西班牙语、德语、法语）与英语的差距在20%以内。CJK和谚文语言则跃升至2-3倍。这一成本差异在27篇文章 × 6种语言 = 162次翻译中不断累积。²

差距存在的原因

大多数分词器（BPE，Claude和GPT-4均采用此方法）主要基于英语文本训练。英语词汇拥有优化的token表示，因为训练数据中英语的占比远超其他任何语言。常见英语单词（”the”、”and”、”is”）映射为单个token。韩语音节块、日语汉字和中文字符通常被拆分为2-3个字节级token，因为分词器在训练过程中遇到它们的频率较低。³

这种效应是系统性的，而非随机的。每次韩语翻译的成本大约是英语等价内容的2.8倍。由于倍率稳定一致，我可以准确地进行预算。

分词Bug

在我第一批韩语翻译中，翻译后的文章丢失了所有Markdown格式：脚注引用（[^1]）消失了，代码块丢失了语言标签，标题标记（##）被合并到正文中。

诊断花了一个小时。根本原因：我的翻译提示词只写了”将这篇博客翻译成韩语”，而没有指定格式保留要求。在韩语上下文中，分词器对Markdown语法的token边界拆分方式与英语上下文不同。模型将[^1]视为可翻译内容，而非结构性标记。

修复方法：我在翻译提示词中添加了明确的约束条件：

Preserve all markdown formatting exactly:
- Keep [^N] footnote references unchanged
- Keep ``` code fences with language tags unchanged
- Keep ## heading markers unchanged
- Keep **bold** and *italic* markers unchanged

每条约束消除了一种故障模式。约束列表最终比翻译指令本身还长——这是我在OODA提示词工程框架中描述的一种模式。⁴

什么是Token

从字符到Token

处理文本的朴素方法是将每个字符作为一个输入单元。”Hello world”变成11个字符。字符级处理捕获了每一个细节，但会产生极长的序列：一篇1000词的文档大约变成5000个字符。⁵

词级处理减少了序列长度，但无法处理未知词汇。一个包含50,000个条目的词级词汇表无法处理”unfathomability”，除非该词在训练中精确出现过。

子词分词找到了一个折中方案。常见词汇（”the”、”and”）保持为单个token。不常见的词汇被拆分为子词片段。”Unfathomability”被拆分为[“un”, “fath”, “om”, “ability”]，其中每个片段出现的频率足够高，拥有经过训练的表示。

字节对编码（BPE）

BPE被Claude和GPT-4采用，它从单个字节开始，迭代地合并最频繁的相邻对：⁶

1. 从单个字符开始：[l, o, w, e, r]
2. 最频繁的对：(l, o) → 合并为[lo, w, e, r]
3. 最频繁的对：(e, r) → 合并为[lo, w, er]
4. 最频繁的对：(lo, w) → 合并为[low, er]
5. 最频繁的对：(low, er) → 合并为[lower]

最终词汇表包含所有原始字节加上每个合并后的token，通常有50,000-100,000个条目。英语词汇在合并token中占主导地位，因为英语在训练数据中占据主导。

我如何优化提示词

在发现token成本差距后，我优化了翻译流水线，将成本降低了35%：

优化1：按语系分批处理

拉丁文字语言（西班牙语、法语、德语）具有结构相似性。当源文章足够短，能在上下文窗口中容纳三种输出时，我将翻译提示词批量化，在单次API调用中产出所有三种语言。共享上下文（英语原文）只需支付一次费用，而不是三次。⁷

优化2：约束去重

我原始的翻译提示词为每种语言重复了约束条件。优化后的版本只定义一次约束，然后应用于所有输出：

# Constraints (apply to ALL translations below):
- Preserve markdown structure, footnotes, code blocks
- Keep proper nouns in English
- Adapt idioms, don't transliterate

# Translate the following post into: Spanish, French, German

约束部分只消耗一次token。替代方案（每种语言重复约束）则消耗3倍。

优化3：精简指令

我原始的提示词使用了340个token的指令。优化后：180个token。47%的缩减在162次翻译中不断累积。

CJK语言从提示词优化中获益较少，因为输出token（翻译本身）主导了成本。无论指令多么精简，输出在token层面本质上就更长。⁸

实际应用

成本估算

对于英文文本的粗略估算：1个token大约等于0.75个单词，或大约4个字符。一篇1000词的文档大约消耗1,333个token。对于非英语内容，请应用上表中的语言倍率。⁹

代码分词

代码的分词方式与散文不同。常见关键字（def、return、if）映射为单个token。变量名根据出现频率进行拆分：

# "def calculate_total(items):" splits approximately as:
# ["def", " calculate", "_total", "(", "items", "):", ]

一致的命名规范可以减少token数量。我的Hook基础设施使用verb-noun.sh命名约定（git-safety-guardian、recursion-guard、blog-quality-gate）。一致的模式帮助分词器高效地预测和合并常见子词。

调试意外行为

当模型产生意外输出时，分词可以解释原因。我的韩语格式Bug发生的原因是分词器在韩语上下文中对[^1]的拆分方式与英语不同。理解拆分模式直接指向了修复方案（显式的格式保留约束）。

核心要点

面向使用LLM API的工程师： - 在承诺多语言支持之前，测量每种语言的token成本；CJK语言每个语义单元的成本是英语的2-3倍 - 优化提示词指令（精简措辞、去重约束），可在高频翻译流水线上实现30-50%的成本降低 - 在生产部署前测试领域特定术语和Markdown语法的分词效果；意外的拆分会导致格式Bug

面向预算AI功能的产品经理： - 非英语语言支持的每次API调用成本是英语的1.5-3倍；使用语言倍率来预算多语言AI功能，而非按语言统一估算 - 上下文窗口限制对CJK语言的影响更大；200K token的窗口容纳的韩语内容比英语少40%

参考文献