兩套由相同NVIDIA H100、GB200 NVL72或GB300 NVL72系統構建的AI計算集群，在訓練吞吐量上可能存在顯著差異。實際測試中，合作夥伴部署與NVIDIA參考架構（RA）在相同工作負載、相同模型、相同全局批次大小下，性能差距通常在8%至12%之間。
這一差距的根源往往是核心、虛擬機管理程序、BIOS以及NVIDIA集合通信庫（NCCL）配置層面的多項設置疊加所致，每項各損失幾個百分點，累積後可能導致最終性能低於NVIDIA Exemplar Cloud認證所要求的95%門檻。
本文將梳理來自真實合作夥伴集群的四個調試案例，每個案例聚焦於不同的技術層面：NVIDIA Grace CPU上的系統內存管理單元（SMMU）與頁表行為、基於x86 CPU的電源管理與非統一內存訪問（NUMA）配置、1.6 Tbps網路中NVIDIA NCCL隊列對並發，以及硬體安裝的隱性缺陷。文章同時給出了通過perf、NVIDIA Nsight Systems或NCCL測試定位根因的具體信號，以及縮小差距的調優方案。
復現上述診斷過程，需要以下條件：
配備NVIDIA Quantum InfiniBand或RoCE互聯的NVIDIA HGX H100、HGX H200、HGX B200、GB200 NVL72或GB300 NVL72系統集群；疊代時間穩定的分布式訓練工作負載，可參考NVIDIA NeMo在Llama 3模型、NVIDIA Nemotron或DeepSeek
配置上的運行結果；至少一個節點的root權限，用於perf、BIOS/UEFI更改和核心參數修改；與訓練框架使用相同NCCL版本編譯的nccl-tests、NVIDIA Nsight Systems，以及支持核心符號的Linux perf工具。
近期Exemplar訓練項目的經驗表明，性能差距很少源於單一的明顯故障，更多來自工作負載壓力下才會暴露的配置細節。常見問題模式包括：
Grace與虛擬化就緒性：平台能力缺失、SMMU開銷、IOMMU行為或頁面大小設置與預期配置不符；CPU電源與進程放置：核心運行頻率低於預期的Turbo頻率、進程或輔助線程分配到錯誤的核心，或NUMA/PCT綁定與平台拓撲不匹配；運行時拓撲：主機拓撲文件或NCCL設置在節點上正確，但在工作負載容器或啟動器環境中缺失；網路與集合通信行為：NCCL設置與目標網路、消息大小或訓練工作負載規模不匹配；應用程式與平台綁定：訓練進程按核心ID或rank順序綁定，而非基於拓撲感知的親和性配置。
以下四個案例展示了上述問題在近期訓練工作中的具體呈現方式。
案例一：虛擬化與SMMU層
某合作夥伴的GB200 NVL72集群在虛擬機內運行DeepSeek-V3混合專家（MoE）FP8預訓練，疊代時間比裸機參考架構長12%至14%。在此之前，Llama 3 70B等稠密模型的預訓練性能與RA差距在3%以內，而每次疊代調用大量小型核心的DeepSeek-V3 MoE成了例外。
在合作夥伴集群上採集的Nsight Systems追蹤顯示，工作負載中小型核心區域的CPU開銷明顯偏高。針對單線程CPU性能的微基準測試表明，合作夥伴與RA集群節點的性能幾乎相同。進一步在主機上執行30秒的`perf record -a -g`並通過`perf report`查看，發現一個異常的頂層函數：24%的CPU周期花費在`arm_smmu_cmdq_issue_cmdlist`上。
該函數負責向Arm SMMU的命令隊列提交無效化命令。在虛擬化環境下，每次導致訪客無效化的map/unmap操作都會觸發主機陷入，並通過單一命令隊列串行化處理，從而產生配置文件中可見的自旋鎖競爭。虛擬命令隊列（VCMDQ）是標準Arm SMMUv3命令隊列虛擬化擴展提供的一項功能，允許訪客直接向硬體發送SMMU無效化命令，無需觸發虛擬機退出。
解決方案：在合作夥伴集群的主機核心中啟用CMDQV/VCMDQ，並將其暴露給訪客。這需要核心包含tegra241-cmdqv驅動以及相應的虛擬機管理程序支持；近期版本的QEMU/libvirt已添加cmdqv IOMMU屬性，可將其暴露給訪客。
應用此變更後，Linux perf顯示`arm_smmu_cmdq_issue_cmdlist`不再出現在頂層函數中，dTLB缺失率也恢復到與裸機相當的水平。MoE疊代時間差距從12%收窄至RA容差範圍內。
經驗總結：基於Grace架構的虛擬化部署，需要VM棧為內存映射密集型工作負載暴露正確的SMMU能力。在主機核心中啟用CMDQV/VCMDQ並暴露給訪客後，平台可以避免不必要的SMMU串行化，將MoE訓練性能恢復至RA容差範圍內。
案例二：CPU電源與進程放置層
某合作夥伴的H100 SXM5集群使用與NVIDIA HGX參考架構相同的NCCL版本和NeMo容器，但運行Llama 3 70B預訓練時比參考速度慢12%。與GB200 NVL72的案例不同，這不是核心層面的問題，而是用戶空間和BIOS配置導致的。
發現了兩個異常：其一，在訓練期間用`turbostat -i 1`監測，繁忙核心被鎖定在3.0 GHz，儘管該型號支持3.8 GHz的Turbo頻率；空閒核心同樣處於3.0 GHz，C狀態停留在C1而非下降至C6。其二，`numastat -p
根本原因：合作夥伴集群在BIOS中將C狀態限制為C1，這是一種常見的"低延遲"默認設置，但對AI訓練工作負載而言適得其反。空閒核心被維持在C1狀態，持續消耗封裝功耗；向GPU提供核心的繁忙核心無法獲得足夠的封裝功耗預算，因此無法達到Turbo頻率。允許空閒核心降至C6可釋放功耗餘量，使繁忙核心攀升至3.8 GHz，在本工作負載上恢復約4%的性能。
此外，虛擬機管理程序的內務線程與訓練進程的數據加載工作線程被固定在相同的物理核心上。在虛擬機內部，這表現為Python線程出現零散的50至100毫秒卡頓，進而形成步驟時間的長尾效應。修複方案是通過cpuset分離：虛擬機管理程序和主機服務使用第0至7核與第56至63核，訓練進程使用其餘核心。
結果：12%的差距收窄至3%，剩餘差距可追溯到下一個案例中涉及的NCCL調優問題。
案例三：ConnectX-8 SuperNIC集合通信調優
某GB300 NVL72部署配備了NVIDIA ConnectX-8 SuperNIC（每節點1.6 Tbps），在Nemotron-4 15B預訓練上呈現31%的訓練性能差距。單節點吞吐量表現正常，差距在512 GPU規模時出現，此時分析器顯示AllGather和ReduceScatter時間明顯暴露。這將問題指向ConnectX-8網路上的集合通信路徑，而非計算本身。
調查通過NCCL Tests（nccl-tests）測試了多個變量，包括疊代次數、UCX/UCC行為、NUMA映射、NVLS和NCCL版本等。對該工作負載網路性能而言，關鍵調優變更更為具體：將`NCCL_IB_QPS_PER_CONNECTION`從默認值1提高至4。
Nsight Systems追蹤顯示，在較低QPS值下通信開銷明顯暴露，導致訓練疊代時間延長。在工作負載和nccl-tests集合測量中均可觀察到相關信號。在NVIDIA參考集群上，默認配置每次疊代約為1.09秒；QPS設置為4後，相同參考工作負載改善至約0.83秒。在性能分析中，AllGather時間從約375毫秒降至262毫秒，ReduceScatter從約389毫秒降至273毫秒。
經驗總結：不應盲目提高QPS。QPS取決於網路和工作負載類型。在此GB300 ConnectX-8工作負載上，QPS=4改善了大消息AllGather和ReduceScatter的行為。在其他網路或消息大小場景下，相同設置可能增加CPU開銷而不提升訓練吞吐量。正確做法是在工作負載的真實消息大小下測試集合通信，在目標網路上掃描該參數，並在訓練工作負載中驗證結果。
案例四：拓撲文件缺失導致的容器環境配置問題
在某虛擬化B200部署中，即使主機上的nccl-tests顯示性能正常，訓練吞吐量仍比NVIDIA參考低13%至53%。在enroot工作負載容器內，AllGather和ReduceScatter慢了2至4倍，調查方向從網路健康狀態轉向對比虛擬機與訓練作業內NCCL拓撲配置的可見性差異。
主機（虛擬機）設置了`NCCL_TOPO_FILE=/etc/nccl/topo.xml`，且對應文件存在；而容器（enroot）中該環境變量未傳播，`/etc/nccl/topo.xml`也未掛載，導致NCCL回退至自動檢測，最終性能低於參考13%至53%。
經驗總結：檢查應在與運行基準測試相同的容器、啟動器和Slurm分配內執行，而非在主機上操作。在作業容器內運行`echo $NCCL_TOPO_FILE && cat $NCCL_TOPO_FILE`是最快速的健全性檢查。如果路徑無法解析，NCCL會靜默失敗且不報錯，這使其成為最難診斷的差距之一，除非知道問題所在。
修復摘要
當集群性能低於NVIDIA參考架構規格時，以下檢查有助於在全規模工作負載調優前排除常見平台問題：虛擬化環境確認啟用CMDQV/VCMDQ；CPU配置確保C狀態可降至C6；檢查NUMA/PCT綁定與平台拓撲的一致性；確認NCCL_IB_QPS_PER_CONNECTION設置與目標網路匹配；驗證容器內NCCL拓撲文件已正確掛載且環境變量已傳播。
雲訓練部署與NVIDIA參考架構之間的性能差距通常是累積性的：CPU電源設置損失幾個百分點，NUMA或PCT綁定再損失幾個百分點，缺失的核心能力、容器可見拓撲或網路配置也會逐項疊加。提前解決這些問題有助於避免代價高昂的全規模調試。
需要注意的是，預檢診斷並不能保證通過Exemplar Cloud認證。某些問題只有在驗證工作負載本身運行時才會出現，精確到模型、精度、拓撲、容器、啟動器和網路條件。實際目標是儘早消除已知的平颱風險，再利用訓練工作負載追蹤來調試只有在規模化場景下才出現的差距。
Q&A
Q1：NVIDIA Exemplar Cloud認證對性能有什麼要求？
A：NVIDIA Exemplar Cloud認證要求合作夥伴部署的性能達到參考架構的95%以上。常見情況是，CPU電源管理、NUMA綁定、核心能力缺失、容器拓撲配置以及網路設置等多項因素累積疊加，導致性能低於這一門檻。通過逐層排查並修復這些配置問題，可以將差距縮小至認證允許範圍內。
Q2：NCCL_IB_QPS_PER_CONNECTION參數應該怎麼設置？
A：該參數取決於具體的網路類型和工作負載特徵，沒有放之四海而皆準的最優值。在GB300 NVL72配備ConnectX-8 SuperNIC的場景下，將其從默認值1調整為4，可顯著改善大消息AllGather和ReduceScatter的性能，AllGather時間從約375毫秒降至262毫秒。建議在目標網路上使用實際工作負載的消息大小進行掃描測試，找到最適合自身環境的值，而非直接套用其他場景的配置。
Q3：為什麼容器內的NCCL性能和主機上的測試結果差異這麼大？
A：容器環境可能缺少必要的NCCL拓撲配置。常見原因是`NCCL_TOPO_FILE`環境變量未傳播至容器內，或者對應的拓撲文件未被掛載，導致NCCL回退至自動檢測模式，性能可能下降13%至53%。由於NCCL在這種情況下不會報錯，問題很難被發現。建議在實際運行作業的容器內執行`echo $NCCL_TOPO_FILE && cat $NCCL_TOPO_FILE`進行驗證，確保拓撲文件可訪問。
