ML模型服务化落地：生产级稳定性与可观测性实战

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，实测吞吐量比裸PyTorch高3.2倍；第三，可精确控制CUDA/cuDNN版本，避免“本地能跑线上报错”的经典陷阱。这笔账怎么算？按我们日均200万次调用测算，Serverless方案年成本约$142,000，而自建K8s集群（含GPU节点）年成本$89,000，且故障排查时间减少70%。技术选型没有银弹，只有基于业务规模、SLA要求和团队能力的务实计算。

2.3 观测性不是“锦上添花”，而是故障定位的唯一路径

曾有个案例：模型在线上突然准确率下跌12%，监控显示CPU使用率正常、API成功率99.9%。团队花了36小时排查，最后发现是上游数据管道将用户年龄字段从整型转为字符串，模型内部astype(int)抛出异常，但异常被静默捕获并返回默认预测值。从此我们定下铁律：所有模型服务必须输出三类日志——结构化请求日志（含输入特征哈希、输出置信度）、性能指标（p50/p95/p99延迟、QPS）、数据质量快照（每1000次请求采样1次，记录各特征分布、缺失率、异常值比例）。这些日志不存本地磁盘，直送ELK集群，配合Grafana看板实现“5分钟定位根因”。比如当准确率告警触发，我们直接筛选该时段日志，用特征哈希聚类，快速发现某类样本的age字段分布偏移——这才是真实世界里救火的标准动作。

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

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

Notebook里常写的df['user_id'].astype(str)在生产环境是定时炸弹。我们用Pydantic V2构建强类型输入模型，强制校验：

from pydantic import BaseModel, Field, validator from typing import List, Optional class PredictionRequest(BaseModel): user_id: str = Field(..., min_length=1, max_length=32, regex=r'^[a-zA-Z0-9_]+$') age: int = Field(..., ge=0, le=120) transaction_amount: float = Field(..., ge=0.0) features: List[float] = Field(..., min_items=128, max_items=128) @validator('transaction_amount') def amount_must_be_positive(cls, v): if v < 0: raise ValueError('transaction_amount must be non-negative') return v

关键点在于：Field(...)表示必填，min_length/max_length防SQL注入，regex约束字符集，ge/le定义业务逻辑边界。当请求{"user_id": "abc", "age": 150}到达时，FastAPI自动返回422错误及详细原因：“age must be less than or equal to 120”。这比在模型里写if age > 120: return default_pred优雅得多——错误在入口处暴露，而非污染预测结果。

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

Triton的config.pbtxt文件里，dynamic_batching参数看似能提升吞吐，但若未设max_queue_delay_microseconds，小批量请求会无限排队等待凑batch，导致P99延迟飙升。我们实测最优配置：

