GPU調度翻車現場：九成團隊把順序搞反了

「等你開始聊Volcano、Kueue這些調度器的時候，昂貴的錯誤早就釀成了。」

這是Kubernetes GPU調度領域的一句刺耳診斷。多數技術團隊把調度器當成起點，實際上它應該是最后一道防線——前提是前面四道題你能答得上來。

本文把原文的硬核框架拆成可執行的檢查清單。如果你正在規劃或優化GPU集群，這些問題的答案比選型哪個調度器重要十倍。

核心誤判：調度器是容量解決方案？

原文作者拋出一個反直覺觀點：GPU調度不是容量解決方案，而是容量執行層。

翻譯成人話：調度器只能幫你把已有的GPU用得更好，它變不出更多卡。如果你的集群是按「理論峰值」采購的，調度器再聰明也救不了預算。

這個認知偏差的代價很具體。很多團隊的集群規劃流程是：業務拍腦袋報一個峰值數字→采購對應數量的A100/H100→上線后發現利用率常年低于30%→開始研究Volcano怎么配置 gang scheduling。

順序錯了。需求建模應該發生在任何調度器選型之前。

第一題：你的真實并發下限是多少？

不是理論峰值，是最小持續并行工作量。集群必須在沒有隊列崩潰的情況下支撐住這個底線。

關鍵區分：峰值是業務想要的，并發下限是系統必須保障的。前者驅動PPT，后者驅動采購。

原文的判定標準很嚴厲：「如果你無法從測量數據中回答這個問題，你沒有需求模型——你只有假設。」

實操建議：拉取過去90天的實際請求并發數據，去掉節假日異常值，取p95而非max。那個數字才是你的并發下限。

第二題：什么是突發，什么是噪音？

需求 spike 持續90秒，值得為此永久保留GPU嗎？還是應該讓它進隊列排隊？

原文給了一個實用 cutoff：短于冷啟動窗口的突發屬于噪音。噪音不應該驅動資源配置決策。

這個判斷直接決定你的集群是「按峰值預留」還是「按基線預留+隊列緩沖」。成本差異通常是3-5倍。

很多團隊的監控儀表盤上，峰值被標紅放大，基線被折疊隱藏。這種可視化本身就在誤導采購決策。

第三題：工作負載在GPU上駐留多久？

模型加載進顯存（VRAM）不等于活躍計算。如果內存保持熱狀態的時間長于計算忙碌時間，利用率在調度器運行第一個任務之前就已經被高估了。

這是推理場景的典型陷阱。模型加載可能占30秒，實際推理計算只占500毫秒。報告出來的「GPU占用」和「有效算力」是兩回事。

原文建議的測量維度：VRAM residency time / active compute time。比值越高，說明你的集群越像「模型倉庫」而非「計算工廠」。

第四題：什么可以等，能等多久？

調度的起點是可容忍延遲。如果每個工作負載都被標記為緊急，那么沒有一個能被高效調度。

這個優先級膨脹的問題在大型組織中尤其嚴重。每個業務方都聲稱自己的任務「不能等」，結果集群調度退化為先到先得，緊急標簽完全失效。

原文的解決方案：用數據定義延遲容忍度，而不是用標簽。批量訓練任務可以排隊15分鐘，實時推理任務必須500毫秒內響應。這兩個應該進不同的隊列，用不同的資源池服務。

七個輸入參數：錯一個，代價具體

答完四道題之后，進入更細粒度的參數校準。原文列出了七個輸入，每個都有明確的錯誤代價。

參數一：請求并發（Request concurrency）

錯誤建模方式：按單線程吞吐量估算。實際后果：集群規模對應一個從未真實運行過的工作負載。

典型場景：測試環境測出單卡QPS為100，直接乘以目標QPS得出卡數。上線后發現生產環境的輸入序列長度分布完全不同，實際單卡QPS只有35。

參數二：隊列深度（Queue depth）

關鍵問題：多少任務排隊之前會變成延遲問題？

