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

“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题里藏着一个被无数数据科学家反复咀嚼、又悄悄咽下的苦涩真相： Jupyter Notebook 从来就不是生产环境的起点，它只是问题被清晰定义前的草稿纸。 我在带团队做模型交付时发现，超过68%的项目延期，根本原因不在算法调优，而在于第4部分——也就是标题里这个“Part 4”——它不讲AUC怎么刷到0.92，而是直面一个没人愿意在周报里写的现实：你训练好的那个 .pkl 文件，能不能扛住每秒37次并发请求？当上游API突然返回空字段、下游数据库凌晨三点开始慢查询、监控告警邮件堆满收件箱时，你的模型是继续沉默地输出错误预测，还是能主动降级、打日志、发钉钉通知？这才是“Real World”的真实水位线。它面向的不是Kaggle排行榜，而是运维值班表、SLO协议书和客户投诉工单。所以Part 4的本质，是把“模型能力”翻译成“工程能力”，把“准确率”转化成“可用性”“可观测性”“可维护性”。它解决的是：如何让一个在本地GPU上跑通的PyTorch脚本，在没有你盯着的情况下，连续稳定运行720小时，且每次异常都能被快速定位。适合谁？刚从学校毕业、手握三篇顶会论文却连Dockerfile都写不全的算法工程师；也适合做了十年后端、第一次接手ML服务但搞不清为什么模型要“warm up”的架构师；更包括那些每天在“要不要重训模型”和“能不能先上线凑合用”之间反复横跳的产品经理。这不是教你怎么写代码，而是教你怎么让代码在真实世界里活下来。

2. 内容整体设计与思路拆解：为什么必须放弃“一键部署”的幻觉

2.1 核心逻辑：从“功能正确”到“系统可靠”的范式转移

很多团队在Part 4阶段栽的第一个跟头，就是误把“模型能跑通”等同于“服务能交付”。我见过最典型的案例：某电商推荐模型在测试环境用 flask run --host=0.0.0.0 --port=5000 启动后，前端调用返回了预期JSON，大家立刻开香槟庆祝“上线成功”。结果正式切流第一天，QPS刚过200，服务就开始503，日志里全是 OSError: [Errno 24] Too many open files 。问题出在哪？Flask默认的Werkzeug服务器是单线程开发模式，根本没做连接池、超时控制、资源回收。它只保证“功能正确”，但完全不考虑“系统可靠”。Part 4的设计起点，必须是 以生产SLO（Service Level Objective）为约束条件反向推导技术选型 。比如，如果你的业务要求P99延迟<200ms、可用性99.95%，那么你就不能选需要每次请求都加载GB级模型权重的方案；如果要求支持灰度发布和AB测试，那单体Flask服务就天然不满足。我们团队现在强制执行一条铁律：所有模型服务在进入Part 4前，必须先填写一份《生产就绪检查表》，其中第一项就是“明确列出3个核心SLO指标及当前基线值”，没填完不准进CI/CD流水线。这逼着算法同学在写 model.predict() 之前，先想清楚“这个predict要被谁调用？峰值多少QPS？容忍多长超时？失败了怎么兜底？”——这才是Part 4真正的设计原点。

2.2 方案选型背后的硬核权衡：为什么不用FastAPI？为什么不用Triton？

