Transformers 回報連續批次效能問題，閒置 KV 快取容量也可能拖慢生成

Hugging Face 專案成員 albertvillanova 於 10 月 20 日提出重現案例：Transformers 的 generate_batch 在連續批次模式下，使用 Flash Attention 時，執行時間可能隨 KV 快取容量增加，即使實際請求遠未填滿快取。回報涵蓋穩定版 5.20.2 與開發版 5.21.0.dev0，目前議題仍開啟。問題回報

測試使用 H100 80GB 與 Qwen2.5-0.5B-Instruct，送入 64 個提示、各最多生成 128 個 token。依可用記憶體配置五成快取時，暖機後每次約需 11 秒；提高至九成約需 18.7 秒，指定 num_blocks=64 則約為 1.9 秒。分析追蹤顯示，大量 GPU 時間落在 prefill 注意力呼叫，其 K/V 輸入形狀涵蓋整個快取容量；decode 呼叫的成本則很低。這是回報者的定位結果，尚不能推廣至所有模型與注意力後端。測試與追蹤數據

這項差異也延伸到強化學習訓練。另一則 TRL 議題指出，啟用 Transformers 連續批次後，GRPO 與 RLOO 會在每次生成時，預設以一半可用 GPU 記憶體配置快取。其小型 GRPO 五步測試，預設設定耗時 59 秒，改用 64 個區塊後降至 15 秒；這是特定生成配置的比較，並非整體訓練框架的通用加速比例。TRL 回報

官方文件將快取容量、每批 token 預算與排程列為不同控制項；連續批次會在每一步調整請求，以提高 GPU 使用率。此次案例提醒工程師，容量設定也應納入效能測試。依現有結果推論，短提示、小模型或低併發工作負載，尤其值得檢查過量預留的代價。連續批次文件

後續應觀察 prefill 路徑是否改為只處理有效快取，以及 TRL 的配置策略是否調整。縮小區塊數可作為本機比較起點，但必須重新驗證長序列與併發容量；回報中的 SDPA 耗時雖不隨快取大小明顯變動，仍慢於小快取的 Flash Attention，不能直接視為最佳替代方案。