ML模型生产化落地：从Notebook到稳定服务的实战指南

最新推荐文章于 2026-06-17 16:38:28 发布

原创最新推荐文章于 2026-06-17 16:38:28 发布 · 404 阅读

3 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

收录于

生活

1. 项目概述：这不是一次“部署上线”演示，而是一场真实世界的ML交付实战复盘

“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题里藏着三个关键信号： Notebook 是起点，不是终点； Production 是目标，但绝非简单打包； Real World 是限定词，也是所有技术决策的终极判官。我带过七支不同行业的ML落地团队，从金融风控模型到工厂设备预测性维护，从电商推荐系统到医疗影像辅助标注，反复验证一个事实：真正卡住90%项目的，从来不是算法精度提升0.3%，而是模型在凌晨三点因上游数据格式突变而静默失效、是API响应延迟从200ms跳到8秒导致前端重试风暴、是运维同事拿着一份“已上线”的模型文档，却找不到它依赖的Python包版本和CUDA驱动号。这篇内容不讲Docker镜像怎么写Dockerfile，不教Kubernetes怎么配HPA，它聚焦的是那些没人写进SOP、但你第二天上班就可能撞上的硬茬子：如何让一个在Jupyter里跑通的 model.predict() ，变成业务系统里能扛住每秒300次调用、自动熔断异常请求、日志能精准定位到某条样本特征异常的稳定服务。核心关键词—— ML部署落地、生产环境稳定性、模型服务化、可观测性、数据漂移监控 ——它们不是抽象概念，而是你调试完第17个超时配置后，在监控面板上看到绿色P99延迟曲线时的真实心跳。适合谁？刚把模型准确率刷到SOTA、正准备提PR给工程组的算法同学；接手了“已上线”模型却连日志都查不到的后端工程师；还有那个被老板问“模型到底有没有在用”的技术负责人——这篇文章就是你们开会前该一起读的那页纸。

2. 内容整体设计与思路拆解：为什么放弃“一键部署”，选择“分层防御”架构

2.1 核心矛盾：Notebook的确定性 vs 生产环境的混沌性

在Jupyter里， pd.read_csv('data.csv') 能稳稳加载本地文件，因为路径、编码、缺失值处理全由你手动控制；但在生产环境，上游ETL任务可能因网络抖动少传2行数据，CSV头部多了一个BOM字符，或某列数值型字段混入了字符串"NULL"。如果服务层还沿用Notebook里的粗放式数据加载逻辑，结果就是500错误雪崩。我们放弃“模型即服务（MaaS）”的幻觉，转而构建三层防御： 数据契约层 → 模型执行层 → 服务治理层 。这不是过度设计，而是用结构换稳定性。数据契约层强制定义输入Schema（字段名、类型、允许空值、取值范围），任何不符合契约的请求在进入模型前就被拦截并返回明确错误码；模型执行层将 model.predict() 封装为原子操作，隔离GPU内存、限制最大batch size、设置硬超时；服务治理层则负责流量调度、熔断降级、链路追踪。这三层像三道安检门，每道门解决一类问题，避免所有风险压在一个模块上。

2.2 为什么不用纯Serverless方案？成本与可控性的现实权衡

很多教程鼓吹AWS Lambda + SageMaker Endpoint，宣称“零运维”。实测下来，当模型推理耗时超过1.5秒，Lambda冷启动延迟（平均800ms）会吃掉近半响应时间，且每次扩容需重新加载GB级模型权重，导致P95延迟毛刺严重。更致命的是，Lambda不支持自定义CUDA版本，而我们的图像分割模型必须绑定特定cuDNN patch。我们最终采用 Kubernetes + Triton Inference Server 组合，表面看运维复杂度上升，但换来三重确定性：第一，GPU资源独占，无多租户干扰；第二，Triton原生支持TensorRT优化、动态batching，实测将单次推理耗时从320ms压到110ms；第三，可精确控制NVIDIA Driver版本，避免“模型训练环境vs生产环境CUDA不兼容”这类深夜救火。这里没有银弹，只有根据你的硬件栈、延迟SLA、团队技能树做的务实选择。

