用 Ollama 在 VPS 上运行 Qwen 27B：内存与速度

可以在没有 GPU 的 VPS 上运行 Qwen 3.8 27B 吗？

要在 VPS 上运行 Qwen 3.8 27B，首先需要确认模型标签确实存在。截至 2026 年 8 月 4 日，Ollama library 中完全没有 qwen3.8 条目。最近发布的 27B 标签是 qwen3.6:27b：包含 27.8 billion 个参数，使用 Q4_K_M 量化，采用 Apache 2.0 许可证。下面的每条命令和每个数字都使用 Ollama v0.32.5 上的该标签；该版本发布于 2026 年 7 月 27 日。

简短答案是：可以在 32 GB 或更大内存的 VPS 上运行，但速度较慢。Q4 量化的 27B dense 模型仅权重就需要约 17 GB RAM，尚未存储任何上下文 token。因此，8 GB 和 16 GB 方案完全不适用。在常见的双通道 DDR4 VPS 上，吞吐上限约为 3 tokens per second，低于大多数人的阅读速度。

3.8 是从哪里来的？最可能是参数数量。qwen3.6:27b 的 Ollama 页面显示其包含 27.8B 个参数，之后很容易将 27.8 记成 3.8。此外还有一个 qwen3.5:27b，它是上一版本发布的相同 Q4_K_M 构建。在复制任何命令前，请先查看实时列表，访问 Ollama qwen3.6 标签页面。如果之后发布真正的 qwen3.8，这里的计算仍然适用，因为计算取决于参数数量和每个权重使用的位数，而不是版本号。

应拉取哪个 Ollama 标签，以及如何检查

拉取不存在的标签时会返回明确错误，因此可以直接在目标主机上快速确认。

ollama pull qwen3.8:27b
# Error: pull model manifest: file does not exist

ollama pull qwen3.6:27b
ollama show qwen3.6:27b

ollama show 会输出您实际拥有的标签的架构、参数量、上下文长度和量化方式。如果参数行显示 27.8B，量化行显示 Q4_K_M，则表示您使用的是本指南对应的构建版本。同一组权重还提供了精度更高的 qwen3.6:27b-q8_0 和 qwen3.6:27b-bf16，此外还有一组 35b-a3b 标签，这些标签对应 MoE（混合专家）模型，在 CPU 上的运行方式明显不同。下文将进一步介绍这些内容。

参数数量乘以每个权重的字节数

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.89,
    "notes": "published tag qwen3.6:27b"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.8,
    "bits_per_weight": 5.7,
    "notes": "computed, no library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 20,
    "bits_per_weight": 5.76,
    "notes": "published tag 27b-nvfp4"
  },
  {
    "label": "Q8_0",
    "size_gb": 30,
    "bits_per_weight": 8.63,
    "notes": "published tag 27b-q8_0"
  },
  {
    "label": "BF16",
    "size_gb": 56,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16"
  }
]

公式只有一行：权重字节数 = 参数数量 * 每个权重的位数 / 8。按每个权重 4 bits 计算，27.8 billion 个参数应占用 13.9 GB。已发布的 Q4_K_M 标签为 17 GB，实际相当于每个权重 4.89 bits。

这不是错误。K-quant 格式不会以标称位宽存储每个张量。压缩后质量损失最大的张量会使用 5 或 6 bits，token embedding 和输出层通常保留为 Q6_K 或 Q8_0。格式名称表示的是平均值，实际平均值接近 4.9。该影响在另一端同样存在：BF16 占用 56 GB，实际为每个权重 16.1 bits，而不是固定的 16 bits，因为文件还包含元数据和完整精度的 embedding table。

此模型没有发布 Q5_K_M 标签，因此 19.8 GB 这一行是按该格式通常使用的每个权重 5.7 bits 计算的，而不是实测值。Q8_0 的大小几乎是 Q4 的两倍，达到 30 GB。在仅使用 CPU 的服务器上，这一增幅会使每个 token 的内存流量增加一倍，因此每秒处理的 token 数也大致减半。仅基于这一点，Q4_K_M 就是这里合适的默认选项。

上下文增长时 KV cache 的开销

权重是固定开销。KV cache（key 和 value cache，即模型为已经处理的每个 token 保留的 attention 状态）会随上下文长度线性增长，也是大多数人实际耗尽 RAM 的部分。

