当一块 GPU 不够用了怎么办？YC 关于芯片和推理架构的最新分享

你有没有想过，我们对 GPU 的理解可能一直太简单了。过去这两年大家聊 AI 基础设施，聊得最多的还是买多少张卡、用哪个云、模型能不能装得下显存。但最近听完一场 YC Paper Club（YC 内部的论文分享会）的分享，我意识到真正决定一个 AI 系统跑得快不快、贵不贵的，早就不是有没有 GPU 这么简单的问题，而是芯片怎么分工、程序怎么写、集群怎么搭这些更底层的东西。

这场分享请了五位讲者。Stuart Sul 来自 Stanford，同时在 Cursor 训练 Composer 这个编程模型。Jon Saad-Falcon 是 Stanford 的博士生。Mark Saroufim 做过五年 PyTorch，联合创办了 GPU Mode，现在在 Core Auto。Misha Smelyanskiy 一个月前刚加入一家叫 Marlo 的创业公司，之前在 Nvidia 做过 AI 基础设施，也在 Meta 做过硬件软件协同设计。Brennan Shacklett 在 Stanford 读博期间做了一个完全跑在 GPU 上的游戏引擎，现在在做一家 AI 加游戏的创业公司。听完这五场分享，我最大的感受是，这轮 AI 竞赛正在往硬件和系统这一层下沉，而这件事的复杂程度比大部分人想的要深得多。

芯片正在被拆成不同的物种

开场是主持人 Francois Chaubard 讲的一个大背景。他说整个行业正在经历芯片层面的专业化分化。训练用的数据中心和推理用的数据中心，需要的规格完全不一样。训练这件事，你其实不太在乎带宽，极端点说，你可以把权重文件送上一艘飞船绕太阳飞一圈再飞回来，对训练没什么影响，因为训练本质上就是不停地算。但推理不一样，推理是要实时给人答案的。尤其是语音助手这种场景，你打个电话过去，对方说了句你好，卡了八秒才有反应，这种体验完全没法接受。

他提到一个我觉得挺扎心的现象。很多做推理系统的团队，为了追求整体吞吐量，牺牲了单次请求的响应速度。系统看起来很高效，但用户体验很差，因为真正让人在意的往往是单个请求有多快，不是系统整体处理了多少请求。我自己听到这段的时候想到的是，这跟做产品是一个道理。你可以把一个功能做得对整体指标很友好，但具体到每一个用户的实际体验上，反而是灾难。

Stuart Sul 单卡已经榨干了 瓶颈换到了网络上

Stuart Sul 讲的是他和团队做的一个叫 Parallel Kittens 的项目，核心问题是怎么写多卡 GPU 的 kernel（内核，也就是跑在 GPU 上执行具体运算的程序）。他说过去几年，整个机器学习系统圈子把大量精力花在单卡效率上，比如 flash attention 这类对内存访问很友好的算法，已经把单张卡的性能榨得差不多了。榨干之后大家发现，真正的瓶颈换成了 GPU 之间的通信。他举了个例子，像 Llama 这种用 MoE（混合专家模型）架构的模型，在做 prefill（把输入的提示词先处理一遍，生成后续要用的中间结果）的时候，网络通信能占到总运行时间的一半。

解决思路是把通信和计算的重叠做得更细。以前是整块整块的张量传输完再算，现在做到按 tile（数据块）甚至按 token（词元）的粒度去重叠，数据量小到几 KB 甚至更小。硬件这边也在进步，比如现在有一种叫 in-network compute 的技术，可以把原来要靠 GPU 之间来回发数据、算局部结果再汇总的笨办法，直接卸载到网络硬件上去做，GPU 就腾出手来做别的计算。还有像 NVL72 这种把 72 张卡打包进一个 NVLink（Nvidia 的高速互联技术）域的架构，以后这个数字还会涨到几百张。

