12 KiB
12 KiB
SGLang 8-Card DeepSeek-V4-Flash 系统 Benchmark 报告
生成时间:2026-07-05 02:10:06
测试环境
- 模型:DeepSeek-V4-Flash (
/data/models/DeepSeek-V4-Flash) - 推理框架:SGLang
- 并行策略:TP=8,8× NVIDIA H200
- MoE backend:marlin
- 投机采样:EAGLE(
--speculative-num-steps 3 --speculative-eagle-topk 1 --speculative-num-draft-tokens 4) - 服务端口:30000
测试负载
- 数据集:ShareGPT V4.3 unfiltered cleaned split
- 请求数:每个测试点 2000 条真实对话请求
- 测试维度:
- 并发扫描:
--max-concurrency= 1, 8, 16, 32, 64, 128 - 请求速率扫描:
--request-rate= 1, 2, 4, 8, 16 (Poisson-like)
- 并发扫描:
Phase 1:并发扫描结果
| 并发 | 耗时(s) | req/s | input tok/s | output tok/s | total tok/s | Mean TTFT(ms) | Mean TPOT(ms) | Mean E2E(ms) | Accept Length |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 1715.45 | 1.17 | 335.83 | 243.51 | 579.34 | 128.09 | 4.00 | 856.77 | 2.62 |
| 8 | 448.91 | 4.46 | 1283.33 | 930.54 | 2213.87 | 146.76 | 8.41 | 1790.65 | 2.61 |
| 16 | 331.79 | 6.03 | 1736.31 | 1259.00 | 2995.30 | 168.95 | 12.67 | 2642.10 | 2.61 |
| 32 | 267.72 | 7.47 | 2151.87 | 1560.32 | 3712.19 | 206.24 | 20.72 | 4249.71 | 2.61 |
| 64 | 207.57 | 9.64 | 2775.39 | 2012.43 | 4787.82 | 248.41 | 32.61 | 6557.39 | 2.61 |
| 128 | 139.41 | 14.35 | 4132.36 | 2996.37 | 7128.73 | 330.40 | 46.15 | 8596.12 | 2.61 |
Phase 2:请求速率扫描结果
| RPS | 耗时(s) | req/s | input tok/s | output tok/s | total tok/s | Mean TTFT(ms) | Mean TPOT(ms) | Mean E2E(ms) | Accept Length |
|---|---|---|---|---|---|---|---|---|---|
| 1 | 2011.46 | 0.99 | 286.41 | 207.67 | 494.08 | 146.87 | 4.91 | 1007.62 | 2.61 |
| 2 | 1007.21 | 1.99 | 571.97 | 414.74 | 986.71 | 160.63 | 5.99 | 1205.24 | 2.61 |
| 4 | 505.49 | 3.96 | 1139.69 | 826.39 | 1966.08 | 174.67 | 9.02 | 1743.40 | 2.60 |
| 8 | 256.46 | 7.80 | 2246.34 | 1628.82 | 3875.15 | 216.65 | 25.35 | 4542.64 | 2.60 |
| 16 | 137.92 | 14.50 | 4176.94 | 3028.70 | 7205.64 | 377.28 | 87.16 | 15048.09 | 2.61 |
关键发现
- 吞吐随并发单调上升:从 c=1 的 579 tok/s 提升到 c=128 的 7129 tok/s,说明 8×H200 在高压下仍能有效扩展。
- c=32 是延迟与吞吐的拐点:c=32 时 total tok/s 为 3712,E2E 延迟约 4.25s;c=64 时吞吐提升到 4788,但延迟增加到 6.56s。
- c=128 达到最高吞吐:total tok/s = 7129,output tok/s = 2996,但 E2E 延迟接近 8.6s,适合离线/批处理场景。
- RPS=16 时系统过载:实际 req/s 达到 14.5,TPOT 飙升到 87ms,E2E 延迟 15s,说明 RPS>14 已超出稳定运行区间。
- RPS=8 是稳定高吞吐边界:total tok/s = 3875,E2E 延迟 4.54s,TTFT 仅 217ms,体验与吞吐兼顾。
- EAGLE 投机采样稳定生效:Accept Length 稳定在 2.60–2.62,有效降低了 decode 步数。
场景建议
| 场景 | 推荐配置 | 理由 |
|---|---|---|
| 低延迟在线 API | --max-concurrency 8 |
TTFT 147ms,TPOT 8.4ms,E2E 1.79s |
| 平衡型在线服务 | --max-concurrency 16 或 --request-rate 4 |
吞吐约 3k tok/s,E2E 2.6–1.7s |
| 高吞吐在线服务 | --max-concurrency 32 或 --request-rate 8 |
吞吐 3.7–3.9k tok/s,E2E 4.3–4.5s |
| 最大吞吐/离线批处理 | --max-concurrency 128 |
吞吐 7.1k tok/s,E2E 8.6s |
| 避免使用 | --request-rate 16 |
系统过载,E2E 15s,TPOT 87ms |
原始数据
- 汇总 JSON:
bench_results/sglang_8card_systematic_20260704_120819/summary.json - 每个测试点的详细结果与日志:
bench_results/sglang_8card_systematic_20260704_120819/
附录 A:Benchmark 参数说明
本次所有测试均使用 sglang.bench_serving 工具,参数统一如下:
envs/sglang/bin/python -m sglang.bench_serving \
--backend sglang \
--host 127.0.0.1 \
--port 30000 \
--dataset-name sharegpt \
--dataset-path /data/user1/yy/datasets/ShareGPT_V4.3_unfiltered_cleaned_split.json \
--num-prompts 2000 \
--model /data/models/DeepSeek-V4-Flash \
--seed 42
两个测试维度的区别仅在于最后一条参数:
-
并发扫描:
--max-concurrency {1,8,16,32,64,128}- 客户端同时保持 N 个未完成的请求,服务器队列按需堆积。
- 适合模拟“系统能扛多少并发”的容量测试。
-
请求速率扫描:
--request-rate {1,2,4,8,16}- 客户端按泊松分布以固定 RPS 发送请求。
- 适合模拟真实线上按流量到达的场景。
指标定义
| 指标 | 含义 |
|---|---|
| req/s | 每秒完成的请求数 |
| input tok/s | 每秒处理的输入 token 数 |
| output tok/s | 每秒生成的输出 token 数 |
| total tok/s | input tok/s + output tok/s |
| TTFT | Time To First Token,首 token 延迟 |
| TPOT | Time Per Output Token,除首 token 外平均每个输出 token 的间隔 |
| E2E Latency | 端到端请求完成时间 |
| Accept Length | EAGLE 投机采样平均每次接受的 draft token 数 |
附录 B:Token 成本计算
假设
- GPU 单价:8.0 元 / 卡 / 小时
- 本次部署使用 8× NVIDIA H200
- 整机每小时成本:
8 卡 × 8.0 元/卡/h = 64 元/h
公式
对于任意一个 benchmark 结果:
每小时处理 input tokens = input_tok/s × 3600
每小时生成 output tokens = output_tok/s × 3600
每 1M input tokens 成本 = 64 / (input_tok/s × 3600 / 1,000,000)
每 1M output tokens 成本 = 64 / (output_tok/s × 3600 / 1,000,000)
各场景成本
| 场景 | input tok/s | output tok/s | 1M input cost | 1M output cost |
|---|---|---|---|---|
| c=1 | 335.83 | 243.51 | 52.94 元 | 73.01 元 |
| c=8 | 1,283.33 | 930.54 | 13.85 元 | 19.10 元 |
| c=16 | 1,736.31 | 1,259.00 | 10.24 元 | 14.12 元 |
| c=32 | 2,151.87 | 1,560.32 | 8.26 元 | 11.39 元 |
| c=64 | 2,775.39 | 2,012.43 | 6.41 元 | 8.83 元 |
| c=128 | 4,132.36 | 2,996.37 | 4.30 元 | 5.93 元 |
| rps=1 | 286.41 | 207.67 | 62.07 元 | 85.61 元 |
| rps=2 | 571.97 | 414.74 | 31.08 元 | 42.86 元 |
| rps=4 | 1,139.69 | 826.39 | 15.60 元 | 21.51 元 |
| rps=8 | 2,246.34 | 1,628.82 | 7.91 元 | 10.91 元 |
| rps=16 | 4,176.94 | 3,028.70 | 4.26 元 | 5.87 元 |
对外定价建议
裸 GPU 成本不等于对外售价。建议根据 SLA 和毛利率加价:
| 推荐场景 | 裸成本(input/output) | 说明 |
|---|---|---|
| 低延迟在线(c=8) | 13.85 元 / 19.10 元 per 1M | TTFT 147ms,TPOT 8.4ms,适合实时聊天 |
| 平衡型在线(c=16) | 10.24 元 / 14.12 元 per 1M | 吞吐与延迟兼顾,主流 API 可参考此档位 |
| 高吞吐在线(c=32 / rps=8) | 8.09 元 / 11.15 元 per 1M | 吞吐高、延迟可接受,适合批量在线服务 |
| 最大吞吐/离线(c=128) | 4.30 元 / 5.93 元 per 1M | 延迟 8.6s,仅适合离线批处理 |
注意:
rps=16虽已接近最大吞吐,但系统已明显过载(E2E 15s),不建议按此成本对外定价。
附录 C:最大吞吐压测(优化服务参数)
为了探索成本下限,重新部署了服务并调优了参数:
envs/sglang/bin/sglang serve \
--trust-remote-code \
--model-path /data/models/DeepSeek-V4-Flash \
--tp 8 \
--moe-runner-backend marlin \
--speculative-algorithm EAGLE \
--speculative-num-steps 3 \
--speculative-eagle-topk 1 \
--speculative-num-draft-tokens 4 \
--max-running-requests 512 \
--chunked-prefill-size 16384 \
--host 0.0.0.0 \
--port 30000
与附录 A/B 的测试相比,主要变化:
--max-running-requests从默认 256 提升到 512--chunked-prefill-size从默认 8192 提升到 16384
超大并发扫描结果
| 并发 | 耗时(s) | req/s | input tok/s | output tok/s | total tok/s | Mean TTFT | Mean TPOT | Mean E2E(ms) |
|---|---|---|---|---|---|---|---|---|
| 128 | 155.26 | 12.88 | 3,710.50 | 2,690.48 | 6,400.98 | 410.55 ms | 48.45 ms | 9,696.87 |
| 256 | 90.65 | 22.06 | 6,355.48 | 4,608.35 | 10,963.84 | 509.73 ms | 62.71 ms | 10,869.76 |
| 512 | 71.39 | 28.02 | 8,070.04 | 5,851.58 | 13,921.61 | 1,343.73 ms | 121.20 ms | 16,176.14 |
| 1024 | 68.21 | 29.32 | 8,445.53 | 6,123.84 | 14,569.37 | 13,265.46 ms | 105.36 ms | 27,566.99 |
关键发现
- 高并发下吞吐显著提升:优化参数后,c=256 及以上远超原配置的最高值(7,129 tok/s);c=1024 达到 14,569 tok/s,约为原配置峰值的两倍。
- c=1024 达到最高吞吐:total 14,569 tok/s,output 6,124 tok/s,但 TTFT 13.3s,系统已严重过载。
- c=512 是实际可用上限:total 13,922 tok/s,output 5,852 tok/s,虽然 TTFT 1.3s、E2E 16s,但吞吐接近峰值,适合离线批处理。
- c=256 是高压在线的甜点:total 10,964 tok/s,TTFT 510ms,E2E 10.9s,如果业务能容忍 10 秒级响应,这是性价比很高的点。
附录 D:最低 Token 成本(基于最大吞吐)
仍按 8.0 元/卡时、8 卡整机 64 元/小时 计算。
公式
每 1M input tokens 成本 = 64 / (input_tok/s × 3600 / 1,000,000)
每 1M output tokens 成本 = 64 / (output_tok/s × 3600 / 1,000,000)
最大吞吐场景成本
| 场景 | input tok/s | output tok/s | 1M input cost | 1M output cost |
|---|---|---|---|---|
| c=128 | 3,710.50 | 2,690.48 | 4.79 元 | 6.61 元 |
| c=256 | 6,355.48 | 4,608.35 | 2.80 元 | 3.86 元 |
| c=512 | 8,070.04 | 5,851.58 | 2.20 元 | 3.04 元 |
| c=1024 | 8,445.53 | 6,123.84 | 2.10 元 | 2.90 元 |
结论
在当前硬件和优化参数下:
- 理论最低 input 成本:约 2.10 元 / 1M input tokens(c=1024)
- 理论最低 output 成本:约 2.90 元 / 1M output tokens(c=1024)
- 实际可用最低成本:c=512 时 2.20 元 / 1M input、3.04 元 / 1M output,此时吞吐已达峰值 95% 以上,且延迟比 c=1024 可控得多。
注意:c=1024 的 TTFT 超过 13 秒,仅适合完全不在意延迟的离线批处理任务;对外 API 服务不建议按此成本定价。
附录 E:测试数据长度分布
本次所有 benchmark 使用的是 ShareGPT_V4.3_unfiltered_cleaned_split.json 数据集。sglang.bench_serving 在 --num-prompts 2000 且 --seed 42 的条件下,从数据集中采样出 2000 条真实对话请求作为测试负载。
长度统计
| 指标 | Input Tokens | Output Tokens |
|---|---|---|
| 请求数 | 2,000 | 2,000 |
| 平均值 | 288.05 | 208.86 |
| 标准差 | 420.07 | 217.60 |
| 最小值 | 2 | 2 |
| P50 | 125 | 150 |
| P90 | 723 | 516 |
| P95 | 841 | 667 |
| P99 | 2,190 | 811 |
| 最大值 | 3,996 | 1,655 |
| 总量 | 576,098 | 417,728 |
分布特点
- 输入长度呈现典型长尾分布:P50 仅 125 tokens,但 P99 达到 2,190 tokens,最大值 3,996 tokens。说明 ShareGPT 中既有大量短 prompt,也有少量长上下文对话。
- 输出长度相对集中:P50 150 tokens,P90 516 tokens,P99 811 tokens,最大值 1,655 tokens。大部分回复属于中等长度。
- 输出/输入比约为 0.73:平均每条请求输出 209 tokens、输入 288 tokens,整体负载偏 decode 侧。
- 与原始 ShareGPT 全集的差异:原始全集输出长度均值约 1,122 tokens,而 bench 采样后的输出均值仅 209 tokens。这是因为
sglang.bench_serving在处理 sharegpt 数据集时会根据内置规则对输出做截断/采样,以更贴近典型在线 serving 负载。
长度分布图
图表文件:
bench_results/sglang_8card_systematic_20260704_120819/length_distribution.png
