首页/资讯中心/详情

机器学习模型服务化：从Notebook到高可用生产的落地实践

机器学习模型服务化：从Notebook到高可用生产的落地实践
📅 发布时间：2026/7/19 3:54:06

1. 这不是“把模型跑起来”那么简单：为什么第4部分专讲真实世界里的机器学习落地

“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题里藏着一个被太多人轻描淡写、却让无数团队在临门一脚时摔得最狠的真相：Notebook 里准确率98%的模型，和生产环境里稳定服务365天、每秒处理2000次请求、故障自动降级不报警的模型，根本不是同一个东西。我干了十多年机器学习工程，从最早用 scikit-learn 在 Jupyter 里调参，到后来带团队支撑日均百亿级特征计算的推荐系统，踩过的坑基本都堆在这 Part 4 里。它不讲怎么画 loss 曲线，也不教你怎么调 learning rate，它只解决一个问题：当你的模型第一次被真实用户点开、下单、搜索、滑动时，它能不能扛住，以及你能不能睡着觉。核心关键词——模型服务化（Model Serving）、流量治理（Traffic Management）、可观测性（Observability）、回滚机制（Rollback Strategy）——这四个词，就是真实世界 ML 的生死线。适合谁看？刚把模型训出来的算法同学、正被业务方催着上线的 MLOps 工程师、还有那些发现“模型上线后效果断崖下跌却查不出原因”的技术负责人。这不是锦上添花的进阶课，而是把模型从实验室安全送进产线的通关手册。

2. 从“能跑”到“敢用”：整体设计思路与方案选型逻辑

2.1 为什么不能直接用 Flask + pickle 搞定一切？

我见过太多团队在项目初期图省事，用 Flask 写个 predict 接口，把训练好的 sklearn 模型 dump 成 pickle 文件，扔进 Docker 里一跑，测试通过就上线。结果呢？第一个大促流量高峰，接口响应时间从 50ms 暴涨到 2s，错误率飙升，监控面板一片红色。问题出在哪？不是模型不行，是整个服务链路没经过真实压力的拷问。Flask 是同步阻塞框架，单进程默认只能处理一个请求；pickle 反序列化模型本身就有 CPU 开销；更别说没有请求队列、没有熔断、没有超时控制、没有版本隔离——这根本不是服务，这是定时炸弹。所以 Part 4 的设计起点非常明确：必须把模型服务当成一个高可用、可伸缩、可观测的微服务来构建，而不是一个临时脚本。这决定了我们所有后续的技术选型和架构决策。

2.2 为什么选择 Triton Inference Server 而不是自研 or TensorFlow Serving？

在模型服务框架选型上，我们对比过 TensorFlow Serving（TFS）、Triton、Seldon Core 和自研 gRPC 服务。最终锁定 Triton，理由很实在，不是因为它新，而是它解决了我们最痛的三个点。第一，多框架原生支持。我们团队同时有 PyTorch 训练的 NLP 模型、TensorFlow 的 CV 模型、还有 ONNX 导出的传统风控模型。TFS 只认 TF，PyTorch 模型得转成 TorchScript 再封装，ONNX 得额外加 adapter；而 Triton 原生支持这三者，配置文件里一行 model_format 就搞定，模型更新不用改服务代码。第二，动态批处理（Dynamic Batching）实测有效。我们线上推理请求是典型的“小包高频”，单次请求数据量小但 QPS 高。Triton 的 dynamic batcher 能自动把多个小请求合并成一个大 batch 送进 GPU，实测在 A10 显卡上，吞吐量比不开启 batch 提升 3.2 倍，P99 延迟反而下降 17%。第三，模型热更新与版本原子切换。Triton 的模型仓库（model repository）设计是声明式的：你只需把新版本模型文件放进去，修改 config.pbtxt 里的 version_policy，Triton 会自动加载新版本，并在新请求进来时无缝切流，旧版本请求处理完自动卸载。这比我们之前用 Kubernetes rolling update 做模型镜像滚动更新，快了整整 4 分钟，且零请求丢失。这些不是纸面参数，是我们在压测平台反复验证过的硬指标。

2.3 为什么 API 网关层必须独立于模型服务？

