把大语言模型完整地跑在自有 GPU VPS 上，最直观的变化不是单纯省下 API 账单，而是权重、日志、提示词和生成结果都能留在自己控制的磁盘里。DatabaseMart 的美国 GPU VPS 提供多档显存规格，本文以一台实际开通的 24GB 显存实例为例，从空系统开始完成驱动、CUDA、推理框架和模型部署，并记录实测表现。
为什么选择 DatabaseMart GPU VPS 作为本地模型运行环境
云厂商的 GPU 实例通常把 AI 训练卡作为卖点，但真正跑推理时，显存容量、驱动适配和网络下载速度往往比单纯算力更重要。DatabaseMart 的美国机房节点在开通后默认提供 Ubuntu 22.04 或 24.04 镜像，本次实例为 10 核 vCPU、64GB 内存和 24GB 显存的 NVIDIA 显卡。这个配置足以承载 7B 到 13B 参数模型的 FP16 加载，也能在 AWQ 或 GPTQ 量化后尝试 30B 级别模型。
开通过程整体比较直接，控制面板可以选择预装 NVIDIA 驱动的镜像，也可以选择纯净系统自己配置。为了测试真实部署流程，我没有使用预装镜像，而是从基础系统开始一步步安装。这样虽然耗时更多，但能清楚掌握每个环节的依赖关系，后续排查问题也会轻松很多。实际体验中，美国机房的网络出口对 Hugging Face 和 GitHub 的访问速度不算稳定，建议提前准备好模型下载镜像或离线权重。
第一轮检查重点是确认 PCIe 设备是否被系统正确识别。执行 lspci | grep -i nvidia 后能看到显卡型号，说明硬件层面没有问题。之后再用 nvidia-smi 查看驱动状态，如果提示命令不存在，就需要手动安装驱动。这个阶段最容易忽略的是内核头文件缺失，导致驱动编译失败，因此需要先安装 linux-headers-$(uname -r)。
环境搭建：驱动、CUDA 与 PyTorch 的正确顺序
对于 Ubuntu 系统来说，推荐的安装顺序是先更新系统并补齐编译工具，再安装 NVIDIA 驱动，最后安装 CUDA Toolkit。驱动不建议直接下载 runfile 硬装，优先使用系统软件源中的 nvidia-driver-535-server 或更新版本。这样 DKMS 会自动跟随内核更新重新编译模块，减少重启后 nvidia-smi 失效的概率。
sudo apt update && sudo apt upgrade -y sudo apt install -y build-essential dkms linux-headers-$(uname -r) lspci | grep -i nvidia sudo apt install -y nvidia-driver-535-server sudo reboot nvidia-smi
驱动装完后，接着安装 CUDA Toolkit。这里不需要使用系统软件源里的 cuda 包，因为它的版本可能落后于 PyTorch 官方推荐的 CUDA 版本。以 PyTorch 2.1 或 2.2 为例，安装 CUDA 12.1 或 12.2 都可以获得完整 GPU 加速支持。下载 runfile 时选择 --toolkit 参数仅安装 CUDA，不覆盖已有驱动，避免版本冲突。
wget https://developer.download.nvidia.com/compute/cuda/12.2.0/local_installers/cuda_12.2.0_535.54.03_linux.run sudo sh cuda_12.2.0_535.54.03_linux.run --toolkit --silent --override echo 'export PATH=/usr/local/cuda-12.2/bin:$PATH' >> ~/.bashrc echo 'export LD_LIBRARY_PATH=/usr/local/cuda-12.2/lib64:$LD_LIBRARY_PATH' >> ~/.bashrc source ~/.bashrc nvcc --version
随后创建独立的 Python 虚拟环境，不要直接污染系统 Python。安装 PyTorch 时一定要指定 CUDA 版本对应的 --index-url，否则默认下载的是 CPU 版本，后续推理会全部回退到 CPU，速度相差几十倍。验证时只需要三行 Python 代码，如果 torch.cuda.is_available() 返回 True，并且能打印出显卡名称，说明 PyTorch 已经可以调用 GPU。
python3 -m venv llm-env source llm-env/bin/activate pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121 python -c "import torch; print(torch.cuda.is_available(), torch.cuda.get_device_name(0))"
模型部署与实测：从 llama.cpp 到 vLLM 的性能差异
如果只是想快速跑通本地大模型，llama.cpp 是门槛最低的选择。它支持 GGUF 量化格式，编译时加入 CUDA 支持即可把权重层卸载到 GPU 上。在 24GB 显存机型上，Qwen2.5-7B-Instruct 的 Q4_K_M 量化版本可以完全放入显存，-ngl 99 表示把所有层都交给 GPU 处理。实测长文本生成时速度稳定在每秒 40 到 60 个 token，显存占用大约 6GB，同时 CPU 占用率很低。
git clone https://github.com/ggerganov/llama.cpp cd llama.cpp make clean && make LLAMA_CUDA=1 -j ./llama-cli -m /data/models/Qwen2.5-7B-Instruct-GGUF/qwen2.5-7b-instruct-q4_k_m.gguf -n 256 --temp 0.7 --repeat_penalty 1.1 -ngl 99
如果需要对外提供 OpenAI 兼容的 HTTP 接口，vLLM 更适合。它采用 PagedAttention 机制，可以更高效地利用显存并支持并发请求。部署 7B 模型时，FP16 版本约占 15GB 显存，AWQ 量化后可以压到 7GB 左右。单用户请求时 vLLM 的生成速度与 llama.cpp 接近，但在 4 路并发下吞吐量提升明显，首 token 延迟也更低。实际测试中，AWQ 版 Qwen2.5-7B-Instruct 在 4 并发下总吞吐约为每秒 90 到 120 个 token。
pip install vllm python -m vllm.entrypoints.openai.api_server --model /data/models/Qwen2.5-7B-Instruct --dtype auto --max-model-len 8192 --port 8000
两种方案的选择取决于使用场景。如果只是本地调试、写文档辅助或做批量抽取，llama.cpp 足够轻量，启动快、依赖少。如果打算接入自建应用、开放给团队内部使用，vLLM 的 OpenAI 兼容接口和并发能力会更合适。需要注意的是，vLLM 对 CUDA 版本和 PyTorch 版本比较敏感，安装前最好先查看官方要求，避免升级后出现算子不匹配的问题。
实用技巧与避坑经验
在长期运行过程中，有几个技巧能明显提升体验。第一是模型文件不要放在系统盘，建议单独挂载一块数据盘到 /data 目录，避免扩容系统盘时迁移文件。第二是下载大权重时使用 huggingface-cli download 并配合镜像变量，例如将 HF_ENDPOINT 指向国内可达的镜像站，速度可以从几十 KB 提升到几 MB 每秒。第三是使用 tmux 或 systemd 让推理服务常驻后台，而不是在 SSH 断开后结束进程。
最容易踩的坑是驱动失效。如果某次系统升级内核后 nvidia-smi 报错，先执行 dkms status 查看模块是否成功编译。如果模块缺失，可以重新安装带 DKMS 的驱动包，或者手动运行 dkms install -m nvidia -v 535.54.03。不要一上来就重装系统，大部分情况只是内核头文件版本不匹配。
显存管理同样需要留意。加载 FP16 模型前先确认剩余显存，避免同时启动两个大模型导致 OOM。可以用 CUDA_VISIBLE_DEVICES=0 限制可见显卡，再结合 --max-model-len 控制上下文长度。遇到推理中途崩溃但显存没有释放时，先检查是否存在僵尸进程占用，使用 nvidia-smi 查看 PID 后手动结束。对于需要连续跑批的任务，建议在代码里加上显存缓存清理逻辑，防止显存碎片持续累积。
DatabaseMartGPU VPS大语言模型部署修改时间：2026-09-30 05:04:05