[
  {
    "label": "4k tokens",
    "kv_f16_gb": 1,
    "kv_q8_gb": 0.5
  },
  {
    "label": "8k tokens",
    "kv_f16_gb": 2,
    "kv_q8_gb": 1
  },
  {
    "label": "16k tokens",
    "kv_f16_gb": 4,
    "kv_q8_gb": 2
  },
  {
    "label": "32k tokens",
    "kv_f16_gb": 8,
    "kv_q8_gb": 4
  },
  {
    "label": "64k tokens",
    "kv_f16_gb": 16,
    "kv_q8_gb": 8
  },
  {
    "label": "128k tokens",
    "kv_f16_gb": 32,
    "kv_q8_gb": 16
  }
]

这些数值基于 Qwen 近期同等规模 dense 模型采用的结构：64 层、GQA（grouped-query attention）下的 8 个 key/value heads，以及 128 的 head dimension。在 f16 下，每个 token 占用 256 KiB。因此，32k tokens 需要 8 GB，128k tokens 需要 32 GB。不要直接将这些计算结果套用到您自己的机器上。加载模型后，读取 ollama ps 的 SIZE 列。该列会将权重、cache 和额外开销合并为一个数值。

因此，模型卡上的 256K context 更像是宣传参数，而不是实际规划。使用 f16 填满整个上下文窗口，除权重外还需要 64 GB cache；而这台机器已经为权重占用了 17 GB。Ollama 默认不会为您分配完整窗口，而是加载一个小得多的窗口。您可以通过 OLLAMA_CONTEXT_LENGTH 有意调大它。请分步调高，并在每次修改后检查 ollama ps。

有两个设置可以将 cache 减半或进一步降低。OLLAMA_KV_CACHE_TYPE=q8_0 会将 cache 的存储精度从 16 bits 降至 8 bits，使 32k tokens 的占用从 8 GB 降至 4 GB。它需要 flash attention，因此还要设置 OLLAMA_FLASH_ATTENTION=1，并通过 ollama ps 确认占用确实下降，不要默认它已经生效。OLLAMA_NUM_PARALLEL=1 同样重要。Ollama 可以同时处理多个请求，每个 slot 都会获得自己的上下文切片。因此，如果保持默认并行度，cache 占用会在不知不觉中按并行请求数倍增。

8、16、32 和 64 GB RAM 可容纳的内容

[
  {
    "label": "8 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "Weights alone exceed the box. Use a 4b or 8b model."
  },
  {
    "label": "16 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "17 GB of weights does not fit in 16 GB of RAM."
  },
  {
    "label": "32 GB",
    "q4_max_ctx_ktok": 32,
    "q8_max_ctx_ktok": 0,
    "notes": "Q4 fits with room to spare. Q8 weights do not fit."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": 64,
    "notes": "Both fit. Q8 leaves much less room for context."
  }
]

将这两个数字理解为：在无图形界面的 Linux VPS 上，使用 f16 cache 时，除模型权重外可容纳的上下文 token 数量（单位为千）。系统需预留约 1.5 GB 内存，并额外保留少量余量。0 表示模型权重本身就无法装入，因此无法容纳任何上下文。

8 GB 和 16 GB 都不是临界情况。17 GB 的模型权重无法装入 16 GB RAM，调整上下文设置也无法改变这一点。增加 swap 同样无法解决问题。Ollama 会对 GGUF 文件进行内存映射，因此常驻页面超过 RAM 后，内核会不断回收并重新读取这些页面，每生成一个 token 都会从磁盘读取数 GB 数据。此时服务器会长期处于高 iowait 状态，生成速度远低于每秒 1 个 token。

32 GB 是可用的起点。模型权重占用 17 GB，剩余约 13 GB，可在保留余量的情况下容纳约 32k 个 f16 上下文 token。占用 30 GB 的 Q8_0 权重则完全无法装入这一档内存。

64 GB 的余量较为充足。Q4 权重可为上下文留下约 128k 个 token，Q8_0 权重装入后还可容纳约 64k 个 token。在为运行 Q8 而购买 64 GB RAM 前，应明确这项升级的实际收益：输出质量略有提升，但速度降低一半，而这台机器本来就已经较慢。对大多数用户而言，Q4 配合更长的上下文是更合理的取舍。

