与SGLang聊聊DeepSeek V4

[00:00:00] 欢迎来到月球大叔的直播间我是月球大叔的小弟然后月球大叔现在就坐在我对面我叫蓝青然后我跟月球大叔一直在之前的一些直播节目中都是一些搭档然后的话今天的话就由我来主持当然的话你看到我们背景板上还有这个LM吉他猫的同学在后面他是我们的陈阳老师陈阳老师你现在愿不愿意出来说两句然后跟大家说嗨对他先来听我们的直播然后这个这个我心里面觉得 Dipsick的这种大的发布比如说VCMV1 而现在VC算是Infra界的春晚非常感谢月球大叔的Fast AGI直播间能够给这样的支持然后也感谢各位听众的到来今天的主讲人一共有三位然后有我们陈阳老师还有我们另外两位同学可以介绍一下大家好我叫万诚我是RedX Arc的员工非常有幸这次能给大家介绍一下我们团队在DipsickV4上面做的一些关于框架上的工作 [00:01:03] hello大家好我叫袁月明然后我是RedX 我也是在RedX Arc 我主要是在做2L 然后这一次也是在参与一些2L的support 所以这次我会跟大家分享一些其实强化学习有关的东西好的那我们今天就可以逐渐开始了然后的话除了我们四位的话今天还有我们的小花同学在最前面也在帮我们担当一任主播小花同学可以说两句叫我妈对叫我妈小花同学好那么我们现在就开始我们今天的主题吧然后的话就是第一节由我们的陈阳老师来简单介绍一下这次 DipsickV4的一个开发的一个感受还有这样的一个进程想让老师愿不愿意先开场做一个分享在这方面非常感谢非常感谢能听到我说话吗就是开发感受还有一个新入历程其实我们会有两位做推理和做训练的如果大家看了Dipsick 他们最近发 [00:02:03] 就是昨天发的论文的话已经能注意到他们有非常多新的这个算法和计算量我们需要去支持然后最近我们SG浪团队也推出了很多非常有意思的新的功能比如说上下无闻病情比如说high cache 就是可以把CPU或者KP cache给存在CPU里面去然后这些支持功能我们也都需要去给DipsickV4 他这么复杂的一个模型去做适配所以这对我们来说也是一个挑战对我觉得我们的工作量肯定是非常的大的因为大家也可以看Technical Report 他们做了非常多很新的东西然后肯定我们要花很多的时间去适配但我觉得更多的可能还是excited 就是我觉得我们在参与一场非常有意思的事情包括它的整个模型架构其实都非常新然后我们可以看到很多从各个角度 [00:03:06] 就是模型或者说Infra这些新东西感觉可以为整个ML6注入很多的活力所以还是非常excited的对其实大家关注到这次Paper的话它这次不管是从Attention Layer 还是整体架构上来说相比于前代有这种大量的改变所以说这个工程量也是相当复杂的不管是对于内容进行压缩还是各方面的一些优化跟原来在过去的系统也都不一样万臣同学先开始分享第一部分内容推理系统对就是我们推理团队现在已经提供了 Deepseek vs 非常全面的支持然后这里大家可以感兴趣的可以直接扫一下这个二维码然后我们提供了一个开箱自己用的一个推理光价而且我们而且我们可以针对不同的硬件以及你可以想想跑的模型 [00:04:06] 以及各种不同的场景你可以基于这些设置来去选择你自己想要跑的模型我们这里也提供了这个启动的指令然后另一方面我们团队也提供了训练框架的支持这个导火月明同学会做一些介绍而且我们现在的适配已经能做到所有的 Hopper系列和Blackwell的硬件我们都能够支持然后接下来我们会讲一些技术相关的细节首先可以带大家稍微简单回顾一下 DipSeq它的新的一个计算流程它最主要的或者说对我们做框架的朋友来说最有挑战性的部分就是它提出了一个非常新的一个注意力机制的算法在它的计算过程当中对于一个新进来的一个词源 [00:05:06] 它需要它需要处理两类注意力机制一类是我们叫它SWA sliding with attention 也就是说它只会看到最近的几个词源它们存下来的KV cache 然后另一方面它会在不同的layer当中它会在另外两个压缩过后的KV cache当中选择其中的一个对于第一类来说我们叫它Compress for Sparse 也就是说它会把每四个Token每四个词源给压缩成一个然后我们在进行计算的时候会在其中做一些上下文的hierarchy code的一个选择然后选择其中的最有影响力的词源对它们进行注意力的机制的计算然后另一方面我们是Compress 128 对于这样的一个一类的注意力机制 [00:06:08] 我们会做一个全注意力机制的计算也就是说所有的压缩过后的词源我们都会参与计算那么这对我们框架的角度来说就会有非常新的挑战因为它这里面有非常多种类的注意力机制或者非常多种类的KV cache 而且为了维护这两类压缩过后的注意力机制它需要的KV cache我们也需要维护另外两段我们叫它在线上的词源的结果那么这样的我们在每计算出比如说对于C4来说每算出来四个词源然后我们可以对它进行压缩对于C128来说我们每计算出128个对它进行压缩那么也就是总的来说我们总共有五类五类状态需要维护一类是sliding window tension 一类是C4 一类是C28 [00:07:09] 以及C4和C28它们分别对应的in-flight的计算然后我们接下来对然后这是这一页slide就是描述了我们怎么去处理或者维护这么复杂的一些状态的机制我们叫它shadowredix cache 总的来说就是对于每一个我们会维护一个虚拟的列表然后我们在做各种其他的操作比如说kv cache的搬运或者比如说redix cache的查找那么我们只需要通过只需要检查检索一下这个虚拟的地址然后这个虚拟的地址它会去结合你现在是第几个就是在计算过程当中第几层以及你现在需要的这个kv cache的大小 [00:08:12] 来去检索对应的状态比如说现在我们在算这一个新的词源的时候我们会检索它的slide window attention中最近的几个部分前面的部分我们它会有对应的索引但是在实际物理内存当中已经被删除了因为它们不会对计算产生任何的影响然后对于后面的两类压缩过后的次元来说我们会进行一些有一个另外的一个映射的机制另外对于这个infra-light的过程我们也会用一个叫缓撞缓撞 buffer的一类技术来去保证它的这个内存的使用量是有限的然后我们可以切到下一slide 对然后除了刚才提到的这个注意力机制 [00:09:16] 它们底下的kv的状态的维护的一个框架之外我们还做了很多内核层面的优化比如说在deep-seek v4 它们kv压缩的过程当中它会有这么一套流程在里面就是它会先去从内存当中去读取很多数据然后做一些加法计算 softmax的计算或者一些点成计算然后每一类计算都会需要涉及到内存的读取然后最后我们把结果给存回到内存里面去那么这里面我们就会发现它总共会有五次的内存的读取那么这里面我们就提供了一个优化就是我们把中间的三个和计算相关的操作都合成了一个算子那么我们从前到后就只需要五次的内存的访问这对于显卡的计算上面来说 [00:10:20] 是非常重要的一个优化因为它能够极大的减少我们内存的访问数量然后我们可以切到下一次来然后除了刚才我们提到的压缩过程的算子优法我们还对topk 或者说对于稀疏就是我们刚才提到在有一类的摊设当中我们需要对前面的所有的摊设做一个hierarchical的计算然后对其中最感兴趣的一些做注意力机制的计算那么这里面就会有一个设计到一个topk的计算对于非常长的上下文来说比如说我现在的输入已经有100万个词源了那么这一个topk的计算是非常慢的 [00:11:24] 在我们的测试当中它已经需要大概100微秒的时间就如果只是要算一个词源它的这个topk已经需要100微秒那么在这里我们提出了一个叫lightningtopk的一个算子它非常巧妙的去改变了这个计算的流程来增加这个并行度然后我们最后实验就证明把我们的这个lightningtopk的计算给替换掉原来的基于纯pytouch实现的topk的算子我们可以把这个算子的计算时间从100微秒提升到优化到15微秒那么在这个原来的100微秒的时间其实是非常不能接受的因为DipSeq当中它其实有60个layer 每个layer都可能都需要这么一个100微秒的一个操作也就是6毫秒那么这就会极大地限制我们的推理速度好然后另一方面就我们 [00:12:29] 我们提供非常的hybrid的这个并行的支持其中对于长上下文的推理我们提供了叫上下文并行的一种方案它可以把你的上下文给分布分在不同多个机器上面去经营计算来去均摊它的内存消耗以及计算开销然后另外对于它这个新的注意力机制架构我们也支持它的张量并行但需要注意到的是它的这个注意力机制并不是天然的支持张量并行因为我们底下的内核它对于输入的形状是有一定要求的就比如说它如果你这个注意力机制它的我们叫它头的数量如果不是64的倍数的话 [00:13:32] 它就没法对用底下的这个内核去进行计算那么这里我们会采用一个叫padding的一个方式也就是补齐的机制把你如果你不是64的倍数就会把它给补到64的倍数然后这样我们就可以在张量并行的情况下去进行计算然后同样我们对于它的混合专家部分我们也支持了专家并行以及大规模并且我们sglawn支持各种就是这些并行方案的各种各样的排列组合所以非常大家去尝试以及去hack我们的engin 然后另一方面我们的推理已经支持了pt分离也就是在lm计算过程当中它其实可以分为两部分一部分叫prefuel 也就是去对你的输入去进行编码我们可以把它理解为这个AI它在做阅读理解 [00:14:35] 它在理解你在说什么然后还有一部分叫decode 也就是说它在生成自己的token 你可以理解为写作它在生成自己要给你的答案我们一般会把这两部分给分到两个类集群上面这个其实对于deepseek v4的实现上来说也是有一定挑战性的那么这里我们也我们的同学也花了非常大的功夫来去做了适配在直播间里有一个叫byron的同学问了一个问题对他问这个pp和cp应该如何去选对我可以简单一下回复一下这个刚才byron同学问到了上下文并行和流水线并行它们的区别我的理解是这样子的就如果你是在单机内去做计算的话那我们可能会更加喜欢上下文并行 [00:15:37] 因为它的通讯很快如果你用流水线并行的话如果你是有多个机器的话就是它们会涉及到跨机之间传输的话我们可能会选择流水线并行因为这样我们可以尽可能的去节约这个跨机通讯我们可以用第一个机器去算一部分的计算第二个机器去算后面一些层数的计算然后它们之间只要进行一次跨机进来就可以了另一方面就是流水线并行它的一个问题在于它没法去充分的利用我们的计算资源就比如说我现在有八张机器你如果用流水线并行的话那你一次只能用其中的四个机器来或者四个单位的资源来去做计算 [00:16:39] 但是如果你是用上下文并行计算的话你一次性可以用八个计算资源来去进行计算对好那我这里的话还有一个问题直播间同学提的我觉得挺好的就是说他在问就是万城大佬这些KVCache的形状到底是不是统一的如果不是统一的话那SCLang在显存管理中是如何规划这些显存的这个对齐的这个策略的这是非常好的一个问题大叔您呢回到我们一开始的讲KVCache的一部分slide 对就下一页对就是这里因为我们这里会涉及到非常多种类的KVCache 所以对于不同的计算流程他们其实需要的这个KVCache的size是不一样的 [00:17:40] 举个例子来说我们对于特别短的输入的请求它的第二类buffer 其实需要是它们的需求是不多的但是它的这个sliding window attention部分需要的部分会一直是一个长量也就是说相对来说它们的大小可能会接近于一个比较均匀的分布的一个状态但对于一个非常长上下文的一个情况它们第二类buffer需要的资源会更多一些因为它需要维护一个它的数据是和上下文数量成正比关系的但是第一类KVCache它们需要的部分仍然是一个长量也就是说对于不同的上下文的长度它们之间的一个需要的内存的比值是不一样的所以在SGLang当中我们是提供了一个参数来去允许用户去基于你的 [00:18:47] 实际的计算和请求的这个请求的这个情况来去动态来去我们开始是一个静态去预处理的一个内存池然后在计算实时计算过程当中我们也可以对它们进行动态调整好万诚老师就是为什么DeepSeq的这个推理不建议开TP 是因为Deep有什么特殊的优化吗可能是刚才基于你说的那个反馈里面大家你有在接说就是TPCP和这些不同PP应该怎么样去处理对这应该是我刚才提到的另一个点就是它底下的算子对于对于张量变形来说并不是非常的友好因为它要求你的头的数目或者说一个机器它分到的头的数目是64的倍数 [00:19:47] 但是如果你去按照头的数目去切开来的话它可能就没法满足这个约束了这也是为什么我们需要一些额外的操作比如说补权的机制来去支持这个操作另一方面我们就是我需要强调的一点就是它的它这个专家并行 sorry 这个张量并行虽然它会引入一些额外的计算但是它仍然在就是在你的请求数量比较小的情况下或者说在低延迟的处理的情况下它仍然是一个非常好的选择嗯好那么我们再选择最后一个问题吧就是其实这个问题也是我比较好奇的因为那个Deep Seek V4 其实在很大程度上它的KVC的这个大小进行了相当大的一个压缩相比于前一代 [00:20:48] 比如说这个一个Million的就是大概100万个这个磁元的这个大小的情况下只需要不到10个GB 就能把这个东西都存下来那是否这个东西可以让我们有更多的机会把这些东西给比如说存在这个CPU的内存里面或者是硬盘上面就是你们从优化这个过程中有没有感受到这个可能在未来会是一个趋势和机会这个我们已经支持了而且我们经过我们的验证它可以支持三倍的上下文的这么一个性能的提升而且我们会觉得它确实会是一个就是从长远来看也确实会是一个优化的一个方向因为我们现在我们现在比如说现在最近非常流行各种各样的 agent [00:21:49] 也非常流行 coding的一些模型的一些应用我们可以看到这些应用它可能对于上下文的要求会越来越高那么在这种情况下显卡的计算其实是没法去充分的去存储所有的 kv cache 那么我们就需要一些 offload的一些过程来去把一些可能不那么需要的一些 kv cache给放进CPU 好的非常感谢万诚老师我觉得我们也可以到下一个环节了我们除了有推理方面的优化阿西辆相比于不一样的这个解决方案同时我们也提供了这个代零就相当于是立马我们就有了一个 RL上的这个知识相当于是说直接你就可以拿你的数据在上面进行一些微调进行一些优化然后让它能够使用在你的这个使用场景中那么这里的话我也邀请我们下一位同学 [00:22:50] 向来给我们介绍一下这个 Miles相关的阿西辆的开发对我觉得其实代零 RL这件事情本身可能是一个比较新的尝试因为在以前应该大家都只做推理上的代零在训练上可能做代零还是比较challenge的事情然后先给大家可能简单科普一下为什么给训练做代零会比较麻烦吧一个是像推理的时候我们可能只需要去实现一遍forward的kernel 然后一整个forward pass 但是在训练里面就是除了forward之外我们可能还需要去做一下 backward support 比如说如果我们想写一个kernel的话都是需要去实现的还有一个很重要的点是在推理的时候大家可以通过去测benchmark 去知道大家的实现是不是正确的如果它有掉点那可能大概率就是有错但像在训练里面的话其实是没有一个标准的baseline的可能整个训练的recipe 包括一整套实现是否是正确的这件事情我们都需要想办法去验证然后需要一个比较长期的一个实验结果比如说我们可能训练的几天它长点了然后我们可以判断 OK 我们实现的系统是比较正确的但这样就导致整个debug成本非常大 [00:23:50] 所以说我们也是希望可以帮大家减少这部分的费用这部分的费用这部分的费用但是如果是有掉点可能大概率是有错但像在训练里面的话其实是没有一个标准的baseline的可能整个训练的recipe 包括一整套实现是否是正确的这件事情我们都需要想办法去验证然后需要一个比较长期的一个实验结果比如说就是导致整个debug成本非常大所以说我们也是希望可以帮大家减少这部分的成本就是不用大家再去尝试花很多时间去debug自己的训练系统可以在第一天就可以用上一套完整的rl系统然后我来简单讲一下我们大概做了什么事情吧其实我觉得总体来讲大概分成三个部分第一个部分的话是对training backend的实现也就是在Megatron里面的一个modeling 这部分其实主要是因为就像刚刚万总讲的我们的Deepseqv4 是非常复杂的一个model 它的tension有好几个compressor 还有indexor等等这些components [00:24:50] 然后包括像mhc 这些结构在Megatron里面都是没有特别原生的支持的当然我可能不是很清楚最新的版本有没有支持mhc 像compressor tension肯定是没有的所以说我们需要把这些operator 都在Megatron里面去实现一遍本身这个会是一个比较大的工作量然后在parallelism上我们其实是support了六种就是Megatron里面的六种从dp、tp、sp、ep、pp和cp 这六种已经全面支持了像dp的话是非常简单直接就可以开然后ep也是因为它在moe上没有很大的改变所以也是可以直接开的 tp和sp的话这两个是一套的我们主要也是在这个compressor tension里面去实现它实现的也是我们直接用的是Megatron的primitives 但我们需要调通整个系统让tp和cp可以同时开 [00:25:51] 并且保证一整套是正确的不会出bug 这个会花一些时间然后对pp的话我们稍微模改了一下 Megatron的pp的一些code 因为我们用了mhc 所以它从一个三个dimension的henestate 变成了四个dimension 所以要稍微改一下它的一些p2p的传输然后cp可能是其中最复杂的一个也是因为在compressor里面它会有一些非常complex的一些变换特别是在c4 也就是我连记不清在paper里叫什么了可能是叫csa吧在c4里面它用到了一个overlap的transform 也就是它的相邻的两个compress token的所用到的原始token会有一些overlap 如果就是因为这个机制所以我们直接去apply一些 [00:26:51] 最naive的cp实现就会遇到一些问题所以说我们在这里会去做一些特殊的处理比如说先去all gather 然后把变换apply好然后再去恢复来保证一整个是正确的然后像在smart attention里面我们也会去支持它的cp 还有就是kernels 刚刚我们有提到 kernels的话这里我们肯定是要首先对slime来表示感谢感谢子凌哥我们实现的一些基础的 jrm5的一些kernels 然后这些对我们也有很大的帮助首先我们是adopt了来自jrm5的dsa的indexerkernel 然后做一些简单的修改把它adapt到了dpcqv4的架构上还有就是我们extend了sparsemla的telankernel 这部分的话主要是因为dpcv4用到了一个perhead的attention bias 然后这个会导致attention的计算和之前有些不一样 [00:27:52] 所以说我们会稍微改一下它的forward和backward的kernel 并且来保证它是正确的然后像这些其他的components 比如说像mhc这些我们也是借用了dpc本身自带的一些kernel 把它接近我们的system 然后确保它end-to-end的精度是正确的这个是第一个大部分也就是training的backend上面的实现还有第二个大部分是rl的一些feature 这部分的话就是我们在inference framework和training framework 两边的一些联动比如说首先是精度上我们支持的是rp8的rollout 和rp8以及rp16的training 想要支持不同的精度的话我们会在mows里面实现不一样的宽态 quantization的processor 然后来保证我们的weight update是正确的从training backend传到inference engine的weight 是符合sglawn所expect的那种format的 [00:28:55] 然后我们也实现了一个attention的quant 我们的实现是比较简单基于rp8做的一个quant 因为在缩完attention的时候sglawn这边的quant quantage是用mf8来存的而在training里面用的是bf16 然后当然我们也实现了像rout in route replay 就是r3这样的features 我们对一些已有的feature都做了一些extension 和基于dpcv4架构的适配我们还实现了一个比较新的experimental的feature 叫indexerreplay 这个可能大家不知道有没有看过一些讨论就是因为在dsa 就是dpcxv4的attention这种架构上面我们加入了一个类似moe的router的这样一个attention的router 这个会对training带来更大的一些不确定性一个比较简单粗暴的方案就是 [00:29:55] 我们可以在inference里面去把他的routing result给记录下来然后我们去训练的过程中再去重放这个其实是一个比较复杂的事情因为它会涉及到在sglawn里面然后这个routing的结果的存储其实是放在一个cache里面然后它会有一些不是那么简单直白的一些format 所以说会需要做一些在这上面做一些特殊的处理在正确的位置给它提取出来然后再传给training这边去做重放这个更多的是一种实验性质的一个feature 然后也是欢迎主要也是为了让大家可以去尝试然后去explore不同的可能性说完了第二部分然后第三部分的话其实是我们花时间最多的一个部分也就是如何去保证我们的训练是正确的以及可以长点的大家如果看deepstick的paper的话 [00:30:56] 会发现他们做了非常多的像deterministic 以及一些在训练stability上的一些努力吧然后我们做的肯定是没有deepstick这样完美的这是一些非常初步的尝试所以也是一种project引玉希望大家可以一块来用mouse 然后一块develop 我们可以做到一个更好的一个training的stability 首先我们的每一套实现我们都会去做tensorlevel的一种的验证就是说我们会对ntuin的一整套每一个tensor 比如说你的每一层里的任何一个activation 以及你的算出来的每一个gradient 不管是activation的gradient 还是这个参数的gradient 我们都会去把它保存下来然后当我们对任何一个地方去做一个可能会破坏的改动 [00:31:57] 比如说我们去接一个kernel 或者我们去换一种实现这个时候我们都会去跟之前的实现去做一个ntuin的非常完整的每一个tensor的比较然后来确保它的这个两板的这个差距是非常小的这样我们才可以确定我们接的这个东西是正确的并且在整个ntuin的system上不会造成一个很大的精度影响然后这里的话我可能会举一个例子比如说我们一开始在写cp的时候发现就是attention的kv这个tensor 它的gradient 不管我们怎么去实现它我们去跑cp等于1和cp等于2的实现它的结果总是差的非常大这个非常大可能是会cosign similarity 大概这个difference会0.2 而其他的tensor可能就是0. 就是10的-410的-5次方这样一个量级 [00:32:57] 所以我们已经花了挺多时间去研究这个问题然后最后我们发现是因为compress attention的这种性质导致它是一个很sparce的架构然后它的一些head会因为它会attent很多的token 然后它的gradient的流动也是比较复杂的在这种情况下它会变得对精度非常敏感然后我们的默认的写我们默认的实现这个东西本来是用的bf16 而bf16对于其他的tensor 不管是对curry也好比如说curry的activation和curry的gradient 以及kv本身的activation它都是ok的但是对于kv的gradient 这一个tensor它的精度会完全不够是因为精度的范围崩了吗还是因为什么原因其实我这里个人的理解是因为它的reduction比较复杂它会涉及到更多的reduction [00:33:58] 所以说它error就更大所以我们把这一个tensor换成f132之后这个问题就被解决了然后我们就可以彻底确定我们的cp等为1和cp等为2 它前后200tensor是对的上的我们是在整个过程中用了很多这样的方法去验证它的正确性对然后也是类似的我们其实我们有看到deep seek的那个technical report里面有讲到一些deterministic的ops 我们其实也是昨天刚刚看到这个report 但在这之前我们已经做了一些类似的事情比如说像我们在quodln里面去用了一些deterministic mode 然后在moe的一些地方也是做了一些deterministic的改动然后包括像我们禁用了一些nico的有一些非deterministic的做法这些对我们的训练还是有不少帮助的比如说我们会发现本来kl loss会有一个spike 在改完这些之后它就消失了 [00:34:59] 对然后还有其他的一些比较小的优化或者说是改动我们这里就先不说了现在可以翻下一页了这是一个比较简单的结果就是我们在depot上面跑了4000的max response length的一个training 是在32个gb300上跑的然后也是因为时间非常有限所以我们没法去测更大的scale 或者说去跑的更长的train 然后更长的sequence等等所以肯定是比较初步的结果但大家也可以看到它的reward确实是可以上涨的然后boss reward和evaluation score都可以上涨然后我们看到的lock property也是相对稳定的在第一步按照我们的metrics测下来 average只有0.02 只有0.02 这个样子还是比较低的对于这样一个复杂的架构然后这里想额外说一下就是我们其实早就发现 dipsic sparse attention dsa这类的架构本身对训练稳定的对于训练稳定的所以肯定是比较初步的结果所以肯定是比较初步的结果但大家也可以看到它的reward 确实是可以上涨的然后boss reward和evaluation score都可以上涨然后我们看到的lock property [00:35:59] 也是相对稳定的在第一步按照我们的metrics 我发现会有一个非常大的挑战就是因为它架构很复杂然后还有attention的indexer 这样一种更多的不确定性所以说我们从dipsic v3 就在做一些exploration 然后那个时候就发现 sorry v3.2 在做一些事情从那个时候就发现这一类的模型是很难去训练稳定的所以我们也是用了一些当时就在做的一些exploration 一直延续到现在给你出来这次的这个dating support 听起来非常不容易我们这个过程中也是做了非常多的这方面一些有了问题我觉得都非常的细微比如说每一层的这种分析包括它的精度包括像刚才圆明老师提到就是会有那么几层的精度如果说你都用bf16去train的话就会导致你的这个最终的这个结果效果不好然后就真的需要用手去每一层去对 [00:37:00] 然后确保它的那个精度可以被保持下来所以说这个地方的话我当然也可以就是提两个问题其实大家对于精度这个问题关注度还是蛮高的一个就是说这个精度对了吗我觉得肯定是对过了要不然的话我们这个效果肯定也是可以的然后有一个问题就是也是跟精度相关就是说想问一下就是说做rollout和训练的这两步的精度分别是什么就是在比如说Miles这个平台上我们主要在跑的时候我们现在的support是rollout用f8 然后training的话支持f8和bf16 我们很快就会去做f4的support 这个就是exactly next step f4主要是做推理还是做训练相关的就会首先做f4的rollout 然后会做一整套f4的包括qat的这样一个training step 对然后这里的话也有一个很有意思的问题就是问老师就是说整个过程中最具挑战的部分如果说真的让你去举一个部分 [00:38:01] 你感觉是你在这个过程中花时间最长的地方你觉得是哪一部分我觉得花时间最长的就是对精度吧对对精度那你觉得这部分可不可以就是说我靠一些因为现在很多公司大家都在讲我我有一个agent 然后我用agent就能帮我解决这件事情你觉得这个需要你手工去做还是说你也可以说通过一些prompt 或者一些skill去实现这个过程靠skill的话肯定是可以做到不少的但有的时候时间比较紧张我们也就是必须要手工push一下对那么我就说还有一个问题就是说指背后这个背景版的效果背后这个背景版的效果它这个RL结果具体指的是哪一个是flash还是pro这个模型这个是flash flash模型对吧那么rollout的这个稀疏配置会影响最终的这个reward吗 rollout的稀疏配置具体指的是什么这个问题其实我也不是很清楚就是他们在直播间里可以问 [00:39:01] 当然这个同学可以就尝试帮我们去说一下就是说他到底是觉得这个问题大概是怎么样的然后还有一个问题就是说如果说还有一个就是关于大概就是大家在做这个计划就是如果说我要做这个RL在不同卡下的这个配置这个配置有没有一个推荐就比如说我在h200在b200b300上大概怎么样配会比较好对嗯我不太确定你的配置指的是像parallelism这一类还是就是说大概多少张卡就是有这样的一个概念对像flash的话嗯如果你有h200大概64张卡是够的然后像我们用的是gb30032张卡也就够了如果想要用1.6T的那个pro的话可能需要256张h200或者128张gb300这个样子但是这个1.6T我们现在也还在验证所以说这是我们一个期待的一个值对但是这个问题的话还有一个很有意思的一个问题 [00:40:01] 这个当然也是我也比较好奇两位老师在这个过程中就是你们在开发这个过程中是如何配合的比如说你们是先把推理做出来还是先做了训练这一块还是说这两个东西同步展开就是这个东西的一个配合你们两个之间是如何做的对这个肯定是同步做的对就是我觉得推理主要是要负责正确性就是把rollout给做出来对还是要先做推理的对不对对对对 ok ok ok ok 那我们现在来一个比较有有趣的问题能不能锐评一下就是这个Deepseek的V4 在这个混合注意力的这个架构下下一代会不会有有所更换这可能应该更算是一个这个预判的问题吧我个人不做算法我是做系统的所以对于这方面的问题我可能只有一些不太成熟的看法 [00:41:06] 我个人会觉得这种这种混合的架构应该是大事所趋因为现在的注意力机制它肯定还是就是既要看一些非常远的就它肯定是需要一些长程的这个注意力机制但是长程的注意力机制它需要的这个显存又非常多就从系统上的角度来说所以我们又会想到用这种 slide window attention这样的一些机制所以我觉得从长远来看因为系统的一些约束所以这个混合的这个架构应该是会一直存在的 OK好非常感谢万诚老师的回答那么还有一个就是说这个问题想给那个岳文老师问一下就是说 Miles欢迎其他的第三方硬件进行适配吗第三方硬件 [00:42:06] 第三方硬件指的是像AMD AMD或者是一些这种国产用的这些加速器我们现在应该是有在做AMD的适配的然后国产加速器的话可能暂时还没有做适配然后之后可能会有嗯好非常感谢大家对于这个一个很有意思的这个问题就是说因为其实在过去我们在进行这个大模型训练然后从当年我记得2023年最早吧当时Semi Analysis出了一篇报导就是说嗯 GP4在尝试使用类似于MOE 当然后来GP4说我们没有用MOE 但是就是感觉上还是用了啊就是但是就是说对于MOE出来到现在当时大家是为了能够去优化它在这种大模型上参数量的这样这样的一个短板然后提升它计算的效率当然在Deepseek v4在发展上也是使用了MOE这个架构随着MOE的这个架构去迭代你们会觉得这个东西以后会消失吗 [00:43:06] 还是说它会变成一种新的形态然后让大家来使用嗯我觉得嗯就是它其实是一个从嗯稠密的一个形态变到一个稀疏的形态吧嗯嗯所以嗯等效来说它其实就是用了就是允许你更加充分的嗯就是MOE它的优势是在于你可以更加充分利用的你的内存但是你原来的这个计算量仍然是保持不变的嗯所以我觉得嗯因为我们现在的显卡的这个呃大小是越来越大嗯像比如说现在GP300 它已经能做到将近嗯 300 呃这个内存呃但是其实你呃要充完全利用这300GB的这个这个全部存比如说全部存这个 [00:44:06] 参数呃然后你继续仍然保持呃稠密的计算的话这个开销会非常的大所以我觉得从呃呃长远来看这个呃这个架架构应该会仍然存在因为呃呃呃我们仍然是希望呃呃呃呃就是在在你测这个呃呃非常在意这个它的速度的呃呃所以从速度和这个我们家智能的这个呃吹到的角度来说我们肯定还是会希望 MOE会继续存在的而且这也会让我们系统方面一直会有新的工作可以去探索对啊大家还是还是欢迎大家提提提提提给我们新的架构这样的话我们ai infra还是还是有活可以干的欢迎大家就疯狂给我们增加新的挑战对然后我们就有新的工作可以去去实施去对对对于这些东西进行加速其实就是说想问的就是说 [00:45:07] 咱们有没有对于这个训练和推理用的一些这个食谱 recipe 就是可以分享在什么地方大家就是适合大家容易去上手去配的这样的一个链接或者是blog大家可以去试的对呃对嗯嗯然后推理的话我们应该有放食谱的cookbook 上面会有我们一些测过的比较推荐的配置呃这个其实就是我刚才放的二维码这个待会我们可以再贴一下对咱们直播间好像是不能放二维码的咱们可以临时啊就突然给大家嗯大家准备一下一些截图1 1 1 1 1 1好没了大叔可以撤了这个slime的区别是什么嗯我觉得mouse跟slime非常像吧有很多都是share的feature 然后我们最开始的时候也是从slime fork出来的嗯 [00:46:07] 如果要说区别的话可能像mouse我们会做更多的一些类似于在blackville上这种新硬件的适配嗯然后我们也会放一些可能我们自己的一些呃尝试上去吧比如说我们最近也在做 folly async的agentic training的这么一套架构然后之后我们也会有更多的release 对那我这里的话还有一个很有这个问题的话我觉得也是在我们做优化这一层很多时候会做的比如说我们把一些算子融合呀或者是把一些东西整合在一起包括在kernel上做一些优化你你增加东西必然也会舍弃一些东西那么当年就是当时你们在进行这个deep seek v4 的这个优化的这个过程中有没有什么比较厉害的东西你们觉得很很可惜单位的效率而最终把它给放弃掉的一些东西有没有这种类似的感受嗯我可以分享一点就是我觉得算子融合他其实也并不是一直都是有效的呃因为我们其实呃就是gpu他的计算其实就是你 [00:47:22] 相当于你举证成法可以沿着不同的维度去切然后去做一些并行的计算呃但是你这个呃两个算子融合在一起的时候你就得确保这两个算子他们融合才能够去去沿着同一个呃呃能沿着同一个维度去切比如说沿着这个头额或者次元的这个维度去进行切分然后去呃呃做一切并行的计算那么这个时候其实就是有一定的局设的就是你虽然呃把两个算子给合成了一个算子可能会减少一些这个显存的访问但是因为你可能比如说对于其中的某一个算子它这个切分的方式并不是最适合这个算子的所以它就会产生一些额外的一些开销或者比如说没法更加充分的利用这个显卡的计算资源所以这也是我们在做算子实现的时候可能会去考虑的一些实现细节非常感谢老师的回答 [00:48:24] 就是刚刚有个同学问这个DSA是怎么加速的可以之后看一下我们回放这个其实我们花了挺长的时间有一页这个PPT讲了一下这个东西如果attention可以越来越稀疏那么这个东西的下限究竟在哪里就是在attention优化两位老师觉得有没有做到一个极限如果说没有做到极限大家觉得在未来发展还有在哪可能还有继续做的这个空间这个好回答吗我其实个人觉得已经比较极限了我感觉像之前的spark attention的话大家还是会用就是用follow attention和spark attention去混合这样的做法也不会做就是会还是会做一些中和吧但然后在V4里面就是比较纯的spark attention 然后去支持一个M的contact window这样的做法 [00:49:27] 我觉得是比较极限的那么我们继续来进行下一个问题就是说其实我个人觉得极限不极限这个问题也取决于硬件对吧其实以后也可能会有一些针对于模型甚至是针对于硬件开发的一些模型一些特殊的架构为了能够更好去适配在硬件上这个优势对然后有两个问题啊这里我也去汇总一下就是说关于这个off policy的这个问题这个主要也是针对于RL这个方向吧有没有新的想法或者是解决方案能够更好去解决off policy相关的一些挑战我觉得这个是个很general的问题就是因为我看到大家有说到 Agentic的Follow Async这一类这个我觉得也是大家其实包括每家大厂和Frontier Lab 都在探索的一个事情然后也没有一个特别 [00:50:28] 就是形成common sense的一种solution吧我觉得最重要的肯定是我们要去限制就是stileness的一个上限然后具体到底去到什么程度会崩然后这个div到底可以需要多大然后我们去限制它stileness 来保证它的稳定性和infra的efficiency 这两者之间到底平衡点在哪这个是需要靠实验去验证的对好那么我们现在再切换一下这个话题问一下相关一个推理方向呢就是说在Agentic这块我们经常做到一个事情就是这个推理上的一个常委就是说它有的这个latency的时间会非常的非常的长然后在deep-seek优化的过程中咱们有没有遇到过这种常委的问题如果有的话咱们有哪些比较好的这个解决方案是问deep-seekv4本身吗 [00:51:28] 其实也是我感觉它也是比较general 就是说这个Agentic场景的一些常委问题应该如何去是指特地在RL训练过程当中的常委问题吗我觉得应该是推理吧我觉得可以都回答一下其实从inference的角度来说常委倒不是一个很重要的问题它最多会就是会增加这个kp cache的一个消耗这个时候我们可以比如说用其他的一些方式比如说暂时的abort掉就是暂时终止掉这样的request的它的这个计算然后确保我们有能留下来足够的空间去给其他的去处理其他请求然后等其他请求处理完了我们再回过头来去处理这样对于这个kp cache需求特别高的这样的请求所以这些我们安证确实不是很喜欢这类request 但是也是可以处理的 [00:52:29] 我们最近的一些体会吧就是比如说现在deep-seek 它的就是我们一直在强调它的算法和之前的算法非常的不一样然后我们会觉得它它和我们现在的main branch 就是直接结合起来的话这个代码会有一些不太优雅的地方所以我们最近会对这些比较重构啊这些事情会比较伤到精好的那岳文老师有没有要补充的感觉我觉得像deep-seek v4的话这种非常新的mod architecture 然后可能做一件没有参考的比较新的事情是一个比较challenge的点吧其实我的感觉是你们在开发过程 [00:53:31] 因为我自己曾经在亚马逊的时候我也做过很多这种未发布模型的开发其实它在它模型并不是从一开始的架构和现在就是一样的对不对其实在这个过程中它也是经历了很多的这种变化所以说你们也是在这种变化中对于这个新的东西进行适配然后可能也会在一些方面进行重复性的工作重复性对精度或者对benchmark 这过程其实并不是一个非常简单的一个流程对那么这一块的话还有一些这个问题的话我看一下还有问题吗还有很多问题我觉得这个就是有一个问题 D-Seq V4 Pro在短上下文比如32K之内的话和TTFT和TPOT或者OTPS 这什么上相比的话和V3和V3.2的性能 [00:54:32] 大概有什么样的这样的一个区别这个说实话我确实没有和V3.2去做过对比不过就V4本身来说我们在GP2版上面现在是能够达到每秒钟生成了200个Token的速度就是说这也是一些比较教育性的就是说如果是一个零基础的CS本科生我应该如何加入 SE-Lang社区进行一个贡献有没有一个比较好的这个线性思路其实我这里先插一句其实就是我们上一期直播中也大概讲了一下那个志鹏老师他也讲了一下他自己的一个心路历层是怎么从一个这个艺术开始看然后慢慢的发展成这个社区中的一个核心的这个发展者这里的话我也是希望各位老师可以我不知道你们是不是从一开始也是从零开始去接触到这个社区 [00:55:34] 然后慢慢把自己的这个能力给做起来的我觉得万诚老师可以分享一下对其实我自己差不多我也是自己先发现了一些比如说一些算子层面可能会有一些问题然后我的第一个PR 就是解决了一些算子的这个实现的问题我记得当时好像是在这个输入量特别大的情况下他可能会有一些一些 illegal memory access的一些问题然后当时就自己提了一个PR把它给修了然后后面的话就是那那是一个moe的kernel 然后后面的话就开始慢慢的开始会做一些moe相关的工作比如说就是专家并行然后再后面的话又会去慢慢的扩展出去比如说就参与了一些dpattention相关的工作再之后又做了dpattention和expertparalism [00:56:36] 以及这个spec计就是投机解码结合就是要把各种各样的feature进行结合的一些工作然后在这之中我就感觉自己的scope 就是对sg-long的熟悉程度以及开发的这个范围就是越来越大就是我一开始只是修了一个moe的kernel 然后慢慢的我去做了一些并行策略的一些修改在后面的话又参与到投机解码以及还有cuda graph的一些参与当中所以我觉得确实就是作为一个新上手sg-long的朋友就是可以确实可以先看一些比较简单的issue 然后我们sg-long社区里面也确实也明确标出来了一些非常适合新开发者贡献的issue 他们就有类tag叫new best first issue 然后如果你对参与sg-long开发感兴趣的话 [00:57:38] 也可以去检索一下这类issue 然后可以开一些pr去解决他们对我也觉得宇文老师要不也回答一下就是说自己从一开始接触到这个项目如何发展成一个核心的贡献者最后加入到这个redis argument 我在认识陈阳的时候确实是博尔然后可能phd的时候我本来就在做一些training infra这些事情之前也在做一些比较大的training这种工作就是在我的paper上然后后来就是巧合吧然后后来认识了陈阳然后被陈阳拐进了这个community 然后如果大家感兴趣的话可以去联系陈阳对对然后从学习资源上来说我觉得坦诚来讲我觉得现在sg-long或者说像miles miles可能还好但是sg-long作为一个发展有三年规模的一个framework 这个学习成本肯定是有的我们有一个非常好玩的项目叫做mini sg-long [00:58:39] 然后这个mini sg-long 呃从我个人的私心上来看这个他的这些命名啊还有这些scheduler这些东西写的都会比sg-long好很多这也是我们非常希望大家如果愿意真的对这东西有兴趣比如说想去看一看continuous fashion 大家是怎么干的这个chunk prefill 这个呃对就是可以写个很mogchunk prefill 可以去研究研究mini sg-long这个项目然后会对整个推理这个行当有很好的认知还有一个同学问了一个问题啊就是说这个大佬们目前在大厂做就是我我是一个在大厂的普通sde 就是一个开发者对吧我如何在sg-long方面做贡献并靠近这个问题的话我就帮忙去回答了因为我自己在一个这个中厂嘛对吧然后的话也是有见到很多这个同学对于lm这块非常感兴趣然后也是在这方面去做其实的话第一我觉得最重要的还是能接触到一些算力吧就是说看有没有一些机会去其实我觉得还是有一些门门 [00:59:40] 就是说能接受到算力的人一般就是做训练做推理然后可能也有一些做这种训练推理数据准备这一块的这个同学可以去接触到这个然后第一还是能尽可能能先往这个方向去靠能接触到这个算力当你手上有了这个算力就比如说H100甚至是哪怕是一张这个A100都可以开始去做一些针对于这方面的开发然后我的感觉其实会有一些比较硬核的课虽然比较枯燥但也值得去学比如说Andro Carpacy的这些就是他就教你该如何写如何写一个PiTorch啊什么的就是对于这种底层算子这些东西要有一定的这个了解然后对于你上层架构的这个建筑也应该去了解一些然后也是像陈阳老师说的去可以先通过这个miniSE浪这个项目去进行一个入手去了解一些基本的这个架构然后能把它给跑起来尝试做一点小优化然后之后呢从小SE浪上优化到大SE浪 [01:00:41] 然后在上面去去进行一些这种开发我觉得是一个比较好的发展的这个路径对我观察了一下身边这些就是说做MLC4科研或者工程的人如果说你在做MLC4的过程当中你只对代码行数就是每天只是看profiling 然后只是对代码行数这个地方有一个小窟窿我把这个的小窟窿给补了那个地方有小窟窿然后我把那个小窟窿给补了你没有站在一个更当然一开始这样肯定行的没有因为要先出火嘛但如果说你站在一个research的角度你就应该想比如说我过去三个月过去两个月已经补了差不多几十个窟窿了那这个窟窿里边有没有共性呢我能不能把这几十个窟窿用一套框架比如说我开发一套派套我开发一套那个什么serling 开发一套一套一套一套一套我能不能把那些就是那个research里边就是那个system research里边那些常用那些pipeline 那些scheduling 那些什么那个各种各样的手段 [01:01:44] 然后把它融合起来把你过去几个月最头疼的问题能够用一套框架里边的若干比较精巧的api或者精巧的设计然后来把它端出来然后又让性能提升了很多其实我觉得这个地方就是之前我和很多很多人聊的那个system的research 是需要一定的抽象和美感的如果你持续在写那种你自己都说不了的一些工程代码但是没有去做那种艺术上的一些就是说抽象的话那它就不是那个system research 但你那个写了几个月之后你突然学了你要做把它变得更美一点我觉得当你决定去做更美的一件事情的时候就是你就开始做system research 其实我觉得也有一个很重要的点大叔所提到就是说有一些这种其实你们看到的是现在不仅仅只是说我们模型在进行提升有很多现在硬件的发展也是在不断进步的随着你硬件架构的改变 [01:02:46] 那么它所运行的系统包括其实你想想在整个推理或者说是这个系统中有三个要素这三个要素分别是什么呢就是存储通信和计算这三个东西在每一个系统中我们都想做到是能够让他们去达到一种优雅的平衡适配于我自己的这种算力去做但是随着每一代新的硬件进来它的架构的这个改变都会打破这个平衡那么打破这个平衡之后我们就需要去配置新的算法新的架构新的一种设计然而你会发现有的时候类似的问题在过去这十年二十年甚至三十年四十年的这个历史中都有过一些人在就是处理过一些问题就比如说最开始我们在这个然后我们这个世界中这个配置配置天神它这个配置这个东西就是它这个整个这个东西架构上被设计出来的思路它也是基于它一开始在这个文件系统中 [01:03:47] 对于它硬件的这个内存和这种东西分析中所抽象出来的一个解决方案然后其实这里面还是有很多这种研究和方向是可以做的对这是我的一个感受吧对然后除此以外的话其实还是有很多我个人认为就是值得去探索和发展的方向其中有一方面就是说对于这个数据存储方面有的人很多人会觉得就是说我现在有了LM 然后这些以前做数据库的或者是做一些传统后端开发的就没有出路了我的感觉其实非常不一样反而是现在大家对于LM这个单纯的这个东西的关注度没有那么高当然也有这里面有同学问了一个很好的问题就是说在这种agentic架构下我该如何更好让让SC让进行一个适配其实有很多的问题现在已经逐步的从于从这种算力的这种压压榨和优化转为的成了一个对于数据管理的一个存储上面的一个问题 [01:04:48] 包括你的agent的可持续的这个记忆包括这个梦对吧 Dreams和Memory这两个东西区别感兴趣的同学可以看一下这个Athropics他们发的一个文章在这上面对于一些分析其实有相当多的这种与数据相关的东西也是在不断进行发展对感谢大家参加我们今天的直播也谢谢清老师还有这个球书的贡献只是说我们现在还不知道未来对于我们现在这个评价但是我们生活的就是在一个这种风起云云非常多变的世界也希望大家能够一起乘风扑浪然后一块去发展那么我们最后给小花同学一个机会说一句话我觉得我跟你有点像吗对啊就是有没有觉得我们我们之间其实是非常像的对不对其实我们大家都是一样的对吧在这个过程中我们谁也不知道未来是什么样的对吧然后我们就跟小花同学保持乐观一块打满 [01:05:51] 好吧一起加油非常感谢笔心好 OK