dynamic_batching [ max_queue_delay_microseconds: 10000 # 10ms内必须执行，避免长尾 preferred_batch_size: [4, 8, 16] # 预热常用batch size ] instance_group [ [ count: 1 kind: KIND_GPU gpus: [0] # 显式绑定GPU索引，避免多卡争抢 ] ]

更隐蔽的坑是model_repository路径权限。Triton容器以非root用户运行，若模型文件夹权限为755但属主是root，Triton会静默失败。解决方案：构建镜像时用chown -R triton:triton /models，并在K8s Deployment中添加securityContext: {runAsUser: 1001}确保UID一致。

3.3 服务治理层：熔断器的阈值不是拍脑袋决定的

Hystrix或Resilience4j的熔断阈值常被设为“错误率>50%”，这在ML服务中极危险。因为模型本身就有一定错误率（如分类置信度<0.5时返回UNKNOWN），若上游调用方未处理UNKNOWN，就会被计入错误计数。我们改用双维度熔断：

  • 基础错误率：HTTP 5xx错误 > 10%（排除模型业务错误）
  • 延迟异常率：P95延迟 > 基线200%且持续5分钟

基线值通过历史数据计算：采集过去7天每小时的P95延迟，取中位数作为基线，避免单日大促数据污染。熔断后，服务自动切换至降级策略——返回缓存预测结果（带is_fallback: true标识），而非直接拒绝。这保证了业务连续性，也为工程师争取了故障修复窗口。

3.4 可观测性落地：特征分布监控的采样策略

全量计算每条请求的特征分布不现实。我们采用分层随机采样：

  • 高频采样层：对user_id哈希值末位为0的请求，100%采集完整特征向量（约10%流量）
  • 低频采样层：对其他请求，仅采集age、transaction_amount等5个关键数值特征（约0.1%流量）
  • 触发采样层：当P95延迟突增>50%，自动开启10分钟全量采样

采样数据经Spark Streaming实时计算KS检验值（Kolmogorov-Smirnov test），当age分布KS值>0.15时触发告警。这个阈值来自历史回溯：我们分析了过去3个月12次真实数据漂移事件，发现KS>0.15时模型准确率下降概率达92%。所有阈值必须用真实故障数据反推，而非理论值。

3.5 模型热更新：如何做到秒级切换不中断

Triton支持模型版本热加载，但需满足两个条件：

  1. 新模型文件夹命名必须为纯数字（如1,2），且config.pbtxt中version_policy设为latest { num_versions: 2 }
  2. 更新时先上传新版本文件夹，再原子性修改model_repository/<model_name>/config.pbtxt中的version_policy指向新版本

我们封装成CI/CD脚本，关键步骤：

# 1. 上传新模型到临时路径 scp -r model_v2/ triton@server:/tmp/model_v2/ # 2. 原子性移动（避免中间态） ssh triton@server "mv /tmp/model_v2 /models/recommender/2" # 3. 更新配置（Triton会自动reload） ssh triton@server "echo 'version_policy: latest { num_versions: 2 }' >> /models/recommender/config.pbtxt"

整个过程耗时<800ms，期间旧版本持续服务，无任何请求丢失。注意：config.pbtxt必须用>>追加而非覆盖，否则Triton会因配置语法错误退出。

3.6 日志结构化：为什么不用print()而用structlog

Notebook里print(f"Predicted: {pred}, Confidence: {conf}")在生产环境是灾难。我们强制使用structlog输出JSON日志：

import structlog logger = structlog.get_logger() def predict_handler(request: PredictionRequest): try: features = preprocess(request.dict()) pred, conf = model_inference(features) logger.info("prediction_success", user_id=request.user_id, prediction=pred, confidence=round(conf, 4), feature_hash=hashlib.md5(str(features).encode()).hexdigest()[:8]) return {"prediction": pred, "confidence": conf} except Exception as e: logger.error("prediction_failed", user_id=request.user_id, error_type=type(e).__name__, error_msg=str(e)) raise

关键收益：

  • ELK中可直接用user_id: "abc123"过滤某用户全链路日志
  • Grafana中用avg(confidence) by (feature_hash)发现某类特征组合置信度持续偏低
  • 安全审计时，feature_hash可验证日志未被篡改（对比原始特征）

提示：feature_hash必须在预处理后计算，否则无法捕捉到preprocess()函数内的数据转换异常。

3.7 环境一致性：Docker镜像构建的“三不原则”

我们制定镜像构建铁律：

  • 不安装非必要包：基础镜像用nvidia/cuda:11.8.0-cudnn8-runtime-ubuntu22.04，仅pip install tritonclient[http] numpy pandas，禁用pip install --upgrade pip（避免依赖冲突）
  • 不挂载外部配置：所有配置（如数据库连接串）通过K8s Secret注入环境变量，镜像内硬编码os.getenv("DB_HOST")，杜绝配置漂移
  • 不使用latest标签：镜像Tag严格匹配Git Commit Hash（如triton-recommender:abc123），CI流水线中docker build -t $IMAGE_NAME:$GIT_COMMIT .，确保任意镜像可100%复现构建环境

曾因某次pip install -r requirements.txt拉取了新版scikit-learn，导致OneHotEncoder行为变更，线上预测全错。自此所有依赖锁定到patch版本：scikit-learn==1.3.0。

3.8 流量染色：灰度发布的最小可行方案

不依赖复杂Service Mesh，我们用Nginx做轻量级灰度：

upstream production { server triton-prod-01:8000; server triton-prod-02:8000; } upstream canary { server triton-canary-01:8000; } # 对user_id哈希值末位为0的请求导流至灰度 map $http_user_id $backend { ~.*0$ "canary"; default "production"; } server { location /v1/predict { proxy_pass http://$backend; } }

关键点：map指令在Nginx启动时编译，无运行时开销；~.*0$正则确保10%流量进入灰度，且同一user_id永远路由到同一集群（保障AB测试一致性）。灰度期间，我们对比两套集群的accuracy、p95_latency、error_rate三大指标，任一指标偏差>5%即自动回滚。

3.9 模型签名：防止“同名不同模”的信任危机

多个团队共用同一模型名称时，极易发生recommender-v1被A团队更新、B团队不知情继续调用的情况。我们在Triton模型配置中加入签名：

# config.pbtxt platform: "pytorch_libtorch" max_batch_size: 32 input [ { name: "INPUT__0", data_type: TYPE_FP32, dims: [128] } ] output [ { name: "OUTPUT__0", data_type: TYPE_FP32, dims: [10] } ] # 新增签名字段 model_signature: "sha256:abc123...xyz789" # 模型权重文件的SHA256

客户端调用时，先GET/v2/models/recommender/versions/1获取签名，再与本地模型哈希比对。不匹配则拒绝调用并告警。这解决了“模型版本管理”的最后一公里信任问题。

3.10 资源隔离：GPU显存不足的终极解法

当多个模型共享GPU时，nvidia-smi显示显存占用95%，但实际torch.cuda.memory_allocated()仅占60%——这是CUDA上下文缓存（context cache）在作祟。Triton默认启用cuda_cache_max_pool_size，但我们发现其默认值（1GB）在多模型场景下导致显存碎片化。解决方案：在config.pbtxt中显式关闭：

# 关闭CUDA缓存，用显存换确定性 optimization [ execution_accelerators [ gpu_execution_accelerator [ name: "tensorrt" parameters: { key: "precision_mode" value: "FP16" } ] ] ] # 关键配置 dynamic_batching [ max_queue_delay_microseconds: 10000 ] # 禁用CUDA缓存 instance_group [ [ count: 1 kind: KIND_GPU gpus: [0] ] ] # 添加此行彻底禁用 model_optimization_config: "disable_cuda_context_caching: true"

实测后，相同GPU节点可稳定部署4个模型（原为2个），且P99延迟标准差降低63%。

3.11 错误分类：让告警不再“狼来了”

模型错误必须分级：

  • Level 0（静默）：confidence < 0.3，返回{"prediction": "UNKNOWN", "is_confident": false}，不告警
  • Level 1（业务）：user_id格式错误，返回422，记录审计日志，不触发告警
  • Level 2（系统）：GPU OOM、Triton进程崩溃，触发PagerDuty告警
  • Level 3（数据）：age分布KS值>0.15，触发企业微信告警+自动创建Jira工单

我们用Prometheus记录model_error_count{level="2"}，当15分钟内>5次，才升级为P1告警。这避免了算法同学凌晨被confidence低的业务告警叫醒。

3.12 回滚机制：比部署更关键的“逃生舱”

热更新失败时，Triton可能卡在LOADING状态。我们预置K8s CronJob，每5分钟检查：

apiVersion: batch/v1 kind: CronJob metadata: name: triton-health-check spec: schedule: "*/5 * * * *" jobTemplate: spec: template: spec: containers: - name: checker image: curlimages/curl command: ['sh', '-c'] args: - | STATUS=$(curl -s http://triton:8000/v2/health/ready | jq -r '.ready') if [ "$STATUS" != "true" ]; then echo "Triton not ready, triggering rollback..." kubectl rollout undo deployment/triton-prod fi restartPolicy: OnFailure

配合K8s Deployment的revisionHistoryLimit: 5，确保最近5次发布版本可一键回滚。真正的稳定性，不在于永不失败，而在于失败后10秒内恢复。

4. 实操过程与核心环节实现：从本地验证到生产上线的完整流水线

4.1 本地验证阶段：用Docker Compose模拟生产环境

在提交代码前，开发者必须在本地运行完整链路。我们提供标准化docker-compose.yml：

version: '3.8' services: triton: image: nvcr.io/nvidia/tritonserver:23.09-py3 ports: - "8000:8000" - "8001:8001" volumes: - ./models:/models - ./config:/config command: tritonserver --model-repository=/models --strict-model-config=false --log-verbose=1 nginx: image: nginx:alpine ports: - "8080:80" volumes: - ./nginx.conf:/etc/nginx/nginx.conf client: build: ./client depends_on: - triton - nginx

关键设计：

  • --strict-model-config=false允许Triton在缺少config.pbtxt时自动推断，加速本地调试
  • --log-verbose=1输出详细日志，方便定位model loading failed类问题
  • client服务内置压力测试脚本，运行locust -f load_test.py --headless -u 100 -r 10模拟100并发，验证P95延迟<500ms

注意：本地Docker Compose不启用GPU，用--cpu-only参数启动Triton，确保CPU/GPU逻辑分离。GPU相关代码在K8s环境才激活。

4.2 CI/CD流水线：GitOps驱动的自动化发布

我们采用Argo CD实现GitOps，所有基础设施即代码（IaC）存于infra仓库，模型代码存于ml-models仓库。流水线分三阶段：

阶段触发条件关键动作通过标准
Stage 1: 单元测试Git Push todevelop运行pytest tests/，验证预处理函数、特征工程逻辑100%用例通过，代码覆盖率>85%
Stage 2: 集成测试Stage 1成功启动临时Triton容器，用tritonclient调用/v2/models/{model}/inferP95延迟<300ms，准确率与Notebook基准误差<0.1%
Stage 3: 生产发布手动Merge tomainArgo CD检测infra仓库变更，自动同步K8s Deployment；同时ml-models仓库的main分支触发模型推送脚本Triton健康检查通过，新版本/v2/models/{model}/versions/2状态为READY

模型推送脚本核心逻辑：

# 1. 构建模型tar包（含权重+config.pbtxt） tar -czf recommender-v2.tar.gz models/recommender/2/ # 2. 上传至对象存储（带SHA256校验） aws s3 cp recommender-v2.tar.gz s3://models-bucket/recommender/v2/ --checksum-mode SHA256 # 3. 更新K8s ConfigMap，触发Argo CD同步 kubectl create configmap model-version --from-literal=version=2 --dry-run=client -o yaml | kubectl apply -f -

4.3 生产环境初始化：K8s集群的GPU节点专项配置

普通K8s集群无法直接调度GPU，需额外配置：

  1. 安装NVIDIA Device Plugin：
    kubectl create -f https://raw.githubusercontent.com/NVIDIA/k8s-device-plugin/v0.14.5/nvidia-device-plugin.yml
  2. 配置GPU节点Label：
    kubectl label nodes gnode-01 nvidia.com/gpu.present=true
  3. Deployment中声明GPU资源：
    resources: limits: nvidia.com/gpu: 1 # 请求1块GPU requests: nvidia.com/gpu: 1

关键避坑：Device Plugin版本必须与宿主机NVIDIA Driver版本匹配。我们固化Driver为525.85.12，对应Device Pluginv0.14.5。升级Driver前，必须先停机更新Device Plugin，否则节点GPU资源会显示为0。

4.4 上线后验证：黄金指标监控看板

上线后首小时，紧盯四大黄金指标看板（Grafana）：

  • 可用性（Availability）：sum(rate(http_request_total{code=~"2.."}[5m])) / sum(rate(http_request_total[5m]))，目标>99.95%
  • 延迟（Latency）：histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le))，目标<500ms
  • 流量（Traffic）：sum(rate(http_request_total{path="/v1/predict"}[5m]))，对比历史同期，确认流量无异常衰减
  • 错误（Errors）：sum(rate(http_request_total{code=~"5.."}[5m]))，关注是否出现新的5xx错误码