VPS 上 CPU 推理有多快？

从稠密模型生成一个 token，意味着每次都要从内存读取全部权重。不是其中一部分，而是全部权重。因此，速度上限不是核心数，而是内存带宽除以权重大小。在 Q4 下，每个 token 需要产生 17 GB 的内存流量。

[
  {
    "label": "DDR4-2666, 2 channel",
    "mem_bandwidth_gb_s": 42.6,
    "ceiling_tok_s": 2.5
  },
  {
    "label": "DDR4-3200, 2 channel",
    "mem_bandwidth_gb_s": 51.2,
    "ceiling_tok_s": 3
  },
  {
    "label": "DDR5-4800, 2 channel",
    "mem_bandwidth_gb_s": 76.8,
    "ceiling_tok_s": 4.5
  },
  {
    "label": "DDR4-3200, 8 channel",
    "mem_bandwidth_gb_s": 204.8,
    "ceiling_tok_s": 12
  },
  {
    "label": "DDR5-4800, 12 channel",
    "mem_bandwidth_gb_s": 460.8,
    "ceiling_tok_s": 27.1
  }
]

这些是理论上限，不是实测结果。实际输出速度通常只有所示数值的 50% 到 70%，因为内存延迟和预取效率不理想，无法达到理论峰值。双通道 DDR4-3200 VPS 的上限是每秒 3 个 token，因此实际应约为 2。双通道 DDR5-4800 服务器的上限是 4.5，因此实际应约为 3。

大型服务器行需要特别注意。12 通道 EPYC 平台的内存带宽为 460.8 GB/s，上限为每秒 27.1 个 token，但您租用的并不是整台 EPYC 服务器。内存带宽是整台主机共享的资源，由该主机上的所有租户共同使用，因此 8 vCPU 实例并不拥有 12 个专用内存通道。专注 GPU 的指南通常完全忽略这一点。这也是同一模型在两个 vCPU 数相同的 VPS 方案上，速度可能相差 3 倍的原因。

出于同样的原因，增加 vCPU 很快就不再有帮助。当核心请求数据的速度超过内存控制器的供给能力后，额外线程只会增加调度开销，不会带来其他收益。将 OLLAMA_NUM_THREAD 设置为物理核心数并进行测试，然后尝试设置为该数量的一半。在许多共享方案中，较低的设置反而更快。

提示词处理的行为不同。Prefill 是在生成第一个 token 前处理输入内容的阶段，它主要受计算能力限制，而不是受内存带宽限制，因此会随着核心数增加而提速。实际表现是：较长的提示词会导致输出开始前出现较长暂停，随后进入上述较慢且稳定的生成速率。使用 --verbose 分别测量这两个阶段。该命令会为每个请求输出一个 prompt eval rate 和一个 eval rate。

如果稠密 27B 模型速度确实太慢，请在放弃 CPU 之前查看 qwen3.6:35b-a3b 标签。这些标签每个 token 只激活约 3 billion 个参数，而不是全部 27.8 billion 个参数。因此，即使磁盘上的文件更大，每个 token 的内存流量仍会减少近一个数量级。代价是更高的 RAM 占用，以换取更快的速度。这里运行时的选择也很重要，Ollama 和 llama.cpp 对相同的底层推理代码提供不同的 CPU 调优控制。

何时应改为按小时租用 GPU

[
  {
    "label": "L40S, 48 GB",
    "mem_bandwidth_gb_s": 864,
    "ceiling_tok_s": 51
  },
  {
    "label": "RTX 4090, 24 GB",
    "mem_bandwidth_gb_s": 1008,
    "ceiling_tok_s": 59
  },
  {
    "label": "A100, 80 GB",
    "mem_bandwidth_gb_s": 2039,
    "ceiling_tok_s": 120
  },
  {
    "label": "H100 SXM, 80 GB",
    "mem_bandwidth_gb_s": 3350,
    "ceiling_tok_s": 197
  }
]

将同一公式应用于已公布的 GPU 内存带宽，得到的结论属于另一类。24 GB 消费级显卡使用这组权重时，理论上限为每秒 59 个 token。当前的数据中心级显卡可达到 197。这不是通过调整线程数就能弥补的差距。该显卡的内存带宽为 1008 GB/s，而 VPS 只有几十 GB/s。

