10 推理框架与服务化

训好的模型要「对外服务」才有价值。这一阶段（阶段三）前半段讲推理的独特性、核心优化技术、主流框架对比，以及在 K8s 上怎么把模型变成高吞吐低延迟的服务。这是你「类 TI-ONE」平台里「推」的那一半，也是 2025-2026 最热的招聘方向。

💡 给你的话：推理时代来了——大模型预训练高峰过后，行业重心转向「把模型变成 API」。这章对你来说是把「部署一个 Web 服务」的 K8s 经验迁移到「部署一个模型服务」，多了 KV Cache、批处理、量化这些 AI 特有优化。

---

10.1 推理为什么和训练不一样

维度	训练	推理
计算	前向+反向，吃显存狠	只有前向
关注	吞吐（samples/s）	延迟（首 token/整句耗时）+ 吞吐（QPS）+ 成本/请求
显存	参+梯+优化器+激活	参数 + KV Cache + 激活
负载特征	稳定大 batch	变长、突发、流式（token-by-token）

名词解释：

• 首 token 延迟（Time To First Token, TTFT）：用户发请求到收到第一个字的时间，体感最关键。
• QPS（Queries Per Second）：每秒处理请求数，吞吐指标。
• 流式输出（Streaming）：像打字一样逐 token 返回，而非等整句生成完。用 SSE（Server-Sent Events） 或 WebSocket 实现。

⭐ 重点：推理优化的本质是在「延迟可接受」前提下最大化单卡吞吐、压低单请求成本。常用杠杆：批处理、KV Cache、量化、算子融合。

---

10.2 推理优化核心技术

KV Cache（注意力缓存）

• Transformer 每生成一个 token，都要回顾之前所有 token 的 Key/Value。KV Cache 把历史 K/V 缓存起来复用，避免重复计算——生成越长，收益越大。
  • 名词解释：注意力（Attention） 是 Transformer 的核心机制，让模型「关注」输入里重要的部分。计算时每个 token 会和所有历史 token 算相关性，产生 Key/Value。
• 代价：KV Cache 占显存（随 batch × 序列长度增长），是推理显存的主要变量。

⭐ 重点：推理显存 ≈ 模型参数 + KV Cache。长上下文（如 128K token）的 KV Cache 可能比模型本身还大——这是为什么大上下文推理贵。

连续批处理（Continuous Batching）

• 传统静态批处理：等凑满一批再算，短请求被长请求拖死。
• 连续批处理：请求逐个流入，算完一个就腾位置给下一个，极大提升 GPU 利用率。这是 vLLM/SGLang 高吞吐的根本。

💡 类比：静态批处理像「公交车凑满人才发车」；连续批处理像「传送带，来一个上一个、走一个下一个」。

PagedAttention（vLLM 首创）

• 把 KV Cache 像操作系统虚拟内存分页一样管理，非连续分配，消除碎片、显存利用率翻倍，从而支持更大 batch / 更高并发。
  • 名词解释：分页（Paging） 是 OS 把内存分成固定大小页框管理的技术，避免碎片。PagedAttention 借用这个思想管 KV Cache。

量化（Quantization）

量化 = 用更低精度（更少比特）表示模型权重/激活，省显存、提速度，代价是少量精度损失。

方法	说明	典型显存/提速
FP8 / INT8	低精度权重/激活	显存减半级、提速
AWQ	激活感知权重量化（4-bit）	质量损失小，主流
GPTQ	基于二阶信息的 4-bit 量化	成熟、常用
QLoRA 式 4-bit 基座	推理也可用 4-bit 加载	单卡跑大模型

名词解释：4-bit 量化 = 每个权重只用 4 比特存（原来 FP16 是 16 比特），显存压到 1/4。激活感知（Activation-aware） = 量化时考虑哪些权重更重要、保留更高精度，减少质量损失。

⭐ 推理用低精度（FP8/INT8/4-bit）是「提吞吐降成本」的最直接杠杆，且对质量影响通常可控。

投机解码（Speculative Decoding，2025-2026 热门）

• 用一个小模型快速「猜」几个 token，再用大模型并行验证，对的就采纳——能在不损失质量下显著降延迟。
• 2025-2026 已在 vLLM/SGLang 等主流框架落地。

---

10.3 主流推理框架对比（⭐面试常考）

框架	特点	适合
vLLM	PagedAttention + 连续批处理，吞吐极高，生态广	大模型在线推理事实标准
SGLang	2025–2026 崛起，RadixAttention（前缀缓存复用）+ 高吞吐，长上下文/多轮对话强	高并发、复杂推理链路
TensorRT-LLM	NVIDIA 官方，深度算子融合+量化，极致延迟/吞吐（仅 N 卡）	追求极致性能的生产
TGI（Text Generation Inference）	HuggingFace 出品，易用、支持量化/流式	快速上线
Ollama / llama.cpp	轻量、本地/消费卡友好	个人/边缘
HuggingFace Transformers	直出，无优化	原型

