GPU VPS什么时候值得用，CPU VPS是否够用？

您需要带 GPU 的 VPS，还是 CPU 就够了？

带 GPU 的 VPS 会改变自行运行模型时的两点：生成 token 的速度，以及模型是否能完全装入内存。除此之外，它不会改变任何事情。如果您的工作负载是量化的 7B 到 27B 聊天模型，且一次只回答一个人；是低流量的嵌入任务；或是使用 Whisper small 进行语音转录，那么配备足够 RAM 的普通 CPU VPS 已经可以完成任务。先从 CPU 开始，测量真正让您不满意的指标，然后再升级。

原因在于内存带宽。语言模型生成一个 token 时，需要从内存中读取所需的全部权重。量化为 4 bit 的 8B 模型在磁盘上约占 4.7 GB，在内存中也大致相同，因此生成一个 token 就意味着移动约 4.7 GB 数据。用机器的内存带宽除以这个数值，就能得到每秒 token 数的上限。这个简单的除法可以解释您将看到的几乎所有基准测试结果。

GPU 的实际价值

带宽。 现代主机中的服务器 DDR5 每秒可传输数十 GB。GPU 内存（VRAM、显存）每秒可传输数百 GB，甚至超过 1 TB。两者的比值就是加速幅度，而且差距很大。

兼顾容量与速度。 配备 64 GB RAM 的 CPU 服务器可以加载 4 bit 的 70B 模型。模型可以运行，但速度更接近阅读，而不是聊天。只有模型能放入 VRAM 时，GPU 才能在这里发挥作用。因为只要模型层溢出到系统 RAM，慢速路径就会重新成为瓶颈。

批处理吞吐量。 这一点经常被低估。GPU 为一个用户生成内容时，大部分计算资源处于空闲状态，因为 GPU 在等待内存。一次处理 20 个请求时，同一次权重读取可以服务全部 20 个请求。聚合每秒 token 数量会提高数倍，而单个用户的速度几乎不会下降。CPU 无法做到这一点。CPU 服务器上有 2 个并发用户时，两者的速度大致会各减半。如果您正在构建供许多客户端调用的 API，批处理就是使用 GPU 的主要理由，其重要性高于单流原始速度。

提示词处理。 读取长提示词受计算能力限制，而不是受内存带宽限制。GPU 在这方面的优势最大。CPU 需要 1 分钟处理的 30,000 token 上下文，GPU 只需几秒。将文档填入每个请求的检索系统会持续遇到这个问题。

粗略数值及其解读方式

下面的表格列出了截至 2026 年 7 月，8B 模型采用 4-bit 量化时，典型的单流实测数据。这些数据只能用于数量级参考，并非性能保证。量化方式、上下文长度和推理引擎都会影响结果。

[
  {
    "label": "8 vCPU, DDR4",
    "mem_bandwidth_gbs": 40,
    "tokens_per_sec": 6
  },
  {
    "label": "16 vCPU, DDR5",
    "mem_bandwidth_gbs": 75,
    "tokens_per_sec": 11
  },
  {
    "label": "24GB GPU",
    "mem_bandwidth_gbs": 300,
    "tokens_per_sec": 50
  },
  {
    "label": "40GB data-centre GPU",
    "mem_bandwidth_gbs": 1555,
    "tokens_per_sec": 130
  }
]

24 GB GPU 这一行显示，其速度为每秒 50 个 token；DDR5 CPU 主机的速度为 11 个 token。这大约是 5 倍，符合带宽比，而不是原始计算能力的差异。实际吞吐量也会低于“带宽除以模型大小”得到的结果，因为上下文不断增长时，注意力计算会增加额外工作量，而简单除法没有考虑这一点。

作为对比，人类的阅读速度约为每秒 5 到 10 个词。对于单个读者来说，每秒达到或超过 15 个 token，体感上就已经接近正常打字速度。因此，许多仅使用 CPU 的配置其实完全够用。

购买前估算 VRAM

模型文件大小只是底线，不是实际需求。需要为权重、KV cache（键值缓存，即 attention 保留的每个 token 的内存）以及约 1 GB 的开销预留空间。

截至 2026 年 7 月，一个实用规则是：取模型文件的 GB 大小，并为 8k 到 16k 的常规上下文增加 20%。一个 4.7 GB 的 8B 模型大约需要 6 GB VRAM。采用 4 bit 的 27B 模型约为 16 GB，通常需要约 20 GB。采用 4 bit 的 70B 模型约为 40 GB，需要一张 48 GB 显卡，或两张较小的显卡。

较长的上下文会使这一规则失效。KV cache 会随上下文长度线性增长，在 128k token 时，其大小可能超过权重本身。如果计划使用较长的上下文，应首先按缓存需求进行配置，并确认所用引擎支持哪些缓存量化选项。

检查机器实际具备的组件

在 GPU 实例上，先确认驱动能够识别显卡。

nvidia-smi

您应看到一个表格，其中列出 GPU 名称、驱动版本，以及已用内存和总内存。出现 NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver 表示缺少驱动，或者内核升级后内核模块未重新构建。在标准 Ubuntu 镜像上，通常执行 sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install 即可修复，然后重启以加载新模块。

对于容器，仅安装驱动还不够。Docker 需要 NVIDIA Container Toolkit 才能传递设备。

sudo apt-get update && sudo apt-get install -y --no-install-recommends ca-certificates curl gnupg2
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

