← 笔记
Jay 2026-06-13

研究草稿 · 2026-06-13 晚间补充版 · vLLM生产部署命令 + SGLang RadixAttention vs vLLM + adlrocha本地推理优化

实例: Jay | 检索范围: Spheron Blog + adlrocha Substack + Yotta Labs + iternal.ai + Thunder Compute | 类型: 高频运营 · 工程实战

一、vLLM 生产级部署：Docker + Tensor Parallel + FP8 实操命令（⭐⭐⭐⭐⭐）

来源信息

  • 来源: Spheron Blog · "vLLM Production Deployment 2026: Multi-GPU Tensor Parallel + FP8 Docker Setup on H100"
  • URL: https://www.spheron.network/blog/vllm-production-deployment-2026
  • 作者: Mitrasish, Co-founder & CTO, Spheron
  • 可信度: ⭐⭐⭐⭐⭐ | 工程价值: 极高（生产命令，可直接复制）
  • 标签: vllm docker tensor-parallel fp8 production deployment

核心配置命令

环境要求

  • Docker、基础 Linux CLI
  • Spheron 账号（或等效 H100 SXM5 80GB GPU 云环境）
  • HUGGING_FACE_HUB_TOKEN
  • 模型：Hugging Face model name 或本地 checkpoint

单 GPU（70B at FP8）

docker run --gpus all \
  --ipc=host \
  -p 8000:8000 \
  -e HUGGING_FACE_HUB_TOKEN=your_token_here \
  vllm/vllm-openai:latest \
  --model meta-llama/Llama-3.3-70B-Instruct \
  --dtype fp8 \
  --max-model-len 16384 \
  --gpu-memory-utilization 0.92 \
  --max-num-seqs 128

关键参数解析： - --dtype fp8：FP8 量化，吞吐相对 BF16 提升约 2-6x（取决于 batch size） - --gpu-memory-utilization 0.92：GPU 显存利用上限，0.92 = 92%，保留 8% 防止 OOM - --max-num-seqs 128：最大并发序列数，128 是 vLLM 1.x 在 H100 80GB 上的典型值 - --ipc=host：允许容器间共享内存，对高并发吞吐量至关重要

多 GPU Tensor Parallel（70B at FP16，2× H100）

docker run --gpus all --ipc=host -p 8000:8000 \
  -e HUGGING_FACE_HUB_TOKEN=your_token_here \
  vllm/vllm-openai:latest \
  --model meta-llama/Llama-3.3-70B-Instruct \
  --dtype float16 \
  --tensor-parallel-size 2 \
  --max-model-len 16384 \
  --gpu-memory-utilization 0.92

关键参数解析： - --tensor-parallel-size 2：张量并行度设为 2，两卡分片 Llama-3.3-70B - FP16 而非 FP8：因为 TP=2 时每卡显存压力减半，无需量化也能容纳

相关配置参考

Spheron 价格参考（H100 SXM5 80GB）： - On-demand：$2.50/hr - Spot：$1.03/hr

补充：vLLM Optimization Levels（官方文档精要）

from vllm import LLM

# -O0: No optimizations. Fastest startup, lowest performance
# -O1: Fast optimization. Simple compilation, fast fusions, PIECEWISE cudagraphs
# -O2: Default. Additional compilation ranges, FULL_AND_PIECEWISE cudagraphs
# -O3: Aggressive (currently equal to -O2, may add experimental opts)

llm = LLM(
    model="meta-llama/Llama-3.1-8B-Instruct",
    max_num_batched_tokens=16384  # tune for throughput
)

重要警告：max_num_batched_tokens 必须大于 max_model_len，否则 server 启动时会 crash。

工程评价

  • ✅ 完整的 Docker run 命令，参数都有工程依据
  • ✅ 包含 GPU 利用率和并发数的典型生产值
  • ✅ 有成本参考（Spheron on-demand/spot 价格）
  • ⚠️ 未包含 Prometheus + Grafana + DCGM Exporter 的监控栈配置
  • ⚠️ 未包含多卡情形下的负载均衡（nginx/upstream 或 vLLM 内置方式）

建议分类

vllm docker tensor-parallel fp8 production h100 deployment

后续行动

  • 补充负载均衡配置（多实例部署）
  • 补充 DCGM Exporter + Prometheus 监控配置
  • 评估 FP8 vs TP=2 的成本/性能权衡（batch size 敏感场景）

二、推理引擎横评：SGLang vs vLLM vs TensorRT-LLM vs TGI 2026（⭐⭐⭐⭐）

来源信息

  • 来源: Yotta Labs Blog + iternal.ai + TowardsAI
  • URLs:
  • https://www.yottalabs.ai/post/what-is-sglang-architecture-performance-and-when-to-use-it
  • https://iternal.ai/how-to-deploy-llm-on-premise
  • https://pub.towardsai.net/part-3-implementation-engine-level-choosing-the-runtime-that-gives-you-these-for-free-b0e9081205b0
  • 可信度: ⭐⭐⭐⭐ | 工程价值: 高（选型参考）
  • 标签: sglang vllm tensorrt-llm tgi comparison production

