从冷启动雪崩到全链路自动化：AI推理服务部署实战

AI推理KubernetesGPU

|难度：普通|阅读约 45 分钟

从“测试环境全绿、生产环境雪崩”说起

去年我负责一条 AI 推理服务上线，当时所有单元测试、接口压测全过，结果生产流量一进来，GPU 显存直接被打满，容器被 OOM Killer 杀掉，重启后模型加载又要 40 多秒，期间健康检查失败，又被调度器反复重启——典型的“冷启动雪崩”。排查下来根本不是模型效果问题，而是推理部署流程里几个非常基础的环节没有自动化兜底：模型文件没有做启动前校验、镜像里的 CUDA 运行时和宿主机驱动不兼容、探针配置不适合推理服务的加载特性。

从那之后我认真梳理了一遍“AI 模型推理自动化部署”这件事。它和普通 Web 后端部署的最大区别在于：推理服务是有状态的、计算密集的、加载代价高昂的进程。自动化不能只解决“把代码打包发布”的问题，而要覆盖模型产物校验、GPU 资源匹配、预热、灰度验证、弹性伸缩和故障恢复一整条链路。

这篇文章我把整套流程拆开来讲，适合正在做 AI 应用开发、平台工程、推理服务运维，或者准备把模型从实验环境推向生产环境的朋友参考。里面包含架构设计、流水线实现、Kubernetes 编排策略，以及我实际踩过的坑和排查过程。

1. 推理服务部署与普通后端部署的本质差异

1.1 一个推理进程的生命周期远比 Web 服务复杂

普通 Web 服务进程启动后，监听端口、接受请求、返回响应，整个过程通常毫秒级完成。容器探针就算检测失败，重启成本也很低。

推理服务完全不同。以我常用的大语言模型场景为例，一个 7B 参数的模型权重文件大约 14GB，加载到显存并完成初始化需要 30 秒到数分钟。在加载完成之前，服务无法处理任何推理请求。如果部署系统只看“进程是否存活、端口是否监听”来判断健康状态，就会在模型加载期间反复发出重启指令，导致永远无法进入就绪状态。

推理进程在运行时也不像 Web 服务那样“无状态”。显存里常驻模型权重、KV Cache、CUDA Context。一旦进程异常退出，这些状态全部丢失，恢复成本极高。因此部署策略必须尽量避免重启，同时在必须重启时告知调度系统“这个服务需要较长启动时间”。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

1.2 传统 CI/CD 模板直接套用的三个翻车点

很多团队第一次做模型部署，直接把 Java 或者 Node.js 服务的那套 Jenkins 流水线拿过来用，通常会在三个地方出问题。

第一个是镜像体积和构建时长。模型推理镜像动辄几个 GB 到几十 GB，包含 CUDA 运行时、推理引擎、模型文件。镜像推送、拉取、解压的时间比普通应用多一个数量级，流水线超时配置若还是默认的 10 分钟，必挂。

第二个是健康检查设计。普通服务存活探针直接检测 TCP 端口或 HTTP 接口即可，但推理服务在模型加载完成前，HTTP 端口即便已经监听，也无法真正处理请求。如果探针把“端口通了”当成“服务可用”，流量进来后全部超时；如果存活探针失败阈值设得太低，启动过程中就会被杀掉。

第三个是版本关联关系。代码有版本，模型有版本，推理引擎和 CUDA 也有版本。任何一个组件不匹配，整个服务就跑不起来。传统 CI/CD 流水线通常只管理代码版本，模型和推理引擎的匹配关系全靠人工记录，生产环境一出问题很难回滚。

我在项目里列过一张对比表，用来向团队解释为什么不能照搬普通部署流程：

对比维度	传统 Web 服务	AI 推理服务
启动时间	秒级	秒到分钟级（模型加载）
计算资源	CPU 为主	GPU 为主，显存敏感
状态特性	基本无状态，可随意重启	显存缓存 + 模型常驻，重启代价高
依赖关系	代码 + 依赖包	代码 + 模型文件 + 推理引擎 + CUDA/驱动
容量瓶颈	CPU、内存、连接数	显存、GPU 利用率、推理并发度
健康检查	端口/接口通即可	需确认模型加载完成、显存分配正常、可处理推理请求

