企业官网建设流程全解析

1. 项目概述：当模型走出Jupyter，真正开始呼吸真实世界空气

“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题里藏着一个被无数数据科学家反复咀嚼、又悄悄咽下的苦涩真相：我们花了80%的时间调参、画图、在Jupyter里把准确率从92.3%刷到92.7%，却只留20%的精力（甚至更少）去思考——当模型明天就要接入订单系统、要扛住双十一流量峰值、要每天凌晨三点自动重训并报警、要让运维同事不用查Python文档就能重启服务时，它到底该长成什么样子？Part 4不是技术演进的序号，而是实战压力测试的临界点。它意味着你已经走过了数据清洗（Part 1）、特征工程（Part 2）、模型选型与验证（Part 3），现在必须直面那个没人愿意深聊但决定项目生死的问题：模型如何脱离笔记本的温床，在没有IDE、没有pip install权限、没有print()调试窗口的真实生产环境里，稳定、可观测、可维护地持续运行？这不是“部署”两个字能概括的轻量动作，而是一场涉及工程规范、基础设施认知、跨团队协作习惯和故障响应肌肉记忆的系统性迁移。我带过三支不同行业的ML落地团队，从金融风控到工业设备预测性维护，踩过的坑几乎一模一样：模型API返回500错误，日志里只有一行ModuleNotFoundError: No module named 'xgboost'；A/B测试流量切过去后，延迟从120ms飙到2.3s，监控面板一片红色，但没人知道是模型推理慢了，还是下游数据库连接池耗尽；更常见的是，业务方说“上个月效果很好”，而你翻完所有指标才发现——训练数据源上周被上游改了字段类型，模型还在用string当float喂进去。Part 4的核心，从来不是“怎么把pkl文件扔进Docker”，而是建立一套让机器学习模型像数据库、像Nginx一样，被当作标准基础设施来对待、来管理、来问责的工程化契约。它要求你放下“算法专家”的身份，戴上“SRE+DevOps+业务翻译官”的三重头盔。这篇文章不讲理论，只讲我在产线服务器机柜前、在凌晨三点的告警电话里、在和运维老张第7次对齐部署清单时，亲手写下的每一条操作指令、每一个配置参数、每一处血泪注释。

2. 核心设计思路拆解：为什么放弃“一键部署”，选择“分层契约式交付”

2.1 拒绝“黑盒打包”：从模型即服务（MaaS）到模型即契约（MaaC）

很多团队在Part 4卡住，根源在于把“部署”误解为“打包”。他们用joblib.dump()保存模型，写个Flask API封装，再套一层Docker，就以为完成了。结果上线三天，运维同事发来截图：容器内存占用98%，top命令里python进程占满CPU，但API响应时间反而越来越长。问题出在哪？——他们交付的不是一个“服务”，而是一个“黑盒谜题”。运维不知道模型依赖哪些C库版本，不知道推理时GPU显存分配策略，更不知道模型加载时会读取哪个路径下的配置文件。Part 4的设计起点，必须是契约先行。我把它定义为“Model as a Contract”（MaaC），即模型交付物必须包含四份不可分割的契约文件：

• 接口契约（Interface Contract）：明确声明输入/输出的JSON Schema，包括字段名、类型、是否必填、取值范围。例如，风控模型的输入契约必须规定"income": {"type": "number", "minimum": 0, "maximum": 1000000}，而非模糊的“传入用户收入”。这直接决定了API网关能否做前置校验，避免无效请求打穿模型层。

• 资源契约（Resource Contract）：精确声明运行时资源需求。不是“需要GPU”，而是“需要NVIDIA T4，显存≥16GB，CUDA 11.2，cuDNN 8.1.0”；不是“内存够用就行”，而是“常驻内存≤1.2GB，峰值内存≤2.8GB，启动时预分配显存1.5GB”。这份契约由nvidia-smi实测+psutil压测生成，写进Kubernetes的resources.requests/limits，让调度器不再猜谜。

• 行为契约（Behavior Contract）：定义模型在非理想状态下的应答逻辑。例如，“当特征缺失率>5%时，返回HTTP 422 + 错误码FEATURE_SPARSE，而非抛出KeyError”；“当GPU不可用时，自动降级至CPU模式，但响应延迟超过800ms时触发告警”。这要求在代码里硬编码熔断逻辑，而非依赖框架默认异常。

