登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  科技周边 >  人工智能

大模型批量输入为什么要设置 padding 和 attention_mask

来源:17golang原创

时间:2026-09-06 00:12:03 282浏览 收藏

把多条文本一起送进大模型时,最容易混淆的是 paddingattention_mask:前者解决“每条文本长度不同,张量无法对齐”,后者解决“补出来的位置不能被模型当成真实内容”。两者通常由 tokenizer 一起返回,再原样传给模型。

要点速览
  • padding=True 让一个 batch 内的序列变成规则矩阵,但不会截断超长文本。
  • attention_mask 中通常用 1 表示有效 token、0 表示 padding 位置;不要只传 input_ids
  • truncationmax_lengthpadding_side 分别处理长度上限与补齐方向,需按模型类型确认。

把不等长文本整理成可计算的批次

单条调用时,token 序列可以各自保持长度;批量调用则通常要组成形如 [batch_size, sequence_length] 的规则张量。例如一条输入被切成 6 个 token,另一条被切成 10 个 token,它们不能直接堆成同一个二维矩阵。padding=True 会把较短样本补到当前 batch 的最长长度;padding="max_length" 则补到显式指定的 max_length

这里的 padding token 只是占位符,不代表文本真的多了几个词。批量效率和显存占用也会受到补齐长度影响:把一批长短差异很大的文本放在一起,短文本会产生更多无效位置。

Hugging Face Transformers 批量输入中原始文本、input_ids、padding token 与规则张量的静态关系
图1:看清变长文本如何对应到 input_ids、padding token 和规则批次张量;padding 是形状对齐,不是语义内容。

让 attention_mask 标出真正有效的位置

补齐之后,模型还需要知道哪些位置应该参与注意力。tokenizer 返回的 attention_mask 通常与 input_ids 形状一致:真实 token 位置为 1,padding 位置为 0。不同模型对额外 mask 的具体处理可能不同,但“补齐位置不应被当成有效输入”是批处理的核心约束。

from transformers import AutoTokenizer, AutoModelForSequenceClassification

# 使用同一个 tokenizer 处理整个 batch,确保 input_ids 与 mask 一一对应
tokenizer = AutoTokenizer.from_pretrained("bert-base-chinese")
texts = ["这个接口返回很快", "批量输入的长度可能不同"]
batch = tokenizer(
    texts,
    padding=True,          # 补到当前 batch 的最长序列
    truncation=True,       # 超过上限时按 max_length 截断
    max_length=32,
    return_tensors="pt"
)

# 将 tokenizer 生成的 attention_mask 一起交给模型
model = AutoModelForSequenceClassification.from_pretrained("bert-base-chinese")
outputs = model(**batch)
print(batch["input_ids"].shape)
print(batch["attention_mask"].shape)

示例中的 **batch 会把 input_idsattention_mask 一起传入;如果某个模型还需要 token_type_ids,tokenizer 也可能将它放入同一个字典。排查时先检查这些键的形状是否一致,再看模型文档要求哪些输入。

attention_mask 将有效 token 与 padding 位置区分后传入 Transformer 层的静态结构
图2:attention_mask 把有效 token 与 padding 位置分开,再与 input_ids 一起进入 Transformer;它是输入边界标记,不是输出质量分数。

同时处理超长输入与生成方向

padding 只负责“补短”,不能让超出模型最大输入长度的文本自动变短。因此通常把 truncation=Truemax_length 一起考虑。max_length 应根据模型可接受长度、任务需要和显存预算设置;截断前要确认被舍弃的是哪一段,避免把关键指令或标签截掉。

补齐方向由 padding_side 控制,可选 "right""left"。编码任务常见右侧补齐,因而有效 token 从序列开头开始;部分自回归生成场景会采用左侧补齐,让不同样本的最新 token 对齐。但这不是可以对所有模型统一套用的规则,应查看目标模型和 tokenizer 的配置。

参数解决的问题常见边界
padding让 batch 内长度对齐会增加占位 token,不负责截断
attention_mask标出有效与补齐位置必须和 input_ids 同批、同形状传递
truncation处理超过上限的输入可能丢失文本,需明确截断策略
padding_side决定从左侧还是右侧补齐生成模型要按模型要求确认

把批处理配置接到模型调用和排查清单

一个稳定的批量推理封装,至少要固定 tokenizer、最大长度、补齐策略和返回张量类型,并把这些配置写入日志。出现“单条正常、批量异常”时,可以按下面顺序排查:

  • 先确认是否真的传入了 attention_mask,不要手工用全 1 mask 覆盖 tokenizer 的结果。
  • 比较 input_ids.shapeattention_mask.shape,两者的 batch 和序列维度必须对应。
  • 确认 tokenizer 是否有可用的 pad_token;没有时不要随意拿普通词元代替,应按目标模型的官方配置处理。
  • 记录 padding=True 还是 padding="max_length",并核对 max_length 是否造成过度补齐或意外截断。

如果任务是训练而不是推理,还要额外区分输入的 attention_mask 与标签的 loss mask:前者告诉模型哪些输入位置有效,后者决定哪些标签位置参与损失计算,不能因为名字相似就混用。

常见问题

padding=True 和 padding="max_length" 有什么区别?

前者默认补到当前 batch 的最长序列,通常更省无效计算;后者补到指定的 max_length,形状更固定,但可能产生更多 padding。

attention_mask 可以不传吗?

如果没有 padding,某些模型可能可以推断全 1 mask;但批量输入一旦包含补齐位置,就应优先传 tokenizer 返回的 mask,并以目标模型文档为准。

为什么设置了 padding 仍然报长度错误?

因为 padding 只会补短,不会缩短长文本。检查是否同时设置了合适的 truncation=Truemax_length,并确认该长度不超过模型限制。

记住一句话:padding 负责把形状排整齐,attention_mask 负责告诉模型哪些位置算数;长度上限和补齐方向则是模型与任务共同决定的配置。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>