大家好我是睿廷，目前是剛升碩二的研究生，碩零的前半年，我做的是 QEMU 模擬器針對 RISC-V 指令加速，讓 x86 主機模擬 RISC-V 架構跑 AI 模型可以加速。

到了碩一上接近結束時，研究方向轉向 AI compiler 和 AI 推論引擎，開始學習 SGLang、vLLM、Torch compile、TorchInductor、Triton、MLIR，以及它們背後不同的硬體。目前接觸 AI compiler 大約八個月了，現在還是很菜的新手，剛好趁這次鐵人賽，把這段時間做過，也卡過的研究內容重新梳理一次，希望這個月可以和大家一起走進 AI compiler 的世界，一起學習相關的知識，讓我們共同前進!

本篇大綱

• 從 Chris Lattner 的演講 「Compiler 黃金時代」看現在有哪些機會。
• 說明 compiler 如何連接上層模型、kernel、runtime 與各種 AI 晶片。
• 用 RISC-V CPU、 NVIDIA GPU、Tenstorrent ASIC 建立這個系列的三條硬體路線。
• 快速說明接下來三十天的旅程。

為什麼現在是 Compiler 的黃金時代

當初會想做 Compiler，就是被 Chris Lattner 在 ASPLOS 2021 的演講感動到。Chris Lattner 是 LLVM 計畫最初的設計者與主要作者。

The Golden Age of Compiler Design in an Era of HW/SW Co-design

為什麼 Compiler 的機會變多了？

演講有提到為什麼 Compiler 的機會變多了？

1.摩爾定律開始出現瓶頸，過去硬體效能每隔一段時間就會自動倍增的免費午餐時代已經結束，軟體無法再無條件地直接獲得效能紅利

2.越來越多領域特定架構和加速器的興起，為了追求極致效能，業界轉向針對特定領域開發專用的硬體加速器。

3.軟體開發變得困難和碎片化，這些新一代加速器通常具備異質運算環境，讓程式碼很難寫和優化，而且很多晶片廠商各自建立不相容的專用軟體堆疊，造成軟體生態碎片化。

所以需要 compiler 實作硬體抽象化，業界需要下一代 compiler 技術來提供統一的硬體抽象化，讓軟體開發者不需針對每一款新硬體重寫程式碼，降低開發門檻。

那 compiler 如何解決軟體碎片化呢?

演講有回顧了 compiler 歷史，GCC 透過開源授權還有多種前端與後端設計，打破了 1990 年代專有 C 編譯器各自為政的碎片化混亂，後來又有 LLVM 加入了模組化與函式庫設計，讓 compiler 零件可以像是積木自由重用，進而催生了 Rust、Swift、Julia 以及 CUDA 等等生態， 但是 LLVM 本質上是為 CPU 設計的，在處理現代加速器的編譯與優化時，出現架構上的限制， Chris 提到解法是底層與 compiler 框架的雙重標準化（RISC-V + MLIR）

RISC-V 用來控制處理器標準化， 加速器通常需要一個控制處理器來調度平行計算單元，與其為每一款晶片手寫專有的組譯器，不如直接採用開放、模組化的 RISC-V 核心，直接共享成熟的 C 編譯器、模擬器以及 GDB/LLDB 工具鏈。

另外 Chris 有提出 MLIR （Multi-Layer Intermediate Representation)，它是一個 Meta-compiler 框架，提供了可以重複使用的函式庫，讓開發者不用重複開發編譯器基礎設施，縮短 compiler 的開發週期，我們在 Day 13 會來介紹一下 MLIR，真的很有趣。

每次研究累了就回去聽演講，聽完演講又讓我很有動力繼續學習 AI compiler 。

Compiler 是站在模型與硬體中間的橋樑

過去提到 compiler，很多人會先想到把 C/C++ 編譯成 CPU machine code。但現在的 AI 系統越來越複雜。上層有持續變化的模型架構、tensor operator、dynamic shape、量化格式和 serving framework；底層則同時存在 CPU、GPU，以及 NPU、TPU 和各種 AI accelerator， AI compiler 的任務，就是要承接上層模型，和底層硬體中間的橋樑。所以我們也會去了解整個 AI 軟體堆疊，從模型應用到最後執行的機器碼，找到優化的機會。

我們可以先把 AI 軟體堆疊簡化成：

模型與推論服務
PyTorch model / SGLang / vLLM
          ↓
