Sam Gross 如何改寫 Python 與 AI 執行效能？從 PyTorch、PEP 703 到 Free-Threading

Sam Gross 如何改寫 Python 與 AI 執行效能？從 PyTorch、PEP 703 到 Free-Threading

AI 軟體基礎設施常把效能問題推給 GPU、kernel 或分散式網路，但 Sam Gross 的工作提醒我們：模型上層所依賴的 Python runtime，也可能決定資料管線、服務併發與開發介面能否自然擴張。他既是 PyTorch 論文共同作者，也是 PEP 703 的作者；從動態深度學習框架走到 CPython free-threading，主題始終是如何保留 Python 的可用性，同時移除系統級瓶頸。

Sam Gross 的位置：從 PyTorch runtime 走進 CPython 核心

PyCon US 2023 的官方講者頁將 Sam Gross 介紹為 Meta AI 軟體工程師與 PyTorch 共同作者。這段經歷很重要，因為他面對的不是抽象的語言效能競賽，而是實際 AI 工作負載：Python 負責模型與控制流程，C++、CUDA 與加速器負責大量運算，兩者之間還有資料載入、排程、extension 與部署邊界。

當一個框架必須讓研究者保留完整 Python，又要在多核心與多 GPU 環境中提高吞吐，GIL 就不只是教科書上的直譯器細節。PEP 703 直接以科學運算與 AI/ML 為重要動機，說明多程序、受限的圖捕捉與多直譯器方案雖能繞路，卻各自增加記憶體、CUDA context、封裝與除錯成本。

為什麼 GIL 對 AI 平台不是單純的 CPU 問題

模型主要算力可能在 GPU，但線上服務仍要做 tokenization、batch 組合、請求路由、後處理與狀態管理；訓練端也有資料解碼、augmentation、checkpoint 與控制邏輯。只要多條執行緒需要回到 Python bytecode，單一 GIL 就可能形成協調瓶頸。GPU 利用率下降時，問題未必在 kernel，也可能是 host 端無法及時供應工作。

傳統解法常使用 multiprocessing。它能繞過單一直譯器鎖，卻需要處理程序啟動、序列化、共享記憶體、錯誤傳播與資源複製。對已初始化 CUDA 的程序，fork 還可能帶來難解的狀態問題。Free-threading 的價值不是宣稱執行緒永遠更快，而是讓同一程序內的共享狀態與多核心並行重新成為可選的工程工具。

PEP 703 改的不是一把鎖，而是一組記憶體語意

移除 GIL 之所以長期困難，是因為 CPython 的 reference counting、container 操作、garbage collection 與 C API 都曾依賴這把全域鎖保護。PEP 703 採用 biased reference counting、deferred reference counting、immortal objects、物件層級同步與經調整的 mimalloc，目標是在多執行緒安全與單執行緒成本之間找到可維護的平衡。

這些名詞不是只給直譯器開發者。平台若大量使用原生 extension，就必須知道哪些物件可跨執行緒共享、哪些 API 以前靠 GIL 隱性保護、哪些模組載入後會重新啟用 GIL。把執行檔換成 free-threaded build，並不會自動把資料競爭、共享 mutable state 或 extension 的未定義行為修好。

從 Python 3.13 實驗到 3.14 正式支援

Python 3.13 首次提供可選的 free-threaded build，當時明確標示為實驗。到了 Python 3.14，PEP 779 讓它進入 phase II：正式支援、但仍然是可選 build，不是預設或唯一模式。這個區別很關鍵；正式支援代表設計與 API 已有較穩定承諾，不代表整個生態已能無痛切換。

Python 官方文件也提醒，部分帶 C extension 的第三方套件仍可能不支援 free-threading，載入時甚至會自動重新啟用 GIL。平台驗收不能只檢查安裝成功；必須在執行中用 sys._is_gil_enabled() 等機制確認實際模式，並把套件 wheel、ABI、runtime flag 與硬體環境一起納入證據。

官方支援不等於預設：phase II 的真正含義

