哪些 AI 模型可以自行托管？RAM 容量计算

决定您可以自行托管哪些 AI 模型的因素

您可以自行托管哪些 AI 模型，取决于一个数字：服务器的 RAM。模型系列和框架的重要性远低于权重是否能在内存中装下，并留有余量。本文通过算术计算这一点。安装运行时是另一项工作，详见在 VPS 上运行 Ollama 的指南。

有两项成本决定结果。权重是固定成本，由参数量和量化方式决定。上下文窗口是运行成本，也是人们最容易忽略的因素：某个模型昨天还能加载，今天却无法加载。

每个参数的位数：容量计算

模型文件几乎全部由权重组成。每个权重使用固定数量的位存储。量化是指使用少于训练时精度的位数存储权重，这会略微降低精度，但能节省大量内存。文件大小可直接按以下公式计算：

weights in GB = (parameters in billions x bits per weight) / 8

模型通常以 16 位精度发布，也就是每 10 亿个参数需要 2 GB。因此，几乎没有人会在 VPS 上运行发布精度的模型。以下是您实际会遇到的量化格式，以及每个权重的实际平均位数：

• Q8_0每个权重约使用 8.5 位，因此每 10 亿个参数约需要 1.1 GB。
• Q6_K每个权重约使用 6.6 位，因此每 10 亿个参数约需要 0.83 GB。
• Q5_K_M每个权重约使用 5.7 位，因此每 10 亿个参数约需要 0.71 GB。
• Q4_K_M每个权重约使用 4.8 位，因此每 10 亿个参数约需要 0.6 GB。

实际计算时，请按每 10 亿个参数 0.6 GB 估算。在内存受限的服务器上，Q4_K_M 是合理的默认选择：与 8 位量化相比，大多数任务的质量损失很小，而文件大小几乎减半。低于 4 位后，质量损失会快速增加。因此，同一代模型中，压缩到 2 位的 70B 通常不如使用 4 位的 32B。内存不足时，应先降低模型规模，不要先降到 4 位以下。

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

上表中的权重容量是按每 10 亿个参数 0.6 GB 的规则计算的。实际 GGUF 文件通常与该估算值相差不超过几个百分点，因为嵌入层和输出层的精度高于其他层。4 位的 3B 模型约为 1.8 GB。8B 模型约为 4.8 GB。32B 模型约为 19.2 GB，70B 模型约为 42 GB。

上下文长度为何比权重占用更多 RAM

KV 缓存（key value cache，即模型为当前对话中的每个 token 保留的注意力状态）是第二项开销。模型加载时会分配该缓存，并根据请求的上下文长度确定大小；上下文越长，缓存就按线性增长。

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

在 Ollama 的默认上下文长度下，这个 8B 模型的缓存占用半个 GB。在 8192 个 token 下，占用 1 GB。在其模型卡标示的 128k 上下文下，占用 16 GB，超过权重的三倍。70B 则相反：其 128k 上下文的缓存占用 40 GB，小于自身权重。这是因为 grouped query attention 使每个 token 的开销不会随着参数量以接近的速度增长。

在仅使用 CPU 的服务器上，Ollama 的默认上下文长度为 4096 个 token。存在 GPU 时，它会根据 VRAM 选择默认值：VRAM 为 24 至 48 GiB 时使用 32k，VRAM 为 48 GiB 及以上时使用 256k。可在服务器上通过 OLLAMA_CONTEXT_LENGTH 变量提高该值，然后在运行模型的 ollama ps 中查看 CONTEXT 列，确认模型实际获得的上下文长度。该设置背后的内存计算详见num_ctx 和上下文长度一文。

有两种方法可以减少缓存占用。请设置实际需要的上下文长度，而不是模型卡标示的长度，因为大多数聊天和编码任务都能在 8k 至 32k 内完成。或者将缓存本身量化为 8 位，这样可以将其占用减半，但长上下文的召回能力会有所下降。

常驻模型会一直占用 RAM，直到被卸载

