一、配置对比

对比两个模型在huggingface上的配置

DeepSeek-V4-Flash/config.json
DeepSeek-V4-Pro/config.json

配置	DeepSeek-V4-Flash	DeepSeek-V4-Pro
hidden_size：隐藏状态维度，也就是每个 token 在 Transformer 层之间传递的向量长度。	4096	7168
层数	43	61
注意力头数	64	128
n_routed_experts路由专家总数。	256	384
num_experts_per_tok每个 token 激活的 routed expert 数量。	6	6
moe_intermediate_size每个 routed expert 内部 FFN 的中间维度。	2048	3072
index_topk	512	1024
q_lora_rank：Query 的低秩 latent 维度。	1024	1536
o_groups	8	16
routed_scaling_factor：路由专家输出的缩放因子。	1.5	2.5
num_hidden_layers：Transformer block 的层数。	43	61
num_attention_heads：意力头数量。	64	128
expert_dtype:MOE专家权重	fp4	fp4

• 备注
  1.两者每个 token 激活的专家数相同。Flash 不是因为激活专家数更少而更小，而是因为：
  ①总专家数少：256 vs 384
  ②每个专家更窄
  ③层数更少
  ④hidden size 更小
  2.routed_scaling_factor是路由专家输出的缩放因子。
  作用：对 routed MoE 分支输出做整体缩放，用来平衡 routed experts 和 shared expert 的贡献。
  3.q_lora_rank：Query 的低秩 latent 维度
  作用：DSV4 先把 hidden state 压缩到这个 latent 空间，再恢复成 query heads。它类似 MLA 中的 query compression rank。

二、vLLM推理DSv4流程

总体流程

vllm serve <model_dir>
        |
        v
读取 <model_dir>/config.json
        |
        v
architecture = DeepseekV4ForCausalLM
        |
        v
vllm.models.deepseek_v4.nvidia.model.DeepseekV4ForCausalLM
        |
        +-- DeepseekV4Model
        |     +-- Embedding
        |     +-- N 个 DeepseekV4DecoderLayer
        |     +-- Norm
        |
        +-- LM Head
        +-- MoE 参数注册

1）读取config.json配置

而json配置填的模型架构是DeepseekV4ForCausalLM，DeepseekV4ForCausalLM在vLLM的注册里面填的类是

2）模型目录及ds模型类的函数解释

各个分支目录下model.py都是对应DeepseekV4ForCausalLM类的实现，Flash 和 Pro 都进入同一个类

这里主要看nvidia的

class DeepseekV4ForCausalLM(
    nn.Module,
    SupportsPP,
    SupportsEagle3,
    DeepseekV4MixtureOfExperts,
):

几个父类分别表示：

• nn.Module：PyTorch 模型基类。
• SupportsPP：支持 Pipeline Parallel。
• SupportsEagle3：支持 Eagle/MTP 类 speculative decoding。
• DeepseekV4MixtureOfExperts：提供 MoE 元数据和专家管理接口

hf_to_vllm_mapper这个类成员变量决定了加载配置里面读取到的MOE精度的权重，要读取的是FP4 还是 FP8 MoE 模型

函数	作用
__init__	构造整个语言模型，创建 Transformer 主体、LM Head、logits 处理器，并初始化 MoE 信息。类似 C++ 构造函数。
set_moe_parameters	扫描模型中的各层，收集 MoE 层、专家数量、本地专家数量等元数据，供专家并行和负载均衡使用。构造函数_init__里面调用
embed_input_ids	把 token ID 转换成 embedding 向量。
compute_logits	把 Transformer 输出的 hidden states 转换成词表上的 logits，用于预测下一个 token。
forward	执行模型主体的前向推理：embedding、Attention、MoE、残差和 Norm。它主要返回 hidden states，不直接负责 logits。
get_mtp_target_hidden_states	为 MTP/speculative decoding 提供目标模型保存的中间 hidden states，普通推理通常不用它。
load_weights	从 checkpoint 读取权重，进行参数名映射，并把权重加载到模型中。
get_expert_mapping	告诉 vLLM checkpoint 中的 MoE 专家权重应该对应到内部哪个专家、哪个权重分片。

get_expert_mapping() 做的事情类似一张表：

checkpoint 里的 experts.0.w1
    -> 第 0 个专家的 w1 权重

checkpoint 里的 experts.0.w2
    -> 第 0 个专家的 w2 权重

checkpoint 里的 experts.1.w1
    -> 第 1 个专家的 w1 权重

然后每个 worker 根据自己的身份判断：

我是 Worker 0
我负责专家0、专家1
所以只加载专家0、专家1的权重

