deepseek-ai/DeepSeek-R1

Fork 0

mirror of https://github.com/deepseek-ai/DeepSeek-R1.git synced 2026-11-05 00:47:42 +00:00

[GH-ISSUE #507] 使用 vLLM 单结点 8块H200 NVL 部署的671B的 DeepSeek R1 理论速度是多少 #404

New issue

Closed

opened 2026-10-26 21:20:44 +00:00 by bsakaguchi · 9 comments

bsakaguchi commented

2026-10-26 21:20:44 +00:00

Owner

Originally created by @AndrewTsao on GitHub (Feb 26, 2025).
Original GitHub issue: https://github.com/deepseek-ai/DeepSeek-R1/issues/507

测试下来，最高达到 1000 tokens/s 的平均生成速度。不知道正不正常，想确认下有没有类似的部署。

或者其它的sglang之类的方案，能达到更高的效率。

Originally created by @AndrewTsao on GitHub (Feb 26, 2025). Original GitHub issue: https://github.com/deepseek-ai/DeepSeek-R1/issues/507 测试下来，最高达到 1000 tokens/s 的平均生成速度。不知道正不正常，想确认下有没有类似的部署。或者其它的sglang之类的方案，能达到更高的效率。

bsakaguchi

2026-10-26 21:20:44 +00:00

closed this issue
added the
stale
label

bsakaguchi commented

2026-10-26 21:20:45 +00:00

Author

Owner

@shike021 commented on GitHub (Feb 26, 2025):

测试下来，最高达到 1000 tokens/s 的平均生成速度。不知道正不正常，想确认下有没有类似的部署。

或者其它的sglang之类的方案，能达到更高的效率。

AndrewTsao 您好，
可否分享下部署参数配置？
另外使用的是671b的什么量化版本？

我们vllm部署的 r1-671b fp8，也是8卡h200。使用evalscope做压测，10并发下却只有200多tokens/s。

@shike021 commented on GitHub (Feb 26, 2025): > 测试下来，最高达到 1000 tokens/s 的平均生成速度。不知道正不正常，想确认下有没有类似的部署。 > > 或者其它的sglang之类的方案，能达到更高的效率。 AndrewTsao 您好，可否分享下部署参数配置？另外使用的是671b的什么量化版本？我们vllm部署的 r1-671b fp8，也是8卡h200。使用evalscope做压测，10并发下却只有200多tokens/s。

bsakaguchi commented

2026-10-26 21:20:45 +00:00

Author

Owner

@shike021 commented on GitHub (Feb 26, 2025):

英伟达发布数据，他们使用Nvidia NIM部署671b fp8 速度高达3800+。估计应该是最高速度了。
NIM对显卡之间的通信做了优化。

@shike021 commented on GitHub (Feb 26, 2025): 英伟达发布数据，他们使用Nvidia NIM部署671b fp8 速度高达3800+。估计应该是最高速度了。 NIM对显卡之间的通信做了优化。

bsakaguchi commented

2026-10-26 21:20:45 +00:00

Author

Owner

@AndrewTsao commented on GitHub (Feb 26, 2025):

启动命令。

vllm serve  DeepSeek-R1 \
   --max-model-len 131072 \
   --max-num-batched-tokens 65536 \
   --enable-reasoning --reasoning-parser deepseek_r1 \
   --port 1234 \
   --api_key sk-KFC-CRAZY-THURSDAY-VWO50 \
   --tensor-parallel-size 8 --trust-remote-code \
   --disable-log-requests \
   --gpu-memory-utilization 0.8

直接拿llmperf做的压力测试，

export OPENAI_API_KEY="sk-KFC-CRAZY-THURSDAY-VWO50"
export OPENAI_API_BASE="http://hpc-xxxx:1234/v1"
export PYTHONPATH=./src:$PYTHONPATH

python token_benchmark_ray.py \
--model "DeepSeek-R1" \
--mean-input-tokens 550 \
--stddev-input-tokens 150 \
--mean-output-tokens 150 \
--stddev-output-tokens 10 \
--max-num-completed-requests 300 \
--timeout 300 \
--num-concurrent-requests 32 \
--results-dir "result_outputs" \
--llm-api openai \
--additional-sampling-params '{}'

然后观察到的服务端的日志速率。

不知道有没有比较好一些的压力测试方法，这个llmperf输出来的 TTFT 都超过几秒，感觉是不是因为DeepSeek的输出跟openai的不一样，导致不正确。

@AndrewTsao commented on GitHub (Feb 26, 2025): 启动命令。 ```sh vllm serve DeepSeek-R1 \ --max-model-len 131072 \ --max-num-batched-tokens 65536 \ --enable-reasoning --reasoning-parser deepseek_r1 \ --port 1234 \ --api_key sk-KFC-CRAZY-THURSDAY-VWO50 \ --tensor-parallel-size 8 --trust-remote-code \ --disable-log-requests \ --gpu-memory-utilization 0.8 ``` 直接拿llmperf做的压力测试， ```sh export OPENAI_API_KEY="sk-KFC-CRAZY-THURSDAY-VWO50" export OPENAI_API_BASE="http://hpc-xxxx:1234/v1" export PYTHONPATH=./src:$PYTHONPATH python token_benchmark_ray.py \ --model "DeepSeek-R1" \ --mean-input-tokens 550 \ --stddev-input-tokens 150 \ --mean-output-tokens 150 \ --stddev-output-tokens 10 \ --max-num-completed-requests 300 \ --timeout 300 \ --num-concurrent-requests 32 \ --results-dir "result_outputs" \ --llm-api openai \ --additional-sampling-params '{}' ``` 然后观察到的服务端的日志速率。不知道有没有比较好一些的压力测试方法，这个llmperf输出来的 TTFT 都超过几秒，感觉是不是因为DeepSeek的输出跟openai的不一样，导致不正确。

bsakaguchi commented

2026-10-26 21:20:46 +00:00

Author

Owner

@magnshen commented on GitHub (Feb 27, 2025):

@AndrewTsao 你启动的DeepSeek-R1 是 fp8 吗?

我这边测出来只有500
Overall Output Throughput: 495.8239901015257

@magnshen commented on GitHub (Feb 27, 2025): @AndrewTsao 你启动的DeepSeek-R1 是 fp8 吗? 我这边测出来只有500 Overall Output Throughput: 495.8239901015257

bsakaguchi commented

2026-10-26 21:20:46 +00:00

Author

Owner

@AndrewTsao commented on GitHub (Feb 28, 2025):

英伟达发布数据，他们使用Nvidia NIM部署671b fp8 速度高达3800+。估计应该是最高速度了。 NIM对显卡之间的通信做了优化。

我看到vllm 项目组的成员发布了一些数据，可以参考下。

https://github.com/vllm-project/vllm/pull/13747#issuecomment-2687039690

可以复现。

@AndrewTsao commented on GitHub (Feb 28, 2025): > 英伟达发布数据，他们使用Nvidia NIM部署671b fp8 速度高达3800+。估计应该是最高速度了。 NIM对显卡之间的通信做了优化。我看到vllm 项目组的成员发布了一些数据，可以参考下。 https://github.com/vllm-project/vllm/pull/13747#issuecomment-2687039690 可以复现。

bsakaguchi commented

2026-10-26 21:20:46 +00:00

Author

Owner

@FlintyLemming commented on GitHub (Mar 15, 2025):

想知道你开 --max-num-batched-tokens 65536 的话，试过长上下文么，我开这么多的话，真有这么多上下文会直接报错

@FlintyLemming commented on GitHub (Mar 15, 2025): 想知道你开 --max-num-batched-tokens 65536 的话，试过长上下文么，我开这么多的话，真有这么多上下文会直接报错

bsakaguchi commented

2026-10-26 21:20:47 +00:00

Author

Owner

@AndrewTsao commented on GitHub (Mar 15, 2025):

我这个参数设置的是 8192。版本用的 0.7.4 开发版。主要调的输入上下文长度，并发 100 已经较高了。

@AndrewTsao commented on GitHub (Mar 15, 2025): 我这个参数设置的是 8192。版本用的 0.7.4 开发版。主要调的输入上下文长度，并发 100 已经较高了。

bsakaguchi commented

2026-10-26 21:20:47 +00:00

Author

Owner

@FlintyLemming commented on GitHub (Mar 15, 2025):

那就对了，vllm 的问题超过 32k 就会报 RuntimeError: Triton Error [CUDA]: an illegal memory access was encountered 错误，这似乎是一个已知问题

@FlintyLemming commented on GitHub (Mar 15, 2025): 那就对了，vllm 的问题超过 32k 就会报 `RuntimeError: Triton Error [CUDA]: an illegal memory access was encountered` 错误，这似乎是一个已知问题

bsakaguchi commented

2026-10-26 21:20:47 +00:00

Author

Owner

@github-actions[bot] commented on GitHub (Apr 19, 2025):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this issue is still relevant, please leave a comment to keep it open. Thank you for your contributions!

@github-actions[bot] commented on GitHub (Apr 19, 2025): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you believe this issue is still relevant, please leave a comment to keep it open. Thank you for your contributions!