模型部署层

2. 层级定位与边界

L2 模型部署层位于 L1 基础设施层之上、L3 模型市场之下，是连接物理算力与模型资产的核心桥梁。它的核心职责是将模型权重文件转化为可供外部调用的高性能推理服务，并管理这些服务的全生命周期——部署、监控、扩缩容、灰度、下线。

L2 不直接操作物理 GPU 设备，也不管理模型元数据版本，这些分别由 L1 和 L3 负责。L2 的焦点在于推理引擎的编排与运行时管理。

3. 边界规范

4. 推理引擎矩阵

L2 层支持多种推理引擎，覆盖从高性能生产部署到本地开发调试的全场景需求。每种引擎有明确的选型定位和推荐用途。

4.1 vLLM 深度剖析（主推引擎）

4.1.1 架构设计

vLLM 的核心架构由调度器 (Scheduler)、Block Manager、Worker 进程和API Server 四部分组成。调度器负责任务调度和抢占，Block Manager 实现 PagedAttention 的显存管理，Worker 执行实际的模型推理，API Server 提供 OpenAI-compatible 的 HTTP 接口。

4.1.2 启动配置详解

vLLM 的启动参数直接影响推理性能、显存利用率和吞吐。以下展示推理 API 服务的完整启动命令和关键参数说明：

# vLLM 启动命令 — Llama 3.1 70B (8×A100-80G, TP=8)
python -m vllm.entrypoints.openai.api_server \
  --model /models/llama3.1-70b \
  --tensor-parallel-size 8 \
  --max-model-len 8192 \
  --gpu-memory-utilization 0.95 \
  --max-num-seqs 256 \
  --max-num-batched-tokens 8192 \
  --enable-prefix-caching \
  --enable-lora \
  --max-lora-rank 64 \
  --lora-extra-vocab-size 256 \
  --lora-dtype auto \
  --dtype bfloat16 \
  --kv-cache-dtype fp8 \
  --port 8000 \
  --host 0.0.0.0 \
  --trust-remote-code \
  --enforce-eager \
  --seed 42

# 参数说明表:
# --tensor-parallel-size      张量并行度, 每张卡处理一部分 hidden dimension
# --max-model-len             最大序列长度 (prompt + generation), OOM 保护
# --gpu-memory-utilization    KV Cache 使用的显存比例, 剩余留给模型权重
# --max-num-seqs              最大并发序列数, 越大吞吐越高但延迟增加
# --max-num-batched-tokens    每个 batch 最大 token 数
# --enable-prefix-caching     相同前缀请求共享 KV Block, 减少重复计算
# --enable-lora               LoRA adapter 热加载支持
# --max-lora-rank             最大 LoRA rank 值 (8/16/32/64)
# --kv-cache-dtype fp8        使用 FP8 格式存储 KV Cache, 节省 50% 显存
# --enforce-eager             禁用 CUDA graph, 减少显存占用 (调试用)

4.1.3 性能基准测试

以下数据基于平台内部测试环境（A100-80G SXM, NVLink Full Mesh, InfiniBand NDR200）采集。测试工具使用 vLLM benchmark 套件，数据集为 ShareGPT 真实请求跟踪。

4.1.4 LoRA 热加载机制

LoRA (Low-Rank Adaptation) 热加载允许在不重启推理服务的情况下动态切换模型行为（如领域微调、角色扮演、风格迁移）。vLLM 通过独立的 LoRA 管理器维护多个 adapter，每个推理请求可按需选择使用不同的 adapter。

LoRA 架构设计

• LoRA 管理器：常驻进程，维护 adapter 池（最多 256 个活跃 adapter），管理显存中的 LoRA 权重
• adapter 存储：权重文件存储于 L1 对象存储（MinIO），启动时懒加载到 GPU 显存
• 请求级路由：每个 /v1/chat/completions 请求可通过 model 参数指定 base model @ adapter
• 版本管理：每个 adapter 支持多版本，热切换零中断

# LoRA adapter 上传 API
POST /v1/loRA/adapters
Content-Type: multipart/form-data

# 请求体
{
  "lora_name": "my-custom-adapter",
  "lora_path": "s3://lora-adapters/finance-v2/adapter.safetensors",
  "base_model": "llama3.1-70b",
  "max_lora_rank": 64,
  "version": "v2.1.0"
}

