Amazon Trainium 訓練憑原生 PyTorch 挑戰 Nvidia

Amazon 於 10 月 20 日推出 Trainium 的原生 PyTorch 支援，透過研究人員已在使用的工作流程，挑戰 Nvidia 在訓練軟件上的優勢。Amazon Trainium 訓練現已提供名為 TorchNeuron 的公開測試版後端，這是一個將 PyTorch 模型程式碼連接至 Amazon 加速器的軟件元件。PyTorch 是開發者用來定義、訓練及執行模型的框架。

這項轉變之所以重要，是因為訓練硬件競爭的不只是運算能力。研究人員需要修改模型、檢視故障，以及重複進行實驗，而毋須為陌生裝置重建軟件。Nvidia 的 CUDA 平台，即其加速運算的程式設計環境，仍是這類體驗的參考標準。

10 月 23 日 SemiAnalysis 的評估帶來令人鼓舞的實測證據，但同時指出編譯延遲及尚未完成的相容性。這場逐漸成形的競爭，關乎 Amazon 能否讓 Trainium 適用於日常研究。這並不代表 Amazon 已在各類訓練工作負載上超越 Nvidia。

Amazon Trainium 訓練獲得原生 PyTorch 路徑

Amazon 正在改變研究人員與其晶片之間的軟件契約。

AWS 的 TorchNeuron 公開測試版 支援 Trainium2 及 Trainium3 執行個體。該公司表示，開發者可選擇 neuron 裝置，同時保留標準 PyTorch 介面。它亦透過 Neuron Kernel Interface 支援自訂運算子，後者是 Amazon 用於編寫裝置專屬運算程序的介面。

這項發布處理了一項實際障礙：研究人員理解的模型，與他們必須遷就的硬件堆疊之間的距離。若要採用一款前景可觀的加速器，卻意味著要維護另一個版本的實驗，它的吸引力便會下降。

原生整合改變了遷就工作發生的位置。理想情況下，硬件後端會吸收更多裝置專屬工作，讓研究人員可更貼近現有模型定義。這讓 Amazon 更容易切入缺乏專責加速器專家的團隊。

措辭仍需審慎。原生支援描述的是整合方式；它並不保證每項操作、函式庫或工作負載都會有完全一致的行為。公開測試版亦意味著開發者應預期支援範圍會持續演變。

對研究團隊而言，有用的區分在於啟動實驗與維持研究計劃之間。啟動需要模型能夠載入及執行。維持則要求架構修改、除錯、評估及軟件更新都保持易於管理。

若這些後續工作不再需要付出異常大的努力，Amazon Trainium 訓練的競爭力便會提升。一次成功示範可以建立切入點。重複而平常的實驗，才決定這個切入點會否成為可靠的工作環境。

設想一個示例團隊正在修改語言模型的注意力機制，即決定哪些資訊會影響每次預測的元件。團隊需要把其修改與基準版本比較。硬件選擇不應變成另一個研究項目。

這個例子說明，這項發布的影響超越基礎設施專家。研究人員選擇工具，部分取決於這些工具讓他們可嘗試甚麼實驗。因此，硬件相容性會影響團隊在可用時間內能研究的問題。

對企業買家而言，含義同樣具體。採購比較應包括維持工作負載健康運作所需的工程工作。若軟件工作令實驗變得不切實際，裝置是否可用便意義不大。

因此，眼前的改變是更廣泛地邀請各方評估 Trainium。AWS 為這項評估提供了熟悉的介面。團隊會否留下來，取決於該介面底下的行為，尤其當其程式碼偏離預先準備的示範時。

Nvidia 在研究人員投入時間之處面臨壓力

競爭突破口在於轉移研究所需的工作量，而非單一硬件分數。

Nvidia 是這個故事中的主要對手，因為 Amazon 正在處理圍繞 GPU 訓練的軟件習慣。GPU 是為平行運算設計的處理器。研究人員會評估其周邊的整體工作環境，包括除錯、函式庫及團隊累積的知識。

這些投資構成留在現有平台的強烈理由。機構知道哪些故障屬於日常情況、哪些改動需要謹慎處理，以及內部專業知識所在之處。轉移硬件可能會動搖這種理解。

Amazon 的做法直接針對轉換負擔。若研究人員能保留熟悉的介面，他們在測試前便較少理由拒絕替代方案。即使買家尚未決定哪個平台表現更佳，這已是競爭優勢。

