如果你打算在本地显卡上跑 X2.0，第一步不是急着下模型权重，而是先确认本地驱动、CUDA 运行时和显存容量三者是否匹配。很多部署失败发生在启动阶段，消息往往只写“CUDA error”或“driver/library mismatch”，却没有告诉你到底缺的是显存、驱动还是 CUDA。下面按启动动作顺序，给出判断和操作路径。
在运行 X2.0 前，先用 nvidia-smi 确认驱动版本与显存大小；驱动只需不低于运行框架所需的 CUDA 版本，不必与 nvcc 完全一致。模型加载日志会提示权重和缓存占用的显存范围，若显存不足，先调整 PyTorch 的显存分配策略和系统 swap，确保进程不被杀，再考虑换卡或降低 batch size。
先用 nvidia-smi 确认当前显存与驱动状态
nvidia-smi 是最直接的环境快照工具。在终端运行 nvidia-smi，能同时看到 GPU 型号、驱动版本、显存总量和当前占用。常用命令：
nvidia-smi # 单屏汇总，看当前显存占用与驱动版本 nvidia-smi -L # 列出每张 GPU 的 UUID 和型号 watch -n 1 nvidia-smi # 每秒刷新，适合在模型加载和推理时观察显存变化
输出表格里，Memory-Usage 显示的是当前已占用与总显存，GPU-Util 显示计算单元利用率。右上角的 CUDA Version 不是本机安装的 CUDA 工具包版本，而是当前驱动能支持的最高 CUDA 版本，这一点容易混淆。若驱动版本过旧，很多新模型推理框架会直接报 “CUDA driver version is insufficient for CUDA runtime version”。
根据模型加载日志估算显存占用
不同依赖环境下，模型加载时打印的日志格式差别很大，但通常包含三类显存来源：
- 权重：模型参数在显存中的镜像，加载即占用，大小约等于参数量 × 精度字节数；
- 中间缓存：推理过程和反向传播的激活值、注意力缓存，随序列长度和 batch size 变化；
- CUDA context：驱动与框架初始化占用的固定显存，通常几百 MB。
启动时留意 stdout 里的 “Loading model”、“CUDA memory allocated” 或 “Total memory used” 等字样。若日志模式不明显，建议在加载和推理前后用 torch.cuda.max_memory_allocated 记录峰值：
import torch
import time
torch.cuda.init()
def print_peak(tag):
print(f"[{tag}] peak allocated: {torch.cuda.max_memory_allocated()/1024**2:.0f} MB")
torch.cuda.reset_peak_memory_stats()
print_peak("before load")
model = load_model() # 你的 X2.0 加载代码
print_peak("after load")
input_tensor = make_input()
output = model(input_tensor)
print_peak("after inference")
这段脚本可以在不同的 batch size 下多跑几次，凑出一张“显存随输入变大”的粗略曲线。如果峰值已经接近显存总量，说明剩余预算有限，需要调小 batch size 或改用流式加载。
核对驱动与 CUDA 版本兼容性
驱动和 CUDA 运行时是两个层面的东西。驱动由显卡硬件支撑，CUDA 运行时由框架自带或系统安装。常见启动错误有两种：
driver/library version mismatch：驱动程序和 CUDA runtime 库版本冲突，通常发生在驱动升级没有完全生效之后，重启系统或重装匹配版本驱动可解决；no kernel image is available for execution on the device：当前编译的算力代码不匹配你的 GPU 架构，需要升级驱动或重新编译模型依赖。
核对流程建议分三步：
- 执行
nvidia-smi，记录右上角 CUDA Version，这是驱动支持的上限； - 执行
nvcc `--version`，记录本地 CUDA 工具包版本；如果不是用本地编译，这一步可忽略； - 在 Python 里运行
python -c "import torch; print(torch.version.cuda)"，查看框架标注的 CUDA 运行时版本。框架要求不要超过驱动上限。
如果框架运行时版本高于驱动支持上限，最容易的路径是升级显卡驱动；如果这是无法操作的生产机器，则降低框架版本或改用预编译的 CPU 版本。
配置交换内存与显存回收参数
当显存不够但机器不想立刻挂掉时，有两个方向可以临时兜底。第一个是 PyTorch 显存分配器参数，在启动 Python 之前设置：
export PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True python run_your_model.py
该参数允许 PyTorch 以可扩展段为单位向驱动申请显存，减少碎片化导致的“显存够用但仍 OOM”情况。注意它只影响 PyTorch 的显存分配策略，不会扩大物理显存。
第二个是系统 swap。Linux 下用 free -h 查看当前交换空间，不足时可以临时添加一个 swapfile：
sudo fallocate -l 16G /swapfile sudo chmod 600 /swapfile sudo mkswap /swapfile sudo swapon /swapfile
swap 的作用是防止系统层 OOM 杀掉进程，并不代表模型计算变快。它也不能承载显存中的矩阵计算，只能让进程多撑一段时间，用于保存上下文或继续跑较小的 batch。所以它适合临时调试，不适合作为正常的显存扩容方案。
做完上述配置后，重新运行模型加载脚本并观察 nvidia-smi 的显存曲线和日志是否还出现 OOM。若日志已经消失，说明分配策略和交换空间兜住了峰值；若依旧报错，就需要回到模型侧降低 batch size，或者更换一张显存更大的显卡。