vLLM解密：DeepSeek-V4本地部署為何如此困難

一、官方部署 Recipe：先看硬件門檻

vLLM 團隊這次同時放出 V4-Pro（1.6T）和 V4-Flash（284B）兩個型號的部署 Recipe 先

說結論：門檻勸退

V4-Flash 單節點最簡部署（B200/B300 各 4 卡）：

docker run --gpus all \
  --ipc=host -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:deepseekv4-cu130 deepseek-ai/DeepSeek-V4-Flash \
  --trust-remote-code \
  --kv-cache-dtype fp8 \
  --block-size 256 \
  --enable-expert-parallel \
  --data-parallel-size 4 \
  --compilation-config '{"cudagraph_mode":"FULL_AND_PIECEWISE", "custom_ops":["all"]}' \
  --attention_config.use_fp4_indexer_cache=True \
  --tokenizer-mode deepseek_v4 \
  --tool-call-parser deepseek_v4 \
  --enable-auto-tool-choice \
  --reasoning-parser deepseek_v4

V4-Pro 版本一樣的形態，區別只是 --data-parallel-size 8，跑在 8×B200 或 8×B300 上

• 鏡像 deepseekv4-cu130（129也可以） ，需要 CUDA 13.0；

• KV cache 直接 FP8， block-size 256 是硬規定，下面會解釋為什么；

• --attention_config.use_fp4_indexer_cache=True 是 V4 獨有的 FP4 indexer cache 開關；

• tokenizer / tool call / reasoning parser 全是 deepseek_v4 專屬新解析器，老的 V3 那套解析器不通用

Recipe 里更狠的是 H200 單節點 PD 解耦部署：4 張 GPU 跑 prefill、4 張跑 decode，中間走 MooncakeConnector + RDMA 傳 KV，外面再掛一個 vllm-router 做輪詢：

pip install vllm-router


 vllm-router --policy round_robin \
  --vllm-pd-disaggregation \
  --prefill http://localhost:8000 \
  --decode http://localhost:8001 \
  --host 127.0.0.1 \
  --port 30000 \
  --intra-node-data-parallel-size 4 \
  --kv-connector mooncake

Flash 還有三檔推理強度，對應技術報告里的 Non-think / Think High / Think Max：

from openai import OpenAI

 client = OpenAI(base_url="http://localhost:8000/v1", api_key="EMPTY")
model = "deepseek-ai/DeepSeek-V4-Flash"
messages = [{"role": "user", "content": "What is 17*19? Return only the final integer."}]

 # Think Max 檔要求 max-model-len >= 393216
resp = client.chat.completions.create(
    model=model,
    messages=messages,
    extra_body={
        "chat_template_kwargs": {
            "thinking": True,
            "reasoning_effort": "max",
        },
    },
)

官方推薦采樣：temperature = 1.0, top_p = 1.0。

Think Max 檔要求 --max-model-len >= 393216（384K tokens），低于這個數會被截斷

二、注意力機制為什么這么麻煩

長上下文推理的兩個老大難：

• KV cache 顯存爆炸 ：標準 MHA / MQA 的 KV 隨上下文線性增長，到 1M 直接撐爆。MLA 已經把這個問題壓了一檔，但 1M 還是頂

• 注意力計算昂貴 ：即便有 DSA（DeepSeek Sparse Attention），1M 上的注意力計算依然是大頭

V4 的解法是在 MLA 之上又疊了 4 層結構：

1. Key 和 Value 共享 ：直接 2× 顯存節省，但為了保持 RoPE 的相對位置正確性，要在 attention 輸出端補一個 inverse RoPE ；

2. 跨 token 壓縮 KV （4× 到 128× 節省），分兩種：

   • ** c4a **：壓縮比約 1/4，每個壓縮 token 是 8 個原始 token 的加權和，stride = 4；

   • ** c128a **：壓縮比約 1/128，每個壓縮 token 是 128 個原始 token 的加權和，stride = 128；

3. DSA 稀疏選擇 ：即使壓縮到 1/4，1M 上下文也還有 25 萬壓縮 token，再用 DSA 選 top-k 參與計算（V4-Flash 在 c4a 上 k=512，c128a 上 k=8192）；

