Language: Chinese
[SRT]
1
00:00:00,000 --> 00:02:05,666
啊，我是来自这个 VLM 团队的尤凯超。啊，我今天简单跟大家分享一下 VLM 项目的一些整体介绍和最新进展。嗯，其实这是我第二次参加 GopherCon 大会啊，就是去年啊大概十月份的时候也是在北京，呃，我们在 GopherCon 上面展示了这个 VLM 相关的一些内容。那么今年呢也是借这个机会再跟大家呃更新一下这个 VLM 一年来的一些发展。啊，在座的朋友可能也有些这个对 VLM 不熟悉的，所以我们先简单介绍一些相关的背景知识。呃，由于当前这个大模型计算它整体还是一个 auto-regressive 的自回归的结构，所以啊这里面的一个关键问题就是自回归过程中的这个中间状态的管理，也就是 KV Cache，这个是啊大模型高效推理的一个关键。那 VLM 项目呢它起源于这个二零二三年发表的 Page Attention 的这篇论文，来自于加州大学伯克利分校的学生，他们提出了这个高效的组织 KV Cache 的方法，也就是啊大家现在所说的 Page Attention，能够提高显存的利用率，加速大模型的推理过程。然后 Page Attention 结合 Continuous Batching，其实也就是 VLM 项目的一个雏形。那么自这个二零二三年六月份开源以来呢，VLM 项目也很幸运的受到了社区的巨大的关注。两年多以来呢，我们现在已经收获了超过五万七千多的 GitHub 的 Star。然后我大概是在二零二四年的三月份左右加入 VLM 项目的，呃，那个时候呢其实可能只有一万多 GitHub Star。然后一年多以来我们也是共同见证了这个项目的成长，而且大家看到这个 Star 的速度，这个增长的速度其实还越来越快。啊，呃，我昨天在这个上海的外滩参加一个外滩大会，然后蚂蚁发布了一个这个开源报告，反正在 GopherCon 也发布了，这这里面其实也提到很多次 VLM，那么在整体的这个开源社区里面啊排名第二，也仅次于 PyTorch。

2
00:02:05,666 --> 00:04:07,106
那由于 vllm 发展的比较早啊，所以这个社区的支持也是相当广泛的。那么 vllm 基本上可以支持大家大模型研发的这个整个的生命流程，包括像 worl啊，unsloth啊，lama factory啊这些后训练啊，微调啊，量化的框架。啊，以及像 langchain 啊，defy 啊这些应用的框架，都是有 vllm 的支持的。然后不管是像 nvidia、amd 这些芯片厂商，或者说 google cloud、aws、阿里云这些云厂商，或者说 deepseek 啊，moonshot 啊，千问啊这些大模型的开发商，啊都是有在用 vllm 的。那么 vllm 的整体目标我们就是希望构建一个又快又好用的大模型的推理引擎。那么它的使用方式包括这个 offline 的 lm layer，包括像 worl 之类的这些强化学习，他们一开始就是通过这个 offline inference 接入进来的。然后还包括这个啊，这部分 api 现在其实基本上是一个社区的标准。然后呢 vllm 也可以作为一个完整的这个 openai 兼容的一个 api 的服务器。然后大家也可以通过各种像中间的这个转换键接入 cloud code 啊，gemini cli 里面。或者说也可以作为其他这个推理引擎管理器的后端，像 nvidia 有这个 triton inference server，那么它通过 async lm engine 接入的方，呃，接入的方式来启动 vllm，然后它自己负责这个请求的一些管理。那么 vllm 支持非常广泛的模型，这里面基本包括了所有的主流的文本生成的模型，也包括这个输入模态是一些语音啊，文本啊，图像啊或者视频的一些多模态的图形。那么在过去这个一两个月呢，国内的大模型厂商也都非常给力啊，发布了非常多的开源模型，包括像呃 step three 啊，kimi k two 啊，千问三啊或者三 next，包括 glm 四点五，文心一言四点五，腾讯混元，书生 s 一等等等等模型，这些模型都是有 vllm 的这个官方支持的。

3
00:04:07,106 --> 00:06:13,826
然后对于一些其实没有 VLM 直接支持的模型，我们也和 Hugging Face Transformers 有合作，设计了一个这个 Transformers 后端，就是你可以在 VLM 里面直接运行一个 Transformer 支持的模型。啊目前这个支持一些比较简单的，像文本生成模型，呃就是文本输入和视觉输入的一些模型。然后对于模型开发者来说，我们也提供了一个模型注册的方案，就是你可以把 VLM 之外的模块导入到 VLM 之内，让它能够更方便的使用，而不需要去修改 VLM 的代码。啊我们时常惊叹于社区的创造力哈，最近 VLM 还支持了一个 I/O processor 的一个插件，它的意思是你可以在 VLM 里面这个定制输入和输出是如何处理的。然后呢你就可以用这个方式让 VLM 去运行那个模型，然后你来管理这个输入输出的处理，从而可以处理一些这个图片、视频，甚至说雷达的数据。这里要感谢 IBM Research Team 的贡献，比如说这里是一个拿 VLM 去做一个类似 segmentation 的任务，就是去识别这个城市里的洪水的区域。啊我们可以从这个大概三个角度来总结 VLM 支持的模型。那么从模型的这个架构层面来看呢，包括标准的 Transformer、MOE 模型啊，像 State Space 模型啊、Linear Attention 模型之类的。然后从支持的模态来说呢，包括文本啊、语音啊、图片啊、视频啊、混合的。然后支持的任务来看，我们不仅包括自回归生成任务，还包括一些计算 embedding 啊、reward 啊、rerank 等等这些一次性生成的任务，我们把它统称为 pooling 的任务。呃 VLM 支持这么多模型，然后用户也经常在问说，啊我就用 VLM 怎么运行某个模型呢？那么为了回答这个问题呢，我们现在其实开启了一个子项目叫做 recipes，就是用于记录我们常见的模型的一些运行的命令，方便用户快速开始。这个网站就是大家直接点击那，呃这个输入 recipes 点 VLM 点 AI，就可以访问到就是常用的这个模型，我们怎么用 VLM 去运行。

