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

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

GPU VPS 会改变自行运行模型时的两点：token 的生成速度，以及内存到底能容纳多大的模型。除此之外不会改变任何事情。如果您的工作负载是一次回答一个人的量化 7B 到 27B 聊天模型、低吞吐量的嵌入任务，或使用 Whisper small 进行语音转录，那么只要 RAM 足够，普通 CPU VPS 就能完成这些工作。先从 CPU 开始，测量最让您困扰的指标，然后再升级。

原因在于内存带宽。语言模型生成一个 token 时，会从内存中读取所需的全部权重。采用 4 bit 量化的 8B 模型在磁盘上约占 4.9 GB，在内存中也大致相同，因此生成一个 token 就意味着移动约 4.9 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 数量会提高数倍，而单个用户的速度只会略有下降。llama.cpp 等 CPU 推理引擎也支持批处理，收益取决于硬件和工作负载。如果您要构建供多个客户端调用的 API，批处理是选择 GPU 的主要理由，其重要性高于单个流的原始速度。

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

粗略数值及其解读

实际吞吐量也会低于“带宽除以模型大小”得到的数值，因为随着上下文增长，注意力计算会增加额外工作，而简单除法没有考虑这一点。

作为对比，成年人默读英文的平均速度约为每秒 4.0 至 4.3 个单词：非虚构文本为每分钟 238 个单词，虚构文本为每分钟 260 个单词。对单个读者而言，达到每秒 15 个 token 或更高的速度，已经接近正常打字速度。因此，许多仅使用 CPU 的部署实际上运行良好。

购买前估算 VRAM

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

不要直接增加一个固定百分比，而应单独计算 cache，因为量化权重不会量化 cache。对于每个 token，全 attention 模型会为每一层和每个 KV head 保存一个 key 和一个 value；在 FP16 中，每个数占 2 bytes，这是 Ollama 的默认 cache 类型。Ollama 的模型元数据（于 2026-10-27 检查）显示，Llama 3.1 8B 有 32 层、8 个 KV head，每个 head 的维度为 128。由此计算，每个 token 占用 128 KiB：在 8k context 下约为 1.07 GB，在 16k 下约为 2.15 GB。因此，一个 4.9 GB 的 8B 模型在 8k 下需要约 7 GB VRAM，在 16k 下需要约 8 GB。使用 4 bit 的 27B 模型约占 17 GB（Ollama library 中的 Gemma 3 27B）。Gemma 3 的元数据显示，其 sliding window 为 1,024 个 token，因此大部分 cache 不会持续增长，建议预留 20 GB 或更多。使用 4 bit 的 70B 模型约占 43 GB（Llama 3.3 70B）。它有 80 层，FP16 cache 在 8k 下额外占用约 2.7 GB，在 16k 下额外占用约 5.4 GB，因此需要一张 48 GB 显卡且几乎没有余量，或使用两张更小的显卡。相同的计算方法也适用于更大的模型，而2.8 万亿参数的 Kimi K3 的 VRAM 计算会说明，到了什么规模后，选择显卡本身就不再是问题。

长 context 最能体现这一点。对于 Llama 3.1 这类 full-attention 模型，KV cache 会随 context 长度线性增长，在 128k token 时可能超过权重本身。使用 sliding-window 或 chunked attention 的模型则不同：Hugging Face 的 Transformers 文档将 Mistral、Gemma 2 和 Llama 4 列为示例，这些模型的相关层在 cache 达到窗口或 chunk 大小时会停止增长，因此总占用增长更慢。如果您计划使用长 context，应首先按 cache 进行容量规划，并确认所用引擎支持哪些 cache 量化方式。在 Ollama 中，OLLAMA_KV_CACHE_TYPE=q8_0 的内存占用约为默认 f16 的一半，而且只有启用 Flash Attention 后，cache quantization 才会生效。还应显式设置 context length。Ollama 会根据 VRAM 选择默认值：低于 24 GiB 时为 4k，24 到 48 GiB 时为 32k，48 GiB 及以上时为 256k。在 48 GB 显卡上运行 70B 模型时，该默认值所需的 cache 远超显卡容量。

检查机器实际具备的组件

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

nvidia-smi

输出中应列出 GPU 名称、驱动版本以及已用内存和总内存。NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver 表示 NVIDIA-SMI 无法访问驱动；请检查驱动是否已安装，以及内核模块是否已加载。在标准 Ubuntu 镜像上，通常执行 sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install 即可修复，然后重启以加载新模块。对于计算型机器，Ubuntu 的服务器文档建议使用 sudo ubuntu-drivers install --gpgpu，该命令会选择 server 驱动分支。

对于容器，仅安装驱动还不够。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 能力，表示 Docker 找不到符合请求的设备驱动；请检查 Toolkit 是否已安装，然后重新执行 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 实例按已配置的计算时间计费，而不是按 token 计费。费率以及停止实例后的收费规则由服务提供商设定。一台全天运行、每天只处理少量请求的 GPU，大部分付费时间都处于空闲状态。关键在于利用率：繁忙的 GPU 每个 token 的成本较低，空闲的 GPU 则是在纯粹浪费资金。

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

无需 GPU 也能正常运行的任务

低负载的嵌入任务。小型嵌入模型使用几个 CPU 核心，每分钟可处理数百个短文档；而且一次构建的索引不需要很快。

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

面向一两个用户的量化聊天模型，规模最高约为 27B。速度较慢，但可读、可用。

任何可归为批处理作业的任务。如果没有人盯着屏幕，墙上时钟时间只是调度细节，而不是硬性要求。

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

FAQ

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

在 8k 上下文和 Ollama 默认的 FP16 缓存下，4-bit 量化的 8B 模型需要约 7 GB；在 16k 上下文下需要约 8 GB。模型权重约占 4.9 GB，KV 缓存在 8k 下增加约 1.07 GB，在 16k 下增加约 2.15 GB，其余约 1 GB 为运行开销。8 GB 显卡可以在 8k 下运行，但在 16k 下余量很小；12 GB 显卡则能为更长的上下文保留充足余量。将缓存切换为 q8_0 后，缓存占用大致会减半。如果计划使用 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 值得使用吗？

通常不值得。英语成人默读速度平均约为每秒 4.0 到 4.3 个单词；将 CPU 服务器的速度与该速度比较前，必须先把每秒 token 数换算为每秒单词数。对单个用户而言，长提示词、图像生成和微调是足以证明成本合理的场景。一次服务多个用户是更有力的理由，因为批处理可以让一个 GPU 在多个请求之间共享模型权重读取。

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

如果任务具有突发性，例如微调、批量生成嵌入或批量转录，请按小时租用。只有在显卡持续繁忙时，才适合始终保持运行，因为已分配的 GPU 计算资源按使用时间计费，而不是按生成的 token 数量计费。对于低流量助手，使用 CPU VPS 或按 token 付费的托管 API，通常比让 GPU 空闲运行更便宜。