權重裝進了 24 GiB四路 32K 上下文還裝得下嗎模型權重已經加載短問題也能回答于是把服務目標改成四路長上下文。接下來遇到的卻是緩存不足、請求等待或者在某個峰值階段顯存不夠。第一反應往往是“權重才占一部分剩下的顯存為什么不夠”加載成功只驗證了當時那筆開銷。生成中的歷史信息也要留在 GPU 上運行時還會需要臨時空間。要判斷四路長請求是否可行需要回答的是扣掉權重和非緩存峰值后每張卡到底還有多少空間能夠同時保留多少 token 的 KV下面用 Qwen2.5-7B-Instruct 的公開配置算一筆賬。24 GiB 顯存、權重與運行開銷都是明確設定的教學條件沒有加載該模型、運行 vLLM 或做 GPU 壓測。算式用于排除不成立的容量承諾不作為這款模型在某張顯卡上的實測結果。先從每張卡的預算里扣掉非 KV 開銷先固定單位1 GB 是 10? 字節(jié)1 GiB 是 23? 字節(jié)。本文的 24 GiB 指假設運行時可見總量恰為 24 × 23? 字節(jié)不是把任何廠商標稱的“24 GB”直接代入。實際機器應讀取字節(jié)數(shù)再換算。對某一張 GPU先寫一個用于規(guī)劃的簡式可規(guī)劃的 KV 空間 ≈ 本實例顯存預算 ? 本卡權重 ? 其他非 KV 峰值預留“其他”包括該執(zhí)行配置下的激活與臨時工作區(qū)、圖捕獲等非權重開銷不能用空閑時截圖代替峰值。若權重已經單列其他項就不要再把同一權重算一遍。這里是分賬方法不是保證每項峰值會在相同時刻達到最大也不是某個版本內部變量的逐一映射。vLLM v0.28.0 的自動預算路徑提供了直接證據。在 GPU Worker 源碼中KV 可用量的計算包含下面三項self.requested_memory-profile_result.non_kv_cache_memory-cudagraph_memory_estimate_applied這是賦值表達式中的連續(xù)項省略了外側變量和括號不能單獨運行。它說明引擎會從請求的預算里扣除已分析的非 KV 開銷及適用的 CUDA Graph 估算而不是把權重加載后看見的全部空閑量直接交給緩存。vLLM GPU Worker 源碼現(xiàn)在設定單卡 24 GiB顯式選擇利用率參數(shù) 0.9權重預算記為 15 GiB其他非 KV 峰值預留 2 GiB。后兩項只是本例輸入不是 Qwen 官方公布或本文測得的占用真實部署必須用當前精度、加載布局與執(zhí)行配置重新測量。也沒有用模型名里的“7B”乘兩字節(jié)冒充精確運行時權重。于是本例得到實例預算 24 × 0.9 21.6 GiB KV 規(guī)劃空間 21.6 ? 15 ? 2 4.6 GiB預算外的 2.4 GiB 不再重復算作 KV 可用空間。本例也沒有把它承諾為能抵擋任意峰值的安全保證。這里的 0.9 是主動設定。核驗時 v0.28.0 文檔默認值為 0.92gpu_memory_utilization描述當前實例的預算比例不是監(jiān)控面板上的 GPU 忙碌百分比。另一個參數(shù)kv_cache_memory_bytes直接指定每 GPU的 KV 字節(jié)量設置后會忽略前述比例的自動預算方式不能把兩者當成可疊加的額度。引擎參數(shù)說明四路 32K需要緩存的是 131,072 個 tokenKV Cache 保存后續(xù)生成還會使用的注意力 Key 和 Value。對普通全注意力、相同結構的各層采用相同 K/V 維度和精度、不考慮共享時可以從數(shù)據形狀推導KV 字節(jié)數(shù) 2 × 層數(shù) × KV head 數(shù) × head 維度 × 每元素字節(jié) × 已緩存 token 總數(shù)開頭的 2 是 Key 與 Value。并發(fā)序列長度不同時總 token 數(shù)應該逐條相加。它既不是本輪新計算的 token 數(shù)也不只是輸入長度已處理的 prompt 和生成歷史都可能占緩存。隊列里尚未獲得 KV 的請求則不能按“已駐留”重復計入。Qwen 官方配置給出了這個例子需要的原始字段hidden_size:3584,num_attention_heads:28,num_hidden_layers:28,num_key_value_heads:4這四行從配置不同位置選取非連續(xù)摘錄。由此得到 head 維度 3584 ÷ 28 128GQA 使用 4 個 KV heads不能把 28 個 Query heads 代入 KV 公式。配置同時記錄use_sliding_window: false本例不套用滑動窗口緩存縮減。Qwen2.5-7B-Instruct 配置再明確選擇 BF16 KV每元素 2 字節(jié)不啟用 KV 量化、前綴共享或緩存卸載TP1、PP1。每 token 在完整模型各層合計需要2 × 28 × 4 × 128 × 2 57,344 字節(jié) 56 KiB若一個序列已經緩存 32,768 個 token就是 1.75 GiB。本文用“32K”指這 32,768 個已緩存總 token不是 32K 輸入之外還免費附送輸出空間。四條這樣的序列合計 131,072 個 tokenKV 為 7 GiB。同時駐留的序列狀態(tài)總緩存 token理想 KV 量1 條各 32,76832,7681.75 GiB2 條各 32,76865,5363.5 GiB3 條各 32,76898,3045.25 GiB4 條各 32,768131,0727 GiB與 4.6 GiB 預算比較第三條已經超過四條更缺 2.4 GiB。權重能加載與這組請求不能全部保持目標 KV 狀態(tài)可以同時成立。表中是張量載荷的理想值不含塊取整、對齊等實現(xiàn)成本不能把“3.5 小于 4.6”寫成兩路一定能穩(wěn)定服務。vLLM 的緩存規(guī)范按塊描述存儲實際可用塊數(shù)仍要從引擎配置和啟動結果確認。KV Cache 存儲規(guī)范反過來四條連接也不意味著始終占 7 GiB。它們若尚未增長到目標長度實際用量會較小。本表問的是目標狀態(tài)能否同時駐留不能拿短輸入試通的結果證明長尾請求組合也成立。當前配置的上下文上限是另一個限制本例只算到配置中 32,768 的量級不宣稱完成上下文擴展。加一張卡之前先看 KV 實際分到了哪里兩張卡的總顯存可以寫在資產表里但同一個緩存分配不會自動跨進另一張卡的空閑區(qū)。容量計算必須落實到每個執(zhí)行 rank——參與執(zhí)行的進程及其設備——所持有的權重、層和 KV heads。若第二張卡運行另一個完整副本它會重新承擔該副本的權重和運行開銷。它能接走別的請求卻不會替第一張卡保存一條請求缺少的 KV。因此不能把“2 × 24 GiB”直接替換進剛才單副本的算式。若采用 TP并且模型與實現(xiàn)允許按 KV heads 均勻切分本例 4 個 KV heads 在 TP2 時每 rank 兩個在 TP4 時每 rank 一個。只看同一組四路 32K 的 KV 載荷每 rank 分別是 3.5 GiB 和 1.75 GiB。這里僅說明 KV 分賬變化權重、其他峰值和通信開銷要按新的布局重新記錄不能假設所有項目一律除以 TP。尤其不能無限除下去。vLLM 的QKVParallelLinear在 TP 數(shù)量不小于 KV head 總數(shù)時把本 rank 的 KV head 數(shù)設為 1并計算 head 的復制份數(shù)。也就是說適用這種路徑的 GQA 模型可能復制 KV heads而不是把一個 head 繼續(xù)切成任意小數(shù)。QKV 并行層源碼候選并行度還要滿足 Query heads 等切分限制本例有 28 個 Query heads不能見到八張卡就直接列 TP8 的均分預算。這里不推薦更大 TP只要求先核實實際布局再把每 rank 的 KV 數(shù)填回公式。采用 PP 時同樣應使用本 rank 真正持有的層而不是只用整機總顯存蓋過局部超額。把“能加載”改成一份有條件的容量結論回到四路長請求的目標現(xiàn)在能夠寫出的結論是“在 24 GiB、0.9、15 GiB 權重和 2 GiB 其他預留這些假設下BF16 KV 的 7 GiB 理想需求超過 4.6 GiB 預算?！彼阋苑駴Q這組假設下的同時駐留承諾卻不足以宣布某個具體 GPU 必然 OOM。引擎可能通過等待或搶占等方式維持運行。vLLM 優(yōu)化文檔說明 KV 空間不足可能觸發(fā)搶占這不等同進程必然崩潰也不說明請求延遲仍能滿足目標。vLLM 搶占說明下一次調整只需圍繞這張容量賬改一筆并重算。減少同時駐留的長度或數(shù)量會降低 KV 需求但也縮小服務承諾改變權重表示只會直接影響權重一項不自動改變選定的 BF16 KV。選擇更低精度 KV則必須重新核實模型、后端支持與質量不能把理想字節(jié)減半直接稱為可上線收益。增加設備則要重新核實分片與復制而非相加總顯存。最終保留一份按 rank 的記錄設備可見字節(jié)、模型配置與精度、預算方式、實測權重、當前負載下的非 KV 峰值、引擎可用 KV 塊以及目標序列長度總和。把本例的假設字段逐個換成實際證據才知道缺口究竟在權重、臨時峰值還是活躍緩存。容量賬通過后仍要用目標輸入輸出長度與并發(fā)檢查延遲、失敗和內存峰值這里沒有完成這一步。它的價值是讓測試從一個明確的可行候選開始而不是從“權重加載成功所以四路長上下文應該也行”開始。 權重裝進了 24 GiB，四路 32K 上下文還裝得下嗎？
權重裝進了 24 GiB四路 32K 上下文還裝得下嗎模型權重已經加載短問題也能回答于是把服務目標改成四路長上下文。接下來遇到的卻是緩存不足、請求等待或者在某個峰值階段顯存不夠。第一反應往往是“權重才占一部分剩下的顯存為什么不夠”加載成功只驗證了當時那筆開銷。生成中的歷史信息也要留在 GPU 上運行時還會需要臨時空間。要判斷四路長請求是否可行需要回答的是扣掉權重和非緩存峰值后每張卡到底還有多少空間能夠同時保留多少 token 的 KV下面用 Qwen2.5-7B-Instruct 的公開配置算一筆賬。24 GiB 顯存、權重與運行開銷都是明確設定的教學條件沒有加載該模型、運行 vLLM 或做 GPU 壓測。算式用于排除不成立的容量承諾不作為這款模型在某張顯卡上的實測結果。先從每張卡的預算里扣掉非 KV 開銷先固定單位1 GB 是 10? 字節(jié)1 GiB 是 23? 字節(jié)。本文的 24 GiB 指假設運行時可見總量恰為 24 × 23? 字節(jié)不是把任何廠商標稱的“24 GB”直接代入。實際機器應讀取字節(jié)數(shù)再換算。對某一張 GPU先寫一個用于規(guī)劃的簡式可規(guī)劃的 KV 空間 ≈ 本實例顯存預算 ? 本卡權重 ? 其他非 KV 峰值預留“其他”包括該執(zhí)行配置下的激活與臨時工作區(qū)、圖捕獲等非權重開銷不能用空閑時截圖代替峰值。若權重已經單列其他項就不要再把同一權重算一遍。這里是分賬方法不是保證每項峰值會在相同時刻達到最大也不是某個版本內部變量的逐一映射。vLLM v0.28.0 的自動預算路徑提供了直接證據。在 GPU Worker 源碼中KV 可用量的計算包含下面三項self.requested_memory-profile_result.non_kv_cache_memory-cudagraph_memory_estimate_applied這是賦值表達式中的連續(xù)項省略了外側變量和括號不能單獨運行。它說明引擎會從請求的預算里扣除已分析的非 KV 開銷及適用的 CUDA Graph 估算而不是把權重加載后看見的全部空閑量直接交給緩存。vLLM GPU Worker 源碼現(xiàn)在設定單卡 24 GiB顯式選擇利用率參數(shù) 0.9權重預算記為 15 GiB其他非 KV 峰值預留 2 GiB。后兩項只是本例輸入不是 Qwen 官方公布或本文測得的占用真實部署必須用當前精度、加載布局與執(zhí)行配置重新測量。也沒有用模型名里的“7B”乘兩字節(jié)冒充精確運行時權重。于是本例得到實例預算 24 × 0.9 21.6 GiB KV 規(guī)劃空間 21.6 ? 15 ? 2 4.6 GiB預算外的 2.4 GiB 不再重復算作 KV 可用空間。本例也沒有把它承諾為能抵擋任意峰值的安全保證。這里的 0.9 是主動設定。核驗時 v0.28.0 文檔默認值為 0.92gpu_memory_utilization描述當前實例的預算比例不是監(jiān)控面板上的 GPU 忙碌百分比。另一個參數(shù)kv_cache_memory_bytes直接指定每 GPU的 KV 字節(jié)量設置后會忽略前述比例的自動預算方式不能把兩者當成可疊加的額度。引擎參數(shù)說明四路 32K需要緩存的是 131,072 個 tokenKV Cache 保存后續(xù)生成還會使用的注意力 Key 和 Value。對普通全注意力、相同結構的各層采用相同 K/V 維度和精度、不考慮共享時可以從數(shù)據形狀推導KV 字節(jié)數(shù) 2 × 層數(shù) × KV head 數(shù) × head 維度 × 每元素字節(jié) × 已緩存 token 總數(shù)開頭的 2 是 Key 與 Value。并發(fā)序列長度不同時總 token 數(shù)應該逐條相加。它既不是本輪新計算的 token 數(shù)也不只是輸入長度已處理的 prompt 和生成歷史都可能占緩存。隊列里尚未獲得 KV 的請求則不能按“已駐留”重復計入。Qwen 官方配置給出了這個例子需要的原始字段hidden_size:3584,num_attention_heads:28,num_hidden_layers:28,num_key_value_heads:4這四行從配置不同位置選取非連續(xù)摘錄。由此得到 head 維度 3584 ÷ 28 128GQA 使用 4 個 KV heads不能把 28 個 Query heads 代入 KV 公式。配置同時記錄use_sliding_window: false本例不套用滑動窗口緩存縮減。Qwen2.5-7B-Instruct 配置再明確選擇 BF16 KV每元素 2 字節(jié)不啟用 KV 量化、前綴共享或緩存卸載TP1、PP1。每 token 在完整模型各層合計需要2 × 28 × 4 × 128 × 2 57,344 字節(jié) 56 KiB若一個序列已經緩存 32,768 個 token就是 1.75 GiB。本文用“32K”指這 32,768 個已緩存總 token不是 32K 輸入之外還免費附送輸出空間。四條這樣的序列合計 131,072 個 tokenKV 為 7 GiB。同時駐留的序列狀態(tài)總緩存 token理想 KV 量1 條各 32,76832,7681.75 GiB2 條各 32,76865,5363.5 GiB3 條各 32,76898,3045.25 GiB4 條各 32,768131,0727 GiB與 4.6 GiB 預算比較第三條已經超過四條更缺 2.4 GiB。權重能加載與這組請求不能全部保持目標 KV 狀態(tài)可以同時成立。表中是張量載荷的理想值不含塊取整、對齊等實現(xiàn)成本不能把“3.5 小于 4.6”寫成兩路一定能穩(wěn)定服務。vLLM 的緩存規(guī)范按塊描述存儲實際可用塊數(shù)仍要從引擎配置和啟動結果確認。KV Cache 存儲規(guī)范反過來四條連接也不意味著始終占 7 GiB。它們若尚未增長到目標長度實際用量會較小。本表問的是目標狀態(tài)能否同時駐留不能拿短輸入試通的結果證明長尾請求組合也成立。當前配置的上下文上限是另一個限制本例只算到配置中 32,768 的量級不宣稱完成上下文擴展。加一張卡之前先看 KV 實際分到了哪里兩張卡的總顯存可以寫在資產表里但同一個緩存分配不會自動跨進另一張卡的空閑區(qū)。容量計算必須落實到每個執(zhí)行 rank——參與執(zhí)行的進程及其設備——所持有的權重、層和 KV heads。若第二張卡運行另一個完整副本它會重新承擔該副本的權重和運行開銷。它能接走別的請求卻不會替第一張卡保存一條請求缺少的 KV。因此不能把“2 × 24 GiB”直接替換進剛才單副本的算式。若采用 TP并且模型與實現(xiàn)允許按 KV heads 均勻切分本例 4 個 KV heads 在 TP2 時每 rank 兩個在 TP4 時每 rank 一個。只看同一組四路 32K 的 KV 載荷每 rank 分別是 3.5 GiB 和 1.75 GiB。這里僅說明 KV 分賬變化權重、其他峰值和通信開銷要按新的布局重新記錄不能假設所有項目一律除以 TP。尤其不能無限除下去。vLLM 的QKVParallelLinear在 TP 數(shù)量不小于 KV head 總數(shù)時把本 rank 的 KV head 數(shù)設為 1并計算 head 的復制份數(shù)。也就是說適用這種路徑的 GQA 模型可能復制 KV heads而不是把一個 head 繼續(xù)切成任意小數(shù)。QKV 并行層源碼候選并行度還要滿足 Query heads 等切分限制本例有 28 個 Query heads不能見到八張卡就直接列 TP8 的均分預算。這里不推薦更大 TP只要求先核實實際布局再把每 rank 的 KV 數(shù)填回公式。采用 PP 時同樣應使用本 rank 真正持有的層而不是只用整機總顯存蓋過局部超額。把“能加載”改成一份有條件的容量結論回到四路長請求的目標現(xiàn)在能夠寫出的結論是“在 24 GiB、0.9、15 GiB 權重和 2 GiB 其他預留這些假設下BF16 KV 的 7 GiB 理想需求超過 4.6 GiB 預算?！彼阋苑駴Q這組假設下的同時駐留承諾卻不足以宣布某個具體 GPU 必然 OOM。引擎可能通過等待或搶占等方式維持運行。vLLM 優(yōu)化文檔說明 KV 空間不足可能觸發(fā)搶占這不等同進程必然崩潰也不說明請求延遲仍能滿足目標。vLLM 搶占說明下一次調整只需圍繞這張容量賬改一筆并重算。減少同時駐留的長度或數(shù)量會降低 KV 需求但也縮小服務承諾改變權重表示只會直接影響權重一項不自動改變選定的 BF16 KV。選擇更低精度 KV則必須重新核實模型、后端支持與質量不能把理想字節(jié)減半直接稱為可上線收益。增加設備則要重新核實分片與復制而非相加總顯存。最終保留一份按 rank 的記錄設備可見字節(jié)、模型配置與精度、預算方式、實測權重、當前負載下的非 KV 峰值、引擎可用 KV 塊以及目標序列長度總和。把本例的假設字段逐個換成實際證據才知道缺口究竟在權重、臨時峰值還是活躍緩存。容量賬通過后仍要用目標輸入輸出長度與并發(fā)檢查延遲、失敗和內存峰值這里沒有完成這一步。它的價值是讓測試從一個明確的可行候選開始而不是從“權重加載成功所以四路長上下文應該也行”開始。