Adam Paszke 如何重塑深度學習框架？從動態 Autograd、PyTorch 到可組合 AI Runtime

Adam Paszke 如何重塑深度學習框架？從動態 Autograd、PyTorch 到可組合 AI Runtime

深度學習框架最關鍵的承諾，不是提供多少模型範例，而是讓研究者寫下普通程式後，系統仍能正確追蹤運算、計算梯度、調度硬體並支援擴充。Adam Paszke 作為 PyTorch 的核心創建者與論文第一作者，代表的是這條框架核心路線：以命令式程式、動態 autograd 與可組合 operator，讓模型研究不必先被固定計算圖限制。

Adam Paszke 的位置：把自動微分做成可程式化 runtime

Adam Paszke 的個人網站與 GitHub 帳號保留了他長期在程式語言、機器學習系統與 PyTorch 相關工作的公開脈絡。PyTorch 論文由他領銜作者群，詳細說明框架如何在命令式 Python 介面、高效底層與自動微分之間取得平衡。這個平衡至今仍是 AI 框架設計的核心。

對平台工程師而言，autograd 不是一個呼叫 backward 的便利功能。它定義哪些運算可被追蹤、狀態何時保存、梯度如何累積、in-place 修改何時安全，以及自訂 operator 如何參與微分。任何錯誤都可能讓模型繼續訓練卻得到不正確梯度，因此 autograd 同時是數學語意與 runtime 契約。

Define-by-run 讓控制流程成為模型的一部分

早期靜態圖框架通常先描述完整計算圖，再交由 runtime 執行。PyTorch 的 define-by-run 方式則在實際執行 tensor operation 時建立梯度關係。Python 的 if、loop、遞迴與資料結構可以直接影響當次圖，研究者更容易表達動態網路、不同長度序列與資料相依控制。

這種設計提升 debug 與探索效率，因為 stack trace、print 與一般除錯器都能工作。但動態也增加編譯難度：每次執行可能看到不同圖、形狀與 Python side effect。後來的 graph capture 與 compiler 必須辨識哪些區段穩定、哪些要回到 eager，而不能擅自改變原始程式語意。

Autograd graph 是一次執行的資料依賴紀錄

當需要梯度的 tensor 參與運算，autograd 會建立 Function 節點與依賴，並保存 backward 所需的中間值。呼叫 backward 時，engine 依拓撲反向傳播，將梯度累積到葉節點。這套機制讓使用者不必手寫每個導數，但記憶體生命週期與依賴仍真實存在。

保存過多 activation 會耗盡記憶體，過早釋放又無法反向。Gradient checkpointing 以重算換記憶體，saved tensor hooks 可改變保存方式，inference mode 則避免不需要的追蹤。平台要依模型與硬體量測，不應把所有 OOM 都用減小 batch size 處理。

Gradient correctness 需要比 loss 曲線更強的證據

自訂 loss、operator 或 extension 可能 forward 正確、backward 錯誤。若梯度方向大致合理，訓練甚至會下降，讓問題延後被發現。團隊應對可微分元件做 gradcheck，以有限差分或高精度 reference 比較；複數、稀疏、邊界與不可微點也要明確定義。

回歸測試要包含 shape、dtype、device、broadcast、空 tensor 與非連續記憶體。對 stochastic operator，固定輸入並測試統計或可控制路徑。正確性 gate 應先於效能 benchmark，否則 kernel 最佳化可能只是更快地產生錯誤梯度。

In-place operation 揭示使用者便利與 runtime 安全的衝突

原地修改可以節省部分配置，但若 backward 仍需要修改前的值，就會破壞梯度。Autograd 以 version counter 等機制偵測不安全修改並報錯。這種保守行為很重要：寧可讓程式停止，也不要靜默計算錯誤結果。

平台封裝模型時，應避免為了表面記憶體節省大量加入 in-place。先用 profiler 找到真正峰值，再評估 checkpoint、offload、fused op 或精度。若必須原地修改，要有針對 backward 與重入的測試，並記錄支援的框架版本。

Tensor、operator 與 dispatcher 是框架的共同語言

高階 Python API 最終要映射到 operator。Dispatcher 依 device、layout、autograd、functionalization 或其他 dispatch key 選擇實作，使同一語意能支援 CPU、CUDA、不同 accelerator 與擴充模式。這比在每個 API 裡寫大量硬體分支更可維護。

新 backend 不是只實作幾個熱門 kernel。它要處理 dtype、broadcast、stride、alias、錯誤、autograd 與 fallback，並通過一致性測試。若 backend 對某個 op 使用不同數值語意，模型可能只在特定硬體退化。平台選擇加速器時要跑自身 operator coverage，不只信供應商模型清單。

可組合微分不只是一階 backward

研究與最佳化常需要 Jacobian、Hessian、vector-Jacobian product、Jacobian-vector product、vmap 與高階梯度。若每種 transform 都要求模型重寫，框架就無法支援快速研究。PyTorch 的 torch.func 與相關工作嘗試把微分、向量化與函數轉換變成可組合工具。

