直观对比 DeepSeek MLA（低秩压缩 576 元素）与传统 GQA/MHA 在受限 4×GPU 显存下的并发承载极限。
Machine Balance 拐点公式： \(I^* = \frac{\text{Peak TFLOPS}}{\text{Peak Memory Bandwidth (TB/s)}}\)
- RTX 4090： 165 TFLOPS / 1.0 TB/s = 165 FLOPs/Byte
- H100 SXM： 989 TFLOPS / 3.35 TB/s = 295 FLOPs/Byte
结论： Decode 阶段的算力密度（Arithmetic Intensity）仅为约 2~8 FLOPs/Byte，远远低于 165！因此在自回归生成阶段，提升单 Token 生成速度的唯一物理杠杆是显存带宽（HBM/GDDR）或通过量化/投机解码减少每次读取权重的字节数，盲目堆砌 TFLOPS 算力毫无意义！
遇到“推理慢”时，按顺序执行以下 4 步排查，快速归因根因：
检查 Prometheus vllm:num_requests_waiting 是否积压。若积压 > 20，说明并发超限；检查日志是否有 Preempting request，若频繁驱逐，调低 max-model-len 并开启 Prefix Caching。
若 TPOT 流畅（<35ms/tok）但 TTFT 奇高，说明长短请求互博。新请求的 Prefill 独占打断了正在 Decode 的请求。立即开启 --enable-chunked-prefill true 消除毛刺。
在 4 卡无 NVLink 机器上，查看 DCGM_FI_DEV_PCIE_TX_THROUGHPUT。若常年接近 30GB/s 且 SM% 极低，说明 TP=4 的 120+ 次 All-Reduce 阻塞在 PCIe。改用 EP=4（专家并行）仅传输激活值。
使用 nsys 抓包。如果每个 Step 之间存在大量空白（CPU Launch 延迟），开启 CUDA Graph；若 FlashAttention 执行耗时过长，确认驱动与 PyTorch 版本是否支持 FlashAttention-2/3。
# 使用 nsys 抓取 30 秒高并发时序流（跳过前 15s 预热） nsys profile \ --trace=cuda,nvtx,osrt \ --cuda-memory-usage=true \ --delay=15 --duration=30 \ -o ./profiles/deepseek_4xgpu_trace \ vllm serve /models/deepseek-v2-lite --tensor-parallel-size 4
🧪 工业级实战诊断实验室
以下 5 个案例源于真实的 4×GPU 生产部署故障。点击选项提交诊断，检验调优内功！