2.3 观测性不是“加个Prometheus”，而是定义故障的黄金信号

新手常犯的错是堆砌监控指标：CPU使用率、内存占用、HTTP 5xx数量……这些是症状，不是病因。我们定义了三个黄金信号（Golden Signals）作为观测性基石：

数据新鲜度（Data Freshness） ：上游数据表最后更新时间距当前是否超阈值（如>15分钟）？若超时，立即触发告警并切换至缓存特征；
特征分布偏移（Feature Drift Score） ：对每个数值型特征计算PSI（Population Stability Index），当PSI>0.25时标记高风险，阻断该批次预测并通知数据科学家；
预测置信度一致性（Confidence Consistency） ：对分类模型，统计过去1小时预测结果中最高置信度的均值与标准差，若标准差骤升50%，说明模型可能遭遇OOD（Out-of-Distribution）样本。
这三个信号直接关联业务影响，而非基础设施状态。它们被嵌入服务健康检查端点（ /healthz ），K8s liveness probe每10秒调用一次，任一信号异常即触发Pod重启——用自动化代替人工巡检。

3. 核心细节解析与实操要点：从代码到产线的12个生死细节

3.1 数据契约层：用Pydantic V2定义不可绕过的输入铁律

Notebook里常见的 df.fillna(0) 在生产环境是定时炸弹——它掩盖了上游数据质量缺陷。我们用Pydantic V2构建强校验契约：

from pydantic import BaseModel, Field, validator
from typing import List, Optional

class PredictionRequest(BaseModel):
    user_id: str = Field(..., min_length=8, max_length=32, regex=r'^[a-zA-Z0-9_]+$')
    features: List[float] = Field(..., min_items=128, max_items=128)
    timestamp: int = Field(..., ge=1609459200)  # 2021-01-01 UTC
    
    @validator('features')
    def validate_features_range(cls, v):
        if not all(-1000.0 <= x <= 1000.0 for x in v):
            raise ValueError('feature values must be in [-1000, 1000]')
        return v

# 实际调用时强制校验
try:
    req = PredictionRequest(**json_payload)
except ValidationError as e:
    # 返回422 Unprocessable Entity + 具体字段错误
    return JSONResponse(status_code=422, content={"detail": e.errors()})

提示：Field的 regex 参数必须用原始字符串（r''），否则反斜杠转义失效； ge （greater than or equal）比 gt 更安全，避免时间戳为0的边界情况。

3.2 模型执行层：Triton配置中的GPU内存陷阱

Triton的 config.pbtxt 文件里， dynamic_batching 看似能提升吞吐，但若未设 max_queue_delay_microseconds ，请求会在队列积压导致P99延迟飙升。我们实测发现：当 max_queue_delay_microseconds=10000 （10ms）时，P95延迟稳定在115±5ms；若设为100000（100ms），P95跳至210ms且波动剧烈。更隐蔽的是 instance_group 配置：

instance_group [
  [
    {
      name: "gpu_0"
      count: 1
      kind: KIND_GPU
      gpus: [0]
    }
  ]
]

这段配置声明只用GPU 0，但若服务器有2块GPU，Triton默认会尝试在两块卡上各启1个实例，导致显存争抢。必须显式指定 gpus: [0] 并确保 count=1 ，否则 nvidia-smi 里会看到两个进程各占40%显存，实际性能反而不如单实例满载。

3.3 服务治理层：熔断器的阈值不是拍脑袋，而是基于P90延迟计算

Hystrix式熔断器常被滥用。我们采用 自适应熔断 ：以过去5分钟P90延迟为基线，当实时P90超过基线200%且持续30秒，触发熔断。实现逻辑如下：

# 伪代码：熔断状态机
class AdaptiveCircuitBreaker:
    def __init__(self, baseline_p90_ms=120, threshold_ratio=2.0, window_sec=300):
        self.baseline = baseline_p90_ms
        self.threshold = baseline_p90_ms * threshold_ratio
        self.window = window_sec
        self.failure_count = 0
        self.success_count = 0
        
    def on_request_complete(self, latency_ms: float, is_success: bool):
        if is_success:
            self.success_count += 1
            if latency_ms > self.threshold:
                self.failure_count += 1  # 高延迟也计为失败
        else:
            self.failure_count += 1
            
    def should_open(self) -> bool:
        total = self.success_count + self.failure_count
        if total < 20:  # 热身期，不熔断
            return False
        failure_rate = self.failure_count / total
        return failure_rate > 0.5 and self.failure_count >= 10

