開發者現在可以在 SageMaker 上撰寫自己的 AI 訓練程式碼

AWS 正透過無伺服器訓練工作階段擴充 Amazon SageMaker AI，讓開發者無須佈建或操作 GPU 基礎設施，即可撰寫並執行自己的後訓練迴圈。這項功能是為需要自訂損失函數、獎勵訊號、偏好最佳化或多輪強化學習的團隊設計，而不是使用固定的微調流程。

這項變更移動了 SageMaker 的抽象化邊界。開發者仍然控制決定模型如何取樣、評分與更新的 Python 邏輯，而 AWS 則管理 GPU 配置、分散式執行、故障復原與檢查點儲存。對 AI 建構者而言，這在高度規範的託管式微調與直接操作訓練叢集之間，形成了一個中間選項。

AWS 透過兩篇 Machine Learning Blog 文章宣布這項能力。The AI Economy 也報導了這項發展，但目前可取得的通訊社稿件沒有額外的技術細節或獨立效能證據。

SageMaker 訓練工作階段的改變

傳統的託管式客製化服務通常要求使用者選擇模型、提供資料，並設定已知的訓練方法。這種做法能減少基礎設施工作，但當專案需要新的目標函數或客製化訓練順序時，可能限制研究人員與工程團隊。

SageMaker AI 訓練工作階段透過 SageMaker Python SDK 公開更低層級的操作。AWS 將 forward_backward()、optim_step() 和 sample() 等呼叫描述為建構模組，開發者可將它們組合成監督式微調、強化學習、偏好最佳化或其他程序。

工作階段會持續運作並保留狀態，選定的模型則在各項操作期間載入託管式加速器。開發者可以在本機執行 Python 程序，對工作階段發出操作、檢查結果並持續迭代，而不必先撰寫完整的叢集設定或建立獨立的分散式訓練工作。

AWS 表示，該服務目前支援監督式微調、直接偏好最佳化、使用可驗證獎勵的強化學習、基於 AI 回饋的強化學習，以及多輪強化學習等技術。使用者也能在 Low-Rank Adaptation 與完整微調之間選擇，然後透過連續客製化流程串接不同技術。

發布資料列出對 gpt-oss-20b、gemma-4-31B-it、Qwen3.6-27B 和 Qwen3.8-27B 等模型的支援。根據公司文件，可用性會因模型與 AWS 區域而異。

開發者控制的迴圈如何運作

在 AWS 的範例中，強化學習迴圈首先將提示傳送至託管式取樣服務。開發者的程式碼會使用驗證器、獎勵模型、測試工具或其他環境，評估產生的回應。接著，它將分數傳送至訓練服務，由 AWS 管理的 GPU 執行梯度計算與最佳化器步驟。

程式碼可以使用更新後的權重重新整理取樣器，並重複整個週期。這種結構對代理程式開發者很重要，因為獎勵可能取決於多次工具呼叫或互動，而不是單一回應。預訂旅程、解決支援案件或執行研究工作的代理程式，可能要經過多輪後才能評估。

AWS 使用 Group Relative Policy Optimization 說明這種方法：針對同一提示產生多個回應，透過獎勵函數比較，並用來更新模型。公司也介紹了涉及 GSM8K 數學問題與競賽程式設計的 cookbook 範例，其中產生的程式碼會透過單元測試進行評估。

對監督式微調而言，可以在不使用取樣與獎勵階段的情況下採用相同的原語。開發者可將交叉熵損失套用到標記資料。AWS 表示，訓練工作階段啟用時，模型會留在託管式 GPU 上；迴圈控制、資料處理、獎勵邏輯與其他應用程式碼則可留在開發者環境中。

證據、定價與主張的限制

產品的核心細節來自 AWS 自己的技術公告，因此它們只能證明供應商聲稱服務能做什麼，不能提供服務在所有工作負載中改善模型品質或降低總成本的獨立證據。

AWS 表示，客戶是按照處理的 token 計費，而不是按照保留的 GPU 容量計費。公司稱，當獎勵函數在客戶環境中評分一個批次時，計費表會暫停。AWS 將此描述為具有潛在優勢，因為對於評估速度較慢、工具使用複雜或需要人工審查的工作負載，開發者在這些階段不必為閒置的加速器付費。

這種定價模式可能讓實驗更容易比較，但實際經濟效益將取決於 token 數量、生成長度、獎勵計算、儲存、資料傳輸，以及達到有用模型所需的迭代次數。提供的資料沒有與自我管理 GPU 進行一般成本比較。

