作者 | AICon 全球人工智能開發(fā)與應用大會
策劃 | 羅燕珊
編輯 | 宇琪
Infra 雖然是看不見的“底座”，但它卻承擔著支撐整個大模型系統(tǒng)運行的重量。那么，Infra 工程師在日常工作中會遇到哪些真實需求與故障類型？開源 Infra 和國產(chǎn)卡適配訓練推進過程中，又會遇到哪些難點和挑戰(zhàn)呢？
近日 InfoQ《極客有約》X AICon 直播欄目特別邀請了華為昇騰技術專家 ZOMI 醬、螞蟻集團高級專家馬介悅和 SGLang 核心開發(fā)者尹良升一起，在 AICon全球人工智能開發(fā)與應用大會2025 北京站即將召開之際，共同探討大模型 Infra 工程師的實戰(zhàn)日常。
部分精彩觀點如下：
并行策略兼容性體現(xiàn)的是代碼實現(xiàn)的耦合度挑戰(zhàn)，而工程流水線管理則關乎功能開發(fā)全周期的資源分配與風險控制。
高效的工程化實踐離不開強大的性能剖析和監(jiān)控系統(tǒng)支持，僅靠人工排查效率低下。
充分利用異構硬件特性、實現(xiàn)跨類型資源的智能調度與混部，已成為 AI 基礎設施演進的重要方向。
在 6 月 27-28 日將于北京舉辦的 AICon 全球人工智能開發(fā)與應用大會上，我們特別設置了 專題。該專題將聚焦 AI 軟硬件及生態(tài)系統(tǒng)的建設，討論如何打造高效的 AI 開發(fā)與應用環(huán)境。
查看大會日程解鎖更多精彩內容：
https://aicon.infoq.cn/2025/beijing/schedule
以下內容基于直播速記整理，經(jīng) InfoQ 刪減。
完整直播回放可查看：https://www.infoq.cn/video/kx2h235pHrE7fENMaxlH
大模型工程中的高頻問題
ZOMI：你們應該都經(jīng)常接到“線上告急”吧——比如訓練掛了、推理跑不動……最近你們最常遇到的用戶需求，或者說大家最常抱怨的問題是什么？ 有沒有一些“聽得最多”的關鍵詞？
馬介悅： 根據(jù)我的經(jīng)驗，線上訓練過程中會遇到各種問題，包括穩(wěn)定性問題、業(yè)務算法或程序本身的缺陷，或者訓練框架本身的問題。例如訓練任務中斷（“跑掛”）就很常見，特別是在千卡或萬卡級別的大規(guī)模集群上。GPU 本身存在一定的錯誤率，對于一個萬卡集群來說，每天出現(xiàn)不同的 GPU 故障幾乎是必然的。
訓練是一個同步過程，任何單卡故障都可能導致整個訓練停滯或失敗，因此這種現(xiàn)象很普遍。我近期專注于解決這類穩(wěn)定性問題，早期遇到此類問題時，若缺乏自動化運維系統(tǒng)，只能依賴人工響應報警，由運維工程師手動重啟相關任務。然而我們發(fā)現(xiàn)，即使重啟任務，也常常會再次中斷。這可能是硬件本身存在問題，或者由于集群涉及環(huán)節(jié)眾多。
從宏觀角度看，問題可能源自底層網(wǎng)絡系統(tǒng)、交換機、光模塊、計算節(jié)點本身，節(jié)點上的每塊 GPU 都是一個潛在故障點，此外還包括內存、CPU 宕機等風險。例如，GPU 經(jīng)常出現(xiàn) ECC 錯誤，導致 CUDA 報錯、進程退出。如果運維工程師無法準確定位故障機器，任務重啟后運行一段時間很可能再次中斷，這種情況令人非常困擾。
早期嘗試過使用二分法等運維手段，或通過錯誤日志、帶外管理（out-of-band）方法來定位故障機器，但當時的準確率不高。這可能導致誤判，錯誤更換機器后任務重啟仍會失敗，問題非常棘手，以上主要涉及硬件或底層基礎設施問題。
對于“跑飛”，我理解為 loss 異常飆升，其成因更為復雜，可能源于算法本身缺陷、并行框架問題或數(shù)據(jù)錯誤等，排查需要 Infra 工程師與業(yè)務工程師協(xié)作，難度較大。還有其他類型的問題，例如任務啟動后無法完成第一個訓練步，這通常與業(yè)務代碼相關。作為 Infra 工程師，我們也需要協(xié)助客戶排查此類問題。常見原因包括 Python 使用不當、庫引用錯誤、軟件包版本沖突、環(huán)境配置問題或 CUDA 驅動故障等。
尹良升： 我們主要面向合作公司或科研機構提供代碼和開源更新，協(xié)助他們實現(xiàn)最佳性能和最佳的可用性，而非直接接觸真實的線上推理環(huán)境部署。因此，當高校、科研機構或公司在進行模型部署或大規(guī)模線下推理的工作流出現(xiàn)問題時，我們往往是首先接到反饋的一方。這種情況下，我聽到最多的關鍵詞主要來自兩個方面。
第一方面是運行時錯誤。這類錯誤可能源于我們代碼中未發(fā)現(xiàn)的 bug，也可能是用戶在部署過程中的配置錯誤所致。例如，某些用戶錯誤調整了 GPU 顯存分配參數(shù)，便可能導致顯存分配溢出（OOM）錯誤。此時，需要熟悉社區(qū)代碼的工程師與一線部署人員深入溝通，精確定位問題代碼行，分析是哪個配置參數(shù)設置不當，進而找到解決方案以消除部署時的運行時錯誤。
第二方面是性能問題。用戶在部署時，即使使用相同的硬件卡和部署策略，也可能發(fā)現(xiàn)其性能無法匹配我們官方的測試報告，進而質疑報告數(shù)據(jù)的真實性或懷疑我們進行了選擇性測試（cherry pick）。實際上，用戶復現(xiàn)結果與官方數(shù)據(jù)存在差異的原因是多方面的。常見原因包括配置問題、軟件版本差異，以及測試數(shù)據(jù)集未能完全一致地遷移到用戶環(huán)境所導致的數(shù)據(jù)偏差。
線上推理流程的各個環(huán)節(jié)出現(xiàn)問題也可能導致性能不符合預期。從接收請求（request）、首次預填充（prefill）到每個解碼（decode）步驟，任一階段的異常都可能引起延遲（latency）偏高。同樣，分配給 KV cache 的內存（GPU memory）分配不足也會導致推理的批次（batch size）降低從而吞吐量（throughput）未達預期。解決這類問題，需要深入代碼層面，具體分析問題環(huán)節(jié)，進行點對點的優(yōu)化或配置修正。綜合來看，性能問題和運行時錯誤確實是用戶反饋中最常提及的兩類緊急問題。
ZOMI： 我個人更關注訓練環(huán)節(jié)。在昇騰工作期間，主要聚焦于服務大客戶的推理集群。遇到的問題首先是如何應對訓練任務中斷。在萬卡甚至十萬卡級別的集群中，硬件故障不可避免，特別是在持續(xù)訓練兩個月的大型模型任務中。其次是如何處理損失函數(shù)異常飆升。這需要判斷是不同硬件差異、算法本身缺陷、客戶代碼錯誤，還是分布式并行處理時出現(xiàn)了問題。因此，解決這些問題往往需要 Infra 團隊與算法團隊進行更緊密的合作。
ZOMI：如果把大模型的工程流程當作一條流水線，你們覺得哪一段最容易出問題？是資源調度、作業(yè)調優(yōu)，還是并行策略不兼容？
尹良升： 針對并行策略不兼容的問題，我以 SGLang 社區(qū)上個月復現(xiàn) DeepSeek Blog 的實踐為例。我們采用了名為“Multi Token Prediction”（MTP，推測解碼）的策略來有效降低 token 輸出延遲。然而，在初始實現(xiàn)中，MTP 與包括“Data-Parallel Attention”（數(shù)據(jù)并行注意力機制）在內的多個功能存在兼容性問題。這種不兼容性通常并非源于策略設計本身，而是代碼實現(xiàn)過程中的兼容性與解耦不足所致：為快速交付新功能，可能暫時忽略了與現(xiàn)有功能的兼容性。
實際部署中，往往需要同時啟用 MTP、DP Attention、大規(guī)模張量并行（EP）等多項功能才能達到“滿血版”最優(yōu)性能。但實現(xiàn)功能間的完全兼容需經(jīng)歷代碼重構與解耦過程，從初步實現(xiàn)到最終兼容存在較長的陣痛期。這既不可避免，也高度考驗工程師的代碼能力與全局設計觀。
若從工程流水線角度討論資源調度與作業(yè)調優(yōu)，此處我理解為推理引擎的功能開發(fā)流程而非訓練資源調度，核心在于新功能開發(fā)的科學管理。開發(fā)關鍵功能需經(jīng)過充分調研與實驗驗證，一個功能最終合并到主分支往往涉及大量代碼和嚴格測試。若驗證表明功能未達預期效果，前期投入可能付諸東流。因此，流水線中需重點關注功能的前期可行性驗證、開發(fā)階段的合理規(guī)劃以及最終測試策略的設計，這些環(huán)節(jié)是保障效率與質量的關鍵，也容易產(chǎn)生問題。并行策略兼容性體現(xiàn)的是代碼實現(xiàn)的耦合度挑戰(zhàn)，而工程流水線管理則關乎功能開發(fā)全周期的資源分配與風險控制。
ZOMI： 在版本迭代過程中，當 Roadmap 規(guī)劃的新特性因算法演進需求必須上線時，常會遇到其與舊有算法或并行策略不兼容的情況。然而，新特性無法放棄，舊特性也不能直接移除。因此，確實需要經(jīng)歷多個版本的持續(xù)迭代與磨合，逐步排查和解決其中的細節(jié)問題與分支沖突，僅依賴 CI 流水線持續(xù)集成進行保障可能不夠充分。我們的處理方式通常是：將沖突特性暫時分置于不同版本或允許獨立啟用，并在后續(xù)版本中進行整合維護。請問你們也是采用類似策略嗎？
尹良升： 是的。這里可分為兩種開發(fā)邏輯：一種是敏捷交付優(yōu)先：確保每個新特性快速交付，同時保證不影響現(xiàn)有功能的正常啟用。另一種是漸進式重構：若新功能并非緊急需求，且強行集成可能對現(xiàn)有代碼造成較大破壞，則選擇將該功能拆解為多個 PR，分步驟進行重構。確保每個中間步驟都保持代碼庫的完整可用狀態(tài)，最終通過最后一個 PR 實現(xiàn)新功能與舊特性的完全兼容。具體采用哪種方式，需根據(jù)功能需求的緊迫性以及不同方案的實現(xiàn)難度綜合評估。
馬介悅： 工程化可分為研發(fā)流程與部署上線兩方面。研發(fā)環(huán)節(jié)，如代碼開發(fā)、功能交付與傳統(tǒng)系統(tǒng)軟件開發(fā)差異不大，都依賴嚴格的代碼審查、門禁（gatekeeping）、自動化測試和用例覆蓋。核心在于門禁流水線的設計，例如每個 PR 合并前必須通過完整的門禁流水線測試。但關鍵挑戰(zhàn)在于性能“門禁”常受資源限制：線上可能使用萬卡規(guī)模訓練，但 CI 流水線通常僅能在 8 卡或更小規(guī)模運行，導致許多大規(guī)模問題在 PR 階段無法暴露。對此，目前尚無完美解決方案，只能在問題于線上大規(guī)模復現(xiàn)后由工程師介入處理。
另一個研發(fā)痛點是：若單次版本更新包含過多新功能，一旦導致機器浮點運算利用率（MFU）下降，難以定位具體是哪個 PR 引入的問題。目前主要依賴二分法或逐版本回退測試來排查，工程師間的代碼審查在此環(huán)節(jié)至關重要。研發(fā)和線上環(huán)節(jié)都需重視性能剖析（profiling）——即便小規(guī)模無法復現(xiàn)問題，也應記錄火焰圖和時間線，為后續(xù)分析 MFU 退化提供依據(jù)，幫助診斷并行切分是否合理。
關于部署上線，其流程基于云原生：首先通過 Kubernetes 以 Pod 形式分配資源；隨后由 DLRover 啟動訓練，并在訓練前執(zhí)行預檢和組網(wǎng)檢測，確保硬件無故障、環(huán)境無異常、通信（如 NCCL）連接正常。預檢通過后，訓練主導權移交至框架。訓練中核心監(jiān)控指標是 MFU，它反映集群算力利用率。MFU 下降通常意味著并行切分（如 TP/EP/PP/DP）策略存在問題，導致計算流中出現(xiàn)等待“bubble”，這需在研發(fā)階段通過大量實驗優(yōu)化模型切分策略。
MFU 下降也可能由穩(wěn)定性問題引發(fā)，例如訓練卡死（hang）。卡死成因復雜，硬件、算法、框架均可能，且硬件問題有時不會觸發(fā)進程報錯退出，僅表現(xiàn)為指標異常。雖然業(yè)界已有多種檢測卡死的方法，如通過業(yè)務指標、metrics 或 DLRover 的 xprof timer 等性能剖析工具，但定位卡死的根本原因比檢測現(xiàn)象更困難。若有強大的底層基礎設施團隊能快速識別并驅逐故障機，問題較易解決；否則需綜合日志、metrics 和性能剖析數(shù)據(jù)進行深度診斷。
類似問題還包括“straggler”場景：訓練步耗時逐漸增加。監(jiān)測到該現(xiàn)象相對簡單，但定位根因（硬件、網(wǎng)絡、數(shù)據(jù)集或切分策略問題）則需復雜的綜合判斷邏輯。
綜上，高效的工程化實踐離不開強大的性能剖析和監(jiān)控系統(tǒng)支持，僅靠人工排查效率低下。常用工具包括 PyTorch Profiler、GPU 監(jiān)控系統(tǒng)、各公司自研監(jiān)控組件，以及 DLRover 的 xprof timer 等。其核心是記錄底層 CUDA 算子執(zhí)行時間、Python 進程調用棧等信息，生成時間線和火焰圖，為 SRE 和研發(fā)人員提供關鍵的排障依據(jù)。
推理部署如何
“壓榨每一分顯存”？
ZOMI：現(xiàn)在大家都在卷“大模型低成本”，你們覺得在哪些環(huán)節(jié)最有“優(yōu)化價值”？是推理時的緩存策略？訓練時的容錯調度？
尹良升： 我認為當前降低大模型成本是行業(yè)共識。從推理部署角度看，隨著大模型普及，其使用量將激增，最終會像可隨時調用的 API 一樣融入生活。因此，將大模型的推理成本壓至最低至關重要。
從推理角度降低大模型成本，我認為主要有三個方面。首先，今年 3 月 DeepSeek 官方博客展示了其通過大規(guī)模卡群部署及 PD 分離節(jié)點策略，成功將 API 價格壓至前所未有的低點。這啟示我們，從系統(tǒng)層面看，特定的部署方式能有效降低成本。例如，采用稀疏 MoE 架構時，每次推理僅激活少量參數(shù)。若使用大量專家并行，等效于單卡承載的模型權重顯著減少。這帶來一個直觀優(yōu)勢：模型權重在卡間分布更稀疏且未大量復制，因此占用顯存減少，釋放出的顯存便可容納更大的 KV 緩存，是大模型推理降成本的核心直覺之一。
它引出的關鍵點在于：模型架構設計需與最終上線部署進行聯(lián)合設計。在模型設計或訓練階段就需考慮未來推理性能，例如設計更多專家數(shù)并利用其架構特性，如 MoE 天然適合數(shù)據(jù)并行，因其不同專家的權重可直接存于不同 GPU 上。這種前期與后期的協(xié)同設計，可能是實現(xiàn)大模型成本持續(xù)下降最重要且基礎的一步。
其次，在推理時的緩存策略方面，當前普遍做法是將每輪對話后的 KV 緩存轉儲至 CPU 內存或文件系統(tǒng)，因為非 GPU 內存相對廉價且可視為資源富余。因此，如何高效加載 KV 緩存、設計顯存到內存間 KV 緩存的驅逐策略，涉及內存管理與多級緩存管理策略，仍有優(yōu)化空間。在多輪對話場景下，用戶可能間隔數(shù)十秒才復用 KV 緩存；但在 Agent 工作流中，觸發(fā)由既定邏輯或者工作流控制，其 KV 緩存的驅逐策略便截然不同。針對特定工作流定制調度策略，包括 KV 緩存的驅逐與重加載，是當前熱門研究方向，也是降低推理成本的重要途徑。
第三點涉及如何提高 GPU 的極限利用率。當前主要依賴 GPU 計算，若 CPU 資源管理不當，會阻塞 GPU 運行，導致 GPU 出現(xiàn)空閑，無法時刻滿載。這源于推理流設計或實現(xiàn)上的缺陷，引入了不必要的同步。解決此問題需要工程與算法的協(xié)同優(yōu)化，例如 DeepSeek 采用“雙批次重疊”策略，將計算與通信階段錯開以掩蓋通信開銷并提升 GPU 利用率。又如 SGLang 框架，通過 Overlap Scheduling，延遲 token 調度完全隱藏了 CPU 開銷。這些都是提升資源利用率、壓榨 GPU 推理性能的關鍵創(chuàng)新點。
第三點核心在于優(yōu)化調度開銷。傳統(tǒng)流程（調度批次 ->啟動內核 ->執(zhí)行計算）中，調度和啟動內核作為 CPU 密集型任務易阻塞后續(xù)流程。SGLang 中的 Overlap Scheduling 重新設計工作流，允許 GPU 執(zhí)行當前批次時，CPU 并行準備下一批次，消除 CPU 準備階段的 GPU 閑置。雖然這提升了 GPU 利用效率，但也面臨兼容性挑戰(zhàn)，如與 MTP 的整合，這正是功能迭代中不可避免的“陣痛期”。
馬介悅： 我想從硬件角度再談一點：英偉達 GPU 的領先很大程度上得益于其 NVLink/NVSwitch 機制，它極大提升了單機節(jié)點內的 GPU 通信效率。相比之下，跨節(jié)點通信，無論使用 InfiniBand 還是 RoCE，其性能較 NVSwitch 存在約一個數(shù)量級的差距。
因此，提升性價比的關鍵在于：將大量節(jié)點整合到大型機柜內。這不僅能節(jié)省交換機等模塊的成本（雖然 GPU 仍是訓練集群的主要成本，但網(wǎng)絡成本占比已不容忽視），更重要的是，通過 NVLink 的“拉遠”互聯(lián)技術，能夠將跨節(jié)點通信帶寬提升至接近節(jié)點內水平。傳統(tǒng)架構中，節(jié)點內走高速 NVLink，節(jié)點間走相對低速的 InfiniBand/RoCE，存在性能降級。大型機柜方案則通過統(tǒng)一的總線級互聯(lián)技術消除這一斷層，顯著提升整體并行性能。我們的實踐也驗證了這一點：僅更換為類似 Cloud Matrix 的硬件架構，實測性能提升便非?？捎^。
所以，成本優(yōu)化不僅關乎價格，更需關注性價比，即同等模型 MFU 下的單位成本。大型集成硬件初期投入可能更高，但如果能大幅提升 MFU，其長期效益仍是顯著的。
開源項目背后的挑戰(zhàn)：
寫代碼之外的難題
ZOMI：兩位都是在做 Infra 開源項目，你們覺得除了寫代碼之外，最難的是什么？ 是社區(qū)運營？用戶反饋？還是版本節(jié)奏管理？
馬介悅：DLRover 自 2023 年開源以來，我們的目標是將其發(fā)展為更龐大的社區(qū)，吸引更多伙伴參與。就個人體會而言，這需要平衡公司繁重工作與社區(qū)投入，唯有對開源的熱愛才能兼顧二者。
DLRover 最初定位為容錯系統(tǒng)，在 PyTorch 生態(tài)基礎上強化了對作業(yè)任務管理、資源調度、容錯及彈性優(yōu)化能力。后續(xù)我們進一步集成了更多訓練框架相關組件，包括自研的訓練框架抽象層，以及基于 CUDA 算子與 Python 構建的性能剖析工具。
當前主要挑戰(zhàn)在于項目剛加入基金會，如何有效運營技術監(jiān)督委員會，并在國內外提升影響力。這需要從零開始，投入大量精力進行線上線下推廣及交流活動。隨著社區(qū)日益活躍、參與者增多，我們將把舞臺讓給新加入的成員，使其在項目中發(fā)揮作用，而我們則轉向幕后提供支持?？偨Y而言，運營開源社區(qū)是辛苦的工作，唯有依靠對開源的熱愛方能持續(xù)投入。
尹良升： 開源的本質是“眾人拾柴火焰高”，開源項目的核心在于其開放性：代碼應被更多人使用，同時我們應始終歡迎潛在開發(fā)者貢獻力量，共同改進代碼。以 SGLang 社區(qū)為例，其從開源起步，如今已成為全球部署規(guī)模最大的推理引擎。最關鍵的挑戰(zhàn)在于：如何在項目維護者與社區(qū)用戶之間構建良性循環(huán)——用戶信任社區(qū)并提供反饋，社區(qū)則吸納更多構建者，驅動版本迭代與項目進化。這種良性互動超越了純粹的工程能力，是開源項目可持續(xù)發(fā)展的核心難點，也是其保持活力、長盛不衰的基礎。
ZOMI： 在華為負責 Mind 系列開源組件的經(jīng)歷讓我深有感觸。起初僅開源了 MindSpore Core，但面臨一個普遍認知：華為開源項目僅支持昇騰硬件，且易用性不足。打造一個如 SGLang 或 vLLM 般成功的開源項目極具挑戰(zhàn)，其難度遠超代碼本身，涉及社區(qū)運營、用戶反饋機制等復雜因素。
觀眾：現(xiàn)在有很多 GPU 共享和虛擬化方案，這塊的技術趨勢是怎樣的呢？
馬介悅： 關于 GPU 虛擬化，我只能淺談一二，因其高度依賴廠商支持。例如英偉達的 MIG（Multi-Instance GPU）技術需要其官方提供。在 MIG 出現(xiàn)前，GPU 虛擬化相當繁瑣，存在多種實現(xiàn)層面。最基礎的是軟件層面虛擬化：通過 Hook CUDA 調用，追蹤 kernel 發(fā)起速率、執(zhí)行時間等信息，并基于此實現(xiàn)簡單的復用策略。此類方案通常需對接 CUDA Forward-Compatibility Runtime。
但軟件虛擬化與 CPU 硬件輔助虛擬化（如 Intel VT-x/AMD-V）的成熟度尚有差距。硬件層面的支持更深入，AMD 早期在云渲染時代已提供相關虛擬化能力（主要服務于虛擬機場景），但當前大模型訓練領域采用 AMD GPU 的案例極少，故暫不展開討論。
在英偉達生態(tài)中，MIG 是較成熟的方案。它基于 SR-IOV（Single Root I/O Virtualization）技術實現(xiàn)設備級虛擬化，本質是將物理 GPU 劃分為多個虛擬實例（呈現(xiàn)為獨立的 PCIe 設備），可同時供給容器或虛擬機使用。虛擬化的核心價值（性能、隔離性、安全性）在 SR-IOV 這一成熟技術框架下均可較好實現(xiàn)，只要廠商遵循規(guī)范支持即可。用戶更關心的可能是具體配置細節(jié)，例如每塊 MIG 實例可分配的 SM 算力比例等資源配額——這與網(wǎng)卡等設備的虛擬化配置思路類似，期待廠商提供更靈活的管控能力。
ZOMI： 早期，不同廠商的 GPU 集群通常獨立部署，實現(xiàn)異構融合極具挑戰(zhàn)性，眾多國家級項目也面臨困難。然而，隨著技術演進，特別是推理環(huán)節(jié)預填充與解碼分離架構的成熟，異構部署的可行性顯著提升。計算需求的分化是關鍵：預填充階段依賴高算力芯片，而解碼階段更看重顯存容量與高效的 KV 緩存管理能力，這使得為不同階段匹配最優(yōu)硬件成為可能。這一趨勢正加速滲透至微調、后訓練乃至訓練環(huán)節(jié)。例如在增量學習場景中，高頻次推理任務與單次訓練任務對資源的差異化需求，為高效的資源共享與分割創(chuàng)造了條件。CPU 與 GPU 的混合部署技術也日益成熟。綜合來看，充分利用異構硬件特性、實現(xiàn)跨類型資源的智能調度與混部，已成為 AI 基礎設施演進的重要方向。
觀眾：尹老師選擇 SGLang 而非 vLLM 的原因是什么？
尹良升： 因為當前開源社區(qū)熱度較高的推理引擎，除了半開源的 TensorRT，便是 SGLang 和 vLLM。首先，開源項目的進步離不開競爭與相互學習，這種良性互動帶來危機感，推動整個社區(qū)共同前進。TensorRT、SGLang、vLLM 以及 lmdeploy 等社區(qū)目前正處于協(xié)同并進的狀態(tài)。
至于用戶選擇 SGLang 而非 vLLM 的理由，這更多是見仁見智的問題。從 SGLang 的 0.1 到最近的 0.4 版本，我們與 vLLM 在功能交付上各有側重。我們的設計理念存在根本差異：例如，從初始版本至今，SGLang 始終圍繞“GPU 顯存前綴共享（prefix share）”為核心進行優(yōu)化，再到后續(xù)實現(xiàn)的“零開銷調度器（Zero Overhead Scheduler）”。這些獨特設計使我們在特定場景下可能具備性能優(yōu)勢。同時，我們社區(qū)的開發(fā)風格是篤定解決用戶的核心痛點——例如近期版本支持 DeepSeek 的大規(guī)模張量并行，目標直指降低用戶部署的過高成本。
用戶的選擇自由毋庸置疑，但如果需要給出一個選擇 SGLang 的理由，可能是我們在某些方面能提供更低的部署成本或更友好的上手體驗。這本質上是用戶與開源社區(qū)建立信任的過程。我們也鼓勵大家嘗試不同引擎，積極反饋使用體驗，這將幫助我們持續(xù)交付新功能，共同推動推理成本優(yōu)化。
