Triton+KServe构建高可用机器学习服务的生产实践

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

“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题本身就像一句暗号，专为那些在Jupyter里调通了模型、画出了漂亮ROC曲线、却在部署时被现实狠狠绊了一跤的工程师准备的。它不是讲怎么写model.fit()，而是讲当你的模型第一次被业务系统调用、第一次在凌晨三点因上游数据格式突变而报错、第一次因为GPU显存碎片化导致推理延迟飙升300%时，你该抓哪根救命稻草。我带过六支AI工程团队，亲手把四十多个模型从研究态推到线上服务，最深的体会是：模型的准确率只决定它能不能上线，而它的可观测性、弹性伸缩能力和故障自愈逻辑，才真正决定它能在线上活多久。Part 4 这个编号很关键——它意味着前面三部分已经铺完了数据管道、特征工程和模型训练框架，现在要直面那个所有教科书都轻描淡写的终极问题：如何让一个在本地24G显存上跑得飞起的PyTorch模型，在Kubernetes集群里稳定扛住每秒800次并发请求，同时不把运维同事的告警群炸成烟花秀。这不是DevOps的附加题，而是机器学习落地的必答题。如果你正卡在模型API化之后的监控盲区、版本混乱、资源争抢或灰度失败无法回滚这些具体痛点上，这篇就是为你写的实操手记，没有理论空谈，只有我在金融风控、电商推荐、工业质检三个场景里反复验证过的硬核方案。

2. 核心设计思路拆解：为什么放弃“一键部署”，选择分层解耦架构

2.1 拒绝黑盒式部署：从“能跑”到“可控”的思维跃迁

很多团队在Part 3结束时，会本能地选择flask + pickle这种看似最快的路径：把训练好的模型dump成文件，用Flask包一层HTTP接口，扔进Docker容器就完事。我试过——在测试环境稳如老狗，上线第三天凌晨两点，监控显示P99延迟从120ms跳到2.3秒，日志里只有一行CUDA out of memory，而nvidia-smi显示GPU显存占用率只有65%。查了六小时才发现，是上游服务批量推送了10倍于预期的batch size，而我们的Flask服务没做任何请求体校验和熔断。这暴露了黑盒部署的根本缺陷：它把模型、运行时、网络协议、资源调度全部揉在一个进程里，故障时无法定位是算法逻辑问题、序列化瓶颈、还是K8s调度策略失灵。Part 4的设计起点，就是把这团乱麻彻底拆开。我们采用四层解耦架构：最上层是协议网关（gRPC/HTTP），中间是模型服务抽象层（Model Server），下层是运行时沙箱（Triton/ONNX Runtime），最底层是基础设施编排（K8s Operator）。每一层都有明确边界和独立健康检查点。比如当延迟飙升时，我们可以先看网关层QPS是否异常→再查服务层模型加载耗时→最后定位到沙箱层GPU kernel启动时间。这种可诊断性，比单纯追求部署速度重要十倍。

2.2 为什么选Triton而非自研服务：省下的不是代码量，是十年踩坑经验

在模型服务层选型时，团队曾激烈争论过自研vs Triton。支持自研的理由很实在：我们模型结构简单，用PyTorch原生torch.jit.trace导出后，自己写个C++加载器性能更好。但当我把过去三年线上事故归因表投影到会议室白板上时，反对声就小了——其中73%的P0级故障，根源都在模型加载阶段：TensorRT引擎缓存失效导致首请求延迟超5秒、不同CUDA版本间cuBLAS库ABI不兼容、动态shape输入触发隐式重编译。Triton的价值，根本不在它多快，而在于它把NVIDIA十年积累的GPU推理工程经验，封装成了标准化的配置项。比如它的config.pbtxt文件里，dynamic_batching参数不是简单开关，而是内置了基于滑动窗口的批处理调度器，能自动合并10ms内到达的请求；model_repository目录结构强制要求按版本号分层，天然规避了“覆盖式更新”导致的A/B测试污染。我们实测过：同样一个BERT-base模型，在自研服务中需要200+行C++代码处理内存池预分配和stream同步，而在Triton里只需在配置文件里写max_batch_size: 32和instance_group [ { count: 2, gpus: [0] } ]。省下的不是代码行数，是避免重蹈NVIDIA工程师们已经踩过的所有GPU推理深坑。

