Hugging Face Transformers 怎么用动态 padding 减少推理浪费

同一批文本长度差异很大时，把每条输入都补到模型允许的最大长度，会让大量 token 只是占位。更合适的做法是：分词时先不补齐，把每条样本保留成自己的长度；组装 batch 时交给 DataCollatorWithPadding，只补到当前 batch 的最长样本，并让 attention_mask 把 padding 位置标成 0。这样不会改变真实 token，只减少无效的矩阵计算。

固定最大长度为什么会浪费推理计算

假设一个 batch 里有 64、128、240 个 token 的样本。如果统一使用 padding="max_length" 和 max_length=512，三条样本都会变成长度 512；其中很大一部分位置只是 padding。Transformer 的注意力计算通常围绕矩形张量展开，形状变大后，padding 也会进入矩阵的计算路径。

动态 padding 的边界更窄：当前 batch 的最长样本是 240，批张量就补到 240。下一批如果最长样本只有 96，形状也会随之缩短。这个策略尤其适合请求长度分布不稳定的分类、向量化和批量编码场景。

用 DataCollatorWithPadding 把补齐推迟到 batch 组装

分词阶段只负责截断，不传 padding，得到长度不同的 token 列表。随后由 collator 读取这一批 features，调用 tokenizer 的 padding 逻辑补到 batch 最长序列。最小实现如下：

from transformers import AutoTokenizer, DataCollatorWithPadding
import torch

model_name = "distilbert-base-uncased"
tokenizer = AutoTokenizer.from_pretrained(model_name)

texts = [
    "短文本只需要少量 token。",
    "这是一段更长的文本，用来观察 batch 内动态补齐。",
    "中等长度的输入也会保留自己的真实 token 数量。",
]

# 先截断，暂时不 padding，保留每条样本的实际长度。
features = tokenizer(texts, truncation=True, max_length=256)

# collator 只补到当前 batch 最长样本，并直接返回 PyTorch 张量。
collator = DataCollatorWithPadding(tokenizer=tokenizer, return_tensors="pt")
batch = collator(features)

with torch.inference_mode():
    outputs = model(**batch)

print(batch["input_ids"].shape)
print(batch["attention_mask"].shape)

这里的重点不是把 features 提前转成等长数组，而是让 collator 在最后一刻决定本批形状。若模型是分类模型，outputs.logits 可以继续用于预测；如果只是生成 embedding，则取模型对应的隐藏状态即可。

attention_mask 怎样保证 padding 不参与注意力

padding 只是为了把列表拼成矩形，不能被模型当成真实词元。Transformers 的 tokenizer 和 DataCollatorWithPadding 会同步组织 input_ids 与 attention_mask：真实位置通常为 1，补齐位置为 0。模型据此忽略 padding 对注意力结果的影响。

排查时可以直接对照两者的形状和值：

如果手工构造 batch 只补了 input_ids，却没有同步补 attention_mask，模型可能无法正确区分真实 token 和占位 token。优先让 tokenizer 与 collator 共同完成这一步。

动态 padding 仍要处理截断、分桶和硬件对齐

动态 padding 不是“永远不限制长度”。truncation=True 仍然要配合业务允许的 max_length，否则少量超长请求会把整批张量拉大。若任务是句对输入，还要明确使用哪一种 truncation 策略，避免不小心截掉错误的一侧。

当 GPU 对特定尺寸更友好时，可以给 collator 设置 pad_to_multiple_of=8 或其他经过验证的倍数。它会在 batch 最长序列之上做小幅对齐，节省的 padding 可能换来更稳定的硬件吞吐；但倍数越大，补齐浪费也可能增加。对长度差异特别大的请求，还可以先按 token 长度分桶，再在桶内动态 padding。

把批处理配置收敛成可复用的推理函数

落地时可以把“分词不补齐、collator 统一补齐、模型接收 mask”封装在一个函数里。上线前至少检查三件事：tokenizer 有 pad token；截断上限符合模型输入限制；batch 的平均有效 token 数与实际 padding 数都被记录。若使用 decoder-only 模型且 tokenizer 没有 pad token，要先根据模型文档明确设置合适的 pad token，并确认 padding side 与任务一致。

动态 padding 解决的是 batch 内无效长度，不会自动解决请求排序、模型量化或注意力内核选择。先用真实长度分布测一轮，再决定是否加长度分桶和硬件倍数，通常比直接把全局最大长度改成一个更大的数字可靠。

相关问题

动态 padding 会不会改变模型结果？

在 tokenizer、mask 和模型设置正确的前提下，padding 位置被 mask 排除，真实 token 不会因为补齐策略改变；但截断、padding side 或生成任务的特殊 token 设置仍可能影响结果。

为什么不直接给 tokenizer 设置 padding="max_length"？

如果所有请求都需要固定形状或硬件图编译，固定长度有其价值；普通变长 batch 则可能产生更多无效位置，应该优先考虑按 batch 最长序列补齐。

如何判断动态 padding 是否真的节省了推理？

同时记录 batch 最大长度、有效 token 总数、padding token 总数、端到端延迟和显存峰值，再用相同请求顺序对比固定长度方案。只看单次耗时容易被冷启动和数据加载干扰。

官方参考：Data collators、Padding and truncation、Tokenizer。