开始之前
一台至少 16 GB 内存的 Linux VPS——32 GB 能给系统和更长的上下文窗口留出更舒适的余量。小模型的纯 CPU 推理对个人使用来说是真的可用，这也是这整篇指南存在的理由：它不是一个生产 API，而是一个花费不到一杯咖啡订阅费的私人助手。
# Ubuntu 22.04/24.04 LTS. Check what the plan actually gives you:
free -h
lscpu | grep -E "^CPU\(s\)|^Thread|^Core|^Socket"
# vCPUs are often hyperthreads: "Thread(s) per core: 2" means
# half of nproc is the number of real cores.编译 llama.cpp
普通的 CPU 构建开箱即用。只有在你打算批量处理长文档时才值得加上 OpenBLAS——llama.cpp 自己的文档写明 BLAS 加速只在批大小超过 32 的提示词处理阶段有用，不会改变生成速度，所以纯聊天场景的 API 可以跳过它。
sudo apt update && sudo apt install -y build-essential cmake git
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build
cmake --build build --config Release -j$(nproc)下载模型并启动服务
Q4_K_M 是合适的默认选择——权重 4.6 GB，在 16 GB 内存里很从容，还能给系统和真正的上下文窗口留出空间。不要写 `-t`：llama.cpp 本来就用物理核心数，而 `$(nproc)` 数的是 vCPU，在很多套餐上那是超线程，只会增加争用而不会更快。绑定到回环地址，如果这台机器有任何公网暴露，就在前面加一个 API key。
pip install -U huggingface_hub
hf download bartowski/Meta-Llama-3.1-8B-Instruct-GGUF \
--include "Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf" --local-dir ./models
./build/bin/llama-server \
-m ./models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
--host 127.0.0.1 --port 8080 \
-c 8192 \
--api-key "your-secret-key"确认它真的没问题
在 VPS 上，「启动成功」和「速度可用」不是一回事——两个都要确认：发一个请求证明服务能应答，再用 `llama-bench` 在你实际租用的硬件上测生成速度（`tg128`）。可执行文件是 `llama-server`；旧教程里那个裸 `server` 的名字是 CLI 改名之前的写法。
curl -H "Authorization: Bearer your-secret-key" \
http://127.0.0.1:8080/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"messages":[{"role":"user","content":"hi"}]}'
# Watch resident memory while it runs:
ps aux | grep llama-server
# Generation speed on this box (tg128 row = tokens/s):
./build/bin/llama-bench -m ./models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf数字大概该是什么样
Llama 3.1 8B 的 Q4_K_M 权重是 4.6 GB。生成速度是「带宽除以这个数字」，而共享型 VPS 的系统内存带宽差异，比显卡显存带宽的差异大得多——它取决于宿主机实际分配给你的资源，而不只是宣传的 vCPU 数量——所以本文不会引用一个没有人在你具体的服务商上实测过的 tok/s 数字。真正值得盯的是内存。按本站计算器，Llama 3.1 8B 的 Q4_K_M 在 8K 上下文下约 6.2 GB，32K 下约 9.5 GB，两者都能和系统一起放进 16 GB 的机器。这个模型完整的 128K 窗口需要约 22.7 GB，放不下，所以要明确设置 `-c`，不要让它停留在训练时的长度。
出问题时
在 16 GB 的机器上爆内存：检查还有什么在跑——和模型共用同一台 VPS 的数据库或 Web 服务器会争抢模型需要的那份内存。生成速度比预期慢：低价 VPS 档位的系统内存带宽常常才是真正的瓶颈，再怎么调线程数也解决不了一条共享、超售的内存总线——真正的解法是换更高的实例档位，不是加参数。服务绑定成功了但外部访问不到：如果你绑定的是 `127.0.0.1`，那是对的——在前面加一层带 TLS 的反向代理，而不是直接绑定到 `0.0.0.0`。如果这台机器有任何公网暴露而你还没加 `--api-key`，那应该是第一件要修的事，不是最后一件。
常见问题
一台 16 GB 内存的廉价 VPS 真的能跑 8B 模型吗？
个人使用的话可以。Llama 3.1 8B 的 Q4_K_M 权重需要 4.6 GB，8K 上下文下合计约 6.2 GB，16 GB 的实例很从容。生成速度取决于服务商的系统内存带宽，本索引没有跨服务商测过这个数字——把它当作一个可用的私人助手，而不是有吞吐保证的生产级 API。
在 VPS 上编译 llama.cpp 要不要加 OpenBLAS？
只有在你要批量处理长文档时才需要。llama.cpp 的文档写明 BLAS 加速只在批大小超过 32 的提示词处理阶段有用，对生成速度没有影响——对聊天类 API 来说，普通的 CPU 构建就够了。
在公网 VPS 上怎么保护 llama.cpp 服务？
把服务绑定到 `127.0.0.1`，不要绑 `0.0.0.0`，务必带上 `--api-key`，并且给任何能从公网访问到的服务加一层带 TLS 的反向代理——llama.cpp 内置的服务本身没有限流，也没有用户管理。
这篇指南用到了什么
- 格式
- GGUF
接下来
看看 💻 16 GB RAM (CPU) 还能跑哪些模型反向查询 —— 16GB、4096 上下文，按质量排序本文涉及的模型
它真的跑起来了吗？
复制命令并不等于它能用，所以站内只在这里问一次。除了你的这个回答之外，不收集任何东西。