MacではOllama経由でMLX Frameworkを使用します。qwen38-deepモデルは32kトークンのコンテキストにRAM 21GBが必要です。エイリアスの設定とKVキャッシュの監視を推奨し、モデルの自動アンロードを防ぎます
環境準備とTerminal経由でのインストール
MacでQwen3を使用するには、Ollama経由でのインストールを選択しました。これはAppleのMLX Frameworkを最もよくサポートするツールだからです。まずOllamaをインストールし、qwen38-chatモデルをテスト用に取得します。私のシステムチェックでは、このモデルのAPIバージョンは200ステータスを正常に返すことが確認されており、ローカルホストとモデル間の接続が完全に機能していることを示しています。より深い推論能力が必要な場合は、qwen38-deepモデルを取得することを推奨します。リソース使用量は増えますが、技術的なタスクでより正確な結果をもたらします。Terminal経由での使用は動作ログを明確に表示し、これらの詳細を隠す一部のGUIよりも問題をデバッグしやすくします。公式サイトからダウンロードしてインストールできます。
VRAMとコンテキストウィンドウの適切な管理
Appleのユニファイドメモリシステムを使用するMacでのメモリ管理は非常に重要です。CPUとGPUでメモリを共有しているからです。私のテストデータによると、qwen38-deepモデルの重みファイルサイズは18GBと比較的大きいです。しかし、大きなドキュメント処理のためにコンテキストウィンドウを最大32kトークンに予約しようとすると、実際の総メモリ使用量は21GBに跳ね上がりました。増加分は会話中の計算データを格納するために必要な約3GBのKVキャッシュです。Macが16GB RAMしか持っていない場合は、マシンがSSDへのスワップなしで滑らかに動作し続けるために、コンテキスト長を16kまたは8kに減らす必要があるかもしれません。そうしないとトークン生成速度が著しく低下します。
実機でのテスト
2026年9月2日、Mac Mini M4 Pro上でqwen38-deep32k-testモデルの限界をテストするために、32kのコンテキストウィンドウと3GBのKVキャッシュを設定して厳格なテストを行いました。20,049トークンの相当量のデータをプロンプトとして投入しました。結果、モデルは計算通りちょうど21GBのメモリを使用して処理に成功しました。興味深いのは失敗から得た教訓で、私のpredictive.shスクリプトはこのモデルを自動的にアンロードしました。なぜなら、その時点でこのモデルを直接使用するプロダクションルートが検出されなかったからです。これにより、新しいコマンドが入った際にモデルを再ロードするのに時間がかかりました。また、LiteLLMシステムからツール呼び出し引数の解析失敗に関する警告も発見しました。これは複雑なコマンドをサポートするためにツール設定をさらに調整する必要があることを示しています。
日本語能力とビジョンのテスト
テキスト会話だけでなく、Qwen3のビジョン能力と日本語理解もテストしました。特にqwen38-chatモデルでThai 5-keyテストセットを使用し、モデルが日本語の文脈を非常に良く理解して応答し、HTTP 200を正常に返すことを確認しました。エンベッディングについては768のnomic-embed-textと1024のembed-bgeの両方をテストし、どちらもまだollama/プレフィックスを使用していることがわかりました。API経由で呼び出す際に注意が必要です。ビジョン機能については、18GB（MLX）のqwen38-fastモデルと7.3GB（GGUF）のqwen2.5vlモデルを組み合わせ、単一のワークフローで画像処理を可能にしました。1x1ピクセルのPNGファイルによるスモークビジョンルートテストはシステム経由で成功し、MLXとGGUFという異なるフレームワークのMac上での組み合わせが可能であり、ストレージ使用量の増加という代償を払いつつも安定性を維持できることを示しています。
このようなラボ作業をさらに追跡したい場合は、LINE @icafefx をフォローするか、redhatai.net で無料ツールをダウンロードしてください。