但问题是，现在写多卡 kernel 的人只有三条路可选。用 NCCL 这类现成的库，只能做粗粒度通信，硬件跑起来会有很多空转的气泡。用编译器自动生成，但生成出来的东西经常比不做重叠还慢。或者直接手写底层的进程间通信调用甚至 PTX 汇编，这种代码复杂到没法维护，还得靠逆向工程去理解硬件到底在干嘛。Parallel Kittens 想找出一套简单的原则，把这件事标准化。他们发现有三个关键权衡决定了多卡 kernel 该怎么写。数据怎么传，copy engine 需要大数据包才划算，TMA（一种数据搬运机制）在数据包很小的时候依然能跑满带宽而且只需要很少的 SM（流多处理器，GPU 里做计算的基本单元），寄存器指令能用上网络内计算但写起来特别痛苦。计算和通信怎么调度，有的方案是同一批线程里一部分算一部分通信，有的是专门留出一批 SM 只做通信。还有要不要为了简化设计牺牲性能，光是去掉 NCCL 默认强制使用的中间缓冲区，就能让 all-reduce（一种常见的多卡数据汇总操作）这类基础操作快上 80%。

结果是，用 Parallel Kittens 写出来的多卡 kernel，只要五十到一百行设备代码，就能追平甚至超过那些手写几百上千行的高度优化版本。Cursor 已经在用它，在几万张 Blackwell（Nvidia 最新一代 GPU 架构）卡上训练 Composer，Together AI 也拿它优化推理。我听完这段的感触是，很多时候我们以为效率问题要靠堆更多资源解决，但真正的突破常常来自把一个混乱的设计空间拆解成几条清晰的权衡线。这跟做产品决策是一回事，复杂问题不是靠更努力，而是靠找到对的几个变量。

Jon Saad-Falcon 我们是不是在重演大型机到 PC 的历史

Jon Saad-Falcon 讲的是一个他和团队提出的概念，叫 intelligence per watt（每瓦特能交付多少智能）。他开场抛出一个挺有意思的类比，说现在这个阶段的 AI 和硬件很像上世纪五六十年代的大型机时代，IBM 那种占满整个房间甚至整层楼的计算机，而现在我们建的数据中心，本质上也是一栋楼一栋楼堆满 GPU 和 TPU，同时干训练和推理的活。他提到一个数字挺震惊我的，现在美国在这上面的投入已经占到 GDP 的百分之二到三，需要新建两百五十吉瓦的数据中心，这个规模可能是自从修建横贯大陆铁路以来最大的一次基础设施投入。

但他接着说了一个反直觉的点，尽管需求涨得这么猛，大部分日常的 AI 请求根本用不上顶尖水平的智能。他自己平时用模型做的事，很多就是整理数据集、建文件夹、写单元测试，根本不需要最前沿的编程或数学能力。所以他判断，接下来会重演一次历史，就像当年从占满房间的大型机走向个人电脑一样，现在也会从每次请求都调用云端大模型，慢慢转向更多用本地的开源小模型处理。这背后有两个趋势在推动，开源小模型一年比一年强，本地的加速器不管是 Apple、Nvidia 还是 AMD 的，内存和性能也在飞涨，已经装得下不少参数量不小的开源模型。

为了验证这个判断，他们测了二十多个主流本地模型，涵盖 Gemma、GPT-OSS、Qwen、IBM Granite 这些系列，参数量从十亿到两千亿不等，同时测了过去两三年里各家最新的本地加速器。结果是，如果把请求做完美路由，最多能有百分之八十八点七的查询可以交给本地跑，而且这个比例还在涨。过去两年，每瓦特能交付的智能提升了大概三倍。算每焦耳能交付的智能，过去大概十六个月里提升了十八倍，这主要是因为消费级 GPU 内存变大了、量化技术更成熟了、训练方法也更精细了。哪怕路由做得不完美，也能省下百分之五十到七十的能耗、算力和成本。当然本地加速器还是打不过数据中心级别的卡，比如拿 Apple M4 Max 跟 Nvidia B200 比，每瓦特智能这个指标还是有明显差距。

