英伟达协议调整下，自建GPU推理环境完整指南：从驱动到Docker部署

英伟达GPU推理NVIDIA驱动

于 2026-08-30 04:07:20 修改

·本内容遵循CC 4.0 BY-SA版权协议

英伟达暂停部分AI云收入分成协议的消息，在AI应用团队里引起了一轮讨论：我们每天调用的文本生成、图像识别、向量化接口，底层到底使用了谁的GPU？如果云厂商和GPU厂商之间的商业协议发生调整，接口定价、算力供给和模型版本会不会跟着波动？这类动态对普通用户可能只是新闻，对负责技术选型的人却是真实的稳定性信号。很多团队把AI能力完全封装在第三方AI云API后面，长期依赖下来，逐渐失去了对底层环境的掌控力。协议一旦暂停或调整，受影响的不只是账单，还有可用性、限流比例、模型升级节奏，甚至数据迁移路径。

这篇文章从工程角度完成一条可复现的自建GPU推理环境路线：从云主机选型、系统准备、英伟达驱动安装，到Docker容器化推理服务，再到压测、监控和排错。文章面向后端开发、AI应用工程师和运维工程师，不需要你已经有GPU服务器，只要按照顺序操作，最终能得到一个可对外提供HTTP接口、可观察资源消耗、可迁移部署的AI推理服务。这样即使外部AI云API发生变动，你仍然有快速切换和自建的余地。

1. 先理解AI云服务背后的GPU协议变化，为什么会影响你的接口

1.1 收入分成协议是什么，和普通用户有什么关系

AI云收入分成协议，可以理解为云服务商和GPU硬件厂商之间关于算力商业化回报的约定。云服务商通常不是免费拿到GPU资源，而是通过采购、租用或与厂商分成的方式获得算力，再封装成API卖给用户。普通开发者看到的是一次接口调用几毛钱，但背后包含了硬件成本、机房成本、模型授权成本和厂商分成成本。

当英伟达暂停部分AI云收入分成协议的消息出现时，最直接的影响对象虽然是云厂商，但风险会沿着供应链传到应用层。云厂商如果无法按原有协议获取GPU资源，可能会重新调整套餐价格、降低部分API的并发额度，甚至下架依赖特定硬件的模型服务。对于已经跑在生产环境的业务，这些变化都会体现为账单波动、接口超时、限流次数增加，或者某个模型版本突然不再可用。

这里不讨论具体商业细节，只提醒一个技术判断：不要把“第三方AI云API可用”当作默认恒真。商业协议可以调整，云厂商的服务目录可以变化，唯一可靠的依赖是你自己能掌控的环境和迁移能力。

1.2 依赖第三方AI云API时，需要关注哪些技术指标

在决定自建之前，先梳理现有业务对第三方AI云API的依赖程度。下面这些指标可以在协议变化或服务降级时帮助你快速判断影响范围。

指标	含义	技术影响
可用性SLA	服务承诺的正常运行时间比例	SLA下降意味着允许更长的故障时间，你的重试和降级策略要更保守
限流策略	每分钟/每小时的请求上限	协议调整后限流可能收紧，生产流量会出现更多429或503
单位价格	每千token或每次调用费用	价格调整直接影响业务成本，需要能快速核算增加幅度
模型版本固定性	是否允许锁定当前版本	如果版本被强制升级，输入输出格式和效果都可能变化
数据出口要求	请求数据是否可以留在指定区域	合规场景下，API背后的机房位置变化可能带来合规风险
回退方案	是否有替代API或自建模型	没有回退方案时，上游任何调整都是业务风险

在实际项目里，依赖第三方API不是不行，但需要在监控和容灾设计上多留一层。比如把第三方API调用单独封装成client接口，底层实现可以随时替换成自建服务，不要让业务代码直接依赖某个云厂商的SDK。

1.3 什么时候应该启动自建GPU环境

自建GPU环境不是所有场景的最优解，它需要投入人力维护驱动、镜像、模型和监控。如果业务满足以下任意几条，就可以考虑启动自建评估：

每天调用量达到一定规模，API账单已经构成显著成本。
对延迟敏感，第三方API的排队时间不可接受。
数据隐私要求高，不能把文本、图片或用户特征发送到外部服务。
需要频繁调整模型参数、微调或部署自定义版本。
上游协议或定价变动历史不稳定，团队希望降低供应商锁定风险。

自建的第一阶段不需要一步到位。可以先选择一两个核心接口，在一台GPU云主机上跑通，再逐步替换流量。这比一次性迁移到自建集群更稳妥，也能在迁移过程中沉淀出镜像、脚本和监控模板。

