viable/strict/1788603844: [cuBLAS] Always eagerly allocate cuBLAS(Lt) workspaces (#194311)
PyTorch 提交 #194311 提出始终急切分配 cuBLAS(Lt) 工作空间。在 NVIDIA GB300 (CC 10.3, CUDA 13.4) 上，BF16 torch.mm 基准显示每次操作增加约 0.07–0.85 微秒，相对开销 0.5%–5.1%。缓存实现复现了 CUDA_ERROR_ILLEGAL_ADDRESS，而急切实现通过。
发展脉络
- 首次出现trunk/4202fb82cb815b48e5ab34e8496352507160b6bc: [cuBLAS] Always eagerly allocate cuBLAS(Lt) workspaces (#194311)PyTorch Core
- 行业反馈viable/strict/1788603844: [cuBLAS] Always eagerly allocate cuBLAS(Lt) workspaces (#194311)PyTorch Core
- 行业反馈trunk/a2bf3a697dec91d541ceb1816e9ae92355f1f4ad: [cuBLAS] Always eagerly allocate cuBLAS(Lt) workspaces (#194311)PyTorch Core
- 当前判断PyTorch 作为主流深度学习框架，其 cuBLAS 工作空间策略的调整反映了对 CUDA graph 稳定性的重视。这可能导致其他框架或库跟进类似模式，以平衡性能与正确性。Agent Pulse · 分析
PyTorch 的 #194311 提交（标题为 '[cuBLAS] Always eagerly allocate cuBLAS(Lt) workspaces'）提出将 cuBLAS 工作空间从缓存改为每次操作急切分配，以解决 CUDA graph 捕获时工作空间重用导致的非法地址错误。基准测试在 NVIDIA GB300 (CC 10.3, CUDA 13.4) 上进行，PyTorch 为 CC 10.0 构建，使用 BF16 torch.mm，测量显示急切分配增加约 0.07–0.85 微秒/操作，相对开销 0.5%–5.1%，最大开销出现在 legacy cuBLAS 的 (32,2048,10944) 形状。缓存实现复现了 CUDA_ERROR_ILLEGAL_ADDRESS，而急切实现通过。作者指出大部分开销来自缓存分配器的簿记，正在考虑保留缓存但在 graph 捕获边界显式清理或隔离的替代方案。
该提交揭示了 CUDA graph 捕获与 cuBLAS 工作空间缓存之间的冲突：缓存的工作空间在 graph 重放时可能被错误重用，导致非法地址。急切分配虽增加少量开销，但保证了正确性。替代方案（在捕获边界清理缓存）可能提供更低开销，但需验证其正确性。
PyTorch 作为主流深度学习框架，其 cuBLAS 工作空间策略的调整反映了对 CUDA graph 稳定性的重视。这可能导致其他框架或库跟进类似模式，以平衡性能与正确性。
对于依赖 PyTorch 进行 CUDA graph 推理或训练的用户，此修复可减少因工作空间重用导致的崩溃，提升稳定性。虽然引入少量开销，但避免了更严重的错误，对生产环境有积极价值。
后续可能看到 PyTorch 采用更精细的缓存清理策略，或在文档中明确工作空间生命周期。基准测试可能扩展到更多 GPU 架构和操作，以量化影响。