AI Day 8
AI Day 8: 推理优化 — vLLM / TensorRT-LLM / SGLang — 让模型跑得更快更省
推理优化(Inference Optimization) 是指在不牺牲模型输出质量的前提下，通过算法和系统工程手段最大化LLM的吞吐量(Throughput)并最小化延迟(Latency)——让同一张GPU同时服务更多用户，每个用户等待更短时间。
2026-04-09
InferencevLLMTensorRT-LLMSGLangPagedAttentionKVSpeculativeContinuous
日期：2026-04-09
阶段：第一阶段 — AI/LLM技术深潜 (Day 1-15)
标签：Inference vLLM TensorRT-LLM SGLang PagedAttention KV Cache Speculative Decoding Continuous Batching
学习路径树
AI/LLM 深度技术学习 50天计划
├── 第一阶段：模型基础 (Day 1-15)
│ ├── Day 1: Transformer架构与LLM基础 ✅
│ ├── Day 2: 模型量化与本地部署 ✅
│ ├── Day 3: 训练过程深度：Pre-training / SFT / RLHF / DPO ✅
│ ├── Day 4: Prompt Engineering与上下文学习(ICL)原理 ✅
│ ├── Day 5: RAG架构：检索增强生成全链路 ✅
│ ├── Day 6: 向量数据库与Embedding模型 ✅
│ ├── Day 7: Fine-tuning实战：LoRA / QLoRA / Adapter ✅
│ ├── Day 8: 推理优化：vLLM / TensorRT-LLM / SGLang ← 你在这里
│ ├── Day 9: 长上下文技术：RoPE扩展 / Ring Attention
│ ├── Day 10: 多模态模型：Vision-Language架构
│ ├── Day 11: Reasoning模型：CoT / o1 / R1 / Extended Thinking
│ ├── Day 12: Agent框架：ReAct / Tool Use / Planning
│ ├── Day 13: MCP协议与Tool生态
│ ├── Day 14: 模型评估：Benchmark / Arena / 安全评估
│ └── Day 15: 阶段复习与架构总结
│
├── 第二阶段：工程实践 (Day 16-30)
│ ├── Day 16-20: LLM应用架构设计（微服务/网关/缓存/监控）
│ ├── Day 21-25: 生产级RAG系统（Chunking/Rerank/评估/迭代）
│ └── Day 26-30: Agent系统工程化（状态管理/错误恢复/成本控制）
│
├── 第三阶段：金融零售AI应用 (Day 31-42)
│ ├── Day 31-35: 金融AI（风控模型/智能投顾/合规/反欺诈）
│ ├── Day 36-40: 零售AI（推荐系统/智能客服/供应链预测/营销）
│ └── Day 41-42: CeFi x DeFi x AI融合架构
│
└── 第四阶段：面试冲刺 (Day 43-50)
├── Day 43-46: 系统设计面试（LLM平台/RAG/Agent/推荐）
├── Day 47-49: 产品/架构面试模拟
└── Day 50: 总结与作品集
核心概念
一句话定义
推理优化(Inference Optimization) 是指在不牺牲模型输出质量的前提下，通过算法和系统工程手段最大化LLM的吞吐量(Throughput)并最小化延迟(Latency)——让同一张GPU同时服务更多用户，每个用户等待更短时间。
金融类比
推理优化 = 银行柜台服务效率优化
同样的柜员（GPU），通过叫号系统/并行窗口/预处理让吞吐量翻倍。
传统LLM推理 = 老式银行排队:
→ 一个客户占一个柜台，办完才叫下一个
→ 简单查余额也要等前面做房贷审批的人办完
→ 柜员大量时间在等客户翻找材料（GPU空闲等内存）
→ 每天只能服务100个客户
优化后推理 = 现代智慧银行:
→ 叫号系统(Continuous Batching): 空出来就叫下一个，不等一批全办完
→ 预处理窗口(Prefix Caching): 常见业务的表格预填好，到柜台直接签字
→ 虚拟内存管理(PagedAttention): 材料不用一次全摊开，按需调取
→ 快速通道(Speculative Decoding): 实习生先预判，老柜员一次确认
→ 每天可以服务1000个客户，成本不变
┌───────────────────────────────────────────────────────────────┐
│ 优化手段 │ 银行类比 │ 效果 │
│───────────────────┼────────────────────┼──────────────────│
│ KV Cache │ 已办业务的记录存档 │ 不重复查客户信息 │
│ PagedAttention │ 档案柜分页管理 │ 显存利用率↑ 2-4x │
│ Continuous Batch │ 智能叫号系统 │ GPU利用率↑ 90%+ │
│ Speculative Dec │ 实习生预处理 │ 速度↑ 2-3x │
│ Prefix Caching │ 模板表格预填 │ 相似请求↑ 5-10x │
│ 量化推理 │ 电子化替代纸质 │ 同GPU跑更大模型 │
└───────────────────────────────────────────────────────────────┘
与前几天的关系
Day 2 量化 → 让模型"变小"，能装进8GB显存
Day 7 微调 → 训练出领域专用模型
Day 8 推理优化 → 让这个模型高效地服务用户
完整链路:
Pre-train → SFT/RLHF → LoRA/QLoRA → 量化(GPTQ/AWQ/GGUF) → 推理服务(vLLM/TRT-LLM/SGLang)
Day 3 Day 7 Day 2 Day 8 ← 今天
知识点1: 推理瓶颈分析
LLM推理的两个阶段
LLM推理 ≠ 传统ML推理
传统ML: Input → Model → Output (一次前向传播)
LLM: Input → [Prefill阶段] → [Decode阶段] → [Decode] → ... → Output
两个阶段截然不同:
┌─────────────────────────────────────────────────────────────────┐
│ Prefill (预填充) │
│ 处理所有输入Token，生成第一个输出Token │
│ │
│ Input: "请分析这只股票的基本面..." (假设50个Token) │
│ ↓ │
│ 并行处理50个Token → 生成KV Cache → 输出第一个Token "从" │
│ │
│ 特点: │
│ ✓ 计算密集 (Compute-bound): GPU算力是瓶颈 │
│ ✓ 高并行度: 所有Token同时处理 │
│ ✓ GPU利用率高 (>80%) │
│ ✓ 类似矩阵乘法，GPU擅长 │
│ │
│ 时间指标: TTFT (Time To First Token) — 首Token延迟 │
├─────────────────────────────────────────────────────────────────│
│ Decode (解码) │
│ 逐个生成输出Token，每次只产出1个Token │
│ │
│ "从" → "财" → "务" → "数" → "据" → "来" → "看" → ... │
│ │
│ 特点: │
│ ✗ 内存密集 (Memory-bound): 显存带宽是瓶颈 │
│ ✗ 串行执行: 必须等上一个Token生成后才能生成下一个 │
│ ✗ GPU利用率低 (<30%): 大量时间在等数据从显存搬到计算单元 │
│ ✗ 每步只做少量计算，但要读取整个模型权重+KV Cache │
│ │
│ 时间指标: TPS (Tokens Per Second) — 每秒输出Token数 │
└─────────────────────────────────────────────────────────────────┘
关键洞察:
Prefill: 瓶颈是GPU的TFLOPS (算力)
Decode: 瓶颈是GPU的Memory Bandwidth (显存带宽)
RTX 4060 8GB:
FP16算力: 15.1 TFLOPS
显存带宽: 272 GB/s
→ Decode阶段，每生成一个Token要读取整个模型权重(7B×2bytes≈14GB)
→ 理论极限: 272÷14 ≈ 19 tokens/s (FP16)
→ 量化到4-bit: 272÷3.5 ≈ 77 tokens/s (理论上限)
→ 实际受其他开销影响: 40-55 tokens/s (Q4_K_M)
核心性能指标
推理性能的四个关键指标:
┌─────────────────────────────────────────────────────────────────┐
│ 指标 │ 含义 │ 目标 │
│───────────────────────┼─────────────────────┼──────────────────│
│ TTFT │ 首Token延迟 │ <500ms (交互式) │
│ (Time To First Token)│ 用户等第一个字的时间 │ <2s (批处理) │
│ │ │ │
│ TPS / TPOT │ 每秒输出Token数 / │ >30 tps (人类 │
│ (Tokens Per Second) │ 每个输出Token的时间 │ 阅读速度) │
│ │ │ │
│ Throughput │ 系统总吞吐量 │ 越高越好 │
│ (请求/秒 或 Token/秒)│ 一秒能处理多少请求 │ = 收入/成本 │
│ │ │ │
│ Latency (E2E) │ 端到端延迟 │ 取决于生成长度 │
│ (End-to-End) │ 从请求到完成的总时间 │ TTFT + n/TPS │
└─────────────────────────────────────────────────────────────────┘
金融场景需求:
实时风控: TTFT < 200ms, 生成长度短 → Prefill优化是关键
客户报告: Throughput优先，延迟可接受3-5s → Batching优化是关键
智能客服: TTFT < 500ms, TPS > 30 → 两者都重要
Batching的重要性
为什么不做Batching = 浪费90%的GPU？
单请求推理 (Decode阶段):
→ 读取14GB模型权重 → 做少量乘法 → 输出1个Token → 重复
→ GPU计算单元90%时间在等待数据搬运
→ 如同银行只开一个窗口，其他柜员都在看报纸
批处理推理 (Batch=8):
→ 读取14GB模型权重 → 同时为8个请求做乘法 → 输出8个Token
→ 读一次权重、算八次，显存带宽开销几乎不变
→ 吞吐量接近8x，单请求延迟几乎不增加
Static Batching (传统):
┌──────────────────────────────────────────────┐
│ Req 1: ████████████████████████ │ ← 先完成，但要等
│ Req 2: ██████████████████████████████████████ │ ← 最长的那个
│ Req 3: ████████████████ │ ← 等待浪费
│ Req 4: ██████████████████████████████ │
│ ───────────────────────────────→ 时间 │
│ 全部完成才开始下一批 → 短请求被长请求拖累 │
└──────────────────────────────────────────────┘
Continuous Batching (动态):
┌──────────────────────────────────────────────┐
│ Req 1: ████████████████████████ → │ Req 5: ██████████
│ Req 2: ██████████████████████████████████████ │
│ Req 3: ████████████████ → Req 6: ████████████████████████
│ Req 4: ██████████████████████████████ → │ Req 7: ██████████
│ ───────────────────────────────→ 时间 │
│ 请求完成立即释放，新请求立即加入 │
└──────────────────────────────────────────────┘
效果: 吞吐量提升2-5x，GPU利用率从20%→80%+
知识点2: KV Cache深度解析
为什么KV Cache是显存大户
Day 1回顾: Self-Attention计算需要Q, K, V三个矩阵
生成第N个Token时:
Q: 只需要当前Token的Query → 很小
K: 需要所有已见Token的Key → 随序列增长
V: 需要所有已见Token的Value → 随序列增长
没有KV Cache:
生成第100个Token → 重新计算前99个Token的K和V → 大量重复计算
生成第1000个Token → 重新计算前999个Token的K和V → 灾难性浪费
有KV Cache:
每生成一个Token → 只计算这一个Token的K和V → 追加到缓存
读取缓存中所有K、V → 和当前Q做注意力 → 输出下一个Token
→ 用"空间换时间"：缓存所有历史K、V，避免重复计算
KV Cache显存计算公式
KV Cache大小 = 2 × n_layers × n_kv_heads × d_head × seq_len × bytes_per_param
解释:
2 = K和V各一份
n_layers = 模型层数
n_kv_heads = KV头数（GQA时 < Attention头数）
d_head = 每个头的维度 (通常128)
seq_len = 当前序列长度
bytes_per_param = 数据类型字节数 (FP16=2, FP8=1, INT8=1)
Llama-3.1-8B 示例:
n_layers=32, n_kv_heads=8 (GQA), d_head=128, FP16
每Token的KV Cache = 2 × 32 × 8 × 128 × 2 bytes = 128 KB/Token
1024 tokens → 128 MB
4096 tokens → 512 MB
32K tokens → 4 GB ← 已经占满半张RTX 4060!
128K tokens → 16 GB ← 已经超出RTX 4060显存!
模型权重(FP16): ~16 GB
模型权重(Q4): ~4.5 GB
对于batch=8, seq=4096的场景:
KV Cache = 512 MB × 8 = 4 GB
模型权重(Q4) = 4.5 GB
总计 = 8.5 GB → OOM on 8GB!
结论:
模型权重是固定的，KV Cache随batch×seq_len线性增长
在高并发/长上下文场景下，KV Cache才是显存瓶颈
KV Cache量化
2025-2026的重要优化: 对KV Cache也做量化
原始: KV Cache用FP16 → 每Token 128 KB (以Llama-3.1-8B为例)
┌─────────────────────────────────────────────────────────────┐
│ 方案 │ 精度 │ 大小/Token │ 节省 │ 质量损失 │
│────────────────┼────────┼───────────┼──────┼─────────────│
│ FP16 │ 原始 │ 128 KB │ 0% │ 无 │
│ FP8 KV Cache │ 8-bit │ 64 KB │ 50% │ 极小 (<0.5%)│
│ INT8 KV Cache │ 8-bit │ 64 KB │ 50% │ 极小 │
│ INT4 KV Cache │ 4-bit │ 32 KB │ 75% │ 小 (1-2%) │
└─────────────────────────────────────────────────────────────┘
vLLM 2025支持FP8 KV Cache:
--kv-cache-dtype fp8
→ batch容量直接翻倍，质量几乎无损
这对8GB显卡意义重大:
FP16 KV + Q4模型: batch=4, seq=2048 → 4.5+4=8.5 → OOM
FP8 KV + Q4模型: batch=4, seq=2048 → 4.5+2=6.5 → OK!
GQA/MQA对KV Cache的优化
Day 1提到了GQA (Grouped-Query Attention) — 它是KV Cache优化的关键
标准MHA (Multi-Head Attention):
每个Attention头有自己的K和V
32头 → 32组KV → KV Cache大
┌─────────────────────────────┐
│ Q头: q1 q2 q3 q4 ... q32 │ 32个
│ K头: k1 k2 k3 k4 ... k32 │ 32个 ← 存32份
│ V头: v1 v2 v3 v4 ... v32 │ 32个 ← 存32份
└─────────────────────────────┘
GQA (Grouped-Query Attention):
多个Q头共享一组KV
32个Q头, 8个KV头 → KV Cache缩小4x
┌─────────────────────────────┐
│ Q头: q1 q2 q3 q4 ... q32 │ 32个
│ K头: k1 k2 ... k8 │ 8个 ← 只存8份 (4x节省)
│ V头: v1 v2 ... v8 │ 8个 ← 只存8份
│ 映射: q1-q4→k1, q5-q8→k2 │
└─────────────────────────────┘
MQA (Multi-Query Attention):
所有Q头共享一组KV → KV Cache最小
┌─────────────────────────────┐
│ Q头: q1 q2 q3 q4 ... q32 │ 32个
│ K头: k1 │ 1个 ← 只存1份 (32x节省)
│ V头: v1 │ 1个 ← 只存1份
└─────────────────────────────┘
2025-2026主流模型:
Llama-3.x: GQA (n_kv_heads=8, Q头32) → 4x压缩
Qwen2.5: GQA (n_kv_heads=4, Q头28, 7B版本)
Mistral-v0.3: GQA (n_kv_heads=8)
DeepSeek-V3: MLA (Multi-head Latent Attention) → 更激进的压缩
Gemma-2: GQA
GQA已成标配 → 现代模型的KV Cache比早期GPT-3时代小4-8x
PagedAttention原理
vLLM的核心创新: PagedAttention — 像OS管理虚拟内存一样管理KV Cache
问题: 传统KV Cache管理
请求1需要2048 tokens空间，请求2需要1024 tokens空间...
但我们不知道每个请求最终会生成多长！
传统做法: 预分配max_tokens空间
┌──────────────────────────────────────────────┐
│ GPU显存 │
│ ┌──────────────────┐┌────────┐ │
│ │ Req 1 (预分配4K) ││Req 2 │ 浪费! │
│ │ [实际用2K][空闲2K]││[用1K] │ 50%+显存 │
│ └──────────────────┘└────────┘ 被浪费 │
└──────────────────────────────────────────────┘
→ 内部碎片(Internal Fragmentation): 预分配了但没用到
→ 外部碎片(External Fragmentation): 不连续的空闲块无法利用
→ 实际显存利用率只有50-70%
PagedAttention解决方案:
核心思想: 把KV Cache分成固定大小的"页"(Block)，按需分配
┌──────────────────────────────────────────────────────────┐
│ 物理显存（分成等大的Block，每Block存16个Token的KV） │
│ │
│ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ ┌─────┐ │
│ │ B-0 │ │ B-1 │ │ B-2 │ │ B-3 │ │ B-4 │ │ B-5 │ ... │
│ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘ └─────┘ │
│ ↑ ↑ ↑ ↑ ↑ ↑ │
│ │
│ 逻辑映射表（每个请求有自己的Block Table） │
│ │
│ Req 1: [B-0] → [B-3] → [B-5] (已用3个Block=48 Token)│
│ Req 2: [B-1] → [B-4] (已用2个Block=32 Token) │
│ Req 3: [B-2] (已用1个Block=16 Token) │
│ │
│ ✓ 不需要连续内存空间 │
│ ✓ 按需分配，用多少给多少 │
│ ✓ 不同请求的Block可以在显存中任意位置 │
│ ✓ 显存浪费从50%→ <4% (只有最后一个Block可能未满) │
└──────────────────────────────────────────────────────────┘
额外好处 — Copy-on-Write (写时复制):
Beam Search / Parallel Sampling时，多个分支共享前缀的KV Cache:
┌──────────────────────────────────────────────┐
│ Prompt KV: [B-0] → [B-1] → [B-2] │ ← 共享，不复制
│ ↙ ↘ │
│ Branch A: → [B-3] → [B-5] Branch B: → [B-4]│ ← 各自独立
└──────────────────────────────────────────────┘
→ 省下大量重复存储
效果:
相比传统方案，同等显存下batch容量提升2-4x
吞吐量提升2-4x
这就是vLLM火起来的核心原因
知识点3: vLLM — 生产级推理引擎
vLLM核心特性 (2025-2026最新)
vLLM = 当前最流行的开源LLM推理引擎
GitHub Star: 50K+ (2026年)
UC Berkeley LMSYS团队开发
论文: "Efficient Memory Management for Large Language Model Serving with PagedAttention"
核心特性:
1. PagedAttention (上面已详解)
→ 显存利用率从50% → 95%+
→ batch容量翻2-4倍
2. Continuous Batching (连续批处理)
→ 请求完成立即释放，新请求实时加入
→ 不等一批全部完成再处理下一批
→ GPU利用率从20% → 80%+
3. Speculative Decoding (投机解码)
→ 用小模型"猜"多个Token → 大模型一次性验证
→ 速度提升1.5-2.5x，输出质量完全不变
→ vLLM原生支持: --speculative-model "draft-model"
4. Prefix Caching (前缀缓存)
→ 相同System Prompt的请求共享KV Cache
→ 金融场景: 同一个风控System Prompt → 缓存命中率90%+
→ 启用: --enable-prefix-caching
5. 量化支持
→ GPTQ, AWQ, FP8, GGUF (2025新增), BitsAndBytes
→ FP8 KV Cache → 进一步省显存
6. 多模型Serving
→ LoRA热切换: --enable-lora → 一个基座模型 + 多个LoRA
→ 不同请求用不同LoRA → Day 7的LoRA部署最佳方案
7. 多GPU/多节点
→ Tensor Parallel (TP): 一个模型拆到多张GPU
→ Pipeline Parallel (PP): 按层拆分
→ 支持NVIDIA NVLink和普通PCIe
8. OpenAI兼容API
→ 直接替换OpenAI API endpoint
→ /v1/chat/completions, /v1/completions, /v1/embeddings
vLLM安装与使用
安装 (2026):
pip install vllm # 自动匹配CUDA版本
启动服务 (OpenAI兼容):
python -m vllm.entrypoints.openai.api_server \
--model Qwen/Qwen2.5-7B-Instruct-AWQ \
--dtype auto \
--max-model-len 4096 \
--gpu-memory-utilization 0.9 \
--enable-prefix-caching \
--port 8000
RTX 4060 8GB推荐参数:
--model: AWQ或GPTQ量化版 (4-bit)
--max-model-len: 2048-4096 (别太大，省KV Cache空间)
--gpu-memory-utilization: 0.85-0.9
--enforce-eager: True (小显存用eager mode更稳定)
--kv-cache-dtype: auto (支持FP8时自动启用)
调用 (与OpenAI API完全兼容):
from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="dummy")
response = client.chat.completions.create(
model="Qwen/Qwen2.5-7B-Instruct-AWQ",
messages=[{"role": "user", "content": "分析招商银行的ROE趋势"}],
max_tokens=512,
temperature=0.7,
)
性能参考 (RTX 4060 8GB, Qwen2.5-7B-AWQ):
单请求: TTFT ~150ms, TPS ~35-45 tok/s
Batch=4: TTFT ~200ms, TPS ~25-35 tok/s (per req), 总吞吐 ~120 tok/s
Prefix Cache命中: TTFT降至 ~50ms
vLLM性能数据 (2025-2026基准)
官方Benchmark (A100-80GB, Llama-3.1-8B-Instruct):
┌──────────────────────────────────────────────────────────────┐
│ 对比维度 │ Naive HF │ vLLM │ 提升 │
│────────────────────────┼────────────┼────────────┼──────────│
│ Throughput (tok/s) │ 250 │ 2800 │ 11.2x │
│ Max Batch Size │ 8 │ 256 │ 32x │
│ 显存利用率 │ 50-60% │ 95%+ │ ~2x │
│ P99 Latency (ms) │ 5000 │ 800 │ 6.25x │
│ QPS (req/s, 256tok) │ 2 │ 22 │ 11x │
└──────────────────────────────────────────────────────────────┘
注: "Naive HF" = HuggingFace transformers + generate() 不做任何优化
知识点4: TensorRT-LLM — NVIDIA官方优化引擎
TensorRT-LLM核心特性
TensorRT-LLM = NVIDIA专为LLM推理打造的加速引擎
特点: 把模型编译成高度优化的CUDA kernel
类比: 从解释执行Python → 编译成C++可执行文件
核心优化:
1. 图优化 + 内核融合 (Kernel Fusion)
→ 把多个小操作合并成一个大CUDA kernel
→ 减少kernel launch开销和中间数据搬运
→ 如: LayerNorm + Linear + Activation → 一个fused kernel
2. 量化优化
→ FP8/INT8/INT4 — 深度利用NVIDIA Tensor Core
→ 比通用量化(GPTQ/AWQ)更快: 原生硬件加速
→ SmoothQuant, AWQ, GPTQ 都支持
→ RTX 40系列的FP8: 理论2x FP16性能
3. In-Flight Batching
→ NVIDIA版的Continuous Batching
→ 与Triton Inference Server深度集成
→ 支持更灵活的调度策略
4. 多GPU优化
→ Tensor Parallel: NVLink互联时接近线性扩展
→ Pipeline Parallel: 跨节点大模型
→ 与NVIDIA硬件(A100/H100/B200)深度适配
5. 2025-2026新特性
→ Speculative Decoding原生支持
→ Medusa heads (一个模型多头预测，不需要额外draft model)
→ KV Cache量化 (FP8/INT8)
→ 结构化输出加速 (JSON mode)
安装:
pip install tensorrt-llm # 需要NVIDIA GPU, CUDA 12+
使用流程:
Step 1: 模型转换 → 从HuggingFace转为TRT-LLM格式
Step 2: 引擎编译 → 针对你的GPU编译优化
Step 3: 部署服务 → 用TRT-LLM API或Triton Server
# 转换+编译 (以Llama-3.1-8B为例)
python convert_checkpoint.py \
--model_dir ./llama-3.1-8b \
--output_dir ./trt_ckpt \
--dtype float16
trtllm-build \
--checkpoint_dir ./trt_ckpt \
--output_dir ./trt_engine \
--gemm_plugin float16 \
--max_batch_size 8 \
--max_input_len 2048 \
--max_seq_len 4096
TensorRT-LLM vs vLLM对比
┌────────────────────────────────────────────────────────────────────┐
│ 维度 │ vLLM │ TensorRT-LLM │
│──────────────────┼───────────────────────┼─────────────────────────│
│ 开发者 │ UC Berkeley (开源社区) │ NVIDIA (官方) │
│ 核心优势 │ 显存管理 (PagedAttn) │ 计算优化 (Kernel Fusion) │
│ 安装难度 │ ★★ (pip install) │ ★★★★ (编译+转换) │
│ 模型支持 │ 广泛 (HF模型直接加载) │ 需要转换 │
│ 迭代速度 │ 快 (2周一版) │ 慢 (月度更新) │
│ 最佳硬件 │ 任何NVIDIA GPU │ A100/H100/B200 最优 │
│ 量化 │ GPTQ/AWQ/FP8/GGUF │ FP8/INT8 (原生Tensor Core)│
│ 社区生态 │ ★★★★★ │ ★★★ │
│ 绝对性能 │ ★★★★ │ ★★★★★ (同硬件峰值更高) │
│ 易用性 │ ★★★★★ │ ★★★ │
│ 适合场景 │ 通用/快速上线/多模型 │ 极致性能/大规模部署 │
│ RTX 4060友好度 │ ★★★★ (直接用) │ ★★★ (可用，但优势不大) │
│ LoRA动态切换 │ ✓ (原生支持) │ ✓ (2025新增) │
│ Speculative Dec │ ✓ │ ✓ (Medusa也支持) │
│ 结构化输出 │ 支持 (Outlines集成) │ 支持 │
└────────────────────────────────────────────────────────────────────┘
选择建议:
RTX 4060本地开发 → vLLM (简单易用, 一行pip install)
生产环境A100/H100 → TensorRT-LLM (极致性能)
快速原型验证 → vLLM
大规模 (>100 QPS) → TensorRT-LLM + Triton
多LoRA动态服务 → vLLM
2025-2026趋势: vLLM也在集成TRT-LLM后端, 界限模糊化
知识点5: SGLang — 2025-2026新星
SGLang核心特性
SGLang = Stanford出品的新一代推理框架
全称: Structured Generation Language
核心创新: RadixAttention + 结构化生成加速
GitHub Star: 25K+ (2026年, 增长最快)
论文: "SGLang: Efficient Execution of Structured Language Model Programs"
核心优势:
1. RadixAttention (基数树前缀缓存)
→ 比vLLM的Prefix Caching更高效
→ 用Radix Tree管理所有请求的KV Cache前缀
→ 自动识别和复用任意共享前缀，不限于System Prompt
示意图:
┌──────────────────────────────────────────────────────────┐
│ Radix Tree (基数树) │
│ │
│ [System Prompt KV] ←── 共享根节点 │
│ / | \ │
│ [用户A历史] [用户B历史] [用户C历史] ← 分支 │
│ / \ | │
│ [追问1] [追问2] [追问1] │
│ │
│ ✓ 多轮对话: 前几轮的KV Cache自动复用 │
│ ✓ 批量任务: 相同Prompt模板的不同参数共享前缀 │
│ ✓ Few-shot: 相同example部分不重复计算 │
│ ✓ LRU淘汰: 内存不够时自动淘汰最少使用的分支 │
└──────────────────────────────────────────────────────────┘
金融场景:
100个客户用同一个"风控分析System Prompt" (2000 tokens)
→ 只计算一次Prefill → 后续99个请求直接复用KV Cache
→ Prefill时间从100×200ms → 1×200ms + 99×10ms ≈ 1.2s (vs 20s)
2. 结构化生成加速
→ JSON Schema / Regex约束输出时不降速
→ 传统方法: 每Token都检查约束 → 速度降30-50%
→ SGLang: 编译约束为FSM(有限状态机), 提前计算合法Token集
→ 速度几乎无损，输出100%符合Schema
3. 编程接口
→ 不只是推理引擎，还是编程框架
→ 支持分支/循环/选择等控制流
→ 自动优化: 并行分支、前缀共享、批量调度
4. 性能优化
→ FlashInfer后端: 针对Attention的极致优化
→ Torch Compile集成: 自动优化计算图
→ Chunked Prefill: 长Prompt分块处理，减少首Token延迟波动
5. 2025-2026新特性
→ 多模态支持 (Vision-Language模型)
→ Speculative Decoding
→ Data Parallelism (多GPU自动拆分请求)
→ DeepSeek MLA专项优化
三大框架对比表
┌──────────────────────────────────────────────────────────────────────────┐
│ 维度 │ vLLM │ TensorRT-LLM │ SGLang │
│──────────────────┼────────────────┼─────────────────┼───────────────────│
│ 开发者 │ Berkeley/社区 │ NVIDIA │ Stanford/LMSYS │
│ 首发年份 │ 2023 │ 2023 │ 2024 │
│ 核心创新 │ PagedAttention │ Kernel Fusion │ RadixAttention │
│ GitHub Stars │ ~50K │ ~10K │ ~25K │
│ 安装易用性 │ ★★★★★ │ ★★★ │ ★★★★ │
│ 模型支持广度 │ ★★★★★ │ ★★★★ │ ★★★★ │
│ 前缀缓存 │ ✓ (手动启用) │ ✓ (有限) │ ★★★★★ (Radix树) │
│ 结构化输出 │ ✓ (Outlines) │ ✓ │ ★★★★★ (原生FSM) │
│ Spec. Decoding │ ✓ │ ✓ (+Medusa) │ ✓ │
│ 多LoRA切换 │ ★★★★★ │ ★★★ │ ★★★★ │
│ 绝对吞吐量 │ ★★★★ │ ★★★★★ │ ★★★★☆ │
│ 延迟稳定性 │ ★★★★ │ ★★★★★ │ ★★★★ │
│ 多模态 │ ✓ │ ✓ │ ✓ │
│ 编程接口 │ API │ API │ API + DSL │
│ 社区活跃度 │ ★★★★★ │ ★★★ │ ★★★★★ (2025最活跃)│
│ 最适场景 │ 通用/多模型 │ 大规模/极致性能 │ 复杂Prompt/结构化 │
│ RTX 4060 8GB │ ★★★★ │ ★★★ │ ★★★★ │
└──────────────────────────────────────────────────────────────────────────┘
2025-2026行业趋势:
→ vLLM: 社区最大，生态最全，大多数公司的默认选择
→ TRT-LLM: NVIDIA大客户/云厂商首选，性能天花板
→ SGLang: 增长最快，复杂应用场景(Agent/RAG)越来越多选它
→ 三者在互相学习: vLLM加了RadixAttention思想, SGLang改进了PagedAttention
→ 未来可能收敛: 底层优化趋同，差异在上层编程模型
知识点6: 其他推理方案
消费级/边缘推理工具
不是所有场景都需要vLLM/TRT-LLM — 很多时候更轻量的方案更合适
┌──────────────────────────────────────────────────────────────────────────┐
│ 工具 │ 定位 │ 优点 │ 适用场景 │
│────────────────┼──────────────────┼────────────────────┼──────────────│
│ llama.cpp │ CPU/边缘推理之王 │ 纯C++, 无依赖 │ 本地/嵌入式 │
│ │ │ Apple Metal/CUDA │ 单用户交互 │
│ │ │ GGUF格式标准 │ 离线场景 │
│ │ │ │ │
│ Ollama │ 一键本地部署 │ 3条命令跑起来 │ 开发/测试 │
│ │ (基于llama.cpp) │ 模型管理像Docker │ 个人使用 │
│ │ │ REST API │ 入门学习 │
│ │ │ │ │
│ ExLlamaV2 │ GPU推理极致优化 │ 单GPU推理最快 │ 消费级GPU │
│ │ │ EXL2量化格式 │ 追求极限速度 │
│ │ │ 自适应量化 │ 单用户 │
│ │ │ │ │
│ MLC-LLM │ 跨平台推理 │ 手机/浏览器/IoT │ 移动端 │
│ │ (Apache TVM) │ WebGPU/Vulkan │ 边缘计算 │
│ │ │ Android/iOS │ 浏览器内 │
│ │ │ │ │
│ ONNX Runtime │ 微软推理框架 │ 跨硬件 (CPU/GPU/NPU)│ 企业部署 │
│ (+GenAI) │ │ DirectML (AMD/Intel)│ 非NVIDIA硬件│
│ │ │ Windows原生优化 │ Azure云 │
└──────────────────────────────────────────────────────────────────────────┘
RTX 4060 8GB用户的推荐:
日常个人使用 → Ollama (最省心)
追求单请求极限速度 → ExLlamaV2 (比llama.cpp快10-15%)
需要API服务(多人) → vLLM (连续批处理)
开发调试 → Ollama + API模式
嵌入到应用 → llama.cpp (C/C++ API)
各方案性能对比 (RTX 4060 8GB, Qwen2.5-7B Q4_K_M)
┌────────────────────────────────────────────────────────────────┐
│ 方案 │ 单请求TPS │ Batch=4 TPS │ TTFT │ 安装难度 │
│───────────────┼──────────┼────────────┼───────┼──────────│
│ Ollama │ ~35-40 │ N/A (单请求)│ ~200ms│ ★ │
│ llama.cpp │ ~38-42 │ N/A │ ~180ms│ ★★ │
│ ExLlamaV2 │ ~45-50 │ ~35 (per) │ ~150ms│ ★★★ │
│ vLLM (AWQ) │ ~35-45 │ ~30 (per) │ ~150ms│ ★★ │
│ SGLang │ ~38-45 │ ~32 (per) │ ~140ms│ ★★ │
│ TRT-LLM │ ~40-50 │ ~35 (per) │ ~120ms│ ★★★★ │
└────────────────────────────────────────────────────────────────┘
注: 数据为近似值, 实际受Prompt长度/生成长度/系统配置影响
8GB显存下Batch能力有限, 大Batch场景需要更大显存
单请求场景下各方案差距不大 (都受显存带宽限制)
多请求并发时vLLM/SGLang的Continuous Batching优势才体现
知识点7: Speculative Decoding详解
为什么Decode阶段慢
回顾知识点1:
Decode = 内存密集(Memory-bound)
每生成1个Token → 读取整个模型权重 → 做少量计算 → 输出1个Token
GPU计算能力严重浪费 (利用率<30%)
关键洞察:
读取7B模型权重做1次推理 和 做5次推理 → 耗时几乎一样！
因为瓶颈在"读取"，不在"计算"
→ 能不能一次读取权重，验证5个Token？
→ 这就是Speculative Decoding的核心思想
Draft-Verify范式
Speculative Decoding (投机/推测解码):
步骤:
1. Draft (草稿): 用一个小模型快速生成K个候选Token
2. Verify (验证): 用大模型一次前向传播验证所有K个Token
3. Accept (接受): 接受从头开始连续正确的Token
4. Reject (回退): 从第一个错误处重新开始
示例:
目标模型 (7B): 准确但慢 → 50ms/Token
草稿模型 (0.5B): 不太准但快 → 5ms/Token
┌──────────────────────────────────────────────────────────────┐
│ Step 1: Draft Model快速生成5个Token │
│ │
│ Draft: "从" → "财" → "务" → "报" → "告" │
│ 耗时: 5 × 5ms = 25ms │
│ │
│ Step 2: Target Model一次验证5个Token │
│ │
│ Verify: "从"✓ "财"✓ "务"✓ "报"✗ (应该是"数") │
│ 耗时: ~55ms (一次前向传播, 5个Token并行验证) │
│ 注: 验证5个Token ≈ 验证1个Token的耗时 (Prefill模式) │
│ │
│ Step 3: 接受前3个正确Token + 大模型生成的修正Token │
│ │
│ Accept: "从" "财" "务" + "数" (大模型修正) │
│ = 80ms获得4个Token │
│ │
│ 对比: 不用Spec Dec → 4 × 50ms = 200ms │
│ 加速: 200ms → 80ms = 2.5x │
└──────────────────────────────────────────────────────────────┘
为什么质量不受影响？
关键定理: Speculative Decoding的输出分布和纯大模型推理完全一致。
验证时使用rejection sampling:
如果大模型同意draft → 直接接受
如果大模型不同意 → 用大模型的分布重新采样
→ 数学上可证明: 最终输出的Token概率分布 = 纯大模型生成的分布
→ 不是"近似"，是"精确相同"
→ 唯一的变化是速度变快了
加速倍率取决于:
α = Draft Model的接受率 (accepted tokens / drafted tokens)
γ = Draft步数 (每次草稿生成几个Token)
α高(Draft Model好) + γ适中(5-8) → 加速2-3x
α低(Draft Model差) → 可能反而变慢
2025-2026最佳实践:
Draft Model = 同家族小模型 (如Llama-3.1-8B + Llama-3.2-1B)
→ 架构相同，词表相同 → 接受率高(α ≈ 0.7-0.85)
→ 稳定加速2x左右
Draft Model选择指南:
┌──────────────────────────────────────────────────────────┐
│ Target Model │ 推荐Draft Model │ 预期加速 │
│────────────────────┼────────────────────┼───────────────│
│ Llama-3.1-8B │ Llama-3.2-1B │ 1.8-2.2x │
│ Llama-3.1-70B │ Llama-3.1-8B │ 1.5-2.0x │
│ Qwen2.5-7B │ Qwen2.5-0.5B │ 1.8-2.5x │
│ DeepSeek-V3 (MoE) │ DeepSeek-V3小版本 │ 1.5-2.0x │
└──────────────────────────────────────────────────────────┘
其他Speculative方案
2025-2026的变体:
1. Medusa (多头推测)
→ 不需要额外Draft Model
→ 在大模型上加几个小的"预测头"
→ 每个头预测未来第2/3/4/...个Token
→ 大模型一次验证所有头的预测
→ 优点: 不需要维护两个模型
→ 缺点: 需要额外训练Medusa heads
2. EAGLE / EAGLE-2 (2024-2025)
→ 特征级别的推测，而非Token级别
→ 使用大模型的中间特征训练轻量预测器
→ 接受率高于普通Draft Model → 加速2.5-3.5x
→ 2025-2026最先进的Speculative Decoding变体
3. Lookahead Decoding
→ 利用Jacobi迭代并行猜测
→ 不需要Draft Model，也不需要额外训练
→ 加速1.5-2x
4. Self-Speculative Decoding
→ 大模型自身的浅层做Draft
→ 前几层快速预测 → 全模型验证
→ 优点: 零额外模型开销
知识点8: 8GB显存优化实战
RTX 4060 8GB推理策略总结
8GB显存 = 必须精打细算每一MB
显存预算分配:
┌──────────────────────────────────────────────────────────┐
│ 8192 MB 总显存 │
│ │
│ ┌────────────────────────────────┐ │
│ │ 模型权重 (Q4): ~4500 MB │ 55% │
│ ├────────────────────────────────┤ │
│ │ KV Cache: ~2500 MB │ 30% │
│ ├────────────────────────────────┤ │
│ │ 激活值+临时: ~700 MB │ 9% │
│ ├────────────────────────────────┤ │
│ │ CUDA Context: ~500 MB │ 6% │
│ └────────────────────────────────┘ │
│ │
│ 可用于KV Cache的空间决定了: │
│ batch_size × max_seq_len 的上限 │
└──────────────────────────────────────────────────────────┘
KV Cache空间 → 可服务能力:
2500 MB ÷ 128 KB/Token (Llama-8B FP16) ≈ 20000 Tokens
→ 单请求4096 tokens: 最多batch=4
→ 单请求2048 tokens: 最多batch=8-10
→ 如果用FP8 KV Cache: 容量翻倍
各模型最优推理方案表
RTX 4060 8GB 推理方案推荐 (2025-2026):
┌──────────────────────────────────────────────────────────────────────────┐
│ 模型 │ 量化方案 │ 推荐引擎 │ Max Batch │ TPS │
│────────────────────┼─────────────┼─────────────┼──────────┼─────────│
│ Qwen2.5-3B │ Q4_K_M │ Ollama │ 1 (个人) │ ~55-65 │
│ │ AWQ-4bit │ vLLM │ 8-12 │ ~45-55 │
│ │ │ │ │ │
│ Qwen2.5-7B │ Q4_K_M │ Ollama │ 1 │ ~35-42 │
│ │ AWQ-4bit │ vLLM │ 4-6 │ ~30-38 │
│ │ EXL2-4.0bpw │ ExLlamaV2 │ 1 │ ~45-50 │
│ │ │ │ │ │
│ Llama-3.1-8B │ Q4_K_M │ Ollama │ 1 │ ~33-40 │
│ │ AWQ-4bit │ vLLM │ 4-6 │ ~28-35 │
│ │ │ │ │ │
│ Phi-4-mini (3.8B)│ Q4_K_M │ Ollama │ 1 │ ~60-70 │
│ │ Q6_K │ Ollama │ 1 │ ~50-58 │
│ │ AWQ-4bit │ vLLM │ 10-16 │ ~50-60 │
│ │ │ │ │ │
│ Mistral-7B │ Q4_K_M │ Ollama │ 1 │ ~35-42 │
│ │ AWQ-4bit │ vLLM │ 4-6 │ ~30-38 │
│ │ │ │ │ │
│ DeepSeek-R1-7B │ Q4_K_M │ Ollama │ 1 │ ~30-38 │
│ │ (CoT长输出) │ │ │ (输出长)│
│ │ │ │ │ │
│ Gemma-2-9B │ Q3_K_M │ Ollama │ 1 │ ~25-32 │
│ │ (9B较大) │ │ │ (勉强) │
│ │ │ │ │ │
│ Qwen2.5-14B │ Q3_K_S │ llama.cpp │ 1 │ ~18-22 │
│ (超频挑战) │ IQ3_XXS │ (CPU卸载部分)│ 1 │ ~12-16 │
└──────────────────────────────────────────────────────────────────────────┘
场景化推荐:
1. 个人日常使用 (聊天/写作/编程):
→ Ollama + Qwen2.5-7B-Q4_K_M
→ 一行命令: ollama run qwen2.5:7b
→ TPS ~38, 流畅对话体验
2. 开发API服务 (多用户):
→ vLLM + Qwen2.5-7B-AWQ
→ 支持并发4-6个请求
→ OpenAI兼容API
3. 极速单用户 (最快速度):
→ ExLlamaV2 + Qwen2.5-7B-EXL2-4.0bpw
→ 单请求TPS ~50
→ 适合写长文/代码补全
4. 轻量推理 (显存充裕):
→ Ollama + Phi-4-mini-Q6_K
→ 只用~3GB显存, 留空间给其他任务
→ 简单任务性价比最高
5. 推理型任务 (需要深度思考):
→ Ollama + DeepSeek-R1-7B-Q4_K_M
→ CoT推理, 输出较长
→ 适合分析题/数学题
6. 金融中文专用 (Day 7微调后):
→ vLLM + 自己QLoRA微调的Qwen2.5-7B
→ Day 7训练 → Day 2量化(AWQ) → Day 8部署(vLLM)
→ 完整闭环
8GB显存OOM急救方案
遇到OOM (Out of Memory) 时的排查清单:
┌──────────────────────────────────────────────────────────────┐
│ 优先级 │ 操作 │ 节省显存 │
│─────────┼─────────────────────────────┼──────────────────────│
│ 1 │ 关闭其他GPU应用(浏览器/游戏) │ 500-2000 MB │
│ 2 │ 降低max_seq_length │ 线性节省KV Cache │
│ 3 │ 减小batch_size │ 线性节省KV Cache │
│ 4 │ 启用FP8 KV Cache │ KV Cache减半 │
│ 5 │ 换更激进的量化 (Q4→Q3→IQ3) │ 500-1500 MB │
│ 6 │ 换更小的模型 (7B→3B→1.5B) │ 1000-3000 MB │
│ 7 │ CPU Offload (llama.cpp) │ 将部分层放CPU │
│ 8 │ 减小gpu-memory-utilization │ 留更多给OS │
└──────────────────────────────────────────────────────────────┘
Ollama OOM配置:
设置环境变量:
OLLAMA_NUM_PARALLEL=1 # 只允许1个并发
OLLAMA_MAX_LOADED_MODELS=1 # 只加载1个模型
OLLAMA_FLASH_ATTENTION=1 # 启用Flash Attention (省显存)
vLLM OOM配置:
--gpu-memory-utilization 0.85 # 降低GPU使用率
--max-model-len 2048 # 限制最大序列长度
--enforce-eager # 禁用CUDA Graph (省显存)
--dtype half # 使用FP16
--kv-cache-dtype fp8 # FP8 KV Cache
终极方案: GPU + CPU混合推理 (llama.cpp)
./llama-server \
--model qwen2.5-7b-q4_k_m.gguf \
--n-gpu-layers 25 \ # 前25层在GPU (共32层)
--n-ctx 2048 # 上下文长度
→ 7层卸载到CPU → 省~1.5GB显存 → 速度降15-20%
→ 比完全OOM无法运行好得多
今日思考
问题1: 推理优化对产品成本的影响有多大？
答：推理优化是LLM产品能否盈利的关键，通常可以降低50-80%的推理成本。
成本计算 (以金融智能客服为例):
假设: 日活1万用户, 平均每人10轮对话, 每轮500 Token
日处理量: 10000 × 10 × 500 = 5000万 Token/天
方案A: 无优化 (HuggingFace + A100)
吞吐: 250 tok/s → 需要 50M/(250×86400) ≈ 2.3 张A100
成本: 2.3 × $2/h × 24h = $110/天 = $3300/月
方案B: vLLM (A100)
吞吐: 2800 tok/s → 需要 50M/(2800×86400) ≈ 0.2 张A100
成本: 0.25 × $2/h × 24h = $12/天 = $360/月
节省: 89%
方案C: vLLM + 量化 + Prefix Caching (A10G, 更便宜GPU)
吞吐: 1500 tok/s, 但GPU单价只$0.8/h
成本: 0.4 × $0.8/h × 24h = $7.7/天 = $230/月
节省: 93%
方案D: 自部署RTX 4090 (本地)
吞吐: 800 tok/s, 硬件摊薄$0.15/h
成本: 0.7 × $0.15/h × 24h = $2.5/天 = $75/月
节省: 98%
PM/架构师的核心决策:
1. 选择推理框架 = 直接影响人力成本和机器成本
2. 量化策略 = 质量vs成本的权衡
3. 缓存策略 = 相似请求越多, Prefix Caching收益越大
4. 模型大小 = 3B vs 7B vs 70B, 要用数据验证质量差异
问题2: 什么时候用Speculative Decoding？什么时候不值得？
答：当Decode延迟是瓶颈且存在高匹配度的小模型时使用。
值得用:
✓ 用户对交互延迟敏感 (聊天/实时翻译)
✓ 有同家族小模型 (Llama-8B + Llama-1B)
✓ 输出以常见模式为主 (代码/模板化文本) → 接受率高
✓ GPU算力有余但带宽是瓶颈 (大多数消费级GPU)
不值得:
✗ 高吞吐批处理场景 (batch已经很大, GPU利用率已高)
✗ 创意性输出 (诗歌/头脑风暴) → 接受率低
✗ 没有好的Draft Model → 接受率<50%, 反而变慢
✗ Prefill是瓶颈 (超长输入) → Spec Dec只优化Decode
✗ 小模型需要额外显存 → 8GB显存装两个模型可能OOM
RTX 4060 8GB实际情况:
7B模型Q4 (4.5GB) + 0.5B Draft (0.5GB) = 5GB → 留3GB给KV Cache → 勉强可行
但batch能力下降 → 适合单用户极速场景
日常使用: Ollama不支持Spec Dec, 所以默认不用
vLLM: --speculative-model Qwen/Qwen2.5-0.5B → 可以尝试
问题3: 推理框架选型应该怎么决策？
答：根据场景分层决策，不要过度优化。
决策树:
┌────────────────────────────────────────────────────────────────┐
│ Q1: 你的场景？ │
│ ├── 个人使用/学习 → Ollama (完事) │
│ ├── 开发原型/Demo → Ollama API 或 vLLM │
│ ├── 生产环境 → 继续↓ │
│ │
│ Q2: 并发量？ │
│ ├── <10 QPS → vLLM (简单部署) │
│ ├── 10-100 QPS → vLLM + 量化 + Prefix Caching │
│ ├── >100 QPS → TRT-LLM + Triton (工程投入大但值得) │
│ │
│ Q3: 有特殊需求？ │
│ ├── 结构化输出多 → SGLang (FSM加速) │
│ ├── 多LoRA切换 → vLLM (原生最好) │
│ ├── 复杂Prompt程序 → SGLang (DSL编程) │
│ ├── 非NVIDIA硬件 → ONNX Runtime / llama.cpp │
│ ├── 移动端/浏览器 → MLC-LLM │
└────────────────────────────────────────────────────────────────┘
金融行业考量:
合规要求本地部署 → vLLM/Ollama (数据不出内网)
需要审计日志 → vLLM (OpenAI API格式, 易集成日志)
多部门不同模型 → vLLM + 多LoRA (一个底座多个微调)
极低延迟风控 → TRT-LLM (毫秒级优化)
面试表达
问题: 解释LLM推理优化的关键技术，以及你会如何为生产系统选择推理框架？
30秒版本:
"LLM推理的核心挑战是Decode阶段的内存瓶颈——每生成一个Token都要读取整个
模型权重，GPU大量时间在等数据搬运。三个关键优化：一是PagedAttention，
像虚拟内存一样管理KV Cache，把显存利用率从50%提到95%；二是Continuous
Batching，动态组批让GPU利用率从20%到80%以上；三是Speculative Decoding，
用小模型预测大模型验证，速度翻倍且质量不变。框架选择上，vLLM是默认选择，
覆盖大多数场景；TRT-LLM适合追求极致性能的大规模部署；SGLang在结构化
输出和复杂Prompt场景有独特优势。"
2分钟版本:
1. 推理瓶颈分析:
"LLM推理分两个阶段：Prefill是计算密集的，处理输入Tokens，GPU利用率高；
Decode是内存密集的，逐Token生成，GPU大量时间等待数据从显存搬到计算单元。
对于一个7B模型，理论上显存带宽决定了Decode速度的天花板。"
2. 核心优化技术:
"PagedAttention解决显存碎片问题——传统方式预分配max_tokens空间，浪费50%
显存；PagedAttention按Block动态分配，浪费降到4%以下。这直接把服务容量翻
2-4倍。Continuous Batching解决GPU空闲问题——不等一批请求全部完成再处理下
一批，而是有空就立即塞新请求进来。Speculative Decoding利用了'读一次权重
算5次和算1次耗时差不多'的特性，用小模型猜、大模型验证，速度翻倍且数学上
可证明输出分布完全一致。"
3. 框架选型建议:
"在实际项目中，我会根据三个维度选择：并发量、特殊需求、团队能力。
大多数场景vLLM是最安全的选择——社区最大、API兼容OpenAI、一行pip install。
如果需要极致性能且有NVIDIA A100/H100，TRT-LLM的Kernel Fusion能比vLLM
再快20-30%，但工程复杂度也高得多。如果应用层有大量结构化输出需求(如JSON
API)，SGLang的FSM加速能避免结构化输出的30%性能损失。"
4. 实际经验:
"在金融场景中，我会优先考虑Prefix Caching——因为同一个部门的请求往往共享
相同的System Prompt(如合规审查模板)，缓存命中率可以达到90%以上。加上多
LoRA动态切换，一台服务器可以同时为风控、客服、研报分析等不同场景服务。"
追问准备:
Q: "KV Cache为什么是显存大户？能不能不缓存？"
A: "以Llama-3.1-8B为例，每个Token的KV Cache占128KB(FP16)。一个4096 Token
的请求就要512MB。Batch=8就是4GB——已经占了RTX 4060一半的显存。不缓存的话，
每生成一个Token都要重新计算之前所有Token的K和V，复杂度从O(n)变成O(n²)。
优化方向是KV Cache量化(FP8)和GQA减少KV头数，现代模型如Llama-3.x用GQA
把KV Cache缩小了4倍。"
Q: "Speculative Decoding为什么不牺牲质量？"
A: "因为验证步骤使用了rejection sampling。大模型检查每个Draft Token：如果大
模型也会生成这个Token，直接接受；如果不会，则按大模型的概率分布重新采样。
数学上可以证明，这个过程的输出Token分布和纯大模型自回归生成完全一致。
加速来自于'一次前向传播验证多个Token'——这在内存密集的Decode阶段几乎
是免费的。"
Q: "你们公司8GB显卡能用vLLM吗？"
A: "可以，但需要注意配置。用AWQ 4-bit量化的7B模型约占4.5GB，剩下3.5GB给KV
Cache，大约能支持4-6个并发请求(seq_len=2048)。启用FP8 KV Cache可以翻倍。
如果只是个人开发，Ollama更适合。vLLM的优势要在多并发场景才能体现。"
学习资源
必读论文/文章
实操教程
| 资源 | 说明 |
|---|---|
| vLLM Documentation | 官方文档, 安装到部署全流程 |
| SGLang Documentation | 官方文档, 含Benchmark |
| TensorRT-LLM Docs | NVIDIA官方文档 |
| llama.cpp GitHub | CPU推理标准, GGUF格式 |
| ExLlamaV2 GitHub | 消费级GPU极致优化 |
视频推荐
| 资源 | 说明 |
|---|---|
| Efficient LLM Inference - Stanford CS229 (2024) | 学术视角的推理优化全景 |
| vLLM Team Talks (LMSYS) | vLLM开发者分享 |
| Trelis Research - Inference Deep Dive | 实操为主的推理优化教程 |
明日预告
Day 9: 长上下文技术 — RoPE扩展 / Ring Attention
核心问题:
Day 8解决了"如何快速推理" → Day 9解决"如何处理超长输入"
Llama-3.1支持128K上下文，有些模型声称支持1M+
→ 长上下文的技术挑战在哪里？
预习内容:
- RoPE (Rotary Position Embedding): 位置编码如何影响上下文长度
- RoPE Scaling: NTK-aware / YaRN / Dynamic Scaling 扩展方法
- Ring Attention / Sequence Parallelism: 分布式长序列处理
- Memory-efficient长上下文: Landmark Attention / Infini-Attention
- 实际挑战: 长上下文 ≠ 长记忆 ("Lost in the Middle"问题)
- 8GB显存的长上下文策略
与今日的关系:
Day 8: 推理优化 → KV Cache管理 → 序列越长KV Cache越大
Day 9: 长上下文 → 如何在有限显存下支持超长序列
KV Cache是两天内容的核心交叉点
Day 8 总结: LLM推理的核心瓶颈在Decode阶段的内存带宽——GPU大量时间在等数据搬运而非计算。三大关键优化：PagedAttention像虚拟内存一样管理KV Cache，把显存利用率从50%提到95%以上，是vLLM的核心创新；Continuous Batching动态组批让GPU利用率从20%飙升到80%+；Speculative Decoding用小模型猜、大模型验证，速度翻倍且数学上保证输出不变。2025-2026三大框架中，vLLM是社区默认、生态最全；TensorRT-LLM在NVIDIA硬件上性能天花板最高；SGLang凭借RadixAttention和结构化生成加速成为增长最快的新星。对于RTX 4060 8GB用户，个人使用选Ollama，需要API服务选vLLM+AWQ量化，追求单请求极速选ExLlamaV2。推理优化不只是技术问题，更是产品成本问题——优化得当可以降低50-90%的推理成本，直接决定LLM产品能否盈利。