从Notebook到生产：机器学习模型服务化落地全链路实践

1. 项目概述：这不是一次“部署”，而是一场从实验室到产线的系统性迁移

“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题里藏着太多被轻描淡写却重若千钧的词。“Notebook”不是指纸质本子，而是Jupyter里那个写着model.fit()、plt.show()、一切看起来都闪闪发光的交互式沙盒；“Production”也不是简单地把模型跑起来，而是它得在凌晨三点的订单洪峰里不掉链子，在客户上传模糊图片时给出稳定置信度，在数据库字段悄悄变更后仍能正确解析输入，在运维同事重启服务器后自动恢复服务，甚至在某天你休假时，它还在 quietly 处理着上万条实时风控请求。我做过27个从0到1落地的ML项目，其中19个卡在Part 2（模型训练完成）和Part 3（API封装）之间，真正走到Part 4并稳定运行超6个月的，只有8个。而这第4部分，恰恰是区分“AI玩具”和“AI资产”的分水岭。它不讲AUC有多高，只关心P99延迟是否压在120ms以内；不炫耀F1-score，只盯着日志里每小时出现几次KeyError: 'user_profile'；不谈Transformer结构多优雅，只问模型镜像体积能不能从1.8GB压到420MB以适配边缘网关。这篇内容面向的不是刚学完scikit-learn的新人，而是已经把模型调到满意、正对着Dockerfile发呆、被SRE同事微信轰炸“接口又503了”的实战者。它解决的核心问题很朴素：当你的模型不再只服务于你自己，而要成为业务流水线中一个可信赖、可监控、可回滚、可计费的环节时，你该亲手拧紧哪几颗螺丝？后面所有内容，都基于我在电商推荐、金融反欺诈、工业设备预测性维护三个垂直场景中踩过的坑、写的脚本、改过的K8s YAML、以及凌晨两点和值班工程师一起盯屏排查OOM的实录。

2. 整体设计思路：为什么必须放弃“一键部署”幻觉，转向分层治理架构

2.1 拒绝“Notebook即服务”的诱惑：从单点可靠到系统可靠

很多团队的第一反应是：把.ipynb文件用nbconvert转成Python脚本，再用Flask包一层，扔进Docker，docker run -p 5000:5000——完事。我试过，也上线过。结果呢？第一个月，模型API平均响应时间从180ms跳到420ms；第二周，因依赖库版本冲突导致特征工程模块静默失败，线上推荐列表变成随机播放；第三天，用户上传一张12MB的扫描件PDF，Flask直接OOM崩溃，整个服务不可用。问题出在哪？根本不在模型本身，而在于这种“单体式封装”把四个完全异构的系统强行焊死在一个进程里：数据加载层（I/O密集）、特征计算层（CPU密集）、模型推理层（GPU/CPU混合）、服务编排层（网络/并发）。它们对资源的需求、故障模式、扩缩容节奏、监控粒度全都不一样。就像把锅炉房、配电室、控制台和客服中心全塞进同一间玻璃房——温度一高，锅炉报警，配电跳闸，控制台黑屏，客服电话打爆，但你根本分不清是哪个环节先崩的。真正的生产级设计，必须做四层解耦：

1. 数据接入层（Ingestion Layer）：独立于模型服务，负责从Kafka/MySQL/S3拉取原始数据，做schema校验、缺失值标记、基础清洗，输出标准化的avro或parquet格式中间数据流。它挂了，模型服务照常处理缓存数据；它恢复，自动追平积压。
2. 特征服务层（Feature Serving Layer）：独立gRPC服务，提供get_features(user_id, timestamp)接口。所有特征计算逻辑（如“过去7天购买频次”、“实时设备温度滑动均值”）在此统一实现、版本化、缓存。模型服务只管调用，不碰SQL和窗口函数。
3. 模型服务层（Model Serving Layer）：这才是真正跑model.predict()的地方。它只接收已对齐的特征向量，返回结构化预测结果（含prediction,confidence,explanation）。支持多模型热切换（A/B测试）、GPU显存隔离、请求队列深度控制。
4. API网关层（API Gateway Layer）：统一入口，负责认证鉴权（JWT/OAuth2）、限流熔断（QPS/并发数/错误率）、请求/响应转换（JSON ↔ Protobuf）、灰度路由（按Header或User ID分流）、审计日志。它不碰业务逻辑，只做流量治理。

