SSD Nodes Learn Hosting plans →
指南 Matt Connor作者: Matt Connor · 更新于 2026-08-24

VPS上运行GLM:Ollama本地模型与内存需求

GLM 5.2在Ollama中仅支持云端运行。本文说明适合VPS的GLM-4.7-Flash标签、各量化版本的下载大小,以及实际所需内存。

能在 VPS 上运行 GLM 5.2 吗?

不能。在租用服务器前,应该先了解原因。截至 2026 年 8 月 18 日,Ollama 的模型库中,GLM 5.2 只有一个标签:glm-5.2:cloud。:cloud标签在 Ollama 的服务器上运行。您的服务器只发送提示词并接收生成的 token,因此模型权重不会写入您的磁盘。该模型有 7560 亿个参数。按每个参数 4 bit 计算,7560 亿个参数约需要 378 GB 权重空间;这还未计入上下文、激活值和操作系统。标准 VPS 方案都不会提供这么多内存。

适合在租用服务器上运行的 GLM 模型是 glm-4.7-flash。该模型提供可下载的权重,共有 4 个标签。它采用混合专家模型架构,也就是说,每个 token 只运行网络中的一小部分。Z.ai 将其描述为 30B-A3B:总参数量为 300 亿,每个 token 约激活 30 亿个参数。因此,本指南回答的是您可以实际执行的问题。固定标签,确定服务器规格,测量您自己的速度,并保持端点私有。

复制任何命令前,请先验证标签,包括本文中的命令。Ollama 的模型库可能随时变更,恕不另行通知。打开 glm-4.7-flash 标签列表,确认该标签仍然存在。如果有更新的 GLM 版本提供本地权重,请优先使用,并记录您实际测试的标签。

如果您仍然需要使用 GLM 5.2 本身,ollama run glm-5.2:cloud在 ollama signin后即可运行;从客户端角度看,它的行为与其他 Ollama 模型相同。但请明确您同意的事项:提示词会离开您的服务器。如果您选择自托管的原因是数据必须保留在自己的机器上,那么 :cloud标签无法满足这一要求。

有哪些 GLM 标签,以及应固定使用哪个标签

这里有 3 个官方 GLM 条目需要关注。glm-5.2 和 glm-5.1 仅支持云端。glm-4.7-flash 是本地版本,以下是其已发布的标签,以及 Ollama 为每个标签列出的下载大小。

Chartglm-4.7-flash tags in Ollama's library, checked 2026-08-18
The data behind this chart
[
  {
    "label": "q4_K_M",
    "download_gb": 19
  },
  {
    "label": "latest",
    "download_gb": 19
  },
  {
    "label": "q8_0",
    "download_gb": 32
  },
  {
    "label": "bf16",
    "download_gb": 60
  }
]

这些是库页面公布的数据,不是实测结果。latest 和 q4_K_M 都列为 19 GB,因此 latest 当前解析为 Q4 构建版本。重新发布后,这一结果可能随时变化。因此,绝不要在脚本或 Dockerfile 中直接写入不带标签的 ollama pull glm-4.7-flash。请明确指定量化类型。最大的标签 bf16 需要下载 60 GB,其中包含未量化的 bfloat16 权重。

在库中搜索时,还会返回名称中带斜杠的命名空间上传内容,例如 someuser/glm-5.2。斜杠表示该内容由某个用户帐户发布,因此它是社区重新上传的版本,而不是官方条目。没有人保证其中包含哪些权重。应将其视为从网上找到的、未经签名的二进制文件。

安装 Ollama 并拉取精确标签

Ollama 的 Linux 安装程序只需运行一条命令。

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

安装程序会创建一个由 ollama 用户运行的 systemd 服务。在拉取任何内容前,先确认该服务已启动。

systemctl status ollama --no-pager

Active: active (running) 表示 API 正在监听端口 11434。如果该单元不存在,说明安装程序回退为普通二进制安装。Ollama Linux 文档提供了手动创建服务文件的方法。

glm-4.7-flash 页面列出了 Ollama 的最低版本要求。旧版二进制文件不会只是运行模型较慢,而是会拒绝运行模型:拉取会失败,并显示模型需要更新版本的 Ollama。重新运行安装脚本即可升级。截至 18 August 2026,当前版本为 0.32.14,已高于该最低版本要求。

现在按名称拉取一个标签。

ollama pull glm-4.7-flash:q4_K_M
ollama ls