当Errors曲线突起，立即下钻：

  1. 查看http_request_total{code="500"}标签，确认是否为model_loading_failed
  2. 若是，登录Triton Pod，执行curl http://localhost:8000/v2/models/recommender/versions/2检查状态
  3. 若状态为UNAVAILABLE，查看kubectl logs triton-prod-01 -c triton定位具体错误（如OSError: libtorch.so not found）

4.5 持续反馈闭环：将线上数据反哺模型迭代

生产环境不是终点，而是新数据的起点。我们建立数据回流管道：

  1. 特征数据回传：每1000次预测，采样1条完整特征向量（含user_id,timestamp,features,prediction,actual_label）发送至Kafka Topicmodel-feedback
  2. 离线训练触发：Airflow每日02:00执行DAG，消费model-feedback中过去24小时数据，若actual_label覆盖率>80%，则启动新训练任务
  3. A/B测试报告：新模型在灰度环境运行72小时后，自动生成报告，对比accuracy、precision、recall、business_revenue_impact（如电商场景的GMV提升）

这个闭环让模型进化从“季度迭代”变为“周级迭代”，且每次迭代都有真实业务效果验证，而非仅看离线指标。

5. 常见问题与排查技巧实录：那些让你半夜爬起来的真问题

5.1 问题现象：Triton服务启动后，/v2/health/ready返回false，日志显示Failed to load model 'recommender'