市面上关于ML服务化的教程，90%都在教你怎么用FastAPI包一层模型然后 uvicorn 跑起来。这没错，但它只覆盖了Part 4的10%。真正决定成败的，是那些藏在文档角落里的取舍。比如FastAPI+Uvicorn组合，优势是异步IO高并发、Pydantic校验强、OpenAPI文档自动生成——但它对GPU显存管理是黑盒。我们实测过：一个ResNet50模型在Uvicorn下处理1000个并发请求时，显存占用会缓慢爬升，3小时后触发OOM，而同样的模型用Triton Inference Server，显存始终稳定在初始值的±5%内。为什么？因为Triton内置了显存池化（memory pooling）和请求批处理（dynamic batching），它把1000个零散请求智能合并成10个大batch送进GPU，而Uvicorn只是把1000个Python线程排队塞给PyTorch。再比如模型格式：为什么坚持用ONNX而不是直接部署PyTorch .pt ？因为ONNX是跨框架中间表示，它剥离了PyTorch的Python运行时依赖，让模型可以脱离 torch==1.13.1 这种脆弱的版本锁。去年我们有个服务因安全补丁强制升级Python 3.11，结果PyTorch 1.12不兼容，整个推荐链路瘫痪47分钟；而同期用ONNX部署的风控模型，只改了一行 onnxruntime==1.16.0 就平滑过渡。这些选择没有标准答案，只有基于你业务场景的硬核算：算力成本、迭代速度、团队技能树、故障恢复时间（MTTR）。我们最终定下的技术栈是“Triton Inference Server + ONNX Runtime + Prometheus+Grafana监控”，不是因为它最炫，而是因为我们的模型更新频率是每周2次，GPU卡是A10，运维团队只会看Grafana面板不会debug Python GIL死锁——所有选型，都是向现实低头后的最优解。

2.3 架构分层：为什么必须把“模型服务”从“业务逻辑”中物理隔离

新手最容易犯的错，是把模型预测逻辑直接写进Spring Boot或Django的Controller里。比如电商下单接口里， orderService.createOrder() 后面紧跟 fraudModel.predict(order) 。这看似简洁，实则埋下三颗定时炸弹：第一，模型推理耗时（可能200ms）会拖垮整个下单链路（目标50ms），违反响应时间预算；第二，当模型服务不可用时，整个下单功能直接熔断，没有降级路径；第三，模型版本更新要重启整个订单服务，影响范围扩大10倍。Part 4的架构设计，核心原则是 物理隔离、契约先行、异步解耦 。我们强制要求所有模型服务必须作为独立微服务存在，通过gRPC或REST API暴露，且必须提供OpenAPI 3.0规范文档。业务系统调用时，必须经过统一的模型网关（Model Gateway），这个网关干三件事：1）路由到对应模型版本（v1/v2）；2）自动重试+熔断（Hystrix配置）；3）注入traceID和业务上下文。这样，当风控模型v2上线出问题，网关可以秒级切回v1，订单服务完全无感。更关键的是，网关层可以做统一的特征工程——比如所有调用都自动补全用户最近7天活跃度分，避免每个业务方重复计算。这种分层不是增加复杂度，而是把“模型不稳定”这个不确定性，封装在可控的边界内。就像汽车的ABS系统，它不参与驾驶决策，但能在轮胎打滑时独立介入，保住整车安全底线。

3. 核心细节解析与实操要点：那些文档里绝不会写的魔鬼参数

3.1 Triton配置文件 config.pbtxt 的12个生死参数详解

Triton的威力全藏在 config.pbtxt 这个看似简单的文本文件里。但它的每一行，都可能成为压垮服务的最后一根稻草。我们线上踩过的坑，90%源于这里配置不当。下面逐条拆解最关键的12个参数，附真实生产值和血泪教训：