4
00:06:13,826 --> 00:07:56,162
然后呃，VMM还不不仅支持很多模型啊，我们也支持非常多的硬件。那当然大家用的最多的是 Nvidia 的 GPU，那我们还支持像 AMD 啊、Intel 它们的 GPU，啊包括 Google 的这个 TPU，啊这个叉八六和 Arm 的 CPU 等等。啊我们也感谢像华为公司的呃等公司的努力，我们也实现了一个硬件的这个插件机制。那么通过插件机制来支持像 AWS Neuron 啊、升腾啊、Intel Gaudi 啊、IBM Sparrow 等等这些芯片。那么未来我们觉得这也是一个大方向，就是我们希望进一步减少 VMM 项目本身里面的这个硬件相关的代码，更多的通过硬件的这个通过插件的形式把硬件接入进来，这样子能够简化 VMM 的代码。那么现在有了这个插件机制之后，其实增加一个硬件的插件已经不需要 VMM 的参与了，厂家自己其实就可以做到。像国内的一些啊沐曦啊等等，他们就是有他们自己的插件，可以直接接入到这个主流的 VMM 里面。那么以升腾为例呢，就是用户呃需要安装 VMM 和 VMM Ascend 的这两个包。那么大家可以把这个看作是一份这个，呃就把 VMM 看作是一份接口，然后它包含了在 Nvidia GPU 上的一个标准的参考实现。那么 VMM Ascend 呢就是这份接口的零点七点一版本在升腾上面的一个实现。啊所以大家安装一份接口，然后再安装一份实现，就可以把 VMM 在各种硬件上跑起来。所以说 VMM 的责任呢就是和这个各大硬件厂商一起说我们怎么去协调沟通这个接口，然后制定出一个合适的方案，方便大家都能在各自的硬件上做一个非常通用的优化。

5
00:07:56,162 --> 00:10:34,818
啊，得益于这个 VLM 的多样化的硬件支持呢，我们也可以在很多像啊 Google Cloud 啊，NVIDIA 的 GTC 大会上面，很多地方都可以见到 VLM 的身影。然后包括像这个 AMD 的发布会啊，Kubernetes 社区啊，这些也都是 VLM 的这个紧密的合作伙伴。当然这一切呃的支持啊，也离不开像这个 PyTorch 的支持，因为这些硬件它们一般都是首先支持 PyTorch，然后在这基础上呢再增加一些这个算子啊，模块啊，然后再接入 VLM。所以也感谢这个 PyTorch 在生态系统里面提供的这个非常关键的受邀结构的这么一个地位，使得 VLM 基于 PyTorch 就可以兼容这些硬件。啊，也正是因为我们和 PyTorch 项目的这个紧密合作的关系，所以我们在去年十二月份的时候加入了这个 PyTorch 生态系统，成为了一个 PyTorch 的生态项目。然后呢再进一步的我们啊今年当 PyTorch 基金会扩展成一个伞形基金会的时候，VLM 也是第一时间加入 PyTorch 基金会，现在变成了这个 PyTorch 基金会下面和 PyTorch 项目平级的一个顶级的项目。那么加入 PyTorch 基金会之后呢，我们又发布了一个博客，就是解释说我们为什么要这样做。因为 PyTorch 它作为一个这个机器学习的基础性框架，然后 VLM 作为基于 PyTorch 的一个引领性的推理框架，那么二者的紧密结合能够让社区更快的前进。具体来说现在呃 VLM 的每一个 commit 都会对 PyTorch 的最新 nightly 版本进行简单的测试，就是这个 man to man 的一个测试。然后 PyTorch 的版本发布流程也会进行完整的 VLM 测试，并修复相关的这个兼容性作为 PyTorch 版本发布的一个前置条件。然后 VLM 所依赖的这个 PyTorch 的特性也会放在 PyTorch 的 CI 里面，保证 PyTorch 的代码未来不会破坏这些特性。那比如说这个呃社区最近在做 Blackwell 的适配的时候，那么因为 Blackwell 它默认需要 CUDA 十二点八以上的版本，所以是我们推动 PyTorch 把它默认发布的版本换成了十二点八，这样方便 Blackwell 的用户更好的进行适配。然后另一方面我们也和 Meta 内部的这个 PyTorch 团队在做紧密合作，把 VLM 部署到这个 PyTorch 内部的各种 production 的 use case 里面来服务大量的用户。所以整体上来说我们会把这个 PyTorch 和 VLM 的合作变得更加紧密，提升二者之间的兼容性，让大家在这个生态可用方面啊能够用得更顺手。

6
00:10:34,818 --> 00:11:56,962
那么在十月份即将举办的这个 PyTorch Conference 二零二五上面呢，我们也会有五场关于 VLLM 的报告，到时候也欢迎大家参观或呃参加或者在网上观看。那么下面我再介绍一些 VLLM 最近的一些新的特性，嗯，呃一个近期的重点啊就是这个混合模型，就是 Hybrid Model 的支持。因为随着这个模型的上下文变得越来越长，那么为了效率起见呢，大家大家都不想用这个完整的 Full Attention，都想做一些这个 Efficiency 上面的改进。那么常见的做法呢就是保留少量的这个 Full Attention，然后再混合一些像 Sliding Window 啊或者 Linear Attention 啊 Sparse Attention 这些技术。那这个时候显存管理就变得相当复杂了。啊对于这些混合模型，我们怎么去做啊 Prefill Caching 啊 Chunk Prefill 啊或者 MTP 这种 Speculative Decoding 啊这些，这里面都是存在复杂，呃相当复杂的一些技术问题的。啊我们花了这个大量的时间在这上面做一些支持。啊现在这个 Hybrid Manager，呃 Hybrid Memory Manager 它已经默认启用了。啊它对于混合架构的模型的支持非常有效，我们近期啊也会争取发出更多的技术博客来帮大家解呃解读这些特性。这个特性也是我们高效支持这个千问三 Next 就是前段时前几天刚发布的模型的一个关键。

