大模型词表扩展会显著增加显存占用，但具体增量取决于嵌入层维度、词表新增规模和批量大小，多数情况下需要额外预留数GB至数十GB显存。
大模型词表扩展显存占用怎么算？先看这几个关键变量
词表扩展不是简单加几个token，它牵扯到模型最前端的嵌入层和最后的输出头，这两个位置的参数数量直接由词表大小决定,所以显存压力往往从这里开始。
业内专家指出，嵌入层参数量等于词表大小乘以隐藏层维度，这个公式决定了基础显存增量，举个例子，一个隐藏层维度为4096的模型，词表从32K扩展到64K，新增的3.2万token会带来大约3亿个新增参数（按FP16存储就是约260MB显存），如果你的模型是7B甚至更大的规模,这个数字还会因为优化器状态和梯度被进一步放大。
训练场景下的显存增量为啥比推理更大
训练时，显存不仅存放参数本身，还要存放梯度、优化器状态（如Adam的动量项）和中间激活值，同样扩展1万个token，训练时额外的显存开销可能是推理时的三到四倍，如果使用混合精度训练，FP16参数加上FP32的优化器副本，每新增一个参数就要吃约12字节显存，一批实验中，词表从30K扩到50K，训练显存峰值上涨了差不多15%到20%,这个数字会随着批次大小和序列长度进一步上浮。
推理时的显存变化要分两段看
推理阶段，显存消耗主要分两块：驻留的模型权重和动态生成的KV缓存，词表扩展对前者的影响是确定的，对后者的影响却是隐藏的，因为词表变大后，模型在生成每个token时需要对整个词表做概率分布计算，输出层的矩阵乘法计算量增大，但KV缓存本身却不直接受词表大小影响，所以实际推理时，显存增量主要来自输出层的权重，以及为了保持相同吞吐量而可能被迫换上的更大batch size。
词表扩展后推理显存不够怎么办？实操优化路径
如果你的模型已经扩展了词表，但推理时总报显存不足,下面几条路可以依次尝试：
- 只用新增词表中的高频词，砍掉用不到的生僻token,从源头缩减词表规模。
- 冻结嵌入层并转换为稀疏存储，只对真实使用到的token分配显存,这在长尾场景下能省出较大空间。
- 降低输出层的计算精度，把FP32的输出头改成FP16或BF16，显存占用直接减半,精度损失在多数任务中可忽略。
- 使用显存卸载工具
，把不常用的嵌入行临时挪到CPU内存，需要时再换回GPU,这会把部分显存压力转移到内存带宽上。
词表扩展对训练显存的影响：从优化器到激活值
训练状态下，词表扩展的影响会沿着反向传播链路扩散，很多人只算了参数增加,却忘了优化器状态才是真正的大头。
以Adam优化器为例，每个参数需要存储两个动量变量，如果主权重用FP16保存，梯度用FP16，动量变量用FP32，那么单个参数的显存开销接近12字节，你的词表新增了5万个token，隐藏层维度是5120，那就是新增56亿个参数，光优化器状态就要吃掉约3GB显存,这是训练场景下最容易被低估的部分。
激活值显存：序列长度和batch size的放大器
词表扩展不直接增加激活值大小，但它会改变模型的输出维度。注意力层之后的线性层会将隐藏状态映射到词表空间，这一步产生的中间激活矩阵大小是“序列长度 × 词表大小”，如果序列长度是2048，词表从32K扩到64K，这层激活值的内存占用就会翻倍，行业共识认为，在长序列训练任务中，输出层激活值占整个激活内存的比例可能达到两到三成,这还没算上反向传播时需要的保存副本。
所以训练时想控制显存，不能只看词表本身，要同时关注序列长度、batch size和梯度检查点的设置。
大模型词表扩展训练显存对比：三种常见方案的取舍
| 方案 | 显存增量 | 训练速度 | 适用场景 |
|---|---|---|---|
| 全量扩展并训练所有参数 | 最大（参数+优化器+激活全量翻倍） | 慢 | 新领域数据量大，需要精确适配 |
| 冻结原有嵌入层，只训练新增token | 中等（新增参数仍需优化器状态） | 中 | 已有词表质量好，只需补充增量词汇 |
| 用低秩适配器（LoRA）调整输出层 | 较小（只多出少量低秩矩阵） | 快 | 扩展规模不大，且对输出分布要求不高 |
从实际效果看，训练所有参数适合语言风格差异大的场景，比如从英文扩展到中文；冻结旧嵌入层适合在原有语言上新增术语，比如给通用模型添加医疗或法律词表；低秩适配则适合快速验证,但可能因表达能力受限导致新增token利用率不高。
词表扩展时的显存优化策略：量化、稀疏化与内存复用
面对显存压力，有人选择硬扛，有人选择优化，优化的核心思路很朴素：让显存里的数据更“值钱”，或者让重复的数据只存一份。
量化压缩：把FP32变成INT8，显存直接砍半
输出层和嵌入层是量化最友好的部分，它们对精度不太敏感，因为经过softmax之后，分数差异往往拉得很大，实际操作中，你可以用torch.quantization对嵌入矩阵做动态量化，把FP16权重转成INT8，无损地把显存占用减半，如果还想更激进，可以做4比特量化，但需要配合校准数据集,避免个别token的表示被严重破坏。
稀疏化存储：只保留活跃token的嵌入行
现实中，一个扩展后的词表有数万行，但每批数据真正用到的token可能只有几千个，利用这个特性，可以把嵌入层拆成“密集部分”和“稀疏部分”，频繁出现的token放在显存里，长尾token放在CPU内存甚至磁盘上，按需加载，这种方式尤其适合处理“词表扩展后推理显存不够”的场景，实现上可以通过torch.nn.EmbeddingBag或自定义索引逻辑完成。
内存复用：减少中间张量拷贝
模型前向传播时，输出层的计算会产生一个形状为“batch × seq_len × vocab_size”的临时张量，这个张量经常被不必要地保存下来，正确做法是在损失函数内部直接完成logits和标签的比对，用F.cross_entropy的ignore_index参数，避免显式构造完整的logits矩阵，一个batch大小为8、序列长度为512、词表为50K的模型，这一改就能省下2GB以上显存。
词表扩展与显存规划：从模型设计到部署预算
如果你正打算做词表扩展，先别急着写代码，把显存预算提前算清楚,能避免后面反复返工。
推理场景下的显存规划公式
部署推理时，显存需求可以粗算为：模型权重（全精度或半精度）+ 词表新增权重 + KV缓存 + 运行开销，前两项固定，KV缓存取决于并发数和生成长度，运行开销留出10%到20%的余量即可，比如一个7B模型，原始FP16权重约14GB，词表扩展增重0.5GB，KV缓存按4GB算，那么单卡至少需要20GB以上显存才能稳定运行。
训练场景下的显存规划公式
训练时公式更复杂：参数显存 + 梯度显存 + 优化器状态显存 + 激活值显存，前三个大约等于参数量的12倍字节数
（混合精度训练），激活值需要实测或通过torch.cuda.max_memory_allocated来测量，经验做法是先把batch size设为1跑一次，记录峰值,再线性估算更大batch的消耗。
百度大模型词表扩展显存优化常用工具
- HuggingFace的
transformers库：支持tie_word_embeddings选项，把嵌入层和输出层绑定，共享同一份权重,直接省下约一半显存。 bitsandbytes库：提供NF4和FP8量化包,一行代码将嵌入层转成量化格式。- DeepSpeed的ZeRO-Offload：训练时把优化器状态和梯度卸载到CPU,扩展后的词表参数不会全部驻留显存。
- FlashAttention：虽然不直接作用于词表，但能减少激活值占用,间接腾出显存给更大的输出层。
词表扩展的显存代价值得吗？先看收益再做决定
扩展词表并非总是划算，如果你的下游任务主要是生成代码或处理数字，标准词表已经够用，强行扩词表只会白白增加显存压力，相反，如果目标语料中Out-of-Vocabulary比例较高，比如中文口语、专业医学术语、多语言代码注释，扩展词表带来的收益会远超显存成本，判断标准很简单：统计一下目标语料的未登录词占比，如果超过5%，就值得扩展；低于2%,则不建议动。
最后回到核心问题：大模型词表扩展对显存的影响是实打实的，但通过量化、稀疏化和内存复用，大部分额外开销可以被消化，做任何扩展之前，先用公式把显存算清楚，再决定是加卡、减批次还是换方案,这样才能让显存预算花在刀刃上。
常见问题：词表扩展显存占用怎么算才准？
问：直接按“新增token数 × 隐藏层维度 × 2字节”算显存增量对吗？
不对，这个公式只算了FP16推理状态下的静态权重，训练时还要加上梯度（2字节）和优化器状态（8字节），实际增量是这个值的5到6倍，如果输出层和嵌入层不共享权重，还要把输出层的参数量也计入,相当于额外再加一份。
问：扩展词表后模型变笨了，是不是显存不足导致的？
两者没有直接关系，模型变笨通常是因为扩展后的嵌入层没有被充分训练，新增token的向量表示还没有和原有语义空间对齐，建议先用大量纯文本语料做嵌入层预热训练，再进入下游微调，显存不足只会导致训练中断,不会直接降低模型效果。