注意：熔断后必须设置 fallback 策略。我们不返回空结果，而是调用轻量级规则引擎（如Drools）生成兜底预测，保证业务连续性。

3.4 日志规范：让每条日志成为故障排查的坐标

生产日志不是 print("model loaded") ，而是结构化事件流。我们强制要求每条日志包含： request_id （全链路追踪ID）、 model_version （Git commit hash）、 input_hash （特征向量SHA256）、 latency_ms 。例如：

{"level":"INFO","timestamp":"2024-06-15T08:22:31.442Z","request_id":"req_abc123","model_version":"git-8f3a9c2","input_hash":"sha256-d4e5f6...","latency_ms":112.3,"event":"prediction_success"}

这样当监控报警时，运维可直接用 request_id 在ELK中检索完整调用链，无需在几十个微服务日志中大海捞针。

3.5 特征漂移检测：PSI计算必须排除缺失值干扰

PSI公式为： PSI = Σ(P_actual - P_expected) * ln(P_actual / P_expected) 。但若某特征缺失率高达40%，直接计算会导致PSI虚高。我们的解决方案是：先对特征做等频分箱（quantile-based binning），再过滤掉缺失值占比>10%的分箱。Python实现关键片段：

def calculate_psi(actual: pd.Series, expected: pd.Series, n_bins=10) -> float:
    # 步骤1：移除缺失值并取交集分布
    actual_clean = actual.dropna()
    expected_clean = expected.dropna()
    
    # 步骤2：用expected分位数切分actual，避免分布偏移导致分箱不一致
    quantiles = np.quantile(expected_clean, np.linspace(0, 1, n_bins + 1))
    actual_binned = np.digitize(actual_clean, quantiles, right=True)
    expected_binned = np.digitize(expected_clean, quantiles, right=True)
    
    # 步骤3：计算各分箱占比（添加平滑避免log(0)）
    actual_dist = np.bincount(actual_binned, minlength=n_bins+1)[1:] / len(actual_clean)
    expected_dist = np.bincount(expected_binned, minlength=n_bins+1)[1:] / len(expected_clean)
    
    # 平滑处理
    actual_dist = np.clip(actual_dist, 1e-5, None)
    expected_dist = np.clip(expected_dist, 1e-5, None)
    
    return np.sum((actual_dist - expected_dist) * np.log(actual_dist / expected_dist))

实操心得：分箱数 n_bins 不能固定为10。对高基数特征（如用户ID哈希值），需用 n_bins=min(10, len(np.unique(expected))/100) 动态调整，否则大部分分箱为空。

3.6 模型热更新：零停机切换的三步原子操作

模型更新不能 kill -9 旧进程。我们采用K8s滚动更新+Triton Model Repository双机制：

预加载阶段 ：将新模型文件（ .pt 或 .onnx ）放入Triton的 models/ 目录，目录名含版本号（如 my_model_v2.1.0 ），此时Triton不加载；
原子切换 ：调用Triton REST API POST /v2/repository/models/{model_name}/load ，Triton在后台编译新模型，完成后返回200；
流量切换 ：K8s Service通过 weight 注解将90%流量导向新Pod（已加载新模型），10%保留在旧Pod，持续15分钟观察指标；无异常则100%切流。

整个过程耗时<45秒，业务无感知。关键点在于： 新模型加载成功后，必须等待至少3个健康检查周期（30秒）再切流 ，避免Triton内部warmup未完成。

3.7 安全加固：模型服务不是裸奔的API

即使内网服务，我们也强制实施：

输入长度限制 ：FastAPI的 Body(..., max_length=1024*1024) 防JSON炸弹；
特征值范围校验 ：除Pydantic外，在模型执行前二次校验（如 np.all(np.abs(features) < 1e3) ），防浮点溢出；
拒绝User-Agent为 sqlmap 或 nuclei 的请求 ：用Nginx if ($http_user_agent ~* "(sqlmap|nuclei)") { return 403; } 。

