1. 项目概述这不是一次模型训练而是一场工程交付“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题里藏着一个被太多人轻描淡写、却让无数团队在临门一脚时彻底卡死的真相Notebook 是思考的草稿纸Production 是交付的合同书。它不讲怎么调参、不教怎么画 loss 曲线它直指那个没人愿意多说但每天都在吞噬工程师时间的核心问题当你在 Jupyter 里跑通了 accuracy 92.3% 的模型下一步该把这串代码交给谁用什么方式交交过去之后它会不会在凌晨三点因为一条脏数据崩掉而你手机没响、告警没触发、业务方已经打电话来问“为什么推荐页全黑了”我做过 7 个从零到上线的机器学习服务其中 4 个在模型准确率达标后花了比训练周期长 2.3 倍的时间才真正稳定跑进生产环境。Part 4 这个编号很关键——它不是入门篇不是原理篇而是压轴的“交付实战篇”。它默认你已掌握模型开发Part 1、特征工程落地Part 2、模型监控基线Part 3现在要解决的是如何让一个“能跑”的模型变成一个“敢签 SLA”的服务。核心关键词“Notebook to Production”背后实际覆盖三个不可妥协的硬性要求可复现性Reproducibility——今天在你本地跑的结果和三个月后运维同事在 k8s 集群里拉起的镜像结果必须完全一致可观测性Observability——不是只看 CPU 和内存而是要实时知道特征分布是否漂移、预测置信度是否集体下滑、某类样本的延迟是否异常升高可演进性Maintainability——当业务方下周突然要求增加“用户最近 30 分钟行为加权”你能不能在不重启服务、不影响线上流量的前提下完成热更新这三个词就是 Part 4 的全部分量。它适合两类人一类是刚把模型跑通、正对着部署文档发愁的算法工程师另一类是被算法同学反复喊“再给我两天就能上线”、但已经等了三周的后端或 SRE 同事。这篇文章就是给你们共同写的交接清单。2. 整体设计思路为什么放弃“一键部署”选择“分层解耦”很多团队在 Part 4 阶段会本能地走向两个极端要么用 MLflow 或 Kubeflow 搞一套“全自动流水线”结果半年过去 pipeline 跑得比模型还复杂出了问题连日志都找不到在哪要么干脆手写 Flask API Gunicorn模型 load 一次、全局变量存着美其名曰“轻量”实则成了线上最脆弱的单点故障。这两种方案本质上都错在试图用“一个工具”解决“三层矛盾”开发态与运行态的矛盾、模型逻辑与基础设施的矛盾、快速迭代与系统稳定的矛盾。我们最终采用的方案是“三层解耦架构”它不追求炫技只确保每层职责清晰、替换成本可控、故障边界明确。第一层叫Model Serving Layer模型服务层它的唯一任务是接收标准化输入JSON/Protobuf、执行模型推理、返回结构化输出。这里我们不用 Flask而选了Triton Inference Server——不是因为它最新而是因为它原生支持 PyTorch/TensorFlow/ONNX 多框架共存且内置了动态批处理dynamic batching和模型版本热加载。举个真实例子我们有个点击率预估模型QPS 从 200 突增到 1800Triton 自动将 batch size 从 1 提升到 32GPU 利用率从 35% 拉到 89%而整个过程对上游完全透明。第二层叫Feature Serving Layer特征服务层它和模型服务层物理隔离。我们用Feast构建但做了关键改造所有离线特征如用户历史平均停留时长走 Hive 批计算所有实时特征如用户当前 session 的点击序列走 Flink 实时流两者通过统一的 feature store ID 关联。这样做的好处是当某天业务方说“把实时特征延迟从 1 秒放宽到 5 秒”我们只需调整 Flink 的 watermark模型服务层完全无感。第三层叫Orchestration Observability Layer编排与观测层它不碰模型、不碰特征只做三件事流量路由A/B 测试、灰度发布、指标采集延迟、错误率、特征统计、异常告警基于 Prometheus Grafana Alertmanager。这一层我们用Argo CD Kustomize管理 Kubernetes manifests用OpenTelemetry统一埋点拒绝任何“自研监控 SDK”。为什么放弃“一键部署”因为真正的生产环境没有“一键”。它有的是凌晨两点你发现模型延迟突增需要快速回滚到上一版本是新模型上线前必须用 5% 流量验证效果而不是全量切流是某次特征更新导致线上 AUC 下降 0.8%你需要 10 分钟内定位到是哪个特征桶的分布偏移了。这些场景“一键”给不了你控制权而分层解耦给你的是每一层都能独立升级、独立压测、独立熔断的能力。就像汽车的发动机、变速箱、底盘你可以单独更换涡轮、调校齿比、加固悬挂而不必把整辆车送回工厂重造。3. 核心细节解析从 Notebook 到可部署模型的 5 个致命改造点把 Jupyter 里的.ipynb文件直接扔进生产环境就像把实验室的烧杯直接拿到化工厂反应釜里用——看着都是玻璃器皿但承压、耐温、密封性、安全冗余全都不在一个量级。我们在 Part 4 中强制执行了 5 项模型代码改造缺一不可。这些不是“最佳实践”而是我们踩过坑后定下的“红线”。3.1 输入/输出接口必须脱离 Pandas拥抱 Schema-first 设计你在 Notebook 里写df pd.read_csv(data.csv)很自然但在生产里这行代码会成为性能黑洞和兼容性雷区。Pandas DataFrame 在跨进程、跨语言、跨网络传输时序列化开销大、版本兼容差pandas 1.5 和 2.0 的 dtype 行为差异曾让我们线上服务连续报错 47 分钟。我们的改造是所有模型必须定义明确的 input schema 和 output schema用 Pydantic v2 实现强类型校验。例如一个用户画像模型的输入不再是pd.DataFrame而是from pydantic import BaseModel, Field from typing import List, Optional class UserInput(BaseModel): user_id: str Field(..., description用户唯一标识长度 16-32 字符) device_type: str Field(..., pattern^(ios|android|web)$, description设备类型) recent_clicks: List[str] Field(default_factorylist, max_length50, description最近点击商品 ID 列表) class ModelOutput(BaseModel): score: float Field(..., ge0.0, le1.0, description预测得分0~1 区间) risk_level: str Field(..., pattern^(low|medium|high)$, description风险等级)模型加载时Triton 会自动将 JSON 请求反序列化为UserInput实例并在传入模型前完成字段校验、类型转换、长度限制。一旦recent_clicks超过 50 个请求直接 422 返回不进模型、不占 GPU 显存。这个改动带来的收益是API 响应时间 P95 从 128ms 降到 43ms无效请求拦截率 100%且前端同学再也不用猜“user_id 是字符串还是数字”。3.2 模型加载必须剥离 I/O实现“冷启动即热服务”Notebook 里常见的model torch.load(model.pth)在生产中是定时炸弹。它意味着每次服务启动都要从磁盘读取几百 MB 模型文件如果磁盘 IO 不稳比如云厂商的共享存储抖动服务可能卡在 loading 状态长达 2 分钟而 Kubernetes 的 liveness probe 已经连续失败 3 次开始杀进程重启。我们的方案是所有模型权重必须打包进容器镜像且加载逻辑必须在__init__中完成而非首次请求时懒加载。具体操作分三步在 Dockerfile 中将model.pth复制到/app/models/目录下在 Triton 的 model repository 结构中为每个模型版本创建config.pbtxt明确指定platform: pytorch_libtorch和max_batch_size: 32编写model.py其initialize()方法在容器启动时即执行torch.load()并缓存到self.model属性。提示Triton 启动日志里会显示Loading model user_score_v2 version 1紧接着是Successfully loaded model user_score_v2。这两行日志出现之间的时间差就是你的冷启动耗时。我们要求这个时间必须 ≤ 800ms超时则视为镜像构建失败自动阻断 CI 流水线。3.3 特征预处理必须与模型解耦禁止嵌入模型代码这是最隐蔽也最危险的坑。很多算法同学会把StandardScaler的fit_transform()直接写在模型forward()里理由是“保证训练和推理一致”。但问题在于fit_transform()需要访问全局统计量均值、方差而这些统计量在训练时是离线计算的在线上推理时必须作为常量注入。如果混在模型里你就无法单独更新 scaler 参数——比如某天发现用户年龄分布整体右移了 5 岁你需要更新 age 的均值但模型代码没改你只能重新训练整个模型哪怕只是换了个数字。我们的规范是所有特征变换归一化、One-Hot、分桶必须由 Feature Serving Layer 完成模型只接收已变换的数值向量。Triton 的config.pbtxt中我们显式声明输入 tensor 的 shape 和 dtypeinput [ { name: user_features data_type: TYPE_FP32 dims: [128] # 固定 128 维特征向量 } ]这意味着上游特征服务必须保证每次返回的user_features都是长度 128、dtypefloat32 的 numpy array。模型代码里不再有任何scaler.transform()只有纯粹的self.model(x)。这个改动让特征参数更新周期从“按模型迭代”缩短到“按小时级”且完全不触发模型服务重启。3.4 错误处理必须覆盖业务语义拒绝裸抛异常Notebook 里except Exception as e: print(e)能帮你 debug但在生产里它会让你失去所有上下文。当模型因输入user_id为空字符串而崩溃Triton 默认返回500 Internal Server Error和一串 PyTorch 底层 traceback运维同学看到的只有RuntimeError: expected scalar type Float but found Double根本不知道是哪条请求、哪个字段、哪个业务方造成的。我们的做法是在 Triton 的model.py中用 try-catch 包裹整个execute()方法并将业务语义错误映射为标准 HTTP 状态码def execute(self, requests): responses [] for request in requests: try: # 解析输入 user_input UserInput(**json.loads(request.get_input(INPUT0).as_numpy()[0])) # 业务校验 if not user_input.user_id.strip(): raise ValueError(user_id cannot be empty or whitespace) # 执行推理 features self.feature_service.get(user_input.user_id) score self.model(torch.tensor(features, dtypetorch.float32)) # 构建响应 output ModelOutput(scorefloat(score), risk_levelself._map_risk(score)) responses.append([np.array(output.json(), dtypeobject)]) except ValueError as ve: # 业务错误 - 400 Bad Request responses.append([np.array(json.dumps({error: Invalid input, detail: str(ve)}), dtypeobject)]) except torch.cuda.OutOfMemoryError: # 系统错误 - 503 Service Unavailable responses.append([np.array(json.dumps({error: GPU memory exhausted}), dtypeobject)]) except Exception as e: # 未知错误 - 500但附带 trace_id trace_id str(uuid.uuid4()) logger.error(fUnexpected error in model execute, trace_id{trace_id}, exc_infoTrue) responses.append([np.array(json.dumps({error: Internal error, trace_id: trace_id}), dtypeobject)]) return responses这样前端收到 400 时知道是自己传参错了收到 503 时立刻扩容 GPU收到 500 时拿着trace_id直接查日志。错误不再模糊责任不再推诿。3.5 日志必须结构化、带上下文、可关联追踪Notebook 里的print(Start inference for user:, user_id)在生产里毫无价值。它无法被 ELK 收集无法按user_id过滤更无法和上游请求、下游数据库操作串联成完整链路。我们的日志规范强制三点格式统一全部使用 JSON 格式字段包括timestamp,level,service,trace_id,span_id,user_id,model_version,latency_ms,input_hash输入数据的 SHA256 前 8 位上下文注入每个请求进入时由网关生成trace_id并透传到 TritonTriton 在execute()开头就记录event: inference_start结尾记录event: inference_end中间所有日志自动携带该trace_id关键字段脱敏user_id在日志中显示为u_abc123...保留前缀哈希后缀原始值仅存于加密日志库中满足 GDPR 基础要求。注意我们禁用所有logging.basicConfig()全局配置每个模块必须用logger logging.getLogger(__name__)获取命名 logger并通过structlog绑定上下文。实测下来当线上出现偶发性高延迟时运维同学能在 Grafana 里点击某个 P99 延迟毛刺直接跳转到对应trace_id的全链路日志平均定位时间从 22 分钟缩短到 90 秒。4. 实操过程从本地验证到灰度发布的 7 步上线流程Part 4 的价值不在于告诉你“应该做什么”而在于给你一份可逐字照抄、每一步都有检查点的《上线核对清单》。我们把整个流程拆成 7 个原子步骤每个步骤都有明确的准入条件、执行动作、验收标准和回滚预案。这不是理论流程而是我们过去 18 个月里23 次模型上线的真实操作记录。4.1 Step 1本地沙箱验证准入条件Notebook 代码已提交 Gitfeature branch 名为feat/prod-ready-v3这一步的目标是在完全隔离的环境中验证模型代码能否脱离 Notebook 环境独立运行。我们不用本地 conda 环境而是用docker build --target dev-sandbox -t ml-model-sandbox .构建一个最小化镜像基础镜像为nvidia/cuda:11.8.0-devel-ubuntu22.04只装 PyTorch 2.0 和必要依赖。镜像构建完成后执行docker run --rm -v $(pwd)/test_data:/data -it ml-model-sandbox \ python /app/scripts/validate_local.py --input-path /data/sample_request.json --model-path /app/models/user_score_v3.pthvalidate_local.py脚本会加载sample_request.json一个符合UserInputschema 的真实样例调用模型forward()方法捕获输出对比输出是否符合ModelOutputschema且score在 [0,1] 区间计算本次推理的latency_ms要求 ≤ 50msP95。验收标准脚本返回exit code 0且 stdout 输出✅ Local validation passed. Latency: 32.7ms。如果失败必须修复代码不得进入下一步。4.2 Step 2Triton 模型仓库集成准入条件Step 1 通过且config.pbtxt已按规范编写这一步是模型服务化的起点。我们创建标准 Triton model repository 结构models/ ├── user_score_v3/ │ ├── 1/ │ │ └── model.py # Triton Python backend 代码 │ ├── config.pbtxt # 必须包含 platform, max_batch_size, input/output 定义 │ └── requirements.txt # 仅列出 Triton 运行时依赖禁止放 torch/tf关键检查点有三个config.pbtxt中version_policy必须设为latest { num_versions: 1 }确保只加载最新版本model.py的execute()方法必须返回List[np.ndarray]且每个 ndarray 的dtype和shape必须与config.pbtxt中声明的完全一致requirements.txt中不能出现torch2.0.1这类精确版本只能写numpy1.21.0,2.0.0避免与 Triton 基础镜像冲突。验证方式启动本地 Triton 服务tritonserver --model-repository./models --strict-model-configfalse然后用curl发送测试请求curl -d {inputs:[{name:INPUT0,shape:[1],datatype:BYTES,data:[{\user_id\:\u_abc123\,\device_type\:\ios\}]}]} \ -X POST http://localhost:8000/v2/models/user_score_v3/infer验收标准返回 HTTP 200且响应 JSON 中outputs[0].data是合法的ModelOutput字符串。4.3 Step 3特征服务联调准入条件Step 2 通过且 Feast feature repo 已同步最新特征定义这一步验证模型与特征服务的契约是否对齐。我们写一个feature_integration_test.py它不调用 Triton而是直接调用 Feast 的get_online_features()方法获取与 Triton 输入完全一致的user_features向量然后用本地加载的模型进行推理对比结果是否与 Triton 一致。重点检查当user_id不存在时Feast 是否返回全零向量而非报错当某特征如age_bucket值域超出训练时范围Feast 是否按约定填充默认值如 -1特征向量长度是否严格等于config.pbtxt中声明的dims。我们曾在这里发现一个严重问题Feast 的online_store配置中redis_ttl设置为 3600 秒但某天 Redis 内存满部分 key 被 LRU 清除导致特征返回空值模型推理出 NaN。解决方案是在 Feast 的get_online_features()调用后强制添加np.nan_to_num(features, nan0.0)。这个修复被写入团队 Wiki成为所有新模型的强制检查项。4.4 Step 4压力测试与容量规划准入条件Step 3 通过且 Prometheus 监控已接入 Triton metrics这一步决定你到底要买几块 GPU。我们不用 ab 或 wrk而是用Locust编写真实业务场景的负载脚本# locustfile.py from locust import HttpUser, task, between import json import random class ModelUser(HttpUser): wait_time between(0.1, 0.5) # 模拟真实请求间隔 task def infer(self): # 随机选取 100 个真实 user_id来自线上采样 user_id random.choice(self.user_ids) payload { inputs: [{ name: INPUT0, shape: [1], datatype: BYTES, data: [json.dumps({user_id: user_id, device_type: random.choice([ios,android])})] }] } self.client.post(/v2/models/user_score_v3/infer, jsonpayload)测试分三轮Baseline50 QPS持续 5 分钟目标 P95 延迟 ≤ 60ms错误率 0%Peak300 QPS模拟大促峰值持续 2 分钟目标 GPU 利用率 ≤ 85%无 OOMStress500 QPS持续 30 秒观察是否触发自动扩缩容KEDA Triton HPA。验收标准三轮测试全部通过且 Prometheus 中nv_gpu_duty_cycle指标在 Peak 轮中未超过 90%。如果超标则必须调整 Triton 的max_batch_size或增加 GPU 数量重新测试。4.5 Step 5CI/CD 流水线打通准入条件Step 4 通过且 GitLab CI 配置已就绪这一步把前面所有验证自动化。我们的.gitlab-ci.yml关键 stage 如下stages: - validate - build - test - deploy validate-local: stage: validate image: docker:20.10.16 script: - docker build --target dev-sandbox -t $CI_REGISTRY_IMAGE:sandbox . - docker run --rm $CI_REGISTRY_IMAGE:sandbox python /app/scripts/validate_local.py ... build-model-image: stage: build image: docker:20.10.16 script: - docker build --target triton-model -t $CI_REGISTRY_IMAGE:triton-$CI_COMMIT_TAG . - docker push $CI_REGISTRY_IMAGE:triton-$CI_COMMIT_TAG test-integration: stage: test image: python:3.10 script: - pip install feast tritonclient - python scripts/feature_integration_test.py --model-tag $CI_COMMIT_TAG deploy-to-staging: stage: deploy image: bitnami/kubectl:1.25 script: - kubectl set image deployment/ml-model-deployment model$CI_REGISTRY_IMAGE:triton-$CI_COMMIT_TAG -n staging - kubectl rollout status deployment/ml-model-deployment -n staging --timeout120s environment: staging only: - tags关键设计所有测试必须在only: tags下触发即只有打v3.1.0这样的语义化版本 tag 时才执行完整流水线。日常开发用git push只触发单元测试不构建镜像。这避免了“开发分支天天构建几百个镜像占满 Harbor 存储”的悲剧。4.6 Step 6金丝雀发布准入条件Step 5 通过且 staging 环境已验证 24 小时这一步是上线前的最后一道保险。我们不直接切 100% 流量而是用Istio VirtualService实现 5% → 20% → 50% → 100% 的四阶段灰度apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: ml-model-vs spec: hosts: - ml-api.example.com http: - route: - destination: host: ml-model-service subset: v3-1-0 weight: 5 # 第一阶段5% 流量 - destination: host: ml-model-service subset: v2-9-0 # 当前稳定版本 weight: 95每个阶段持续 30 分钟期间 SRE 同学紧盯 Grafana 看板triton_inference_requests_total{modeluser_score_v3}是否与总流量同比例增长triton_inference_errors_total{modeluser_score_v3}是否出现尖峰feature_store_latency_seconds_bucket{featureuser_age_mean}的 P99 是否稳定。如果任一指标异常如错误率 0.1% 或延迟 P95 100ms立即执行kubectl patch virtualservice ml-model-vs -p {spec:{http:[{route:[{weight:0},{weight:100}]}]}}100% 切回旧版本。整个过程业务方无感知。4.7 Step 7生产环境全量与监控固化准入条件Step 6 四阶段全部平稳通过这一步不是结束而是开始。全量发布后我们执行三项固化动作更新文档在 Confluence 的“模型服务手册”中新增user_score_v3条目包含config.pbtxt全文、输入/输出 schema、SLA 承诺P95 60ms, 99.95% 可用性、负责人zhangsan创建专属告警在 Alertmanager 中为user_score_v3新建规则- alert: MLModelLatencyHigh expr: histogram_quantile(0.95, sum(rate(triton_inference_request_duration_us_bucket{modeluser_score_v3}[1h])) by (le)) 60000000 for: 5m labels: severity: warning annotations: summary: User Score v3 latency 60ms (P95)归档训练 artifacts将本次上线对应的model.pth、feast_feature_repo_commit_hash、triton_config.pbtxt打包为user_score_v3-release-bundle.tar.gz上传至 MinIO 的ml-artifacts/releases/目录并生成 SHA256 校验码存入 Git。至此Part 4 的使命完成。模型不再是 notebook 里的一个变量而是一个有身份证版本号、有户口文档、有社保监控告警、有紧急联系人负责人的正式服务成员。5. 常见问题与排查技巧实录那些没写在文档里的血泪经验在 Part 4 的实践中有些问题不会出现在官方文档里但它们高频、致命、且往往让你在深夜三点对着日志抓狂。我把过去两年遇到的 7 个典型问题连同排查路径、根因分析、永久解决方案整理成这张速查表。这不是“可能遇到”而是“你一定会遇到”。问题现象排查路径根因分析永久解决方案我的实操心得Triton 启动成功但curl测试返回400 Bad Request日志无有效信息1.kubectl logs triton-pod查看启动日志2.kubectl exec -it triton-pod -- ls /models/确认模型目录结构3.kubectl exec -it triton-pod -- cat /models/user_score_v3/config.pbtxt检查语法config.pbtxt中input或output的name字段与model.py中execute()方法里request.get_input(INPUT0)的字符串不匹配。Triton 不报错但找不到对应 input返回 400。所有config.pbtxt必须用yamllint校验且name字段必须与代码中硬编码字符串完全一致大小写、下划线。我们已在 CI 中加入grep -r get_input . | grep -o INPUT[0-9]\ | sort -u自动提取所有 input name与 config.pbtxt 比对。我第一次栽在这儿花了 3 小时。后来写了个小脚本check_triton_config.py输入模型目录自动比对 config 和代码中的 input/output name现在是每个 PR 的必检项。压力测试时GPU 利用率始终 ≤ 40%QPS 上不去1.nvidia-smi dmon -s u -d 1实时查看 GPU utilization2.kubectl top pods查看 pod CPU/Mem3.curl http://triton-ip:8002/v2/models/user_score_v3/stats查看 Triton 内部队列状态Triton 的dynamic_batching未生效。原因通常是config.pbtxt中max_batch_size设得太小如 1或preferred_batch_size未设置导致 Triton 不敢合并请求。config.pbtxt中必须显式配置dynamic_batching [ preferred_batch_size: [8, 16, 32] max_queue_delay_microseconds: 1000 ]且max_batch_size至少为 32。我们通过locust脚本模拟不同 batch size 的请求找到 P95 延迟最优的preferred_batch_size组合。别迷信文档里的默认值。我们实测发现对于 128 维特征的模型preferred_batch_size: [16, 32]比[8, 16, 32]的 GPU 利用率高 12%因为 8 这个档位太小合并收益低。线上服务偶发CUDA out of memory但nvidia-smi显示显存充足1.kubectl logs triton-pod | grep -i out of memory2.kubectl describe pod triton-pod查看 events3.kubectl exec -it triton-pod -- nvidia-smi -q -d MEMORY查看显存详细分配Triton 的 Python backend 使用torch.jit.script加载模型时会为每个模型实例预留显存池。当多个模型版本v3.0, v3.1同时加载或同一模型有多个 instanceinstance_group配置显存被碎片化占用。1. 在config.pbtxt中为每个模型设置instance_group [ kind: KIND_CPU ]CPU 推理或严格限制count: 12.永远不要在同一 Triton server 中混布 CPU 和 GPU 模型3. 升级 Triton 到 23.06启用--cuda-memory-pool-byte-size10737418241GB显存池管理。这个坑让我重启了 7 次服务。后来我们规定GPU 模型独占一个 Triton PodCPU 模型用另一个 Pod物理隔离。虽然多花点资源但换来的是稳定性。特征服务返回的向量模型推理结果全是 NaN1.kubectl exec -it triton-pod -- python -c import torch; print(torch.__version__)2.kubectl exec -it triton-pod -- python -c import numpy; print(numpy.__version__)3. 用feature_integration_test.py打印特征向量的np.isnan(features).any()Feast 的get_online_features()返回的 numpy array dtype 是float64而 Triton 的 PyTorch backend 期望float32。类型不匹配导致 PyTorch 内部计算溢出产生 NaN。在model.py的execute()方法中在torch.tensor(features)前强制转换features features.astype(np.float32)。并在 Feast 的feature_view定义中显式指定dtypenp.float32。类型问题永远是第一怀疑对象。我们现在的feature_integration_test.py第一行就是assert features.dtype np.float32不通过直接 fail。灰度发布后新版本流量的 P95 延迟比旧版本高 200ms但单机压测无差异1.kubectl get endpoints ml-model-service -n prod查看 endpoints 列表2.kubectl get pod -l appml-model -n prod -o wide查看 pod 分布3.kubectl top nodes查看节点负载新版本模型镜像体积比旧版大 2.3GB导致 Kubernetes 在调度时将新 pod 调度到了一台磁盘 IO 较差的老旧节点上。kubectl describe node old-node显示DiskPressure为 True。1. 所有模型镜像构建后必须docker history image检查层数和大小禁止引入apt-get install等非必要包2. 在deployment.yaml中为 Triton Pod 添加nodeSelector限定只调度到gpu-class: high-io的节点组3. 为