Jay 工程实践筛选 · 第二轮（2026-07-28 晚间版）

筛选结论

本轮保留条目（A级）共 4 条，B级 2 条，C级 3 条。覆盖上午第三轮筛选后的新增工程内容，重点挖掘命令级可复现内容。

✅ 保留条目（A级）

条目 1：FlashInfer GPU 部署实战命令（Spheron，2026-07）

• 来源：https://www.spheron.network/blog/deploy-flashinfer-gpu-cloud-llm-inference-kernels
• 可信度：高 — 工程博客，含实测命令和 CUDA 版本要求
• 核心命令： ```bash # Step 1: torch_sdpa 基线 docker run --gpus all --ipc=host -p 8000:8000 \ vllm/vllm-openai:latest \ --model meta-llama/Llama-3.1-70B-Instruct \ --dtype bfloat16 \ --attention-backend torch_sdpa \ --gpu-memory-utilization 0.92 \ --max-model-len 16384

# Step 2: Benchmark python -m vllm.benchmarks.benchmark_serving \ --model meta-llama/Llama-3.1-70B-Instruct \ --dataset-name random \ --random-input-len 2048 \ --random-output-len 512 \ --num-prompts 200 \ --concurrency 32 \ --host localhost --port 8000 `` - **工程价值**： - DeepSeek V3/V4 的 FlashInfer MLA 路径：--attention-backend flashinfer- 8×B200 节点需求（192GB×8=1.536TB）；8×H200 节点（141GB×8=1.128TB）**不足以**在 bfloat16 下加载 DeepSeek-V3 671B，会 OOM - JIT 编译错误排查：nvcc --version确认 CUDA 12.3+；指定--attention-backend flashinfer显式路由到 FlashInfer MLA kernel - FlashInfer vs TRT-LLM 决策树：需要动态模型切换 → FlashInfer；单模型长期固化 → TRT-LLM - **是否需要核验**：建议交叉对比 DeepGEMM + DeepEP 部署指南中的 MoE 命令 - **标签**：flashinfervllmsglangcudadeepseekgpuproductionbenchmark`

条目 2：vLLM OOM 根因诊断（ParallelIQ，2026-05）

• 来源：https://www.paralleliq.ai/blog/vllm-oom-errors-root-cause-diagnosis
• 可信度：高 — Sam Hosseini，工程博客，三类 OOM 根因都有诊断逻辑
• 三类 OOM 根因及诊断特征： 1. KV Cache 溢出：OOM 发生在长时间 session 后；内存使用随请求逐步增长；解决：--gpu-memory-utilization 下调 或 --enable-chunked-prefill 2. Batch Size 配置错误：OOM 发生在 startup 或 first batch；内存从一开始就很高且平坦；解决：切换到 continuous batching（默认开启，不要手动设大 --max-batch-size） 3. 内存碎片化：PyTorch CUDA 分配器长期运行后碎片化；总可用内存够但没有足够连续空间；解决：重启 pod 或设置 --enable-chunked-prefill
• SGLang vs vLLM OOM 对比（GitHub Issue #12496）：
• SGLang 的 --mem-fraction-static 与 vLLM 的 --gpu-memory-utilization 0.8 行为差异很大
• 同一 Gemma3 12B 模型，2×4090 上 vLLM 能跑，SGLang 会 OOM
• 根因：SGLang KV cache 分配策略与 max context length 处理方式不同
• 工程价值：生产排障实操手册，含诊断特征签名，可直接用于故障复现
• 是否需要核验：建议对照 vLLM 官方文档中 --gpu-memory-utilization 与 SGLang --mem-fraction-static 的实际默认值
• 标签：vllm oom troubleshooting production memory-management sglang

条目 3：vLLM vs SGLang 2026 H100 基准对比（Spheron + LeetLLM，2026-07）

• 来源：
• https://www.spheron.network/blog/vllm-vs-tensorrt-llm-vs-sglang-benchmarks
• https://www.spheron.network/blog/vllm-vs-sglang-2026
• https://techsy.io/en/blog/vllm-vs-sglang（2026-07-14 更新）
• 可信度：高 — 实测数据，H100 硬件，50 并发请求，含冷启动时间
• Benchmark 核心数据： | 引擎 | 吞吐量（50 req） | TTFT p50 | 冷启动 | |------|----------------|----------|--------| | vLLM | 1,850 tok/s | 120 ms | ~62 sec | | TensorRT-LLM | 2,100 tok/s | 105 ms | ~28 min | | SGLang | 1,920 tok/s | 112 ms | ~58 sec |

Prefix Caching 效果（80% 共享 512-token 系统提示词）： | Prefix 长度 | Cache hit rate | TTFT 降低 | |------------|---------------|----------| | 256 tokens | ~75% | ~18% | | 512 tokens | ~82% | ~26% | | 1,024 tokens | ~88% | ~35% | | 2,048 tokens | ~92% | ~42% |