名词解释：RadixAttention（SGLang）= 用基数树组织 KV Cache，让多个请求共享相同前缀的 KV（如系统提示词），大幅省算。前缀缓存（Prefix Caching） 是 2025-2026 推理优化的热点。

选型心智：在线高并发 → vLLM / SGLang；极致 N 卡性能 → TensorRT-LLM；快速验证 → TGI/Ollama。

⚠️ 内幕：2025-2026 推理框架竞争白热化，vLLM 和 SGLang 各有拥趸，性能榜单每月在变。选型别死记榜单，看你的场景（长上下文/多轮对话 → SGLang 强；通用高吞吐 → vLLM 生态广）。

---

10.4 服务化与 K8s 部署

Triton Inference Server（NVIDIA）

• 多框架（TensorRT/PyTorch/ONNX）、多模型、动态批处理、模型集成。
  • 名词解释：ONNX 是跨框架的模型交换格式；模型集成 = 把多个模型串成 pipeline。
• 适合「一个服务挂多个模型、追求性能」的场景。

KServe / Seldon（K8s 原生推理）

• KServe：基于 Knative，用 InferenceService CRD 声明模型服务，自动扩缩容（含缩到 0）、灰度、流量切分。
  • 名词解释：Knative 是 K8s 上的 Serverless 框架，支持「缩到 0」和自动伸缩。灰度（Canary） = 新版本先切小流量验证。
• Seldon：更重的模型部署/多框架/复杂推理图。
• 意义：把「部署模型」变成一条 kubectl apply 的 CRD——这正是平台该提供的抽象（呼应 09.8）。

弹性部署要点

• Autoscaling（自动扩缩容）：按 QPS/GPU 利用率扩副本；≠ 训练，推理可缩到 0 省成本。
• 多模型复用：一个推理服务挂多个适配器（LoRA），降成本。
• 流式输出：SSE/WebSocket 逐 token 返回，提升体感。

---

10.5 实战：用 vLLM 起一个推理服务

# 单卡起一个 7B 模型的 OpenAI 兼容服务
docker run --gpus all -p 8000:8000 \
  vllm/vllm-openai:latest \
  --model Qwen/Qwen2.5-7B-Instruct \
  --tensor-parallel-size 1 \
  --gpu-memory-utilization 0.9 \
  --enable-continuous-batching

# 调用（OpenAI 兼容）
curl http://localhost:8000/v1/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"Qwen/Qwen2.5-7B-Instruct","prompt":"你好","max_tokens":64}'

名词解释：

• tensor-parallel-size：张量并行度，1 = 单卡。多卡推理时可设大于 1。
• gpu-memory-utilization：vLLM 允许占用的显存比例（0.9 = 90%）。
• OpenAI 兼容 API：暴露和 OpenAI 一样的 /v1/completions 接口，方便客户端无缝切换。

在 K8s 用 KServe 暴露（示意）：

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata: {name: qwen7b}
spec:
  predictor:
    model:
      modelFormat: {name: vLLM}
      storageUri: s3://models/qwen2.5-7b
      resources: {limits: {nvidia.com/gpu: 1}}

---

10.6 ⭐ 推理的「成本经济学」（AI Infra 核心价值）

推理时代，企业最关心的是「每 1000 token 成本」。你的优化直接影响营收：

• 量化：FP16 → INT8，显存减半，单卡并发翻倍 → 单请求成本降一半。
• 连续批处理：GPU 利用率从 30% → 80%，吞吐翻倍以上。
• 前缀缓存：多轮对话场景省 30-50% 算力。
• 弹性伸缩：夜间缩到 0，省闲置成本。
• 多 LoRA 复用：一个基座挂多个微调适配器，省多套部署。

⭐ 重点：面试讲推理别只说「我会部署 vLLM」，要讲「我把单 token 成本降了 X%」——量化、批处理、缓存、弹性四件套是你的价值证据。

⚠️ 内幕：推理/训练分离（Disaggregated Serving） 是 2025-2026 的新趋势——把「prefill（首 token 计算）」和「decode（逐 token 生成）」拆到不同 GPU 池，各自优化，因为两者算力/显存特征不同。这是前沿加分点。

---

10.7 实战：在 MacBook 上部署推理服务（CPU 模式）

没有 GPU 也能跑推理——这一节用 Ollama（轻量推理引擎）在 MacBook 上部署一个小模型，体验「加载模型→推理→流式输出」的全链路。

10.7.1 安装 Ollama（MacBook / Linux）

