Triton模型服务化实战：从Notebook到高可用ML生产环境
1. 项目概述：这不是一次“部署上线”，而是一场从实验室到产线的系统性迁移
“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题里藏着一个被太多人轻描淡写、却让无数团队在临门一脚时彻底卡死的真实困境。它不是讲“怎么把模型导出成ONNX”，也不是教“用Flask搭个API接口就完事”，而是直指机器学习落地中最硬的那块骨头：当你的Jupyter Notebook在本地跑通了98%的指标，它离真正支撑业务、扛住流量、持续迭代，中间还隔着至少七道关卡。我带过三支不同行业的ML工程团队，从电商推荐到工业设备预测性维护，最后都卡在Part 4——不是模型不行，是整个运行环境、数据链路、监控反馈和协作机制没跟上。这一期的核心关键词是模型服务化（Model Serving）、可观测性（Observability）、持续验证（Continuous Validation）与运维协同（MLOps Workflow），它们共同构成了一条看不见但必须踩实的“生产化地基”。如果你还在用pickle.load()读模型、用curl手动测接口、靠人工盯日志查异常，那你不是在做MLOps，你是在给未来埋雷。这篇文章适合两类人：一类是刚从算法岗转岗做模型交付的工程师，手握SOTA模型却总被业务方问“为什么线上效果比离线差20%”；另一类是技术负责人，正被“模型上线周期长达6周”“每次更新都要重启整套服务”这类问题反复折磨。它不提供速成幻觉，只给你一条经过产线验证的、可拆解、可检查、可追责的落地路径。
2. 内容整体设计与思路拆解：为什么放弃“一键部署”，选择分层解耦架构
2.1 核心设计哲学：拒绝“Notebook即服务”，拥抱“模型即组件”
很多团队的第一反应是：把Notebook里的训练代码封装成Docker镜像，挂上REST API，再用Nginx反向代理——看起来很美，实则隐患重重。我亲眼见过一家金融风控团队用这种方式上线XGBoost模型，结果在大促期间因单个请求触发了Notebook中未清理的全局变量，导致后续所有请求的特征计算全部错位，坏账率一夜飙升。根本问题在于：Notebook本质是探索性工具，不是生产级服务框架。它的执行环境不可控（随机种子、临时文件、隐式依赖），状态管理混乱（cell执行顺序敏感），且缺乏服务治理能力（超时、熔断、限流）。因此，Part 4的设计起点不是“怎么包装”，而是“怎么解耦”。我们采用三层分离架构：
模型层（Model Layer）：仅包含纯推理逻辑（
model.predict()）、标准化输入/输出协议（如TensorFlow Serving的PredictRequest格式）、以及版本化的模型权重文件（.pb,.pt,.joblib）。这一层必须做到“无状态、无副作用、无外部依赖”。服务层（Serving Layer）：由专用模型服务框架承载（如Triton Inference Server、KServe、Seldon Core），负责模型加载、批处理、GPU资源调度、gRPC/HTTP协议转换。它不碰业务逻辑，只做“模型搬运工”。
编排层（Orchestration Layer）：由Kubernetes+Argo Workflows或Airflow驱动，管理模型版本发布、A/B测试流量切分、回滚策略、以及与特征平台、监控系统的对接。它定义“什么时候用哪个模型”，而不是“怎么算”。
这种分层不是为了炫技，而是为了解决三个刚性需求：第一，故障隔离——模型崩溃不会拖垮整个API网关；第二，灰度可控——新模型可以先对5%的用户生效，效果达标再全量；第三，责任明确——算法同学只管模型层，SRE同学只管服务层，无需互相等待。
2.2 方案选型背后的硬约束：为什么Triton成为首选，而非自建Flask服务
在服务层选型上，我们对比了五种主流方案：Flask/FastAPI自建、TensorFlow Serving、Triton Inference Server、KServe、以及云厂商托管服务（如SageMaker Endpoint）。最终锁定Triton，决策依据不是“谁功能多”，而是“谁最能扛住真实世界的脏数据和突发流量”。举几个关键硬指标：
多框架原生支持：Triton原生支持PyTorch、TensorFlow、ONNX、SKLearn、XGBoost等12种框架模型，无需统一转ONNX。我们有个客户用LightGBM做实时点击率预估，转ONNX后精度损失0.3%，而Triton直接加载
.txt模型文件，精度零损失。这背后是Triton对各框架底层runtime的深度适配，比如对LightGBM的predict函数做了内存零拷贝优化。动态批处理（Dynamic Batching）：这是应对高并发请求的杀手锏。传统Flask服务每收到一个请求就启动一次
model.predict()，而Triton会将毫秒级内到达的多个请求自动合并成一个batch（如batch_size=8），一次GPU推理完成全部计算，吞吐量提升3-5倍。我们在某短视频APP的推荐模型压测中，QPS从1200飙升至5800，P99延迟从320ms降至85ms。模型热重载（Hot Model Reload）：无需重启服务即可加载新版本模型。Triton通过文件系统监听机制，检测到
models/my_model/2/目录下新增config.pbtxt时，自动加载并切换流量。这让我们实现了“模型更新像发版一样快”——从算法提交新模型到线上生效，全程<90秒。
提示：Triton并非万能。它对Python后处理逻辑支持较弱（需用C++编写custom backend），且不内置特征工程。因此，我们约定：所有特征工程必须前置到数据管道中完成，Triton只做纯模型推理。这条铁律避免了90%的线上一致性问题。
2.3 观测性设计：不是“加监控”，而是“把监控刻进服务基因”
很多团队的监控停留在“CPU使用率>80%告警”层面，这在ML服务中毫无意义。真正的可观测性必须覆盖三个维度：数据、模型、系统。我们为Triton服务注入了三类探针：
数据探针（Data Drift Detection）：在Triton的preprocessing阶段插入统计钩子，实时计算输入特征的分布偏移（如KS检验p-value、特征均值/方差变化率）。当
user_age均值从32.1骤降至28.5，系统自动触发告警，并冻结该模型的流量分发。模型探针（Model Performance Tracking）：利用Triton的metrics endpoint（
/v2/metrics），采集每个模型实例的nv_inference_request_success（请求成功率）、nv_inference_queue_duration_us（排队耗时）、nv_inference_compute_duration_us（计算耗时）。这些指标被Prometheus抓取，Grafana看板上可下钻到单个模型、单个GPU卡粒度。系统探针（Infrastructure Health）：不仅监控GPU显存，更关注
nv_gpu_duty_cycle（GPU利用率）和nv_gpu_memory_used_bytes（显存占用）。我们发现某次线上故障源于GPU显存碎片化——虽然总显存剩余4GB，但最大连续块仅剩128MB，导致新batch无法分配。Triton的model_repository_indexAPI可实时查询各模型的显存占用，成为诊断利器。
这套观测体系不是事后补救，而是前置防御。它让“模型退化”从“业务方投诉才发现”变成“系统自动预警+自动降级”。
3. 核心细节解析与实操要点：从配置文件到生产就绪的每一处魔鬼细节
3.1 Triton配置文件（config.pbtxt）的12个必填字段详解
Triton的服务行为几乎全部由config.pbtxt文件定义。很多人复制网上模板却忽略关键字段，导致线上行为诡异。以下是我们生产环境强制要求的12个字段及其真实含义：
| 字段名 | 必填 | 示例值 | 为什么重要 | 实操教训 |
|---|---|---|---|---|
name | 是 | "recommendation_v2" | 模型唯一标识，用于API路由 | 曾有团队用中文命名，导致Kubernetes DNS解析失败 |
platform | 是 | "pytorch_libtorch" | 指定框架runtime，决定加载方式 | 误填"pytorch"会导致Triton找不到libtorch.so |
max_batch_size | 是 | 32 | 单次推理最大batch size，影响显存占用 | 设为0表示禁用batching，但会丧失性能优势 |
input | 是 | [{name:"INPUT__0", data_type:"TYPE_FP32", dims:[-1,128]}] | 定义输入张量名、类型、维度 | -1表示动态batch，128是特征维度，必须与模型导出时一致 |
output | 是 | [{name:"OUTPUT__0", data_type:"TYPE_FP32", dims:[-1,1]}] | 输出张量定义，dims:[-1,1]表示单值预测 | 若模型输出logits，此处必须匹配，否则客户端解析错误 |
instance_group | 是 | [{kind:"KIND_GPU", count:2}] | 指定GPU实例数，count=2即启2个模型副本 | 不设此字段，Triton默认只启1个，无法利用多卡 |
dynamic_batching | 否 | {max_queue_delay_microseconds:1000} | 启用动态批处理，1000μs内请求合并 | 延迟设太高导致P99上升，太低则batch效率低 |
model_warmup | 否 | [{name:"warmup_data", batch_size:1}] | 启动时预热，避免首请求冷启动延迟 | 未配置时，首个请求延迟高达2.3秒 |
version_policy | 否 | {"latest": {"num_versions":1}} | 只加载最新1个版本，旧版本自动卸载 | 防止显存被历史版本长期占用 |
default_model_filename | 否 | "model.pt" | 指定模型文件名，默认为model.pt | PyTorch模型必须显式声明，否则加载失败 |
cc_model_filenames | 否 | {"6.0":"model_sm60.pt"} | 按GPU计算能力指定模型文件 | A100（cc8.0）和V100（cc7.0）需不同编译版本 |
metric_tags | 否 | {"team":"recsys", "env":"prod"} | 打标便于Prometheus多维查询 | 无标签则无法区分测试/生产环境指标 |
注意：
dims中的-1必须与模型导出时的torch.jit.trace参数严格一致。我们曾因导出时用example_input=torch.randn(1,128)，而config中写dims:[-1,128]，导致Triton加载时报shape mismatch。正确做法是：导出前用torch.jit.script替代trace，或确保trace的example_inputbatch_size=1。
3.2 模型导出的三大陷阱与绕过方案
将PyTorch模型喂给Triton，绝非torch.save()那么简单。以下是三个血泪教训：
陷阱一：nn.Module中的self.device硬编码
很多Notebook代码里写着self.linear = nn.Linear(128,1).to('cuda')。Triton加载时会报CUDA error: invalid device ordinal，因为Triton管理GPU设备，不允许模型自行绑定。
绕过方案：导出前删除所有.to()调用，在Triton的config.pbtxt中通过instance_group指定GPU，由Triton统一调度。
陷阱二：torch.nn.functional.interpolate的动态尺寸
图像分割模型常用F.interpolate(x, size=(h,w))，但Triton要求输入尺寸固定。若config中dims:[-1,3,224,224]，而模型内部试图插值到(448,448)，会触发CUDA kernel crash。
绕过方案：改用F.interpolate(x, scale_factor=2.0)，或在预处理阶段将图像resize到固定尺寸，模型内只做scale_factor插值。
陷阱三：torch.jit.trace的控制流丢失
Notebook中常有if x.sum() > 0.5: return y else: return z，trace会固化分支，导致线上输入分布变化时逻辑失效。
绕过方案：强制使用torch.jit.script，它能完整捕获Python控制流。但需注意：script不支持numpy、PIL等库，所有预处理必须用torchvision.transforms重写。
3.3 Kubernetes部署的5个生产级配置要点
Triton服务跑在K8s上，不是简单kubectl apply -f triton.yaml就能搞定。以下是我们的Deployment核心配置：
apiVersion: apps/v1 kind: Deployment metadata: name: triton-inference-server spec: replicas: 1 selector: matchLabels: app: triton template: metadata: labels: app: triton annotations: # 关键1：启用GPU设备插件 nvidia.com/gpu: "2" spec: # 关键2：必须使用hostNetwork，避免K8s网络栈增加延迟 hostNetwork: true # 关键3：设置GPU显存限制，防止OOM containers: - name: triton image: nvcr.io/nvidia/tritonserver:23.08-py3 resources: limits: nvidia.com/gpu: 2 memory: "16Gi" requests: nvidia.com/gpu: 2 memory: "12Gi" # 关键4：挂载模型仓库，且必须read-only volumeMounts: - name: model-repo mountPath: /models readOnly: true # 关键5：健康检查必须用Triton原生端点 livenessProbe: httpGet: path: /v2/health/live port: 8000 initialDelaySeconds: 60 periodSeconds: 30 readinessProbe: httpGet: path: /v2/health/ready port: 8000 initialDelaySeconds: 30 periodSeconds: 10 volumes: - name: model-repo persistentVolumeClaim: claimName: triton-model-pvc注意：
hostNetwork: true是性能关键。我们实测开启后，P99延迟降低47%，因为绕过了K8s CNI插件的iptables规则链。但代价是服务IP与宿主机共享，需确保宿主机防火墙开放8000/8001/8002端口。
4. 实操过程与核心环节实现：从本地验证到灰度发布的全流程记录
4.1 本地验证：用tritonclient模拟真实请求链路
在推送到K8s前，必须在本地完成端到端验证。我们不用curl，而是用NVIDIA官方tritonclient库，因为它能精确复现生产环境的序列化/反序列化逻辑：
import numpy as np import tritonclient.http as httpclient from tritonclient.utils import InferenceServerException # 1. 创建客户端（指向本地triton服务） client = httpclient.InferenceServerClient(url="localhost:8000") # 2. 构造输入数据（必须与config.pbtxt的dims完全一致） input_data = np.random.randn(1, 128).astype(np.float32) # batch_size=1, feat_dim=128 # 3. 创建InferenceRequest inputs = [] inputs.append(httpclient.InferInput("INPUT__0", input_data.shape, "FP32")) inputs[0].set_data_from_numpy(input_data) outputs = [] outputs.append(httpclient.InferRequestedOutput("OUTPUT__0")) # 4. 发送请求并解析 try: result = client.infer( model_name="recommendation_v2", inputs=inputs, outputs=outputs ) pred = result.as_numpy("OUTPUT__0") print(f"Prediction: {pred[0][0]:.4f}") # 确保输出是标量 except InferenceServerException as e: print(f"Error: {e}")这段代码的价值在于：它暴露了所有潜在断裂点。我们曾在此处发现两个问题：第一，input_data.shape传入(128,)而非(1,128)，导致Triton报batch dimension mismatch；第二，as_numpy("OUTPUT__0")返回None，原因是模型输出张量名实际为"scores"，config中却写"OUTPUT__0"。这种验证必须在CI流水线中自动化执行，作为模型入库的准入门槛。
4.2 模型仓库（Model Repository）的原子化管理
Triton的模型仓库结构是/models/{model_name}/{version}/，其中{version}必须是纯数字（如1,2）。我们严禁手动拷贝文件，而是用GitOps模式管理：
# 模型仓库根目录（Git管理） /models/ ├── recommendation_v2/ │ ├── 1/ │ │ ├── config.pbtxt │ │ └── model.pt │ └── 2/ # 新版本 │ ├── config.pbtxt │ └── model.pt └── fraud_detection/ └── 1/ ├── config.pbtxt └── model.onnx关键操作是原子化切换：Triton通过model-controlAPI控制加载/卸载。发布新版本时，我们执行：
# 1. 先加载新版本（不切换流量） curl -X POST "http://localhost:8000/v2/repository/models/recommendation_v2/load" \ -H "Content-Type: application/json" \ -d '{"parameters":{"version":"2"}}' # 2. 验证新版本是否ready curl "http://localhost:8000/v2/repository/models/recommendation_v2/versions/2/ready" # 3. 切换默认版本（流量立即生效） curl -X POST "http://localhost:8000/v2/repository/models/recommendation_v2/unload" \ -H "Content-Type: application/json" \ -d '{"parameters":{"version":"1"}}'这套流程保证了“加载-验证-切换”三步原子性，避免了mv命令导致的短暂服务不可用。
4.3 灰度发布：用Istio实现基于Header的A/B测试
我们不依赖Triton自身的ensemble功能做A/B，而是用Istio Service Mesh在入口层分流，因为Istio能提供更精细的流量控制（如按用户ID哈希、按地域、按设备类型）：
# Istio VirtualService apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: triton-vs spec: hosts: - "ml-api.example.com" http: - match: - headers: x-canary: exact: "true" # 请求头含x-canary:true走新模型 route: - destination: host: triton-inference-server subset: v2 # 指向新模型服务 - route: - destination: host: triton-inference-server subset: v1 # 默认走老模型 --- # Istio DestinationRule apiVersion: networking.istio.io/v1beta1 kind: DestinationRule metadata: name: triton-dr spec: host: triton-inference-server subsets: - name: v1 labels: version: v1 - name: v2 labels: version: v2业务方只需在请求头加x-canary: true，即可命中新模型。我们用此机制完成了三次灰度：第一次5%流量，观察P99延迟；第二次20%流量，验证数据漂移告警；第三次100%流量，同步关闭老模型。整个过程无需修改任何模型代码或Triton配置。
5. 常见问题与排查技巧实录：那些文档里不会写的产线真相
5.1 典型问题速查表
| 问题现象 | 根本原因 | 排查命令 | 解决方案 |
|---|---|---|---|
HTTP 503 Service Unavailable | Triton未启动或模型未加载 | curl http://localhost:8000/v2/health/ready | 检查kubectl logs triton-pod，常见于config.pbtxt语法错误 |
InferenceServerException: model 'xxx' is not ready | 模型加载失败（如显存不足） | curl http://localhost:8000/v2/repository/index | 查看返回JSON中state字段，若为UNAVAILABLE，检查kubectl logs中CUDA OOM日志 |
P99延迟突增300ms | 动态批处理未生效，单请求触发full batch | curl http://localhost:8000/v2/metrics | grep nv_inference_request_batch_size | 检查max_queue_delay_microseconds是否过大，或客户端请求间隔是否远超该值 |
GPU显存占用100%但利用率<10% | 模型加载后未释放显存缓存 | nvidia-smi --query-compute-apps=pid,used_memory --format=csv | 在config.pbtxt中添加optimization: {execution_accelerators: {gpu_execution_accelerator: [{name:"tensorrt"}]}}启用TensorRT优化 |
模型输出全为0 | 输入数据未归一化，超出模型训练范围 | curl http://localhost:8000/v2/models/recommendation_v2/stats | 检查inference_count是否增长，若增长但输出异常，用tritonclient打印原始输入数据分布 |
5.2 独家避坑技巧：来自三年产线的血泪总结
技巧一：用tritonserver --model-repository=/models --strict-model-config=false跳过config校验
开发阶段，strict-model-config=true（默认）会因config.pbtxt缺失字段而拒绝启动。但生产环境必须设为true，否则Triton可能用默认值（如max_batch_size=0）导致性能灾难。我们的CI流程是：开发用false快速验证，CI流水线用true强制校验。
技巧二：model-controlAPI的幂等性陷阱/load接口对已加载模型重复调用会报错，但/unload对未加载模型调用会静默成功。因此灰度脚本必须先/load new_version，再/unload old_version，顺序颠倒会导致双模型同时在线，显存爆满。
技巧三：特征工程必须与模型解耦，哪怕多一次网络调用
曾有团队为省事，在Triton custom backend里集成特征计算，结果因特征库版本升级，导致所有模型服务崩溃。现在我们强制规定：特征计算由独立微服务（Feast Feature Store）提供，Triton只接收feature_vector: List[float]。多一次gRPC调用（<5ms），换来的是模型与特征的完全解耦。
技巧四：监控告警必须设置“静默期”
Triton的/v2/metrics每秒暴露数千指标，若对每个nv_inference_compute_duration_us都设告警，会产生海量噪音。我们只监控三个黄金指标：nv_inference_request_success{model="xxx"} < 0.95（成功率）、nv_inference_queue_duration_us{model="xxx"} > 100000（排队超100ms）、nv_gpu_duty_cycle{device="0"} < 10（GPU空闲）。且所有告警设置5分钟静默期，避免瞬时抖动误报。
技巧五：模型回滚不是“删文件”，而是“切版本”
当新模型引发故障，最快速恢复不是删/models/xxx/2/，而是用/load重新加载/models/xxx/1/，再/unload掉/2/。整个过程<3秒，且不中断服务。我们甚至将此封装成rollback.sh脚本，放入SRE应急手册首页。
6. 持续验证机制：让模型退化无所遁形
6.1 在线验证流水线（Online Validation Pipeline）
模型上线不是终点，而是持续验证的起点。我们构建了三层验证：
实时层（Real-time）：Triton内置的
data drift探针，每10秒扫描1000个请求样本，计算特征分布偏移。当user_location的熵值下降20%，自动触发alert: feature_stagnation。近实时层（Near-real-time）：用Spark Streaming消费Kafka中的模型请求日志（含输入特征、模型版本、预测结果），每5分钟计算
prediction_distribution（如CTR预测值在[0,0.1]区间的占比）。若该占比从65%突变为82%，说明模型对长尾用户失效。离线层（Offline）：每日凌晨用最新24小时线上数据，重跑模型评估（AUC、LogLoss），并与基线模型对比。差异>0.5%时，自动创建Jira ticket，指派算法同学分析。
这套机制让我们在某次线上事故中提前47分钟发现风险：user_session_length特征的均值从12.3骤降至8.1，而模型预测CTR却未同步下降，说明模型对会话长度不敏感，已出现概念漂移。我们在业务方投诉前，主动下线了该模型。
6.2 模型健康度评分（Model Health Score）
我们定义了一个0-100分的健康度指标，综合五个维度：
| 维度 | 权重 | 计算方式 | 健康阈值 |
|---|---|---|---|
| 服务可用性 | 20% | (uptime_last_24h / 24) * 100 | ≥99.9% |
| 请求成功率 | 25% | sum(success) / sum(total) | ≥99.5% |
| P99延迟 | 20% | 100 - min(100, (p99_ms - baseline_p99) / baseline_p99 * 100) | ≥80分 |
| 数据漂移 | 20% | 100 - max_drift_score * 100（KS检验） | ≥90分 |
| 预测稳定性 | 15% | 1 - std(prediction_values) / mean(prediction_values) | ≥85分 |
每日自动生成报告，健康分<85的模型进入“观察名单”，连续3天<80则强制下线。这个分数不是KPI，而是技术债仪表盘——它让“模型老化”从模糊感知变成可量化、可追踪、可行动的工程问题。
7. 运维协同工作流：打破算法与SRE之间的那堵墙
7.1 模型发布SOP（Standard Operating Procedure）
我们废除了“算法提PR，SRE合并”的旧流程，改为基于GitOps的自动化发布：
- 算法同学：在
models/仓库提交PR，包含{model_name}/{version}/config.pbtxt和model.{pt/onnx}； - CI流水线：自动执行
tritonclient本地验证 +tritonserver --model-repository=/tmp/models --strict-model-config=true启动测试； - 审批门禁：PR需通过算法TL和SRE TL双签，SRE重点审核
config.pbtxt中的instance_group和max_batch_size； - 自动部署：合并后，Argo CD检测到
models/仓库变更，自动触发kubectl apply -f triton-deploy.yaml； - 自动验证：部署后，CI流水线调用
/v2/repository/models/{name}/versions/{ver}/ready确认加载成功，并发送Slack通知。
整个流程平均耗时11分钟，比人工部署快5.3倍，且100%可追溯。
7.2 故障响应RACI矩阵
当模型服务异常时，明确各方职责，避免扯皮：
| 任务 | Responsible（执行） | Accountable（担责） | Consulted（咨询） | Informed（知悉） |
|---|---|---|---|---|
| 检查Triton Pod状态 | SRE | SRE TL | 算法工程师 | 产品经理 |
分析/v2/metrics指标 | SRE | SRE TL | 算法工程师 | 技术总监 |
| 验证输入数据分布 | 算法工程师 | 算法TL | SRE | 业务方 |
| 执行模型回滚 | SRE | SRE TL | 算法工程师 | 全体成员 |
| 撰写故障复盘报告 | 算法工程师+SRE | 技术总监 | 全体成员 | CEO |
我们强制要求：所有故障必须在24小时内产出复盘报告，且必须包含“下次如何避免”的具体Action Item。例如，某次因config.pbtxt中dims写错导致服务不可用，Action Item是：“在CI流水线中加入dims校验脚本，比对模型导出时的torch.jit.trace参数”。
8. 最后的经验体会：生产化不是技术问题，而是认知升级
我在Part 4的实践中最深刻的体会是：机器学习生产化最大的障碍，从来不是技术选型，而是角色认知的错位。算法工程师习惯说“我的模型AUC是0.85”，但SRE听到的是“这个数字在GPU上跑多久？占多少显存？失败了怎么降级？”；SRE习惯说“服务SLA是99.99%”，但算法工程师想的是“这个SLA下，我能用多大的batch size做在线学习？”——双方用不同语言描述同一个系统。Part 4的价值，就是强行把这两套语言翻译成同一份契约：config.pbtxt是技术契约，健康度评分是质量契约，RACI矩阵是协作契约。当你不再问“怎么把Notebook上线”，而是问“这个模型需要什么样的服务契约”，你就真正跨过了从实验室到产线的最后一道门槛。至于工具，Triton也好，KServe也罢，都只是契约的载体。真正的生产化，始于一份写清楚“谁在什么条件下，为谁承担什么责任”的文档。这是我踩过27次坑后，最想告诉后来者的一句话。