企业官网建设流程全解析

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

“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题里藏着一个被无数数据科学家反复咀嚼、又悄悄咽下的苦涩真相：我们花了80%的时间调参、画图、在Jupyter里把准确率从92.3%刷到92.7%，却只留20%的精力（甚至更少）去思考——当模型明天就要接入订单系统、要扛住双十一流量峰值、要每天凌晨三点自动重训并报警、要让运维同事不用查Python文档就能重启服务时，它到底该长成什么样子？Part 4不是技术演进的序号，而是实战压力测试的临界点。它意味着你已经走过了数据清洗（Part 1）、特征工程（Part 2）、模型选型与验证（Part 3），现在必须直面那个没人愿意深聊但决定项目生死的问题：模型如何脱离笔记本的温床，在没有IDE、没有pip install权限、没有print()调试窗口的真实生产环境里，稳定、可观测、可维护地持续提供预测服务？这不是“部署”两个字能概括的轻量动作，而是一整套工程化肌肉记忆的建立过程。它涉及容器镜像的精简构建、API网关的流量熔断策略、模型版本的灰度发布机制、GPU资源的隔离调度，甚至包括日志里一句model.predict() took 42ms背后所隐含的P99延迟保障逻辑。我带过三支不同行业的ML工程团队，从金融风控到工业质检，最常听到的崩溃瞬间不是模型崩了，而是业务方凌晨两点打电话问：“你们那个‘实时评分’接口，为什么返回503？我们下游支付系统卡住了。”——那一刻，你写的不是.py文件，是SLA协议里的白纸黑字。本文不讲理论，只拆解我在银行核心信贷系统上线前72小时里，亲手敲进Kubernetes集群的每一条命令、改过的每一个Dockerfile参数、以及压测时发现的那个让P95延迟飙升300ms的PyTorch DataLoader线程锁死问题。所有内容，均可直接抄作业。

2. 核心设计思路：为什么放弃Flask+Gunicorn，选择FastAPI+Uvicorn+Triton的三层架构

2.1 传统方案的隐形陷阱：从“能跑”到“敢用”的鸿沟

很多团队的第一反应是沿用开发期的Flask+Gunicorn组合。毕竟本地flask run跑得飞起，加个Gunicorn多进程似乎就“生产就绪”了。我试过——在某次电商大促压测中，单节点QPS刚过800，Gunicorn的worker进程就开始疯狂fork失败，错误日志里全是OSError: [Errno 12] Cannot allocate memory。根本原因在于：Gunicorn是为CPU密集型Web请求设计的，它通过预分叉（pre-fork）模式启动多个Python进程，每个进程都完整加载整个模型权重（比如一个BERT-base模型约400MB），再叠加上PyTorch的CUDA上下文初始化内存开销。当模型本身是GPU推理任务时，这种架构等于在GPU显存上强行复制N份模型副本，而Gunicorn的worker数量又往往按CPU核数配置（比如16核配16个worker），结果就是显存瞬间耗尽，连第一个请求都接不住。这不是配置调优能解决的，是架构基因缺陷。

提示：别被“支持异步”这类宣传迷惑。Gunicorn的异步worker（gevent/eventlet）本质仍是协程，无法绕过Python GIL对CPU密集型计算的限制，对模型推理这种纯计算负载毫无增益。

2.2 FastAPI+Uvicorn：为什么它是API层的最优解

我们最终选定FastAPI作为Web框架，核心依据不是它的自动生成Swagger文档有多炫，而是其底层依赖Uvicorn的真正的异步I/O能力。Uvicorn基于uvloop（libuv的Python绑定）和httptools，能在一个OS线程内高效处理数千个并发连接。关键在于，它把“接收HTTP请求”和“执行模型推理”这两个动作做了清晰分离：

