Horace He如何推動PyTorch 2編譯？從TorchDynamo、GPT-Fast到可重現LLM推論｜2026技術更新

Horace He如何推動PyTorch 2編譯？從TorchDynamo、GPT-Fast到可重現LLM推論｜2026技術更新

先講結論： Horace He 的工作把 PyTorch eager 使用體驗接到 TorchDynamo、TorchInductor 與高效推論；每次加速都必須同時守住圖完整性、數值正確性、硬體相依與可重現測試。

Horace He 是誰？ 他是深度學習編譯與效能工程師，參與 PyTorch 2、TorchDynamo、GPT-Fast 與高效推論工作。

TorchDynamo 做什麼？ 它在 Python 程式執行時捕捉可編譯的運算片段，交給後端做圖最佳化與程式碼生成。

為什麼 PyTorch 保留 eager 模式？ Eager 便於除錯與動態控制，編譯模式追求效能；兩者並存可分工開發與部署。

圖斷裂是什麼？ 動態 Python 行為、未支援操作或資料相依可能切開計算圖，降低融合與最佳化效果。

TorchInductor 或 GPT-Fast 如何加速？ 可結合編譯、kernel、量化與快取降低延遲，但必須依模型、批次、精度與硬體重新量測。

速度變快就代表模型變好嗎？ 不代表；數值精度、輸出一致性、記憶體、錯誤處理與服務穩定性都要驗證。

可重現推論怎麼做？ 固定版本、硬體、精度、輸入與隨機種子，並記錄編譯快取、fallback 與環境差異。

如何找到真正瓶頸？ 用 profiler 分開 Python、kernel、記憶體、資料搬移、通訊與網路時間，避免只優化表面指標。

如何公平比較編譯結果？ 固定模型、輸入、batch、硬體、版本、精度與品質指標，分別報告延遲、吞吐、峰值記憶體與 fallback。

PyTorch 2 的真正難題，不是替 eager mode 加上一顆「編譯」按鈕，而是在保留 Python 動態語意的前提下，找到足夠穩定的圖、產生高效 kernel，並在遇到副作用或動態 shape 時誠實回退。Horace He 長期投入 PyTorch compiler、GPT-Fast、FlexAttention 與 function transforms，後來加入 Thinking Machines；他的路線把編譯器從離線工具變成模型工程的日常執行層。

實體索引｜PyTorch 編譯與 LLM 推理實體

• 人物、框架與工具：Horace He如何推動PyTorch 2編譯？從TorchDynamo、GPT-Fast到可重現LLM推論｜2026技術更新；核對 Horace He、PyTorch 2、TorchDynamo、GPT-Fast、LLM 推理、編譯與版本。
• 原文錨點：先講結論： Horace He 的工作聚焦 PyTorch 編譯與高效推論，TorchDynamo 等路線把 eager Python 程式捕捉成可最佳化圖；速度提升必須和圖斷裂、數值差異、硬體相依與可重現測試一起評估。 Horace He 是誰？ 他是深度學習編譯與效能工程師，參與 PyTorch 2、TorchDynamo 與高效推論相關工作。 TorchDynamo 做什麼？ 它在 Python 程式執行時捕捉可編譯的運算片段，交給後端做圖最佳化與程式碼生成。 為什麼保
• 工程脈絡：把圖捕捉、編譯、算子、記憶體、模型、延遲、吞吐與可重現性連回推理。
• 編輯界線：區分框架功能、基準條件、硬體與作者推論。

Horace He 的位置：在機器學習與編譯器交界工作

Horace He 的個人網站寫明他喜歡機器學習與編譯器，並列出 PyTorch、torch.compile、GPT-Fast 與技術文章等代表工作。這不是兩個領域的簡單相加：模型作者想保留 Python 控制流程，硬體則需要可分析的圖、明確的 shape 與可融合的 operator；編譯器必須在兩種需求之間建立契約。

