为什么在Vertex AI上仍要关注CUDA配置

Vertex AI提供托管式训练、批量预测和在线推理能力。很多基础设施细节已被平台封装。

但只要涉及自定义容器、GPU推理、深度学习框架版本固定，就绕不开NVIDIA CUDA环境。CUDA版本、显卡驱动、cuDNN、PyTorch或TensorFlow之间存在严格兼容关系。任何一处不匹配，都可能导致容器启动失败、模型加载报错、推理延迟异常或GPU无法被识别。

对于普通开发者来说，Vertex AI的优势是少维护服务器。它适合把模型快速上线为可调用的服务。

但它并不等于“无需配置”。更准确的理解是：平台负责资源调度和端点管理。用户需要负责运行镜像、依赖版本、模型文件结构和推理入口。

本文按实战流程梳理配置思路。适合AI工具安装、模型部署、企业内部测试环境搭建等场景。

部署前先确认三件事

确认模型类型

小型文本分类、传统机器学习模型通常不需要GPU。选择CPU规格更省资源。

大语言模型、图像生成、语音识别、视觉检测等任务，才更适合使用GPU。

确认框架版本

例如PyTorch 2.1常见搭配CUDA 11.8或12.1。TensorFlow不同版本对CUDA和cuDNN要求也不同。

不能只看“最新版”。

确认部署方式

若使用Vertex AI预构建容器，配置量较少。

若要安装私有依赖、加载特殊算子或使用量化推理框架，就建议采用自定义容器。

一个稳妥原则是：先从模型官方说明或项目仓库查到推荐环境，再反推镜像基础版本。不要先随意选择CUDA最新版，再强行适配框架。

生产环境中，推荐固定所有关键版本，包括Python、CUDA、cuDNN、torch或tensorflow、transformers、tokenizers等。避免后续镜像重建时出现不可复现的问题。

本地准备与项目结构建议

部署前建议准备四类文件：

• 模型文件：可以来自训练产物，也可以来自公开模型转换后的目录。
• 推理服务代码：通常提供健康检查接口和预测接口。
• 依赖清单：用于锁定包版本。
• 容器构建文件：负责指定CUDA基础镜像、复制代码并启动服务。

推荐目录结构为：

• model目录存放权重与配置。
• app目录存放服务代码。
• requirements.txt记录Python依赖。
• Dockerfile定义镜像。

若模型较大，不建议直接把权重打入镜像。可上传到对象存储，再在容器启动时读取。或通过Vertex AI模型制品路径挂载。这样镜像更轻，更新服务代码时也不必反复上传巨大文件。

CUDA镜像选择与版本匹配

自定义容器通常以NVIDIA官方CUDA镜像作为基础，例如带有runtime或devel标识的镜像。

runtime镜像体积较小，适合只运行推理。devel镜像包含编译工具，适合需要编译自定义算子、安装部分原生扩展的场景。

线上推理优先选择runtime。只有确实需要编译时再使用devel，以减少镜像体积和启动时间。

版本匹配可按以下顺序判断：

• 先看深度学习框架支持的CUDA版本。
• 再看Vertex AI可选GPU机型。
• 再选择对应镜像。

比如模型基于PyTorch并要求CUDA 11.8，则基础镜像可选择nvidia/cuda:11.8.0-cudnn8-runtime-ubuntu22.04这一类组合。如果框架官方安装包标注cu121，则选择CUDA 12.1更合适。

不要混装多个CUDA版本。也不要在容器里随意升级系统级GPU组件。

容器构建的关键步骤

第一步：编写推理服务

服务需要监听平台要求的端口。常见做法是使用FastAPI、Flask或其他轻量Web框架。

启动后应提供健康检查路径，返回模型是否加载完成。预测路径接收JSON或文件地址，完成预处理、推理和后处理。

模型加载建议放在进程启动阶段，避免每次请求重复读盘。

第二步：安装依赖

requirements.txt中要显式写清版本，例如torch、transformers、accelerate、numpy、Pillow等。

若使用框架官方CUDA轮子，应从官方推荐命令提取版本。不要让包管理器自动选择不确定版本。

安装完成后可加入简单自检命令。例如打印torch.cuda.is_available()结果和GPU名称，便于在构建或启动日志中确认环境。

第三步：构建镜像并推送到Artifact Registry

