附11：工程化部署与推理优化

本节目标：理解 LLM 推理的两阶段瓶颈、掌握 vLLM 三大创新、学会主流量化方案选型、建立服务架构思维。

第11课你实现了 SSE 流式输出。这一节把"模型跑起来之后"的工程问题讲透。

1. LLM 推理为什么慢？

推理的两阶段

Phase 1

Phase 1: Prefill（预填充）
  - 处理 prompt 的所有 token
  - 计算密集，GPU 利用率高
  - 决定：首字延迟 (TTFT)

Phase 2: Decode（解码/生成）
  - 一次生成 1 个 token
  - 显存带宽密集，GPU 利用率低
  - 决定：每 token 延迟 (TPOT)

关键认知：传统以为算力是瓶颈。实际 Decode 阶段，显存带宽才是瓶颈。每生成 1 个 token 需要读取全部 14GB 模型参数，计算量却很小。

性能指标

指标	全称	含义
TTFT	Time To First Token	首字延迟（用户感知关键）
TPOT	Time Per Output Token	每 token 延迟
Throughput	Tokens / Second	系统总吞吐

2. vLLM 三大创新

PagedAttention —— 最核心创新

Code

传统 KV Cache：按 max_seq_length 预分配 → 浪费 60-80% 显存
PagedAttention：像 OS 虚拟内存一样分块管理 → 显存利用率 96%

类比：
  传统 = C 语言 malloc（碎片化）
  PagedAttention = 虚拟内存分页（紧凑高效）

效果：显存利用率 30% → 96%，吞吐量提升 24 倍。

Continuous Batching（连续批处理）

Code

Static Batching：
  Batch 内必须等所有请求完成 → GPU 大量空闲

Continuous Batching：
  请求完成立即放入新请求 → GPU 持续满载

效果：吞吐量提升 5-23 倍。

优化的 CUDA Kernels

FlashAttention 集成 + 算子融合 + 量化支持（AWQ/GPTQ/FP8）。

3. 量化方案对比

方案	精度损失	推理速度	显存压缩	适用场景
FP16	0%	慢	1x	基准
INT8	`<1%`	1.5x	2x	通用
AWQ-INT4	`<1%`	2.5x	4x	GPU部署
GPTQ-INT4	1-2%	2x	4x	GPU部署
GGUF Q4_K_M	1-2%	视硬件	4x	CPU/本地

选型决策

GPU 服务端部署 → AWQ（校准快、精度高、速度快）
本地 / Mac / CPU → llama.cpp + GGUF
微调训练 → BnB (BitsAndBytes) QLoRA

4. 推理框架选型

框架	核心优势	适用
vLLM	PagedAttention + 社区活跃	生产首选推荐
SGLang	RadixAttention + 结构化输出	高吞吐、DeepSeek 部署
TensorRT-LLM	NVIDIA 官方，极致性能	极致性能需求
Ollama	一键启动，像 Docker	个人开发
llama.cpp	C++ 实现，CPU/Metal 都支持	本地/边缘

决策树

Code

你是？
  ├─ 个人开发者 → Ollama / llama.cpp
  ├─ 小型生产 → vLLM
  ├─ 大规模生产 → vLLM / SGLang
  ├─ 极致性能 → TensorRT-LLM
  └─ 边缘设备 → llama.cpp

5. LLM 服务架构

Request Pipeline

用户请求 (HTTPS)
  → API Gateway（鉴权/限流/路由）
  → Load Balancer（按 GPU 利用率均衡）
  → vLLM Instances × N（多副本）
  → Redis Cache（重复请求缓存）

多模型路由

Code

简单分类 → 0.5B 模型
通用问答 → 7B 模型
复杂推理 → 70B 模型

效果：成本降低 5-10x，质量几乎无损

核心要点

Decode 阶段瓶颈是显存带宽，不是算力
vLLM = PagedAttention + Continuous Batching + 优化 Kernel
量化方案：GPU 选 AWQ，本地选 GGUF，微调选 BnB
QPS < 10 用 API，QPS > 50 自部署更便宜

下一节附12，我们讲 MCP 协议与 A2A 标准。