在 VPS 上自建大模型。
没有 GPU。没有 API 密钥。没有一条提示词会离开这栋楼。

几乎所有关于本地跑大模型的文章讲的都是显卡，如果你手上只有一台虚拟机，这些内容帮不上什么忙。真正有用的心智模型比 GPU 那套话语体系简单得多，一句话就能说完：要生成一个 token，稠密模型必须把它所有的权重都从内存里读一遍。不是读一部分——是全部，每个 token 都要读一次。

光这一个事实就决定了整个性能问题的答案。生成速度不是由你租了多少核心决定的，而是由这台机器能以多快的速度把模型从 RAM 里读出来决定的。这样一来，你在花一分钱之前，就能在信封背面随手算出一个上限：

tokens per second  ≈  memory bandwidth (GB/s)  ÷  model size (GB)

一个量化后的 8B 模型大约占用 5 GB。在一台实际带宽在 20 GB/s 左右的虚拟化主机上，上限大约是每秒 4 个 token，而实测到的数字往往只有这个上限的一半到三分之二。大致是每秒 3 个词。把这当成这类任务本身的事实，而不是什么让人失望的结果：对聊天窗口来说这确实慢，但对一个负责给文档分类、返回一行 JSON 的任务来说完全够用。

核心数依然重要，只是原因和大多数人想的不一样。 增加线程数是有用的，但一旦占满内存通道就没用了，而这些机器往往很早就会撞到这个上限——通常在四到八个线程左右。过了这个点，多出来的核心只能闲着，其他一切都在等 RAM。这就是为什么一台十六核的机器生成文本的速度不会是四核机器的四倍，也是为什么为了追求速度去多花钱买核心数，是选错档位最常见的原因。

读得快，写得慢。 每一次请求都分两个阶段，它们的表现完全不一样。处理提示词——也就是预填充（prefill）阶段——是一次对整段输入一次性完成的矩阵运算，受算力限制，运行速度比生成快得多。生成答案则是前面说的那种受内存限制的部分，一个 token 一个 token 来。所以，把一份两千字的文档丢给模型、只要求返回三句话，是一项轻松的任务，而让它写一篇两千字的文章就不是了。围绕这种不对称去设计你的提示词，一台 CPU 机器给人的感觉会比它的 token 速率听起来要好得多。

模型大小统一按 Q4_K_M 量化计算，这种量化用一点几乎察觉不到的质量损失，换来不到一半的内存占用。速度这一列是从上面那道算式推出来的数量级，不是跑分——第 03 步的意义就在于让你实测自己的机器，而不是相信任何一张表格，包括这一张。

从任务本身倒推。先确定模型要做什么，选出能胜任的最小规模，查一下这个规模在 Q4_K_M 下占多大空间，再加上各种开销：

RAM needed  =  model file  +  KV cache  +  ~2 GB for the system

  3B  Q4_K_M  ≈  2.0 GB        KV cache at 8k context   ≈  0.5–1 GB
  8B  Q4_K_M  ≈  4.9 GB        KV cache at 32k context  ≈  2–4 GB
 14B  Q4_K_M  ≈  9.0 GB
 32B  Q4_K_M  ≈ 20.0 GB
 70B  Q4_K_M  ≈ 40.0 GB

键值缓存是大家最容易忘记的那部分开销。 对话里已经出现过的每个 token 都会被保留在内存中，这样模型就不用重新计算，而这块存储会随着你允许的上下文长度增长。上下文翻一倍，它也大致翻一倍。一个在 4k 上下文下装得下的模型，到了 32k 可能就装不下了，而且往往不是在第一次请求就失败，而是在第十次才失败，这会让人觉得莫名其妙，其实只是一道算式没算对。

这里没有什么优雅降级可言。 当总量超出 RAM 时，内核不会礼貌地慢下来：它会在每一个 token 上，把模型权重来回换出换入磁盘。本该四秒完成的生成变成四分钟，负载均值飙到两位数，机器上的其他一切——数据库、网页服务器、你的 SSH 会话——都会跟着遭殃。装进内存不是一项优化。这是硬性要求。

在面板里操作：Order → VPS → 算式指向的那个档位，镜像选 Debian 12。开户不需要邮箱地址，任何环节都不会索要身份证件，账单可以用 Monero、Bitcoin、Lightning 或其他支持的资产结算——这一点在这里比在普通的网页服务器上更重要，原因见匿名 VPS 托管支柱指南，下文的隐私章节则专门把这个道理用到了提示词上。

拉取一个模型。用来做第一次测速，随便哪个目前的 8B 级指令模型都行——它们体积足够接近，测出来的时间反映的是硬件本身，而不是模型的差异：

ollama pull llama3.1:8b        # ~4.9 GB at Q4_K_M
ollama list
ollama ps                      # nothing resident yet

现在打开计时开关，跑一次生成。真正重要的数字是生成速率——也就是提示词读完之后，每秒产生的 token 数：

ollama run llama3.1:8b --verbose "Reply with exactly one sentence about the Baltic Sea."

total duration:        14.2s
load duration:          3.1s
prompt eval count:        24 token(s)
prompt eval rate:      92.11 tokens/s      ← reading: fast
eval count:               38 token(s)
eval rate:              3.42 tokens/s      ← writing: the real ceiling

两行数字，两个不同的世界。读的速度跑到了每秒 90 多个 token；写的速度只有 3.5 个。这个比例正是算式那一章讲的不对称，只不过这次是在你自己的机器上实测出来的，也是你今天能拿到的最有用的一个事实。它在说：给这台机器长输入，只问它要短输出。

通过 API 做同样的测量，如果你打算写脚本批量对比两三个模型规模，这才是你真正需要的方式：

apt install -y jq

