Transformers tokenizer padding_side 设置错误会怎样影响批推理

批量生成时，padding_side 不是排版选项，而是会影响模型从哪一个位置继续预测。对 decoder-only 模型，输入长度不一致且使用 padding=True 时，通常应把 tokenizer 配成左填充：真实 token 对齐到批张量右端，generate() 取到的最后位置才是每条输入的真实末尾。右填充可能触发 “right-padding was detected” 警告，也可能让批推理结果和单条推理不一致。

官方文档：https://huggingface.co/docs/transformers/

right padding 为什么会让批生成从错误位置继续

假设同一批有两条输入，一条短、一条长。右填充会把短输入写成“真实 token + padding token”，这样两行的最后一列并不都是真实内容。decoder-only 模型的生成是从序列末端接续，末列落在补齐 token 上时，模型看到的生成起点就偏了。

attention_mask 仍然重要，但它解决的是注意力范围：哪些位置可以参与计算。它不会改变批张量的列数，也不会替 generate() 自动选择每一行最后一个非 padding 位置。因此“mask 已经传了”不能单独证明填充方向正确。

先按模型架构决定填充方向

对常见的 decoder-only 因果语言模型，初始化时直接声明左填充，并处理没有 pad token 的 tokenizer。某些模型把 EOS 同时作为 padding 的占位符，这不是“让 EOS 提前结束”的意思；在生成配置和 attention mask 正确传入的前提下，它只是补齐位置的 token id，具体仍要看模型卡和使用方式。

from transformers import AutoTokenizer, AutoModelForCausalLM

# 左填充让不同长度输入的真实末 token 对齐到批张量右端
model_name = "your-causal-lm"
tokenizer = AutoTokenizer.from_pretrained(
    model_name,
    padding_side="left",
)
model = AutoModelForCausalLM.from_pretrained(model_name)

# 部分 decoder-only tokenizer 没有独立的 pad token，需要显式补齐
if tokenizer.pad_token_id is None:
    tokenizer.pad_token = tokenizer.eos_token
model.config.pad_token_id = tokenizer.pad_token_id

这里的关键不是把 warning 静音，而是让模型架构、tokenizer 的填充策略和生成配置保持一致。不要只修改 model.config 而忘记 tokenizer：真正生成 input_ids 的是 tokenizer。

把 input_ids、attention_mask 和 generate 绑在一起

批推理时应让 tokenizer 同时返回 input_ids 和 attention_mask，并把二者一起传给 generate()。下面的切片使用批张量的统一输入宽度，取出新增 token；它不把左侧补齐区域当成模型回答。

prompts = [
    "解释向量数据库的倒排索引",
    "用一句话说明 attention_mask 的作用",
]

# 统一补齐宽度，保留每行的可见范围
batch = tokenizer(
    prompts,
    padding=True,
    return_tensors="pt",
)

# max_new_tokens 限制新增长度，避免被输入长度配置间接影响
generated = model.generate(
    input_ids=batch["input_ids"],
    attention_mask=batch["attention_mask"],
    max_new_tokens=64,
)

# generate 返回“输入 + 新 token”，统一输入宽度后再截取新内容
input_width = batch["input_ids"].shape[1]
new_tokens = generated[:, input_width:]
answers = tokenizer.batch_decode(new_tokens, skip_special_tokens=True)

如果模型和输入在 GPU 上，实际项目还要把 batch 移到与模型相同的设备；这属于设备管理，不改变 padding_side 的判断。对 chat model 还要先按模型要求使用 chat template，避免把 prompt 格式问题误判成填充问题。

不要把所有模型都改成 left padding

填充方向要跟模型的输入语义绑定。decoder-only 模型的批生成关注输入序列最后位置，因此左填充通常是安全起点；encoder-decoder 模型先把输入交给 encoder，再由 decoder 生成，常见配置不应因为看到一条 decoder-only 警告就全局改写。

生产环境至少保留三组样本：batch=1、两条长度明显不同的 batch，以及长度相同的 batch。若只有 batch=1 正常，短长混合批异常，优先检查填充方向、pad_token_id 和截取输出的宽度；若三组都异常，再检查 prompt 模板、模型权重和设备。

常见问题

只传 attention_mask，还需要设置 padding_side 吗？

需要。mask 说明哪些位置可见，padding_side 决定真实输入落在序列哪一侧；对 decoder-only 批生成，两者承担的职责不同。

为什么单条输入看不出 right padding 的问题？

batch=1 且不需要补齐时，序列末端通常就是真实 token，错误配置没有暴露。换成长度不同的批才会出现补齐列。

把 pad_token 设成 eos_token 会不会马上停止生成？

不会因为补齐位置本身就必然停止。停止条件由生成过程中的 EOS 判断控制，但仍应结合具体模型文档、attention_mask 和实际回归样本确认。