无需 GPU、仅用 CPU 运行本地 LLM：按 8/16/32 内存容量选择模型 Go

#为什么要在不使用 GPU 的情况下本地运行 LLM？

所有本地 AI 指南都假设您的台式机里装着一张 RTX 4070。现实是，绝大多数笔记本电脑、办公台式机和迷你 PC 使用集成 GPU，或根本没有独立显卡。好消息是：仅靠 CPU 运行 LLM 也行得通。

选择仅用 CPU 运行通常有三个原因：笔记本电脑没有 NVIDIA GPU（大多数 Dell、Lenovo 笔记本和较老的 Intel Mac 都属于这种情况）；商用台式机配备的是 Intel 或 AMD 集成显卡；或者 Linux 无头服务器不打算加装 GPU。在这三种情况下，关键不是“能不能运行”，而是“哪个模型仍然可用”。

#实际可预期的表现

在下载任何内容之前，请先调整好预期。仅用 CPU、没有 GPU 的本地 LLM，其响应速度与 ChatGPT 或在 RTX 4090 上运行的模型不同。以下是 2026 年切合实际的性能量级：

Q4 量化的 1B–2B 模型

在较新的 CPU 上，每秒可生成 20 到 40 个 token。非常流畅，几乎如同在线聊天。非常适合简单任务：改写、生成短摘要、分类。

3B 模型（Q4）

每秒 10 到 20 个 token。体验依然流畅，可以在模型生成内容的同时阅读。这是日常使用中 CPU 运行模型的理想平衡点。

7B–8B Q4模型

4 到 10 token/秒。可以使用，但需要等待。适合异步任务（分析文本、生成草稿）。

13B–14B Q4 模型

每秒 2 至 5 个 token。速度勉强还能接受。请仅用于批处理任务，不要用于交互式聊天。

超过 14B

可以运行，但体验很痛苦。与其在 CPU 上运行 32B 模型，不如租用一小时的云 GPU。

#根据可用 RAM 推荐的模型

在CPU上，系统所有内存均可用于模型，但需为操作系统和应用程序保留一定空间。建议预留4至6GB给系统。剩余内存决定可加载模型的大小。

#8 GB 内存：支持 2B 至 4B 模型

Qwen 3.5 2B Q4_K_M

≈1.9 GB。运行极快，支持多模态，上下文长度达 256k，许可协议为 Apache 2.0。适用于改写、翻译、分类等任务。

Granite 4.2 3B Q4_K_M

约 2.2 GB。资源占用很低，token 使用效率高，由 IBM 出品，采用 Apache 2.0 许可证。法语表达能力不错。

Qwen 3.5 4B Q4_K_M

约 3.4 GB。新的默认小型模型。在代码和法语处理方面表现稳健。

Gemma 4 E2B Q4 (QAT)

≈4.3 GB。体积小，支持多模态，由谷歌出品，2026 年改用 Apache 2.0 许可证。

#16 GB 内存：可轻松运行 8B–12B 模型

Granite 4.2 8B Q4_K_M

约 5.3 GB。token 使用效率很高，上下文长度为 128k，采用 Apache 2.0 许可证。加载速度快。

Qwen 3.5 9B Q4_K_M

≈6.6 GB。2026 年 8 GB 内存配置的首选：256k 上下文，支持视觉输入，在推理和法语方面表现出色。

Gemma 4 12B Q4_K_M

≈7.6 GB。支持多模态且高效，采用 Apache 2.0 许可证。如果您的内存容量允许，这是更高一档的选择。

Qwen 2.5 Coder 7B base Q4_K_M

约4.7 GB。这是一个至今仍值得使用的例外：2026年本地内联代码补全（FIM）的标杆。

#32 GB 内存：可以考虑 24B 模型

Mistral Small 24B Q4_K_M

约 14 GB。通用模型，法语表现很好，但在 CPU 上每秒只能生成 3 至 5 个 token。

gpt-oss 20B Q4 (MXFP4)

≈14 GB。OpenAI 的开放权重模型，得益于 MXFP4 格式，运行速度非常快，上下文长度为 131k。

Qwen 3.8 27B Q4_K_M（接近容量上限）

约 18 GB。支持 262k 上下文长度、视觉能力，许可协议为 Apache 2.0。可行但较慢，约每秒 2 个 token。更适合批量处理 —— 建议将推理模式设为 low，以避免过度思考。