PEP 779 為 phase II 設定效能、記憶體、API 穩定性與維護性的門檻，同時把是否進入預設 free-threading 的 phase III 留給未來決策。這是一種務實治理：先讓更多真實工作負載採用，取得成本與效益資料，再決定是否改變所有 Python 使用者的預設。

對企業平台而言，這代表現在適合建立相容性軌道，而不是一次性全面切換。可以選擇 CPU-bound、執行緒自然且 extension 依賴可控的服務作 canary；GPU 訓練、資料科學 notebook、複雜 vendor extension 則分開評估。每一類工作負載都應有自己的效能、正確性與回退門檻。

單執行緒成本必須和多核心收益一起量

沒有 GIL 並非免費午餐。物件同步、atomic 操作、記憶體配置與垃圾回收策略都可能提高單執行緒成本或記憶體占用。PEP 779 記錄 phase II 評估時常見的線性效能與記憶體代價，也明確說明不同平台的數值會有差異。拿一個理想化 microbenchmark 當全站結論，會掩蓋真正的容量風險。

正確測法應同時包含單請求延遲、不同 thread count 的 throughput、p95/p99、RSS、GC pause、CPU 使用率與 context switching。對 AI 服務還要一起看 GPU utilization、batch formation time 與 queue depth。若多執行緒只把 bottleneck 推到記憶體頻寬或 extension lock，增加 thread 反而可能讓尾延遲變差。

PyTorch 的經驗說明「Python first」也需要 runtime 工程

PyTorch 論文主張命令式、Pythonic 的使用方式可以和高效 accelerator runtime 並存。這項承諾背後不是單一技巧，而是 dispatcher、autograd、tensor storage、operator library、C++ runtime 與 Python binding 的共同設計。Sam Gross 作為作者群成員，代表的正是讓上層自由度不被底層成本吞噬的工程方向。

同一原則延伸到 no-GIL：不是要求使用者離開 Python 才能取得效能，而是重新設計 runtime，使更多自然 Python 程式能安全運用硬體。這也解釋為什麼 AI 基礎設施人物不能只按產品曝光排序；改變語言執行模型的人，會同時影響框架、資料工具、服務與整個套件生態。

資料載入是最適合也最容易誤判的試驗場

影像解碼、文字解析與 augmentation 看似適合多執行緒，但實際 pipeline 可能混合 Python、NumPy、原生 library、磁碟與網路。某些原生函式原本就會釋放 GIL，因此改用 free-threaded build 不一定有顯著收益；另一些 Python-heavy transform 則可能得到更直接的多核心擴張。

平台應把 pipeline 拆成階段，量測 read、decode、transform、collate 與 host-to-device copy。使用固定資料快照與 warm cache、cold cache 兩組情境，避免把磁碟波動誤認為 runtime 改善。驗收還要比對輸出 hash、隨機種子與樣本順序，不能為了吞吐犧牲資料正確性。

線上推論要特別觀察尾延遲與共享狀態

Free-threading 可能讓多個請求在同一程序並行執行 Python 邏輯，減少多 worker 的記憶體重複；但模型 cache、tokenizer、metrics、LRU 與 request context 若原本依賴 GIL，就可能暴露 race。平均吞吐增加，並不保證 p99 或錯誤率改善。

安全 canary 應先限制流量與 thread 數，對輸入輸出做 shadow comparison，並啟用 race-sensitive 測試與高基數錯誤標記。若結果依 thread interleaving 改變，要保留可重現的 request batch 與 seed。回退機制必須能切回 GIL build，而不是臨時重建所有 container。

C extension 是遷移中最重要的供應鏈邊界

科學運算與 AI 套件大量依賴 C、C++、Cython、Rust 或 CUDA extension。過去「呼叫 Python C API 時持有 GIL」常被當成默契；free-threading 後，extension 必須明確標示支援並使用合適的 critical section、thread state 與物件存取 API。未更新的套件可能選擇重新啟用 GIL，以安全性換相容性。

平台應建立 extension inventory：名稱、版本、wheel tag、原生依賴、free-threading 聲明、測試 owner 與回退版本。掃描 import 成功遠遠不夠，還要在併發下跑 reference output、allocation stress、shutdown/reload 與 exception path。Vendor binary 若沒有公開支援矩陣，就應視為尚未驗證。

