{"id":"mb-20260827-46d0c4","account":"mubei","brand":"","title":"从 A100 到 B200，显卡的张量计算吞吐暴涨了 7.2 倍","summary":"从 A100 到 B200，显卡的张量计算吞吐暴涨了 7.2 倍","body":"从 A100 到 B200，显卡的张量计算吞吐暴涨了 7.2 倍。\n但机箱里卡和卡之间的通信通道，只提升了 3 倍。\n跨机柜的互连网络，更是只涨了 2 倍。\n这道越撕越大的剪刀差，把整个算力工业逼到了墙角。\n今天大模型训练和推理的真正瓶颈，早就不在单张显卡算得多快。\n在卡和卡之间的数据通道有多窄。\n如果你直接用官方默认的 PyTorch 和 NCCL 组合去跑分布式任务，整套集群的实际性能，连理论通信屋顶线的一半都跑不到。\n一半的硬件算力，纯粹在原地干等数据搬运。\n既然通道不够宽，为什么不能在写代码的时候，把数据搬运和核心计算在时间上彻底叠在一起？\n只要重叠得足够精妙，计算的时间就能把通信的等待完全吃掉。\n顶尖的系统工程师确实做到了。\nTogether AI 的 Simran Arora 团队写出了 ParallelKittens，只往单卡算子里加了十几行底层原语，直接走 NVLink 调度硬件，在生产环境里把性能拉满，跑进了 Together AI 和 Cursor 的核心系统。\n真正的硬仗在后面。\n如果把这套多卡调优的任务，交给今天最顶尖的代码大模型，它能写得出来吗？\n答案打碎了很多人对 AI 编程的幻想。\n研究团队建了一个包含 87 道工业级多卡难题的基准 ParallelKernelBench。\n给模型一份没优化的基础代码和物理硬件拓扑图，让它写出直接操控 NVLink 搬运数据的 CUDA 算子。\n最强的前沿大模型单次上阵，87 道题里只写对了 28 道。\n这 28 道里，真正跑得比基线更快的，只有 22 道。\n哪怕给它疯狂采样、多抽几次结果，正确题数也只能勉强摸到 36 道。\n既写对又跑得更快的比例，被死死钉在 31% 附近。\n哪怕给它配上完整的多轮智能体环境，给它命令行终端去反复试错调试，最终也只停留在 35 道。\n大模型到底卡死在哪里？\n很多人以为是它写不好复杂的 CUDA 语法。\n完全猜错了。\n大模型其实格外擅长语法，编译报错只要让它重试一次就能修正。\n真正让它全线崩溃的，是一张它脑子里根本不存在的硬件物理拓扑图。\n要写出极致的多卡算子，程序员必须在硬件物理层做精细的三重权衡。\n第一重，是卡与卡之间通信顺序的时序编排。\n第二重，是海量数据在多张卡之间的切分与重组逻辑。\n第三重，是物理搬运路径的取舍。\n到底该走专用的硬件拷贝引擎，还是调用张量内存加速器 TMA，或者直接把数据塞进寄存器级别传输？\n每一种路径的延迟、带宽占用和流式多处理器开销，全都不一样。\n大模型之所以能写对前面两成题目，是因为那些模式在开源互联网上被反复写过，它只是在记忆里匹配既有模版。\n一旦面对真实的硬件物理瓶颈，需要根据显卡拓扑结构去推演数据流的碰撞与等待，它就彻底失去了方向。\n它背得下世界上所有的编程语法。\n但它从未真正理解过物理世界的电子和光子，是怎样在硅片与铜线之间穿梭的。\n软件层面的代码生成，只要逻辑闭环、通过单元测试就能交差。\n但当 AI 试图去优化物理世界的极端性能，一切语法技巧都会在硬件的物理铁律面前现出原形。\n算力跑得越快，通信的阻力就越致命。\n那些能够把代码写得符合语法的系统，永远只是第一步。\n真正能把几十万颗芯片捏成一台巨型计算机的，永远是对物理极限和空间拓扑的深刻理解。","category":"科技","score":null,"translated_x_url":null,"translated_status_id":null,"published_at":"2026-08-27 21:12:42","created_at":"2026-08-27 21:12:42"}