• 可观测契约（Observability Contract）：规定必须暴露的指标端点及格式。例如，“/metrics端点必须返回Prometheus格式，包含model_inference_latency_seconds_bucket（直方图）、model_cache_hit_ratio（Gauge）、model_version_info（Info）”。没有这个契约，监控系统就是瞎子。

提示：契约文件不是文档，而是可执行的校验脚本。我团队用jsonschema校验接口契约，用kubectllint检查资源契约YAML，用pytest跑行为契约的边界测试用例。每次CI流水线运行，先验证契约合规性，再构建镜像——契约不通过，代码禁止合并。

2.2 分层解耦：为什么坚持“模型核心”、“服务框架”、“基础设施”三者物理隔离

曾有个项目，算法同学把整个训练Pipeline（含数据下载、特征计算、模型训练、评估）全塞进一个Flask应用里，还自豪地说“端到端自动化”。上线后，运维发现每次模型更新都要重启整个服务，导致API中断3分钟；更糟的是，当上游数据源临时不可用时，Flask进程因requests.get()超时卡死，所有推理请求排队阻塞。Part 4的架构铁律是：模型核心（Model Core）必须是纯函数，零IO、零网络、零状态。它只做一件事：接收结构化输入，返回结构化输出。所有外部依赖（数据拉取、缓存读写、日志上报）必须剥离到服务框架层（Service Framework）。

我强制推行三层物理隔离：

• 模型核心层（Core Layer）：仅包含.py文件，定义predict(input: dict) -> dict函数。依赖库严格锁定（如scikit-learn==1.2.2），禁用任何import requests或open()。模型文件（.pkl,.onnx）作为只读资源挂载，不参与代码构建。这样做的好处是：模型可被任意框架加载（FastAPI、Triton、甚至C++推理引擎），且版本回滚只需替换挂载的模型文件，无需重建镜像。

• 服务框架层（Framework Layer）：用FastAPI实现，职责清晰：接收HTTP请求→按接口契约校验→调用模型核心→按行为契约处理异常→记录可观测指标→返回响应。框架层管理所有外部交互：用redis-py连接缓存，用prometheus-client暴露指标，用structlog统一日志格式。关键点在于，框架层代码与模型核心完全解耦，模型更新时，框架层镜像复用，极大缩短发布周期。

• 基础设施层（Infra Layer）：由Kubernetes Helm Chart定义，声明资源契约、健康检查探针、自动扩缩容策略。例如，livenessProbe指向/healthz（检查模型加载状态），readinessProbe指向/readyz（检查Redis连接），hpa基于model_inference_latency_seconds指标自动扩容。这一层与业务逻辑彻底无关，由平台团队统一维护。

这种分层不是为了炫技，而是为了责任切割。当API变慢时，运维看基础设施层日志（CPU/内存/网络）；开发看服务框架层日志（请求链路追踪）；算法看模型核心层指标（单次推理耗时分布）。三方各执一词的局面，从此终结。

2.3 拒绝“静态快照”：为什么必须将模型版本、数据版本、代码版本三者强绑定

Part 3的模型验证报告里写着“AUC=0.92”，但Part 4上线后业务方反馈“效果下降”。排查发现：验证用的是2023年Q3的数据快照，而生产环境实时拉取的是2024年Q1的数据，期间上游埋点逻辑变更，导致关键特征user_session_duration的统计口径从“秒”变成了“毫秒”，模型输入值放大1000倍。这是典型的“数据漂移”（Data Drift），但根子在版本管理失控。

我的解决方案是三版本原子提交（Tri-atomic Commit）：每次模型上线，必须同时提交三个版本标识，并写入同一份部署清单（Deployment Manifest）：

• 模型版本（Model Version）：由MLflow或自建模型仓库生成，如model-v3.2.1，包含模型文件哈希、训练参数、验证指标。

• 数据版本（Data Version）：指向特征存储（Feature Store）中的快照ID，如feature-snapshot-20240515-1422，该快照固化了所有特征计算逻辑及原始数据时间范围。

• 代码版本（Code Version）：Git Commit Hash，精确到服务框架层和模型核心层的代码。

部署脚本（如Ansible Playbook）在启动容器时，强制校验三者匹配：