如果你想做一套真正可用的推理自动化部署，第一步不是写流水线，而是让你的部署系统理解上面这些差异。后面的所有设计都是围绕这些差异展开的。

2. 整体架构设计：从训练产物到对外服务

2.1 基础设施选型

我这次采用的架构以 Kubernetes 为底座，核心组件包括：

容器运行时与 GPU 调度：Docker + NVIDIA Container Toolkit，配合 Kubernetes 的 NVIDIA Device Plugin，让 Pod 能声明并独占 GPU 资源。
镜像仓库：Harbor，用于存放推理服务镜像和推理引擎镜像。Harbor 自带镜像签名和漏洞扫描，生产环境很有用。
模型仓库：MinIO（S3 协议），用于存放模型文件。MinIO 部署简单，和 Kubernetes 集成方便。也可以直接用云厂商的对象存储或 Hugging Face Hub 的私有化版本。
CI/CD：Jenkins + Pipeline as Code。选 Jenkins 不是因为它是技术上的最优解，而是它在我当时的团队里落地成本最低、插件生态成熟，这个选型逻辑后面专门说。
推理引擎：根据模型类型选。大语言模型我用 vLLM 或 Triton Inference Server，CV 模型用 Triton 或 ONNX Runtime。核心思路是让引擎层支持动态 Batch、并发请求队列和指标暴露，这些能力对弹性伸缩至关重要。

一个比较关键的设计决策是：模型文件不打包进镜像，而是从模型仓库动态拉取。原因有三个：大模型文件容易超过镜像层大小限制，每次构建镜像都会把几百 MB 到几十 GB 的模型文件重复传输，极慢；模型迭代比代码频繁，一旦模型文件进镜像，每次模型更新都要重新走一遍镜像构建流程；模型版本的回滚和灰度必须能独立于代码进行，把模型文件放对象存储后，部署时通过环境变量指定模型版本即可。

2.2 服务链路与组件职责

整个推理服务的调用链路分为四层：

code复制入口网关（Ingress/API Gateway）
    ↓
推理服务容器（FastAPI 或 gRPC 服务）
    ↓
模型加载器（负责从模型仓库拉取并加载）
    ↓
推理引擎（vLLM / Triton / ONNX Runtime）

入口网关负责路由、限流、认证和灰度流量切换。推理请求通常需要长连接和流式响应，网关要支持相应的协议。
推理服务容器是模型和上层业务之间的适配层。它负责将业务请求转换为模型输入、调用推理引擎、解析结果。如果后续要接入多种模型，适配层的价值会非常明显。
模型加载器不是一个独立服务，而是推理服务进程内的一个模块。启动时按环境变量中的模型版本从模型仓库下载模型到本地缓存，再加载到显存。下载和加载都要有详细的日志和指标。
推理引擎是真正吃 GPU 的部分。它要支持并发请求排队、动态 Batch（把多个请求合并成一个 Batch 推理以提高吞吐），并暴露 Prometheus 指标，包括排队长度、Batch 大小、推理延迟、GPU 利用率等。

2.3 模型仓库的目录规范和版本约定

自动化部署要做得好，规范必须先定。我用的模型仓库目录结构如下：

code复制s3://model-repo/
├── llm-chat/
│   ├── 7b-v2.1/
│   │   ├── config.json
│   │   ├── model.safetensors
│   │   ├── tokenizer.json
│   │   └── metadata.json
│   └── 7b-v2.2/
│       ├── config.json
│       ├── model.safetensors
│       ├── tokenizer.json
│       └── metadata.json
└── embedding/
    └── bge-v1.5/
        ├── model.onnx
        └── metadata.json

metadata.json 里记录模型的 SHA256 校验值、使用的推理引擎版本、推荐的显存占用、输入输出的 shape 约束。这个文件在流水线里会被读取，用于镜像构建后的模型校验和环境匹配。SHA256 是部署校验的核心依据，保证下载的模型文件和训练产出一致。

2.4 设计原则：不可变产物 + 可回滚

这套架构的底层设计原则就两条：每次发布对应一个不可变版本，回滚就是切换版本引用。

我的做法是发布时生成一个发布清单，包含镜像 Tag、模型版本、推理引擎版本、环境变量、配置项。发布清单本身作为制品保存在流水线里。回滚时，只需用上一份发布清单重新执行部署步骤，而不需要重新构建镜像或修改代码。这个方式和传统的“改代码再发布”完全不同，它能保证你在任何时候都能回到任意一个历史状态，且状态是完全一致的。

