SSD Nodes Learn 🎉 VPS $5.50/月起
指南 Matt Connor作者： Matt Connor

Muse Glimmer 30B VPS 内存和磁盘要求

Muse Glimmer 标签大小为17GB至59GB。了解下载所需磁盘、上下文带来的额外内存，以及仅用CPU在Linux VPS上运行30B模型的实际成本。

Muse Glimmer 对 VPS 的要求

Muse Glimmer 可在普通 Linux VPS 上运行，无需 GPU。选择的标签决定它是否适合当前内存。Meta Superintelligence Labs 于 10 August 2026 以 Apache 2.0 许可证发布了该模型：模型包含 30 billion 个参数，支持 128K 上下文窗口，并配备专用的 1.8B 参数感知编码器，因此可以同时读取图像和文本。Meta 将其定位为持续运行的本地代理，而不是聊天模型；您可以针对每个请求设置推理强度。

截至 16 August 2026，已发布的 Ollama 标签对应的模型大小范围为 17 GB 到 59 GB。这一范围决定了全部容量要求。默认标签列出的大小约为 18 GB，因此，合理的最低配置应具有明显多于 18 GB 的可用 RAM。下载所需的磁盘空间和上下文窗口所需的内存还需额外计算。

应拉取哪个 muse-glimmer 标签？

ChartPublished muse-glimmer tag sizes on 16 August 2026 (Linux tags only)
The data behind this chart
[
  {
    "label": "30b-nvfp4",
    "size_gb": 17
  },
  {
    "label": "30b (default)",
    "size_gb": 18
  },
  {
    "label": "30b-q4_K_M",
    "size_gb": 18
  },
  {
    "label": "30b-q4_K_M-dflash",
    "size_gb": 20
  },
  {
    "label": "30b-nvfp4-dflash",
    "size_gb": 21
  },
  {
    "label": "30b-q8_0",
    "size_gb": 31
  },
  {
    "label": "30b-mxfp8",
    "size_gb": 33
  },
  {
    "label": "30b-q8_0-dflash",
    "size_gb": 33
  },
  {
    "label": "30b-mxfp8-dflash",
    "size_gb": 35
  },
  {
    "label": "30b-bf16",
    "size_gb": 57
  },
  {
    "label": "30b-bf16-dflash",
    "size_gb": 59
  }
]

Ollama 为此模型列出了 11 个非 Apple 构建的标签。它们都包含相同的 300 亿个权重，但使用了不同的数值精度。显示的大小就是需要下载的数据量，也是添加上下文前大致需要占用的内存量。

两个 4-bit 构建较小：30b-nvfp4 为 17 GB，30b-q4_K_M 为 18 GB。默认的 30b 标签所列大小与 q4_K_M 构建相同。8-bit 构建 30b-q8_0 和 30b-mxfp8 接近 31 GB。30b-bf16 是未量化的 16-bit 版本，大小为 57 GB。对大多数租用服务器来说，这需要的 RAM 超出其可用容量，而为个人项目租用这样的服务器通常也不划算。

-dflash 标签是带 DFlash 支持的相同构建，每个标签列出的大小都大于对应的普通版本。Ollama 将 DFlash 描述为一项加速功能，并在 Apple Silicon 和桌面 GPU 上演示了该功能。在仅使用 CPU 的 VPS 上，为了一个在其他硬件上测试的功能而承担额外的内存占用并不划算，因此应先使用普通标签，并且一次只改动一项设置。

除非有明确原因，否则应从 4-bit 开始。对每个生成的 token，CPU 从 4-bit 切换到 8-bit 后需要读取的字节数大致会翻倍，因此吞吐量会下降，而内存使用量会上升。q4、q8 和 fp16 量化的实际代价将详细介绍这种取舍；对于 CPU 服务器，简而言之，4-bit 构建是唯一值得优先尝试的版本。

为什么 MLX 标签在 Linux 服务器上不起作用

MLX 是 Apple 的数组框架，Ollama 的 MLX 引擎是其 Apple Silicon 后端。名称中包含 mlx 的任何标签都是为该引擎和相应硬件构建的。在 x86 Linux VPS 上，这些标签对应数十 GB 的下载内容，无法运行，只会占用磁盘空间。公告中在 Mac 上测得的速度数据属于这些标签，因此也不能代表您的服务器。查看模型页面上的标签列表时，先过滤掉所有 mlx 名称，再根据剩余内容评估大小。

