Mehdi Amini 如何打造可擴充 MLIR？從 LLVM 基礎設施到 AI 編譯器治理

Mehdi Amini 如何打造可擴充 MLIR？從 LLVM 基礎設施到 AI 編譯器治理

先講結論：Mehdi Amini 的 MLIR 工作把多層 IR、可擴充方言、重寫系統與 LLVM 後端接成工具鏈；可擴充性同時是介面、測試、版本與社群治理問題。

Mehdi Amini 是誰？ 他是編譯器工程師、MLIR 論文共同作者與 LLVM／MLIR 生態的重要貢獻者。

MLIR 的核心價值是什麼？ 用多層 IR 表達不同抽象，讓高階模型語意與低階硬體最佳化能在同一基礎設施協作。

Dialect 如何支援擴充？ 新領域可定義操作、型別、驗證與轉換，不必修改所有既有編譯器核心。

IR 驗證器為何重要？ 它檢查型別、不變量與合法組合，讓錯誤在流入後續 pass 前被發現。

MLIR 和 LLVM IR 如何分工？ MLIR 承接較高階與中階語意，LLVM IR 常作為更低階後端介面；分工可降低耦合。

重寫系統和 pass 解決什麼？ 它們以可組合步驟轉換與最佳化 IR，讓不同硬體、模型與方言能重用工具。

開放工具鏈的治理難題有哪些？ API 相容、測試責任、版本策略、效能回歸與文件都需要社群共同維護。

如何避免 dialect 碎片化？ 先定義共享語意與互通規則，再用轉換、共同測試與文件維持一致性。

AI 編譯器要如何量測成果？ 同時追蹤編譯時間、生成程式效能、數值正確性、記憶體占用與錯誤診斷品質。

當 AI 編譯器要同時服務模型框架、研究用方言、硬體後端與生產部署，最大的挑戰往往不是缺少最佳化，而是基礎設施無法安全擴充。Mehdi Amini 是 MLIR 論文共同作者與核心維護者之一，長期投入 IR 架構、重寫系統、pass 基礎設施與社群治理。他代表的工程方法，是把「任何人都能擴充」轉化為有驗證、有介面、有測試且能上游協作的系統。

實體索引｜MLIR 與 AI 編譯器治理實體

• 研究者、基礎設施與編譯器：Mehdi Amini 如何打造可擴充 MLIR？從 LLVM 基礎設施到 AI 編譯器治理；核對 Mehdi Amini、MLIR、LLVM、AI 編譯器、IR、方言、版本與治理。
• 原文錨點：先講結論： Mehdi Amini 是 MLIR 與 LLVM 生態的重要工程貢獻者，關注 IR 設計、工具鏈整合與編譯器治理；AI 編譯器能否擴展，取決於介面、測試與社群規則是否同樣清楚。 Mehdi Amini 是誰？ 他是編譯器工程師與 MLIR 貢獻者，參與 LLVM 基礎設施與 AI 編譯器工具鏈。 MLIR 的核心價值？ 以多層 IR 表達不同抽象，讓高階模型與低階硬體最佳化可以在同一基礎設施協作。 dialect 如何支援擴充？ 新領域可定義操作、型別、驗證與轉
• 編譯脈絡：把中間表示、抽象層、最佳化、Lowering、後端、開源協作與治理連回 AI 編譯。
• 編輯界線：區分專案架構、社群治理、產品支援與效能推論。

Mehdi Amini 的角色：讓研究原型成為共享 compiler infrastructure

MLIR 官方論文與維護者資料都列出 Mehdi Amini。LLVM 開發者大會的官方簡報則持續呈現他對 MLIR internals、上游協作與基礎設施設計的投入。這些工作不像一個新模型那樣容易被看見，卻決定數百個前後端能否共享工具而不互相破壞。

AI compiler 不是封閉程式：它要讓框架作者加入 operation、讓硬體團隊加入 lowering、讓工具團隊讀寫 IR。擴充點若沒有契約，速度愈快，技術債也累積愈快。Amini 的重要性，正在於把 extensibility 與工程紀律放在同一個設計裡。

MLIR 的共同物件模型降低重複建設

Operation、value、type、attribute、region、block 與 location 構成 MLIR 的共同骨架。Dialect 可以自訂語意，但仍使用相同的 parser、printer、verification、diagnostics 與 pass manager。新領域因此不必重新發明一整套 compiler framework。