Framework operators
ATen operators / custom operators
          ↓
Graph capture 與 compiler frontend
FX graph / specialization
          ↓
Compiler optimization 與 code generation
fusion / layout / tiling / vectorization / memory planning
          ↓
產生的 kernel 或函式庫呼叫
C++ / RVV kernels / Triton or CUDA kernels / vendor libraries
          ↓
Runtime / driver / operating system
          ↓
CPU / GPU / NPU / AI accelerator

這張只是示意圖，SGLang 和 vLLM 實際上會橫跨模型執行、scheduler、KV cache、runtime 和 kernel dispatch，並不只停在最上層。CPU、GPU 和 Tenstorrent 的實際路徑也不會完全相同。

相較於底層 kernel，模型程式主要描述 tensor 要進行哪些計算，通常不會完整指定 tile 大小、指令選擇與執行緒配置，舉個例子

y = torch.nn.functional.linear(x, weight)

底層硬體需要的是另一組細節

矩陣要切成多大的 tile？
要使用哪條 vector 或 matrix instruction？
哪些資料要保留在 register、shared memory 或 local SRAM？
資料排列與存取順序要如何利用 cache locality？
哪些資料可以重用或 broadcast？
要啟動多少 thread、warp 或 core？
shape 不符合最佳化條件時怎麼 fallback？

Compiler 會和 autotuner、kernel library 與 runtime 一起補上這些執行細節，並在允許的數值誤差與語意限制內維持程式行為。不同 compiler stack 採用的 IR 不同；有些系統會逐步經過 graph IR、tensor IR、loop IR 和 target-specific IR，最後產生 machine code 或呼叫現成的 kernel library，再由 runtime 負責實際執行。

AI compiler 有很多能實際投入的方向。除了建立新的 compiler infrastructure，也可以從 operator、kernel、backend、runtime 或驗證工具開始：

• 為新 operator 寫 lowering、fusion 和 pattern rewrite。
• 研究 tiling、layout、memory planning、autotuning 和 cost model。
• 改善 compiler、runtime、driver 和硬體之間的介面。

接下來這30天的旅程，我們會走過我目前主要研究的三種硬體。每一種硬體看待計算和資料移動的方式都不一樣，也會讓 compiler 面對不同的選擇。

先從 RISC-V CPU 出發

我們會先看 Banana Pi BPI-F3 上的 SpacemiT K1。先練習讀硬體規格：RISC-V ISA、RVV、core、cache 和記憶體，分別會影響後面的哪些選擇。

接著寫一個簡單的 vector add，剛好可以專心看 RVV intrinsic 怎麼設定 vector length、載入資料、做運算，再把結果存回去。

有了這個迴圈之後，我們才把它帶進真實系統。

Day01：從 SpacemiT K1 規格讀懂 RISC-V CPU 架構
Day02：用 RVV Intrinsic 寫第一個 Vector Add 運算子
Day03：SGLang RVV Attention 後端怎麼接進來
Day04：從 Linear／GEMM 看 RVV AI 運算子
Day05：Norm、Activation、RoPE 的 RVV 寫法
Day06：Decode／Extend Attention 的 RVV Kernel

這幾篇會以我們實作的 SGLang RVV backend 為例，一直來回走同一條路：

SGLang Python
→ torch.ops
→ C++ dispatch
→ RVV kernel
→ CPU

手寫 kernel 可以讓我們看清楚硬體實際需要哪些資訊，也會遇到實作與維護成本。Day03 到 Day06 先理解手寫 backend 與 kernel；到了 Day07，我們會進入 graph compiler 與自動 code generation，觀察 torch.compile 和 TorchInductor 如何從 PyTorch graph 產生 CPU C++。

Day08 和 Day09 會接到我最近投稿的 PyTorch Conference North America 2026 的 poster：TorchInductor for SGLang Inference on RISC-V CPUs.

PyTorch PR #175746 正在為 ATen CPU vector layer 加入 RVV 支援，到目前還沒合併，我目前的實驗以這項提案及自己的開發分支為基礎，繼續處理 TorchInductor 的 RVV code generation 與 LLM Linear 所需的 RVV BF16 kernel。
我把這段工作拆成 P1–P6：從 VecRVV、GEMV / GEMM microkernel、static routing，一路做到 packed weight、small-batch serving 和可重現環境。

