知识库草稿：vLLM/SGLang 工程对比 · 量化基准 · MoE 路由与负载均衡 · 2026-06-11 晚
实例： Jay | 日期： 2026-06-11 晚 | 检索范围： Substack（The AI Engineer / Cameron R. Wolfe）、TechSy.io、Particula.tech、Spheron、Runpod、Springer's Journal of Ambient Intelligence、arXiv、Introl、LinkedIn 工程经验贴
一、筛选结论
| 条目 | 保留理由 | 丢弃理由 | 可操作性 |
|---|---|---|---|
| vLLM vs SGLang 工程对比（TechSy/Particula/Spheron/Runpod） | 含真实 H100 基准数字、RadixAttention 原理、GPU 内存占用差异（7GB vs 21GB）、TTFT/p95 数据 | — | 高：可直接指导引擎选型 |
| The AI Engineer: vLLM vs Ollama vs SGLang vs TRT-LLM | Substack 工程决策指南，含 FastAPI OOM 真实案例 | 属综述，质量略低于专项深度对比文章 | 中 |
| The AI Engineer: GPTQ vs AWQ vs GGUF 量化实战 | 含 JARVIS Labs Jan 2026 H200 基准数字（Qwen2.5-32B），跨格式 perplexity/throughput 对比表格 | Substack 免费部分信息有限 | 高 |
| Cameron Wolfe Substack: MoE LLMs | DeepSeek-v3 auxiliary-loss-free 路由机制、DBRX 2× 推理加速数据、Fine-grained expert + shared expert 架构细节 | 属研究综述，非纯工程；已有下午 KV cache draft 部分覆盖 | 中（工程价值在负载均衡策略细节） |
| Apple ML: KVP — RL 驱动的 KV 驱逐策略 | RL per-head agent 框架，February 2026，KIT 论文 | 纯研究，无源码/命令/部署步骤 | 低（研究洞察，非工程） |
| Springer: 多层级 KV cache 边缘部署 | 自适应分层驱逐（V0/V1/V2 阈值，U1/U2 利用率），边缘推理场景 | 学术期刊，复现成本高 | 低 |
| KVzip（arXiv 2603.20397） | 自监督上下文重建评估 token 重要性，query-agnostic | 无工程落地数据 | 低（研究方向） |
| SemiAnalysis InferenceMAX | AMD/NVIDIA 基准设置说明，vLLM/SGLang/TRT-LLM 选择逻辑 | Substack 付费墙，snippet 信息有限 | 中（工具价值，引用价值高） |
| LinkedIn: vLLM GPU memory 30%→90%+ | SGLang overlap scheduler 使 GPU 利用率 78%→98%，prefix-heavy 吞吐量 6× | LinkedIn 帖子，非正式出版 | 中（工程洞察，高参考价值） |
| NextBigTeng Substack: AI Infra Roadmap 2026 | 基础设施创业公司概览（TensorMesh/LMCache/RadixArk/Inferact） | 偏市场，非技术深度 | 低 |
二、保留条目详细记录
条目 1：vLLM vs SGLang 工程对比（含基准数字）
来源： - TechSy.io: vLLM vs SGLang 2026: H100 Benchmarks Inside - Particula.tech: SGLang vs vLLM in 2026: Benchmarks, Architecture, and When to Use Each - Spheron: SGLang Production Deployment Guide: RadixAttention and Multi-Turn Inference on GPU Cloud (2026) - Runpod: When to Choose SGLang Over vLLM: Multi-Turn Conversations and KV Cache Reuse
核心工程数据：
| 指标 | vLLM（PagedAttention） | SGLang（RadixAttention） | 备注 |
|---|---|---|---|
| Llama 3.1 8B 吞吐量（H100） | ~12,500 tok/s | ~16,200 tok/s | SGLang 快 29% |
| 70B+ 模型吞吐量 | 差异 3-5% | 同左 | 基本持平 |
| TTFT p95 尾延迟 | 基准 | 低 5-8% | SGLang 稳定 |
| 前缀缓存命中率（多轮） | 块级哈希，需一致边界 | Token 级 Radix 树，自动发现复用 | SGLang 明显优 |
| 共享前缀工作负载（80% 重叠） | 基准 | 最高 6.4× 吞吐量 | SGLang 显著优势 |
| GPU 内存占用（7B 模型） | ~21GB（默认 gpu_memory_utilization=0.9） | ~7GB（按需分配） | SGLang 更节省 |
| 独特 prompt 场景 | 持平或略优 | 略低 | 无缓存优势时 vLLM |
| 内存管理策略 | 预分配 max batch size | 按需分配（lazy allocation） | — |
RadixAttention 原理（Spheron 文档）： - SGLang 将 KV cache 保留在 LRU radix 树中，不在请求完成后丢弃 - 新请求到达时遍历树寻找最长匹配前缀，从缓存位置继续计算 - 调度器改为 cache-aware：优先处理长共享前缀请求（近似深度优先），最大化缓存命中 - 实测：200 prompt，10 并发，80% 共享前缀，缓存命中率 ~78%
SGLang 内存节省根因（GitHub Discussion #17221）：
vLLM 默认 gpu_memory_utilization=0.9（预分配 90% VRAM）
SGLang 默认更保守，按需分配
→ 7GB vs 21GB 差异主要来自此处
调低 vLLM 内存占用：
vllm serve qwen2.5-7b \
--gpu-memory-utilization 0.3 \
--max-model-len 2048 \
--max-num-seqs 8
Runpod 实测（DeepSeek-R1-Distill-Llama-70B，2×H100 SXM）： | 测试类型 | 时长 | Prompt Tokens | Speed (tok/s) | |---------|------|--------------|--------------| | 7k context, fresh | 5.093s | 6,835 | 29.5 | | 7k context, cache hit | 4.287s | 6,829 | 35.0 | | 7k context, cache hit 2 | 4.295s | 6,824 | 34.9 | | Small context | 4.154s | 72 | 36.1 |
→ 7k prompt 缓存命中提速约 20%，小 prompt 无 context 开销时 ~36 tok/s
LinkedIn 工程经验（SGLang overlap scheduler）： - overlap scheduler 在 GPU 运行当前 batch 时，在 CPU 上准备下一 batch - 实测 GPU 利用率：78% → 98% - prefix-heavy 工作负载：SGLang 吞吐量最高达 vLLM 的 6× - 无前缀重叠时差距缩小至 10-20%
SGLang 适用场景： - 多轮对话（5+ turns，平均 5K token context） - Agent 工具调用（重复 system prompt + tool schema） - RAG 共享文档引用 - Few-shot learning（共享示例 prompt） - Multi-LoRA batching（原生支持）
vLLM 适用场景： - 独特 prompt 工作负载（无前缀重叠） - 高并发批处理 - 需要 AMD/Intel/TPU 等多硬件支持 - 更成熟的 K8s/Helm 生态
可信度： 高。综合 TechSy/Particula/Spheron/Runpod 四来源，数字基本吻合；GitHub Discussion 提供了根因解释。
后续行动： 可写入知识库「Inference Serving 引擎选型」页面，作为 2026 H100 生产部署参考；建议对照 SemiAnalysis InferenceMAX（付费）交叉验证。
条目 2：The AI Engineer — GPTQ vs AWQ vs GGUF 量化实战基准
来源： The AI Engineer Substack（Paolo Perrone），JARVIS Labs January 2026 Benchmark on H200
JARVIS Labs Jan 2026 基准（Qwen2.5-32B-Instruct，vLLM，单卡 H200）：
| 格式 | Perplexity（Wikitext-2） | 代码（HumanEval Pass@1） | Throughput（10 并发用户） | vLLM Marlin 速度 |
|---|---|---|---|---|
| FP16 | 基准 | 基准 | 基准 | — |
| AWQ | 6.84 | 51.8% | ~741 tok/s | 741 tok/s, 12.6ms inter-token |
| GGUF Q4_K_M | — | — | ~300-400 tok/s（预估） | 非 NVIDIA 专用 |
| GPTQ | — | — | ~500-600 tok/s（预估） | 可切换 Marlin 内核追评 AWQ |
| bitsandbytes NF4 | 6.67（最低 perplexity） | 51.8% | ~168 tok/s | vLLM 支持有限 |
AWQ 结论（The AI Engineer）：
- vLLM on NVIDIA GPU → 用 AWQ（Marlin 内核，速度质量比最优）
- Mac/laptop/CPU → 用 GGUF Q4_K_M（唯一有非 NVIDIA 内核的格式）
- 已部署 GPTQ → 切换 Marlin 内核即可获得 AWQ 速度，无需重新量化
bitsandbytes NF4： - Perplexity 最低（6.67），精度最高 - 但 vLLM 吞吐量仅 168 tok/s（AWQ 的 22%） - 8-bit bitsandbytes 在 vLLM 中尚不支持 - 适合原型开发和 QLoRA 微调（在线量化，无需离线预处理）
可信度： 中高。JARVIS Labs 基准数字有出处，Substack 作者 Paolo Perrone 信誉较好，但需自行验证完整数字表。
后续行动： 建议写入「LLM 量化选型」页面，引用 JARVIS Labs 2026-01 原始链接。
条目 3：Cameron R. Wolfe Substack — MoE LLMs 工程细节
来源： Cameron R. Wolfe, Ph.D. Substack，Mixture-of-Experts (MoE) LLMs
DeepSeek-v2/v3 负载均衡机制（Auxiliary-loss-free）：
核心问题：传统 MoE 用辅助损失均衡专家负载，但会损害模型质量。
DeepSeek 方案： - 每个 expert 维护一个偏置项（bias term）b_i - 每 iteration：根据 expert 是否超载/欠载，将 b_i 按固定因子 γ 增减 - 偏置仅在 Top-K 选择时使用，不影响 router 中 expert probability 的计算 - 效果：有效均衡专家利用率，同时不引入性能损失 - DeepSeek-v3 仍使用极低权重的辅助损失（作为稳定训练保险）
DBRX 推理效率数据（Databricks）： - DBRX 推理速度：2× LLaMA-2-70B at 150 tok/s/user（TensorRT-LLM, FP16） - DBRX 总参数量仅为 Grok-1 的 40%（active 参数同比例） - MoE 架构使 active 参数远小于 total 参数 → 推理成本接近小模型
Fine-grained Expert + Shared Expert 架构（DeepSeek）： - 动机：在大量细粒度专家中促进专业化，同时减少专家间的冗余信息 - 部分 expert 固定为"shared expert"（始终激活），其余为可选择性激活的细粒度 expert
Mixtral 8×7B 实测： - 总参数量 46.7B（8 × 5.6B expert + shared） - 每次 token 激活 2 个 expert → active 参数 ~12.8B - 推理速度等同于 13B 稠密模型
可信度： 高。Cameron Wolfe 为深度学习博士，Substack 技术深度可靠。
后续行动： 补充到「MoE 架构」主题页，重点标注 DeepSeek 辅助损失-free 机制和 DBRX 推理数据。
条目 4：Apple ML — KVP（RL 驱动 KV 驱逐）
来源： Apple ML Research，Learning to Evict from Key-Value Cache，MIT 研究员 Luca Moschella 等，February 2026
核心思想： 将 KV cache 驱逐重新定义为强化学习问题——学习对 token 按"对未来解码的预测有用性"排序。
方法： - KVP：轻量级 per-head RL agent 框架 - 在预计算的生成轨迹上训练（仅使用 key 和 value 向量） - 每个 agent 学习专门的驱逐策略，由未来效用驱动 - 每个 agent 评估单个 KV cache entry 对未来解码的重要性
评估结果（需核实原文）： - ICML 2026 论文
工程价值： 低。当前无开源代码/命令/生产部署数据，属研究方向。
三、整体评估
本轮新增工程高价值条目： 1. vLLM vs SGLang H100 基准（含 GPU 内存差异根因）→ 选型必读 2. GPTQ/AWQ/GGUF H200 量化基准（Jarvis Labs Jan 2026）→ 量化选型参考 3. DeepSeek auxiliary-loss-free MoE 路由 + DBRX 推理数据 → MoE 工程参考
与已有草稿重叠检查： - 2026-06-11-kv-cache-inference-systems-eviction-security.md → KV cache 策略已覆盖，本文侧重 benchmark 数字 - 2026-06-11-csdn-rag-sourcecode-mlops-substack.md → Substack 部分无重复 - 2026-06-11-inference-benchmark-engineering.md → 需确认该文是否含本次 SGLang/vLLM 数字（概率低，该文为下午轮）
建议写入路径： /shared/research-kb/inbox/jay/2026-06-11-evening-vllm-sglang-quantization-moe.md
标签： inference-engineering vLLM SGLang quantization MoE benchmark production
精读建议： - ⭐ 精读：TechSy/Particula vLLM vs SGLang 专项（含 GPU 内存 7GB vs 21GB 根因） - ⭐ 精读：The AI Engineer AWQ vs GPTQ vs GGUF（含 Jarvis Labs 2026-01 H200 数字） - 参考：DeepSeek-v3 auxiliary-loss-free 路由（ Wolfe Substack） - 参考：LinkedIn GPU 利用率 78%→98% 经验（Overlap Scheduler）