因此，应根据工作负载划分界限，而不是根据个人偏好决定。当任务是异步执行且没有人等待结果时，CPU 推理是合适的选择，例如在夜间汇总一批文档，或在你休息时运行每晚一次的分类任务。当有人等待输出，或请求到达频率高于每 30 秒一次时，就应租用 GPU。仅使用 CPU 的主机没有足够的批处理余量，队列只会不断增长。

成本比较并不像表面上那么简单。无论模型是否已加载，64 GB VPS 都会按整月的每小时计费；GPU 实例则只在保持运行的时段计费。如果实际使用时间是每天 2 小时，租用 GPU 可能同时更快、更便宜。先计算使用率，再进行价格比较。选择带 GPU 的 VPS介绍了应在实例本身检查的项目；在 GPU 上处理并发请求时，vLLM 会因正确执行批处理而超过 Ollama。

还有第三种选择，但经常被忽略。让 CPU 运行 27B 模型处理批量任务，并在交互式请求路径前接入托管 API 模型。不要求同一个模型同时承担这两类服务。

安装 Ollama 并测量本机性能

安装脚本是官方脚本，它会创建一个由专用 ollama 用户运行的 systemd 服务。

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

ollama --version 应输出 0.32.5 或更高版本。在拉取任何内容之前，先检查 free -g。如果 Mem 行的 total 列低于 32，请停止操作并选择更小的模型。拉取一个无法运行的 17 GB 模型会浪费一小时和大量磁盘空间。

请在 systemd override 中设置运行时选项，不要在 shell 中设置。模型在服务内部运行，因此无法读取您的交互式环境。

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_KEEP_ALIVE=60m"

sudo systemctl restart ollama
ollama pull qwen3.6:27b
ollama run qwen3.6:27b --verbose "Name two Linux distributions."

--verbose 输出就是您需要的测量结果。eval rate 是生成期间每秒生成的 token 数。prompt eval rate 是预填充速度。load duration 是从磁盘读取权重所需的时间，这也是设置 OLLAMA_KEEP_ALIVE=60m 的原因：在 CPU 上，每次请求都从磁盘重新加载 17 GB 权重，耗时可能超过请求本身。

模型加载期间，请在另一个终端中检查内存占用。

ollama ps

SIZE 列显示包含 KV cache 在内的实际内存占用。该数值应接近权重占用量，加上 KV 图表中与您的上下文长度对应的那一行。在 8192 token、8-bit cache 的情况下，预计会在权重占用量之上再增加约 1 GB；如果 cache 保持为 f16，则对应数值为 2 GB。PROCESSOR 列应显示 100% CPU。如果显示其他内容，说明某个进程占用了 GPU，本指南中的速度数据不适用于您的本机。

失败模式以及您将看到的确切字符串

模型拒绝加载。 Ollama 会输出一行，同时列出两个数值，格式为 model requires more system memory (18.6 GiB) than is available (15.2 GiB)。这是较理想的失败方式，因为 Ollama 在分配内存前就完成了检查，而不是让内核处理。请缩短上下文长度、改用更小的 tag，或升级到更大的方案。

进程在回答过程中消失。 客户端不会显示有用信息，而 journalctl -u ollama -n 50 会显示服务正在重启。运行 dmesg -T | tail；如果出现内容为 Out of memory: Killed process ... (ollama) 的行，表示内核的 OOM killer 终止了该进程。这通常发生在预加载检查通过，但长时间对话期间缓存增长超过估算值之后。请缩短上下文长度。

拉取立即失败。 Error: pull model manifest: file does not exist 表示该 tag 不在库中。输入 qwen3.8:27b 会准确产生此错误，版本号中的任何拼写错误也会导致相同结果。请先在库页面确认 tag，再排查网络问题。

一切正常，但速度慢得无法使用。 如果机器有足够 RAM，而生成速度低于每秒一个 token，通常说明发生了分页，而不是计算能力不足。生成内容时运行 vmstat 1。si 或 so 列为非零值，表示内核正在交换内存；应减少上下文长度或加载的模型数量。wa 持续较高且没有交换活动，表示内存映射的权重正在从磁盘重新读取，也就是说它们实际上无法完全放入内存。

