對於剛接觸大規模模型訓練的工程師來說，最容易陷入的誤區是認為只要「增加 GPU 數量」就能提升模型能力。早期的 Scaling Laws（規模定律）確實強調預訓練時的算力投入，但現代的基礎模型生命週期已經演進為三維度的規模化：預訓練（Pre-training）、後訓練（Post-training，如 SFT 與 RLHF）以及推理時算力（Test-time compute，如長思考與搜尋驗證）。
這意味著基礎設施的需求不再僅僅是單一的算力堆疊，而是一個由計算、網路、儲存儲、調度與可觀測性組成的複雜系統工程。
硬體基礎設施的三大支柱
要支撐千億級參數模型的運作，硬體層面必須解決三個核心瓶頸：計算吞吐量、記憶體頻寬以及節點間的通信延遲。
首先是加速計算。目前的趨勢是追求更高的 Tensor Core 吞吐量與更大的 HBM（高頻寬記憶體）。HBM 的重要性在於它決定了模型權重與 KV Cache（推理時儲存的鍵值快取）能存放多少，以及數據餵入計算單元的速率。例如 NVIDIA H100 到 B200 的演進，不僅是運算速度的提升，更重要的是 HBM 容量與頻寬的飛躍，這直接影響了模型能處理的上下文長度。
其次是網路通信。在分佈式訓練中，GPU 之間的數據交換（Collective Communication）往往比純計算更耗時。這裡分為兩個維度：Scale-up（向上擴展）利用 NVLink 提供節點內極高頻寬的 GPU 對 GPU 通信；Scale-out（向外擴展）則利用 EFA（Elastic Fabric Adapter）實現跨節點的 RDMA（遠端直接記憶體存取）。EFA 的關鍵在於 OS-bypass（繞過作業系統核心），讓數據直接在網卡與記憶體間傳輸，大幅降低延遲，這對於 MoE（混合專家模型）中頻繁的 All-to-All 通信至關重要。
最後是分層儲存。面對數 TB 的模型權重與檢查點（Checkpoints），單一儲存無法滿足需求。實務上會採用分層架構：本地 NVMe SSD 處理熱數據，FSx for Lustre 等並行檔案系統提供高吞吐的共享存取，而 Amazon S3 則作為最終的持久化儲存。
資源調度：Slurm 與 Kubernetes 的取捨
當你管理數千顆 GPU 時，手動分配資源是不可能的。目前主流有兩種調度路徑。
Slurm 是高效能運算（HPC）的標準，其核心優勢在於 Job-level Atomicity（作業級原子性）。也就是說，如果你申請 512 顆 GPU，Slurm 會確保這 64 個節點同時被分配給你，而不是一個一個慢慢到位，避免了分佈式訓練中常見的死結（Deadlock）問題。
Kubernetes 則是以 API 驅動的容器調度。雖然它在模型部署（Inference）上表現卓越，但在訓練上缺乏原生批處理隊列與拓撲感知能力。為了彌補這一點，社群開發了 Kueue 或 Volcano 等工具，用來實現 Gang Scheduling（幫組調度），確保所有必要的 Pod 同時啟動。
資源調度的目標是將硬體能力轉化為穩定的運算環境，並透過如 SageMaker HyperPod 等工具實現節點故障後的自動恢復（Auto-resume），減少人工干預。
ML 軟體棧的五層結構
從底層到頂層，軟體棧的配置決定了硬體利用率（MFU）。
第一層是硬體驅動，確保 GPU 與網路卡能高效協作（如 GPUDirect RDMA）。第二層是運算庫與編譯器，現代性能的突破往往來自於 FlashAttention 等融合內核（Fused Kernels），它們透過減少 HBM 讀寫次數來提升速度。
第三層是通信底層，最核心的是 NCCL（NVIDIA Collective Communications Library）。它根據拓撲結構自動選擇最優路徑（如 Ring 或 Tree 算法）來執行 All-reduce 等操作。
第四層是 ML 框架，如 PyTorch。工程師需掌握 DDP（分佈式數據並行）與 FSDP（完全分片數據並行）。FSDP 的重要性在於它將模型參數、梯度與優化器狀態分片到不同 GPU 上，讓單卡記憶體不足以承載的模型也能被訓練。
第五層是高階分佈式框架。追求易用性可選擇 Hugging Face Accelerate；追求極限性能則需使用 Megatron-LM 或 NeMo，實現 3D 並行（張量、流水線與專家並行）。
系統可觀測性：從監控到診斷
在大規模集群中，性能下降或訓練中斷是常態。可觀測性（Observability）的作用在於快速定位瓶頸。
基礎工具鏈通常是 Prometheus（數據採集）與 Grafana（視覺化）。但對 ML 工程師而言，關鍵在於監控指標的選擇。簡單的 GPU 利用率（Utilization）具有誤導性，應觀察 SM Activity（流處理器活動度）來衡量真實計算效率。
此外，硬體健康監控至關重要。透過 DCGM 監控 ECC 錯誤或 XID 事件（如 GPU 掉線），可以在硬體完全崩潰前主動將故障節點剔除並更換，避免整個訓練任務因單點故障而崩潰。
總結
基礎模型的規模化已不再是單純的算力競賽，而是計算、網路、儲存、調度與可觀測性的協同優化。任何一層的配置失誤（例如網路驅動版本不匹配或儲存吞吐不足）都會成為整個系統的瓶頸。理解這套分層架構，才能在面對性能瓶頸時，精準判斷問題出在算法策略、軟體棧配置，還是底層硬體限制。
來源：huggingface.co (Building Blocks for Foundation Model Training and Inference on AWS)
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。