我是 Worker 1
我负责专家2、专家3
所以只加载专家2、专家3的权重

但是它不负责推理时选择专家。

get_expert_mapping() 主要用于启动时的 checkpoint 权重加载；EPLB 重新平衡以后，worker 上专家的位置由 EPLB 的物理映射表维护，权重通过搬运完成，不会每次重新调用 get_expert_mapping()。

3）ds代码流程的推理过程

（1）模型加载流程

vLLM Engine
└── 根据 config.json 找到架构
    └── ModelRegistry
        └── DeepseekV4ForCausalLM
            └── __init__(vllm_config, prefix)
                ├── 读取 hf_config
                │   ├── hidden_size
                │   ├── num_hidden_layers
                │   ├── n_routed_experts
                │   └── 其他模型参数
                │
                ├── 创建 self.model
                │   └── DeepseekV4Model.__init__
                │       ├── 创建 Embedding
                │       ├── 创建 num_hidden_layers 个 DecoderLayer
                │       │   └── DeepseekV4DecoderLayer.__init__
                │       │       ├── 选择 Attention backend
                │       │       │   └── _select_dsv4_attn_cls
                │       │       │       ├── FlashMLA
                │       │       │       └── FlashInfer
                │       │       │
                │       │       ├── 创建 Attention
                │       │       │   └── DeepseekV4Attention.__init__
                │       │       │       ├── Query/Key/Value 投影
                │       │       │       ├── Indexer
                │       │       │       ├── Compressor
                │       │       │       └── KV Cache 相关对象
                │       │       │
                │       │       └── 创建 MoE
                │       │           └── DeepseekV4MoE.__init__
                │       │               ├── 创建 Router/Gate
                │       │               ├── 创建 Shared Expert
                │       │               └── 创建 Routed Experts
                │       │                   ├── FusedMoEFactory
                │       │                   └── 或 MegaMoE
                │       │
                │       └── 创建最终 RMSNorm
                │
                ├── 创建 lm_head
                │   └── ParallelLMHead
                │
                ├── 创建 logits_processor
                │   └── LogitsProcessor
                │
                └── set_moe_parameters()
                    ├── 找到所有 MoE 层
                    ├── 记录专家数量
                    ├── 记录本地专家数量
                    └── 保存 MoE 元数据

（2）模型推理流程

用户请求
└── Scheduler
    └── DeepseekV4ForCausalLM.forward
        └── DeepseekV4Model.forward
            │
            ├── 第一个 PP worker:
            │   └── embed_input_ids
            │       └── token ID -> hidden_states
            │
            ├── 非第一个 PP worker:
            │   └── 接收上一个 worker 的 hidden_states
            │
            └── 遍历 DecoderLayer
                └── DeepseekV4DecoderLayer.forward
                    │
                    ├── mHC attention 前处理
                    │
                    ├── DeepseekV4Attention.forward
                    │   ├── _run_parallel_input_projections
                    │   │   └── 计算 Q/K/V 相关投影
                    │   │
                    │   ├── Q/K RMSNorm
                    │   ├── RoPE
                    │   │
                    │   ├── Prefill:
                    │   │   └── 计算 prompt 并写入 KV Cache
                    │   │
                    │   └── Decode:
                    │       ├── 读取历史 KV Cache
                    │       ├── Indexer 选候选 token
                    │       ├── Compressor 处理压缩层
                    │       └── FlashMLA/FlashInfer 执行 Attention
                    │
                    ├── mHC FFN 前处理
                    │
                    └── DeepseekV4MoE.forward
                        ├── Router/Gate
                        │   └── 计算每个 token 的专家选择
                        │
                        ├── fused_topk_bias
                        │   └── 得到 top-k expert IDs
                        │
                        ├── 如果启用 EPLB
                        │   └── 逻辑 expert ID
                        │       -> 物理 expert 副本
                        │       -> 对应 worker
                        │
                        ├── Routed Experts.forward
                        │   └── 执行选中的专家
                        │
                        ├── Shared Expert.forward
                        │
                        └── 合并专家输出

三、dsv4模型部署

1）部署DeepSeek-V4-Flash-0731

前提：
手里至少有一张 80GB 以上显存的 GPU，或者一组多卡服务器。24GB 的消费级显卡只能实验性跑 INT4 量化加缩短上下文，别指望流畅。
能访问 HuggingFace；在大陆的话，能访问 ModelScope。权重约 160GB，动手前先确认磁盘和带宽够。

参数解释：

