LM Studio の検索画面から mlx-community/gemma-4-26b-a4b-it-4bit をダウンロードして、いざ Load を押した瞬間に Failed to load model と赤いダイアログが返ってきて、ログを見ても英語の長い stack trace しか出ていない、という状況に何度かハマりました。個人開発で運用しているアプリの写真分類処理を、API の課金を抑えながら手元で回したくて、Apple Silicon の MacBook Pro 上で Gemma 4 をオフライン側に寄せようと検証していた最中のことでした。ローカル LLM は「動けば速い」のですが、動かすまでの最初の一歩でつまずく人が多い領域だと感じています。
「Failed to load model」は単一の原因ではなく、私の手元では大きく 4 系統に切り分けられました。順番に潰していくと 30 分かからずに切り分け完了します。先に結論をまとめると、メモリ不足・モデルファイルの破損・ランタイム互換性・量子化レベルの不一致のいずれかです。
エラーが出た時にまず開くログの場所
LM Studio の Failed to load model ダイアログは多くの情報を隠しています。先に開いておきたいのが Developer タブの Console です。MacOS 版なら左サイドバーから Developer を選び、Console を開きっぱなしにしておくと、Load ボタンを押した時の本当の例外メッセージが流れます。
ログに頻出する判別キーワードは次の通りです。metal::CommandBuffer error はメモリまわり、ValueError: model file is corrupted はダウンロード破損、unsupported architecture: gemma3_text はランタイム互換性、mlx.core.array.shape mismatch は量子化版とメタデータの不一致を示します。エラー文中のキーワードを見れば、後述する 4 系統のどこを疑えばよいか即座に判断できます。
原因 1: メモリ不足（最頻出）
4bit 量子化版の Gemma 4 26B は、モデル自体のディスクサイズが約 16GB、ロード後のワーキングメモリ使用量が約 10〜12GB です。M シリーズ Mac はユニファイドメモリ構造のため、OS とブラウザと IDE を含む空きメモリが 14GB 以下になると、LM Studio が Metal バックエンドの確保に失敗します。
実機で踏んだケースでは、16GB MacBook Air で Chrome のタブを 40 個開いた状態で Load を押すと 100% 失敗、タブを 5 個まで減らすと成功、という再現性のある挙動でした。アクティビティモニタの「メモリ」タブで「使用済みメモリ」を確認し、Gemma 4 をロードする前に最低でも 14GB の空きを確保してください。
# ターミナルから空きメモリを確認する
vm_stat | awk '/free|wired|active|inactive|compressed/ { print }'
# Pages free が 概算で 3,500,000 以上あれば 14GB 以上の空きとみなせるOS バックグラウンドの Spotlight インデックス再構築（再起動直後の数十分間）も無視できないメモリ食いです。再起動直後にロードを試して失敗した場合は、15 分ほど待ってから再試行すると通ることがあります。
原因 2: モデルファイルのダウンロード破損
Failed to load model のうち、Developer Console に safetensors file is corrupted や header size mismatch が出ている場合、ダウンロードが中断したまま不完全なファイルが残っているケースが多いです。LM Studio はチェックサム検証を行わずに「ダウンロード成功」と表示してしまうことがあるため、再ダウンロードの判定は手動になります。
モデル保管場所は MacOS 版で ~/.cache/lm-studio/models/mlx-community/gemma-4-26b-a4b-it-4bit/ 配下です。.safetensors ファイルのサイズが想定値（4bit 26B 量子化なら 14〜16GB 前後）と大きく違う場合、欠損の可能性が高いです。
# モデルディレクトリのファイル一覧とサイズを確認
ls -lh ~/.cache/lm-studio/models/mlx-community/gemma-4-26b-a4b-it-4bit/
# .safetensors の合計サイズが 14GB 未満なら欠損疑い
du -sh ~/.cache/lm-studio/models/mlx-community/gemma-4-26b-a4b-it-4bit/欠損が疑われたら、LM Studio の Models タブから該当モデルを Uninstall して、再ダウンロードします。私の環境では、Wi-Fi が不安定な喫茶店で初回ダウンロードした時に必ず破損し、自宅の有線回線で取り直すと成功するパターンがありました。Hugging Face 側の CDN リトライ挙動と LM Studio のダウンロード再開ロジックの相性問題と思われます。
原因 3: MLX ランタイムのバージョン不一致
unsupported architecture: gemma3_text のような「アーキテクチャ未対応」エラーが出る場合、LM Studio に同梱されている MLX ランタイムが Gemma 4 のメタデータをサポートしていない世代である可能性が高いです。Gemma 4 の MLX 対応は 2026 年 4 月の LM Studio リリースで追加されたため、それ以前のバージョンでは Load に失敗します。
LM Studio のバージョン確認は、上部メニューの LM Studio → About LM Studio から行えます。0.3.18 以前で Gemma 4 MLX を試す場合は、まずアプリ自体を最新版にアップデートしてください。アップデート後、Runtime タブから MLX ランタイムも個別に更新が必要になることがあります。Runtime タブの MLX 行に Update available の表示があれば、必ず適用してから Load を再試行します。
ランタイム更新後に LM Studio を再起動するのを忘れがちです。私自身、更新だけ済ませて再起動を忘れて Load し、また Failed と表示されて 10 分溶かしました。MLX エンジンはアプリ起動時にだけ読み込まれるため、ランタイム更新後の再起動は必須です。
原因 4: 量子化版とメタデータの不一致
mlx.core.array.shape mismatch や tokenizer config not found が出る場合は、量子化版とメタデータファイルの組み合わせが壊れているケースです。コミュニティが配布している MLX モデルは、.safetensors（重み本体）と config.json / tokenizer.json / tokenizer_config.json などのメタデータをセットで揃える必要があります。
LM Studio が一部のファイルだけダウンロードして他をスキップしてしまった場合に発生します。Models タブで該当モデルを開き、ファイル一覧に tokenizer.json と tokenizer_config.json の両方が並んでいるかを目視確認してください。片方しかなければ、Uninstall → 再ダウンロードが手早い解決策です。
# 必要メタデータが揃っているかを確認
ls ~/.cache/lm-studio/models/mlx-community/gemma-4-26b-a4b-it-4bit/ | \
grep -E '^(config\.json|tokenizer\.json|tokenizer_config\.json|special_tokens_map\.json)$'
# 出力に 4 行揃っていない場合は再ダウンロード別パターンとして、別の量子化レベル（2bit 版と 4bit 版）を意図せず混在ダウンロードしてしまった場合も、shape mismatch を引き起こします。Models タブで重複インストールがないか確認してください。
原因切り分けの順序が重要
4 つの原因はどれも単独で起きますが、複数同時に起きることもあります。私が組んでいる切り分け順序は次の通りです。
最初にアクティビティモニタで空きメモリを確認し、14GB 未満ならアプリを閉じてから再試行します。これで通れば原因 1 です。通らなければ、LM Studio の Developer Console を開いて Load を再試行し、エラー文中のキーワードで原因 2〜4 のどれかを特定します。corrupted 系なら 2、unsupported architecture 系なら 3、shape mismatch や tokenizer 系なら 4 です。
この順序を守る理由は、メモリ不足が他の症状をマスクすることがあるためです。メモリが足りない状態で Load すると、たまたまファイルロードまで進んで shape mismatch のように見える誤検知が出る場合があります。先にメモリを確保してから再現させると、本当の原因が見えやすくなります。
復旧後に確認しておきたいパフォーマンス指標
無事に Load 成功したら、Gemma 4 MLX が本来のパフォーマンスを出せているかを確認しておくと安心です。私の M5 Pro 32GB MacBook Pro では、ベンチマーク用の短いプロンプト 200 トークンに対する応答が 38〜42 tokens/秒 前後で安定します。これが大きく下回る場合（20 tokens/秒以下など）は、メモリ圧迫で MLX が CPU フォールバックしている可能性があります。
LM Studio の Inference 画面で、応答速度（tokens/sec）の表示を有効にしておくと、Load 直後に異常を見つけやすくなります。Apple Silicon のユニファイドメモリは GPU と CPU が共有するため、空きメモリの量がそのまま推論速度に直結します。Gemma 4 を常用するなら、メモリ 32GB 以上の機種が体感としても圧倒的に快適です。
Load 前に 4 系統をまとめて確認する
毎回 Console を読みに行くのが面倒なら、Load を押す前に「空きメモリ・モデルの合計サイズ・メタデータの有無」を 1 つのスクリプトでまとめて確認しておくと、原因 1・2・4 を事前に潰せます。
#!/bin/bash
MODEL=~/.cache/lm-studio/models/mlx-community/gemma-4-26b-a4b-it-4bit
# 1) 空きメモリの概算（14GB 以上が目安）
PAGES_FREE=$(vm_stat | awk '/Pages free/ {gsub(/\./,"",$3); print $3}')
echo "空きメモリ概算: $(( PAGES_FREE * 16384 / 1073741824 )) GB"
# 2) モデルの合計サイズ（14GB 以上が正常）
du -sh "$MODEL" 2>/dev/null
# 3) メタデータ 4 点が揃っているか（出力が 4 なら正常）
ls "$MODEL" 2>/dev/null | grep -cE '^(config|tokenizer|tokenizer_config|special_tokens_map)\.json$'私はこれを precheck-gemma.sh として保存し、Load が通らない時にまず走らせる習慣にしています。3 つの数字を眺めるだけで、Console の stack trace を読み込む前に当たりがつくので、切り分けの初動がかなり速くなりました。
LM Studio を介さず mlx_lm で切り分ける
原因が LM Studio 側にあるのか、それともモデルファイルやランタイム側にあるのか判断がつかない時は、LM Studio を経由せずに mlx_lm から直接ロードしてみると一発で切り分けられます。
pip install mlx-lm
python -m mlx_lm.generate \
--model mlx-community/gemma-4-26b-a4b-it-4bit \
--prompt "ping" --max-tokens 8ここでも同じエラーが出るなら、原因はモデルファイルかランタイム（原因 2〜4）の側にあります。逆に、ここでは応答が返るのに LM Studio だけ Failed と出るなら、LM Studio のキャッシュや Runtime 設定の問題に絞り込めます。私の場合、mlx_lm では通るのに LM Studio だけ失敗したことがあり、Runtime タブの MLX を更新し直したら解消しました。切り分けの初手としてとても有効です。
次に試すこと
Gemma 4 の Load が安定したら、続いて気になるのが GGUF 版と MLX 版の応答速度差や、Gemini API との品質比較だと思います。M シリーズ Mac で MLX 版を使う場合のスループットは、私の環境では GGUF 版の約 1.4 倍でした。同じプロンプトで API 版と比較すると、長文生成では Gemini 3.2 Pro が有利ですが、短いタグ付けや分類処理は Gemma 4 ローカルでも遜色ない品質が出ます。
ローカル LLM はクラウド API と組み合わせるのが現実的です。同じ問題に取り組んでいる方の参考になれば嬉しいです。