做 NLP 相关的工作尤其是跟大模型打交道之后你会发现一个绕不开的基础设施Embedding。很多人最开始接触它时只是把model.get_input_embeddings()当成一个查表操作——输入 Token ID返回一个向量完事。至于这个向量为什么是 2560 维而不是 768 维或者 4096 维里面存了什么信息怎么被训练出来的训练和推理时它又有什么不一样的行为这些问题如果不搞清楚后面排查问题、调参、做微调时就会经常踩坑。这篇内容我想从头到尾拆一遍一个离散的 Token ID到底经过什么过程变成了一个 2560 维的稠密向量。我会从查找表的本质讲起讲到维度为什么是 2560再到语义如何被训练出来然后给出可运行的 PyTorch 代码最后聊一些训练和推理时的工程细节。无论你是刚入门 NLP 的开发者还是已经跑过不少模型、想补底层原理的人这篇都能给你一些新的视角。1. 从 Token ID 到向量一张查找表解决了什么事1.1 离散符号为什么不能直接喂给模型先做个思维实验。你把“猫喜欢吃鱼”这句话送进分词器得到一串 Token ID比如[187, 527, 294, 4201]。如果模型直接拿这四个整数做计算它会怎么做它能发现 187 和 527 之间有什么语义关系吗不能。因为这些整数本身只是编号编号的大小、顺序跟词义毫无关系。527不比526更接近什么4201也不比4200高贵。数字在这里只是“名字”。那能不能用 One-Hot 编码词表如果有 10 万个词每个词就是一个 10 万维的向量其中只有一位是 1其余全是 0。这个方案有两个致命问题第一维度爆炸10 万维的向量无论存储还是计算都太浪费第二任意两个 One-Hot 向量的内积都是 0也就是所有词之间的相似度都是 0模型完全无法利用词与词之间的关联。这不是在解决问题这是在制造问题。所以我们需要一个办法把离散的、无结构的 Token ID映射到一个低维、稠密、带有语义关联的空间里。这个办法就是 Embedding。通俗点说Embedding 就是给词表里的每一个词分配一组浮点数坐标。这些坐标不是随便给的它们的位置关系编码了词的语义。整个 Embedding 技术要回答的核心问题就一个这组浮点数坐标怎么来以及怎么保证它们有意义。1.2 查找表的本质一个可训练的大矩阵在 PyTorch 里nn.Embedding是专门干这件事的模块。它里面其实只有一个大矩阵形状是vocab_size × embedding_dim。比如词表大小是 152064维度是 2560那么这个矩阵的形状就是152064 × 2560有大约 3.9 亿个参数。所谓“查表”就是根据 Token ID 去这个大矩阵里取某一行。ID 是 100就取第 100 行ID 是 30000就取第 30000 行。取出来的这一行就是那个 Token 的 2560 维向量。这个矩阵的行顺序是固定的但在初始化阶段这些行里的数值是从某个分布里随机采样的彼此之间没有任何语义意义。语义是后面通过训练逐步写入的。注意Embedding 矩阵的行号只是“索引”不是“内容”。训练完成后真正有意义的是每一行里那 2560 个浮点数的分布和方向。这个概念很多人搞混他们以为 ID 小就代表“更重要”实际上完全不是。用个生活化的比喻这就像一本巨大的电话簿每个人有一个号码翻到那一页能看到这个人的详细住址坐标。住址坐标不是根据号码大小排列的而是由这个人的社会关系、活动范围决定的。1.3 查表操作和矩阵乘法的等价性你可能听说过一个说法Embedding 查表实际上就是一次矩阵乘法。这句话是对的而且理解它能帮你打通很多概念。假设输入是一个 One-Hot 向量在词表位置上只有一位是 1其余为 0把它乘以 Embedding 矩阵会发生什么由于矩阵乘法里某个值等于左侧向量与矩阵对应列的内积而 One-Hot 向量只有一位是 1所以结果恰好就是矩阵中被选中那一行的内容。也就是说One-Hot 向量 × Embedding矩阵 查表结果。实际工程里没人会真的构造 One-Hot 向量因为太浪费内存和算力但“查表就是取行”这个视角足够直观。我写代码验证过两种做法结果一模一样。后面第 4 部分我会给出具体代码。2. 2560 这个数字从哪来维度设定背后的取舍2.1 先分清三个容易混淆的数字聊维度之前得先把三个数字分清楚词表大小vocab_size决定 Embedding 矩阵有多少行比如 152064、32000、50257 这些。嵌入维度embedding_dim / d_model决定每一行有多少个浮点数比如 768、1024、2048、2560、4096。序列长度seq_len决定一条样本最多包含多少个 Token比如 2048、4096、8192。很多人把词表大小和维度混在一起。其实它们是独立的词表大小是由分词器决定的维度是模型结构设计者拍板定的。2560 属于后者——它是模型架构设计时的一个超参数。2.2 为什么偏偏是 2560而不是别的你可能会想随便定一个数字不就行了吗实际上2560 这个数字背后有几个工程上的合理性第一硬件对齐友好。2560 能被 8 和 128 整除。混合精度训练bfloat16/fp16中数据一般都是 8 的倍数对齐GPU 上的张量核心在执行矩阵乘时对维度为 8 的倍数有优化。在很多分布式并行方案里2560 也可以被切成多个等份方便在多个设备之间均衡分配。第二它是 Transformer 主干的一个合理中间档。模型里Token Embedding 的维度通常跟 Transformer 每一层的隐藏层维度d_model保持一致。选 2560相当于在 2048 和 4096 之间找了个平衡点。2048 维度表达能力在某些任务上不够4096 又让参数量和计算量翻倍2560 是那种“够用又不浪费”的折中。第三和注意力头数的配合。假设模型配置了 20 个注意力头2560 ÷ 20 128也就是每个头的维度是 128。这个 128 是个经典值在性能和表达能力上都有保障。20 个头也方便做多头注意力的并行切分。你会看到很多模型的 head_dim 都是 128这不是巧合。第四参数量预算。152064 × 2560 ≈ 3.89 亿参数在动辄几十亿甚至上百亿参数的模型里这只占很小一部分。但如果换成 4096 维这个表就变成 6.23 亿参数凭空多出 2 亿多参数而收益并不一定显著。我整理了几个常见模型的维度对照方便你感受一下规律模型类型常见 Embedding 维度说明早期 BERT76812 层 Transformer 的小型基础配置稍大规模 BERT / GPT-2102416 层左右的中型配置中大模型常见档204824 层左右性能和成本平衡2560 所在档位256020 个头 × 128 head_dim 的典型产物超大模型常见档4096/512032~40 层的大规模配置注意不同模型家族的选择逻辑不完全一样有些是按“层数 × head_dim”反推的有些是按 GPU 显存带宽拍的。2560 这个值在不少中等规模模型中出现本质上就是硬件对齐和模型容量之间的平衡。2.3 维度不是越大越好这一点必须单独强调。Embedding 维度决定了每个词向量能承载的信息量上限。维度太低比如 128很多细微的语义差异会被挤压在一起模型难以区分维度太高比如 8192参数量爆炸而且训练数据不够时高维空间里的向量会非常稀疏绝大多数维度学到的是噪声。有个直观的类比你描述一个人用“身高、体重、年龄”三个特征只能区分个大概加上“职业、居住城市、爱好、学历”就能更精确但如果给你 8000 个特征其中 7900 个都是无关信息反而会干扰判断。Embedding 维度就是在找这个平衡点。从实际操作角度看2560 维的向量做余弦相似度计算时浮点运算量可观。如果你在一个几万条文本的库上做向量检索每一对都要算 2560 维的内积这个计算量不是你想象中那么便宜的。后面我会讲几个实际的优化手段。3. 查表只是开始向量里的语义是被谁“教”出来的3.1 从随机初始化说起Embedding 矩阵的初始值通常是随机生成的比如从均值为 0、标准差为 0.02 的正态分布里采样。这时候词表里所有向量都“挤”在原点附近的一个小区域内彼此方向随机。此时此刻如果你去计算“猫”这个词的向量和“狗”的向量之间的余弦相似度你会得到一个接近于 0 的随机值没有任何语义意义。也就是说初始化状态下这张表是一张空白画布所有词都是“孤儿”。真正开始改变这一切的是训练信号。3.2 Next Token Prediction 如何推动语义聚类现代大模型主流的训练目标就是 Next Token Prediction给定前文预测下一个 Token 是什么。当模型在训练时它需要让正确 Token 对应位置的输出概率尽量高。这个过程中反向传播的梯度会沿着计算图回传到 Embedding 层。简单推演一下假设模型看到前文“我今天中午吃了”需要预测“饭”。那么“饭”对应的 Embedding 向量会朝着让后续层更容易输出“饭”的方向移动同时前文所有 Token 的 Embedding——包括“我”“今天”“中午”“吃”“了”——都会因为这次预测而被微调调整的幅度取决于它们在这次预测中的贡献大小。经过海量语料反复训练之后一个很有趣的现象就会出现语义相近的词它们的向量在空间中彼此靠近“国王”和“王后”之间的向量偏移方向跟“男人”和“女人”之间的偏移方向高度接近。这就是所谓的语义线性结构。你可以把训练过程想象成在一个大球场上所有词起初随机散布。每次预测成功或失败都会把相关的词向正确的位置推一把。日积月累运动员词们自动按照位置语义形成了队形。这个队形不是任何人规定出来的是数据分布的自然投影。3.3 词向量的经典性质方向即语义词向量最著名的性质之一就是“类比”能力king - man woman ≈ queen。这句话的意思是在向量空间里“国王”向量减去“男人”向量再加上“女人”向量结果会很接近“王后”向量。用 2560 维的视角看这等价于说这 2560 个维度里存在一个“性别”方向向量。从“国王”到“王后”的移动和从“男人”到“女人”的移动方向几乎一致。这个方向不是某个单独维度对应的而是一个跨越多个维度的组合方向。我在实践中验证过类似的效应前提是训练语料足够大、词频足够高。低词频词由于样本太少向量往往不稳定线性关系会破碎。这也是为什么实际操作中对于低频词你最好不要依赖它的 Embedding 做细微的语义推断。一个容易误解的点Embedding 中存放的语义是“统计共现”的结果不是人类定义的规则。它就是数据里看到的模式模型没有“理解”任何概念。所以如果你拿一个在代码上训练的模型去查“猫”的向量它跟“狗”可能并不近——因为语料里它们很少一起出现。3.4 位置信息怎么处理到这里你可能注意到一个问题如果只靠 Token Embedding模型只知道“这个词是什么”不知道“这个词在句子里的位置”。所以 Transformer 架构还需要加入位置编码。比较新的模型比如 LLaMA 系列用的是 RoPE旋转位置编码它不把位置信息加到 Embedding 向量里而是通过旋转矩阵作用在 Query 和 Key 上让模型隐式感知位置。也就是说RoPE 不会改变 Embedding 表本身的内容。如果你在代码里查看model.get_input_embeddings().weight你看到的只是内容信息位置信息需要去 attention 运算里找。这也是很多人第一次检查 Embedding 权重时感到困惑的地方——明明输入了位置Weight 里却看不到位置的影响。这是正常的因为位置信息被编码在计算过程里了。4. 代码实操完整走一遍从 Token ID 到 2560 维向量的链路4.1 建一个最小可运行的模型下面是一段最小化的 PyTorch 代码直接演示Token ID - 2560 维向量的全过程。我用的词表大小是 152064只为了贴近真实模型的规模你可以随意修改。import torch import torch.nn as nn vocab_size 152064 embedding_dim 2560 seq_len 8 batch_size 2 # 定义 Embedding 层 embedding_layer nn.Embedding( num_embeddingsvocab_size, embedding_dimembedding_dim, padding_idx0, # 通常把 0 作为 pad token ) # 造一批 Token ID形状 (batch_size, seq_len) token_ids torch.randint(1, vocab_size, (batch_size, seq_len)) print(token_ids.shape) # torch.Size([2, 8]) # 查表得到向量 embedded embedding_layer(token_ids) print(embedded.shape) # torch.Size([2, 8, 2560])核心结果就一行embedded的形状是(2, 8, 2560)含义是2 条样本每条 8 个 Token每个 Token 被表示成 2560 个浮点数。这个操作没有经过任何线性层计算就只是“取行”。Embedding 层目前只是一张矩阵不涉及卷积、不涉及非线性。4.2 验证“查表等于乘矩阵”前面我说过 One-Hot 乘 Embedding 矩阵等价于查表用代码验证一下。这个验证也许看起来多此一举但能帮你理解 Embedding 的数学本质。# 手动构造 One-Hot one_hot torch.zeros(vocab_size) one_hot[527] 1.0 # 方法一直接查表 direct embedding_layer(torch.tensor(527)) # 方法二One-Hot 乘 Embedding 矩阵 manual one_hot embedding_layer.weight # 等价于取第 527 行 print(torch.allclose(direct, manual)) # True如果两边不一致通常是因为数据类型或设备不一致float64和float32之间会有细微浮点误差。但在同一精度下结果严格一致。这个等价性有个实际用途有些框架或推理引擎对 Embedding 层的实现不是真正的“查表”而是用一个可选的 One-Hot 稀疏矩阵乘法来替代。两种实现的效率不同但结果一致。4.3 查完之后怎么进入 Transformer得到 Token Embedding 之后下一步一般是“当作 Transformer 第一层的输入”。假设你用的是一个 4 层的简易 Transformer block那么核心代码如下class SimpleTransformerBlock(nn.Module): def __init__(self, d_model2560, n_head20): super().__init__() self.attn nn.MultiheadAttention(d_model, n_head, batch_firstTrue) self.ffn nn.Sequential( nn.Linear(d_model, 4 * d_model), nn.GELU(), nn.Linear(4 * d_model, d_model), ) self.norm1 nn.LayerNorm(d_model) self.norm2 nn.LayerNorm(d_model) def forward(self, x): h self.norm1(x) attn_out, _ self.attn(h, h, h) x x attn_out h2 self.norm2(x) x x self.ffn(h2) return x此时embedded就是x参与 Attention 里的 Q/K/V 映射。你会发现后面的所有计算维度都是 2560其实这就是一串从 Token Embedding 开始一路保持同样宽度的特征流。4.4 实际加载模型时怎么看这层如果你用的是 HuggingFace Transformers加载模型后可以直接检查 Embedding 表from transformers import AutoModel model AutoModel.from_pretrained(some/model-name) emb_layer model.get_input_embeddings() print(emb_layer.weight.shape) # (vocab_size, 2560) # 观察某一行向量 token_embed emb_layer.weight[527] print(token_embed.shape) # (2560,)这个weight就是一张大矩阵。你可以把它存下来用于后续的相似度检索或者做可视化。有个实操经验拿到模型第一件事打印 Embedding 权重的一些统计量比如均值、方差、weight.norm(dim-1)的分布。如果这个分布明显偏离常规比如说方差异常大往往说明这个模型没有充分训练或者 Embedding 层被某种方式污染了。这个习惯帮你提早发现很多模型质量问题。5. 训练与推理中 Embedding 层的真实差异梯度、显存、并行切分5.1 训练时只有被用到的行有梯度Embedding 层有一个非常重要、但很多人会忽略的工程性质在一个 batch 内只有那些被用到的 Token ID 所在的行才会收到梯度。假设你的 batch 里有 2000 个序列每个序列 512 个 Token那么这 2000 × 512 ≈ 100 万个 Token 里去重后可能只有几万到几十万个不同的 Token ID。Embedding 矩阵有 152064 行其中大部分在这一步里根本不会被访问。反向传播时未访问的行的梯度为 0优化器不会更新它们。这个性质对显存和优化器状态影响很大。常规优化器比如 Adam会为每一个参数维护一阶和二阶动量如果你的 Embedding 矩阵是 3.9 亿参数Adam 会额外占用 2 倍的参数内存。好在 PyTorch 提供了torch.optim.SparseAdam它可以只在有梯度的行上更新动量大幅减少显存占用。不过要注意SparseAdam和某些并行策略比如DataParallel配合时会有问题需要谨慎使用。如果你用的是 HuggingFace 的 Trainer 或 DeepSpeed默认情况下 Embedding 参数也会被纳入优化器。全量微调时Embedding 层的参数量往往占总模型参数的 5%~10%但它的更新频率其实很高因为它每一位的出现频次不同低频词对应的行更新极少。这也是为什么低频词向量在微调时容易停留在初始状态附近。5.2 推理时Embedding 层不产生 FLOPs 大头但吃显存推理阶段Embedding 层不做任何矩阵乘法严格说不涉及矩阵乘加运算它只是一次查表操作。这意味着它的计算开销很小FLOPs 几乎可以忽略。但它的显存占用是实打实的152064 × 2560 × 2 字节bf16≈ 780MB。如果你加载一个模型Embedding 表本身可能就占了几百 MB 甚至几个 GB。这一点在多卡推理时尤其明显。很多人以为 Embedding 层不重要但实际上它占比可观。有些模型用 8 卡做张量并行推理时会把 Embedding 矩阵按行切分到不同 GPU 上每张卡只持有部分词表。切分逻辑很简单按词表维度平均切比如 152064 ÷ 8 19008每张卡负责 19008 行。做查表时每张卡只需要查找自己负责的那一段 ID然后做一次 all-gather 汇总。5.3 高效微调时要不要动 Embedding 层这是我在实际项目里踩过不少次坑的问题。先说结论完全参数微调时Embedding 层应该保持可训练。因为你要让模型适应新领域的数据分布Embedding 是“理解新词义”的第一道关口。但是如果你用的是 LoRA 这类参数高效微调方法LoRA 通常不作用于 Embedding 层。原因有两个LoRA 的作用对象通常是线性层而 Embedding 层本质上是一个查找表很难用低秩分解去近似“某一行的调整”。即使做了收益往往也不明显反而增加显存。在实际操作中我用过几种方式冻结 Embedding 层只训练 Transformer 内部的 LoRA 层——对于通用任务够用但领域迁移效果一般。让 Embedding 层可训练叠加 LoRA——效果好一些但要注意设置较小的学习率否则低频词向量容易被噪声带偏。将新领域的特殊 Token 加入词表同时只对新增行的 Embedding 做初始化——通常用已有 Token Embedding 的平均或随机初始化然后一起微调。一个容易被忽略的细节是词表扩充会让 Embedding 矩阵形状变化之前保存的检查点如果不做维度对齐加载时直接报错。我遇到过不止一次因为忘记处理 embedding 层 shape 改变导致模型加载失败的情况。5.4 Embedding 层的“显存黑洞”效应训练超大模型时Embedding 层有时候会成为显存瓶颈原因在于优化器状态太大。以 Adam 为例152064 × 2560 3.9 亿参数每个参数需要 8 字节的浮点数状态一阶二阶动量也就是 3.1GB。对于很多单卡训练场景这已经是相当重的开销了。常用的工程解法使用 Adafactor 优化器它不存储完整的二阶动量对 Embedding 层的内存占用友好得多。很多大模型的预训练用 Adafactor 或类似策略。将 Embedding 层切分到多卡Megatron 的张量并行原生支持。混合精度训练时Embedding 层通常保持在 float32 或 bfloat16但要留意梯度缩放对低频词的影响。6. 拿到这 2560 个数之后相似度、可视化和微调细节6.1 词与词之间到底多“近”用余弦相似度算Embedding 向量的最常见的用途是计算两个词或两个文本之间的语义相似度。因为向量是 2560 维的浮点数直接比较“绝对的差”没有意义通常用余弦相似度import torch import torch.nn.functional as F def cos_sim(vec1, vec2): return F.cosine_similarity(vec1.unsqueeze(0), vec2.unsqueeze(0)).item() emb emb_layer.weight cat_vec emb[187] # 假设“猫”的 ID 是 187 dog_vec emb[527] # 假设“狗”的 ID 是 527 car_vec emb[294] # 假设“汽车”的 ID 是 294 print(猫-狗相似度:, cos_sim(cat_vec, dog_vec)) print(猫-汽车相似度:, cos_sim(cat_vec, car_vec))正常情况下“猫”和“狗”的相似度会明显高于“猫”和“汽车”。但你可能会碰到一种尴尬情况所有词的相似度都非常高甚至大于 0.9。这个现象我遇到过好多次原因通常有两个一是 Embedding 矩阵没有做 L2 归一化而不同词的向量模长差异很大二是训练不充分或者语料极度不平衡导致向量整体偏向某一方向。解决方法是计算前先对向量做归一化norm_cat F.normalize(cat_vec, p2, dim-1) norm_dog F.normalize(dog_vec, p2, dim-1) print(归一化后猫-狗相似度:, norm_cat norm_dog)6.2 2560 维怎么可视化先降维再画图很多时候你想直观看看词向量的聚类效果。2560 维直接画是不可能的必须降维。我用过的稳妥路线是从 Embedding 矩阵里采样一部分高频词比如 3000~5000 个避免全部词挤在一起。先用 PCA 降到 50~100 维去掉噪声维度。再用 t-SNE 或 UMAP 降到 2 维。为什么先 PCA 再 t-SNE因为 t-SNE 直接处理 2560 维时距离计算非常慢而且对噪声敏感。先 PCA 能去掉一部分冗余维度速度更快结果也更稳定。UMAP 在速度和结构保持上通常优于 t-SNE尤其是大数据量时。一个容易踩的坑如果你把整个词表15 万个词全部丢进 t-SNE你会得到一张“中间一堆高频词四周散落低频词”的图。这不是语义结构只是频次分布。所以采样策略很关键高频词和低频词都要有比例相对均衡。6.3 直接用 Embedding 做语义检索的“翻车”经历刚接触 Embedding 时我犯过一个典型错误用预训练模型的 Token Embedding 直接做句子级语义检索。做法是把一个句子里的所有 Token 向量做平均当成句子向量然后跟其他句子向量做余弦相似度排序。结果是什么排序出来的结果非常糟糕几乎都偏向“高频词、停用词”。比如查询“我想买一台笔记本电脑”检索结果里全是“我”“的”“了”这类词。原因在于Token Embedding 是以词为粒度训练的它捕捉的是词共现信息而不是句子级别的语义。更重要的是这类 Embedding 矩阵存在严重的各向异性anisotropy所有向量并非均匀分布在空间中而是挤在一个狭窄的锥形区域内。这导致单纯用余弦相似度去比较高频词会主导相似度计算。如果你真要拿 Embedding 做语义检索有几个方案使用专门训练过的句子级 Embedding 模型比如基于对比学习训练的模型它们经过后处理各向异性被显著修正。如果你只能使用现有 Token Embedding试试做 whiten白化处理先计算所有向量的均值向量 μ 和协方差矩阵 Σ然后做线性变换x Σ^{-1/2} (x - μ)。白化之后余弦相似度的分布会正常很多。做对比学习微调让句子向量在空间中的各向异性降低。这条路我走通过效果提升很明显。具体的 whiten 操作可以用 scikit-learn 的StandardScaler或者自己用 PCA 做。6.4 进一步压缩2560 维变短、变量化2560 维向量在存储和检索时开销不小。工程实践中常用的压缩路线降维直接训练一个小的线性层把 2560 维压到 256 维或 128 维有些检索系统如基于双塔模型输出的向量维度只有 128~768。量化把 float32 的向量量化成 int8维度不变显存占用变为原来的 1/4。对精度要求不极高的场景YoC 或类似量化方案可以减少 80% 左右的内存开销。二进制哈希把 2560 维转成 256 位二进制哈希比如用 SimHash 或学习式哈希。仅保留相似度排序能力不保留精确的向量数值。我的建议是尽量不要在 Embedding 层直接暴力降维到 64 维以下因为这会显著损失语义细节。如果确实需要极低维最好用学习式降维方法而不是简单的 PCA。最后说说我的实际体会Embedding 层是一个模型中最容易被忽略、但信息密度最高的一部分。你说它只是“查表”没错但这张表承载了模型对语言的基本认知——每一个词、每一个 Token分布在这个 2560 维空间里它们的相对位置就是模型“看到”的世界结构。很多模型调试的疑难问题根源都藏在 Embedding 的分布里。我的个人习惯是拿到一个新模型之后先不看它的 Transformer 有多深、头有多少而是先看一眼 Embedding 权重矩阵的分布——统计均值、方差、行方向的偏心率。这比看一堆训练曲线更能快速判断模型是否健康。另外你如果之后要基于这个 Embedding 做下游任务别跳过“清洗和压缩”这一步。直接拿 2560 维原始向量做检索效果往往不具备竞争力稍微做一些归一化、白化、降维检索质量的提升会非常明显。这些操作单独看都不难但组合在一起就是普通开发者和资深工程师之间经验差距的具体体现。