• 参数量：总参数 284B，每次推理只激活 13B。MoE 架构，仓库里全是货，每次只搬一小部分出来干活。
• 上下文长度：100 万 token
• 精度：FP4 + FP8 混合。MoE 专家参数用 FP4，其余大部分用 FP8，权重体积压得很狠，原始权重约 160GB。
• 投机解码：和 V4-Flash-DSpark 同结构，自带投机解码模块。草稿和主模型共用同一份权重，不用额外下载草稿模型，推理速度有加成。
• 推理档位：reasoning_effort 支持 low / high / max 三档，控制模型在回答前思考多久。本质上都是三档推理强度，只是新版改了名称。

Non-think — fast, intuitive responses.
Think High — explicit chain-of-thought for logical analysis and planning.
Think Max — maximum reasoning effort; requires --max-model-len >= 393216 (384K tokens) to avoid truncation.

增加字段

extra_body={
    "chat_template_kwargs": {
        "thinking": True,
        "reasoning_effort": "high",
    }
}

硬件配置

0731 不是消费级显卡能轻松带动的模型，官方部署示例就是单台 4×GB300。下面是几档现实可行的配置。

先给结论：严肃的本地推理，双卡 80GB 以上起步。只有一张 24GB 卡，只能 INT4 量化加限制上下文，实验性跑一跑，别指望流畅。
显存预算要留够 KV 缓存。有人按 160GB 权重 + 100 万 token 窗口算过，加 KV 和开销总共要 175GB。上下文越长，KV 缓存越大，把窗口缩到 128K 能省下一大块。

权重下载

模型权重在 HuggingFace 和 ModelScope 都有，MIT 协议，随便商用。

# 安装 HuggingFace 命令行工具
pip install huggingface_hub

# 下载 0731 正式版权重，约 160GB
huggingface-cli download deepseek-ai/DeepSeek-V4-Flash-0731 \
  --local-dir ./DeepSeek-V4-Flash-0731

大陆用户建议走 ModelScope，直接用 modelscope 命令行下载。

# 安装 ModelScope 工具
pip install modelscope

# 从魔搭下载，对国内网络友好
modelscope download --model deepseek-ai/DeepSeek-V4-Flash-0731 \
  --local_dir ./DeepSeek-V4-Flash-0731

部署服务方案

vllm部署详情页

核心配置说明

• DSpark 投机解码：0731 自带投机解码模块，用 --speculative-config 的 dspark 方法开启，num_speculative_tokens 设 7，draft 采样用 greedy。草稿和主模型共用权重，用更少的算力换更高的吞吐。
• FP4 索引缓存：–attention-config 里开 use_fp4_indexer_cache，配合混合精度权重使用。
• 专家并行：MoE 模型用 --enable-expert-parallel 把专家层摊到多卡，配合 --data-parallel-size 使用。
• KV 缓存精度：–kv-cache-dtype fp8 压缩缓存，省显存，长上下文场景尤其明显。

备注：

• DGX 是 NVIDIA 的整机/服务器产品系列名称

部署策略对比

DEP有个缺点是：得单个节点放得下一份模型（这里的 node 指一台物理服务器/机器，不是单张 GPU。）

模型需要 500 GB
单张 GPU 只有 80 GB
一台服务器有 8 张 GPU，共 640 GB

方案一 ：(以单台 4×GB300 为例)

# 官方 vLLM 部署示例，以单台 4×GB300 为例
vllm serve deepseek-ai/DeepSeek-V4-Flash-0731 \
  --trust-remote-code \
  --kv-cache-dtype fp8 \
  --block-size 256 \
  --data-parallel-size 4 \
  --enable-expert-parallel \
  --moe-backend deep_gemm_mega_moe \
  --attention-config '{"use_fp4_indexer_cache": true}' \
  --speculative-config '{"method":"dspark","num_speculative_tokens":7,"draft_sample_method":"greedy"}'

这套是官方给的基准配置。卡数少的话，把 --data-parallel-size 和 --moe-backend 按实际环境调整。deep_gemm_mega_moe 只对 Blackwell 架构生效，非 GB300 环境直接去掉这个参数。

方案二：DGX Station Single-GPU单点部署

vllm serve deepseek-ai/DeepSeek-V4-Flash \
  --tensor-parallel-size 1 --pipeline-parallel-size 1 \
  --kv-cache-dtype fp8 --trust-remote-code --block-size 256 \
  --gpu-memory-utilization 0.92 \
  --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 \
  --max-cudagraph-capture-size 128 \
  --speculative-config '{"method":"mtp","num_speculative_tokens":3}'

参数解释