Ollama 会在最后一次请求后将模型保留在内存中 5 分钟，然后将其卸载。这个默认设置适合笔记本电脑，但不适合服务器。服务器在每次空闲间隔后收到第一个请求时，都需要再次支付模型加载时间。

ollama ps
ollama stop qwen3:4b

ollama ps 会列出当前驻留的模型，其中 SIZE 列显示模型占用的内存量，UNTIL 列显示模型的到期时间。要永久固定模型，请在服务上设置 OLLAMA_KEEP_ALIVE=-1。设置为 0 后，每次响应完成时都会立即卸载模型。

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

发送一个提示词，然后在 10 分钟后再次运行 ollama ps。模型仍会列出，这正是要说明的问题：无论是否有人使用，它都会持续占用 RAM。固定模型并不等于有可用容量。在 16 GB VPS 上，使用 8k 上下文的 8B 模型会在服务运行期间持续占用约 6 GB 内存。因此，应根据模型和应用程序的总需求选择服务器规格，而不能只根据模型大小选择。将模型固定在内存中介绍了这一设置与冷启动延迟之间的权衡。

4 GB VPS 上可以运行什么

为操作系统和模型服务器预留约 1 GB 后，还剩约 3 GB。在默认的 4096 token 上下文长度下，这足以运行 4 bit 的 1B 至 4B 模型。截至 August 2026，这一规模包括 3B 的 Llama 3.2、1.7B 和 4B 的 Qwen 3，以及较小的 Gemma 和 Phi 版本。请将这些名称视为规模示例，而不是推荐。模型名称每隔几个月就会更新，但计算方式不会改变。

预计速度约为 6 至 14 tokens/second。这类小模型适合执行范围明确的任务：分类、提取标签、生成简短摘要，以及按照统一文风改写段落。它们不擅长多步推理，也不擅长处理跨多个文件的代码；再多提示也无法弥补这一点。

这一档配置最常见的问题是 swap。如果模型无法装入内存，Linux 不会拒绝加载，而是将内存页换出到磁盘。由于生成单个 token 时需要读取全部权重，生成速度会降至每个 token 数秒。模型生成回答时，监控 free -h 以及 vmstat 1 的 si 和 so 列。生成过程中如果 swap in 和 swap out 均为非零，说明模型对于该配置过大。

8 到 16 GB VPS 上可以运行什么

这时，自托管模型通常已经具备实用价值。在 8 GB 内存的 VPS 上，可以运行 4 bit 量化的 7B 或 8B 模型，权重约占 4.8 GB，并使用 8k 上下文。在 16 GB 内存的 VPS 上，可以运行 4 bit 量化的 13B 或 14B 模型，权重约占 8.4 GB；如果更重视精度而不是参数量，也可以将 8B 模型保持为 8 bit 量化。

限制在于速度。CPU 上的 8B 模型每秒生成约 3 到 7 个 token，14B 模型约为 1.5 到 3.5 个 token。人类的阅读速度约为每秒 5 到 10 个 token，因此，在 CPU VPS 上运行 8B 模型就像看着打字很慢的人输入内容。对于后台任务，这样的速度可以接受；对于交互式聊天，则会让人感到疲劳。在 VPS 上实测 Qwen 3 的 8B 及更大模型可以直观看到实际效果。

32 至 64 GB VPS 上可以运行什么

一个 32B 模型采用 4 bit 量化时，大约需要 19.2 GB，因此可以装入 32 GB 方案，但上下文长度需要较短；在 48 GB 或 64 GB 上则有充足余量。一个 70B 模型采用 4 bit 量化时，大约需要 42 GB，因此在完全不计缓存的情况下也需要 64 GB。

然后要如实评估速度。32B 模型在 CPU 上的速度约为每秒 0.6 到 1.5 个 token，70B 模型约为每秒 0.2 到 0.5 个 token。70B 模型生成 500 个 token 的回答大约需要二十分钟。这类工具适合批处理。让它们整夜处理文档队列，速度就不重要。将它们接入聊天窗口后，速度就会非常重要。

