前面幾篇已經把 Tenstorrent 的硬體與軟體拆開來看。Wormhole 把 Tensix cores、local L1、DRAM tiles 與 NoC 放在同一張 grid 上，TT-Metalium 程式要安排 reader、compute、writer 與 circular buffers，TT-MLIR 則將 tensor operation 逐步降成 layout、core grid、buffer、NoC 和 device kernel。
看完這些元件後，會遇到一個 compiler 問題，一個 tile kernel 要擴充到整張 core grid 時，誰來決定 logical tiles 放在哪些 cores、什麼時候執行、哪些資料可以共用，以及 NoC 上的資料要怎麼搬？
TileLoom: Automatic Dataflow Planning for Tile-Based Languages on Spatial Dataflow Accelerators 回答的就是這個問題。這篇 OSDI '26 paper 想讓 programmer 繼續使用 Triton 或 Helion 這類 tile-based language，compiler 自動負責 core mapping、execution order、data reuse 與 communication planning。
故事要從 deep learning workloads 的 memory bottleneck 開始。製程進步讓晶片可以放入更多 arithmetic units，off-chip memory 的 bandwidth 與 capacity 卻沒有同比例成長。DRAM access 的 energy cost 也高於 arithmetic operation，而 on-chip SRAM 在新製程下仍然會佔用可觀的 area 與 power。
所以單純增加 compute units 不一定能讓 workload 跑得更快。資料若持續在 shared cache 與 off-chip memory 之間往返，運算單元還是會等待 operands。
這正好對應前面講過的 Tenstorrent 硬體。每個 Tensix core 有 local L1，cores 與 DRAM interfaces 由 NoC 連成 grid。Reader kernel 可以把 tensor tiles 搬進 local buffer，compute kernel 在本地執行運算，writer kernel 再將結果送到下一個 core 或寫回 DRAM。資料也可以在 cores 之間 forward、multicast 與 reuse，減少重複往返 off-chip memory。
Spatial dataflow accelerator 就是將這種資料移動方式放到架構核心，compute、distributed local memories 與 on-chip network 組成空間上的 processing elements，software 顯式安排資料要放在哪裡、搬往哪裡、保留多久。
越來越多公司開始將 explicit data movement、distributed local memory 與 on-chip network 放進 AI accelerator 的核心設計，像是
| 公司 | Paper 列舉的架構或產品線 |
|---|---|
| Tenstorrent | Wormhole 等 Tensix core grid 架構 |
| Cerebras | Wafer-Scale Engine（WSE） |
| Graphcore | Intelligence Processing Unit（IPU） |
| SambaNova | Reconfigurable Dataflow Unit（RDU） |
| Groq | Tensor Streaming Processor（TSP） |
| Meta | Meta Training and Inference Accelerator（MTIA） |
| Amazon Web Services | Trainium |
| Tesla | Dojo |
這些系統的 core 組成、network topology、memory hierarchy 與 programming model 並不相同。共同點是運算由 distributed buffers 和顯式的 on-chip data movement 串起來，減少對大型 shared cache 與 off-chip memory 的依賴。
這也說明 TileLoom 為什麼要另外建立 architecture representation。Compiler 如果把 2D mesh、ring、wafer-scale fabric 或不同的 memory hierarchy 全部寫死在 passes 裡，很難跨硬體重用 planning logic。
Paper 以 Tenstorrent Wormhole 作為代表性的硬體架構。像是 Figure 1 畫出 8 × 8 core grid，每個 core 都有 local scratchpad memory（SPM）、FPU 與 SFPU，周邊則有多個 DRAM bank。Core 之間由 packet-switched mesh NoC 連線。
圖片出處：Wei Li et al.，〈TileLoom: Automatic Dataflow Planning for Tile-Based Languages on Spatial Dataflow Accelerators〉，Figure 1，CC BY 4.0
每個 core 都可以存取自己的 local SPM。Paper 報告 64 個 core 同時存取 local scratchpad 時，aggregate peak bandwidth 約為 24.5 TB/s，文中將它與 NVIDIA H100 約 6 TB/s 的 L2 bandwidth 比較。
Core 有 (x, y) 座標，資料要穿過 NoC 才能到達別的 core。因此，logical tile 放在哪個 physical core 上，會改變路由距離、連線競爭、broadcast 範圍和 memory bank 壓力。
這和 TT-Metalium 的 reader、compute、writer 結構可以直接對上。Programmer 要建立 L1 buffer 與 circular buffer，reader 經由 NoC 取得資料，compute 才能開始工作。擴充到多個 cores 後，compiler 還要決定每份資料由哪個 core 載入、送往哪裡、是否 broadcast，以及在 local memory 保留多久。
接著比較 CUDA 的 grid–block–thread model 拆分 compiler 責任。Programmer 將問題分成許多 blocks，每個 block 在不同資料區域執行相同計算，整個 grid 覆蓋完整 problem domain。Halide 與 TVM 也將 tile shape 和 launch configuration 當成 schedule parameters。
在 GPU 上，grid level 主要由 hardware scheduler 管理。Blocks 會動態分派給 SM，shared cache hierarchy 也可能留住跨 blocks 重用的資料。Software 與 compiler 有更多空間處理 block 內部的 threads、warps、shared memory 和 synchronization。
Triton、TileLang、CuTile、Tilus 和 Taichi 就是從這個 block-level 範圍出發。Programmer 用 tile operators 描述一個 block 要做的運算，compiler 再把 tile computation 對應到 intra-SM 或 intra-core resources。以 Triton matmul 為例，一個 program instance 負責一塊 output tile，並沿 K 軸迭代與累加。
Spatial dataflow accelerator 將 grid level 的 placement、execution order 與 communication 暴露給 software。這類硬體沒有一個大型 unified cache 幫所有 cores 自動捕捉重用，也不一定由 hardware scheduler 動態安排整個 logical grid。Compiler 因此要把 tile instances 放到數量有限的 physical cores，安排多波執行，並決定資料如何經由 NoC forward 或 multicast。這就是 scale-out dataflow planning。
| 決策範圍 | GPU 常見處理方式 | Spatial dataflow accelerator 要暴露給 software 的決策 |
|---|---|---|
| 工作分配 | Hardware scheduler 將 blocks 分配到 SM | 決定 tile instance 對應的 core 與執行 wave |
| 跨 core 重用 | Shared cache 可能隱式留住資料 | 決定 buffer、forward、multicast 和 broadcast |
| Communication | 許多細節由 hardware 與 memory hierarchy 處理 | 計畫 NoC path、traffic 與 DRAM bank access |
| Execution order | Blocks 可由 hardware 動態排程 | 編譯時期安排 spatial 與 temporal mapping |
這些決策會互相影響。例如，同一個 A tile 放到一排 core 上使用，可能適合 row broadcast，但 core mapping 改變之後，原本的重用方向、NoC traffic 和 temporal order 也會跟著改變。候選組合會很快增加。
Naive mapping 可能產生四種直接後果
目前許多高效 mapping 放在 vendor-specific compiler 或手工調校的 library 內。常見的 GEMM、convolution 與 attention 有專家撰寫的實作，新 kernel、新 model structure 或新一代硬體則要重新設計 mapping。這種依賴也會限制 kernel 在不同架構間的 portability，並增加實驗新 model structures 的成本。
Spatial dataflow accelerator 的顯式硬體結構也給 compiler 一個機會。Core coordinates、network topology、memory placement、bandwidth 和 compute resources 都可以放進硬體描述。Compiler 便能在編譯時期比較不同 schedules，將原本由 GPU hardware scheduler、cache 和 runtime 承擔的部分 grid-level 責任，改由 static planning 處理。
TileLoom 因此接收 tile-based DSL kernel 與目標硬體描述，搜尋可行的 spatiotemporal mappings 和 data movement plans，目標是平衡工作、增加 on-chip reuse，並將 NoC 與 memory constraints 納入成本估計。硬體模型不可能包含所有微架構細節，所以 framework 也保留 optional hardware profiling，可以對少量候選做實機量測，再挑出最後方案。
Introduction 最後的效能主張是 TileLoom 在兩代 Tenstorrent 系統上測試多種 kernels，結果可以接近或超過 vendor-provided handwritten libraries。這句話先當成 paper 的 claim，還要對照每個 kernel 的 baseline 與實驗數字，才能判斷它的成立範圍。
TileLoom 是一個 MLIR-based end-to-end framework。輸入是 Triton 或 Helion 這類 tile-based DSL kernel，輸出是 target spatial dataflow architecture 可執行的程式。
圖片出處：Wei Li et al.，〈TileLoom: Automatic Dataflow Planning for Tile-Based Languages on Spatial Dataflow Accelerators〉，Figure 2，CC BY 4.0
圖的左側是 architecture representation。Scale-out architecture 描述 core array 與 network，intra-core architecture 描述 functional unit 與 memory，這些資訊還會建立 performance model。虛線箭頭表示硬體資訊會同時影響 mapping、data movement 和 candidate ranking。
Front-end 接收 tile-level kernel 與 launch grid，並探索不同 block shape。候選程式會被 lower 成 MLIR，再經過 normalization，形成一致的 dataflow-agnostic representation。
Figure 2 把這個中間點標成 Dataflow-agnostic MLIR。Paper 使用 affine + linalg + scf + arith 表達 tile 與 grid 結構。此時還沒有選定 physical core mapping，所以同一份 IR 可以繼續產生多種候選 dataflow plans。
Dataflow planning 有兩個主要階段
Spatiotemporal Mapping 決定 logical tile instances 怎麼分配到 cores 和 time。Spatial dimensions 對應實體 core 座標，temporal dimensions 則對應同一組 cores 先後處理的 tile waves。
Data Movement Planning 分析固定 mapping 暴露的 spatial 與 temporal reuse，再決定 tensor tile 放在哪個 memory、何時 copy、從哪裡讀取，以及是否經由 NoC broadcast 給多個 core。
這兩步會產生多個 dataflow candidates。Performance model 先依 compute、memory bandwidth 與 NoC cost 排名，選出 top-k。系統也可以把這 k 個候選放到實際硬體 profiling，補足 architecture description 沒有覆蓋的微架構細節，最後選出 top-1。
Dataflow planning 完成後，IR 裡的 memory allocation、copy 和 communication endpoint 已經具體化，這是 Figure 2 的 Dataflow-aware MLIR。Backend 接著執行 block-level optimization 與 code generation，將每個 core 要執行的程式交給 vendor backend。TileLoom 在 Tenstorrent 上會接到 TT-Metalium。
這正好接上 TT-Metalium 的責任邊界。TileLoom 決定 core mapping、buffer 與 NoC data movement；TT-Metalium 則提供 buffer allocation、synchronization、data movement 與 compute primitive，讓這些決定可以落到實際硬體上。
假設要計算：
A: M × K
B: K × N
C: M × N
Triton 或 Helion 先把 C 分成很多 (m_block, n_block) output tiles。每個 tile program 會沿 K 軸反覆載入 A 和 B tile，呼叫 tile-level matmul，最後寫回 C tile。
TileLoom 接手後需要回答
(m_block, n_block) 怎麼映射到 8 × 8 core grid？Figure 2 裡的每個方塊，最後都會變成一個可在 IR 裡觀察的變化。例如 03_after_hardware_mapping.mlir 會展開 mapping candidates，04_after_reuse_analyzation.mlir 會標記 reuse，05_after_enumerate_broadcast.mlir 會讓 copy 帶上 broadcast region。後續讀這些 IR 時，就可以把 framework 方塊對應到具體 compiler pass。
接下來要深入 spatiotemporal mapping，看 logical parallel loops 如何變成 physical core coordinates 與 temporal tile waves，再繼續追 reuse、broadcast 與 candidate ranking。
iThome鐵人賽
看影片追技術