7
00:11:56,962 --> 00:13:56,738
然后呃，KV Connector 也是一个广受好评的功能。那么它提供了一个非常灵活的接口，方便其他的组件和 VLM 内部管理的这个 KV Cache 进行交互。那么通过这个接口呢，我们可以进行不同 instance 之间的这个 KV Cache 共享啊，或者 PD 分离之间的功能啊，或者把它和 LM Cache、Dynamo 等系统进行集成，将这个 KV Cache 持久化存储到一些啊磁盘啊或者三 F S、三 F S 这种这个 RDMA 的这个呃存储中，进一步去降低推理的成本。以及我们最近在跟 PyTorch 合作做一些这个基于 Torch Compile 的一些优化的功能。啊，我们做这个目的，这初衷呢就是说，因为 VLM 支持这么多的模型、硬件和特性，所以我们和这个团队的关键就是说，我们去如何处理这个组合爆炸的问题，因为我们不能够这个单独的维护每一个 case，所以呢我们需要有一种通用的这个优化手段。啊，比如说这里以一个常见的这个 sequence parallel 为例，啊，它作为 tensor parallel 的一个进一步的优化。如果你只是只要支持一个模型的话，这个是非常简单的，你就在这个模型的文件里面改一改就行了。但是 VLM 作为一个引擎，它支持了上百个模型，包括它未来还需要支持新的模型。那么怎么在这样的一个情况下，把一个硬，啊，把一个这个功能的优化加进来呢？那么我们最后想到的办法是基于 Torch Compile 的这个编译器的优化。那么我们用 Torch Compile 抓抓出来计算图之后，再把这个优化的功能实现为一个编译的 pass。那么通过这个功能呢，我们就可以适配所有的模型，而且后续新加进来的模型也能够自动获得这个新的功能。啊，这是我们这这个例例子里面具体就是展示我们怎么用这个 Torch Compile 的一些 sequence parallel 的 pass。啊，当然这个易用性方面我们还在啊改进，就是因为这个功能变得越来越复杂嘛，所以这个命令也会变得越来越复杂，你需要去看怎么去调各种各样的参数。

8
00:13:56,738 --> 00:15:51,106
啊，基于类似的思路呢，我们用 compiler 实现了一个分层的 CUDA graph。我们保留这个 attention 部分的灵活性，同时兼容其他部分的这个效率。那在较大的模型上面，我们测下来基本上跟呃完整的 CUDA graph 的性能是相当的，然后在小模型上会慢一点。所以呢为了这一点呢，我们呃就是因为它提供了一个分层 CUDA graph 的框架，所以它其实是一个统一的框架。那么你一个 CUDA graph 也是一种分层 CUDA graph 的一个特例。所以我们现在其实已经支持了啊既支持完整的 CUDA graph，又支持这个分层的 CUDA graph。那么我们在 decode 的时候可以保跑 full CUDA graph，在 preview 的时候可以跑 piecewise CUDA graph。这样就相当于我们把尽可能把能跑 CUDA graph 的部分都跑上了。那么像这个 FA 三啊，flex attention 等等，他们支持 full CUDA graph 的这个模型呢，我们就可以跑 full CUDA graph。这个分层 CUDA graph 的影响其实不只是在这个推理框架上，我们还看到像 Megatron 这些训练框架，他们也开始采用类似的分层 CUDA graph 的这个技术路线，即使是 training 也是要上这个 CUDA graph。然后包括很多这个研究 sparse attention 的学者，他们呃通过 VLM 的插件去改 VLM 的 attention。然后因为这个是一个分层的 CUDA graph，所以他们可以在 attention 部分做他们任意的适配，比如说做一些这个 dynamic 的 sparse attention 啊，不需要考虑 CUDA graph 的兼容，而其他部分依然能够跑在 CUDA graph 里面。然后呃其他的一些优化，比如说这个近期一个一个重点，一个比较亮点的功能就是因为我们看到这个模型越变越大，但是呢他们的 KV cache 其实越变越小，像 DeepSeek 的这个 MLA 结构，它只有一个 KV head。所以传统上来说我们喜欢非常喜欢用的这个 TP 啊并行的话，它就变得非常低效，因为我们需要重复保存那个 KV cache。那么这里呢我们和阅站面的洪超同学合作，引入了一个 decode context parallel 这一优化。

9
00:15:51,106 --> 00:17:58,402
啊，就是把这个 KV Cache 交替的存在这个 TP Rank 的 GPU 里面，这样我们可以充分利用 GPU 的存储空间。那么这个一个好处就是，一个是它带来的这个提升非常明显，还有一个就是它的用户使用方式非常友好。因为我们平常喜欢用这个加一个杠 TP 就 Tensor Parallel 就起来了。那么像大 E P 啊，这个 P D 分离啊，它们的使用方式还是比较复杂的。那么这里我们这个 DeepCo 的 Context Parallel，我们只需要在杠 TP 后面再加一个杠 DCP 的参数，我们就可以立马获得这个 DeepSeek M L A 上面的这个性能收益。那你加一个杠 DCP 八的参数，就可以直接获得八倍的 KV Cache。那我们我们测试表明呢，这个可以直接带来两到三倍的这个吞吐上面的收益，尤其是特别适合像 RL 啊或者这个 Offline 的 Data Processing 这些大类，呃，这个这量这类的需要大量的这个 KV Cache 的一些场景。啊，当然在 Offline 的场景呢可能还需要进一步的优化一下，因为我们还有一些这个 T T F T 的要求。啊，另一个就是我们像跟这个 Kimi 的同学合作，啊，关于这个强化学习里面的 Weight Update，那么我们现在已经能够做到半分钟内直接更新万亿级的参数。这也非常感谢 Kimi 的这个王维骁同学和我们的合作。然后还有几个小 feature，像这个啊 Sleep Mode 也是啊很多用户非常喜欢的，就其实它出来已经大半年了，我们可能宣传的比较少啊。它可以用在一些这个 Serverless 之类的或者资源共享的场景，比如说后训练的这个 RL 它的训练和推理共用 GPU，或者说你一个 GPU 上面想起多个 Service，那么我们可以把一个推理服务的这个 GPU，让它临时把 Weight 卸载，把 KV Cache 扔掉，然后呢让它陷入睡眠模式。后续我们想要让这个模型再起来的时候，我们只需要打一个这个特殊的请求，说你这个模型该起来工作了。啊，这样子呢我们就可以避免这个非常长的这个加载的时间。啊，这项功能利用的是这个 CUDA 底层的驱动的功能，对上层的应用的这个透明性和呃也非常好，就是基本上用户不需要关心这个功能跟其他功能的兼容性问题。