• I/O层（Uvicorn）：专注处理网络连接、解析HTTP头、序列化JSON响应，全程非阻塞，毫秒级完成；
• 计算层（模型推理）：由独立的、受控的线程池或进程池执行，避免阻塞事件循环。

这意味着，当1000个用户同时发起请求时，Uvicorn不会为每个请求创建新线程，而是将请求快速入队，由后端有限的推理工作线程（比如固定4个）依次处理。这直接解决了Gunicorn的内存爆炸问题——模型权重只需加载一次，所有推理请求共享同一份内存映射。

实操中，我们配置Uvicorn启动参数如下：

uvicorn main:app --host 0.0.0.0:8000 --port 8000 \ --workers 1 \ # 关键！只启1个Uvicorn主进程，靠异步处理连接 --limit-concurrency 1000 \ # 限制并发请求数，防雪崩 --timeout-keep-alive 5 \ # 保持连接超时，减少TIME_WAIT --log-level info

注意--workers 1：这是反直觉但至关重要的设置。Uvicorn的异步模型不需要多进程，多开worker反而会因进程间通信开销降低性能。

2.3 Triton Inference Server：为什么需要独立的模型服务层

FastAPI解决了API网关问题，但模型推理本身仍有巨大优化空间。我们曾把PyTorch模型直接嵌入FastAPI的predict()函数里，结果压测发现：单次推理耗时波动极大（20ms~200ms），P99延迟完全不可控。根源在于PyTorch的动态图执行、CUDA流调度、以及Python解释器本身的GC抖动。

NVIDIA Triton Inference Server（以下简称Triton）正是为此而生。它是一个专为AI模型推理设计的高性能、多框架、多实例服务引擎。其核心价值体现在三个硬核能力上：

1. 模型实例化管理（Model Instance Grouping）：Triton允许为同一模型配置多个GPU实例（如instance_group [ { count: 2, gpus: [0] } ]），每个实例独占一块GPU显存区域，实现物理隔离。当请求涌入时，Triton自动将请求轮询分发到空闲实例，彻底消除单实例瓶颈。
2. 动态批处理（Dynamic Batching）：Triton能在毫秒级时间内，将多个小批量请求（如10个单样本请求）自动聚合成一个大batch（如batch_size=10）送入模型，显著提升GPU利用率。我们在图像分类场景下实测，开启动态批处理后，吞吐量提升3.2倍，P99延迟下降65%。
3. 多框架原生支持：无需将模型转换为ONNX。Triton原生支持PyTorch（TorchScript）、TensorFlow、ONNX、TensorRT等格式。我们保留了PyTorch的TorchScript编译流程，因为其调试友好性远超TensorRT的黑盒优化。

架构上，我们采用FastAPI（API网关） → Triton（模型服务）的两级调用。FastAPI不直接加载模型，而是通过HTTP/gRPC协议向本地Triton服务（http://localhost:8000/v2/models/credit_score/infer）发送标准化推理请求。这种解耦带来三大收益：

• 故障隔离：Triton崩溃不影响API网关的健康检查探针；
• 弹性伸缩：可独立对Triton服务进行水平扩缩（如增加GPU节点）；
• 模型热更新：Triton支持模型版本管理，新模型上传后，旧版本请求仍可继续处理，实现无缝切换。

注意：Triton默认监听0.0.0.0:8000，但FastAPI也用8000端口——必须修改Triton端口。我们在config.pbtxt中明确指定backend_config: "http, port=8001"，避免端口冲突。

3. 实操全流程：从Notebook模型到K8s集群的7个关键步骤

3.1 步骤一：模型固化——从model.train()到model.eval()的严肃仪式

在Notebook里，我们习惯写model = MyModel().to('cuda')然后直接model(input)。但在生产环境，这行代码暗藏杀机。PyTorch的train()模式会启用Dropout和BatchNorm的训练行为（如BatchNorm使用当前batch的均值方差），而eval()模式则冻结这些层。如果忘记切换，模型在推理时会输出完全不可预测的结果。

