通信人家园

 找回密码
 注册

只需一步,快速开始

短信验证,便捷登录

搜索

军衔等级:

  少将

注册:2016-11-17275
跳转到指定楼层
1#
发表于 2024-10-16 15:21:28 |只看该作者 |倒序浏览
渣B zartbot
TL;DR

昨天看到信息平权的一篇《新高 vs 砍单》, 再加上前几日Oneflow翻译了《2美元/小时出租H100:GPU泡沫破灭前夜》. 然后mackler在知乎的一个回答《人工智能的发展可能会对芯片行业带来哪些变革影响?》[1]

恰逢但斌总在和某经济学家吵架,想起但总几个月前还转发了渣B写的《谈谈三万亿的破绽》,似乎也该更新一下了?

640?wx_fmt=png&from=appmsg

然后就是一个关于NV下一代 Rubin 288 in-rack的图, 到时候供电会是一个非常困难的事情, 配合SemiAnalysis在科普数据中心供电《Datacenter Anatomy Part 1: Electrical Systems》[2], 又勾起了小时候帮家里老爷子一起去推10KV开关柜手车的回忆, 那么就再来码点文字吧.

大致的结论(或许是一个暴论): NV在技术演进上已经遇到了极大的困难, 无论是在工艺上B200的COWOS的问题, 还是在GPU体系结构上, 然后在供电和散热上都面临着很大的瓶颈.

大A的国庆FOMO给了很多梭哈的人一个非常深刻的教训, 而GPU的FOMO下未来如何走呢? 本文将继续对比互联网时期的Cisco谈一些观点,反正是个渣B乱扯,看客们一笑了之:)

全文目录如下

1. 谈谈NV遇到的问题
1.1. 工艺上的问题
1.2. GPGPU体系结构上的问题
1.2.1 牧本摆动是否继续?
1.2.2 从“定制”开始的GPU
1.2.3 可编程的演进
1.2.4 回到“定制”
1.2.5 CUDA是护城河,还是拖累
2. ScaleUP的执念
2.1 Blackwell的散热复杂度
2.2 Rubin Next的供电复杂度
2.3 OneGPU的执念和互联的瓶颈
2.4 谈谈Cisco当年的ScaleUP
3. 散落一地的龙珠
3.1 新高 vs 砍单
3.2 龙珠
1. 谈谈NV遇到的问题
1.1. 工艺上的问题
前段时间CoWoS-L的问题,导致Blackwell重新流片

640?wx_fmt=png&from=appmsg

本质的问题是单个Die Size被约束在附近, 既要连接大量的HBM,又要连接大带宽的NVLink ScaleUP网络, 系统扩展性到了极限, 于是被迫从单Die结构走向了多Die MCM-GPU

640?wx_fmt=png&from=appmsg
但是MCM又必须要拿出1个边(Blackewell)或者2个边(Rubin)来做D2D互联, D2D互联带宽需求也非常大, 以前整理过相关的资料《英伟达GB200架构解析4: BlackWell多die和Cache一致性相关的分析》, 自然就把所有的压力压在了封装上.

640?wx_fmt=png&from=appmsg
B200上因为这些约束采用了CoWoS-L, 但是由于翘曲等问题影响了整个封装的良率,被迫返工.

640?wx_fmt=png&from=appmsg
其实渣B有个观点就是,当一个芯片特别依赖于先进的工艺时, 可能整个系统的架构就遇到瓶颈了. 需要从算法和体系结构上来平衡解决这一类的问题了.