3. Jenkins 流水线：从模型交付到生产可用的完整链路

3.1 工具选型：为什么用 Jenkins

当前社区里自动化部署常用方案有 Jenkins、GitLab CI、GitHub Actions、Argo CD 等。我为什么在 AI 推理部署场景里还是选了 Jenkins？

结合团队实际情况来谈。AI 推理部署的流水线不只是“代码提交后跑测试”，它需要调度 Kubernetes、操作对象存储、等待模型预热、执行金丝雀验证。Jenkins 的 Pipeline 脚本能把这些步骤完整地写成一个有状态编排，且 Jenkins 在私有化部署、内网环境、GPU 服务器集群场景下非常成熟，插件丰富。GitLab CI 的优点是和代码仓库集成紧密，但当时我们团队的模型研发和平台研发不在同一个 GitLab 实例里，跨系统编排反而更麻烦。Argo CD 更适合 GitOps 风格的持续交付，但 AI 推理服务的部署逻辑里有很多“等待模型加载完成”、“验证 GPU 可用性”这类操作，用 Jenkins Pipeline 写起来更直接。

如果你从一开始就全面采用 GitOps，用 Argo CD 也没问题。重要的是理解流水线的阶段设计，工具只是承载。

3.2 流水线阶段拆分与每阶段的核心任务

我设计的流水线包含以下阶段，每个阶段都有明确的价值：

拉取模型元数据：根据本次发布的模型版本，从模型仓库读取 metadata.json，拿到 SHA256 和引擎要求。
模型文件校验：从模型仓库下载模型文件，计算 SHA256，和元数据比对。校验失败直接终止流水线。这一步防止模型文件在传输中被损坏。
单元测试与格式检查：对推理服务的适配层代码跑 lint 和单元测试，确认请求解析、结果格式化等逻辑没有回归。
镜像构建：构建推理服务镜像。镜像里包含代码依赖和推理引擎运行时，但不包含模型文件。构建完成后推送至 Harbor。
安全扫描：对镜像做漏洞扫描，对于高危漏洞设置阻断阈值，避免带着已知漏洞的镜像进入生产。
部署到测试环境：在测试环境用该镜像 + 模型版本部署一套实例，执行自动化冒烟测试。
冒烟测试：发送真实推理请求，验证模型能正常加载、推理延迟在预期范围、返回结果格式正确。
部署到生产金丝雀：在生产环境部署一个金丝雀实例，接入 5% 流量。
金丝雀验证与全量发布：监控金丝雀实例的延迟、错误率、GPU 利用率，持续观察一段时间（通常 30 分钟到几小时）。验证通过后逐步提升流量比例，完成全量发布。

3.3 一个可跑的 Jenkinsfile 示例

这里给一个精简版的 Jenkinsfile，主要展示阶段编排逻辑。不同推理引擎在启动命令和健康检查上略有差异，但骨架是通用的。