第一个 token 需要 30 秒，之后输出速度加快。 这是预填充，属于正常现象。每次请求未命中缓存时，都需要重新处理较长的系统提示词，因此应先缩短系统提示词，再调整其他参数。

仅使用 CPU 的 27B 模型实际适合做什么

根据实际数据设定预期，不要凭希望做判断。每秒生成 2 到 4 个 token 时，生成 500 个 token 的回答需要 2 到 4 分钟。这种速度不适合聊天，但完全可以用于队列处理。文档摘要、批量添加标签、从文件积压中提取字段，以及无人值守的代码审查都能接受这种延迟，因为这些任务不需要等待即时回复。

真正有说服力的是隐私性。模型运行在您租用并控制的硬件上，不会有请求离开服务器，也不需要按 token 付费。即使速度只有每秒 3 个 token，对于受监管数据而言，这些优势仍然很有价值。您应当客观地将其与其他方案比较：自行托管前沿规模模型需要多一个数量级的硬件资源；而在这条成本曲线上，使用 CPU 运行 27B 模型是输出结果仍然值得阅读的最低成本方案。

如果这是您第一次安装 Ollama，在 VPS 上运行 Ollama 的完整教程介绍了本指南假设您已经完成的服务配置、HTTP API 和防火墙规则。不要将端口 11434 暴露到互联网。Ollama 本身不提供身份验证，因此任何能够访问该端口的对象都可以使用您的模型并读取您的提示词。

FAQ

Ollama 上有 Qwen 3.8 27B 模型吗？

没有。截至 2026 年 8 月 4 日，Ollama 库中没有 qwen3.8 命名空间。现有的 27B 标签是 qwen3.5:27b 和 qwen3.6:27b，二者都是 27.8 billion 参数 dense 模型的 Q4_K_M 构建版本。搜索词中的 3.8 几乎可以确定是把 27.8B 参数数量误记成了版本号。请查看 https://ollama.com/library/qwen3.6/tags 获取当前列表；如果要使用最新发布的 27B 模型，请拉取 qwen3.6:27b。不存在的标签会导致 Error: pull model manifest: file does not exist。

在 VPS 上运行 Qwen 27B 模型需要多少 RAM？

Q4_K_M 实际上至少需要 32 GB。权重占用 17 GB，操作系统约需 1.5 GB；在 f16 下，KV cache 每增加 4000 个上下文 token，约增加 1 GB。16 GB 方案根本无法容纳权重。swap 也无法解决问题，因为文件采用内存映射，内核会在生成每个 token 时重新从磁盘读取数据。64 GB 可为更长的上下文留出空间，也可以容纳 30 GB 的 Q8_0 权重。

27B 模型在 CPU 上每秒能生成多少个 token？

将内存带宽除以权重大小，再取其 50% 到 70%。双通道 DDR4-3200 VPS 的理论上限约为每秒 3 个 token，实际约为 2。双通道 DDR5-4800 服务器的理论上限约为 4.5 个 token，实际约为 3。通道数更多的服务器平台在理论上表现更好，但主机上的所有租户会共享内存带宽。因此，请使用 ollama run qwen3.6:27b --verbose 测量自己的性能，并读取 eval rate 行。

仅使用 CPU 的 VPS 应该选择 Q4 还是 Q8？

几乎所有情况下都应选择 Q4_K_M。Q8_0 占用 30 GB，而 Q4_K_M 占用 17 GB，因此 Q8_0 需要 64 GB 方案，并且每生成一个 token 几乎要传输两倍的内存数据，使每秒 token 数大约减半。对于大多数任务，27B 模型的 Q4_K_M 与 Q8_0 在质量上的差异很小。建议将 RAM 用于更长的上下文，因为这会改变模型能够执行的任务，而不只是改变措辞方式。

什么时候租用 GPU 比购买大内存 VPS 更便宜？

当 GPU 使用率较低，或者需要有人等待生成结果时。使用这些权重时，配备 24 GB 显存的 GPU 约可达到每秒 59 个 token，而典型 VPS 只有 2 或 3 个；GPU 只按实际运行小时计费。64 GB VPS 则整月计费，无论模型是否已加载。请计算每天实际生成 token 的小时数。每天少于 2 或 3 小时时，按小时租用 GPU 通常在速度和成本上都更有优势。持续运行的低优先级批处理任务则更适合使用常驻 VPS。