排查路径：

  1. 进入Triton容器：kubectl exec -it triton-prod-01 -c triton -- bash
  2. 检查模型路径权限：ls -la /models/recommender/，确认2/文件夹属主为triton（UID 1001）
  3. 检查config.pbtxt语法：tritonserver --model-repository=/models --strict-model-config=true --log-verbose=1，此命令会输出详细配置错误
  4. 最常见原因：config.pbtxt中input字段的dims与模型权重实际维度不符。例如PyTorch模型期望[1, 128]，但配置写成[128]，Triton会静默失败。解决方案：用torch.jit.load()加载模型，打印model.graph确认输入shape。

实操心得：在CI阶段加入triton-config-validator工具，自动校验config.pbtxt与模型权重兼容性，避免问题流入生产。

5.2 问题现象：P95延迟稳定在450ms，但P99延迟高达3.2秒，且呈周期性毛刺

根因分析：Triton的dynamic_batching在等待凑batch时，将请求放入队列，当队列积压或GPU计算繁忙，请求在队列中等待超时。
解决方案：

  • 降低max_queue_delay_microseconds至5000（5ms）
  • 在config.pbtxt中添加priority: 1，确保高优先级请求不被低优先级阻塞
  • 监控nv_gpu_utilization指标，若GPU利用率<30%但延迟高，说明是CPU瓶颈（如预处理太重），需将preprocess()函数用Numba JIT加速

