作者： VPS运行Meta Muse Glimmer 30B需要多少内存？
Muse Glimmer Ollama 标签大小为17GB至59GB。了解Linux VPS所需RAM和磁盘空间，以及无GPU、仅用CPU运行30B模型的实际推理代价。
VPS 对 Muse Glimmer 的要求
Muse Glimmer 可在无 GPU 的普通 Linux VPS 上运行。所选 tag 决定它是否能装入内存。Meta Superintelligence Labs 于 10 August 2026 以 Apache 2.0 许可证发布了该模型：30 billion 个参数、128K 上下文窗口，以及一个专用的 1.8B 参数感知编码器，因此它可以同时读取图像和文本。Meta 将其定位为持续运行的本地 agent，而不是聊天模型；每次请求都可以设置其推理强度。
截至 16 August 2026，已发布的 Ollama tag 从 17 GB 到 59 GB 不等。整个配置问题都取决于这个范围。默认 tag 的大小约为 18 GB，因此，合理的最低配置显然需要拥有远多于 18 GB 的可用 RAM。下载文件占用的磁盘空间和上下文窗口所需的内存还要额外计算。
应拉取哪个 muse-glimmer 标签？
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 构建的标签。它们都包含相同的 30 billion 个权重，但使用不同的数值精度存储。显示的大小就是需要下载的大小，也是加入上下文之前大致需要占用的内存。
两个 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 开始。改用 8-bit 后，CPU 为生成每个 token 需要读取的字节数大致翻倍，因此吞吐量会下降，而内存使用量会上升。q4、q8 和 fp16 量化的实际开销将详细讨论这一取舍；对于 CPU 服务器，简而言之，4-bit 构建是唯一值得首先尝试的版本。
为什么 MLX 标签在 Linux 服务器上不起作用
MLX 是 Apple 的数组框架，Ollama 的 MLX 引擎是面向 Apple Silicon 的后端。名称中包含 mlx 的任何标签都针对该引擎和相应硬件构建。在 x86 Linux VPS 上，这些标签需要下载数十 GB 的内容，但无法运行，只会占用磁盘空间。公告中的速度数据是在 Mac 上测得的，仅适用于这些标签，因此也不能代表您的服务器性能。查看模型页面上的标签列表时，先排除所有 mlx 名称，再根据剩余内容估算所需空间。
实际需要多少 RAM 和磁盘空间？
有两部分会占用内存，只有一部分取决于 tag 大小。权重由拉取的 tag 固定。KV cache 是模型为对话保留的每个 token 的状态，其大小会随配置的上下文长度增长。Ollama 文档指出，并行处理请求时，上下文大小会乘以同时处理的请求数。因此，同时回答两个代理的主机，需要的内存多于只回答一个代理的同一台主机。
不要采用任何指南中的 RAM 数值，包括本指南中的数值。拉取 tag，发送一次提示词，然后在模型仍驻留内存时运行以下两个命令。
ollama ps
free -hollama ps 显示当前已加载的内容，以及任务如何在 CPU 和 GPU 之间分配。free -h 显示剩余资源。这两个命令在您自己的主机上得到的输出，比任何已发布的表格都更可靠，因为其中已经包含您的上下文设置、量化方式，以及服务器运行的其他所有内容。
磁盘空间更容易计算。Ollama 在 Linux 上将模型存储在 /usr/share/ollama/.ollama/models 下，而该路径在大多数 VPS 镜像中位于根文件系统上。40GB 的根卷无法容纳 57 GB 的 bf16 构建，也无法同时容纳两个 8-bit tag。如果您从未查看过 pull 实际写入的内容，请参阅Ollama 存储模型的位置以及如何迁移模型，其中介绍了该目录。拉取任何内容前，先将存储目录迁移到已挂载的卷。
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 ollamaollama 用户必须拥有该目录，因为服务以 ollama 身份运行，并以该身份将 blob 写入目录。如果 pull 因权限问题失败，journalctl -u ollama -n 50 中会显示原因。
关于 swap，需要明确说明：swap 无法让您运行更大的 tag。模型每生成一个 token 都需要访问权重，因此位于 swap 中的权重会反复从磁盘读回，vmstat 1 会显示 si 和 so 列持续繁忙，输出速度会降至每个 token 数秒。保留一个较小的 swap 文件，用于防止触发 out of memory killer。根据实际需要运行的 tag 为 RAM 配置容量。
安装 Ollama 并固定命名标签
curl -fsSL https://ollama.com/install.sh | sh
ollama --version
systemctl status ollama安装脚本会配置 systemd 服务，因此服务器重启后该服务会自动恢复。如果不希望以 root 管理的系统服务运行 Ollama，请参阅在 Podman 下以无 root 模式运行 Ollama。然后拉取明确的标签。
ollama pull muse-glimmer:30b
ollama list请自行读取 ollama list 中的大小列，并与模型页面上的当前标签列表进行比较。已发布的标签会新增、重命名或删除，指南中的大小只是某一天的快照。
请勿在依赖该服务器的环境中写入 ollama pull muse-glimmer。不带标签的模型名称会解析为 latest 标签，而 latest 是发布者可以指向其他构建的指针。常规拉取操作随后会在代理下方替换模型，导致内存需求和行为发生变化，而且日志不会对此作出提示。请在脚本、单元文件和代理配置中写入标签。使用 Ollama 在 VPS 上自行托管 LLM介绍其余服务器配置。
能否在没有 GPU 的情况下运行 Muse Glimmer？
可以，但需要明确它的性能上限。生成一个 token 需要从内存中读取模型权重，因此速度取决于内存带宽，而不是套餐标称的 vCPU 数量。核心数超过一定数量后，继续增加核心几乎没有收益。在共享 VPS 上，内存带宽还要与主机上的其他租户共享，因此 30B 模型使用 4-bit 量化时，每秒只能生成少量 token。
不要直接接受任何人的数据，包括我的数据。在自己的服务器上测量每秒 token 数，再根据实际结果做决定。
这会明显影响模型适合的工作类型。交互式聊天体验很差，因为您的阅读速度高于服务器的生成速度，而且每次回复开始前都要长时间等待。后台代理任务则没有问题，因为无人值守运行十分钟的任务并不在意速度较慢。这正是 Meta 为该模型描述的使用场景。
如果需要交互式速度，诚实的答案只有两个：使用 GPU，或使用托管 API。在租用任何资源前，请先计算 GPU VPS 与 API token 的盈亏平衡点；GPU VPS 实际提供什么介绍了您购买的具体能力。对于某台服务器能够运行哪些模型这一更广泛的问题，请先查看可以自行托管哪些模型；在 VPS 上运行相近规模的 Qwen 模型则是此规模级别中最接近的对比。如果实测结果慢到无法接受，在 VPS 上运行 Nemotron 3.5 Lightning会针对一个以速度而非规模为设计目标的模型，讨论相同的 RAM 和每秒 token 数问题。
为什么远未达到 128K tokens 就开始遗忘内容？
因为无论模型支持多大的上下文窗口，Ollama 的默认上下文窗口都是 4096 tokens。截至 2026 年 8 月，Ollama 自己的 FAQ 仍采用这一默认值。模型标签标注了 128K，但服务器会先为模型提供 4096，除非您另行设置。因此，较长的 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 设置。回答长度同样需要控制，因此应使用 使用 num_predict 限制回答长度，不要让一条冗长回答占用性能较低的设备数分钟。
让模型持续加载，支持常驻代理
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 会记录内核的 out-of-memory 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/modelsOllama 会将模型层存储为共享 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 是 Ollama 的 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。固定之前请查看模型页面上的标签列表，因为已发布的标签可能会发生变化。