更深层的问题是权重固化。Notebook中模型权重可能还在nn.Parameter状态，包含梯度计算图。生产环境需要的是静态、无梯度、可序列化的模型快照。我们的标准流程是：

1. 强制eval()并禁用梯度：

   model.eval() for param in model.parameters(): param.requires_grad = False # 彻底切断梯度链

2. 导出为TorchScript：优先选择torch.jit.script()而非torch.jit.trace()，因为前者能完整捕获控制流（如if/else、for循环），后者仅记录一次执行路径，对动态输入长度的模型（如NLP）极易失效。

   # 假设模型接受 (batch_size, seq_len) 的input_ids example_input = torch.randint(0, 1000, (1, 128)).to('cuda') traced_model = torch.jit.script(model, example_input) # 注意：script需传入实际输入样例 traced_model.save("model.pt") # 保存为.pt文件，非.pth

3. 验证导出正确性：在导出后立即加载并比对输出，这是防止“导出即失效”的黄金步骤。

   loaded_model = torch.jit.load("model.pt").to('cuda') with torch.no_grad(): orig_out = model(example_input) load_out = loaded_model(example_input) assert torch.allclose(orig_out, load_out, atol=1e-5), "TorchScript导出结果不一致！"

3.2 步骤二：构建最小化Docker镜像——从2.3GB到387MB的瘦身革命

一个典型的pip install torch torchvision基础镜像动辄2GB以上，其中90%的组件（如CUDA Toolkit的完整开发包、C++编译器）在推理时完全用不到。我们采用多阶段构建（Multi-stage Build）策略，将构建环境与运行环境彻底分离：

# 第一阶段：构建环境（含完整CUDA、PyTorch） FROM nvidia/cuda:11.8.0-devel-ubuntu22.04 RUN apt-get update && apt-get install -y python3-pip python3-dev RUN pip3 install torch==2.0.1+cu118 torchvision==0.15.2+cu118 --extra-index-url https://download.pytorch.org/whl/cu118 # 复制模型和代码 COPY model.pt /app/model.pt COPY main.py /app/main.py # 第二阶段：极简运行时（仅含CUDA运行时库） FROM nvidia/cuda:11.8.0-runtime-ubuntu22.04 # 安装最小化Python运行时 RUN apt-get update && apt-get install -y python3 python3-pip && rm -rf /var/lib/apt/lists/* # 从第一阶段拷贝已编译的PyTorch wheel（关键！） COPY --from=0 /usr/local/lib/python3.10/site-packages/torch /usr/local/lib/python3.10/site-packages/torch COPY --from=0 /usr/local/lib/python3.10/site-packages/torchvision /usr/local/lib/python3.10/site-packages/torchvision # 拷贝应用文件 COPY --from=0 /app/ /app/ WORKDIR /app # 安装FastAPI等轻量依赖 RUN pip3 install fastapi uvicorn pydantic numpy CMD ["uvicorn", "main:app", "--host", "0.0.0.0:8000", "--port", "8000"]

这个Dockerfile的核心技巧在于：

• 复用已编译的PyTorch：第一阶段安装的PyTorch包含所有CUDA内核，第二阶段直接拷贝二进制文件，避免在精简镜像中重复编译；
• 剔除编译工具链：runtime-ubuntu22.04镜像不含gcc、make等，体积锐减；
• 精确控制Python版本：显式指定python3.10，避免Ubuntu默认Python版本升级导致的兼容性问题。

构建后镜像大小从2.3GB降至387MB，推送至私有Harbor仓库耗时从12分钟缩短至90秒，K8s拉取镜像时间从平均45秒降至8秒。

3.3 步骤三：Triton模型仓库结构——让服务“看懂”你的模型

Triton不接受单个.pt文件，它要求一个严格定义的模型仓库（Model Repository）目录结构。这是新手最容易卡壳的环节。我们的标准结构如下：

