ParallelKernelBench揭示大型语言模型在多GPU内核上的弱点

realtime news Jun 23, 2026 18:47

ParallelKernelBench显示GPT-5.5及其同行在处理多GPU CUDA内核时表现不佳，仅解决了不到31%的任务。这是为什么。

最近的一个基准测试，ParallelKernelBench（PKB），揭示了大型语言模型（LLMs）在生成多GPU CUDA内核时的显著局限性。尽管在AI驱动的代码生成方面取得了进展，包括像GPT-5.5 和 Gemini 3 Pro这样的工具，但在基准测试中的87个问题中，正确解决的不到31%——其中只有一部分提供了比基线实现更好的性能改进。

PKB值得注意，因为它将焦点从单GPU任务转移到更复杂的多GPU工作负载领域，而这些工作负载主导了今天的生产AI系统。这些工作负载需要高效的GPU之间的通信，通常受限于像NVLink这样的技术的带宽限制。与单GPU内核生成相比（性能主要依赖于计算和内存优化），多GPU任务引入了围绕GPU之间数据移动和同步的复杂挑战。

基准测试发现

PKB评估了LLMs替代标准PyTorch + NCCL（NVIDIA 集体通信库）实现并生成优化CUDA内核的能力。模型在87个真实任务中进行了测试，包括来自NVIDIA的Megatron-LM和NeMo-RL等系统的工作负载。结果令人失望：

• 在零样本设置下，表现最好的模型（GPT-5.5）仅解决了28个任务，其中22个优于基线。
• 允许三次尝试提高了成功率，但最佳模型的“fast₁@3”分数仍仅为31%。

失败的原因既有语法级别的问题（例如，错误的CUDA代码），也有更深层次的推理缺陷，如秩协调和选择最佳的GPU到GPU通信机制。即使是更强大的模型，在需要高级抽象（如TMA（Tensor Memory Accelerator）或NVLS（NVLink Load/Store））的任务上也表现不佳。

为什么多GPU是一个更难的问题

从单GPU内核生成到多GPU内核生成的过渡大大增加了问题的复杂性：

• 组合设计空间：多GPU工作负载混合了张量、数据、专家和序列并行性，每种都产生独特的通信模式。
• 性能瓶颈：与单GPU设置不同（计算和内存占主导），多GPU性能取决于互连带宽。
• 新的设计选择：在GPU之间高效移动数据——无论是通过复制引擎、SM加载/存储，还是NVLink路径——都需要精心优化。

PKB的方法反映了这些挑战。每个任务从PyTorch + NCCL基线开始，要求模型生成利用直接GPU到GPU通信的CUDA内核。基准测试涵盖了多种工作负载，从大型语言模型（LLM）训练到图神经网络（GNN）路由和分布式FFT。

成功的曙光

尽管结果喜忧参半，但也有一些值得注意的成功。在少数情况下，模型生成的内核优于任何公开可用的实现。例如，Gemini 3 Pro为NVIDIA NeMo-RL的GRPO训练循环生成了一个自定义内核，将计算和通信操作融合在一起，与PyTorch + NCCL参考相比，显著减少了延迟。

这些胜利突显了AI驱动内核优化的潜力，特别是在没有优化的公共参考文献的特定领域。然而，这些成功仍是例外，而非普遍现象。

接下来会怎样

PKB的发现表明需要进一步研究多GPU内核生成。提高LLM性能可能需要两个主要转变：

• 反馈循环：将迭代反馈（例如调试、性能分析）集成到生成过程中，可能有助于LLMs改进其输出。
• 训练数据：扩展数据集，包含更多多GPU工作负载的示例——特别是涉及高级通信原语的工作负载——可能有助于模型建立更强的先验。

PKB还建议未来的基准测试应从节点内的NVLink扩展到像InfiniBand或RoCE这样的节点间结构，在那里通信复杂性进一步增加。

为什么这很重要

随着AI系统的扩展，多GPU工作负载的效率将直接影响模型训练和推理的成本和速度。PKB强调了LLMs在自主优化大规模分布式基础设施之前还有多远的路要走。对于开发者和研究人员来说，该基准测试设定了一个明确的目标：弥合“可用”分布式内核和真正优化内核之间的差距。

PKB是开源的，欢迎贡献和合作来解决这些挑战。有兴趣的人可以通过npaek@together.ai访问基准测试并提交新任务。

• ai
• llm
• cuda
• multi-gpu