GPUStack 部署 DeepSeek-V4-Flash-0731 双平台实测：H20 单并发 600+ TPS，昇腾 910B 表现如何？

GPUStack

309人浏览 · 2026-08-06 11:19:59

GPUStack · 2026-08-06 11:19:59 发布

2026 年 7 月 31 日，DeepSeek 正式发布 DeepSeek-V4-Flash-0731。作为取代 Preview 版本的正式版本，0731 沿用了 DeepSeek-V4-Flash 的模型架构，升级重点集中在后训练与 Agent 能力。官方评测显示，它以更小的激活参数规模在多项 Agent 基准中超过 DeepSeek-V4-Pro（Preview），并支持低、高、最高三档推理强度。

与此同时，DeepSeek-V4-Flash-0731 的 checkpoint 内置了 DSpark 投机解码模块。它可以在尽量保持生成质量的前提下，一次预测多个候选 token，从而减少主模型逐 token 解码带来的等待时间，为降低生成延迟、提升推理吞吐提供新的优化空间。

本文分别选择 8 卡 NVIDIA H20-3e 与 8 卡昇腾 910B（单卡 64 GB） 环境，通过 GPUStack 完成模型部署和基准测试，并给出相应的生产配置建议。

H20 部署

环境

第一组测试使用单节点 8 卡 NVIDIA H20-3e。GPUStack 可以统一展示设备状态、温度、利用率和显存占用，便于在模型启动及压力测试过程中观察资源变化。

下载镜像

本次部署直接使用支持 DeepSeek-V4-Flash-0731 与 DSpark 的 vLLM 镜像：

docker pull vllm/vllm-openai:v0.25.0

GPUStack 部署拉起

在 GPUStack 中创建模型服务，选择上述自定义 vLLM 镜像，并为实例分配 8 张 H20。模型、推理后端及 GPU 资源配置如下：

推理后端参数如下：

--max-model-len 300000 \
--trust-remote-code \
--kv-cache-dtype=fp8 \
--block-size=256 \
--tensor-parallel-size=8 \
--no-enable-flashinfer-autotune \
--tokenizer-mode=deepseek_v4 \
--tool-call-parser=deepseek_v4 \
--enable-auto-tool-choice \
--reasoning-parser=deepseek_v4 \
--speculative-config '{"method":"dspark","num_speculative_tokens":7,"draft_sample_method":"greedy"}' \
--gpu-memory-utilization 0.9 \
--max-num-seqs 48 \
--enable-prefix-caching

环境变量：

VLLM_ENGINE_READY_TIMEOUT_S=3600

其中，--tensor-parallel-size=8 将模型切分到 8 张 GPU 上；--kv-cache-dtype=fp8 用 FP8 存储 KV Cache，以换取更大的上下文与并发容量；--speculative-config 启用 DSpark，并设置每轮最多推测 7 个 token。--tokenizer-mode、--tool-call-parser 和 --reasoning-parser 则用于适配 DeepSeek-V4 的分词、工具调用与推理内容解析。

虽然模型能够进一步扩展上下文长度，本次生产配置将 --max-model-len 设置为 300,000，并通过 --gpu-memory-utilization 0.9 为运行时保留一定显存余量。模型首次加载和编译时间较长，因此将引擎就绪等待时间延长至 3,600 秒，避免 GPUStack 在启动阶段过早判定超时。

访问与测评

从启动日志可以看到，该实例可用 KV Cache 显存约为 108.37 GiB，对应 6,837,341 个 token 的 KV Cache 容量。按照单请求 500K token 估算，理论最大并发约为 13.67。

这说明 H20 环境具备较强的长上下文承载能力，但生产环境仍建议把单请求最大上下文限制在 300K。如果直接开放 1M 上下文，少量超长请求就可能持续占用大量 KV Cache，挤压其他请求的并发空间并显著放大排队延迟。

在单并发生成测试中，输出速度可以达到 600+ TPS。从本次实测结果看，其性能约为 DSV4F 普通 + MTP 的 2 倍、普通 DSV4F 的 4 倍，DSpark 对解码阶段的加速效果比较明显。

10 × 64K Input / 3K Output 测试

在 10 路并发、每路 64K Input / 3K Output 的压力测试中，整体运行较为稳定。结合 KV Cache 容量和实际响应情况估算，单台 8 卡 H20 节点可以承载约 25 路 64K 上下文并发，适合对长上下文和响应速度都有较高要求的生产场景。

生产建议： 将单请求最大上下文设置为 300K，并结合实际业务流量限制超长请求；常规 64K 上下文场景可按约 25 路并发进行容量规划。