2.3 K8s Operator而非Helm Chart：当模型成为一等公民

很多人用Helm Chart管理ML服务，觉得够用了。但当我们开始做模型灰度发布时，问题来了：Helm只能控制Deployment副本数，而模型灰度需要的是“同一时刻，v1.2版本处理30%流量，v1.3版本处理70%流量，且v1.3必须在GPU资源充足时才扩容”。Helm做不到这点，因为它不理解“模型版本”这个概念。我们转向Kubeflow KFServing的继任者KServe，核心是它的Custom Resource Definition（CRD）InferenceService。这个CRD把模型抽象成K8s原生资源，你可以像操作Pod一样kubectl get isvc查看模型状态，用kubectl patch动态修改流量切分比例。更关键的是，KServe Operator能监听InferenceService资源变更，自动触发Triton模型仓库的热重载——不需要重启Pod，模型新版本就能生效。我们在电商大促前夜做过压力测试：通过kubectl patch将推荐模型v2.1的流量权重从0%瞬间拉到100%，整个过程耗时1.8秒，期间P95延迟波动小于5ms。这种原子性操作能力，是Helm永远无法提供的，因为它把模型从“部署产物”升级为了“运行时实体”。

3. 核心细节解析与实操要点：让每个配置项都经得起生产环境拷问

3.1 Triton配置文件的魔鬼细节：别让config.pbtxt毁掉三个月努力

Triton的config.pbtxt文件表面简单，但每个字段背后都是血泪教训。以我们部署的ResNet50图像分类模型为例，初始配置如下：

name: "resnet50" platform: "pytorch_libtorch" max_batch_size: 32 input [ { name: "INPUT__0" data_type: TYPE_FP32 dims: [ 3, 224, 224 ] } ] output [ { name: "OUTPUT__0" data_type: TYPE_FP32 dims: [ 1000 ] } ]

上线后发现GPU利用率长期低于40%。排查发现max_batch_size: 32只是理论上限，实际请求中92%的batch size为1，Triton默认的动态批处理策略（dynamic_batching）未启用。补上这段后，吞吐量直接翻倍：

dynamic_batching [ { max_queue_delay_microseconds: 1000 } ]

但新的问题又来了：max_queue_delay_microseconds: 1000（1毫秒）太激进，导致小batch请求等待超时。我们做了AB测试，最终选定5000微秒——这个值是通过分析线上请求间隔分布得出的：P95请求间隔为3.2ms，设为5ms既能保证大部分请求被合并，又不会引入明显延迟。另一个致命细节是instance_group配置。最初我们写instance_group [ { count: 4 } ]，以为能启4个模型实例。结果监控显示GPU显存只用了50%，而CPU使用率爆表。原因在于：Triton默认把所有实例放在同一GPU上，而PyTorch模型实例是CPU密集型的。改成instance_group [ { count: 2, gpus: [0] }, { count: 2, gpus: [1] } ]，显存利用率立刻升到85%，CPU负载均衡。这些参数没有文档能告诉你最优值，只有在真实流量下用tritonserver --model-repository /models --log-verbose 1开启详细日志，盯着Batcher和Instance模块的输出才能调准。

3.2 KServe InferenceService的流量切分陷阱：权重不是百分比，是整数比

KServe的流量切分语法看着很友好：

apiVersion: "kserve.io/v1beta1" kind: "InferenceService" metadata: name: "resnet50" spec: predictor: canaryTrafficPercent: 30 componentSpecs: - spec: containers: - image: nvcr.io/nvidia/tritonserver:23.04-py3 args: ["--model-repository=/mnt/models"] traffic: - name: "v1" namespace: "default" serviceName: "resnet50-predictor-default" percent: 70 - name: "v2" namespace: "default" serviceName: "resnet50-predictor-canary" percent: 30

但这里有个反直觉的坑：percent字段不是浮点数，而是整数，且所有版本的percent之和必须严格等于100。当你想做灰度时，不能写v1: 99, v2: 1，因为KServe会拒绝创建——它要求最小粒度是1%。更麻烦的是，canaryTrafficPercent和traffic里的percent是两套独立系统，如果同时设置，后者会覆盖前者。我们在金融风控场景吃过亏：想用canaryTrafficPercent: 5快速验证新模型，结果发现老模型流量没降下来。查源码才明白，canaryTrafficPercent只是创建canary版本的快捷方式，真正的流量控制必须走traffic字段。现在我们的标准流程是：先用kubectl apply -f v1.yaml部署基线版本，再用kubectl patch isvc resnet50 --type='json' -p='[{"op": "replace", "path": "/spec/predictor/traffic", "value": [{"name":"v1","percent":95},{"name":"v2","percent":5}]}]'动态切流。这样既避免了YAML文件冲突，又能用GitOps记录每次切流操作。