# Mac:
brew install ollama

# Linux:
curl -fsSL https://ollama.com/install.sh | sh

# 启动 Ollama 服务（后台运行）
ollama serve &
# 或 Mac 可直接打开 Ollama.app

# 验证
curl http://localhost:11434/api/version
# 应返回版本号 JSON

目的：Ollama 是轻量推理引擎，内置模型管理，CPU 也能跑（慢但能体验机制）。它不是 vLLM，但推理链路一样：加载模型权重到内存 → 前向传播 → 流式输出 token。

10.7.2 加载一个模型

# 下载一个小模型（Qwen2.5 0.5B，约 500MB，CPU 也能跑）
ollama pull qwen2.5:0.5b

# 查看已下载的模型
ollama list
# 应看到 qwen2.5:0.5b

# 看模型大小
ls -lh ~/.ollama/models/

目的：这一步模拟了「把模型权重加载到显存/内存」。真实 GPU 推理是加载到 HBM 显存，CPU 推理加载到 DRAM 内存——机制一样，只是位置不同。

10.7.3 体验推理（含 prefill + decode）

# 发送推理请求
ollama run qwen2.5:0.5b "解释什么是 GPU"

# 你会看到：
# ① 第一个字等待一会（prefill 阶段：处理 prompt）
# ② 然后逐字输出（decode 阶段：一次一个 token，流式显示）
# 这就是 10.2 讲的 prefill + decode 的直观体验！

目的：你亲眼看到「打字机效果」——第一个字延迟（prefill 算力密集），后续逐字输出（decode 访存密集）。这就是 KV Cache 在起作用。

10.7.4 用 API 调用（模拟线上服务）

# 用 curl 调用 Ollama API（模拟线上推理服务）
curl http://localhost:11434/api/generate -d '{
  "model": "qwen2.5:0.5b",
  "prompt": "什么是 Kubernetes？",
  "stream": true
}'

# 流式输出（SSE 格式）——这就是线上推理 API 的工作方式
# 每个 token 作为一个 JSON 返回

10.7.5 安装 vLLM（Linux 服务器，CPU 模式）

# vLLM 是工业级推理引擎（Mac 上安装较复杂，建议 Linux 服务器）
pip install vllm

# 启动 vLLM 服务（兼容 OpenAI API 格式）
# 需要先下载一个小模型
python3 -c "
from vllm import LLM
llm = LLM(model='Qwen/Qwen2.5-0.5B', dtype='float32', enforce_eager=True)
output = llm.generate('解释 GPU 是什么')
print(output)
"
# 这就是 vLLM 的核心：PagedAttention + 连续批处理
# CPU 模式下会慢，但能验证机制

10.7.6 在 K8s 上部署推理服务

# 在 kind 集群上部署一个推理服务
cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ollama-server
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ollama
  template:
    metadata:
      labels:
        app: ollama
    spec:
      containers:
      - name: ollama
        image: ollama/ollama:latest
        ports:
        - containerPort: 11434
        resources:
          limits:
            cpu: "2"
            memory: "4Gi"
---
apiVersion: v1
kind: Service
metadata:
  name: ollama-service
spec:
  selector:
    app: ollama
  ports:
  - port: 11434
    targetPort: 11434
EOF

# 等待就绪
kubectl get pods -l app=ollama -w

# 端口转发到本地访问
kubectl port-forward svc/ollama-service 8080:11434 &
# 然后访问 http://localhost:8080

目的：这就是「把模型变成 API」——在 K8s 上部署推理 Pod + Service，对外提供推理服务。真实 GPU 场景加 nvidia.com/gpu: 1 资源请求即可。

10.7.7 清理

kubectl delete deployment ollama-server --ignore-not-found
kubectl delete service ollama-service --ignore-not-found

---

10.8 自测题

1. 推理和训练在关注点上有什么本质不同？什么是 TTFT、QPS？
2. KV Cache 是什么？它占显存吗？为什么长上下文推理贵？
3. 连续批处理解决了什么痛点？PagedAttention 又解决了什么？用类比解释。
4. 量化为何能降成本？AWQ 和 GPTQ 是什么？4-bit 量化省多少显存？
5. 什么是投机解码？为什么能不损失质量降延迟？
6. ⭐ vLLM、SGLang、TensorRT-LLM 各自的定位与适用场景？RadixAttention 是什么？
7. KServe / Seldon 在 K8s 上解决什么？它和 Triton 什么关系？为什么能「缩到 0」？
8. 推理服务为什么可以「缩到 0」，而训练一般不行？
9. ⭐ 降低「每 1000 token 成本」有哪四件套？什么是推理/训练分离？

答上即可进 11——怎么用 Prometheus/DCGM 看 GPU、怎么排查「利用率低」。