昇腾 910B 单台部署（单卡 64 GB）

环境

第二组测试使用单节点 8 卡昇腾 910B，每张卡配备 64 GB 显存。与 H20 环境相同，设备由 GPUStack 统一纳管，并通过控制台观察推理过程中的利用率、温度和显存状态。

拉取镜像

昇腾环境使用 vLLM Ascend 的 nightly 镜像，以获得 DeepSeek-V4-Flash-0731 所需的最新适配：

docker pull quay.io/ascend/vllm-ascend:nightly-main

GPUStack 拉起

在 GPUStack 中选择自定义 vLLM Ascend 镜像，为模型实例分配 8 张 910B，并填写模型启动参数：

部署参数：

--max-model-len=500000 \
--max-num-batched-tokens=8192 \
--gpu-memory-utilization=0.9 \
--max-num-seqs=32 \
--data-parallel-size=1 \
--tensor-parallel-size=8 \
--enable-expert-parallel \
--tokenizer-mode=deepseek_v4 \
--tool-call-parser=deepseek_v4 \
--enable-auto-tool-choice \
--reasoning-parser=deepseek_v4 \
--no-disable-hybrid-kv-cache-manager \
--model-loader-extra-config='{"enable_multithread_load": true, "num_threads": 128}' \
--quantization=ascend \
--block-size=128 \
--speculative-config '{"method": "dspark", "num_speculative_tokens": 7, "enforce_eager": true}' \
--compilation-config='{"cudagraph_mode": "FULL_DECODE_ONLY"}'

环境变量：

export HCCL_BUFFSIZE=1024
export TASK_QUEUE_ENABLE=1
export HCCL_OP_EXPANSION_MODE=AIV
export OMP_NUM_THREADS=10
export PYTORCH_NPU_ALLOC_CONF=expandable_segments:True
export VLLM_ENGINE_READY_TIMEOUT=3600

这组配置同样采用 8 路张量并行，并通过 --enable-expert-parallel 开启专家并行，以更好地适配 MoE 模型。--quantization=ascend 启用昇腾侧量化支持，enable_multithread_load 使用 128 个线程并行加载模型文件，减少大模型权重加载时间。

DSpark 在当前昇腾后端中以 eager 模式运行；FULL_DECODE_ONLY 则将 CANN Graph 优化集中在解码阶段。环境变量主要用于增大 HCCL 通信缓冲区、开启任务队列、调整算子展开方式，并优化 NPU 显存分配。

访问与测评

启动日志显示，该实例可用 KV Cache 显存约为 13.89 GiB，对应 539,406 个 token 的 KV Cache 容量。按照单请求 500K token 计算，理论最大并发约为 1.08，也就是单节点基本只能稳定承载 1 路 500K 超长上下文请求。

相比 H20，910B 单卡显存较小，可用于 KV Cache 的空间更加有限。若生产业务需要同时处理多路超长上下文请求，需要通过 GPUStack 部署多个模型副本并组成服务集群，利用统一入口进行负载均衡。

生产建议： 对高并发生产环境，建议使用 8 台以上 910B 节点组成集群，并根据请求长度和峰值流量规划模型副本数量。

在单并发测试中，输出速度最高接近 100 TPS。对于 910B 环境而言，这意味着 DeepSeek-V4-Flash-0731 已经能够在昇腾硬件上获得具备实际使用价值的生成速度，也完成了从可部署到可用的关键跨越。

10 × 64K Input / 3K Output 测试

10 路并发、每路 64K Input / 3K Output 的测试表明，910B 对超长上下文和高并发的承载能力不如 H20。综合吞吐与稳定性考虑，建议把单实例最大上下文长度设置为 128K；在 10 路 32K 并发下运行更为稳定，整体推理性能约为 H20 单台的 1/3。

生产建议： 单实例优先采用 128K 最大上下文配置，常规业务按 10 路 32K 并发规划；如需更高吞吐，通过增加模型副本进行横向扩展。

总结

本次实测表明，GPUStack 已经可以在 NVIDIA H20 与昇腾 910B 两类硬件上完成 DeepSeek-V4-Flash-0731 的部署、运行和监控，并通过自定义推理镜像快速接入模型与 DSpark 的最新适配。

H20 在 KV Cache 容量、长上下文并发和解码速度方面优势明显，单节点更适合承载高吞吐、长上下文业务；910B 已经实现接近 100 TPS 的单并发生成速度，但受显存容量影响，更适合控制单请求上下文长度，并通过多节点、多副本集群扩展整体并发。实际生产部署时，应根据请求长度分布、并发峰值和响应时延目标，选择合适的上下文上限与副本规模。