这几天写了 V4 的技术解读、云实例 TCO、买断报价，后台问得最多的还是一个更基础的问题——
「DeepSeek V4-Pro 在 8×141GB 机器上，到底什么水平？H20 能参考吗？」
这个问题不是靠猜能答上来的。所以这篇文章，我直接用 GPUStack 团队的实测压测数据 说话。但在看数字之前，必须先把两个容易踩的坑说清楚。
坑一：这不是全精度版本，是官方低精度服务权重。 DeepSeek V4-Pro 官方发布的不是 FP16/BF16 全精度权重，而是 FP4+FP8 混合精度——MoE 专家参数用 FP4，Attention / Norm / Router 等部分用 FP8。这不是第三方随手量化，是 DeepSeek 官方发布的推理部署版本。正是这个精度前提，1.6T 参数的模型才能在 8×141GB 单机上启动。没有这个设定，这件事根本不成立。
坑二：单机测试的意义不是证明”满血 V4-Pro 能单机跑”。 这组数据真正回答的是五个工程问题：
- 官方低精度权重在 8×141GB 机器上能不能启动
- 显存边界在哪里
- 粗略吞吐能到什么水平
- 哪些参数一拉高就 OOM
- 企业私有化的最低门槛和风险大概在哪
它是一条工程可行性的边界线，不是满血模型的性能天花板。H20 141GB 可以参考这条边界，但吞吐数字需要自己的机器重新压测；96GB H20 则不应套用这篇的结论。
TPM、RPM、TTFT、TPOT——每一个数字都是真实跑出来的，不是 PPT 里的理论值。这是官方服务权重下的实际工程水位。
⚠️ 数据口径说明：封面及插图为视觉辅助，文中所有实测数字（TPM/RPM/TTFT/TPOT）均来自 GPUStack 在 8×NVIDIA H200 141GB 上的压测。H20 141GB 同级显存，可参考部署思路和显存边界，但吞吐性能不能直接套用，需自行压测。
一、先搞清楚：测的是什么配置？
压测环境：单台 8×NVIDIA H200 141GB，推理引擎 vLLM v0.20.0-cu130，平台 GPUStack v2.1.2，KV Cache 精度 FP8，GPU 显存利用率 0.95。
模型是 DeepSeek-V4-Pro（1.6T 总参数，49B 激活参数），跑的是官方 FP4+FP8 混合精度权重。MoE 架构 + 专家并行 + 低精度权重三者叠加，才把显存压力压到 8×141GB 单机可承受的范围。能启动和能稳定高并发是两回事——真正吃紧的始终是长上下文和高并发叠加带来的 KV Cache 占用。
测试分两种并行模式：
| 模式 | 说明 |
|---|---|
| TP 8 + EP | Tensor Parallel 8卡 + 专家并行，单请求延迟优先 |
| DP 8 + EP | Data Parallel 8卡 + 专家并行，总吞吐量优先 |
这两种模式代表了两种截然不同的部署哲学，选哪个取决于你的业务诉求。
二、先分清楚两个维度：单请求速度 vs 系统总吞吐
这里必须先把两个经常被混淆的指标说清楚，否则后面的数字根本没法理解：
| 指标 | 含义 | TP 8 + EP | DP 8 + EP |
|---|---|---|---|
| 单请求速度（per-request） | 一个请求被服务时的输出速率 | 68 tok/s | 43 tok/s |
| 系统总吞吐（aggregate） | 整台机器所有并发输出的总速率 | ~2,483 tok/s | ~10,289 tok/s |
两组数字量纲不同，不能放在一起直接比大小。43 tok/s 和 10,289 tok/s 描述的根本不是同一件事。
为什么 DP8 单请求只有 43 tok/s，总吞吐却能到 10,289 tok/s？
DP8+EP 的逻辑是数据并行调度配合专家并行——每张卡并不是完整复制一份 1.6T 模型，而是在 Expert Parallelism 的配合下分摊 MoE 专家权重，由调度层把不同的请求批次分发给不同的 GPU 组处理。对于某一个具体请求来说，它只被当前分配的 GPU 组服务，所以速度是 43 tok/s；但整台机器同时在并行调度大量请求，把所有并发输出加在一起，总速率就能到 10,289 tok/s。
相比之下，TP8 是把 8 张卡的力气全部集中服务一个请求——单请求速度快（68 tok/s），但同时能承载的并发数有限，总吞吐自然低于 DP8。
一句话：TP8 快在单人体验，DP8 赢在整体产能。
延迟数据同样印证了两者的特点差异：
| 指标 | TP 8 + EP | DP 8 + EP |
|---|---|---|
| TTFT（首 Token 延迟） | ~240 ms | ~273 ms |
| TPOT（每 Token 延迟） | ~21 ms | ~33 ms |
TP8 的 TTFT 约 240ms，TPOT 约 21ms（即延迟压测中每输出一个 Token 的平均间隔）——对话场景下完全可以接受，基本感觉不到卡顿。 DP8 的感知延迟慢约 30%，换来的是整体吞吐量的 4 倍提升，值不值得取决于你的业务形态。
三、吞吐压测：峰值 10K tokens/s，但有个大坑
吞吐测试最能反映真实的服务能力。测了三种配置：
| 配置 | 输出吞吐量 | 稳定性 |
|---|---|---|
| TP8+EP，max-batched-tokens=512 | ~2,483 tokens/s | ✅ 稳定 |
| TP8+EP，max-batched-tokens=8192 | ~6,936 tokens/s | ⚠️ 显存压力大 |
| DP8+EP，max-batched-tokens=512 | ~10,289 tokens/s | ✅ 峰值最高 |
| DP8+EP，max-batched-tokens=8192 | ❌ OOM 崩溃 | — |
从 512 提升到 8192，TP 模式吞吐提升接近 3 倍。 但 DP 模式直接 OOM 崩溃——说明这个参数对显存和 KV Cache 的压力极大，不能莽撞拉高。
那个坑：DP8+EP + 高 batch 是最危险的组合。 生产环境不建议盲目冲刺极限，应该从保守配置起步，逐步压测找安全区间。
四、TPM/RPM 到底多少？换算给你看
先把换算公式说清楚，否则很容易搞混：
TPM（系统总） = 整机并发总吞吐（tok/s） × 60
注意，这里用的是系统总吞吐，不是单请求速率。如果你用 68 tok/s（TP8 单请求速度）去乘 60，只能得到 4,080——这只是一个请求在一分钟内产出的 token 数，跟系统 TPM 是完全不同的概念。
617K TPM 的来源：DP8+EP 模式下，整机实测总吞吐 10,289 tok/s，乘以 60 秒 ≈ 617K。这是整台机器同时服务所有并发请求的总产出，不是单个请求的速率。
按此公式换算（RPM 按 500 tokens/请求 估算）：
| 配置 | 整机总吞吐（tok/s） | TPM（×60） | RPM |
|---|---|---|---|
| TP8+EP，稳定配置（batch=512） | 2,483 | ~149K | ~298 |
| TP8+EP，高吞吐（batch=8192） | 6,936 | ~416K | ~832 |
| DP8+EP，峰值（batch=512） | 10,289 | ~617K | ~1,234 |
峰值 617K TPM 是 DP8 模式、保守 batch 配置下的整机最高产出，不代表单个用户能得到这个速率。真实可承载并发人数还要看上下文长度、响应长度和业务高峰分布，不能直接用 TPM 除以每人请求数换算在线人数。
五、8×141GB 单机能跑什么场景？哪些场景别碰？
实测数据给出了清晰的场景边界：
✅ 8×141GB 单机跑得稳的场景：
- 企业内部智能问答 — 中低并发、平均上下文 32K 以内，稳定运行无压力
- 代码审查 / 代码生成 — 请求量可控，单请求质量优先，TP8 模式首选
- Agent 工作流调用 — 短上下文、高频次，DP8 模式吞吐够用
- 文档摘要 / 报告生成 — 批量处理，DP8 高吞吐模式，一台机器服务整个部门
⚠️ 8×141GB 单机谨慎运行的场景：
- 百万 Token 长上下文 — 技术上支持 1M，但高并发下 KV Cache 爆满极易 OOM，生产建议限制在 128K~512K
- 高并发 + 长上下文双重压力 — 两个因素叠加，是最容易崩溃的组合
❌ 不建议碰的场景：
- DP8 + max-batched-tokens=8192 + 长上下文 — 直接 OOM，实测验证
一句话总结：公开资料显示，8×H200 141GB 可以在特定配置下跑 V4-Pro，但这是贴着显存上限跑，不宽松。 H20 141GB 如果要上生产，显存边界可以参考这组数据，但吞吐和稳定区间必须重新实测。至于 96GB H20，不应套用这篇的结论。
六、三个调优核心：稳定比性能更重要
做了这么多压测，给到三个最重要的实战建议：
第一，并行策略按场景选，不要一刀切。 低并发、对话体验优先 → TP8；高并发、批量处理 → DP8。两种模式不是好坏之分，是不同业务场景的最优解。
第二，上下文长度是硬约束，不是软参数。 --max-model-len auto 理论上优雅，但生产中极不安全。推荐显式设置为 131072 或 262144，换取可预测的稳定性。需要注意：131K/262K 是稳定优先配置，适合日常对话和文档摘要；如果要支持 Think Max 模式或超长文档任务，DeepSeek 官方模型页提到至少需要约 384K，务必按实际场景重新压测 KV Cache 边界。
第三，OOM 是性能追求的天花板，不是 Bug。 在 8×141GB 单机环境下，真正限制并发能力的不只是算力，还有 KV Cache 空间。扩展 KV Cache（LMCache/HiCache）是下一步提升稳定性的关键方向。
写在最后
连着四天写 DeepSeek V4 的系列文章，从技术架构、到云实例 TCO、到买断报价、再到今天的压测数据——把一个问题从四个维度掰开揉碎，这才是做技术判断的正确姿势。
8×H200 141GB 跑 DeepSeek V4-Pro？公开资料显示可以跑，但前提很苛刻：官方混合精度权重、专家并行、保守上下文和认真调过的参数配置。H20 141GB 能不能达到同样水位，不要靠猜，还是要按自己的机器和业务负载再压一遍。
数字不骗人。8×H200 141GB 实测，整机峰值总吞吐 10,289 tok/s，换算 617K TPM——这是官方服务权重下的实际工程水位。够不够用，对着你的业务量算一下，自然有答案。
我一个人打造的 Zaokit AI 正在内测，2026年4月30日前1000名用户赠送价值150RMB的Pro计划，助力大家高效完成图文创作和PPT生成，唯一网站：zaokit.app。
DeepSeek-V4 私有化买断 GPU 要多少钱？两套方案，价格我都算好了