groovy复制pipeline {
    agent any

    environment {
        MODEL_VERSION = "7b-v2.1"
        MODEL_REPO_URL = "http://minio:9000/model-repo"
        IMAGE_REPO = "harbor.internal/ai-inference/llm-chat"
        K8S_NAMESPACE = "ai-prod"
        RELEASE_NAME = "llm-chat"
    }

    stages {
        stage('拉取模型元数据') {
            steps {
                script {
                    sh """
                        curl -s -o metadata.json \\
                            ${MODEL_REPO_URL}/llm-chat/${MODEL_VERSION}/metadata.json
                    """
                    env.EXPECTED_SHA = sh(
                        script: "python3 -c \"import json; print(json.load(open('metadata.json'))['sha256'])\"",
                        returnStdout: true
                    ).trim()
                }
            }
        }

        stage('模型文件校验') {
            steps {
                sh """
                    wget -q ${MODEL_REPO_URL}/llm-chat/${MODEL_VERSION}/model.safetensors
                    echo "${EXPECTED_SHA}  model.safetensors" | sha256sum -c -
                """
            }
        }

        stage('单元测试') {
            steps {
                sh "make test"
            }
        }

        stage('构建并推送镜像') {
            steps {
                script {
                    docker.build(
                        "${IMAGE_REPO}:${MODEL_VERSION}-${BUILD_NUMBER}",
                        "--build-arg MODEL_VERSION=${MODEL_VERSION} ."
                    ).push()
                }
            }
        }

        stage('部署到测试环境') {
            steps {
                sh """
                    helm upgrade --install $RELEASE_NAME ./deploy/chart \\
                        --namespace ai-test \\
                        --set image.tag=${MODEL_VERSION}-${BUILD_NUMBER} \\
                        --set model.version=${MODEL_VERSION} \\
                        --wait
                """
            }
        }

        stage('冒烟测试') {
            steps {
                sh """
                    python scripts/smoke_test.py \\
                        --endpoint http://$RELEASE_NAME.ai-test:8080 \\
                        --prompt "介绍一下你自己" \\
                        --expect-latency-ms 5000
                """
            }
        }

        stage('部署生产金丝雀') {
            steps {
                sh """
                    helm upgrade --install $RELEASE_NAME ./deploy/chart \\
                        --namespace $K8S_NAMESPACE \\
                        --set image.tag=${MODEL_VERSION}-${BUILD_NUMBER} \\
                        --set model.version=${MODEL_VERSION} \\
                        --set canary.enabled=true \\
                        --set canary.trafficWeight=5 \\
                        --wait
                """
            }
        }

        stage('金丝雀验证') {
            steps {
                sh """
                    python scripts/canary_validate.py \\
                        --namespace $K8S_NAMESPACE \\
                        --release $RELEASE_NAME \\
                        --duration-min 30
                """
            }
        }

        stage('全量发布') {
            steps {
                sh """
                    helm upgrade $RELEASE_NAME ./deploy/chart \\
                        --namespace $K8S_NAMESPACE \\
                        --set canary.enabled=false \\
                        --set canary.trafficWeight=100
                """
            }
        }
    }

    post {
        failure {
            // 发布失败时回滚到上一个稳定版本
            sh "helm rollback $RELEASE_NAME"
        }
    }
}

3.4 冒烟测试和健康检查脚本的设计逻辑

冒烟测试不是简单地调一次接口就算完。我的脚本里至少包含这几项验证：

模型预热：发送一个空请求或短 prompt，确保模型完成初始化。预热请求的响应时间通常比正常请求长很多，所以脚本里要单独处理预热超时。
真实请求延迟：用正常业务 prompt 请求，验证 P50 延迟在预期范围内。如果超过阈值，说明镜像或推理引擎配置有问题。
返回结果格式：解析响应字段，验证输入输出结构与上游设计一致。
GPU 资源确认：通过 /metrics 接口查询 nvidia_gpu_memory_used_bytes 和 nvidia_smi_utilization_gpu，确认模型确实加载到了 GPU 上，而不是因为配置错误跑在 CPU 上（团队里真有人把 CUDA_VISIBLE_DEVICES 漏配了，服务能启动但性能差了百倍）。

健康检查脚本还要考虑一个关键点：探针检测和真正的推理请求必须走不同的通道。Kubernetes 的 HTTP 探针建议请求一个轻量的 /healthz 接口，这个接口只检查进程状态、模型是否完成加载、显存是否正常。真正的业务请求走 /infer 接口。不要让探针占用推理引擎的并发队列，否则在高峰期探针会挤掉真实请求。

4. Kubernetes 编排与发布策略的实战配置

4.1 Deployment 还是 StatefulSet

对推理服务，我最终选择了 Deployment 而不是 StatefulSet。

很多人可能会疑惑：推理服务不是“有状态”的吗？为什么不用 StatefulSet？原因是：推理服务的“状态”存放在模型仓库和对象存储里，Pod 本身是无状态的。模型文件在启动时从模型仓库拉取到本地临时目录，Pod 重建后重新拉取即可。Deployment 提供了滚动更新、副本管理、快速回滚等更成熟的机制，这些都更贴合推理服务的运维需求。

StatefulSet 适合的是那些节点身份需要稳定的场景，比如 Redis Cluster、ZooKeeper。推理服务没有这种需求，强行用 StatefulSet 反而提高了运维复杂度。

4.2 探针配置：让调度系统真正理解推理服务

这是整个部署里最容易踩坑的环节。常规配置如下：

yaml复制startupProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 30
  periodSeconds: 10
  timeoutSeconds: 2

readinessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 5
  periodSeconds: 10
  failureThreshold: 3

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 30
  failureThreshold: 6

startupProbe 是 Kubernetes 1.16 之后引入的，专门用于解决“启动时间长”的服务。它的机制是：启动探针失败时不会杀死容器，而是持续重试。只有启动探针成功后，存活探针和就绪探针才会开始工作。

这里有个关键坑：启动探针的 failureThreshold 必须覆盖最坏情况下的模型加载时间。比如模型加载可能需要 5 分钟，探针每 10 秒探测一次，那么 failureThreshold 至少设为 30（30 * 10s = 300s）。如果你的服务在启动阶段会自动重试下载模型，而网络波动导致下载重试时间拉长，探针超时次数不够，容器就会被杀掉，然后重新进入启动流程，形成死循环。

就绪探针的作用是控制流量接入。只有就绪探针返回成功后，Pod 才会被加入 Service 的 Endpoint 列表，流量才会被路由进来。对于推理服务，就绪探针还应该在显存即将耗尽、或推理队列堆积严重时返回失败，提示调度系统暂时不要向这个 Pod 发送新请求。

4.3 灰度发布：用流量权重控制风险

推理服务的灰度发布和普通 Web 服务有一个重要区别：你不能只看 HTTP 错误率，还要关注模型层面的质量指标，比如生成内容的长度、拒绝率、语义一致性。所以我的灰度策略是分层验证：

第一层：基础设施验证（发布后 0-5 分钟），检查 Pod 启动、模型加载、健康检查、GPU 指标是否正常。
第二层：业务质量验证（发布后 5-30 分钟），把金丝雀 Pod 的流量权重设为 5%，对比金丝雀版本与稳定版本的延迟、错误率、GPU 利用率、请求成功率。
第三层：模型效果验证（发布后 30 分钟以上），抽样对比金丝雀版本生成的回答质量。这个步骤对对话模型尤其重要，因为纯技术指标无法完全反映模型效果的变化。

技术实现上，我用 Ingress 的流量权重配置实现金丝雀。如果用的是 NGINX Ingress Controller，配置方式大致如下：

yaml复制apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: llm-chat-canary
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "5"
spec:
  rules:
  - host: infer.example.com
    http:
      paths:
      - path: /infer
        pathType: Prefix
        backend:
          service:
            name: llm-chat-canary-service
            port:
              number: 8080

注意金丝雀版本必须和稳定版本使用同一个 Service 名称吗？不需要，可以创建独立的 llm-chat-canary-service，通过 Ingress 的 canary 注解分流。NGINX Ingress 的 canary-weight 是按百分比分流的，流量到了网关层就直接按权重转发到金丝雀 Service。使用独立 Service 的好处是回滚时只需把 canary 注解移除或归零，稳定版本的服务完全不受影响。

4.4 弹性伸缩：GPU 指标驱动的 HPA

推理服务的弹性伸缩分为两个层面。一是容器副本的扩缩容，二是推理引擎内部并发度的调整。这两个层面必须协同，否则会出现“Pod 已经扩容了，但单个 Pod 内的推理引擎还在排队”的割裂情况。

HPA 的参考指标我建议用以下组合：

指标	建议阈值	说明
GPU 显存使用率	70%-80%	达到阈值触发扩容，防止 OOM
GPU 利用率	60%-70%	利用率高说明算力饱和，缩容时要结合显存考虑
推理请求队列长度	视引擎而定	队列堆积 = 处理能力不足，扩容信号
P95 推理延迟	依据业务要求	延迟过高说明副本能力不够

使用 Prometheus Adapter 把 GPU 指标暴露给 HPA 是一种常用做法。配置示例：

yaml复制apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: llm-chat-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: llm-chat
  minReplicas: 2
  maxReplicas: 8
  metrics:
  - type: Pods
    pods:
      metric:
        name: gpu_memory_used_bytes
      target:
        type: AverageValue
        averageValue: 70Gi
  - type: Pods
    pods:
      metric:
        name: inference_queue_length
      target:
        type: AverageValue
        averageValue: 32

HPA 扩容后，新 Pod 需要几十秒甚至几分钟完成模型加载。如果流量高峰在几秒内到达，扩容的速度是跟不上的。所以推理服务不能只依赖“被动扩容”，还需要“主动扩容”。我实际的做法是：