参数名	生产推荐值	为什么这么设	不这么设的后果
max_batch_size	64	Triton批处理上限，需匹配GPU显存和模型输入shape。ResNet50输入[1,3,224,224]时，64 batch约占用12GB显存（A10）	设为0：禁用批处理，吞吐量暴跌60%；设为128：显存溢出OOM
preferred_batch_size	[16,32,64]	告诉Triton优先合并哪些尺寸的请求。我们流量80%是16/32 batch，所以放前面	不设置：Triton随机合并，P99延迟抖动剧烈（实测从180ms跳到420ms）
dynamic_batching	true	必开！否则无法实现动态批处理	关闭：每个请求单独进GPU，显存利用率<30%，浪费钱
instance_group	[{"kind":"KIND_GPU","count":1}]	显式指定GPU实例数。A10卡必须写 count:1 ，不能省略	省略：Triton默认 KIND_CPU ，模型在CPU跑，延迟暴涨10倍
model_warmup	name:"warmup" batch_size:1	预热请求，防止首请求冷启动延迟。我们加了3个warmup：1/16/64 batch	不预热：首请求延迟>2s（加载权重+显存分配），触发业务超时
input / output format	FORMAT_NCHW	图像模型必须显式声明，否则Triton按NHWC解析导致结果全错	不声明：模型输出乱码，但日志无报错，排查3天才发现
version_policy	latest { num_versions: 2 }	只保留最新2个模型版本，自动清理旧版节省磁盘	不限制：磁盘爆满，Triton拒绝加载新模型
default_model_filename	"model.onnx"	显式指定文件名，避免Triton扫描所有.onnx文件耗时	不指定：启动时间从12s延长到47s（目录有23个模型文件）
optimization execution_accelerators	{"gpu_execution_accelerator": [{"name": "tensorrt"}]}	对ONNX模型启用TensorRT加速，实测ResNet50提速2.3倍	不启用：纯ONNX Runtime推理，吞吐量仅TensorRT的43%
metrics enable	true	开启Prometheus指标暴露，否则监控告瞎	关闭：无法知道GPU利用率、请求队列长度等关键指标
log verbose	0	生产环境必须关VERBOSE，否则日志爆炸（单日120GB）	开启：磁盘IO打满，服务假死
rate_limiter mode	"execution_count"	按GPU执行次数限流，比按请求数更精准	用 request_count ：小batch请求被误限，大batch却超载

提示： config.pbtxt 修改后必须重启Triton服务才生效，但你可以用 tritonserver --model-repository /models --model-control-mode explicit 启动，然后用 curl -X POST http://localhost:8000/v2/repository/models/fraud_model/load 热加载单个模型，避免全局重启。

3.2 特征服务（Feature Store）不是可选项，而是生存必需品

很多人以为Part 4只管模型推理，但真正的地狱在特征层面。我们曾有个信贷风控模型，离线训练用的是“用户近30天交易笔数”，但线上服务时，业务方传来的却是“当天实时交易笔数”。结果模型在测试集AUC 0.89，线上bad rate飙升到37%。问题根源？ 训练和推理的特征口径不一致（Training-Serving Skew） 。Part 4必须建立统一的特征服务，它不是锦上添花，而是防止模型在生产环境“精神分裂”的安全阀。我们采用Feast作为Feature Store，但关键不在工具，而在设计哲学：所有特征必须通过“特征视图（Feature View）”抽象，且每个视图强制绑定两个实体：1） 离线来源 （如Hive表 user_daily_stats ）；2） 在线存储 （如Redis集群）。当算法同学定义 feature_view = FeatureView(name="user_stats", entities=["user_id"], ttl=timedelta(hours=1)) 时，Feast会自动生成两套代码：离线部分从Hive拉取历史数据生成训练样本；在线部分监听Kafka实时流，把最新统计写入Redis。业务系统调用时，只需 get_online_features(feature_refs=["user_stats:transaction_count"], entity_rows=[{"user_id": "u123"}]) ，Feast自动从Redis读取，毫秒级返回。这样，训练和推理永远用同一套特征逻辑，彻底消灭skew。更重要的是，Feast的 materialization 机制支持按需刷新——比如每天凌晨2点批量更新用户月度特征，白天实时更新分钟级特征。我们线上所有模型服务，都必须通过Feast SDK获取特征，禁止任何硬编码SQL或本地缓存。这条红线，是我们用3次重大事故换来的教训。

3.3 模型监控的三大死亡地带：你看到的指标，可能正在说谎

部署完服务，90%的人只看一个指标： HTTP 200 Rate 。这就像只检查汽车仪表盘的油量灯，却不管发动机温度、胎压、ABS状态。Part 4的监控必须穿透HTTP层，直击模型本质。我们划出三个“死亡地带”，每个地带都配了专用探测器：

死亡地带一：数据漂移（Data Drift）
模型失效的第一征兆，不是准确率下降，而是输入数据分布突变。比如风控模型突然收到大量 age=0 的用户（爬虫伪造），或推荐模型输入的 user_embedding 向量L2范数集体缩小50%（特征工程bug）。我们用Evidently构建实时数据质量看板，每10分钟采样1000个请求，计算KS检验p-value。当 p-value < 0.01 持续5分钟，自动触发钉钉告警：“检测到user_age分布显著偏移，请检查上游数据源”。注意：不能只看单个字段，要监控字段间相关性——比如 income 和 loan_amount 的皮尔逊系数从0.68掉到0.21，说明用户画像逻辑可能被破坏。