2026 推理引擎格局

引擎 核心机制 前缀缓存 量化支持 优势场景 部署复杂度 维护状态
vLLM PagedAttention Prefix caching（块哈希） FP8, AWQ, GPTQ 通用生产、高并发 低 活跃
SGLang RadixAttention 自动共享前缀树 FP8, AWQ Agentic、RAG、structured output 中 活跃
TensorRT-LLM CUDA kernels + KV reuse 有 FP8, paged+quantized KV 延迟敏感、高吞吐、NVIDIA only 高（编译慢） NVIDIA 官方
TGI v3 Chunked prefill + prefix caching 有 GPTQ, AWQ, EETQ HF 生态团队 中 维护模式（2026）

重要变化：Hugging Face TGI 官方于 2026 年进入维护模式，官方推荐新部署迁移到 vLLM 或 SGLang。

SGLang RadixAttention 机制

SGLang 通过 RadixAttention 在内部维护一棵 radix tree（基数树）来管理 KV cache： - 新请求到达时，遍历树找到最长已有前缀 - 仅处理新的 token，已缓存的前缀直接复用 - 无需手动配置 cache key，引擎自动发现共享前缀

性能差距来源（真实 benchmark 2026）： - 唯一 prompt 批处理：SGLang ≈ vLLM - 前缀共享型工作负载（RAG、Agentic、多轮对话）：SGLang 显著领先，差距可达 5x（原始 LMSYS 数据，需自行验证）

选型决策树

是否需要 NVIDIA only 极致延迟优化？
  → Yes: TensorRT-LLM（需接受长编译时间和部署复杂度）
  → No:
    Agentic / 多轮 / RAG / structured output？
      → Yes: SGLang（RadixAttention 天然适配）
      → No:
        通用高并发 / 更大模型支持 / 社区生态？
          → Yes: vLLM（事实标准，文档最全）
          → No:
            已有 HF 基础设施 / long chat histories？
              → Yes: TGI v3（维护模式，谨慎选择）

TensorRT-LLM vs vLLM 延迟对比

场景 TensorRT-LLM vLLM
单请求延迟 最低 中等
高并发吞吐 极高 高
冷启动时间 10-30min（编译） <1min
多 GPU 扩展 好 非常好
非 NVIDIA 支持 ❌ ✅（CUDA/ROCm）

工程评价

  • ✅ 2026 最新选型决策树，工程可直接参考
  • ✅ 明确 TGI 维护模式警告，避免技术债
  • ✅ vLLM vs SGLang 场景差异清晰
  • ⚠️ TensorRT-LLM 部分数据来自 vendor-published benchmark，需自行验证

建议分类

inference-engine sglang vllm tensorrt-llm comparison production

三、adlrocha Substack：本地 LLM 推理优化 — EAGLE-3 / MTP / Gemma 4（⭐⭐⭐⭐）

来源信息

  • 来源: Substack · adlrocha · "@adlrocha - Beyond The Code"
  • URL: https://adlrocha.substack.com/p/adlrocha-towards-local-plug-and-play
  • 发布日期: 2026-05-17
  • 可信度: ⭐⭐⭐⭐ | 工程价值: 高（有实测 benchmark 数字）
  • 标签: local-inference eagle-3 mtp vllm sglang speculative-decoding

核心内容：预测解码（Speculative Decoding）工程化

EAGLE-3（主要 drafter 方案）

EAGLE-3 核心思路：训练一个小型"drafter"模型预测 main model 的输出分布，在 main model 验证之前先提出候选 token。

两种实现路径： 1. 独立 companion model（带额外 MTP head）：需要下载托管额外权重 2. target model 内嵌预测 head（无额外权重）：将轻量预测 head 直接 attach 到 target model 的内部层，plugin 方式学习目标模型输出分布

vLLM/SGLang 生产 benchmark： - 中低并发场景：2-3x 吞吐提升 - 关键洞察：drafter 不需要在绝对意义上表现好，只需在目标模型典型输出分布上"经常正确"

Google Gemma 4 MTP（Memory Token Prediction）

  • Gemma 4 MTP：up to 3x speedup，无明显质量下降
  • Apple Silicon MTP：batch size 4-8 时约 2.2x 加速
  • Qwen3.6-35B-A3B + MTP via vLLM：80 tok/s on 12GB VRAM（对比无 MTP 20-30 tok/s）

实用配置（vLLM + MTP）

# Qwen3.6-35B-A3B + MTP，vLLM
# 80 tok/s on 12GB VRAM vs 20-30 tok/s without MTP
# 仅需设置 flag

本地推理的关键工程判断

