LLM 推理服务部署架构

原创灵阙教研团队

S 精选提升 | 约 6 分钟阅读更新于 2026-02-27

AI 导读

LLM 推理服务部署架构从推理引擎选型到生产级 GPU 集群的全链路实践 Maurice | 灵阙学院一、推理引擎三巨头 LLM 推理服务的核心在于如何在有限的 GPU 资源上最大化吞吐量。三个主流推理引擎各有侧重。 ┌─────────────────────────────────────────────────────────────┐ │ 推理引擎技术栈 │...

LLM 推理服务部署架构

从推理引擎选型到生产级 GPU 集群的全链路实践

Maurice | 灵阙学院

一、推理引擎三巨头

LLM 推理服务的核心在于如何在有限的 GPU 资源上最大化吞吐量。三个主流推理引擎各有侧重。

┌─────────────────────────────────────────────────────────────┐
│                   推理引擎技术栈                              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  vLLM                TGI                 TensorRT-LLM       │
│  ┌──────────┐       ┌──────────┐       ┌──────────┐        │
│  │PagedAttn │       │Flash Attn│       │TensorRT  │        │
│  │连续批处理 │       │Token流式 │       │图优化    │         │
│  │OpenAI API│       │HF生态    │       │NVIDIA原生│         │
│  │Python原生│       │Rust+Py  │       │C++核心   │         │
│  └──────────┘       └──────────┘       └──────────┘        │
│       │                  │                  │               │
│       ▼                  ▼                  ▼               │
│  通用 + 灵活        HF 集成最优        极致性能            │
└─────────────────────────────────────────────────────────────┘

1.1 详细对比

维度	vLLM	TGI (HuggingFace)	TensorRT-LLM
核心优势	PagedAttention 显存高效	HuggingFace 生态深度整合	NVIDIA 硬件极致优化
语言	Python	Rust + Python	C++ + Python
API 兼容	OpenAI 兼容	自有 API + OpenAI 适配	Triton Server
模型支持	广泛 (Llama/Mistral/Qwen等)	HF Hub 全量模型	需预编译 engine
量化支持	AWQ, GPTQ, FP8	GPTQ, AWQ, EETQ	FP8, INT8, INT4 (原生)
多模型部署	需多实例	需多实例	Triton 原生支持
启动时间	快 (直接加载权重)	中等	慢 (需编译 engine)
社区活跃度	极高 (UC Berkeley)	高 (HuggingFace)	高 (NVIDIA)
生产成熟度	高	高	高 (企业级)

1.2 选型决策

你的优先级是什么？
│
├─ 快速上手 + OpenAI 兼容 API
│  └─ vLLM (默认推荐，社区最活跃)
│
├─ HuggingFace 模型直接部署 + 快速迭代
│  └─ TGI (模型切换最方便)
│
├─ 极致吞吐 + NVIDIA GPU 深度优化
│  └─ TensorRT-LLM (需要预编译，但性能最强)
│
└─ 多模型统一服务 + 企业级运维
   └─ TensorRT-LLM + Triton Inference Server

二、服务架构模式

2.1 单模型服务

最简单的部署形态，一个服务实例对应一个模型。

Client → Load Balancer → [vLLM Instance (Model A)] x N

# vLLM 单模型部署
python -m vllm.entrypoints.openai.api_server \
    --model Qwen/Qwen2.5-72B-Instruct-AWQ \
    --quantization awq \
    --tensor-parallel-size 4 \
    --max-model-len 32768 \
    --gpu-memory-utilization 0.90 \
    --port 8000

2.2 多模型网关

通过统一网关将请求路由到不同模型实例。

                    ┌── vLLM (Qwen-72B) ──── GPU Node A
Client → Gateway ───┼── vLLM (Llama-70B) ── GPU Node B
                    ├── TGI (Mistral-7B) ── GPU Node C
                    └── vLLM (CodeLlama) ── GPU Node D

2.3 模型路由与负载均衡

# 路由策略示例
class ModelRouter:
    def route(self, request: ChatRequest) -> str:
        # 按任务复杂度路由
        if request.estimated_complexity == "high":
            return "qwen-72b"
        elif request.task_type == "code":
            return "codellama-34b"
        else:
            return "qwen-7b"  # 简单任务用小模型

    def select_instance(self, model: str) -> str:
        instances = self.healthy_instances[model]
        # 按队列深度选择最空闲的实例
        return min(instances, key=lambda i: i.pending_requests)

三、硬件选型

3.1 GPU 显存估算

模型加载所需显存的经验公式：

显存 (GB) = 参数量 (B) * 每参数字节数 + KV Cache + 运行开销

FP16: 参数量 * 2 bytes
INT8: 参数量 * 1 byte
INT4: 参数量 * 0.5 bytes

KV Cache = batch_size * seq_len * num_layers * hidden_dim * 2 * dtype_size

3.2 常见模型硬件需求

模型	参数量	FP16 显存	AWQ/INT4 显存	推荐 GPU 配置
Llama-3.1-8B	8B	16 GB	6 GB	1x A100-40G / 1x L40S
Qwen2.5-32B	32B	64 GB	20 GB	2x A100-40G / 1x A100-80G
Llama-3.1-70B	70B	140 GB	40 GB	2x A100-80G / 4x A100-40G
Qwen2.5-72B	72B	144 GB	42 GB	2x A100-80G (TP=2)
Llama-3.1-405B	405B	810 GB	220 GB	8x A100-80G (TP=8)