1.--tensor-parallel-size 1 --pipeline-parallel-size 1
张量并行和流水线并行都设置为 1：
2.--kv-cache-dtype fp8
KV Cache 使用 FP8，减少显存占用。
3.--trust-remote-code
允许加载模型仓库中的自定义 Python 模型代码。
4.--block-size 256
KV Cache 按 256 个 token 一块进行管理。
5.--gpu-memory-utilization 0.92
最多使用约 92% GPU 显存，给 CUDA、vLLM 和临时缓存预留空间。
6.--compilation-config \
'{"cudagraph_mode":"FULL_AND_PIECEWISE","custom_ops":["all"]}'
启用 CUDA Graph 和 vLLM 自定义算子，优化单 GPU 推理性能。
7.--attention_config.use_fp4_indexer_cache True
让 DeepSeek-V4 稀疏 Attention 的索引缓存使用 FP4，减少缓存显存占用。
8.--tokenizer-mode deepseek_v4
使用 DeepSeek-V4 专用的消息编码和 tokenizer 模式。
9.--tool-call-parser deepseek_v4
--enable-auto-tool-choice
启用 DeepSeek-V4 的工具调用解析，并允许模型自动选择工具。
10.--reasoning-parser deepseek_v4
解析 DeepSeek-V4 的思考/推理内容。
11.--max-cudagraph-capture-size 128
限制 CUDA Graph 捕获的最大规模为 128。
12.--speculative-config \
'{"method":"mtp","num_speculative_tokens":3}'

启用 MTP 投机解码：
MTP 草稿模块先预测 3 个 token
        ↓
主模型批量验证
        ↓
接受正确 token，减少 Decode 次数

方案三：RTX PRO 6000 8× (8×96 GB, sm_120)

启动 RTX PRO 6000 的 vLLM 服务前，需要手动修正 FlashInfer 版本兼容问题。

vLLM 0.25.0 的 DeepSeek-V4 稀疏 MLA Decode 代码，会调用 FlashInfer 的一个新参数：
swa_topk_lens
它可以理解成：
稀疏 Attention Decode 时，告诉 kernel 每个请求需要处理多少个滑动窗口/Top-K 索引。

但是：
vLLM 0.25.0 需要 FlashInfer 0.6.14
容器里预装的是 FlashInfer 0.6.13
所以版本对不上。

兼容命令

# vLLM 0.25.0's DeepSeek-V4 sparse MLA decode passes `swa_topk_lens`, which
# only exists in FlashInfer 0.6.14; the image pins 0.6.13. --no-deps is
# required — a plain install pulls a different torch and breaks vLLM's
# compiled extensions.
/usr/bin/python3.12 -m pip install --no-deps flashinfer-python==0.6.14

# flashinfer-cubin has no matching 0.6.14 release, so skip the parity check.
export FLASHINFER_DISABLE_VERSION_CHECK=1

部署命令

vllm serve deepseek-ai/DeepSeek-V4-Flash-0731 \
  --trust-remote-code \
  --kv-cache-dtype fp8 \
  --block-size 256 \
  --enable-expert-parallel \
  --tensor-parallel-size 8 \
  --tokenizer-mode deepseek_v4 \
  --tool-call-parser deepseek_v4 \
  --enable-auto-tool-choice \
  --reasoning-parser deepseek_v4

备注
1.RTX PRO 6000 这类 SM120 GPU 上，当前 vLLM 不能使用 MTP 或 DSpark 投机解码。

方案四：MI325X (1×256GB)

export VLLM_ROCM_USE_AITER=1

vllm serve deepseek-ai/DeepSeek-V4-Flash \
  --host 0.0.0.0 \
  --port 8002 \
  --tensor-parallel-size 1 \
  --kv-cache-dtype fp8_e4m3 \
  --max-model-len 4096 \
  --enable-chunked-prefill \
  --max-num-batched-tokens 256 \
  --kv-cache-memory-bytes 10000000000 \
  --distributed-executor-backend mp \
  --trust-remote-code \
  --tokenizer-mode deepseek_v4 \
  --moe-backend triton_unfused \
  --enforce-eager

已经使用 vLLM 0.25.0 和 PyTorch HIP 7.2.53211 完成端到端验证。请使用这套保守的 TP1、Eager 模式启动命令，不要使用 MI355X 的吞吐量优化配置。

Chunked Prefill 可以支持最长 4K token 的请求，同时每次调度最多处理 256 个 token。这个配置成功加载了 148.66 GiB 的 checkpoint，并在一次持续 24 小时的 GPU 分配中通过了模型列表和聊天接口测试，覆盖 Non-think 和 Think High 模式。当前只验证过 TP1、4K 上下文；TP2 及以上配置没有验证成功。Think Max 至少需要 384K 上下文，因此在这套配置中不可用。