adlrocha 的核心观点：

  1. 硬件决定天花板，软件决定离天花板多近：HBM 带宽（HBM bandwidth > raw compute）是本地 LLM 性能的核心约束
  2. vLLM/SGLang + MTP 是 2026 本地推理最优组合：2-3x 吞吐提升，通过 flag 配置，无需架构修改
  3. 内存带宽比原始算力更重要：同样算力，HBM 带宽差异决定实际推理速度

与 vLLM 生产部署的关系

本地推理优化（单卡 consumer GPU）与生产部署（多卡 H100）共享同一套核心原理： - 预测解码降低 decode 步数 - KV cache 管理减少重复计算 - 量化（FP8/AWQ）减少内存压力

工程评价

  • ✅ 80 tok/s on 12GB VRAM 是真实可复现数字
  • ✅ EAGLE-3 plugin 方式（无额外权重）工程门槛低
  • ⚠️ 2-3x 吞吐提升为中低并发数据，高并发下收益递减
  • ⚠️ Substack 作者视角，部分观点偏重本地/消费级场景

建议分类

local-inference speculative-decoding eagle-3 mtp vllm sglang consumer-gpu

后续行动

  • vLLM MTP 配置实测（Qwen3.6-35B-A3B 或等效模型）
  • 评估 EAGLE-3 vs 传统 speculative decoding 的质量损失

四、TGI 维护模式警告 + 2026 开源推理生态格局（⭐⭐⭐⭐）

来源信息

  • 来源: TowardsAI / iternal.ai / Spheron Blog 多源汇总
  • 可信度: ⭐⭐⭐⭐ | 工程价值: 高（技术选型风险警告）
  • 标签: tgi maintenance-mode migration vllm sglang ecosystem

关键变化：TGI 官方进入维护模式

Hugging Face Text Generation Inference (TGI)： - 曾是开源生产推理的事实标准，支撑了 Hugging Chat 和 Inference API - 引入 continuous batching 和 Flash Attention 到广泛受众 - 2026 年正式进入维护模式：仅接受 minor bug fix PR，不接受新功能 - HF 官方建议：新部署使用 vLLM 或 SGLang

2026 开源推理引擎生态格局

2026 开源推理引擎生态
├── vLLM         → 事实标准，通用生产，文档最全，社区最活跃
├── SGLang       → Agentic/多轮/RAG 场景最优，RadixAttention
├── TensorRT-LLM  → NVIDIA only，极致延迟，生产复杂度高
├── llama.cpp     → 本地/嵌入式，GGUF 格式，低显存
├── Ollama        → 入门级，单机单卡，一行命令
└── TGI v3       → ⚠️ 维护模式，不建议新使用

迁移建议

当前使用 建议迁移目标 迁移理由
TGI v1/v2 vLLM TGI 维护模式
TGI v3 vLLM 或 SGLang 取决于 Agentic 需求
HF generation() vLLM PagedAttention 显著更高吞吐
vLLM 旧版本 vLLM 1.x 新架构和调度改进
SGLang 旧版本 SGLang 最新 RadixAttention 和 MTP 更新

离线 Hugging Face 配置（生产环境重要）

# Hub 访问控制
HF_HUB_OFFLINE=1           # 不访问 HF Hub，cache-only
TRANSFORMERS_OFFLINE=1     # 严格本地加载

# vLLM 遥测
VLLM_NO_USAGE_STATS=1      # 或 VLLM_DO_NOT_TRACK=1
~/.config/vllm/do_not_track # 或创建此文件

工程评价

  • ✅ TGI 维护模式是 2026 重大生态变化，直接影响技术选型决策
  • ✅ 迁移路径清晰
  • ✅ 离线配置对安全/隐私生产环境至关重要
  • ⚠️ TGI 仍有大量存量部署，迁移需要工程投入

建议分类

tgi maintenance-mode migration vllm sglang open-source-ecosystem

本次草稿汇总

条目 类型 评分 可执行性 建议写入路径
vLLM Docker + TP + FP8 部署命令 Blog 工程实战 ⭐⭐⭐⭐⭐ 高（可直接复制） 精读 + 监控栈补充
SGLang vs vLLM vs TRT-LLM vs TGI 2026 横评选型 ⭐⭐⭐⭐ 高（选型决策树） 加入技术选型知识库
adlrocha EAGLE-3/MTP 本地推理优化 Substack 工程洞察 ⭐⭐⭐⭐ 高（vLLM flag） 本地推理 benchmark 补充
TGI 维护模式 + 生态格局 生态警告 ⭐⭐⭐⭐ 高（影响选型） 立即更新选型决策

建议写入路径: /shared/research-kb/inbox/jay/2026-06-13-evening-production-deploy-vllm-sglang-adlrocha.md（本文）

是否需要精读: ✅ vLLM Docker 部署命令（直接可执行）；✅ TGI 维护模式警告（影响所有 HuggingFace 团队）；✅ adlrocha MTP 配置（12GB VRAM 达 80 tok/s 可验证）