他在 2025 年的第一人稱文章中說明，自己在 PyTorch 工作約四年後加入 Thinking Machines 擔任 founding engineer。該文也把他的職業選擇說得很清楚：與其只直接推進模型研究，他更重視用系統工作讓成千上萬的研究者提高效率。這正是 AI 基礎設施人物的核心影響方式。

PyTorch 2 不是把 eager mode 換成靜態圖

PyTorch 的普及很大程度來自一般 Python 程式就能定義模型。若為了編譯要求所有使用者改寫成受限 DSL，雖然容易最佳化，卻會失去原有生態。PyTorch 2 的方向是捕捉可編譯區段，保留必要的 graph break，讓現有模型逐步取得效能，而不是一次重寫。

這個策略使編譯器成為「部分而可回退」的系統。平台不能只問編譯是否成功，而要知道捕捉了多少圖、在哪裡中斷、是否因 input shape 重編譯、fallback 後剩下多少收益。沒有這些指標，按下 torch.compile 可能只是增加 cold start，卻沒有改善穩態成本。

TorchDynamo 從 Python bytecode 找到可捕捉的工作

PyTorch 2 論文說明 TorchDynamo 在 Python 層攔截 bytecode，將 PyTorch operation 序列抽成 FX graph，再交給可替換 backend 編譯。這種位置很有策略性：它比只看 operator 更早，能觀察控制流程；又不必要求使用者先提供完整靜態圖。

捕捉時必須建立 guard，例如型別、shape、global 或物件狀態。Guard 成立就能重用已編譯圖，失效則重新捕捉或 graph break。平台要把 guard failure 變成可觀測事件；若產品輸入高度分散，過度特化會造成 compile storm、cache 膨脹與尾延遲。

Graph break 不是羞恥，而是語意邊界

任意 Python 可能讀檔、修改 list、呼叫不透明 extension、依賴反射或產生難以追蹤的 side effect。安全編譯器不應假裝全部理解；遇到不確定行為時停止圖捕捉，通常比錯誤重排更可靠。Graph break 的問題不在存在，而在是否太頻繁、是否可解釋。

團隊可以先用 explanation 工具找出 break，再判斷要重構純 tensor 區段、補 operator 支援，還是接受 eager fallback。若一段業務邏輯本來就需要外部副作用，把它強行塞進圖並不會更好。可維護的模型會明確分離可編譯計算與控制面。

TorchInductor 把圖降成硬體可執行程式

捕捉到 FX graph 只是開始。TorchInductor 需要做 fusion、layout、memory planning 與 code generation，GPU 常透過 Triton 產生 kernel，CPU 則走對應的低階路徑。真正收益來自減少 Python/dispatcher overhead、降低中間 tensor materialization，並讓多個 operation 一起最佳化。

因此平台 benchmark 不能只看一個 kernel。應比較 eager 與 compile 的端到端 latency、吞吐、編譯時間、峰值記憶體、數值差異與 graph coverage。短工作若每次都重新編譯，總時間可能更慢；長時間訓練則較能攤平 compile cost。使用情境決定是否值得。

Dynamic shape 決定編譯器能否進入真實產品

文字長度、batch、影像尺寸與候選數在生產環境都會變化。為每一組形狀完全特化可得到快 kernel，卻可能產生大量版本；把所有維度都設成動態又會失去部分最佳化機會。需要根據真實分布選擇 guard、symbolic shape 與 bucket。

平台應從流量紀錄建立 shape histogram，先覆蓋主要區間，再為極端輸入設上限或 fallback。監控新增模型版本後的 recompile 次數與 cache 命中；若 prompt 長度政策改變，容量模型與編譯 cache 也要一起更新，而不是等線上 latency 爆炸才調查。

GPT-Fast 展示「原生 PyTorch 也能接近系統級最佳化」

GPT-Fast 以相對精簡、可讀的原生 PyTorch 實作 transformer inference，結合 torch.compile、量化、speculative decoding 與 tensor parallel 等技巧。它的價值不只是 benchmark，而是把原本散落在專用 inference engine 的觀念，拉回模型作者熟悉的程式環境。