这四层不是理论空想。我在某银行反欺诈项目里，把原来3000行混杂的Flask代码，按此拆分为4个独立服务，部署在K8s不同命名空间，用Istio做服务网格。结果：单点故障率下降76%，横向扩容响应时间从15分钟缩短至47秒，新模型上线从“停服发布”变为“无感热更”。关键不是技术多炫，而是每个层都有明确的SLO（Service Level Objective）：数据接入层P99延迟<200ms，特征服务P99<50ms，模型服务P99<80ms，网关层错误率<0.1%。目标清晰，责任到人，故障定位时间从小时级降到分钟级。

2.2 为什么选Kubernetes而非纯Docker Compose？真实成本算给你看

常有人问：“我们小团队，就3个模型，用Docker Compose不行吗？”行，当然行。但你要算清三笔隐性成本：

第一笔：资源碎片化成本
Docker Compose启动N个容器，每个容器都预分配内存（比如-m 2g），但实际峰值可能只用800MB。10个服务，理论需20GB内存，实际峰值仅12GB，浪费40%。K8s的ResourceQuota+LimitRange+HorizontalPodAutoscaler能动态调度。我们在一个边缘计算节点（16GB RAM）上，通过K8s调度，同时稳稳跑着3个CV模型（YOLOv5s、ResNet18、MobileNetV2），总内存占用始终控制在14.2GB内，Compos无法做到这点。

第二笔：发布风险成本
docker-compose up -d是全量重启。哪怕你只改了一个模型的权重文件，整个服务栈（包括网关、特征服务）都要重启。我们曾因此导致5分钟全站风控失效。K8s的RollingUpdate策略，配合readinessProbe（检查/healthz端点）和livenessProbe（检查/livez端点），能确保新Pod就绪后再切流量，旧Pod确认无请求才销毁。一次模型更新，业务无感。

第三笔：可观测性建设成本
Compos的日志是docker logs -f，指标是docker stats，链路追踪要自己埋点。K8s原生集成Prometheus（指标）、Loki（日志）、Tempo（链路），且所有组件（Pod、Service、Ingress）都有标准标签（app.kubernetes.io/name: model-service）。我们用Grafana搭了个Dashboard，一页看尽：模型QPS、P99延迟热力图、GPU显存使用率曲线、各Pod重启次数排行榜、慢查询TOP10（由OpenTelemetry自动注入）。这页Dashboard，是SRE和算法同学每天晨会必看的“作战地图”。

所以，K8s不是为“大厂”准备的奢侈品，而是为“不想半夜被叫醒修API”的务实选择。它的学习曲线确实陡峭，但当你第5次因为pip install版本冲突导致服务崩溃时，你会感谢当初花两周啃完《Kubernetes in Action》的自己。

2.3 模型服务框架选型：为什么最终放弃TensorFlow Serving，拥抱Triton Inference Server

选型不是比参数，而是比“谁最懂你的痛点”。我们对比了TF Serving、TorchServe、KServe（原KFServing）和NVIDIA Triton：

决定性一击来自一个真实场景：工业设备预测性维护项目。我们需要同时运行3个模型：一个轻量级LSTM（预测轴承温度趋势）、一个中等ResNet（分析红外热成像图）、一个重型ViT（处理高清设备外观图）。TF Serving要求每个模型独占GPU，一块A10（24GB显存）只能跑1个ViT；Triton通过dynamic_batching和model_control_mode: "explicit"，让3个模型共享显存，ViT用16GB，ResNet用5GB，LSTM用1GB，总占用21.3GB，显存利用率从33%提升到89%。更关键的是，Triton的ensemble功能，让我们能把“图像预处理→ViT推理→结果后处理”串成一个逻辑模型，对外暴露单一API，内部自动调度，省去我们自己写胶水代码。现在，我们的Triton配置文件config.pbtxt里，一行dynamic_batching { max_queue_delay_microseconds: 100000 }，就把P99延迟从320ms压到78ms。这不是魔法，是NVIDIA工程师把GPU调度玩到了极致。

3. 核心细节与实操要点：从Dockerfile到K8s Manifest的每一处魔鬼细节

3.1 Dockerfile：为什么基础镜像选nvidia/cuda:11.8.0-devel-ubuntu22.04而非python:3.9-slim