然后在容器内部验证设备传递是否正常：

sudo docker run --rm --gpus all ubuntu:24.04 nvidia-smi

此时应显示相同的表格。出现 docker: Error response from daemon: could not select device driver 行，并且其中列出了无法满足的 GPU capability，表示已安装 toolkit，但 Docker 从未重新配置或重启。因此请重新执行 nvidia-ctk 行，并进行重启。在 Compose 中，等效配置是一个 deploy.resources.reservations.devices 条目，其 driver 为 nvidia，并且 capabilities 列表包含 gpu。该配置可以直接加入 VPS 上的 Docker Compose 中介绍的常规服务定义。

升级前先测量

在现有的 CPU 机器上运行您实际准备使用的模型，并记录数据。使用 Ollama 在 VPS 上自行托管 LLM 时，只需设置一个标志：

ollama run llama3.1:8b --verbose "Summarise the causes of the 1929 crash in 200 words."

输出末尾会显示计时信息。eval rate 是每秒生成的 token 数。prompt eval rate 是机器读取输入的速度。这两个数值可以帮助您确定应进行哪种升级：eval rate 较低表示存在内存带宽问题；长输入下 prompt eval rate 较低表示存在计算性能问题。

在配备 GPU 的机器上，确认模型确实已加载到 GPU：

ollama ps

如果模型完全适配，PROCESSOR 列会显示 100% GPU；如果未完全适配，则会显示类似 43%/57% CPU/GPU 的内容。部分分配通常比预期更慢，因为每个 token 仍需等待速度较慢的部分。

成本问题

GPU 实例的成本是同等 CPU 实例的数倍，并且按实例存在的每个小时计费，而不是按其生成的 token 数计费。让一台始终运行的 GPU 每天只处理少量请求，是运行推理最昂贵的方式。盈亏平衡点在于利用率：繁忙的 GPU 平均每个 token 的成本较低，空闲的 GPU 则完全是在浪费资源。

有三种切合实际的模式。将稳定的低流量工作负载保留在 CPU VPS 上。偶尔遇到复杂请求时，发送到托管 API，并按 token 付费。按小时租用 GPU 运行批处理任务、微调或批量 embedding，完成后将其销毁。混合使用这些模式很正常，此处同样适用 始终运行的 VPS 上的 AI agent 成本控制 中介绍的预算管理原则，但差别在于，成本漏洞来自空闲时间，而不是 token 数量。

没有 GPU 仍可正常运行的任务

低吞吐量的 Embedding。小型 Embedding 模型在几个 CPU 核心上每分钟可处理数百份短文档，而只需构建一次的索引不需要很高的处理速度。

使用 Whisper small 和 base 进行转录。Faster-whisper 在 CPU 上使用 small 模型时，转录速度接近实时，足以支持运行一整夜的流水线。

面向一个或两个用户、规模不超过约 27B 的量化聊天模型。速度较慢，但输出易读且可以使用。

任何可归类为批处理作业的任务。如果没有人盯着屏幕，实际运行时长只是调度细节，而不是硬性要求。

真正需要 GPU 的任务包括：超出小型适配器范围的训练或微调、为许多并发用户提供服务、图像和视频生成，以及延迟本身就是产品要求的实时语音处理。

FAQ

7B 或 8B 模型需要多少 VRAM？

对于在正常 8k 到 16k 上下文长度下运行的 4-bit 量化 8B 模型，大约需要 6 GB。模型权重约占 4.7 GB，其余空间用于 KV cache 和约 1 GB 的开销。12 GB 显卡可以为更长的上下文留出充足空间。如果计划使用 128k 上下文长度，请单独为缓存预留空间，因为缓存可能会超过模型权重的大小。

没有 GPU 可以运行 Ollama 吗？

可以。Ollama 会自动回退到 CPU，只需要足够的 RAM 来容纳模型。对于 4-bit 8B 模型，根据内存速度不同，预计每秒生成约 5 到 12 个 token。对于单个用户，这接近阅读速度。CPU 的主要瓶颈是长提示词，因为读取 30,000 个上下文 token 受计算能力限制，耗时远高于生成回复。

为什么我的 GPU 几乎没有比 CPU 快？

通常是因为模型无法完全放入 VRAM，部分层在 CPU 上运行，每个 token 都要等待较慢的一侧。运行 ollama ps，并检查 PROCESSOR 列是否显示 100% GPU。如果显示存在拆分，请使用更小的量化版本或更小的模型。另一个常见原因是基准测试时间太短，模型加载时间占据了主要测量结果。

单个用户使用 GPU VPS 是否值得？

通常不值得。一个人的阅读速度为每秒 5 到 10 个单词，而对于不超过约 13B 的模型，CPU 服务器生成 token 的速度已经高于此速度。单个用户使用 GPU 的合理场景包括长提示词、图像生成和微调。同时为许多用户提供服务是最有力的理由，因为批处理可以让一块 GPU 以接近处理一个请求的成本响应二十个请求。

应该按小时租用 GPU，还是让 GPU 始终运行？

如果工作负载具有突发性，例如微调、批量生成 embedding 或批量转录任务，请按小时租用。只有在显卡持续繁忙时才应让它始终运行，因为 GPU 实例按运行时间计费，而不是按生成的 token 数量计费。低流量助手使用 CPU VPS 或按 token 付费的托管 API，比运行空闲 GPU 更便宜。