再谈谈三万亿的破绽

恰逢 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.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 折腾的十年》

RDMA 针对 HPC 的小数据量低延迟场景取得的性能收益在 AI 时代为什么会遇到那么多问题呢？ 为什么会在拥塞控制上遇到那么多麻烦呢？ 下面这图理清楚了这笔糊涂账

本质上的问题在 NetDAM 的论文也讲清楚了：

RDMA 实际上是一种直接将主机内 DMA 映射到以太网或者 IB 上的处理机制，同样继承了 PCIe 已有的 go-back-N 和 QueuePair Credit 机制，但是由于主机侧 PCIe 的原因会带来一些 Cache 操作的复杂性和总线争抢的不确定性，因此尾部延迟会非常高。同样在以太网上由于 Lossless 的需求使得交换机和各种控制协议设计会变得复杂并进一步加大了延迟。

芯片架构上， Mellanox 也在不停的应对这些变化折腾

具体的内容可以参考

《RDMA 这十年的反思 2：从应用和芯片架构的视角》

《谈谈英伟达的 SpectrumX 以太网 RDMA 方案》

另一个问题就是生态上的处理， 为什么 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 在嘲讽

详细的内容参考：

《谈谈基于以太网的 GPU Scale-UP 网络》

《再来谈谈以太网 GPU 互联：一块价值 10 亿美金的胶布》

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 的另一个值得关注的点是它的弹性互联架构。详细可以参考

《大规模弹性部署：Google 如何管理 TPUv4 集群》

用不用 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 定律？

当前 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 上能做点附加值出来。

1. 搜广推的场景利用边缘 LLM 做一些搜索增强是一个很好的场景？

2. 投机 Decoding 利用边缘模型是否可行？

3. Killer App 很有可能是一个基于 LLM 的游戏， 如何构建这样的游戏？ 想起 30 年前的主题医院/模拟人生 这类游戏？

4. 企业数据智能管理这一块， 很多大型企业都有内部的文档库， 做一些基于大模型的离线部署的搜索增强或许也是一条路？

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/数学/物理竞赛没有高考可以任选专业， 很多人也因为当时国家的落后选择了数学/物理这样的基础学科. 当年教我高等代数的是以前中科大的大神乔公，老爷子可是吴文俊先生的助教， 我后面很长一段时间对图神经网络的研究也是受他的影响， 数学分析是以前武大数学系的主任王维克老师， 几何则是长期搞飞行器制导技术的周国标老师， 当然还有抽象代数的章璞老师 (冯克勤先生的学生)，很感谢这些老师的教导。

所以现在在工作之余还在维持着一个专题

《大模型的数学基础》

大概就这样吧， 洋洋洒洒又写了一篇技术吐槽的文章， 目的是拉平一些信息差，并且避免一些瞎折腾而做一个 “技术扶贫”, 大概国内外能够从算法到模型再到底层芯片架构全部拉通的听众也没有几个， 看客们一笑了之即可， 我继续踏踏实实的去干活去了...

本文作者：zartbot，来源：信息平权，原文标题：《再谈谈三万亿的破绽》