很多人图省事，用python:3.9-slim作为base image，pip install一堆包。结果呢？镜像体积轻松破1.5GB，构建时间长，且slim版缺少glibc、libstdc++等底层库，某些C扩展（如faiss-cpu、lightgbm）运行时报Symbol not found。我们最终锁定nvidia/cuda:11.8.0-devel-ubuntu22.04，理由硬核：

• CUDA版本锁死：项目用PyTorch 2.0.1，官方只支持CUDA 11.7/11.8。用11.8 base，pip install torch==2.0.1+cu118能直接装预编译wheel，无需源码编译（编译一次耗时23分钟）。
• Ubuntu 22.04 LTS：内核5.15，对NVMe SSD I/O优化好，dd if=/dev/zero of=test bs=1M count=1000 oflag=direct实测顺序写入比18.04快17%。特征服务频繁读取Parquet文件，I/O就是生命线。
• devel版含完整toolchain：gcc-11,cmake,make全预装，pip install遇到需要编译的包（如pyarrow），不用再apt-get install一堆依赖。

我们的Dockerfile严格遵循多阶段构建（Multi-stage Build），分三层：

# 构建阶段：纯净环境，只装编译依赖 FROM nvidia/cuda:11.8.0-devel-ubuntu22.04 AS builder RUN apt-get update && apt-get install -y \ python3.10-dev \ python3.10-venv \ libpq-dev \ libjpeg-dev \ zlib1g-dev \ && rm -rf /var/lib/apt/lists/* COPY requirements.txt . RUN python3.10 -m venv /opt/venv && \ /opt/venv/bin/pip install --upgrade pip && \ /opt/venv/bin/pip install -r requirements.txt # 运行阶段：极简镜像，只复制编译好的包 FROM nvidia/cuda:11.8.0-runtime-ubuntu22.04 # 复制venv，而非重新pip install COPY --from=builder /opt/venv /opt/venv ENV PATH="/opt/venv/bin:$PATH" # 创建非root用户，安全基线 RUN groupadd -g 1001 -r mluser && useradd -r -u 1001 -g mluser mluser USER mluser # 复制应用代码 COPY --chown=mluser:mluser src/ /app/ WORKDIR /app # 健康检查 HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \ CMD curl -f http://localhost:8000/v2/health/ready || exit 1 CMD ["tritonserver", "--model-repository=/models", "--http-port=8000", "--grpc-port=8001"]

关键点：

• --chown=mluser:mluser：避免root权限写入，满足PCI-DSS审计要求；
• HEALTHCHECK：用Triton原生/v2/health/ready端点，比curl http://localhost:8000更精准（后者只检查HTTP server，前者检查模型加载状态）；
• CMD不加--model-control-mode=explicit：留待K8s Deployment里通过args注入，便于不同环境差异化配置。

3.2 Triton模型仓库结构：如何组织config.pbtxt让多版本管理不翻车

Triton的模型仓库（--model-repository）不是随便放个.pt文件就行。必须严格遵循层级：

/models ├── fraud_detector │ ├── 1 │ │ ├── model.py # Python backend自定义逻辑 │ │ └── config.pbtxt │ ├── 2 │ │ ├── model.onnx │ │ └── config.pbtxt │ └── config.pbtxt # Ensemble配置 ├── feature_encoder │ └── 1 │ ├── model.pt │ └── config.pbtxt └── ensemble_recommender └── 1 └── config.pbtxt # 定义fraud_detector + feature_encoder串联

config.pbtxt是灵魂。以fraud_detector/2/config.pbtxt为例：

