恰逢SemiAnalysis最近有一篇文章在谈奥特曼挖TPU的人和一个七万亿芯片的故事. 那么今天就来详细写写三万亿技术上的破绽以及未来AI Infra的演进, 这是一个系统性的工程, 不要单单去看GPU/DPU/交换机这些芯片和互联, 还要去看计算平台和模型算法几个维度来评估, 可惜XX们大概只知道第一做啥就抄啥, 然后还非得在自己抄作业那个领域屎上雕花...
本文从几个方面来讨论三万亿的破绽, 一方面是从GPU自身的体系结构上, 我们分析了GPU出现然后统一图形可编程业务构建GP-GPU,再到HPC和AI遇到问题后出现的架构分叉,最后再来探讨一下Hopper这一代的架构缺陷. 然后再分析互联业务上RDMA遇到的各种难题以及片间互联的一些问题.
然后我们再来看看奥特曼准备挖TPU来讲的七万亿故事背后的TPU架构, 最后展望一下AI Infra演进的方向, 这篇字有些多, 列个提纲放前面, 供大家跳着读.
1. 从体系结构看Hopper的缺陷
1.1 GPU的体系结构演进
从体系结构的视角看, GPU的诞生一开始是为了解决访存的问题, 1994年的时候整个图形渲染流水线基本上已经固定成为开放的OpenGL标准
但是我们可以看到整个流水线上有大量的内存访问, 486时代的CPU浮点运算能力已经强了很多, Doom一类的3D游戏逐渐开发出来, 伴随着EDO内存频率提升到50MHz,低价大带宽的内存使得图形处理Offload成为可能, 于是3Dfx诞生了.
它很巧妙的把纹理单元和光栅化这些需要大量访问内存的操作从CPU里面Offload出来,继续利用主CPU的性能优势实现VertexShader. 内存带宽通过2way/4way interleave提升
黄教主也是在差不多这个年代创立了Nvidia, 第一款芯片NV1非常激进,采用二次曲面,但和工业界常用的多边形渲染算法不同, 另一方面集成了声卡和游戏手柄的支持. 大概是这件事情的教训,黄教主明白了:“ I don't need to change the world overnight. I will change the world over the next 50 years." 于是很快的调整路线, 兼容DirectX5和OpenGL1的Riva128在1997年发布了. 并且在TNT这一代通过多重纹理引擎在性能上击败了3Dfx Voodoo2成为当时最快的3D加速卡.
第一块GPU来自于1999年的GeForce256, 新增了一个名为光照变化单元(T&L Unit),实质就是把顶点处理和几何变换等功能全部Offload到了显卡上，而CPU只是简单的描述3D空间的三角形和传递纹理即可。
但此时还是一个固定的可配置的ASIC,并没有太多可编程的能力. 2001年发布了一篇SIGGRAPH的论文< A User-Programmable Vertex Engine >. 论文中很明确的讲到了需要Vertex Shader可编程的原因：由于GPU性能的快速增加，对于新的图形API的需求越来越多，各种计算的组合使得GeForce 256那一代的可配置能力要求爆炸性的增加，到最终变成了API对可编程硬件的需求。
于是第一个支持Vertex Shader可编程的GPU GeForce 3发布了
GeForce3的Vertex Engine在考虑到易用性方面，只是在整个几何计算流水线中暴露了一小部分的可编程能力，提供了一系列SIMD的浮点计算指令，不支持分支，提供固定的处理延迟，如下所示：
nVidia支持DX9的GeForce FX直到2003年才出现，Vertex Shader新增Branching的能力，支持单个程序65536条指令，循环深度也支持256个， 所以顺便也支持了Dynamic flow Control来应对整个Pipeline的性能问题，同Radeon 9700一样GeForce FX也整合了8条128bit浮点像素渲染管线，但它支持了CineFX最大128bit浮点的精度。
伴随着GeForce 6的发布，Vertex Shader和Pixel Shader都支持了完整分支、循环、预测等功能实现，最终一个完全支持高级渲染语言(Cg, DirectX HLSL, OpenGL GLSL)的平台诞生了,而HDR等特效也引入了主流游戏平台.
但是又有一个问题来了, 不同的渲染场景Vertex Shader和Pixel Shader负载不一样
然后又引入了Geometry Shader后, 发现整个流水线都有一堆可编程的需求
是否可以整合一下呢?
于是GP-GPU就逐渐诞生了.
1.2 GP-GPU体系架构, CUDA可编程
正是这一系列的思考，2006年nVidia 革命性的Tesla架构芯片GeForce 8发布了
它采用了将8个标量计算核(Streaming Processor,SP)和2个特殊函数计算单元(SFU)配合一些Cache和共享内存整合构成一个Streaming Multiprocessor(SM), 然后采用SIMT的方式进行，将32个Thread打包成一个Warp，而一个SM又可以同时管理24个Warp. 然后两个SM共享一个Texture Unit和一个Geometry Controller构成一个Texture/Processing Cluster.
SIMT执行方式类似于SIMD,一条指令可以同时对多个数据处理，但是不同的是，由于每个执行的SM都可以有独立的Branch的能力，所以每个thread编程更加灵活，使得我们可以用通用的C语言代码来描述单个thread的执行。
正是由于新的架构极其灵活的可编程能力，一个名为CUDA(Compute Unified Device Architecture)的编程框架也跟随着G8x一起发布了，它受到了OpenMPI的很多影响，采用Grid、BLock、Thread的方式组织并行计算任务，使得它们和硬件的处理核心完全解耦了，最关键的是它只是给标准的C语言增加了少数几个关键字，大量熟悉MPI的程序员基本上花上两三周的时间就可以完全动手进行CUDA编程。
而第二代Tesla GT200核心发布，支持双精度浮点，更多的线程使得它第一次可以真正的走进HPC的市场了。
SIMT虽然很巧妙, 通过32个Thread并行执行,
并通过流水线并行了访问内存的延迟
但是遇到一些分支计算的情况, 一开始只能Warp Vote的功能
然后构成了一个SIMT控制路径和SIMT数据路径的架构
但随着SM单元增多,整个体系架构上Warp调度器出现了几次修改
例如Fermi的调度器如下
随着FP64的支持NV逐渐在HPC打开局面, GPU的架构又一次面临调整. 例如动态网格的一些算法
简而言之就是原来Kernel函数只能由CPU调用GPU执行，GPU在这个模式下当一个协处理器。而支持Dynamic Parallelism后GPU在一个Kernel函数内可以再调用一个Kernel函数，这样业务的执行就变得更加灵活，甚至还可以玩Kernel函数的递归执行了
例如HPC中常用的lU分解, 在Fermi这一代还需要CPU控制,有了Kepler的动态并行, 又一次把CPU的工作Offload了
1.3 图形/HPC/AI众口难调,架构开始分裂
面对移动端和图形业务, FP64和ECC这些HPC用的东西似乎也不需要, NV的架构开始逐渐分叉, 第一次分叉在Maxwell和Pascal这两代上. Maxwell针对移动端和图形业务砍掉FP64算力, 而Pascal开始逐渐针对深度学习业务构架加速, 加回了FP64算力和增加了NVLink并支持了HBM.
调度器上Kepler在一个SMX内堆了192个CUDA Core,但多任务调度效率并不好, 在Maxwell中改为4组32个Cuda Core构成一个SMM，到了Pascal进一步改为2x32 CudaCore构成的SM
Pascal这一代分成了GP100针对计算业务, 而GP104(GTX 1080)针对图形业务, 通过每个SM增加一个一个PolyMorph Engine 3.0构成一个TPC(Texture Processing Clusters),然后5个TPC共享一个光栅化引擎构成一个GPC.
但是到了Volta这一代, 又发现2x32 Cuda Core又少了, 然后又加回到四组
这一代为了针对更灵活的Branch支持能力, 每个thread有了独立的Program Counter和Stack
伴随着Google TPU的竞争和深度学习中大量的矩阵运算, Tensor Core出现了
但是英伟达时至今日还是想SM计算这一块尽量能够统一, 例如Turing这一代, 针对图形业务发展光线追踪的RT Core, 但是很多其它运算还是复用Tensor Core. 核心内分为4个区域，每个区域有16个FP32 Core，16个INT32 Core 2 个TensorCore，一个Warp Scheduler一个Dispatcher。同时包含L0 I-Cache及64KB寄存器文件，4个区域共享96KB L1 DCache/Shared Memory.同时针对光追业务，每个SM增加了一个RT Core
此时英伟达已经开始遇到内存带宽的瓶颈, 例如Turing LD/ST UNIT翻倍, Cache也在开始加重
Tensor Core虽然性能较Volta增强了,但总要维持一个4的维度去兼容图形业务. 在Ampere这一代进一步在提高内存搬运的效率。
但大体结构上还是维持一个SM共享的L1$, 四个独立的Cuda CLuster构成, 并且每个配置一个Tensor Core，而针对商用图形卡的GA102砍掉了FP64增加了RT Core
这一代在以前每个thread有了独立的PC和Stack后, 进一步在构建异步编程的生态, 实现了异步的Barrier和异步的内存拷贝。
1.4 Hopper的缺陷
前面谈到一个SM内部有4个区域,每个区域都有独立的Tensor Core,但是为了兼顾图形业务, TensorCore的一个维度只能是4. 为了针对大模型大矩阵的乘法, 英伟达在Hopper这一代临时贴了一个胶布
通过Warp Group(WGMMA)指令来同时调度单个SM内四个warp一起进行矩阵乘法运算, 但是此刻就需要更好的异步内存访问能力和更加精细化的编程.
TMA的引入配合TensorCore以及Warp Group调度, 事实上这样的编程也代表着SIMT走向终结. 以前GPU上使用wmma.mma.sync 和 mma.sync在单个warp内同步的将数据块喂给Tensor Core并等待结果, 而wgmma.mma_async则是把分散在4个区域的128个线程糅在一起, Memory layout和bank conflict的控制变得异常复杂
进一步来看, CUDA SIMT架构已经走到了尽头, 计算性能无法进一步提高, 异步访问内存带来的编程复杂性进一步提升, 在Blackwell这一代, 抛开FP4这些指标看，就FP8/FP16 Tensorcore的性能来看，两个Die 实际性能提升了2.27倍(2250/990TFLOPS)，也就是说平均每个Die来看只提升了13.5%, 也就是说英伟达已经遇到瓶颈了.
为了应对CUDA原有的编程模型和习惯, 英伟达针对MCM-GPU也做了好多年的工作
2. GPU互联结构的的缺陷
2.1 互联协议的分析
从互联结构上来看, 本质上是片上网络和数据中心网络如何紧耦合的问题
数据中心以太网和TCP/IP的生态在那里已经几十年了, 是那么容易通过IB掀翻的么?英伟达其实自己也明白, ComputeX上就看到了它的妥协
本质上我们需要从主机内(Intra-Host)和主机间(Inter-Host)通信协议上来看待这个问题, 正如我在NetDAM的论文里讲的, 内存墙在那里,你会如何处理
既要容量又要带宽该如何处理呢?
PCIe作为主机内(Intra-Host)各扩展卡和CPU通信的标准已经存在了接近20年，基于PCIe的直接内存访问DMA也被广泛的用于芯片间的通信. RDMA over Ethernet简单的将DMA操作扩展到了主机间(Inter-Host)通信网络。但是go-back-N的策略对丢包非常敏感，因此DCQCN这一类基于PFC的可靠传输和拥塞控制机制被开发出来，但是随着网络规模增大及VPC等Overlay网络架构的出现，这样的架构将会带来巨大的延迟和抖动。因此像Fungible一样的厂商逐渐开始实现基于硬件TCP卸载的iWARP技术，与此同时阿里巴巴的HPCC和Intel的NDP也被开发出来用于消除PFC带来的影响。但与此同时，通过一些研究发现，PCIe本身由于RootComplex的设计和驱动的问题，也会带来巨大的延迟，因此GenZ、CCIX、CXL等总线被开发出来用于解决这些问题。
但是我们重新审视了主机内(Intra-Host)和主机间(Inter-Host)通信协议，主机内通信由于延迟可控丢包可控通常采用共享内存(share-memory)的模式，而主机间通信则通常采用消息传递(MPI)的方式，因此两者在设计原则上有根本性的不同：
-
拓扑：主机内通信协议通常是有固定的树状拓扑的，并且设备编址和寻址相对固定(例如PCIe使用的DFS),消息路由相对简单。而主机间通信协议通常是非固定的并且有多路径支持和Overlay支持会使得报文调度更加复杂。当然有一些片上网络总线例如AMBA CHI可以实现多跳通信，这也是我们为什么在处理器架构中推荐基于ARM Neoverse2的Octeon CN10k的原因。但是CHI总线更多的用于片上网络设计，对于跨芯片传输和跨主机有丢包和延迟的以太网传输则不适合。 -
延迟: 主机内通信协议通常只有小于200ns的固定传输延迟，而主机间以太网通常为数个微秒的延迟，并由于包调度和多路径及拥塞控制等原因会带来不确定性. -
丢包: 主机内通信通常由于仲裁器和Credit Token调度通常不会出现丢包，但是在主机间通信经常由于拥塞或者中间节点失效导致丢包，实现不丢包的以太网代价巨大并且成本过高而且网络利用率和复用率较低. -
一致性：在主机内通信由于往返延迟非常低，因此通常采用基于MESI一类协议的缓存一致性协议实现共享内存的通信。而在主机间高延迟的情况下实现一致性会非常困难，也带来了编程模式的挑战。 -
保序: 通常主机内通信为了内存一致性是需要严格保序的，从物理实现上也相对容易，虽然PCIe也支持Relax Order但是用处并不是很大。而主机间通信由于多路径和一些网络安全设备调度的因素乱序时常发生。 -
传输报文大小:由于主机内通信实时性、低延迟和一致性的需求下，通常一个flit不会放的太大，大多数协议都最大维持到一个CacheLine的大小.再大会影响其它设备的实时通信，而且很多协议对于ACK、NACK有严格的时序约束，而以太网通常是1500B甚至9000B的传输。
2.2 RDMA瞎折腾的十年
详细的内容可以阅读专题
RDMA针对HPC的小数据量低延迟场景取得的性能收益在AI时代为什么会遇到那么多问题呢? 为什么会在拥塞控制上遇到那么多麻烦呢? 下面这图理清楚了这笔糊涂账
本质上的问题在NetDAM的论文也讲清楚了:
RDMA实际上是一种直接将主机内DMA映射到以太网或者IB上的处理机制，同样继承了PCIe已有的go-back-N和QueuePair Credit机制，但是由于主机侧PCIe的原因会带来一些Cache操作的复杂性和总线争抢的不确定性，因此尾部延迟会非常高。同样在以太网上由于Lossless的需求使得交换机和各种控制协议设计会变得复杂并进一步加大了延迟。
芯片架构上, Mellanox也在不停的应对这些变化折腾
具体的内容可以参考
另一个问题就是生态上的处理, 为什么Infiniband无法替代Ethernet? AWS很早就给出了答案
《RDMA这十年的反思3：AWS HPC为什么不用Infiniband》
本质上AI用RDMA有两个需求, 一个是CPU bypass 做GDR, 另一个是兼容MPI的一些使用习惯, 但是同样还需要CPU在关键控制路径上。
演进到今日,英伟达在搞(GPUDirect Async–KI)
本质上还需要一个RDMA协议么? Yet Another GPU Kernel based TCP可以么?如果不可以,那么?
2.3 谈谈UEC和UALink的缺陷
UEC在做什么,有些人家组织协议标准保密的事情就不多谈论了. 大概的意思就是它代表了交换机厂商的屁股和工业界普遍的端网协同的错误认知, 实际上一个很简单巧妙的算法就可以完全解决当下RDMA遇到的拥塞控制难题,在以太网上大规模组网.
一方面的问题是它过分依赖于Libfabric的生态, 另一方面是所有的厂商出发点是克隆一个Infiniband, 这是导致整个组织走偏的根源. 兼容标准的RDMA Verbs才是能够走下去的根源.
当然这是一个工业界非常难的问题, 当今能够完全搞定这个算法的全世界只有一个团队. 英伟达或许现在明白了Window based CC, 但是多路径上和Google一样面临拥塞和选路的两大难题. 完全的NIC Driven不依赖任何交换机的支持怎么做得到, 我打赌英伟达/AMD/博通/Google/Intel都想不到, 事实上看到Google在PLB后的波塞冬折腾, UEC里面的AMD和BRCM两套拥塞控制算法, 以及英伟达跟我的交流, 他们都没有得到精髓.
这句话只有完美解决了这个问题的人才有资格说出来, 由于涉密就不多谈了.
对于完美的定义:交换网利用率高于97%, 拥塞算法对交换机无任何依赖,PFC和ECN都不需要,PacketSpray也不需要交换机支持,同时AlltoAll incast情况下GPU 128打1 流量间差值小于100Kbps.
例如你们捧着的Meta只能Call for action
“不是,不要误会, 我不是针对你,我是在说在座的各位....”
至于UALink本质上就是AMD InfinityFabric和博通PCIe Switch一起的开源实现, 个人一直对于Cache一致性在GPU场景下是否真的需要持怀疑态度, 即便是NV的GraceHopper的实现也是有取舍的. 当然UALink的好处也是有的, 至少可以直接拉通CPU Core, 这是它巨大的价值.
对于ScaleUP网络而言,本质上我们需要回答一个问题,当构建了UALink 1024卡集群或者CXL 4096卡集群规模的时候, 延迟本身还是一个问题么? 或者所定义的只是一个具有Load/Store语义的互联系统, 这个需求是否真的存在?
说个重点, 如何保证256B的Flit在102.4T或者204.8T的交换机上保持LineRate? 这就是UALink的死穴.也是NVLink的死穴. 所有直接Load/Store上大规模交换网的死穴.
其实英伟达的GPS/PROACT/FinePACK才是演进的方向.
也难怪Jim Keller在嘲讽
详细的内容参考:
3. 它山之石Google TPU + Pathways
3.1 矩阵乘法的效率
专门针对AI设计的芯片,其实只需要回答好一个问题, 如何更加高效的进行大尺度的矩阵运算. Google在2018年的一篇文章《What makes TPUs fine-tuned for deep learning?》就讲的很清楚, 所以无论是Google TPU还是AWS Trainium 都采用了脉动阵列的方式来构建乘法器, 然后外挂一些标量的控制核. 而Jim Keller的Tenstorrent则是一个更加宏观的大型以太网互联的脉动阵列.
另一方面,你可以关注到即便是在NV的GPU中, 算力的提供也开始大量依赖于TensorCore
3.2 弹性的互联架构
Google TPU的另一个值得关注的点是它的弹性互联架构.详细可以参考
用不用OCS只是术, 而真正的道是脉动阵列配合Torus-Ring的拓扑, 并根据算子的需求构建不同的Cube
TPU的互联最重要的是如下两块:
3.3 灵活调度能力
对于一个大规模AI集群的多任务调度, 大多数人包括英伟达或许只看到Borg然后抄出来了K8S和容器, 但是物理上的实效规避和热迁移等能力始终搞不懂. 一个很简单的问题, NVLink断掉一根或者某个GPU故障对NVL72的影响是什么? RDMA网卡故障后整个计算实例是否能够热迁移? 当然简单粗暴的另外找个机器重新拉起集群Job就行了? 有没有更高效的做法呢?其实Google给出了很多有意义的见解.
另一方面是算子编排上, Pathways的调度框架直击了当下基于MPI的SPMD生态
MPMD才是正路啊
然后Pathways使用了自研的PLAQUE来协调多个算子，Lowlevel Pathways IR将直接转换成PLAQUE程序，然后用DataFlow Graph表示, 并采用调度器在TPU网络上基于算子编排.
也难怪人家可以做到五万卡规模的线性加速比
天天叫嚣着十万卡百万卡规模的, 先来谈谈加速比怎么样? 谈完以后我们谈谈Amdahl定律?
4. AI Infra未来演进
当前GPU的问题虽然暴露出来的是一系列通信和互联的问题, 本质上还是体系结构和算法的问题需要改进.
4.1 尊重生态的选择
首先要谈的一个问题是一定要尊重生态的选择, 人的潜意识和用户习惯在那里需要长达十年的慢慢培养, 不要想着一夜之间掀翻桌子改变世界. 你看老黄在NV1就犯了错然后很快就明白了这个道理, 开启了长达20年的CPU替代之路, 兼容北向OpenGL/DirectX生态,先挖点纹理渲染,然后挖掉像素填充,再挖掉CPU的Vertex计算. 然后全挖完了再来可编程成了CUDA,有了图形的基本盘再去挖HPC, HPC挖完了再搞AI, 每一步都走的踏踏实实, 有一个感触是那些年基本上SIGGRAPH的论文出来没多久,两年内就能见到实际落地的应用.
所以不要想着一上来就搞新的生态和团体, 特别是UEC这些, 用以太网没错,但是你好歹兼容一下RDMA Verbs吧, 即便是Google都在做这样的事情,你非得要用Libfabric折腾很多新概念给那些开发者, 会有人为你买单么?
4.2 改进DMA的缺陷
另一方面RDMA本来就有很多缺陷, 这些缺陷在它自身的语义上, 对GPU的内存子系统的干扰在那里, Completion的关键路径又要通过CPU,即便是有了GDA-KI, 然后对GPU的CUDA Core也有干扰. 本质的问题在哪? 有没有想过本质上是DMA的问题呢?
其实下一步在网卡上做一点特别的工作, 直接把网卡和GPU的HBM整合在一起呢? 这样你就会明白NetDAM和Tenstorrent的做法了
所有的通用性,本质上是来源于抽象.增加一个内存抽象层即可:
至于报文格式, 最终会走到如下这条路, 无论是谁来设计,这些字段是必选集.
但是这条路很漫长, 需要慢慢地去引导RoCE生态一步步走过去, 也需要大概5~10年的时间.
另一个话题是随着玻璃基板封装带来的一些变革, 特别是GPU互联和内存子系统而产生的体系结构的变革, 点到为止.
4.3 算子编排和调度能力建设
当前大模型训练和推理还一定程度上停留在手工编排并行策略的时代,
加强Ray+Alpa生态的建设是一条很好的出路
另一方面是需要注意英伟达的Legate布局
Alpa对于底层的通信需要很多修改,点到为止了.
4.4 重视从边缘改造,农村包围城市
CUDA的生态在那里, 那么高工资养着的算法工程师大概率只会Python,AI Infra工程师也只会在对并行策略手工调优,让他们上手一个bug百出各种问题的新的框架ROI极差, 同时又要面临别的大模型公司的竞争. 这个时候在训练场景还是继续维持CUDA生态演进.
而在推理场景中, 由于业务刚起来, ROI的约束下机器成本远高于人力成本时, 整个行业都有动力去探索新的框架. 特别需要注意的是一些通过CPU的算力也在快速增长, Intel AMX和AMD未来的Turin AI. 探索一下NV Hopper做Prefill, Turin-AI/Intel-AMX做Decode是否可以呢?
更重要的是在整个业务链条上,如何充分的使用端侧的算力. 我在2018年的时候就开始研究这个问题并开发了Nimble这一套边缘推理引擎,可以通过端云协同的方式去编排算子,中间通过Ruta完成低延迟可靠传输, 可惜思科的那群人当时并没有意识到AI Infra的潜在市场,跑去卷BRCM的交换芯片了....
当时还干过几个事情, 基于Google Coral Edge TPU连在树莓派上做边缘推理的原型验证, 当然也用过Jetson Nano和Xavier去开发支撑Nimble的流计算框架. 而如今的AI-PC或者说Apple M4/晓龙Gen4 都把NPU集成进去了, 是时候在边缘做些事情了.
但是一个尴尬的事情出现了: Killer App在哪里? 搞了这么久本来想copilot收钱的,端侧的一些模型似乎就能搞定了,特别是code copilot这类的应用, 大概只有微软这样的在Office上能做点附加值出来.
-
搜广推的场景利用边缘LLM做一些搜索增强是一个很好的场景?
-
投机Decoding利用边缘模型是否可行?
-
Killer App很有可能是一个基于LLM的游戏, 如何构建这样的游戏? 想起30年前的主题医院/模拟人生 这类游戏?
-
企业数据智能管理这一块, 很多大型企业都有内部的文档库, 做一些基于大模型的离线部署的搜索增强或许也是一条路?
4.5 算法和模型架构的变革
Transformer本身出来也差不多7年了, 其自身也遇到了很多问题. 最终的AGI一定是在算法上的突破, 我个人并不非常的认同ScalingLaw. 另一方面大家都在卷模型结构的时候, 一些对齐的工作需要更加注意.
形象的理解人类神经的形成,本质上大模型Pretrain的过程是Synapse formation的过程, 后期的对齐是一个突触裁剪的过程, 这个过程并不是一个简单的RLHF, 而且RLHF并不是简单的模型安全性的问题.
Claude的工作《Scaling Monosemanticity: Extracting Interpretable Features from Claude 3 Sonnet》
OpenAI的一篇文章也在开展类似的工作
算法上我一直在强调一点
这一次人工智能革命的数学基础是：范畴论/代数拓扑/代数几何这些二十世纪的数学第一登上商用计算的舞台。
我们注意到对于Transformer模型在多模态下的解释, ilya点赞了一篇柏拉图表征假说的论文:
本质上这些内容在数学上早就有了定义, 那就是TOPOS理论. 所以这方面才是要去卷的核心点, 任何一个大模型厂家,你们要找的人并不只是算法工程师, 看看OpenAI团队的很多的人的学历,以及Google DeepMind团队中一些人的背景吧.
说实话,没有足够的数学功底,光靠CS那些知识是不够的. 恰逢高考之时, 想起当年的我们也是一腔热血, 虽然通过OI/数学/物理竞赛没有高考可以任选专业, 很多人也因为当时国家的落后选择了数学/物理这样的基础学科. 当年教我高等代数的是以前中科大的大神乔公,老爷子可是吴文俊先生的助教, 我后面很长一段时间对图神经网络的研究也是受他的影响, 数学分析是以前武大数学系的主任王维克老师, 几何则是长期搞飞行器制导技术的周国标老师, 当然还有抽象代数的章璞老师(冯克勤先生的学生),很感谢这些老师的教导.
所以现在在工作之余还在维持着一个专题
5. 总结
大概就这样吧, 洋洋洒洒又写了一篇技术吐槽的文章, 目的是拉平一些信息差,并且避免一些瞎折腾而做一个“技术扶贫”, 大概国内外能够从算法到模型再到底层芯片架构全部拉通的听众也没有几个, 看客们一笑了之即可, 我继续踏踏实实的去干活去了...
本文作者：zartbot，来源：信息平权，原文标题：《再谈谈三万亿的破绽》
