<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/">
  <channel>
    <title>ML Compilers on KKKZOZ&#39;s Blog</title>
    <link>http://blog.kkkzoz.top/tags/ml-compilers/</link>
    <description>Recent content in ML Compilers on KKKZOZ&#39;s Blog</description>
    <image>
      <title>KKKZOZ&#39;s Blog</title>
      <url>http://blog.kkkzoz.top/images/papermod-cover.png</url>
      <link>http://blog.kkkzoz.top/images/papermod-cover.png</link>
    </image>
    <generator>Hugo -- 0.147.0</generator>
    <language>en</language>
    <lastBuildDate>Tue, 11 Aug 2026 14:08:18 +0800</lastBuildDate>
    <atom:link href="http://blog.kkkzoz.top/tags/ml-compilers/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>vllm &amp; torch.compile</title>
      <link>http://blog.kkkzoz.top/posts/learning/ml-compilers/vllm--torch.compile/</link>
      <pubDate>Tue, 11 Aug 2026 00:00:00 +0000</pubDate>
      <guid>http://blog.kkkzoz.top/posts/learning/ml-compilers/vllm--torch.compile/</guid>
      <description>&lt;p&gt;vLLM 中同时存在多条与 FX 和 &lt;code&gt;torch.compile&lt;/code&gt; 相关的执行路径，它们虽然共享 PyTorch 的 graph infrastructure，但解决的问题并不相同。理解这些路径的边界，是区分“模型结构改写”“Inductor 编译优化”和“CUDA Graph replay”的前提。&lt;/p&gt;
&lt;p&gt;进入正文前，可以先区分三类用法：&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;&lt;strong&gt;HF Transformers modeling backend&lt;/strong&gt;：直接使用 &lt;code&gt;fx.Tracer&lt;/code&gt; 分析 Hugging Face &lt;code&gt;forward&lt;/code&gt;，识别可融合结构并通过 AST 改写模型源码&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;vLLM 自定义 &lt;code&gt;torch.compile&lt;/code&gt; 主路径&lt;/strong&gt;：由 Dynamo 产生完整 FX &lt;code&gt;GraphModule&lt;/code&gt;，再由 vLLM 控制 graph partition、shape specialization、custom passes、cache 和 CUDA Graph integration&lt;/li&gt;
&lt;li&gt;&lt;strong&gt;普通 &lt;code&gt;@torch.compile&lt;/code&gt; 小函数&lt;/strong&gt;：FX 主要作为 Dynamo、AOTAutograd 和 Inductor 的内部 IR，vLLM 通常不直接处理这些 graph&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;Piecewise CUDA Graph 不是第四条独立的 tracing 路径，而是建立在 vLLM Piecewise Compilation 之上的运行时优化：编译阶段先拆分并编译 graph regions，随后只对兼容区域执行 CUDA Graph capture/replay。&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;这篇文章的核心问题是：vLLM 如何围绕标准 &lt;code&gt;torch.compile&lt;/code&gt; 增加一层 LLM-serving-aware 的 graph processing、compilation policy 和 runtime integration。&lt;/p&gt;</description>
    </item>
    <item>
      <title>Piecewise CUDA Graph</title>
      <link>http://blog.kkkzoz.top/posts/learning/ml-compilers/piecewise-cuda-graph/</link>
      <pubDate>Mon, 10 Aug 2026 00:00:00 +0000</pubDate>
      <guid>http://blog.kkkzoz.top/posts/learning/ml-compilers/piecewise-cuda-graph/</guid>
      <description>&lt;h2 id=&#34;核心结论&#34;&gt;核心结论&lt;/h2&gt;