定时预留：分析业务流量，预测高峰时段，提前扩容到目标副本数。
请求排队上限：在推理服务适配层设置请求队列上限，队列满了直接返回 429，避免后端雪崩。不要让请求无限堆积，否则只是把延迟问题变成系统崩溃问题。
缩容冷却：设置 HPA 的 behavior.scaleDown.stabilizationWindowSeconds，比如 15 分钟，避免 GPU 利用率一波动就频繁缩容。缩容后释放的 GPU 资源也可以更快地留给新的扩容需求。

4.5 成本控制经验：GPU 资源不能“梭哈”

GPU 是昂贵资源，部署流程里必须考虑成本。我的经验有三条：

开启 GPU 共享：NVIDIA MPS（Multi-Process Service）或 MIG（Multi-Instance GPU）都能在物理 GPU 上切分出多个隔离实例。如果推理请求并发不高，可以让多个模型实例共享一块 GPU。MIG 更适合 A100/A800 这类大卡，MPS 方案适合小模型场景，实际效果取决于模型显存占用。
设置 CPU/内存资源限制：推理服务的主要算力来自 GPU，但 CPU 用于请求解析、Tokenize、结果后处理。为容器设置合理的 CPU 和内存 limit 可以防止某些业务异常导致整台节点资源耗尽。
模型加载缓存：同一模型有多个副本时，如果每个副本都从对象存储拉取并加载，浪费大量带宽和时间。可以在节点上用本地 SSD 和节点亲和策略做缓存，只对第一个副本做全量拉取，后续副本直接从共享卷或本机缓存加载。

5. 上线后绕不开的监控与常见故障排查

5.1 必须盯住的核心指标

部署自动化解决的是“发布”问题，上线后的“运行”问题需要监控体系来兜底。我把监控指标分为三类：

类别	指标	用途
资源类	GPU 利用率、显存使用量、GPU 温度、功率	判断算力是否饱和、是否接近显存上限
服务类	推理延迟（P50/P95/P99）、QPS、错误率、排队长度	判断服务是否健康、容量是否足够
业务类	生成内容长度、拒绝率、回退率	判断模型效果是否衰减、输入是否符合预期

这些指标统一通过 Prometheus 采集，Grafana 展示。告警规则我通常会设定三类级别：信息级（延迟小幅上升）、警告级（显存使用率超过 85%、错误率超过 5%）、严重级（Pod 频繁重启、GPU 显存 OOM、探针连续失败）。

5.2 故障一：容器被 OOM Killer 杀掉

现象：上线高峰期 Pod 频繁 CrashLoopBackOff，kubectl describe pod 显示容器被 OOM Kill。

根因：推理引擎初始化时分配的显存比模型理论占用高出不少。以 vLLM 为例，它默认会预留一部分 GPU 显存作为 KV Cache 和运行时缓冲，如果服务配置时没有显式限制显存上限，进程可能占用整张卡的全部显存，再加上服务端请求并发度过高，显存瞬间被打满，触发 OOM。

排查链路：第一反应是看 df -h 和系统内存，确认不是 RAM 问题；然后看 nvidia-smi，发现显存确实被占满；再查推理引擎日志，里面有“CUDA out of memory”的明确报错。最后确认是启动参数缺少显存限制导致。

修复方案：在推理引擎启动命令中加入显存上限参数。vLLM 可以用 --gpu-memory-utilization 0.85 限制最多使用 85% 的显存；Triton 则通过 --memory-limit 和模型配置里的 max_batch_size 来控制。同时把 HPA 的显存阈值调低到 70%，在接近上限之前完成扩容。

5.3 故障二：CUDA 运行时与宿主机驱动不兼容

现象：服务能启动，但推理请求时报错“CUDA error: no kernel image is available for execution on the device”。

根因：镜像里的 CUDA 版本和宿主机 NVIDIA 驱动版本不匹配。CUDA 的向下兼容规则是：镜像里的 CUDA 主版本不能高于驱动支持的版本。比如宿主机驱动是 470 系列（支持 CUDA 11.4 以下），镜像里却用了 CUDA 11.8 的运行时，即使容器能起来，真正执行 CUDA Kernel 时也会失败。

