打开 ChatGPT 问了一个问题，光标闪了三秒才吐出第一个字。
脑子里闪过一串念头：又在排队了，这破服务器。模型是不是太大了跑不动。要不要切到另一个 App。
这些猜测里，只有一个方向是对的，但大多数人不会往那想——不是你用的模型笨，也不是服务器不够多，而是那台机器里几张显卡在互相等对方的数据。等的时间，可能占到你实际等待时间的五分之一以上。
ParallelKernelBench 是上周刚公开的一个基准测试。名字很硬核，但问的问题很简单：当 AI 能自己写 GPU 代码时，它能搞定多张显卡之间的通信吗？
答案是不太行。
PKB 从 Megatron-LM、DeepSpeed、TensorRT-LLM 这些生产级代码库里拆了 87 道真实的多 GPU 场景题。每道题给一个能用但偏慢的参考实现，让模型自己写一版更快的 CUDA kernel——把数据搬得更好，让计算和通信重叠得更紧。
当前最强的 GPT-5.5 解出了 28 道，不到三分之一。这 28 道里，跑得过参考实现的只有 22 道。四分之一。
更有意思的是失败模式。弱一点的模型经常编译都过不了。强模型（GPT-5.5、Opus 4.7 这种）反而经常写出能编译、能跑、但算出错误结果的 kernel——它不是不懂 CUDA 语法，是卡在"第 3 张卡该什么时候把数据发给第 7 张卡"这种跨卡协调上。这正是人类写多 GPU kernel 最难的部分。
连给模型配上编译器和测试框架让它自己边跑边改——像人类程序员那样 loop——Gemini 3 Pro 也只能从 24 道提到 35 道。过了第 20 轮左右就平了。这不是"再想想就能解"的问题。
堵的不是车，是路
单 GPU 上，瓶颈是算力和显存带宽。到了多 GPU，瓶颈变成了 GPU 之间那根线——NVLink 的带宽。
每张 GPU 的算力增长曲线很陡，互联带宽的增长曲线要平得多。车越跑越快，路没同步加宽。这不是任何一张卡的问题，是物理结构的问题。
PKB 的数据印证了这一点：模型最擅长的是"集体通信原语"和"张量并行 GEMM"——开源代码里最常见的模式，学过了，有先验。一旦涉及更新的通信机制，比如 TMA 异步拷贝、NVLS 这种需要理解 NVLink 新拓扑的东西，模型几乎束手无策。不是它们不够聪明，是训练数据里根本没出现过。
这就引出一个比 benchmark 本身更大的问题。
往上建的人越来越多，修路的人没增加
PKB 发布那天，GitHub Trending 前排挤满了 Agent 项目。热度最高的几个仓库全是给 AI 加"手"加"脚"的——让它调用更多工具、跑更长的任务链、编排更复杂的多步推理。每一步都可能跨多张 GPU。
同一天 Claude 发布了新的模型控制功能，Cursor 宣布了自研模型和移动端 App。模型尺寸在涨，单次请求背后的推理调用次数在涨，并行度在涨——全都在给底层互联施压。
而 PKB 告诉我们的是：在最需要优化的那个环节，连最强的 AI 也只能搞定四分之一。这不是"再训练几轮就能补上"的差距——多 GPU 通信模式的训练数据覆盖本身就非常薄。
一个能带走的判断
PKB 里也有一小撮让人意外的亮点。有些模型生成的 kernel 跑得比任何公开实现都快。NeMo-RL 的 GRPO 训练循环里有一个词汇表并行加 top-k/top-p 过滤的算子，以前没人专门优化过，Gemini 3 Pro 直接写了一个用对称内存跨卡置换的版本，跳过所有 NCCL 集合通信，性能显著优于参考实现。
这反而更说明问题：AI 的优化能力是真实的，但它在多 GPU 场景下发挥不出来，因为可学的东西太少。一旦数据覆盖够了，它就能找到人类没找到的路径。问题在于，路没跟上车的进化。
下次用 AI 觉得慢，别脱口而出"这模型不行"。你等的可能不是一个 GPU 在算，是八个 GPU 在互相等消息。这层物理税不是软件能绕过去的。而知道这笔税在哪——这种判断力，比知道哪个模型更强有用得多。
