指南

作者： Matt Connor 2026-08-16

Muse Glimmer 30B VPS 需要多少 RAM 與磁碟？

Q: MLX 標籤在 Linux VPS 上有用嗎？

沒有。名稱包含 mlx 的每個標籤，都是為 Ollama 的 MLX engine 建置，而 MLX 是其 Apple Silicon backend。在 x86 Linux server 上，這些標籤只是無法執行的大型下載內容。請使用一般的 30b 標籤，或其他不含 MLX 的標籤，並忽略隨 MLX build 提供的 Apple hardware benchmark。

Q: 應該固定標籤，還是直接使用 latest？

請固定標籤。未指定標籤的 muse-glimmer 會解析至 latest；這是 publisher 隨時可以指向其他 build 的指標，因此例行 pull 可能會變更 agent 執行的模型。請在 scripts、unit files 和 agent config 中寫入 muse-glimmer:30b。固定標籤前，請先查看 model page 上的標籤清單，因為已發布的標籤可能會變更。

Muse Glimmer tag 大小從 17GB 到 59GB。先確認 Linux VPS 的 RAM 與磁碟需求，再評估純 CPU 推理的實際成本。

Muse Glimmer 在 VPS 上的需求

Muse Glimmer 可在一般的 Linux VPS 上執行，不需要 GPU；使用的 tag 會決定它是否能載入記憶體。Meta Superintelligence Labs 於 10 August 2026 以 Apache 2.0 授權發布此模型：30 billion 個參數、128K context window，以及專用的 1.8B parameter perception encoder，因此能同時讀取影像與文字。Meta 將它定位為長時間執行的本機代理，而非聊天用途；每次請求都可以設定 reasoning strength。

截至 16 August 2026 查閱的 Ollama tags，大小介於 17 GB 到 59 GB。這個範圍就是整個規模評估的核心。預設 tag 列出的大小約為 18 GB，因此最小的合理 VPS 顯然需要有多於 18 GB 的可用 RAM。下載所需的磁碟空間，以及 context window 所需的記憶體，還要另外預留。

應拉取哪個 muse-glimmer 標籤？

ChartPublished muse-glimmer tag sizes on 16 August 2026 (Linux tags only)

label

size_gb

30b-nvfp4

30b (default)

30b-q4_K_M

30b-q4_K_M-dflash

30b-nvfp4-dflash

30b-q8_0

30b-mxfp8

30b-q8_0-dflash

30b-mxfp8-dflash

30b-bf16

30b-bf16-dflash

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 build 的標籤。這些標籤都包含相同的 30 billion 個權重，但使用不同的數值精度儲存。顯示的大小就是你要下載的大小，也是加入任何 context 前大致需要保留在記憶體中的容量。

兩個 4-bit build 是較小的版本：30b-nvfp4 為 17 GB，30b-q4_K_M 為 18 GB。預設的 30b 標籤列出的大小，與 q4_K_M build 相同。8-bit build 30b-q8_0 和 30b-mxfp8 的大小約為 31 GB。30b-bf16 是未量化的 16-bit release，大小為 57 GB。這超過多數租用伺服器所提供的 RAM，而其價格也不適合一般 side project。

-dflash 標籤是加入 DFlash 支援的相同 build，每個版本列出的大小都比對應的 plain twin 大。Ollama 將 DFlash 描述為速度功能，並以 Apple Silicon 和 desktop GPU 示範。在僅使用 CPU 的 VPS 上，你必須以實際記憶體承擔這項額外容量，但該功能的效能測試是在其他硬體上進行。因此，請先使用 plain tag，並一次只變更一項設定。

除非有明確原因，否則請從 4-bit 開始。從 4-bit 改用 8-bit，CPU 每產生一個 token 都必須讀取大約 2 倍的位元組，因此吞吐量會下降，記憶體用量則會上升。這項取捨詳見 q4、q8 與 fp16 量化的實際成本。在 CPU 主機上，簡短結論是：4-bit build 是唯一值得用來起步的版本。

MLX 標籤在 Linux 伺服器上無法使用的原因