3.3 模型版本管理的物理隔离：为什么不用Git LFS存模型文件

很多团队图省事，把.pt或.onnx模型文件用Git LFS提交到代码仓库。这是灾难的开始。我们曾有个项目，模型文件大小12GB，每次CI构建都要下载完整LFS对象，导致流水线平均耗时从8分钟涨到47分钟。更糟的是，当需要回滚到v1.7版本时，发现Git LFS的git checkout v1.7命令会静默失败——因为v1.7对应的LFS指针文件被后续提交覆盖了。正确的做法是建立物理隔离的模型仓库。我们用MinIO搭建私有对象存储，目录结构严格遵循<model-name>/<version>/<framework>/model.<ext>，例如resnet50/v2.3/pytorch/model.pt。KServe的InferenceService通过storageUri字段直接引用这个路径：

spec: predictor: model: storageUri: "s3://ml-models/resnet50/v2.3/pytorch"

这样做的三大好处：第一，模型文件和代码解耦，前端工程师改UI不影响模型部署；第二，MinIO的版本控制功能可以追溯每次模型上传；第三，也是最关键的——模型文件的权限可以精细控制。比如给测试环境的KServe ServiceAccount只授予resnet50/v2.3/*的读权限，而禁止访问resnet50/v2.4/*，从根源上防止测试环境误用未验证模型。这套机制让我们在最近一次合规审计中，顺利通过了“模型版本可追溯性”这一项。

4. 实操全流程：从本地调试到线上灰度的七步通关

4.1 第一步：本地Triton服务验证（离线环境必备）

在把模型扔进K8s前，必须在本地100%验证Triton服务行为。我们用Docker Compose搭建最小闭环：

# docker-compose.yml version: '3.8' services: triton: image: nvcr.io/nvidia/tritonserver:23.04-py3 ports: - "8000:8000" # HTTP - "8001:8001" # GRPC - "8002:8002" # Metrics volumes: - ./models:/models command: ["--model-repository=/models", "--log-verbose=1"] client: build: ./client depends_on: [triton]

关键动作不是跑通curl，而是用Triton自带的perf_analyzer压测：

perf_analyzer -m resnet50 -u localhost:8000 --concurrency-range 1:32:2 \ --input-data ./input_data.json --measurement-interval 10000

这个命令会生成详细的吞吐量（infer/sec）和延迟（p95 latency）报告。我们设定硬性阈值：P95延迟必须≤150ms，吞吐量必须≥300 infer/sec。如果未达标，立即停止后续流程——因为K8s环境只会更差。曾经有个模型在本地perf_analyzer里P95是142ms，上线后变成210ms，追查发现是K8s节点上的NVMe SSD IOPS不足，导致模型文件加载慢。这个环节省下的排查时间，远超本地调试多花的半小时。

4.2 第二步：KServe CRD安装与命名空间准备

KServe的安装不是kubectl apply -f kserve.yaml就完事。我们发现官方Helm Chart在多租户场景下有严重缺陷：它默认把ClusterServingRuntime资源全局安装，导致不同团队的模型互相干扰。正确姿势是分命名空间安装：

# 创建专用命名空间 kubectl create ns kserve-system # 安装KServe核心组件（不含ClusterServingRuntime） helm install kserve kserve/kserve --namespace kserve-system \ --set global.istioEnabled=false \ --set kserve.enabled=true \ --set knative.enabled=false # 为业务团队创建独立命名空间 kubectl create ns ml-team-a kubectl label ns ml-team-a serving.kserve.io/inferenceservice=enabled

重点在最后一行label——KServe Operator只监听打了这个label的命名空间。这样ml-team-a的工程师只能看到自己命名空间下的InferenceService，无法误操作其他团队的模型。我们还额外加了RBAC限制：

# rbac.yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: namespace: ml-team-a name: isvc-manager rules: - apiGroups: ["kserve.io"] resources: ["inferenceservices"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: isvc-manager-binding namespace: ml-team-a subjects: - kind: ServiceAccount name: default namespace: ml-team-a roleRef: kind: Role name: isvc-manager apiGroup: rbac.authorization.k8s.io

这套权限体系让每个团队像管理自己的数据库一样管理模型服务，彻底告别“谁都能删Production模型”的噩梦。

4.3 第三步：模型仓库自动化同步（GitOps驱动）

模型文件不能手动aws s3 cp上传。我们用Argo CD实现GitOps驱动的模型同步。在Git仓库中建models/目录，里面放YAML文件：

# models/resnet50-v2.3.yaml apiVersion: v1 kind: ConfigMap metadata: name: resnet50-v2.3-manifest data: model_uri: "s3://ml-models/resnet50/v2.3/pytorch" framework: "pytorch" input_shape: "[1,3,224,224]"

Argo CD监听这个目录，一旦有新文件提交，就触发一个K8s Job：

# job-template.yaml apiVersion: batch/v1 kind: Job metadata: name: sync-resnet50-v2.3 spec: template: spec: containers: - name: sync image: minio/mc command: ['sh', '-c'] args: - | mc alias set models http://minio:9000 $MINIO_ROOT_USER $MINIO_ROOT_PASSWORD; mc cp /tmp/model.pt models/ml-models/resnet50/v2.3/pytorch/; volumeMounts: - name: model-file mountPath: /tmp/model.pt subPath: model.pt volumes: - name: model-file configMap: name: resnet50-v2.3-manifest items: - key: model_uri path: model.pt

这个Job会把ConfigMap里定义的模型文件同步到MinIO。整个过程完全自动化，且每次同步都有Git提交记录，满足审计要求。我们甚至把模型训练流水线的最后一步，设为自动生成这个YAML文件并推送到Git——模型诞生那一刻，部署流程就自动启动了。

4.4 第四步：InferenceService声明式创建（含健康检查）

创建InferenceService时，必须包含端到端健康检查。以下是我们生产环境的标准模板：

apiVersion: "kserve.io/v1beta1" kind: "InferenceService" metadata: name: "resnet50" annotations: # 启用Prometheus指标导出 prometheus.io/scrape: "true" prometheus.io/port: "8002" spec: predictor: # 指定GPU资源请求 containerConcurrency: 10 minReplicas: 2 maxReplicas: 10 serviceAccountName: "kserve-sa" containers: - name: kserve-container image: nvcr.io/nvidia/tritonserver:23.04-py3 args: ["--model-repository=/mnt/models", "--http-port=8000", "--grpc-port=8001"] env: - name: NVIDIA_VISIBLE_DEVICES value: "0,1" resources: limits: nvidia.com/gpu: 2 memory: "16Gi" cpu: "8" requests: nvidia.com/gpu: 2 memory: "12Gi" cpu: "4" volumeMounts: - name: model-storage mountPath: /mnt/models livenessProbe: httpGet: path: /v2/health/live port: 8000 initialDelaySeconds: 60 periodSeconds: 30 readinessProbe: httpGet: path: /v2/health/ready port: 8000 initialDelaySeconds: 120 periodSeconds: 10 volumes: - name: model-storage persistentVolumeClaim: claimName: model-pvc transformer: # 预处理逻辑（可选） containers: - image: my-registry/transformer:1.2 name: transformer

注意几个关键点：livenessProbe和readinessProbe的path必须是Triton原生健康检查端点（/v2/health/live），不能用自己的HTTP handler，否则KServe无法感知模型真实状态；initialDelaySeconds设为60秒，因为Triton加载大型模型可能需要半分钟；volumeMounts指向PVC而非直接挂S3，这是性能优化——MinIO客户端在K8s里读S3会有额外延迟，我们用Rook Ceph作为底层存储，通过PVC提供低延迟块存储。

4.5 第五步：流量接入与金丝雀发布

KServe默认创建ClusterIPService，我们需要把它暴露给外部。这里不用NodePort（端口冲突风险高），也不用LoadBalancer（云厂商费用贵），而是用Istio Gateway：

# gateway.yaml apiVersion: networking.istio.io/v1beta1 kind: Gateway metadata: name: ml-gateway spec: selector: istio: ingressgateway servers: - port: number: 80 name: http protocol: HTTP hosts: ["ml-api.example.com"] --- # virtual-service.yaml apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: resnet50-vs spec: hosts: - "ml-api.example.com" gateways: - ml-gateway http: - match: - uri: prefix: "/v1/models/resnet50" route: - destination: host: resnet50-predictor-default.ml-team-a.svc.cluster.local port: number: 8000 weight: 100

金丝雀发布时，我们不改VirtualService，而是直接kubectl patchInferenceService：

# 将5%流量切到v2.3 kubectl patch isvc resnet50 -n ml-team-a --type='json' -p='[ {"op": "replace", "path": "/spec/predictor/traffic", "value": [ {"name":"v2.2","percent":95}, {"name":"v2.3","percent":5} ]} ]'

然后用curl -H "Host: ml-api.example.com" http://$INGRESS_IP/v1/models/resnet50 | jq .验证响应头里是否有X-Model-Version: v2.3。整个过程30秒内完成，且KServe会自动为v2.3创建新Pod，旧Pod继续服务v2.2流量，零中断。

4.6 第六步：全链路可观测性埋点（不止是Prometheus）

可观测性不能只靠/metrics端点。我们在四个层面埋点：

1. 网关层：Istio Envoy的access log开启%REQ(X-Model-Version)%和%DURATION%，写入ELK；
2. 服务层：KServe的InferenceService自带kserve_inference_request_duration_seconds指标，但默认不聚合。我们用Prometheus recording rule预计算：

   groups: - name: kserve-rules rules: - record: kserve:inference_request_duration_seconds:mean5m expr: histogram_quantile(0.95, sum(rate(kserve_inference_request_duration_seconds_bucket[5m])) by (le, model, version))

3. 模型层：Triton的/v2/models/{model}/stats端点返回每个模型实例的execution_count和cache_hit_count，我们用Telegraf定时抓取，计算缓存命中率；
4. 业务层：在客户端SDK里注入trace ID，当调用/v2/models/resnet50/infer时，自动带上X-Request-ID，让Jaeger能追踪从APP到GPU kernel的完整链路。

这套组合拳让我们在一次故障中快速定位：P95延迟升高不是模型问题，而是网关层Envoy的TLS握手耗时突增——因为证书快过期了。没有这四层埋点，我们至少要多花两小时在猜谜游戏上。

4.7 第七步：自动化回滚与熔断（故障时的保命机制）

最后一步，也是最重要的一步：当新模型表现不佳时，如何秒级回滚？我们用KEDA（Kubernetes Event-driven Autoscaling）监听Prometheus告警：

# keda-scaledobject.yaml apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: resnet50-fallback namespace: ml-team-a spec: scaleTargetRef: name: resnet50-predictor-default triggers: - type: prometheus metadata: serverAddress: http://prometheus-k8s.monitoring.svc:9090 metricName: kserve:inference_request_duration_seconds:mean5m threshold: '200' # P95延迟超200ms触发 query: sum(kserve:inference_request_duration_seconds:mean5m{model="resnet50"}) by (version) > 200

当kserve:inference_request_duration_seconds:mean5m超过200ms持续5分钟，KEDA会自动执行回滚Job：

# fallback-job.yaml apiVersion: batch/v1 kind: Job metadata: name: resnet50-fallback spec: template: spec: containers: - name: fallback image: curlimages/curl command: ['sh', '-c'] args: - | kubectl patch isvc resnet50 -n ml-team-a --type='json' -p='[ {"op": "replace", "path": "/spec/predictor/traffic", "value": [ {"name":"v2.2","percent":100} ]} ]'; echo "Fallback to v2.2 completed" restartPolicy: Never

这个Job会在30秒内完成回滚，比人工操作快10倍。更进一步，我们在客户端SDK里实现了熔断：当连续5次调用/v2/models/resnet50/infer返回5xx，SDK自动切换到备用模型URL（指向v2.2的独立Endpoint），真正做到“故障自愈”。

5. 常见问题与排查技巧实录：那些文档里永远不会写的真相

5.1 问题速查表：高频故障现象与根因定位

5.2 踩过的坑：那些让我凌晨三点爬起来改代码的教训

坑一：Triton的model_control_mode默认值是none
我们曾以为model_repository目录下的模型会自动加载，结果发现新模型文件放进去后，Triton根本不理。查了三天文档才发现，默认模式下Triton只在启动时扫描一次模型目录。解决方案是在启动参数里加--model-control-mode=poll --repository-poll-secs=30，让它每30秒轮询一次。这个参数在官网文档里藏在“Advanced Options”章节第7页，连NVIDIA工程师都承认是“最容易被忽略的配置”。

坑二：KServe的minReplicas不是保底副本数，而是冷启动副本数
设置minReplicas: 2本意是保证永远有2个Pod在线，但实际效果是：当流量为0时，KServe会把Pod缩容到0，只保留2个“待机”副本（即Pending状态）。这意味着第一个请求来时，仍有冷启动延迟。真正要保底，得用autoscaling.knative.dev/minScale: "2"这个Annotation，它强制KServe保持2个Running Pod。这个区别在KServe 0.11版本才修复，之前版本必须用Annotation绕过。

坑三：GPU显存“虚假充足”陷阱
监控显示GPU显存占用率65%，但Triton报CUDA out of memory。用nvidia-smi -q -d MEMORY发现：FB Memory Usage是65%，但ECC Errors里有大量Single Bit错误。根源是GPU ECC校验开启后，部分显存被硬件保留用于纠错，实际可用显存只有标称值的85%。解决方案是在InferenceService的resources.limits.nvidia.com/gpu里，把申请量从2改为1.7（即2*0.85），让K8s调度器知道真实容量。

坑四：模型版本号语义化带来的灾难
我们曾用v1.0.0-alpha作为模型版本，结果KServe解析失败——它的版本比较逻辑只支持MAJOR.MINOR.PATCH格式。后来统一改用20231001-1422（日期+时间戳）格式，既保证字典序可排序，又避免语义化版本的解析歧义。这个教训告诉我们：在机器学习工程里，版本号不是给程序员看的，是给自动化系统解析的。

5.3 实操心得：提升10倍效率的三个野路子

心得一：用tritonserver --model-repository /models --strict-model-config=false跳过配置校验
开发阶段频繁改config.pbtxt，每次都要重启Triton太慢。加--strict-model-config=false后，Triton会用默认配置加载模型，即使config.pbtxt语法错误也不报错。等调试完成，再用tritonserver --model-repository /models --strict-model-config=true --log-verbose=1做最终校验。这个开关让本地迭代速度提升3倍。

心得二：在KServe里用initContainer预热GPU
新Pod启动时，首次CUDA调用会有200ms延迟。我们在InferenceService里加initContainer：

initContainers: - name: gpu-warmup image: nvidia/cuda:11.7.1-runtime-ubuntu20.04 command: ['sh', '-c'] args: ['nvidia-smi -i 0 -q -d MEMORY \| grep "Used"']

这个容器会触发GPU驱动初始化，等主容器启动时，CUDA上下文已就绪。实测首请求延迟从210ms降到45ms。

心得三：用kubectl wait替代sleep做部署等待
脚本里写sleep 60等KServe就绪是反模式。正确姿势是：

kubectl wait isvc/resnet50 -n ml-team-a --for=condition=Ready --timeout=120s

它会实时监听InferenceService的Ready条件，一旦变为True立即返回。在CI流水线里，这个命令让部署阶段平均耗时从60秒降到12秒，因为大部分时候10秒内就Ready了。

6. 最后分享一个压箱底技巧：如何用一行命令诊断所有模型服务瓶颈

在生产环境救火时，最宝贵的是时间。我写了一个Bash函数，把它放在所有运维工程师的.bashrc里：

function ml-diagnose() { local isvc=$1 local ns=${2:-default} echo "=== Diagnosing $isvc in $ns ===" # 1. 检查KServe状态 kubectl get isvc $isvc -n $ns -o wide # 2. 检查Pod状态和GPU分配 kubectl get pods -n $ns --selector serving.kserve.io/inferenceservice=$isvc -o wide # 3. 获取Triton实时统计（需Pod就绪） kubectl exec $(kubectl get pods -n $ns --selector serving.kserve.io/inferenceservice=$isvc -o jsonpath='{.items[0].metadata.name}') -n $ns -- curl -s http://localhost:8000/v2/models/$isvc/stats \| jq '.model_stats[0].inference_stats.execution_count' # 4. 检查Prometheus指标（需Prometheus可用） curl -s "http://prometheus-k8s.monitoring.svc:9090/api/v1/query?query=kserve_inference_request_duration_seconds_mean5m%7Bmodel%3D%22$isvc%22%7D" \| jq '.