指南

作者： Matt Connor 2026-10-12

VPS 執行 Meta Muse Glimmer 30B 需要多少資源？

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

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

Linux tags 大小為 18GB 至 59GB；先估算 VPS 的 RAM 與磁碟，再了解無 GPU、僅靠 CPU 推理的實際成本。

VPS 上的 Muse Glimmer 需求

Muse Glimmer 可在沒有 GPU 的一般 Linux VPS 上執行，而所拉取的 tag 會決定它是否能裝入記憶體。Meta Superintelligence Labs 於 2026 年 8 月 10 日以 Apache 2.0 授權發布此模型：30 billion 個參數、128K context window，以及專用的 1.8B parameter perception encoder，因此能同時讀取影像與文字。Meta 將它定位為持續運作的本機代理程式，而非聊天用途；推理強度可依每次請求設定。

截至 2026 年 10 月 12 日，已發布且可在 Linux 上執行的 Ollama tags，大小介於 18 GB 至 59 GB。這個範圍就是整體容量規劃的重點。完整 tag 清單的起點更低、終點更高，分別為 17 GB 和 65 GB；但這兩端都是針對 Apple Silicon 建立的 MLX tags，因此不適用於 Linux 伺服器。預設 tag 列出的大小約為 18 GB，因此，合理的最低規格主機必須具備明顯多於 18 GB 的可用 RAM。下載所需的磁碟空間，以及 context window 所需的記憶體，還需另外計入。

應拉取哪個 muse-glimmer 標籤？

圖表Published muse-glimmer tag sizes on 12 October 2026 (Linux tags only)

label

size_gb

30b (default)

30b-q4_K_M

30b-q4_K_M-dflash

30b-q8_0

30b-q8_0-dflash

30b-bf16

30b-bf16-dflash

此圖表背後的資料

[
  {
    "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-q8_0",
    "size_gb": 31
  },
  {
    "label": "30b-q8_0-dflash",
    "size_gb": 33
  },
  {
    "label": "30b-bf16",
    "size_gb": 57
  },
  {
    "label": "30b-bf16-dflash",
    "size_gb": 59
  }
]

Ollama 為此模型列出 7 個未帶 MLX 標籤的標籤，不計入 latest 別名。一般標籤都包含相同的 30 billion 權重，但使用不同的數值精度儲存。-dflash 標籤除了這些權重，還包含下文介紹的另一個較小網路，因此每個標籤列出的大小都比對應的一般標籤大。顯示的大小就是你需要下載的大小，也是加入任何 context 前大致需要保留在記憶體中的容量。

4-bit build 是較小的版本：30b-q4_K_M，大小為 18 GB。預設的 30b 標籤只是這個 build 的另一個名稱，在標籤頁面上使用相同的 digest。8-bit build 是 30b-q8_0，大小為 31 GB。30b-bf16 是未量化的 16-bit release，大小為 57 GB；對 side project 而言，多數租用伺服器即使付出一般人願意負擔的價格，也無法提供這麼多 RAM。17 GB 的 30b-nvfp4 標籤雖然標示的容量較小，8-bit 的 30b-mxfp8 為 33 GB，但兩者都帶有 MLX 標籤，因此不列入圖表。下一節會說明原因。

-dflash 標籤加入 Meta 的 DFlash drafter。模型卡將其描述為「一次提出完整 token 區塊的小型搭配網路」：使用 5 個 draft layers，預測由 16 個 token 組成的區塊。這是 speculative decoding 的加速功能，而 Ollama 的模型頁面將 DFlash 支援列為 Apple Silicon 上 MLX engine 的一部分。在僅使用 CPU 的 VPS 上，這個 drafter 約需額外 2 GB 的實際記憶體；但你尚未測量它在硬體上的效益，因此請先使用一般標籤，並且每次只變更一項設定。