共享骨架也讓跨 dialect 工具成為可能，例如 IR diff、symbol 查找、bytecode、除錯與 reduction。對企業而言，真正的節省不是少寫幾個 class，而是不同編譯團隊能共用測試、觀測與維運能力，降低人才被鎖在單一私有格式的風險。

Operation、type 與 attribute 必須清楚分工

Operation 表示行為，type 描述值的靜態性質，attribute 保存編譯期已知資訊。若把所有資訊都塞進 operation 名稱或任意字典，分析很難重用；若把會變動的 runtime 狀態誤當 attribute，又會讓 compiler 做出不成立的假設。

Dialect 設計應先寫出語意與生命週期，再決定資料放在哪裡。哪些資訊會被 rewrite 改變、哪些必須參與 uniquing、哪些要序列化，都要有測試。清楚資料模型能讓 verifier 提早攔截錯誤，也讓後續 lowering 不必猜測。

Region 與 block 讓結構化控制流程可以保留

AI 工作負載不只有純資料流，也包含條件、迴圈、函式、融合區域與裝置執行範圍。MLIR 允許 operation 擁有 region，region 再由 block 與 SSA value 組成，因此不同 dialect 能表達自己的控制結構，同時共享 traversal 與分析。

過早把結構化控制流攤平成 jump，可能失去適合融合與平行化的資訊；永遠保持高階則難以產生機器碼。Progressive lowering 應在每一階段保留必要結構，並用明確 conversion 把控制語意轉下去，避免隱性假設。

Traits 與 interfaces 是跨 dialect 重用的關鍵

若每個最佳化都用 operation 名稱判斷能力，新增 dialect 就必須修改大量中央程式碼。Traits 可表達無區域、交換律等結構性質，interfaces 則讓 operation 實作共同能力，例如 shape inference、memory effect 或 type inference。

好的 interface 以行為契約為中心，不洩漏單一 dialect 細節。呼叫者只依賴能力，提供者則負責正確實作與測試。企業新增 interface 前，應先確認至少有多個真實使用者，否則過早抽象會形成難以演進的 API 負擔。

宣告式定義把文件、驗證與程式碼連起來

MLIR 的 operation 定義可宣告 operands、results、attributes、constraints 與組裝格式，再產生部分 C++。這降低 boilerplate，也讓規格能驅動 verifier 與文件。當定義改變時，相關輸出能一起更新，減少實作和說明分裂。

宣告式工具不是免寫設計。複雜語意仍需自訂 verifier、canonicalization 與測試；名稱與 constraint 要讓使用者理解。團隊應審查產生後的公共介面，避免把方便 generator 的結構直接變成永久相容契約。

Rewrite infrastructure 要同時管理正確性與複雜度

Canonicalization、fusion、folding 與 lowering 都依賴 pattern rewrite。Pattern 可用 imperative 或宣告方式建立，但每條規則都要說明適用條件與結果語意。浮點 reassociation、side effect、aliasing 與 dynamic shape 是最常被忽略的邊界。

規則應有 unit test、negative case 與模型級 differential test。對可能互相觸發的 pattern 設定 benefit 與迭代上限，觀測 rewrite 次數與 IR size。若 compiler 只在罕見模型上耗盡記憶體，通常也是 correctness 問題，不只是效能問題。

Pass manager 必須知道分析何時失效

Compiler pass 會查詢 dominance、alias、call graph 或 shape 等分析結果；當 IR 被修改，舊分析若仍被重用，就可能導致錯誤判斷。Pass 必須準確宣告 preserved analysis，framework 才能在正確與效能之間取得平衡。

生產 pipeline 還需要 timeout、取消、統計與失敗隔離。對每個 pass 記錄時間與 IR 規模，才能找出退化。若某一步失敗，錯誤應包含 pipeline、operation location 與最小可重現線索，而不是只回傳通用 internal error。

多執行緒編譯不能犧牲決定性

大型模型的編譯時間很長，平行化 traversal 與 pass 很有吸引力；但不穩定 iteration order、全域狀態或 thread-unsafe cache 會讓相同輸入產生不同 IR。這類非決定性使 cache、除錯與回歸比對失去可信度。

平台要重複編譯同一輸入並比較 artifact digest，對 symbol 命名與集合順序採穩定規則。隨機化測試可以揭露隱性依賴，production 則固定 seed 與環境。加速只有在輸出仍可重現時才有營運價值。