組合的難點在於 side effect、mutation、randomness 與 alias。函數轉換通常偏好純函式，而現有模型可能修改 buffer 或依賴全域狀態。Functionalization 把部分 mutation 轉成可分析形式，但平台仍要測試實際模型。宣稱支援 vmap 或 compile，不代表所有自訂模組都能透明工作。

You Only Linearize Once 提醒我們重用線性化工作

自動微分可被理解為對程式做線性化，再轉置得到反向模式梯度。Adam Paszke 參與的相關研究探討如何更清楚地組合這些轉換與避免重複工作。對框架設計而言，這種程式轉換視角有助於把 autograd 從黑盒 tape 提升為可分析、可最佳化的語意。

對一般平台，實際價值在於高階微分、meta-learning、物理模擬與科學計算能共享一套核心，而不是每個領域建立獨立引擎。但越多 transform 疊加，錯誤與效能行為越難直覺理解，因此需要清楚的 IR、錯誤訊息與最小重現工具。

Eager 與 compiler 不是二選一

Eager execution 提供即時回饋與完整 Python 彈性；compiler 能融合 operator、降低 dispatch overhead、選擇 kernel 與改善記憶體。現代 PyTorch 路線嘗試捕捉可編譯區段，在必要時 graph break 回到 eager。成功標準是保留語意，同時讓常見工作取得效能。

平台不能只看「編譯成功」。要記錄 graph break 原因、recompile 次數、dynamic shape guard、編譯時間與快取命中。若每個新 shape 都重編譯，線上延遲可能比 eager 更差；若 fallback 不可見，團隊可能誤以為最佳化已生效。

Graph capture 必須尊重 Python side effect

模型可能讀寫 list、dictionary、global、檔案或隨機狀態。Compiler 若把這些操作錯誤重排或省略，就會改變結果。安全捕捉需要 guard 與明確 graph break，並對 mutation 做分析。使用者也應把純 tensor 計算和外部副作用分開。

生產模型可逐步 functionalize：把參數與狀態顯式傳入，工具或日誌留在圖外，隨機性使用可追蹤 generator。這不只幫助 compiler，也使測試、分散式執行與 checkpoint 更可靠。框架最佳化與良好程式結構在此方向一致。

Dynamic shape 是真實產品需求，不是角落案例

文字長度、影像尺寸、batch 與候選數會變化。完全為固定形狀最佳化雖然快，卻可能讓每種輸入產生新圖或 padding 浪費。Compiler 需要 symbolic shape、guard 與特化策略，平台則要知道真實分布，決定哪些維度固定、哪些保留動態。

測試應包含最小、最大、空輸入與邊界，監控不同 shape 的記憶體與重編譯。若產品改變上限，編譯快取與容量模型也要更新。動態支援不是一個布林功能，而是一組對輸入域的契約。

Mixed precision 讓 autograd 與數值治理相遇

半精度與更低精度能提高吞吐、降低記憶體，但梯度可能 underflow、overflow 或累積誤差。Automatic mixed precision 依 operator 選擇 dtype，gradient scaling 則保護小梯度。這些機制使低精度較易使用，仍不能取代模型級驗證。

平台要保存 autocast、scaler、matmul precision 與硬體設定，監控 NaN、Inf、loss scale 與收斂。升級框架或 GPU 後，operator policy 可能改變。評估應比較品質、穩定性、速度與成本，不應只用訓練可啟動作為通過。

自訂 autograd Function 是明確的責任邊界

當既有 operator 無法表達演算法，使用者可定義 forward 與 backward。這提供彈性，也把導數正確性、saved tensor、device、dtype 與 double backward 責任交給作者。每個自訂 Function 都應視為核心基礎設施程式碼。

除了 gradcheck，還要測試 autocast、compile、vmap、distributed 與序列化相容。若元件只在單機 float32 通過，支援聲明就應限制在該範圍。平台 registry 可記錄 extension owner 與驗證矩陣，避免模型私下帶入未審核 kernel。

記憶體 alias 與 view 語意影響所有最佳化

Tensor view 可以共享底層 storage，reshape、transpose、slice 後看似是新 tensor，實際修改可能影響原值。Autograd、compiler 與 dispatcher 都必須理解 alias，否則會錯誤重用或釋放記憶體。這也是自訂 extension 常見的隱性 bug。

團隊要測非 contiguous input、不同 stride、view 後 mutation 與跨 device。效能工具顯示的配置減少，不一定代表安全；若為了節省 copy 改變 alias 關係，應加入語意測試。框架核心的價值之一，就是集中處理這些難以由每個模型作者正確管理的細節。

分散式 autograd 要跨程序保存因果關係

當 forward 跨 worker 或模型分片，梯度依賴也跨越網路。失敗、重試與非同步通信可能讓同一梯度重複或遺失。平台需要清楚定義 step、版本與 collective 順序，並在任一 rank 失敗時安全終止或恢復。