# 响应
HTTP/1.1 201 Created
{
  "lora_name": "my-custom-adapter",
  "status": "loading",
  "estimated_load_time": "12s",
  "adapter_id": "lora-abc123-def456"
}

---

# LoRA adapter 列表查询
GET /v1/loRA/adapters

# 响应
HTTP/1.1 200 OK
{
  "adapters": [
    {
      "name": "my-custom-adapter",
      "status": "active",          # active | loading | error
      "base_model": "llama3.1-70b",
      "rank": 64,
      "version": "v2.1.0",
      "gpu_memory_mb": 128,
      "created_at": "2026-06-01T10:30:00Z",
      "loaded_at": "2026-06-01T10:30:15Z",
      "request_count": 1520
    }
  ]
}

---

# 请求级别 LoRA 路由示例
POST /v1/chat/completions
Content-Type: application/json

{
  "model": "llama3.1-70b@my-custom-adapter",  # base@adapter 路由
  "messages": [
    {"role": "user", "content": "What is the RSI of AAPL?"}
  ],
  "temperature": 0.1
}

# 响应 (使用 LoRA adapter 微调后的模型回复)
HTTP/1.1 200 OK
{
  "model": "llama3.1-70b@my-custom-adapter",
  "choices": [{
    "message": {
      "content": "Based on the latest data, AAPL's RSI(14) is 58.3, indicating neutral momentum..."
    }
  }],
  "usage": {
    "prompt_tokens": 18,
    "completion_tokens": 42,
    "total_tokens": 60
  }
}

4.2 引擎选型决策树

选择一个推理引擎需要在吞吐、延迟、显存效率、生态兼容和运维复杂度之间权衡。以下是平台推荐的选型决策路径。

5. 一键部署

L2 模型部署层提供一键部署 (One-Click Deployment) 能力，用户只需选择模型、引擎和资源配置，平台自动完成推理 Pod 创建、权重挂载、Service 暴露和监控集成。

5.1 部署流程

启动时间目标

5.2 ModelDeployment CRD

平台通过自定义 CRD (Custom Resource Definition) 定义模型部署的期望状态。CRD 控制器将期望状态同步为 K8s 原生资源（Deployment、Service、HPA 等）。

# ModelDeployment CRD 完整定义示例
apiVersion: ai.platform/v1
kind: ModelDeployment
metadata:
  name: llama3-1-70b-production
  namespace: inference
  labels:
    model: llama3.1-70b
    engine: vllm
    environment: production
    team: ai-platform
