Mac Mini M4 Pro に Ollama をインストールし、Qwen38 と GLM モデルをローカルで実行しました。VRAM と実際の速度を測定した結果、32k コンテキストではテストごとにメモリが 3GB 増加することが判明しました。一般的なウェブ検索ツールのエラー解決手順も記載しています。

環境準備と Ollama のインストール

まず、Ollama の公式ウェブサイトから macOS 用のインストーラーをダウンロードしました。Apple Silicon M4 Pro チップに最適化されています。インストール後、ollama --version コマンドでバージョンを確認し、メモリ管理が最も効率的な最新バージョンを使用していることを確認しました。

重要なステップは、モデルのパスを十分な空き容量があるパーティションに設定することです。Qwen38 のような大規模モデルは数十 GB のファイルサイズになります。OLLAMA_MODELS=/Volumes/AI_Disk コマンドを使用して、モデルの保存領域をシステムドライブから分離しました。これにより、メイン SSD が急速に埋まるのを防ぎ、寿命に影響を与える書き込み・読み取りを減らすことができます。

さらに、chmod -R 755 /Volumes/AI_Disk コマンドでフォルダのアクセス権限を確認し、Ollama が「Permission Denied」の問題に遭遇することなくデータを取得できるようにしました。これは多くの人が見落としてモデルの読み込みが途中で失敗する原因となる点です。ダウンロードと実際の性能テストに進む前に、領域を準備することは重要な基盤となります。

Qwen38 モデルのダウンロードと管理

Qwen38 モデルをテストの主力として選択しました。32k トークンの長いコンテキストに対応しており、タイ語文書の分析作業に適しているためです。ollama pull qwen38 コマンドを使用してウェイトファイルをダウンロードし、高速インターネット環境で約 15 分かかりました。

ダウンロードが完了したら、du -sh ~/.ollama/models/blobs/sha256-* コマンドで実際のサイズを確認しました。このモデルは約 18GB のストレージを消費します。割り当てられた 32k コンテキスト（KV キャッシュ）と合わせると、私のテスト報告書によると総メモリは 21GB に増加します。

ollama run qwen38 --num-ctx 32768 コマンドを使用して、最大コンテキストサイズを指定してモデルを実行しました。この設定により、システムは KV キャッシュ用に追加で 3GB の RAM を予約する必要があります。これは、以前のデータを忘れることなく会話の継続性や長文書の処理を維持するために必要です。

実際のマシンでのテスト

2026 年 9 月 2 日、Mac Mini M4 Pro で resume-verify テストスイートを実行し、webui.siam2r.com/api/version の API を通じてシステム状態を確認しました。結果はステータスコード 200 を示し、サービスが正常に動作していることを確認しました。

1x1 ピクセルの PNG ファイルで Vision パスをテストしました。Qwen3-VL-8B と GLM-4.6v-flash の両方が 3/3 回のテストをステータスコード 200 で通過し、これらのモデルは Mac でも基本的な画像処理をサポートしていることを示しています。

しかし、LiteLLM の search_web 関数を実行した際に実際の問題が発生しました。15:52:43 に「failed-to-parse tool-call args」エラーが発生しました。クライアントモデルのバグですが、この問題は私の主要な設定とは関係なく、コードの修正も不要であることを記録しておきます。開発チームがソースで修正するのを待つだけです。

エラーから学んだ教訓と解決策

得られた重要な教訓は、本番環境（Production）に投入する前に「Dry-run」テストを行うことで損害を防げるということです。qwen38-deep32k-test というエイリアスを使用して実際の実行前にシナリオをシミュレートし、予想以上のメモリ使用の問題を発見できました。

Qwen38 と 7.3GB の Qwen2.5VL を同時に実行すると、スワップが過剰になりマシンが遅くなることを発見しました。そのため、テスト終了後に使用されていないモデルを即座にアンロードする predictive.sh スクリプトを設計する必要がありました。

もう一点は Embedding Dimensions の問題です。Nomic-embed-text が 768 次元、BGE が 1024 次元を使用していることを確認しました。これらの数値を理解することは適切なベクトルデータベースの選択に役立ちます。次元が一致しないと、システムは明確なエラーを表示せずに誤動作し、デバッグが非常に困難になるためです。

パフォーマンスのまとめと推奨事項

私の実際のデータによると、Qwen38 Deep 32k は合計 21GB のメモリを使用します（ウェイト 18GB + KV キャッシュ 3GB）。一方、Fast バージョンは 18GB のみで、RAM の少ないマシンに適しています。

Mac Mini M4 Pro で RAM 64GB 以上のユーザーには、これらのモデルをスムーズに実行できると推奨します。サーマルスロットリングをあまり心配する必要はありませんが、大規模モデルを実行中は Chrome や Xcode のような RAM を消費する他のアプリケーションを閉じるべきです。

最後に、Mac 上のローカル AI はプライバシーの面でクラウドよりも信頼性が高く安全な結果を提供することを確認します。ただし、マシンリソースの厳格な管理と引き換えです。安定性を求める開発者にとって、ログと VRAM 使用量の定期的な監視は不可欠です。

このようなラボ作業をさらに追いたい方は、LINE @icafefx をフォローするか、redhatai.net で無料ツールをダウンロードしてください。