1. 为什么机器学习工程师现在必须懂容器？——从“在我机器上能跑”到“在任何地方都稳如磐石”

我带过三届校招的ML工程师，头两年面试时问“你部署过模型吗”，回答基本是：“用Flask写个API，扔到服务器上跑着，偶尔崩了就ssh上去重启一下。”第三年开始，这个问题的答案变了：“我们用Docker打包模型服务，Kubernetes做滚动更新和自动扩缩容，Prometheus监控GPU显存和请求延迟。”这个转变不是赶时髦，而是被现实反复毒打出来的。你有没有经历过这些场景：训练环境用的是CUDA 11.3 + PyTorch 1.12，但生产服务器只装了CUDA 11.0，结果 torch.cuda.is_available() 永远返回 False ；或者同事发来一个 .ipynb ，里面 pip install 了十几个包，版本全靠猜， requirements.txt 里连 torch 都没写明具体小版本，你本地装完发现 torchvision 不兼容直接报错；又或者模型上线后流量突增，手动起三个新进程再改Nginx配置，手忙脚乱中把旧Pod的健康检查端口配错了，导致一半请求502……这些不是“小问题”，是每天都在消耗你本该用来调参、设计特征、优化pipeline的宝贵时间。容器化解决的从来不是“能不能跑”的问题，而是“能不能确定性地、可重复地、可审计地、可规模化地跑”。它把“环境”这个最不可控的变量，变成了一个可版本控制、可CI/CD流水线验证、可灰度发布的标准构件。对ML团队来说，Docker不是运维的工具，它是数据科学家和算法工程师的“环境保险丝”——它确保你花三天调出来的AUC 0.87，在测试、预发、生产三个环境里，数值误差不超过小数点后三位。而Kubernetes，则是这套保险丝的“智能配电箱”，它不关心你模型是XGBoost还是Llama-3，只负责在GPU卡快爆满时自动调度新实例，在某个节点宕机时秒级迁移服务，在凌晨三点流量低谷时把副本数缩到1节省成本。这不是基础设施的升级，是整个ML工作流范式的切换：从“人肉运维驱动”转向“声明式配置驱动”。你写的不再是 bash 脚本，而是YAML里的一行 replicas: 3 ；你不再需要记住每台服务器IP，而是通过 kubectl get svc ml-inference 拿到一个稳定的DNS名。这种确定性，才是让ML项目真正走出实验室、走进业务核心的底层支撑。

2. Docker实战：从零构建一个可复现的PyTorch训练环境

2.1 为什么不能直接用 python:3.9-slim ？——基础镜像选型的硬核逻辑

很多新手一上来就抄网上的Dockerfile，第一行就是 FROM python:3.9-slim ，然后发现 pip install torch 死活装不上，或者装上了但 import torch 报 libcuda.so.1: cannot open shared object file 。这背后是基础镜像选型的致命误区。 python:3.9-slim 是Debian系的精简版，它连 g++ 编译器都没有，更别说CUDA驱动了。而PyTorch官方预编译包分三类：CPU-only、CUDA 11.x、CUDA 12.x。你的宿主机GPU是什么型号？驱动版本多少？这直接决定了你该选哪个基础镜像。我实测过，NVIDIA A100服务器（驱动版本515.65.01）必须用 pytorch/pytorch:2.1.2-cuda11.8-cudnn8-runtime ，而RTX 4090开发机（驱动535.54.03）则要选 pytorch/pytorch:2.1.2-cuda12.1-cudnn8-runtime 。选错的后果不是报错，而是静默降级——它会自动fallback到CPU版本，你根本意识不到模型没走GPU。所以第一步永远是查宿主机： nvidia-smi 看驱动版本， cat /proc/driver/nvidia/version 确认内核模块，再对照 NVIDIA CUDA Toolkit文档 查兼容性。基础镜像不是越小越好，而是“最小必要”。 slim 镜像省下的那100MB空间，换不来GPU加速的10倍性能提升。我现在的标准操作是：训练环境一律用 pytorch/pytorch:2.1.2-cuda12.1-cudnn8-runtime （兼顾新硬件和稳定性），推理服务用 nvcr.io/nvidia/pytorch:23.10-py3 （NVIDIA官方优化版，自带TensorRT加速）。别信“自己编译更轻量”的说法，PyTorch官方镜像已经做了极致优化，你手动编译不仅耗时，还极可能因 CMAKE 参数错误导致性能反降。