4. 保留局部性 ：滑動窗口 SWA，window size = 128 跑在未壓縮的原始 token 上，讓 query 在到達壓縮邊界之前還能看到本地信息

CSA 的結構是先壓縮再稀疏，每 m 個 token 的 KV 被壓成一條，再走 DSA 選 top-k：

CSA 結構：先壓縮再稀疏

HCA 的壓縮比更激進，m'=128，走稠密注意力：

HCA 結構：更重的壓縮

vLLM 博客給了一段 c4a 處理 13 個 token 的動畫，把上面四步的連鎖關系展示得很清楚：

c4a 注意力機制動畫：展示壓縮→稀疏選擇→局部窗口的完整流程

最后效果：bf16 KV Cache 在 1M 上下文下每序列 9.62 GiB，比 V3.2 那個 61 層堆疊估算的 83.9 GiB 小 8.7×；indexer 用 fp4、attention 用 fp8 之后再砍一半，比 bf16 估算再 2× 節省

下圖是 vLLM 官方對 V3.2 和 V4 每層 KV 狀態的直觀對比：

V3.2 與 V4 逐層 KV 狀態對比，V4 的壓縮效果一目了然

? 引用 vLLM 博客原文：DeepSeek V4 only has 9.62 GiB KV cache per sequence at 1M context. That is about 8.7x smaller than the 83.9 GiB estimate for a 61-layer DeepSeek V3.2-style stack.

但是省下來的顯存不是白省的——這套混合注意力讓"KV cache 管理"這件事的復雜度爆炸式增長：

• 同一個 attention kernel，prefill 用 bf16 KV cache，decode 用部分 token-wise fp8；

• 模型里同時存在 c4a、c128a、純 SWA 三種層，KV cache 管理要兼容三種壓縮比；

• 同一個 batch 里多條 sequence，相對于壓縮邊界的狀態可能不同；

• 模型權重原生就是 fp4 MoE，需要 vLLM 專門處理

vLLM 的優化分兩條線：顯存管理和內核效率

3.1 顯存：把 KV Cache 壓緊

(1) 統一邏輯塊大小為 256 個原生 token

不同層壓縮比不同（c4a 是 1/4、c128a 是 1/128、SWA 是 1/1）。一個樸素思路是按"壓縮后 entry 數"湊整，但那樣每層 page layout 都不一樣，allocator 要分別處理

vLLM 的選擇是：把邏輯塊在所有壓縮層統一釘死在 256 個原生 token 位置。這樣 c4a 塊物理上裝 256/4 = 64 條壓縮 entry，c128a 塊裝 256/128 = 2 條。分配一個塊永遠意味著預留下一個 256 原生位置，slot mapping、調度器記賬、prefix-hit 檢測全都不用 branch on compress_ratio

這就是為什么 Recipe 里 --block-size 256 是硬規定

(2) 把壓縮器殘差狀態當成 SWA

每個壓縮器層每個請求維護一個滾動殘差：c4a 是 8 個 token（帶 overlap）的部分狀態，c128a 是 128 個 token。直覺是放"每請求側 buffer"里，但這樣會讓 prefix caching 要在每個可緩存邊界做快照、PD 解耦要新增一條殘差傳輸路徑——又給系統多堆一層狀態

vLLM 的做法是把壓縮器狀態注冊成 sliding-window KV cache，sliding_window = coff × compress_ratio（c4 是 8、c128 是 128）。一來 prefix caching 直接復用塊語義；二來 PD 解耦把殘差當 SWA 傳，省下來的傳輸大小不變；三來 CUDA graphs / MTP 跟 SWA 走同一條集成路徑

(3) Page size 三桶歸一

c4 indexer 塊、c128a KV 塊、c4a 壓縮器狀態塊還是不一樣大。如果每種都自己一個 block pool，跨池碎片化又回來了

vLLM 注意到 page size = block_size × compress_ratio × per_entry_size，三個因子都可控。仔細挑參數之后整個五路緩存棧被壓成 3 個 page-size 桶，每個桶一個 block pool：

• 最大桶 ：c4a 主 KV、SWA KV、c4a 壓縮器狀態、c128a 壓縮器狀態；

• 中桶 ：c4 indexer KV、c4 indexer 壓縮器狀態；

