AIInfra工程師們如何應對大模型流水線裡的“暗湧”？

作者 | AICon 全球人工智慧開發與應用大會

策劃 | 羅燕珊

編輯 | 宇琪

Infra 雖然是看不見的“底座”，但它卻承擔著支撐整個大模型系統執行的重量。那麼，Infra 工程師在日常工作中會遇到哪些真實需求與故障型別？開源 Infra 和國產卡適配訓練推進過程中，又會遇到哪些難點和挑戰呢？

近日 InfoQ《極客有約》X AICon 直播欄目特別邀請了華為昇騰技術專家 ZOMI 醬、螞蟻集團高階專家馬介悅和 SGLang 核心開發者尹良升一起，在 AICon全球人工智慧開發與應用大會2025 北京站即將召開之際，共同探討大模型 Infra 工程師的實戰日常。

部分精彩觀點如下：

並行策略相容性體現的是程式碼實現的耦合度挑戰，而工程流水線管理則關乎功能開發全週期的資源分配與風險控制。
高效的工程化實踐離不開強大的效能剖析和監控系統支援，僅靠人工排查效率低下。
充分利用異構硬體特性、實現跨型別資源的智慧排程與混部，已成為 AI 基礎設施演進的重要方向。

在 6 月 27-28 日將於北京舉辦的AICon全球人工智慧開發與應用大會上，我們特別設定了【AI 基礎設施與生態構建】專題。該專題將聚焦 AI 軟硬體及生態系統的建設，討論如何打造高效的 AI 開發與應用環境。檢視大會日程解鎖更多精彩內容：https://aicon.infoq.cn/2025/beijing/schedule

以下內容基於直播速記整理，經 InfoQ 刪減。

完整直播回放可檢視：https://www.infoq.cn/video/kx2h235pHrE7fENMaxlH

大模型工程中的高頻問題

ZOMI：你們應該都經常接到“線上告急”吧——比如訓練掛了、推理跑不動……最近你們最常遇到的使用者需求，或者說大家最常抱怨的問題是什麼？有沒有一些“聽得最多”的關鍵詞？

馬介悅： 根據我的經驗，線上訓練過程中會遇到各種問題，包括穩定性問題、業務演算法或程式本身的缺陷，或者訓練框架本身的問題。例如訓練任務中斷（“跑掛”）就很常見，特別是在千卡或萬卡級別的大規模叢集上。GPU 本身存在一定的錯誤率，對於一個萬卡叢集來說，每天出現不同的 GPU 故障幾乎是必然的。

訓練是一個同步過程，任何單卡故障都可能導致整個訓練停滯或失敗，因此這種現象很普遍。我近期專注於解決這類穩定性問題，早期遇到此類問題時，若缺乏自動化運維繫統，只能依賴人工響應報警，由運維工程師手動重啟相關任務。然而我們發現，即使重啟任務，也常常會再次中斷。這可能是硬體本身存在問題，或者由於叢集涉及環節眾多。

從宏觀角度看，問題可能源自底層網路系統、交換機、光模組、計算節點本身，節點上的每塊 GPU 都是一個潛在故障點，此外還包括記憶體、CPU 宕機等風險。例如，GPU 經常出現 ECC 錯誤，導致 CUDA 報錯、程序退出。如果運維工程師無法準確定位故障機器，任務重啟後執行一段時間很可能再次中斷，這種情況令人非常困擾。

早期嘗試過使用二分法等運維手段，或透過錯誤日誌、帶外管理（out-of-band）方法來定位故障機器，但當時的準確率不高。這可能導致誤判，錯誤更換機器後任務重啟仍會失敗，問題非常棘手，以上主要涉及硬體或底層基礎設施問題。

此外，對於“跑飛”，我理解為 loss 異常飆升，其成因更為複雜，可能源於演算法本身缺陷、並行框架問題或資料錯誤等，排查需要 Infra 工程師與業務工程師協作，難度較大。還有其他型別的問題，例如任務啟動後無法完成第一個訓練步，這通常與業務程式碼相關。作為 Infra 工程師，我們也需要協助客戶排查此類問題。常見原因包括 Python 使用不當、庫引用錯誤、軟體包版本衝突、環境配置問題或 CUDA 驅動故障等。