注意：不要在模型代码里写 os.system() 或 subprocess.Popen() ，曾有团队因调试需要留了 os.popen('ls -la') ，被扫描器利用执行任意命令。

3.8 资源隔离：为什么给模型容器分配2核CPU却只用1个？

K8s中 resources.requests.cpu=2 不是给模型用的，而是为 预处理线程池 预留。我们的特征工程包含实时文本清洗（正则替换、停用词过滤），若只分配1核，当并发请求达50+时，GIL锁导致CPU利用率100%但QPS不升反降。实测分配2核后，启用 concurrent.futures.ThreadPoolExecutor(max_workers=4) ，QPS从320提升至480。内存同理： requests.memory=4Gi 中，2Gi给模型权重，1Gi给特征缓存，1Gi为OOM Killer留余量。

3.9 错误码设计：4xx/5xx不是二分法，而是故障地图

我们定义了细粒度错误码体系：

4001 ：数据契约校验失败（如user_id格式错误）→ 前端修复输入；
4002 ：特征分布偏移（PSI>0.25）→ 数据团队检查上游ETL；
4221 ：模型加载失败（Triton报错）→ SRE检查GPU驱动；
5031 ：熔断器开启 → 自动降级，无需人工干预；
5032 ：下游特征服务超时 → 定位特征平台瓶颈。

每个错误码对应明确的SLA责任人和SOP文档链接，避免故障升级时扯皮。

3.10 测试金字塔：从单元测试到混沌工程

单元测试 ：覆盖Pydantic契约、特征转换函数（如 time_to_hour() ）；
集成测试 ：用 tritonclient 调用本地Triton，验证端到端延迟；
金丝雀测试 ：新模型在1%生产流量运行24小时，对比A/B指标；
混沌测试 ：用Chaos Mesh注入 network-delay （模拟上游数据延迟），验证熔断器是否在30秒内生效。

关键经验：混沌测试必须在预发环境做，且注入故障前要备份监控基线，否则无法判断是故障还是正常波动。

3.11 文档即代码：Swagger不是摆设，而是契约

FastAPI自动生成的 /docs 页面，我们强制要求：

每个请求体（ PredictionRequest ）字段必须有 description ，说明业务含义（如 user_id: "用户唯一标识，来自CRM系统，长度8-32位" ）；
responses 中 4001 等自定义错误码必须有 description 和 content 示例；
所有示例值用真实脱敏数据（如 user_id: "usr_7b8c2a" 而非 "string" ）。

这样前端工程师看文档就能写调用代码，无需再找算法同学问“这个字段到底要不要传”。

3.12 回滚机制：比上线更关键的是“一键还原”

回滚不是删Pod重部署。我们保留最近3个模型版本的Docker镜像（tagged as v2.0.0 , v2.1.0 , v2.1.1 ），并预置K8s kubectl rollout undo deployment/my-model --to-revision=2 命令。更重要的是 数据快照 ：每次模型上线前，自动备份特征仓库中该模型依赖的最新100万条样本（压缩存S3），回滚时同步恢复特征数据，避免“模型回退但数据已更新”导致结果不一致。

4. 实操过程与核心环节实现：从开发机到K8s集群的完整流水线

4.1 环境准备：开发、测试、生产的三套独立配置

我们拒绝“一套配置走天下”。使用Pydantic Settings管理环境变量：

from pydantic import BaseSettings

class Settings(BaseSettings):
    ENV: str = "dev"
    MODEL_NAME: str
    TRITON_URL: str
    FEATURE_STORE_URL: str
    DRIFT_THRESHOLD: float = 0.25
    
    class Config:
        case_sensitive = False
        env_file = ".env"

# .env.dev
ENV=dev
MODEL_NAME=my_model
TRITON_URL=http://localhost:8000
FEATURE_STORE_URL=http://feature-dev:8080