排查链路：nvidia-smi 看驱动版本；进入容器执行 nvcc --version 看 CUDA 运行时版本；对比两者是否匹配。这里有个坑：如果容器里没装 nvcc（编译工具链），只看运行时库版本会误判。正确做法是检查 libcudart.so 的版本，或者直接跑一个调用 CUDA 的最小测试程序。

修复方案：在流水线的模型元数据校验阶段，加上“宿主机驱动版本 ≥ 镜像 CUDA 要求”的自动检查。这个检查可以用 Kubernetes Node 的 label 实现：给节点打上驱动的 label，Deployment 的调度条件里也声明所需的 CUDA 版本，调度器会自动把 Pod 调度到满足要求的节点上。这样就不需要人工去核对每台机器的驱动版本了。

5.4 故障三：动态 Shape 导致 TensorRT 报错

现象：模型在本机跑得好好的，部署到生产后第一个请求就报“Assertion failed: (engine.getBindingDimensions()), input shape is invalid”。

根因：TensorRT 在转换模型时会固定输入的最小/最优/最大 shape。如果推理服务没有对输入做 Padding 或指定动态轴，实际请求的 shape 超出转换范围，就会报错。本地测试时输入长度恰好都在允许范围内，生产环境请求多样性一上来，问题就暴露了。

排查链路：对比本机测试请求和生产请求的输入 shape 分布；查看 TensorRT 转换时的 profile 配置；确认推理引擎调用时有没有显式设置 minShape、optShape、maxShape。

修复方案：在模型转换阶段就把动态 shape 范围定义好，转换配置和模型文件一起存到模型仓库。流水线里的模型校验阶段也要加上 shape 合法性检查，用一组边界输入（最短、最长、正常长度）来验证，不合格直接阻断发布。对文本模型来说，通常的做法是设置最大序列长度，如 2048 或 4096，并在适配层对超长输入做截断。

5.5 故障四：探针误杀导致发布失败

现象：发布新版本时，Pod 启动后 3-5 分钟里被多次重启，发布一直无法完成。

根因：存活探针配的是 TCP 端口检测。推理服务进程启动后、模型加载完成前，端口已经在监听。存活探针检测到端口通，认为进程存活，不需要处理。但就绪探针在模型加载完成前会返回失败，Kubernetes 会把 Pod 从 Endpoint 列表中移除，这是预期的。真正的问题在线程池或事件循环被阻塞时，TCP 检测依然“成功”，但服务实际无法响应业务请求。此时存活探针没有触发，就不会重启；而流量到达后全部超时。

排查链路：看 Pod 事件，发现不是 CrashLoop，而是 readiness probe 一直失败。再看服务日志，进程还活着但无法处理新请求，典型的线程池阻塞。查探针类型，发现是 TCP，无法反映应用层可用性。

修复方案：把所有探针改成 HTTP GET，指向 /healthz。这个接口内部检查模型加载状态、显存使用率、推理队列长度。队列堆积超过阈值或显存接近上限时返回非 200，让调度系统及时摘除流量。存活探针和就绪探针的用途必须区分：就绪探针管流量接入，存活探针管进程恢复。不要为了让探针“更严格”就随意调低存活探针的失败阈值，否则正常启动过程中的模型加载会被误杀。正确的做法是：启动探针搞定启动时长，就绪探针管业务可用性，存活探针只在进程僵死时才触发。

6. 最后分享两个实在的部署经验

第一，发布流程必须“可观测”。每次发布都要输出一份部署报告，包含模型版本、SHA256、推理引擎版本、镜像 Tag、环境变量、探针配置、压测结果、验证时间点。这样后期排查问题时，只需对照报告定位是哪个环节的变更导致的异常。我吃过亏：有一次线上模型回答质量突然下降，排查了很久才发现是发布时误用了上一版模型文件，原因是模型版本和镜像 Tag 的对应关系完全靠人工记录，没人核对 SHA256。

第二，自动化部署最大的收益不是“快”，而是“可复现”。手动部署即使成功十次，也无法保证第十一次不出错。自动化流程把每一次部署都固化成相同的步骤，让结果变得可预测、可重试、可回滚。我个人的体会是，不要一上来就追求全自动，先把手动部署步骤记录下来，逐条审视哪些能脚本化、哪些需要人判断，一步步推进。等流程稳定后，再考虑结合 AI Agent 做告警自动归因和发布失败自动回滚。那时候，你的系统才算真正具备了“自动部署”的基础。