ollama ls 应列出 glm-4.7-flash:q4_K_M,其大小应接近已发布的 19 GB。拉取中途失败不会留下可运行的模型,因此请重新运行相同的命令。在小型套餐上,拉取失败最常见的原因是磁盘已满,而不是网络问题,因为模型会写入根文件系统中的 /usr/share/ollama/.ollama/models。开始前使用 df -h /usr/share/ollama 检查。

每种量化需要多少 RAM?

先将下载大小作为最低需求,再在此基础上增加内存。权重必须常驻内存。除此之外,还需要 KV cache(键值缓存),即运行时用于记住对话中已有 token 的内存,以及计算缓冲区和操作系统占用的内存。RAM 恰好为 19 GB 的服务器无法运行 19 GB 标签对应的模型。

不存在适用于所有人的固定倍数,因为 KV cache 会随允许的上下文长度增长,其余部分也会随运行时版本变化。因此应进行测量,而不是猜测。使用一个简单提示词加载模型,然后读取服务器预留的内存。

ollama run glm-4.7-flash:q4_K_M "Reply with the single word: ready"
ollama ps

ollama ps 会显示已加载的模型,其中包括 SIZE 列和 PROCESSOR 列。SIZE 是运行时实际预留的内存,这就是应与规划值比较的数字。PROCESSOR 会告诉您计算发生在哪里,因此 100% CPU 表示完全未使用 GPU。

模型无法装入内存时,故障通常不会直接显示,并且有两种表现。启用 swap 时,加载看似成功,但生成速度会变得极慢,因为每生成一个 token,页面都要在磁盘和 RAM 之间交换。未启用 swap 时,进程会直接被终止,而 journalctl -k | grep -i "out of memory" 会显示内核的 Out of memory: Killed process 行,其中会指出 ollama。请同时检查这两项,因为它们都不会在您输入命令的终端中打印有用信息。

从 19 GB 的 Q4 标签升级到 32 GB 的 Q8 标签,是影响该数值的主要手段。Q4 会牺牲一部分输出质量,具体程度取决于任务;结构化输出和较长的推理链受到的影响通常大于普通聊天。Q4、Q8 和 FP16 在实际使用中的差异 值得您在确定方案前阅读,因为在仅使用 CPU 的 VPS 上,量化方式通常决定模型能否运行。

仅使用 CPU 的 VPS 会发生什么

大多数 VPS 方案不提供 GPU,Ollama 会直接使用 CPU 运行模型,也不会发出警告。结果是否可用,取决于工作负载和您的耐心。

混合专家架构有助于提高速度。对于每个 token,实际只使用约 3 billion 个参数,而不是使用全部 30 billion 个参数,因此每个 token 所需的计算量远小于稠密 30B 模型。但内存需求不会减少。每个专家都必须常驻内存,因为路由器可能为下一个 token 选择其中任意一个专家。因此,仅使用 CPU 的服务器运行 Q4 标签仍需要完整的 19 GB 或更多内存,其吞吐量主要取决于内存带宽,而不是 CPU 时钟频率。

这会带来一个实际影响:即使两个方案的核心数和内存大小相同,生成速度也可能明显不同,因为它们的内存子系统不同。共享方案还会引入第二个变量,因为嘈杂邻居导致的 CPU steal time会表现为每秒生成的 token 数,并且这一数值会随时间变化。这就是其他人公布的数字无法预测您的实际结果的原因,也是下一节提供测量方法而不是结果表格的原因。

自行测量每秒生成的 token 数

Ollama 的 generate 端点会在最终 JSON 对象中返回计时字段。将生成的 token 数除以生成耗时,即可得到您在当前套餐和提示词下的实际速度。

sudo apt install -y jq
curl -s http://localhost:11434/api/generate -d '{
  "model": "glm-4.7-flash:q4_K_M",
  "prompt": "Write a 200 word explanation of how TCP congestion control works.",
  "stream": false,
  "options": {"num_ctx": 8192}
}' | jq '{
  tokens: .eval_count,
  tokens_per_second: (.eval_count / .eval_duration * 1e9),
  prompt_seconds: (.prompt_eval_duration / 1e9),
  load_seconds: (.load_duration / 1e9)
}'

eval_count表示生成的 token 数,eval_duration表示生成这些 token 所用的纳秒数,因此 eval_count / eval_duration * 1e9表示每秒生成的 token 数。prompt_eval_duration表示读取提示词所用的时间,也就是用户在第一个 token 出现前实际感受到的等待时间。load_duration表示从磁盘加载模型所用的时间,因此重启后的首次调用通常较大,下一次调用则接近于零。