curl -s http://127.0.0.1:11434/api/generate -d '{
  "model":  "llama3.1:8b",
  "prompt": "List three Nordic capitals.",
  "stream": false
}' | jq '{
  tokens: .eval_count,
  seconds: (.eval_duration / 1000000000),
  rate: (.eval_count / (.eval_duration / 1000000000))
}'

测一下小一档和大一档的模型，然后就此打住。 拉取一个 3B 和一个 14B，把同样的提示词分别跑一遍，把三个速率都记下来。这样你就能确切知道在这台机器上这笔交换要付出多少代价——通常两个方向都接近翻倍——之后就可以按任务挑模型，而不是凭印象。然后把不打算留的模型删掉，因为它们每一个都占好几个 GB。

有一点要提醒：任何模型第一次运行时，输出里的加载耗时指的是把权重从磁盘读进 RAM 所花的时间。只有模型还没有常驻内存时才会产生这笔开销，而这正是 OLLAMA_KEEP_ALIVE 控制的东西。比较速率的时候不要把它算进去，也不用为此惊慌——在 NVMe 上也就是几秒钟，而且只会发生一次。

Ollama 在 /v1 上提供一套兼容 OpenAI 的接口，与它自己的 API 并存。集成方式就这么简单：任何为 OpenAI 构建的东西——官方 SDK、框架的封装、自动化节点——只需要改一下基础 URL 和密钥就能用，其他什么都不用变。

curl -s https://llm.example.com/v1/chat/completions \
  -H "Authorization: Bearer THE_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3.1:8b",
    "messages": [{"role":"user","content":"Reply with the word OK."}]
  }' | jq -r '.choices[0].message.content'

从 Python 代码的角度看，和调用托管服务相比，唯一不同的就是开头那两行：

from openai import OpenAI

client = OpenAI(
    base_url="https://llm.example.com/v1",
    api_key="THE_TOKEN",
)

r = client.chat.completions.create(
    model="llama3.1:8b",
    messages=[{"role": "user", "content": "Classify: 'the invoice is overdue'"}],
)
print(r.choices[0].message.content)

要 JSON，就给你 JSON。 对自动化来说，最有用的功能是约束输出。Ollama 可以强制答案是合法的 JSON，而不是指望模型自觉配合，这能把一个小模型从一个不可靠的“讲故事者”变成一个靠谱的解析器——这就是一个能无人值守运行的工作流，和一个每四十条就出错一次的工作流之间的区别：

curl -s http://127.0.0.1:11434/api/generate -d '{
  "model":  "llama3.1:8b",
  "prompt": "Extract the total and the currency: Invoice 4021, 1 249,90 EUR due 30 days.",
  "format": "json",
  "stream": false
}' | jq -r .response
# → {"total": 1249.90, "currency": "EUR"}

在自动化流水线里也是同样的道理：n8n 自带专门的 Ollama 节点，它的 OpenAI 节点也支持自定义基础 URL，所以现有工作流只需改一个凭证就能切换到本地推理。n8n 自建指南讲的是自动化引擎本身；如果条件允许，把两者放在不同的机器上跑，因为一个空闲时就占 700 MB 的引擎，和一个想要 5 GB 的模型，挤在一台 8 GB 的机器上不会相处愉快。

还有嵌入接口——这才是这台机器真正物有所值的地方。 嵌入模型比生成模型小两个数量级，每个分块只需一次前向计算，不用生成任何东西，所以 CPU 处理起来的速度几乎是瞬间完成：

ollama pull nomic-embed-text      # ~275 MB

curl -s http://127.0.0.1:11434/api/embed -d '{
  "model": "nomic-embed-text",
  "input": ["the first chunk of a document", "the second chunk"]
}' | jq '.embeddings | length'

以上说的全都是生成，也就是 CPU 做得慢的那部分。检索是大多数实用系统的另一半，而它把局面完全反过来了——这也是为什么这个页面上最便宜的档位，哪怕你从不在它上面生成一个 token，也能做成一件真正有价值的事。

嵌入模型把一段文本变成一个向量。它的体积以几百 MB 计，而不是几个 GB，每个分块只需要一次前向计算，没有逐 token 的循环会被内存带宽卡住。在同一台机器上，8B 模型每秒只能吐 3 个词，嵌入模型处理一个文档库的速度却快得像在复制文件。

大致的样子。 把文档切成几百字一块的分块。每个分块生成一次嵌入并存下这个向量。提问的时候，把问题也生成嵌入，找出最接近的那几个分块，连同问题一起交给模型。存储不需要什么特别的东西：带向量扩展的 SQLite 数据库，就足够在一台 VPS 上存下几万个分块，PostgreSQL 配 pgvector 则能撑得更远。专门的向量数据库以后再想也不迟，第一天就上是没必要的依赖。

为什么这比速度更重要。 看看这两半各自会碰到什么。生成这一步接触到的是一个问题和几段文字。嵌入这一步接触到的是<em>你拥有的每一份文档</em>——整个档案库、每一份合同、每一条笔记、每一条消息，一块一块地喂给模型。如果这一步跑在托管端点上，你的整个语料库就已经为了建索引而传给了第三方。如果它跑在你自己的机器上，什么都没有离开过。

这为那些不愿放弃前沿质量的人提供了一个真正好用的混合方案：在本地建索引、在本地检索，只有当答案需要做到出色时，才把问题和检索到的那三个分块发给托管模型。语料库留在本地，只有薄薄一片会外传，而且只在需要时才传。

本站上的两个相邻话题能把这个模式讲得很具体。自建 SearXNG为检索层提供的是一个面向公开网络的私人前端，而不是语料库；自建文档存储提供的才是语料库。这两者加上模型，放在一起的档位，每月花费也比一个托管席位的价格更低。