周末回了趟上海,WAIC逛了逛然后参加了几场会, 第一感触是今年都在卷机器人, 第二个感觉是大模型的垂直场景都在盯着金融和医疗, 第三个感觉是伴随着多模态, CV大佬们重新站上舞台的中央, 例如阶跃和商汤等. 但是大模型落地场景还是有很多困难. 紧接着是一些ScalingLaw的天花板在哪里? 本文分为几段:
1. 大模型落地相关的探讨1. 大模型落地相关的探讨
2. 算法的演进
3. 训练基础设施
4. 推理基础设施
启明创投有一个很有意思的观点, 微处理器将计算的边际成本降至零, 互联网将信息分发的成本降为零, 人工智能将创作的边际成本降为零. 但是对于最后一条, 我想可能还是需要分为两个阶段: Step-1
: 类似于文字/图片/视频的生成类创作 Step-2
:一些多步决策的任务,后一类可能需要走出一条完全不同的路径. 创作出来的东西能不能用? 是否能够真的达到kill-time或者save-time的目的呢?
1.1 机器人
今年机器人的热潮主要就是两方面的技术, 一个是LLM带来的指令跟随能力, 另一个就是RL算法和伺服机构的配合越来越成熟, 成本基本上达到可接受的范围, 但是真正的变成生产力落地赚到钱还是存在一些难题的, B端的一些产线改造可能还好, 但C端人形机器人大概率短期内只是一个噱头, 主要原因是当前的大模型还缺乏较强的可信的多步决策能力, 因此整个商业逻辑上是没有闭环的.
1.2 ScalingLaw的天花板
基本上国内外对ScalingLaw的认知还是对于大模型的参数还可以提升两个数量级,大概到100T左右. 但是另一方面训练语料大概在15T左右已经不够了, 那么合成数据则是一个非常重要的路径. 另一方面针对100T的模型训练, 训练基础设施的规模和功耗问题也是一个需要解决的问题.当然另一个问题也逐渐显现出来, 推理系统的ROI如何考虑?
1.3 垂直领域模型
WAIC展厅里邀请的不少国企都有相应的大模型垂域模型的场景, 某种意义上来说工业/制造这些场景更多的是基于社会责任视角, 从商业上讲这些大模型确实可以提高整个社会的制造业效率, 但是从企业经营的角度ROI可能并不好. 这一点上能看到一些国有企业在覆盖这些场景也是挺不错的.
另一个就是对于商业化的公司而言,垂域模型基本上都在盯着金融和医疗, 医疗这一块我完全不懂就不谈了. 说说金融吧, 毕竟还是考过FRM周围也有一些小伙伴都在做金融风控和量化投资这一块的.
事实上当前的大模型结构上对于金融时间序列分析的能力和多步决策的能力, 以及生成的内容还是完全无法满足金融业的需求的, 某种意义上来说, 外行的这些模型算法工程师觉得自己训练了一个很聪明的大模型 ,其实在金融领域就是类似于回答弱智吧的问题, 并且这个行业只要大模型输出结果错一次,基本上就完全会丢掉信任.
1.4 多模态生成
生树的视频Demo现在已经可以很好的配上声音了, 阶跃的1T-MoE多模态的感知能力也非常不错, 商汤也有蛮不错的表现. 当然这些1T的模型落地对推理系统的影响是什么, 基础设施演进上还有很多路要走.
2. 算法的演进2.1 多模态使CV重回舞台中央
想起很多年前, RNN/LSTM的效率问题使得NLP的同学们游离在深度学习的边缘, 最终ChatGPT把他们送到了风口, 让一众CV的公司突然哑火了. 而伴随着多模态的演进, 我们看到 阶跃和商汤最近都带来非常不错的产品. 接下来一些视频合成数据的训练或许还能再把一些做CG和物理仿真的人卷进来.
2.2 灰盒模型
漆远教授带着“百亿参数的可信光语大模型”亮相, 其实这是一个非常值得关注的领域, 那就是灰盒模型, 也是我过去两三年一直在研究的一个领域
另一方面阶跃的CEO姜总也在谈到对于多模态的理解上, 以及后面的System2的任务规划/抽象概念归纳等
从模型结构上来看,Decoder-Only的模型是一个完全的黑盒模型, 当然从信息压缩的角度来看,一个1T左右的模型很有可能就可以很好的隐含物理世界的信息了. 但是我们需要在旁边挂一个白盒模型构建大量的逻辑能力. 当然这个也是辩证的来看, 特别是最近在读《概率论沉思录》的时候, 对于合情推理的一些探讨
例如书中的几段话, 在如今的大模型时代还有非常深刻的意义.
因此，在推理过程中，我们非常依赖先验信息来评估新问题的合情程度．这种推理过程是无意识的，几乎是即时的．为了隐藏其复杂性，我们称之为常识．
我们在一开始就强调我们关注的是逻辑关系，原因是一些关于推理的讨论和应用由于未能看到逻辑蕴涵关系与物理因果关系之间的区别，而陷入了严重的错误．
明确的定理将取代相互矛盾的直觉判断，确定的规则将取代特定的处理流程——这些规则由一些几乎不可避免的基本的理性准则确定．
简而言之, 现在的Decoder-Only更像是一个直觉判断的过程, 因此我个人过去十多年对图神经网络在金融领域的探索, 以及最近两年结合大模型的一些探索, 观点和漆远教授是相同的, 例如通过范畴论和一些其它新的数学工具的引入来构建一个白盒系统
最近通过分析DeepMind TransNAR和OAI/Anthropic相关的Sparse-AutoEncoder后, 基于图神经网络/范畴论/Sparse-AutoEncoder的方式来构建新一代模型可能会成为一个新的范式
《谈谈DeepMind会做算法导论的TransNAR并引出基于SAE-GNN的可组合Transformer猜想》
例如上文中提到的一种Adaptive 的Sparse-GNN-AutoEncoder. 建议一些做Foundation Model的厂商可以尝试着把SAE搞出来开源一些数据,供学术界进行一些研究.
另一方面是物理世界的模拟上, 也在探索一些AI4Science的模型, 只是最近几个月工作很繁忙, 开了个偏微分方程数值解的头,后续再尽量补上PINN/FNO这些内容,以及AIMD(Ab Initio Molecular Dynamics)相关的内容
3. 训练基础设施针对训练场景, 夏Core昨天写了一篇《站在AI Scale-Up域的一个岔路口》[1] ,本质上是一个ScaleUP分层的逻辑.
我个人的观点一直是推进以太网ScaleUP, 并且我也不认同那些非对称的拓扑带来的调度和编程的复杂性.
另一方面是针对多Die的MCM-GPU也算是这种内存语义互联的ScaleUP, 英伟达很多工作值得参考
《英伟达GB200架构解析4: BlackWell多die和Cache一致性相关的分析》
当然相关的工作也在推进中, 具体的方案就不便展开阐述了. 对于下一代基础设施另一个关键的因素是分离式架构的引入, 异构算力的引入.这一点对Decoder-Only+白盒模型非常关键. 例如GPU还是维持原来的Transformer架构,而在旁路出来Sparse-Encoder和一些GNN/决策树模型在CPU实例上进行互联. 这一点推理系统也会用到.
4. 推理基础设施针对推理昨天有一篇文章补进来... 知乎上看到方佳瑞博士的一篇文章《LLM分离式推理可能带来的软硬件变革的迷思》[2]
恰逢这周工作上有一些和HugeCTR相关的事情, 那么就从软硬件一体化的视角来阐述一下整个架构的演进, 特别是在分离式推理架构上. 以下观点仅代表个人,和作者任职机构无关.
4.1. 推理系统和训练系统的区别
最简单的一句话是: 推理系统没有所谓的DP并行. 背后隐藏的一个含义是两个系统的Workload是完全不一样的.
4.1.1 训练系统
到达速率和服务速率为确定性分布
在训练系统中数据以Batch的方式到达, 然后计算时间也相对确定, 一方面是因为backward过程的同步需求, 另一方面是训练语料本身有长短的分布但也做了Padding, 当然可以通过一些技术对Padding进行优化提升计算效率.
4.1.2 推理系统
到达速率假设为泊松分布, 服务速率受实现方式和服务策略影响
推荐系统请求到达的分布假设是一个泊松分布, 另一方面input token和output token的分布则会带来服务时间有一个特定的分布, 简单的来看按泊松分布算, 或者有长尾的情况,例如Pareto分布.而Prefill-Decoder的方式也会影响这个分布, 因此在调度系统上该如何考虑是一个更值得深思的问题. 这些问题也是最近一段时间工作的一个方向.
4.1.3 推理系统SLO
对于不同的用户而言(例如按照充值程度分金/银/铜)SLO是不同的, 针对不同的SLO下的TTFT/TBT的整个推理系统的优先级调度和延迟隐藏也有很多可以去做的事情. 另一个非常重要的工作是对用户请求的服务时间的预测
推理系统的请求和服务时间分布相对于训练系统更加有不确定性, 因此在各个子系统内的调度编排和Locality的利用上以及时间/空间折中处理上有着巨大的创新空间.其实这也是Prefill-Decode/KV-Cache Centric Sched有收益的本质原因.
接下来我们分别从软件系统和硬件系统来谈谈.
4.2. 软件架构
从软件架构来看, 数据和控制平面的分离是一个非常经典的设计模式.
4.2.1 控制面
控制平面主要负责一些用户请求服务时间预测/调度/集群管理和高可靠/Cache及相关的分离式内存池管理的任务, 这些任务从架构上来看应该用通过的CPU进行处理.
4.2.2 数据面
数据面主要是用于计算的Prefill Node和Decode Node以及一些弹性内存池相关的数据搬移的工作. 从数据面来看, 其缓存结构在推荐系统中已经有很好的借鉴, 那就是HugeCTR一类的框架中的Hierarchical Parameter Server
从Embedding Cache变成了需要在LLM处理KVCache, 但是相应的软件栈和结构还是有区别的. Embedding TableLookup更多的是Hash Lookup ExatclyMatch. 而在LLM中KVCache的处理是一个Longest Prefix Match. 因此CPU Memory和SSD的软件架构还需要一些调整.
4.2.3 存储设计和内存缓冲池
当然系统也会面临DRAM不够的问题需要落盘. 然后既要SSD容量大又要高I/O,同时还要考虑低成本和可运维. 因此在SSD前面构建一个分布式的弹性内存池应该是必须要做的了, 这里有一篇华为《MemServe: Context Caching for Disaggregated LLM Serving with Elastic Memory Pool》[3]
另一个业务场景是DeepSeek会将用户的上下文落盘到SSD中并保存24小时. 那么相应的软件架构应该就很好构建了.
我们可以通过Trie树或者TreeBitMap的算法来构建整个查询树.
当访问到一个叶子后, 即记录该叶子对应的KVCache所在的内存的节点ID和指针并放入处理List, 以便以后进行异步的DMA/RDMA. 这些在用户请求到达后即可进行异步执行处理并在队列适当的时候由调度器控制执行相应Prefill Node GPU VRAM的Prefetch.
Trie树也可以根据input token做一些并行化的处理方式, 例如通过一致性Hash针对前几个Token将workload分散到不同的CPU服务器上. 而这些服务器又可以构建成一个很大规模的弹性内存池.
对于弹性内存层的Cache Evict可以按照LRU的方式进行, 落盘的时候还需要考虑一些KVCache生命周期的问题. 落盘后也需要对Trie树进行更新将其相应的叶子节点指针更新到指向某个文件的特定的block
谈到落盘,可以借鉴类似于LSM的方式合并压缩后落入磁盘, 并且还可以根据实际情况进行冷温热分层. 因此对于存储落盘到SSD的场景, 个人并不是很喜欢在GPU实例上的本地SSD, 损坏后维修带来的业务影响还是有的, 另一方面可能还会带来一些workload偏斜的影响, 因此可能更倾向于一种分布式并行存储的方式.
当然这里还有一个不同的地方是对于长时间没有更新的block也需要定期的进行GC, 例如按照DeepSeek保留24h的做法, 可以对超过24h的数据删除并在Trie树上剪枝更新.
4.3. 硬件架构
4.3.1 三网融合的推理系统
黄大年茶思屋最近也有一篇《英伟达、谷歌、Meta等5大巨头Scale-up超节点规模大比拼，揭示未来AI网络最优解》[4]. 个人对这种不根据workload来谈互联的分析持怀疑态度, 但是有些结论是正确的. 其中最重要的一点就是“三网合一”即文章中的观点
当前的AI网络是三个独立网：前端存储网VPC（以太）、后端参数面（IB、RoCE2）和超节点（NVLink，HCCS）。三个网长期共存不合理的，一定会融合。
当然这个问题在方博士的文章中也有提及:
现在分离式架构都是用GPU训练集群做推理，节点内NVLink互联，节点间用IB或ROCE的RDMA互联。这种配置分离式架构完全是浪费，好比李云龙攻打平安县城，章明星称之为富裕仗。
有几个难题:
4.3.2 FrontEnd: CPU实例和GPU实例耦合
在这样的一个推理系统中, NVL72-GB200是一个非常不错的方案, ScaleUP规模大, 而CPU又直接和GPU有C2C的带宽, 这样控制面和弹性内存池的设计难度会小不少.
而对于国内非Grace-B/H的大概只能通过RDMA将弹性内存池和GPU连接了, 因此需要VPC上跑超大规模RDMA并且完全商用的, 现阶段全球能做的大概也就只有AWS SRD/Google Falcon和阿里云eRDMA.
而同时在这个网络上又要兼顾Prefill Node之间的SP并行带来的alltoall incast的影响, 对于其它很多客户而言, 包括英伟达自己都是有很大挑战的.
为什么需要呢, 从另一个角度来看,现在的Prefill/Decoder的转移其实都是在8卡PCIe连接的同服务器的CPU上,然后再通过Messenger转发到另一个Decoder实例, 并通过Async Load加载. 也就是说CPU的算力和内存空间和GPU是绑定的, 外置的CPU服务器如果可以直接GDR访问GPU显存来做异步的调度和prefix lookup整个的性价比还应该有所提升.
但是我们注意到Google Vertex AI很早就通过一些闲置的CPU实例和GPU混布来构建, 并且通过CPU实例来做参数服务器,当然还有一个是Cerebas的Swarm-X/Memory-X架构
另外Enfabrica也有一些机会,难怪NV也投资了.
4.3.3 ScaleOut: Prefill-Decode M:N的部署
即章明星老师提到的异构分离式架构, 需要在H800/A800和H20之间构建很高的Bi-Section带宽, 同时考虑到组网规模的问题还需要避免网络上hash冲突带来的利用率降低的问题.
4.3.4 ScaleUP: 是否还需要Load/Store ?
针对推理系统来看, ScaleUP主要用于TP/SP并行,例如模型规模大了或者算力无法满足SLO时或负载均衡的考虑带来的并行策略. 细粒度的Load/Store访存似乎并不需要,因此Eth-X这样的方案或许也就够用了.当然还有一些优化方式,例如英伟达的GPS/PROACT/Fine-PACK的处理方式等. 当然另一方面有现成的NVLink用用也挺好的. 等待UALink似乎又要考虑一些问题, 例如BRCM Altas4的single vendor供应的问题和InfityFabric这些IP的成熟度, 当前的国产GPU厂商可能面临二选一的决策, 但是还是请先考虑是否还需要Load/Store over Scale-UP Link.
这个问题的答案取决于业务部署模式的考虑,成本的衡量,弹性的重要程度,是否训推一体,生态的兼容程度等. 未来多模态的业务场景也是一个变数.
4.3.5 弹性和成本视角
方博士也提到了一个问题Prefill和Decode Instance弹性扩缩容
因为Prefill和Decode各自子集群网络互联可以用以太网，没准也可以根据负载弹性扩容Memory Pool和计算设备和存储。
其实最终都是在成本上打算盘, 以后的服务就是按照Token印钱, 印刷机的成本, 推理流量的峰谷带来的弹性供给, 都是值得考虑的问题.
其实很多探索在几年前已经有了答案
本质上是内存的两个墙不可兼得
但是....
站在AI Scale-Up域的一个岔路口: https://zhuanlan.zhihu.com/p/707355769
[2]LLM分离式推理可能带来的软硬件变革的迷思: https://zhuanlan.zhihu.com/p/707199343
[3]MemServe: Context Caching for Disaggregated LLM Serving with Elastic Memory Pool: https://arxiv.org/abs/2406.17565
[4]英伟达、谷歌、Meta等5大巨头Scale-up超节点规模大比拼，揭示未来AI网络最优解: https://mp.weixin.qq.com/s/5Oq6H1VBd3G2CTGwXtjq8A