spec:
  # ── 模型与引擎 ──
  model:
    name: llama3.1-70b
    version: "v1.0.0"
    source:
      type: S3
      path: s3://model-weights/llama3.1-70b/
      format: safetensors
      size: 140Gi                    # 权重文件总大小
    quantization: bf16               # bf16 | fp8 | int4 | awq | gptq
    engine:
      type: vllm                     # vllm | tensorrt-llm | tgi | sglang
      version: "0.6.3"
      image: registry.internal/vllm:v0.6.3-cuda12.4
      args:
        tensor-parallel-size: 8
        max-model-len: 8192
        gpu-memory-utilization: 0.95
        max-num-seqs: 256
        max-num-batched-tokens: 8192
        enable-prefix-caching: true
        enable-lora: true
        max-lora-rank: 64
        kv-cache-dtype: fp8
        dtype: bfloat16
        trust-remote-code: true

  # ── 资源规格 ──
  resources:
    replicas: 2                      # 初始副本数
    gpu:
      type: nvidia-a100-80g
      count: 8                       # 每副本 GPU 数量
    cpu: "64"
    memory: "512Gi"
    ephemeral-storage: "100Gi"
    nodeSelector:
      accelerator-model: "A100-SXM-80GB"
      accelerator-count: "8"

  # ── 存储 ──
  storage:
    model-weight:
      storageClass: minio-csi
      size: 200Gi
      existingClaim: ""              # 空则自动创建 PVC
    lora-adapters:
      storageClass: minio-csi
      size: 50Gi
    cache:
      storageClass: nvme-local
      size: 100Gi
      mountPath: /mnt/cache

  # ── 网络 ──
  network:
    serviceType: ClusterIP
    ports:
    - name: http
      port: 8000
      targetPort: 8000
    ingress:
      enabled: true
      host: llama3-70b.api.internal
      annotations:
        nginx.ingress.kubernetes.io/proxy-read-timeout: "600"

  # ── 扩缩容 ──
  scaling:
    minReplicas: 2
    maxReplicas: 10
    metrics:
    - type: QPS
      target: 100                    # 每副本 QPS > 100 扩容
    - type: GPUUtilization
      target: 70                     # GPU 利用率 > 70% 扩容
    - type: P99Latency
      target: 3000                   # P99 延迟 > 3s 扩容 (ms)
    - type: QueueDepth
      target: 50                     # 排队请求 > 50 扩容
    scaleDownStabilization: 300      # 缩容稳定窗口 (秒)
    scaleUpStabilization: 60         # 扩容稳定窗口 (秒)

  # ── 灰度发布 ──
  rollout:
    strategy: RollingUpdate           # RollingUpdate | BlueGreen | Canary
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
    canary:                           # Canary 策略配置
      steps:
      - weight: 10
        duration: 10m                 # 10% 流量验证 10 分钟
      - weight: 50
        duration: 30m                 # 50% 流量验证 30 分钟
      - weight: 100
        duration: 10m                 # 全量
      metrics:
        - errorRate < 0.01            # 错误率 < 1%
        - p99Latency < 3000           # P99 延迟 < 3s
        - gpuUtilization < 90         # GPU 利用率 < 90%

  # ── 健康检查 ──
  health:
    readinessProbe:
      httpGet:
        path: /health
        port: 8000
      initialDelaySeconds: 60
      periodSeconds: 10
      timeoutSeconds: 5
    livenessProbe:
      httpGet:
        path: /health
        port: 8000
      initialDelaySeconds: 120
      periodSeconds: 30
      timeoutSeconds: 10

  # ── 监控集成 ──
  monitoring:
    metrics:
      enabled: true
      port: 8000
      path: /metrics
    logs:
      enabled: true
      collector: fluent-bit
    traces:
      enabled: false

  # ── 安全 ──
  security:
    serviceAccount: inference-sa
    networkPolicy:
      enabled: true
      allowedSources:
      - namespace: gateway
    podSecurityContext:
      runAsUser: 1000
      fsGroup: 2000

---
# 部署状态 (由控制器更新)
apiVersion: ai.platform/v1
kind: ModelDeployment
metadata:
  name: llama3-1-70b-production
  namespace: inference
status:
  phase: Running                     # Pending | Deploying | Running | Scaling | Upgrading | Failed
  replicas: 2
  readyReplicas: 2
  availableReplicas: 2
  endpoint: "http://llama3-1-70b-production.inference:8000"
  engineStatus: Healthy
  conditions:
  - type: Deployed
    status: "True"
    lastTransitionTime: "2026-06-02T10:30:00Z"
  - type: Scaled
    status: "True"
    reason: "QPS threshold not reached"
  currentScale: 2
  targetScale: 2
  observedGeneration: 3

6. 自动扩缩容

L2 层支持多层次自动扩缩容策略，覆盖不同的业务场景和负载模式。扩缩容决策基于多个维度的指标综合判断，避免单一指标误触发。

6.1 HPA (水平扩缩) 与 VPA (垂直扩缩)

6.2 KEDA ScaledObject 配置

KEDA 通过 Prometheus 触发器实现 GPU 感知自动伸缩，支持同时监控多个指标维度：

# KEDA ScaledObject — 推理服务 GPU 感知自动伸缩
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: llama3-70b-scaler
  namespace: inference
