哪些 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，超过权重的 3 倍。70B 模型的情况相反：其 128k 上下文的缓存占用 40 GB，少于自身权重。这是因为 grouped query attention 使每个 token 的开销增长速度远低于参数数量的增长速度。

在仅使用 CPU 的服务器上，Ollama 的默认上下文长度为 4096 个 token。存在 GPU 时，Ollama 会根据 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 上，8B 模型使用 8k 上下文时，只要服务运行，就会占用约 6 GB 内存。因此，应按模型加应用的总需求规划服务器容量，而不是只按模型需求规划。将模型固定在内存中介绍了固定模型与冷启动延迟之间的权衡。

4 GB VPS 上可运行的内容

为操作系统和模型服务器预留约 1 GB，剩余空间约为 3 GB。在默认 4096 token 上下文下，这足以运行采用 4-bit 量化的 1B 至 4B 模型。截至 2026 年 8 月，这一规模包括 3B 的 Llama 3.2、1.7B 和 4B 的 Qwen 3，以及较小的 Gemma 和 Phi 版本。这里只将这些模型作为大小示例，不构成推荐。模型名称每隔几个月就会变化，但计算结果不会。

预计每秒生成约 6 至 14 个 token。这类小模型适合执行范围有限的任务：分类、提取标签、生成简短摘要，以及按指定文风改写段落。它们不擅长多步推理，也不擅长处理跨多个文件的代码；再多提示词也无法解决这一问题。

这一档配置的主要故障模式是 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。

限制在于速度。8B 模型在 CPU 上每秒生成约 3 到 7 个 token，14B 模型约为 1.5 到 3.5 个 token。人类的阅读速度约为每秒 5 到 10 个 token，因此，在 CPU VPS 上运行 8B 模型，就像看着打字速度很慢的人输入一样。这适合后台任务，但用于交互式聊天会让人感到漫长。Qwen 3 8B 及更大模型在 VPS 上的实测运行结果展示了实际使用效果。

在 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 tokens/秒，70B 模型约为 0.2 至 0.5 tokens/秒。70B 模型生成 500 个 token 的回答大约需要 20 分钟。按这个速度，请求通常会在模型完成生成前失败，因为 Ollama 前面的某个客户端或代理会先触发超时。这就是 context deadline exceeded 错误 的来源。这些工具适合批处理。让它们在夜间处理一批排队的文档，速度通常不是问题。将它们接入聊天窗口后，速度就会非常重要。

混合专家路由会改变上述计算方式，这是唯一值得了解的架构细节。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。如果发现了非预期的拆分，首先降低上下文长度。通常是缓存导致模型超出容量。

并发是需要选择更大 GPU 的另一个原因。同时处理的请求可以共享权重，但每个活动请求都需要独立的 KV 缓存，因此，10 个用户同时以 8k 上下文使用 8B 模型时，除了模型权重外，还需要 10 倍的 1 GB 缓存。使用一个自托管模型为并发用户提供服务会说明这个上限具体在哪里。

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

无法自行托管的内容

这里有两道不同的限制，先弄清楚你遇到的是哪一道会更有帮助。

第一道是权重不开放。前沿商业模型不会发布模型权重，因此没有可供下载的文件，再多 RAM 也无法改变这一点。你可以自行托管围绕模型构建的所有组件：界面、检索层、代理循环和日志。模型本身仍然是远程 API。能否自行托管 Claude对此进行了完整说明。

第二道是开放权重模型规模过大。最大的开放模型通常采用混合专家架构，总参数量达到数千亿级别。同样的规则也适用于这些模型：一个总参数量为 400B、使用 4 bit 的模型，仅权重就需要约 240 GB，还不包括任何缓存。这需要专业硬件，而按月租用这类硬件的费用，远高于大多数人一年在 API token 上的支出。自行托管 Kimi 级别模型需要什么条件详细介绍了实际需求。同样的区别也体现在 Ollama 自己的模型库中：GLM 5.2 仅作为云端模型提供，而真正能下载到 VPS 上的是一个小得多的同系列模型。

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

选择前先确认现有资源

free -h
nproc
lscpu | grep 'Model name'

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

FAQ

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

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

VPS 有足够多的 vCPU，为什么模型仍然很慢？

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

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

需要，而且内存占用会随 token 数量线性增长。典型的 8B 模型每个 token 约占用 128 KiB 的 KV cache，因此 8192 个 token 需要 1 GB，131072 个 token 需要 16 GB。模型加载时就会分配 KV cache，而不是等对话增长后再分配。因此，指定 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 量化时，仅权重就需要超过 200 GB RAM，尚未计算 KV cache；而最强的商业模型根本不会公开分发。普通硬件适合运行 8B 到 32B 的优质模型来完成单一任务。在这种场景下，目标明确且 prompt 编写良好的小模型通常可以达到通用模型的效果。如果需要前沿模型的质量，应在购买硬件或 API 之前比较两者的成本。