# .env.prod  
ENV=prod
MODEL_NAME=my_model
TRITON_URL=http://triton-prod.svc.cluster.local:8000
FEATURE_STORE_URL=https://feature-prod.company.com
DRIFT_THRESHOLD=0.15  # 生产环境更敏感

开发时 python main.py --env dev ，生产K8s Deployment中通过 envFrom: configMapRef 注入 .env.prod 。这样算法同学改模型名只需改一处，不会出现“开发环境叫my_model_v2，生产环境叫my_model_prod”的混乱。

4.2 模型导出：ONNX不是万能钥匙，而是性能权衡点

PyTorch模型导出ONNX时， opset_version 必须匹配Triton支持的版本（当前Triton 24.04支持ONNX opset 17）。关键参数：

torch.onnx.export(
    model,
    dummy_input,
    "model.onnx",
    export_params=True,
    opset_version=17,  # 必须与Triton兼容
    do_constant_folding=True,
    input_names=["input"],
    output_names=["output"],
    dynamic_axes={
        "input": {0: "batch_size"},  # 支持动态batch
        "output": {0: "batch_size"}
    }
)

注意：若模型含 torch.nn.Dropout ，导出前必须 model.eval() ，否则ONNX中会保留dropout节点导致推理结果随机。

4.3 Triton模型仓库构建：目录结构即部署契约

Triton要求严格目录结构，这是部署的“宪法”：

models/
└── my_model/
    ├── 1/              # 版本号目录（整数，越大越新）
    │   ├── model.onnx
    │   └── config.pbtxt
    ├── 2/
    │   ├── model.onnx
    │   └── config.pbtxt
    └── config.pbtxt    # 模型级配置（可选）

config.pbtxt 核心内容：

name: "my_model"
platform: "onnxruntime_onnx"
max_batch_size: 32
input [
  {
    name: "input"
    data_type: TYPE_FP32
    dims: [ 128 ]
  }
]
output [
  {
    name: "output"
    data_type: TYPE_FP32
    dims: [ 2 ]
  }
]
dynamic_batching [ 
  { max_queue_delay_microseconds: 10000 } 
]
instance_group [
  [
    {
      name: "gpu_0"
      count: 1
      kind: KIND_GPU
      gpus: [0]
    }
  ]
]

实操技巧： dims: [128] 表示输入是128维向量，若为2D输入（如 [batch, 128] ），需写 dims: [-1, 128] 并启用 dynamic_batching 。

4.4 K8s部署：YAML不是模板，而是基础设施说明书

Deployment YAML中， livenessProbe 和 readinessProbe 必须指向Triton健康端点：

livenessProbe:
  httpGet:
    path: /v2/health/ready
    port: 8000
  initialDelaySeconds: 60
  periodSeconds: 10
readinessProbe:
  httpGet:
    path: /v2/health/live
    port: 8000
  initialDelaySeconds: 30
  periodSeconds: 5

关键点： /v2/health/ready 检查模型是否加载完成， /v2/health/live 检查Triton进程是否存活。 initialDelaySeconds 必须大于模型加载时间（实测ONNX模型加载约45秒），否则Pod会因探针失败被反复重启。

4.5 监控告警：Grafana看板不是装饰，而是决策仪表盘

我们构建了4个核心看板：

服务健康看板 ：P90/P95延迟、错误率、QPS，按 model_version 分组；
数据质量看板 ：各特征PSI趋势、缺失率、新鲜度（Last Update Time）；
资源看板 ：GPU显存使用率、CUDA核心占用率、CPU等待时间；
业务影响看板 ：预测结果分布（如分类概率直方图）、与A/B测试对照组的转化率差异。

告警规则示例（Prometheus）：

# 当PSI连续5分钟>0.25，触发数据漂移告警
ALERT FeatureDriftHigh
  IF avg_over_time(model_drift_score{job="triton"}[5m]) > 0.25
  FOR 5m
  LABELS {severity="warning"}
  ANNOTATIONS {summary="Feature drift detected for {{ $labels.model }}", description="PSI score high for {{ $labels.feature }}"}

注意： FOR 5m 避免瞬时毛刺误报； avg_over_time 取5分钟均值，比瞬时值更稳定。

