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