DeepSeek-V4 本地部署，SGLang 把活做絕了

關于 DeepSeek-V4，我之前寫過：

今天換個角度，從架構和推理引擎的視角聊聊：DeepSeek-V4 這次發布為啥這么難伺候，以及 SGLang Day-0 是怎么把活給做下來的

V4 到底改了啥

先簡單交代下背景，DeepSeek 這次一發就是倆：

變體

總參數

激活參數

單節點部署門檻

DeepSeek-V4-Flash

284B

13B

B200 / GB200 / GB300 / H200 4 卡

DeepSeek-V4-Pro

1.6T

49B

B200 8 卡 / GB200 8 卡（2 節點）/ GB300 4 卡 / H200 8 卡（FP4）

兩個版本的 Instruct 都是 FP4 MoE 專家權重 + FP8 注意力/dense 的混合精度 checkpoint，一份權重通吃所有支持 FP4 的卡，這一手就把 Hopper、Blackwell、AMD、NPU 全打通了，MIT 協議，1M 上下文，32T+ token 預訓練

真正狠的是架構層，三件套：

• 混合稀疏注意力（CSA + HCA） ：每一層都把 SWA（128 token 滑動窗口）和兩種壓縮機制之一組合起來——要么是 C4 （4:1 壓縮 + top-512 稀疏），要么是 C128 （128:1 壓縮 + dense），在 1M 上下文場景，V4-Pro 每 token 推理 FLOPs 只有 V3.2 的 27%，KV cache 只有 10%

• mHC（流形約束超連接） ：把傳統殘差連接換成一組并行分支的混合，配 Sinkhorn 歸一化生成混合權重，梯度流和表征質量雙雙拉升

• 原生 FP4 專家權重 ：直接吃 Blackwell 的 FP4 張量核心紅利，小批次 decode 場景不再被 MoE 權重帶寬卡死

外加一個讓推理框架頭疼的小細節：V4 給了一個單層 MTP head做投機解碼，而且 reasoning 分了三檔——Non-think（直覺響應）、Think High（鏈式推理）、Think Max（推到極限，建議 ≥384K 上下文窗口）

下圖一張圖說清楚 V4 每層注意力的工作范圍（N=1024 的例子）：

V4 每層混合注意力作用域 SGLang 干了什么硬活

V4 的混合注意力最難受的地方是：3 套異構 KV 池 + 2 套壓縮狀態池，要在 prefill / decode / 投機解碼三種 pass 之間保持一致性換句話說，傳統的 prefix cache 假設直接報廢了

SGLang 這次的活兒，密度相當高，挑幾個關鍵的看：

ShadowRadix：給混合注意力的原生前綴緩存

核心思路一句話：用一棵基數樹索引"虛擬全 token 槽"，再把它投影成各物理池的影子（SWA / C4 / C128），壓縮狀態環形緩沖嵌套在 SWA 頁索引里，地址公式是 swa_page * ring_size + pos % ring_size，SWA 頁一釋放、ring 自動失效，零額外追蹤成本

每個節點帶倆計數器：full_lock_ref 管 source 和 C4/C128 影子，swa_lock_ref 只管滑動窗口SWA 計數清零就直接 tombstone 掉 SWA 槽，但節點本身和壓縮影子還在樹上繼續被復用——一個 1 萬 token 的請求最終只占 128 個 SWA token + 完整 C4/C128，前綴復用的就是這塊壓縮 KV

下圖是 ShadowRadix 的存儲布局：

ShadowRadix 存儲布局

投機解碼這塊還有個隱藏陷阱：draft token 在 verify 之前就先寫進了 ring，萬一被拒絕重試就可能繞一圈覆蓋活窗口里的槽，SGLang 的解法很樸素——spec 模式下把 ring size 翻倍（C4: 8→16, C128: 128→256），EAGLE 直接 work out of the box

HiSparse：把不活躍 KV 甩到 CPU

C4 層的特點是 indexer 每步只 top-k 一小撮壓縮位置，絕大多數 KV 在任意時刻都是非活躍的——典型的可以下沉到 CPU 的場景，HiSparse 給 C4 KV 池單獨掛了一份固定在 CPU 的鏡像，GPU 只留小工作集，每步由 Coordinator 異步換頁，按 LRU 淘汰

