[RFC]: 使用torch.compile的vLLM中的图形优化系统

r7s23pms  于 2个月前  发布在  其他
关注(0)|答案(3)|浏览(37)

动机。
从高层次来看,我们在Neural Magic正在为Torch Dynamo编写一个自定义编译器,以在vLLM中定义一个系统,我们可以在其中编写图变换。主要目标是在高级模型定义和某些性能关键的低级决策之间实现关注分离。这对于对模型定义具有特别侵入性的优化尤为重要,这些优化会破坏抽象、跨越层之间的边界,或者不是普遍有效或有用的。如果将这些优化作为模型定义的一部分进行,那么添加新模型就会变得困难得多。
我们正在为此系统的初始一组优化工作,详细说明在Proposed Passes部分中。

  • 将量化操作融合到LayerNorm内核上(适用于fp8和int8,以及静态和动态量化)
  • 融合包含GEMM、SiLU、Mul和量化操作的MLP部分
  • 将Gemm + AllReduce + Layer Norm + Gemm重写为Fused Gemm-ReduceScatter + LayerNorm + Fused AllGather Gemm,以利用ByteDance的Flux内核

尽管这个系统在Torch Dynamo内部作为自定义编译器运行,但最好将其视为vLLM中的优化系统,而不是编译器。我们没有采用垂直编译堆栈的方式,通过IR的一系列层降低高级Tensor操作,而是采取了简单实用的方法,即改善vLLM的自定义内核生态系统,而不是取代它。
向前看,根据我们在Neural Magic的经验,以及DeepSparse中取得的成功,我们对如何将图优化融入vLLM以及它应该如何与PyTorch团队的torch.compile计划相结合有了看法。简而言之,我们认为:

  • 图优化/编译系统可以成为vLLM开发者的动力倍增器。
  • torch.compile不太可能足以替换线性层的自定义内核。
  • vLLM不应该将torch.compile视为黑盒子。
  • 我们应该构建一个vLLM开发者可以控制且与Torch Inductor良好交互的系统。
  • 这个图优化系统应该保持轻量级——vLLM不应该试图成为图编译器。
bxgwgixi

bxgwgixi1#

听起来很激动人心!从我的Angular 来看,Torch.compile团队肯定会非常有兴趣更好地支持Inductor中的自定义传递。这一直是我们最近特别感兴趣的一件事,我怀疑在不花费太多精力的情况下(应该可以做到),可以让你们的生活变得更轻松:)

yfwxisqw

yfwxisqw2#

听起来很令人兴奋!从我的Angular 来看,Torch编译团队,我认为我们肯定会非常有兴趣更好地支持Inductor中的自定义传递。这是我们最近特别感兴趣的一件事,我怀疑在不花费太多精力的情况下,应该可以让你们的生活变得更轻松:)

很高兴听到这个消息。最终我们希望这能尽可能地与Inductor集成。我们会尽力争取得到帮助,更好的支持自定义传递将是非常了不起的。

cwxwcias

cwxwcias3#

你好,这是否意味着我们不会在模型定义中注意到fused_add_rms_norm(只需写rms_norm和残差),而图优化机制会识别它并调用融合内核(但不会直接编译成汇编代码)?

相关问题