尹良升： 我們主要面向合作公司或科研機構提供程式碼和開源更新，協助他們實現最佳效能和最佳的可用性，而非直接接觸真實的線上推理環境部署。因此，當高校、科研機構或公司在進行模型部署或大規模線下推理的工作流出現問題時，我們往往是首先接到反饋的一方。這種情況下，我聽到最多的關鍵詞主要來自兩個方面。

第一方面是執行時錯誤。這類錯誤可能源於我們程式碼中未發現的 bug，也可能是使用者在部署過程中的配置錯誤所致。例如，某些使用者錯誤調整了 GPU 視訊記憶體分配引數，便可能導致視訊記憶體分配溢位（OOM）錯誤。此時，需要熟悉社群程式碼的工程師與一線部署人員深入溝通，精確定位問題程式碼行，分析是哪個配置引數設定不當，進而找到解決方案以消除部署時的執行時錯誤。

第二方面是效能問題。使用者在部署時，即使使用相同的硬體卡和部署策略，也可能發現其效能無法匹配我們官方的測試報告，進而質疑報告資料的真實性或懷疑我們進行了選擇性測試（cherry pick）。實際上，使用者復現結果與官方資料存在差異的原因是多方面的。常見原因包括配置問題、軟體版本差異，以及測試資料集未能完全一致地遷移到使用者環境所導致的資料偏差。

此外，線上推理流程的各個環節出現問題也可能導致效能不符合預期。從接收請求（request）、首次預填充（prefill）到每個解碼（decode）步驟，任一階段的異常都可能引起延遲（latency）偏高。同樣，分配給 KV cache 的記憶體（GPU memory）分配不足也會導致推理的批次（batch size）降低從而吞吐量（throughput）未達預期。解決這類問題，需要深入程式碼層面，具體分析問題環節，進行點對點的最佳化或配置修正。綜合來看，效能問題和執行時錯誤確實是使用者反饋中最常提及的兩類緊急問題。

ZOMI： 我個人更關注訓練環節。在昇騰工作期間，主要聚焦於服務大客戶的推理叢集。遇到的問題首先是如何應對訓練任務中斷。在萬卡甚至十萬卡級別的叢集中，硬體故障不可避免，特別是在持續訓練兩個月的大型模型任務中。其次是如何處理損失函式異常飆升。這需要判斷是不同硬體差異、演算法本身缺陷、客戶程式碼錯誤，還是分散式並行處理時出現了問題。因此，解決這些問題往往需要 Infra 團隊與演算法團隊進行更緊密的合作。

ZOMI：如果把大模型的工程流程當作一條流水線，你們覺得哪一段最容易出問題？是資源排程、作業調優，還是並行策略不相容？

尹良升： 針對並行策略不相容的問題，我以 SGLang 社群上個月復現 DeepSeek Blog 的實踐為例。我們採用了名為“Multi Token Prediction”（MTP，推測解碼）的策略來有效降低 token 輸出延遲。然而，在初始實現中，MTP 與包括“Data-Parallel Attention”（資料並行注意力機制）在內的多個功能存在相容性問題。這種不相容性通常並非源於策略設計本身，而是程式碼實現過程中的相容性與解耦不足所致：為快速交付新功能，可能暫時忽略了與現有功能的相容性。

實際部署中，往往需要同時啟用 MTP、DP Attention、大規模張量並行（EP）等多項功能才能達到“滿血版”最優效能。但實現功能間的完全相容需經歷程式碼重構與解耦過程，從初步實現到最終相容存在較長的陣痛期。這既不可避免，也高度考驗工程師的程式碼能力與全域性設計觀。