2. 云主机选型与系统准备：先把自己能控制的部分准备好

2.1 GPU云主机规格怎么选

自建AI推理环境的起点是一台带GPU的云主机。规格选错了，后面驱动和模型都会遇到瓶颈。先按模型类型估算显存需求，再反推CPU和内存配置。

GPU型号	显存	适合场景	典型模型示例
入门级GPU	6GB-8GB	小型embedding、文本分类、目标检测验证	MiniLM、BERT-base
中等规格GPU	16GB-24GB	文本生成、图像生成、批量向量化	LLaMA-7B量化、SD1.5
高端GPU	32GB以上	大模型微调、高并发推理	LLaMA-13B以上、多模态模型

如果是学习环境或小型业务，选择一块入门级GPU加8核CPU、16GB内存通常够用。生产环境则要额外考虑GPU显存占用峰值和并发请求数。比如多个用户同时请求embedding模型时，显存可能会因为批处理增大而上升，CPU内存也会被tokenizer和请求队列占满。

云主机选型时还需要确认虚拟化类型。部分云主机使用的GPU直通方式不同，有的支持完整NVIDIA驱动功能，有的只提供vGPU，安装驱动的方式会不一样。下单前先查看云厂商的说明，尽量选择支持NVIDIA驱动和CUDA的GPU实例。

2.2 操作系统选择：为什么优先考虑Linux服务器

GPU推理服务建议选择Linux服务器。Ubuntu Server LTS是社区资料最多、NVIDIA驱动兼容性最好的选择；Debian、Rocky Linux也可以，但遇到问题时排查资料相对少。如果你使用的是基于Linux内核的国产操作系统，驱动安装思路类似，但需要确认内核版本和驱动包渠道。

云主机控制台通常会提供预装驱动或预装CUDA的镜像。这类镜像适合快速验证，但生产环境不能默认信任镜像里的驱动版本。你仍然需要检查驱动分支和GPU型号是否匹配，避免使用了过旧的驱动。

推荐使用Ubuntu 22.04 LTS或Ubuntu 24.04 LTS。新版本对最新内核和NVIDIA驱动支持更好，但如果你的业务依赖特定CUDA版本，先确认该CUDA版本是否支持目标操作系统。CUDA版本和操作系统内核之间有兼容矩阵，不能只看驱动版本号。

2.3 分区与文件系统建议

GPU推理服务的核心数据包括Docker镜像、模型文件、日志和训练数据。这些数据不能全部塞在系统盘中。建议单独划分数据盘，并把Docker的数据目录迁移到数据盘上。

BASH

# 查看当前磁盘和挂载情况

lsblk

# 如果数据盘是 /dev/vdb，先格式化再挂载

sudo mkfs.xfs /dev/vdb

sudo mkdir -p /data

sudo mount /dev/vdb /data

把Docker数据目录设置到/data/docker：

BASH

sudo systemctl stop docker

sudo mkdir -p /data/docker