2.2 Dockerfile不是脚本，是“环境契约”——每一行指令的深意

下面这个Dockerfile，是我给团队定的ML项目模板，它不是为了“能跑”，而是为了“可审计、可回滚、可协作”：

# 第一层：明确基础依赖，锁定CUDA和PyTorch大版本
FROM pytorch/pytorch:2.1.2-cuda12.1-cudnn8-runtime

# 第二层：创建非root用户，安全底线（K8s PodSecurityPolicy强制要求）
RUN groupadd -g 1001 -f app && useradd -r -u 1001 -g app app
USER app

# 第三层：设置工作目录，所有后续操作在此路径下，避免绝对路径污染
WORKDIR /app

# 第四层：分层缓存关键——先拷贝requirements.txt再安装，利用Docker layer cache
# 这样改代码不重装依赖，改依赖才重装，极大加速CI构建
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt && \
    pip install --no-cache-dir torchmetrics==1.3.0  # 显式指定小版本，防自动升级

# 第五层：拷贝代码，但排除.git和__pycache__，减小镜像体积
COPY --chown=app:app . .
RUN find . -name "__pycache__" -type d -exec rm -rf {} + 2>/dev/null || true

# 第六层：暴露端口，这是服务契约的一部分，K8s Service会据此生成iptables规则
EXPOSE 8000

# 第七层：健康检查入口，K8s livenessProbe会调用此命令
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD curl -f http://localhost:8000/health || exit 1

# 第八层：启动命令，用gunicorn替代原始python app.py，支持多worker和优雅重启
CMD ["gunicorn", "--bind", "0.0.0.0:8000", "--workers", "4", "--timeout", "120", "app:app"]

重点解释几个易被忽略的细节：

• --chown=app:app ：确保代码文件属主是普通用户，避免root权限运行带来的安全风险。K8s默认禁止root容器，这条不加，你的Pod永远处于 CreateContainerConfigError 状态。
• pip install --no-cache-dir ：禁用pip缓存，防止不同构建环境中缓存污染导致依赖不一致。Docker层缓存已足够，不需要额外缓存。
• HEALTHCHECK ：这不是可选项。没有健康检查，K8s无法判断Pod是否真“活着”。我见过太多案例：Python进程没崩溃，但GPU显存泄漏卡死， /health 接口超时，K8s自动杀掉并重建Pod，比人肉发现快10分钟。
• gunicorn ：单线程的 python app.py 在生产环境是自杀行为。 --workers 4 意味着4个独立Python进程处理请求， --timeout 120 防止长尾请求拖垮整个服务。别用 uvicorn ，它默认单进程，虽快但扛不住并发。

2.3 构建与验证：如何证明你的镜像真的“可复现”

构建命令绝不是 docker build -t my-ml-app . 就完事。真实生产流程必须包含验证环节：

# 1. 构建时强制使用最新base image，避免缓存旧镜像
docker build --pull -t my-ml-app:20240520-v1 .

# 2. 启动容器并进入交互模式，验证基础环境
docker run -it --rm --gpus all my-ml-app:20240520-v1 bash
# 在容器内执行：
# python -c "import torch; print(torch.__version__, torch.cuda.is_available())"
# nvidia-smi  # 确认能看到GPU设备

# 3. 验证服务启动和健康检查
docker run -d --gpus all -p 8000:8000 --name test-ml my-ml-app:20240520-v1
sleep 10  # 等待服务启动
curl http://localhost:8000/health  # 应返回{"status":"ok"}
docker stop test-ml

# 4. 扫描镜像安全漏洞（CI中必做）
docker scan my-ml-app:20240520-v1
# 重点关注Critical/High级别漏洞，特别是openssl、libxml2等基础库