MoE 模型（DeepSeek V3/Mixtral）：MoE 模型上 vLLM vs SGLang 差距 <7%，工作负载特征比模型架构更影响选型 - 选型结论： - vLLM：最广硬件支持（NVIDIA/AMD/Intel/Trainium/TPU），Helm charts，庞大社区 - SGLang：多轮对话、共享前缀 RAG、结构化输出、多 LoRA batching - TRT-LLM：极致吞吐量、固定单模型、28 min 冷启动 - 是否需要核验：H100 基准数据需对照各引擎最新版本，量化结果可能随版本变化 - 标签：vllm sglang tensorrt-llm benchmark h100 production inference-engine

条目 4：MoE 模型推理显存配置速查表（Spheron，2026-05）

• 来源：https://www.spheron.network/blog/moe-inference-optimization-gpu-cloud
• 可信度：高 — 工程博客，含 nvidia-smi topo -m NVLink 检测命令和显存配置
• 核心命令：nvidia-smi topo -m → 确认 GPU 间 NVLink 连接（SXM H100 会显示 NV，PCIe 变体显示 PCIe/SYS）
• MoE 模型显存需求表： | 模型 | 最小配置 | 推荐配置 | 备注 | |------|---------|---------|------| | Mixtral 8x7B | 1× H100 80GB FP8 | 2× H100 | 单卡 FP8 可跑 | | Mixtral 8x22B | 3× H100 80GB FP8 | 4× H100 SXM5 | 建议 NVLink | | DeepSeek V3.2 | 8× H200 141GB FP8 | 8× H200 | 需 DeepGEMM | | Kimi K2 (1T) | 16× H100 80GB | 16× H200 | 多节点或 8× B200 |
• SGLang MoE 启动命令： bash python -m sglang.launch_server \ --model-path deepseek-ai/DeepSeek-V3.2-Speciale \ --tp-size 8 \ --dp-size 1 \ --dtype fp8 \ --context-length 32768 \ --port 8000
• DeepGEMM 依赖：vLLM 无 DeepGEMM 时会 fallback 到 generic GEMM，速度明显更慢
• 标签：moe deepseek kimi mixtral sglang vllm deepgemm gpu-configuration production

⚠️ B级（选择性参考）

B1：RAG 评估框架 2026 工具对比（Braintrust/FloTorch/RAGAS/Giskard）

• 来源：
• https://www.braintrust.dev/articles/best-rag-evaluation-tools（2026-07）
• https://www.flotorch.ai/blogs/rag-evaluation-metrics（2026-07）
• 工程价值：中等 — 框架介绍为主，缺乏可执行命令；框架选型有价值
• 选型矩阵：
• Braintrust：生产 trace → eval 数据闭环，CI/CD 集成，RAG Score 92/100
• FloTorch：医疗 benchmark，embedding 成本对比（AWS Titan $0.00002/1k vs Azure $0.000143/1k，7×差距）
• RAGAS + Giskard + BERTScore：经典组合，适合离线 eval
• 建议：作为框架选型参考，不单独写知识库条目；可整合到 RAG eval 主题页
• 标签：rag-eval braintrust ragas giskard flotorch production

B2：CUDA Kernel Optimization 知识工程体系（KernelWiki，MLSys 2026）

• 来源：https://langcopilot.com/posts/2026-05-23-let-the-agent-optimize-its-own
• 工程价值：中等 — 描述了 KernelWiki 知识检索层 + Humanize agent loop，但没有具体可执行命令
• 核心理念：kernel 优化不是一次性代码生成问题，而是长期实验系统工程问题
• 评价：与上午第三轮筛选中 arXiv:2607.17979 同一主题，本文更偏工程经验总结；建议与上午条目合并处理，不单独归档
• 标签：cuda kernel-optimization llm-agent mlsys2026 flashinfer

❌ 丢弃条目（C级）

C1：YouTube "I Benchmarked vLLM vs SGLang" 视频

• 丢弃理由：视频形式无法提取结构化数据；标题党（"Shocking Results!"）；基准数据已在 Spheron/LeetLLM 文章中有更完整的文字版
• 保留价值：无

C2：Substack 书单/课程推荐类文章

• 丢弃理由：资讯类，无源码、无命令、无复现步骤；不符合工程筛选标准
• 涉及条目：多个 Substack 的 "AI Engineer Roadmap 2026" 类文章

C3：Statsig/Label Your Data RAG 评估文章

• 丢弃理由：内容与 B1 重叠，且缺乏实际可执行命令；属于框架介绍，不是工程实践

本轮新增知识库条目建议

分类标签汇总

flashinfer vllm sglang tensorrt-llm cuda deepseek gpu benchmark production oom troubleshooting memory-management moe deepgemm kimi mixtral gpu-configuration rag-eval braintrust ragas giskard flotorch kernel-optimization llm-agent mlsys2026 h100

与上午第三轮筛选的关系

上午第三轮（10:50 AM）已覆盖： - ✅ arXiv:2607.17979（MLSys 2026 FlashInfer Contest，KernelWiki 知识工程） - ✅ LMCache KV Caching（Twitter/X，2026-07-27） - ✅ awesome-harness-engineering GitHub 更新 - ✅ Multi-Agent Debugging 7 Failure Modes

本轮新增，未重复：FlashInfer 部署命令、vLLM OOM 诊断、vLLM vs SGLang 2026 H100 基准（具体数据）、MoE 显存配置速查表。

Jay · 2026-07-28 19:50 · 第四轮工程筛选 · 第二轮（晚间版）