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

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

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

核心誤判：調(diào)度器是容量解決方案？

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

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

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

順序錯了。需求建模應該發(fā)生在任何調(diào)度器選型之前。

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

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

關(guān)鍵區(qū)分：峰值是業(yè)務想要的，并發(fā)下限是系統(tǒng)必須保障的。前者驅(qū)動PPT，后者驅(qū)動采購。

原文的判定標準很嚴厲：「如果你無法從測量數(shù)據(jù)中回答這個問題，你沒有需求模型——你只有假設?！?/p>

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

第二題：什么是突發(fā)，什么是噪音？

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

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

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

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

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

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

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

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

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

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

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

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

七個輸入?yún)?shù)：錯一個，代價具體

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

參數(shù)一：請求并發(fā)（Request concurrency）

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

典型場景：測試環(huán)境測出單卡QPS為100，直接乘以目標QPS得出卡數(shù)。上線后發(fā)現(xiàn)生產(chǎn)環(huán)境的輸入序列長度分布完全不同，實際單卡QPS只有35。

參數(shù)二：隊列深度（Queue depth）

關(guān)鍵問題：多少任務排隊之前會變成延遲問題？

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

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

參數(shù)三：突發(fā)特征（Burst profile）

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

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

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

參數(shù)四：延遲容忍度（Latency tolerance）

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

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

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

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

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

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

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

把兩者塞進同一個調(diào)度策略，結(jié)果通常是兩邊都不滿意。

參數(shù)六：顯存駐留時間（VRAM residency time）

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

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

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

參數(shù)七：任務持續(xù)時間方差（Job duration variance）

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

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

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

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

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

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

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

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

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

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

為什么這件事現(xiàn)在特別重要

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

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

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

調(diào)度器是執(zhí)行層，不是戰(zhàn)略層。戰(zhàn)略層的錯誤，執(zhí)行層補不回來。