最关键的验证点是 GPU可见性 。很多人以为 --gpus all 就万事大吉，其实不然。宿主机NVIDIA驱动版本必须严格匹配基础镜像中的CUDA版本。比如你用 cuda12.1 镜像，宿主机驱动必须≥530，否则 nvidia-smi 在容器内会显示 NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver 。这个错误不会在构建时报出，只会在运行时暴露，是线上事故的高发区。我的经验是：在CI流水线中，构建完立即启动一个临时容器，执行 nvidia-smi --query-gpu=name,temperature.gpu,utilization.gpu --format=csv,noheader,nounits ，解析输出确认GPU型号和温度正常，才算构建成功。

3. Kubernetes深度实践：让ML服务从“能用”到“好用”的关键配置

3.1 不是所有Pod都适合跑ML——资源请求（requests）与限制（limits）的生死线

K8s调度器不是神仙，它靠 resources.requests 和 resources.limits 这两个字段做决策。很多团队把ML服务当普通Web服务配， requests: {cpu: "1", memory: "2Gi"} ，结果上线后Pod频繁OOMKilled或被驱逐。原因在于：ML推理服务的内存和GPU使用模式是脉冲式的。一个BERT模型加载时占3GB显存，但处理单个请求只用500MB；而训练任务则是持续高压。正确做法是 按峰值配limits，按基线配requests 。以一个ResNet50图像分类服务为例：

resources:
  requests:
    cpu: "500m"          # 基线CPU：模型加载、HTTP框架开销
    memory: "1Gi"        # 基线内存：代码+框架+少量缓存
    nvidia.com/gpu: 1    # 必须显式申请GPU，K8s不识别"gpu"这个resource name
  limits:
    cpu: "2"             # 峰值CPU：批量推理时的tensor计算
    memory: "4Gi"        # 峰值内存：大batch加载图片+中间tensor
    nvidia.com/gpu: 1    # GPU limits必须等于requests，K8s不支持GPU超卖

这里的关键陷阱是 nvidia.com/gpu 。K8s本身不原生支持GPU，必须安装 NVIDIA Device Plugin ，它会将每个GPU注册为 nvidia.com/gpu 这个自定义resource。如果你写成 gpu: 1 ，K8s会直接报错 unknown resource gpu 。而且 limits 和 requests 必须相等，因为GPU是独占资源，无法像CPU那样超卖。我踩过的坑：曾把 requests.nvidia.com/gpu 设为 0.5 ，以为能共享GPU，结果Pod永远处于 Pending 状态——K8s调度器找不到有0.5个GPU的节点。GPU只能整卡分配，这是物理限制，不是K8s缺陷。

3.2 Deployment不是“起几个Pod”那么简单——滚动更新与金丝雀发布的工程实践

一个典型的ML服务Deployment YAML，远不止 replicas: 3 这么简单：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ml-inference
  labels:
    app: ml-inference
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # 更新时最多多起1个Pod，保证总副本数<=4
      maxUnavailable: 0  # 更新期间0个Pod不可用，即蓝绿过渡
  minReadySeconds: 30    # 新Pod就绪后等待30秒再标记为ready，防冷启动抖动
  revisionHistoryLimit: 5 # 只保留最近5次revision，防etcd存储爆炸
  selector:
    matchLabels:
      app: ml-inference
  template:
    metadata:
      labels:
        app: ml-inference
      annotations:
        prometheus.io/scrape: "true"   # 告诉Prometheus抓取此Pod指标
        prometheus.io/port: "8000"
    spec:
      containers:
      - name: ml-model
        image: my-registry.com/ml-inference:20240520-v1
        resources: { ... } # 如上节所述
        env:
        - name: MODEL_PATH
          value: "/models/resnet50_v1.pth"
        - name: LOG_LEVEL
          valueFrom:
            configMapKeyRef:
              name: ml-config
              key: log_level
        ports:
        - containerPort: 8000
          name: http
        livenessProbe:
          httpGet:
            path: /health
            port: 8000
          initialDelaySeconds: 60   # 模型加载需60秒，不能太早探活
          periodSeconds: 30
        readinessProbe:
          httpGet:
            path: /readyz
            port: 8000
          initialDelaySeconds: 30   # 就绪探针比存活探针早30秒
          periodSeconds: 10
        volumeMounts:
        - name: models
          mountPath: /models
      volumes:
      - name: models
        persistentVolumeClaim:
          claimName: ml-models-pvc

重点解析几个生产级配置：