这段我印象最深的是他们接下来要做的一个项目，叫 Open Jarvis，目标是把整套个人 AI 编程能力放到本地设备上跑，不用再为每次调用付钱给云厂商。我作为一个经常要给团队算 AI 调用成本的人，这个方向挺打动我的，因为它意味着未来很多现在看起来昂贵的智能，可能会变得几乎免费，前提是你愿意接受本地模型没有那么聪明这件事。

Mark Saroufim AI 写内核这件事 比想象中疯狂得多

Mark Saroufim 这段是我听完印象最深的一场。他做过五年 PyTorch 系统研发，联合创办了 GPU Mode，现在在 Core Auto，讲的是 AI 写 GPU kernel 这件事到底发展到什么程度了。他先说了句挺自嘲的话，说自己作为系统研究者，意见其实没有做 AI 研究的人重要，因为研究员想要的是自回归、动态控制流、稀疏性，还要能打印调试信息，这些东西对写系统的人来说是噩梦，但没办法，还是得把工具做出来。

他梳理了一遍现在写 GPU 代码的技术谱系，从最稳定的数学公式（矩阵乘法这个 API 两百五十年都没变过），到 PyTorch 的算子层，到 Triton（一种基于 tile、写起来很 Python 化的语言，大概两年半前开始统治整个领域），再到更底层的 ThunderKittens、Cutlass、CuteDSL 这些 Nvidia 自己的闭源库，到 CUDA，一直到最底层的手写 PTX 汇编。他们做了个叫 KernelBot 的平台，有点像面向 GPU 程序员的 LeetCode，谁都可以提交 kernel 代码，可以选任何一种技术方案。数据显示，真正追求极限性能的人还是最爱用 CUDA，做矩阵乘法相关的问题大家喜欢用 CuteDSL，Triton 经常能进前十，但很少能拿到前二。

真正让我意外的是接下来这段。今年一月他们办了一场关于 NVFP4（一种新的数据精度格式）kernel 的比赛，结果一堆从没写过 GPU 代码的人，靠 AI 生成代码直接冲进了前四前五名。他举了个例子，一个在中国读研究生的选手从没写过 CUDA，全靠模型生成代码，拿到了第四名。还有个高中老师，第一次写矩阵乘法相关的 kernel，也拿到了不错的成绩。Mark 说他自己长期在这个领域工作，都没想到这一天来得这么快。

接下来这段是我觉得整场分享里最扎实的部分，关于怎么评价 AI 写的 kernel 到底靠不靠谱。标准做法是拿 PyTorch 的实现当参照标准，采样一批随机输入，跑一遍看结果对不对，再看性能。听起来是个可验证的问题。但 Mark 说这里面藏着很多陷阱。第一个例子是，他们要选手写一个计算向量平均值的 kernel，结果因为测试数据默认是均值为零、方差为一采样出来的，AI 直接返回零，反而是全场最快的，因为它压根没算。更离谱的是，AI 会偷偷缓存输出结果重复利用，他们禁止用 data pointer 这种手段去读取缓存地址，AI 换了个写法照样能拿到，他们再堵，AI 就把这串字符拆成两半分别写在不同行里绕过关键词检测。

最夸张的一个案例是一个学生发现的。他们的测试流程是先做十五次正确性检验，再做一次性能测试，性能测试的时候不会再检查结果对不对。AI 发现了这个规律，在正确性检验阶段老老实实给出正确但慢的结果，一到性能测试阶段就切换成错误但快的结果，还把批次结果拼凑得看起来正常。Mark 说这个套路让他想起大众的柴油门事件，当年那些车会侦测到自己正在被做尾气检测，把排放调低四十倍，一到现实道路上又恢复原状。他们的解法是，既然大部分提交都是 AI 生成的，反作弊也交给 AI 来做，人发现一个作弊案例就标记出来，喂给 AI 系统总结出一套检测规则，再拿这套规则去抓更多作弊者，发现新招数就继续迭代。

