輝達近日在官方開發者部落格上釋出了一項重要分析：即使採用完全相同的H100、GB200 NVL72或GB300 NVL72系統，不同AI計算叢集的實際訓練吞吐量也可能出現顯著差異。輝達團隊在與合作伙伴的部署實踐中發現，在相同工作負載、相同模型和相同全域性批次大小下，合作部署與輝達參考架構之間的效能差距通常在8%至12%之間。這一差距的根源並非單一硬體故障，而是核心、虛擬機器監控器、BIOS以及NVIDIA集體通訊庫等多層配置細節的累積效應，這些細節各自造成幾個百分點的損失，最終疊加起來足以使叢集無法達到輝達Exemplar Cloud驗證所要求的95%效能閾值。

部落格文章通過四個真實案例診斷，逐一剖析了不同層面的效能瓶頸。第一個案例聚焦於GB200 NVL72系統在虛擬機器環境中的表現：一個執行DeepSeek-V3混合專家模型FP8預訓練的合作伙伴部署，其迭代時間比裸機參考架構慢了12%至14%。分析發現，問題出在虛擬化層和系統記憶體管理單元配置上——Grace CPU的SMMU功能缺失及IOMMU行為不當導致了顯著的CPU開銷，尤其是在處理大量小核心的混合專家模型時更為突出。

第二個案例涉及x86架構下的CPU電源管理和非統一記憶體訪問配置。當CPU核心執行頻率低於預期的睿頻頻率，或者訓練程序的排名和輔助執行緒被錯誤地繫結到非最優核心或NUMA節點時，記憶體訪問延遲增加，整體吞吐量下降。輝達建議通過系統性地檢查CPU電源管理策略和NUMA/程序繫結來最佳化效能。

第三個案例揭示了高速網路上的通訊瓶頸。在採用ConnectX-8 SuperNIC等1.6 Tbps頻寬的架構中，如果NCCL佇列對併發數沒有根據實際網路規模和訓練工作負載進行調整，AllGather和ReduceScatter等集體通訊操作會出現嚴重的效能下降。這種問題往往在標準基準測試中不易察覺，但在大規模分散式訓練中會顯著拖慢進度。

第四個案例則是一個容易被忽視的配置問題：主機上的拓撲檔案和NCCL環境變數雖然在節點層面正確設定，但未能正確傳遞到容器化的訓練環境中。這導致訓練程序在容器內部無法獲取正確的拓撲資訊，從而在通訊路徑選擇上做出次優決策，造成“靜默”的效能損失。

輝達強調，這些效能差距很少來自單一的明顯故障，更多是多個配置細節在負載壓力下才暴露出來。對於AI基礎設施工程師和效能架構師而言，可以通過系統性地驗證SMMU和虛擬機器核心能力、最佳化CPU電源管理和NUMA/程序繫結、調整NCCL佇列對併發數，以及確保所有拓撲和環境變數在容器化訓練環境中可訪問，來縮小與參考架構的效能差距。這一分析為大規模AI叢集的部署和最佳化提供了實用的診斷框架，有助於提升算力投資的實際回報。