除非有特定理由，否則請從 4-bit 開始。從 4-bit 改用 8-bit 後，CPU 為每個產生的 token 讀取的位元組數大致會加倍，因此記憶體使用量上升，而 throughput 下降。q4、q8 與 fp16 量化實際會付出什麼代價將說明這項取捨；對 CPU 主機而言，簡短結論是：4-bit build 是唯一值得用來開始的版本。

為什麼 MLX 標籤在 Linux 伺服器上沒有作用

MLX 是 Apple 的陣列框架，而 Ollama 的 MLX 引擎是供 Apple Silicon 使用的後端。Ollama 宣布這項功能時，要求「確認你使用的是 unified memory 超過 32GB 的 Mac」。標籤頁標示為 MLX 的每個標籤，都是為該引擎及該硬體建置，且標籤名稱不一定會包含 MLX：在此模型中，這包括 30b-nvfp4、30b-mxfp8 及其 -dflash 變體，以及所有包含 mlx 的標籤。在 x86 Linux VPS 上，這些標籤各自都是數十 GB 的下載內容，無法執行，還會佔用磁碟空間。Mac 上測得的任何速度數據都適用於這些標籤，因此也無法描述你的伺服器。查看模型頁面的標籤清單時，先排除所有具有 MLX 標籤的項目，再根據剩餘內容評估需求。

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

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

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

ollama ps
free -h

ollama ps 顯示目前已載入的內容，以及工作如何分配到 CPU 與 GPU。free -h 顯示剩餘的資源。這兩個命令在您自己的主機上產生的結果，比任何已發布的表格都可靠，因為其中已包含您的 context 設定、量化設定，以及伺服器正在執行的其他所有工作。

磁碟空間較容易估算。Ollama 在 Linux 上會將模型儲存於 /usr/share/ollama/.ollama/models。在大多數 VPS 映像檔中，這個路徑位於 root 檔案系統。40GB 的 root volume 無法容納 57 GB 的 bf16 組建，也無法同時容納 8-bit 與 4-bit 組建。如果您從未查看拉取操作實際寫入的內容，Ollama 儲存模型的位置及移動方式會逐步說明該目錄。請在拉取任何內容前，先將模型儲存區移至已掛載的 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 並鎖定特定標籤

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 files) 與代理程式設定中寫入標籤。在 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 模型是此規模等級中最接近的比較。如果您測得的數據慢到無法接受，Nemotron 3.5 Lightning on a VPS 針對專為速度而非規模設計的模型，提出了相同的記憶體與每秒 token 數問題。

為什麼遠在 128K tokens 之前就開始遺忘內容？

因為在沒有 GPU 的主機上，Ollama 的預設 context window 是 4096 tokens，與模型支援的上限無關。Ollama 的 FAQ 說明預設值為 4096，而其 context length 文件（截至 12 October 2026 查閱）會依 GPU 記憶體調整預設值：VRAM 低於 24 GiB 時為 4k，24 至 48 GiB 時為 32k，48 GiB 以上時為 256k。僅使用 CPU 的 VPS 位於最低一級。模型標籤雖然標示 128K，但伺服器仍會將 4096 傳給模型，除非你明確指定其他值。因此，較長的代理程式對話記錄會遺失前段內容，看起來就像模型失憶。

在伺服器上為每個請求提高上限：

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"

在互動式工作階段中，/set parameter num_ctx 32768 只會變更該工作階段的設定。使用 API 時，請在請求選項中傳送 num_ctx。

每增加 1 個 context token，都會在模型權重之外額外耗用記憶體。如果主機的容量只足以載入模型權重，卻要求完整的 128K，載入可能會失敗，或退回較慢的執行方式。請分階段提高上限，並在每個階段後執行 ollama ps。Ollama 中 num_ctx 與 context length 的運作方式會說明相關計算。

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