很多团队会把 API 认证、限流、日志、灰度路由这些功能，一股脑塞进模型服务的 Flask 或 FastAPI 里。短期看省事，长期看是灾难。一旦模型服务因为某个新模型的 bug 导致 CPU 100%，网关层的功能（比如 JWT 解析、IP 限流）也会跟着挂掉，整个入口失守。所以我们坚持“关注点分离”：Triton 只做一件事——高效、稳定地执行模型推理；所有外围能力，由独立的 API 网关（我们用的是 Kong）统一承载。Kong 作为前置网关，承担了四层关键职责：一是认证鉴权，所有请求必须携带有效的 OAuth2 token，Kong 在转发前完成校验，Triton 完全不碰敏感凭证；二是精细化限流，我们按用户 ID、App ID、甚至设备指纹做多维度速率限制，比如“单个用户每分钟最多调用 30 次”，规则变更无需重启 Triton；三是灰度发布控制，Kong 的 plugin 可以根据 header 中的 x-deploy-version 字段，将 5% 的流量打到 v2 版本 Triton 实例，95% 打到 v1，实现真正的金丝雀发布；四是统一日志与追踪，Kong 自动生成结构化 access log，包含 request_id、latency、upstream_status，并注入 OpenTelemetry trace_id，让一次请求的完整链路（Kong → Triton → 特征存储）能在 Grafana Tempo 里一键下钻。这种分层，让模型服务可以专注性能，网关层可以专注治理，出了问题，边界清晰，定位极快。

2.4 为什么可观测性不是“加个 Prometheus 就行”？

“上了 Prometheus 就算有可观测性了？”这是我在内部分享时最常听到的误解。Prometheus 确实能采集 Triton 的 metrics（比如 infer_request_success、gpu_utilization），但它告诉你的是“结果”，不是“原因”。比如，你看到 infer_request_failed_total 突然飙升，Prometheus 告诉你失败了，但失败是因为模型输入格式错了？GPU 显存 OOM？还是特征服务超时导致 Triton 等待超时？这些信息，metrics 给不了。所以我们构建的是三层可观测性栈：第一层是Metrics（指标），用 Prometheus + Grafana，监控核心 SLO：P99 推理延迟 < 200ms，成功率 > 99.95%，GPU 利用率 60%-80%（太低说明没压满，太高说明要扩容）；第二层是Logs（日志），Triton 的详细 error log、Kong 的 access log、特征服务的 debug log，全部接入 Loki，用 LogQL 按 request_id 关联查询；第三层是Traces（链路追踪），用 OpenTelemetry SDK 在 Triton client、Kong、特征服务中埋点，所有 span 都带上 model_name、input_size、feature_source 等业务标签，在 Tempo 里能看到“这次失败，95% 的时间耗在了 Redis 查询上”。这三层不是并列关系，而是递进：Metrics 告诉你“哪里坏了”，Logs 告诉你“坏成什么样”，Traces 告诉你“为什么坏”。缺一层，排查效率就打五折。

3. 核心细节解析与实操要点：从配置到部署的每一处陷阱

3.1 Triton 模型仓库的目录结构与 config.pbtxt 的魔鬼细节

Triton 的模型仓库（model repository）是它的灵魂，但也是新手最容易栽跟头的地方。一个标准的模型仓库长这样：

models/ ├── recommendation_v1/ │ ├── 1/ │ │ └── model.onnx │ └── config.pbtxt ├── fraud_detection_v2/ │ ├── 1/ │ │ └── model.pt │ └── config.pbtxt └── nlp_sentiment_v3/ ├── 1/ │ └── model_repository/ │ └── 1/ │ └── model.plan └── config.pbtxt

重点在config.pbtxt。很多人以为只要写对 input/output 名字就行，其实远不止。以recommendation_v1的 config 为例：