连续运行 3 次,并保留第 2 次和第 3 次的结果,因为第 1 次包含模型加载时间。然后使用长得多的提示词再次运行,因为提示词处理时间会随输入长度增加,而生成速度不会变化。将这些数字记录在套餐名称和量化方式旁边。这份记录比您读到的任何基准测试都更有参考价值,因为它是在您付费使用的硬件上测得的。

上下文长度如何成倍增加内存占用

Ollama 默认使用 4096 个 token 的上下文。模型支持更大的上下文,glm-4.7-flash 可达 198K 个 token,但默认不会启用这么大的上下文,启用它也不是没有代价。

KV cache 会为每一层中的每个 token 保存一个 key 向量和一个 value 向量。其大小会随允许的 token 数量线性增长。将上下文从 4096 个 token 增加到 32768 个 token,相当于将上下文扩大 8 倍,因此 KV cache 大约也会扩大 8 倍。对于内存只够容纳模型权重的服务器,这部分额外分配会直接导致系统开始使用 swap。这就是为什么一台处理短提示词正常的机器,在有人粘贴长文档后会突然变得非常慢。

可以在请求的 options 对象中使用 num_ctx 设置该值,如上面的 curl 命令所示;也可以修改服务器默认值。

sudo install -d -m 755 /etc/systemd/system/ollama.service.d
printf '[Service]\nEnvironment="OLLAMA_CONTEXT_LENGTH=16384"\n' \
  | sudo tee /etc/systemd/system/ollama.service.d/override.conf
sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment

最后一条命令应输出 OLLAMA_CONTEXT_LENGTH 的值。如果输出空的 Environment=,说明覆盖文件位于错误的目录,或者未执行重新加载。下次加载模型后,ollama ps 应显示一个明显大于上下文为 4096 时的 SIZE。逐步提高该值,并在每次调整后监控这个数字。使用 num_ctx 设置 Ollama 的上下文长度介绍了该设置与 keep-alive 及并行请求的交互方式;这两者都会使相同的成本进一步增加。如果服务器将供多个客户端使用,应同时确定并发限制和上下文长度,因为每个并行槽位都有自己的 KV cache,而队列设置决定第二个请求是等待,还是直接被拒绝。

API 比服务器更便宜时

自行托管并不一定更便宜。对于这一系列模型,已公布的价格尤其清楚地说明了这一点。

ChartZ.ai published list prices per million tokens, checked 2026-08-18
The data behind this chart
[
  {
    "label": "GLM-5.2 input",
    "usd_per_million_tokens": 1.4
  },
  {
    "label": "GLM-5.2 output",
    "usd_per_million_tokens": 4.4
  },
  {
    "label": "GLM-4.7-Flash input",
    "usd_per_million_tokens": 0
  },
  {
    "label": "GLM-4.7-Flash output",
    "usd_per_million_tokens": 0
  }
]

截至 18 August 2026,Z.ai 列出的 GLM-5.2 价格为每百万个输入 token $1.4,每百万个输出 token $4.4。该网站列出的 GLM-4.7-Flash 价格为两个方向均为每百万个 token $0。本指南在本地运行的就是这个模型。这些是公布价格,并且可能发生变化,因此在据此制定预算前,请查看当前价格页面。

因此,目前自行托管的成本理由 glm-4.7-flash 并不充分。配备足够 RAM 的 VPS 每月都需要实际支出,而模型发布方免费提供同一个模型。自行运行所带来的优势不同:您的提示词保留在您控制的机器上,模型版本也不会变化,除非您主动更换。这些都是自行托管的合理理由。但对于这个模型,在当前价格下,成本不是其中之一。

如果您需要的模型并不免费,或者法律规定您的数据不能离开自有网络,成本计算结果就会反转。GPU VPS 与 API token 的盈亏平衡点会逐项列出变量并完成计算。如果您还在选择机器,VPS 每月的实际成本则是计算的另一部分。

保持端点仅监听 localhost

这是人们最容易跳过的一步,也是最重要的一步。

Ollama 默认在端口 11434 上绑定 127.0.0.1,因此只能从服务器本机访问。请在您的服务器上确认这一点,不要直接假设配置正确。

ss -ltnp | grep 11434