若從工程流水線角度討論資源排程與作業調優，此處我理解為推理引擎的功能開發流程而非訓練資源排程，核心在於新功能開發的科學管理。開發關鍵功能需經過充分調研與實驗驗證，一個功能最終合併到主分支往往涉及大量程式碼和嚴格測試。若驗證表明功能未達預期效果，前期投入可能付諸東流。因此，流水線中需重點關注功能的前期可行性驗證、開發階段的合理規劃以及最終測試策略的設計，這些環節是保障效率與質量的關鍵，也容易產生問題。並行策略相容性體現的是程式碼實現的耦合度挑戰，而工程流水線管理則關乎功能開發全週期的資源分配與風險控制。

ZOMI： 在版本迭代過程中，當 Roadmap 規劃的新特性因演算法演進需求必須上線時，常會遇到其與舊有演算法或並行策略不相容的情況。然而，新特性無法放棄，舊特性也不能直接移除。因此，確實需要經歷多個版本的持續迭代與磨合，逐步排查和解決其中的細節問題與分支衝突，僅依賴 CI 流水線持續整合進行保障可能不夠充分。我們的處理方式通常是：將衝突特性暫時分置於不同版本或允許獨立啟用，並在後續版本中進行整合維護。請問你們也是採用類似策略嗎？

尹良升： 是的。這裡可分為兩種開發邏輯：一種是敏捷交付優先：確保每個新特性快速交付，同時保證不影響現有功能的正常啟用。另一種是漸進式重構：若新功能並非緊急需求，且強行整合可能對現有程式碼造成較大破壞，則選擇將該功能拆解為多個 PR，分步驟進行重構。確保每個中間步驟都保持程式碼庫的完整可用狀態，最終透過最後一個 PR 實現新功能與舊特性的完全相容。具體採用哪種方式，需根據功能需求的緊迫性以及不同方案的實現難度綜合評估。

馬介悅： 工程化可分為研發流程與部署上線兩方面。研發環節，如程式碼開發、功能交付與傳統系統軟體開發差異不大，都依賴嚴格的程式碼審查、門禁（gatekeeping）、自動化測試和用例覆蓋。核心在於門禁流水線的設計，例如每個 PR 合併前必須透過完整的門禁流水線測試。但關鍵挑戰在於效能“門禁”常受資源限制：線上可能使用萬卡規模訓練，但 CI 流水線通常僅能在 8 卡或更小規模執行，導致許多大規模問題在 PR 階段無法暴露。對此，目前尚無完美解決方案，只能在問題於線上大規模復現後由工程師介入處理。

另一個研發痛點是：若單次版本更新包含過多新功能，一旦導致機器浮點運算利用率（MFU）下降，難以定位具體是哪個 PR 引入的問題。目前主要依賴二分法或逐版本回退測試來排查，工程師間的程式碼審查在此環節至關重要。此外，研發和線上環節都需重視效能剖析（profiling）——即便小規模無法復現問題，也應記錄火焰圖和時間線，為後續分析 MFU 退化提供依據，幫助診斷並行切分是否合理。

關於部署上線，其流程基於雲原生：首先透過 Kubernetes 以 Pod 形式分配資源；隨後由 DLRover 啟動訓練，並在訓練前執行預檢和組網檢測，確保硬體無故障、環境無異常、通訊（如 NCCL）連線正常。預檢通過後，訓練主導權移交至框架。訓練中核心監控指標是 MFU，它反映叢集算力利用率。MFU 下降通常意味著並行切分（如 TP/EP/PP/DP）策略存在問題，導致計算流中出現等待“bubble”，這需在研發階段透過大量實驗最佳化模型切分策略。

MFU 下降也可能由穩定性問題引發，例如訓練卡死（hang）。卡死成因複雜，硬體、演算法、框架均可能，且硬體問題有時不會觸發程序報錯退出，僅表現為指標異常。雖然業界已有多種檢測卡死的方法，如透過業務指標、metrics 或 DLRover 的 xprof timer 等效能剖析工具，但定位卡死的根本原因比檢測現象更困難。若有強大的底層基礎設施團隊能快速識別並驅逐故障機，問題較易解決；否則需綜合日誌、metrics 和效能剖析資料進行深度診斷。