构建前先在本地或CI环境执行一次容器启动测试，确认接口能返回健康状态。

推送镜像时要使用区域一致的镜像仓库。部署资源、模型文件和镜像仓库尽量放在同一区域，减少跨区域读取带来的延迟和管理复杂度。

在Vertex AI创建模型与端点

进入Vertex AI控制台后，先创建或导入模型。选择“自定义容器”作为服务方式，填写镜像地址、容器端口、健康检查路径、预测路径。

随后创建Endpoint，并把模型部署到该Endpoint。部署时选择机器类型和GPU类型，例如适合中小模型的T4、适合更高吞吐的L4或A100系列。具体以项目可用资源为准。

副本数设置要结合访问量。测试阶段可设置最小副本为1，避免冷启动影响调试。低频服务可评估是否接受启动等待，以降低长期资源占用。

生产场景建议配置自动扩缩策略。但要先通过压测获得单副本吞吐、显存占用、平均延迟和峰值延迟，再决定扩展阈值。盲目堆高规格并不一定带来线性收益，瓶颈可能在预处理、序列长度或数据读取。

模型选择建议：不要只看参数规模

选模型时应同时看准确率、推理成本、显存占用、响应时间和维护难度。

文本分类、摘要、问答等任务，如果业务边界清晰，中小模型经过微调往往比超大模型更稳定。图像识别任务可优先选择成熟的检测或分类架构。多模态任务则要重点评估输入尺寸、批处理策略和显存峰值。

如果使用大语言模型，建议先测试量化版本与原始版本的效果差异。8位或4位量化能显著降低显存需求，但可能影响部分复杂任务表现。

对实时交互场景，延迟比极限精度更重要。对离线批处理，吞吐和单位任务成本更关键。上线前至少准备一个基准集，记录不同模型、不同GPU、不同批大小下的指标，避免凭感觉选型。

常见问题与排查方法

问题一：日志提示CUDA不可用

优先确认部署时是否选择了GPU规格。其次检查镜像中框架是否为CUDA版本，而不是CPU版本。

进入容器日志查看torch.cuda.is_available()或TensorFlow设备列表。若没有GPU，多半是规格或依赖安装不匹配。

问题二：容器启动后健康检查失败

常见原因是服务端口写错、模型加载时间过长、启动命令未执行、依赖缺失。

可先让健康检查在服务启动后快速返回，再在后台加载模型。或者调大启动探测等待时间。模型很大时，要特别关注首次下载和解压耗时。

问题三：显存不足

可尝试减小批大小、缩短输入长度、启用半精度、使用量化模型，或更换更大显存GPU。

不要只依赖重启解决，显存不足通常是配置或模型策略问题。

问题四：推理很慢

应分别检查模型计算时间、数据预处理、网络传输、日志输出和并发设置。很多时候瓶颈并不在CUDA本身。

安全边界与合规建议

部署AI服务时，不要把密钥、访问令牌、私有地址写进镜像或代码仓库。应使用Secret Manager或环境变量管理。

模型文件如果包含内部数据训练结果，要设置最小访问权限，并定期审查服务账号。日志中避免输出用户原始输入、完整请求体和敏感字段。调试阶段也要做好脱敏。

自定义容器只安装必要依赖。尽量使用官方镜像和可信源，定期扫描镜像漏洞。

对外提供接口时要做鉴权、限流和输入校验。防止异常大请求拖垮服务。对于生成式模型，还应设置内容过滤、提示词边界和人工复核流程。特别是面向客户的场景，不能把模型输出直接等同于可靠结论。

实用部署清单

正式上线前可按清单复核：

• CUDA、cuDNN和框架版本已锁定。
• 镜像可重复构建。
• 健康检查和预测接口路径正确。
• 模型加载日志清晰。
• GPU可被框架识别。
• 小样本预测结果符合预期。
• 压测数据已记录。
• 最小副本和扩展策略合理。
• 密钥未写入镜像。
• 错误日志能帮助定位问题。

Vertex AI的部署效率很高，但稳定运行依赖前期工程化细节。

对初次实践者，建议先用小模型走通完整流程，再替换为目标模型。先在单副本上压测，再考虑扩展。先固定环境，再做性能优化。

只要把CUDA兼容、容器结构、端点配置和监控排查四件事做好，自定义AI模型就能更平稳地进入可用状态。