MLX 是 Apple 的陣列框架，而 Ollama 的 MLX engine 是其 Apple Silicon 後端。名稱中含有 mlx 的任何標籤，都是為該 engine 與該硬體建置的。在 x86 Linux VPS 上，這些標籤需要下載數十 GB 的資料，但無法執行，只會佔用磁碟空間。公告中的速度數據是在 Mac 上測得，適用於這些標籤，因此也不能代表你的伺服器效能。閱讀模型頁面的標籤清單時，先排除所有 mlx 名稱，再根據剩餘項目評估大小。

實際需要多少 RAM 與磁碟空間？

有兩項內容會占用記憶體，只有其中一項取決於 tag 大小。權重大小由你拉取的 tag 固定。KV cache 是模型為對話保留的每 token 狀態，會隨你設定的 context length 增加。Ollama 的官方文件指出，同時處理平行請求時，context 會依處理中的請求數量倍增。因此，同一台主機若要同時回應兩個 agent，所需記憶體會高於只回應一個 agent 的情況。

不要採用任何指南中的 RAM 數值，包括本指南。先拉取 tag，傳送一個 prompt，並在模型仍駐留記憶體時執行以下兩個命令。

ollama ps
free -h

ollama ps 顯示目前載入的內容，以及工作如何分配至 CPU 與 GPU。free -h 顯示剩餘的資源。你自己的主機產生的這兩份輸出，比任何公開表格都更可靠，因為其中已包含你的 context 設定、量化方式，以及伺服器目前執行的其他所有工作。

磁碟空間比較容易估算。在 Linux 上，Ollama 會將模型儲存在 /usr/share/ollama/.ollama/models；大多數 VPS 映像檔會將此路徑放在 root 檔案系統上。40GB 的 root volume 無法容納 57 GB 的 bf16 建置版本，也無法同時容納兩個 8-bit tag。開始拉取任何內容前，先將模型儲存位置移至已掛載的 volume。

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 不會讓你執行更大的 tag。模型每產生一個 token，都會讀取權重；位於 swap 的權重必須反覆從磁碟讀回，vmstat 1 中的 si 與 so 欄位會持續繁忙，輸出速度也會降至每個 token 需數秒。保留一個小型 swap 檔，作為防止 out of memory killer 的保險。請依照實際要使用的 tag 配置 RAM。

安裝 Ollama 並固定指定的 tag

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

安裝指令碼會建立 systemd 服務，因此伺服器重新開機後，服務會自動恢復。若不想將 Ollama 作為由 root 管理的系統服務執行，請參閱在 Podman 下以 rootless 模式執行 Ollama。接著拉取明確指定的 tag。

ollama pull muse-glimmer:30b
ollama list

請自行查看 ollama list 中的大小欄位，並與模型頁面目前的 tag 清單比較。已發布的 tag 可能新增、重新命名或移除，而指南中的大小只是某一天的快照。

不要在依賴的伺服器上使用 ollama pull muse-glimmer。未指定 tag 的模型名稱會解析至 latest tag，而 latest 是發布者可以移動到其他建置版本的指標。例行拉取會在代理程式底層替換模型，導致記憶體需求與行為改變，且日誌不會對此發出任何提示。在指令碼、unit 檔案及代理程式設定中明確寫入 tag。在 VPS 上使用 Ollama 自行託管 LLM涵蓋其餘伺服器設定。

不使用 GPU 可以執行 Muse Glimmer 嗎？

可以，但必須直接說明其效能上限。產生單一 token 時，必須從記憶體讀取模型權重，因此速度取決於記憶體頻寬，而不是方案標示的 vCPU 數量。核心數超過幾個後，增加核心幾乎沒有幫助。在共用 VPS 上，該頻寬還會與主機上的其他租戶共用，因此 30B 模型以 4-bit 執行時，每秒只能產生少量 token。

不要直接採信任何人的數據，包括我的數據。請在自己的主機上測量每秒 token 數，再根據實際結果做決定。

這會明顯區分模型適合的工作類型。互動式聊天體驗不佳，因為讀取速度比伺服器輸出速度快，而且每次回覆開始前都要長時間等待。背景 agent 工作則沒有問題，因為無人值守執行 10 分鐘的工作不在意速度緩慢。這正是 Meta 為此模型描述的工作負載。