sudo mv /var/lib/docker/* /data/docker/

编辑Docker配置文件：

JSON

{

"data-root": "/data/docker"

}

修改后重新加载Docker：

BASH

sudo systemctl daemon-reload

sudo systemctl start docker

分区规划的目标是让模型文件和容器镜像不会撑爆系统盘。生产环境还要考虑数据盘备份，如果云主机宕机或磁盘损坏，可以从快照恢复。

2.4 基础环境检查清单

安装驱动之前，先执行一轮基础检查。这一步能提前发现很多环境问题，避免在驱动安装阶段反复踩坑。

检查项	命令	预期结果
系统版本	`cat /etc/os-release`	明确当前发行版和版本号
内核版本	`uname -r`	记录内核版本，方便匹配驱动
磁盘空间	`df -h`	数据盘已挂载且有足够空间
网络连通	`curl -I https://example.com`	能正常访问外部网络
时间同步	`timedatectl`	已开启NTP，日期时间正确
GPU是否可见	`lspci	grep -i nvidia`

检查完再进入驱动安装。不要跳过，内核版本和GPU设备标识是后续排查最常需要的信息。

3. 安装英伟达显卡驱动：这一步决定后续所有容器能否识别GPU

3.1 先确定GPU型号和推荐驱动版本

在Ubuntu系统里，先用lspci确认GPU型号：

BASH

lspci | grep -i nvidia

输出示例：

TEXT

01:00.0 3D controller: NVIDIA Corporation GA102 [GeForce RTX 3080] (rev a1)

拿到型号后，到NVIDIA官方驱动下载页面选择对应分支。对于云主机，常见做法是选择一个长期稳定分支，比如535或550。不要盲选最新版，最新版驱动虽然修复了新问题，但可能带来内核兼容性问题。

如果云主机控制台提供了预装驱动选项，可以直接选用。但启动后还要执行nvidia-smi确认驱动能够识别GPU。如果识别不到，说明预装镜像可能没有正确加载内核模块，需要重新安装。

3.2 关闭nouveau并安装依赖

Ubuntu默认可能加载开源显卡驱动nouveau，它和NVIDIA官方驱动冲突。如果不关闭，安装过程会出现内核模块加载失败，或者nvidia-smi提示没有可用的NVIDIA设备。

先禁止nouveau：

BASH

sudo bash -c "echo blacklist nouveau > /etc/modprobe.d/blacklist-nouveau.conf"

sudo bash -c "echo options nouveau modeset=0 >> /etc/modprobe.d/blacklist-nouveau.conf"

sudo update-initramfs -u

sudo reboot

重启后确认nouveau没有加载：

BASH

lsmod | grep nouveau

如果没有输出，说明禁用成功。

安装编译驱动所需的依赖：

BASH

sudo apt update

sudo apt install -y build-essential dkms linux-headers-$(uname -r)

dkms不是必须的，但强烈建议安装。它能在内核升级后自动重建NVIDIA内核模块，避免云主机一更新内核，驱动就失效。

3.3 安装驱动的两种方式

方式	优点	缺点	推荐场景
apt安装	简单，自动处理依赖	版本相对旧，定制性差	快速验证和学习环境
runfile安装	可控性强，易于指定版本	需要手工处理依赖和黑名单	生产环境、特殊内核环境
云厂商预装镜像	开箱即用	版本可能不透明，难排查	临时环境，不推荐生产长期使用

apt方式最简单，但版本不是完全可控：

BASH

sudo apt install -y nvidia-driver-535

sudo reboot

runfile方式适合需要精确控制驱动的场景。从NVIDIA官网下载对应驱动后：

BASH

chmod +x NVIDIA-Linux-x86_64-535.154.05.run

sudo ./NVIDIA-Linux-x86_64-535.154.05.run --dkms

安装过程中会提示是否安装32位兼容库、是否生成X配置，按实际需求选择即可。生产环境如果没有图形界面，可以不生成X配置。

3.4 验证驱动：nvidia-smi输出解读

驱动安装完成后，执行：

BASH

nvidia-smi

正常输出类似：

TEXT

+-----------------------------------------------------------------------------+

| NVIDIA-SMI 535.154.05 Driver Version: 535.154.05 CUDA Version: 12.2 |

|-------------------------------+----------------------+----------------------+

| GPU Name Persistence-M | Bus-Id Disp.A | Volatile Uncorr. ECC |

| | | |

| 0 NVIDIA GeForce RTX 3080 | On | N/A |

+-------------------------------+----------------------+----------------------+

| MPS Client Sessions: None |

+-------------------------------+----------------------+----------------------+

需要关注四类信息：

驱动版本：和安装版本一致。
CUDA Version：这是驱动支持的最大CUDA版本，不代表系统已安装对应CUDA toolkit。
GPU利用率和显存使用：确认GPU已工作。
Peristence-M：建议开启持久模式，减少任务间隔启动开销。

开启GPU持久模式：

BASH

sudo nvidia-smi -pm 1

3.5 宿主机的CUDA和cuDNN：装还是不装

使用Docker运行AI推理服务时，宿主机不需要安装完整CUDA toolkit和cuDNN。容器镜像里会自带CUDA运行时。宿主机只需要保证NVIDIA驱动版本不低于容器需要的版本即可，否则容器内nvidia-smi可能无法访问GPU。

如果需要在宿主机直接运行Python训练脚本，再安装CUDA toolkit。安装时注意选择目标AI框架要求的版本。例如PyTorch 2.1官方镜像默认支持CUDA 12.1，那么宿主机驱动需要支持CUDA 12.x。通过nvidia-smi中显示的CUDA Version作为参考，如果驱动最大支持CUDA 12.2，那么运行CUDA 12.1的容器是没问题的。

常见坑：有人为了“用最新版”，在宿主机安装比驱动支持版本更高的CUDA toolkit，结果运行时提示CUDA driver version is insufficient。解决方法是降低CUDA toolkit版本，或者升级NVIDIA驱动。

4. 使用Docker和NVIDIA Container Toolkit封装推理服务

4.1 为什么容器化更适合GPU推理环境

GPU环境最麻烦的不是模型本身，而是依赖矩阵。PyTorch版本、CUDA版本、cuDNN版本、Python版本、系统库版本必须精确对齐。直接在宿主机上安装，一旦升级系统软件或安装其他项目依赖，很容易破坏已有环境。

容器化的好处是把CUDA运行时、AI框架、Python依赖一起封装到镜像里。宿主机只需要提供NVIDIA驱动，容器内部使用自己带的CUDA版本。这样你可以在同一台GPU云主机上，同时运行需要不同CUDA版本的服务，互不干扰。

同时，容器镜像也是多云迁移的基础。你在一个云环境构建好的镜像，可以推到镜像仓库，然后在另一个云上拉取运行。只要目标云主机的NVIDIA驱动满足要求，服务行为就是一致的。

4.2 安装Docker Engine和NVIDIA Container Toolkit

先安装Docker Engine。以Ubuntu为例，可以使用官方源，也可以使用国内可用的镜像源：

BASH

sudo apt update

sudo apt install -y docker.io

sudo systemctl enable --now docker

测试Docker是否正常：

BASH

sudo docker run --rm hello-world

接着安装NVIDIA Container Toolkit，它为Docker提供了--gpus参数支持。

BASH

distribution=$(. /etc/os-release;echo $ID$VERSION_ID)

curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add -

curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list

sudo apt update

sudo apt install -y nvidia-container-toolkit

如果网络无法访问NVIDIA仓库，可以手动下载对应安装包，或者使用云厂家提供的容器运行时。安装完成后配置Docker runtime：

BASH

sudo nvidia-ctk runtime configure --runtime=docker

sudo systemctl restart docker

配置完成后，Docker的/etc/docker/daemon.json中会多出一个nvidia runtime。启动容器时使用--gpus all就会调用它。

4.3 编写Dockerfile：以PyTorch推理镜像为例

下面是一个最小Dockerfile，用于封装后续的embedding推理服务。它基于PyTorch官方镜像，基础镜像中已经包含CUDA和cuDNN。

DOCKERFILE

FROM pytorch/pytorch:2.1.0-cuda12.1-cudnn8-runtime

ENV PYTHONUNBUFFERED=1 \

PIP_NO_CACHE_DIR=1

WORKDIR /app

RUN pip install --no-cache-dir fastapi uvicorn transformers sentence-transformers pydantic

COPY app.py /app/app.py

EXPOSE 8000

CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]

这个示例里，pytorch/pytorch镜像版本要和你的业务需求对齐。如果不需要PyTorch，也可以从nvidia/cuda镜像开始自己搭建。PIP_NO_CACHE_DIR可以减少镜像体积。

4.4 启动容器并验证GPU透传

先做一次最简单的GPU验证：

BASH

sudo docker run --rm --gpus all pytorch/pytorch:2.1.0-cuda12.1-cudnn8-runtime nvidia-smi

如果看到和宿主机类似的GPU信息输出，说明GPU已经成功透传到容器内部。

如果提示：

TEXT

docker: Error response from daemon: could not select device driver "" with capabilities: [[gpu]].

说明NVIDIA Container Toolkit没有安装或Docker runtime没有配置。检查/etc/docker/daemon.json中是否包含"nvidia" runtime，然后重启Docker。

常见坑：容器镜像中的CUDA版本高于宿主机驱动支持版本时，容器内nvidia-smi能执行，但实际运行模型时可能报错CUDA error: no kernel image is available。解决方法是匹配驱动和CUDA版本，或者降低镜像版本。

5. 部署一个最小AI推理服务并验证镜像、显存和延迟

5.1 用FastAPI封装一个embedding模型

为了让整个过程形成最小闭环，这里使用一个轻量级embedding模型。它把文本转换成一串向量，是语义搜索、知识库检索、文本去重等任务的基础能力。示例代码使用transformers加载模型，并通过FastAPI提供HTTP接口。

创建app.py：

PYTHON

import torch

from fastapi import FastAPI

from pydantic import BaseModel

from transformers import AutoTokenizer, AutoModel

app = FastAPI()

model_name = "sentence-transformers/all-MiniLM-L6-v2"

tokenizer = AutoTokenizer.from_pretrained(model_name)

model = AutoModel.from_pretrained(model_name)

device = "cuda" if torch.cuda.is_available() else "cpu"

model.to(device)

model.eval()

class Item(BaseModel):

text: str

@app.post("/embed")

def embed(item: Item):

inputs = tokenizer(item.text, return_tensors="pt", truncation=True, max_length=256)

inputs = {k: v.to(device) for k, v in inputs.items()}

with torch.no_grad():

outputs = model(**inputs)

# 使用CLS向量作为文本表示

vector = outputs.last_hidden_state[:, 0, :].squeeze().cpu().tolist()

return {"vector": vector, "dim": len(vector)}

关键点：

模型加载到GPU后要先执行model.eval()，否则部分层会表现出训练行为。
推理时使用torch.no_grad()，避免构建不需要的反向传播图，节省显存。
max_length限制输入长度，防止超长文本导致显存暴涨。
返回向量前调用.cpu().tolist()，把张量转为Python列表，方便JSON序列化。

下载模型时如果网络慢，可以设置环境变量指定镜像源，例如：

BASH

export HF_ENDPOINT=https://your-hf-mirror.example.com

实际项目根据自己可访问的镜像地址填写。

5.2 构建镜像并启动服务

在工作目录下构建镜像：

BASH

sudo docker build -t ai-embedding-server:0.1 .

启动容器：

BASH

sudo docker run -d --name embedding-server \

--gpus all \

-p 8000:8000 \

ai-embedding-server:0.1

查看启动日志：

BASH

sudo docker logs -f embedding-server

看到类似Application startup complete后，用curl发送请求：

BASH

curl -X POST http://127.0.0.1:8000/embed \

-H "Content-Type: application/json" \

-d '{"text": "英伟达AI云协议调整之后，自建GPU环境会成为可选方案"}'

预期返回一个包含vector和dim的JSON。dim为384，模型返回维度是384维。

5.3 请求验证和压测

为了验证服务不是只能跑通一次，需要做简单压测。这里用一个Python脚本模拟并发请求：

PYTHON

import json

import time

import urllib.request

url = "http://127.0.0.1:8000/embed"

payload = json.dumps({"text": "test embedding request"}).encode("utf-8")

start = time.time()

responses = []

for i in range(200):

req = urllib.request.Request(url, data=payload, headers={"Content-Type": "application/json"})

with urllib.request.urlopen(req, timeout=5) as resp:

responses.append(resp.status)

end = time.time()

print("total", end - start)

print("qps", len(responses) / (end - start))

print("status", set(responses))

如果CPU和GPU配置较低，可以减小循环次数。压测时在另一个终端观察GPU使用率：

BASH

watch -n 1 nvidia-smi

重点观察GPU-Util和Memory Usage。如果GPU-Util长期低于30%，说明瓶颈可能在CPU或默认线程数上。FastAPI默认同步接口会限制并发，实际生产环境可以调整为异步处理，或者使用多个worker。

常见坑：压测时因为请求太多导致进程OOM，会看到killed process。如果出现这种情况，降低并发数，或者在容器启动参数中增加内存限制。

5.4 观察日志和GPU资源

服务运行一段时间后，需要定期检查容器状态和GPU状态：

BASH

sudo docker ps

sudo docker logs --tail 50 embedding-server

nvidia-smi --query-gpu=timestamp,utilization.gpu,memory.used,temperature.gpu --format=csv

nvidia-smi查询命令适合写入监控脚本。生产环境不要只靠人工看，后面章节会给出监控方法。

6. 协议变化场景下的生产级应对：监控、排错和多云冗余

6.1 建立基础GPU监控

真实环境不能靠人眼盯着nvidia-smi。可以用脚本定期采集GPU指标，并输出到日志或监控系统。下面是一个简单的bash采集脚本：

BASH

# !/bin/bash

while true; do

nvidia-smi --query-gpu=timestamp,utilization.gpu,memory.used,memory.total,temperature.gpu \

--format=csv,noheader >> /var/log/gpu_monitor.log

sleep 30

done

把脚本加入systemd或cron，再配合Prometheus和Grafana，就能形成可视化的监控面板。更专业的是使用NVIDIA DCGM工具，它提供更丰富的GPU指标和故障检测能力。

监控指标至少要覆盖：

GPU利用率：判断算力是否被打满。
显存使用量：提前发现显存泄漏。
GPU温度：防止散热问题导致降频。
功耗：排查是否因为功耗墙导致性能异常。
容器重启次数：发现服务崩溃。

6.2 常见故障排查链路

GPU服务出问题时，按下面顺序排查比乱试命令更有效。

问题现象	可能原因	检查方式	处理建议
容器启动报错找不到GPU	Nvidia Container Toolkit未配置	`docker info`查看运行时，`/etc/docker/daemon.json`检查	重新执行`nvidia-ctk runtime configure`并重启Docker
容器内`nvidia-smi`不存在	镜像未包含NVIDIA工具	在容器内执行`which nvidia-smi`	使用包含CUDA的镜像，或通过宿主机判断容器是否可见GPU
运行模型报CUDA error	驱动版本低于镜像CUDA要求	对比`nvidia-smi`的CUDA Version和镜像版本	升级驱动或降低CUDA镜像版本
显存不足OOM	并发请求过多或输入过长	`nvidia-smi`观察显存，检查日志	限制并发、减小batch、使用量化模型
服务启动慢	首次加载模型时间长	`docker logs`看加载时间	增加健康检查超时时间，启动时预加载模型
重启后驱动失效	内核升级导致模块未重建	`dkms status`检查模块	安装dkms，升级内核后手动重建驱动模块

如果nvidia-smi正常，但容器内部看不到GPU，优先排查Docker runtime而不是重新安装驱动。宿主机驱动正常不代表容器运行时正确。

6.3 让服务在多云之间可迁移

自建GPU环境的最终目的是降低供应商锁定风险。因此，从第一步开始就要考虑迁移能力。

镜像仓库：把Docker镜像推到多个镜像仓库，避免单点依赖。
模型版本：使用固定的模型版本文件，记录下载地址和校验值。
配置外置化：不要在镜像中写死IP、token、模型路径，用环境变量或配置中心管理。
初始化脚本：把云主机从裸机到驱动安装、Docker安装的步骤固化成脚本，方便在其他云环境复现。

下面是一个简化版的初始化脚本骨架：

BASH

# !/bin/bash

set -euxo pipefail

# 1. 更新系统并安装依赖

apt update

apt install -y build-essential dkms linux-headers-$(uname -r)

# 2. 禁用nouveau

echo blacklist nouveau > /etc/modprobe.d/blacklist-nouveau.conf

echo options nouveau modeset=0 >> /etc/modprobe.d/blacklist-nouveau.conf

update-initramfs -u

# 3. 安装驱动（以apt方式为例）

apt install -y nvidia-driver-535

# 4. 安装Docker和NVIDIA Container Toolkit

apt install -y docker.io

curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | apt-key add -

...

nvidia-ctk runtime configure --runtime=docker

systemctl restart docker

# 5. 拉取业务镜像并启动

docker pull your-registry.example.com/ai-embedding-server:0.1

docker run -d --name embedding-server --gpus all -p 8000:8000 \

-e MODEL_NAME=sentence-transformers/all-MiniLM-L6-v2 \

your-registry.example.com/ai-embedding-server:0.1

脚本里的镜像地址和驱动版本需要根据实际环境调整。生产环境还应该包含日志采集、监控Agent安装和备份策略。

6.4 落地前检查清单

在自建GPU环境切换流量前，按下面清单逐项确认。每一项都应该是可执行可验证的。

检查项	验证方式	通过标准
驱动安装	`nvidia-smi`	驱动版本正确，GPU利用率显示正常
Docker GPU透传	`docker run --gpus all ... nvidia-smi`	容器内能识别GPU
镜像构建	`docker build`	构建成功，日志无关键警告
推理接口	`curl`请求	返回正确向量，维度正确
并发稳定性	压测100次连续请求	无超时，无进程崩溃
显存控制	压测时观察`nvidia-smi`	显存占用不超过可用值的80%
日志输出	`docker logs`	有访问日志，错误日志能定位
重启恢复	重启Docker和服务容器	服务自动启动，模型重新加载正常
配置外置	检查容器环境变量	无敏感信息写死在镜像
数据备份	查看数据盘快照	模型文件和日志有备份策略

这份清单也可以作为每次发布前的最小回归用例。如果哪一项失败，不应该把流量切到新环境。

回到开头提到的英伟达暂停部分AI云收入分成协议，这个事件的启示不是要求所有团队立刻放弃第三方API，而是提醒我们在技术选型时保留选择权。自建GPU环境不是唯一答案，但至少应该在真正出现协议调整、价格波动或服务降级时，有可以快速切换的退路。建议先从一个小接口开始，搭建并验证自建链路，再逐步扩大范围。下一步可以继续学习Kubernetes下的GPU调度、模型服务框架和自动扩缩容，让自建环境从单机能力走向生产可用的集群能力。