mamba generation throughput lower than original due to DecodingCGCache

快速结论：在 Transformers 中使用 MambaForCausalLM 生成文本时，如果吞吐量明显低于原始 mamba-ssm 仓库开启 cg=True 的结果，核心原因是 Hugging Face 实现当时未支持 torch.compile / CUDA Graphs 编译路径，而不是 use_cache 没生效。优先确认是否启用了编译，以及所用 Transformers 版本是否已包含相关支持。

适用环境：Issue 中确认的环境为 Python 3.10.13、CUDA 12.1、NVIDIA GeForce RTX 2080 Ti（10.747 GB 显存）、torch 2.2.1、torchaudio 2.1.0、torchvision 0.16.0、tokenizers 0.15.2、triton 2.2.0、causal_conv1d 与 mamba_ssm 均来自指定 Git 提交的版本；后续测试还使用了 transformers 4.44.0。模型为 state-spaces/mamba-130m 与 state-spaces/mamba-130m-hf。

最快修复方案：Issue 中没有确认的一步修复方案。可优先尝试升级到包含 #30139、#31247 等改动的 Transformers 版本，并按评论中的思路尝试对 Mamba 使用 torch.compile；这些改动是否完全消除差距，Issue 中并未给出明确验证结论。

注意事项：use_cache=True 并不是此问题的根因，修改该参数无法恢复原仓库 cg=True 的吞吐量。Issue 中报告即使升级到 transformers 4.44.0 并重测，开启 cg=True 的 mamba_ssm 仍远快于 HF 实现；此外用户的测试环境不支持 flash_attention_2，该因素是否影响结果在 Issue 中未完全确认。

问题场景

用户在对比 Mamba 文本生成性能时触发该问题。原始 mamba-ssm 仓库使用 MambaLMHeadModel，在 generate() 中开启 cg=True，生成 100 prompt + 1000 输出耗时约 1011 ms。改用 Transformers 的 MambaForCausalLM 与 state-spaces/mamba-130m-hf 后，同样长度耗时约 15970 ms。用户尝试在加载模型时传 use_cache=True、传 cache_params={use_cache: True}、设置 model.config.use_cache=True，甚至修改 modeling_mamba.py 强制使用 cache，均未改善生成速度。

报错原文

mamba generation throughput lower than original due to DecodingCGCache

Number of parameters: 129135360
Prompt length: 100, generation length: 1000
Prompt processing + decoding time: 1011 ms

state-spaces/mamba-130m-hf prompt processing + decoding time: 15970ms

# mamba_ssm, with cg=True
# Time: 1.33s
# torch.Size([1, 1000])

原因分析

Issue 讨论中，维护者明确指出这不是 caching 问题，而是 compilation 问题：原仓库里的 cg 参数会触发编译，cg 很可能代表 CUDA Graphs；而 Hugging Face 当时实现的 Mamba 与 fullgraph 编译不兼容，因此无法复现原仓库的加速效果。后续该问题被转为 feature request，目标是为 Mamba 增加 torch.compile 支持。可能原因还包括：Mamba 中原本的 einsum 被替换为普通运算，以及 HF 实现当时未支持 flash-attn 相关能力，但这些在 Issue 中没有形成最终确认结论。

环境排查

确认 Python 版本，Issue 中为 3.10.13。
确认 CUDA 版本，Issue 中为 12.1。
确认 PyTorch 版本，Issue 中为 torch 2.2.1；后续重测环境同样为 torch 2.2.1。
确认 Transformers 版本，Issue 初始为指定 Git 提交，后续重测使用 transformers 4.44.0。
确认 triton 版本，Issue 中为 2.2.0。
确认 mamba_ssm 与 causal_conv1d 版本，Issue 中均来自指定 Git 提交。
确认显卡型号与显存，Issue 中为 NVIDIA GeForce RTX 2080 Ti，最大显存 10.747 GB。
确认是否启用 torch.compile，以及是否使用 fullgraph=True。
确认生成配置是否一致，Issue 中强调应只比较 greedy search，而不是 sampling 或 beam search。
确认是否支持 flash_attention_2，用户测试环境中未支持。

解决步骤

先确认问题本质：不要继续只调 use_cache。Issue 中已确认 cache 正常生效，单纯设置 use_cache=True 或修改 MambaModel 强制 cache 都不能恢复原仓库 cg=True 的速度。
将 Transformers 升级到包含 #30139、#31247 等改动之后的版本。Issue 中维护者认为这些 PR 应有所帮助，但用户重测 4.44.0 后差距仍然显著，因此升级后需自行验证。
按评论中的复现思路，尝试对模型使用 torch.compile：加载 MambaForCausalLM，设置 model.eval()，然后尝试 model.forward = torch.compile(model.forward, mode="reduce-overhead", fullgraph=True)，再进行生成测试。注意该做法在 Issue 中只是维护者给出的复现建议，并未确认可完全解决吞吐量差异。
对比测试时使用完全相同的生成配置：只跑 greedy search，不启用 sampling，不启用 beam search，并统一 prompt 长度与生成长度。
如果升级和编译后速度仍无改善，记录当前版本、生成配置、耗时和输出形状，到对应 Issue 或新 Issue 中反馈，因为该问题在 2026-09-11 关闭时，用户重测仍报告明显差距。

验证方法

使用相同模型、相同 prompt 长度 100、相同生成长度 1000，在 HF Transformers 与原始 mamba_ssm 之间分别运行 greedy generation，比较总耗时。Issue 中的参考对比为：HF transformers v4.44.0 无 flash_attention_2 支持时约 14.75s；mamba_ssm 不开 cg=True 约 13.99s；mamba_ssm 开 cg=True 约 1.33s。若启用编译后 HF 侧耗时显著下降并接近开启 cg=True 的量级，即可认为问题得到改善；若仍停留在 14s 左右，则说明编译路径未生效或尚未覆盖该问题。