死亡地带二：概念漂移（Concept Drift）
数据没变，但标签含义变了。典型例子：疫情期“用户是否购买口罩”这个标签，从“健康行为”变成了“恐慌行为”，模型学到的模式瞬间失效。我们用ADWIN算法（自适应窗口）监控在线AUC滑动窗口，当AUC连续1000个样本下降超5%，判定概念漂移。此时不报警，而是自动启动影子模式（Shadow Mode）：新请求同时走线上模型和备用模型，对比预测差异。差异率>15%持续1小时，则触发模型重训流程。

死亡地带三：推理性能陷阱
P99 latency 达标，不代表服务健康。我们发现一个致命陷阱：Triton的 nv_gpu_utilization 指标显示GPU利用率<20%，但 queue_length （请求队列长度）却持续>50。这意味着什么？GPU在空转，但请求在排队。根因是 max_queue_delay_microseconds （最大排队延迟）设得太小（默认100000，即100ms），Triton宁愿丢弃请求也不愿让队列过长。我们把它调到 5000000 （5秒），并配合 priority_queue_policy 按业务优先级排序——支付类请求永远插队，推荐类请求可等待。这样，P99延迟仍<200ms，但成功率从92%提升到99.99%。

注意：所有监控告警必须带“可操作性”。比如“data drift detected”告警，必须附带：1）漂移字段清单；2）最近1小时该字段分布直方图；3）建议检查的上游数据表名。不能只说“有问题”，要说“去哪查、查什么”。

4. 实操过程与核心环节实现：从本地Notebook到K8s集群的7步落地

4.1 Step 0：环境准备——为什么必须用NVIDIA Container Toolkit

在开始任何部署前，先确认宿主机已安装NVIDIA Container Toolkit。这不是可选项，而是Triton运行的基石。很多团队卡在第一步： docker run --gpus all nvcr.io/nvidia/tritonserver:23.09-py3 tritonserver --model-repository /models 启动失败，报错 Failed to initialize CUDA driver API 。原因99%是没装Container Toolkit。它负责把宿主机的NVIDIA驱动映射进容器，没有它，Docker容器根本看不到GPU。安装命令极简：

# Ubuntu 20.04+
curl -sL https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add -
curl -sL https://nvidia.github.io/nvidia-docker/ubuntu20.04/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list
sudo apt-get update && sudo apt-get install -y nvidia-docker2
sudo systemctl restart docker

验证是否成功： docker run --rm --gpus all nvidia/cuda:11.8.0-base-ubuntu20.04 nvidia-smi 。如果看到GPU列表，说明环境就绪。这一步看似简单，但我们团队新人平均耗时2.3小时，因为文档里总把它和Docker CE安装混在一起写。记住： 先装Docker CE，再装NVIDIA Container Toolkit，顺序错了全白搭。

4.2 Step 1：模型转换——ONNX不是终点，而是起点

把PyTorch模型转ONNX，网上教程一堆，但90%漏掉一个致命细节： 必须用训练时的相同 torch.set_grad_enabled(False) 状态导出 。我们曾有个模型，训练时用 with torch.no_grad(): ，但导出时忘了加，结果ONNX模型里残留了梯度计算节点，Triton加载时报 Unsupported op: Gradient 。正确姿势：

import torch
import torch.onnx

# 加载训练好的模型
model = torch.load("best_model.pth")
model.eval()  # 必须设为eval模式！

# 创建dummy input，shape必须和线上请求一致
dummy_input = torch.randn(1, 3, 224, 224)  # batch=1, channel=3, h=224, w=224

# 导出ONNX，关键参数一个都不能少
torch.onnx.export(
    model,
    dummy_input,
    "model.onnx",
    export_params=True,        # 存储模型权重
    opset_version=14,          # ONNX opset版本，Triton 23.09支持14
    do_constant_folding=True,  # 优化常量
    input_names=['input'],     # 输入名，必须和config.pbtxt一致
    output_names=['output'],   # 输出名，必须和config.pbtxt一致
    dynamic_axes={
        'input': {0: 'batch_size'}, 
        'output': {0: 'batch_size'}
    }  # 支持动态batch，否则Triton无法批处理
)