對平台團隊，這提供一個可拆解的 reference：先確認 baseline，再逐項量測 compile、KV cache、量化、batch 與並行策略。不能把示範數字直接套到自己的模型；權重形狀、GPU、sequence length、精度與服務排程不同，結果就會改變。可讀性讓差異更容易被驗證。

FlexAttention 把注意力變體交給可編譯抽象

注意力最佳化常陷入「想改 score 語意，就必須重寫 fused kernel」的軟體彩票。FlexAttention 讓使用者用較高階函式描述 score modification 或 mask，再透過 PyTorch compiler 降成融合實作，目標是在彈性與 FlashAttention 類效能之間減少取捨。

這種方法的關鍵不是 API 看起來簡單，而是 compiler 能否證明轉換、處理 block sparsity、dynamic shape 與 backward。平台採用時要比較 reference attention 的輸出與梯度，涵蓋 causal、sliding window、document mask、空 block 與極端長度，再做速度與記憶體評估。

Activation checkpointing 是 compiler 與記憶體預算的交會

大模型訓練常用重算換取 activation memory。傳統手工切 checkpoint region 需要模型作者猜測邊界；若 compiler 能理解 graph、operator cost 與保存值，就有機會在記憶體預算下選擇較合理的重算策略。Horace He 也參與 PyTorch 新 checkpoint API 的公開分享。

但自動化不能只追求少用記憶體。重算會增加 FLOPs、通信與 step time，某些非決定性 operation 還可能改變結果。平台要同時記錄峰值、吞吐、數值與 recompute ratio，並用固定模型版本驗證 backward。省下 OOM 卻讓成本翻倍，不算成功。

Function transforms 讓 grad、vmap 與模型程式可組合

Horace He 參與的 functorch 路線把 grad、vmap、JVP、VJP 等轉換帶入 PyTorch，後續整合進 torch.func。這些能力對 per-sample gradient、Jacobian、meta-learning 與 ensemble 很重要，也要求 framework 更清楚處理 mutation、alias 與 randomness。

可組合轉換與編譯器共享同一個前提：程式語意要能被分析。模型若到處修改 global state 或 buffer，transform 就容易失敗。平台可透過 functionalization、顯式 state 與純函式邊界改善，不只是為了某個 API，而是讓測試、分散式與最佳化都更可靠。

從 Meta 到 Thinking Machines，問題轉向 LLM 執行可重現性

Thinking Machines 於 2025 年刊出的〈Defeating Nondeterminism in LLM Inference〉由 Horace He 與團隊合作撰寫，討論即使 temperature 設為零，batch size 與 kernel reduction 次序仍可能讓結果改變。這把編譯與 kernel 問題連到科學可重現性、評測與 on-policy RL。

「相同模型、相同 prompt」不一定足以定義相同計算。平台需要記錄 batch composition、kernel、precision、hardware 與服務排程，並分清數學非結合性、atomic、race 和隨機採樣。若評估結果會隨線上 batch 改變，就不能只靠固定 seed 宣稱 deterministic。

Batch invariance 是比固定執行順序更實用的契約

完全要求每次低階指令順序一致，可能犧牲大量效能，也未必跨硬體可行。另一種目標是 batch invariance：同一輸入不因和哪些其他輸入一起執行而改變結果。這對動態 batching 的推論服務特別重要，因為 batch 組成往往由即時流量決定。

驗收可將同一樣本放進不同大小、不同鄰居與不同順序的 batch，比較中間層或最終 logits；再對 RMSNorm、matmul、attention 分層定位。若只能達到容差內一致，也要把容差與業務影響明確化，不能用「浮點本來就不準」掩蓋可修復的漂移。

Compiler correctness 必須先於 speedup

圖捕捉、decomposition、fusion、layout 與低精度都可能改變結果。最危險的錯誤不是 crash，而是模型仍能輸出、品質卻悄悄漂移。團隊要用 eager 作 reference，在多 shape、dtype、device、training/eval 與 forward/backward 下比較，並保留失敗的最小重現。