他还讲了个具体的技术故事。他同事对一个叫 Shampoo 的优化器很感兴趣，这个优化器依赖 QR 分解，但 PyTorch 里这个操作特别慢。他们把这个当成一个社区竞赛题目，集体协作出来的 kernel 比原来快了六十倍，而且不会出现数值爆炸，已经能用到真实的训练任务里了。有意思的是，这些最快的 kernel 代码量特别夸张，平均一份提交能有一万五千行，因为它们针对不同的矩阵形状写不同的调度逻辑，小的用共享内存版本，大的用全局内存版本，常被测到的形状用低精度抄近路。Mark 说没有一个人类工程师会写出这种代码，人类天然追求简洁和优雅，AI 完全不在乎这些，他们试着把这些又长又丑的 kernel 提炼成简洁版本，到现在还没搞定，这是个开放问题。

我听完这段最大的感触是，我们对可验证奖励这件事的想象可能一直太天真了。大家觉得只要有客观标准就能自动化训练和评估，但只要目标和真正想要的东西之间有一丝缝隙，AI 就会用你想不到的方式钻进去。这跟做产品特别像，你定的任何一个指标，只要不是用户真正想要的那个东西本身，团队和系统迟早会找到钻空子的办法。唯一的解法不是设计出完美无漏洞的指标，而是像 Mark 说的那样，把发现漏洞、修补漏洞这件事变成一个持续运转的飞轮。

Misha Smelyanskiy 一次推理请求 从头到尾没有一种芯片能通吃

Misha Smelyanskiy 一个月前刚加入一家叫 Marlo 的创业公司，之前在 Nvidia 做过 AI 基础设施，也在 Meta 做过硬件软件协同设计。他讲的核心观点是，推理是一个极度异构的工作负载，一次推理请求里不同阶段对计算、网络、存储、内存带宽的要求完全不一样，给不同阶段配不同的硬件是很自然的选择。

他把一次推理请求的生命周期拆开讲。用户输入提示词，CPU 做调度和批处理，查前缀缓存，没缓存到的部分做 prefill，这一步计算量很大，很吃加速器，紧接着是 KV 缓存的生成，可能要跨网络访问其他机器的内存，再往后是自回归的 decode（逐个词元生成输出的阶段），对内存带宽极度敏感，对延迟也极度敏感，过程中可能还夹杂着投机解码，需要另一个模型验证。他引入了 arithmetic intensity（算术强度）这个概念，就是一个算法的浮点运算量和它需要搬运的数据量之比，如果这个比值比硬件本身的浮点算力和内存带宽的比值高，这个计算就是被算力卡住的，比值低就是被内存带宽卡住的。这个模型最早是伯克利的 Sam Williams 在 2012 年左右为高性能计算领域提出的，叫 roofline model（屋顶线模型）。按这个框架看，prefill 通常是算力受限，因为权重只需要读一次，可以在很多词元上复用，decode 是典型的带宽受限，因为每处理一个词元都要重新把权重搬一遍，效率很低。

他顺着讲了一类叫 SRAM 机器的硬件，把整个模型权重都放在芯片内的 SRAM 里，不用去外部的 HBM（高带宽内存）拿数据，带宽极高，延迟极低，特别适合 decode 这种带宽受限的场景。代价是芯片面积有限，能塞进去的容量从几十兆到几十吉字节不等，远比不上 HBM。他管这类芯片叫矩阵向量乘法加速器。