10
00:17:58,402 --> 00:20:07,778
然后做这个性能优化的朋友大家都非常关心这个 GPU 能不能打满，对吧？这个呃受到 NanoFlow 的这个影响呢，我们也开启了这个两个 in-flight batch 的这个想法，我们把当前 batch 正在执行的时候去去 prepare 下一个 batch 的这个调度。然后呢这样子对于这个中小模型来说，我们可以有百分之十左右的这个性能的收益。啊当然这个 model execution 和 model 的 prepare input 我们还没有完成完全的 overlap，这一步也正在这个使用过程中。啊我们也正在优化这个功能和这个 speculative decoding 啊，structured 这个 output 这些功能的兼容性。啊争取能够在常用场景下把 GPU 的这个利用率拉到百分之百，让它不空转。然后我们也非常重视这个用户体验啊，我们提供了像 Docker、Wheel 安装等方式。然后尤其是我们注意到大部分的用户他其实并不需要修改 kernel，他其实只需要修改一些这个 Python 的代码。所以我们提供了像这个预编译的安装方式，我们可以加一个环境变量，WLM_USE_PRECOMPILED 等于一。然后呢大家安装的时候就会从我们编译好的这个 Wheel 里面直接把这个啊编译好的这个 so 文件拿过来，然后大家只需要安装这个 Python 代码就可以了。啊当然我我们也知道就是有些用户还不知道这个功能，所以我们我们也正在看就是呃怎么在更广泛的场景把这个 precompiled 功能用起来，让大家能够呃安装 WLM 的时候更加的方便。然后我们构建的每一个 Wheel 都是在这个 wheels 点 WLM 点 AI 这个网站下面。然后一般来说就是新模型发布的时候，比如说这个 Kimi K 二发布的时候，它第一时间会给 WLM 提一个 PR，然后 WLM merge 了这个 PR 之后呢，大概半个小时左右，这个 Wheel 就会上传到这个我们的网站上。然后大家就可以通过这个网站的这个用用这个 precompiled 的方式，这种方式马上就能够在发布之后的半个小时到一个小时，就能够用到最新的版本，就能够支持上这个模型。啊这样子呢我们这个模型的发布和我们正常模型正常 WLM 的版本的发布就可以啊做一个 decouple，我们可啊我们可以在这个 WLM 这个版本发布就可以变得更从容一些。

11
00:20:07,778 --> 00:22:16,418
然后呃，作为这个大模型推理的一个基础引擎啊，我们一个很重要的责任也就是在维护 VLLM 的这个功能与性能。那么我们不仅是在做优化，我们也需要保证之前的那些优化不会啊出现问题。为此呢，我们提供了大量的测试，啊我们每一个 commit 都会经过这个巨量的测试，我们也和 PyTorch 团队合作，呃更多的利用 PyTorch 的一些性能监控的一些基础设施和他们的这个社区的一些工具，啊呃来跟踪这个主流模型的性能。然后一旦性能出问题的时候，我们可以快速定位到是过去的哪一个 commit 出现了这个问题。啊这个是 PyTorch 团队给我们提供的一个啊非常基础性的资源的呃投入的工作。呃这背后呢我们每个月，呃这这应该也是比较老的数据了，我们在几个月之前就已经每个月要花费这个五万美元左右在纯粹的 CI 的机器上，这还不包括各种的这个人力的这个开销。啊当然这方面我们啊要大力感谢我们的这个赞助商哈，包括国内外的各大云厂商啊，这个科研机构啊，给我们提供了非常多的计算资源的支持。啊我们也非常感谢我们的这个社区贡献者，我们现在有超过一千五百名的贡献者，就是提交过代码的，其中包括四十多名的 committer，啊这些 committer 主要来自像加州大学伯克利分校、清华大学、香港科技大学这个等等这些研究机构，啊包括像英伟达呀、AMD 啊、Google、华为、Intel 这些硬件厂商，或者像这个 Red Hat 啊、Meta 啊、Hugging Face、AnyScale 这些 VLLM 的这个大规模的用户，包括这个千问啊、Mistral 这些模型厂商，以及一些纯粹的热爱开源的一些技术贡献者。啊没有他们的付出呢就没有 VLLM 项目的今天。啊我们也非常感谢这个我们欣欣向荣的社区，我们仅仅在上个月就是八月份，在国内举办了北京、上海、深圳三场 meet up，场场都是人数饱满。啊所以 GoCin 今年那个官方问我要不要再办一场这个 VLLM 的 workshop 的时候，我就就婉拒了，就是让大家呃先消化一下八月份的这个 meet up 的内容啊，然后再我们后面再看这个后面十十月份要不要继续开始办。

12
00:22:16,418 --> 00:23:43,106
啊，VLLM的社区，我觉得啊，它不仅是这个开发和优化VLLM，它其实也是这个和大模型推理相关的诸多的技术讨论的发源地。所以我们可以看到前几天这个Hugging Face他们发了一个就是怎么在在VLLM的基础上怎么去研究在大模型推理里面保持绝对的输出稳定性。然后像这个NVIDIA跟我们一起研究就是在VLLM里呃以VLLM为样例，如何去调试像illegal memory access这种非常令人头疼的这个基础问题。啊包括这个Google工程师啊呕心沥血写了一篇非常非常长的非常详细的这个呃VLLM internal的一些技术细节的介绍。啊这些我觉得都是社区让我们非常感动的一个努力。那么VLLM的我们的目标一直没变，就是我们想要构建一个又快又好用的这个大模型推理的引擎。那我觉得这不只是不是我们几个人或者几十个人能够完成的一个目标。我觉得我们最重要的是构建这个大模型推理技术的一个社区，从而能够汇聚这个关心和支持这使用这些技术的一些公司和个体，这样大家一起来共建这个生态，共同推进VLLM的一个进步。啊以以上就是这个VLLM的简单的介绍和进展的更新。那么因为由于时间有限，我们很多细节都是呃一笔带过的，大家可以去看这个文档啊，包括文档里面有这个ask AI机器人，可以跟他去交流更多的技术细节。

13
00:23:43,106 --> 00:24:27,755
然后我们的开发平台主要是 GitHub，然后我们的沟通呢通过这个 Slack，我们现在也开通了这个啊微信群啊，然后什么的。然后这个宣传平台呢主要是通过像 Twitter 啊、知乎啊、小红书啊、微信公众号等等社交媒体。啊，我们就最近有一个这个 VLM 小助手，就是大家可以搜他加他的微信，然后加入一些这个 VLM 的一些技术讨论群。啊，我们也在更多的看怎么去方便大家进行更广泛的技术交流，因为啊国外的同学适合呃适应 Slack，但是我看国内的这个我们开发更还是喜欢用呃微信来进行交流，所以我们也在尽可能看啊尽可能的在看怎么呃给大家构建更通畅的交通的这个交流的渠道吧。好，我就讲到这里，谢谢大家。


