DeepSeekV4 Flash与Pro模型部署

文章目录一、配置对比二、vLLM推理DSv4流程1读取config.json配置2模型目录及ds模型类的函数解释3ds代码流程的推理过程1模型加载流程2模型推理流程三、dsv4模型部署1部署DeepSeek-V4-Flash-0731参数解释硬件配置权重下载部署服务方案方案一 (以单台 4×GB300 为例)方案二DGX Station Single-GPU单点部署方案三RTX PRO 6000 8× (8×96 GB, sm_120)方案四MI325X (1×256GB)方案五MI355X (4×288GB)方案六H200 Single-Node PD (Mooncake)方案七H200 Single-Node PD (Nixl)测试服务畅通服务报错2部署DeepSeek-V4-Pro-0831模型介绍部署模型选择推理模式KV 存储拓扑部署服务方案请求测试KV Cache Offloading设置一、配置对比对比两个模型在huggingface上的配置DeepSeek-V4-Flash/config.jsonDeepSeek-V4-Pro/config.json配置DeepSeek-V4-FlashDeepSeek-V4-Prohidden_size隐藏状态维度也就是每个 token 在 Transformer 层之间传递的向量长度。40967168层数4361注意力头数64128n_routed_experts路由专家总数。256384num_experts_per_tok每个 token 激活的 routed expert 数量。66moe_intermediate_size每个 routed expert 内部 FFN 的中间维度。20483072index_topk5121024q_lora_rankQuery 的低秩 latent 维度。10241536o_groups816routed_scaling_factor路由专家输出的缩放因子。1.52.5num_hidden_layersTransformer block 的层数。4361num_attention_heads意力头数量。64128expert_dtype:MOE专家权重fp4fp4备注1.两者每个 token 激活的专家数相同。Flash 不是因为激活专家数更少而更小而是因为①总专家数少256 vs 384②每个专家更窄③层数更少④hidden size 更小2.routed_scaling_factor是路由专家输出的缩放因子。作用对 routed MoE 分支输出做整体缩放用来平衡 routed experts 和 shared expert 的贡献。3.q_lora_rankQuery 的低秩 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配置填的模型架构是DeepseekV4ForCausalLMDeepseekV4ForCausalLM在vLLM的注册里面填的类是2模型目录及ds模型类的函数解释各个分支目录下model.py都是对应DeepseekV4ForCausalLM类的实现Flash 和 Pro 都进入同一个类这里主要看nvidia的classDeepseekV4ForCausalLM(nn.Module,SupportsPP,SupportsEagle3,DeepseekV4MixtureOfExperts,):几个父类分别表示nn.ModulePyTorch 模型基类。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()。3ds代码流程的推理过程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 命令行工具pipinstallhuggingface_hub# 下载 0731 正式版权重约 160GBhuggingface-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 设 7draft 采样用 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-size256\--data-parallel-size4\--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-size1--pipeline-parallel-size1\--kv-cache-dtype fp8 --trust-remote-code --block-size256\--gpu-memory-utilization0.92\--compilation-config{cudagraph_mode:FULL_AND_PIECEWISE,custom_ops:[all]}\--attention_config.use_fp4_indexer_cacheTrue\--tokenizer-mode deepseek_v4 --tool-call-parser deepseek_v4\--enable-auto-tool-choice --reasoning-parser deepseek_v4\--max-cudagraph-capture-size128\--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.0s 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 vLLMs # compiled extensions. /usr/bin/python3.12 -m pip install --no-deps flashinfer-python0.6.14 # flashinfer-cubin has no matching 0.6.14 release, so skip the parity check. export FLASHINFER_DISABLE_VERSION_CHECK1部署命令vllm serve deepseek-ai/DeepSeek-V4-Flash-0731\--trust-remote-code\--kv-cache-dtype fp8\--block-size256\--enable-expert-parallel\--tensor-parallel-size8\--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_AITER1 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 8exportVLLM_ROCM_USE_AITER1vllm serve deepseek-ai/DeepSeek-V4-Flash\--hostlocalhost\--port8001\--dtypeauto\--kv-cache-dtype fp8\--tensor-parallel-size4\--max-num-seqs512\--max-num-batched-tokens8192\--distributed-executor-backend mp\--trust-remote-code\--gpu-memory-utilization0.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 commandMODELdeepseek-ai/DeepSeek-V4-Flash lm_eval --model local-completions \ --model_args model$MODEL,base_urlhttp://0.0.0.0:8001/v1/completions,num_concurrent128,max_retries10,max_gen_toks2048,timeout60000 \ --batch_size auto \ --tasks gsm8k \ --num_fewshot 8 \ --output_path . 21 | tee -a eval.logReported resultlocal-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 --ipchost -p 8000:8000 \ --network host \ -v ~/.cache/huggingface:/root/.cache/huggingface \ -v /mnt/shared:/mnt/shared \ -e TILELANG_CLEANUP_TEMP_FILES1 \ -e VLLM_DISABLE_COMPILE_CACHE1 \ -e VLLM_ENGINE_READY_TIMEOUT_S3600 \ -e VLLM_RPC_TIMEOUT600000 \ -e VLLM_LOG_STATS_INTERVAL1 \ -e VLLM_MOONCAKE_BOOTSTRAP_PORT8998 \ -e CUDA_VISIBLE_DEVICES0,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 --ipchost -p 8001:8001 \ --network host \ -v ~/.cache/huggingface:/root/.cache/huggingface \ -v /mnt/shared:/mnt/shared \ -e TILELANG_CLEANUP_TEMP_FILES1 \ -e VLLM_DISABLE_COMPILE_CACHE1 \ -e VLLM_ENGINE_READY_TIMEOUT_S3600 \ -e VLLM_RPC_TIMEOUT600000 \ -e VLLM_LOG_STATS_INTERVAL1 \ -e VLLM_MOONCAKE_BOOTSTRAP_PORT9889 \ -e CUDA_VISIBLE_DEVICES4,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 --ipchost -p 8000:8000 \ --network host \ -v ~/.cache/huggingface:/root/.cache/huggingface \ -v /mnt/shared:/mnt/shared \ -e TILELANG_CLEANUP_TEMP_FILES1 \ -e VLLM_DISABLE_COMPILE_CACHE1 \ -e VLLM_ENGINE_READY_TIMEOUT_S3600 \ -e VLLM_RPC_TIMEOUT600000 \ -e VLLM_LOG_STATS_INTERVAL1 \ -e VLLM_NIXL_SIDE_CHANNEL_PORT5557 \ -e CUDA_VISIBLE_DEVICES0,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 --ipchost -p 8001:8001 \ --network host \ -v ~/.cache/huggingface:/root/.cache/huggingface \ -v /mnt/shared:/mnt/shared \ -e TILELANG_CLEANUP_TEMP_FILES1 \ -e VLLM_DISABLE_COMPILE_CACHE1 \ -e VLLM_ENGINE_READY_TIMEOUT_S3600 \ -e VLLM_RPC_TIMEOUT600000 \ -e VLLM_LOG_STATS_INTERVAL1 \ -e VLLM_NIXL_SIDE_CHANNEL_PORT5558 \ -e CUDA_VISIBLE_DEVICES4,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测试服务畅通# 确认服务就绪能看到模型列表即成功curlhttp://localhost:8000/v1/models# 用 OpenAI 兼容接口测一句curlhttp://localhost:8000/v1/chat/completions\-HContent-Type: application/json\-d{model:deepseek-ai/DeepSeek-V4-Flash-0731,messages:[{role:user,content:11?}]}返回里能看到 choices[0].message.content 就算跑通。注意 0731 没有标准的 Jinja 聊天模板官方在仓库 encoding 目录里给了编码脚本自建推理链路时用得上。服务报错⚠️CUDA out of memory显存不够时先缩 --max-model-len从 1M 降到 128K 是最立竿见影的一步。KV 缓存按上下文长度线性增长窗口是显存大头降下来再考虑量化。⚠️Unsupported architecture 报错DeepSeek V4 架构比较新旧版 vLLM 不认识。用较新的 vLLM0.26 及以上或者 vllm/vllm-openai 的 cu130 系列镜像。⚠️投机解码不生效确认 --speculative-config 里的 method 是 dspark且版本支持 DSpark。方法名写错会静默回退到普通解码速度没有加成排错时容易漏掉。⚠️A卡兼容ROCmRadeon 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 393216384K 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 存储拓扑模式工作方式优点缺点Distributedembedded分布式嵌入式每个 vLLM 实例内嵌一个 Mooncake Store各实例管理自己的本地 CPU 内存缓存部署简单没有额外 Store 服务故障影响范围小小规模场景延迟通常更低缓存分散容量利用率可能不均实例之间共享和迁移更复杂扩容后缓存管理不如集中式统一Centralizedstandalone store集中式单独运行 Mooncake Store 服务由它统一管理整个 CPU DRAM 缓存池vLLM GPU 侧不保留本地缓存缓存池统一容量利用率高多实例共享更直接适合大规模部署和集中运维需要额外服务网络访问增加Store 服务可能成为性能瓶颈或故障点部署、监控和高可用更复杂部署服务方案B3008 张 GPU单节点数据并行DP 专家并行EP设置 --data-parallel-size 8。H2008 张 GPU使用数据并行DP 专家并行EP设置 --data-parallel-size 8。由于密集参数会在各个 rank 上复制为 KV 缓存预留空间上下文长度限制为 800K token即 --max-model-len 800000。这一限制同时适用于单节点和多节点 H200 配置。MI355X8 张 GPU已通过 ROCm AITER 验证配置如下VLLM_ROCM_USE_AITER1–gpu-memory-utilization 0.9–max-num-seqs 128–max-num-batched-tokens 8192–distributed-executor-backend mpGB200 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”.fromopenaiimportOpenAI clientOpenAI(base_urlhttp://localhost:8000/v1,api_keyEMPTY)modeldeepseek-ai/DeepSeek-V4-Pro-0813messages[{role:user,content:What is 17*19? Return only the final integer.}]# Non-thinkrespclient.chat.completions.create(modelmodel,messagesmessages,)# Think Highrespclient.chat.completions.create(modelmodel,messagesmessages,extra_body{chat_template_kwargs:{thinking:True,reasoning_effort:high,},},)# Think Maxrespclient.chat.completions.create(modelmodel,messagesmessages,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集群共享池可以可以最高