models/ ├── credit_score/ # 模型名称（必须小写、无下划线） │ ├── 1/ # 版本号（正整数，越大越新） │ │ └── model.pt # TorchScript模型文件 │ └── config.pbtxt # 模型配置文件（必须！） └── ...

config.pbtxt是灵魂所在，它告诉Triton：“这个模型长什么样、怎么喂数据、输出什么”。一个典型配置如下：

name: "credit_score" platform: "pytorch_libtorch" max_batch_size: 32 # Triton能接受的最大batch size # 输入定义：必须与TorchScript模型的forward签名完全一致 input [ { name: "input_ids" data_type: TYPE_INT32 dims: [ -1 ] # -1表示动态维度，即seq_len可变 } ] # 输出定义：必须与模型return的tensor name匹配 output [ { name: "scores" data_type: TYPE_FP32 dims: [ 2 ] # 二分类输出[reject_prob, approve_prob] } ] # Triton核心优化配置 instance_group [ { count: 2 # 在GPU 0上启动2个模型实例 gpus: [0] } ] dynamic_batching [ # 启用动态批处理 max_queue_delay_microseconds: 1000 # 请求等待聚合的最大时间（1ms） ]

注意：dims: [-1]中的-1是Triton语法，表示该维度可变；若写成[128]则Triton会强制要求输入长度必须为128，否则报错INVALID_ARG。

3.4 步骤四：Kubernetes部署——YAML文件里的生存法则

在K8s中部署Triton，绝不是简单kubectl apply -f triton.yaml。我们必须应对GPU资源调度、健康检查、流量治理三大挑战。以下是生产环境验证过的triton-deployment.yaml核心片段：

apiVersion: apps/v1 kind: Deployment metadata: name: triton-server spec: replicas: 1 selector: matchLabels: app: triton-server template: metadata: labels: app: triton-server spec: # 关键：GPU资源请求与限制 containers: - name: triton image: nvcr.io/nvidia/tritonserver:23.07-py3 resources: limits: nvidia.com/gpu: 1 # 严格限制使用1块GPU requests: nvidia.com/gpu: 1 # Triton启动命令，指向模型仓库 args: [ "--model-repository=/models", "--http-port=8000", "--grpc-port=8001", "--metrics-port=8002", "--strict-model-config=false", # 允许config.pbtxt缺失某些字段 "--log-verbose=1" # 日志级别，生产环境建议设为0 ] volumeMounts: - name: models mountPath: /models volumes: - name: models persistentVolumeClaim: claimName: triton-models-pvc # 模型仓库挂载为PVC，支持热更新 # 健康检查：Triton提供内置HTTP端点 livenessProbe: httpGet: path: /v2/health/live port: 8000 initialDelaySeconds: 60 periodSeconds: 30 readinessProbe: httpGet: path: /v2/health/ready port: 8000 initialDelaySeconds: 45 periodSeconds: 15 --- # Service暴露Triton的HTTP和gRPC端口 apiVersion: v1 kind: Service metadata: name: triton-service spec: selector: app: triton-server ports: - name: http port: 8000 targetPort: 8000 - name: grpc port: 8001 targetPort: 8001

这里的关键细节：

• nvidia.com/gpu资源请求：必须与集群中GPU设备插件（如NVIDIA Device Plugin）注册的资源名完全一致，否则调度失败；
• --strict-model-config=false：在模型调试期开启，允许Triton忽略config.pbtxt中缺失的字段（如未定义version_policy），避免因配置不全导致服务启动失败；
• livenessProbe与readinessProbe分离：/live端点只检查进程存活，/ready端点检查模型是否加载完成。若合并使用，模型加载中（可能长达数分钟）会导致Pod被反复重启。

3.5 步骤五：FastAPI服务对接——用HTTP协议驯服Triton