公司也表示，工作階段支援檢查點與恢復、租戶隔離和故障復原。資料與檢查點會保留在客戶控制的 Amazon S3 位置，並可選擇設定 AWS Key Management Service 與 virtual private cloud。AWS 聲稱客戶資料與客製化權重不會用於訓練其他模型，但在來源資料中，這是供應商的政策聲明，而不是經過獨立稽核的結果。

AWS 引用了 ImagineSoftware 的客戶評論，以及另一個未具名客戶的案例，該案例涉及 gpt-oss-20b 與 Amazon Neptune 知識圖譜。這些敘述描述了細緻的控制與可靠的檢查點恢復，但它們是 AWS 提供的客戶證據，不是中立的基準測試或廣泛採用研究。目前可取得的 AI Economy 報導也沒有提供進一步佐證。

這項發布對 AI 建構者的重要性

最重要的受眾並不是所有微調使用者。使用標準流程的團隊可能會覺得傳統的託管工作更簡單。當演算法本身就是產品時，訓練工作階段會更有用，例如測試新優勢估計器的對齊研究人員、設計跨工具呼叫獎勵的代理程式團隊，或從低階訓練框架遷移程式碼的 ML 工程師。

這項功能可能降低這些實驗的營運成本。團隊不再需要決定如何放置 GPU、同步梯度、復原失敗的工作程序，或為每次推出維護獨立的推論服務。這可能讓較小的團隊在保留資料課程與評估邏輯控制權的同時，測試更具企圖心的後訓練方法。

但這也有取捨。將基礎設施移出開發者程式碼，並不會消除設計可靠獎勵函數、防止獎勵駭客攻擊、選擇評估資料，或判斷改進是否能超越基準測試泛化的難度。此外，這可能產生對 SageMaker 支援的模型、SDK 操作、區域與定價模式的新依賴。

對企業而言，治理細節非常重要。AWS 表示，團隊可以使用 IAM 執行角色、S3 儲存、KMS 金鑰、VPC 設定、針對準確性、偏差與安全性的部署前評估，以及透過 Amazon CloudWatch 進行部署後監控。這些控制措施可能協助組織將客製化訓練納入既有流程，但買方仍需針對自己的區域與工作負載，驗證資料駐留、存取邊界、可稽核性與營運支援。

競爭層面的影響同樣明確。雲端供應商正日益嘗試同時提供易用性與訓練迴圈存取權。SageMaker 的定位不只是「託管式微調」，而是為客製化演算法提供託管式執行。它位於完全託管的模型客製化服務，以及 Amazon SageMaker Training Jobs 或 Amazon SageMaker HyperPod 等由客戶承擔更多基礎設施責任的服務之間。

接下來值得關注的事項

第一個訊號將是更廣泛的模型與區域支援。此次發布列出四個支援的基礎模型，但服務對生產團隊的實用性，將取決於清單擴展的速度，以及客戶能否帶入已經使用的開放權重模型。

定價透明度也很重要。AWS 說明了以 token 為基礎的計費方式，但如果能提供監督式微調、長時間代理程式推出，以及需要大量本機運算的獎勵函數等詳細範例，將有助於買方把服務與保留或隨需 GPU 基礎設施進行比較。

建構者應關注訓練品質、收斂、故障復原與端到端成本的獨立評估。AWS 的範例展示了程式設計模型，但沒有證明訓練工作階段能產生比現有框架更好的模型。

最後，實際考驗在於團隊能否在不失去可觀測性與安全控制的情況下，從實驗走向部署。只有當產生的模型能像透過較傳統 SageMaker 工作流程訓練的模型一樣可靠地接受評估、治理、版本管理與監控時，支援自訂迴圈才真正有用。

Creati.ai 觀點

SageMaker 訓練工作階段解決了 AI 開發堆疊中的一個實際缺口：許多團隊想要改變學習程序，卻不想成為 GPU 基礎設施營運者。AWS 在保留託管式執行的同時公開訓練操作，讓客製化後訓練更容易取得，但沒有假裝演算法設計已經變得簡單。

評估這項發布時，重點不應只是撰寫 Python 迴圈的新奇性，而應放在營運成果上：可重現的實驗、可預測的 token 成本、穩健的獎勵評估，以及從客製化訓練走向受治理生產部署的可信路徑。AWS 已透過自身技術資料確立服務的能力；市場仍需要針對這些成果的獨立證據。