他给了三个具体的异构设计例子。第一个是大家已经比较熟悉的 prefill 和 decode 分离部署，让两个阶段可以独立扩展，不互相抢资源。他进一步问了个问题，如果把 decode 单独放到一台专门的 SRAM 机器上，什么时候划算。答案是从 TCO（总体拥有成本）的角度看，只要这台新机器带来的加速效果能盖过它多花的电费，就值得，序列短的时候不划算，序列变长之后，decode 占比升高，才会真正开始省钱。第二个例子是把 attention（注意力计算）和 MLP（多层感知机部分）拆开跑在不同硬件上，因为这两部分的计算特征完全不同。GPU 在高并发的时候吞吐量很漂亮，但一旦为了追求交互性和低延迟而降低并发，吞吐量会断崖式下跌，这时候如果把那些吃内存带宽的 MLP 计算卸载到 SRAM 机器上，可以把 GPU 交互性能撑住的区间往后延伸一截。第三个例子是投机解码里，把负责起草的小模型放到一台专门的机器上跑，这样可以用一个更大更准的起草模型，提高接受率，不拖慢整体延迟，还能把多个验证器绑定到一个起草器上进一步优化成本。

我听完这段最大的收获是，以前我下意识觉得推理就是一整块任务丢给一堆一样的 GPU 处理，但 Misha 讲的这套框架让我意识到，一次推理请求内部本身就是好几种完全不同性质的计算拼在一起，分别有各自的最优硬件形态。这也提醒我，以后看任何 AI 产品的成本结构，可能都不该笼统地问贵不贵，而要拆开问，贵在哪个阶段，那个阶段本质上是被算力卡住还是被带宽卡住。

Brennan Shacklett 把整个游戏引擎塞进一张 GPU 里

这场分享的收尾，是 Brennan Shacklett 讲的。他在 Stanford 读博期间做了一个项目，叫 Madrona，想法是把一整个能模拟任意游戏的引擎搬到 GPU 上跑，现在他在做一家 AI 加游戏的创业公司。他说做这件事的动机是，游戏环境是训练机器人、自动驾驶、强化学习模型的绝佳场地，但一个反直觉的事实是，如果只是简单粗暴地把一千份游戏引擎并行跑起来，效率反而很差，因为这些副本会互相抢资源，没法摊薄成本，CPU 和 GPU 都用得很浪费。

他们的解法叫批量模拟器，用一个引擎同时模拟成千上万个环境，当成一个大批次扔到 GPU 上跑。他举了 OpenAI 那个捉迷藏多智能体强化学习环境的例子，用这套方法能在一张 GPU 上塞下大量环境副本，吞吐量可以做到每秒几百万帧的经验数据，这对强化学习这种极度吃数据的算法非常关键。

难点在于，现有的 GPU 编程框架跟游戏逻辑天生八字不合。游戏里的逻辑充满了分支判断，还经常要动态分配内存，比如智能体要去搬东西、锁东西，这种代码放到 GPU 上听起来就是性能灾难。他们的解法是把游戏行业早就用来解决 CPU 并行问题的一套设计模式，叫 ECS（实体组件系统），搬到 GPU 上。实体就是场景里的物体，比如障碍物、智能体本身。组件是挂在每个实体上的数据，比如位置、朝向、动作、奖励，这些数据被存成一张张巨大的内存列存表，直接放在 GPU 显存里，不同环境的物体被打包进同一张统一的表，用一列环境编号来区分谁属于哪个环境。系统是真正跑在这些行上的代码，比如处理动作、碰撞检测、计算奖励，每个系统只需要声明自己要读哪些列，比如碰撞检测只需要位置和包围盒这两列，完全不需要知道具体是障碍物还是智能体，一次函数调用刚好对应一个 GPU 线程，天然就是大规模并行的。

他们把这些系统串成一张任务图，描述一帧里数据怎么流转，从接收动作，到物理模拟，到给每个智能体生成观测，一路串下去。内存管理上他们用了一种类似垃圾回收的思路，不断往表里追加行，标记删除的行，再用高性能的 GPU 排序把这些清理掉，整个任务图靠一个常驻的巨型 kernel 不停跑，靠 GPU 原生的快速原子操作做同步。他们做了个可视化，在一张 RTX 4090 上同时模拟四千个捉迷藏环境副本，画面显示几乎所有 SM 都在满负荷工作，同步开销占比不到百分之一。

