解读

国内线上推理服务普遍要求 7×24 不间断，而 Triton Inference Server 的容器实例一旦重启，GPU 初始化、模型加载、预热通常需要 30 s~2 min，直接造成业务受损。面试官真正想考察的是：

1. 你是否理解 Triton 模型仓库版本化机制与 Model Control API；
2. 能否在 Docker 层把“热更新”与“零停机”打通，而不是简单回答“用 k8s rollingUpdate”；
3. 是否具备 镜像瘦身、优雅探针、GPU 共享、回滚策略 等落地细节，符合国内监管与灰度规范。

知识点

1. Triton 模型仓库目录规范：
   model_repository/<model_name>/config.pbtxt
   └─ 1/、2/ … 版本目录，Triton 默认加载最高版本。
2. Model Control Mode：
   • explicit：需调用 HTTP/gRPC repository/index 与 repository/model/load|unload 接口；
   • poll：Triton 定时扫描文件系统，自动切换至高版本。
3. Docker 层关键技术：
   • 多阶段构建把 tritonserver:23.06-py3-min 与自定义后端、业务插件分离，镜像 < 1 GB；
   • 匿名卷或 hostPath 挂载模型仓库到容器，避免镜像重打；
   • 共享 CUDA 上下文 使用 --gpus all + nvidia-docker2，保证热更新不释放 GPU；
   • preStop hook 调用 triton_grpc_client.unload()，等待 inflight_requests=0 再退出；
   • readinessProbe 检测 v2/health/ready，国内云厂商 SLB 仅转发到 ready 实例；
   • 双缓存策略：本地 SSD 保留新旧两版本，回滚只需 rename 目录，秒级完成。
4. 国内合规：
   • 模型文件含用户数据时需 加密落盘，更新流程走 国密 TLS 1.3 通道；
   • 灰度发布需对接 工信部备案系统，记录模型版本 MD5。

答案

步骤一：镜像侧

1. 使用官方 nvcr.io/nvidia/tritonserver:23.06-py3-min 作为运行时镜像，多阶段构建仅拷贝自定义后端 .so 与启动脚本，镜像从 6 GB 压缩到 980 MB。
2. 构建时 不打包模型，仅保留 /opt/triton-model-repository 空目录，后续通过卷挂载。

步骤二：部署侧

1. 启动命令：

   docker run -d --name triton-hot \
     --gpus all \
     -p 8000:8000 -p 8001:8001 -p 8002:8002 \
     -v /mnt/ssd/model-repo:/opt/triton-model-repository:ro \
     -e TRITON_MODEL_CONTROL_MODE=poll \
     -e TRITON_MODEL_LOAD_THREAD_COUNT=4 \
     -e TRITON_BACKEND_CONFIG=tensorrt,optimization_level=3 \
     --health-cmd="curl -f http://localhost:8000/v2/health/ready" \
     --health-interval=5s \
     triton-hot:23.06
   

2. 更新流程：
   a) 将新模型 3/ 目录 rsync 到 /mnt/ssd/model-repo/<model_name>/，保持文件权限 644；
   b) Triton 默认 poll 间隔 1 s，检测到高版本后自动 unload 旧版本→load 新版本；
   c) 期间 inflight 请求由旧版本继续服务，新请求路由至新版本，实现 零停机；
   d) 若验证失败，立即 mv 3/ 3.bak && mv 2/ 3/ 回滚，Triton 再次热加载，回滚耗时 < 3 s。
3. 监控：
   • 通过 Prometheus + Grafana 采集 nv_inference_queue_duration_us 与 nv_inference_load_ratio，若 P99 延迟突增 > 20 % 自动触发回滚脚本；
   • 日志落盘到 /var/log/triton，使用 Loki 收集，满足国内等保 2.0 审计要求。

步骤三：CI/CD 对接

1. GitLab CI 构建完模型后，计算国密 SM3 摘要，写入 manifest.json；
2. 通过 Ansible 推送到线上 GPU 宿主机，调用 docker exec triton-hot tritonctl reload 立即生效；
3. 蓝绿发布场景下，先启动 shadow 容器挂载同一模型仓库，SLB 权重 0，验证无误后权重切换，老容器 preStop 等待 inflight=0 再销毁，实现 真正零损。

拓展思考

1. 如果模型体积 > 20 GB，poll 模式会阻塞主线程，可把 TRITON_MODEL_CONTROL_MODE 设为 explicit，通过 sidecar 容器异步调用 repository/model/load，并用 ** readinessGate** 通知主容器。
2. 在多租户场景，利用 NVIDIA MPS + CUDA MIG 把 GPU 切成 2 gi 实例，每个实例运行独立 Triton 容器，热更新互不影响，资源利用率提升 40 %。
3. 国内部分金融客户要求 双活数据中心，可基于 Dragonfly P2P 分发模型镜像层，跨机房延迟 < 30 s，配合 Consul DNS 权重切换，实现 同城双活零停机。