#1. 安装Ollama（自动启用CPU模式）

Ollama 是最容易上手的工具。它会自动检测到没有 GPU，并切换到 CPU 运行，无需特殊配置。守护进程默认监听 http://localhost:11434。

curl -fsSL https://ollama.com/install.sh | sh

在Windows和macOS上，请从ollama.com下载安装程序。CPU模式无需特殊设置——Ollama会自动做出合适的选择。

ollama --version
ollama ps

命令 ollama ps 应显示守护进程状态。若正在进行对话，PROCESSOR 列将显示 100% CPU —— 这正是我们在此场景中期望的结果。

#2. 三个可在纯 CPU 环境下比较的模型

对于 16 GB 内存，问题并非「哪个模型」，而是「2026 年三大小型模型中哪一个」。下载三个模型，一小时内自行判断。

ollama pull qwen3.5:4b
ollama pull granite4.2:3b
ollama pull gemma4:e2b-it-qat

Qwen 3.5 4B

这一规模下综合能力最强的选择。法语表现非常扎实，代码能力良好，支持 256k 上下文，能很好地遵循指令。三者中速度最慢，毕竟有 4B 参数。

Granite 4.2 3B

IBM 出品，资源占用很低，token 使用效率高。指令遵循能力好，采用 Apache 2.0 许可证。是速度与质量之间的良好折中。

Gemma 4 E2B

三者中速度最快。支持多模态，对于其规模而言质量令人惊喜。适合希望在低端CPU上实现近实时性能的用户。在代码生成方面表现不如另外两个模型。

ollama run gemma4:e2b-it-qat --verbose
>>> Explique en 3 phrases la différence entre une LLC et une SAS.

--verbose 选项会在每条回复底部显示统计信息：prompt eval rate、eval rate（生成阶段每秒输出的 token 数）和 total duration。这些是您在这台机器上的参考指标。

#3. 每秒 token 数基准测试：数量级参考

以下是在一些代表性设备上，不使用 GPU、通过 Ollama（底层使用 llama.cpp）并采用 Q4_K_M 量化时的大致性能数值。您的结果会因上下文、内存和 DDR 频率而有 ±20% 的波动。

#Intel Core i5-12400 + DDR4-3200 16 GB

Gemma 4 E2B Q4

生成速度约为 26 token/秒

Granite 4.2 3B Q4_K_M

约 20 个标记/秒

Qwen 3.5 4B Q4_K_M

≈ 15 tokens/sec

Granite 4.2 8B Q4_K_M

≈ 8 tokens/sec

Qwen 3.5 9B Q4_K_M

≈ 6 tokens/秒

#Intel Core i7-13700K + DDR5-5600 32 GB

Gemma 4 E2B Q4

≈ 40 tokens/sec

Granite 4.2 3B Q4_K_M

≈ 30 tokens/秒

Qwen 3.5 4B Q4_K_M

≈ 23 tokens/sec

Qwen 3.5 9B Q4_K_M

≈ 12个token/秒

Mistral Small 24B Q4_K_M

约 4 个标记/秒

#AMD Ryzen 7 7700X + DDR5-6000 32 GB

Gemma 4 E2B Q4

≈ 44 tokens/sec

Granite 4.2 3B Q4_K_M

≈ 32个标记/秒

Qwen 3.5 4B Q4_K_M

≈ 24 tokens/sec

Granite 4.2 8B Q4_K_M

≈ 13 tokens/sec

Qwen 3.5 9B Q4_K_M

≈ 11 个标记/秒

Mistral Small 24B Q4_K_M

≈ 5 tokens/sec

#4. 使用AVX-512编译llama.cpp（高级）

Ollama 内置通用的预编译 llama.cpp 二进制文件。使用您 CPU 的指令集（AVX2、AVX-512、AMX）手动编译 llama.cpp，可在某些处理器上将每秒生成的 token 数提高 10 至 30%。仅适用于支持 AVX-512 的第 11 代及更新的 Intel Core 处理器（Ice Lake / Rocket Lake / Sapphire Rapids）。

grep -o 'avx512[a-z_]*' /proc/cpuinfo | sort -u

如果命令返回了包含 avx512f、avx512dq 等内容的行，说明您的 CPU 支持 AVX-512。否则，请继续使用标准版 Ollama，换用其他版本不会带来收益。

