跳到主要内容

模型部署与推理服务深度解析

引言​

生产级 LLM 推理服务面临高并发、低延迟、显存利用率与成本平衡等多重挑战。本文从架构、框架选型、部署实践到扩缩容，系统解析模型推理服务的工程体系。

主流推理框架架构​

1. vLLM​

核心特性：

  • PagedAttention：借鉴操作系统虚拟内存思想，将 KV Cache 按块管理，显著提升显存利用率与吞吐
  • 连续批处理（Continuous Batching）：动态将新请求加入正在运行的 batch，无需等待当前 batch 全部完成
  • 高吞吐：相比原生 PyTorch 推理，吞吐可提升数倍
  • OpenAI 兼容：提供与 OpenAI Chat Completions 兼容的 HTTP API

适用场景：生产环境、高并发、需要稳定高吞吐的 SaaS 或企业内部服务。

2. TGI (Text Generation Inference)​

核心特性：

  • Hugging Face 官方：与 HuggingFace Hub 深度集成，模型加载标准化
  • 多框架：支持 PyTorch、Flash Attention、Safetensors
  • 安全：内置输入/输出过滤、速率限制
  • 多模型：支持 LLaMA、Mistral、Qwen、Phi 等主流架构

适用场景：企业级、需要标准化模型管理与安全策略的场景。

3. SGLang​

核心特性：

  • RadixAttention：共享前缀的 KV Cache，适合多轮对话、Few-shot 等共享前缀场景
  • 结构化输出：对 JSON、Function Calling 等结构化生成有专门优化
  • 与 vLLM 互补：vLLM 偏吞吐，SGLang 偏结构化与多轮对话场景

适用场景：Agent、结构化输出、多轮对话密集型应用。

推理 API 设计​

OpenAI 兼容接口​

多数推理框架提供与 OpenAI 兼容的端点：

POST /v1/chat/completions
Content-Type: application/json

{
  "model": "qwen2-7b",
  "messages": [{"role": "user", "content": "你好"}],
  "stream": true,
  "temperature": 0.7,
  "max_tokens": 1024
}

优势：应用层可使用 OpenAI SDK、LangChain、Dify 等，仅修改 base_url 即可切换后端。

流式输出（Streaming）​

  • 作用：降低首 Token 延迟（TTFT），用户更快看到输出
  • 实现：服务端按 Token 或 chunk 流式返回 SSE（Server-Sent Events）
  • 注意：需处理断线重连、部分解析错误

批处理与并发​

  • 静态批处理：收集固定数量请求后统一推理，实现简单但延迟不均
  • 动态/连续批处理：vLLM 等支持动态加入新请求，兼顾吞吐与延迟

负载均衡与扩缩容​

单实例能力​

模型规模显存（FP16）显存（4-bit）典型 QPS（估算）
7B~14GB~4–6GB数十–上百
13B~26GB~8–10GB数十
70B~140GB+~40GB+需多卡

多实例部署​

  • 负载均衡：Nginx、Kubernetes Service 等将请求分发到多个推理实例
  • 会话亲和：长对话可考虑按 session 粘性，减少重复加载
  • 健康检查：/health 端点，K8s 探针、负载均衡器健康探测

扩缩容策略​

  • 水平扩展：按 QPS、GPU 利用率等指标自动增减实例
  • 弹性伸缩：Kubernetes HPA、云厂商 Auto Scaling
  • 冷启动：大模型加载耗时，可预留最小实例数减少冷启动

GPU 与资源调优​

显存优化​

  • 量化：INT4/INT8 降低显存，参见 模型量化
  • PagedAttention：vLLM 默认，提高显存利用率
  • 最大批大小：--max-num-seqs 等参数控制并发 batch 大小

延迟与吞吐权衡​

  • TTFT（Time to First Token）：首 Token 延迟，影响用户感知
  • TPS（Tokens Per Second）：生成速度
  • 吞吐（requests/s）：单位时间处理的请求数
  • 批越大吞吐越高，但单请求延迟可能上升，需按业务调优

容器化与 Kubernetes​

Docker 部署示例（vLLM）​

FROM vllm/vllm-openai:latest
# 可自定义启动参数
ENV VLLM_GPU_MEMORY_UTILIZATION=0.9

Kubernetes 部署要点​

  • 资源请求：requests/limits 正确设置 GPU、显存
  • 节点选择：nodeSelector 选择带 GPU 的节点
  • 多副本：Deployment 多副本 + Service 负载均衡
  • HPA：按 CPU/自定义指标扩缩容（需配合指标暴露）

可观测性​

推理服务的可观测性包括：

  • 延迟：TTFT、总耗时、Token 级延迟分布
  • 吞吐：QPS、TPS
  • 错误率：4xx/5xx、超时、OOM
  • 资源：GPU 利用率、显存占用
  • Trace：请求链路追踪，与 AI 可观测性 配合

与本地推理、量化的关系​

主题关系说明
本地推理Ollama、llama.cpp 等轻量方案，适合开发与小规模部署
模型量化量化后模型通过推理服务部署，降低显存与成本
AI 可观测性推理服务的延迟、成本、错误需纳入 LLM 应用监控体系

总结​

模型推理服务是 LLM 应用的工程基石。选型时需结合业务场景：高吞吐选 vLLM，结构化与多轮选 SGLang，企业标准化选 TGI。配合量化、容器化与可观测性，可构建稳定、高效的推理服务体系。