Meta 為 Muse Glimmer 定義了 low 到 xhigh 的 4 種推理強度，並建議在複雜的程式撰寫與代理程式工作中使用後兩者。在 Ollama 中，此設定由 think 參數控制。您可以在命令列使用 --think=，或在 API 主體中傳送 think。

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

在互動式工作階段中，/set think 與 /set nothink 可切換此設定。Ollama 的 thinking 文件（讀取日期為 12 October 2026）指出，每個模型都會在 /api/show 回應的 thinking.values 中公布其接受的值，格式可能是布林值或具名等級，並要求使用其中列出的確切值。命令列說明只列出 true、false、high、medium 與 low，其他字串則會未經檢查直接傳送至伺服器。因此，請先查看 muse-glimmer:30b 回報的 /api/show，不要自行猜測；在將設定整合至代理程式前，也應先手動測試一次。

在僅使用 CPU 的主機上，此設定會明顯影響效能。強度越高，模型在顯示回答的第一個字之前產生的思考 token 越多，而每個思考 token 所需的實際經過時間，與回答 token 相同。例行工作請維持 low 設定。回答長度也需要同樣謹慎處理，因此請使用以 num_predict 限制回答長度，不要讓單次冗長回答使速度緩慢的主機持續忙碌數分鐘。

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

Ollama 預設會在模型閒置 5 分鐘後將其卸載。對於每 10 分鐘執行一次的代理程式而言，這表示每次執行都必須從磁碟重新載入完整的 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

代理會發送大型提示詞。檔案內容、工具輸出與不斷增長的對話紀錄都會轉化為輸入 Token；在 CPU 伺服器上，提示詞處理階段在生成開始前就會造成效能瓶頸。請將上下文設定保持在任務允許的最小範圍內。將程式碼代理指向 Ollama 涵蓋了客戶端設定，在 VPS 上執行程式碼代理說明了其運作環境，而控制 VPS 上的代理成本則探討了全天候運作時的相關事項。

影像輸入的運作方式相同。Ollama API 會接收訊息中 images 欄位的影像，因此若客戶端僅支援文字，即使感知編碼器功能再強大，也無法發送影像。

請勿開啟 11434 埠

Ollama API 並無內建驗證機制。若設定 OLLAMA_HOST=0.0.0.0:11434 以便從筆記型電腦存取，等於將未經驗證的模型執行環境暴露於公用網際網路。任何掃描到該埠的人皆可將模型載入您的磁碟，並讀取您的代理程式所傳送的所有內容。請務必將其綁定於 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 與 4-bit 建置並存時也一樣。

模型載入後程序終止。 記憶體不足。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 頁面，日期為 12 October 2026；已發布的 tag 清單不代表永久不變。請在模型頁面查看目前的清單，再確認實際寫入磁碟的內容：

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

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

FAQ

Muse Glimmer 在 VPS 上需要多少 RAM？

先以 tag 大小為基準，再加上 context window。2026 年 10 月 12 日的資料顯示，預設 tag 約為 18 GB，因此 16GB 主機完全無法容納，24GB 主機則幾乎沒有剩餘空間可供 context 使用。這只能作為起點，不能直接視為答案。請先 pull 該 tag 並載入一次，再在自己的主機上執行 ollama ps 和 free -h，查看實際數值。較長的 context 與平行請求都會在模型權重之外增加記憶體用量。

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

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

MLX tags 在 Linux VPS 上有用嗎？

沒有。tag 頁面標示為 MLX 的每個 tag，都是為 Ollama 的 MLX engine 建置；MLX 是 Ollama 的 Apple Silicon backend。這也包括 30b-nvfp4 和 30b-mxfp8，即使它們的名稱沒有包含 mlx。在 x86 Linux server 上，這些 tags 只是大型下載檔案，無法執行。請使用一般的 30b tag，或其他非 MLX tags，並忽略 MLX builds 所附的 Apple 硬體效能基準。

為什麼模型在遠少於 128K tokens 前就忘記內容？

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

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

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

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