FastAPI服务通过HTTP协议调用Triton，而非直接加载模型。这要求我们编写健壮的客户端代码，处理网络超时、重试、错误码映射。核心逻辑封装在inference_client.py中：

import httpx from typing import Dict, List, Any import json class TritonClient: def __init__(self, triton_url: str = "http://triton-service:8000"): self.client = httpx.AsyncClient( timeout=httpx.Timeout(10.0, connect=5.0), # 连接5秒，总超时10秒 limits=httpx.Limits(max_connections=100, max_keepalive_connections=20) ) self.triton_url = triton_url async def predict(self, input_ids: List[int]) -> Dict[str, float]: # 构造Triton标准推理请求体 request_body = { "inputs": [{ "name": "input_ids", "shape": [1, len(input_ids)], # Triton要求明确shape "datatype": "INT32", "data": input_ids }], "outputs": [{"name": "scores"}] } try: response = await self.client.post( f"{self.triton_url}/v2/models/credit_score/infer", content=json.dumps(request_body), headers={"Content-Type": "application/json"} ) response.raise_for_status() # 抛出4xx/5xx异常 result = response.json() # 解析Triton返回的scores数据（一维数组） scores = result["outputs"][0]["data"] return {"reject_prob": float(scores[0]), "approve_prob": float(scores[1])} except httpx.HTTPStatusError as e: if e.response.status_code == 400: raise ValueError(f"Triton请求参数错误: {e.response.text}") elif e.response.status_code == 404: raise RuntimeError("Triton模型未找到，请检查模型名称和版本") else: raise RuntimeError(f"Triton服务异常: {e}") except httpx.TimeoutException: raise TimeoutError("Triton推理超时，请检查GPU负载") except Exception as e: raise RuntimeError(f"未知错误: {str(e)}") # FastAPI路由中使用 @app.post("/score") async def get_credit_score(request: CreditRequest): client = TritonClient() try: result = await client.predict(request.input_ids) return {"status": "success", "data": result} except Exception as e: logger.error(f"Score API error: {str(e)}") raise HTTPException(status_code=500, detail=str(e))

这段代码的价值在于：

• 显式超时控制：httpx.Timeout(10.0, connect=5.0)确保连接和总耗时不失控；
• 错误码精准映射：将Triton的400/404等HTTP错误转化为业务可理解的异常类型；
• 异步非阻塞：await self.client.post()不阻塞FastAPI事件循环，支撑高并发。

3.6 步骤六：可观测性埋点——让每一毫秒的延迟都有迹可循

生产环境没有print()，只有指标、日志、链路追踪。我们为整个链路注入三层可观测性：

1. Prometheus指标：在FastAPI中集成prometheus-fastapi-instrumentator，自动采集HTTP请求延迟、错误率、Triton调用耗时：

   from prometheus_fastapi_instrumentator import Instrumentator instrumentator = Instrumentator( should_group_status_codes=True, should_ignore_untemplated=True, should_respect_env_var=True, excluded_handlers=["/health", "/metrics"], ) instrumentator.instrument(app).expose(app) # 暴露/metrics端点

2. 结构化日志：使用structlog替代logging，每条日志包含request_id、model_version、input_length等上下文：

   logger = structlog.get_logger() logger.info("inference_start", request_id="req_abc123", model_name="credit_score", input_length=len(input_ids))

3. OpenTelemetry链路追踪：通过opentelemetry-instrumentation-fastapi自动注入Span，可视化FastAPI → Triton → GPU Kernel的完整调用链。在Grafana中，我们能清晰看到：一次请求中，FastAPI处理耗时3ms，网络传输2ms，Triton排队5ms，GPU计算18ms，总耗时28ms——当P99飙升时，一眼定位瓶颈在GPU计算层。

3.7 步骤七：CI/CD流水线——从Git Push到K8s上线的12分钟自动化

最后一步是固化流程。我们使用GitLab CI构建端到端流水线，核心阶段如下：

整个流水线从代码提交到Staging环境可用，平均耗时11分48秒。最关键的是smoke-test阶段——它用真实的HTTP请求验证模型服务是否真正“活”着，而非仅仅Pod Running。这是防止“部署成功但服务不可用”这类低级错误的最后一道防线。

4. 常见问题与排查技巧实录：那些深夜告警背后的真相

4.1 问题一：Triton Pod反复CrashLoopBackOff，日志显示CUDA driver version is insufficient

现象：K8s中Triton Pod状态为CrashLoopBackOff，kubectl logs输出E0712 03:22:17.123456 1 cuda_utils.cc:123] CUDA driver version is insufficient for CUDA runtime version。

