著者 VPSでMuse Glimmer 30Bを動かすRAMと容量
Muse Glimmerのtagは17GBから59GBです。Linux VPSでpullする前に必要なRAMとディスク容量を確認し、CPUのみの推論にかかる現実的な負荷も解説します。
VPS で Muse Glimmer に必要なもの
Muse Glimmer は GPU なしの一般的な Linux VPS で動作します。必要なメモリ容量は、取得する tag によって決まります。Meta Superintelligence Labs は、2026 年 8 月 10 日にこのモデルを Apache 2.0 で公開しました。パラメータ数は 30 billion、コンテキストウィンドウは 128K です。さらに、1.8B パラメータの専用 perception encoder を備えているため、テキストと画像を同時に処理できます。Meta は、このモデルをチャット用途ではなく、常時稼働するローカルエージェント向けとして位置付けています。推論の強度はリクエストごとに設定できます。
2026 年 8 月 16 日に確認した公開済みの Ollama tag は、17 GB から 59 GB まであります。この範囲が、必要なサイズを決める際の中心的な要素です。default tag は約 18 GB と記載されています。そのため、現実的な最小構成でも、空き RAM は 18 GB を明確に上回る必要があります。ダウンロード用のディスク容量と、コンテキストウィンドウ用のメモリも別途必要です。
どの muse-glimmer タグを pull すべきか
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 には、このモデルについて Apple ビルドではないタグが 11 件あります。これらは、同じ 30 billion 個の重みを異なる数値精度で保存したものです。表示されるサイズはダウンロードする容量であり、コンテキストを追加する前にメモリへ保持する必要がある容量の目安でもあります。
4-bit ビルドは小さい 2 つです。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 では、別のハードウェアで測定された機能のために、増加したサイズ分の実メモリを消費します。そのため、まず通常のタグを使用し、一度に 1 つだけ変更してください。
特別な理由がない限り、4-bit から始めてください。4-bit から 8-bit に変更すると、CPU が生成する各トークンのために読み取るバイト数が概ね 2 倍になります。そのため、メモリ使用量が増える一方でスループットは低下します。このトレードオフについては、q4、q8、fp16 の量子化で実際に生じるコストで説明します。CPU サーバーでは、要点は 4-bit ビルドから始める価値があるのはこれだけだということです。
Linux サーバーで MLX タグが機能しない理由
MLX は Apple の配列フレームワークであり、Ollama の MLX エンジンは Apple Silicon 向けのバックエンドです。名前に mlx を含むタグは、そのエンジンとハードウェア向けにビルドされています。x86 Linux VPS では数十 GB のダウンロードが必要ですが実行できず、ディスク上で容量を占有するだけです。Mac で測定された告知の速度値もこれらのタグを対象としているため、サーバーの性能を示すものではありません。モデルページのタグ一覧を確認するときは、まず mlx という名前をすべて除外し、残ったタグを基に容量を見積もってください。
必要な RAM とディスク容量は実際にはどのくらいか
メモリを消費する要素は 2 つあり、タグのサイズだけが要因ではありません。重みのサイズは取得するタグによって決まります。KV キャッシュは、モデルが会話のために保持するトークンごとの状態であり、設定したコンテキスト長に応じて増加します。Ollama のドキュメントにもあるとおり、並列リクエストを処理すると、同時に処理中のリクエスト数に応じてコンテキストが増えます。そのため、2 つのエージェントに同時に応答するホストには、1 つのエージェントだけに応答する同じホストより多くのメモリが必要です。
このガイドを含め、どのガイドに記載された RAM 容量もそのまま信じないでください。タグを取得し、1 つのプロンプトを送信して、モデルがまだメモリ上に常駐している間に次の 2 つのコマンドを実行します。
ollama ps
free -hollama ps は現在ロードされている内容と、処理が CPU と GPU にどう分配されているかを示します。free -h は残りの容量を示します。この 2 つの出力は、コンテキスト設定、量子化設定、その他ホスト上で実行中のすべての処理をすでに反映しているため、公開されたどの表よりも実際のホストに即しています。
ディスク容量の確認は、メモリより簡単です。Linux では、Ollama は通常 /usr/share/ollama/.ollama/models 以下にモデルを保存します。ほとんどの VPS イメージでは、これは root ファイルシステム上にあります。40GB の root ボリュームでは、57 GB の bf16 ビルドを保存できず、8-bit タグを 2 つ並べて保存することもできません。pull で実際にどのようなファイルが書き込まれるか確認したことがない場合は、Ollama がモデルを保存する場所と保存先を移動する方法でそのディレクトリを確認できます。何かを pull する前に、保存先をマウント済みのボリュームへ移動してください。
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 を使っても、より大きなタグを実行できるわけではありません。生成処理では、出力するすべてのトークンについて重みを参照します。そのため、swap 上にある重みはディスクから何度も読み戻され、vmstat 1 では si 列と so 列が継続的に増加し、出力速度は 1 トークンあたり数秒まで低下します。OOM killer への備えとして、小容量の swap ファイルは残してください。RAM は、実際に使用したいタグに合わせて確保してください。
名前付きタグを固定して Ollama をインストールする
curl -fsSL https://ollama.com/install.sh | sh
ollama --version
systemctl status ollamaインストールスクリプトは systemd サービスを設定するため、再起動後もサーバーは起動します。root が管理するシステムサービスとして実行したくない場合は、Podman で Ollama を rootless 実行する方法でその構成を確認できます。その後、明示的なタグを pull します。
ollama pull muse-glimmer:30b
ollama listollama list のサイズ列を自分で確認し、モデルページにある現在のタグ一覧と比較してください。公開済みのタグは追加、名前変更、削除が行われます。ガイドに記載されたサイズは、ある1日の時点のスナップショットです。
依存しているサーバーでは、ollama pull muse-glimmer を使用しないでください。モデル名だけを指定すると latest タグに解決されます。また、latest は公開元が別のビルドを指すように変更できるポインターです。通常の pull を実行すると、エージェントの下でモデルが置き換わります。メモリ要件と動作が変わる可能性がありますが、ログにはその変更が通知されません。スクリプト、unit ファイル、エージェント設定にはタグを記述してください。VPS 上で Ollama を使って LLM をセルフホストする方法では、残りのサーバー設定を説明しています。
GPUなしでMuse Glimmerを実行できますか？
はい。ただし、性能の上限は明確に理解しておく必要があります。1トークンを生成するたびに、モデルの重みをメモリから読み出します。そのため、速度を決めるのはvCPU数ではなく、メモリ帯域幅です。数個を超えるコアを追加しても、速度はほとんど向上しません。共有VPSでは、その帯域幅をホスト上の他のテナントと共有します。そのため、4-bitの30Bモデルでは、1秒あたりに生成できるトークン数は少なくなります。
この点については、私の測定値も含め、誰かの数値をそのまま信用しないでください。自分の環境で1秒あたりのトークン数を測定することで、実測値を基準に判断してください。
その結果、モデルに適した用途が明確に分かれます。対話形式のチャットには向きません。サーバーの出力より読む速度のほうが速く、各応答の開始まで長く待たされるためです。一方、バックグラウンドのエージェント処理には適しています。人が監視しないまま10分間実行するタスクであれば、処理が遅くても問題になりません。Metaがこのモデル向けに説明しているのも、まさにこの用途です。
対話形式で十分な速度が必要なら、現実的な選択肢はGPUまたはホスト型APIです。何かを借りる前に、GPU VPSとAPIトークンの損益分岐点を確認することを推奨します。また、GPU VPSで実際に得られるものでは、購入するものの内容を説明しています。特定のサーバーでどのモデルを実行できるかという広い問題については、自分でホストできるモデルから確認してください。このサイズ帯で最も近い比較対象は、VPSで同程度のサイズのQwenモデルを実行するです。実測値が許容できないほど遅い場合は、VPS上のNemotron 3.5 Lightningで、サイズより速度を重視して構築されたモデルについて、同じRAM容量と1秒あたりのトークン数を確認できます。
128K トークンよりはるかに前の内容を忘れるのはなぜですか？
Ollama のデフォルトのコンテキストウィンドウは、モデルが対応している長さに関係なく 4096 トークンです。2026 年 8 月時点で、このデフォルト値は Ollama 自身の FAQ に記載されています。タグには 128K と表示されていますが、明示的に変更しない限り、サーバーがモデルに渡すのは 4096 トークンです。そのため、長いエージェントの記録では初期のやり取りが失われ、モデルが記憶喪失になったように見えます。
すべてのリクエストに対してサーバー側で値を引き上げます。
[Service]
Environment="OLLAMA_CONTEXT_LENGTH=32768"対話セッション内では、/set parameter num_ctx 32768 により、そのセッションだけの値を変更できます。API 経由では、リクエストのオプションに num_ctx を指定します。
コンテキストを 1 トークン追加するたびに、重みとは別にメモリを消費します。重みだけを想定して容量を決めたホストで完全な 128K を要求すると、ロードに失敗するか、より低速な方式にフォールバックします。値は段階的に引き上げ、各段階の後に ollama ps を実行してください。Ollama の num_ctx とコンテキスト長の仕組みでは、この計算方法を説明しています。
推論強度: low、medium、high、xhigh
Meta は Muse Glimmer について、low から xhigh までの4つの推論強度を定義しており、複雑なコーディングやエージェントタスクには後者2つを推奨しています。Ollama では、これは think パラメーターで指定します。コマンドラインでは --think= を使用し、API のリクエスト本文では 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 も受け付けます。このモデルが受け付ける正確な文字列はモデルページに記載されているため、推測せずに確認してください。エージェントに組み込む前に、手動で1つ試してください。
CPU だけの環境では、この設定が処理時間に大きく影響します。強度を上げると、回答の最初の単語が表示される前に生成される思考トークンが増えます。思考トークンの生成にも、回答トークンと同じ実時間がかかります。通常の処理では low に設定してください。回答の長さも同様に管理する必要があります。そのため、num_predict で回答を制限することで、冗長な回答によって低速なマシンが数分間占有されるのを防ぎます。
常時稼働エージェント向けにモデルをロードしたままにする
Ollama はデフォルトで、アイドル状態のモデルを 5 分後にアンロードします。10 分ごとに実行するエージェントでは、実行のたびにディスクから 18 GB のモデルを完全にロードすることになります。ネットワーク接続ストレージを使用する VPS では、このロードに時間がかかります。代わりに、モデルをメモリに保持します。
[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"負の値を指定すると、何かがアンロードするまでモデルが常駐します。また、API リクエストの keep_alive により、その 1 回の呼び出しだけサーバーのデフォルト設定を上書きできます。代わりに、何も処理していない間も RAM を占有し続けるというコストがあります。そのため、これはエージェント専用のサーバー向けの設定です。Ollama モデルをロードしたままにするでは、さまざまな設定方法を説明しています。
コーディングエージェントを接続する
Ollama は http://127.0.0.1:11434/v1 で OpenAI 互換 API を提供します。そのため、多くのエージェントツールは、ベース URL と空でない API key を指定するだけで接続できます。Ollama の Muse Glimmer ページには、対応するエージェントをローカルモデルに 1 つのコマンドで接続する起動ショートカットも記載されています。そこでもタグを固定してください。
ollama launch claude --model muse-glimmer:30bエージェントは大きなプロンプトを送信します。ファイルの内容、ツールの出力、増加し続けるトランスクリプトがすべて入力トークンとして送られます。CPU 環境では、生成が始まる前のプロンプト処理が負荷になります。コンテキスト設定は、タスクに必要な範囲でできるだけ小さくしてください。コーディングエージェントを Ollama に接続するではクライアント側を、VPS でコーディングエージェントを実行するではエージェントを動かす環境を、VPS でエージェントのコストを管理するでは終日実行した場合の影響を説明しています。
画像入力も同じ仕組みです。Ollama API はメッセージの images フィールドで画像を受け取ります。そのため、知覚エンコーダーの性能にかかわらず、テキスト専用のクライアントから画像が送信されることはありません。
11434 番ポートを公開しない
Ollama API には認証機能がありません。ノート PC からアクセスできるように OLLAMA_HOST=0.0.0.0:11434 を設定すると、認証されていないモデル実行環境がインターネット上に公開されます。ポートを見つけた第三者がディスクにモデルを読み込んだり、エージェントが送信した内容を読み取ったりできる状態になります。localhost にバインドしたまま、代わりにトンネルを使用してください。
ssh -N -L 11434:127.0.0.1:11434 user@your-vpsOllama API エンドポイントの保護では、認証情報を要求するリバースプロキシなど、適切な方法を説明しています。
何が原因で失敗し、何が表示されるか
pull が途中で停止する。 ディスク容量が原因です。モデルディレクトリに対して df -h を実行します。57 GB の bf16 ビルドは 40GB の root ボリュームに収まりません。8-bit の tag を 2 つ並べて保存する場合も同様です。
モデルのロード後にプロセスが終了する。 メモリ不足が原因です。dmesg -T には、kernel の out of memory killer がプロセスを選択した記録が残ります。journalctl -u ollama -n 100 には、同じ事象をサービス側から見た記録が表示されます。対処方法は、より小さい tag またはより小さい num_ctx を使用することです。swap を増やしても解決しません。
1 token あたり数秒かかる。 vmstat 1 を実行し、si 列と so 列を確認します。swap が継続的に使用されている場合、重みが RAM に収まっていません。処理中にディスクから重みを読み戻しています。
先週は動作した tag がなくなっている。 tag の一覧は変わります。モデルページを再確認し、現在の tag を固定して、後で確認できる場所に tag 名を記録します。
pull 前にサイズを自分で再確認する
表のサイズは 16 August 2026 にモデルの tag ページから取得したものです。公開されている tag 一覧が保証されているわけではありません。モデルページで現在の一覧を確認し、実際にディスクへ保存されたサイズを確認します。
ollama pull muse-glimmer:30b
ollama list
sudo du -sh /usr/share/ollama/.ollama/modelsOllama はモデルレイヤーを共有 blob として保存します。そのため、同じレイヤーを共有する 2 つの tag を保存しても、ディスク使用量は 2 倍になりません。du の報告値を公開サイズと比較し、2 つのうち大きい方を基準にディスク容量を計画します。
FAQ
Muse Glimmer を VPS で実行するには、RAM がどのくらい必要ですか？
タグのサイズを基準にし、コンテキストウィンドウ分を加えます。デフォルトタグは、2026 年 8 月 16 日時点で約 18 GB と記載されています。そのため、16GB のマシンにはまったく収まらず、24GB のマシンでもコンテキスト用の余裕はほとんど残りません。これは目安であり、確定値ではありません。タグを pull して一度ロードし、自分のマシンで ollama ps と free -h を実行して、実測値を確認してください。コンテキストを長くすると、並列リクエストと同様に、重みの分に加えてメモリ使用量が増えます。
GPU なしで Muse Glimmer を実行できますか？
はい。CPU のみの VPS でもロードして応答できます。生成速度はコア数よりもメモリ帯域幅に左右されます。共有ホストでは帯域幅も共有されるため、4-bit では 1 秒あたり数トークン程度を見込んでください。これは無人で実行するバックグラウンドのエージェント処理には使えますが、対話型チャットには適しません。リクエスト中に ollama ps を実行し、プロセッサーの列を確認して、処理がどこで実行されているかを確認してください。
Linux VPS では MLX タグに利用価値がありますか？
いいえ。名前に mlx を含むすべてのタグは、Ollama の MLX エンジン向けにビルドされています。これは Apple Silicon 用のバックエンドです。x86 Linux サーバーでは、これらのタグをダウンロードしても実行できません。通常の 30b タグ、またはその他の MLX ではないタグを使用し、MLX ビルドに対応する Apple ハードウェアのベンチマークは無視してください。
モデルが 128K トークンよりかなり前に内容を忘れるのはなぜですか？
Ollama のデフォルトのコンテキストウィンドウは、モデルが対応している長さに関係なく 4096 トークンだからです。そのため、モデルが内容を受け取る前に、サーバーが長い会話を切り詰めます。サーバーでは OLLAMA_CONTEXT_LENGTH、1 セッションでは /set parameter num_ctx、API リクエストのオプションでは num_ctx を指定してください。コンテキストを増やすとメモリ使用量も増えるため、段階的に増やし、その都度 ollama ps を確認してください。
タグを固定すべきですか。それとも latest を使えばよいですか？
固定してください。タグを指定しない muse-glimmer は latest に解決されます。これは公開元がいつでも別のビルドを指すように変更できるポインターです。そのため、通常の pull によってエージェントが実行するモデルが変わる可能性があります。スクリプト、unit ファイル、エージェント設定には muse-glimmer:30b を記述してください。固定する前にモデルページでタグの一覧を確認してください。公開されているタグは変更されるためです。