还呗 2024-07-07 20:51 北京
（以下内容来自 zartbot）
周末回了趟上海,WAIC逛了逛然后参加了几场会, 第一感触是今年都在卷机器人, 第二个感觉是大模型的垂直场景都在盯着金融和医疗, 第三个感觉是伴随着多模态, CV大佬们重新站上舞台的中央, 例如阶跃和商汤等. 但是大模型落地场景还是有很多困难. 紧接着是一些ScalingLaw的天花板在哪里? 本文分为几段:
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更像是一个直觉判断的过程, 因此我个人过去十多年对图神经网络在金融领域的探索, 以及最近两年结合大模型的一些探索, 观点和漆远教授是相同的, 例如通过范畴论和一些其它新的数学工具的引入来构建白盒系统
针对训练场景, 夏Core昨天写了一篇《站在AI Scale-Up域的一个岔路口》[1] ,本质上是一个ScaleUP分层的逻辑.
我个人的观点一直是推进以太网ScaleUP, 并且我也不认同那些非对称的拓扑带来的调度和编程的复杂系统。当然相关的工作也在推进中, 具体的方案就不便展开阐述了. 对于下一代基础设施另一个关键的因素是分离式架构的引入, 异构算力的引入.这一点对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的方式也会影响这个分布, 因此在调度系统上该如何考虑是一个更值得深思的问题. 这些问题也是最近一段时间工作的一个方向.
关于推理系统的更多细节，欢迎关注 zartbot
声明：本站转载文章来自其他媒体，转载以分享为目的，并不代表本人及任何机构观点，且不构成任何投资建议
