核心概念

Hugging Face 與 AWS 合作發布的這篇技術文章，系統性梳理了在 AWS 上進行基礎模型訓練與推論所需的四個基礎層次。文章的核心論點是：基礎模型的規模化現在橫跨三個不同的訓練階段——預訓練（pre-training）、後訓練（SFT/RL，如 RLHF、DPO）、測試時計算（test-time compute）——而這三個階段都需要相似的底層基礎設施：緊密耦合的加速器、高頻寬網路，以及分散式儲存系統。

理解這四層架構的關鍵不在於每一層本身，而在於它們的相互依賴性：任何一層的配置錯誤（驅動程式、網路、儲存）都可能成為訓練效能的瓶頸，即使其他層都已優化也於事無補。這也是為何大型 AI 實驗室的基礎設施工程師，需要具備跨越硬體、系統軟體和 ML 框架的全棧診斷能力。

關鍵要點

第一層：基礎設施（算力、網路、儲存）

  • 算力：AWS EC2 P 系列實例（P5、P5e、P6）配備 NVIDIA H100、H200、Blackwell B200/B300 GPU，是主力訓練硬體
  • 網路：Elastic Fabric Adapter（EFA）提供 OS bypass RDMA，EFA v3/v4 比前代延遲降低 18-35%；高頻寬低延遲網路是分散式訓練的關鍵限制因子
  • 儲存：三層設計——本地 NVMe（最快，揮發性）+ Amazon FSx for Lustre（並行檔案系統，適合訓練資料集）+ S3（持久性，適合 checkpoint 與模型保存）
  • 規模擴展：EC2 UltraClusters 和 EC2 UltraServers 可以將 NVLink 域（原本限於單台機器）延伸到跨機器規模

第二層：資源編排（Orchestration）

  • Slurm：HPC 傳統主力，支援 job 層級原子性、拓撲感知排程、透過 GRES 管理 GPU 資源，適合需要明確資源保證的訓練作業
  • Kubernetes：宣告式方式管理，但需要額外擴充（Kueue、Volcano、NVIDIA KAI Scheduler）才能實現 gang scheduling 和拓撲感知排程
  • AWS 託管服務：ParallelCluster、AWS PCS、Amazon SageMaker HyperPod，後者提供 checkpointless training（節點故障時無損恢復）和彈性擴展

第三層：ML 軟體棧（五層）

  1. 硬體啟用層：GPU 驅動、GDRCopy、EFA 驅動、Lustre 客戶端
  2. 加速器運行時：CUDA、自訂 kernel（FlashAttention、Triton、CuTe）
  3. 通信層：NCCL + aws-ofi-nccl 外掛（讓 NCCL 使用 EFA 而非標準 TCP）
  4. ML 框架：PyTorch（DDP、FSDP2）和 JAX
  5. 分散式框架：Hugging Face Transformers（通用）、NVIDIA Megatron Core（大規模並行）、veRL（RLHF）、vLLM 和 SGLang（推論）

第四層：可觀測性（Observability）

  • 核心組合：Prometheus（指標收集）+ Grafana（視覺化）
  • AWS 託管版本：Amazon Managed Service for Prometheus + Amazon Managed Grafana（省去自行維運）
  • 關鍵指標：DCGM-Exporter（GPU 健康、溫度、使用率）、EFA 流量統計、訓練吞吐量（tokens/second）、主動故障偵測

實務意義

這份文件的定位不是教學，而是工程師在做 AI 基礎設施決策時的地圖。幾個值得特別注意的實務含義：

NCCL + aws-ofi-nccl 是隱藏關鍵：大多數教學只談 NCCL，但在 AWS EFA 環境中，如果沒有正確安裝 aws-ofi-nccl 外掛，NCCL 會 fallback 到標準 TCP，通信頻寬大幅下降，且幾乎不會有明確的錯誤訊息，只是訓練速度莫名其妙偏慢。

Slurm vs Kubernetes 的選擇：Kubernetes 在通用 DevOps 場景佔主流，但在大規模 GPU 訓練中，Slurm 的資源保證模型（全部資源就緒才啟動）更適合 gang scheduling 的需求。兩者並不互斥，許多大型 AI 實驗室用 Kubernetes 管理推論，用 Slurm 管理訓練。

三個訓練階段共用基礎設施：預訓練、後訓練（SFT/RLHF）、測試時計算（如 chain-of-thought search）過去被視為不同類別的工作，但它們的底層需求收斂。這意味著一套好的基礎設施設計可以在整個模型開發週期複用，而不需要為每個階段客製化不同的計算環境。

延伸觀點

搜尋延伸文章後，有三個在多個來源中共同被強調的觀點：

1. EFA 網路的端到端配置成本遠高於硬體採購：包含 HuggingFace 自有的 H200 cluster 部署經驗與 AWS 官方案例，都指出 EFA 的正確配置（OS bypass 參數、NUMA 綁定、MTU 設定）是真正耗時的部分，而非硬體本身。aws-ofi-nccl 版本與 NCCL 版本的相容性問題是常見的無聲效能殺手。

2. 觀測性（Observability）正從可選項變成必要項：早期 GPU cluster 訓練失敗的主要原因是硬體故障，現在更多是「軟性故障」——某個節點的通信頻寬下降 10%，或某顆 GPU 的 SM 使用率偏低，這些問題在沒有 DCGM + 完整指標管線的情況下幾乎不可能診斷。這與 Microsoft NSDI 2026：分散式系統與 AI 交匯的前沿突破 中強調的可觀測性優先原則一致。

3. 推論基礎設施與訓練正在收斂：vLLM、SGLang 等推論框架的出現，讓「訓練一套基礎設施、推論另一套」的分離模式開始鬆動。vLLM V0 升級 V1：強化學習訓練的後端正確性優先原則 記錄了 RL 訓練如何直接使用 vLLM 作為推論後端，這讓訓練與推論的基礎設施邊界進一步模糊。

相關頁面：Stargate 計畫：OpenAI 打造智能時代算力基礎設施 | MRC 超算網路協議：OpenAI 的多路徑可靠連接技術 | OpenAI 入駐 AWS Bedrock：GPT 模型、Codex 與託管代理三合一整合 | Microsoft NSDI 2026：分散式系統與 AI 交匯的前沿突破 | vLLM V0 升級 V1：強化學習訓練的後端正確性優先原則

反向連結

以下頁面引用了本頁：