MacでMuse Glimmer MLXを動かす：SGLangバックエンドのセットアップガイド

Metaが2026年8月10日にオープンウェイトの高密度マルチモーダルモデル「Muse Glimmer 30B」を公開した直後、Macで試そうとした人の多くが同じエラーに遭遇しました。アーキテクチャが既存ローダーには新しすぎたため、複数のMLXランタイムで model type muse_glimmer not supported が出ていたためです。

現時点で動作させる手段の一つが、SGLangのMLXバックエンドです。ソースからのビルド、Python 3.11の固定、そして環境変数を一つ設定する必要があります。起動後はOpenAI互換APIとして公開されるため、コーディングエージェントやチャットフロントエンドからそのまま接続できます。この記事では、SGLangのロードマップissue #19137にある手順と対処法を、一通り実行できる形にまとめます。

始める前に確認したい要件

Muse Glimmer 30Bは、300億パラメータの高密度マルチモーダルモデルです。MLXの4ビット量子化では、重みだけでおよそ16～18 GBを使います。さらに32Kトークンのコンテキストウィンドウ向けKVキャッシュを含めると、必要なワーキングメモリは約18～20 GBです。SGLangのロードマップではMetalの推奨最大ワーキングセットサイズでメモリ使用量を制限しています（PR #21539）。そのため、実際に使える上限はMacのユニファイドメモリ総量より低くなります。

ウェイト公開時、r/opencodeCLIのRedditユーザーも次のように述べています。

「ユニファイドメモリが32 GB以上のMacなら、より高い量子化でも実用になりそうです。」

このほか、Metal対応のためmacOS 13.5以降、Xcode Command Line Tools、Homebrewが必要です。SGLangのMLXバックエンドで検証済みなのはPython 3.11のみです。ロードマップでも、ほかのバージョンでは問題が起きることが明記されています。

手順1：Python 3.11、uv、MLXを準備する

MacでSGLangを使うには、まずHomebrewパッケージを二つ導入し、uvでPython 3.11の仮想環境を作成します。

1. Homebrewの依存パッケージを入れる

brew install ffmpeg uv

ffmpegは音声を含むマルチモーダル処理パイプラインで使われます。uvは、SGLangのロードマップでも仮想環境作成に推奨されている高速なPythonパッケージマネージャーです。

1. SGLangリポジトリをクローンする

git clone https://github.com/sgl-project/sglang.git
cd sglang

1. Python 3.11の環境を作成して有効化する

uv venv -p 3.11 my-venv
source my-venv/bin/activate
python -m pip install --upgrade pip

Python 3.12や3.13は使わないでください。ロードマップissueによると、Python 3.12以降ではTritonスタブのインポートが壊れます（PR #21551で修正済みですが、完全な検証は未完了）。また、MLXのコンパイルチェーンでテストされているのも3.11だけです。

1. MLXランタイムを最新版へ更新する

pip install mlx mlx-lm mlx-vlm --upgrade

ロードマップでは、古いmlxやmlx-lmが大量のプロファイリングログやアーキテクチャ検出の失敗を招くと注意されています。PR #22162では、これらがSGLangの明示的な依存関係に追加されました。Muse Glimmerのようなマルチモーダルモデルにはmlx-vlmも必要です。これがないと、起動時にmodel type muse_glimmer not supportedが発生します。

手順2：MLXバックエンド対応のSGLangをソースからビルドする

通常のpip install sglangパッケージにはMLX対応が含まれていません。Apple MPS用のextrasを指定し、ソースからビルドする必要があります。

1. pyproject.tomlを差し替える

cp python/pyproject.toml python/pyproject.toml.bak
cp python/pyproject_other.toml python/pyproject.toml

pyproject_other.tomlでは、macOSでビルドに失敗するCUDA専用依存関係を外し、MPS互換の代替パッケージに置き換えます。

1. MPS extrasを指定して編集可能モードでインストールする

uv pip install -e "python[all_mps]"

これによりMetalカーネルスタブがコンパイルされ、Apple Silicon向けランタイムパスが導入されます。ビルドにはMacの性能に応じて数分かかります。最も時間がかかるのはsgl-kernelのMetalビルド（PR #23449）です。

1. インストールを確認する

python -c "import sglang; print(sglang.__version__)"

Tritonエラーなしでインポートできれば、MPSパスは正しく設定されています。

手順3：Muse GlimmerのMLXモデルをダウンロードする