Dialect conversion 需要明確合法性與失敗語意

Lowering 不應是「能轉多少就轉多少」。Conversion target 要定義 legal、illegal 與 dynamically legal operation；type converter 則管理值與簽章變化。流程結束時若仍有非法節點，compiler 應立即停止並指出原因。

嚴格合法性可防止半轉換 IR 流入後端。企業每個 stage 都應列出允許 dialect 與版本，對未知 operation fail closed。必要時提供明確 fallback 到舊 compiler，而不是讓 runtime 猜測剩餘節點如何執行。

從 MLIR 降到 LLVM IR 要選擇正確資訊邊界

LLVM IR 適合較低階的 SSA、控制流程與 code generation，但 tensor shape、layout、domain operation 與 accelerator mapping 往往需要在更高層處理。過早 lowering 會失去可融合與可特化資訊，太晚則可能讓後端承擔不必要複雜度。

合理 pipeline 會逐步把 tensor 轉為 buffer 或較低層結構，顯式處理 memory space、lifetime 與 ABI，再交給 LLVM。每個邊界要測 allocation、alias、alignment、overflow 與錯誤釋放。效能回歸常源於資訊消失的時機，而不只是後端品質。

Bytecode 與版本把內部 IR 變成外部契約

只要 IR 會跨程序、存入 cache 或交給部署系統，它就不再是短暫記憶體結構。Operation、type 與 attribute 的編碼必須有版本與相容策略；舊 reader 遇到新內容要明確拒絕，不能錯誤解讀。

平台應區分可長期保存格式與僅限同版本交換的內部格式。Artifact 記錄 producer、dialect version、target 與 digest，升級前批次讀取舊樣本。若無法保證向前相容，就保存 source 與重建環境，並先演練 rollback。

Diagnostics 與 location 是模型團隊的操作介面

Compiler error 若只顯示 C++ stack 或內部 operation 編號，框架使用者無法處理。MLIR location 能把 IR 對應回模型節點、原始碼或多層轉換來源；診斷則應解釋違反的契約、實際值與可能修正。

Location 也可能包含內部路徑或敏感模型名稱，因此 production log 要去識別與分級。完整 IR dump 僅放在受控 evidence store，普通監控只保存 digest、stage 與錯誤分類。可除錯性與資料保護可以同時達成。

mlir-reduce 代表「先縮小再理解」的工程文化

複雜模型可能生成數萬行 IR，直接閱讀幾乎不可能。Reducer 透過反覆刪除或簡化結構，在仍能重現 crash 或錯誤結果的前提下產生最小案例。這使問題能安全分享，也讓回歸測試保持精準。

團隊要為 reducer 提供穩定的 interestingness test，例如固定退出碼、特定診斷或輸出差異。非決定性問題先穩定重現，敏感常數再替換。每個 production compiler incident 最終都應留下小型 regression test，而不是只保存原始大模型。

Symbol 與 ABI 邊界要能跨模組演進

大型編譯流程通常由多個 module、library 與裝置 artifact 組成，symbol name、visibility、calling convention 與資料 layout 會形成實際 ABI。若 pass 任意改名或改變函式簽章，cache 與分階段部署就可能失效。

平台要在 IR 層明確標記公共與私有 symbol，對跨模組引用做 verifier，並為 ABI 變更設定版本與遷移。Link 前後都檢查 unresolved reference、型別與 target data layout。能在單一測試中編譯，不等於可跨服務穩定交換。

Transform dialect 把最佳化策略和負載描述分開

同一個 tensor operation 在不同硬體、shape 與服務目標下，可能需要不同 tiling、fusion 或 vectorization。若所有策略硬編碼進 pass，新增 target 就會堆疊條件。Transform dialect 提供一條把 transformation intent 表達成 IR 的路徑。

策略可被檢查與保存，但仍要防止 tuning script 產生非法或過度特化 pipeline。每個 transform sequence 要綁定輸入條件、target、工具版本與效能證據；找不到對應 payload 時明確停止。可程式化 transformation 只有配合約束才具可重現性。

遠端編譯服務需要租戶隔離與資源預算

當模型編譯移到共享服務，單一惡意或異常 IR 可能耗盡 CPU、記憶體與磁碟，影響其他租戶。Queue 應限制輸入大小、巢狀深度、並行與執行時間，worker 使用隔離身分，預設沒有外網與 production 資料存取。