效果是 V4-Flash 在 2×B200 上跑 200K 輸入 / 20K 輸出的長上下文場景，峰值吞吐最高拉到 3 倍

HiSparse 架構與峰值吞吐

MTP 投機解碼 + 圖內元數據

混合注意力的 per-pass 元數據非常重——SWA 頁索引、影子映射、壓縮器/索引器的執行計劃、各池寫入位置——這些東西如果在調度器線程上 eager 準備，投機解碼下直接被啟動開銷吃干凈

SGLang 的做法是把元數據準備整個塞進 CUDA Graph，每次 replay 只拷貝原始 batch 狀態進固定 buffer，剩下的索引算術全在圖內 device kernel 里算，Python 完全不參與 per-pass 路徑配合 CPU 端的 overlap 調度（結果處理、batch 準備、釋放都和 GPU 執行并行），把投機解碼的啟動瓶頸壓到了底

最直觀的效果，看這張圖：

不同上下文長度的解碼吞吐

混合稀疏 + ShadowRadix + 圖內 spec 元數據三件套堆下來，SGLang 的解碼吞吐從 4K 一路平到 900K，逼近 1M 上下文窗口B200 從 199 token/s 跌到 180，H200 從 266 跌到 240，**兩邊掉幅都不到 10%**這個吞吐曲線的"平坦度"，是過去 long context 推理基本不敢想的

Kernel 層一堆狠活

簡單列下，每一項單拎出來都夠寫一篇：

• FlashMLA 新接口 ：SWA 和 extra attention（C4/C128）一次 kernel 調用搞完，metadata 在 forward 里共享

• Flash Compressor ：把壓縮注意力 5 次 HBM 往返壓成 1 次片上 pass（HBM 5→2），H200 上能吃滿 80% 峰值帶寬，比 naive PyTorch pipeline 快 10×+

• Lightning TopK ：1M 上下文下 indexer 要從 256K 候選里挑 top-512，naive 實現單 batch 都要 100us+，用 cluster-of-8 radix-select 替代全局排序， 壓到約 15us

• FlashInfer TRTLLM-Gen MoE ：MXFP8 激活 × MXFP4 專家權重，吃 Blackwell FP4 張量核心

• DeepGEMM Mega MoE ：把 EP dispatch + 第一次 FP8×FP4 GEMM + SwiGLU + 第二次 GEMM + EP combine 融成一個 mega kernel，NVLink 通信和張量核心計算重疊

• TileLang mHC kernels（帶 split-K） ：低延遲 decode 下 pre-GEMM 容易成瓶頸，split-K 把它救回來

• DP/TP/CP 注意力，DeepEP 上的 EP MoE，PD 解聚合部署 ：并行策略一應俱全

SGLang 給每個硬件平臺都準備了獨立 Docker 鏡像：

硬件

鏡像

NVIDIA B300

lmsysorg/sglang:deepseek-v4-b300

NVIDIA B200

lmsysorg/sglang:deepseek-v4-blackwell

NVIDIA GB200/GB300

lmsysorg/sglang:deepseek-v4-grace-blackwell

NVIDIA H200

lmsysorg/sglang:deepseek-v4-hopper

最小啟動命令長這樣：

docker run --gpus all \
    --shm-size 32g \
    -p 30000:30000 \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN= 
                
 " \ 
        
    --ipc=host \
    lmsysorg/sglang:deepseek-v4-blackwell \
    sglang serve 
        

具體的啟動參數，強烈建議用官方 cookbook 的交互式命令生成器

https://docs.sglang.io/cookbook/autoregressive/DeepSeek/DeepSeek-V4-1-basic-configuration

按照（硬件 × 變體 × 配方）選好直接出命令三種主推配方：

• low-latency ：MTP steps=3, draft-tokens=4，bs=1 時收益最大

• balanced ：MTP steps=1, draft-tokens=2，高 batch 下更平衡

• max-throughput ：直接關掉 MTP，飽和場景下 verify 比省下的更貴