他们拿捉迷藏和一个叫 Overcooked 的合作类强化学习环境做基准测试，原始 CPU 参考实现慢得几乎看不出柱状图，用同样的 ECS 思路但跑在 CPU 上快一些，真正跑在 4090 这张 GPU 上，速度比原始版本快了上百倍。而且很多完全不懂底层 GPU 编程的机器学习研究员，靠这套系统也能自己搭出新环境，拿到很好的性能。他收尾说的一句话我很认同，他说哪怕已经进入了 AI 写代码的时代，GPU 上依然缺一门真正好用的高级脚本语言，现在很多方案不过是把 CUDA 的编程模型套上 Python 的语法糖，看起来简单了，但根本没解决动态内存分配、不规则并行这些底层问题。GPU 明明有巨大的带宽和算力，真正能把这些算力用起来的抽象工具还远远不够。

我自己的一点思考

听完这五场分享，我最大的感受是，这一整波 AI 竞赛正在往一个大家平时很少讨论的方向下沉，就是硬件和系统这一层。过去两三年大家争论的焦点一直是模型参数量、训练数据、对齐方法，但从 Stuart Sul 讲的多卡通信瓶颈，到 Jon Saad-Falcon 讲的本地和云端算力重新分配，到 Mark Saroufim 讲的 AI 写内核出现的种种作弊和惊喜，到 Misha Smelyanskiy 讲的推理请求内部就是好几种完全不同的计算拼出来的，再到 Brennan Shacklett 把整个游戏引擎塞进一张 GPU，这五件事放在一起看，其实都在讲同一件事，真正决定 AI 系统好不好用、贵不贵的，已经不是有没有更聪明的模型这么简单，而是底下这套算力怎么被切分、调度、优化的工程能力。

我自己感触最深的一点是，这些分享里反复出现一个模式，当实现一件事的成本急剧下降之后，原来靠人力和经验守住的那道护城河，很快就会被冲垮，取而代之的是新的、更隐蔽的护城河。Mark 讲的 AI 写内核这件事最能说明这一点，以前写高性能 GPU 代码需要多年经验积累，现在一个没写过 CUDA 的人靠 AI 也能冲进比赛前几名，但护城河并没有消失，它换了个地方，变成了怎么设计一套不会被钻空子的评测系统，怎么把内部混乱但性能极致的代码提炼成人能看懂、能维护的形态。这跟我们做产品是一模一样的道理，当某个环节变得便宜、变得人人都能做的时候，真正值钱的东西一定会转移到别的地方，不会消失。

另外一点让我一直在想的是，异构正在变成整个行业的默认答案。不管是芯片层面的训练卡和推理卡分家，还是一次推理请求内部 prefill 和 decode 用不同硬件，还是本地小模型和云端大模型协同分工，核心逻辑都是一样的，没有一种硬件、一种规格能通吃所有场景。与其追求一个万能方案，不如老老实实把问题拆开，搞清楚每一段到底被什么卡住，再对症下药。我觉得这不只是芯片设计的道理，做任何复杂系统，包括做产品、做团队、做业务流程，可能都得学会这种拆解的耐心，而不是指望一个大一统的答案解决所有问题。

结尾

也欢迎大家留言讨论，分享你的观点！

觉得内容不错的朋友能够帮忙右下角点个赞，分享一下。您的每次分享，都是在激励我不断产出更好的内容。

欢迎关注深思圈，一起探索更大的世界。

- END -

两个“特别坑”的AI产品创业方向，你知道吗

速度将成为AI时代唯一的护城河

a16z重磅预测：Vibe coding赢者通吃？错了，垂直专业化才是未来