指南

作者： Matt Connor 2026-08-18 · 更新于 2026-08-21

VPS上运行GLM 5.2：可用模型与内存需求

Q: GLM 5.2 可以在 VPS 上本地运行吗？

不可以。截至 18 August 2026，Ollama 的库中只有 glm-5.2:cloud 形式的 GLM 5.2。该标签会在 Ollama 自有基础设施上运行，且必须先具备 ollama signin 才能工作。该模型有 756 billion 个参数，因此即使每个参数使用 four bits，权重本身也需要数百 GB，远超任何标准 VPS 套餐提供的容量。适合在租用服务器上运行、且提供可下载权重的 GLM 模型是 glm-4.7-flash。

Q: 如何测量自己的 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 会随输入长度增长，而生成速度不会增长。

Q: 为什么不应将 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。

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 亿个参数。7560 亿个参数按每个参数 4 bit 计算，权重约占 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

label

download_gb

q4_K_M

latest

q8_0

bf16

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 的 tag。

不存在适用于所有情况的固定倍数，因为 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 tag 升级到 32 GB 的 Q8 tag，是影响该数值的主要手段。Q4 会牺牲部分输出质量，具体程度取决于任务；结构化输出和较长的推理链受到的影响通常大于普通聊天。Q4、Q8 和 FP16 在实际使用中的差异值得在确定方案前阅读，因为在仅使用 CPU 的 VPS 上，量化选择通常决定模型能否运行。

仅使用 CPU 的 VPS 会发生什么

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

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

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

测量您自己的每秒令牌数

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

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

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

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

Ollama 默认使用 4096 个 token 的上下文。模型支持更大的上下文，glm-4.7-flash 可达 198K 个 token，但默认不会启用这么大的上下文，启用它也会带来额外开销。

KV 缓存会为每一层中的每个 token 保存一个键向量和一个值向量。允许的 token 数量增加时，KV 缓存会线性增长。上下文从 4096 增加到 32768 个 token 后，长度变为原来的 8 倍，因此 KV 缓存大约也会变为原来的 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=，说明 override 文件位于错误的目录，或者未执行 reload。下次加载模型后，ollama ps 应显示一个明显大于 4096 时的 SIZE。逐步增大该值，并在每次调整后监控这个数字。使用 num_ctx 设置 Ollama 的上下文长度介绍了该设置如何与 keep-alive 和并行请求交互；这两者都会使相同的开销进一步增加。

API 比服务器更便宜时

自行托管并不一定更便宜。对于这一系列模型，公开标价尤其清楚地说明了这一点。

ChartZ.ai published list prices per million tokens, checked 2026-08-18

label

usd_per_million_tokens

GLM-5.2 input

1.4

GLM-5.2 output

4.4

GLM-4.7-Flash input

GLM-4.7-Flash output

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 默认绑定到 127.0.0.1 的 11434 端口，因此只能从服务器本机访问。不要想当然，应在服务器上确认这一点。

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介绍了适用于中等配置服务器的相同安装流程；使用 Ollama 在 VPS 上自行托管 LLM 的通用指南涵盖了无论选择哪个模型都保持不变的部分。无论最终选择哪个模型，都应固定标签，在自己的方案上进行性能测量，并让端点仅监听 loopback。

FAQ

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

不可以。截至 18 August 2026，Ollama 的库中只有 glm-5.2:cloud 形式的 GLM 5.2。该标签会在 Ollama 自有基础设施上运行，且必须先具备 ollama signin 才能工作。该模型有 756 billion 个参数，因此即使每个参数使用 four bits，权重本身也需要数百 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。

#ollama#glm#self-hosted-llm #vps #quantization