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

关注

原创最新推荐文章于 2026-10-29 10:04:56 发布 1.3k 阅读 AI 写同款· GEO 优化 ›

DeepSeek-V4-Flash在昇腾910B上的安全智能体部署实战大语言模型推理是构建安全智能体的基础能力，其核心在于低延迟、高可控与强可审计性。DeepSeek-V4-Flash作为轻量化但保留长上下文与结构化推理能力的模型，天然适配安全合规场景；而昇腾910B凭借CANN生态优化与HBM内存管理优势，在Ubuntu 22.04 LTS稳定环境下可实现端到端推理延迟降低18%、显存占用减少41%。该技术组合支撑红蓝对抗辅助、自动化等保检查、内部威胁分析等关键应用，尤其适合政企隔离网络、高校AI安全实验及创业公司POC验证等对数据主权和推理确定性要求严苛的落地场景。阅读详情

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 的单并发生成速度，但受显存容量影响，更适合控制单请求上下文长度，并通过多节点、多副本集群扩展整体并发。实际生产部署时，应根据请求长度分布、并发峰值和响应时延目标，选择合适的上下文上限与副本规模。