對生成模型，token 完全相等有時過度嚴格，有時又不夠；應同時看 logits difference、top-k ordering、序列結果與任務品質。若採用非決定性 kernel，要區分允許的數值範圍和 compiler 新增的回歸。效能 gate 永遠不能取代正確性 gate。

自訂 operator 是最常見的編譯斷點與風險點

企業模型常帶有 C++/CUDA extension 或 vendor op。Eager 能跑不代表 compiler 知道 shape、alias、mutation、fake tensor 與 backward 語意。缺少 metadata 時，Dynamo 可能 graph break；錯誤宣告則可能讓 compiler 做不安全轉換。

平台應建立 operator registry，要求 reference implementation、schema、fake/meta kernel、autograd、dtype/device matrix 與 compile 測試。新 extension 先在隔離模型驗證，再進共用 runtime。若只能 fallback，應讓 fallback 可見並設定上限，避免少數 op 吃掉全部收益。

編譯 cache 需要版本與租戶治理

Compiled artifact 可能依賴模型 graph、guard、框架、Triton、driver、GPU architecture 與環境旗標。若 cache key 不完整，就會重用不相容程式；若每個細節都過度特化，又會造成儲存與 cold start 壓力。多租戶服務還要防止 artifact 跨信任邊界誤用。

可靠做法是把 artifact 視為具 provenance 的 build 產物：記錄輸入 digest、compiler 版本、target、guard 與測試結果，限制 TTL 與容量，失敗時可刪除單一 namespace 而非清空全站。預熱只針對有流量證據的 shape，不盲目產生所有組合。

升級 PyTorch compiler 要有分層 canary

先在 CI 跑 operator 與代表模型 correctness，再離線重播真實 shape，接著進內部或 shadow 流量，最後才逐步擴量。每階段觀察 compile success、graph breaks、recompile、latency、memory、GPU utilization、錯誤與品質。任何一項回歸都要能回到原版本。

框架升級常同時改 Dynamo、Inductor、Triton 與 operator decomposition，不能只比較 package version。映像檔、driver 與模型 artifact 要一起鎖定；事故報告要指出哪個層級改變。這使「編譯器更新」從一次性賭注變成可稽核發布。

AOT 與訓練圖需要另一套生命週期管理

線上服務可在請求前預先編譯部分 artifact，降低 cold start；訓練則同時包含 forward、backward、optimizer、distributed collective 與動態控制。AOTAutograd 類方法會先捕捉前後向圖，再讓 backend 一起最佳化，但 saved tensor、mutation 與高階梯度都會擴大語意風險。平台不應把推論成功的設定直接複製到訓練。

訓練驗收要跑多個完整 step，比對 loss、gradient、optimizer state 與 checkpoint 恢復；還要覆蓋 gradient accumulation、mixed precision、activation checkpoint 與不同 world size。若只能在固定模型和 shape 使用 AOT，就把限制寫入部署政策，避免新模型自動繼承未證明安全的編譯模式。

效能回歸要回到可解釋的成本分解

端到端速度由 host dispatch、graph capture、kernel、memory traffic、通信與 queue 共同決定。同一模型升級後變慢，可能是新的 graph break，也可能是 fusion 讓 register pressure 上升，或動態 batching 改變 shape。只看一個總 latency，團隊往往會錯怪 compiler 或硬體。

每次基線應保存 compile wall time、產生圖數、kernel 數、主要 kernel duration、配置量、HBM 讀寫與 collective 時間。當 regression 發生，先用相同輸入重播，再逐層關閉最佳化做二分。這種可解釋 benchmark 才能讓 compiler 團隊、模型團隊與平台團隊共享同一份事實。

平台團隊可採用的 PyTorch compiler 稽核表

列出每個模型的 compile mode、dynamic shape、graph break、custom op、precision 與 expected speedup；保存 eager reference；設定 compile time 與 cache budget；對主要 shape 跑 forward/backward；記錄 fallback 與重新編譯原因。線上 dashboard 要能依模型版本分解。

