如何在无GPU VPS上运行Qwen3.6 27B Ollama

能否在没有 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 上运行，但速度较慢。27B dense 模型在 Q4 量化下，仅模型权重就需要约 17 GB RAM，还未计算上下文占用。这意味着 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 云端提供服务的 GLM 5.2 容易让人困惑的地方。

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，以及一组采用 MoE（专家混合）架构的 35b-a3b 标签。这些模型在 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，因为文件还包含元数据和全精度 embedding 表。

此模型没有发布 Q5_K_M 标签，因此 19.8 GB 这一行是按该格式通常使用的 5.7 bits per weight 计算的，不是实测值。Q8_0 的大小几乎是 Q4 的两倍，达到 30 GB。在仅使用 CPU 的服务器上，这种翻倍会使每个 token 的内存流量增加一倍，因此 tokens per second 也大致减半。仅基于这一点，Q4_K_M 就是这里的正确默认选项。如果您想了解这一选择对质量的影响，而不只是内存占用，Q4、Q8 和 fp16 的详细对比可以说明输出从哪里开始出现明显劣化。

上下文增长时 KV 缓存的成本

权重是固定成本。KV 缓存（键和值缓存，即模型为已经处理的每个 token 保留的注意力状态）会随上下文长度线性增长。大多数情况下，RAM 不足就是因为 KV 缓存占满了内存。