類似問題還包括“straggler”場景：訓練步耗時逐漸增加。監測到該現象相對簡單，但定位根因（硬體、網路、資料集或切分策略問題）則需複雜的綜合判斷邏輯。

綜上，高效的工程化實踐離不開強大的效能剖析和監控系統支援，僅靠人工排查效率低下。常用工具包括 PyTorch Profiler、GPU 監控系統、各公司自研監控元件，以及 DLRover 的 xprof timer 等。其核心是記錄底層 CUDA 運算元執行時間、Python 程序呼叫棧等資訊，生成時間線和火焰圖，為 SRE 和研發人員提供關鍵的排障依據。

推理部署如何

“壓榨每一分視訊記憶體”？

ZOMI：現在大家都在卷“大模型低成本”，你們覺得在哪些環節最有“最佳化價值”？是推理時的快取策略？訓練時的容錯排程？

尹良升： 我認為當前降低大模型成本是行業共識。從推理部署角度看，隨著大模型普及，其使用量將激增，最終會像可隨時呼叫的 API 一樣融入生活。因此，將大模型的推理成本壓至最低至關重要。

從推理角度降低大模型成本，我認為主要有三個方面。首先，今年 3 月 DeepSeek 官方部落格展示了其透過大規模卡群部署及 PD 分離節點策略，成功將 API 價格壓至前所未有的低點。這啟示我們，從系統層面看，特定的部署方式能有效降低成本。例如，採用稀疏 MoE 架構時，每次推理僅啟用少量引數。若使用大量專家並行，等效於單卡承載的模型權重顯著減少。這帶來一個直觀優勢：模型權重在卡間分佈更稀疏且未大量複製，因此佔用視訊記憶體減少，釋放出的視訊記憶體便可容納更大的 KV 快取，是大模型推理降成本的核心直覺之一。

它引出的關鍵點在於：模型架構設計需與最終上線部署進行聯合設計。在模型設計或訓練階段就需考慮未來推理效能，例如設計更多專家數並利用其架構特性，如 MoE 天然適合資料並行，因其不同專家的權重可直接存於不同 GPU 上。這種前期與後期的協同設計，可能是實現大模型成本持續下降最重要且基礎的一步。

其次，在推理時的快取策略方面，當前普遍做法是將每輪對話後的 KV 快取轉儲至 CPU 記憶體或檔案系統，因為非 GPU 記憶體相對廉價且可視為資源富餘。因此，如何高效載入 KV 快取、設計視訊記憶體到記憶體間 KV 快取的驅逐策略，涉及記憶體管理與多級快取管理策略，仍有最佳化空間。在多輪對話場景下，使用者可能間隔數十秒才複用 KV 快取；但在 Agent 工作流中，觸發由既定邏輯或者工作流控制，其 KV 快取的驅逐策略便截然不同。針對特定工作流定製排程策略，包括 KV 快取的驅逐與重載入，是當前熱門研究方向，也是降低推理成本的重要途徑。

第三點涉及如何提高 GPU 的極限利用率。當前主要依賴 GPU 計算，若 CPU 資源管理不當，會阻塞 GPU 執行，導致 GPU 出現空閒，無法時刻滿載。這源於推理流設計或實現上的缺陷，引入了不必要的同步。解決此問題需要工程與演算法的協同最佳化，例如 DeepSeek 採用“雙批次重疊”策略，將計算與通訊階段錯開以掩蓋通訊開銷並提升 GPU 利用率。又如 SGLang 框架，透過 Overlap Scheduling，延遲 token 排程完全隱藏了 CPU 開銷。這些都是提升資源利用率、壓榨 GPU 推理效能的關鍵創新點。