遇到效能退化時，先判斷是圖覆蓋下降、kernel 變慢、shape 分布改變、cache miss 還是 host bottleneck，不要直接關閉所有 compile。若必須停用，保留失敗 artifact 與最小輸入供離線分析。可恢復性與可診斷性和峰值速度同樣重要。

Compiler 觀測要串起 graph、kernel 與線上 batch

一般服務 metrics 只顯示一次 forward 的總延遲，無法說明它經過多少 graph、是否重新編譯、哪些 operator fallback，或用了哪個 kernel。平台應將 model digest、graph key、compiler backend、kernel artifact、shape bucket 與 batch cohort 串成同一條 lineage，再分別統計 capture、compile、launch、guard failure 與 eager 時間。

對 batch invariance 測試，觀測還要記錄同一樣本所處 batch 大小與鄰居類型，但不能保存原始 prompt。可使用去識別 request ID、shape、dtype 與輸出 digest 做差異比對。若只在離線固定 batch 正確，線上 dynamic batching 仍可能暴露 reduction 與排程差異。

分散式環境會放大不一致的編譯決策

多 GPU 或多節點工作中，若某個 rank 因 shape、guard 或 cache miss 走不同 graph，其他 rank 可能已進入 collective，最後只呈現難解的 timeout。平台要比較各 rank 的 graph digest、compile event 與 collective sequence，並確保 shared artifact 的相容鍵包含框架、driver、GPU architecture 與 compiler flags。

升級測試不能停在單卡。應用代表資料跑多 rank、restart、elastic membership 與失敗注入，確認重新編譯不會讓節點失同步。事故時先保留 rank-level compiler evidence，再決定回退 framework、停用特定 graph 或切回 eager；單純放大 timeout 只會延後真正失敗。

若要把 Horace He 對 TorchDynamo、TorchInductor 與 PyTorch compiler 的圖捕捉，接回 autograd、dispatcher 與 runtime 語意，可延伸閱讀 Adam Paszke 如何重塑深度學習框架？從動態 Autograd、PyTorch 到可組合 AI Runtime，先理解 compiler 能最佳化的核心契約，再讀它如何落到硬體與推論。

Horace He 留給 AI 基礎設施的核心方法

Horace He 的工作顯示，現代 AI 編譯器不是把模型凍結成一張圖，而是持續在 Python 語意、動態輸入、kernel 效能與可重現性之間協商。TorchDynamo、GPT-Fast、FlexAttention 與 batch-invariant 推論看似不同，實際都在尋找更好的高階抽象與可驗證 lowering。

對平台工程師，最值得採用的不是單一 API，而是這種迭代方式：保留可讀 reference、讓 compiler 自動處理重複工作、把 graph break 與數值差異變成證據，再逐層擴大最佳化範圍。速度只有在語意仍可信、錯誤可定位、回退可執行時，才會成為真正的基礎設施能力。

延伸閱讀

若想把PyTorch compiler的圖、kernel與runtime優化放進AI平台脈絡，可以接著閱讀黃仁勳如何把GPU變成AI權力中心，對照硬體、編譯器與開發者生態。

官方資料與延伸閱讀

• Cornell ICPC：Horace He 官方校隊資料與人物照
• Horace He 個人網站
• Horace He：離開 PyTorch、加入 Thinking Machines 的第一人稱說明
• PyTorch 2 論文與官方說明
• PyTorch 官方 torch.compiler 文件
• PyTorch Labs GPT-Fast
• PyTorch 官方 FlexAttention 文章
• Thinking Machines：Defeating Nondeterminism in LLM Inference

2026 年 8 月 14 日更新：把 Horace He 的現職、編譯器貢獻與可重現性分開

本文在 2026 年 8 月 14 日重新整理。Horace He 的公開履歷很容易被壓縮成幾個名詞：PyTorch 2、torch.compile、TorchDynamo、TorchInductor、GPT-Fast、FlexAttention，以及 Thinking Machines 的 batch-invariant inference。這些名詞其實對應不同層次的問題：Python 程式如何被捕捉、計算圖如何降到硬體、注意力變體如何維持可組合、以及同一模型為何在不同 batch 狀態下可能產生不一致結果。