原文的觀察：大多數團隊在應該設計隊列行為的時候，選擇了買硬件。隊列深度是軟件問題，GPU數量是硬件問題。前者便宜得多。

一個設計良好的隊列可以把峰值吸收為延遲，而不是轉化為容量需求。這需要顯式定義每個任務類型的最大可容忍排隊時間。

參數三：突發特征（Burst profile）

短需求峰值被定價進永久容量，這是最常見的浪費模式。

正確的突發特征分析：分離 spike 持續時間與分配決策。90秒的spike不需要90秒的專屬GPU，它需要一個能緩沖90秒任務的隊列。

需要區分的兩個數字：spike 高度（并發請求數）和 spike 寬度（持續時間）。寬度決定是否需要額外容量，高度只決定隊列深度。

參數四：延遲容忍度（Latency tolerance）

批量訓練容忍排隊，實時推理不容忍。統一 sizing 兩者是 guaranteed waste pattern（原文原話：保證浪費的模式）。

這個分類錯誤在混合集群中極其普遍。訓練任務搶占了推理任務的資源，導致推理延遲抖動；或者反過來，為推理預留的資源在訓練高峰期閑置。

原文建議：不同的延遲容忍度應該對應不同的資源池，而不是同一個池子里的不同優先級。

參數五：訓練與推理的混合比例（Batch vs inference mix）

這是兩個截然不同的資源配置決策。優化訓練批任務的集群形狀，與優化持續推理吞吐的集群形狀不同。

訓練任務：高顯存占用、長運行時間、可容忍排隊、需要 gang scheduling（多卡協同）。

推理任務：低顯存占用（相對）、短運行時間、低延遲要求、需要高并發能力。

把兩者塞進同一個調度策略，結果通常是兩邊都不滿意。

參數六：顯存駐留時間（VRAM residency time）

模型保持加載狀態的時間，相對于活躍處理請求的時間。

高駐留-計算比意味著：內存在做可用性（availability）的工作，而不是吞吐量（throughput）的工作。

這在多模型服務場景中尤其危險。每個模型都想常駐顯存以避免冷啟動，加起來就超過了物理容量。調度器被迫頻繁換入換出，實際有效算力暴跌。

參數七：任務持續時間方差（Job duration variance）

高方差導致調度碎片化，無論調度器配置得多好。

原文建議用 p50/p90/p99 分布來理解方差，而不是平均值。這決定了是否需要 gang scheduling 或搶占策略。

如果p99是p50的20倍，你的集群需要為長尾任務預留大量緩沖，或者設計搶占機制來回收資源。

糾正動作：從「峰值預留」到「并發分帶」

原文提出的替代方案：并發分帶（concurrency bands）和隊列容忍度（queue tolerance）。

并發分帶來自請求并發的實際測量。不是一條線，而是多條線：基線帶、日常帶、峰值帶。每個帶對應不同的資源策略。

基線帶：必須保障的物理容量，不能排隊。

日常帶：可以容忍短隊列的彈性容量，用自動伸縮或 Spot 實例。

峰值帶：明確接受任務被拒絕或長時間排隊，不預留專屬資源。

隊列容忍度來自延遲要求的顯式分級。每個任務類型必須有數字：最大可容忍排隊秒數。沒有這個數字，調度器無法做有意義的決策。

為什么這件事現在特別重要

GPU 采購決策的糾錯成本極高。CPU 集群買多了可以跑其他服務，GPU 集群買錯了型號或數量，轉售折價率通常在40-60%。

更隱蔽的成本是機會成本。錯誤的容量規劃導致團隊把工程師時間花在調度器調參上，而不是業務優化上。Volcano 的 gang scheduling 配置可以調兩周，但如果是需求模型錯了，這兩周完全是沉沒成本。

原文的結尾很克制，沒有給「未來展望」。這種克制本身是一種誠實：需求建模沒有銀彈，只有四個問題、七個參數、持續測量。

調度器是執行層，不是戰略層。戰略層的錯誤，執行層補不回來。