# 启动前校验脚本片段 if [ "$(cat /app/MODEL_VERSION)" != "$MODEL_VERSION_ENV" ]; then echo "模型版本不匹配！期望$MODEL_VERSION_ENV，实际$(cat /app/MODEL_VERSION)" exit 1 fi # 同理校验DATA_VERSION和CODE_VERSION

注意：版本标识不能写死在代码里。我要求所有版本号通过环境变量注入容器，由CI/CD流水线在构建时写入。这样，同一个镜像可部署到不同环境（staging/prod），只需切换环境变量即可，杜绝“改一行代码就要重新构建镜像”的低效操作。

3. 核心细节解析与实操要点：从契约到代码的每一处魔鬼细节

3.1 接口契约的落地：用OpenAPI 3.0生成可执行的请求校验器

接口契约不能停留在Swagger UI页面上。我要求所有模型API必须提供openapi.json，且该文件必须由代码自动生成，而非手工编写。工具链是：pydantic定义数据模型 →fastapi自动生成OpenAPI →openapi-spec-validator校验合规性 →openapi-diff检测向后兼容性变更。

具体步骤：

1. 用Pydantic定义输入/输出Schema：

from pydantic import BaseModel, Field, validator from typing import List, Optional class PredictionInput(BaseModel): user_id: str = Field(..., min_length=1, max_length=32, description="用户唯一标识") features: List[float] = Field(..., min_items=10, max_items=10, description="10维特征向量") @validator('features') def features_must_be_normalized(cls, v): if not all(-1.0 <= x <= 1.0 for x in v): raise ValueError('所有特征值必须在[-1.0, 1.0]范围内') return v class PredictionOutput(BaseModel): prediction: float = Field(..., ge=0.0, le=1.0, description="预测概率") confidence: float = Field(..., ge=0.0, le=1.0, description="置信度")

2. FastAPI自动挂载：

