141G显存H20单机DeepSeek-R1满血FP8版性能测试

#环境参数#

H20 141G 单机8卡，CUDA 12.4，vLLM v0.8.3，flashinfer v0.2.2

#服务化命令#

基于知乎大神的推荐出装与前期H800双机生产环境测试，在H20上开启EP、MLA等核心优化参数，实现推理吞吐性能最优吞吐量破10000tokens/s，VLLM 0.8.1版本驱动下的Deepseek-r1 671Bhttps://zhuanlan.zhihu.com/p/1887527788514346095?utm_campaign=shareopn&utm_medium=social&utm_psn=1887760069761938542&utm_source=wechat_session

VLLM_ATTENTION_BACKEND=FLASHMLA \
VLLM_TEST_ENABLE_EP=1 VLLM_USE_V1=1 \
vllm serve /DS_test \
--served-model-name deepseek-r1 \
--enable-prefix-caching \
--max-model-len 131072 \
--gpu-memory-utilization 0.95 \
--tensor-parallel-size 8 \
--enable-chunked-prefill \
--enable-reasoning \
--reasoning-parser deepseek_r1 \
--max_num_batched_tokens 32768 \
--block-size 64 \
--port 8000 

#FlashMLA依赖环境配置 

vLLM v0.8.3框架未与flashinfer v0.2.3及以上版本完成适配，且flashinfer自身不支持向下兼容，建议回退到v0.2.2版本 

[topk_topp_sampler.py:38] Currently, FlashInfer top-p & top-k sampling sampler is disabled because FlashInfer>=v0.2.3 is not backward compatible. Falling back to the PyTorch-native implementation of top-p & top-k sampling.

 #NVIDIA GPU架构

 启动服务化过程中会出现 TORCH_CUDA_ARCH_LIST is not set的问题

明确该参数后， PyTorch 在构建过程中可针对CUDA 架构版本进行优化，实现性能5%~10%提升

python -c "import torch; print(torch.cuda.get_device_capability())" ##获取参数
export TORCH_CUDA_ARCH_LIST="9.0" ##配置环境变量

 # 测试结果

采用vLLM内置benchmark脚本进行测试，按照短对话（128输入、512输出），长对话（4k输入、1k输出）进行吞吐性能测试

   vllm bench serve \
        --model "/DS_test" \
        --seed 12345 \
        --served-model-name deepseek-r1 \
        --dataset-name random \
        --request-rate inf \
        --random-input-len 128 \
        --random-output-len 512 \
        --num-prompts 1024

开启MLA后，吞吐性能提升测试结果如下：

H20-DeepSeekR1性能测试

测试组	并发数	总吞吐（t/s）	单用户吞吐（t/s）	首字延迟（ms）	字间时差（ms）	性能提升
短输入输出-1并发	1	32.06	32.06	71.09	31.11	0.470%
短输入输出-2并发	2	68.46	34.23	104.95	29.03	-0.117%
短输入输出-4并发	4	124.31	31.08	138.10	31.95	-0.249%
短输入输出-8并发	8	199.43	24.93	211.80	39.57	-0.484%
短输入输出-16并发	16	335.49	20.97	257.52	47.25	8.929%
短输入输出-32并发	32	485.13	15.16	362.53	57.69	0.647%
短输入输出-64并发	64	803.36	12.55	507.49	71.89	3.390%
短输入输出-128并发	128	1379.88	10.78	813.57	80.54	1.527%
短输入输出-256并发	256	2210.55	8.63	1647.61	99.48	-0.797%
短输入输出-512并发	512	3242.10	6.33	4058.10	142.88	-1.824%
短输入输出-1024并发	1024	4093.34	4.00	7883.23	236.33	-1.066%
长输入输出-1并发	1	31.60	31.60	139.22	31.54	0.349%
长输入输出-2并发	2	66.25	33.13	366.97	29.83	-0.015%
长输入输出-4并发	4	117.83	29.46	793.19	33.17	-0.582%
长输入输出-8并发	8	189.19	23.65	1075.26	41.22	0.772%
长输入输出-16并发	16	320.77	20.05	2139.90	47.74	8.872%
长输入输出-32并发	32	447.60	13.99	4208.34	79.27	2.015%
长输入输出-64并发	64	666.81	10.42	6661.36	167.95	1.115%
长输入输出-128并发	128	909.42	7.10	11280.51	237.09	3.948%
长输入输出-256并发	256	781.70	3.05	94509.18	275.17	-4.569%
长输入输出-512并发	512	725.57	1.42	257414.50	332.60	0.012%
长输入输出-1024并发	1024	723.96	0.71	591347.34	273.59	0.035%

####后续调优方向

当前测试场景，开启MLA优化后，整体吞吐性能提升不明显，且随着对话长度增长，整体吞吐性能下降明显。

后续考虑通过torch插件，打印prefill阶段更详细的日志信息，确认vLLM框架下MLA优化器的工作效率。

（当前服务侧日志信息）