• maxUnavailable: 0 ：这是金丝雀发布的基础。它确保更新过程中，旧Pod不销毁，新Pod启动成功后才销毁旧Pod，实现真正的零停机。很多团队设成 1 ，以为“损失一个Pod没关系”，但在高并发场景下，3个Pod变2个，QPS直接跌33%，用户明显感知。
• minReadySeconds: 30 ：新Pod启动后，K8s会立即将其加入Service的Endpoint，但此时模型可能还在加载权重。 minReadySeconds 强制等待30秒，让模型热身完成再导流，避免首请求超时。
• livenessProbe.initialDelaySeconds: 60 ：模型加载是重IO操作，ResNet50权重文件200MB，从PV读取+反序列化需40-50秒。如果探针5秒就发起，会误判Pod死亡，反复重启，形成“重启风暴”。
• readinessProbe vs livenessProbe ：就绪探针（readiness）决定是否接收流量，存活探针（liveness）决定是否重启容器。两者阈值必须不同。就绪探针应更激进（ initialDelaySeconds: 30 ），让服务尽快接入流量；存活探针应更保守（ initialDelaySeconds: 60 ），避免误杀。我见过因两者相同导致的惨案：模型加载到55秒时，存活探针触发，容器重启，重新加载，无限循环。

3.3 Service与Ingress：让外部世界安全、高效地访问你的ML模型

一个ML服务对外暴露，绝不是简单 kubectl expose 就能搞定。你需要三层网络抽象：

# 1. ClusterIP Service：集群内部通信的稳定入口
apiVersion: v1
kind: Service
metadata:
  name: ml-inference-svc
spec:
  selector:
    app: ml-inference
  ports:
  - port: 8000
    targetPort: 8000
    protocol: TCP
  type: ClusterIP  # 默认，仅集群内可访问

# 2. Ingress：七层路由，支持HTTPS、路径转发、WAF集成
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ml-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    nginx.ingress.kubernetes.io/proxy-body-size: "50m"  # 允许50MB图片上传
    cert-manager.io/cluster-issuer: "letsencrypt-prod"   # 自动签发HTTPS证书
spec:
  ingressClassName: nginx
  tls:
  - hosts:
      - ml-api.yourcompany.com
    secretName: ml-tls-secret
  rules:
  - host: ml-api.yourcompany.com
    http:
      paths:
      - path: /v1/classify
        pathType: Prefix
        backend:
          service:
            name: ml-inference-svc
            port:
              number: 8000
      - path: /metrics
        pathType: Prefix
        backend:
          service:
            name: prometheus-svc  # 指向Prometheus服务
            port:
              number: 9090

# 3. NetworkPolicy：最小权限网络隔离（可选但强烈推荐）
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: ml-network-policy
spec:
  podSelector:
    matchLabels:
      app: ml-inference
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: api-gateway  # 只允许API网关访问
    ports:
    - protocol: TCP
      port: 8000
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          name: default
      podSelector:
        matchLabels:
          app: redis  # 只允许访问redis
    ports:
    - protocol: TCP
      port: 6379

为什么需要这三层？

• ClusterIP 是内部服务发现的基石。你的训练任务Pod、数据预处理Pod、监控采集Pod，都通过 ml-inference-svc:8000 这个DNS名访问，而不是硬编码IP。K8s CoreDNS自动解析，且支持负载均衡。
• Ingress 解决的是外部访问问题。 nginx.ingress.kubernetes.io/proxy-body-size: "50m" 这一行至关重要——ML服务常需上传大图片或视频，Nginx默认只允许1MB，不改这个，用户上传必413。 cert-manager 自动管理HTTPS证书，避免手动更新过期证书导致服务中断。
• NetworkPolicy 是安全最后一道锁。默认情况下，K8s集群内所有Pod可互相访问。 NetworkPolicy 强制规定：只有 api-gateway 能访问ML服务，ML服务只能访问 redis ，其他一切连接都被拒绝。这能有效遏制横向移动攻击，比如某个Web服务被黑，黑客无法通过它跳转到你的GPU集群。

4. MLOps流水线实战：从代码提交到模型上线的全自动闭环

4.1 CI阶段：用GitHub Actions构建可验证的Docker镜像