4.6 CI/CD流水线：GitOps不是理念，而是每日操作

我们用Argo CD实现GitOps，流程如下：

算法同学提交模型代码到 ml-models 仓库 main 分支；
GitHub Action触发CI：运行单元测试 → 导出ONNX → 推送至Docker Hub（tag= git-commit-hash ）；
Argo CD监听 k8s-manifests 仓库，检测到 deployment.yaml 中 image: company/model:abc123 更新；
自动同步K8s集群，执行滚动更新；
流水线末尾调用 curl -X POST https://monitoring/api/v1/alerts/trigger?alert=model_deployed ，通知值班群。

整个过程无人值守，从代码提交到生产就绪平均耗时8分23秒。

4.7 故障复盘：一次真实的P95延迟飙升事件

上周三14:22，监控显示 my_model P95延迟从115ms跳至720ms。排查步骤：

Step1：查K8s事件 kubectl get events --sort-by=.lastTimestamp ，发现 triton-7c8f9d4b5-xyz Pod因OOM被Kill；
Step2：查该Pod日志，发现 CUDA out of memory 错误；
Step3：对比 config.pbtxt ，发现 max_batch_size=32 ，但上游流量突发至50 QPS，Triton动态batching将batch size推至64，超出GPU显存；
Step4：紧急操作： kubectl scale deploy triton --replicas=3 增加副本，同时 kubectl patch cm triton-config -p '{"data":{"config.pbtxt":"max_batch_size: 16"}}' 降低单实例负载；
Step5：根因修复：在CI流水线中加入压力测试步骤，用 locust 模拟峰值流量，验证 max_batch_size 配置。

教训： max_batch_size 必须基于实测峰值QPS和GPU显存计算，而非拍脑袋。公式： max_batch_size ≈ GPU_memory_GB * 1024 / (model_size_MB + feature_size_per_sample_MB * 2) 。

4.8 性能压测：Locust脚本不是玩具，而是SLA证明书

Locust压测脚本直连Triton HTTP端点：

from locust import HttpUser, task, between
import json
import numpy as np

class TritonUser(HttpUser):
    wait_time = between(0.1, 0.5)
    
    @task
    def predict(self):
        # 生成符合契约的随机特征
        features = np.random.uniform(-1, 1, 128).tolist()
        payload = {
            "id": "locust_test",
            "inputs": [{
                "name": "input",
                "shape": [1, 128],
                "datatype": "FP32",
                "data": features
            }]
        }
        self.client.post("/v2/models/my_model/infer", json=payload)

# 运行命令：locust -f locustfile.py --host http://triton-prod:8000 --users 100 --spawn-rate 10

压测目标：在100并发下，P95延迟≤150ms，错误率=0%。未达标则回溯调优：降低 max_batch_size 、升级GPU型号、或优化特征工程代码。

4.9 成本优化：GPU不是越贵越好，而是够用即止

我们对比了A10（24GB显存）和A100（40GB显存）：

A10：单卡支持4个Triton实例，月成本$1200，P95延迟112ms；
A100：单卡支持2个实例（显存浪费），月成本$3200，P95延迟108ms（仅快4ms）。

最终选择A10，将省下的$2000/月投入特征平台建设。结论： 延迟收益<5%时，优先选性价比GPU 。监控中增加 cost_per_prediction 指标（GPU月成本/月总请求数），让成本透明化。

4.10 知识沉淀：Runbook不是文档，而是救命指南

每个模型服务必须配备Runbook Markdown文件，包含：

启动检查清单 ： kubectl get pods 状态、 curl /v2/health/ready 返回、 nvidia-smi 显存占用；
常见故障速查 ： 503 Service Unavailable → 检查Triton是否加载模型； 4001 → 查Pydantic校验日志；
紧急操作命令 ： kubectl rollout undo deployment/my-model 、 kubectl logs -l app=my-model --tail=100 ；
联系人矩阵 ：模型Owner、SRE On-Call、数据平台Support。

Runbook存Git仓库，与代码同版本管理，确保“代码更新，Runbook同步更新”。

5. 常见问题与排查技巧实录：那些让你凌晨三点爬起来的坑