导出后，用 onnxsim 简化模型（减少冗余节点）：

pip install onnx-simplifier
python -m onnxsim model.onnx model_sim.onnx

最后，用 onnx.checker.check_model() 验证：

import onnx
onnx_model = onnx.load("model_sim.onnx")
onnx.checker.check_model(onnx_model)  # 无报错才算合格

这三步做完，才是真正的ONNX就绪。少一步，Triton加载时就可能静默失败。

4.3 Step 2：构建Triton模型仓库——目录结构是门玄学

Triton对模型目录结构有严格约定，错一个字母服务就起不来。我们线上用的标准结构：

/models
├── fraud_model
│   ├── 1
│   │   ├── model.onnx
│   │   └── config.pbtxt
│   └── 2
│       ├── model.onnx
│       └── config.pbtxt
└── recommendation_model
    └── 1
        ├── model.onnx
        └── config.pbtxt

关键规则：

• 模型名（ fraud_model ）必须全小写+下划线，不能有空格或大写字母；
• 版本号（ 1 , 2 ）必须是纯数字文件夹，不能叫 v1 或 version_1 ；
• config.pbtxt 必须放在每个版本文件夹内，不能放在模型根目录；
• model.onnx 文件名必须和 config.pbtxt 里 default_model_filename 一致。

我们曾因把 fraud_model 写成 Fraud_Model ，Triton启动时日志只有一行 E0101 00:00:00.000000 1 model_repository_manager.cc:1198] failed to load 'Fraud_Model' ，没有任何具体错误。排查3小时才发现是大小写问题。所以， 所有模型名、文件名、配置名，全部用 lowercase_with_underscores ，这是血换来的规范。

4.4 Step 3：启动Triton服务——生产环境必须加的5个flag

开发环境 tritonserver --model-repository /models 能跑，但生产环境必须加这5个flag，缺一不可：

tritonserver \
  --model-repository=/models \
  --model-control-mode=explicit \  # 允许热加载模型
  --http-port=8000 \
  --grpc-port=8001 \
  --metrics-port=8002 \
  --log-verbose=0 \  # 关闭VERBOSE日志
  --strict-model-config=false \  # 允许config.pbtxt缺失某些字段
  --cuda-memory-pool-byte-size=0:2000000000 \  # 为GPU 0预分配2GB显存池
  --allow-gpu-memory-growth=true \  # 显存按需增长，避免OOM
  --backend-directory=/opt/tritonserver/backends \
  --repository-agent-directory=/opt/tritonserver/repository_agents

重点解释三个易错点：

• --cuda-memory-pool-byte-size=0:2000000000 ：为GPU 0预分配2GB显存池。不加这个，Triton启动时显存占用只有几十MB，但第一个请求进来会瞬间申请几GB，触发Linux OOM Killer杀进程；
• --allow-gpu-memory-growth=true ：允许显存按需增长。不加这个，Triton会尝试占满整张卡显存（比如A10的24GB），导致其他服务无法使用；
• --strict-model-config=false ：允许 config.pbtxt 里缺少非必需字段（如 version_policy ）。开发时方便，但生产环境建议写全。

启动后，用 curl http://localhost:8000/v2/health/ready 检查服务状态，返回 {"ready": true} 才算成功。

4.5 Step 4：编写客户端SDK——别用手写curl，用官方gRPC

调用Triton，千万别用 curl -X POST http://... 。HTTP API只适合调试，生产必须用gRPC，理由有三：1）gRPC二进制协议比JSON轻量，网络开销小30%；2）支持流式响应，适合大模型；3）内置超时、重试、负载均衡。我们封装了一个Python SDK：

import tritonclient.grpc as grpcclient
from tritonclient.utils import InferenceServerException

