为什么在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 模型就能更平稳地进入可用状态。