根因分析：这是GPU环境最经典的版本错配。Triton容器镜像（如23.07-py3）内置的CUDA Runtime版本（11.8）要求宿主机NVIDIA Driver版本≥525.60.13。而我们的测试节点Driver版本仅为470.129.06，低于最低要求。

排查步骤：

1. 登录K8s节点，执行nvidia-smi查看Driver版本；
2. 查阅Triton官方文档的 Compatibility Matrix ，确认所需Driver版本；
3. 对比节点Driver与要求版本。

解决方案：

• 短期：降级Triton镜像至22.12-py3（要求Driver≥450.80.02），命令：kubectl set image deployment/triton-server triton=nvcr.io/nvidia/tritonserver:22.12-py3；
• 长期：升级节点Driver，执行sudo apt-get install --install-recommends nvidia-driver-525（Ubuntu）。

经验：在K8s集群初始化时，必须将nvidia-driver版本纳入基础设施即代码（IaC）管理，用Ansible或Terraform统一管控，避免手工升级遗漏。

4.2 问题二：FastAPI服务P99延迟突增至2秒，但CPU/GPU利用率正常

现象：Grafana监控显示FastAPI的http_request_duration_seconds_bucket{le="0.1"}比例从95%暴跌至30%，但kubectl top pods显示FastAPI和Triton Pod的CPU、GPU Memory均未打满。

根因分析：这是典型的连接池耗尽问题。httpx.AsyncClient默认连接池大小为max_connections=100，当突发流量超过100 QPS时，后续请求会在连接池队列中等待，直到超时。而httpx.Timeout的connect参数只控制建立TCP连接的超时，不控制队列等待时间。

验证方法：

• 在FastAPI服务中添加连接池监控：

  from httpx import AsyncClient client = AsyncClient(limits=httpx.Limits(max_connections=100)) # 在请求前打印连接池状态 print(f"Pool stats: {client._transport._pool._connections}")

• 压测时观察日志，若出现大量Connection pool is full, discarding connection，即确诊。

解决方案：

• 扩大连接池：将max_connections从100提升至500，并同步调整max_keepalive_connections；
• 引入熔断：在TritonClient.predict()中加入Hystrix式熔断逻辑，当连续5次请求超时，自动降级为返回缓存结果或503错误，避免雪崩。

4.3 问题三：Triton动态批处理失效，P95延迟无改善

现象：开启dynamic_batching后，tritonserver --metrics显示dynamic_batch_size始终为1，未发生聚合。

根因分析：动态批处理生效需同时满足三个条件：

1. 请求到达Triton的时间间隔 <max_queue_delay_microseconds（默认1000微秒）；
2. 请求的input shape完全一致（如[1,128]和[1,127]视为不同shape）；
3. Triton配置中max_batch_size≥ 单个请求的batch size。

我们的问题出在第2点：前端服务未对input_ids做padding，导致每次请求的seq_len随机（112, 134, 97...），Triton认为每个请求都是不同shape，拒绝聚合。

解决方案：

• 前端统一padding：在FastAPI接收请求后，将input_idspadding至固定长度（如128），并传入attention_mask；
• Triton配置优化：在config.pbtxt中显式声明dynamic_batching的preferred_batch_size: [8, 16, 32]，引导Triton优先聚合这些尺寸。