[Transcript]
啊，我是来自这个 VLM 团队的尤凯超。啊，我今天简单跟大家分享一下 VLM 项目的一些整体介绍和最新进展。嗯，其实这是我第二次参加 GopherCon 大会啊，就是去年啊大概十月份的时候也是在北京，呃，我们在 GopherCon 上面展示了这个 VLM 相关的一些内容。那么今年呢也是借这个机会再跟大家呃更新一下这个 VLM 一年来的一些发展。啊，在座的朋友可能也有些这个对 VLM 不熟悉的，所以我们先简单介绍一些相关的背景知识。呃，由于当前这个大模型计算它整体还是一个 auto-regressive 的自回归的结构，所以啊这里面的一个关键问题就是自回归过程中的这个中间状态的管理，也就是 KV Cache，这个是啊大模型高效推理的一个关键。那 VLM 项目呢它起源于这个二零二三年发表的 Page Attention 的这篇论文，来自于加州大学伯克利分校的学生，他们提出了这个高效的组织 KV Cache 的方法，也就是啊大家现在所说的 Page Attention，能够提高显存的利用率，加速大模型的推理过程。然后 Page Attention 结合 Continuous Batching，其实也就是 VLM 项目的一个雏形。那么自这个二零二三年六月份开源以来呢，VLM 项目也很幸运的受到了社区的巨大的关注。两年多以来呢，我们现在已经收获了超过五万七千多的 GitHub 的 Star。然后我大概是在二零二四年的三月份左右加入 VLM 项目的，呃，那个时候呢其实可能只有一万多 GitHub Star。然后一年多以来我们也是共同见证了这个项目的成长，而且大家看到这个 Star 的速度，这个增长的速度其实还越来越快。啊，呃，我昨天在这个上海的外滩参加一个外滩大会，然后蚂蚁发布了一个这个开源报告，反正在 GopherCon 也发布了，这这里面其实也提到很多次 VLM，那么在整体的这个开源社区里面啊排名第二，也仅次于 PyTorch。
那由于 vllm 发展的比较早啊，所以这个社区的支持也是相当广泛的。那么 vllm 基本上可以支持大家大模型研发的这个整个的生命流程，包括像 worl啊，unsloth啊，lama factory啊这些后训练啊，微调啊，量化的框架。啊，以及像 langchain 啊，defy 啊这些应用的框架，都是有 vllm 的支持的。然后不管是像 nvidia、amd 这些芯片厂商，或者说 google cloud、aws、阿里云这些云厂商，或者说 deepseek 啊，moonshot 啊，千问啊这些大模型的开发商，啊都是有在用 vllm 的。那么 vllm 的整体目标我们就是希望构建一个又快又好用的大模型的推理引擎。那么它的使用方式包括这个 offline 的 lm layer，包括像 worl 之类的这些强化学习，他们一开始就是通过这个 offline inference 接入进来的。然后还包括这个啊，这部分 api 现在其实基本上是一个社区的标准。然后呢 vllm 也可以作为一个完整的这个 openai 兼容的一个 api 的服务器。然后大家也可以通过各种像中间的这个转换键接入 cloud code 啊，gemini cli 里面。或者说也可以作为其他这个推理引擎管理器的后端，像 nvidia 有这个 triton inference server，那么它通过 async lm engine 接入的方，呃，接入的方式来启动 vllm，然后它自己负责这个请求的一些管理。那么 vllm 支持非常广泛的模型，这里面基本包括了所有的主流的文本生成的模型，也包括这个输入模态是一些语音啊，文本啊，图像啊或者视频的一些多模态的图形。那么在过去这个一两个月呢，国内的大模型厂商也都非常给力啊，发布了非常多的开源模型，包括像呃 step three 啊，kimi k two 啊，千问三啊或者三 next，包括 glm 四点五，文心一言四点五，腾讯混元，书生 s 一等等等等模型，这些模型都是有 vllm 的这个官方支持的。
然后对于一些其实没有 VLM 直接支持的模型，我们也和 Hugging Face Transformers 有合作，设计了一个这个 Transformers 后端，就是你可以在 VLM 里面直接运行一个 Transformer 支持的模型。啊目前这个支持一些比较简单的，像文本生成模型，呃就是文本输入和视觉输入的一些模型。然后对于模型开发者来说，我们也提供了一个模型注册的方案，就是你可以把 VLM 之外的模块导入到 VLM 之内，让它能够更方便的使用，而不需要去修改 VLM 的代码。啊我们时常惊叹于社区的创造力哈，最近 VLM 还支持了一个 I/O processor 的一个插件，它的意思是你可以在 VLM 里面这个定制输入和输出是如何处理的。然后呢你就可以用这个方式让 VLM 去运行那个模型，然后你来管理这个输入输出的处理，从而可以处理一些这个图片、视频，甚至说雷达的数据。这里要感谢 IBM Research Team 的贡献，比如说这里是一个拿 VLM 去做一个类似 segmentation 的任务，就是去识别这个城市里的洪水的区域。啊我们可以从这个大概三个角度来总结 VLM 支持的模型。那么从模型的这个架构层面来看呢，包括标准的 Transformer、MOE 模型啊，像 State Space 模型啊、Linear Attention 模型之类的。然后从支持的模态来说呢，包括文本啊、语音啊、图片啊、视频啊、混合的。然后支持的任务来看，我们不仅包括自回归生成任务，还包括一些计算 embedding 啊、reward 啊、rerank 等等这些一次性生成的任务，我们把它统称为 pooling 的任务。呃 VLM 支持这么多模型，然后用户也经常在问说，啊我就用 VLM 怎么运行某个模型呢？那么为了回答这个问题呢，我们现在其实开启了一个子项目叫做 recipes，就是用于记录我们常见的模型的一些运行的命令，方便用户快速开始。这个网站就是大家直接点击那，呃这个输入 recipes 点 VLM 点 AI，就可以访问到就是常用的这个模型，我们怎么用 VLM 去运行。
然后呃，VMM还不不仅支持很多模型啊，我们也支持非常多的硬件。那当然大家用的最多的是 Nvidia 的 GPU，那我们还支持像 AMD 啊、Intel 它们的 GPU，啊包括 Google 的这个 TPU，啊这个叉八六和 Arm 的 CPU 等等。啊我们也感谢像华为公司的呃等公司的努力，我们也实现了一个硬件的这个插件机制。那么通过插件机制来支持像 AWS Neuron 啊、升腾啊、Intel Gaudi 啊、IBM Sparrow 等等这些芯片。那么未来我们觉得这也是一个大方向，就是我们希望进一步减少 VMM 项目本身里面的这个硬件相关的代码，更多的通过硬件的这个通过插件的形式把硬件接入进来，这样子能够简化 VMM 的代码。那么现在有了这个插件机制之后，其实增加一个硬件的插件已经不需要 VMM 的参与了，厂家自己其实就可以做到。像国内的一些啊沐曦啊等等，他们就是有他们自己的插件，可以直接接入到这个主流的 VMM 里面。那么以升腾为例呢，就是用户呃需要安装 VMM 和 VMM Ascend 的这两个包。那么大家可以把这个看作是一份这个，呃就把 VMM 看作是一份接口，然后它包含了在 Nvidia GPU 上的一个标准的参考实现。那么 VMM Ascend 呢就是这份接口的零点七点一版本在升腾上面的一个实现。啊所以大家安装一份接口，然后再安装一份实现，就可以把 VMM 在各种硬件上跑起来。所以说 VMM 的责任呢就是和这个各大硬件厂商一起说我们怎么去协调沟通这个接口，然后制定出一个合适的方案，方便大家都能在各自的硬件上做一个非常通用的优化。
啊，得益于这个 VLM 的多样化的硬件支持呢，我们也可以在很多像啊 Google Cloud 啊，NVIDIA 的 GTC 大会上面，很多地方都可以见到 VLM 的身影。然后包括像这个 AMD 的发布会啊，Kubernetes 社区啊，这些也都是 VLM 的这个紧密的合作伙伴。当然这一切呃的支持啊，也离不开像这个 PyTorch 的支持，因为这些硬件它们一般都是首先支持 PyTorch，然后在这基础上呢再增加一些这个算子啊，模块啊，然后再接入 VLM。所以也感谢这个 PyTorch 在生态系统里面提供的这个非常关键的受邀结构的这么一个地位，使得 VLM 基于 PyTorch 就可以兼容这些硬件。啊，也正是因为我们和 PyTorch 项目的这个紧密合作的关系，所以我们在去年十二月份的时候加入了这个 PyTorch 生态系统，成为了一个 PyTorch 的生态项目。然后呢再进一步的我们啊今年当 PyTorch 基金会扩展成一个伞形基金会的时候，VLM 也是第一时间加入 PyTorch 基金会，现在变成了这个 PyTorch 基金会下面和 PyTorch 项目平级的一个顶级的项目。那么加入 PyTorch 基金会之后呢，我们又发布了一个博客，就是解释说我们为什么要这样做。因为 PyTorch 它作为一个这个机器学习的基础性框架，然后 VLM 作为基于 PyTorch 的一个引领性的推理框架，那么二者的紧密结合能够让社区更快的前进。具体来说现在呃 VLM 的每一个 commit 都会对 PyTorch 的最新 nightly 版本进行简单的测试，就是这个 man to man 的一个测试。然后 PyTorch 的版本发布流程也会进行完整的 VLM 测试，并修复相关的这个兼容性作为 PyTorch 版本发布的一个前置条件。然后 VLM 所依赖的这个 PyTorch 的特性也会放在 PyTorch 的 CI 里面，保证 PyTorch 的代码未来不会破坏这些特性。那比如说这个呃社区最近在做 Blackwell 的适配的时候，那么因为 Blackwell 它默认需要 CUDA 十二点八以上的版本，所以是我们推动 PyTorch 把它默认发布的版本换成了十二点八，这样方便 Blackwell 的用户更好的进行适配。然后另一方面我们也和 Meta 内部的这个 PyTorch 团队在做紧密合作，把 VLM 部署到这个 PyTorch 内部的各种 production 的 use case 里面来服务大量的用户。所以整体上来说我们会把这个 PyTorch 和 VLM 的合作变得更加紧密，提升二者之间的兼容性，让大家在这个生态可用方面啊能够用得更顺手。
那么在十月份即将举办的这个 PyTorch Conference 二零二五上面呢，我们也会有五场关于 VLLM 的报告，到时候也欢迎大家参观或呃参加或者在网上观看。那么下面我再介绍一些 VLLM 最近的一些新的特性，嗯，呃一个近期的重点啊就是这个混合模型，就是 Hybrid Model 的支持。因为随着这个模型的上下文变得越来越长，那么为了效率起见呢，大家大家都不想用这个完整的 Full Attention，都想做一些这个 Efficiency 上面的改进。那么常见的做法呢就是保留少量的这个 Full Attention，然后再混合一些像 Sliding Window 啊或者 Linear Attention 啊 Sparse Attention 这些技术。那这个时候显存管理就变得相当复杂了。啊对于这些混合模型，我们怎么去做啊 Prefill Caching 啊 Chunk Prefill 啊或者 MTP 这种 Speculative Decoding 啊这些，这里面都是存在复杂，呃相当复杂的一些技术问题的。啊我们花了这个大量的时间在这上面做一些支持。啊现在这个 Hybrid Manager，呃 Hybrid Memory Manager 它已经默认启用了。啊它对于混合架构的模型的支持非常有效，我们近期啊也会争取发出更多的技术博客来帮大家解呃解读这些特性。这个特性也是我们高效支持这个千问三 Next 就是前段时前几天刚发布的模型的一个关键。
然后呃，KV Connector 也是一个广受好评的功能。那么它提供了一个非常灵活的接口，方便其他的组件和 VLM 内部管理的这个 KV Cache 进行交互。那么通过这个接口呢，我们可以进行不同 instance 之间的这个 KV Cache 共享啊，或者 PD 分离之间的功能啊，或者把它和 LM Cache、Dynamo 等系统进行集成，将这个 KV Cache 持久化存储到一些啊磁盘啊或者三 F S、三 F S 这种这个 RDMA 的这个呃存储中，进一步去降低推理的成本。以及我们最近在跟 PyTorch 合作做一些这个基于 Torch Compile 的一些优化的功能。啊，我们做这个目的，这初衷呢就是说，因为 VLM 支持这么多的模型、硬件和特性，所以我们和这个团队的关键就是说，我们去如何处理这个组合爆炸的问题，因为我们不能够这个单独的维护每一个 case，所以呢我们需要有一种通用的这个优化手段。啊，比如说这里以一个常见的这个 sequence parallel 为例，啊，它作为 tensor parallel 的一个进一步的优化。如果你只是只要支持一个模型的话，这个是非常简单的，你就在这个模型的文件里面改一改就行了。但是 VLM 作为一个引擎，它支持了上百个模型，包括它未来还需要支持新的模型。那么怎么在这样的一个情况下，把一个硬，啊，把一个这个功能的优化加进来呢？那么我们最后想到的办法是基于 Torch Compile 的这个编译器的优化。那么我们用 Torch Compile 抓抓出来计算图之后，再把这个优化的功能实现为一个编译的 pass。那么通过这个功能呢，我们就可以适配所有的模型，而且后续新加进来的模型也能够自动获得这个新的功能。啊，这是我们这这个例例子里面具体就是展示我们怎么用这个 Torch Compile 的一些 sequence parallel 的 pass。啊，当然这个易用性方面我们还在啊改进，就是因为这个功能变得越来越复杂嘛，所以这个命令也会变得越来越复杂，你需要去看怎么去调各种各样的参数。
啊，基于类似的思路呢，我们用 compiler 实现了一个分层的 CUDA graph。我们保留这个 attention 部分的灵活性，同时兼容其他部分的这个效率。那在较大的模型上面，我们测下来基本上跟呃完整的 CUDA graph 的性能是相当的，然后在小模型上会慢一点。所以呢为了这一点呢，我们呃就是因为它提供了一个分层 CUDA graph 的框架，所以它其实是一个统一的框架。那么你一个 CUDA graph 也是一种分层 CUDA graph 的一个特例。所以我们现在其实已经支持了啊既支持完整的 CUDA graph，又支持这个分层的 CUDA graph。那么我们在 decode 的时候可以保跑 full CUDA graph，在 preview 的时候可以跑 piecewise CUDA graph。这样就相当于我们把尽可能把能跑 CUDA graph 的部分都跑上了。那么像这个 FA 三啊，flex attention 等等，他们支持 full CUDA graph 的这个模型呢，我们就可以跑 full CUDA graph。这个分层 CUDA graph 的影响其实不只是在这个推理框架上，我们还看到像 Megatron 这些训练框架，他们也开始采用类似的分层 CUDA graph 的这个技术路线，即使是 training 也是要上这个 CUDA graph。然后包括很多这个研究 sparse attention 的学者，他们呃通过 VLM 的插件去改 VLM 的 attention。然后因为这个是一个分层的 CUDA graph，所以他们可以在 attention 部分做他们任意的适配，比如说做一些这个 dynamic 的 sparse attention 啊，不需要考虑 CUDA graph 的兼容，而其他部分依然能够跑在 CUDA graph 里面。然后呃其他的一些优化，比如说这个近期一个一个重点，一个比较亮点的功能就是因为我们看到这个模型越变越大，但是呢他们的 KV cache 其实越变越小，像 DeepSeek 的这个 MLA 结构，它只有一个 KV head。所以传统上来说我们喜欢非常喜欢用的这个 TP 啊并行的话，它就变得非常低效，因为我们需要重复保存那个 KV cache。那么这里呢我们和阅站面的洪超同学合作，引入了一个 decode context parallel 这一优化。
啊，就是把这个 KV Cache 交替的存在这个 TP Rank 的 GPU 里面，这样我们可以充分利用 GPU 的存储空间。那么这个一个好处就是，一个是它带来的这个提升非常明显，还有一个就是它的用户使用方式非常友好。因为我们平常喜欢用这个加一个杠 TP 就 Tensor Parallel 就起来了。那么像大 E P 啊，这个 P D 分离啊，它们的使用方式还是比较复杂的。那么这里我们这个 DeepCo 的 Context Parallel，我们只需要在杠 TP 后面再加一个杠 DCP 的参数，我们就可以立马获得这个 DeepSeek M L A 上面的这个性能收益。那你加一个杠 DCP 八的参数，就可以直接获得八倍的 KV Cache。那我们我们测试表明呢，这个可以直接带来两到三倍的这个吞吐上面的收益，尤其是特别适合像 RL 啊或者这个 Offline 的 Data Processing 这些大类，呃，这个这量这类的需要大量的这个 KV Cache 的一些场景。啊，当然在 Offline 的场景呢可能还需要进一步的优化一下，因为我们还有一些这个 T T F T 的要求。啊，另一个就是我们像跟这个 Kimi 的同学合作，啊，关于这个强化学习里面的 Weight Update，那么我们现在已经能够做到半分钟内直接更新万亿级的参数。这也非常感谢 Kimi 的这个王维骁同学和我们的合作。然后还有几个小 feature，像这个啊 Sleep Mode 也是啊很多用户非常喜欢的，就其实它出来已经大半年了，我们可能宣传的比较少啊。它可以用在一些这个 Serverless 之类的或者资源共享的场景，比如说后训练的这个 RL 它的训练和推理共用 GPU，或者说你一个 GPU 上面想起多个 Service，那么我们可以把一个推理服务的这个 GPU，让它临时把 Weight 卸载，把 KV Cache 扔掉，然后呢让它陷入睡眠模式。后续我们想要让这个模型再起来的时候，我们只需要打一个这个特殊的请求，说你这个模型该起来工作了。啊，这样子呢我们就可以避免这个非常长的这个加载的时间。啊，这项功能利用的是这个 CUDA 底层的驱动的功能，对上层的应用的这个透明性和呃也非常好，就是基本上用户不需要关心这个功能跟其他功能的兼容性问题。
然后做这个性能优化的朋友大家都非常关心这个 GPU 能不能打满，对吧？这个呃受到 NanoFlow 的这个影响呢，我们也开启了这个两个 in-flight batch 的这个想法，我们把当前 batch 正在执行的时候去去 prepare 下一个 batch 的这个调度。然后呢这样子对于这个中小模型来说，我们可以有百分之十左右的这个性能的收益。啊当然这个 model execution 和 model 的 prepare input 我们还没有完成完全的 overlap，这一步也正在这个使用过程中。啊我们也正在优化这个功能和这个 speculative decoding 啊，structured 这个 output 这些功能的兼容性。啊争取能够在常用场景下把 GPU 的这个利用率拉到百分之百，让它不空转。然后我们也非常重视这个用户体验啊，我们提供了像 Docker、Wheel 安装等方式。然后尤其是我们注意到大部分的用户他其实并不需要修改 kernel，他其实只需要修改一些这个 Python 的代码。所以我们提供了像这个预编译的安装方式，我们可以加一个环境变量，WLM_USE_PRECOMPILED 等于一。然后呢大家安装的时候就会从我们编译好的这个 Wheel 里面直接把这个啊编译好的这个 so 文件拿过来，然后大家只需要安装这个 Python 代码就可以了。啊当然我我们也知道就是有些用户还不知道这个功能，所以我们我们也正在看就是呃怎么在更广泛的场景把这个 precompiled 功能用起来，让大家能够呃安装 WLM 的时候更加的方便。然后我们构建的每一个 Wheel 都是在这个 wheels 点 WLM 点 AI 这个网站下面。然后一般来说就是新模型发布的时候，比如说这个 Kimi K 二发布的时候，它第一时间会给 WLM 提一个 PR，然后 WLM merge 了这个 PR 之后呢，大概半个小时左右，这个 Wheel 就会上传到这个我们的网站上。然后大家就可以通过这个网站的这个用用这个 precompiled 的方式，这种方式马上就能够在发布之后的半个小时到一个小时，就能够用到最新的版本，就能够支持上这个模型。啊这样子呢我们这个模型的发布和我们正常模型正常 WLM 的版本的发布就可以啊做一个 decouple，我们可啊我们可以在这个 WLM 这个版本发布就可以变得更从容一些。
然后呃，作为这个大模型推理的一个基础引擎啊，我们一个很重要的责任也就是在维护 VLLM 的这个功能与性能。那么我们不仅是在做优化，我们也需要保证之前的那些优化不会啊出现问题。为此呢，我们提供了大量的测试，啊我们每一个 commit 都会经过这个巨量的测试，我们也和 PyTorch 团队合作，呃更多的利用 PyTorch 的一些性能监控的一些基础设施和他们的这个社区的一些工具，啊呃来跟踪这个主流模型的性能。然后一旦性能出问题的时候，我们可以快速定位到是过去的哪一个 commit 出现了这个问题。啊这个是 PyTorch 团队给我们提供的一个啊非常基础性的资源的呃投入的工作。呃这背后呢我们每个月，呃这这应该也是比较老的数据了，我们在几个月之前就已经每个月要花费这个五万美元左右在纯粹的 CI 的机器上，这还不包括各种的这个人力的这个开销。啊当然这方面我们啊要大力感谢我们的这个赞助商哈，包括国内外的各大云厂商啊，这个科研机构啊，给我们提供了非常多的计算资源的支持。啊我们也非常感谢我们的这个社区贡献者，我们现在有超过一千五百名的贡献者，就是提交过代码的，其中包括四十多名的 committer，啊这些 committer 主要来自像加州大学伯克利分校、清华大学、香港科技大学这个等等这些研究机构，啊包括像英伟达呀、AMD 啊、Google、华为、Intel 这些硬件厂商，或者像这个 Red Hat 啊、Meta 啊、Hugging Face、AnyScale 这些 VLLM 的这个大规模的用户，包括这个千问啊、Mistral 这些模型厂商，以及一些纯粹的热爱开源的一些技术贡献者。啊没有他们的付出呢就没有 VLLM 项目的今天。啊我们也非常感谢这个我们欣欣向荣的社区，我们仅仅在上个月就是八月份，在国内举办了北京、上海、深圳三场 meet up，场场都是人数饱满。啊所以 GoCin 今年那个官方问我要不要再办一场这个 VLLM 的 workshop 的时候，我就就婉拒了，就是让大家呃先消化一下八月份的这个 meet up 的内容啊，然后再我们后面再看这个后面十十月份要不要继续开始办。
啊，VLLM的社区，我觉得啊，它不仅是这个开发和优化VLLM，它其实也是这个和大模型推理相关的诸多的技术讨论的发源地。所以我们可以看到前几天这个Hugging Face他们发了一个就是怎么在在VLLM的基础上怎么去研究在大模型推理里面保持绝对的输出稳定性。然后像这个NVIDIA跟我们一起研究就是在VLLM里呃以VLLM为样例，如何去调试像illegal memory access这种非常令人头疼的这个基础问题。啊包括这个Google工程师啊呕心沥血写了一篇非常非常长的非常详细的这个呃VLLM internal的一些技术细节的介绍。啊这些我觉得都是社区让我们非常感动的一个努力。那么VLLM的我们的目标一直没变，就是我们想要构建一个又快又好用的这个大模型推理的引擎。那我觉得这不只是不是我们几个人或者几十个人能够完成的一个目标。我觉得我们最重要的是构建这个大模型推理技术的一个社区，从而能够汇聚这个关心和支持这使用这些技术的一些公司和个体，这样大家一起来共建这个生态，共同推进VLLM的一个进步。啊以以上就是这个VLLM的简单的介绍和进展的更新。那么因为由于时间有限，我们很多细节都是呃一笔带过的，大家可以去看这个文档啊，包括文档里面有这个ask AI机器人，可以跟他去交流更多的技术细节。
然后我们的开发平台主要是 GitHub，然后我们的沟通呢通过这个 Slack，我们现在也开通了这个啊微信群啊，然后什么的。然后这个宣传平台呢主要是通过像 Twitter 啊、知乎啊、小红书啊、微信公众号等等社交媒体。啊，我们就最近有一个这个 VLM 小助手，就是大家可以搜他加他的微信，然后加入一些这个 VLM 的一些技术讨论群。啊，我们也在更多的看怎么去方便大家进行更广泛的技术交流，因为啊国外的同学适合呃适应 Slack，但是我看国内的这个我们开发更还是喜欢用呃微信来进行交流，所以我们也在尽可能看啊尽可能的在看怎么呃给大家构建更通畅的交通的这个交流的渠道吧。好，我就讲到这里，谢谢大家。