我们的CI流水线不是“跑通测试就行”，而是构建出 带完整元数据的、可追溯的、带安全扫描的 镜像。以下是核心步骤：

name: Build and Scan ML Model Image
on:
  push:
    branches: [main]
    paths:
      - 'Dockerfile'
      - 'requirements.txt'
      - 'app/**'
      - '.github/workflows/ml-ci.yml'

jobs:
  build-and-scan:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v3

    # 步骤1：登录私有镜像仓库（如Harbor）
    - name: Login to Container Registry
      uses: docker/login-action@v2
      with:
        registry: ${{ secrets.REGISTRY_URL }}
        username: ${{ secrets.REGISTRY_USERNAME }}
        password: ${{ secrets.REGISTRY_PASSWORD }}

    # 步骤2：构建镜像，打两个tag：语义化版本+git commit hash
    - name: Build and Push Docker Image
      uses: docker/build-push-action@v4
      with:
        context: .
        push: true
        tags: |
          ${{ secrets.REGISTRY_URL }}/ml-inference:${{ github.sha }}
          ${{ secrets.REGISTRY_URL }}/ml-inference:latest
        cache-from: type=gha
        cache-to: type=gha,mode=max

    # 步骤3：安全扫描，Critical漏洞直接失败
    - name: Scan Docker Image
      uses: anchore/scan-action@v4
      with:
        image: ${{ secrets.REGISTRY_URL }}/ml-inference:${{ github.sha }}
        fail-build: true
        severity-cutoff: critical

    # 步骤4：运行单元测试（在镜像内执行，确保环境一致）
    - name: Run Unit Tests in Container
      run: |
        docker run --rm \
          --entrypoint /bin/bash \
          ${{ secrets.REGISTRY_URL }}/ml-inference:${{ github.sha }} \
          -c "pip install pytest && cd /app && pytest tests/ -v"

    # 步骤5：生成SBOM（软件物料清单），满足合规审计
    - name: Generate SBOM
      uses: anchore/sbom-action@v1
      with:
        image: ${{ secrets.REGISTRY_URL }}/ml-inference:${{ github.sha }}
        output-file: ./sbom.json
        format: "spdx-json"

这个流水线的精髓在于 环境一致性 。单元测试不是在开发者本地Python环境跑，而是在刚构建好的Docker镜像里跑。这意味着：如果测试通过，那么这个镜像在任何K8s集群上都能跑通。 SBOM （Software Bill of Materials）是近年强监管行业的硬性要求，它列出镜像里所有开源组件及其许可证， spdx-json 格式可被合规系统自动解析。 anchore/scan-action 扫描出的Critical漏洞，比如 openssl 的CVE-2023-38545，会直接让CI失败，阻断发布流程——宁可晚一天上线，也不能带高危漏洞上生产。

4.2 CD阶段：GitOps驱动的Kubernetes部署

我们不用 kubectl apply -f 这种命令式操作，而是采用 Argo CD 实现GitOps。核心思想： K8s集群的状态，必须100%由Git仓库中的YAML文件声明，任何手动 kubectl 操作都是违规 。

# k8s/deployments/ml-inference.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: ml-inference
  namespace: argocd
spec:
  project: default
  source:
    repoURL: 'https://github.com/your-org/ml-repo.git'
    targetRevision: 'HEAD'
    path: k8s/overlays/prod  # 指向生产环境的kustomize目录
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: ml-prod
  syncPolicy:
    automated:
      prune: true     # 删除Git中不存在的资源
      selfHeal: true  # 自动修复被手动修改的资源
    syncOptions:
    - CreateNamespace=true

k8s/overlays/prod 目录结构如下：

prod/
├── kustomization.yaml
├── deployment.yaml
├── service.yaml
├── ingress.yaml
└── patches/
    ├── gpu-resources.yaml  # 生产环境专用：添加GPU requests/limits
    └── hpa.yaml           # 生产环境专用：添加HorizontalPodAutoscaler

kustomization.yaml 内容：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- ../../base/deployment.yaml
- ../../base/service.yaml
- ../../base/ingress.yaml
patchesStrategicMerge:
- patches/gpu-resources.yaml
- patches/hpa.yaml
images:
- name: my-registry.com/ml-inference
  newName: my-registry.com/ml-inference
  newTag: 20240520-v1  # 此处动态替换为CI生成的tag