一句話摘要：Horace He 的技術位置在機器學習與編譯器交界；他的工作價值不只是把模型跑快，而是把 eager Python、圖捕捉、kernel、快取、硬體與推論可重現性接成可以測量與治理的執行系統。本文不把任何單篇 blog、競賽履歷或 benchmark 分數寫成他單獨完成 PyTorch 2。

截至 2026 年，Horace He 現在在哪裡？

Horace He 個人網站目前自述他在 Meta 做 PyTorch，並把 PyTorch、torch.compile 與 GPT-Fast 列為讀者可能認識他的工作。這是截至更新日可直接回查的個人自述；它可以支持「目前網站所寫的現職與公開研究入口」，卻不能延伸成未公開的職稱、團隊權責或每一項產品決策。文章原有「從 Meta 到 Thinking Machines」的段落，本次改用時間與合作關係分開描述。

Thinking Machines Lab 官方文章標示 Horace He 與其他人合作，日期為 2025 年 9 月 10 日。這頁是重要的技術來源，能支持他參與 batch invariance 與 LLM inference nondeterminism 的公開文章；但一篇 2025 年合作文章不等同於 2026 年現職公告。人物文章若不把「曾經合作」「目前任職」與「文章作者」分開，搜尋摘要很容易把時間線拼錯。

PyTorch 2 的真正問題：如何保留 Python 彈性又取得編譯效能

PyTorch 2 的難題不是把 eager mode 粗暴換成靜態圖，而是在保留 Python 開發體驗的前提下，找出可以安全捕捉、最佳化與重新執行的程式區段。PyTorch 官方 PyTorch 2 論文導讀把 TorchDynamo、AOTAutograd 與 TorchInductor 放進同一個 compiler stack；這個分層讓模型作者不必一開始就改寫成另一種 DSL，平台團隊則可以在圖、編譯與 kernel 層各自觀察失敗原因。

對 AI 基礎設施而言，這是一個很實際的取捨：越高階的抽象越容易寫與維護，越低階的控制越容易壓榨硬體，但兩者之間會出現 graph break、dynamic shape、custom operator、記憶體配置與版本相容性問題。真正可靠的 compiler rollout，不是看到平均 latency 下降就宣布完成，而是要知道哪些輸入形狀被捕捉、哪些 fallback 回 eager、快取是否命中，以及結果是否仍符合原始語意。

TorchDynamo：從 Python bytecode 找到可編譯的語意邊界

TorchDynamo 的核心工作可以用一個易懂的比喻說明：它觀察 Python 程式執行，嘗試把可以穩定重複的 tensor 操作收集成圖，再把不能安全推斷的部分留在 Python。這個設計讓編譯器不必假裝整個程式都是靜態的，也讓 graph break 成為明確的語意邊界，而不是模糊的「編譯器失敗」。

PyTorch 官方 torch.compile 文件提醒使用者，編譯會涉及 graph capture、guard、recompilation 與 dynamic shapes。這些概念直接影響產品成本：若輸入 shape 變化造成頻繁重編譯，離線 benchmark 的一次 warm-up 結果就不能代表線上服務；若 guard 過度寬鬆，則可能得到不正確的快取重用。把每次編譯事件記錄成可追蹤資料，才能把效能問題與正確性問題分開調查。

TorchInductor：圖要真的落到硬體，才算完成一半

TorchInductor 將捕捉到的計算圖轉成更接近硬體的執行形式，這裡的困難從「看懂 Python」移到算子融合、記憶體流、kernel 選擇、編譯快取與不同 backend 的差異。單看一個 kernel 的 microbenchmark 很容易得到漂亮數字，但模型真正的 throughput 還會受資料搬運、啟動成本、batch、序列長度、KV cache、通訊與併發排程影響。

因此，Horace He 這條技術線的重點不是某個神奇的 speedup，而是讓高階模型程式可以與低階硬體最佳化保持可組合。平台團隊應該同時保留 eager baseline、compiled path、fallback path 與輸出差異檢查；如果只保留最快的結果，後續升級 PyTorch、CUDA、GPU driver 或自訂 operator 時，就很難知道回歸來自哪一層。