• 最小桶 ：c128a 主 KV

加載時一次性 size 好，運行時只是桶查找——零運行時重分區、零按種類記賬、零跨緩存碎片

下圖展示了 V4 異構 KV Cache 的整體布局，State Cache 和 KV Cache 兩級結構如何共存：

異構 KV Cache 兩級布局：State Cache 存 SWA 與尾部未壓縮 token，KV Cache 按塊存 CSA/HCA 壓縮結果 3.2 內核：把 GPU 喂飽

顯存安排好之后，問題變成"這個模型 decode 路徑上有一堆小的、內存受限的內核，啟動開銷和 HBM 來回都要省"

vLLM 的回答是內核融合 + 多流并發

下圖是 c4a decode 路徑的完整算子圖，彩色輪廓標出了三處融合，藍色帶是 default stream，琥珀色帶是 indexer stream：

c4a decode 路徑：內核融合（彩色輪廓）與多流分區（藍色=default stream，琥珀色=indexer stream）

三個融合：

• Compressor + RMSNorm + RoPE + cache 寫入 ：壓縮之后 K 立刻走 RMSNorm、RoPE、寫入下一層 attention 的 KV cache（主 attention 或者 indexer），全是 elementwise，融成一個 kernel。indexer K cache 和主 attention K cache 仍保留各自的 kernel 以便對每個 head dim 單獨調并行策略。 1.4-3× 加速

• Inverse RoPE + fp8 quant ：主 attention 輸出之后過 inverse RoPE，再進 o_lora 投影的 fp8 batched matmul。兩步融了之后省一次 HBM 來回，算術強度抬上去。 2-3× 加速

• Fused Q norm + KV RoPE + K insert ：主 attention 之前的 query 和未壓縮 SWA key 那段 elementwise 工作，做 horizontal fusion，按 warpID 靜態分派到 Q head 或 K head，不用跨 warp 通信。 10-20× 加速

多流并發：

主 attention 之前可拆成三件事——indexer 計算、主 attention KV 壓縮、SWA token 插入。投影之后這三條幾乎獨立，所以走多 CUDA stream 并發

• c128a 層 沒有 indexer，主 KV 壓縮跟 SWA token 插入并發；

• c4a 層 完整 indexer 流水線在自己的 stream 上跟主 KV 壓縮、SWA 插入并發（后兩者之間還是串行）

實測低 batch 下端到端延遲降低 5-6%。疊加 CUDA Graph 把 launch 開銷也壓下去

完整實現是 vLLM 這個 PR：#40760

vLLM 團隊也寫了下一步要做的優化方向：DeepGEMM MegaMoE 內核、Paged prefill 內核。當前實現主要面向 NVIDIA Hopper 和 Blackwell。

靠著 vLLM 的插件系統，vllm-ascend（華為昇騰）和 vllm-mlu（寒武紀）已經獨立支持上 V4

四、總結

回到標題——為什么 V4 本地部署如此困難？

不是 vLLM 不給力，是模型本身把"如何用最少的顯存裝下 1M 上下文"這件事做到了極致：MLA 之上疊 K/V 共享 + 雙層 KV 壓縮（c4a + c128a）+ DSA + SWA，再疊 fp4 indexer + fp8 attention cache。每多一層都是一次工程債，所有的債都得 vLLM 這一側的 KV cache allocator、kernel fusion、多流調度還

最后落到普通用戶能感知的就是 Recipe 第一行：起步 4 張 B200/B300，單節點最簡部署，pip 裝個 vllm-router 還得自己起兩個 docker

我的判斷：

• 個人用戶、消費級顯卡、本地離線跑 V4 這件事，短期內別想了；

• 真正能吃到 V4 紅利的是有 H200/B200 集群、又需要 1M 上下文 + agent 工作流的團隊，比如做長文檔分析、多輪 agent 任務的 infra 團隊；

• 想理解 V4 推理實現的細節，vLLM 這篇博客 + Recipe + PR 是目前最干凈的官方解釋，比對著技術報告讀更直觀

制作不易，如果這篇文章覺得對你有用，可否點個關注。給我個三連擊：點贊、轉發和在看。若可以再給我加個，謝謝你看我的文章，我們下篇再見！