如果需要互動速度，誠實的答案只有 GPU 或託管 API。租用任何資源前，請先計算 GPU VPS 與 API token 之間的損益平衡點；GPU VPS 實際提供的功能則說明你購買的內容。若要了解特定主機可以容納哪些模型，請先參閱哪些模型可以自行託管；而在 VPS 上執行大小相近的 Qwen 模型是此大小級距中最接近的比較案例。

為什麼還不到 128K tokens 就開始忘記事情？

因為無論模型支援多少 tokens，Ollama 的預設 context window 都是 4096 tokens。截至 2026 年 8 月，Ollama 自己的 FAQ 仍是如此說明。該 tag 宣稱支援 128K，但在你另行指定之前，server 只會將 4096 傳給模型。因此，長篇 agent transcript 會遺失開頭的回合，模型看起來就像失憶一樣。

在 server 上為每個 request 提高這個值：

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

在互動式 session 中，/set parameter num_ctx 32768 只會變更該 session 的設定。透過 API 時，請在 request options 中傳送 num_ctx。

context 的每個額外 token 都會在 weights 之外增加記憶體用量。如果主機只按照 weights 所需的記憶體規模配置，卻要求完整的 128K，載入可能會失敗，或退回較慢的設定。請逐步提高數值，並在每次調整後執行 ollama ps。Ollama 中的 num_ctx 與 context length 運作方式會說明相關計算方式。

推理強度：low、medium、high 與 xhigh

Meta 為 Muse Glimmer 定義了 4 種推理強度，從 low 到 xhigh，並建議在複雜的程式撰寫與代理程式工作中使用較高的 2 個等級。在 Ollama 中，這項設定由 think 參數控制。您可以在命令列使用 --think=，或在 API body 中傳送 think。

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

在互動式工作階段中，/set think 與 /set nothink 可切換這項設定。Ollama 的文件指出，多數模型接受 boolean 或 low、medium、high 等級別；有些模型也接受 max，代表可用的最高強度。此模型實際接受哪些字串，應以模型頁面為準，不要自行猜測。將設定整合至 agent 前，先手動測試其中一個值。

在僅使用 CPU 的主機上，這項設定會直接影響效能。強度越高，模型在輸出第一個答案字詞前產生的 thinking tokens 越多，而每個 thinking token 所需的實際經過時間，與每個答案 token 相同。例行工作請維持 low 設定。

讓模型持續載入，供常駐代理程式使用

Ollama 預設會在模型閒置五分鐘後將其卸載。對於每十分钟執行一次的代理程式而言，這表示每次執行都必須從磁碟重新載入完整的 18 GB；而在使用網路附加儲存空間的 VPS 上，載入速度並不快。請將模型固定在記憶體中。

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"

負值會讓模型持續常駐，直到有程序將其卸載；在 API 請求中使用 keep_alive，則可覆寫伺服器預設值，且只套用於該次呼叫。代價很明確：即使沒有工作執行，RAM 仍會持續被占用。因此，這項設定適合專門供代理程式使用的主機。讓 Ollama 模型持續載入涵蓋各種相關設定。

指定給 coding agent 使用

Ollama 在 http://127.0.0.1:11434/v1 提供與 OpenAI 相容的 API，因此大多數 agent 工具只要設定 base URL 和任意非空的 API key 即可連線。Ollama 的 Muse Glimmer 頁面也記載了啟動捷徑，可用一個命令將支援的 agent 連接到本機模型；同時也應在該處固定 tag。

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

Agent 會傳送大型提示。檔案內容、工具輸出及持續增長的對話記錄都會成為輸入 token；在 CPU 主機上，模型開始生成前，最耗時的部分通常是提示處理。請將 context 設定維持在工作允許的最小值。將 coding agent 指向 Ollama說明用戶端設定；在 VPS 上執行 coding agent說明其所在的主機；控制 VPS 上的 agent 成本則說明長時間執行時的情況。

影像輸入的方式相同。Ollama API 會將影像放在訊息的 images 欄位，因此僅支援文字的用戶端永遠不會傳送影像，無論 perception encoder 的能力多強。

不要開放連接埠 11434