备注：
1.eager：不使用 CUDA Graph 捕获，按照普通动态图方式逐个执行算子。

方案五：MI355X (4×288GB)

想要更高延迟，用–tensor-parallel-size 8

export VLLM_ROCM_USE_AITER=1

vllm serve deepseek-ai/DeepSeek-V4-Flash \
  --host localhost \
  --port 8001 \
  --dtype auto \
  --kv-cache-dtype fp8 \
  --tensor-parallel-size 4 \
  --max-num-seqs 512 \
  --max-num-batched-tokens 8192 \
  --distributed-executor-backend mp \
  --trust-remote-code \
  --gpu-memory-utilization 0.9 \
  --tokenizer-mode deepseek_v4 \
  --reasoning-parser deepseek_v4 \
  --tool-call-parser deepseek_v4 \
  --enable-auto-tool-choice \
  --compilation-config '{"mode": 3, "cudagraph_mode": "FULL_DECODE_ONLY"}'

这段测试主要是为了确认：
模型能正常加载
AMD ROCm/vLLM 路径正常
Completion API 正常
批量并发正常
模型数学推理结果基本正确

MI355X is validated on GSM8K dataset:
Launch command

MODEL=deepseek-ai/DeepSeek-V4-Flash
lm_eval --model local-completions \
  --model_args model=$MODEL,base_url=http://0.0.0.0:8001/v1/completions,num_concurrent=128,max_retries=10,max_gen_toks=2048,timeout=60000 \
  --batch_size auto \
  --tasks gsm8k \
  --num_fewshot 8 \
  --output_path . 2>&1 | tee -a eval.log

Reported result

local-completions ({'model': 'deepseek-ai/DeepSeek-V4-Flash', 'base_url': 'http://0.0.0.0:8001/v1/completions', 'num_concurrent': 128, 'max_retries': 10, 'max_gen_toks': 2048, 'timeout': 60000}), gen_kwargs: ({}), limit: None, num_fewshot: 8, batch_size: auto

|Tasks|Version|     Filter     |n-shot|  Metric   |   |Value |   |Stderr|
|-----|------:|----------------|-----:|-----------|---|-----:|---|-----:|
|gsm8k|      3|flexible-extract|     8|exact_match|↑  |0.9439|±  |0.0063|
|     |       |strict-match    |     8|exact_match|↑  |0.9431|±  |0.0064|

方案六：H200 Single-Node PD (Mooncake)

Single-host disaggregated serving: 4 prefill GPUs + 4 decode GPUs on one 8-GPU H200 node, using MooncakeConnector over RDMA for KV cache transfer.

Prefill (GPUs 0–3, port 8000):

docker run --gpus all \
  --privileged --ipc=host -p 8000:8000 \
  --network host \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -v /mnt/shared:/mnt/shared \
  -e TILELANG_CLEANUP_TEMP_FILES=1 \
  -e VLLM_DISABLE_COMPILE_CACHE=1 \
  -e VLLM_ENGINE_READY_TIMEOUT_S=3600 \
  -e VLLM_RPC_TIMEOUT=600000 \
  -e VLLM_LOG_STATS_INTERVAL=1 \
  -e VLLM_MOONCAKE_BOOTSTRAP_PORT=8998 \
  -e CUDA_VISIBLE_DEVICES=0,1,2,3 \
  vllm/vllm-openai:v0.25.0 \
  deepseek-ai/DeepSeek-V4-Flash \
  --trust-remote-code \
  --kv-cache-dtype fp8 \
  --block-size 256 \
  --port 8000 \
  --data-parallel-size 4 \
  --enable-expert-parallel \
  --tokenizer-mode deepseek_v4 \
  --reasoning-parser deepseek_v4 \
  --max-model-len auto \
  --max-num-batched-tokens 16384 \
  --max-num-seqs 8 \
  --enforce-eager \
  --no-disable-hybrid-kv-cache-manager \
  --disable-uvicorn-access-log \
  --kv-transfer-config '{"kv_connector":"MooncakeConnector","kv_role":"kv_both","kv_load_failure_policy":"fail","kv_buffer_device":"cuda","kv_connector_extra_config":{"enforce_handshake_compat":false,"mooncake_protocol":"rdma"}}'

Decode (GPUs 4–7, port 8001):