spec:
  scaleTargetRef:
    name: llama3-1-70b-deployment
    apiVersion: apps/v1
    kind: Deployment
  pollingInterval: 15                # 每 15 秒查询一次指标
  cooldownPeriod: 120                # 触发条件消失后等待 2 分钟再缩容
  minReplicaCount: 2
  maxReplicaCount: 10
  advanced:
    horizontalPodAutoscalerConfig:
      behavior:
        scaleDown:
          stabilizationWindowSeconds: 300
          policies:
          - type: Percent
            value: 50                 # 每次最多缩容 50% 副本
            periodSeconds: 60
        scaleUp:
          stabilizationWindowSeconds: 60
          policies:
          - type: Pods
            value: 4                  # 每次最多扩容 4 个副本
            periodSeconds: 60
          - type: Percent
            value: 100
            periodSeconds: 60
          selectPolicy: Max           # 取最大值

  triggers:
  # 触发器 1: GPU 利用率
  - type: prometheus
    metricType: AverageValue
    metadata:
      serverAddress: http://prometheus-server.monitoring:9090
      query: |
        avg(
          avg_over_time(
            DCGM_FI_DEV_GPU_UTIL{
              pod=~"llama3-1-70b-deployment-.*"
            }[2m]
          )
        ) by (pod)
      threshold: "70"                 # GPU 利用率平均值 > 70% 扩容
      activationThreshold: "10"       # GPU 利用率 < 10% 缩容时忽略

  # 触发器 2: QPS (每秒请求数)
  - type: prometheus
    metricType: AverageValue
    metadata:
      serverAddress: http://prometheus-server.monitoring:9090
      query: |
        sum(rate(
          vllm:request_prometheus_requests_total{
            pod=~"llama3-1-70b-deployment-.*"
          }[1m]
        )) by (pod)
      threshold: "100"                # 每副本 QPS > 100 扩容
      activationThreshold: "5"

  # 触发器 3: P99 延迟
  - type: prometheus
    metricType: AverageValue
    metadata:
      serverAddress: http://prometheus-server.monitoring:9090
      query: |
        histogram_quantile(0.99,
          sum(rate(
            vllm:request_prometheus_ttft_seconds_bucket{
              pod=~"llama3-1-70b-deployment-.*"
            }[2m]
          )) by (le)
        )
      threshold: "3"                  # P99 TTFT > 3s 扩容 (单位: 秒)
      activationThreshold: "0.5"

  # 触发器 4: 排队深度
  - type: prometheus
    metricType: AverageValue
    metadata:
      serverAddress: http://prometheus-server.monitoring:9090
      query: |
        avg(
          vllm:num_requests_waiting{
            pod=~"llama3-1-70b-deployment-.*"
          }
        ) by (pod)
      threshold: "50"                 # 排队请求 > 50 扩容
      activationThreshold: "5"

6.3 Scale to Zero (缩零能力)

对于非核心或实验性模型服务，平台支持 Scale to Zero 能力，在不使用时自动将副本数缩减至零，节省 GPU 资源。当请求到来时通过 Knative/KEDA 冷启动恢复。

# KEDA ScaledObject — Scale to Zero 配置
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: experimental-model-scaler
  namespace: inference-dev
spec:
  scaleTargetRef:
    name: experimental-model-deployment
  minReplicaCount: 0                  # 缩零
  maxReplicaCount: 3
  triggers:
  - type: prometheus
    metricType: AverageValue
    metadata:
      serverAddress: http://prometheus-server.monitoring:9090
      query: |
        sum(rate(
          istio_requests_total{
            destination_workload="experimental-model",
            destination_service_namespace="inference-dev"
          }[5m]
        ))
      threshold: "1"                  # 只要有请求就扩容
      activationThreshold: "0"
  advanced:
    horizontalPodAutoscalerConfig:
      behavior:
        scaleDown:
          stabilizationWindowSeconds: 600   # 无请求 10 分钟后缩零
          policies:
          - type: Pods
            value: 1
            periodSeconds: 60

6.4 定时弹性扩缩

可预见的业务高峰（如上班早高峰、促销活动）通过定时弹性策略预先扩容，消除冷启动延迟的影响。

# KEDA ScaledObject — 定时弹性 (Cron 触发器)
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: scheduled-scale-pre-warm
  namespace: inference
spec:
  scaleTargetRef:
    name: llama3-1-70b-deployment
  minReplicaCount: 2
  maxReplicaCount: 20
  triggers:
  - type: cron
    metadata:
      timezone: Asia/Shanghai
      start: 0 8 * * *               # 早 8 点开始扩容
      end: 0 10 * * *                # 早 10 点结束
      desiredReplicas: "15"          # 高峰前预扩到 15 副本
  - type: cron
    metadata:
      timezone: Asia/Shanghai
      start: 0 18 * * *              # 晚 6 点开始扩容
      end: 0 22 * * *                # 晚 10 点结束
      desiredReplicas: "12"
  - type: cron
    metadata:
      timezone: Asia/Shanghai
      start: 0 0 * * *               # 夜间缩容
      end: 0 6 * * *
      desiredReplicas: "3"