3.3 吞吐量规划

单 GPU 吞吐估算 (vLLM, A100-80G, FP16):
  7B 模型:  ~2000 tokens/s (批处理)
  70B 模型: ~300 tokens/s  (TP=2, 批处理)

生产容量规划:
  目标: 100 并发用户, 平均每请求 500 output tokens
  所需吞吐: 100 * 500 / 平均响应时间(s)

  以 70B 模型为例:
  单实例 ~300 tok/s → 单用户 ~1.7s
  100 并发 → 需要 ~170 tok/s 持续吞吐 → 1 实例 (2xA100) 可覆盖
  但 P99 延迟要求 < 10s → 建议 2 实例做冗余

四、量化部署

4.1 量化方案对比

方案	精度	压缩比	质量损失	推理速度	工具链
FP16	16-bit	1x	无	基线	原生支持
GPTQ	4-bit	4x	轻微	1.5-2x	AutoGPTQ
AWQ	4-bit	4x	极小	1.5-2x	AutoAWQ
GGUF	2-8bit	2-8x	可调	CPU友好	llama.cpp
FP8	8-bit	2x	极小	1.3x	TensorRT-LLM

4.2 量化部署示例

# AWQ 量化模型部署 (vLLM)
python -m vllm.entrypoints.openai.api_server \
    --model TheBloke/Llama-2-70B-Chat-AWQ \
    --quantization awq \
    --tensor-parallel-size 2 \
    --max-model-len 4096 \
    --enforce-eager  # 调试时关闭 CUDA Graph

# GGUF 模型部署 (llama.cpp server, CPU/低端GPU)
./llama-server \
    -m models/qwen2.5-7b-instruct-q4_k_m.gguf \
    -c 8192 \
    -ngl 35 \
    --host 0.0.0.0 \
    --port 8080

4.3 量化选型建议

你的硬件是什么？
│
├─ 高端 GPU (A100/H100)
│  └─ FP8 (TensorRT-LLM) 或 FP16 (vLLM)
│     性能最好，质量无损
│
├─ 中端 GPU (A10G/L40S/RTX 4090)
│  └─ AWQ 4-bit (vLLM / TGI)
│     4x 压缩，质量损失极小
│
├─ 低端 GPU / 消费级
│  └─ GGUF Q4_K_M (llama.cpp)
│     CPU+GPU 混合推理
│
└─ 纯 CPU 部署
   └─ GGUF Q4_K_M / Q5_K_M (llama.cpp)
      速度较慢但可用

五、自动伸缩策略

5.1 伸缩指标

┌───────────────────────────────────────────┐
│           自动伸缩决策树                    │
├───────────────────────────────────────────┤
│                                           │
│  监控指标:                                 │
│  ├─ GPU 利用率 > 80% (持续 5min)          │
│  ├─ 请求队列深度 > 50                      │
│  ├─ P95 延迟 > 阈值                       │
│  └─ Token 吞吐量接近上限                   │
│                                           │
│       任一触发 → 扩容 (cooldown: 5min)     │
│                                           │
│  缩容条件:                                 │
│  ├─ GPU 利用率 < 30% (持续 15min)         │
│  └─ 请求队列深度 < 5 (持续 15min)          │
│                                           │
│       全部满足 → 缩容 (cooldown: 10min)    │
└───────────────────────────────────────────┘

5.2 Kubernetes HPA 配置

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: vllm-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: vllm-serving
  minReplicas: 1
  maxReplicas: 8
  metrics:
    - type: Pods
      pods:
        metric:
          name: gpu_utilization
        target:
          type: AverageValue
          averageValue: "80"
    - type: Pods
      pods:
        metric:
          name: pending_requests
        target:
          type: AverageValue
          averageValue: "20"
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60
      policies:
        - type: Pods
          value: 2
          periodSeconds: 120
    scaleDown:
      stabilizationWindowSeconds: 300

六、成本优化模式

模式	节省比例	实施方式
Spot/抢占实例	60-90%	非关键负载用 Spot GPU
分时复用	30-50%	非高峰时段缩容到最小
量化压缩	50-75%	AWQ/GPTQ 减少 GPU 需求
模型级联	40-60%	简单请求走小模型
推测解码	10-30%	小模型草稿 + 大模型验证
KV Cache 复用	10-20%	Prefix caching (vLLM 原生支持)

七、生产部署清单

维度	检查项	说明
可用性	健康检查端点	/health 返回模型加载状态
可用性	优雅关停	SIGTERM 时等待在途请求完成
可用性	多实例冗余	至少 2 实例消除单点
性能	基准测试	用 benchmark_serving.py 确认吞吐
性能	显存监控	OOM 前告警并拒绝新请求
安全	API 认证	Token / API Key 鉴权
安全	输入过滤	Prompt 长度限制 + 内容安全
运维	日志收集	请求日志 + 性能指标
运维	模型版本管理	版本化存储 + 灰度发布
成本	使用量计量	按 Token 计量用于计费/预算

Maurice | maurice_wen@proton.me