Thread-safe 不代表業務邏輯自動具備原子性

CPython 讓內部物件不因同時操作而損壞，和應用層的「檢查後更新」是否原子是兩回事。兩條執行緒先讀 balance、各自計算再寫回，即使 dictionary 本身安全，仍可能遺失更新。過去因 GIL 時序而碰巧穩定的程式，在真正並行後會更容易暴露問題。

團隊要把共享 mutable state、cache fill、singleton 初始化與 lazy loading 列為審查焦點，使用 lock、queue、immutable snapshot 或單一 owner。測試應刻意增加切換機會並重複執行；沒有失敗只能說尚未重現，不能證明沒有 race。資料一致性的契約必須由應用明確建立。

可觀測性工具也要理解新的執行模型

Profiler、tracer、debugger 與 sampling agent 可能假設某一時刻只有一條執行緒執行 Python bytecode。Free-threading 後，stack aggregation、事件排序與 overhead 都可能改變。若 observability agent 本身不是 thread-safe，它甚至會成為新的 crash 或鎖競爭來源。

遷移前應驗證 CPU profiler、OpenTelemetry instrumentation、錯誤追蹤、coverage 與記憶體工具。平台 dashboard 要區分 GIL-enabled 與 free-threaded build，避免把兩種環境混在同一基線。事故時能讀出 build mode、GIL 實際狀態與 extension 清單，才有足夠線索定位。

容量規劃不能再只用 process 數量

傳統 Python 服務常以 worker process 數量對應 CPU core；free-threading 讓每個程序內的 thread 數、共享模型記憶體與 allocator 行為變成新的容量旋鈕。少量程序可降低模型副本與 cold start，但單一程序失效的 blast radius 也會變大。

平台應建立 process×thread×batch 的實驗矩陣，量測吞吐、記憶體、尾延遲與故障隔離。不要假設 thread 等於 core，也不要把所有 core 都塞進一個程序。NUMA、記憶體頻寬、GPU stream 與下游 connection pool 都會限制最佳點。

部署工件需要同時鎖住 ABI 與 GIL 模式

同一 Python 版本可能有一般 build 與 free-threaded build，extension wheel 相容性也可能不同。若 artifact manifest 只寫 Python 3.14，重建時仍可能得到不同 runtime。映像檔應記錄 interpreter build、ABI tag、package hash、編譯旗標與底層 libc/allocator。

CI 應為兩種 build 分開產生鎖檔與測試證據，禁止在部署時臨時解析依賴。回滾也要回到完整環境組合，而不是只降一個套件。這種可重現性是 free-threading 從實驗走向生產的必要條件。

壓力測試要包含取消、例外與關閉流程

許多 concurrency bug 不會在正常成功路徑出現，而是在 timeout、task cancellation、interpreter shutdown、extension unload 或部分初始化後爆發。AI 服務常有長時間 GPU 工作，host thread 被取消時，資源與 callback 的生命週期更複雜。

驗收應反覆執行啟動與關閉、在高負載中取消請求、注入 extension exception、模擬 OOM 與 worker crash，並檢查 lock、file descriptor、GPU memory 是否回收。只有 steady-state benchmark，無法證明服務能安全營運。

執行緒除錯需要從偶發症狀回到事件證據

Race condition 往往只在特定核心數、負載與時序出現，重新啟動後就消失。平台要保存 thread dump、正在執行的 request、lock wait、extension stack 與最近的資源事件，並用 bounded ring buffer 避免日誌本身造成大量競爭。若只看到最終 segmentation fault，通常不足以判斷是哪個共享物件先失去一致性。

測試環境可以重複相同工作數千次、隨機改變 thread 排程與插入故障，搭配 address、thread 或 undefined-behavior sanitizer 檢查原生程式。Python 層則要為共享狀態建立 invariant，在每次更新後驗證。除錯目標不是追求一次成功重現，而是逐步縮小能觸發問題的最小並行序列。