第三點核心在於最佳化排程開銷。傳統流程（排程批次 ->啟動核心 ->執行計算）中，排程和啟動核心作為 CPU 密集型任務易阻塞後續流程。SGLang 中的 Overlap Scheduling 重新設計工作流，允許 GPU 執行當前批次時，CPU 並行準備下一批次，消除 CPU 準備階段的 GPU 閒置。雖然這提升了 GPU 利用效率，但也面臨相容性挑戰，如與 MTP 的整合，這正是功能迭代中不可避免的“陣痛期”。

馬介悅： 我想從硬體角度再談一點：英偉達 GPU 的領先很大程度上得益於其 NVLink/NVSwitch 機制，它極大提升了單機節點內的 GPU 通訊效率。相比之下，跨節點通訊，無論使用 InfiniBand 還是 RoCE，其效能較 NVSwitch 存在約一個數量級的差距。

因此，提升價效比的關鍵在於：將大量節點整合到大型機櫃內。這不僅能節省交換機等模組的成本（雖然 GPU 仍是訓練叢集的主要成本，但網路成本佔比已不容忽視），更重要的是，透過 NVLink 的“拉遠”互聯技術，能夠將跨節點通訊頻寬提升至接近節點內水平。傳統架構中，節點內走高速 NVLink，節點間走相對低速的 InfiniBand/RoCE，存在效能降級。大型機櫃方案則透過統一的匯流排級互聯技術消除這一斷層，顯著提升整體並行效能。我們的實踐也驗證了這一點：僅更換為類似 Cloud Matrix 的硬體架構，實測效能提升便非常可觀。

所以，成本最佳化不僅關乎價格，更需關注價效比，即同等模型 MFU 下的單位成本。大型整合硬體初期投入可能更高，但如果能大幅提升 MFU，其長期效益仍是顯著的。

開源專案背後的挑戰：

寫程式碼之外的難題

ZOMI：兩位都是在做 Infra 開源專案，你們覺得除了寫程式碼之外，最難的是什麼？是社群運營？使用者反饋？還是版本節奏管理？

馬介悅：DLRover 自 2023 年開源以來，我們的目標是將其發展為更龐大的社群，吸引更多夥伴參與。就個人體會而言，這需要平衡公司繁重工作與社群投入，唯有對開源的熱愛才能兼顧二者。

DLRover 最初定位為容錯系統，在 PyTorch 生態基礎上強化了對作業任務管理、資源排程、容錯及彈性最佳化能力。後續我們進一步集成了更多訓練框架相關元件，包括自研的訓練框架抽象層，以及基於 CUDA 運算元與 Python 構建的效能剖析工具。

當前主要挑戰在於專案剛加入基金會，如何有效運營技術監督委員會，並在國內外提升影響力。這需要從零開始，投入大量精力進行線上線下推廣及交流活動。隨著社群日益活躍、參與者增多，我們將把舞臺讓給新加入的成員，使其在專案中發揮作用，而我們則轉向幕後提供支援。總結而言，運營開源社群是辛苦的工作，唯有依靠對開源的熱愛方能持續投入。

尹良升： 開源的本質是“眾人拾柴火焰高”，開源專案的核心在於其開放性：程式碼應被更多人使用，同時我們應始終歡迎潛在開發者貢獻力量，共同改進程式碼。以 SGLang 社群為例，其從開源起步，如今已成為全球部署規模最大的推理引擎。最關鍵的挑戰在於：如何在專案維護者與社群使用者之間構建良性迴圈——使用者信任社群並提供反饋，社群則吸納更多構建者，驅動版本迭代與專案進化。這種良性互動超越了純粹的工程能力，是開源專案可持續發展的核心難點，也是其保持活力、長盛不衰的基礎。

ZOMI： 在華為負責 Mind 系列開源元件的經歷讓我深有感觸。起初僅開源了 MindSpore Core，但面臨一個普遍認知：華為開源專案僅支援昇騰硬體，且易用性不足。打造一個如 SGLang 或 vLLM 般成功的開源專案極具挑戰，其難度遠超程式碼本身，涉及社群運營、使用者反饋機制等複雜因素。

觀眾：現在有很多 GPU 共享和虛擬化方案，這塊的技術趨勢是怎樣的呢？

