与vLLM团队畅聊多模态（上）

[00:00:00] 我大概讲一下就是为什么我们要做这个项目吧 就是这个项目的前世今生是什么 首先BIM大家都知道或者说S-Line或者TRT-Line这些大元模型推理的引擎大家都知道 然后也知道它怎么运作的 然后其实这个在23年的时候大家开始做了20年底也开始做了 然后当时其实还是专注在大元模型推理上 也没有去搞一些多模的东西 然后上次我跟专注大叔聊也是聊怎么样在一个大元模型的引擎上加多模态输入这一块 就是上次我们聊了一个话题 然后其实在那之后呢就一直在看 包括说不管说是工业界还是学术界的一些进展嘛 对于这种整合的一个模型的一个方向嘛 然后之所以这个项目的一个启发点其实是当时千万 2.5奥米当时刚出来 [00:01:01] 还有一个mini CPMO是OpenBNB那边就清华那边一个Lab出来的两个项目嘛 都是做一些类似于N2N就是你可以去做多模理解和多模生成 也是文字生成的一个N2N的模型 一个N2N的模型 那当然支持第一部分其实很容易支持你第一部分这个多模理解 其实不管说VRM还是XLINE还是TRTRM都做的 已经说是不错了 但是对于怎么样支持这样一套N2N这个东西还是有一些 Question Mark的 然后 当时呢其实千万那边那个范洋老师给我们VRM提的一个PR 那个PR呢就支持千万2.5奥米N2N 然后那个PR呢他那个加是一万行 减是一千行 当时我看了他只能把VRM给磨改了 当时我看的东西我就说这我们肯定接不了 但是我们就有一个solution嘛对吧那你可能 现在他这个PR 只为了千万奥米去做这样一个支持 [00:02:02] 可能太 偏向于说给这个模型支持了 但 肯定以后会有更多人想往这方面去发展对吧然后当时呢也是去年大概是去年4月份的时候 他们给我发这个PR其实你现在来看也就一年不能够了 对吧这个发展很快 然后 也是过去一年吧觉得发现大家就是在这种多模态 端到端就是N2N的这个这个发展上 大家开始越来越的越来越去利用于利用了 更大的模型来去做一些encoding和一些理解 比方说 可能最早的时候我们在做diffusion的时候你可能拿个T5 去做encoding然后之后呢 千万那个image对吧 他直接拿一个 千万2.5BL去做encoding了 那你的模型这些encoding模型呢在变得越来越大 这是一点然后还有一点呢是 你模型本身这个pipeline也变得非常 非常复杂了对吧你可能原来只是一步encode 一步decode就完了 [00:03:02] 那后来 越来越复杂变成了像千万 Omni啊这种这种这种 一步encode是一个thinker talker然后还有一个video audio generator 然后包括说还有其他的模型他可能 本身是个TTS 他本来是一步encode的然后出audio 他可能现在这个encode这一步变得很复杂 可能有多重的一个 一个交互型形式 比方说小米那个memo audio就是这样 类似于这样的模型 然后 这也是为什么当时我就说 想立一个项目吧 去做 这样一套 就是一套方案怎么样我们怎么样做到 做一套这个框架 来去解决这一个 悬而未决的问题 然后也是这个 beyond army的一个 核心思想就是我们怎么样做好这个多stage的一个管理吧 其实你想 我们今天在聊 PD部署的时候虽然大家叫pdpd嘛 但其实说白了其实有两个stage 只不过一个stage是做precual 另外一个stage是做decode的 当然这和大元模型就比较贴合 其实我们beyond army做的是一个这个的扩展 [00:04:04] 类似于说 我怎么样 这个stage可能是一个多模引扣的 这个stage可能是一个多模的 input plus 或者说这个stage是一个多模的生成 或者说sometimes你可能 模与模之间还有一些 额外的交互 你可能今天我们在聊pd的时候大家会说 你的kvcast transfer 然后可能会 两边都transfer也会有这样的情况 但可能说 但可能在 多模这一块呢 就可能更复杂了 你可能不仅 不仅传的是kvcache 还有更容易各种embedings 各种metadata 然后有时候这些传的也不是单向的 可能是双向的 或者说是你可能第一步 第1个stage得跳第3个stage 就类似于这样子 所以 这是我当时 起这个项目的这个 想法吧 就是veon army这个项目的想法 也是为什么我们把这个项目拆出来了 就没有放在这个 veon底下 因为我想这个还是一个非常unclear的一个picture 就是也不知道该怎么做 也得根据模型发展而做 [00:05:05] 然后也是因为这个原因 其实 当时起这个项目只有我一个人 就是 主项那边并没有人想来做这个东西 然后我就去 sale what idea吧 就是去卖我的这个点子 然后 正好华为那边 还有包括国内同学呢 对这个 开源这个项目比较感兴趣 然后也是把这个慢慢的做了起来 然后 包括说 支捧呀 还有跃迁呀 也是因为看到这个项目比较感兴趣 所以加入过来 然后 这个项目可能 我记得立项是 我看一眼我们的stars 就是 我们的立项是去年 去年年中吧 然后真的做出来的可能是去年年底 然后也是因为 可能也是因为这些 这些动物模型吧 可能大家大元模型去完了 开始卷动物了对吧 然后 慢慢的活起来 然后包括千问啊 千问三奥尼啊 包括 各种TTS模型啊 我们和Mistro也合作了 在 在Day0就发布了这个Mistro TTS 然后包括 小米之前这个Memo Audio 之前他其实是没有框架可以支持的 [00:06:06] 也是因为有了VM Omni 他在 在VM Omni上上的Memo Audio 我也是觉得 这个发展呢 还是一个 不是很清晰的一个 就不像大元模型这么清晰吧 但我们也想 我们也想是说 当这个模型本身在Evolve的时候 我们基建这一块也可以跟着Evolve 然后 包括Diffusion对吧 Diffusion大家也是 过去年发现 Diffusion发现又变得很有意思 你虽然可能觉得 以前的Diffusion 只是一部Encode 一部DIT 现在发现我们也得做Diffusion Diffusion本身得做Diffusion 你可能Diffusion之间 Diffusion这一部里面 你得去把它拆出来 拆成各种Stages 所以 这个项目 做就想做这个事情 我们怎么样去把一个 多摩泰这块 多个Stage 管理给做好 然后怎么样去让 各个Stage之间这个协调 可以做得 做得更好 这样一个项目 然后 对 这大概是一个 大概是这个 这个项目的这个 前世今生 [00:07:06] 然后 我可能给大家 介绍一下 就是 月签是我们现在 这个项目里面的 这个TTS的一个负责人 就所有 Text Speech的这个 东西呢 都是 月签来负责的 然后志鹏呢 是我们这边 类似于 Walmany Habby Model的一个负责人 所以 类似于这种 混元呀 包括说Bagel呀 这种你可能 模型在 两个C之间 可以互相切换呀 这种模型 使智鹏这边在 在引导而做 然后我就是个拉拉队 我就是 基本上就是在这个项目里面 给大家 加油打气 对吧 就是有什么问题 可以我帮你 帮你帮你去问一问 这种类似于这样的角色吧 对 然后第一个问题是 你觉得未来 Omany模型会有多主流 现在Omany模型的大小 还是较小的问号 我觉得这其实是可以从 签问团队那边 看出来一些端倪的 其实 你当时看 签问2.5Omany 它最大是7B 然后第二版就上30B了 然后 [00:08:06] 再大一版 就是 最近放3.5 3.5虽然还没有放出来 放开源出来 但是你可以从那个模型的速度上感觉到它其实是更大的 我觉得这是一个 包括之前 忘了是林俊阳还是谁 他之前还在签问的时候 他在某个跟那次 大会上说过嘛 他们想的是scale up 包括他Omany提到的是雄之一 我觉得 包括小米对吧 小米最近也发那个 Memo Omni 就是他们自己的虽然没有开源 应该没有开源 他们也是一个很大的模型 我觉得 这一块 还是会继续scale的 因为 这一块还是一个没有被figure out的一个东西 我觉得 就是怎么样做Omany 包括training那边其实都没有很好的figure out 就比如说 Bidense那块那边做了一个项目 叫做vOmany 它是用来做多模训练的 那个其实也在很快速的发展 我觉得这一块还没有被完全的figure out 大家也在慢慢的探索 对 感谢回答 [00:09:07] 然后第2个问题是 请问Omany跟VLM有啥区别和联系吗 然后VLM就是一个L不是两个L 一个L 一个L 虽然是VL Omany其实更注重于 其实如果说 今天你想直接跑一个VLM的话 你用VLM就可以跑了 就是多么理解 这是我在主户做的 多么理解上 就是VLM就可以跑任何的多么理解 大多数 多么理解都可以跑了 然后Omany的话 更注重于说多么生成 像比如说 举个例子对吧 你切碗Omany的那个thinker 它其实就是一个多么理解的模型 你就可以用VLM主库去跑 但如果说你想跑 我想 文字图片或者语音输入 然后它同时可以文字加 语音输出的话 你就用VLM Omni 因为它后面有个talker 还有一个 那个 这是这两个的区别吧 然后 我最近在想要不要 就是以后把这些整合在一起 [00:10:07] 但目前来说还是要分开好一点 对我觉得是这样 对 嗯 然后 其实我博有一个问题 问一下 Roger 其实 Omany这个东西 它的从设计的思路上来说 它其实跟 以前其实TTS ASR的东西很早就有了 但是 我们当时其实在帮 比如说 亚马逊的个人助手 Alexa做这些 设计的时候 其实 当时思考的时候 就是类似于用一个 类似于 spark或者ray这样的pipeline 把不同的一些模块orchestrate在一起 然后 相当于就是做一个类似于这种nearline的一个pipeline 然后就把每个 不同的这个环节pipe进来 然后pipe出去 然后当时的话 其实我们就相当于就是把它整个一个 模型 然后不同部分 包括像 ASR ASM PTS PTS的 然后单独让他们去scale 去执行 这样能够最大化的throughput 但是如果说你参考于这个 [00:11:07] 但是这是非常多年前了 如果说你参考 当年这种架构和我们现在这个 OMNI 比你觉得 它最大的变化是在什么地方 首先 GPU 是最大的变化 首先就是 你的用的硬件不一样了 用的硬件之间的 interconnect也不一样了 包括你的模型的size也不一样 对吧 如果说 如果说大元模型 还是EB的话 那其实可能 这些我们都不需要 写本地跑就还了嘛 为什么要上服务器呢 如果都是EB的话 那你现在模型变大了 这是一个点 然后 第二个点是 可能还是跟GPU有关嘛 就是我觉得 这些很多 创新都是因为 模型在变大 硬件在evolve 然后 构架本身也有一些evolve 但是会偏向于 朝着 还是朝scaling方向走 东西在变大 所以你东西变大了 你KP cash变大了 对吧 所有东西消耗的 就可能 你单条请求 所需要的资源 开始变大了 [00:12:08] 那这时候就需要做好一个 怎么样去管理好 各个state之间的东西了 对 我觉得这是一个很大的区别 就可能 可能 可能 我个人经历 没有这么长啊 就可能 那个时候的 一个TTS 你单人请求 所需要的这个资源 这个compute资源 根线一个TTS 可能单人请求 所需要的资源 可能差了 可能就不止一个 或者两个数量级了 我觉得 这个 每个用户请求的这个资源 这个分布 是一个 非常 变化很大的事情嘛 就 我是这么觉得 对 对 其实我可以说一下 当时那个 那个原因 主要 这样做的想法 是为了能够 scale up 相当于说 我想要把 把它那个流量 吞吐量给 给增加 然后这样的话 我 我通过一些pipeline做 我就可以知道 我比如说 就算我 我没法优化我的硬件 但我可以通过去堆料 比如说我去增加这个环节中的这个机器 可以去 保持我整体的pipeline的一个稳定性 当时是为了这样一个 [00:13:08] 就是说我可以进行 弹性的增长 或者收缩 所以才做了一个 这种做 做环节skill 但我觉得从 Omin这个角度 因为它也是有 多个环节的 对 所以在未来它也会有面临这样的问题 对吧 对我觉得 肯定是会有的 对然后我包括 包括其实 Omin本身也会有 触及到 跟我们现在普通LM一样的问题 你怎么去做好一些 state管理 对吧 你可能之前的一些模型都比较stayless 这个模型本身 或者说这个 引擎本身 是一个比较stayless的一个东西 你现在是非常的stay for 我当时还在看完 因为我们大家都用cloud code 对吧 然后当时看了一下为什么cloud code的voice 这么垃圾 如果说它这个voice 这么厉害的话 我就不需要自己打字把我要说的事情全部出来 但你要看这其实这就是一个牵扯到 Omin的一个东西 这个我觉得是一个 目前 AI-infa就是比较和之前的不太一样的地方 [00:14:10] 对 好 然后那么第1个问题是在VM Omni里面统一 Auto-regressive和diffusion的工程难度是否很大 怎么做抽象 其实没有 我觉得没有统一 应该说概念上是统一的是stage 你怎么样管理好stage的一些 抽象 这个是最难的 那其实VM Omni里面 那个Auto-regressive就是 其实就是借用VM 然后 因为VM本身就是一个很好的Auto-regressive引擎 对吧 diffusion这一块其实更难 也不是更难吧 就是 我们不想搞得很抽象 对我觉得 最好的抽象就是stage 对吧 其实我这个stage里面 我跑 VM也可以 我跑diffusion也可以 我跑pop hacking face也可以 我甚至跑来西班都可以 我觉得这个stage本身抽象做好之后 基地里面跑什么 那是框架本身去定义的 但我觉得应该做得越flacible越好 对 不是说我硬要把这个diffusion拉到AR这边来让他支持 对 [00:15:14] 好 好那我开始吧 就是先跟大家打个招呼 我是林月谦 然后 也是VM Omni的这个committer 然后我可能先跟大家介绍一下整体的overview和跟Auto-regressive model相关的一些我们最近的进展 然后智鹏呢可能会更加的穿插的讲一些DIT 然后和我们之后的roadmap 当然我们是 非常希望有更多的这个同道众人可以加入我们的 所以首先是一个overview吧 然后 这PPT大家可能在别的地方也看过 所以我们 大概的一个想法就是刚刚roger也介绍了很多 我们有这个multimodal input 是吧多模态的输入 同时呢 我们也有这个多模态的输出 那么VM他们主库那边呢可能主要还是支持的前半部分 就是多模态的输入 其实你直接用他们的这个框架来 就行了然后我们额外的来这个加的这个支持呢 就是我们可以支持多模态的输出 那么同时我们在这个DIT方面也是 有很多对应的这个框架的支持 [00:16:16] 然后我们的这个slogan我们的goal就是 bill the fastest and easy to use open source omni model inference and serving engine 所以我们是希望能够 首先是 让他很好用很易用 同时能够 让他很快 同时大家都可以很上 上手的 都能够 是吧 用自己的电脑就来 deploy对应的这个 开源的模型 我们希望 就是越来越多的人能够加入到这个事情上来 然后 这个就是我们大概支持的一些东西啊 比如说我们输出 输出现在支持image to image text to image 然后text to audio text to video 所以我们 最最重要的贡献可能就是这个 从这个 传统的这个文字的输 输入和输出转移到了支持多模态的输入以及多模态的输出 包括我刚刚看就是有人在问就是主库能不能serve TDS的模型 其实我们把TDS是全部都放到了这个omni model 这个 库来做因为主库可能 [00:17:16] 比如说你做asr做语音识别的话 主库就 就是那边来支持 然后跟 语音生成语音合成 还有包括一些general audio generation相关的模型 都是我们这个omni这边来做 然后一个大概的这个 overview就是我们是支持 直接用一行这个python的这个interface来调用的 那么我们可以用 一个 from vm omni input omni的形式呢 去调用各样的模型比如说这个千文三omni的这个模型 那么我们其实在后面讲也会讲很多跟千文三omni有关的事情吧 因为刚刚roget讲这个我们 这个项目立项就是因为有千文2.5omni这个模型 所以我们也 因此呢一直在致力于 首先把这个千文三omni给优化好 然后才去 扩散到更多的模型来 好 然后这个呢是一个open ai的server的这个request 所以我们也可以像 vm一样来serve一个这样的omni model 那么我们只需要加一个这个omni的这个argument 就可以 [00:18:16] 支持用户直接来serve了 所以你要不加这个呢就直接 serve它就是 serve它thinker的部分 然后加了这个我们就可以同时serve这个audio generation 那么用户也可以通过这种 这个api code形式来 调用这我们对应的模型 ok 然后 我们同时呢也写了一些比较简单的这个example 包括这个千文三omni 还有这个应该是image generation或者video generation这个config ui的这个integration 那么 我们就可以 很轻松的在server完模型之后呢就用一些比较简单的网页的单目来看一下我们这个inference的一个速度 到底有多快 当然我们也在这个跟社区有这个vm playground的合作 同时也有这个对应的这个 网页的这个设计 那么 至今为止呢我们已经支持了30多个很主流的开源的这个omni和diffusion的模型 包括这个千问系列啊还有bagel系列啊还有美团的 [00:19:16] 笼包啊还有小米memo还有包括我们最近 队琳支持了这个Mistro的Voctro TTS 那么这些都是一些最近的一些模型然后我们也希望能够让他 就是 很快的能够这个 这个发出来让的用户可以亲自去试一下使用一下 然后 呃现在呢我们当然非常欢迎有更多的这个 contributor来帮我们看一下这个 对应的rfc啊然后参与一下一些相关的讨论 呃大家可以在github上去搜我们这个仓库然后应该现在有 非常非常多的艺术可以等待大家去解决啊 呃包括大家也可以啊 呃当然这是我们现在的一个0.18的版本吧我们大概和 主库是保持一样的这个顺序啊 但是我们可能一个月才去呃进行这个一个版本的这个release 呃然后我们现在已经获得了4000家的stars我们希望 当然有更多人参与这个项目的能够把这个项目做大做强啊 呃这个是一个呃我们的一些联系方式 呃我不太确定能不能放出来啊但是先 [00:20:19] 那就是欢迎大家这个加入我们啊OK我现在详细讲一下 这个呃我们这个系统的这个 呃workthrough吧 呃那么这几页ppt主要是想呃让大家在就是更加轻松的了解我们这个框架呃具体做啥 同时呃呃我们到底能够 对吧呃改哪些层进一步去适配这个对应的框架 OK那么先看看我们这个支持的模型长啥样吧 就是呃这是一个对应的这个总结性的一个图啊 那么一共有三类模型第一类就是以这个千文奥尼系列为代表的呃thinker token的这种类型的模型 那么他输入可以是文本图像音频那么输出呢这个thinker就可以直接输出这个 tags然后这个vocoder呢就可以进一步输出这个audio 所以呃他这个tags就相当于多模态输入和这个tags audio的输出 那么ar加dit的就是有 以gm image还有很多千文image等为代表的text image text video image to video的这种模型 [00:21:20] 那么他们呃可能区别于这个上一个thinker token就是他们decode的更多的有一些diffusion的这种呃呃框架 总是我们也有很多这个对应的optimization专门针对于这个部分 然后后面可能智鹏会详细讲这一部分 然后当然还有一些specialized generator比如说bagel他呃或者火源 image他有一些更特殊的一些这个 呃生成的这个部分那么我们也是对应的支持 然后呃所以他的生成方式可能和diffusion不太一样但是我们同时就是因为我们刚刚说的stage的这个概念也是能够放到我们框架里去呃做这个事情的 所以呃一个共同特征就是我们可以把这些模型分成若干个stage每个stage他的这个呃计算出来的这个特征不一样 那么我们通过抽象成stage的形式呢让大家可以更加简单的去接入一些呃最新的这个omni的模型 然后呃这里对比了一下我们呃所说的自回归和DIT的两种不同的这个差异吧就是为什么我们要分别设计呃他们不同的engine [00:22:24] 那么AR大家很熟悉就是呃VLM已经呃做得很好的关于kvcash关于prepure decode的这些优化 那么我们可以非常天然的把它拿过来然后再用对吧当然我们也加了一些自己的multification但是大部分还是VLM这个他们已经有的足够完善的支持 那么DIT呢呃他可能呃没有prepure decoding啊然后他同时也有一些不同的这个序列长度之间的问题所以呃我们也需要进行单独的优化所以我们把它抽象成两个不同的这个engine来在我们VLM omni这个仓库里去做 呃然后这个是我们这个项目的一个整体的架构图大家可以就是大概看一下就是 蓝色的部分是我们从VLM的仓库里面import直接拿来的然后呃黄色的部分是我们呃有些修改然后呃粉色的部分是我们提出了一些新的一些呃框架或者新的一些呃呃 呃方身吧然后最上层呢是这个entrain point那么呃 API server刚刚讲可以用来在线服务去呃serve这些模型 [00:23:25] 那么omni或者async omni呢他们是用于呃离线或者backend的这个推理的然后omni stage是我们说的抽象出来的新的概念 那么AR和diffusion这两个engine呢呃呃他可能有不同的这个侧重啊但是呃我们还是希望他们有一些这个相似点嘛 比如说呃这个呃AR我们呃从呃VLM本身主库里面拿来的这个M engine但是我们同时需要呃修改一些 呃部分能够让他暴露出这个hidden的这个states或者hidden embeddings 所以呢呃我们可以通过hidden embeddings进一步的去做呃下一步的比如说语音合成或者说 那再理解了之后再去做别的呃比如说image generation 那么这个是一个不同啊当然diffusion是我们完全就是从头开始写的 然后同时呢他们可能有一些共用的tension啊或者别的一些呃算子的一些优化 那么呃同时在这这些的最下层呢是我们的omni connect就是把不同stage之间怎么样去进行这个链接那包括 呃我们呃就是怎么tensor或者别的一些特殊的信息 [00:24:27] 呃所以encode prefill decode generation他们有一些呃天然的知识然后同时天然知识我们可以把它分布式的这个可能布置到不同的这个GPU里面 OK然后呃这我们同时也有一套这个硬件的这个plugin的这个插件的系统呃我们现在vm omni是支持呃GPU这个cuda然后rockm还有这个华为MPU 然后然后去可能还会接入这个百度的这个昆仑那么我们想做的当然是能够让厂商或者说更加呃轻松的去 用嘛就是我们我们一直说我们强调我们所有可能是易用或者说 易于上手所以呃我们把这个hardware就硬件相关的这个优化呢变成了一种就像这种插件的形式 所以呃按照不同的平台可能有不同的 对不同的算子有这个应优化所以我们让这新硬件的接入更加容易了 就是不需要改我们核心的这一套ar diffusion这个逻辑 只需要我们呃对吧也暴露一个插件的这个接口让这对应的模型厂商去进进一步去优化 [00:25:30] 那么我们现在其实也可以看到我们呃已经支持了啊不少的这个 这个芯片啊所以我们可以呃 服务更多的这个呃有需求的这个用户 ok 那就像刚刚说的我主要讲的是这个自回归的这个模块的设计嘛那么自回归呃相比于vom只生成于这个 tax就是文字这个输出呢我们同时 还生成了这个hidden imbalance 就是他不同比如说千文omni 他需要这个hidden imbalance直接拿来去做这个这个 进一步的云音合成啊不是说通过这个文字来做云音合成对吧不是这种 cascade的system 那么同时呢这个multimodal的这个latent token比如说 在token就是他这个云音合成的第2步 呃需要把它放到vocoder的时候他可能需要一些 啊autoregressive generation比如说不同layer在codec里面 他就是通过这种方式来进行传递就是我们还是把它包装到这个AR里面 但是呢他其实是有不同的这个功效 所以我们要新加一个这个 additional information 包括对于音色呀或者他的这个语音的 [00:26:32] 呃这个style instruction 那么我们都可以把它放到这个additional information里面 这样的话就可以在不同的stage进行传递 呃另外呢我们呃在这里呃大概总结了一下对于vom的这个三个关键的 扩展 一个是我们不仅仅可以处理多么态的输入了 我们还可以处理多么态的输出 所以我不仅有这个 文字啊我们还有这个视频啊还有 呃音频的这个输出 那么同时呢我们这个prob embedding或者说这个hidden state的传递 呃让我们整个这个 不同stage之间更加 容易获得上一个stage的这个 呃计算出来得到的结果 那么第三呢就是我们可以携带更多的这个数据就是原数据 可能他们通过不同的形式传递到这个整个 呃vomni的pipeline ok 然后呃 我们这是一个大概的简要的这个介绍啊就展示了我们大概stage到底是怎么配置的就是我们怎么去 做这个分离化的部署 [00:27:33] 那么呃前面三omni我们分为sangstage啊thinker toga和cote wave 那么分别是这个做这个multimodal understanding 然后是这个呃generation就是tds这两部托克和cote wave 那么我们可以把它放到不同device上面去 那么同时呢你可以设置在device里面这一个stage 所需要占用的gpu的这个这个 这个utilization rate 同时我们可以规定对应的这个 输出的这个形式 所以这样的话我们可以让 呃不同的呃模型其实去现在omni模型还没有到一个那种大一统的模式啊 还是不同的这个stage还是有很多呃特殊的一些设计的所以呃我们通过这样抽象成stage的形式呢就可以让 呃他们能够尽可能的呃复用一些我们框架的内容 同时呢我们也可以让用户在部署的时候 可以灵活的调整每个stage到底放在哪一张卡上 就是我们在维护设计的时候发现 可能很多人都是在和别人共用一张gpu 那么这个时候可能就需要调整呃这个stage的存放比如说我想在这里塞一个stage在另外一个gpu上塞另一个stage那么这样的这样的配置方式就天然的这个支持呃分离式的部署了 [00:28:38] 呃 同时呢呃我们可以看一下就是我们到底是怎么是支持所谓的分离式的部署的 那么在不同的omnistage上面我们是有这个transfer engine以及这个omni connector 那么呃thinker比如说呃还是以千万三omni为敌 千万呃他的thinker输出的是hiddenstage对吧那么他是一个float tensor不是传统意义上token的那个id 那么我们不可能直接就是把那个id拿来我们得把这个embedding传到下一个stage去做进一步的这个生成 所以呃但是我们不需要这个 操心呀到底他底层是怎么传的因为不管传的是tensor还是什么float point numbers什么的 我们的接口都是一样的我们都通过这个omni connector来进行这个呃 所谓的这个 呃说不同stage之间的这个transfer 那么第2个我们可以看到不同stage他其实是有很 呃两个可以说有两个不同的这个呃东西要传吗一个是 呃控制的信息比如说这个request id 或者说这个采样的参数 那么第2个呢是我们要传一些比较heavy的payload的就是他的 [00:29:43] 音频呀或者说他的整个embalances这个整个 呃matrix or vectors 那么这两个之间如果混在一起传的话可能就会 对吧拖慢节奏所以我们是叫做control and data plane decoupling 就是这两个呃是分开来的 这样的话可以更加 高效的去进行这个传输 那么第3个呢我们是 有这个混合的后端知识 那就是我们刚说的 如果你部署在一张卡上可能他们就放在一个这个memory pool里面对吧 shell memory 那么如果是多张卡呢我们会自动的就用这个mooncake 来去进行一个这个传输 所以的话 那就我们这个上层代码是不需要进行更改的我们会自动的去进行这个调整 那么另外一个呢就是 呃刚刚也讲了很多他怎么样实现不同stage之间的这个simless是无缝的这个传输的 然后我们同时 天然的也支持 把不同的stage放到不同的gpu上 然后可能 比如说 你想支持 每每个state多多部级台 那么这个也是我们即将就是 希望能达到这个elastic的这个部署的效果 OK [00:30:45] 还是拿千万三opni的举例 刚刚讲很多他我们这个stage大家可能都被绕晕了 那么他本然 天然到底是做啥呢 就其实和gbt4o差不多吧 他的输入是这个tax 和video还有audio 那么这文字音频视频输进去之后一个非常naive的solution 就是把他们去 encode完之后 放到thinker里面 那么thinker 在decode出所有的token之后再放下一步toker 那么这个toker其实也是一个自回归 自回归的一个transformer 然后继续生成进一步的这个音频需要的这个tokens 那么我们 和这个传统的naive的这个方法来相比呢 我们主要做的就是 我们 请求在经过process之后有这个不同的omni stage传输 那么omni stage再进行这个自回归的 tokenbytokengeneration的时候 我们是实际上是可以把 前面的几个 已经得到的chunks 这个output 就或者hidden states 给他放到 对应的下一个stage里面去 那么这个时候我们就 实现了这个 asynchronous的就是一步的这个生成了 [00:31:46] 那么我们就可以 更加高效的去 生成对应的音频或者说对应的其他的一些 multi mode 多模态的这个 输出 ok 这是我刚讲这个 如果是n2n的话我们可能 一开始需要等 thinker全部生成完所有token之后再把它传到toker 然后toker再进一步的传到 这个coated wave去生成对应的音频 那么现在呢因为我们有这个asynchronous的这个streaming的支持就流逝的音频的输出的支持 我们可以 把 所得到的之前的一些chunks 直接比如说第1个chunk得到之后我们直接就传给下一个stage 那么这个时候 下一个stage就可以继续进行下一步的操作了 那么我们不需要等 所有的chunk在第1个stage都生成完之后 才这个对应的去生成到下一步 所以这是一个比较显著的差距啊就是如果我们看这个手包延迟的 为什么手包延迟这么重要呢就是 比如说你在和一个语音或者视频的agent去说话的时候 可能我们用户的感知上来说可能只过了一会儿但是他 [00:32:47] 或者说都过了很久 我们希望能够缩短这个等待的时间 那么其实他不需要模型不需要思考完就可以直接开始说话对吧 因为我们可以直接在他说出第1个token的时候 就去生成对应的这个audio token 那么他的音频在进行播放的时候 其实你后台可以做很多步的对应的chunkwise decoding 那么这样的话 因为只要我们的模型足够快他的这个效率足够高 他的这个real time factor就可以做到小于1那么他实时 性就能够得到保障 相当于我们生成的这个音频永远都是比 对吧用户听到的要快 那么只要达到这个目的的话 其实所谓实时的这个或者说流逝的输出就是能够实现的了 ok 然后这个是可能更加细节一点就是我们到底 哪些组件设计到了传输数据呢 所以 最大是这个omni connector 然后里面有这个transfer的adapter 那么chunkwise呢他就是通过这个get和put 来传递这个对应的数据 所以 我们schedule的也做了类似对应的修改来支持chunkwise的这个调度 从而实现异步的这个 [00:33:47] input and output 然后 我们可以处理对应的chunk的这个实际的计算 然后这个是呃我们的一个 大概的 对比吧 就asyncchunk就是刚刚讲半天 呃他是怎么异步的这个chunkwise这个传输吗 那么开了asyncchunk之后他的这个 速度 在chunkwise上是 有很大的提升的 就是 可能一开始你要等那么久之后才能够得到第一个音频的输入 对吧 那个时候可能已经将近要10秒钟 但如果我们在可能他生成了头几个或者几十个token之后就开始进行这个进一步的音频输出的时候 他可以做到小于一秒钟零点几秒就可以生成对应的音频了所以这个 呃呃展示出来的这个 呃效果还是很可观的 我们最近也做一些对应的这个demo啊能够呃展示出我们到底有多快的就比如说用户只要展示出一个image就可以实时的去describe这个image 或者只是实时的语音就说出来哦这个图像是关于什么 啊这些还是非常我觉得 还是能够展示出我们呃对于手包延迟这方面特殊的这个优化的 那么呃另外一个就是TDS方面刚刚也说我是TDS方面的这个负责的这个同学吗所以啊我们也是 [00:34:55] 呃类似的这个千文三omni也是做了对应的优化 我们和这个having phase这种 呃传统的这种transformance架构来比的话我们是可以做到 呃非常快的这个 first audio就是或者手包的这个时间的 那么同时我们在高并发的情况下也能够呃去 扩展我们这个thruple所以这个还是 呃欢迎大家去尝试因为我们在社区经常看到各种各样的这个 关于千文三TDS的需求我们也发现 确实现在很多人在用这个模型所以我们也 呃真的是快马加兵每天都在去上一些新的一些 优化去给能够让大家更好的去 用他的这个模型 所以呃这是一个就是我录的一个小的这个demo吧 就是展示一下他到底啥叫是实时的流逝输出 就比如说你输入了一个这个文字之后我们按了这个 可能等这个这边会显示这个手包延迟啊然后等一会儿就可以 可以呃听到完整的这个语音的输出 Have you ever wondered what it would be like to travel through time and visit ancient civilizations [00:35:57] The possibilities are endless from witnessing the construction of the pyramids to experiencing the renaissance first hand 对其实大家在后面的时候可以看到看到他直接就写finish playback 那个时候就代表其实我们已经生成完了这整条音频只需要播播放就可以了 所以这个整整体这个speedup还是我觉得还是可以非常 呃呃简单的就能够体现出来的 OK然后现在啊志鹏可能要接下来讲一下 呃我们呃如何去做这个scaling然后我们 呃进一步的这个关于DIT方面的这个这个优化 我觉得我看你先打你先打你 对对对对对 赶紧赶紧打你对 我现在能看到第一个问题是 VM Omni有steph level diffusion contiguous flashing rfc 欢迎comment贡献 这不是问题 我看到有个问题是说LM有pd分离 Omni模型是怎么部署的 然后 所以我刚刚也讲了很多这个 呃其实我们在第一个stage 或者说thinker这个不他也是有 [00:36:58] 呃pd也可以支持pd分离的 只是后面stage可能pd分离它的这个 效率效率不是很高我们也没有上 然后Omni模型怎么部署就是 刚刚也介绍了我们通过这个stage的这个参数的控制 让他在不同的gpu和不同的 呃环境下去都能够进行对应的部署吧 但是我们希望核心做到就是能够优化不同的 呃就是能够让他一步的去处理这个数据流 同时能够在不同的gpu上去serve起不同的这个模块 对 然后 呃然后他有一句是目前Omni的优化 LM的哪些可以借用过来 呃 对这个问题 呃我我没太读懂但可能就是这个Omni的优化 这个在LM那边 哪些可以直接用过来哪些不行 啊 这个东西的话 因为我们这边主要是增加了一个DIC模块 然后DIC模块发生TP这个其实是可以直接用那个主仓那边的 [00:37:59] 然后 我们的这个flash retention的话是做了一些改动 因为我们这边的flash retention他是做那个fullmax这边的flash retention 然后还有一个就是相应于是呃主仓那边的话他有一个pd分离 我们这边其实lotikanet就是lotistage部署 有一些模型中间也是需要传kv开始的 然后这块地方我们也会参考他们那边的一些价格设计 嗯好然后呃下一个问题是有比较过omni和vlom上面tts的区别吗 对这个可能就是呃我们所有的tts现在都是vlomni上面的支持 就是其实就像roger一开始说的我们呃一开始是呃有人在vlom主仓提了一个pr 想支持呃千万3omni或千万2.5omni这个tts 或者说语音合成的这一步 那么呃后来我们就直接就是 把它单拎出来放到这个项目里来做了所以 大部分的tts模型就是全全都在这个框架里面然后大家也可以去试就是 [00:39:00] 呃我还是尽量support了一些最新的state of the art的model的然后当然我 目前看到用户反馈最多还是用千万3tts 但是像呃vostro tts就是mistro他们最近release的也是一个非常小而且非常快的一个模型 呃大家可以去用我们框架部署试一下 嗯好然后呃下一个问题是 就是vlomomni支持fp8量化吗 呃这个东西我们如果是ar部分的话是跟主仓完全一致的如果是dip部分的话有多个模型是支持的 就是我们现在在dip部分的话实现不像主仓那边他有比较好的机内 然后网织有很多模型属于是比如说我需要支持fp8 那么我就需要 去在这些目标中去传一些参数让人和支持fp8 所以非常需要社区人来参与 我们这个做很多的重机的基础这个模组的一些贡献 嗯所以大家这个这个 想搞开源的赶紧过来好吧这个一个project的还并不完备有很多contribution的机会这个是这个是不多见的啊 [00:40:06] 然后呃下一个问题是呃算是stage分离吗那听起来好像是就听起来这个架构应该是stage分离的一个架构是吗 嗯对对呃好 嗯 那么下一个问题是vlm ovni里面的声纹部分性能对比vlm有差别吗还是一样的 呃这应该是完全一样的因为我们基本上是完全使用的是 我要命名的他这个backup就是backup就直接去呃继承或者是直接去使用现在的一些时间 嗯嗯还有一个问题就是这个意思在问就是diffusion server由于step的差异不能continuous batching应该怎么处理高并发 他们是三四了一下啊 这是个非常好的问题 这个问题其实也是非常需要社区参与的东西的 其实呃diffusion的这个batching它是可以去做continuous batching 然后呃我们考虑的是在qr的时候参考这个vlm里面的这种做法在skydwell里面 [00:41:08] 他会去把一些不同的请求 然后在不同staff的一些batch 组成一个那个在一起的batch 然后在里面去计算 然后比如说有的呃staff已经算了之后 他要他打新的一些staff从staff0的一个 request进来组成新的一个batch进行后续推移 对这个东西是我们qr的时候一个需要先做特性 然后如果有同学对这个感兴趣的话 可以进来参与一下 嗯这一块我想问一下是类似于 multi嗯microbatch这种感觉的这种parallel吗 对还是呃这个 这个东西就是因为它在diffusion model里面的话 我在常规来讲的话其实有些公司说 一开始我们认为这个diffusion的话 它这个操作它属于是companybound 就是不太适合主batch 但是我们自己在测试下来的话 实际发现这个现在显卡性能下太强了 一般情况下是完全计算上面出口余的 [00:42:09] 所以说而本身这个diffusion的生存 它是本身在多少很多staff进入解码形式 那么我们就会把不同的request 处在不同staff的一些计算把它拼在一起 这样子来做 嗯好然后这位同学问了一个follow up question 就是那不是需要timestamp输入会不一致吗 就可能是对diffusion的一些问题 嗯对这个东西的话我们现在来看的话 就是它 一般来讲的话你组成半计划 其实不会对这个timestamp一直造成一些影响 然后这个东西对我们现在是有一些同学正在探索这个方向 而且我们其实来讲到有些公司他们自己内部做这个dip模型的部署 他也是采用这种类似的思路在做的 好然后下一个问题是新增一个新的模型需要适配哪些 嗯这个是case by case [00:43:09] 主要是看你新增的模型是什么类型的模型 如果你的新增模型是一个纯dip模型的话 其实你把这个diffuser里面的模型翻过来 然后把它一些模型改成我们自己的模型 就可以比较好的适配了 然后如果你这个模型是multistage模型的话 我觉得最好你先提个rc 就介绍一下自己这个模型是需要怎么样去拆分的 然后中间它是传什么的 因为multistage模型的话可能它会对我们的正方架里面 那些核心代码进行改动 我们可能需要更多去讨论一下 然后后面才会去设定个具体的模型 应该怎么去configure 嗯好 然后我这边有个小问题 就是我看之前我们omni这边是用put和get作为这个存取的interface 那么这个put和get的key是怎么算的 是指什么什么的interface [00:44:09] 就是我之前看到了我们做这个staging 然后在staging中间传data的时候 用的是一个put和get的标准interface 然后put和get一般需要个key 然后很好奇这个key是怎么算出来的 key是用这个比如说是用图hash出来的 还是用这个tensor本身做了hashing出来的还是怎么算的 staging之间的传输的话 其实它主要是依赖于request的id 然后它staging中间传的话就是有传 有传这个token也有时候传这个hash 然后就是呃现在来看的话 其实只有ar部分是完全支持perfect开始了 然后其他部分的话其实是基本上没有什么 怎么kvmine 你这位啊什么这些东西的都是没有这些东西的 现在所以也是非常需要大家来参与这个里面的贡献 对 好那么下一个问题 diffusion相比ar decode compute bund更加显著 还有必要捕捉复杂graph吗 呃对这个其实是个很好的问题啊 [00:45:15] 这个 其实我们里面是有些人去尝试去捕捕claw graph 但是确实这一块的话它 没有一个很显著的注意 diffusion它有自己的很多 特异性的这个退价速的技术 这个我稍后也会去讲的 常规来讲的话我个人认为可能 看不像是这个ar模型里面对于 这个比如说decode的阶段的话 这个claw graph属于那么明显 然后接下来就属于是该我来讲的 对吧 其实我因为我的主要目的其实是 希望更多人来参与到我们海底项目的 所以你可以把我当做就是来带货的 对吧 然后这个月前刚才讲的就属于很专业了 然后后面这一部分的话 这个 呃一个是我主要会讲一些这种分布式的部署 然后它一些 呃 针对diffusion模型的一些特性 然后以及我们一些未来的长官 这个基本就属于是很多的 任务都是需要大家一起来帮忙 然后去做贡献的 你可以这么理解 [00:46:15] 好 首先就是 我们 现代的话是支持一个multi stage 然后multi device的一个部署 部署的 当然这个pr的话呃你可以看到是我们一个大概是在两个月之前的一个pr 但是其实最近的话我们发现这个pr可能也是需要有一些改进 对吧因为我们现在这个实现的话 呃他是只能够支持每个stage就是部署一个实例的 我们如果是参照这种pt分比请示的话其实是需要部署多个实例的 然后这个就是我们这个pr的一个大概设计 我们会先起一个 呃 呃头的一个 一个这个一个server 然后的话我们再起一个hide list的 然后这个hide list的话 他就跟这个头去进行连接 那么我们就可以在两个机器上面去 那个在不同机上部署不同的stage 把它拼成一个 很完整的部署 呃目前来看的话可能在汇圆一密集这个模型里面他会非常需要这种类型的部署 [00:47:16] 因为汇圆一密集它本身是一个80b的一个模型 然后 他的这个AR和DIT的这个速度也是 差别很大的 我们可能会参考这个pt分比请示 就是部署一个AR之类 比如说4个DIT这样的实例 然后最后把它评计 当然这个汇圆一密集它也是一个支持 呃就是image input的text input的和text output的和image output的一个模型 所以它参数大于很大原因是因为它非常依赖于模型本身自身的配理能力 呃 嗯好 这个就是我们现在这个呃 OMINI模型里面的一些知识情况 对然后其实可以看到我们现在 完整支持的OMINI模型 大概就是这些 就是 然后它里面的话 只有这种 Odio的模型 它是支持这个窗口的 然后如果你是做OMINI模型里面的生土 任务的话 它其实 [00:48:17] 呃就是尽量的话 就是在AR部分的话使用AR的退架式技术 然后DIT部分使用DIT部分的退架式技术 然后中间 去通过一些OminiConnect传出它的token或者是KWC 好 然后这个就是我们Diffusion Modules Design 我们Diffusion Modules Design的话 现在设计 其实基本上来讲 就是尽可能去参考主仓的一个 呃 Language Model的这个安全来进行一个设计的 然后我们 呃 现在就像我说这个Scheduler的话 它其实是需要有些改动的 就是我们现在这个Scheduler它其实就是 一个 呃 放不进来 然后我把它放到个对列里面 然后取出个对列 然后进行一个N部的一个sample计算 然后再输到这个唯一的Decode的里面 但是实际上我们是希望可以做这个continue Biton的 所以说也是很希望大家可以在里面做一些贡献 [00:49:19] 然后这个功能做好之后的话 可能也会更有助于这个商业化的部署 然后这里面也讲了Diffusion它里面的一些 配以加速技术 除了在这个我们现在在AR里面经常见到的像什么TP 然后DP和EP 然后我们现在实际上Diffusion里面后面也会有这个PP 然后它还有Diffusion里面一些自己特殊的 它的SP是指的是USP 然后还有REAL ATTENTION 然后还有一个HSDP的话 基本上是参考FSTP 然后做的一个权重的 就是权重的一个直接的切割 然后VAE的话它有个VAE 那个Pething 就是它会把这个图像的Heading States 切割很多块 然后每块中间做一些覆盖 然后这样的话 可以对它做成一个VAE层面的 图像解码这块的一个并行 然后同时我们现在也在支持一些 Penitalization 但是Penitalization的实现基本上全都是 [00:50:21] Case by case的 就是一个模型的话 我们要支持它的Penitalization 然后我们就会 去对它的模型本身做一些改动 然后让它去支持 然后因为Diffusion的使用的话很多场景 是用户使用自己的个人电脑去部署的 所以说我们在Diffusion里面是支持了 ModuleWise和LayerWise的 它的Module的话会逐个的从CPU加起来到GPU 然后如果它上上之后就从GPU再 卸载回CPU 然后LayerWise的话就是会预先的加在几层 为模型权重 然后算到这里来之后再把算过的文件权重 也能切带回去 因为很多用户的话它属于一些 掌握一些边缘设备 或者是使用个人电脑 因此这些技术 对于Diffusion来讲可能会更加重要一些 然后当然还有Diffusion它里面还有一个 HDIT和DIT开启 这种加速的话 它带来的一般来讲是有一些精度损失加速 但是它确实可以带来一个很不错的速度提升的效果 [00:51:24] 好 OK好 这个我们如果是单纯的去部署一个单 Stage的Diffusion模型 它的一个Request的一个流程 这个流程就是这样之后先到安键 然后安键的话它把它通过scheduler 把这些情统放在对列里面去 然后Worker的话 它DiffusionWorker和Diffusion DiffusionWorker和主仓的这边的实现基本一样的 也是去获取它的一些的parallel的一些通讯组 然后到ModelRound那里面 我会去调用模型里面的Pipeline 然后去在这里去执行它里面的一些Pipeline 然后我们因为Diffusion Diffusion我们现在有些模型它Omini模型的话 它中间是需要去传KWCache的 然后KWCache的话 它跟托衡和黑色Stage不太一样 托衡和黑色Stage 我们是可以在Omini的调度这一块 [00:52:27] 直接去从Stage的output里面去取它 但是因为OilMod它的一个比较特殊的地方 就导致你的KWCache是想得从ModelRound那里面 然后根据Schedule 你的BlockID去拿你的实际的KWCache 所以说我们为了做一个对齐 在整个OilMOmini里面 对于DIT模型和AR的模型 它的ModelRound都做了一个改动 这个改动就是用来去发送KWCache 和接收KWCache 好 然后这个东西就是TCache和CacheDIT 这个图是AI生成 所以你看其实有些地方它是有些问题的 然后如果很多直播间同学 可能之前只做过AR相关的 对于DIT模型不是很了解 DIT模型里面的话 它是有一些类似于量化形式的特殊的加速技术 [00:53:28] 然后它这个东西的话 但DIT模型本身也是支持量化的 但是因为DIT它生涂模型 它对于精度要求非常高 所以说一般来讲的话 DIT模型它 的量化是没有办法开得很大的 很多这种 MP4的这种精度量化其实是很难去做的 然后我们一般来讲的话会采用另外两种 比较特殊的架色技术 就是这个Tcache和KDIT 然后这个东西怎么理解呢 我觉得就可以把它想成 比如说我有个工厂 然后我工厂里面的话 我做一个架工一个零件 然后这个零件比如说我可能需要20天去加工 然后每个架工工序里面的话 它可能会有50个工序 就是DAR这个模型的50层 然后Tcache的话它的整个操作 它是可以去对于你这个一天的工作来进行跳过 就比如说我一个员工 我发现今天我最后生产 我拿到的样品跟我前一天或者前几天我拿的样品长得差不多 [00:54:32] 我就直接拿起同一天或者前几天的架工之后结果 就当中我今天加工就完成了 我今天这一天加工我就直接跳过了 这个就是Tcache的一个基本的原理 然后开始DIT 它真的是我一天里面加工 我先做了几道工具 然后做了一半之后 我看到我这个结果跟之前某一天的结果长得有点像 那么我就直接把这一天 它在工序之后的所有的对于我 Hidden state这些改变 直接加到我现在的工序里来 然后这样我就可以把后面 这一天的工具也全部跳过 所以说Tcache的话 它是做一个layer级的跳过 然后开始DIT的话 它是做一个block级别的跳过 一般来讲的话 当然它它两个具体来讲的加速的效果 以及它对于原图的进度上损失 也是需要case by case去进行测试的 然后我们Tcache的话它有个比较特殊的地方 [00:55:33] 它是需要去传 它是需要去算一个多项式系数做拟合的 然后我们现在这个仓景也提供了一个多项式系数拟合工具 所以如果有同学 比如说想 做一些 Good first issue Good first的一些pr的话 其实是可以去直接用我们的工具 去算出一些多项式系数 然后去拿一些现在还没有实现Tcache模型 做一些贡献 这样它可以很快的 去实现一个比较好的fature的贡献 然后这个东西就是讲的 DiP模型中它会存在的一些并行技术 它有些是可以一起使用的 然后有些就是不能进行一起使用的 像tp fp里面的usp和ray 还有CentG 它这些都是可以一起使用的 而hsdp的话因为它是直接的把沉重进行平分的 然后VaE排行的话 它这块地方也是不能跟前面进行一起使用的 [00:56:37] 对然后 我猜我可能sp的话 它这块地方可能会跟 AR部分的不太一样 它SP的话 它指的是一个叫Ulysses Parallel 然后还有的是ray attention 然后它后面如果这个东西 就是USP的话 它其实主要就是在attention地方会做两次O2O 在进来的时候 它的Sequence会按照你Sequence维度进行切割 然后做第一次O2O的话 它会把你的kvhashkv的hide 进行一个安投的切割 然后后面计算其实会跟 这个tp部分的计算非常像 然后算完之后 它这个tention完之后 它会再做一次O2O 再返回按照Sequence维度的切割 然后6个tention的话 因为它主要是在做 SortoMax的这个地方 [00:57:38] 它会去做一个 这个tention的它是一个交换 所以说它这本身USP跟锐尔分线本来是正交的 它两个可以一起开 然后因为现在有些模型的话 它使用的也是带EP MOE架构的 所以说我们现在也是支持DP和EP的 然后这个就是一些模型部署的一些小tips 就比如说我们现在的话 这个word size它是等于TP乘SP 然后乘PP乘CFGP 然后再乘DP CFGP的话其实可以把它理解成一个特殊形式的DP 因为不像生成的话它需要有一些 这种参照 可以说理解成这种反向提示 然后实际上的话就属于是要把一个请求 变成好几次来进行个request [00:58:40] 然后它CFG的话 就是把这些请求分开来进行计算了 所以说它这个东西跟DP非常的相像 然后这里面也是说 比如说如果我一张卡放不下的话 那么你可以去采用TP和HSDP的 因为他们是对于全动静的风格 然后如果你的sequence 认识太长的话 你的active的进货值太大的话 那么你可以采用USP和热的tension 然后如果你发现整个的推理速度太慢的话 那么你可以开CFGP CFGP它属于是加速效果最稳定也是最明显的 然后VEE的decoding 因为它这一块地方 如果站中性固很大 所以说它有可能会速度比较慢 那么你可以使用VE拍些parallel 好然后这个就是非常需要社区的同学们来帮忙的 这个里面展示了我们现在所有的知识的模型 以及支持的避免技术 可以看到其实有很多的避免技术 [00:59:41] 都是目前不支持的 然后如果想参与到我们科学项目的同学 就是可以拿这些东西来作为你的第一个 good first PR 然后我们可以非常乐意的帮你去远入 然后去合并你的PR 然后这个里面也是 前面一个是做的生图的 然后这里面是生视频以及生音频的 然后这里面也是有很多地方都是需要大家去来贡献的 然后就是我们的联系方式 然后就是我会介绍一下的 我们0.180这个版本的发布 这个版本是上个月月底里发的 属于是我们一个 QE版本的 就是QE这个季度的话 最后一个总结 就是讲一下的我们QE大概做了些什么东西 首先我们会我们支持了很多的模型 然后我们 对于量化的这块知识 虽然现在是case by case [01:00:42] 但是我们尽量的是先让用过线路用起来 所以说这个哪个case by case 我们也是尽量的先去对一些主流的模型 做一些量化上的知识 然后我们的量化有一位同学 他属于是做的很细致的 因为diffusion model的话 它量化的每一层量化其实对于进度影响是有很大区别的 所以我们同学他是逐层的进行量化上的尝试 看哪些程序可以做量化 然后进度影响不大 然后哪些层的话他的量化进度影响是比较大的 然后他这种方式的话 去做了一个比较复杂的配置 让模型可以在 尽可能的量化程度下能够不影响进度 然后也是因为这位同学他在量化这一块的 耕耘很多 做的贡献很大 然后他成为我们这个项目最新的commeter 对所以说 想参与我们这个项目的话机会是非常多的 而且你只要贡献多的话 也是可以像我们一样成为这个项目的commeter的 好 然后再来呃就是我们 [01:01:45] 嗯支持了一些呃文生视频的模型 就是像这个high loss high loss这个模型的一个特点就是在于它可以支持 有很长的序列输出力 大概可以一口气剩成一个长达几分钟的视频 然后这一点的话也属于这个比较有特色的 如果大家新加入这个 为了money的话 抢商场的话 也可以还是可以 先去尝试 跑一下我们藏商的模型 一方面的话你可以去熟悉 我们这个软件应该怎么使用 然后再另一方面的话 就是你说明你可以发现一些bund 然后这个的话 你提这个bund也会变成一个非常好的 其实如果想在太原项目里面 尽快的让你的代码合并 其实很关键一点 是在于你需要去换一些演员 就是让更多的人可以在特别是每天的可以在一些pr或依序中经常看到你的身影 那么他比如看到你提了一个新的pr 然后他感觉你很眼熟 他可能会有跟大家的兴趣去看你的pr是怎么回事 [01:02:48] 可以加速你代码的合路 然后这个就是我们QE阶段的一个非常重大的改动 我们在原来的架构里面的话其实基本上就是上面有一个大的掉漏器 然后底下的话就是完全去 嵌入一些vm里面的原本的工作流 然后我们再做了一个diffusion的 然后就是跟diffusion的一个安装 它跟lm安装的话就属于放在一起的 然后vm里面的话因为它的位移引擎之后 它实际上就是把前端部分和它的后端的部分做成了一个两个进程 然后中间用zm和q进行通讯 然后这个东西是我们一开始v0的时候做的一个架构 然后qE版本之后我们考虑到 就是我们按照v0来讲的话 实际上我们是中间是有三个进程来进行通讯 最后才能够到达实际上的模型直行 [01:03:51] 对我们的调度器跟让我自己的前端进行融合 那么我们之间的原本的进程通讯就变成了线程通讯 然后只在最后模型的直行的按针扩这里 采用的是线程上面zmq进行通讯 然后基本上来讲的话 所有multi stage模型都可以因此获得 就大概都可以获得一到两秒钟的一个收益 然后这个也是我们跟vr做的一个对接 就是我们在vr里面在支持的用gram Omini作为它rollout 然后去支持了千万一密集的一个实现 然后如果有同学们比如说对rl感兴趣 特别是多摩泰的rl的话 其实是非常建议大家来参与到我们开源项目 然后我们在qr头是计划针对更多的这种 Omini模型 就是特别是multi stage模型 [01:04:51] 做一些rl的实配的 比如像是vagle 然后还有像是千万Omini这些模型 然后比如说因为现在rl也是还是挺火的 大家比如说对这个发展感兴趣的话 完全是可以参与到我们开源项目的工钱 然后我们区域里面的话一个是做了一些 对于一个支持 对于一些厂商 这个一块的话可能 这个功德强度就比较大 然后因为也是一些有保密性的问题 所以可能这个东西很多都是我们每天的去熬夜去做的 然后再就是hallowware的support 我们跟一些主流厂商有很多的对比 然后我们帮他们我们做了一个类似于hallowware的 那种插件的形式可以让我们更好的去针对不同的 硬件平台进行的适配 然后再一个就是跟vrl还有vomini 做的一个rl的integration 我们这个设计是一个非常有爱的设计 大家可以经常来这边滑水 [01:05:53] 然后看一下我们这边聊聊天 这样子都是很好的 然后这边我来介绍一下我们的qr的计划 这个对方就是 我们需要因为hallowmini这种模型的话其实不光只是我们所见到的一些比较常规的这种比如说语音到语音的或者是图像到图像的这种模型 其实hallowmini模型里面有两个很大的类别 就是我的model和vrl model 这块的话我们是已经在有rfv了 然后也是 有一些找到一些 愿意去给我们这个仓库 做贡献的一些问题 来给我们去做这些模型的支持 然后如果有更多的比如说正在research的一些同学 或者是一些正在 一些frontier airlab专门做我的model同学 其实是非常欢迎大家来我们这边互相讨论一下交流一下子 对因为整个项目的话我们是在广泛的收集意见当中 [01:06:54] 同时我们也希望可以 获得更多的对于我们框架改进的建议 所以如果有人现在正在做这些研究方向的话 我是非常希望大家可以参与到我们的讨论中去 好然后这个就是我们现在正在做的一个streaming input的一个support这个东西我们之所以做的一个很大原因 也是因为针对wordmodel和vla的支持 因为wordmodel的话它是需要流适的视频的输入 然后是需要一些操作键盘上的输入 然后这些东西其实就是一些streaming的types input 然后在output上面 wordmodel的话我们现在看到一些wordmodel它是做一些流适的视频输出 然后我们必须得让它支持streaming input的流适的输入 我们才能够把wordmodel和well也能够正常的跑起来 当然这个东西其实是我们的一个rfc 然后现在也是正在完善之中 [01:07:54] 目前的话应该我们应该是有一个audio的streaming input 做一个第一个支持 然后这个支持之后 我们就可以自由的去跟AI聊天 然后你可以随时去打断它的说话 然后这可能会是一个很好的做产品的方向 好 然后这个也是我们qr的一个计划 我们qr的话是需要支持multistage的model的 比较有代表现在就是bego和千问omini 特别我觉得可能圈后mini它是一个很不错的方向 因为我个人自己使用来讲的话 我感觉圈后mini这个模型的话 它可以 或许可以给我们带来一些新的一些启发 你有时候会真的感觉一个响应速度很快的AI 它某种程度可以给人带来一些情绪价值 对吧 那么在语音这一块的话其实语音的音色 [01:08:55] 然后语音的一些人说话的一些技巧 包括一些AI口头禅 这些东西我觉得都是可以通过一些后训练的工作来解决的 那么我觉得这种东西其实非常适合做成一些 来给人带来这种情绪价值的一些好的产品 所以大家如果有人对multistage的model的后训练感兴趣的话 也可以去来多关注一下我们项目