資料隱私與租戶隔離不能因共享程序而退讓

少量程序共享模型可節省記憶體，卻也讓更多租戶資料同時存在於一個 address space。Thread-local context、暫存 buffer、exception 與 metrics label 若清理不完整，可能造成跨請求資料洩漏。過去用 process boundary 自然取得的隔離，改成 thread 後必須由應用與 runtime 明確補回。

多租戶推論應對 request context 做生命週期測試，禁止把敏感輸入寫入全域 cache，並在取消與錯誤路徑確認 buffer 歸零或釋放。若 workload 的信任邊界要求強隔離，就保留多程序甚至 sandbox；free-threading 是效能選項，不是推翻安全模型的理由。

從小範圍採用建立企業 free-threading 路線圖

第一階段先建立雙 build CI，完成 extension inventory 與最小 correctness suite；第二階段選一個 CPU-heavy、狀態單純且可快速回退的內部服務；第三階段才測共享模型、複雜資料管線與外部流量。每一步都要有基線、canary、觀察窗與停止條件。

成功指標應包括成本與可靠性，而不只是 benchmark speedup。若 throughput 提高但記憶體增幅使節點密度下降，整體成本可能沒有改善；若 extension 偶發重新啟用 GIL，效能曲線也會不穩。把模式偵測和相容性結果做成平台元資料，才能避免每個團隊重複踩坑。

基準測試必須控制 CPU quota、NUMA 與執行緒池

容器看到的邏輯 CPU、Kubernetes quota 與實際可持續使用的核心可能不同；若 benchmark 沒記錄 throttling，free-threaded build 增加執行緒後反而會把排程等待誤算成直譯器成本。多 socket 機器還要觀察 NUMA locality，因為共享 Python 物件、allocator page 與 tensor buffer 跨節點移動時，memory latency 可能抵消平行收益。

AI runtime 也常同時啟用 OpenMP、BLAS、tokenizer 與 PyTorch intra-op／inter-op thread pool。測試要逐層固定執行緒上限，先量單一 pool，再組合真實服務；否則 oversubscription 造成的 context switch 會讓結果不可解釋。最終報告應保存 CPU 型號、quota、affinity、NUMA、pool 設定與負載分布，並附上每次量測的暖機、持續時間與重複次數，才能讓後續版本重跑並辨識偶發噪音。

Sam Gross 留給 AI 基礎設施的核心方法

Sam Gross 的代表性不在於「刪掉一把鎖」，而在於把一個牽涉記憶體管理、ABI、套件生態與使用者體驗的長期限制，拆成可實作、可漸進採用、可回退的工程方案。PEP 703 與 PEP 779 的分階段治理，也讓大規模 runtime 變更有明確證據門檻。

對 AI 平台團隊而言，最值得學的是不要把上層易用性與底層效能當成必然衝突。先辨識真實工作負載的瓶頸，再調整 runtime 契約、補齊相容性與觀測工具，最後用可回復 canary 擴張。Free-threading 是否適合某個服務要靠量測，但它已把 Python 與多核心 AI 系統的設計空間真正打開。

延伸閱讀

若想把Python free-threading與AI運算平台的效能問題放在一起看，可以接著閱讀黃仁勳如何把GPU變成AI權力中心，對照硬體、runtime與開發者生態。

若要從 Sam Gross 以 PEP 703、free-threading 與 PyTorch 改寫 Python 執行效能，回到 Guido van Rossum 如何設計 Python 語言、可讀性與開放社群，可延伸閱讀 Guido van Rossum 如何讓程式碼更容易讀？Python、語言設計與開放社群，補上同一實體脈絡的延伸閱讀。

官方資料與延伸閱讀

• PyCon US 2023：Sam Gross 官方講者頁
• PEP 703：Making the Global Interpreter Lock Optional in CPython
• PEP 779：Free-threaded Python 正式支援條件
• Python 3.14 官方版本說明
• Python 官方 Free-threading HOWTO
• Sam Gross 的 nogil reference implementation
• PyTorch: An Imperative Style, High-Performance Deep Learning Library