因此，對 Nvidia 的壓力是具體的。AWS 正嘗試令硬件評估對研究流程造成較少干擾。Nvidia 必須持續贏得那些獲得更易接觸替代方案的團隊之偏好。

這種壓力不應被誤解為即時遷移預測。實驗室可在保留現有 GPU 基礎設施的同時研究 Trainium。評估擴大了可選範圍，但未能確定最終會轉移多少工作。

TorchTitan 是 PyTorch 用於組裝大規模訓練工作流程的框架，提供了一個有用的參考點。其項目描述模組化模型定義及可配置的分散式執行，即將運算分布於多個裝置。這使它與正在調整既有訓練基礎的研究團隊相關。

策略價值在於保留這個基礎。團隊不希望每次硬件實驗都為其科學工作建立永久分支。實作越接近，結果便越容易比較。

這亦是為何推論成功不能自動證明適合訓練。推論是使用已訓練模型產生輸出。研究訓練則在開發者探索架構、資料及最佳化選擇時改變模型參數。

服務工作負載可從對穩定路徑的精心最佳化中受益。研究工作負載亦需要容忍變化。加速器必須支援供應商未有特別準備的實驗。

對買家而言，這意味著應以不同方式理解競爭。相關問題是，團隊憑現有員工及基礎設施能完成多少有用研究。硬件吞吐量有助達成這個結果，連同設定工作及診斷時間亦然。

若 Amazon 能減少這些額外負擔，便有可信的機會。只要 Nvidia 的工作環境能讓團隊更具生產力，它便會保有優勢。競爭結果將隨工作負載、軟件依賴關係，以及操作它們的人員專業知識而異。

這種差異令廣泛宣布誰是勝方為時尚早。它亦令這項發布意義重大：AWS 正在競爭研究人員的工作日，而硬件偏好正是在那裏變得持久。

原生 PyTorch 改變實驗迴圈

Amazon 挑戰背後的機制，是把修改模型程式碼至評估其行為的路徑縮短。

AWS 的 原生 PyTorch 後端 使用 PyTorch 的標準擴充機制，將 Trainium 註冊為裝置。其文件描述即時執行，即操作在開發者呼叫時執行；以及編譯執行，即軟件在運行前最佳化已擷取的運算。

這些模式服務於實驗中的不同時刻。當構想仍未定型時，互動式執行可協助開發者檢視行為。當運算趨於穩定，而重複執行值得額外最佳化時，編譯便變得吸引。

實際好處來自可在這些時刻之間轉換，而毋須放棄研究程式碼。研究人員可探索一項改動、確認它是否可行，然後檢視效能。支援這個次序的後端，符合實驗工作的實際進展。

AWS 的文件亦解釋，為何熟悉的執行方式並不消除編譯成本。首次出現的操作形狀可能需要在初次使用時編譯。快取結果可有助後續執行，但最初的等待仍是研究人員體驗的一部分。

這項細節將整合故事連接到剩餘的摩擦。模型在介面上可以感覺熟悉，卻在底層出現陌生的停頓。開發者在估計可節省多少迭代時間前，需要理解兩個層面。

從這個角度理解 TorchNeuron，它是責任的改變。更多調整移入後端，而研究人員保留更多熟悉程式碼。在覆蓋範圍或效能不足之處，裝置專屬工程仍然必要。

同一份文件區分了不同執行模式下的回退行為。在即時模式中，不受支援的運算子可在 CPU，即電腦的通用處理器上執行，並附帶警告。在編譯模式下，後端無法轉譯的操作則可能導致編譯失敗。

在評估一次成功執行時，這種區分十分重要。僅僅完成並不代表預期運算一直留在加速器上。實驗可運作與實驗獲有效加速，是兩項不同發現。

對一個示例研究團隊而言，評估應跟隨其實際進行的工作。標準模型建立基準。有意義的架構修改，則揭示相容性是否延伸至預先準備的路徑以外。

團隊其後可比較科學結果，以及取得這些結果所需的工作量。若修改後的實驗行為正確但需要大量修補，介面改進便只兌現了部分承諾。

Amazon 的軟件策略令這種評估較容易嘗試。其長期價值取決於後端處理研究人員所作雜亂改動的一致性。這正是原生整合與更廣泛訓練業務之間的連繫。

更易接觸的起點會擴大潛在用戶群。可靠的實驗迴圈則給予這些用戶繼續使用的理由。