Ollama API 沒有驗證機制。設定 OLLAMA_HOST=0.0.0.0:11434 讓筆電可以連線，會把未經驗證的模型執行器暴露在公用網際網路上。任何找到它的人，都可能將模型載入你的磁碟，並讀取 agent 透過它傳送的所有內容。請讓它維持繫結至 localhost，改用 tunnel。

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

保護 Ollama API 端點說明正確的選項，包括要求提供認證資料的反向代理。

發生的問題與可觀察到的現象

拉取作業中途停止。 磁碟空間不足。對模型目錄執行 df -h。57 GB 的 bf16 建置版本無法放入 40GB 的 root volume，兩個 8-bit tag 並列存放也一樣。

模型載入後程序終止。 記憶體不足。dmesg -T 會記錄 kernel 的 out-of-memory killer 選取程序的情況，journalctl -u ollama -n 100 則會顯示服務端對同一事件的記錄。解決方式是改用較小的 tag 或較小的 num_ctx。增加 swap 無法解決問題。

執行速度只有每秒數個 token。 執行 vmstat 1，並觀察 si 與 so 欄位。持續的 swap 活動表示權重無法全部放入 RAM，系統在執行期間不斷從磁碟讀回權重。

上週可用的 tag 消失了。 Tag 清單會變動。重新查看模型頁面，固定目前使用的 tag，並將 tag 名稱記錄在日後能再次查找的位置。

拉取前重新自行確認大小

圖表中的大小取自模型在 16 August 2026 的 tag 頁面；已發布的 tag 清單不代表永久不變。請在模型頁面查看目前的清單，再確認實際寫入磁碟的內容：

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

Ollama 會將模型層儲存為共用 blob，因此共用同一層的兩個 tag 不會占用兩倍磁碟空間。比較 du 回報的大小與已發布的大小，並以兩者較大值規劃磁碟空間。

FAQ

Muse Glimmer 在 VPS 上需要多少 RAM？

從標籤大小開始計算，再加上 context window。2026 年 8 月 16 日的預設標籤大小約為 18 GB，因此 16GB 主機完全無法容納，24GB 主機載入後也幾乎沒有空間留給 context。這只能作為起點，不能直接視為答案。請在自己的主機上拉取標籤、載入一次，然後執行 ollama ps 和 free -h，查看實際數值。較長的 context 與平行請求都會在模型權重之外額外增加記憶體用量。

沒有 GPU 可以執行 Muse Glimmer 嗎？

可以。它能在僅使用 CPU 的 VPS 上載入並回應。生成速度主要受記憶體頻寬限制，而不是核心數量；在共享主機上，這項頻寬還會與其他使用者共用，因此使用 4-bit 時，預期每秒只能生成少量 token。這適合無人值守的背景 agent 工作，但不適合互動式聊天。請在處理請求期間執行 ollama ps，查看 processor 欄位，以確認工作實際執行的位置。

MLX 標籤在 Linux VPS 上有用嗎？

沒有。名稱包含 mlx 的每個標籤，都是為 Ollama 的 MLX engine 建置，而 MLX 是其 Apple Silicon backend。在 x86 Linux server 上，這些標籤只是無法執行的大型下載內容。請使用一般的 30b 標籤，或其他不含 MLX 的標籤，並忽略隨 MLX build 提供的 Apple hardware benchmark。

為什麼模型在遠低於 128K token 時就忘記內容？

因為無論模型支援的大小為何，Ollama 的預設 context window 都是 4096 token。因此，server 會在模型看到長對話之前先將其截斷。請在 server 上設定 OLLAMA_CONTEXT_LENGTH，或針對單一工作階段設定 /set parameter num_ctx，也可以在 API request options 中傳送 num_ctx。記憶體用量會隨之增加，因此請分階段提高設定，並在每次調整後檢查 ollama ps。

應該固定標籤，還是直接使用 latest？

請固定標籤。未指定標籤的 muse-glimmer 會解析至 latest；這是 publisher 隨時可以指向其他 build 的指標，因此例行 pull 可能會變更 agent 執行的模型。請在 scripts、unit files 和 agent config 中寫入 muse-glimmer:30b。固定標籤前，請先查看 model page 上的標籤清單，因為已發布的標籤可能會變更。

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