馬介悅： 關於 GPU 虛擬化，我只能淺談一二，因其高度依賴廠商支援。例如英偉達的 MIG（Multi-Instance GPU）技術需要其官方提供。在 MIG 出現前，GPU 虛擬化相當繁瑣，存在多種實現層面。最基礎的是軟體層面虛擬化：透過 Hook CUDA 呼叫，追蹤 kernel 發起速率、執行時間等資訊，並基於此實現簡單的複用策略。此類方案通常需對接 CUDA Forward-Compatibility Runtime。

但軟體虛擬化與 CPU 硬體輔助虛擬化（如 Intel VT-x/AMD-V）的成熟度尚有差距。硬體層面的支援更深入，AMD 早期在雲渲染時代已提供相關虛擬化能力（主要服務於虛擬機器場景），但當前大模型訓練領域採用 AMD GPU 的案例極少，故暫不展開討論。

在英偉達生態中，MIG 是較成熟的方案。它基於 SR-IOV（Single Root I/O Virtualization）技術實現裝置級虛擬化，本質是將物理 GPU 劃分為多個虛擬例項（呈現為獨立的 PCIe 裝置），可同時供給容器或虛擬機器使用。虛擬化的核心價值（效能、隔離性、安全性）在 SR-IOV 這一成熟技術框架下均可較好實現，只要廠商遵循規範支援即可。使用者更關心的可能是具體配置細節，例如每塊 MIG 例項可分配的 SM 算力比例等資源配額——這與網絡卡等裝置的虛擬化配置思路類似，期待廠商提供更靈活的管控能力。

ZOMI： 早期，不同廠商的 GPU 叢集通常獨立部署，實現異構融合極具挑戰性，眾多國家級專案也面臨困難。然而，隨著技術演進，特別是推理環節預填充與解碼分離架構的成熟，異構部署的可行性顯著提升。計算需求的分化是關鍵：預填充階段依賴高算力晶片，而解碼階段更看重視訊記憶體容量與高效的 KV 快取管理能力，這使得為不同階段匹配最優硬體成為可能。這一趨勢正加速滲透至微調、後訓練乃至訓練環節。例如在增量學習場景中，高頻次推理任務與單次訓練任務對資源的差異化需求，為高效的資源共享與分割創造了條件。此外，CPU 與 GPU 的混合部署技術也日益成熟。綜合來看，充分利用異構硬體特性、實現跨型別資源的智慧排程與混部，已成為 AI 基礎設施演進的重要方向。

觀眾：尹老師選擇 SGLang 而非 vLLM 的原因是什麼？

尹良升： 因為當前開源社群熱度較高的推理引擎，除了半開源的 TensorRT，便是 SGLang 和 vLLM。首先，開源專案的進步離不開競爭與相互學習，這種良性互動帶來危機感，推動整個社群共同前進。TensorRT、SGLang、vLLM 以及 lmdeploy 等社群目前正處於協同並進的狀態。

至於使用者選擇 SGLang 而非 vLLM 的理由，這更多是見仁見智的問題。從 SGLang 的 0.1 到最近的 0.4 版本，我們與 vLLM 在功能交付上各有側重。我們的設計理念存在根本差異：例如，從初始版本至今，SGLang 始終圍繞“GPU 視訊記憶體字首共享（prefix share）”為核心進行最佳化，再到後續實現的“零開銷排程器（Zero Overhead Scheduler）”。這些獨特設計使我們在特定場景下可能具備效能優勢。同時，我們社群的開發風格是篤定解決使用者的核心痛點——例如近期版本支援 DeepSeek 的大規模張量並行，目標直指降低使用者部署的過高成本。

使用者的選擇自由毋庸置疑，但如果需要給出一個選擇 SGLang 的理由，可能是我們在某些方面能提供更低的部署成本或更友好的上手體驗。這本質上是使用者與開源社群建立信任的過程。我們也鼓勵大家嘗試不同引擎，積極反饋使用體驗，這將幫助我們持續交付新功能，共同推動推理成本最佳化。