pack_padded_sequence通过压缩padding使RNN仅在真实token上计算，显著减少无效运算；需按长度降序排序、传入真实长度、配合pad_packed_sequence还原，否则报错或结果错乱。
pack_padded_sequence 为什么能加速 RNN？
PyTorch 的 RNN、LSTM、GRU 默认会对整个 batch 中所有序列按最长长度做填充（padding），哪怕某些样本只有 5 个 token，也会被 pad 到 100 长度。RNN 内部仍会逐时间步计算——包括那些 padding 位置，白白消耗显存和算力。
pack_padded_sequence 的作用不是“让 RNN 跳过 padding”，而是把 padding 全部压缩掉，让 RNN 只在真实 token 上运行。它不改变 RNN 的前向逻辑，但大幅减少无效计算量，尤其在 batch 内长度差异大时（比如机器翻译中短句和长句混排），速度提升常达 2–4 倍。
注意：pack_padded_sequence 必须配合 pad_packed_sequence 使用，否则输出形状错乱或报错 RuntimeError: Expected hidden[0] size (1, 32, 128), got (1, 33, 128)。
怎么正确调用 pack_padded_sequence？
关键有三点：排序、打包、还原。漏掉任一环都会出错或失效。
立即学习“Python免费学习笔记（深入）”；
- 输入必须是按长度**降序排列**的 batch（
sort=True参数仅控制是否自动排序，但强烈建议自己排——避免与后续 label 对齐错误） -
pack_padded_sequence的lengths参数必须是原始未 padding 的真实长度（torch.tensor([5, 12, 8, ...])），不能是 padding 后的 shape[0] - 打包后的输出送入 RNN，RNN 输出再用
pad_packed_sequence还原为常规张量；若需取最后时刻隐藏态，要用torch.nn.utils.rnn.pad_packed_sequence(output, total_length=max_len)[0]再索引，不能直接output[-1]
# 示例：正确流程
lengths = torch.tensor([12, 8, 5]) # 真实长度，已降序
x_packed = torch.nn.utils.rnn.pack_padded_sequence(
x, lengths, batch_first=True, enforce_sorted=True
)
output_packed, h_n = rnn(x_packed) # RNN 接收 packed 输入
output, _ = torch.nn.utils.rnn.pad_packed_sequence(
output_packed, batch_first=True, total_length=x.size(1)
)
enforce_sorted=True 和 False 有什么区别？
enforce_sorted=False 表示允许输入序列未排序，PyTorch 会内部排序 + 记录逆索引，之后自动还原顺序。但代价是：
- 额外 CPU/GPU 开销（排序 + 索引映射）
- 如果后续要对 output 做 loss 计算（比如 CRF 或 token-level 分类），必须确保 label 也同步重排，否则标签错位
- 某些旧版 PyTorch（enforce_sorted=False 下可能触发
RuntimeError: input.size(0) != lengths.size(0)
更稳的做法是：自己用 torch.argsort(lengths, descending=True) 排序输入和 label，设 enforce_sorted=True，省去框架隐式开销。
哪些场景下 pack_padded_sequence 反而拖慢速度？
不是所有 RNN 场景都适合。以下情况收益极小甚至负优化：
- batch 内所有序列长度几乎一致（比如固定截断到 64），padding 占比
- 使用
nn.LSTM且只取最后 hidden state（h_n），而不用每个时间步输出 —— 此时 RNN 本就不需要遍历全部 padding 步骤（部分实现会提前终止），打包意义不大 - 启用了 cuDNN 的 LSTM（默认开启），其底层已对 padding 做了高度优化；此时
pack_padded_sequence可能迫使 PyTorch 回退到慢速路径 - 模型含大量非 RNN 层（如大 embedding + 多层 FFN），RNN 计算占比低，整体加速不明显
实际提速得看 profile：用 torch.autograd.profiler 对比 packed/unpacked 版本的 CUDA kernel 时间，别凭感觉。
最容易被忽略的一点：pack_padded_sequence 不处理 embedding 层的 padding 计算——如果你在 embedding 后直接打包，那 embedding 本身仍在全长度上运行。真正省的是 RNN 层，不是前面的任何操作。