GPT-Fast：原生 PyTorch 也能碰到系統級推論問題

GPT-Fast 官方 repository把低延遲 LLM inference 的許多問題放到可閱讀的程式與 benchmark 脈絡中。它讓讀者看到，推論速度不只取決於模型架構，也取決於 compile、量化、KV cache、token 產生迴圈、prompt 長度、batch 與硬體記憶體。這類 repository 可以當作方法與實作入口，卻不能把其中一個硬體、模型或測試設定的數字直接當成所有部署環境的保證。

對選型者而言，應該把「能啟動」與「適合生產」分開。能在單張 GPU 跑起來，只證明安裝與基本路徑；能在目標 batch、目標 context、目標 concurrency 下維持 p50／p95 latency、吞吐、顯存與輸出正確性，才接近可用的 production evidence。若模型會在長 context 或工具回合中改變輸入形狀，還要把 compile cache 與 fallback 行為加入成本估算。

FlexAttention：把注意力變體放進可編譯抽象

PyTorch 官方 FlexAttention 文章呈現另一個重要方向：研究者希望把不同 attention pattern 的控制交給較高階的抽象，再讓 compiler 生成接近手寫 kernel 的執行結果。這種做法的價值在於減少每種 mask、稀疏模式或局部注意力都重寫一份低階程式的負擔。

但抽象不會自動消除風險。新的 attention score modifier、mask 邏輯與 dynamic shape 仍要經過 correctness test、梯度測試、長短序列測試與效能回歸。當模型改用特殊 attention 時，不能只看平均 tokens per second，還要確認邊界 token、padding、causal constraint 與不同 dtype 下的輸出。這是 Horace He 的技術題目和一般「模型排行榜」不同的地方：真正的產出是可重複的執行語意。

Batch invariance：為什麼同一個 prompt 不一定得到相同結果

Thinking Machines Lab 的官方文章把 LLM inference nondeterminism 拉到更細的系統層。即使 temperature 設成 0，並不代表整個服務在所有 batch 狀態都會 bitwise deterministic；浮點數非結合律、平行 reduction、kernel 執行順序與 batch 形狀，都可能讓非常小的差異出現在 logits，最後影響 token 選擇。

這裡必須精確區分三件事：第一，數學上相同的輸入是否每次得到相同的浮點結果；第二，服務層是否在不同鄰居請求併入同一 batch 時改變結果；第三，使用者是否在語意層面感受到不同答案。Batch invariance 主要處理第二層的執行契約，不是保證所有生成內容都永遠相同，也不是宣稱所有 nondeterminism 都由單一原因造成。

對需要審計的 AI 產品，這會直接影響 replay、監控與 incident review。若線上結果無法用 request id、模型版本、權重 hash、tokenizer、sampling 設定、batch metadata 與 kernel／compiler 版本重建，團隊就很難判斷差異是模型更新、資料差異還是執行順序造成。可重現性不是研究者的附加品，而是 agent、RAG、評測與人工覆核能否信任的基礎。

2026 年的 AI 基礎設施觀：效能、正確性與可重現性必須同時驗收

2026 年的 AI 系統已經不只是一次請求、一次回答。長 context、工具使用、agent loop、批次推理與多租戶 GPU 會把 compiler 的小差異放大成成本、延遲、評測與信任問題。這也是為什麼「模型變快」不是完整的工程結論：系統還要能說明哪個工作負載變快、是否犧牲精度、是否新增 compile warm-up、是否引入 cache 污染，以及失敗時是否能退回可驗證路徑。

可以採用四層驗收：語意層確認輸出與 eager baseline 在允許誤差內一致；執行層記錄 graph break、guard、recompile、kernel 與 cache；服務層觀察不同 batch、shape、tenant 與 concurrency 的 p50／p95；治理層保存版本、hash、回滾點與 incident replay。這四層一起存在，才有資格把一次 local benchmark 推進到 production canary。

Horace He 技術位置的三層可引用總結