您应看到 127.0.0.1:11434。如果看到 0.0.0.0:11434 或 *:11434,则表示 API 正在所有网络接口上监听,包括公网接口。

这一点很重要,因为 Ollama 的 API 没有身份验证机制。它没有密码、令牌或允许列表。任何能够访问端口 11434 的人,都可以列出您的模型、使用您付费提供的硬件运行生成任务、不断将新模型下载到您的磁盘直至磁盘占满,还可以删除现有模型。端口 11434 是固定且广为人知的端口,因此扫描器会很快发现开放的端口。

不要设置 OLLAMA_HOST=0.0.0.0。许多教程建议在笔记本电脑上的客户端无法连接时使用它,但这是错误的解决方法。请改用端口转发。

ssh -N -L 11434:127.0.0.1:11434 you@your-server

该命令会通过 SSH 将笔记本电脑上的端口 11434 映射到服务器的环回地址。因此,配置为 http://localhost:11434 的客户端无需修改,同时不会暴露新的网络接口。对于多名用户或多台机器,请将服务器加入专用隧道网络,并让 Ollama 绑定到隧道地址,绝不要绑定到 0.0.0.0。

请从服务器以外的位置进行验证。在 SSH 隧道关闭的情况下,从笔记本电脑执行:

curl -m 5 http://your-server-ip:11434/api/tags

curl: (28) Connection timed out 或 curl: (7) Failed to connect 才是正确结果。如果返回包含您的模型的 JSON 列表,说明该端口已对互联网开放,需要立即修复。云服务提供商的网络防火墙与服务器上运行的防火墙是两个独立的控制层,因此请同时检查两者。关于 VPS 托管是否安全这一更广泛的问题介绍了长期运行服务器所需的其他基线安全措施。

如果 glm-4.7-flash 仍然太大

Q4 标签无法适配您的方案时,应改用更小的模型,而不是缩小上下文。为了装下模型而减少上下文,只会得到一个能够加载、但在第一个长提示词处就失败的模型。在 VPS 上运行 8B 和 27B 版本的 Qwen 3介绍了相同的安装流程,并适用于配置较低的服务器;在 VPS 上使用 Ollama 自托管 LLM 的通用指南涵盖了无论选择哪个模型都相同的部分。无论最终选择哪个模型,都应固定标签,在您自己的方案上进行测试,并让端点仅监听 loopback。

FAQ

GLM 5.2 可以在 VPS 上本地运行吗?

不可以。截至 2026 年 8 月 18 日,Ollama 库中的 GLM 5.2 只有 glm-5.2:cloud,该标签会在 Ollama 自有基础设施上运行,并且需要 ollama signin 后才能工作。该模型有 7560 亿个参数,因此即使每个参数使用 4 位,权重本身也需要数百 GB,远超任何标准 VPS 套餐的容量。带有可下载权重且适合租用服务器的 GLM 模型是 glm-4.7-flash。

glm-4.7-flash 需要多少 RAM?

将标签的下载大小视为最低需求,并在此基础上为 KV cache 和操作系统预留空间。Ollama 列出的 Q4 标签大小为 19 GB,Q8 标签大小为 32 GB,bfloat16 标签大小为 60 GB。不存在适用于所有环境的固定倍数,因为 KV cache 会随设置的上下文长度增长。加载模型,运行 ollama ps,然后读取 SIZE 列,以获取该服务器上的实际数值。

如何在自己的 VPS 上测量每秒处理的 token 数?

向 http://localhost:11434/api/generate 发送一个带有 "stream": false 的请求,然后从响应中读取 eval_count 和 eval_duration。每秒处理的 token 数为 eval_count / eval_duration * 1e9,因为 eval_duration 的单位是纳秒。丢弃第一次运行的结果,因为其中的 load_duration 包含了从磁盘读取权重所需的时间。还应使用较长的提示词重复测试,因为 prompt_eval_duration 会随输入长度增长,而生成速度不会增长。

为什么不应将 OLLAMA_HOST 设置为 0.0.0.0?

因为 Ollama API 没有身份验证,将其绑定到 0.0.0.0 会在公网暴露一个未经身份验证的端点。任何能访问 11434 端口的人都可以使用你的硬件生成内容,并更改已安装的模型。保持默认的 127.0.0.1 绑定,使用 ss -ltnp | grep 11434 检查绑定地址,然后通过类似 ssh -N -L 11434:127.0.0.1:11434 you@your-server 的 SSH 隧道从笔记本电脑访问 API。