1.2. GPGPU体系结构上的问题
1.2.1 牧本摆动是否继续?
牧本摆动(Makimoto's Wave)是指IC有规律的在“定制”和“可编程”之间变化, 循环周期大概为10年.

1.2.2 从“定制”开始的GPU
当年图形渲染是相对固定的软件流程,如下所示:

640?wx_fmt=png&from=appmsg

当时的霸主SGI将工作站级的技术做成一张很复杂的扩展卡IrisVision试图进入PC市场,售价5000美金,大概跟现在4090的价格也差不多了.

640?wx_fmt=png&from=appmsg
然后3Dfx的几个创始人快速的捕捉到EDO内存价格快速下降的趋势, 利用通用CPU来做几何处理,而将光栅/像素纹理填充这些内存密集型的处理Offload到加速卡上

640?wx_fmt=png&from=appmsg

同时期的英伟达的Riva TNT基本上也和3Dfx Voodoo系列一样的架构

640?wx_fmt=png&from=appmsg

GPU的诞生恰好在25年前, 1999年10月发布的GeForce256将几何处理也从CPU Offload出来构建了T&L Unit.

640?wx_fmt=png&from=appmsg

1.2.3 可编程的演进
GeForce 3开始, Nvidia开始在Vertex Shader(VS)添加了一些可编程能力. 同期的ATI Radeon 9700第一次将24bits浮点可编程引擎引入Pixel Shader(PS)并率先支持了DX9. 但是通常VS和PS都按照1:3的比例固定配比,在不同的画面内容下固定配比的使用率.

Stanford在2004年发布了一篇论文< Brook for GPUs: Stream Computing on Graphics Hardware > 通过扩展C并实现了一个BRCC的编译器,利用当时Nvidia GeForce 6800和ATI Radeon X800XT 实现了SGEMV矩阵运算、FFT等五种通用计算的算法,然后有一些做期权交易的机构就开始了在上面进行期权相关的计算..

然后针对这些问题, Nvidia在2006年发布了第一代的可编程通用GPU GeForce 8系列,当时的宣传就是统一VS和PS构成的Unified shader model.

真正的CUDA成熟和完全可编程要到2010年的Fermi架构的GPU出现. SIMT的抽象使得它在超算和通用图形处理两条线上都走的特别顺利. 也逐渐出现了深度学习使用GPU加速的AlexNet.

1.2.4 回到“定制”
2016年Google发布的TPU给Nvidia带来的很大的压力, 正好从2010年发布Fermi,到2017年的Volta加入TensorCore,再加上2018年发布的Turing加入光追引擎, 计算和图像两套架构也分拆了, 图形Turing->Ada->, 计算Volta->Ampere->Hopper->Blackwell, Unified的故事讲不下去了, 和牧本摆动周期类似,NV又一次回到了“定制”的路线上.

围绕着TensorCore的流水线架构似乎显而易见

640?wx_fmt=png&from=appmsg

另一方面, 我们来看每一层神经网络的架构, 暂且不谈Transformer, 以更加通用的视角来看, Pre LayerNorm, Softmax Classifier, Post MLP等结构基本上是确定的, 只是中间的Attention计算可能还会引入一些旁路引擎或新的架构. 当然这里还有一点变数,例如KAN/MoE等...

牧本摆动周期恰好又在此刻上演...

1.2.5 CUDA是护城河,还是拖累
从图形渲染来看, Nvidia当年靠着微软支持的D3D逐渐的蚕食当年的霸主3Dfx Glide3D, 再到和AMD(ATI)的竞争快速发展到完全可编程的CUDA时代一统江湖. 而如今在一个体系结构即将出现变革的时候, CUDA即是护城河, 也成了拖累, 既要兼容当年的生态和客户长达十年的使用习惯, 又要折腾一些新的DSA.

例如Hopper的TMA/WGMMA, 直到发布两年了才有TK/FlashAttention3这样的工作, 并且还要大量NV原厂的人配合开发, 我不确定Blackwell发布后,新的微架构是否能够很快的转换成生产力.如今NV对B系列的微架构还是讳莫如深, 官方的架构白皮书一直没有出来, HotChip这些吹水会上也不披露, 事出反常必有妖

转向MCM—GPU架构后, CUDA SIMT的编程抽象能力会进一步减弱, 具体可见《英伟达GB200架构解析4: BlackWell多die和Cache一致性相关的分析》

其实后续关于CUDA的拖累还很多,  围绕着Warp的调度, 访问内存的流水线, Tiling的复杂度, L2Cache的干扰影响等, 以及NVLink上带来的流量冲击和ScaleUP域变大后的长尾延迟的问题等, 还有多个GB200操作系统间内存的抽象, 可靠性相关的问题, 故障宕机后的迁移热备份的问题等....

对极大带宽的ScaleUP的追求, 对One GPU抽象的偏执, 其实本质上就是没有放下CUDA生态的决心而产生的执念罢了. 后面也来谈谈当年Cisco不想放弃IOS的执念带来的一堆问题.

2. ScaleUP的执念
NVLink确实是NV的护城河, 150GB/s/mm beachfront是AMD的5x. UALink上224G Serdes或许能够帮AMD追回来不少?

640?wx_fmt=png&from=appmsg

进一步的卷ScaleUP是一个很聪明的策略, 既能带来大型机那样的高利润,又能显著拉开和对手的差距, 但是很多事情会事与愿违. 下面从散热/供电以及当时Cisco的ScaleUP的故事三个视角来谈谈.

2.1  Blackwell的散热复杂度
看到微软POC的GB200机柜, 液冷机柜比GB200机柜还大,总有点买椟还珠的感觉.

640?wx_fmt=png&from=appmsg

按照NV的设计可以多个机柜共享一个液冷单元, 但是整个系统的占地面积来看, 总觉得有点奇怪 18个机柜 10个放互联,还有两个额外的制冷单元, 实际计算机柜只有8个.

640?wx_fmt=png&from=appmsg

2.2 Rubin Next的供电复杂度
对于散热渣B不懂,暂且认为NV可以搞定. 而对于供电, 渣B很小的时候就跟搞电气的老爷子当童工, 基本上10KV以下的输变电这些东西都玩过.

前几天微信群里面看到一个猜测Rubin 288卡单柜的图. GB200 NVL72单机柜功耗为120KW, 简单点算Rubin单芯片应该包含4个Die,简单估计功耗大概为B200的2倍, 单柜288卡来估计,整个机柜功耗接近1MW.

一般来说城市内通常采用10KV中压(国内叫它为高压以区分220V/380V低压)输变电设备

640?wx_fmt=png&from=appmsg
中压的配电柜通常是手车式的断路器,非常笨重的一个手推车的结构

640?wx_fmt=png&from=appmsg
然后再由低压配电设备分发到不同的包间, 最后由列头的动力柜分发到PDU上. 如果单个机柜接近1MW, 按照低压三相380V来算, 那么光是这个断路器/母排馈线的电气间歇等就要占用一个机柜. 还要考虑一下功率补偿的问题需要一个电容屏和自动补偿仪. 然后再母排连接到配电箱, 配电箱内多个空气开关连接到PDU, 馈电的母排要怎么连, 断路器配电柜这些东西的占地面积, 以及防止因为电源过载导致的整个机柜掉电风险, 总觉得这条路很难...

国内还搞过一些高压直流, 国外还有48V直流供电等技术, 但是总觉得对于单机柜1MW的负载, 再配合训练时模型的同步启动停止带来的对供电基础设施的冲击, 这件事好难...

2.3 OneGPU的执念和互联的瓶颈
o1的出现一方面宣告了Training Scaling-Law接近终结, 而对于推理Scaling-law,MCTS一类的算法或许用小于70B的模型收益更高, 那么NV当时讲的NVL72 for 1.8T MoE的故事是否还能持续下去?

ScaleUP堆成这样,大概只是不肯放弃CUDA,需要OneGPU抽象的执念. 但是业务真的需要么? 或许只是因为生态的执念罢了.就像季宇在知乎上回答的

640?wx_fmt=png&from=appmsg
GPU大型机的故事如何通过消费级硬件替代, 然后再进一步转移到端侧才是Scaling正确的演进方向, 特别是从推理Scaling的角度来看.

NVLink和CUDA, 即是优势, 又是累赘.. 或许老黄自己也清楚,但是下一步怎么走值得期待...

2.4 谈谈Cisco当年的ScaleUP
思科从单芯片单进程的IOS软件转发路由器起家, 到后面也是在90年代中期通过多个处理器通过总线互联构建的ScaleUP构建了7500系列路由器. 大概跟现在AMD/Intel的GPU通过p2p互联类似,在应对1995年开始的互联网快速增长时, 恰逢其时的推出了带有交换背板的GSR12000系列路由器, 但是还是要维持单个IOS系统的软件界面.

和NVL72如出一辙的在机柜的中间放置了交换矩阵. 上下各16张业务卡

640?wx_fmt=png&from=appmsg
但同一时刻, Juniper没有IOS那么多负担, 很快的作出了M40系列路由器并也占据了不少运营商级路由器市场并很快上市.  而Cisco因为IOS操作系统单进程的问题和转发性能等一系列问题, 直到2004年才另起炉灶构建了基于IOS XR的分布式集群CRS-1, 它基于一个光交换的结构

640?wx_fmt=png&from=appmsg
机柜之间采用光互联

640?wx_fmt=png&from=appmsg
而这些又和NV未来的光互联不谋而合

640?wx_fmt=png&from=appmsg
但我想说的是,当时Cisco在CRS-1上并没有获得那么好的可扩展性,分布式系统的各种容错需求使得其管理平面的复杂度成倍上升, 而最后这样的大集群也逐渐演进到了多个小盒子构建的分布式系统上.

640?wx_fmt=png&from=appmsg
而异构拓扑的故事在同一个人身上又一次出现, 在英伟达的首席科学家Bill Dally,在当年创建了Avici公司通过3D-Torus互联来构建Tbit级路由器, 后来跟华为合作了一下搞了NE5000然后就很快的消失了.

640?wx_fmt=png&from=appmsg
而如今他似乎又在提起DragonFly的拓扑, 我并不觉得这条路是对的.

640?wx_fmt=png&from=appmsg
对称是一种美, 可惜很多人不懂. 然后久合必分的故事又会再一次上演.

3. 散落一地的龙珠
3.1 新高 vs 砍单
昨天受ASML的影响, 半导体普遍下跌, OAI和微软都Show出了B200的样机, Google昨天也拿出了GB200的测试机柜, NV在B系列发布后的业绩是否能给股价创新高? 或许没人知道, 从技术上它的未来演进遇到了很多难题, 但从市场上流动性的泛滥导致的资产荒下, 说不定乘着AI的风口它还能继续狂飙? 人的非理智行为是不可预测的.

另一方面快速的迭代也会带来反噬, 例如前两年抢购GPU的合作伙伴, 面对B系列的上市和H系列租金快速下滑的投资回报率的问题,再加上NV快速的迭代, 销售端的反噬可能来得更快一些.

AI时代的效率提升对于经济的冲击或许更大, 新晋诺贝尔经济学奖获得者阿西莫格鲁的一些观点值得去看看,他估计未来10年AI对TFP的增长上限不超过0.66%. 当然阿西莫格鲁在经济学家这个圈子里也是一个争议很大的人物. 但是财富的转移和不平衡的发展或许在市场结构下也会进一步反噬AI的发展, 而这些并不是以往的反垄断手段能够解决的, 虽然NV现在也被反垄断盯上了, 但是未来更需的是技术上的引导,更加平衡发展的系统.

3.2 龙珠
虽然不能预测NV的市值, 但是我们这些做技术的人可以预测未来的发展路径, 看到NV已经遇到的瓶颈然后会心一笑的绕开.

当年Google的三驾马车MapReduce/BigTable/GFS在消费级的X86上构建了大规模计算能力, 阿里当年的飞天5K也把小型机赶出了历史的舞台. 而下一次因为买不起NV的小型机(8卡/16卡ScaleUP的DGX)或者大型机(NVL72)而带来的系统改进的故事还会继续上演, 特别是在推理需求百万倍增长的时候. 而散落一地的龙珠有哪些呢? 随手凑7颗吧

1 是否真的需要那么先进的工艺么? SRAM并没有缩放多少, 算力密度进一步上升的空间也有限
2 是否真的需要HBM么? 当年3Dfx EDO内存的故事还会通过另一种形态的便宜点内存上演么?
3 基于消费级的芯片如何堆起大规模集群?
4 牧本摆动下的GPU体系结构演进该如何?
5 像MapReduce那样的, 针对大模型训练和推理降低ScaleUP需求的算法在哪里? 特别是o1带来的一些推理上的变化,使得推理阶段用小模型大并行成为一种可能?
6 ScaleUP极致的带宽需求真的没有别的办法了么?
7 移动端推理和云端的协同呢?
大概已经有了一些答案, 当然在这条路上, 看到国内很多DSA的厂商围绕着当前的模型架构, 少了一些通用泛化的远见, 多了几分人肉写算子的酸涩, 如同那几个人肉做蛋白质结构的xx, 或许这些才是最先被AI淘汰的...

举报本楼

您需要登录后才可以回帖 登录 | 注册 |

手机版|C114 ( 沪ICP备12002291号-1 )|联系我们 |网站地图  

GMT+8, 2024-12-23 00:34 , Processed in 0.236289 second(s), 19 queries , Gzip On.

Copyright © 1999-2023 C114 All Rights Reserved

Discuz Licensed

回顶部