UMT5 incredibly slow in generating

快速结论：在使用 Transformers 加载 google/umt5-small 并执行 generate 生成时，会出现“UMT5 incredibly slow in generating”，即同样参数规模下 UMT5 的生成耗时明显高于 mbart/t5/mt5。优先排查 UMT5 相对位置偏置计算（compute_bias）在解码每一步的重复开销，而不是参数量或显存问题。

适用环境：Issue 中确认的环境：transformers 4.33.1、Python 3.11.4、PyTorch 2.0.1+cu117（GPU）、Linux x86_64（glibc 2.34）、huggingface_hub 0.16.4、safetensors 0.3.1、accelerate 0.22.0。模型涉及 google/umt5-small，对照 facebook/mbart-large-50-many-to-one-mmt、google/mt5-small、t5-small。

最快修复方案：暂无确认的一步修复方案。Issue 中维护者定位到 compute_bias 是耗时函数，并明确表示“应该为它引入缓存机制”，但讨论链未给出已验证的补丁或配置项。

注意事项：不同作者用 device_map={“”: “cuda”} 与直接 .to(“cuda”) 测得倍数不一致（9-10x 与约 4x），说明测试方式和环境会影响结果；去掉 UMT5 的翻译前缀并不消除差异。使用 mt5/t5 等相近架构对照更有意义，单独与 mbart 比较容易误判。

问题场景

用户在 GPU 上用 Transformers 的 AutoModelForSeq2SeqLM 加载 google/umt5-small，并通过 model.generate 生成约 200 个新 token。用户观察到大模型 mbart-large-50（约 11 亿参数）生成更快，而参数更少的 umt5-small（约 3 亿参数）反而慢 9-10 倍，因此怀疑 past states 缓存未正确实现。后续对照 google/mt5-small 与 t5-small 后，umt5-small 仍是明显异常点。

报错原文

UMT5 incredibly slow in generating

Generation duration for mbart-large-50-many-to-one-mmt:  22413427363
Generation duration for umt5-small:                     207906791077

google/umt5-small:        975.10% (relative gen. time); 50.19% (relative size)
google/mt5-small:        12.80% (relative gen. time); 49.14% (relative size)

原因分析

维护者在复现用户脚本后指出，问题出在 UMT5 的 compute_bias：如果去掉该函数、改用默认位置偏置，性能可以恢复到与其他模型相当的水平。这说明 UMT5 的位置偏置在每个解码步骤被重复计算，是当前主要性能瓶颈。维护者同时认为这与“UMT5 相对位置偏置的特性”有关，属于可预期但应优化的实现方式，并提到应该为 compute_bias 增加缓存机制。讨论中未确认缓存是否已经实现或将在哪个版本修复，因此“缓存缺失是根因”仍属于讨论结论而非已验证补丁。

环境排查

确认 transformers 是否为 4.33.1 或相近版本，不同版本 UMT5 实现可能不同。
确认 PyTorch 与 CUDA 版本（Issue 中为 PyTorch 2.0.1+cu117，GPU 可用），排除 CPU 回退导致的整体变慢。
确认是否使用 device_map={“”: “cuda”}；讨论中提到 device_map 与 _no_split_module 的差异可能影响测量结果。
确认是否安装 accelerate（0.22.0），以及是否能提供 transformers-cli env 的完整输出。
对照测试时使用 t5-small 或 mt5-small 等架构相近模型，而不是只与 mbart 比较。
确认 generate 的 max_new_tokens、max_length、num_beams 等 GenerationConfig 设置在各模型间一致。

解决步骤

先复现并记录单次 generate 的耗时，避免只靠 100 次循环的总时间判断；Issue 中维护者单次测试未复现 9-10 倍差异，循环测试才复现。
使用 google/mt5-small 与 t5-small 作为对照，重新测量 UMT5 的相对耗时和相对参数量，确认 UMT5 是否为异常点。
若需要临时验证瓶颈，可优先尝试在本地代码中绕开 UMT5 的 compute_bias（例如改用默认位置偏置）观察 generate 耗时是否明显下降；该做法只用于定位，Issue 中未给出可直接使用的生产补丁。
关注 transformers 后续版本对 UMT5 位置偏置缓存的实现；在修复落地前，可评估是否改用 mt5 或 t5 等架构相近且生成速度正常的模型。
如需进一步反馈，附上 transformers-cli env、是否安装 accelerate、device_map 设置以及可复现的计时脚本。

验证方法

在相同输入、相同 GenerationConfig 和相同设备下，分别记录 umt5-small、mt5-small、t5-small 的单次 generate 平均耗时，并与参数量比例对照。如果 UMT5 的生成时间仍显著高于同规模对照模型，则问题依旧；如果绕开 compute_bias 后耗时接近其他模型，则可确认瓶颈在该函数。最终应以更新后 transformers 版本中 UMT5 的实测结果为准。