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 详细对比

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 常见模型硬件需求

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 量化方案对比

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

六、成本优化模式

七、生产部署清单

Maurice | [email protected]