课程0基础Agent开发课 / LLM基础 / LLM工作原理-Token与Transformer
— 11 min read

LLM工作原理-Token与Transformer

> **本文适合谁**

LLM 工作原理:Token 与 Transformer

本文适合谁

想搞清楚"LLM 到底在做什么"的开发者。不需要数学背景,不需要会写神经网络。读完这篇,你会明白为什么换几个词效果就变了,为什么模型会"数错字母",为什么上下文窗口是个硬约束。


1.1 为什么要理解 Token 和 Transformer

很多开发者直接跳到调 API,遇到这些问题时完全摸不着头脑:

  • 让 ChatGPT 数 "strawberry" 里有几个字母 r,它数错了——为什么?
  • 中文版 API 比英文版贵——为什么?
  • 上下文窗口 128K,感觉够用了,但模型"忘记"了很久以前说的话——为什么?
  • 同一段 Prompt,每次输出略有不同——为什么?

这四个"为什么",答案都在 Token 和 Transformer 里。


原始文本

分词器
Tokenizer

Token 序列

Token Embedding
向量化表示

Transformer 层
多层自注意力

输出概率分布
下一个 Token 概率

生成文本
逐 Token 解码

LLM 完整工作流程——从原始文本到生成输出的六个关键步骤

1.2 Token:不是字符,不是单词

1.2.1 先建立直觉:Token 是什么

想象你在读一篇文章,你不是一个字母一个字母地读,也不是一个句子一个句子地读,而是以"词块"为单位——常见的词整体处理,生僻的词拆开处理。

这就是 Token 的工作方式。

LLM 处理语言的基本单位不是字符,也不是单词,而是 Token。Token 是分词器(Tokenizer)把文本切割之后得到的片段:

  • 常见英文单词通常是 1 个 token("cat", "the", "is")
  • 复杂英文单词会被切成多个片段("unbelievable" → "un" + "believ" + "able")
  • 中文汉字通常对应 1-2 个 token(常用汉字为 1 个,生僻字可达 3 个)
  • 数字、标点都有自己的 token

1.2.2 为什么不用字符也不用单词

用字符的问题:每个字符携带的信息太少。"Apple"变成 [A, p, p, l, e] 五个输入,模型需要从这五个独立字符中推断出这是一个有意义的词,学习效率极低。而且序列长度急剧增大,自注意力的计算复杂度是 O(n²),序列越长计算量越大。

用单词的问题:词汇表会无限膨胀。英语有数十万个单词,加上各种变形、新词、专有名词,词汇表可以无限大。更严重的是 OOV(Out of Vocabulary)问题:遇到词汇表里没有的词,模型就完全不认识了。

Token 是折中方案:比字符大,比单词小。常见词保持完整,罕见词拆成有意义的片段。词汇表大小可控(GPT-4 约 10 万个 token),同时对未知词也有处理能力——把它拆成已知子词片段。

1.2.3 Token 的直接影响:为什么模型数不对字母

"strawberry" 这个词,在 GPT-4 的分词器中被切成 "st"、"raw"、"berry" 三个 token。模型看到的是三个编号,不是十个字母。让它数里面有几个 r,等于让你看三张碎片化的纸片,然后数原文有几个特定字母——确实会数错,这是 Token 机制的必然结果,不是 Bug。

1.2.4 Token 的直接影响:为什么中文 API 更贵

同样传达一段意思,中文需要约 1.5-2 个 token 对应一个汉字,英文约 0.75 个 token 对应一个单词。同样的信息量,中文消耗的 token 更多,成本相应更高。

python
import tiktoken

enc = tiktoken.get_encoding("cl100k_base")  # GPT-4 使用的编码

# 英文的 token 化
text_en = "The large language model processes tokens, not characters."
tokens_en = enc.encode(text_en)
print(f"英文:{len(text_en)} 字符,{len(tokens_en)} tokens")

# 中文的 token 化
text_zh = "大型语言模型处理的是Token,而不是字符。"
tokens_zh = enc.encode(text_zh)
print(f"中文:{len(text_zh)} 字符,{len(tokens_zh)} tokens")
print(f"中文的 token/字符 比例:{len(tokens_zh)/len(text_zh):.2f}")