实际需要多少 RAM 和磁盘空间？

有两部分会占用内存，只有一部分取决于标签大小。权重由所拉取的标签固定。KV cache 是模型为当前对话保留的每个 token 状态，会随配置的上下文长度增长。Ollama 官方文档指出，并行处理请求时，上下文内存会乘以同时处理的请求数。因此，同时回答两个代理的服务器，比只回答一个代理的同一台服务器需要更多内存。

不要采用任何指南中的 RAM 数值，包括本指南中的数值。拉取标签，向模型发送一个提示词，然后在模型仍驻留内存时运行以下两个命令。

ollama ps
free -h

ollama ps 显示当前已加载的内容，以及任务如何在 CPU 和 GPU 之间分配。free -h 显示剩余资源。这两条命令在您自己的服务器上输出的结果，比任何已发布的对照表都更可靠，因为其中已经包含您的上下文设置、量化方式，以及服务器正在运行的其他所有内容。

磁盘空间更容易计算。Ollama 在 Linux 上将模型存储在 /usr/share/ollama/.ollama/models 下。大多数 VPS 镜像会将该路径放在根文件系统中。40GB 的根卷无法容纳大小为 57 GB 的 bf16 构建，也无法同时容纳两个 8-bit 标签。拉取任何内容前，先将存储目录移动到已挂载的卷。

sudo systemctl edit ollama
[Service]
Environment="OLLAMA_MODELS=/mnt/models"
sudo mkdir -p /mnt/models
sudo chown -R ollama:ollama /mnt/models
sudo systemctl daemon-reload
sudo systemctl restart ollama

ollama 用户必须拥有该目录，因为服务以 ollama 身份运行，并以该身份向目录写入 blob。如果拉取因权限失败，原因会显示在 journalctl -u ollama -n 50 中。

关于 swap，需要明确一点：swap 不能让您运行更大的标签。模型每生成一个 token 都要访问权重，因此存放在 swap 中的权重会被反复从磁盘读回；vmstat 1 会显示 si 和 so 列持续繁忙，输出速度会降至每个 token 数秒。保留一个较小的 swap 文件，用于防止 OOM killer 终止进程。应根据实际需要运行的标签为 RAM 配置容量。

安装 Ollama 并固定命名标签

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

安装脚本会设置 systemd 服务，因此服务器重启后该服务会自动恢复。如果您不希望将其作为由 root 管理的系统服务运行，请参阅在 Podman 下以无 root 方式运行 Ollama。然后拉取一个明确的标签。

ollama pull muse-glimmer:30b
ollama list

请自行读取 ollama list 中的大小列，并将其与模型页面上的当前标签列表进行比较。发布的标签可能会新增、重命名或删除，指南中的大小只是某一天的快照。

切勿在您依赖的服务器上写入 ollama pull muse-glimmer。不带标签的模型名称会解析为 latest 标签，而 latest 是发布者可以指向其他构建的指针。随后执行例行 pull 时，模型会在您的代理下方被替换，内存需求和行为也会改变，而且日志中不会对此作出提示。请在脚本、unit 文件和代理配置中写明标签。在 VPS 上使用 Ollama 自托管 LLM介绍其余服务器设置。

不使用 GPU 可以运行 Muse Glimmer 吗？

可以，但必须明确它的性能上限。生成一个 token 需要从内存中读取模型权重，因此速度取决于内存带宽，而不是套餐标称的 vCPU 数量。核心数超过几个后，继续增加核心带来的收益非常有限。在共享 VPS 上，内存带宽还要与主机上的其他租户共享，因此 30B 模型使用 4-bit 量化时，每秒只能生成少量 token。

不要直接接受任何人给出的数值，包括我的数值。在自己的服务器上测量每秒生成的 token 数，再根据实际结果做决定。

这会明显影响模型适合执行的任务类型。交互式聊天体验较差，因为您的阅读速度快于服务器的输出速度，而且每次回复开始前都要长时间等待。后台代理任务则没有问题，因为无人值守运行十分钟的任务并不在意速度较慢。Meta 对该模型的描述正是针对第二类工作负载。