docker run --gpus all \
  --privileged --ipc=host -p 8001:8001 \
  --network host \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -v /mnt/shared:/mnt/shared \
  -e TILELANG_CLEANUP_TEMP_FILES=1 \
  -e VLLM_DISABLE_COMPILE_CACHE=1 \
  -e VLLM_ENGINE_READY_TIMEOUT_S=3600 \
  -e VLLM_RPC_TIMEOUT=600000 \
  -e VLLM_LOG_STATS_INTERVAL=1 \
  -e VLLM_MOONCAKE_BOOTSTRAP_PORT=9889 \
  -e CUDA_VISIBLE_DEVICES=4,5,6,7 \
  vllm/vllm-openai:v0.25.0 \
  deepseek-ai/DeepSeek-V4-Flash \
  --trust-remote-code \
  --kv-cache-dtype fp8 \
  --block-size 256 \
  --port 8001 \
  --data-parallel-size 4 \
  --enable-expert-parallel \
  --tokenizer-mode deepseek_v4 \
  --reasoning-parser deepseek_v4 \
  --max-model-len auto \
  --max-num-seqs 512 \
  --max-num-batched-tokens 512 \
  --compilation-config '{"mode":0,"cudagraph_mode":"FULL_DECODE_ONLY","max_cudagraph_capture_size":512,"compile_ranges_endpoints":[512]}' \
  --no-disable-hybrid-kv-cache-manager \
  --disable-uvicorn-access-log \
  --kv-transfer-config '{"kv_connector":"MooncakeConnector","kv_role":"kv_both","kv_load_failure_policy":"fail","kv_buffer_device":"cuda","kv_connector_extra_config":{"enforce_handshake_compat":false,"mooncake_protocol":"rdma"}}'

路由

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

方案七：H200 Single-Node PD (Nixl)

Single-host disaggregated serving: 4 prefill GPUs + 4 decode GPUs on one 8-GPU H200 node, using NixlConnector for KV cache transfer.

Prefill (GPUs 0–3, port 8000):

docker run --gpus all \
  --privileged --ipc=host -p 8000:8000 \
  --network host \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -v /mnt/shared:/mnt/shared \
  -e TILELANG_CLEANUP_TEMP_FILES=1 \
  -e VLLM_DISABLE_COMPILE_CACHE=1 \
  -e VLLM_ENGINE_READY_TIMEOUT_S=3600 \
  -e VLLM_RPC_TIMEOUT=600000 \
  -e VLLM_LOG_STATS_INTERVAL=1 \
  -e VLLM_NIXL_SIDE_CHANNEL_PORT=5557 \
  -e CUDA_VISIBLE_DEVICES=0,1,2,3 \
  vllm/vllm-openai:v0.25.0 \
  deepseek-ai/DeepSeek-V4-Flash \
  --trust-remote-code \
  --kv-cache-dtype fp8 \
  --block-size 256 \
  --port 8000 \
  --data-parallel-size 4 \
  --enable-expert-parallel \
  --tokenizer-mode deepseek_v4 \
  --reasoning-parser deepseek_v4 \
  --max-model-len auto \
  --max-num-batched-tokens 16384 \
  --max-num-seqs 8 \
  --enforce-eager \
  --no-disable-hybrid-kv-cache-manager \
  --disable-uvicorn-access-log \
  --kv-transfer-config '{"kv_connector":"NixlConnector","kv_role":"kv_both"}'

Decode (GPUs 4–7, port 8001):

docker run --gpus all \
  --privileged --ipc=host -p 8001:8001 \
  --network host \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  -v /mnt/shared:/mnt/shared \
  -e TILELANG_CLEANUP_TEMP_FILES=1 \
  -e VLLM_DISABLE_COMPILE_CACHE=1 \
  -e VLLM_ENGINE_READY_TIMEOUT_S=3600 \
  -e VLLM_RPC_TIMEOUT=600000 \
  -e VLLM_LOG_STATS_INTERVAL=1 \
  -e VLLM_NIXL_SIDE_CHANNEL_PORT=5558 \
  -e CUDA_VISIBLE_DEVICES=4,5,6,7 \
  vllm/vllm-openai:v0.25.0 \
  deepseek-ai/DeepSeek-V4-Flash \
  --trust-remote-code \
  --kv-cache-dtype fp8 \
  --block-size 256 \
  --port 8001 \
  --data-parallel-size 4 \
  --enable-expert-parallel \
  --tokenizer-mode deepseek_v4 \
  --reasoning-parser deepseek_v4 \
  --max-model-len auto \
  --max-num-seqs 512 \
  --max-num-batched-tokens 512 \
  --compilation-config '{"mode":0,"cudagraph_mode":"FULL_DECODE_ONLY","max_cudagraph_capture_size":512,"compile_ranges_endpoints":[512]}' \
  --no-disable-hybrid-kv-cache-manager \
  --disable-uvicorn-access-log \
  --kv-transfer-config '{"kv_connector":"NixlConnector","kv_role":"kv_both"}'

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 nixl

