2026 年 10 月 23 日（UTC；UTC+8 為 10 月 24 日），Kimbo Chen 與 Dylan Patel 在 SemiAnalysis 發布了〈Amazon’s Trainium Takes a Strike at the Training King〉。這份 Trainium 訓練測試最值得追問的，是暖機後的速度提升，能否抵過研究者每次改模型後的等待。
先看作者實際觀察到什麼，再用官方文件拆解等待的原因，最後算一筆短實驗的時間帳。這次新增的是第三方測量；TorchNeuron 的原生後端公告，可先讀 先前的 TorchNeuron 解析。
Trainium 訓練測試：1.28 倍，究竟比的是誰？
SemiAnalysis 使用官方 TorchTitan 映像，在 16 顆 Trainium2、LNC=2、共 64 個邏輯核心上訓練 Qwen3-32B，報告如下結果。這些是該團隊的觀察，AlphaLab 未在 Trainium 執行或重現。
| 模式 | 作者報告的訓練吞吐量 | MFU | 首步時間 |
|---|---|---|---|
| eager | 11,099 tokens/s | 23.89% | 184.6 秒 |
| compiled | 14,156 tokens/s | 30.47% | 255.7 秒 |
a 1.28x throughput improvement over eager mode.
中文：相對 eager 模式，吞吐量提高至約 1.28 倍。
SemiAnalysis 原文節錄，2026 年 10 月 23 日 UTC
比較對象是同一測試的 eager 模式。14,156 ÷ 11,099 約為 1.275；它不是相對 NVIDIA 的速度倍率，也不能直接換成訓練總時間少 28%。MFU 是模型有效運算相對理論運算能力的利用程度，要與模型、精度及計算口徑一起讀。
兩種時鐘：跑起來的速度，與第一次看到結果的時間
作者另在 GPT-OSS 20B 配方記錄了 27 分 17 秒的編譯等待；那是另一個模型，不能接到上表當作 Qwen3 的啟動時間。其核心判斷是：可沿用研究習慣的方向值得肯定，首次等待仍會妨礙架構實驗。
這個摩擦有官方機制可核對。AWS 的 TorchNeuron 架構文件說明，eager 會把算子編成 Neuron 執行檔（NEFF）；首次遇到新形狀可能編譯，後續才使用快取。eager 描述的是運算派送與開發方式，不能直接解讀成零編譯。
TorchTitan Neuron 文件也直接列出首步可能花數分鐘、編譯路徑要求固定形狀，以及持久快取的重用條件。實驗改了序列長度、批次大小或相關配置，就可能再次付出編譯代價。這些是 2026 年 10 月 26 日查閱的現行文件，不是對原文未列版本的補填。
PyTorch 的編譯時間指南同樣區分首次成本與後續執行，也提醒重編譯會再次收費。這是圖編譯普遍要管理的代價；至於哪一套後端最適合你的研究節奏，要看實際回合長度。
不只是一張速度表：相容性、數值與診斷工具
原文還報告 Trainium3 的 FlexAttention 測試為 89／96 通過，七項失敗歸因於編譯逾時；並展示矩陣乘法、品質測試與 Neuron Explorer。作者讚賞診斷體驗，也期待後續縮短等待；這些觀察與期待，仍要各自驗收。
這張圖適合問「哪一類矩陣形狀值得調校」。單一運算的利用率，並沒有把資料讀取、反向傳播、跨裝置通訊與啟動時間全部包進來。把其中一段曲線的領先擴大成整個模型更快，會跳過真正的工作流程。
診斷工具的價值則可以問得更具體：能否定位哪個運算在等資料、哪段通訊沒有和計算重疊？Neuron Explorer 官方入門區分框架／系統層與裝置指令層的追蹤。這支持可觀測性的用途，並不足以直接支持某家工具「全面優於所有 GPU 工具」的排名。
數值也要單獨檢查。PyTorch 的數值精度說明指出，浮點運算順序與後端差異會影響結果。測試能執行、張量誤差合理、loss 曲線一致，以及最後達到同樣品質，是不同層次；一次小測試不能替整條訓練曲線交卷。這也呼應 softmax 數值誤差分析裡的問題：算得快之前，先知道自己算對了什麼。
Trainium 訓練測試的時間帳：何時才能賺回多等的 71.1 秒？
先做一個純算術示例。假設兩模式每步都處理 65,536 tokens、上述吞吐量代表首步之後的穩態速度，且每個後續步驟沒有額外讀檔、同步或重編譯等待。65,536 是本文選的假設值，並非原文公開的每步配置；下表不是新增實測。
在這些假設下，eager 後續每步約 5.905 秒，compiled 約 4.630 秒；compiled 的首步卻多等 255.7 − 184.6 = 71.1 秒。若總步數為 N，估算式是 總時間＝首步時間＋（N−1）×每步 tokens÷穩態 tokens/s。首步已包含一次工作，因此後面用 N−1。
| 假設的總步數 | eager 估算總時間 | compiled 估算總時間 | 這組假設的結果 |
|---|---|---|---|
| 20 步 | 約 296.8 秒 | 約 343.7 秒 | eager 較早結束 |
| 100 步 | 約 769.2 秒 | 約 714.0 秒 | compiled 較早結束 |
依同一公式，compiled 約到第 57 個總步驟才抵過額外首步等待。57 是此示例的回本點，不是 Trainium 的通用門檻。改變每步 token 數、快取命中、架構或重編譯次數，答案就會變；真正測量時，直接用同步後的端到端時間核對。
這也解釋為什麼「穩態快約 28%」與「短實驗較慢」可以同時成立。若只跑少量步驟就決定下一個假設，等待占比很高；若配置固定、連跑很久，較快的後續步驟才有更多機會攤平前面的代價。
AlphaLab 的判讀：值得肯定的進展，與尚待交付的答案
一、我同意把研究迭代當成獨立的驗收目標
研究者常常不是要把同一模型永遠跑下去，而是想今天多排除幾個錯誤想法。能修改模型、順利除錯、早點看到可判讀的 loss，會影響實驗產量。原生 PyTorch 入口能降低一些摩擦；是否真的多完成有效實驗，要把每次冷啟動與失敗回合都記進去。
二、我存疑把短測吞吐量外推成硬體勝負
這份材料能支持「這個配方值得繼續測」，卻還不足以決定不同晶片的全面排名。採購比較要固定模型品質與工作量，對齊實例、精度、資料、版本與成本。尤其不要把 Trainium2 訓練表、Trainium3 單核心矩陣圖，拼成同一場 GPU 對決。
三、下一版編譯器的承諾，要用完整實驗回合對帳
若未來首步真的縮短，最有價值的證據是同一套實驗在新舊版本下，冷快取、暖快取、改架構三種情境的總時間都可比較。只展示快取命中後的漂亮速度，回答不了研究者第一次改模型要等多久。反過來，一次冷啟動慢，也不該抹掉長時間固定工作負載的潛在收益。
發布狀態也要放對時間軸：AWS 在 10 月 20 日公告 TorchNeuron public beta；10 月 23 日是本文所讀第三方測量的發布日。測試版的存在與原生 API 路線可以核對，某個後續優化是否已交付，則應另看版本與可重跑結果。
下一步：把「多久知道這次實驗有沒有用」寫進測量表
已有授權 Trainium 環境的團隊，可選一個範圍小的訓練配方，保留一組現有平台基準；先定品質與數值容忍，再測冷啟動、同配置重跑、一次明確架構修改。尚無環境時，先整理自己實驗的步數分布與可重用配置，不必為追一個倍率先租整座機櫃。
| 保留哪一項 | 它回答什麼 |
|---|---|
| 精確版本、模型、dtype、序列長度、batch、LNC 與切分 | 下一次比較是否仍是同一份工作？ |
| 首個有效結果時間、穩態吞吐與端到端總時間 | 速度提升是否真的縮短實驗？ |
| 冷／暖快取、重編譯次數與 trace | 時間改善來自哪一段？ |
| loss、梯度檢查、失敗重跑與完整帳單 | 是否以相同品質完成，代價是多少？ |
品質門檻可用 AI Evals 的驗收方法補齊；跨硬體數字的口徑，可對照 TorchTPU 的 MFU 與弱擴展解析；效率倍率則可接著看 MAI-Base-2 預訓練效率分析。這些比較方法的共同用途，是讓漂亮數字回到同一個工作目標。
Trainium 這次值得追蹤的，是從「能啟動」走向「能順手做研究」的距離。下次再看到更高 tokens/s，先追問：改完模型後，多久能得到同樣可信的結果？這個答案，才決定它能不能成為你的日常研究工具。
接著閱讀
左右滑動查看更多推薦