name: "fraud_detector" platform: "onnxruntime_onnx" max_batch_size: 128 input [ { name: "input_ids" data_type: TYPE_INT64 dims: [ -1 ] }, { name: "attention_mask" data_type: TYPE_INT64 dims: [ -1 ] } ] output [ { name: "output" data_type: TYPE_FP32 dims: [ 2 ] } ] dynamic_batching [ # 关键！开启动态批处理 { max_queue_delay_microseconds: 100000 # 最大排队100ms，平衡延迟与吞吐 } ] instance_group [ # GPU实例分组 { count: 2 # 启动2个实例，充分利用A10的2个GPC kind: KIND_GPU } ]

血泪教训：max_batch_size不能设太大。我们曾设为1024，结果单个大请求（batch=1024）进来，GPU显存瞬间打满，后续所有小请求排队，P99飙升。128是经过压测的甜点值：吞吐够用，单请求延迟可控。max_queue_delay_microseconds更是玄学，100000（100ms）是我们用locust模拟1000QPS时，P95延迟<80ms的临界点。低于它，吞吐降；高于它，延迟升。没有银弹，只有压测。

3.3 K8s Deployment：如何用resource和affinity把模型钉死在GPU节点

Deployment不是写完就完。关键在resources和affinity：

apiVersion: apps/v1 kind: Deployment metadata: name: triton-fraud-detector spec: replicas: 2 selector: matchLabels: app: triton-fraud-detector template: metadata: labels: app: triton-fraud-detector spec: # 关键1：GPU节点亲和性 affinity: nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: nvidia.com/gpu.present operator: Exists # 关键2：精确资源请求 containers: - name: triton image: your-registry/triton-fraud:2.24.0 resources: limits: nvidia.com/gpu: 1 # 严格限制1块GPU memory: 4Gi cpu: "2" requests: nvidia.com/gpu: 1 memory: 3.5Gi # request < limit，防OOM killer误杀 cpu: "1.5" # 关键3：GPU设备插件 env: - name: NVIDIA_VISIBLE_DEVICES value: "all" # 关键4：健康探针 livenessProbe: httpGet: path: /v2/health/live port: 8000 initialDelaySeconds: 60 periodSeconds: 30 readinessProbe: httpGet: path: /v2/health/ready port: 8000 initialDelaySeconds: 45 periodSeconds: 15 timeoutSeconds: 5

为什么requests.memory: 3.5Gi？因为Triton自身进程约占用800MB，模型加载后（ONNX Runtime）约占用2.7GB，留200MB余量防突发。initialDelaySeconds设为45秒，是因为大型ONNX模型加载需30~40秒，太短会导致Readiness Probe失败，K8s反复重启Pod。这些数字，全是kubectl describe pod看Events、kubectl top pod看实时资源、nvidia-smi看GPU占用，一点一点抠出来的。

4. 实操全流程：从本地验证到灰度发布的7个关键步骤

4.1 步骤1：本地Docker验证——用docker run跑通最小闭环

别急着上K8s。先在本地Mac/Windows（用WSL2）验证Docker镜像能否跑通：

# 1. 构建镜像 docker build -t triton-fraud:local . # 2. 启动Triton，挂载本地模型仓库 docker run --gpus all -p 8000:8000 -p 8001:8001 \ -v $(pwd)/models:/models \ --shm-size=1g \ triton-fraud:local # 3. 用curl测试健康状态 curl http://localhost:8000/v2/health/ready # 应返回{} # 4. 用tritonclient Python SDK测试推理 pip install tritonclient[all] python -c " import tritonclient.http as httpclient client = httpclient.InferenceServerClient(url='localhost:8000') print(client.is_model_ready('fraud_detector', '2')) "

注意：--shm-size=1g至关重要！Triton用共享内存（Shared Memory）加速GPU-CPU数据传输，不设此参数，大模型推理会报Failed to create CUDA shared memory region。这是90%新手卡住的第一步。

4.2 步骤2：压力测试——用locust找出真实瓶颈

本地跑通不等于生产可用。用locust模拟真实流量：

# locustfile.py from locust import HttpUser, task, between import json import numpy as np class TritonUser(HttpUser): wait_time = between(0.1, 0.5) # 每秒2-10请求 @task def predict_fraud(self): # 构造真实业务请求体 payload = { "inputs": [ { "name": "input_ids", "shape": [1, 128], "datatype": "INT64", "data": np.random.randint(0, 1000, size=(1,128)).tolist() }, { "name": "attention_mask", "shape": [1, 128], "datatype": "INT64", "data": np.ones((1,128), dtype=int).tolist() } ] } self.client.post("/v2/models/fraud_detector/infer", json=payload, headers={"Content-Type": "application/json"})

启动：locust -f locustfile.py --host=http://localhost:8000 --users 100 --spawn-rate 10。观察：

• Triton日志里的Request rate和Inference rate是否匹配？
• nvidia-smi里GPU Util%是否持续>85%？若<60%，说明CPU或网络是瓶颈；
• kubectl top pod里内存是否缓慢上涨？若有，检查Python backend是否有全局变量缓存未释放。

我们曾发现，一个@lru_cache(maxsize=1000)装饰的特征编码函数，在高并发下缓存膨胀，内存泄漏。locust一压，10分钟Pod OOM。这就是本地验证无法发现的“时间维度”问题。

4.3 步骤3：K8s部署——用Helm Chart统一管理

手写YAML易出错。我们用Helm管理Triton部署：

# 创建chart helm create triton-model # 修改templates/deployment.yaml，注入上面的Deployment模板 # values.yaml里定义可变参数： replicaCount: 2 image: repository: your-registry/triton-fraud tag: "2.24.0" gpuCount: 1 modelRepo: "gs://your-bucket/models" # 支持GCS/S3

部署命令一行搞定：

helm upgrade --install triton-fraud ./triton-model \ --set image.tag=2.24.0 \ --set gpuCount=1 \ --set modelRepo="s3://my-bucket/models" \ --set-file extraConfig=config.pbtxt # 覆盖默认config

Helm的价值在于：一次定义，多环境复用。开发环境用--set gpuCount=0跑CPU版；测试环境用--set replicaCount=1；生产环境用--set gpuCount=1 --set replicaCount=2。所有差异都在values.yaml里，GitOps友好。

4.4 步骤4：API网关接入——用Istio VirtualService做灰度路由

模型服务跑起来了，但不能直接暴露给业务方。用Istio做网关：

# virtualservice.yaml apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: fraud-api spec: hosts: - "api.yourcompany.com" http: - match: - headers: x-deployment: # 业务方在Header里传 exact: "v2" # 指定用v2模型 route: - destination: host: triton-fraud-detector.default.svc.cluster.local subset: v2 weight: 100 - route: # 默认路由到v1 - destination: host: triton-fraud-detector.default.svc.cluster.local subset: v1 weight: 100 --- # DestinationRule定义subsets apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: triton-fraud-dr spec: host: triton-fraud-detector.default.svc.cluster.local subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2

业务方只需在请求头加x-deployment: v2，流量就切到新模型。我们用这招做了7次A/B测试，零停机。subset标签对应Deployment里的version: v2label，K8s和Istio无缝联动。

4.5 步骤5：监控告警——用Prometheus Rule盯住3个黄金信号

Triton原生暴露/metrics端点（Prometheus格式）。我们只盯3个指标：

1. nv_gpu_duty_cycle> 95% 持续5分钟→ GPU过载，需扩容或优化模型；
2. triton_inference_request_success{model="fraud_detector"} == 0持续1分钟→ 模型加载失败，立即触发PagerDuty；
3. triton_inference_queue_length{model="fraud_detector"} > 100持续2分钟→ 请求积压，可能是下游特征服务慢，或上游流量突增。

Prometheus Rule示例：

groups: - name: triton-alerts rules: - alert: TritonModelLoadFailed expr: triton_inference_request_success{model="fraud_detector"} == 0 for: 1m labels: severity: critical annotations: summary: "Triton model {{ $labels.model }} failed to load" - alert: TritonQueueBacklog expr: triton_inference_queue_length{model="fraud_detector"} > 100 for: 2m labels: severity: warning annotations: summary: "Triton queue backlog for {{ $labels.model }}"

这些规则，比“CPU使用率>80%”有用100倍。因为它们直接关联业务SLA。

4.6 步骤6：日志分析——用Loki+LogQL定位KeyError根源

模型报错KeyError: 'user_profile'，但日志里只有500 Internal Server Error。用Loki查：

{job="triton"} |~ `KeyError.*user_profile` | line_format "{{.log}}"

结果发现，错误全发生在user_id以test_开头的请求里。顺藤摸瓜，查特征服务日志：

{job="feature-service"} |~ `user_id.*test_` | json | __error__ != ""

定位到特征服务一个硬编码逻辑：if user_id.startswith('test_'): return {}，导致user_profile字段为空字典。修复后，KeyError归零。Loki的| json解析和|~正则，让日志从“大海捞针”变成“精准定位”。

4.7 步骤7：回滚机制——用K8s Rollout History一键退回到v1

任何发布都必须有回滚预案。K8s原生支持：

# 查看历史版本 kubectl rollout history deployment/triton-fraud-detector # 回滚到上一版本 kubectl rollout undo deployment/triton-fraud-detector # 回滚到指定版本（revision=3） kubectl rollout undo deployment/triton-fraud-detector --to-revision=3

我们把这条命令写进发布Checklist，并在CI/CD流水线里加一道门禁：每次发布前，自动执行kubectl rollout history并截图存档。真出问题时，30秒回滚，比解释“为什么出问题”重要100倍。

5. 常见问题与排查技巧实录：那些文档里不会写的“脏活累活”

5.1 问题1：Triton启动报错Failed to load 'fraud_detector' version 2: Internal: unable to get model configuration

现象：kubectl logs里反复出现此错误，/v2/models返回空列表。

排查路径：

1. 进入Pod：kubectl exec -it <pod-name> -- bash
2. 检查模型路径：ls -l /models/fraud_detector/2/→ 发现model.onnx权限是-rw-------，属主是root，而Triton进程以mluser运行，无读取权限。
3. 修复：在Dockerfile里加RUN chmod 644 /models/fraud_detector/2/model.onnx

根因：COPY指令保留源文件权限。解决方案：构建时chmod，或用COPY --chown=mluser:mluser。

5.2 问题2：P99延迟忽高忽低，从50ms跳到800ms

现象：Grafana Dashboard上，延迟曲线呈锯齿状，无规律。

排查路径：

1. kubectl top pod看内存：发现内存使用率缓慢爬升，从3.5Gi到4Gi（limit），然后Pod被OOMKilled，重启。
2. kubectl describe pod看Events：OOMKilled。
3. 检查config.pbtxt：max_batch_size: 128没错，但dynamic_batching没开！
4. 修复：在config.pbtxt里加上dynamic_batching []，重启。

根因：未开启动态批处理，每个请求都单独推理，GPU显存碎片化严重，触发Linux OOM Killer。开dynamic_batching后，请求自动合并，显存利用率稳定在75%，延迟锯齿消失。

5.3 问题3：特征服务返回None，但日志无报错

现象：模型服务日志显示input features is None，特征服务日志平静如水。

排查路径：

1. 特征服务是gRPC，用grpcurl直连测试：

   grpcurl -plaintext -d '{"user_id":"12345"}' localhost:8080 feature.FeatureService/GetFeatures

2. 返回{"features": null}，确认是特征服务问题。
3. 查特征服务代码，发现一个try...except块里，except分支直接return None，且没打日志。
4. 修复：except Exception as e: logger.error(f"GetFeatures failed for {user_id}: {e}"); raise

根因：静默失败是生产环境最大杀手。所有except必须打ERROR日志，且raise或返回明确错误码。

5.4 问题4：新模型上线后，准确率下降15%

现象：A/B测试显示v2模型AUC从0.92降到0.77。

排查路径：

1. 对比v1和v2的输入特征分布：用pandas-profiling生成报告，发现v2的transaction_amount字段，v1里是float64，v2里是int64（因上游数据源变更）。
2. 检查模型训练代码：v2训练时用了astype(int)，但推理时没做同样转换，导致数值溢出。
3. 修复：在特征服务里，对transaction_amount统一做astype(float)。

根因：训练-推理不一致（Training-Serving Skew）。解决方案：特征服务必须是唯一真相源，训练数据也必须从特征服务离线导出，而非直接读数据库。

5.5 问题5：K8s集群升级后，Triton Pod一直ContainerCreating

现象：kubectl get pods显示Pending，kubectl describe pod里Events有Failed to bind volumes: timed out waiting for the condition。

排查路径：

1. kubectl get pv,pvc→ PVC状态Bound，但PV的StorageClass是gp2（AWS EBS），而新集群用gp3。
2. kubectl get sc→gp2不存在。
3. 修复：修改PVC的storageClassName: gp3，或创建gp2StorageClass指向gp3。

根因：云厂商K8s升级常变更默认StorageClass。解决方案：所有PVC显式声明storageClassName，不依赖default。

提示：所有上述问题，我们都整理成Checklist，放在Confluence。每次发布前，运维和算法同学一起过一遍，15分钟搞定。经验不是写在PPT里，是刻在Checklist上的。

6. 经验总结：那些让我少熬200小时夜的硬核习惯

最后分享几个不写在任何官方文档里，但让我在深夜接到告警电话时，能3分钟定位、5分钟修复的硬核习惯：

习惯1：永远在模型服务里内置/debug/dump_state端点
这个端点返回当前加载的所有模型名、版本、状态（READY/UNAVAILABLE）、GPU显存占用、最近10次推理的输入shape和耗时。不用kubectl exec进容器，curl http://pod-ip:8000/debug/dump_state，一眼看清全局。代码就10行Python，但价值远超1000行监控脚本。

**习惯2：用git bisect定位“突然变慢