token是什么？为什么大模型会有上下文长度的限制

聊起大语言模型，经常会碰到两个核心概念：Token 和上下文长度。你要是搞不懂这俩，很多技术细节就理不清。所以，咱们今天就把这事儿掰开揉碎了讲透。

先说 Token。这是大模型处理文本时的最小单位。模型并不会直接去“读”我们的汉字或英文字母，它有自己的一套颗粒度，这个颗粒就是 Token。所有的理解和生成，都是基于 Token 进行的。你可以把它想象成模型“阅读”文本时的“碎片”，但这些碎片不一定是我们日常理解的一个字或一个词。

一、Token 的三个关键点

1.1 分词过程

当你输入一句话时，模型不是直接拿过来就处理，而是先通过一个叫 Tokenizer（分词器）的组件，把文本切成一个个的 Token。这玩意儿是个前置工具，就像个文本切割器，它有固定的规则（由训练时的词表决定）。没有它，模型就看不懂原始的文字，必须要先转换成它能识别的 Token 格式。

举个例子，“我喜欢猫”可能会被切成 [“我”, “喜欢”, “猫”] 三个 token。而英文的 "unbelievable"，则可能被拆成 ["un", "believ", "able"]。这里体现了中英文分词的一个典型差异，背后是行业通用的“子词分词”思路：

• 中文
  ：“喜欢”这类高频词，分词器倾向于把它保留成一个 Token，减少序列长度；只有遇到很生僻的词，才会拆成单个字。

• 英文
  ：拆前缀、词根、后缀，是因为英语单词实在太多了，如果每个单词都做一个 Token，词表会爆炸。拆成语义子单元，既能覆盖几乎所有单词，又能控制词表大小，还能让模型学到词根词缀的规律，一举多得。

1.2 向量化

分词只是第一步。模型会把每个 Token 转换成一个高维向量（也就是 embedding），之后的所有计算，比如注意力机制、前馈网络，全是基于这些向量来完成的。这说的是 Token 的“数字化”过程。计算机只认数字，不认文字。每个 Token 会被转换成一串包含几千个数字的数组，这串数组里编码了它的语义、语法、情感等信息。语义相近的词，它们的向量距离就近，比如“猫”和“狗”的相似度就很高，而“猫”和“桌子”则隔着十万八千里。

1.3 计费单位

这也是为什么大模型 API 会按 Token 数量来收费。你想想，每一个 Token 都要走一遍完整的向量计算，Token 越多，GPU 干的活儿就越多，硬件成本自然就上去了。计费时会同时算你输入给模型的 Token（提问）和模型生成的 Token（回复），两者加起来就是总消耗。

二、上下文长度限制是什么？

上下文长度限制，就是模型单次能处理的 Token 数量上限，比如 4K、128K、200K。这里的 K 是计算机单位，1K = 1024。超过这个上限的内容，模型就“看不见、记不住”了。那为什么会有这个限制？原因主要有这么几个，每一条都是硬伤。

2.1 注意力机制的“平方灾难”

Transformer 架构的核心是自注意力机制，它的计算复杂度跟序列长度是二次方关系，用公式表示就是 O(n²)。这意味着，如果上下文从 4K 扩展到 128K，计算量不是增加 32 倍，而是增加将近 1000 倍！这直接导致推理速度急剧下降，甚至显存爆炸。

• 推理
  ：就是我们日常跟 AI 对话、让它生成内容的过程。计算量暴涨，GPU 算不过来，响应就慢如蜗牛。

• 显存爆炸
  ：大量中间数据会撑爆 GPU 显存，导致程序直接崩溃，俗称“显存炸了”。

2.2 显存（GPU Memory）的物理瓶颈

注意力机制需要存储一个“注意力矩阵”，用来记录序列中每个 Token 与其他所有 Token 的关系。序列越长，这个矩阵就越大，占用的显存也就越恐怖。128K 序列长度的注意力矩阵大约有 131072 × 131072 ≈ 170 亿个数值，用常用的半精度格式存储一个要占 2 字节。算下来，仅这个矩阵就需要约 32GB 显存。再加上模型参数和其他数据，普通消费级 GPU 根本招架不住。这是硬件层面的物理天花板。

2.3 长距离依赖的衰减问题

就算技术能处理长文本，模型在长序列中的注意力分数也会变得非常稀疏和“稀释”。好比一杯水倒进越来越大的池子里，浓度会越来越低。相隔很远的两个 Token，它们之间的关联权重会变得极低，模型相当于“没注意到”二者有关系，长距离的逻辑推理效果自然就下来了。

2.4 训练难度与成本

训练超长上下文模型比推理更费资源。训练时要存大量的梯度数据来更新参数，显存压力是推理的好几倍。而且，序列越长，梯度传递的路径就越长，很容易出现“梯度消失”或“梯度爆炸”，模型很难学好长序列的规律。

面对这些限制，业界目前的主流优化方案主要有两类：

1. 位置编码优化
   ：因为自注意力本身不识别顺序（“我打他”和“他打我”的 Token 一样），所以需要给每个 Token 加上位置信息。像 RoPE、ALiBi 这类新的位置编码，比老方法能更好地支持超长上下文。

2. 稀疏注意力
   ：放弃“每个 Token 和所有 Token 算注意力”的全量模式，改成只和部分 Token 计算，把复杂度从 O(n²) 降到 O(n)。比如滑动窗口注意力（Sliding Window Attention），每个 Token 只跟它前后固定窗口内的 Token 算关联，能大幅节省计算和显存。

不断探索，共勉。