zz
我把它和理论核算 + 公开实测数据做了对照，结论先说：整体方向和数量级基本靠谱，容量规划值（右侧单列）偏保守、可以安全用于产能测算；但区间上限和个别方法论存在问题。
分项核对
Qwen3-235B-A22B（表中唯一能用实测验证的一行）—— 校准得不错
恰好有 GPUStack 在 8×A100 SXM 80G 上对该模型的完整压测：vLLM 基线约 1,798 output tok/s（ShareGPT 高并发负载），SGLang 约 2,202 tok/s，峰值 3,297–4,926 tok/s。报告区间 1,500–3,500、规划值 1,200，与实测高度吻合，这一行可信。
Qwen3.8-27B 八副本 —— 数量级成立，但行内混了两个方案
27B 的 BF16（54GB）和 W4A16（约 14GB）吞吐差近一倍，报告把两个方案塞在同一行给一个区间。理论核算：W4A16 单卡 batch=1 上限约 150 tok/s（报告给 70–140，合理）；聚合 8,000–15,000 需要每卡持续 1,000+ tok/s，即每卡大 batch 50 以上才够得着上限——BF16 版本大概率达不到区间上半段。好在规划值 6,000 足够保守，不会因这个问题踩坑。
Kimi K2.6/K2.7 —— 风险判断对，吞吐上限偏乐观约 2 倍
显存账是对的：1T 参数 INT4 ≈ 500GB，占 640GB 的 78%。但吞吐端：TP=8 下每卡每 token 需读取约 62.5GB 权重，batch=1 理论上限只有约 33 tok/s（与报告"单用户 20–35"自洽）；要摸到 800–2,000 的聚合上限，需要 batch 拉到很大且算力利用率 30%+——A100 上 INT4 反量化（Marlin 类 kernel）实际只能吃到 50–70% 有效算力。实测口径下更现实的区间是 300–800（大 batch 前提）。规划值 600 恰好落在这个修正区间内，可用。
DeepSeek-V4-Flash / GLM-5.3-Flash / MiniMax-M3 —— 无法直接验证
这几个模型的具体规格我未能检索到公开实测（可能过新或未公开），只能做结构性判断：
- "吞吐与激活参数量成反比"的规律方向正确，报告自己的排序（13B→18B→23B→22B 激活）也基本自洽；
- 但 MoE 在 A100 上** expert parallel（EP）配置对吞吐影响极大**，报告只写了 TP/PP 完全没提 EP，而 MoE 纯 TP 部署会因专家权重 all-to-all 通信显著拉低有效带宽——这是这类估算最容易翻车的地方；
- INT8 W8A8 在 Ampere 上无原生支持（Hopper 才有 W8A8 FP8 路径），实际收益依赖 kernel 实现，报告中 INT8 行按"接近 BF16 算力"估算是偏乐观的。
方法论上的三个硬伤
- 没有声明 batch size 和上下文长度假设。同一台机器，Qwen3-235B 在 2K 输入下实测 output 只有 442 tok/s，32K 输入低到 17 tok/s，而 ShareGPT 混合负载是 1,798 tok/s——相差两个数量级。报告所有数字都没有负载定义，实际使用时必须按你的真实输入/输出长度比折算。
- "单用户 tok/s"与"总吞吐"并列容易误读：前者是 batch=1 延迟指标，后者是大并发指标，两者不能同时取到。
- 未区分 SXM 与 PCIe 版 A100：PCIe 版带宽 1.55TB/s，比 SXM 低约 25%，所有数字要同比例下调。
建议
- 若用于产能/成本测算：直接采用右侧"容量规划值"列是安全的，它整体保守；
- 若用于对外承诺性能：报告自己也说了要实机压测，我补充一点——压测时务必固定你的真实上下文长度分布和并发模型，并重点验证 K2 和 GLM/MiniMax 这三行（估算成分最重，且 MoE 的 EP 配置可能带来 1.5 倍以上的偏差）；
- Qwen3-235B 一行可以基本免测采信（已有同配置公开实测兜底）。
一句话总结：这是一份"规划值可用、区间上限偏乐观、假设声明不完整"的估算报告，作为采购前初筛合格，作为性能承诺依据不合格。