第17章 §05 · 扩展与部署 · 讲解稿¶

承接: Ch17 §04 边缘 → §05 大规模部署篇幅: ~4000 字

一 · 一句话总览¶

大规模 LLM 部署 = K8s + Ray + 推理服务 + 监控。千卡 GPU 集群跑千亿模型, 弹性伸缩 + 多区域容灾 + 成本优化。

二 · 部署模式 3 大类¶

2.1 公有云¶

云厂商	LLM 服务
AWS	Bedrock + SageMaker JumpStart
GCP	Vertex AI + Model Garden
Azure	Azure OpenAI + AI Studio
Cloudflare	Workers AI (CPU 推理)

2.2 私有云¶

CoreWeave (GPU 专用云)
Lambda Labs
Together AI
中国: 阿里 PAI / 腾讯 TI / 百度 BML

2.3 混合云 + 边缘¶

数据敏感部分 → 私有云
弹性部分 → 公有云
延迟敏感 → 边缘

三 · 推理部署架构¶

3.1 单模型小流量¶

用户 → Load Balancer → vLLM (1 GPU)

3.2 大模型 + 高流量¶

用户 → CDN/Edge
       → API Gateway (限流 / 认证)
       → 推理集群 (多个 vLLM Pod)
            ├─ Pod 1 (TP=4, 70B)
            ├─ Pod 2 (TP=4, 70B)
            └─ Pod 3 (TP=4, 70B)
       → 监控 (Prometheus + Grafana)

3.3 多模型 + 多区域¶

                    Global Load Balancer
                   /         |          \
            US-East      EU-West      Asia-Pacific
           (vLLM)        (vLLM)        (vLLM)
            70B           70B           70B

四 · Kubernetes 部署 LLM¶

4.1 Helm Chart¶

# values.yaml
replicaCount: 3
image: vllm/vllm-openai:latest

model: meta-llama/Llama-3-70B-Instruct
tensorParallelSize: 4
gpuMemoryUtilization: 0.9
quantization: awq

resources:
  limits:
    nvidia.com/gpu: 4
    memory: 200Gi

autoscaling:
  enabled: true
  minReplicas: 2
  maxReplicas: 10
  targetGPUUtilization: 70

4.2 Kserve + vLLM¶

apiVersion: serving.kserve.io/v1beta1
kind: InferenceService
metadata:
  name: llm-service
spec:
  predictor:
    model:
      modelFormat:
        name: vllm
      runtime: kserve-vllm
      storageUri: s3://models/llama-3-70b
      resources:
        limits:
          nvidia.com/gpu: "4"

五 · 模型网关¶

5.1 为什么需要网关¶

多模型路由 (A 模型 vs B 模型)
限流 / 配额 (按用户)
Fallback (主模型宕机切备)
A/B 测试 (灰度)
Cost tracking (按调用计费)

5.2 LiteLLM¶

from litellm import completion

# 统一 API 调用多家模型
response = completion(
    model="gpt-4",
    messages=[{"role": "user", "content": "Hello"}],
    api_key="...",
)

5.3 Portkey / Helicone / OpenRouter¶

Portkey: 网关 + observability
Helicone: LLM 监控
OpenRouter: 多模型市场

六 · 弹性伸缩¶

6.1 KEDA + K8s HPA¶

KEDA (Kubernetes Event-Driven Autoscaling): - 基于 GPU 利用率 / 队列长度 / 延迟 - 弹性扩缩容到 0

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: llm-scaler
spec:
  scaleTargetRef:
    name: vllm-deployment
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus:9090
      query: rate(http_requests_total[1m])
      threshold: "100"

6.2 预测性扩容¶

基于历史 + 时间序列预测
提前扩容应对流量峰值
节省冷启动延迟

七 · 成本优化¶

7.1 成本维度¶

维度	优化方法
GPU 成本	Spot 实例 / 自研 NPU
能耗	模型量化 / 蒸馏
请求数	缓存 / 批量
模型大小	MoE / 蒸馏
延迟	调度 / 区域

7.2 Spot 实例 + 预emption 处理¶

AWS Spot 价格: $0.5-1.5/hr (vs On-demand $3-4/hr)
节省 50-70%
风险: 2 分钟通知回收
处理: 多 AZ 冗余 + 快速重启

7.3 模型路由 (按成本)¶

简单 query → Llama 3 8B ($0.05/1M token)
复杂 query → GPT-4 ($5/1M token)
代码 query → DeepSeek-Coder ($0.3/1M token)

八 · 容灾与多区域¶

8.1 主动-主动 (Active-Active)¶

多区域同时服务
Anycast IP / DNS Geo-routing
区域故障 0 中断

8.2 主动-被动 (Active-Passive)¶

主区域 + 备区域
故障时切备 (5-30 分钟)
成本低

8.3 数据同步¶

模型权重跨区域同步 (S3 Cross-Region Replication)
配置 (ConfigMap) 全局一致
KV cache 不跨区域

九 · 监控告警¶

9.1 4 层监控¶

层	工具	指标
业务	Mixpanel / Amplitude	DAU / 转化
应用	Langfuse / Phoenix	延迟 / 错误率
模型	Custom	Token/s / 队列
基础设施	Prometheus + Grafana	GPU / 网络

9.2 关键告警¶

alerts:
  - name: HighLatencyP99
    condition: http_request_duration_p99 > 2s for 5m
    severity: critical
  - name: HighErrorRate
    condition: error_rate > 1% for 5m
    severity: critical
  - name: GPUHighMemory
    condition: gpu_memory_used > 90% for 10m
    severity: warning
  - name: ModelCostSpike
    condition: daily_cost > budget * 1.5
    severity: warning

十 · 一句话总结¶

LLM 部署 = K8s + vLLM + 网关 + 弹性 + 多区域 + 监控。千卡 GPU 集群 + 推理服务 + 智能路由 + 成本优化 让 LLM 服务达到互联网级别的可靠性。未来 Serverless LLM + Edge LLM = 普及。