外加兩個特化配方：cp（prefill 上下文并行，長上下文專用）、pd-disagg（prefill/decode 解聚合）

跑起來之后調用就是標準 OpenAI 兼容接口：

curl http://localhost:30000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-ai/DeepSeek-V4-Flash",
    "messages": [{"role": "user", "content": "What is 15% of 240?"}]
  }'

要 reasoning 分離，加上 deepseek-v4 reasoning parser，reasoning_content 和 content 自動分兩個字段；要 tool calling，掛 deepseekv4 解析器，結構化 tool calls 直接出

幾個坑要提醒

實戰部署的話，有幾個雷點直接看官方 cookbook，免得踩：

• DeepEP dispatch buffer ：必須滿足 max-running-requests × MTP_draft_tokens ≤ SGLANG_DEEPEP_NUM_MAX_DISPATCH_TOKENS_PER_RANK ，違反了穩態負載會直接炸 buffer，生成器給的默認值偏保守，跑通之后建議自己往上調

• Hopper（H200）雙方案 ：原始 FP4 checkpoint 走 Marlin w4a16 MoE kernel，只支持 TP，單節點能吃下完整 Pro；想要更多并行就用 SGLang 預轉的 FP8 checkpoint（ sgl-project/DeepSeek-V4-Flash-FP8 / Pro-FP8 ）

• PD-Disagg on H200 ： docker run 要帶 --privileged --ulimit memlock=-1 （或 --device /dev/infiniband:/dev/infiniband --cap-add IPC_LOCK ），不然 mooncake 拿不到 IB HCA 會靜默掉成 TCP，大 checkpoint 容易 KV 傳輸錯亂

• Base model ：用 base 必須 SGLANG_FIX_DSV4_BASE_MODEL_LOAD=1

• GB300 跨 pod NVLink ：mooncake 報 nvlink_transport.cpp:497 Requested address ... not found! 的話，prefill 和 decode 都加上 MC_FORCE_MNNVL=1 NCCL_MNNVL_ENABLE=1 NCCL_CUMEM_ENABLE=1

如果你對工程實現感興趣，主合并 PR 是 sgl-project/sglang#23600，從 V4Config 注冊、JIT kernel dtype map、FP8 weight postprocess、SM_120 上 MLA 的 Triton fallback、MXFP4 MoE 的 Marlin fallback……一路到具體的混合注意力 kernel，commits 寫得相當有教學意義，建議有時間拉下來過一遍

總結

DeepSeek 這次把架構層搞這么激進，其實是把"開源大模型怎么壓成本上長上下文"這個問題又往前推了一大步，1M 上下文做到 27% FLOPs、10% KV cache，是真的可以"把長上下文當默認能力賣"的水平

但代價是：所有推理引擎幾乎都得重寫 KV/緩存/注意力這條線，SGLang 這次能做到 Day-0，靠的是 ShadowRadix、HiSparse、圖內 spec 元數據、一票新 kernel 集成這一整套體系工程，不是一兩個補丁

從 LMSYS 公開的 Day-0 對比圖看，30K 上下文同口徑單批 decode 下，SGLang 明顯領先另一家開源引擎——而且對手在這個口徑里其實是帶傷上陣：B200 上 MTP-3 的 accept length 只有 1.19（SGLang EAGLE 是 2.5），H200 上 num_speculative_tokens≥2 直接踩 kernel assertion 起不來，只能降級到 MTP-1，長上下文 200K+ 干脆 timeout 跑不出來，不過 LMSYS 自己也聲明這是 Day-0 快照，不是定論排名，等社區把另一家的配置調通之后再看也不遲

更扎實的數字其實是 SGLang 自己的縱向吞吐曲線：B200 上 V4-Pro 從 4K 一路平到 900K，從 199 token/s 跌到 180；H200 上 V4-Flash 從 266 跌到 240，**兩邊掉幅都不到 10%**，這個吞吐曲線的"平坦度"才是真正能落地長上下文的關鍵

至于到底好不好用，等手上的卡再倒騰倒騰，回頭再來一篇真機評測

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