5.3 问题现象：模型在生产环境预测结果与本地Notebook完全不一致

排查清单：

  • ✅ 检查Python版本：python --version，生产环境是否为3.9.16而本地为3.10.12？dict顺序在3.7+已确定，但某些库行为仍有差异
  • ✅ 检查NumPy版本：np.__version__，np.random.seed()在1.21+与1.20行为不同
  • ✅ 检查CUDA版本：nvidia-smi，torch.version.cuda，确保与训练环境一致
  • ✅ 检查输入数据：用structlog输出feature_hash，对比线上与本地请求的哈希值，若不同，说明预处理逻辑有环境差异（如pandas.read_csv()默认engine='c'，但某些环境fallback到'python'）

经验：在模型服务启动时，自动打印sys.version,np.__version__,torch.__version__,torch.version.cuda到日志，形成环境指纹。

5.4 问题现象：K8s集群中GPU节点频繁NotReady，nvidia-smi显示No devices found

根本原因：NVIDIA Driver与Linux Kernel版本不兼容。我们集群Kernel为5.15.0-86-generic，但Driver515.65.01仅支持Kernel5.15.0-76。
解决步骤：

  1. 查看Driver支持矩阵：nvidia-driver --list-supported-kernels
  2. 升级Kernel：sudo apt install linux-image-5.15.0-76-generic
  3. 重启节点，验证nvidia-smi
  4. 重新安装匹配的Driver：sudo ./NVIDIA-Linux-x86_64-515.65.01.run --no-opengl-files --no-opengl-libs