結果 cache 以租戶、模型 digest、toolchain 與 target 完整分區，不能因 key 碰撞洩漏 artifact。Audit log 保存提交者、pipeline、資源消耗與結果 digest，但不暴露模型內容。基礎設施可擴展必須包含多租戶安全，而不只是 pass extensibility。

上游友善不是禮貌，而是降低生態分裂

Mehdi Amini 在 LLVM 開發者會議討論讓 upstream MLIR 更容易合作，背後是大型專案的現實：若介面、review、測試與文件成本太高，下游就會維護私有 fork；fork 愈多，共同基礎設施愈難演進。

上游也不能無條件接受所有 vendor feature。貢獻要證明通用性、維護者與測試，設計討論留下紀錄，破壞性變更提供遷移。企業參與時應安排工程容量維護 upstream，而不是只在需要功能時一次性丟出巨大 patch。

方言治理避免 extensibility 變成無限碎片

每個新 dialect 都增加概念、conversion 與版本成本。建立前應盤點現有 dialect 能否擴充，定義唯一語意需求與退出條件。若只是暫時承接 importer 結果，可標示為內部過渡層，不把它包裝成永久公共格式。

治理清單包括 owner、RFC、operation 規格、verifier、canonicalization、round-trip、bytecode、conversion coverage 與 deprecation。跨團隊共用時，再增加相容窗口與變更通知。自由擴充只有配合責任歸屬，才不會成為長期負擔。

Compiler plugin 與外部模型需要安全邊界

Dialect plugin、custom pass 與 parser 可能載入 native code或處理惡意構造的巨大 IR。Build worker 應限制網路、檔案、CPU、記憶體與執行時間；plugin 來源要有 allowlist、簽章、版本鎖與 code review。

Parser、verifier、bytecode reader 與 rewrite engine 要做 fuzz，對深層巢狀、極大 tensor 與循環 symbol reference 設上限。輸出 artifact 在進入部署前再驗證 schema、來源與完整性。Compiler 是供應鏈執行面，不能假設所有模型可信。

企業導入 MLIR 的分階段策略

第一階段選一個明確問題，例如共用 diagnostics、替換單一 graph importer 或建立特定 lowering。先保存舊路徑為 fallback，建立相同輸入的 differential test，量測正確性、compile time 與 runtime 效能。

第二階段才建立公共 dialect 與多後端，指定 owner 與 release cadence。第三階段處理 artifact 穩定、remote compilation、cache 與部署驗證。把所有層一次重寫會讓任何 regression 都難以定位，也無法證明 MLIR 本身帶來的效益。

驗收 AI compiler 基礎設施的實際矩陣

功能面要覆蓋 operation、dtype、static 與 dynamic shape、control flow、custom op、不同 target 與版本升級；正確性面做 operation reference、模型 differential、極端值與品質評估。效能面同時量 compile time、執行延遲、吞吐、記憶體與 artifact size。

營運面則測 timeout、取消、OOM、cache 損壞、未知 dialect、reader 版本不符、plugin crash 與 rollback。每個測試保存輸入 digest、工具鏈、pipeline 與硬體。只有結果可重現，benchmark 才能支援架構決策。

Mehdi Amini 留給 AI 基礎設施的核心方法

Mehdi Amini 的代表性，在於把 compiler extensibility 建立在可執行契約上：共同 IR 物件模型提供骨架，traits 與 interfaces 支援跨 dialect 能力，rewrite 與 conversion 管理變換，pass manager、diagnostics、bytecode 與 reducer則支撐長期營運。

這套方法也提醒團隊，平台成功不能只靠漂亮架構。每個擴充都要有 owner、verifier、測試、版本與上游策略；每次最佳化都要能回溯與回退。當 AI 模型、硬體與框架持續變化時，可治理的演進能力就是核心競爭力。

延伸閱讀

若想把MLIR與LLVM的編譯器治理放進AI運算平台脈絡，可以接著閱讀黃仁勳如何把GPU變成AI權力中心，對照硬體、compiler與開發者生態。

官方資料與延伸閱讀

• MLIR 官方 FAQ 與論文作者資訊
• MLIR 官方核心維護者文件
• MLIR 官方開放專案與導師名單
• EuroLLVM 2024：Deep Dive on MLIR Internals
• LLVM Developers’ Meeting：Making Upstream MLIR More Friendly
• EuroLLVM 2019：MLIR Tutorial
• Mehdi Amini GitHub 官方身分頁