[
  {
    "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 在近期同等规模的稠密模型中采用了相同的结构：64 个层、GQA（分组查询注意力）下的 8 个键/值头，以及 128 的头维度。在 f16 下，每个 token 占用 256 KiB。因此，32k tokens 需要 8 GB，128k tokens 需要 32 GB。不要只根据这些计算结果判断自己的机器。加载模型，然后读取 ollama ps 的 SIZE 列。该列会将权重、缓存和额外开销合并为一个数值。

这就是模型卡上的 256K 上下文更像宣传参数，而不是实际规划的原因。在 f16 下填满整个上下文窗口，除了权重外还需要 64 GB 缓存，而这台机器已经为权重占用了 17 GB。Ollama 默认不会为你提供完整窗口。它会加载一个小得多的窗口，你可以通过 OLLAMA_CONTEXT_LENGTH 有意调大它。这个服务器级变量并不是唯一的控制项；为单个请求设置 num_ctx，可以让其他请求继续使用较低的默认值，同时为一个长任务提供更大的窗口。请分步调高该值，并在每次修改后检查 ollama ps。

有两个设置可以将缓存减少一半或更多。OLLAMA_KV_CACHE_TYPE=q8_0 会将缓存存储为 8 位，而不是 16 位，使 32k tokens 的缓存从 8 GB 降至 4 GB。它需要 flash attention，因此还要设置 OLLAMA_FLASH_ATTENTION=1，并在 ollama ps 中确认缓存确实减少，不要假设设置已经生效。OLLAMA_NUM_PARALLEL=1 同样重要。Ollama 可以同时处理多个请求，每个槽位都会获得一部分独立的上下文空间。因此，如果保持默认并行度，缓存预算会被静默地倍增。如果这台机器要供多人使用，问题通常就从这里开始；自托管模型可以服务的并发用户数，很早就由缓存槽位和队列深度决定，而不是由核心数量决定。

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 KV 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。在购买 64 GB RAM 以运行 Q8 前，应明确自己获得的是什么：输出质量略有提升，但速度降低一半，而且运行环境本来就很慢。对几乎所有人来说，使用更长上下文的 Q4 是更好的取舍。

VPS 上的 CPU 推理速度有多快？

使用稠密模型生成 1 个 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 的 VPS 并不拥有 12 个专用内存通道。以 GPU 为重点的指南通常完全忽略这一点。这也解释了为什么在运行同一个模型时，两个 vCPU 数相同的 VPS 套餐，速度可能相差 3 倍。

更多 vCPU 也会因为同样的原因很早就不再提升性能。当核心请求数据的速度超过内存控制器的供给能力时，额外线程只会增加调度开销，不会带来其他收益。将 OLLAMA_NUM_THREAD 设置为物理核心数，进行测试，然后再尝试设置为该数值的一半。在许多共享套餐上，较低的设置反而更快。

Prompt 处理方式不同。Prefill 是在生成第一个 token 之前处理输入的阶段，主要受计算能力限制，而不是受内存带宽限制，因此会随核心数增加而扩展。实际表现是：较大的 Prompt 会导致输出开始前出现较长暂停，之后进入上文所述的稳定低速率。使用 --verbose 分别测量这两个阶段；它会为每个请求输出 prompt eval rate 和 eval rate。

如果稠密 27B 模型速度确实太慢，请先查看 qwen3.6:35b-a3b 标签，不要立即放弃 CPU。这些标签每个 token 只激活约 30 亿个参数，而不是全部 278 亿个参数。因此，即使磁盘上的文件更大，每个 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 tokens/s。当前的数据中心显卡可达到 197。这不是通过调整线程数就能弥补的差距。该显卡的内存带宽为 1008 GB/s，而 VPS 只有几十 GB/s。

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

成本比较没有看上去那么简单。无论模型是否已加载，64 GB VPS 都会按整个月的每小时计费；GPU 实例则只对实际运行的时长计费。如果实际使用时间为每天 2 小时，租用 GPU 可能同时更快、更便宜。先计算使用率，再比较价格。选择带 GPU 的 VPS介绍了应检查实例本身的哪些方面；而在 GPU 上处理并发请求时，vLLM 在并发 GPU 请求场景下会超过 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 权重，耗时可能超过请求本身。默认空闲超时为 5 分钟。对于项目之间存在间隔的批处理队列，这个时长过短，会反复承担加载成本；保留模型常驻的选项同时涵盖每个请求的 keep_alive 字段，以及让该设置在重启后继续生效的方法。

模型加载期间，在第二个终端中检查内存占用。

ollama ps

SIZE 列显示包括 KV cache 在内的实际内存占用。该数值应接近权重占用，加上 KV 图表中对应上下文长度的那一行。上下文长度为 8192 个 token、cache 使用 8-bit 时，预计会在权重之外额外占用约 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 足够的计算机上，如果速度低于每秒 1 个 token，通常说明发生了分页，而不是计算能力不足。生成内容时运行 vmstat 1。si 或 so 列为非零表示内核正在进行交换；解决方法是减少上下文长度或减少已加载的模型。wa 持续较高且没有交换活动，表示内存映射的权重正在从磁盘重复读取，也就是说内存实际上不足以容纳它们。

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

CPU-only 27B 实际适合做什么

根据实际数据设定预期，不要寄希望于理想情况。每秒生成 2 到 4 个 token 时，生成 500 个 token 的回答需要 2 到 4 分钟。这种速度不适合聊天，但完全可以用于队列任务。会先进行推理再回复的模型会让耗时更长，因为隐藏的推理 token 也会以同样的低速生成。因此，根据任务调整推理力度是无需更换模型即可缩短回复时间的少数方法之一。文档摘要、批量添加标签、从文件积压中提取字段，以及无人值守的代码审查都能接受这种速度，因为没有人在等待回复。编码辅助正好处于这个边界上。因此，让编码代理使用您托管的模型适合处理提交消息和测试脚手架等后台任务，不适合需要您坐等的行内建议。

隐私才是使用本地模型的主要理由。模型运行在您租用并控制的硬件上，没有请求离开服务器，也没有按 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 参数稠密模型的 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 tokens per second，实际约为 2。双通道 DDR5-4800 服务器的理论上限约为 4.5，实际约为 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，因此前者需要 64 GB 方案，并且每个 token 需要传输近两倍的内存数据，这会使每秒 token 数大致减半。对于大多数任务，27B 模型的 Q4_K_M 与 Q8_0 在质量上的差异很小。应将 RAM 用于更长的上下文，因为这会改变模型能完成的任务，而不只是改变措辞方式。

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

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