class TritonClient:
    def __init__(self, url="localhost:8001"):
        self.client = grpcclient.InferenceServerClient(url=url, verbose=False)
    
    def predict(self, model_name, inputs, outputs):
        # 构建输入tensor
        input_tensors = []
        for name, data in inputs.items():
            tensor = grpcclient.InferInput(name, data.shape, "FP32")
            tensor.set_data_from_numpy(data)
            input_tensors.append(tensor)
        
        # 构建输出tensor
        output_tensors = []
        for name in outputs:
            output_tensors.append(grpcclient.InferRequestedOutput(name))
        
        try:
            # 调用推理
            results = self.client.infer(
                model_name=model_name,
                inputs=input_tensors,
                outputs=output_tensors,
                client_timeout=10.0  # 10秒超时
            )
            return {name: results.as_numpy(name) for name in outputs}
        except InferenceServerException as e:
            # 统一错误处理
            if "Request timeout" in str(e):
                raise TimeoutError("Triton inference timeout")
            else:
                raise RuntimeError(f"Triton error: {e}")

# 使用示例
client = TritonClient("triton-service.default.svc.cluster.local:8001")  # K8s内网地址
inputs = {"input": np.random.randn(1, 3, 224, 224).astype(np.float32)}
outputs = client.predict("fraud_model", inputs, ["output"])

这个SDK把重试、超时、错误码转换都封装好了，业务方调用时只需关心 inputs 和 outputs ，不用懂gRPC底层。我们强制所有业务服务都引用这个SDK，杜绝手写HTTP请求。

4.6 Step 5：Kubernetes部署——StatefulSet还是Deployment？

Triton服务在K8s里该用StatefulSet还是Deployment？答案是： Deployment，但必须加 hostNetwork: true 和 shareProcessNamespace: true 。StatefulSet用于有状态应用（如数据库），而Triton是无状态的——模型文件存在外部存储（NFS/S3），状态全在内存。用StatefulSet反而增加复杂度。但Deployment有两大坑：
1） hostNetwork: true ：Triton需要直接访问宿主机GPU设备，必须用hostNetwork模式，否则容器内 nvidia-smi 看不到GPU；
2） shareProcessNamespace: true ：让Triton主进程能监控子进程（如TensorRT引擎），否则 kill -9 主进程时子进程变成僵尸。

我们的K8s YAML精简版：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: triton-server
spec:
  replicas: 2
  selector:
    matchLabels:
      app: triton-server
  template:
    metadata:
      labels:
        app: triton-server
    spec:
      hostNetwork: true  # 关键！
      shareProcessNamespace: true  # 关键！
      containers:
      - name: triton
        image: nvcr.io/nvidia/tritonserver:23.09-py3
        args: [
          "tritonserver",
          "--model-repository=/models",
          "--http-port=8000",
          "--grpc-port=8001",
          "--metrics-port=8002",
          "--log-verbose=0"
        ]
        ports:
        - containerPort: 8000
        - containerPort: 8001
        - containerPort: 8002
        volumeMounts:
        - name: models
          mountPath: /models
      volumes:
      - name: models
        nfs:
          server: nfs-server.default.svc.cluster.local
          path: /triton-models

注意： replicas: 2 不是为了负载均衡，而是为了高可用。Triton本身不支持水平扩展（模型加载在内存），多副本是靠K8s Service做轮询，单个副本挂了流量自动切到另一个。

4.7 Step 6：CI/CD流水线——模型发布的最后一道闸门

模型更新不能靠 kubectl replace -f triton.yaml 手动操作。我们用GitOps模式，把模型文件、 config.pbtxt 、版本号全部纳入Git仓库，CI/CD流水线自动触发部署。流程如下：
1）算法同学提交PR，包含： /models/fraud_model/3/model.onnx 和 /models/fraud_model/3/config.pbtxt ；
2）CI流水线（GitHub Actions）自动执行：

• onnx.checker.check_model() 验证ONNX有效性；
• tritonserver --model-repository /tmp/models --model-control-mode=none 启动Triton验证配置；
• 发送10个测试请求，验证 HTTP 200 和输出shape；
  3）全部通过后，自动 git push 到生产分支；
  4）Argo CD监听生产分支变更，自动 kubectl apply 更新K8s资源。