git clone https://github.com/ggerganov/llama.cpp
cd llama.cpp
cmake -B build \
  -DGGML_NATIVE=ON \
  -DGGML_AVX512=ON \
  -DGGML_AVX512_VBMI=ON \
  -DGGML_AVX512_VNNI=ON
cmake --build build --config Release -j

-DGGML_NATIVE=ON 选项让编译器自动检测您 CPU 的指令集并启用所有可用功能。这是最简单且最可靠的方法。

./build/bin/llama-bench -m qwen3.5-9b-Q4_K_M.gguf -t 8

选项 -t 设置线程数（请填写物理核心数，而非逻辑核心数）。llama-bench 会返回一个表格，列出 pp512（提示词评估）和 tg128（生成）的速度，单位为 tokens/sec——这就是您今后进行比较的新基准。

#提升 CPU 上 token 生成速度的技巧

1. 01
   设置线程数量

   Ollama默认使用所有逻辑核心。在部分支持超线程的CPU上，限制为物理核心（如8核CPU设置OLLAMA_NUM_THREADS=8）可提升5%至15%的性能。
2. 02
   让模型保持已加载状态

   模型加载需要数秒。设置OLLAMA_KEEP_ALIVE=30m可使模型在最后一次请求后继续保留在内存中30分钟。没有GPU时，这一设置尤其有用，因为重新加载较慢。
3. 03
   如有可能，缩短上下文长度

   将 num_ctx 从 8192 降低到 2048 可节省 RAM 并显著提升速度。仅在真正需要时（如 RAG、长文档）保留大上下文。
4. 04
   关闭 Chrome 和 Slack

   在 CPU 上运行的 7B LLM 会占满内存带宽。其他同样使用 RAM 的应用（打开 50 个标签页的浏览器、Slack、Teams）都会抢占模型所需的处理器周期。在 16 GB 内存的机器上，这可能就是每秒 5 个 token 与 8 个 token 的差别。
5. 05
   选择兼容且速度最快的 DDR 内存

   若进行升级：DDR4-3200 → DDR4-3600 = +10%。DDR4 → DDR5-5600 = +30%至50%。对于LLM推理，CPU的影响远小于内存。

#当CPU无法满足需求时

实事求是：没有 GPU，部分应用场景仍无法实现。如果您在以下列表中找到了自己的情况，现在就需要考虑配备一块入门级 GPU（例如以 250 欧元购入的二手 RTX 3060 12GB，将带来巨大改变）或选择按小时租赁云服务。

与 13B+ 模型进行交互式聊天

每秒 2 到 5 个 token，对于对话式 AI 来说太慢了。一个 12 GB 显存的 GPU 可以瞬间解决这个问题。

使用大上下文的 RAG（16k 及以上）

在 CPU 上，提示词评估的处理时间会大幅增加。RTX 3060 处理长度为 8k 的提示词需要 1 秒，而 i7 需要 30 秒。

实时代码自动补全

内联补全扩展（如 Tabby 等，配合 FIM 模式使用 Qwen 2.5 Coder 7B 基础模型）需要响应时间低于 200 毫秒。在 CPU 上，响应时间将不低于 1 到 2 秒，必须使用 GPU。

批量生成

处理 1000 个文档 = CPU 上需数天，GPU 上需数小时。对于单次批量任务，RunPod 或 Vast.ai 按 0.30 欧元/小时计费，可在一夜之间完成。

#深入了解

您已经有一个在本地 CPU 上运行、能够回答问题的 LLM。根据您接下来想了解的问题，可以进一步阅读以下内容：

选择合适的量化

Q4_K_M 是稳妥的默认选择，但根据您的 RAM 容量，Q5_K_M 或 Q3 也有各自的适用场景。量化指南详细介绍了这些权衡。

为整体添加一个用户界面

终端确实适合测试。Open WebUI 或 LM Studio 可在几分钟内提供类似 ChatGPT 的本地界面。

何时添加 GPU

如果您决定迈出这一步，GPU 选购指南对比了 RTX 3060、4060 和 4070，并提供相应的 LLM 基准测试。

推荐硬件： Radeon RX 9070 XT 16 GB — 从纯CPU模式切换至专用GPU模式。 所有 AI 硬件 →