品質控制必須涵蓋正確性與等待時間

訓練軟件透過保留結果，同時讓實驗可實際地重複進行，來贏得信任。

SemiAnalysis 的 Trainium 訓練測試 報告指出，在 16 枚 Trainium2 晶片上，Qwen3-32B 在即時模式的吞吐量為每秒 11,099 個 token，而在編譯模式則為 14,156 個。Token 是語言模型處理的文字單位。這些屬於特定工作負載的測量結果，並非與 Nvidia 的普遍比較。

該刊物亦報告，其 gpt-oss 訓練配方的編譯等待時間為 27 分 17 秒。其 Trainium3 FlexAttention 評估在 96 個案例中通過了 89 個；其餘案例超出編譯時間限制。FlexAttention 是用於定義注意力變化的 PyTorch 介面。

這些發現支持一個審慎的解讀。這個堆疊能執行實質的訓練實驗，但等待時間對研究可用性仍然重要。更快地重複執行，並不會抹去為達成該速度所花的時間。

這個區分對短期實驗尤其重要。測試某個想法的研究人員，可能更在意取得初步結果所需的時間。較長的運行則可將準備成本分攤到更多有用的運算上。

這意味著效能報告應分開列出準備、執行及成功完成的時間。將它們合併成一個有利的數字，可能掩蓋了決定研究人員會否繼續使用平台的那部分體驗。

正確性帶來另一項要求。模型即使運行快速，若其學習方式不同，也必須先進行調查，其速度才有價值。數值一致性意味著要檢查，在選定的精度及測試條件下，運算是否產生足夠一致的結果。

AWS 在其 TorchNeuron testing methodology 中描述了大量自動化測試。它表示，其模型掃描涵蓋 100,000 個採用精簡配置的 Hugging Face 模型，記錄執行、編譯及回退行為。這些均為供應商自行報告的覆蓋範圍聲稱。

同一份說明指出，8 月約有 154,000 項上游測試結果，其中約 69,000 項被跳過。部分跳過項目遵循 PyTorch 的資格規則；另一些則反映 Neuron 的覆蓋範圍決策。列出的初步排除項目包括稀疏運算及動態形狀。

持續整合，即對軟件變更進行自動化測試，在此十分重要，因為後端改進可能在其他地方引入回歸問題。一套有用的測試系統，會在研究人員於昂貴實驗中發現問題之前，先識別這些回歸。

單憑測試量無法證明可靠性。讀者需要知道哪些項目已運行、哪些被跳過，以及受測配置與其工作負載有多接近。廣泛的目錄掃描不能取代對每個列出模型進行完整訓練驗證。

最有力的證據，會結合透明的覆蓋範圍報告與可重現的外部結果。AWS 的披露提供了這種審視的材料。SemiAnalysis 的經驗則提供外部視角，包括原本可能被利好發布措辭掩蓋的問題。

Amazon Trainium 訓練值得從兩個層面評估：實驗能否正確完成，以及團隊能否在不過度延誤下重複進行。某一層面的進展，絕不應掩蓋另一層面的弱點。

Profiler 為 Amazon 提供另一種競爭方式

即使首次結果令人失望，對緩慢執行有更佳可見度，也能讓加速器更容易改進。

Neuron Explorer 是 Amazon 的剖析工具，這類軟件會記錄執行情況，讓工程師可調查效能。AWS 的 hardware profiling tools 區分系統層級活動與裝置層級活動。它們提供時間軸、原始碼連結、相依性資訊及記憶體檢視。

這些功能處理的是與相容性不同的問題。模型一旦運行，開發人員需要判斷它為何等待。緩慢的步驟可能反映運算、資料移動、通訊，或在加速器以外完成的工作。

總耗時能識別症狀；有用的追蹤記錄則有助找出原因。這項差異決定工程師能否作出針對性改動，還是只能透過反覆猜測來調查。

例如，一項示範性的訓練工作可能在運算得以繼續前，花時間等待資料移動。單純改善算術運算，並不會消除這項相依性。清晰的時間軸可將工程師重新導向真正限制進度的工作。

這就是為何剖析工具的品質應納入競爭分析。硬件規格描述可用能力；診斷工具則協助開發人員將這些能力轉化為其特定模型的實用執行效能。

它與原生整合的關係同樣務實。熟悉的模型程式碼可縮短達成初次運行的距離。清晰的剖析則可縮短從該次運行到解釋其行為的距離。