如果需要交互式速度，诚实的选择只有 GPU 或托管 API。在租用任何资源前，请先计算 GPU VPS 与 API token 的盈亏平衡点；了解 GPU VPS 实际能提供什么介绍了您购买的内容。若要进一步了解指定服务器可以运行哪些模型，请从了解哪些模型可以自行托管开始；在 VPS 上运行大小相近的 Qwen 模型是这一规模类别中最接近的对比。

为什么在远未达到 128K tokens 前就忘记内容？

因为 Ollama 的默认上下文窗口是 4096 tokens，与模型支持的上限无关。截至 2026 年 8 月，Ollama 自己的 FAQ 仍采用这一默认值。标签标注支持 128K，但除非另行设置，服务器只会向模型提供 4096 tokens。因此，较长的 agent 对话记录会丢失早期轮次，模型看起来就像失去了记忆。

在服务器上设置上下文长度，使其应用于每个请求：

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

在交互式会话中，/set parameter num_ctx 32768 只会修改当前会话的设置。通过 API 时，在请求选项中发送 num_ctx。

每增加一个上下文 token，都会在模型权重之外额外占用内存。如果主机只按模型权重所需的内存配置，却请求完整的 128K，上下文加载可能失败，或回退到更慢的运行方式。请分阶段逐步提高，并在每个阶段后运行 ollama ps。Ollama 中 num_ctx 和上下文长度的工作方式详细说明了相关计算。

推理强度：low、medium、high 和 xhigh

Meta 为 Muse Glimmer 定义了 4 个推理强度级别，从 low 到 xhigh，并建议在复杂编码和代理任务中使用较高的两个级别。在 Ollama 中，这通过 think 参数控制。可在命令行中使用 --think=，也可在 API 请求体中发送 think。

ollama run muse-glimmer:30b --think=high "Summarise the changes in /tmp/patch.diff"

在交互式会话中，/set think 和 /set nothink 可切换该设置。Ollama 文档说明，大多数模型接受布尔值或 low、medium、high 等级别；有些模型还接受 max，表示可用的最高级别。该模型具体接受哪些字符串，应以其模型页面为准，不要自行猜测。将其接入代理前，先手动尝试一个值。

在仅使用 CPU 的机器上，这个设置会明显影响性能。较高的强度会在回答出现第一个词之前生成更多推理 token，而生成一个推理 token 所需的实际耗时与生成一个回答 token 相同。常规任务应保持 low 设置。

让模型始终驻留，以支持持续运行的代理

Ollama 默认会在模型空闲五分钟后将其卸载。对于每十分钟运行一次的代理，这意味着每次运行都要从磁盘加载完整的 18 GB 模型。在使用网络连接存储的 VPS 上，加载过程并不快。可以将模型固定在内存中。

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"

负值会让模型一直驻留，直到其他操作将其卸载；API 请求中的 keep_alive 可针对单次调用覆盖服务器默认值。代价很明确：无任务运行时，模型仍会占用 RAM。因此，这项设置适用于专门运行该代理的服务器。让 Ollama 模型保持加载介绍了相关变体。

连接编码代理

Ollama 在 http://127.0.0.1:11434/v1 提供兼容 OpenAI 的 API，因此大多数代理工具只需配置基础 URL 和任意非空 API 密钥即可连接。Ollama 的 Muse Glimmer 页面还记录了一个启动快捷方式，可通过一条命令将受支持的代理连接到本地模型；在那里也应固定模型标签。

ollama launch claude --model muse-glimmer:30b

代理会发送很大的提示。文件内容、工具输出和不断增长的对话记录都会作为输入令牌传入。在 CPU 服务器上，生成尚未开始前，提示处理就可能成为主要瓶颈。将上下文设置保持在任务允许的最小值。将编码代理连接到 Ollama介绍客户端配置，在 VPS 上运行编码代理介绍代理所在的服务器，控制 VPS 上代理的成本介绍代理全天运行时的情况。

图像输入的工作方式相同。Ollama API 使用消息的 images 字段接收图像，因此纯文本客户端永远不会发送图像，无论感知编码器的能力多强。

不要开放端口 11434