MLX Communityは、Hugging FaceでMuse Glimmerの4ビット量子化版を公開しています。

huggingface-cli download mlx-community/Muse-Glimmer-30B-4bit

huggingface-cliが未導入なら、先に以下を実行します。

pip install huggingface-hub

ダウンロードサイズは約16～17 GBです。標準ではhuggingface-cli downloadがモデルを~/.cache/huggingface/hub/以下に保存します。SGLangの--model-pathにはHugging FaceのリポジトリIDを直接指定できますし、ローカルキャッシュのディレクトリを指定しても構いません。

必要メモリの目安

つまり、32 GBのMacでもモデル自体は読み込めますが、大きなコンテキストウィンドウに割ける余裕は限られます。サーバーは起動するのに最初の長いプロンプトで落ちる場合は、--context-lengthを8192または16384へ下げてください。

手順4：SGLangサーバーを起動する

依存関係の導入とモデルのダウンロードが済めば、起動コマンドは1本です。ただし、環境変数の指定が重要です。

SGLANG_USE_MLX=1 python -m sglang.launch_server \
  --model-path mlx-community/Muse-Glimmer-30B-4bit \
  --port 30000 \
  --context-length 32768

各オプションの役割

• SGLANG_USE_MLX=1は、PyTorch MPSやCPUへフォールバックさせず、ネイティブのMLX実行バックエンドを有効にします。このフラグがない場合もサーバーは起動しますが、速度は大幅に落ちます。
• --model-pathにはMLX形式の4ビットモデルを指定します。SGLangのPR #25191でMLX形式のquantization_configを自動検出する仕組みが追加されているため、追加フラグなしで形式を認識するはずです。
• --context-lengthは最大コンテキストウィンドウを制限します。メモリ不足の兆候があれば値を下げてください。コミュニティテストとMetaのリリースノートによれば、Muse Glimmerは理論上262Kトークンまで対応しますが、ユニファイドメモリを使うMacでの実用上限ははるかに低くなります。

上級者向け：SGLangは--quantization mlx_q4またはmlx_q8を使い、BF16重みから起動時に量子化することもできます（PR #24907）。事前構築済みの4ビットモデルを読み込むより起動に時間がかかるため、量子化プロセスを自分で制御したい場合だけ使うとよいでしょう。

手順5：OpenAI互換APIで動作を確認する

サーバーにServer is readyと表示されたら、OpenAI互換エンドポイントへcurlリクエストを送りましょう。

curl http://localhost:30000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "muse-glimmer",
    "messages": [
      {"role": "system", "content": "You are a helpful assistant."},
      {"role": "user", "content": "Explain how GQA reduces KV cache size in one sentence."}
    ],
    "max_tokens": 200
  }'

成功すれば、補完結果を含むJSONオブジェクトが返ります。SGLangロードマップのベンチマークデータでは、M5 Proで4ビットモデルを単一ユーザー向けにデコードした場合、およそ17.6 tokens/secondが目安です。

重要：max_tokensは余裕を持って200以上にしてください。Muse Glimmerは推論を先に行う設計で、chain-of-thoughtトークンが出力予算の多くを消費することがあります。出力が空に見える、あるいは途中で切れる場合、最も多い原因はmax_tokensが小さすぎることです。回答が現れる前に推論が予算を使い切ってしまいます。

MLX向けチューニング変数の使い分け

SGLangには、公式の環境変数リファレンスに記載されたMLX専用の環境変数が三つあります。いずれも初期値では無効、または控えめな設定です。

チューニングを有効にした起動例です。

SGLANG_USE_MLX=1 \
SGLANG_MLX_USE_CUSTOM_ROPE=true \
SGLANG_MLX_FUSE_SWIGLU=true \
SGLANG_MLX_CLEAR_CACHE_STEPS=128 \
python -m sglang.launch_server \
  --model-path mlx-community/Muse-Glimmer-30B-4bit \
  --port 30000 \
  --context-length 32768

これらはロードマップ上では実験的機能です。いずれかのカーネル統合フラグを有効にしてクラッシュする場合は、無効に戻してレポートを送ってください。MLXバックエンドは現在も活発に開発されています。

よくあるエラーと対処法

「Model type muse_glimmer not supported」と表示される

公開初日に最も多かったエラーです。MLXランタイム（mlx-lmまたはmlx-vlm）がmuse_glimmerアーキテクチャを認識していないことを意味します。まずは更新してください。

