VPS需要GPU吗？哪些模型用CPU就够了

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

带 GPU 的 VPS 会改变自行运行模型时的两件事：token 的生成速度，以及内存是否能够容纳某个模型。除此之外不会改变任何事情。如果您的工作负载是量化后的 7B 至 27B 对话模型，且一次只回答一个人的请求；低并发量的 embedding 任务；或使用 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 服务器可以加载 70B 模型的 4 bit 版本。但运行速度更接近阅读，而不是聊天。只有模型能装入 VRAM 时，GPU 才能在这里发挥作用，因为模型层一旦溢出到系统 RAM，慢速路径就会重新成为瓶颈。

批处理吞吐量。 这是人们最容易低估的部分。GPU 为单个用户生成内容时，大部分计算资源处于空闲状态，因为 GPU 在等待内存。一次处理 20 个请求时，同一次权重读取可以服务全部 20 个请求。总体每秒生成的 token 数量会提高数倍，而单个用户的速度几乎不会下降。CPU 无法做到这一点。在 CPU 服务器上，两个并发用户通常会使彼此的速度大致减半。如果您要构建供许多客户端调用的 API，批处理就是选择 GPU 的理由，而且比单路请求的原始速度更重要。

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

粗略数值及其解读方式

下面的数据块列出了截至 July 2026，4-bit 量化的 8B 模型在单流场景下常见的已发布数据。这些数值仅用于提供数量级参考，不构成性能保证。量化方式、上下文长度和推理引擎都会使结果发生变化。

[
  {
    "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 到 10 个单词。对于单个读者来说，每秒达到或超过 15 个 token，体感上已经接近正常打字速度。因此，许多仅使用 CPU 的配置实际上完全够用。

购买前估算 VRAM

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

截至 July 2026，一个实用的估算方法是：将模型文件大小（单位为 GB）增加 20%，适用于常见的 8k 到 16k 上下文。一个 4.7 GB 的 8B 模型需要约 6 GB VRAM。一个 4 bits 的 27B 模型约为 16 GB，需要大约 20 GB。一个 4 bits 的 70B 模型约为 40 GB，需要一张 48 GB 显卡，或两张容量更小的显卡。对于更大的模型，同样的计算方式仍然适用；像 Kimi K3 这样的 2.8 trillion parameter 模型的 VRAM 计算则说明，显卡选型最终可能根本不再是问题所在。

长上下文会使这一规则失效。KV cache 会随上下文长度线性增长，在 128k tokens 时，其容量可能超过权重本身。如果计划使用长上下文，应首先按照缓存需求进行容量规划，并确认所用引擎是否支持缓存量化。

确认机器实际具备的组件

在 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 才能传递 GPU 设备。

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 能力，表示工具包已安装，但 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 则完全是在浪费资源。

有 3 种可行且符合实际的模式。将持续但低流量的工作放在 CPU VPS 上。偶尔将复杂请求发送到托管 API，并按 token 付费。对于批处理任务、微调或大批量嵌入任务，按小时租用 GPU，完成后将其销毁。混合使用这些方式很常见。始终运行的 VPS 上的 AI agent 成本控制中介绍的预算管理原则同样适用于这里，但需要注意，真正造成成本泄漏的是空闲时间，而不是 token 数量。

在没有 GPU 的情况下仍能正常运行的任务

低负载嵌入。小型嵌入模型使用几个 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 始终运行？

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