Ollama API 没有身份验证。设置 OLLAMA_HOST=0.0.0.0:11434 以便从笔记本电脑访问，会将一个未经身份验证的模型运行器暴露在公网中。任何发现该服务的人都可以将模型加载到您的磁盘，并读取代理通过它发送的所有内容。应让它继续绑定到 localhost，改用隧道访问。

ssh -N -L 11434:127.0.0.1:11434 user@your-vps

保护 Ollama API 端点介绍了正确的选项，其中包括要求提供凭据的反向代理。

常见故障及现象

拉取中途停止。 磁盘空间不足。对模型目录运行 df -h。57 GB 的 bf16 构建无法放入 40GB 的根卷，两个 8-bit 标签并存也同样无法放入。

模型加载后进程退出。 内存不足。dmesg -T 记录内核 OOM killer 选择进程的过程，journalctl -u ollama -n 100 显示服务端对同一事件的记录。解决方法是使用更小的标签或更小的 num_ctx。增加 swap 无法解决问题。

运行速度为每个 token 数秒。 运行 vmstat 1 并监控 si 和 so 列。持续的 swap 活动表示权重无法全部放入 RAM，系统运行期间正在从磁盘反复读取权重。

上周可用的标签现在消失了。 标签列表会变化。重新查看模型页面，固定当前可用的标签，并将标签名称记录在便于再次查找的位置。

拉取前自行重新核对大小

图表中的大小取自模型标签页面在 16 August 2026 发布的信息，已发布的标签列表并不保证长期不变。请在模型页面查看当前列表，然后确认实际写入磁盘的内容：

ollama pull muse-glimmer:30b
ollama list
sudo du -sh /usr/share/ollama/.ollama/models

Ollama 会将模型层存储为共享 blob，因此共享同一层的两个标签不会占用两倍磁盘空间。将 du 报告的大小与已发布大小进行比较，并按两者中的较大值规划磁盘空间。

FAQ

Muse Glimmer 在 VPS 上需要多少 RAM？

从标签大小开始，再加上上下文窗口。2026 年 8 月 16 日，默认标签列出的大小约为 18 GB，因此 16GB 的主机完全无法容纳它，24GB 的主机加载后也几乎没有空间留给上下文。请将此数值视为起点，而不是最终答案。拉取标签并加载一次，然后在您自己的主机上运行 ollama ps 和 free -h，查看实际数值。更长的上下文和并行请求都会在权重之外继续增加内存占用。

不使用 GPU 也能运行 Muse Glimmer 吗？

可以。它可以仅使用 CPU 在 VPS 上加载并生成响应。生成速度主要受内存带宽限制，而不是核心数量限制。在共享主机上，内存带宽还会被其他用户共享，因此使用 4-bit 时，预计每秒只能生成少量 token。这足以用于无人值守的后台代理任务，但不适合交互式聊天。在请求期间运行 ollama ps，查看处理器列，以确认任务实际运行在哪里。

MLX 标签在 Linux VPS 上有用吗？

没有。名称中包含 mlx 的每个标签都是为 Ollama 的 MLX 引擎构建的，MLX 是其 Apple Silicon 后端。在 x86 Linux 服务器上，这些标签虽然下载量很大，但无法运行。请使用普通的 30b 标签，或其他不含 MLX 的标签，并忽略与 MLX 构建相关的 Apple 硬件基准测试。

为什么模型在达到 128K token 之前很早就遗忘内容？

因为无论模型支持多大的上下文窗口，Ollama 的默认上下文窗口都是 4096 token，因此服务器会在模型看到长对话之前将其截断。在服务器上设置 OLLAMA_CONTEXT_LENGTH，或为单个会话设置 /set parameter num_ctx，也可以在 API 请求选项中发送 num_ctx。上下文窗口增大后，内存占用也会增加，因此请逐步提高该值，并在每次调整后检查 ollama ps。

应该固定标签，还是直接使用 latest？

请固定标签。不带标签的 muse-glimmer 会解析为 latest。这是一个指针，发布者可以随时将其移动到其他构建，因此例行执行 pull 可能会改变代理运行的模型。在脚本、单元文件和代理配置中写入 muse-glimmer:30b。固定之前，请检查模型页面上的标签列表，因为已发布的标签可能会发生变化。

#ollama#local-llm#muse-glimmer#agents#gpu