注意：--no-opengl-files避免覆盖系统OpenGL库，引发GUI应用崩溃。

5.5 问题现象：灰度发布后，新模型准确率提升，但业务收入下降15%

深度归因：准确率是技术指标，收入是业务指标。我们发现新模型对高价值用户（ARPU>500元）的召回率下降，原因是训练数据中高价值用户样本占比仅0.3%，模型偏向优化整体准确率。
修正方案：

  • 在损失函数中加入类别权重：weight = 1 / class_frequency，使高价值用户样本权重提升300倍
  • A/B测试时，不仅看accuracy，更要看revenue_per_user、conversion_rate等业务漏斗指标
  • 建立“技术-业务”双指标看板，任何技术优化必须通过业务指标验证

5.6 问题现象：ELK中搜索user_id: "U12345"，返回0条日志，但确认该用户确实调用了服务

排查逻辑：

  • 检查Nginx日志：kubectl logs nginx-prod-01 | grep "U12345"，确认请求是否到达Nginx
  • 若Nginx有日志，检查Triton访问日志：kubectl logs triton-prod-01 -c triton | grep "U12345"
  • 若Triton无日志，检查FastAPI中间件是否捕获了异常（如JWT token过期，返回401未记录）
  • 最终发现：user_id在请求头中为X-User-ID，但日志中记录的是request.headers.get("user_id")（应为"x-user-id"），大小写敏感导致字段为空

教训：所有日志字段名统一用小写+下划线，避免HTTP头大小写歧义。

5.7 问题现象：模型服务内存持续增长，72小时后OOM被K8s Kill

内存泄漏定位：

  1. 在Triton容器中安装psutil：pip install psutil
  2. 添加内存监控脚本：
    import psutil, time while True: mem = psutil.Process().memory_info().rss / 1024 / 1024 print(f"[{time.ctime()}] Memory: {mem:.1f} MB") time.sleep(60)
  3. 分析日志发现：每处理1000次请求，内存增长12MB，且不释放。根因是preprocess()中使用了pandas.DataFrame.copy(deep=True)，但未显式del df_copy。
    修复：改用df.copy()（浅拷贝），或在函数末尾del所有中间变量，并调用gc.collect()。

5.8 问题现象：/v2/models/{model}/versions/2状态为LOADING，持续10分钟不变化

紧急处理：

  • 登录Triton Pod，执行kill -USR2 1（向PID 1进程发送USR2信号），触发Triton重新加载模型
  • 若仍失败，检查/models/{model}/2/目录下是否有model.pt（PyTorch）或model.onnx（ONNX）文件，Triton对文件名敏感，必须严格匹配平台类型
  • 常见错误：PyTorch模型文件名为model.pth，但Triton只识别model.pt，需重命名

5.9 问题现象：Grafana中model_error_count{level="2"}突增，但http_request_total{code="500"}无变化

真相：Level 2错误包含Triton内部错误（如`TRITONSERVER_ERROR_INTERNAL