4.4 问题四：模型更新后，新版本请求返回404，旧版本请求正常

现象：上传新模型版本2/到模型仓库，curl http://triton:8000/v2/models/credit_score/versions返回["1"]，新版本2未列出。

根因分析：Triton的模型加载是主动扫描机制，默认每30秒扫描一次模型仓库。新目录创建后，Triton尚未触发下一次扫描。

解决方案：

• 手动重载：发送HTTP POST请求触发立即重载：

  curl -X POST "http://triton:8000/v2/repository/credit_score/load"

• 配置自动扫描：在Triton启动参数中添加--repository-poll-secs=5，将扫描间隔从30秒缩短至5秒。

4.5 问题五：GPU显存占用100%，但nvidia-smi显示无进程，tritonserver进程RSS仅200MB

现象：nvidia-smi显示GPU-0显存使用率99%，但Processes列表为空，ps aux | grep triton显示tritonserver进程的RSS（常驻内存）仅200MB，远低于显存总量。

根因分析：这是CUDA的显存预分配特性。Triton在启动时会调用cudaMalloc预分配显存池，用于存放模型权重、中间激活值、CUDA流缓冲区。这部分内存被CUDA驱动占用，但不归属于任何用户进程，因此nvidia-smi的Processes列为空。

验证方法：

• 执行nvidia-smi --query-compute-apps=pid,used_memory --format=csv，若返回空，则确认是预分配内存；
• 查看Triton日志，搜索Allocated X MB for GPU Y字样。

解决方案：

• 调整显存分配策略：在config.pbtxt中添加optimization { execution_accelerators { gpu_execution_accelerator [ { name: "tensorrt" } ] } }，启用TensorRT加速，可减少显存占用；
• 限制最大显存：通过--memory-growth=true参数启用显存按需增长，避免一次性全量分配。

5. 实战经验总结：那些文档里不会写的血泪教训

在交付第4个生产级ML服务后，我整理出几条刻在骨子里的经验，它们比任何架构图都更接近真相：

第一，永远假设你的模型会“撒谎”。我们曾上线一个信用评分模型，AUC高达0.92，但上线首周就收到业务方投诉：“为什么给同一个客户连续三次评分，结果分别是0.45、0.67、0.33？”排查发现，模型中一个torch.nn.Dropout层在eval()模式下未被完全禁用（model.eval()后漏掉了model.dropout.training = False）。这个bug在千次测试中从未触发，却在真实流量下高频暴露。从此，我的模型上线Checklist第一条就是：“用1000个相同输入，跑1000次，检查输出标准差是否<1e-6”。

第二，K8s的resources.limits不是保险丝，而是枷锁。给Triton Pod设置nvidia.com/gpu: 1，看似合理，但当GPU因温度过高触发降频时，Triton的推理速度会断崖式下跌，而K8s对此毫无感知，Pod依然标记为Running。我们后来在Prometheus中新增了DCGM_FI_DEV_GPU_UTIL（GPU利用率）和DCGM_FI_DEV_TEMPERATURE（GPU温度）指标告警，当温度>85°C且利用率<10%时，自动触发Pod驱逐，强制调度到其他节点。

第三，不要迷信“自动”。Triton的动态批处理、FastAPI的异步、K8s的自动扩缩容，听起来很美，但它们的触发阈值、冷却时间、聚合策略，全部需要根据你的真实业务流量曲线手工校准。我们曾将hpa的CPU阈值设为70%，结果在早高峰流量陡升时，K8s花了4分钟才完成扩容，而业务已损失2000+订单。最终方案是：放弃CPU指标，改用自定义指标custom.googleapis.com/ml_inference_p95_latency，当P95>100ms时，立即扩容。

第四，文档版本必须与镜像版本强绑定。Triton 23.07