Transformers项目中RecurrentGemma模型长文本推理崩溃问题分析
问题背景
在Transformers项目的最新版本(v4.50.3)中,研究人员发现RecurrentGemma-9b-it模型在处理长文本输入时会出现崩溃现象。具体表现为:当输入文本长度超过模型滑动窗口注意力机制设定的2048个token限制时,程序会抛出张量维度不匹配的运行时错误。
技术细节分析
RecurrentGemma模型采用了滑动窗口注意力机制,这种设计原本是为了处理长序列而优化的。然而在实际使用中发现,当输入序列超过预设的2048个token窗口大小时,模型在生成阶段会触发以下关键错误:
RuntimeError: The size of tensor a (2048) must match the size of tensor b (2402) at non-singleton dimension 3
深入分析表明,这个问题源于模型内部对注意力掩码(attention_mask)的处理逻辑。在解码阶段,模型假设接收到的attention_mask已经按照滑动窗口大小进行了裁剪,但实际上当前的通用输入准备函数并未执行这一裁剪操作。
问题演变历史
通过代码审查发现,这个问题经历了两个关键阶段:
-
在v4.46.0版本中,移除了模型特定的prepare_inputs_for_generation方法,同时错误地中断了past_key_values参数的传递,这曾导致模型生成功能完全失效。
-
在v4.48.3版本中,恢复了kwargs参数的传递,虽然修复了生成功能,但长文本处理的问题仍然存在。
解决方案
针对这个问题,技术团队提出了明确的修复方案:在_update_causal_mask()方法内部添加对attention_mask的裁剪逻辑,确保其长度不超过因果掩码的尺寸。这一修改与原始prepare_inputs_for_generation方法的处理方式保持一致,能够有效解决长文本输入时的张量维度不匹配问题。
对开发者的建议
对于需要使用RecurrentGemma模型处理长文本的开发者,建议:
- 暂时将输入文本控制在2048个token以内
- 关注Transformers项目的后续更新,及时获取修复版本
- 如需立即使用,可以考虑回退到v4.42.4等早期版本
这个问题凸显了在模型优化过程中保持向后兼容性的重要性,特别是在处理具有特殊架构要求的模型时。技术团队正在通过回归测试确保类似问题不会再次出现。
Kimi-K2.5Kimi K2.5 是一款开源的原生多模态智能体模型,它在 Kimi-K2-Base 的基础上,通过对约 15 万亿混合视觉和文本 tokens 进行持续预训练构建而成。该模型将视觉与语言理解、高级智能体能力、即时模式与思考模式,以及对话式与智能体范式无缝融合。Python00- QQwen3-Coder-Next2026年2月4日,正式发布的Qwen3-Coder-Next,一款专为编码智能体和本地开发场景设计的开源语言模型。Python00
xw-cli实现国产算力大模型零门槛部署,一键跑通 Qwen、GLM-4.7、Minimax-2.1、DeepSeek-OCR 等模型Go06
PaddleOCR-VL-1.5PaddleOCR-VL-1.5 是 PaddleOCR-VL 的新一代进阶模型,在 OmniDocBench v1.5 上实现了 94.5% 的全新 state-of-the-art 准确率。 为了严格评估模型在真实物理畸变下的鲁棒性——包括扫描伪影、倾斜、扭曲、屏幕拍摄和光照变化——我们提出了 Real5-OmniDocBench 基准测试集。实验结果表明,该增强模型在新构建的基准测试集上达到了 SOTA 性能。此外,我们通过整合印章识别和文本检测识别(text spotting)任务扩展了模型的能力,同时保持 0.9B 的超紧凑 VLM 规模,具备高效率特性。Python00
Baichuan-M3-235BBaichuan-M3 是百川智能推出的新一代医疗增强型大型语言模型,是继 Baichuan-M2 之后的又一重要里程碑。Python00
VLOOKVLOOK™ 是优雅好用的 Typora/Markdown 主题包和增强插件。 VLOOK™ is an elegant and practical THEME PACKAGE × ENHANCEMENT PLUGIN for Typora/Markdown.Less00