すべてのMacユーザーがこの新しいAIモデルランナー（oMLX）を導入すべき理由
BBetter Stack
Computing/SoftwareConsumer ElectronicsInternet Technology
Transcript
00:00:00こちらがOMLXです。非常にエキサイティングなプロジェクトで、要するに
00:00:06Appleシリコンの性能を極限まで引き出すために設計された、専用の推論エンジンです。
00:00:11Macユーザーなら、きっとワクワクするはずです。OMLXは基本的に、
00:00:16ローカルハードウェアにおける最大のボトルネックである「メモリ税」の解決を試みています。
00:00:21この動画では、OMLXの概要と仕組みを解説し、実際にテスト走行を行って、
00:00:27有力な競合であるLM Studioと比較し、この新しいツールがMacでローカルAIモデルを
00:00:33動かす未来になり得るかを見ていきます。楽しい内容になるので、早速始めましょう。
00:00:39では、OMLXとは一体何でしょうか？核心部分を言えば、Appleの
00:00:49MLXフレームワーク上に特別に構築されたランタイムです。あらゆるGPUをサポートしようとする汎用ツールとは異なり、
00:00:55MLXはAppleシリコンチームによって、Macを支える「ユニファイドメモリアーキテクチャ」を
00:01:02活用するために専用設計されています。従来のPCでは、CPUとGPUに個別のメモリプールがあり、
00:01:09モデルの重みのようなデータは、常にPCIバス経由でやり取り（コピー）されなければなりません。
00:01:16しかしMLXは、そのコピーを完全に排除します。CPUとGPUが全く同じ物理メモリを共有しているため、
00:01:22MLXは「ゼロコピー配列」を使用します。GPUが計算を終えると、CPUは1バイトも動かさずに
00:01:29即座に結果を読み取れます。また、「遅延計算」も採用しており、
00:01:36出力が必要になる最後の瞬間まで、実際の計算処理を実行しません。
00:01:41これにより、計算グラフ全体を動的に最適化できるのです。しかし、OMLXが標準的な
00:01:47LM Studioの設定と異なるのは、KVキャッシュの管理方法です。一般的なLLMのセッションでは、
00:01:54会話履歴のすべての単語を、高価なRAMに記憶しておく必要があります。しかしOMLXは、
00:02:012層システムを導入しています。即時のコンテキストは速度のためにユニファイドメモリに保持しますが、
00:02:07会話の古い部分、例えば膨大なシステムプロンプトやツール定義などは「フリーズ」させ、
00:02:12SSDにスワップします。LM Studioと比較すると、その差は歴然です。LM Studioは
00:02:19非常に安定しており互換性も高いですが、問題はメモリ履歴全体を常にアクティブな状態で保持しようとすることです。
00:02:23OMLXは、よりモダンなOSに近い動きをします。どのデータが今「脳内（RAM）」に必要で、
00:02:30どれをディスクにページング（退避）できるかを賢く判断するのです。では、実際にOMLXを
00:02:36起動して試してみましょう。インターフェースは非常に直感的です。まず最初に、
00:02:41サーバーの設置場所を指定して、すぐに起動できるウィンドウが表示されます。その後、
00:02:47APIキーの入力を求められるので、入力します。そしてついに、
00:02:53OMLXサーバーのメインエントリポイントであるダッシュボードにたどり着きます。ここから、
00:03:00今回のテストで使用する「Qwen 3.6 35B 4-bit」モデルをダウンロードしました。
00:03:07また、空のリポジトリと「agents.md」ファイルを用意しました。ここでモデルに、
00:03:13映画を検索し、ウィッシュリストに追加し、Movie DBのAPIキーを使って評価できる
00:03:19シンプルなウェブアプリの作成を依頼します。デモ用なので複雑なものではなく、
00:03:24実際のコーディングタスクでどれほどのパフォーマンスを発揮するかを確認するための単純なテストです。ダッシュボードには、
00:03:31実行可能な様々なAIエージェント・ハーネス用の、すぐに使えるコードスニペットが用意されています。
00:03:37今回のデモでは、テストを実施するために「Codex CLI」を使用します。
00:03:42なぜ公式の「Claude Code CLI」を使わないのか不思議に思うかもしれませんね。実は、
00:03:47MacBook M2では、1トークンも無駄にできません。Claude Codeのコンテキスト統計を
00:03:54全くの白紙状態で確認すると、自身のシステムプロンプトとツール定義だけで約16.2Kトークンも消費します。
00:04:0232Kのウィンドウでは、実際のプロジェクトに使えるのはわずか16Kトークンしか残らず、
00:04:09フルスタックアプリを構築するにはあまりに少なすぎます。一方で、
00:04:14Codexははるかに軽量であることが分かりました。会話のベース重量を圧迫しないため、
00:04:20コンテキストの上限に達する前に、コードを書くための余裕（ランウェイ）を十分に確保できます。
00:04:26よし、それではここに記載されているシンプルなコマンドでCodexを起動しましょう。
00:04:31次に、タスクを説明する簡単なスタートアッププロンプトを入力して、実行します。
00:04:36右側で処理が進んでいく様子から、このセッションのパフォーマンスをリアルタイムで確認できます。
00:04:42生成されているトークン数、キャッシュされている数、
00:04:46そして全体のキャッシュ効率のパーセンテージが表示されています。また、1秒間に平均
00:04:51何トークンが処理されているかが見れるのも非常に便利です。さて、私のM2 MacBook Proで
00:04:57この非常に重い35BのQwen 3.6モデルを動かして、タスク完了までに約20分かかりました。
00:05:04このモデルにとって非常に大きな負担であることを考えれば、これは予想通りの結果です。
00:05:10ただ、プロンプトがM2 MacBookの30Kコンテキスト制限を超えてしまい、
00:05:17400エラーが2、3回発生しました。他のツールであれば、プロジェクトが完全に詰んでしまう場面です。
00:05:24通常「/clear」を実行するとAIの短期記憶が消去され、モデルが直前に書いたコードを忘れて
00:05:29ハルシネーション（幻覚）を起こしがちです。しかし、ここでOMLXの永続的なSSDキャッシュに驚かされました。
00:05:37Codexでセッションをクリアしても、プロジェクトの実際の計算状態は
00:05:42依然としてSSDに残っていました。そのため、Codexに続きから作業するように新しいプロンプトを与えた瞬間、
00:05:48OMLXはプレフィックス（接頭辞）を認識し、ディスクからモデルの「脳」を即座に復元（ハイドレート）したのです。
00:05:56ハルシネーションを起こしたりゼロからやり直したりすることなく、中断したところから正確に再開しました。
00:06:02このケースでは、キャッシュ効率が本当に役立っています。最終的に、OMLXの助けを借りた
00:06:08Qwen 3.6は、178万トークンを生成してタスクを完遂しました。そのうち
00:06:16約159万トークンがキャッシュされていました。つまりキャッシュ効率は89%で、これは驚異的です。
00:06:22出来上がったアプリ自体も、かなり良い出来です。映画を検索し、ウォッチリストに追加し、
00:06:28評価することができます。ただし、ページを更新するとウォッチリストがリセットされてしまいました。
00:06:33データベースの保存ソリューションが正しく実装されなかったようですが、全体としては素晴らしい成果です。
00:06:40ここまでは印象的ですが、LM Studioのような重量級のモデルランナーと比べて
00:06:46パフォーマンスがどう違うのかを確かめたくなりました。そこで、同じQwen 3.6モデル、
00:06:52同じコンテキストウィンドウと制約を使用して、全く同じタスクを実行してみました。正直なところ、
00:06:58予想外の結果でしたが、LM Studioの方がパフォーマンスが悪かったのです。
00:07:04タスク完了までに約35分かかりました。OMLXよりもすでに15分多くかかっています。
00:07:11また、実行中にLM Studioは私のMacBookのリソースを使い果たしていました。
00:07:17深刻なメモリ不足で動作が重くなり、サブモニターで動画を見ることすらできないほどでした。
00:07:23OMLXではそのような問題は起きませんでした。Codexがバックグラウンドで
00:07:30動作している間も、ウェブ閲覧や動画視聴などの他の作業を快適に行うことができました。
00:07:35LM Studioでは、それはほぼ不可能でした。そして、この統計を見てください。
00:07:41さらに驚いたのは、1秒あたりの平均トークン生成速度がLM Studioでは16トークンだったのに対し、
00:07:47OMLXでは約47トークンでした。これでタスク完了に15分の差が出た理由が説明できます。
00:07:55ただ、公平を期すために言うと、LM StudioはOMLXのように
00:08:01コンテキスト制限による400エラーを一回も出しませんでした。LM Studioのコンテキスト管理は
00:08:08非常に安定しており、完璧に動作していました。最終的な結果も、非常に似たものでした。
00:08:13派手なアニメーションこそありませんでしたが、正直なところ、同じモデル・同じタスクで
00:08:18シード値が違うだけの同じ出力を見ているような感覚です。ですから、ここで結論を急ぐつもりはありません。
00:08:25どちらもQwen 3.6ですからね。Qwenのモデル出力については、皆さんが判断してください。
00:08:33さて、最終的な評価はどうでしょうか？OMLXのパフォーマンスには非常に、非常に感銘を受けました。
00:08:39もしRAMの限られたMacBookを使っていて、バックグラウンドでローカルAIエージェントを動かしつつ、
00:08:45パソコンで他の作業もしたいのであれば、OMLXは最適なツールです。高速なSSDと、
00:08:52Appleシリコンでモデルをよりスムーズに動かせるMLXフレームワークを組み合わせることで、
00:08:58実質的にRAMを拡張してくれます。確かに、たまに発生する400エラーへの対処として、
00:09:05時々クリアコマンドを手動で打つ必要はあります。しかし、生成速度が3倍になることを考えれば、
00:09:10十分に受け入れられるトレードオフだと思います。OMLXのようなプロジェクトは、
00:09:16強力なエージェントを動かすために必ずしも128GBのRAMが必要なわけではないことを証明しています。
00:09:23必要なのは、今あるMacBookのメモリをより賢く管理する方法なのです。
00:09:29数ヶ月前にアンケートを実施したところ、視聴者の多くがMacユーザーであることが分かりました。
00:09:34皆さんは自分のマシンでOMLXを試してみましたか？使い心地はどうでしょうか？
00:09:40下のコメント欄でぜひ教えてください。以上、OMLXの概要でした。
00:09:45このような技術的な解説が気に入っていただけたら、動画の下にある
00:09:50高評価ボタンを押して知らせてください。チャンネル登録もお忘れなく。
00:09:55Better StackのAndrisでした。また次の動画でお会いしましょう。