最关键的是 灰度发布策略 ：新模型上线时，先只对1%流量生效。我们在Triton前加了一层Nginx，根据请求Header中的 x-canary: true 转发到新模型，否则走老模型。这样，即使新模型有bug，影响面也控制在1%。我们规定：所有模型更新必须经过72小时灰度观察期，监控指标（延迟、错误率、数据漂移）全部达标，才能全量。

5. 常见问题与排查技巧实录：那些凌晨三点救了命的命令

5.1 问题速查表：从现象到根因的10分钟定位法

现象	快速定位命令	根因概率	解决方案
curl http://localhost:8000/v2/health/ready 返回 {"ready": false}	kubectl logs -f triton-pod 查看启动日志	70%	检查 config.pbtxt 语法错误（用 tritonserver --model-repository /models --strict-model-config=true 验证）
Triton启动后 nvidia-smi 显示GPU占用0%，但 queue_length 持续>100	curl http://localhost:8002/metrics 查看 nv_inference_request_success	65%	max_queue_delay_microseconds 太小，调大到5000000
模型加载成功，但 curl -X POST http://localhost:8000/v2/models/fraud_model/infer 返回400	curl http://localhost:8000/v2/models/fraud_model 查看模型状态	80%	输入tensor name和 config.pbtxt 里 input 定义不一致
P99延迟正常，但偶发2s超时	kubectl top pod 查看pod CPU/MEM	55%	宿主机CPU争抢，给Triton pod加 resources.limits.cpu: "4"
tritonserver 进程占用GPU显存，但 nvidia-smi 看不到进程	lsof -i :8000 查看端口占用	90%	Triton没正常退出，残留进程占着显存， kill -9 $(pgrep tritonserver)
模型输出全是0或NaN	python -c "import onnxruntime; sess=onnxruntime.InferenceSession('model.onnx'); print(sess.get_inputs())"	75%	ONNX模型输入shape和 config.pbtxt 里 dims 不匹配
K8s pod状态 CrashLoopBackOff	kubectl describe pod triton-pod 查看Events	85%	hostNetwork: true 没加，或NVIDIA Container Toolkit未安装
curl http://localhost:8002/metrics 返回空	curl http://localhost:8002/metrics 加 -v 看HTTP头	60%	--metrics-port 没暴露，或防火墙拦截
Triton日志里大量 failed to get model config	find /models -name "config.pbtxt" -exec cat {} \;	95%	config.pbtxt 文件权限不对（必须644），或路径错误
模型热加载失败： curl -X POST http://localhost:8000/v2/repository/models/fraud_model/load 返回400	curl http://localhost:8000/v2/repository/index	70%	模型版本文件夹名不是纯数字（如 v1 应改为 1 ）

实操心得：我们把这10条命令做成一个 triton-debug.sh 脚本，放在所有运维同学的 $PATH 里。遇到问题，直接 triton-debug ，按提示输入现象编号，脚本自动执行对应命令并高亮关键信息。新人5分钟就能完成基础排查。

5.2 深度排查：用 perf 抓取GPU kernel级瓶颈

当常规监控找不到问题时，就得上硬件级分析。我们曾遇到一个诡异问题：Triton服务P99延迟稳定在180ms，但每小时有3分钟突然飙到800ms。 nvidia-smi 显示GPU利用率始终<30%， top 看CPU也正常。最后用 perf 抓到了真相：

# 在Triton pod里执行
apt-get update && apt-get install -y linux-perf-5.4
perf record -e 'nvtx:*' -p $(pgrep tritonserver) sleep 60
perf script > perf.out

分析 perf.out 发现，每小时固定时刻， nvtx::trt_engine::enqueue 函数调用耗时突增。根因是TensorRT引擎的CUDA stream同步等待。解决方案：在 config.pbtxt 里加 optimization { execution_accelerators { gpu_execution_accelerator: [{name: "tensorrt", parameters: { "precision_mode": "FP16" }}] } } ，强制FP16精度，减少kernel launch次数。这个技巧，是我们在NVIDIA工程师指导下挖出来的，普通文档里根本不会提。

5.3 故障演练：定期制造灾难