GitOps的优势在于 可审计、可回滚、可协同 。每次部署，都是Git Commit的自然结果。你想知道“为什么昨天服务变慢了？”，直接 git blame k8s/overlays/prod/patches/hpa.yaml ，看到是某次commit把 targetCPUUtilizationPercentage 从70%改成90%，导致HPA反应迟钝。回滚？ git revert <commit-hash> ，Argo CD自动同步。这比 kubectl rollout undo deployment/ml-inference 可靠十倍，因为后者只回滚Deployment，不回滚配套的Ingress或NetworkPolicy。

4.3 监控与告警：用Prometheus+Grafana盯住你的GPU和模型

没有监控的ML服务，就像没有仪表盘的飞机。我们监控三个黄金维度：

维度	关键指标	Prometheus查询示例	Grafana看板建议
基础设施	nvidia_gpu_duty_cycle{job="gpu-exporter"} GPU利用率	avg by (instance) (nvidia_gpu_duty_cycle{job="gpu-exporter"}) > 80	GPU Utilization热力图，按节点着色
服务健康	http_request_duration_seconds_bucket{handler="predict", le="1.0"} P95延迟	histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{handler="predict"}[5m])) by (le)) > 1	请求延迟分布直方图，叠加P50/P90/P99线
模型效果	model_prediction_accuracy{model="resnet50"} 准确率（需应用埋点）	avg_over_time(model_prediction_accuracy{model="resnet50"}[24h]) < 0.85	准确率趋势图，标注模型版本变更点

告警规则 alerting-rules.yaml ：

groups:
- name: ml-alerts
  rules:
  - alert: GPUHighUtilization
    expr: avg by (instance) (nvidia_gpu_duty_cycle{job="gpu-exporter"}) > 95
    for: 5m
    labels:
      severity: warning
    annotations:
      summary: "GPU high utilization on {{ $labels.instance }}"
      description: "GPU utilization is above 95% for more than 5 minutes."

  - alert: ModelAccuracyDrop
    expr: avg_over_time(model_prediction_accuracy{model="resnet50"}[1h]) < (avg_over_time(model_prediction_accuracy{model="resnet50"}[24h]) * 0.9)
    for: 10m
    labels:
      severity: critical
    annotations:
      summary: "Model accuracy dropped significantly"
      description: "ResNet50 accuracy dropped below 90% of 24h average."

最关键的告警是 ModelAccuracyDrop 。它不依赖基础设施指标，而是直接监控业务效果。当准确率异常下降，可能是数据漂移（data drift）、特征工程bug、或模型过时。这个告警会触发MLOps流水线自动拉起一个数据质量检查任务，对比新老数据分布，生成诊断报告。这才是真正的“智能运维”，而不是在日志里大海捞针。

5. 常见问题与避坑指南：那些文档里不会写的血泪教训

5.1 “Docker build卡在pip install，一小时不动”——国内网络的终极解法

这是新手最大痛点。 pip install torch 在国内源经常超时或404。解决方案不是换源，而是 分层构建+离线wheel ：

# Step 1: 构建阶段，用国内源下载所有wheel
FROM python:3.9-slim AS builder
RUN pip install --upgrade pip && \
    pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple/
COPY requirements.txt .
RUN pip wheel --no-deps --no-cache-dir --wheel-dir /wheels -r requirements.txt

# Step 2: 运行阶段，直接从/wheels安装，不联网
FROM pytorch/pytorch:2.1.2-cuda12.1-cudnn8-runtime
COPY --from=builder /wheels /wheels
RUN pip install --no-index --find-links /wheels --no-cache-dir -r requirements.txt

原理：第一阶段用 pip wheel 把所有依赖（包括torch的CUDA wheel）下载为本地wheel文件，第二阶段完全离线安装。这样构建速度提升5倍，且100%可重现。注意： pip wheel 命令必须加 --no-deps ，否则会递归下载所有依赖的依赖，产生冗余。 --find-links /wheels 告诉pip只从这个目录找wheel，不访问网络。

5.2 “Kubernetes Pod一直Pending，describe显示0/1 nodes are available”——GPU调度失败的排查链