混合专家模型（MoE）的路由机制会改变上述计算方式，这是唯一值得了解的架构细节。MoE 模型只会让每个 token 经过全部权重中的一小部分。一个总参数量为 30B、每个 token 激活 3B 参数的模型，需要 30B 模型的内存，但生成速度接近稠密 3B 模型，因为每个 token 只读取激活的专家。在 32 GB 服务器上，这种结构的 MoE 模型比稠密 30B 模型实用得多。需要记住的规则是：总参数量决定内存需求，激活参数量决定速度。

CPU 推理速度究竟有多快？

生成一个 token 需要从内存中读取每个活跃权重一次。这个过程无法绕过，因此 CPU 上的生成速度取决于内存带宽，而不是核心数量。上限可以通过一个除法得出：可用内存带宽除以权重的字节大小。小型共享 VPS 的所有 vCPU 通常可实际提供 10 到 25 GB/s 的内存带宽，因此 4.8 GB 的模型最高约为每秒 2 到 5 个 token。

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

这些范围通常来自普通 VPS 硬件上的报告，不是对某一台机器的基准测试。实际数值取决于内存代际、主机上的内存通道数量，以及争用内存资源的邻居数量。可以使用已有的任意模型标签测量自己的速度：

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

答案结束后打印的摘要中有一行以 eval rate: ... tokens/s 开头。这就是生成速度。忽略会话中的第一次运行，因为同一摘要中的 load duration 还包括从磁盘读取权重的时间。正确测量每秒生成的 token 数介绍了如何获得具有比较价值的数值。

这里有两个结果经常让人意外。增加 vCPU 很快就不再有帮助，因为超过大约 8 个核心后，额外核心是在等待内存，而不是执行计算。在共享方案中，同一命令每小时返回的数值可能不同。这是嘈杂邻居导致的 CPU steal time，不是配置错误。

读取提示词与生成答案是两项不同的工作。提示词处理受计算能力限制，因此会随核心数增加而扩展，也是 GPU 优势最明显的环节。CPU 读取一份长文档需要几分钟，而 GPU 只需几秒。这是让编码代理使用您托管的模型时首先遇到的瓶颈，因为每一轮都要先重新发送文件上下文和工具定义，然后才能返回答案中的第一个 token。

添加 GPU 后有哪些变化

算式不变，变化的只是适用的资源池。VRAM 是硬限制，因此在租用之前，先计算需要的配置：

• 8 GB VRAM 可在较短上下文下运行 4 bit 的 7B 或 8B 模型。
• 16 GB 可在实际使用的上下文下运行 4 bit 的 14B 模型，或 8 bit 的 8B 模型。
• 24 GB 可在较短上下文下运行 4 bit 的 32B 模型。
• 48 GB 及以上可运行 4 bit 的 70B 模型，并为缓存和并发留出空间。

模型无法完全装入 GPU 时，Ollama 会将其拆分：部分层放在 GPU 上，其余层放在 CPU 上。ollama ps 会在其 PROCESSOR 列中报告拆分情况，例如 78%/22% CPU/GPU。应将其视为警告，而不是功能。CPU 上的部分决定处理速度，因为每个 token 仍需等待这些层完成处理。因此，如果模型有四分之一的层在 CPU 上运行，其速度会更接近 CPU，而不是 GPU。如果发现了不符合预期的拆分，先降低上下文长度。通常是缓存导致模型超出显存限制。

并发是选择更大配置的另一个原因。多个并发请求会共享模型权重，但每个活动请求都需要独立的 KV 缓存。因此，10 个并发用户以 8k 上下文运行 8B 模型时，除了模型权重外，还需要 10 倍的 1 GB 缓存。使用一个自托管模型服务并发用户介绍了这一上限如何影响配置。

是否值得租用 GPU 同样是一个算术问题，取决于您每月实际生成多少 token。GPU VPS 与 API token 的盈亏平衡点列出了相关数据。

无法自行托管的内容