Day07：從 torch.compile 看 PyTorch CPU 編譯流程
Day08：PyTorch Conference 2026 Poster：為什麼要讓 TorchInductor 支援 RVV
Day09：把 Inductor RVV 接進 SGLang：Packed State、Small Batch 與重現環境
Day10：把 SGLang RVV 和 Inductor RVV 放回同一條推論服務流程

每10天都會有一個重點回顧，來複習我們前面學習到的內容。

跟著 Triton kernel 走到 NVIDIA GPU

第二站我們來到 NVIDIA GPU。

Day11：GPU 架構：從 SM、warp、memory hierarchy 看 NVIDIA GPU 系列
Day12：CUDA、CUTLASS、cuBLAS：從手寫 kernel 到高效 GEMM library
Day13：讀 MLIR Paper：多層 IR 從哪裡來，又想解決什麼問題

會介紹 Triton 這個程式語言與編譯器和 CUDA 的差別，然後以目前的 NVIDIA backend 為例，完整走一次 Triton kernel 如何在 ASUS Ascent GX10 的 GB10 GPU 上執行。

Python @triton.jit
→ TTIR
→ TTGIR
→ LLVM IR
→ LLVM NVPTX backend
→ PTX
→ ptxas
→ cubin（內含 NVIDIA GPU machine code，通常稱為 SASS）
→ CUDA Driver API 載入並啟動 kernel
→ GPU

Day14：在 ASUS Ascent GX10 上拆解 Triton JIT
Day15：打開 TTIR：Triton 前端如何理解矩陣乘法
Day16：打開 TTGIR：GB10 上的 layout、shared memory 與 MMA
Day17：打開 LLVM IR：Triton 如何接上 NVVM
Day18：讀 PTX 與 ptxas log：virtual ISA 如何變成 GB10 binary
Day19：拆開 cubin 與 SASS，再追到 CUDA Driver launch
Day20：GPU、Triton 與 CUDA Driver：把編譯到執行收成一張圖

Tenstorrent 空間資料流架構

最後一站來到到我目前正在學習的另一種硬體：Tenstorrent。

Day21：Tenstorrent：先認識 Wormhole／Blackhole，再拆解 tile 與 NoC
Day22：TT-Metal：用 reader、compute、writer 看 Tenstorrent 程式模型
Day23：TT-MLIR：Tenstorrent 的 MLIR dialect 與 compiler flow
Day24：Triton NPU Flow：Triton 如何接到不同的 NPU backend

Day25 到 Day26 會一起讀這篇 paper：〈TileLoom: Automatic Dataflow Planning for Tile-Based Languages on Spatial Dataflow Accelerators〉。

Paper 裡會探討一段 tile-based program 要放到 spatial dataflow accelerator 上，logical tile 該映射到哪個實體 core？資料能不能留在 local memory 重用？多個 core 都需要同一塊資料時，應該各自讀取，還是透過 NoC broadcast？

這份 paper 會分兩天讀。第一天先弄懂 spatial dataflow accelerator 帶來的編譯問題；第二天再把 framework、實驗結果與限制放在一起讀：

Day25：TileLoom 論文閱讀一：spatial dataflow accelerator 的編譯問題
Day26：TileLoom 論文閱讀二：front-end、dataflow planning、backend、效能與限制

最後三篇直接看程式碼裡留下來的 IR，用矩陣乘法當作是例子

Day27：TileLoom 實戰一：matmul IR 從 frontend 到 explicit memory access
Day28：TileLoom 實戰二：hardware mapping、reuse analysis、broadcast
Day29：TileLoom 實戰三：Materialize、One-Shot Bufferization 與 TT opt
Day30：統整 Tenstorrent、TT-Metal、TT-MLIR、Triton Flow、TileLoom

我們可以把前後兩個階段放在一起比較，觀察 compile pass 到底改了什麼。

準備出發囉

這個系列預設你具備 LLM 、 計算機組織、作業系統相關知識。程式部分會用到 Python 和 C++，不需要一開始就會 RVV、CUDA、MLIR、Triton、Tenstorrent，可以跟著這系列一起來學習。
準備出發，祝您旅途愉快，一路平安，一起探索 AI Compiler 的黃金鄉!

參考資料

• Chris Lattner, The Golden Age of Compiler Design in an Era of HW/SW Co-design, ASPLOS 2021
  https://www.youtube.com/watch?v=4HgShra-KnY

• PyTorch PR #175746, RISC-V Vector Extension (RVV) support for ATen
  https://github.com/pytorch/pytorch/pull/175746