当 kubectl get pods 看到 Pending ，别急着删Pod。按顺序执行：

# 1. 查看Pod事件，找第一线索
kubectl describe pod ml-inference-5f8d7b9c4d-abcde

# 2. 如果事件显示"0/3 nodes are available: 3 Insufficient nvidia.com/gpu"，说明节点没GPU
# 检查节点GPU资源是否注册
kubectl get nodes -o wide
kubectl describe node your-gpu-node | grep -A 10 "nvidia.com/gpu"

# 3. 如果显示"0/3 nodes are available: 1 node(s) had taints that the pod didn't tolerate"，是污点问题
# 查看节点污点
kubectl describe node your-gpu-node | grep Taints
# 典型污点：nvidia.com/gpu=:NoSchedule —— 这是NVIDIA Device Plugin自动加的
# 解决方案：在Pod spec中添加toleration
tolerations:
- key: "nvidia.com/gpu"
  operator: "Equal"
  value: "present"
  effect: "NoSchedule"

# 4. 如果以上都正常，检查Pod是否指定了nodeSelector
nodeSelector:
  nvidia.com/gpu.present: "true"  # 必须和Device Plugin注册的label一致

最隐蔽的坑是 nodeSelector 的label。NVIDIA Device Plugin注册的label是 nvidia.com/gpu.present: "true" ，不是 gpu: "true" 或 accelerator: nvidia 。写错一个字符，Pod就永远Pending。我的做法是：先 kubectl get nodes -o yaml ，复制真实的label，再粘贴到YAML里，绝不手敲。

5.3 “模型预测结果每次都不一样”——随机种子的全局锁定

PyTorch/TensorFlow的随机性来自四个层面：Python、NumPy、PyTorch CPU、PyTorch CUDA。只设 torch.manual_seed(42) 是不够的。必须全局锁定：

# 在app.py最顶部，所有import之前
import os
import random
import numpy as np
import torch

def set_seed(seed=42):
    """Set all seeds for reproducibility"""
    os.environ['PYTHONHASHSEED'] = str(seed)  # Python hash seed
    random.seed(seed)                        # Python random
    np.random.seed(seed)                     # NumPy
    torch.manual_seed(seed)                  # PyTorch CPU
    if torch.cuda.is_available():
        torch.cuda.manual_seed(seed)         # PyTorch CUDA
        torch.cuda.manual_seed_all(seed)     # 多GPU
        # 禁用CUDA的非确定性算法（牺牲一点性能换确定性）
        torch.backends.cudnn.deterministic = True
        torch.backends.cudnn.benchmark = False

set_seed(42)

但还不够！Docker容器内的时间戳、进程ID也是随机的。所以要在Dockerfile里加：

# 固定容器内时间，避免time.time()引入随机性
ENV TZ=UTC
RUN ln -snf /usr/share/zoneinfo/$TZ /etc/localtime && echo $TZ > /etc/timezone

最后，在K8s Deployment里，禁用Pod的随机性：

spec:
  template:
    spec:
      # 禁用Pod的随机性，确保每次启动环境一致
      securityContext:
        sysctls:
        - name: net.ipv4.ip_forward
          value: "1"
      # 强制使用固定hostname，避免socket绑定随机端口
      hostname: ml-inference

只有这四层（代码种子+环境变量+Docker时区+K8s hostname）全部锁定，才能保证“同一份代码、同一份数据、同一份镜像”，在任何时间、任何节点上，输出完全相同的预测结果。这是MLOps的底线，不是可选项。

5.4 “GPU显存不释放，Pod OOMKilled”——PyTorch的显存泄漏黑洞

PyTorch的 torch.cuda.empty_cache() 不是万能的。它只释放未被引用的缓存，如果Python对象还持有tensor引用，显存就不会释放。真正的解法是 进程级隔离 ：

# 使用multiprocessing而非threading，每个预测请求在独立进程
from multiprocessing import Process, Queue
import torch

def predict_worker(model_path, input_queue, output_queue):
    # 每个worker进程独立加载模型，退出时自动释放所有显存
    model = torch.load(model_path)
    model.eval()
    with torch.no_grad():
        while True:
            data =