# 查看 strawberry 的分词
word = "strawberry"
tokens_word = enc.encode(word)
print(f"\n'{word}' 的 token:{[enc.decode([t]) for t in tokens_word]}")
# 输出:['st', 'raw', 'berry']  ← 模型看到的是这三个片段,不是10个字母

你应该看到类似这样的输出

code
英文:56 字符,11 tokens
中文:16 字符,22 tokens
中文的 token/字符 比例:1.38
'strawberry' 的 token:['st', 'raw', 'berry']

1.3 Transformer:每个 Token 都在"看"其他 Token

1.3.1 为什么需要"注意力":先看问题

在 Transformer 出现之前,词嵌入(Word Embedding)已经能把每个词映射成一个向量。但这个向量是静态的——"苹果"这个词,无论在"我买了一个苹果"还是"苹果公司发布了新产品"里,它的向量表示完全相同。

这显然不够。同一个词在不同上下文中含义不同,模型需要根据上下文动态调整每个 token 的表示。这就是 Transformer 要解决的问题。

根据 AWS 的定义,Transformer 是"将输入序列转换为输出序列的神经网络架构",其自注意力机制"使模型能同时查看序列不同部分,确定哪些部分最重要"。

1.3.2 自注意力:直觉理解

Transformer 的核心机制叫自注意力(Self-Attention)。理解它只需要一个直觉:

在处理每一个 token 的时候,模型会去"看"序列中所有其他 token,判断它们对当前 token 有多重要,然后根据这些重要性加权融合信息。

举个例子。句子"银行倒闭了,我的钱没了。"和"他坐在河岸边,望着银行对岸。"里面都有"银行"两个字,但它们的意思完全不同。Transformer 通过自注意力机制,让"银行"这个 token 去关注周围的词——在第一句中关注"倒闭"和"钱",在第二句中关注"河岸"和"对岸"——从而在内部生成不同的表示。

同一个 token,在不同的上下文里,得到的向量表示是不一样的。这是 Transformer 相比更早的 RNN 的核心优势。

1.3.3 为什么比 RNN 好:两个关键优势

优势一:处理长距离依赖

RNN 处理长句子的方式是信息接力。处理第 20 个词时,第 1 个词的信息要经过 19 次"传递"才能到达,每次传递都有损耗,到了基本稀释殆尽。

自注意力处理第 20 个词时,第 1 个词和第 20 个词是直接交互的,一步到位,没有中间损耗。无论序列多长,任意两个词之间的"距离"都是 1。

优势二:并行计算

RNN 必须按顺序处理,处理第 t 个词之前必须处理完前 t-1 个词,没法并行。自注意力对序列里所有词的计算可以同时进行,利用现代 GPU 的并行能力,训练速度大幅提升。这是 Transformer 时代能训练规模更大的模型的工程基础。

RNN 方式
信息接力传递
1→2→3→...→100
第1个词信息到第100个词已稀释

Transformer 方式
任意两词直接交互
1和100直接对话
无损耗无衰减

1.3.4 上下文窗口的限制从哪来

自注意力要计算序列里每对 token 的相似度。序列长度为 n,就有 n² 对组合,计算量是 O(n²)。

序列长度翻倍,计算量变成四倍。这是标准自注意力的算法复杂度约束

2024年后的进展:Flash Attention 等 IO 感知优化技术通过减少显存读写次数,大幅降低了实际运行时间(并非降低理论复杂度,而是更高效地利用硬件)。这也是为什么现代模型的上下文窗口能扩展到百万 token 级别。但 O(n²) 的计算量增长规律依然成立,只是被工程技术显著缓解了。

这就是为什么 Context Window(上下文窗口)有长度限制。主流模型通常在 128K 到 200K token 之间,具体以各厂商官方文档为准。超出上下文窗口会怎样?信息会被截断,模型看不到被截掉的部分,就好像那部分对话从未发生过——但它可能不会告诉你这一点,而是续写一个"看起来合理"的答案。


1.4 LLM 的本质:续写,不是理解

1.4.1 自回归生成:为什么模型总是"往下接"

理解 LLM 最重要的一个认知是:LLM 的训练目标只有一个——预测下一个 token 是什么

这个简单的预测任务,配合海量数据,产生了令人惊叹的能力。但这个机制有一个直接的推论:

模型生成的每一个 token,都是基于之前所有 token 的概率预测。它不是在"思考",它是在非常精妙地"续写"。