&lt;p&gt;Piecewise CUDA Graph 的核心思想是：不要求整个 Transformer &lt;code&gt;forward&lt;/code&gt; 都满足 CUDA Graph capture 条件，而是将 CUDA Graph 不兼容的算子作为边界，只 capture 其余 CUDA-Graph-safe 区域。&lt;/p&gt;
&lt;p&gt;在 vLLM 中，最典型的边界是 Attention。因此，&lt;code&gt;PIECEWISE&lt;/code&gt; 模式并不是“把一个 CUDA Graph 切开执行”，而是将模型划分为多个独立的 CUDA Graph，并在它们之间以 eager 模式执行 CUDA-Graph-unsafe 操作：&lt;/p&gt;
&lt;div class=&#34;highlight&#34;&gt;&lt;pre tabindex=&#34;0&#34; class=&#34;chroma&#34;&gt;&lt;code class=&#34;language-text&#34; data-lang=&#34;text&#34;&gt;&lt;span class=&#34;line&#34;&gt;&lt;span class=&#34;cl&#34;&gt;CUDA Graph -&amp;gt; Attention (eager) -&amp;gt; CUDA Graph -&amp;gt; Attention (eager) -&amp;gt; CUDA Graph
&lt;/span&gt;&lt;/span&gt;&lt;/code&gt;&lt;/pre&gt;&lt;/div&gt;&lt;p&gt;CUDA Graph 会提前 capture 一组 GPU operations，后续通过 graph replay 一次性提交，从而降低 CPU 逐个启动 kernel 的开销。Transformer 中的 RMSNorm、Linear/GEMM、activation、FFN 和 residual 等计算，在 capture size 确定时通常具有稳定的执行结构；Attention 则需要处理 KV Cache、动态 shape 和运行时 metadata，对 CUDA Graph 的兼容要求更高。&lt;/p&gt;</description>
    </item>
    <item>
      <title>ML Compilers Overview</title>
      <link>http://blog.kkkzoz.top/posts/learning/ml-compilers/ml-compiler/</link>
      <pubDate>Sun, 09 Aug 2026 00:00:00 +0000</pubDate>
      <guid>http://blog.kkkzoz.top/posts/learning/ml-compilers/ml-compiler/</guid>
      <description>&lt;h2 id=&#34;ml-compiler-overview&#34;&gt;ML Compiler Overview&lt;/h2&gt;
&lt;p&gt;ML Compiler 位于深度学习框架和底层硬件之间，作用是把 TensorFlow、PyTorch、JAX 等框架描述的高层张量计算转换成能在 CPU/GPU/TPU 等硬件上高效执行的程序。&lt;/p&gt;
&lt;p&gt;它的典型架构是 Frontend → IR → Optimization → Backend:&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;Frontend 接收框架已经构造或捕获出来的计算图/算子程序（例如 tf.function 得到的 TF Graph、PyTorch Dynamo 得到的 FX Graph），转换成统一的中间表示 IR&lt;/li&gt;
&lt;li&gt;中间层进行算子融合、常量折叠、布局变换、内存规划、并行化等与机器学习计算相关的优化&lt;/li&gt;
&lt;li&gt;Backend 再根据目标硬件进行 lowering、调度和代码生成&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;因而 ML compiler 输入通常是带有 tensor shape、dtype、算子及数据依赖关系的计算图或 IR，输出则是面向特定设备的低层 IR、kernel 或可执行程序。&lt;/p&gt;
&lt;blockquote&gt;
&lt;p&gt;需要特别区分的是：graph capture 不一定属于 compiler 本身——例如 TensorFlow 由 tf.function tracing 捕获图，PyTorch 由 TorchDynamo 捕获图，然后 ML compiler 才接手，对这个图做优化并最终生成高效机器码。&lt;/p&gt;&lt;/blockquote&gt;
&lt;h2 id=&#34;ir-pipeline&#34;&gt;IR Pipeline&lt;/h2&gt;
&lt;p&gt;下面这套 IR 划分描述的是一个典型 ML Compiler 从&lt;strong&gt;高层模型计算&lt;/strong&gt;逐渐 lowering 到&lt;strong&gt;硬件可执行 kernel&lt;/strong&gt; 的过程。不同编译器实际使用的 IR 名称和数据结构可能不同，但抽象层次通常可以归纳为：&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
