M4 Mac mini 32GBをAI開発マシンとして使っている環境まとめ
M4 Mac mini（32GB）を中心に、Local LLM、Coding Agent、Astro/OCI運用を組み合わせた個人AI開発環境の現状と、今後の計測方針を整理します。
M4 Mac mini（メモリ32GB）を、個人開発とAIを使った開発の中心マシンとして使っています。この記事では、公開できる設定と確認できた開発フローを整理し、同じ条件で取り直せる小さなLocal LLM測定も添えます。数値はこの1台、この時点の実測に限定して扱います。
1. Overview
この環境では、Mac miniでAstroの静的サイトをビルドし、生成したファイルをOCI上のnginxで配信します。公開サーバーは静的配信に専念させ、Node.js、npm、Astro、LLMの実行はローカル環境で扱う構成です。
記事の本文はMarkdown、変更履歴はGitで管理します。公開前にはローカルで型・コンテンツを確認し、静的成果物を検証してから次の工程へ進みます。
2. Hardware
Mac mini M4 / RAM 32GB
- モデル: Mac mini（Apple M4）
- メモリ: 32GB
- CPU: 10コア（高性能コア4、効率コア6）
ローカル推論、エディタ、ブラウザ、開発ツールを同じマシンで扱う前提で、この構成を使っています。モデル常駐時の余裕や同時利用時の挙動は、条件をそろえた計測結果で評価します。
Storage
ストレージの空き容量、モデルの保存先、運用上のしきい値は変動しやすく、公開する必要もないため、本記事では扱いません。モデル管理の方針を公開できる形に整理できた時点で、別途追記します。
3. Software environment
macOS
この記事の更新時点で、開発ホストはmacOS 26.6.1です。
Ollama
OllamaをローカルLLMの実行基盤として使います。モデル名、量子化形式、コンテキスト長、常駐設定は結果を左右するため、実行ログと同じ単位で記録する方針です。この記事では、モデル一覧や常駐設定を推測で掲載しません。
OpenCodeとCoding Agent
OpenCodeはローカル開発環境に導入しており、この記事更新時点のバージョンは1.18.18です。Coding Agentは、実装、調査、検証、レビューを一度に混ぜず、目的ごとに役割を分けて扱います。利用するproviderや認証情報を含む設定は公開しません。
4. Local LLM experiments
Qwen系とGemma系については、Ollamaをproviderに指定した小規模なcanaryタスクの設定を用意しています。ここでは、現在使っているQwen設定と、同程度のファイルサイズのGemma設定を、短い同一プロンプトでだけ実行しました。これはモデルの総合評価ではなく、この開発マシンで日常の短文生成を試したときの観察記録です。
2026-08-21のミニベンチマーク
実行基盤はOllama 0.32.13です。各モデルを直列に3回ずつ実行し、Ollamaのeval_count / eval_durationから出力速度を求めました。ロード時間とプロンプト評価時間は、この数値に含めていません。
| モデル | output tok/s（平均） | 3回の値（tok/s） |
|---|---|---|
Qwen qwen3.8:27b-64k |
5.48 | 5.50 / 5.52 / 5.40 |
Gemma gemma4:26b |
32.10 | 32.24 / 31.78 / 32.27 |
- Qwenは27.3B、Q4_K_S。Gemmaは25.8B、Q4_K_Mで、どちらもOllama上のGGUFモデルです。
- モデルが持つ最大コンテキスト長はどちらも262,144 tokenですが、比較時はリクエスト単位で
num_ctx=4096に固定しました。Qwenのモデル設定にある既定のnum_ctx=65536は、この測定では使っていません。 - 同じ公開用の日本語プロンプトを使い、temperature 0、seed 42、thinking無効、
num_predict=160、keep_alive=0を指定しました。実際の出力はQwenが各79 token、Gemmaが各74 tokenでした。 - 今回の5.48 tok/sと32.10 tok/sの差は、この組み合わせで観察した値です。モデルアーキテクチャ、Ollama内の実装・実行経路、量子化形式、生成したtoken数がそろっていないため、「Gemmaが優れている」「Qwenが遅い」といった用途の優劣や、他環境での速度として一般化しません。
測定は、各モデルを3回実行してeval_count / eval_durationを記録する簡単な方法です。初回記事では環境の全体像を優先するため、再現用のcurlコマンド全文と手順の解説は別記事で扱います。
メモリとswapの観察
開始直前、Qwenの1回目終了時、全6リクエスト終了後のvm.swapusageは、いずれも使用量4,660.50MiBでした。これは測定前から存在していたswapであり、短時間の結果だけから「推論中にswapを使わない」とは判断しません。終了後のメモリ圧迫統計ではthrottled pageは0でしたが、バックグラウンドの作業状況は固定していません。
この記録では、モデル名、量子化、コンテキスト長、プロンプト、測定式を残します。初回のロード時間と再実行時の応答、同時利用時の挙動は別に測る必要があります。
5. AI coding workflow
AIコーディングでは、ツールを同じ目的で並べるのではなく、作業の性質に応じて役割を分けます。
| 役割 | 使い分けの方針 |
|---|---|
| Coding Agent | リポジトリを対象にした実装、検証、変更の整理 |
| 対話型AI | 設計の壁打ち、文章化、別視点での確認 |
| Local LLM | 低コストで繰り返す試行、ローカルで完結させたい実験 |
出力をそのまま採用せず、変更内容、テスト結果、Git差分を確認してから次の工程へ進めます。公開コンテンツとデプロイは、Markdown、Git、buildの各境界で確認する運用です。
6. Development projects
Static blog workflow
このブログでは、Markdownで記事を書き、Gitで履歴を管理し、Mac miniでビルドした静的成果物だけを配信します。デプロイスクリプトは、新しいrelease directoryを検証してからcurrent symlinkを切り替える構成です。問題があった場合は、直前のreleaseへ戻せます。
Blog automation
Astroのcontent collectionでMarkdownのfrontmatterを検証し、公開記事から一覧、カテゴリ、タグ、RSS、sitemapを生成します。公開前に実行する基本の確認コマンドは次のとおりです。
npm run check
npm run build
npm run verify:distOCI usage
OCI側はnginxによる静的ファイル配信を担当します。ビルドやLLM実行をサーバーへ移さないことで、公開環境の構成を小さく保ちます。DNS、TLS、OCIネットワーク設定はコンテンツ運用とは分けて扱います。
7. Lessons learned
- ハードウェアのスペックだけでなく、モデル設定と測定条件を残さなければ比較できない。
- Coding Agentは用途を分け、出力を検証する工程を明示したほうが開発フローに組み込みやすい。
- 公開サーバーの責務を静的配信に限定すると、開発環境と公開環境を別々に改善できる。
- 未確認の情報は、公開記事で断定しない。
8. Future plans
- M4 Mac miniでのOllama速度の測り方、Qwen 27BとGemmaの詳細検証を別記事として記録する。
- context length、KV cache、Flash Attention、メモリ使用量、batch設定ごとの比較を別記事として記録する。
- 冷却状態、長時間連続動作、Dockerやブラウザを同時に使った場合の挙動を確認する。
- Coding Agentの実タスク比較と、公開可能なモデル管理方針を整理する。
- Coding Agentの役割分担を、実際のタスク例とともに更新する。
この記事は、構成の変更や測定結果が増えた時点で更新します。