pip install mlx-lm mlx-vlm --upgrade

それでも解決しない場合、SGLangのチェックアウトにQwen3 dense向けMLXサポートのPR（#25754）が入っているか確認します。このPRでは高密度Transformerモデル向けのアーキテクチャ書き換えが追加されました。必要なアーキテクチャ対応を取得するため、git pullで最新のmainブランチへ更新する必要があるかもしれません。

Python 3.12でTritonスタブがクラッシュする

SGLangのセットアップは、Python 3.12以降と互換性のないTritonスタブをインポートします。Python 3.11で仮想環境を作り直すのが解決策です。

deactivate
rm -rf my-venv
uv venv -p 3.11 my-venv
source my-venv/bin/activate
uv pip install -e "python[all_mps]"

PR #21551でTritonのインポートパスは修正されていますが、完全に検証済みなのは依然としてPython 3.11だけです。

サーバーは起動するがCPUで動いている

トークン生成が極端に遅い、具体的には2 tokens/second未満なら、SGLANG_USE_MLX=1をexportしていないためSGLangがCPUへフォールバックしている可能性があります。以下で確認します。

echo $SGLANG_USE_MLX

何も返らない場合は、サーバーを起動する前にexportするか、起動コマンドの先頭に環境変数を直接付けてください。

MLXのメモリクラッシュ、またはシステム再起動

Metalの推奨ワーキングセットサイズを超えると、サーバーがクラッシュします。深刻な場合にはmacOS全体が再起動することもあります。ロードマップではPR #21539でワーキングセット上限を導入し、この問題の軽減を図っています。ただし、大きなコンテキストウィンドウでは依然として上限を超える可能性があります。対処法は次のとおりです。

• --context-lengthを8192以下に下げる
• SGLANG_MLX_CLEAR_CACHE_STEPS=64を設定し、より頻繁にキャッシュをクリアする
• BF16重みからの起動時量子化ではなく、4ビットモデルを使う
• GPU負荷の高いほかのアプリケーションを閉じる。特にハードウェアアクセラレーションを有効にしたSafariには注意する

ツール呼び出しがループする、または結果が空になる

r/LocalLLaMAのコミュニティスレッドでは、Muse Glimmerのツール呼び出しは量子化方式によって挙動が安定せず、MLX版とGGUF版の両方を試したユーザーからツール呼び出しループが報告されています。これはMLX固有の問題ではなく、ランタイムをまたいで見られる現象です。function callingを使う際はmax_tokensを500以上に設定し、まずは単発呼び出しのワークフローで試してください。信頼性の高いツール呼び出しが最優先なら、Qwen 3.6 27Bを検討する価値があります。

FAQ

SGLangのMLXバックエンドはMuse Glimmerで推測デコーディングに対応している？

まだ対応していません。SGLangのロードマップではEAGLEの推測デコーディングが予定項目として挙げられていますが、MLXバックエンドには未実装です。Macでは、ロードマップの議論にあるベンチマークデータ上、標準的な自己回帰デコーディングに限られ、速度はおよそ17.6 tokens/second（M5 Pro、Q4）です。

Mac上のMuse GlimmerはMLXとGGUFのどちらを選ぶべき？

MLXはApple Siliconのネイティブパスです。Metalを直接利用し、明示的なCPU-GPU間コピーなしにユニファイドメモリの恩恵を受けられます。MLXランタイムがmuse_glimmerのアーキテクチャをサポートしていない場合は、llama.cpp経由のGGUFが代替手段になります。主な選択肢はMLX Communityの4ビット版と、Hugging Faceで入手できるUnslothのGGUF版です。MLXは動作しさえすれば一般にデコードが速く、GGUFはLM StudioやOllamaなど幅広いツールと互換性があります。

サービング用途では、SGLang MLXはmlx-lmやOllamaとどう違う？

SGLangは、OpenAI互換APIサーバーに加え、radix cachingと前述のチューニング変数を提供します。mlx-lmはよりシンプルで、少ない設定でモデルのロードとテキスト生成ができますが、サーバー抽象化はありません。r/LocalLLMでは、独自のAPIレイヤーを持つOllamaのmuse-glimmer:30b-mlxタグを使ったという報告もあります。OpenCode CLIのようなコーディングエージェントにそのまま接続できるAPIが必要なら、実用的な選択肢はSGLangまたはOllamaです。短い一回限りの生成なら、mlx-lmで十分です。