素材：模型选型对产能的影响——以 DeepSeek V4 Pro vs Flash 为例
用途：支撑 P8 产能页「模型与配置声明」卡——产能数字必须绑定模型，因为模型决定”单卡产能”和”单价”两个变量。核心结论（口径分层）：单卡产能差 ~2×（官方实测）、集群同卡数端到端差 3.8×（理论）；模型选型 = 通信税的多少，拓扑决定税率——模型越大越依赖高速互联，互联带宽决定产能兑现率。
数据来源：SGLang 官方 cookbook re-benchmark（PR #31363）、LMSYS Day-0 blog、AWS DLC PR、vLLM 官方 blog 与社区实测（见文末）。
一、演讲核心叙事（30 秒口播版）
产能 = 单卡产出 × 卡数；单卡产出 ∝ 1/激活参数。
模型不同，影响产能的三个变量：
- 单卡产能（官方高并发实测）：Flash ~8,400 vs Pro ~4,200 tok/s/卡，差 ~2×（注意 Pro 测在 B300、硬件强一代，同硬件差距更大）
- 集群产能（同卡数）：端到端（prefill+decode 全流程）资源消耗差 3.8×——模型选型决定「同样产能要几倍的卡」
- 通信税：大模型必须切卡 → 必须高速互联 → 通信开销是”为了能跑”交的税；拓扑（NVLink/IB）决定税率——单节点可隐藏（接近理论），跨节点拖死（产能归零）
- 单价：模型越强、token 越值钱（Pro 输出 27 元 vs Flash 9 元/百万，忙时价）——产能低，但 $/MTok 高
模型选型 = 在”单卡产能 × 通信税 × token 值钱”之间做选择——这正是”产能数字必须绑定模型声明”背后的经济学。
二、产能的物理来源（先给直觉）
| 阶段 | 瓶颈 | 关系 |
|---|---|---|
| Prefill（读题，算力密集） | FLOPs | 每 token 算力 ∝ 激活参数 → 吞吐 ≈ 算力 ÷ 激活参数 |
| Decode（逐字生成，带宽密集） | 内存带宽 | 每 token 读一遍激活参数 → tokens/s ≈ 带宽 ÷ 激活参数字节数 |
- 是激活参数，不是总参数：MoE 下两者差几十倍（Pro 49B/1.6T = 3.06%，Flash 13B/284B = 4.58%）。
- 推论（严谨版）：激活参数减半 → 每 token 权重读取与 FFN 算力各减半 → 产能理论上限翻倍；实际倍数 = 上限 × 饱和率 × kernel 效率 × (1 − 注意力/KV 占比)。
三、端到端流程视角（为什么说”~2–3.8 倍”）
单看 decode 或单卡都是片面的——请求是 prefill → decode 串联，稳态引擎两类请求共享 GPU（continuous batching）。
真实负载把流程量化（素材 10 生产实测）：input:output ≈ 294:1、prefix 命中 ~96% → 真正重算的 input ≈ 12:1（每产出 1 个 output token 要 prefill 12 个 input token）。
同卡数、同稳态负载下的资源消耗（BF16 口径）：
| 成本项 | Flash（13B 激活） | Pro（49B 激活） | 差距 |
|---|---|---|---|
| prefill 算力（12× 重算 × 每 token FLOPs） | 12 × 52 GFLOPs ≈ 624 | 12 × 196 ≈ 2,352 | 3.8× |
| decode 带宽（每 token 权重读取） | 26GB | 98GB | 3.8× |
| 端到端资源消耗 | 1 | 3.8× | 3.8× |
端到端结论（集群·同卡数口径）：各 8 卡时，Flash 集群端到端产能 ≈ Pro 集群的 3.8 倍（理论上限）——这是「模型选型决定卡数」的核心依据。实际偏离由三个调制器决定：
- MTP（多 token 预测）：一次前向预测多个 token，decode 不再纯”每 token 读一遍”——投机解码实测提速近 3 倍；单卡瓶颈的 Flash 收益更大
- PD 分离：prefill 池（算力型）+ decode 池（带宽型）独立扩缩容——池配比按 ISL:OSL 调，12:1 重算比下 Pro 的 prefill 池压力是 Flash 的 3.8 倍
- 稀疏注意力（DSA/CSA）：1M 上下文 prefill 注意力不再 O(n²)——两兄弟都受益，Flash 更长上下文下 prefill 占比更低
按负载类型：decode 主导（短对话、高并发）→ 差距 ~2 倍；prefill 主导（RAG、长上下文、Agent 重读）→ 差距趋近 3.8 倍。
四、通信税：切卡的代价（模型越大税率越高）
前提：Pro 激活 49B 单卡放不下/带宽不够 → 必须切卡 → 切卡必须高速互联（NVLink 单节点 / IB 跨节点）→ 通信开销是”为了能跑”交的税，不是优化问题。没有互联，模型根本起不来。
税率由”互联带宽 vs 通信量”的比值决定：
| 链路 | 带宽 | vs HBM（8TB/s） | 通信能否隐藏 | 产能兑现 |
|---|---|---|---|---|
| 单节点 NVLink | ~900GB/s | 1/9 | 大部分可隐藏（与权重读取重叠） | 接近理论（次线性但接近线性） |
| 跨节点 IB 400G | ~50GB/s | 1/160 | 隐藏不了 | 拖死（产能归零） |
机制：通信时间 / 权重读取时间 = (通信量/权重读取量) × (HBM带宽/互联带宽)。MoE all-to-all 通信量 ∝ token 数 × 专家维度，与权重读取同量级（~1/4–1/2）——乘带宽比 1/9（NVLink）≈ 通信占 4–9 倍读取时间但可重叠；乘 1/160（IB）= 40–80 倍，完全无法隐藏。
产能增长 vs 参数比——没有固定关系，拓扑决定：
| 场景 | 产能增长 vs 参数比 | 机制 |
|---|---|---|
| 理论上限（无通信损耗） | 线性 = 3.8× | 带宽/算力 ∝ 1/激活参数 |
| 通常部署（单节点、成熟引擎） | 次线性 ~2× < 3.8× | decode 固定同步延迟、kernel 效率不随参数缩 |
| 跨节点通信重（Day-0 极端） | 超线性 30× » 3.8× | Pro 被 all-to-all + 同步拖死（AWS 实证） |
为什么通常场景是次线性：decode 每 token 时间 = 权重读取（∝ 参数，线性缩）+ 通信与同步（不按比例缩）——all-reduce 每 step 两轮同步、all-to-all 一轮，单次同步的往返延迟（跨节点 ~10–50μs）与小模型无关；Flash 权重读取时间本来就短，固定延迟占比反而更高。
模型选型 = 通信税的多少：
| Flash | Pro | |
|---|---|---|
| 部署 | 1–2 卡 | 8–32 卡 |
| 通信税 | ≈ 0 | 单节点 NVLink：税低（可隐藏）；跨节点：税高（拖死） |
| 产能兑现 | 接近理论 | 单节点接近理论，跨节点崩 |
“Flash 只要一半卡”的隐含前提是”同拓扑”（都单节点）——一旦 Pro 必须跨节点，Flash 优势从 2× 跳到 30×。
五、实测数据（SGLang / vLLM）
SGLang cookbook 官方 re-benchmark（v0.5.15，单卡 tok/s/GPU）
| 配置 | 低并发 | 高并发 |
|---|---|---|
| B200 + V4-Flash FP4 | 585（c1）→ 8,399（c256） | 8,345–8,676（c1024–4096） |
| B300 + V4-Pro | — | ~4,203（高并发）、4,400（c4096） |
| GB300 + V4-Flash FP4 | 513（c1）→ 6,366（c1024） | ~6,246（c4096） |
| H200（V4-Flash） | 729–3,407（不同配置） | — |
高并发下 Flash 单卡 ≈ Pro 的 2 倍（激活 3.8 倍被精度/调度损耗打折；注意 Pro 测在 B300，硬件强一代）。
LMSYS Day-0（SGLang，V4-Pro，TP=8，单请求）——集群口径（8 卡整模型）
- B200 decode ~199 tok/s（4K ctx）、~180 tok/s（900K）；H200 ~266 / ~240
- decode 从 4K 到 900K 几乎不衰减（稀疏注意力 + ShadowRadix）
AWS DLC PR（SGLang，H100，同引擎同硬件直接对比，并发 32）——集群口径（8 卡 vs 16 卡）
| V4-Flash（8 卡） | V4-Pro（16 卡） | |
|---|---|---|
| 输出 tok/s | 1,284 | 42.93 |
| 总 tok/s | 6,890 | 230 |
Pro 卡数多一倍、吞吐低 30 倍——跨节点（TP=16 走 EFA）+ KV 约束的 Day-0 极端样本，是”通信税”的最直观实证（不代表稳态）。
vLLM 社区实测（V4-Flash）——集群口径（多卡整模型）
| 配置 | decode | prefill |
|---|---|---|
| 4×RTX PRO 6000（stock vLLM 0.25.1） | ~133 tok/s 单流 | ~12,500 tok/s @ 256K |
| 4×RTX 5090 TP4 | 214 tok/s median | 6,101 tok/s |
| 4 节点 DGX Spark（TP=4） | ~56 tok/s 单流 | ~2.7k tok/s（100K 上下文不衰减） |
vLLM 官方 blog 无吞吐数字，仅确认支持与部署 recipe（Pro 8×B200/B300、Flash 4×B200/B300，1M 上下文 KV 9.62GiB/BF16）。
六、换算成产能四数（P8 页直接可用）
单卡产能（官方高并发口径）
| Flash | Pro | 差距 | |
|---|---|---|---|
| 单卡产能 | ~8,400 tok/s/卡（B200） | ~4,200 tok/s/卡（B300） | ~2× |
集群日上限（= 单卡 × 卡数 × 86400）——集群口径，各取典型部署
| Flash | Pro | |
|---|---|---|
| 部署 | 8 卡（1 节点） | 16 卡（2 节点） |
| 日上限 | 8,400 × 8 × 86,400 ≈ 5.8 万亿 tok/天 | 4,200 × 16 × 86,400 ≈ 5.8 万亿 tok/天 |
同样的日产能，Flash 只要一半的卡（同拓扑前提下）——这就是”模型影响产能”最直白的说法：模型选型决定你买多少卡。
日产值（= 日上限 × $/MTok）——产能低但 token 值钱
DeepSeek 现行目录价（忙时）：Pro 输出 27 元/百万 vs Flash 输出 9 元/百万——Pro 单 token 3 倍价。产能差距 2× × 单价差距 3× → 同样卡数的日产值 Pro 反而可能更高（按不同负载口径差异大，演讲只讲方向）。
七、演讲用法（P8 模型卡的口播支撑）
- “模型与配置声明”卡：产能数字必须绑定模型——Pro vs Flash 激活参数差 3.8 倍，单卡产能差 ~2×（实测），跨模型比 token 数没有意义，只能比钱（$/MTok）
- “同样的日产能，Flash 只要一半的卡”：模型选型直接决定卡数需求——这是模型影响产能的最强一句话（隐含前提：同拓扑）
- “通信税”：大模型必须切卡、必须高速互联——单节点 NVLink 税低（接近理论），跨节点 IB 拖死（AWS 实证 30×）——产能永远绑定”模型 + 配置 + 拓扑”，这是 P8 三变量声明的完整版
- “产能低但 token 值钱”：Pro 单卡产能是 Flash 的一半，但单价是 3 倍——模型选型是”产能 × 通信税 × 单价”的权衡
八、口径注（引用前必读）
- 数据跨引擎（SGLang/vLLM）、跨精度（FP4/FP8/Q4）、跨硬件（B200/B300/H200/H100/RTX），不可直接横向对比——同源对比只有 AWS 那组（H100 + SGLang）。
- Day-0 数字（LMSYS、AWS PR）偏保守，成熟版本（v0.5.15）已有大幅提升（GB300 5×）。
- 高并发数字是”吞吐”口径（tok/s/GPU 聚合），单流数字是”延迟”口径——讲演讲时区分。
- 产能四数的换算用官方高并发口径，属于”工程可实现”而非”理论极限”；日产值按 DeepSeek 官方目录价（忙时），限时/闲时价不同，引用前复核。
- “一半的卡”隐含”同拓扑（单节点）”前提；跨节点场景 Flash 优势跳到 30×。
九、来源链接
- SGLang cookbook re-benchmark（PR #31363）：https://github.com/sgl-project/sglang/pull/31363
- LMSYS Day-0 blog：https://www.lmsys.org/blog/2026-04-25-deepseek-v4/
- AWS DLC PR #6144：https://github.com/aws/deep-learning-containers/pull/6144
- vLLM blog：https://blog.vllm.com.cn/2026/04/24/deepseek-v4.html
- DeepSeek-V4-Flash on 4×RTX PRO 6000：https://raw.githubusercontent.com/hermia-ai/deepseek-v4-flash-sm120-stock-vllm/main/README.md
- PyTorch blog（GB300 5×）：https://pytorch.org/blog/serving-deepseek-v4-on-gb300-with-sglang-5x-higher-throughput-at-the-same-interactivity-since-day-0/
- DeepSeek V4 Pro 部署条件：https://www.ai-indeed.com/encyclopedia/29654.html
- VLLM Recipes：https://recipes.vllm.ai/deepseek-ai/DeepSeek-V4-Pro