6.5 预热策略

新启动的推理 Pod 在接入真实流量前需要预热，确保模型权重完全加载、KV Cache 填充到工作状态、CUDA kernel 编译完成。预热不充分会导致首个请求延迟极高（tail latency spike）。

# 预热配置 — 嵌入 ModelDeployment 中
spec:
  warmup:
    enabled: true
    strategy: prewarm-requests        # prewarm-requests | prewarm-mock | prewarm-cached
    requests:
    - prompt: "Hello, this is a warmup request. Please generate a short response."
      maxTokens: 128
      count: 10                       # 发送 10 个预热请求
    concurrency: 4                    # 预热并发数
    timeout: 120                      # 预热超时 (秒)
    readinessCondition:               # 预热完成才能就绪
      minSuccessfulRequests: 8        # 至少 8 个请求成功
      maxP95LatencyMs: 5000           # P95 延迟 < 5s

7. 灰度发布

模型服务的升级（引擎版本变更、模型权重替换、配置参数调整）采用灰度发布机制，逐步将流量切到新版本，在可观测指标异常时自动回滚。

7.1 发布策略对比

7.2 Canary 步骤示例

7.3 Canary 灰度发布 YAML 配置

# Istio VirtualService + DestinationRule — Canary 灰度
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: llama3-70b-canary
  namespace: inference
spec:
  hosts:
  - llama3-70b.inference.svc.cluster.local
  http:
  - match:
    - headers:
        x-canary:
          exact: "true"              # 特定 Header 流量到新版本
    route:
    - destination:
        host: llama3-70b-v2
      weight: 100
  - route:
    - destination:
        host: llama3-70b-v2          # 新版本 v2
      weight: 10
    - destination:
        host: llama3-70b-v1          # 旧版本 v1
      weight: 90
    timeout: 60s
    retries:
      attempts: 2
      perTryTimeout: 30s
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: llama3-70b-destination
  namespace: inference
spec:
  host: llama3-70b-v2
  trafficPolicy:
    connectionPool:
      http:
        http1MaxPendingRequests: 128
        maxRequestsPerConnection: 100
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 5m
      maxEjectionPercent: 50

7.4 自动回滚机制

灰度发布过程中，控制器持续监控关键指标。当检测到异常时自动回滚到上一版本，无需人工介入。

# 自动回滚配置 (嵌入 ModelDeployment rollout 策略)
spec:
  rollout:
    strategy: Canary
    canary:
      steps:
      - weight: 10
        duration: 10m
        metrics:                      # 每个 step 的验证指标
        - name: error-rate
          query: |
            sum(rate(
              istio_requests_total{
                destination_workload="llama3-70b-v2",
                response_code=~"5.."
              }[5m]
            )) / sum(rate(
              istio_requests_total{
                destination_workload="llama3-70b-v2"
              }[5m]
            ))
          threshold: 0.01              # 错误率 > 1% 回滚
        - name: p99-latency
          query: |
            histogram_quantile(0.99,
              sum(rate(
                istio_request_duration_milliseconds_bucket{
                  destination_workload="llama3-70b-v2"
                }[5m]
              )) by (le)
            )
          threshold: 5000              # P99 延迟 > 5s 回滚 (ms)
        - name: gpu-utilization
          query: |
            avg(
              DCGM_FI_DEV_GPU_UTIL{
                pod=~"llama3-70b-v2-.*"
              }
            )
          threshold: 95                # GPU 利用率 > 95% 回滚
      - weight: 50
        duration: 30m
        metrics:
        - name: error-rate
          query: "..."
          threshold: 0.01
        - name: p99-latency
          threshold: 5000
      rollback:
        action: immediate              # immediate | gradual (逐步撤流)
        notification:
          channel: feishu
          severity: critical

8. 性能优化

推理服务的性能优化涉及引擎配置、硬件利用、请求调度和模型优化四个维度。以下是经验证的 10 项优化技术及其预期收益。

9. SLA / SLO 目标

L2 模型部署层的 SLO 直接影响上层 L3 模型市场和 L4 模型网关的服务质量。以下指标是 L2 团队承诺的关键 SLO，按月度和季度进行评估。

10. 技术选型

以下表格列出了 L2 层所有技术组件的选型结果、版本和选型理由：