当你问 ChatGPT"北京的首都是哪里",它不是在数据库里查找答案,而是在预测:在"北京的首都是哪里?"这串 token 之后,最可能出现的下一个 token 是什么——然后继续预测下下个,一直到回答结束。

这个机制解释了幻觉(Hallucination)的根源:模型的预测依据是训练数据中的统计规律。当被问到训练数据覆盖不足的问题,模型依然会给出一个"续写"——语言上合理,但事实上可能完全错误。详细分析见第 7 篇《LLM 的幻觉问题》。

1.4.2 多头注意力:同时从多个角度看

实际的 Transformer 并不是只做一次自注意力,而是做多头注意力(Multi-Head Attention)

为什么要多个头?一句话里,一个词可能同时和多种不同类型的信息有关联。以"它喝了水,因为它渴了"为例:

  • "它"和"因为"有因果关系
  • "它"和另一个"它"有指代关系
  • "喝"和"水"有动宾关系

如果只有一个注意力头,它只能同时关注一种关联模式。多头注意力允许每个头独立学习不同类型的关联——有的头专注于指代关系,有的头专注于语法结构,有的头专注于语义相似性。

这也解释了为什么现代 LLM 通常有几十到上百个注意力头——头越多,模型能同时捕捉的关联模式越丰富。


1.5 理解原理,是为了用好工具

作为应用开发者,大概率永远不需要手写一行 Transformer 代码。但理解 token 和 Transformer 的工作方式,会直接影响怎么写 Prompt:

  • 知道 token 是什么,就明白为什么把复杂任务拆成小步骤比一次性问更有效——每次预测都在积累上下文。
  • 知道模型是"续写"不是"理解",就会在 Prompt 里给它更多引导,而不是假设它能猜到意图。
  • 知道多头注意力捕捉多种关联,就理解为什么提供丰富的上下文信息能显著提升回答质量。
  • 知道上下文窗口的限制,就知道在设计有状态的对话系统时,要主动管理上下文,不能什么都往里塞。
  • 知道幻觉的本质,就知道什么时候必须加上事实来源,什么时候需要让模型做二次验证。

1.6 多模态:不只是文字的 Token

2024 年起,主流 LLM 都支持了多模态输入——不只是文字,还有图片、音频。

1.6.1 图像是怎么变成 Token 的

文字变成 Token 很直观(分词),但图片怎么处理?

Vision Transformer(ViT)的思路:把图片切成小块(patch),每个 patch 当作一个"图像 Token"。

code
原始图片(256×256 像素)
    ↓ 切成 16×16 的小块
256 个图像 patch
    ↓ 每个 patch 通过线性投影变成向量
256 个图像 Token 向量
    ↓ 和文字 Token 一起输入 Transformer
LLM 统一处理文字 + 图像

类比:就像把一张照片切成 16×16 的拼图,每块拼图变成一个"词",LLM 读"图像词"和"文字词"的方式是一样的。

1.6.2 多模态的实际成本

输入类型 Token 数量估算
1 个英文单词 ≈ 1-2 token
1 个中文字 ≈ 1-2 token
一张低分辨率图片(512×512) ≈ 170-340 token
一张高分辨率图片(1024×1024) ≈ 765-1530 token

截至 2026 年 3 月,各模型差异较大,以官方文档为准。


1.7 小结

概念 核心直觉 对开发者的意义
Token 语言的碎片,比词小比字符大 API 计费单位;解释"数不清字母"等奇怪行为
自注意力 每个词直接看所有其他词,加权融合 理解为什么模型能处理长距离依赖
多头注意力 同时从多个角度看同一句话 解释为什么丰富上下文能提升质量
上下文窗口 O(n²) 的算法复杂度约束(Flash Attention 等技术已大幅缓解) 长对话和长文档处理的边界
自回归生成 模型在续写,不是在查数据库 理解幻觉的根源;解释为什么 Prompt 质量重要

Token 和 Transformer,是理解 LLM 一切行为的底层语言。

后续阅读

  • 第 4 篇《Transformer 自注意力机制详解》深入讲解 Q/K/V 的直觉
  • 第 5 篇《分词器详解》讲 BPE 算法和 token 计数实践
  • 第 7 篇《LLM 的幻觉问题》详细分析幻觉的成因、类型和缓解策略
本页目录