测试服务畅通

# 确认服务就绪，能看到模型列表即成功
curl http://localhost:8000/v1/models

# 用 OpenAI 兼容接口测一句
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"deepseek-ai/DeepSeek-V4-Flash-0731","messages":[{"role":"user","content":"1+1=?"}]}'

返回里能看到 choices[0].message.content 就算跑通。注意 0731 没有标准的 Jinja 聊天模板，官方在仓库 encoding 目录里给了编码脚本，自建推理链路时用得上。

服务报错

⚠️ CUDA out of memory 显存不够时，先缩 --max-model-len，从 1M 降到 128K 是最立竿见影的一步。KV 缓存按上下文长度线性增长，窗口是显存大头，降下来再考虑量化。
⚠️ Unsupported architecture 报错 DeepSeek V4 架构比较新，旧版 vLLM 不认识。用较新的 vLLM（0.26 及以上），或者 vllm/vllm-openai 的 cu130 系列镜像。
⚠️ 投机解码不生效 确认 --speculative-config 里的 method 是 dspark，且版本支持 DSpark。方法名写错会静默回退到普通解码，速度没有加成，排错时容易漏掉。

⚠️ A卡兼容 ROCm（Radeon Open Compute）是 AMD GPU 的计算软件平台，作用类似 NVIDIA 的 CUDA。

2）部署DeepSeek-V4-Pro-0831

模型介绍

1.DeepSeek-V4-Pro 是 V4 预览系列中的旗舰模型：采用 1.6 万亿参数总量、490 亿激活参数的混合专家（MoE）架构。它结合了 混合注意力堆栈，即压缩稀疏注意力（CSA）与高度压缩注意力（HCA），以及 流形约束超连接（mHC），在 100 万上下文长度下，将每个 token 的推理 FLOPs 降至 V3.2 的 27%，KV 缓存降至 V3.2 的 10%。模型使用 Muon 优化器在超过 32 万亿个 token 上进行预训练，以实现更快收敛；后训练则分为两个阶段：先培养领域专用专家，再通过基于策略的蒸馏进行统一整合。

2.该检查点采用 FP4 + FP8 混合精度：MoE 专家权重以 FP4 存储，其余参数，包括注意力、归一化层和路由器参数，则保留为 FP8。

3.此外还提供 NVFP4 版本（nvidia/DeepSeek-V4-Pro-NVFP4）。该版本通过 NVIDIA ModelOpt 将 MoE 专家重新量化为标准 NVFP4，而注意力层、共享专家、路由器头和 MTP 仍使用 FP8。可以在 Variant（变体）一栏中选择该版本；它支持在 Blackwell GPU 上运行，并使用 FP4 索引器缓存。

4.需要注意的是，与原生 FP8 检查点不同，NVFP4 版本的专家权重不支持 deep_gemm_mega_moe MoE 内核，因为该内核仅支持 FP8。因此，NVFP4 版本会使用默认的 MoE 后端。

部署模型选择

Variant（变体）这一行有四种模型可选。

融合版检查点在磁盘上约占 893 GB，而预览版约占 865 GB，两者的差异主要来自草稿模块。
这两个版本都要求使用 vLLM 0.25.0，高于本配置方案原本的 0.20.0 基线版本；当选择其中任意一个版本时，安装模块会自动升级到所需版本。

推理模式

聊天模板提供三种推理强度模式：

• Non-think：快速、直觉式的回答。
• Think High：针对复杂问题求解和规划，进行显式思维链推理。
• Think Max：最高推理强度；要求 --max-model-len >= 393216（384K token），以避免输出被截断。
  推荐的采样参数为：

temperature = 1.0
top_p = 1.0

在 0813 变体中，推理强度名称改为 low / high / max。DeepSeek 建议在智能体场景中使用 top_p = 0.95，其他场景使用 top_p = 1.0，同时 temperature 保持为 1.0。在 high 和 max 模式下，最多允许生成 384K 个输出 token。
需要注意的是，0813 版本没有自带 Jinja 聊天模板。仓库提供了一个 encoding/ 文件夹，其中包含 encode_messages 和 parse_message_from_completion_text 辅助函数。
如果通过 vLLM 并使用 --tokenizer-mode deepseek_v4（即 Tool Calling 选项）来提供服务，vLLM 会应用内置的 DeepSeek-V4 编码方式，因此 OpenAI 兼容接口无需依赖这些辅助脚本即可正常工作。