這些改進合在一起，處理了圍繞訓練的工程工作。它們並不保證帶來效能優勢，卻可讓團隊更容易發現這項優勢是否存在。

「GPU impossible」這個說法需要克制。SemiAnalysis 以此形容它對 Trainium 細粒度剖析體驗的熱情。這句話不應演變成 Nvidia 硬件缺乏任何方式觀察運算程序內活動的聲稱。

Nvidia 記錄了 in-kernel event tracing，這是一種用於記錄 kernel 內事件的機制；kernel 即在加速器上執行的例程。它的存在將可合理辯護的比較範圍，收窄至特定任務的整合、可見度及開發人員投入。

這仍是一項有意義的比較。兩個平台可以呈現相關資訊，卻需要不同程度的工作才能收集及解讀。相關判斷在於工程師需進行多少調查。

因此，買家評估剖析工具時，應使用一個尚未解決的真實效能問題。漂亮的截圖無法證明工具能多有效地協助團隊回答該問題。能產生可採取行動診斷的追蹤記錄，提供更強的證據。

分析亦應保留診斷與修復之間的界線。知道工作負載為何停滯，並不保證軟件或硬件能消除該停滯。更佳的可見度可改善決策，包括拒絕不合適平台的決策。

Amazon 的機會，在於讓這些決策更快且資訊更充足。這可加強其訓練主張，而無須每個工作負載都產生有利結果。

甚麼能證明一個可持續的訓練替代方案

下一輪證據應追蹤迭代時間、持續維護的相容性，以及超越已支援示範案例的採用情況。

未來數月的首個訊號，是初始編譯等待時間可重現地縮短。發布公告應配合同一批模型及具意義的架構變更，否則更快的結果可能反映的是不同實驗。

重要的成果，是更短的路徑通往可信賴的結果。若準備工作有所改善，而正確性及重複執行能力仍然相若，Amazon 的研究主張便會更有力。若等待時間在一般改動下仍持續存在，原生介面仍留下大量未解決的負擔。

這項評估應包括全新及重複運行。研究人員需要區分來自快取編譯結果的好處，以及有助於陌生工作負載的改進。兩者都重要，但它們回答的是日常可用性中不同的問題。

第二個訊號，是能經受軟件更新的相容性。發布時支援某個介面，只是建立起點。隨著研究工作改變，團隊需要模型、其相依項目及裝置後端能繼續協同運作。

應留意新支援運算、尚餘排除項目及回歸問題的透明報告。例外清單縮短，將加強 Amazon 正吸收更多適配工作的論據；若用戶程式碼需要反覆修復，則會削弱這一論據。

這正是將 TorchNeuron 視為開發策略，而非發布口號時更有價值的地方。它的價值取決於用戶隨時間可避免多少硬件專屬維護工作。介面只是這項承諾的開始。

第三個訊號，是來自執行多樣化訓練工作負載團隊的詳細報告。有用的說明應交代哪些內容被遷移、哪些需要調整，以及哪些仍保留在既有基礎設施上。它們也應區分日常供應商支援與例外的工程協助。

這些報告有助讀者判斷，這種體驗是否超越預先準備好的範例。獨立重現將進一步加強證據。一組狹窄的示範案例，會令實際採用的廣度仍然不明朗。

對不同讀者而言，影響各不相同。開發人員多了一個可與其實際實驗比較的環境。企業買家則有理由就遷移工作及維護提出更精確的問題。

AI 產品用戶應預期間接影響。更佳的基礎設施選擇，可影響產品團隊如何分配工程時間及推進模型改進。這項公告本身並未確立用戶所接觸應用程式會有任何特定改善。

對於關注這項轉變的團隊，應將基準測試設定、軟件版本及失敗說明連同有利結果一併保留。一個可搜尋知識庫可在下一次後端發布改變比較時，讓這些證據保持可用。

先從團隊熟悉的研究工作負載開始，再評估由程式碼變更至已驗證結果的完整路徑。記錄準備時間、執行行為、除錯工作及維護需要。讓比較始終連結到你打算重複進行的工作。Amazon Trainium 訓練現時提供更熟悉的評估途徑，而公開測試版亦讓更廣泛的受眾看見餘下缺口。把相容性披露與效能結果一併閱讀，然後隨軟件發展重新檢視決策。有用的問題是，你的團隊能否以現有資源完成更多可信賴的實驗。選擇能為你的工作負載證明這個成果的平台。