人物層：Horace He 個人網站目前寫明他在 Meta 做 PyTorch，並以 PyTorch、torch.compile 與 GPT-Fast 作為公開研究入口；Cornell ACM 頁面則提供其 ICPC 校隊的歷史圖片與身份脈絡。這些來源不延伸證明未公開職稱或全部產品貢獻。

系統層：他的公開技術脈絡連結 PyTorch 2 compiler stack、TorchDynamo、TorchInductor、GPT-Fast、FlexAttention 與 batch-invariant inference；這些問題共同指向「如何讓 ML 程式在不同硬體與工作負載下可編譯、可觀測、可重現」。

限制層：任何 speedup 都依模型、硬體、版本、shape、batch、compile warm-up 與測試方法而定；Thinking Machines 的合作文章也不能直接改寫成 2026 現職公告。文章應把官方文件、程式碼、技術 blog 與人物自述分開標示，避免把一個來源的證據範圍擴張到另一個主張。

Horace He 常見問題：更新後的精確回答

Horace He 現在在哪裡工作？

截至 2026 年 8 月 14 日，他的個人網站目前寫明自己在 Meta 做 PyTorch。這是當期公開自述；本文不另行推測其職稱、團隊層級或未公開專案。

Horace He 是 PyTorch 2 的唯一作者嗎？

不是。PyTorch 2 是大型開源專案與多位研究者、工程師共同完成的 compiler stack。Horace He 的公開工作可放在 torch.compile、GPT-Fast 與 ML systems 的重要貢獻脈絡理解，不應寫成一人完成整個 PyTorch 2。

TorchDynamo 和 TorchInductor 有什麼不同？

TorchDynamo 主要處理 Python 程式的圖捕捉與可編譯邊界；TorchInductor 則把捕捉到的計算圖進一步降到可執行的 kernel／backend 路徑。實際 PyTorch 2 compiler stack 還包含其他層，兩者不是可以互換的同義詞。

GPT-Fast 的 benchmark 可以代表所有 GPU 嗎？

不能。GPT-Fast 的數字受模型、量化、GPU、driver、PyTorch 版本、context、batch 與測試腳本影響。它適合作為實作與測量入口；要做選型，仍要在自己的工作負載上重跑並保存版本與設定。

Batch invariance 是不是代表 LLM 永遠產生相同答案？

不是。它主要是對 batch 狀態與推論執行一致性的工程討論，不等同於消除 sampling、模型版本差異或所有生成內容變動。可靠的系統要明確定義「相同」是 bitwise、數值誤差、token 序列還是語意層級。

為什麼文章要更新人物圖片？

本篇保留既有 Cornell 官方人物圖，並重新核驗其原始 URL、本站檔案與 hash；alt 與 caption 說明圖片只用於辨識人物與校隊歷史脈絡，不把肖像當成 PyTorch 性能或現職細節的證明。

本次更新的官方資料

• Horace He 個人網站：現職自述與 PyTorch／torch.compile／GPT-Fast 公開入口。
• Cornell ACM past teams：ICPC 校隊歷史身份脈絡。
• PyTorch 官方 PyTorch 2 論文導讀、torch.compile 官方文件與 dynamic shapes 官方文件。
• GPT-Fast 官方 repository與 FlexAttention 官方文章。
• Thinking Machines Lab：Defeating Nondeterminism in LLM Inference：2025 年合作技術文章，不代替 2026 現職公告。
• Cornell 官方 Horace He 圖片：人物／校隊脈絡圖片，不是性能證據。

若想把 Horace He 的 PyTorch compiler 與 FlexAttention 接到 Triton kernel 的 tiling、occupancy 與 online softmax 實作，可接著閱讀 Triton、Attention Kernel、Tiling 與 Online Softmax。

若想把 Horace He 對 PyTorch compiler、FlexAttention 與動態圖的處理，延伸到 Tri Dao 對 FlashAttention 與 IO 效率的演算法設計，可接著閱讀 Tri Dao、FlashAttention、Mamba 與 Transformer 效率。