ガイド

著者 Matt Connor 2026-08-16

VPSでMeta Muse Glimmer 30Bを動かすRAMと容量

Q: Linux VPS では MLX タグを使えますか？

いいえ。名前に mlx を含むタグはすべて Ollama の MLX engine 用に構築されています。MLX は Apple Silicon 用のバックエンドです。x86 Linux サーバーでは、これらのタグをダウンロードしても実行できません。通常の 30b タグ、または MLX 以外のタグを使用し、MLX ビルドに対応する Apple ハードウェアのベンチマークは無視してください。

Q: タグを固定すべきですか、それとも latest を使えばよいですか？

固定してください。タグを指定せずに muse-glimmer を実行すると latest に解決されます。これは、公開元がいつでも別のビルドを指すように変更できるポインターです。そのため、通常の pull だけでエージェントが実行するモデルが変わる可能性があります。スクリプト、unit ファイル、エージェント設定には muse-glimmer:30b を記述してください。固定する前にモデルページでタグ一覧を確認してください。公開されているタグは変更されるためです。

Muse GlimmerのOllama 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 すべきですか？

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 には、このモデルについて Apple ビルドではないタグが 11 件あります。いずれも、同じ 300 億個の重みを異なる数値精度で格納しています。表示されるサイズはダウンロードする容量であり、コンテキストを追加する前にメモリへ保持する必要がある容量の概算でもあります。

2 つの 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 では、別のハードウェアで測定された機能のために、増加したサイズ分の実メモリを使用することになります。そのため、まずは通常のタグから始め、変更は一度に 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 -h

ollama ps は、現在ロードされている内容と、処理が CPU と GPU にどのように分担されているかを示します。free -h は、残っているリソースを示します。この2つの出力は、コンテキスト設定、量子化方式、サーバー上で実行中のその他すべての処理をすでに反映しているため、公開されているどの表よりも実際のサーバーに即しています。

ディスク容量については、判断が簡単です。Linux では、Ollama は /usr/share/ollama/.ollama/models にモデルを保存します。ほとんどの VPS イメージでは、この場所は root ファイルシステム上にあります。40GB の root ボリュームでは、57 GB の bf16 ビルドを保存できません。8-bit タグを2つ並べて保存することもできません。何かを取得する前に、保存先をマウント済みのボリュームへ移動してください。

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 については、1つだけ明確にしておく必要があります。Swap を使用しても、より大きなタグを実行できるわけではありません。生成処理では、生成するすべてのトークンについて重みを参照します。そのため、Swap 上にある重みは繰り返しディスクから読み戻され、vmstat 1 では si 列と so 列が高い値になります。出力速度は、1トークンあたり数秒まで低下します。Out of memory 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 list

ollama list のサイズ列を自分で確認し、モデルページにある現在のタグ一覧と比較してください。公開済みのタグは追加、名前変更、削除が行われるため、ガイドに記載されたサイズは特定の日のスナップショットです。

依存しているサーバーでは、ollama pull muse-glimmer を絶対に使用しないでください。モデル名だけを指定すると latest タグに解決されます。latest は公開元が別のビルドを指すように変更できるポインターです。通常の pull によってエージェントの下でモデルが置き換わると、必要なメモリ量と動作が変わる可能性がありますが、ログにはその変更が通知されません。スクリプト、unit ファイル、エージェント設定にはタグを記述してください。サーバーの残りの設定については、VPS 上で Ollama を使用して LLM をセルフホストする方法を参照してください。

GPU なしで Muse Glimmer を実行できますか？

はい。ただし、性能の上限については率直に考える必要があります。1 トークンを生成するには、メモリからモデルの重みを読み出す必要があります。そのため、速度はプランがうたう vCPU 数ではなく、メモリ帯域幅で決まります。数個のコアを超えると、コアを増やしても性能はほとんど向上しません。共有 VPS では、その帯域幅をホスト上の他のすべてのテナントと共有します。そのため、4-bit の 30B モデルでは、1 秒あたりに生成できるトークン数は少なくなります。

この点について、私の数値も含め、他人の数値をそのまま受け入れないでください。自分のマシンで 1 秒あたりのトークン数を測定するで測定し、実際の結果に基づいて判断してください。