name: "recommendation_v1" platform: "onnxruntime_onnx" max_batch_size: 128 input [ { name: "user_id" data_type: TYPE_INT64 dims: [ 1 ] }, { name: "item_ids" data_type: TYPE_INT64 dims: [ -1 ] # 注意：-1 表示可变长度，Triton 会自动 batch } ] output [ { name: "scores" data_type: TYPE_FP32 dims: [ -1 ] } ] dynamic_batching [ # 必须显式开启，否则不生效 { max_queue_delay_microseconds: 10000 } # 最大排队等待 10ms，超过则立即触发 batch ] instance_group [ { count: 4 kind: KIND_GPU } ]

这里有几个魔鬼细节：第一，dims: [ -1 ]不是随便写的。如果你的item_ids输入是一个长度为 50 的 list，Triton 会把它 reshape 成[1, 50]；但如果count设为 4，batch size 是 32，那实际送入模型的 shape 就是[32, 50]。你的 ONNX 模型导出时，必须把item_ids的 input shape 设为[-1, 50]，否则 runtime 直接报错。第二，max_queue_delay_microseconds是动态批处理的命脉。设得太小（比如 1000），batch 基本凑不满，吞吐上不去；设得太大（比如 100000），用户感知延迟飙升。我们实测下来，10ms 是大多数场景的甜点值，既保证了 batch 效率，又没牺牲用户体验。第三，instance_group的count: 4并不是指启动 4 个进程，而是指在单张 GPU 上启动 4 个 Triton 的模型实例（inference instance），它们共享 GPU 显存，但各自有独立的 CUDA stream，能真正并行处理请求。这个数不是越大越好，要结合模型大小和 GPU 显存来算：比如你的模型占 3GB 显存，A10 有 24GB，理论最多 8 个，但还要给 Triton 自身留 2GB，所以count: 6是安全上限。这些数字，都是我们一台台机器、一个个模型压测出来的，不是拍脑袋。

3.2 Kong 网关的灰度路由配置：如何用 5 行代码实现 0.1% 流量切流

Kong 的灰度发布能力，核心在于其request-transformer和traffic-control插件的组合使用。我们不需要写任何 Lua 脚本，纯 YAML 配置就能搞定。假设我们要把recommendation_v1模型的 0.1% 流量切到recommendation_v2，配置如下（放在 Kong 的 route 配置中）：

plugins: - name: request-transformer config: add: headers: - "x-model-version: v1" # 默认打上 v1 标签 - name: traffic-control config: rules: - match: headers: - "x-model-version: v1" percentage: 99.9 upstream: service: triton-v1-service - match: headers: - "x-model-version: v1" percentage: 0.1 upstream: service: triton-v2-service

关键点在于match的逻辑：Kong 的traffic-control插件是“先匹配，再按比例分流”。我们先用request-transformer统一给所有请求加上x-model-version: v1，然后traffic-control看到这个 header，就按 99.9% 和 0.1% 的比例，把流量分别打到两个不同的 upstream（即两个 Triton Service）。为什么不用consumer或ip-restriction？因为它们粒度太粗。consumer是按用户身份，但我们想测的是模型本身，不是某个用户；ip-restriction是按 IP，但移动端 IP 经常变，不稳。用 header 匹配，精准、可控、可编程。上线后，我们只需要在客户端 SDK 里，随机生成一个 0-1000 的整数，如果等于 0，就手动加上x-model-version: v2，其他情况不加，就能完美实现 0.1% 的灰度。这个方案，上线零风险，回滚就是删掉那几行 YAML，5 秒生效。

3.3 特征服务的强一致性保障：为什么我们放弃 Redis，选择了 Redis + PostgreSQL 双写

模型推理的瓶颈，80% 不在模型本身，而在特征获取。我们早期用纯 Redis 存储用户实时特征（如最近 1 小时点击序列），QPS 高时，Redis 的LRU淘汰策略会导致热点特征被误删，模型拿到空特征，直接返回默认值，效果暴跌。后来换成 Redis Cluster，问题依旧，因为集群间数据同步有延迟，读写分离时，刚写入的特征可能还没同步到 slave，读请求就打过去了。我们最终采用Redis + PostgreSQL 双写 + 本地缓存兜底的混合方案。流程是这样的：当用户行为发生（如点击商品），我们的事件服务会同时向两个地方写：一是写入 Redis（设置 1 小时 TTL），二是写入 PostgreSQL 的user_features表（带updated_at时间戳）。Triton 的预处理脚本（preprocessing script）在加载特征时，按此顺序查询：第一步，查 Redis，命中则直接返回；第二步，Redis miss，则查 PostgreSQL，查到后，立刻回写 Redis，并设置 TTL；第三步，PostgreSQL 也查不到（极端情况），则返回一个预定义的“冷启动特征向量”，并记录一条告警日志。为什么 PostgreSQL 不是主库？因为它的写入延迟（平均 8ms）比 Redis（0.2ms）高太多，不能作为主路径。但它的强一致性，是 Redis 永远无法替代的。这个双写，我们用 Kafka 的事务性 producer 保证：一条消息，要么同时写入 Redis 和 Kafka（PG 同步靠 Kafka consumer），要么都不写，杜绝数据不一致。实测下来，特征获取的 P99 延迟稳定在 15ms 以内，Redis miss rate 低于 0.3%，完全满足 SLA。

3.4 回滚机制的“黄金 3 分钟”：如何在模型出问题时，5 秒内切回上一版

回滚不是“重启服务”，而是“秒级切流”。我们定义的 SLO 是：从发现模型异常（如 P99 延迟 > 500ms 或成功率 < 99%），到流量 100% 切回上一版，必须在 3 分钟内完成。为此，我们做了三件事：第一，Triton 模型版本永远保留至少两个。config.pbtxt里version_policy设为specific: [1, 2]，意味着 Triton 同时加载 v1 和 v2 两个版本，内存里常驻，无需重新加载。第二，Kong 的 upstream 切换脚本自动化。我们写了一个 Python 脚本rollback.py，它只做一件事：调用 Kong Admin API，把当前 route 的upstream从triton-v2-service切换到triton-v1-service。这个 API 调用耗时 < 200ms。第三，全链路健康检查哨兵。我们部署了一个独立的health-checker服务，它每 10 秒用真实样本请求一次 Triton 的/v2/health/ready和/v2/models/{model}/infer，并校验返回的scores是否在合理区间（比如不全是 0 或 NaN）。一旦连续 3 次失败，health-checker自动触发rollback.py。整个过程，从检测到切流，实测平均耗时 4.7 秒。比人工登录服务器、改 YAML、kubectl apply 快了 100 倍。而且，这个哨兵服务本身也部署在 Kubernetes 里，有自身的 liveness probe，确保它自己不会成为单点故障。这才是真正的“敢上线”。

4. 实操过程与核心环节实现：从本地调试到生产发布的完整流水线

4.1 本地开发与调试：如何在笔记本上模拟生产环境的每一环

很多工程师的痛点是：“本地跑得好好的，一上测试环境就各种 timeout、OOM、格式错误”。根源在于本地环境和生产环境的鸿沟太大。我们的解决方案是：用 Docker Compose 在本地复刻一个最小化的生产子集。docker-compose.yml如下：

version: '3.8' services: kong: image: kong:3.6 ports: - "8000:8000" - "8001:8001" environment: KONG_DATABASE: "off" KONG_DECLARATIVE_CONFIG: /kong.yml volumes: - ./kong.yml:/kong.yml triton: image: nvcr.io/nvidia/tritonserver:23.12-py3 ports: - "8000:8000" - "8001:8001" - "8002:8002" volumes: - ./models:/models command: ["tritonserver", "--model-repository=/models", "--strict-model-config=false"] redis: image: redis:7-alpine ports: - "6379:6379" postgres: image: postgres:15 environment: POSTGRES_DB: features POSTGRES_USER: user POSTGRES_PASSWORD: pass ports: - "5432:5432" volumes: - ./init.sql:/docker-entrypoint-initdb.d/init.sql

关键点在于kong.yml的配置，它和线上 Kong 完全一致，只是 upstream 指向了本地triton容器。models/目录下放着你正在开发的模型，config.pbtxt也按生产标准写。这样，你在本地浏览器访问http://localhost:8000/v2/models/recommendation_v1/infer，走的路径就是：Kong → Triton → Redis/PostgreSQL，和线上一模一样。调试时，你可以用docker logs -f kong看网关日志，docker logs -f triton看模型日志，redis-cli直连 Redis 查数据，psql连 PG 查状态。所有问题，都在本地闭环。我们要求，任何模型上线前，必须在这个 Compose 环境里，通过 1000 次并发压测（用hey -z 30s -c 100 http://localhost:8000/v2/models/recommendation_v1/infer），P99 延迟 < 100ms，错误率为 0，才算本地验证通过。这一步，挡住了 70% 的低级错误。

4.2 CI/CD 流水线：从 Git Push 到生产环境部署的 7 个自动化阶段

我们的 CI/CD 流水线（基于 GitLab CI）不是简单的“build & deploy”，而是一个有严格质量门禁的漏斗。每一次git push到main分支，都会触发以下 7 个阶段：

  1. Lint & Unit Test：运行pylint检查代码风格，pytest运行所有单元测试（包括模型预处理脚本的逻辑测试），失败则中断。
  2. Model Validation：调用 Triton 的model-analyzer工具，对models/下的新模型进行静态分析：检查 ONNX 模型是否符合 opset 14 规范，输入输出 shape 是否与config.pbtxt一致，是否有不支持的算子。这是防止“模型文件放错目录就炸”的第一道墙。
  3. Local Integration Test：启动上面提到的docker-compose环境，用真实请求体（从线上脱敏采样）调用新模型，验证返回结果的 schema 和数值范围是否符合预期。比如，scores必须是 float32 数组，长度必须等于item_ids输入长度，且所有值必须在 [0, 1] 区间内。不满足，流水线失败。
  4. Performance Benchmark：在docker-compose环境中，用tritonclient的perf_analyzer工具，对新模型进行基准测试：perf_analyzer -m recommendation_v1 -u localhost:8000 --concurrency-range 1:100:10，生成一份 CSV 报告，要求 P99 延迟比上一版提升 ≥5%，或至少不劣化 >2%。这是性能不退化的硬约束。
  5. Security Scan：用trivy扫描Dockerfile和所有基础镜像，检查 CVE 漏洞，高危漏洞（CVSS ≥ 7.0）必须修复，否则阻断。
  6. Staging Deploy：所有检查通过后，自动将新模型打包成 Helm Chart，部署到 Staging 环境（一个与生产等规模的 Kubernetes 集群）。Kong 的灰度插件在此环境默认开启 100% 流量到新模型，供 QA 团队进行端到端业务验收。
  7. Production Promote：Staging 验收通过后，运维同学在 GitLab UI 上点击 “Promote to Prod” 按钮，流水线自动执行：更新生产环境的 Helm Release，将 Kong 的 upstream 切换到新模型 Service，并触发一次全链路 smoke test（用 5 个核心业务场景的请求，验证端到端流程）。整个过程，无人值守，平均耗时 4 分 12 秒。

这个流水线，把“人”的判断压缩到了最后一步——业务验收。所有技术性、质量性的门槛，都由机器自动把关。上线不再是“赌一把”，而是“确认无误”。

4.3 生产环境监控大盘：Grafana 里必须盯死的 5 个核心看板

上线不是终点，而是监控的起点。我们在 Grafana 里搭建了 5 个核心看板，每个都对应一个关键 SLO，值班同学每天必须扫一眼：

  1. 模型服务健康总览（Health Overview）：展示所有 Triton 模型的inference_request_success（成功率）、inference_request_duration（P99 延迟）、gpu_utilization（GPU 利用率）的实时曲线。阈值线清晰标出：成功率红线 99.95%，延迟红线 200ms，GPU 红线 90%。任何一个指标触线，立刻告警。
  2. 特征服务水位（Feature Store Water Level）：展示 Redis 的used_memory和evicted_keys，PostgreSQL 的pg_stat_database.blks_read和pg_stat_database.xact_commit。重点关注evicted_keys是否突增，这往往是特征被误删的前兆；blks_read如果持续高于xact_commit的 10 倍，说明磁盘 IO 成瓶颈，需要优化索引。
  3. Kong 网关流量图谱（Kong Traffic Map）：用 Grafana 的Worldmappanel，按地理区域（国家/省份）展示 API 请求来源，再叠加upstream_status（2xx/4xx/5xx）的饼图。如果某个地区 5xx 突增，大概率是那个地区的特征服务节点出了问题，而不是模型本身。
  4. 模型输入输出分布（Input/Output Distribution）：用histogram_quantile函数，绘制user_id的分布直方图（看是否出现异常 ID）、item_ids长度的分布（看是否出现超长列表导致 OOM）、scores的分布（看是否出现大量 0 或 1，暗示模型失效）。这个看板，是发现“模型静默崩溃”（Silent Failure）的唯一途径。
  5. 链路追踪热力图（Trace Heatmap）：用 Tempo 的heatmap视图，横轴是时间，纵轴是 trace duration，颜色深浅代表该耗时区间的请求数量。正常情况下，应该是一片集中在 50-150ms 的绿色区域；如果突然出现一大片 2000ms 的红色区域，说明有慢 SQL 或网络抖动，立刻下钻看具体 trace。

这 5 个看板，不是摆设。我们规定，任何值班同学，看到任一看板出现异常，必须在 5 分钟内发起初步排查，并在 15 分钟内给出根因或升级路径。这套机制，让我们把平均故障恢复时间（MTTR）从过去的 47 分钟，压缩到了现在的 8.3 分钟。

5. 常见问题与排查技巧实录：那些只有踩过才知道的坑

5.1 问题：P99 延迟突然飙升 300%，但 CPU/GPU 利用率都很低，为什么？

这是最让人抓狂的问题。表面看资源充足，但服务就是慢。我们遇到过三次，根因各不相同，但排查路径高度一致：

提示：不要先看 Triton 日志，先看 Kong 的 access log 和 feature store 的 slow query log。

  • 第一次：Kong log 显示大量upstream_status: 504，但 Triton 的 metrics 里infer_request_success是 100%。顺着request_id去查 feature store 的日志，发现 PostgreSQL 的pg_stat_statements里有一条 SQL 的total_time从 5ms 暴涨到 1200ms。原因是 DBA 误操作，删除了一个关键索引。解决方案：给所有核心查询语句加EXPLAIN ANALYZE自动巡检，每周跑一次，发现执行计划变化就告警。
  • 第二次：Kong log 正常，但 feature store 的 Redis log 里有大量timeout。查redis-cli info | grep latency，发现max_latency达到 800ms。原因是 Redis 的maxmemory-policy被设成了allkeys-lru，而我们的特征 key 都带时间戳，是“热数据”，LRU 淘汰时，它会疯狂扫描整个 key space 来找最久未用的 key，导致主线程卡顿。解决方案：把 policy 改成volatile-lru，并确保所有特征 key 都设置了合理的 TTL。
  • 第三次：所有日志都正常，但perf_analyzer测试单个请求就是慢。最后发现，是 Triton 的config.pbtxt里max_batch_size设成了 1024，而我们线上流量的平均 batch size 只有 8。Triton 为了凑够 1024，一直在 queue 里等，max_queue_delay_microseconds又设得太大（100ms）。解决方案：把max_batch_size降到 64，max_queue_delay_microseconds降到 5000，让 Triton 更积极地触发小 batch。

这三次教训告诉我们：延迟问题，90% 出在模型之外的依赖上。Triton 是最后一环，不是第一环。

5.2 问题：模型上线后，A/B 测试显示效果提升，但线上业务指标（如 GMV）反而下跌，为什么？

这是算法同学最怕的“指标悖论”。我们深度复盘过一个推荐模型的案例。离线评估 AUC +2.3%，线上 A/B 测试 CTR +1.8%，但最终 GMV -0.7%。根因藏在input的构造逻辑里。

注意：离线评估用的input，和线上实时推理用的input，必须是同一份数据源、同一套清洗逻辑。

我们发现，离线评估时，item_ids是从用户历史点击日志里取的“最近 100 个”，而线上实时推理时，item_ids是从当前页面的“曝光商品池”里取的“当前 20 个”。这两个集合的分布完全不同：历史点击池里，长尾商品占比高；曝光池里，头部商品占比高。模型在历史数据上训练，学到了“预测用户对长尾商品的兴趣”，但线上却让它预测“用户对头部商品的兴趣”，方向错了。解决方案：强制要求，所有用于离线评估的input，必须从线上实时特征服务的 mock 接口里取，mock 接口的行为（包括数据源、采样逻辑、过滤规则）必须和线上 100% 一致。我们把这个 mock 接口叫feature-store-staging，它和线上feature-store-prod共享同一套代码，只是连接不同的数据库。从此，再也没有出现过“离线准、线上歪”的问题。

5.3 问题：Kong 网关偶尔返回 502 Bad Gateway，但 Triton 服务明明是健康的，为什么？

502 是网关层的错误，说明 Kong 无法成功连接到 upstream（即 Triton）。但kubectl get pods显示 Triton Pod 状态是Running，kubectl logs也没报错。这种问题，99% 出在 Kubernetes 的 Service 和 Endpoints 上。

提示：kubectl get endpoints <triton-service-name>是排查 502 的第一命令。

我们遇到的真实案例：Triton 的 Deployment 里，Pod 的 readiness probe 配置错了。probe 的 path 是/v2/health/ready，但 Triton 的健康检查 endpoint 默认是/v2/health/ready，没错。问题出在 probe 的initialDelaySeconds设成了 5，而 Triton 启动加载一个大模型需要 12 秒。结果就是，Pod 启动 5 秒后，Kubernetes 就认为它 ready 了，把它加进了 Service 的 Endpoints，但此时 Triton 根本还没加载完模型，Kong 的请求打过去，自然 502。解决方案：把initialDelaySeconds改成15，并加上periodSeconds: 10，确保模型加载完成且稳定后再纳入流量。这个配置，必须和你最大的模型加载时间相匹配，不能拍脑袋。

5.4 问题：如何快速判断是模型 bug 还是数据漂移（Data Drift）？

模型效果下跌，是代码问题，还是世界变了？这是 MLOps 的终极哲学问题。我们的判断法则是“三秒法则”：

  • 第一秒：看Input/Output Distribution看板。如果user_id的分布、item_ids的长度分布、scores的分布，和上周同时间段相比，发生了显著偏移（用 KS 检验 p-value < 0.01），那大概率是数据漂移。比如，scores的均值从 0.45 降到 0.22，且分布变窄，说明模型输出越来越保守，可能是特征分布变了。
  • 第二秒：看Feature Store Water Level看板。如果evicted_keys突增，或者blks_read暴涨，说明特征获取环节出了问题，模型拿到的是脏数据或缺失数据。
  • 第三秒：看Trace Heatmap。如果慢请求都集中在某几个特定的user_id或item_id上，那很可能是这些 ID 对应的数据，在训练时没覆盖到，属于“长尾 case”，不是模型 bug，而是数据覆盖不足。

如果三秒都看不出问题，那就进入深度排查：用tritonclient直连 Triton，传入一个已知的、过去表现良好的样本，看输出是否异常。如果异常，就是模型 bug；如果正常，那就是线上数据流的某个环节（特征、预处理、后处理）出了问题。这个“三秒法则”，是我们团队新人入职必背的口诀，它把模糊的“感觉不对”，转化成了可执行的、有依据的排查动作。

5.5 问题：Triton 的 GPU 显存占用率一直 100%，但利用率（gpu_utilization）只有 5%，是显存泄漏吗？

不是泄漏，是 Triton 的显存管理策略。Triton 启动时，会向 GPU driver 申请一块巨大的显存池（默认是 GPU 总显存的 80%），用于存放模型权重、中间激活值、batch buffer 等。这块显存一旦申请，就不会释放给其他进程，nvidia-smi看到的就是 100%。但gpu_utilization是指 GPU 的 SM（Streaming Multiprocessor）的计算单元使用率，它反映的是“正在干活”的程度。显存占满但利用率低，说明 Triton 把显存都占着了，但没多少计算任务在跑，比如 batch size 太小，或者模型本身计算量不大（如一个简单的 LR 模型）。解决方案：调整config.pbtxt里的instance_group的count，减少实例数，从而减少总的显存申请量；或者，如果确定模型计算量小，可以给 Triton 加上--memory-growth参数，让它按需申请显存，而不是一次性占满。但要注意，--memory-growth会带来一点额外的内存管理开销，对超高吞吐场景要谨慎。

6. 个人实操心得