KV 存储拓扑

模式	工作方式	优点	缺点
Distributed（embedded）分布式嵌入式	每个 vLLM 实例内嵌一个 Mooncake Store，各实例管理自己的本地 CPU 内存缓存	部署简单；没有额外 Store 服务；故障影响范围小；小规模场景延迟通常更低	缓存分散，容量利用率可能不均；实例之间共享和迁移更复杂；扩容后缓存管理不如集中式统一
Centralized（standalone store）集中式	单独运行 Mooncake Store 服务，由它统一管理整个 CPU DRAM 缓存池；vLLM GPU 侧不保留本地缓存	缓存池统一，容量利用率高；多实例共享更直接；适合大规模部署和集中运维	需要额外服务；网络访问增加；Store 服务可能成为性能瓶颈或故障点；部署、监控和高可用更复杂

部署服务方案

• B300（8 张 GPU）：单节点数据并行（DP）+ 专家并行（EP），设置 --data-parallel-size 8。

• H200（8 张 GPU）：使用数据并行（DP）+ 专家并行（EP），设置 --data-parallel-size 8。由于密集参数会在各个 rank 上复制，为 KV 缓存预留空间，上下文长度限制为 800K token，即 --max-model-len 800000。这一限制同时适用于单节点和多节点 H200 配置。

• MI355X（8 张 GPU）：已通过 ROCm + AITER 验证，配置如下：VLLM_ROCM_USE_AITER=1
  –gpu-memory-utilization 0.9
  –max-num-seqs 128
  –max-num-batched-tokens 8192
  –distributed-executor-backend mp

• GB200 NVL4（每个托盘 4 张 GPU）：约 960 GB 的混合精度检查点无法装入单个托盘，因此需要使用 2 个托盘进行多节点数据并行（DP）+ 专家并行（EP），总计 8 张 GPU，并设置 --data-parallel-size 8。选择 Multi-Node（多节点）选项卡，并将节点数设为 2。

请求测试

思考字段：For DeepSeek-V4, keep reasoning controls in chat_template_kwargs, as it exposes a custom Think Max mode via “reasoning_effort”: “max”.

from openai import OpenAI

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

# Non-think
resp = client.chat.completions.create(
    model=model,
    messages=messages,
)

# Think High
resp = client.chat.completions.create(
    model=model,
    messages=messages,
    extra_body={
        "chat_template_kwargs": {
            "thinking": True,
            "reasoning_effort": "high",
        },
    },
)

# Think Max
resp = client.chat.completions.create(
    model=model,
    messages=messages,
    extra_body={
        "chat_template_kwargs": {
            "thinking": True,
            "reasoning_effort": "max",
        },
    },
)

KV Cache Offloading设置

• Simple
  使用 SimpleCPUOffloadConnector。
  它会把放不进 GPU 显存的 KV Cache 块，卸载到每个节点上、各个 rank 独立占用的一块 CPU 内存区域中。
  这是为单个 vLLM 实例扩展有效 KV Cache 容量最简单的方式。

• Mooncake
  使用 MooncakeStoreConnector。
  Mooncake 会把多台机器的 CPU 内存整合成一个分布式共享 KV 存储池，提供两种拓扑：
  Embedded（嵌入式）：每个 rank 对应的 vLLM Worker 都运行一个 Mooncake 客户端，并贡献一部分本机 CPU 内存。
  Standalone（独立存储服务）：每个节点单独运行一个 mooncake_store_service，由它管理该节点的 CPU 内存并加入共享缓存池。这让 KV Cache 的生命周期与 vLLM 推理引擎解耦，即使引擎重启，缓存也可以继续存在。
  整个集群由一个 mooncake_master 负责协调。
  当存在两个或更多 vLLM 实例时，各个 GPU Worker 可以共享这个缓存池，实现跨实例的公共前缀复用。
  需要通过前面的额外安装模块安装，详情参见 Mooncake 文档。

• LMCache
  使用 LMCacheMPConnector。
  它提供一个节点本地的 KV 缓存池，由配套的 lmcache 服务进程负责管理。必须先启动 LMCache 服务，再执行 vllm serve。
  它只支持单节点部署策略。
  需要通过前面的额外安装模块安装，详情参见 LMCache 文档。

区别

方案	缓存范围	跨实例共享	跨节点	部署复杂度
Simple	每个 rank 独立	否	否	最低
LMCache	单节点共享池	可以，限本节点	否	中等
Mooncake	集群共享池	可以	可以	最高