この結果、モデルが得意とする用途は明確に分かれます。対話型チャットは快適ではありません。サーバーが書き出す速度より読む速度のほうが速く、返信のたびに長い待ち時間が発生するためです。一方、バックグラウンドのエージェント処理には適しています。10 分間 unattended で実行するタスクなら、処理が遅くても問題にならないためです。Meta がこのモデルの用途として説明しているのも、まさにこの種の処理です。

対話型の速度が必要なら、現実的な選択肢は GPU またはホスト型 API です。何かをレンタルする前に、GPU VPS と API トークンの損益分岐点を計算するを確認してください。また、GPU VPS で実際に得られるものでは、何に料金を支払うのかを説明しています。特定のマシンで実行できるモデルの範囲については、どのモデルをセルフホストできるかから読み始めてください。このサイズ帯で最も近い比較対象は、VPS で同程度のサイズの Qwen モデルを実行するです。

なぜ 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 の設定を使用してください。

常時稼働エージェントのためにモデルをロードしたままにする

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 には認証機能がありません。OLLAMA_HOST=0.0.0.0:11434 を設定してノート PC から接続できるようにすると、認証のないモデルランナーがインターネットに公開されます。発見した第三者がディスクにモデルを読み込んだり、エージェントが送信した内容を読み取ったりできる状態になります。localhost にバインドしたまま、代わりにトンネルを使用してください。

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

Ollama API エンドポイントの保護では、認証情報を要求するリバースプロキシなど、適切な方法を説明しています。

何が問題になり、何が表示されるか

pull が途中で停止する。 ディスク容量の問題です。モデルディレクトリに対して df -h を実行します。57 GB の bf16 ビルドは 40GB の root ボリュームに収まりません。8-bit のタグを 2 つ並べて保存する場合も同様です。

モデルの読み込み後にプロセスが終了する。 メモリ不足です。dmesg -T で、カーネルの out of memory killer がプロセスを選択したことを確認できます。journalctl -u ollama -n 100 には、同じ事象をサービス側から見たログが表示されます。対処方法は、より小さいタグまたはより小さい num_ctx を使うことです。swap を増やしても解決しません。

1 トークンあたり数秒かかる。 vmstat 1 を実行し、si 列と so 列を確認します。swap が継続的に使用されている場合、重みが RAM に収まっていません。処理中に、システムがディスクから重みを読み戻しています。

先週動作したタグがなくなっている。 タグの一覧は変わります。モデルページをもう一度確認し、現在のタグを固定して、後で再確認できる場所にタグ名を記録します。

pull 前にサイズを自分で再確認する

表のサイズは 16 August 2026 にモデルのタグページから読み取ったものです。公開されているタグ一覧が保証されているわけではありません。モデルページで現在の一覧を確認し、実際にディスクへ保存されたサイズを確認します。

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

Ollama はモデルレイヤーを共有 blob として保存します。そのため、同じレイヤーを共有する 2 つのタグを保存しても、ディスク容量を 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 を実行し、processor 列を確認すると、処理がどこで実行されているかを確認できます。

Linux VPS では MLX タグを使えますか？

いいえ。名前に mlx を含むタグはすべて Ollama の MLX engine 用に構築されています。MLX は Apple Silicon 用のバックエンドです。x86 Linux サーバーでは、これらのタグをダウンロードしても実行できません。通常の 30b タグ、または MLX 以外のタグを使用し、MLX ビルドに対応する Apple ハードウェアのベンチマークは無視してください。

モデルが 128K トークンよりかなり前に情報を忘れるのはなぜですか？

Ollama のデフォルトのコンテキストウィンドウが、モデルの対応範囲にかかわらず 4096 トークンだからです。そのため、モデルが長い会話を受け取る前に、サーバーが切り詰めます。サーバーでは OLLAMA_CONTEXT_LENGTH を設定してください。1 セッションだけ変更する場合は /set parameter num_ctx を使用します。API リクエストの options には num_ctx を指定します。設定値を上げるとメモリ使用量も増えるため、段階的に増やし、その都度 ollama ps を確認してください。

タグを固定すべきですか、それとも latest を使えばよいですか？

固定してください。タグを指定せずに muse-glimmer を実行すると latest に解決されます。これは、公開元がいつでも別のビルドを指すように変更できるポインターです。そのため、通常の pull だけでエージェントが実行するモデルが変わる可能性があります。スクリプト、unit ファイル、エージェント設定には muse-glimmer:30b を記述してください。固定する前にモデルページでタグ一覧を確認してください。公開されているタグは変更されるためです。

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