5.1 问题：Triton报错 `Failed to load 'my_model', failed to initialize CUDA context`

现象：Pod日志显示CUDA初始化失败， nvidia-smi 可见GPU，但 kubectl describe pod 中Events有 FailedMount 。
根因：K8s节点NVIDIA驱动版本（525.85.12）与Triton容器内CUDA版本（11.8）不兼容。Triton 24.04要求驱动≥535.54.03。
解决：

在节点执行 sudo apt install nvidia-driver-535 ；
重启节点（ sudo reboot ）；
删除旧Pod触发重建。

避坑：Triton Docker镜像tag隐含CUDA版本， nvcr.io/nvidia/tritonserver:24.04-py3 对应CUDA 12.2，需驱动≥535；而 23.12-py3 对应CUDA 12.1，需驱动≥530。务必查官方兼容矩阵。

5.2 问题：Pydantic校验通过，但模型预测报 `RuntimeError: Expected all tensors to be on the same device`

现象：请求能过契约校验，但Triton返回500，日志显示张量设备不一致。
根因：Pydantic模型中 features: List[float] 被解析为CPU tensor，而Triton ONNX Runtime默认用GPU执行，未做设备迁移。
解决：在模型执行前显式移动tensor：

# Triton Python backend中
import torch
def execute(self, requests):
    for request in requests:
        features = torch.tensor(request.input("input"), dtype=torch.float32)
        features = features.to("cuda:0")  # 强制迁移至GPU
        # ... 后续推理

5.3 问题：特征漂移告警频繁，但业务无异常

现象：PSI每天告警10+次，但线上A/B测试指标平稳。
根因：PSI对低频特征（如用户地域）敏感，其分布天然波动大。我们原用等宽分箱（equal-width binning），导致稀疏特征分箱不均。
解决：改用 等频分箱+最小分箱样本数过滤 ：

# 计算分位数时，要求每箱至少100个样本
quantiles = []
for q in np.linspace(0, 1, n_bins + 1):
    val = np.quantile(expected_clean, q)
    # 若该分位数处样本数<100，跳过此分位点
    if np.sum(expected_clean <= val) < 100:
        continue
    quantiles.append(val)

5.4 问题：K8s滚动更新后，部分请求返回 `503 Service Unavailable`

现象：新Pod已Ready，但旧Pod未完全终止，流量被分发至未就绪Pod。
根因： readinessProbe 配置 initialDelaySeconds=30 ，但Triton加载模型需45秒，导致Pod在未加载完模型时就标记为Ready。
解决：

将 initialDelaySeconds 改为 60 ；
在 readinessProbe 中增加 failureThreshold: 3 ，避免瞬时失败误判；
使用 preStop 生命周期钩子：

lifecycle:
  preStop:
    exec:
      command: ["/bin/sh", "-c", "sleep 10"]  # 给旧Pod 10秒优雅退出

5.5 问题：监控显示GPU显存100%，但 `nvidia-smi` 只显示80%

现象：Prometheus指标 nvidia_gpu_duty_cycle 为100%，但 nvidia-smi 中 Memory-Usage 为7800MiB/8192MiB。
根因：Triton的 dynamic_batching 在队列积压时，会预分配显存缓冲区，这部分内存不计入 nvidia-smi 的 Used ，但被Prometheus采集为 memory_used_bytes 。
解决：

调整 config.pbtxt 中 max_queue_delay_microseconds=10000 ；
在Grafana中添加 nvidia_gpu_memory_total_bytes - nvidia_gpu_memory_free_bytes 与 nvidia_gpu_memory_used_bytes 对比图，确认是否为缓冲区占用。

5.6 问题：模型预测结果与本地Notebook不一致

现象：相同输入，Notebook输出 [0.8, 0.2] ，生产服务输出 [0.75, 0.25] 。
根因：Notebook中用了 model.eval() ，但Triton ONNX导出时未冻结BN层，导致推理时BN统计量变化。
解决：导出ONNX前，确保：

model.eval()  # 关闭dropout/batchnorm训练

标签

#ML部署落地 #生产环境稳定性 #模型服务化