※ この記事にはアフィリエイト広告が含まれることがあります。
14インチM5 Max MacBook Proを64GBのユニファイドメモリで使い始めてから、いくつかのローカルLLMと推論ツールを試してきました。 最初は、ローカルでどの程度の大きさのモデルを動かせるかに関心がありました。 実際に使ってみると、モデルが読み込めるか、何トークン毎秒で生成できるかだけでは、日常的に使えるかを判断できませんでした。
短い文章の要約や翻訳と、長い履歴を渡すコーディングエージェントでは、必要なメモリもモデルに求める能力も違います。 同じMLX対応のツールでも、Pythonを使うもの、RustやSwiftからMLXを呼ぶもの、推論サーバーとして必要な機能を備えるものがあり、使ったときの感触は同じではありません。
この記事は、2026年8月22日時点で試したことと、現在の使い分けを残すためのメモです。 厳密に条件をそろえたベンチマークではありません。
使用環境と確認した範囲
使用しているMacは、14インチM5 Max MacBook Proの64GBメモリ構成です。 ローカルLLMの主な用途として、自作のニュースリーダーNewzsnacによる記事の要約と翻訳、Claude Codeからローカルモデルを使うコード修正を試しました。
Newzsnacについては、64GBのM5 Max MacBook Proで、自分用ニュースリーダーを動かすにまとめています。 この記事では機能の説明を繰り返さず、推論環境を選ぶ過程と、コーディング用途との違いを中心に書きます。
Macで使える推論ツール
今回調べたツールを、モデル形式と実行経路で整理すると次のようになります。
| ツール | 主なモデル形式 | MLX | 主な実行経路 | Python | 今回の扱い | ||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| llama.cpp | GGUF | 使わない | C/C++からMetal | 不要 | LM Studio経由で使用 | ||||||||||||||||||||||||||||||||||||||||||||||||
| LM Studio | GGUF、MLX | 対応 | GGUFはllama.cpp、MLXはmlx-engine | MLX runtimeに同梱 | 使用 | ||||||||||||||||||||||||||||||||||||||||||||||||
| mlx-lm | MLX | 対応 | PythonからMLX、Metal | 必要 | 調査のみ | ||||||||||||||||||||||||||||||||||||||||||||||||
| MTPLX | MLX | 対応 | PythonからMLX、Metal | 必要 | 使用後に中止 | ||||||||||||||||||||||||||||||||||||||||||||||||
| mlxcel | MLX | 対応 | RustからMLX C++、Metal | 不要 | 使用 | ||||||||||||||||||||||||||||||||||||||||||||||||
| rMLX | MLX | 対応 | RustからMLX、Metal | 不要 | 調査のみ | ||||||||||||||||||||||||||||||||||||||||||||||||
| MLX Studio、vMLX | MLX | 対応 | Swift中心のネイティブ実装 | 構成による | 調査のみ | ||||||||||||||||||||||||||||||||||||||||||||||||
| mlx-swift-lm | MLX | 対応 | SwiftからMLX、Metal | 不要 | 調査のみ |
MLXはApple silicon向けの機械学習フレームワークです。CPUとGPUが同じメモリを参照できるユニファイドメモリを前提に設計されています。
MLX対応と書かれたツールは、最終的にはMLXとMetalを通じてGPUで計算します。 ただし、その上で動くサーバーやCLIがPython、Rust、Swiftのどれで作られているかによって、導入方法、常駐プロセス、キャッシュ、リクエスト処理などは変わります。 「MLXなので全部同じ」とは考えないほうがよさそうです。
llama.cppとLM Studio
llama.cppはGGUF形式のモデルを扱う推論エンジンです。Apple siliconではMetalを使えますが、MLXを経由するわけではありません。
LM Studioはモデルの検索、ダウンロード、読み込み、チャット、APIサーバーをGUIから扱えます。GGUFにはllama.cpp、MLX形式には別のruntimeを使う構成です。
LM Studioのmlx-engineは、mlx-lmとmlx-vlmを利用し、Python 3.11をruntime内に同梱しています。 利用者が別にPython環境を作らなくても動かせますが、内部までPythonを使わない実装という意味ではありません。
現在インストールしているLM Studioは0.4.21+2です。 GUIとローカルAPIをまとめて扱えるので、試した中では日常利用へ移しやすいツールでした。
mlx-lmとMTPLX
mlx-lmは、MLX上で言語モデルを生成、量子化、微調整するためのPythonパッケージです。MLXモデルを扱う基礎的な選択肢ですが、今回はPython環境を自分で維持する構成を増やしたくなかったため、単独では使い込みませんでした。
MTPLXはMLXモデルでMulti-Token Predictionを使い、先の複数トークンを予測して生成を速めるツールです。CLIとOpenAI互換サーバーを備えていますが、導入にはPython 3.11以降の仮想環境を使います。
実際に動かすと、PythonプロセスのCPUとメモリ使用量が気になりました。 GPU側の負荷やメモリの余裕も含め、私の環境ではLM Studioより扱いやすくなったとは感じられず、使用をやめました。 正確な版は記録しておらず、現在はアンインストールしています。
mlxcel
mlxcelはRustで作られたMLX推論サーバーです。Pythonを使わず、MLXのC++ APIを通じてMetalを利用します。 OpenAI互換APIを備え、MTPによる投機的デコードにも対応しています。
Pythonを常駐させずにMLXモデルを配信できる点に関心を持ち、Ornith-1.5-35B-A3B-MLX-6bitとQwen3.8-27B-MLX-6bitを試しました。 執筆時点で手元にある版は0.5.2です。
短い入力では動作しましたが、Claude Codeの長い会話履歴を渡したときに、後述する大きなメモリ確保で行き詰まりました。 実装言語がRustであることと、長いコンテキストを少ないメモリで処理できることは別の問題でした。
rMLX、MLX Studio、mlx-swift-lm
rMLXもRust製のMLX推論サーバーで、単一の実行ファイルからOpenAI互換APIとAnthropic互換APIを提供します。Pythonを必要としない構成は魅力的でしたが、今回は実際の運用までは進めていません。
MLX Studioと、そのサーバー部分であるvMLXは、SwiftとMetalを中心にMac向けの推論環境を構成しています。従来のPython経路も残っており、すべてが同じ実行方式ではないため、利用する機能ごとの確認が必要です。
mlx-swift-lmは、SwiftアプリへMLXの言語モデルや視覚言語モデルを組み込むためのパッケージです。汎用のローカルサーバーをすぐ起動する道具ではなく、自分のアプリに推論機能を組み込む場合の選択肢です。
LM Studioの生成速度ログ
LM Studioでモデルを動かしながら、生成速度をターミナルで確認する方法も調べました。 lms log stream --source model --filter output --statsでは、私が使っている経路の出力を確認できませんでした。
実際に生成速度が出ていたのはruntimeのログです。
lms log stream --source runtime \
| grep -E 'eval time|tokens per second' \
| grep -v 'prompt eval'
ここに出るtokens per secondは、一回のモデル呼び出しで生成したトークン数を生成時間で割った平均です。 Newzsnacの処理全体を通した瞬間的な速度ではありません。 処理同士を比較するときは、プロンプトの長さや生成トークン数も一緒に見ないと判断を誤ります。
LM Studioのログ機能については、CLIの資料にも出力元とフィルターの説明があります。
Claude Codeとローカルモデル
LM StudioはAnthropic互換の/v1/messagesを提供しており、Claude Codeから接続する方法も案内しています。 シェルでANTHROPIC_BASE_URLとANTHROPIC_AUTH_TOKENを設定すれば、Claude CodeのリクエストをローカルのLM Studioへ向けられます。
私の環境では~/.claude/.に書いただけでは読み込まれませんでした。 シェルの環境変数か、env~/.claude/settings.jsonのenvへ設定する必要がありました。 コンテキストと出力の上限には、次の値を使いました。
CLAUDE_CODE_MAX_CONTEXT_TOKENS=65535
CLAUDE_CODE_MAX_OUTPUT_TOKENS=8192
Qwen3.8のchat template
Qwen3.8-27BをLM Studioで使ったときは、System message must be at the beginningというエラーになりました。 Claude Codeは会話の途中にもsystemメッセージを挿入しますが、使用したQwenのchat templateは先頭以外のsystemメッセージを許していませんでした。
モデル自体の能力や速度とは別に、コーディングエージェントが組み立てるメッセージ列をchat templateが処理できる必要があります。 OpenAI互換やAnthropic互換のAPIが起動しただけでは、エージェントとの互換性までは確認できません。
Ornith 1.5
そこで、Claude Codeでの利用を想定したOrnith 1.5 35B-A3Bを試しました。 約35Bのパラメーターを持つMoEモデルで、一つのトークンを生成するときに使うパラメーターは約3Bです。 モデルカードにはClaude Codeを使った評価があり、chat templateにもClaude Code向けの変更が含まれています。
LM Studioでは、まずGGUFのQ6_Kを65535トークンのコンテキストで読み込みました。 読み込み後のシステム全体のメモリ使用量は48GB前後になり、Claude Codeでシステム関連の処理を始めるとmacOSのメモリプレッシャーが「上昇」に変わりました。
Q6_Kのモデルファイルは約28.5GB、Q5_K_Mは約24.7GB、Q4_K_Mは約21.2GBです。 Q5_K_MならQ6_Kより約3.8GB小さくなるため、現在は精度を極端に下げずに余裕を増やす構成としてQ5_K_Mを選んでいます。
mlxcelと長いコンテキスト
mlxcelでは、次のような設定でOrnithのMLX 6bit版を起動しました。
mlxcel serve \
-m ornith-ai/Ornith-1.5-35B-A3B-MLX-6bit \
--host 127.0.0.1 \
--port 1234 \
--ctx-size 131072 \
--n-predict 8192 \
--draft-kind mtp \
--draft-max 3
Claude Codeの履歴が約36,000トークンに達した状態では、Metalの単一バッファー確保に失敗しました。 Ornithでprompt_len=36794のときは43,309,776,672バイトを確保しようとして、上限の41,747,087,360バイトを超えています。 Qwen3.8-27B-MLX-6bitでは、prompt_len=36478で63,853,426,992バイトを要求していました。
--parallel 1、--no-batch、--no-prompt-cacheを指定し、--prefill-chunk-sizeを512、さらに256へ下げても、要求される単一バッファーの大きさは減りませんでした。ログ上ではhistory_boundary_prefillの処理中に失敗していました。
この結果から、会話履歴全体に対応するモデル状態か中間データが、一度に実体化されている可能性を考えています。 内部実装を追って確定した原因ではなく、設定変更とログからの推測です。
多くの場合はHTTP 500が返って処理だけが終了しましたが、何度かはMac全体が固まり、画面が緑色になった後に再起動しました。 panicログまでは確認していないため、OSの再起動を起こした原因がmlxcel、Metal、macOSのどこにあるかは断定できません。 少なくとも、64GBのMacで約36,000トークンの履歴を渡す現在の構成は、普段使いできる状態ではありませんでした。
Ornithによるコード修正
長いコンテキストを渡せるかとは別に、生成されたコードをそのまま採用できるかも確認しました。 Ornithには、並行するAIコーディング作業を管理するEveresのhook修正を依頼しました。
LM Studioで起動したornith-1.5-35b-a3b@q5_k_mをContextは262144に設定してClaude Codeを使って書かせました。
基本となるhookの二重登録対策は成立しており、Goのテストもすべて通りました。 しかし、1回目のコードレビューは散々でした。
リリース用URLが誤っていてインストーラーが失敗する、CLIは最新版を取得するのにAPM側の版が0.2.0へ固定されている、APM manifestのバージョン表記が仕様と異なる、といった問題が残っていました。 手動実行したworkflowからmainという名前のリリースを作れること、生成したchecksumをインストール時に検証していないこと、完了確認で想定しているAPMのmetadataファイル名が実際と違うこともレビューで見つかりました。
テストが通り、変更の中心部分がもっともらしく見えても、配布と更新を含む一連の動作は壊れていました。 レビュー後の確認と修正にかかる時間まで含めると、現在このMacで動かせるモデルにリポジトリ全体へ関わるコードを書かせるのは効率がよくありません。
小さく区切れて、期待する結果を自動テストで十分に確認できる変更なら使える場面はありそうです。 一方、パッケージ管理、配布、CI、複数ツールの仕様が関係する変更は、強いクラウドモデルへ任せたほうが早いと考えています。
Newzsnacで使う構成
Newzsnacが行う記事の要約、翻訳、KEY POINTSの抽出、分類では、ローカルLLMで困っていません。 入力と期待する出力を限定しやすく、生成結果を読めばおかしな点にも気づけます。 大量の記事を外部APIへ送り続けずに処理できる利点もあります。
当面はLM Studioでornith-1.5-35b-a3b@q5_k_mを起動し、Newzsnacから使い続けるつもりです。Contextは65535です。 Ornithを選ぶ理由はコード生成能力だけではなく、手元で安定して起動でき、必要な日本語の要約と翻訳をこなせるためです。 LM Studioを選ぶ理由は、モデルの管理とAPIサーバーが一つにまとまり、GGUFのllama.cpp経路を日常的に扱いやすいためです。
2026年8月22日時点の使い分け
64GBのM5 Max MacBook Proでは、27B級や35B MoEの量子化モデルを動かし、実際のアプリから継続して利用できます。 その一方で、モデルを読み込めることと、長い会話履歴を安全に処理できること、コード修正を任せて作業時間を短くできることは別でした。
現在の使い分けは次のとおりです。
Newzsnacの要約と翻訳には、LM StudioとOrnith 1.5 35B-A3BのQ5_K_Mを使います
モデルや推論方式を調べるときはMLX系ツールも試しますが、常用環境はLM Studioへ戻します
Claude Codeをローカルモデルへ接続する実験は続けられますが、長い履歴とメモリ使用量には注意が必要です
リポジトリ全体に関わるコード修正は、現時点では強いクラウドモデルを使います
Claude Codeからも動作するornith-1.5-35b-a3bで
Everesの動作確認のため、ローカルでCodexとClaude Codeが動作すると良いです。Codexは有料プランを契約しているのですが、Claude Codeは現在はFreeプランです。2つのAIエージェントをまたがってタスク管理の検証を行うため、Claude Codeが動く状態を維持するため、ornith-1.5-35b-a3bを使います。
※ 処理が始まってすぐは80tokens/s以上出る瞬間もありますが、続けて記事を処理していると悪い時は20tokens/sまで速度が落ちます。GPUのサーマルスロットリングにより1.6GhzのGPUが400Mhz程度に抑えられてしまうためです。熱対策がうまくいけばだいぶ高速に動作するのでは無いかと思います。とはいえ、やはりクラウドの商用サービスとはダンチで遅いです。
所感
ローカルLLMが使えないわけではありません。 要約や翻訳にはすでに日常の道具として使えますが、コーディングではレビューと手戻りを含めると時間を節約できませんでした。 用途を分けることが、今の64GBのMacで無理なく使い続けるための答えになっています。