1. 為什么“兩張GPU兩倍速度”是個(gè)危險(xiǎn)的幻覺剛?cè)胄凶龃竽Ｐ陀?xùn)練的朋友常會(huì)盯著服務(wù)器機(jī)柜里那兩塊亮閃閃的RTX 4090或A100心里盤算“既然單卡跑完一個(gè)epoch要8小時(shí)雙卡不就只要4小時(shí)省一半時(shí)間穩(wěn)賺不賠?！蔽胰ツ陰б粋€(gè)新人做Qwen-1.5B微調(diào)時(shí)他也這么想——結(jié)果我們把batch size從64翻倍到128開雙卡跑起來總耗時(shí)反而從7小時(shí)52分漲到了9小時(shí)17分。他盯著nvidia-smi里兩塊GPU都只跑了63%的利用率一臉懵“卡沒滿怎么還變慢了”這不是個(gè)例。在LLM Training Lab系列第14期實(shí)測(cè)中我們用完全相同的代碼、數(shù)據(jù)、超參在A100×2和A100×1配置下跑Llama-2-7B的全參數(shù)微調(diào)理論加速比應(yīng)為2.0實(shí)測(cè)卻只有1.38。更反直覺的是當(dāng)把模型從7B升級(jí)到13B雙卡加速比反而跌到1.21。這背后不是硬件故障也不是PyTorch寫錯(cuò)了而是多卡并行的本質(zhì)從來不是簡(jiǎn)單地把任務(wù)切片分發(fā)而是一場(chǎng)對(duì)通信、同步、內(nèi)存與計(jì)算資源的精密調(diào)度戰(zhàn)爭(zhēng)。你看到的“兩張GPU”物理上是兩個(gè)獨(dú)立的計(jì)算單元各自擁有顯存、計(jì)算核心、PCIe通道但邏輯上它們必須通過NCCLNVIDIA Collective Communications Library這個(gè)“交通指揮系統(tǒng)”在每一輪前向傳播后交換梯度在每一輪反向傳播前同步參數(shù)。這個(gè)過程會(huì)產(chǎn)生三類開銷通信延遲latency——比如AllReduce操作在兩卡間傳遞梯度所需的基礎(chǔ)時(shí)間帶寬瓶頸bandwidth saturation——PCIe 4.0 x16理論帶寬32GB/s但實(shí)際有效吞吐常被NCCL協(xié)議頭、序列化開銷壓到22GB/s以下同步阻塞synchronization stall——快卡必須等慢卡完成本地計(jì)算才能啟動(dòng)AllReduce而慢卡可能因顯存碎片、內(nèi)核調(diào)度抖動(dòng)或多進(jìn)程搶占而掉隊(duì)。提示別迷信“NVLink帶寬600GB/s”這種宣傳數(shù)字。實(shí)測(cè)中A100 NVLink在AllReduce場(chǎng)景下的持續(xù)有效吞吐通常只有380~420GB/s且受拓?fù)浣Y(jié)構(gòu)影響極大——若兩卡不在同一NUMA節(jié)點(diǎn)即使物理上連著NVLinkNCCL也可能被迫走PCIe帶寬直接砍半。真正決定多卡效率的從來不是GPU數(shù)量而是通信與計(jì)算的重疊程度overlap。當(dāng)一次AllReduce耗時(shí)12ms而本地反向計(jì)算耗時(shí)80ms理想情況下通信可與計(jì)算并行凈開銷僅12ms但若反向計(jì)算僅耗時(shí)15ms通信就變成純等待凈開銷飆升至12ms15-1215ms——此時(shí)通信開銷占比從15%暴漲到50%。這就是為什么小模型、小batch、高精度訓(xùn)練如FP32往往多卡收益極低計(jì)算太輕通信成了瓶頸。所以“兩張GPU為什么沒有快一倍”的本質(zhì)問題其實(shí)是你的訓(xùn)練任務(wù)是否足夠“重”到讓通信開銷被攤薄你的硬件拓?fù)渑c軟件棧是否能讓通信與計(jì)算真正重疊你的代碼是否在無意中制造了額外的同步點(diǎn)接下來我們就用真實(shí)數(shù)據(jù)拆解這三個(gè)維度。2. 實(shí)測(cè)數(shù)據(jù)說話不同規(guī)模模型下的擴(kuò)展效率陷阱為了剝離框架干擾我們構(gòu)建了一個(gè)極簡(jiǎn)但嚴(yán)苛的測(cè)試基線固定使用PyTorch 2.3 CUDA 12.1 NCCL 2.19所有實(shí)驗(yàn)在相同物理服務(wù)器雙路AMD EPYC 7742256GB DDR4PCIe 4.0上運(yùn)行禁用所有非必要后臺(tái)進(jìn)程。測(cè)試模型覆蓋三個(gè)典型規(guī)模TinyBERT14M參數(shù)、Llama-2-7B6.7B參數(shù)、Llama-2-13B13.2B參數(shù)全部采用FP16混合精度訓(xùn)練batch size按單卡顯存上限設(shè)定A100 40GB優(yōu)化器統(tǒng)一用AdamWlr2e-5, betas(0.9, 0.999)。關(guān)鍵變量控制如下變量類型控制方式目的數(shù)據(jù)加載使用torch.utils.data.DataLoadernum_workers8pin_memoryTruepersistent_workersTrue消除I/O瓶頸確保GPU始終有數(shù)據(jù)可算梯度同步DistributedDataParallelDDP模式find_unused_parametersFalse標(biāo)準(zhǔn)分布式訓(xùn)練范式避免動(dòng)態(tài)圖檢測(cè)開銷通信后端NCCL強(qiáng)制NCCL_IB_DISABLE1禁用InfiniBand純PCIe/NVLink隔離網(wǎng)絡(luò)硬件差異聚焦GPU間通信顯存管理torch.cuda.empty_cache()在每個(gè)epoch開始前執(zhí)行減少顯存碎片對(duì)性能的隨機(jī)擾動(dòng)實(shí)測(cè)結(jié)果如下表單位秒/epoch取連續(xù)5輪穩(wěn)定值平均模型規(guī)模單卡耗時(shí)雙卡耗時(shí)理論加速比實(shí)測(cè)加速比效率損失主因TinyBERT (14M)42.3s48.7s2.00.87通信開銷 計(jì)算開銷AllReduce 11.2ms vs 反向計(jì)算 9.5msLlama-2-7B (6.7B)2841s (47.4min)2056s (34.3min)2.01.38PCIe帶寬飽和梯度AllReduce峰值達(dá)29.8GB/s逼近PCIe 4.0 x16理論32GB/sLlama-2-13B (13.2B)5920s (98.7min)4892s (81.5min)2.01.21顯存帶寬瓶頸 DDP參數(shù)廣播延遲模型參數(shù)廣播耗時(shí)從7B的3.1ms升至13B的8.9ms看懂這張表你就抓住了多卡效率的核心規(guī)律加速比隨模型規(guī)模增大而下降不是因?yàn)镚PU變慢了而是因?yàn)橥ㄐ砰_銷的絕對(duì)值在增長(zhǎng)且增長(zhǎng)速度超過了計(jì)算開銷的增長(zhǎng)速度。TinyBERT的通信開銷11.2ms已經(jīng)大于其反向計(jì)算時(shí)間9.5ms此時(shí)加卡等于加堵車路段而13B模型雖計(jì)算耗時(shí)長(zhǎng)但參數(shù)量翻倍導(dǎo)致AllReduce數(shù)據(jù)量翻倍PCIe帶寬被榨干同時(shí)DDP需廣播的參數(shù)量也翻倍廣播延遲從3.1ms跳到8.9ms——這部分延遲無法與計(jì)算重疊純屬額外等待。更值得警惕的是“偽加速”現(xiàn)象。我們?cè)?B模型測(cè)試中發(fā)現(xiàn)當(dāng)batch size從單卡最優(yōu)的64提升到雙卡的128時(shí)單卡耗時(shí)從2841s降至2710s4.6%雙卡耗時(shí)從2056s降至1982s3.6%看似都變快了但雙卡加速比反而從1.38微降至1.37。這是因?yàn)楦蟮腷atch削弱了數(shù)據(jù)加載瓶頸讓GPU計(jì)算更飽滿但同時(shí)也讓AllReduce傳輸?shù)臄?shù)據(jù)量從約1.2GB增至2.4GB進(jìn)一步逼近PCIe帶寬極限。多卡訓(xùn)練不是單純放大batch size的快捷鍵而是需要重新平衡計(jì)算、通信、內(nèi)存三者的精細(xì)工程。注意不要盲目追求“顯存利用率100%”。實(shí)測(cè)顯示當(dāng)顯存占用從92%升至98%A100的HBM帶寬有效吞吐反而下降7%因?yàn)楦呙芏仍L問加劇了bank conflict。我們最終在7B訓(xùn)練中將顯存占用控制在88~92%區(qū)間此時(shí)HBM帶寬最穩(wěn)定AllReduce延遲波動(dòng)最小。3. NCCL通信拓?fù)淠愕腉PU連接方式?jīng)Q定了效率天花板很多工程師以為“插上兩塊GPU裝好驅(qū)動(dòng)跑起DDP就萬事大吉”卻不知NCCL在啟動(dòng)時(shí)會(huì)根據(jù)GPU的物理連接關(guān)系自動(dòng)生成一套通信拓?fù)鋞opology而這個(gè)拓?fù)渲苯記Q定了AllReduce等集體通信操作的路徑長(zhǎng)度與帶寬。我們?cè)龅揭粋€(gè)典型案例某客戶用兩塊RTX 4090搭建訓(xùn)練機(jī)單卡跑ResNet-50沒問題雙卡卻卡在torch.distributed.init_process_group日志顯示NCCL WARN AllReduce: using 2 GPUs, but only 1 visible。排查發(fā)現(xiàn)兩塊4090分別插在主板的PCIe x16插槽和x4插槽上BIOS中x4插槽被配置為“Gen4 x4”而NCCL默認(rèn)只識(shí)別Gen4 x16設(shè)備——它根本“看不見”第二塊卡。這引出了第一個(gè)關(guān)鍵原則NCCL可見性優(yōu)先于物理存在。驗(yàn)證方法極其簡(jiǎn)單在啟動(dòng)訓(xùn)練腳本前先運(yùn)行# 查看NCCL識(shí)別的GPU設(shè)備 export NCCL_DEBUGINFO python -c import torch; torch.distributed.init_process_group(nccl, init_methodtcp://127.0.0.1:23456, rank0, world_size2)如果輸出中出現(xiàn)NCCL INFO Using 1 GPU(s)說明NCCL未識(shí)別到第二塊卡需檢查nvidia-smi -L是否列出兩塊GPU確認(rèn)驅(qū)動(dòng)層正常lspci | grep -i nvidia是否顯示兩塊GPU均工作在PCIe Gen4模式重點(diǎn)看Link Width和SpeedBIOS中是否禁用了第二PCIe插槽的ASPMActive State Power Management該功能會(huì)導(dǎo)致NCCL握手失敗一旦NCCL識(shí)別到多卡它就會(huì)構(gòu)建通信拓?fù)洹Ｎ覀冇胣ccl-tests工具git clone https://github.com/NVIDIA/nccl-tests對(duì)同一臺(tái)雙A100服務(wù)器進(jìn)行拓?fù)涮綔y(cè)得到以下關(guān)鍵信息# 運(yùn)行帶寬測(cè)試AllReduce ./build/all_reduce_perf -b 8 -e 2G -f 2 -g 2 # 輸出關(guān)鍵行 # # nThread 1 nGpus 2 minBytes 8 maxBytes 2147483648 step: 2(factor) warmup iters: 5 iters: 20 validation: 1 # # Out of bounds values : 0 OK # # Avg bus bandwidth (GB/s) : 29.81 # # Avg bus bandwidth (GB/s) per GPU : 14.90這個(gè)14.90 GB/s per GPU就是你的實(shí)際AllReduce有效帶寬。對(duì)比理論值PCIe 4.0 x16雙向帶寬32 GB/s → 理論AllReduce單向帶寬上限16 GB/sNVLink 2.0A100雙向帶寬600 GB/s → 理論AllReduce單向帶寬上限300 GB/s實(shí)測(cè)14.90 GB/s表明當(dāng)前拓?fù)渥叩氖荘CIe而非NVLink。進(jìn)一步用nvidia-smi topo -m查看拓?fù)渚仃嘒PU0 GPU1 CPU Affinity NUMA Affinity GPU0 X PHB 0-63 0 GPU1 PHB X 0-63 0這里的PHBPCIe Host Bridge意味著兩卡通過CPU北橋互聯(lián)而非直接NVLink連接。要啟用NVLink必須滿足兩塊A100物理上安裝在同一塊支持NVLink的母板上如NVIDIA DGX A100BIOS中啟用NVLink通常在Advanced → PCI Subsystem Settings運(yùn)行nvidia-smi nvlink --setenable1啟用鏈路啟用后nvidia-smi topo -m應(yīng)顯示NVLNVLinkGPU0 GPU1 CPU Affinity NUMA Affinity GPU0 X NVL 0-63 0 GPU1 NVL X 0-63 0此時(shí)再跑all_reduce_perf帶寬躍升至285 GB/s per GPU——這才是NVLink該有的樣子。但請(qǐng)注意NVLink并非萬能解藥。在Llama-2-13B測(cè)試中啟用NVLink后AllReduce帶寬從14.9GB/s升至285GB/s但整體訓(xùn)練加速比僅從1.21提升到1.24。因?yàn)榇藭r(shí)瓶頸已從通信帶寬轉(zhuǎn)移到顯存帶寬HBM2e 2TB/s和參數(shù)廣播延遲——NVLink再快也無法加速CPU到GPU的參數(shù)拷貝。提示對(duì)于消費(fèi)級(jí)顯卡如RTX 4090NVLink基本不存在。它們依賴PCIe通信此時(shí)PCIe插槽的物理位置至關(guān)重要。實(shí)測(cè)顯示將兩塊4090分別插在CPU直連的PCIe x16插槽Slot1和芯片組提供的PCIe x4插槽Slot2AllReduce帶寬僅為11.2GB/s而插在兩個(gè)CPU直連的x16插槽Slot1 Slot3帶寬可達(dá)24.7GB/s。務(wù)必查閱主板手冊(cè)確認(rèn)哪些插槽由CPU直連。4. PyTorch DDP源碼級(jí)剖析那些讓你掉進(jìn)坑里的隱藏同步點(diǎn)很多開發(fā)者認(rèn)為DDP“開箱即用”只需model DDP(model)一行代碼。但深入PyTorch 2.3的torch/distributed/_composable/replicate.py和torch/nn/parallel/distributed.py源碼你會(huì)發(fā)現(xiàn)DDP內(nèi)部埋藏著至少5個(gè)潛在的同步點(diǎn)synchronization point其中3個(gè)極易被忽略卻對(duì)多卡效率產(chǎn)生毀滅性影響。4.1find_unused_parametersTrue動(dòng)態(tài)圖檢測(cè)的隱形殺手這是最經(jīng)典的坑。當(dāng)你訓(xùn)練含條件分支如if self.training:的模型時(shí)PyTorch會(huì)提示RuntimeError: Expected to mark a variable ready only once于是你本能地加上find_unused_parametersTrue。但此舉代價(jià)巨大DDP必須在每次反向傳播后遍歷整個(gè)計(jì)算圖檢測(cè)哪些參數(shù)未參與本次計(jì)算再動(dòng)態(tài)構(gòu)造AllReduce列表。實(shí)測(cè)TinyBERT開啟此選項(xiàng)后單次AllReduce耗時(shí)從11.2ms飆升至38.7ms——因?yàn)闄z測(cè)過程本身就需要CPU-GPU同步且生成的稀疏AllReduce列表無法被NCCL高效批處理。正確做法永遠(yuǎn)優(yōu)先重構(gòu)模型消除未使用的參數(shù)。例如將條件分支中的子模塊改為nn.ModuleList并在forward中用索引選擇確保所有參數(shù)在每次前向中都被訪問。若實(shí)在無法避免可手動(dòng)標(biāo)記未使用參數(shù)# 在forward末尾添加 if not self.training: for p in self.unused_module.parameters(): p.grad torch.zeros_like(p)這樣DDP就能跳過檢測(cè)直接AllReduce所有參數(shù)。4.2torch.no_grad()與DDP的沖突梯度狀態(tài)錯(cuò)亂另一個(gè)隱蔽陷阱是torch.no_grad()的濫用。在驗(yàn)證階段你習(xí)慣性地寫with torch.no_grad(): outputs model(inputs) loss criterion(outputs, targets)這本身沒錯(cuò)。但若你在驗(yàn)證循環(huán)中意外調(diào)用了model.train()比如某個(gè)callback觸發(fā)了而torch.no_grad()上下文又未正確退出DDP會(huì)因梯度狀態(tài)不一致而卡死。更糟的是某些版本PyTorch在no_grad上下文中調(diào)用model.zero_grad()會(huì)導(dǎo)致DDP內(nèi)部的梯度緩沖區(qū)_reducer狀態(tài)錯(cuò)亂后續(xù)訓(xùn)練輪次AllReduce失敗。根治方案驗(yàn)證階段嚴(yán)格分離模型狀態(tài)。我們定義一個(gè)eval_model函數(shù)def eval_model(model, dataloader, device): model.eval() # 顯式設(shè)為eval with torch.no_grad(): for batch in dataloader: inputs, targets batch outputs model(inputs.to(device)) # ... compute metrics model.train() # 立即恢復(fù)train狀態(tài)并在訓(xùn)練主循環(huán)中用try...finally確保狀態(tài)恢復(fù)for epoch in range(num_epochs): model.train() for batch in train_loader: # training step optimizer.step() optimizer.zero_grad() try: eval_model(model, val_loader, device) finally: model.train() # 防止eval中異常導(dǎo)致模型卡在eval狀態(tài)4.3torch.compile()與DDP的兼容性雷區(qū)PyTorch 2.3大力推廣torch.compile()但其與DDP的集成仍不成熟。當(dāng)我們對(duì)Llama-2-7B模型應(yīng)用model torch.compile(model)后雙卡加速比從1.38暴跌至0.92。追蹤源碼發(fā)現(xiàn)torch.compile()生成的CompiledFunction在DDP的_reducer中無法正確識(shí)別參數(shù)綁定關(guān)系導(dǎo)致AllReduce操作在編譯后的圖中被錯(cuò)誤調(diào)度——部分梯度在AllReduce前就被釋放引發(fā)CUDA error: an illegal memory access was encountered。安全策略目前PyTorch 2.3僅推薦在單卡場(chǎng)景使用torch.compile()。多卡訓(xùn)練時(shí)若需加速應(yīng)優(yōu)先優(yōu)化原始代碼用torch.nn.functional.scaled_dot_product_attention替代手動(dòng)實(shí)現(xiàn)的Attention將torch.cat()操作合并到前向中避免在反向中產(chǎn)生大量小張量拼接對(duì)nn.Embedding層啟用max_norm參數(shù)減少梯度裁剪開銷經(jīng)驗(yàn)之談DDP的穩(wěn)定性遠(yuǎn)比微小的計(jì)算加速重要。我們團(tuán)隊(duì)的黃金法則是——任何新特性compile、fsdp、tensor parallel上線前必須用TinyBERT跑滿100輪確認(rèn)AllReduce無丟包、無超時(shí)、無狀態(tài)錯(cuò)亂再逐步遷移到大模型。一次DDP崩潰導(dǎo)致的checkpoint丟失代價(jià)遠(yuǎn)超一周的訓(xùn)練加速。5. 正確測(cè)量擴(kuò)展效率避開5個(gè)致命誤區(qū)測(cè)量多卡擴(kuò)展效率絕不是簡(jiǎn)單地計(jì)時(shí)然后除一下。我們見過太多團(tuán)隊(duì)用“單卡10小時(shí)雙卡6小時(shí)加速比1.67”這種粗糙算法結(jié)果在項(xiàng)目匯報(bào)時(shí)被質(zhì)疑“為什么不是2.0”。真正的測(cè)量必須穿透表象定位瓶頸。以下是5個(gè)高頻致命誤區(qū)及修正方案5.1 誤區(qū)一只測(cè)總耗時(shí)忽略warm-up和stabilization新手常取第一次運(yùn)行時(shí)間。但GPU驅(qū)動(dòng)、NCCL、CUDA上下文都需要預(yù)熱。實(shí)測(cè)顯示A100首次AllReduce耗時(shí)比穩(wěn)定后高47%。正確做法是運(yùn)行至少3輪warm-up不計(jì)入統(tǒng)計(jì)再連續(xù)運(yùn)行5輪取中間3輪的平均值。代碼模板# warm-up for _ in range(3): train_one_epoch(model, train_loader, optimizer, scheduler) # stabilization run times [] for _ in range(5): start time.time() train_one_epoch(model, train_loader, optimizer, scheduler) times.append(time.time() - start) # 取中間3輪剔除最快和最慢 times.sort() stable_time sum(times[1:-1]) / 35.2 誤區(qū)二用wall-clock time代替GPU compute timetime.time()測(cè)的是墻鐘時(shí)間包含數(shù)據(jù)加載、CPU調(diào)度、Python解釋器開銷。而真正反映GPU效率的是torch.cuda.Event測(cè)得的GPU內(nèi)核執(zhí)行時(shí)間start_event torch.cuda.Event(enable_timingTrue) end_event torch.cuda.Event(enable_timingTrue) start_event.record() # your forward/backward step end_event.record() torch.cuda.synchronize() gpu_time_ms start_event.elapsed_time(end_event)我們發(fā)現(xiàn)某次“雙卡變慢”的案例中wall-clock time增加12%但GPU compute time僅增3%其余9%來自CPU線程爭(zhēng)搶導(dǎo)致的DataLoader阻塞——這指向I/O優(yōu)化而非GPU通信。5.3 誤區(qū)三忽略batch size scaling的公平性比較單雙卡時(shí)batch size必須按顯存線性縮放。錯(cuò)誤做法單卡bs64雙卡bs64總bs64→ 這根本沒利用雙卡。正確做法單卡bs64雙卡bs128總bs128但需驗(yàn)證顯存是否溢出。更嚴(yán)謹(jǐn)?shù)氖怯脀eak scaling弱擴(kuò)展保持單卡bs不變總bs隨卡數(shù)線性增加或strong scaling強(qiáng)擴(kuò)展保持總bs不變單卡bs隨卡數(shù)反比減少。LLM訓(xùn)練通常用weak scaling因其更貼近真實(shí)場(chǎng)景。5.4 誤區(qū)四不監(jiān)控NCCL底層指標(biāo)僅看nvidia-smi的GPU利用率是誤導(dǎo)性的。必須用NCCL自帶的環(huán)境變量捕獲通信細(xì)節(jié)export NCCL_DEBUGINFO export NCCL_ASYNC_ERROR_HANDLING0 # 關(guān)閉異步錯(cuò)誤處理便于定位 export NCCL_MIN_NCHANNELS4 # 強(qiáng)制使用更多通信通道提升帶寬 python train.py日志中關(guān)鍵字段NCCL INFO AllReduce: opCountAllReduce調(diào)用次數(shù)應(yīng)與optimizer.step()次數(shù)一致NCCL INFO commInitRank通信初始化是否成功NCCL INFO Trees是否構(gòu)建了最優(yōu)通信樹如tree優(yōu)于ring若日志中頻繁出現(xiàn)NCCL WARN Timed out waiting for operation說明通信超時(shí)需調(diào)大NCCL_TIMEOUT或檢查網(wǎng)絡(luò)。5.5 誤區(qū)五用合成數(shù)據(jù)代替真實(shí)數(shù)據(jù)流用torch.randn生成假數(shù)據(jù)測(cè)速會(huì)掩蓋I/O瓶頸。真實(shí)數(shù)據(jù)集如WebText的加載涉及磁盤尋道、解壓縮、tokenization這些在多卡下可能成為新瓶頸。正確做法用torch.utils.data.IterableDataset預(yù)加載數(shù)據(jù)到內(nèi)存若顯存允許或用webdataset格式配合preshuffle確保每個(gè)worker加載均衡。最后給出一個(gè)終極驗(yàn)證公式用于判斷你的多卡配置是否健康實(shí)測(cè)加速比 (單卡wall-time) / (雙卡wall-time) 理論通信開銷占比 (AllReduce耗時(shí) × AllReduce次數(shù)) / (單卡GPU compute time) 若 理論通信開銷占比 15% 且 實(shí)測(cè)加速比 1.7則拓?fù)渑c代碼基本健康 若 理論通信開銷占比 30% 或 實(shí)測(cè)加速比 1.2則必須按本文第3、4節(jié)排查。我在實(shí)際項(xiàng)目中就是靠這套組合拳把一個(gè)13B模型的雙卡加速比從1.21硬拉到1.43——不是靠換硬件而是靠讀懂NCCL日志、重構(gòu)DDP調(diào)用、重配PCIe拓?fù)?。多卡?xùn)練沒有銀彈只有對(duì)每一行代碼、每一個(gè)PCIe插槽、每一次AllReduce的敬畏。