部署架构的重要性
模型再好，部署不好也白搭。推理部署架构决定了服务的延迟、吞吐、可用性和成本。从单卡到大规模集群，每个规模都有不同的最优架构。
部署规模分层
Tier 1：单卡部署
适用场景： 小规模应用、开发测试、边缘计算
硬件配置：
- GPU: RTX 3090/4090 (24GB) 或 A10G (24GB)
- 模型: 7B Q4量化
- 并发: 5-10 QPS
- 延迟: 50-200ms/token
架构：
[用户] → [Nginx] → [vLLM/Ollama] → [GPU]
优化要点：
- INT4量化减小模型大小
- 使用vLLM的PagedAttention
- 设置合理的max_batch_size
- 启用prefix caching
Tier 2：多卡部署
适用场景： 中等规模生产环境
硬件配置：
- GPU: 2-8张 A100/H100 (80GB)
- 模型: 70B Q4 或 7B FP16
- 并发: 50-100 QPS
- 延迟: 30-100ms/token
架构选择：
方案A：Tensor Parallel（张量并行）
单模型分布在多GPU上:
GPU1: 模型层1-40 (矩阵上半部分)
GPU2: 模型层1-40 (矩阵下半部分)
每次forward需要GPU间通信
适合: 单模型多GPU场景
# vLLM张量并行
python -m vllm.entrypoints.openai.api_server \
--model meta-llama/Llama-3-70B \
--tensor-parallel-size 4
方案B：Pipeline Parallel（流水线并行）
模型按层切分:
GPU1: 层1-20
GPU2: 层21-40
GPU3: 层41-60
GPU4: 层61-80
流水线处理多个请求
适合: 超大模型
方案C：数据并行（多副本）
4张GPU各运行一个完整模型副本:
GPU1: 完整7B模型 ←→ 请求1-100
GPU2: 完整7B模型 ←→ 请求101-200
GPU3: 完整7B模型 ←→ 请求201-300
GPU4: 完整7B模型 ←→ 请求301-400
负载均衡分发请求
适合: 7B级别的多副本部署
Tier 3：集群部署
适用场景： 大规模生产环境
架构：
[负载均衡]
/ | \
[节点1] [节点2] [节点3]
/ \ / \ / \
GPU1 GPU2 GPU3 GPU4 GPU5 GPU6
\ / \ / \ /
[vLLM] [vLLM] [vLLM]
| | |
[共享存储] [模型缓存]
关键组件：
负载均衡
- 基于请求数的均衡（轮询）
- 基于延迟的均衡（最短队列）
- 基于会话的粘性（会话保持）
模型分发
- 共享存储（NFS/S3）存储模型文件
- 节点启动时拉取模型
- 本地SSD缓存热模型
配置管理
- Kubernetes管理Pod
- ConfigMap管理配置
- 就绪探针检查健康状态
Tier 4：弹性云原生
适用场景： 需要弹性伸缩的大规模服务
架构特点：
- 基于Kubernetes的自动伸缩
- GPU节点池按需扩缩
- Spot Instance降低成本
- 多区域部署
弹性伸缩策略：
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: llm-service
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: llm-service
minReplicas: 2
maxReplicas: 20
metrics:
- type: Pods
pods:
metric:
name: llm_queue_depth
target:
type: AverageValue
averageValue: "5"
- type: Resource
resource:
name: gpu_utilization
target:
type: Utilization
averageUtilization: 80
高可用设计
模型冗余
多副本部署:
Active-Active: 所有副本都处理请求
Active-Standby: 一主一备，备用待命
推荐: Active-Active，资源利用率高
故障切换
class FailoverHandler:
def __init__(self, endpoints):
self.endpoints = endpoints
self.health_check_interval = 5 # 秒
async def send_request(self, request):
for endpoint in self.endpoints:
try:
return await self.call(endpoint, request, timeout=30)
except (TimeoutError, ConnectionError):
continue
raise ServiceUnavailableError("所有节点不可用")
优雅降级
正常: GPT-4级别模型 → 高质量回答
高负载: 切换到7B模型 → 可接受质量
故障: 切换到缓存回答或简单模板 → 基本可用
成本优化
GPU利用率优化
# 监控GPU利用率
def monitor_gpu():
while True:
util = get_gpu_utilization()
if util < 50:
# 利用率低，增加batch size
increase_batch_size()
elif util > 90:
# 利用率高，减少batch size
decrease_batch_size()
time.sleep(10)
Spot Instance
策略:
- 使用Spot Instance运行非关键推理
- On-Demand Instance保底容量
- Spot被回收时优雅迁移到On-Demand
成本节省: 60-70%
模型路由
class ModelRouter:
def route(self, request):
# 简单请求用小模型
if request.complexity == "low":
return self.cheap_endpoint # 7B模型
# 复杂请求用大模型
else:
return self.expensive_endpoint # 70B模型
部署检查清单
上线前检查:
□ 模型加载正常（权重完整性校验）
□ 健康检查端点可用
□ 流式输出正常
□ 并发压测通过
□ 故障切换测试
□ 降级方案验证
□ 监控指标采集正常
□ 日志输出正常
□ 成本告警配置
□ 限流配置
□ 认证鉴权
总结
大模型推理部署是"系统工程"而非"单点优化"。从单卡到集群，每个层级都有特定的架构模式。核心原则是：先跑起来再优化——从单卡vLLM起步，根据需求增长逐步扩展到多卡和集群。不要一开始就设计复杂架构，但也不要在业务增长时来不及扩展。预留好水平扩展的接口，在需要时能快速从单卡升级到多卡再到集群。