from fastapi import FastAPI, HTTPException from starlette.status import HTTP_422_UNPROCESSABLE_ENTITY app = FastAPI( title="风控模型API", openapi_url="/openapi.json", # 自动生成OpenAPI文档 ) @app.post("/predict", response_model=PredictionOutput) def predict(input_data: PredictionInput): # Pydantic自动校验 try: result = model_core.predict(input_data.dict()) return result except ModelValidationError as e: # 自定义异常 raise HTTPException( status_code=HTTP_422_UNPROCESSABLE_ENTITY, detail={"error_code": "MODEL_VALIDATION_ERROR", "message": str(e)} )

3. CI流水线强制校验：

# .gitlab-ci.yml 片段 stages: - validate validate-openapi: stage: validate script: - pip install openapi-spec-validator - curl -s http://localhost:8000/openapi.json > openapi.json - openapi-spec-validator openapi.json # 校验语法 - openapi-diff openapi-staging.json openapi-prod.json --fail-on-incompatible # 检测破坏性变更

实操心得：Pydantic的@validator装饰器是接口契约的终极武器。它把业务规则（如“特征值必须归一化”）直接编译进校验逻辑，比在模型内部做if判断更早拦截错误，且错误信息可直接透传给调用方。我见过太多团队在模型里写if x < 0: x = 0，结果业务方传入负数却得不到明确报错，只能靠猜。

3.2 资源契约的量化：如何用压测数据反推Kubernetes资源配置

资源契约不是拍脑袋写的。我坚持用真实压测数据驱动配置。流程分三步：

第一步：基准压测（Baseline Load Test）
用locust模拟100并发请求，持续5分钟，记录psutil.Process().memory_info().rss（常驻内存）和nvidia-smi --query-gpu=memory.used --format=csv,noheader,nounits（显存占用）。关键指标：

• 常驻内存：进程启动后稳定值（非峰值）
• 显存占用：模型加载后稳定值（非推理峰值）
• CPU使用率：psutil.cpu_percent(interval=1)，取中位数

第二步：峰值压测（Peak Load Test）
将并发提升至预期峰值（如电商大促的5000QPS），用wrk压测，记录：

• 单请求P95延迟（wrk -t10 -c100 -d30s http://localhost:8000/predict）
• 内存/显存峰值（psutil和nvidia-smi每秒采样）
• 错误率（HTTP 5xx占比）

第三步：配置反推（Configuration Derivation）
根据压测数据，按以下公式计算Kubernetes资源配置：

注意：requests和limits必须严格区分。requests是调度器分配资源的依据，limits是cgroup限制的硬上限。若requests设得太低，Pod可能被调度到资源不足的节点；若limits设得太高，可能抢占过多资源导致其他Pod被驱逐。我团队的黄金法则是：limits.memory≤requests.memory× 2.5，确保OOM Killer不会轻易杀死你的进程。

3.3 行为契约的编码：在模型核心里写“防御性推理”

行为契约要求模型核心具备自我保护能力。这不是框架的事，是算法工程师的代码责任。我在模型核心层强制植入三类防御逻辑：

1. 输入鲁棒性校验（Input Robustness）

import numpy as np from typing import Dict, Any def predict(input_dict: Dict[str, Any]) -> Dict[str, float]: # 1. 字段存在性校验 required_fields = ['user_id', 'features'] missing = [f for f in required_fields if f not in input_dict] if missing: raise ModelValidationError(f"缺少必需字段: {missing}") # 2. 特征维度校验（硬编码，不依赖配置） features = np.array(input_dict['features']) if features.shape[0] != 10: # 确保10维，与训练时一致 raise ModelValidationError(f"特征维度错误: 期望10维，实际{features.shape[0]}维") # 3. 数值范围校验（基于训练数据分布） if not np.all((features >= -1.0) & (features <= 1.0)): raise ModelValidationError("特征值超出训练分布范围[-1.0, 1.0]") # 4. NaN/Inf校验 if not np.isfinite(features).all(): raise ModelValidationError("特征包含NaN或Inf值") # 安全校验通过，执行推理 return _actual_predict(features)

2. 异常降级策略（Graceful Degradation）

def _actual_predict(features: np.ndarray) -> Dict[str, float]: try: # 尝试GPU推理 if torch.cuda.is_available(): with torch.no_grad(): output = model_gpu(torch.tensor(features).cuda()) return {"prediction": float(output.cpu().item()), "confidence": 0.95} else: raise RuntimeError("CUDA不可用") except Exception as e: # 降级到CPU logger.warning(f"GPU推理失败，降级至CPU: {e}") with torch.no_grad(): output = model_cpu(torch.tensor(features)) return {"prediction": float(output.item()), "confidence": 0.85}

3. 输出一致性保障（Output Consistency）

def _actual_predict(features: np.ndarray) -> Dict[str, float]: # ... GPU/CPU推理逻辑 ... # 最终输出强制校验 result = { "prediction": float(np.clip(output.item(), 0.0, 1.0)), # 强制截断 "confidence": float(np.clip(confidence_score, 0.0, 1.0)) # 强制截断 } # 验证输出符合契约 if not (0.0 <= result["prediction"] <= 1.0): raise ModelIntegrityError(f"预测值越界: {result['prediction']}") return result

提示：所有自定义异常（ModelValidationError,ModelIntegrityError）都继承自Exception，并在服务框架层统一捕获，转换为标准HTTP错误码。这样，算法工程师只管写防御逻辑，开发工程师只管写HTTP适配，职责清晰。

4. 实操过程与核心环节实现：从本地验证到灰度发布的完整流水线

4.1 本地验证：用Docker Compose模拟生产环境的最小闭环

在推送代码到GitLab前，每个开发者必须在本地完成“三环验证”：

第一环：模型核心单元测试（Model Core Unit Test）

# 运行模型核心层的pytest pytest tests/test_model_core.py -v --tb=short # 测试用例覆盖：正常输入、缺失字段、维度错误、数值越界、NaN输入

第二环：服务框架集成测试（Framework Integration Test）

# 启动Docker Compose（含FastAPI、Redis、Prometheus） docker-compose up -d # 用curl发送契约规定的合法/非法请求 curl -X POST http://localhost:8000/predict \ -H "Content-Type: application/json" \ -d '{"user_id":"u123","features":[0.1,0.2,0.3,0.4,0.5,0.6,0.7,0.8,0.9,0.95]}' # 验证返回HTTP 200及正确JSON curl -X POST http://localhost:8000/predict \ -H "Content-Type: application/json" \ -d '{"user_id":"u123","features":[0.1,0.2]}' # 维度错误 # 验证返回HTTP 422及标准错误码

第三环：资源契约验证（Resource Contract Validation）

# 启动容器后，立即采集资源数据 docker stats --no-stream my-model-api | head -n 2 # 检查内存是否在契约范围内（如<1.6GB） # 检查CPU使用率是否稳定（如<70%）

docker-compose.yml关键配置：

version: '3.8' services: model-api: build: . ports: ["8000:8000"] environment: - MODEL_VERSION=model-v3.2.1 - DATA_VERSION=feature-snapshot-20240515-1422 - CODE_VERSION=abc1234 # 强制资源限制，模拟K8s环境 mem_limit: 3072m mem_reservation: 1536m deploy: resources: reservations: cpus: '0.5' memory: 1536M limits: cpus: '2.0' memory: 3072M redis: image: redis:7-alpine prometheus: image: prom/prometheus:latest volumes: ["./prometheus.yml:/etc/prometheus/prometheus.yml"]

实操心得：本地Docker Compose不是玩具，而是生产环境的“缩小版”。我要求docker-compose.yml必须与K8s Helm Chart的资源配置100%一致（如mem_limit对应resources.limits.memory）。这样，本地压测数据可直接用于K8s配置，避免“本地跑得飞快，线上卡成PPT”的悲剧。

4.2 CI/CD流水线：GitLab CI的七步自动化发布

我们的GitLab CI流水线严格遵循“测试-构建-验证-发布”四阶段，共7个关键作业（Job）：

关键配置（.gitlab-ci.yml）：

stages: - test - build - deploy variables: DOCKER_REGISTRY: registry.example.com IMAGE_NAME: $CI_PROJECT_NAME test:unit: stage: test script: - pytest tests/ -v artifacts: paths: [coverage.xml] test:contract: stage: test script: - python scripts/validate_contract.py # 自研校验脚本 dependencies: [] build:docker: stage: build image: docker:20.10.16 services: [docker:dind] script: - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY - | if [ "$CI_COMMIT_TAG" ]; then docker build -t $DOCKER_REGISTRY/$IMAGE_NAME:$CI_COMMIT_TAG . docker push $DOCKER_REGISTRY/$IMAGE_NAME:$CI_COMMIT_TAG else docker build -t $DOCKER_REGISTRY/$IMAGE_NAME:$CI_COMMIT_SHORT_SHA . docker push $DOCKER_REGISTRY/$IMAGE_NAME:$CI_COMMIT_SHORT_SHA fi dependencies: [] deploy:staging: stage: deploy script: - helm upgrade --install model-api ./helm/model-api \ --set image.repository=$DOCKER_REGISTRY/$IMAGE_NAME \ --set image.tag=$CI_COMMIT_SHORT_SHA \ --set model.version=$CI_COMMIT_SHORT_SHA \ --namespace staging environment: staging only: - develop deploy:prod: stage: deploy script: - helm upgrade --install model-api ./helm/model-api \ --set image.repository=$DOCKER_REGISTRY/$IMAGE_NAME \ --set image.tag=$CI_COMMIT_TAG \ --set model.version=$CI_COMMIT_TAG \ --set traffic.weight=10 \ --namespace production environment: production when: manual only: - tags

注意：deploy:prod作业设置为when: manual，且仅对Git Tag触发。这意味着，只有打了v3.2.1这样的语义化版本标签，才能进入生产发布队列。这强制团队遵守版本管理规范，杜绝“随便merge个commit就上生产”的野路子。

4.3 灰度发布与流量切换：用Istio实现10%-50%-100%的渐进式切流

生产环境的流量切换，我坚持“三步灰度法”，全程由Istio Service Mesh控制，无需修改应用代码：

第一步：10%灰度（Canary 10%）

# istio-canary-10.yaml apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: model-api spec: hosts: - model-api.prod.svc.cluster.local http: - route: - destination: host: model-api subset: v3.2.0 weight: 90 - destination: host: model-api subset: v3.2.1 weight: 10 --- apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: model-api spec: host: model-api subsets: - name: v3.2.0 labels: version: v3.2.0 - name: v3.2.1 labels: version: v3.2.1

第二步：50%放量（Ramp-up 50%）
等待30分钟，观察以下指标无异常后，执行：

# 更新VirtualService，将weight改为50/50 kubectl apply -f istio-canary-50.yaml

第三步：100%切流（Full Rollout）
再等待30分钟，确认所有指标（延迟、错误率、资源使用率）稳定，执行：

# 删除旧版本subset，100%流量指向新版本 kubectl patch virtualservice model-api -p '{"spec":{"http":[{"route":[{"destination":{"host":"model-api","subset":"v3.2.1"}}]}]}}'

关键监控指标看板（Grafana）：

实操心得：灰度不是技术动作，是决策流程。我要求每次灰度切换前，必须召开15分钟站会，算法、开发、运维三方共同确认：模型指标（AUC变化）、业务指标（转化率影响）、系统指标（延迟/错误率）均达标，才点击“Apply”。这比任何自动化都可靠。

5. 常见问题与排查技巧实录：产线故障的21个真实现场与解法

5.1 模型加载失败：从ImportError到CUDA out of memory的全链路排查

问题现象：Pod启动失败，kubectl logs显示：

Traceback (most recent call last): File "/app/main.py", line 10, in <module> import torch ImportError: No module named 'torch'

排查路径：

1. 确认Docker镜像层：docker history $IMAGE_NAME查看torch是否在构建层中。若缺失，检查requirements.txt是否漏写torch==1.13.1+cu117（注意CUDA版本后缀）。
2. 确认基础镜像兼容性：FROM nvidia/cuda:11.7.1-devel-ubuntu20.04必须与torch的CUDA版本严格匹配。用nvidia-smi查宿主机CUDA版本，用torch.version.cuda查PyTorch编译版本。
3. 确认GPU驱动：kubectl describe node查看节点nvidia.com/gpu资源是否为0。若为0，说明NVIDIA Device Plugin未安装或驱动版本不匹配（如宿主机驱动470.xx，但Plugin要求510.xx）。

高频变体：

• CUDA out of memory：不是显存不足，而是torch.load()时map_location未指定。正确写法：torch.load(model_path, map_location='cpu')（先加载到CPU，再根据需要移到GPU）。
• OSError: libgomp.so.1: cannot open shared object file：基础镜像缺少OpenMP库。在Dockerfile中添加：RUN apt-get update && apt-get install -y libgomp1。

注意：所有GPU相关错误，第一反应不是调代码，而是查nvidia-smi和kubectl describe node。硬件层不通，上层一切免谈。

5.2 推理延迟飙升：从网络抖动到特征计算瓶颈的定位树

问题现象：API P95延迟从150ms突增至2.1s，kubectl top pods显示CPU使用率仅40%，内存正常。

定位树（Decision Tree）：

延迟飙升？ ├─ 是HTTP 503？ → 检查K8s readinessProbe失败日志（Redis连不上？） ├─ 是HTTP 200但慢？ → 进入Pod执行：`curl -s http://localhost:8000/metrics | grep latency` │ ├─ `model_inference_latency_seconds`高？ → 模型本身问题（特征维度错？GPU没启用？） │ ├─ `redis_request_duration_seconds`高？ → 缓存层问题（Redis连接池耗尽？） │ └─ `http_request_duration_seconds`高但`model_inference`不高？ → 框架层问题（日志同步写磁盘？） └─ 其他？ → 检查`kubectl describe pod`的Events（如`FailedScheduling`表示资源不足）

真实案例：某次延迟飙升，/metrics显示redis_request_duration_secondsP99=1.8s。排查发现：服务框架层用redis.Redis()创建了全局连接，但未设置max_connections=100，默认连接池仅10个。高并发时请求排队，造成延迟雪崩。修复：redis.Redis(connection_pool=ConnectionPool(max_connections=100))。

提示：延迟问题永远先看指标，再看日志。/metrics端点是你的第一道防线，必须保证它自身延迟<10ms（用curl -w "@time.txt"测）。

5.3 模型效果衰减：数据漂移、概念漂移与监控盲区的识别

问题现象：业务方反馈“模型不准了”，但/metrics里model_inference_latency、http_requests_total一切正常。

三步诊断法：
第一步：确认是否真衰减

• 拉取最近7天的model_prediction_distribution直方图（Prometheus），看预测值分布是否偏移（如原来集中在[0.2,0.8]，现在大量落在[0.01,0.05]）。
• 对比A/B测试分流：将5%流量固定路由到旧模型（v3.2.0），5%到新模型（v3.2.1），用rate(http_request_total{code="200"}[1h])对比转化率。

第二步：定位漂移类型

第三步：快速止血

• 若确认数据漂移：立即回滚到上一版数据快照