對大模型，sharding 進一步拆分參數、梯度與 optimizer state。Checkpoint 必須記錄 shard layout 與世界大小，恢復時驗證完整性。Autograd engine 只負責計算依賴，整體 exactly-once step 仍需要訓練控制面、資料進度與 artifact commit 協作。

框架升級的驗收應從 operator 到模型分層

底層先跑 operator correctness、dtype 與 gradient tests；中層測自訂 module、extension 與 checkpoint；上層再跑代表模型的訓練步、收斂、推理輸出與效能。分層能在失敗時快速定位，不必每次都重跑完整訓練才知道問題。

同時保存 old/new 環境與 artifact digest，讓回歸可重現。Canary 只進小部分工作，觀察 OOM、graph break、compile、數值與成本後再擴量。若 rollback 需要重新建環境，代表發布機制還不成熟。

平台團隊可採用的 autograd 稽核清單

盤點自訂 Function 與 C++/CUDA op；對每個元件確認 forward reference、gradcheck、double backward、dtype、device、shape 與 alias；記錄 compile 與 transform 支援；保存 owner 與框架版本。新模型進場時自動檢查未登記 extension。

監控訓練中的 NaN、Inf、gradient norm、loss scale、記憶體峰值與 step time，並將異常連到模型、資料與環境。事故調查要能取得最小批次與 deterministic 重現，而不是只保留巨大 checkpoint。這使 autograd 從隱形黑盒變成可營運的系統。

前向模式與反向模式應依輸入輸出維度選擇

反向模式適合參數很多、輸出較少的訓練 loss，這也是神經網路最常見情境；前向模式則在輸入方向較少、輸出較多時可能更合適。若框架只提供一種模式，科學計算、敏感度分析與 Jacobian 工作就會反覆重算。可組合的 JVP、VJP 與 vmap 讓團隊依問題結構選擇，而不是把所有需求塞進一次 backward。

平台評估這些 transform 時，要以實際維度、batch 與記憶體量測。巢狀 forward-over-reverse 或 reverse-over-forward 可形成 Hessian 相關計算，但也會放大保存狀態與編譯複雜度。應限制最大問題規模、提供逾時與記憶體預估，避免研究程式意外耗盡共用叢集。

Autograd 異常偵測只適合定位，不適合永久開啟

異常偵測能追蹤產生 NaN 或錯誤 backward 的 forward 來源，對縮小問題很有價值；代價是額外紀錄與同步，可能大幅降低訓練速度。生產平台應在偵測到非有限值時保存最小重現資訊，再於隔離工作中開啟詳細模式，而不是讓所有工作長期承擔 overhead。

最小重現要包含模型與資料版本、batch 識別、隨機狀態、精度與 operator 堆疊，同時避免把敏感原始資料寫入日誌。若問題無法在相同環境重現，應比較硬體、driver、框架 build 與非決定性 operator。這套程序把數值異常從一次性 debug 轉成可稽核的事故流程。

梯度累積與清零語意也會影響模型結果

PyTorch 預設會把梯度累積到參數，這支援多個 microbatch 或多個 loss，但若團隊忘記清零，就會把不同 step 混在一起。使用 set_to_none、填零或重新配置可能有不同效能與 hook 行為。訓練框架應明確定義 accumulate steps、optimizer step、scaler update 與 checkpoint 邊界。

分散式訓練還要確保所有 rank 在相同邊界同步；某一 rank 跳過 step、遇到 overflow 或資料耗盡，都可能讓 collective 失序。平台應記錄 global step、microstep、有效 batch 與跳步原因，並在恢復後驗證 optimizer 與資料游標一致。

若要把 Adam Paszke 對自動微分、命令式程式與 runtime 的核心工作，接到 PyTorch 如何成為開源社群與平台治理基礎，可延伸閱讀 Soumith Chintala如何把PyTorch變成全球AI框架？2026現況、Torch7、開源社群與生產治理，對照核心執行語意與框架長期維護之間的關係。

Adam Paszke 留給 AI 基礎設施的核心方法

Adam Paszke 的代表性，在於把自動微分、命令式程式與高效 runtime 接成一個可被一般 Python 使用的框架核心。這條設計讓研究者保有表達力，也迫使系統正面處理動態圖、mutation、alias、dispatcher 與高階轉換。

當 PyTorch 進入編譯、大模型與新硬體時，最重要的仍是原始契約：最佳化不能犧牲使用者可理解的語意，擴充必須能參與正確微分，錯誤應該 fail loudly。能在彈性、正確性與效能之間留下可驗證邊界，才是框架成為長期 AI 基礎設施的原因。

延伸閱讀

若想進一步理解PyTorch框架如何落在GPU與系統平台，可以接著閱讀黃仁勳如何把GPU變成AI權力中心，對照自動微分、核心運算與硬體生態。

官方資料與延伸閱讀

• Adam Paszke 個人網站
• Adam Paszke GitHub 官方帳號
• PyTorch: An Imperative Style, High-Performance Deep Learning Library
• Automatic Differentiation in PyTorch
• PyTorch 官方 Autograd 文件
• PyTorch 官方 torch.func 文件
• You Only Linearize Once: Tangents Transpose to Gradients