这里有两道不同的限制，首先需要确定您遇到的是哪一道。

第一道限制是权重闭源。前沿商业模型不提供权重，因此没有可下载的文件，增加 RAM 也无法解决这个问题。您可以自行托管模型周边的所有组件：界面、检索层、代理循环和日志。模型本身仍通过远程 API 提供。能否自行托管 Claude对此进行了完整说明。

第二道限制是开放权重模型规模过大。最大的开放权重模型采用混合专家架构，总参数量达到数千亿级别。同样的规则也适用于这类模型：一个总参数量为 400B、使用 4 bits 的模型，仅权重就需要约 240 GB，还未计算任何缓存。这需要专业硬件，而按月租用这类硬件的成本，远高于大多数人一年用于 API token 的支出。自行托管 Kimi 级别模型需要什么条件详细介绍了实际需求。

两者之间的实际界线是：负载稳定且数据不应离开您的服务器时，选择自行托管。负载具有突发性，或者您真正需要的是前沿模型的回答质量时，购买 token。

选择前先确认现有资源

free -h
nproc
lscpu | grep 'Model name'

根据 free -h 的 available 列规划，而不是根据 total 列规划，因为 total 包含系统当前已使用的内存。为操作系统和模型服务器预留约 1 GB。将剩余内存除以 0.6，得到在 4 bit 精度下可容纳的最大参数量（以十亿为单位）。然后扣除实际所需上下文的 KV cache。剩余数值就是答案。与模型名称列表不同，它不会因模型更新而过时。

FAQ

运行 8B 模型需要多少 RAM？

4 bit 量化时，权重约占 4.8 GB，此外还需要为上下文长度分配 KV 缓存，并为操作系统和模型服务器预留约 1 GB。在 8192 token 上下文下，缓存会增加约 1 GB，因此 8 GB 方案可以运行，4 GB 方案则不行。如果要使用模型卡宣传的完整 128k 上下文，仅 KV 缓存就需要 16 GB，此时应选择 32 GB 方案。

为什么 VPS 有充足的 vCPU，但模型运行仍然很慢？

因为生成速度受内存带宽限制，而不是由核心数量决定。生成每个 token 都需要从 RAM 读取完整的活动权重集，因此几个核心占满内存通道后，其余核心只能等待。另一个常见原因是 swap。如果模型回答时 vmstat 1 显示非零的 si 和 so，说明权重无法全部装入 RAM，每个 token 的部分计算都需要从磁盘读取，代价远高于直觉预期。

更长的上下文窗口确实需要更多内存吗？

需要，而且内存占用会随 token 数量线性增长。典型的 8B 模型每个 token 约占用 128 KiB 的 KV 缓存，因此 8192 个 token 需要 1 GB，131072 个 token 需要 16 GB。模型加载时就会分配缓存，而不是等对话增长后再分配。因此，指定 128k 上下文会立即预留这部分内存，即使发送的每个 prompt 都只有 200 个 token。

应该使用 2 bit 的大模型，还是使用 4 bit 的小模型？

选择 4 bit 的小模型。从 8 bit 降到 4 bit 时，质量下降较慢；低于 4 bit 后，质量会快速下降。因此，同一模型系列中，压缩到 2 bit 的 70B 模型通常不如 4 bit 的 32B 模型。高强度量化通常表现为重复输出和遗漏指令，而不是显示错误消息，因此很容易误以为是 prompt 的问题。应将 4 bit 视为下限，并改用调整参数量的方式。

可以自行托管能力接近大型商用模型的模型吗？

在普通 VPS 上不行。最强的开放权重模型规模达到数千亿参数，使用 4 bit 量化时，在计算 KV 缓存之前就需要超过 200 GB RAM；而最强的商用模型根本不会公开分发。普通硬件适合运行针对单一任务的优秀 8B 到 32B 模型。在这种场景下，范围明确且 prompt 编写良好的小模型通常可以达到通用模型的效果。如果需要前沿模型的质量，应在购买硬件前先将 API 成本与硬件成本进行比较。