M6 Mac mini 32GBをホームサーバーに。M2 MacBook Airとの性能差も試してみた

こんにちは、いぬにしです。

みなさんは、普段使うPCと、自宅で動かしておきたいサーバーを分けていますか？

筆者はこれまで、M2 MacBook Airをホームサーバーにして、主にiPadからAIとの会話や記録の整理を行っていました。手元のMacで始められるのはよかったのですが、普通のPCとしても使いたいMacBook Airに、サーバーとして置いておきたい役割が重なっていたんですよね。

そこで今回、メモリ32GBのM6 Mac miniを購入しました。サーバー機能をMac miniへ移し、MacBook AirとiPadは操作する側へ。前回紹介したホームシステムの、続編です。

MacBook Airをホームサーバーに。iPadから使う我が家のAI環境

手元のM2 MacBook Airを常時起動し、iPadから使うホームサーバーに。OllamaとOpenWebUIでのAIチャット、Markdownへの記録、Windows PCの起動まで、我が家の構成と使って感じた楽しさ・割り切りを紹介します。

inunishi.com

2026.09.18

今回の検証で分かったことは、次の2点です。

• 同じ動画のCPUエンコードは、約524秒から約83秒へ短縮。共通のLLM 2モデルも、生成速度が約1.7〜1.8倍になりました。
• 32GB機では大型候補2つの応答を確認。ただし、ツール呼び出しに難があり、日記の相手とKBの扱いは引き続きQwen Cloudに任せています。

今回は、2026年10月8日に届いたMac miniの使い方と、10月9日に行った測定を中心に紹介します。10月12日の時点では、まだがっつり作業できていないので、購入の総合評価は保留中です。まずは環境を分けて使い始めた段階での話になります。

※アイキャッチは筆者の実写写真をもとにしたAI生成イメージです。実際の設置環境は本文中の写真をご覧ください。

サーバーを分けるためにMac miniを買い増した

今回の購入目的は、MacBook Airをサーバーの役割から離し、操作端末として使える構成にすることです。あわせて、16GBのMacBook Airでは限界を感じていたローカルLLMも、もう少し大きなモデルで試したいと考えていました。

MacBook Airを手放してMac miniだけにするのではなく、2台の役割を分けます。自宅で処理を引き受けるMacと、そのとき使いたい場所で操作するMacやiPad、という組み合わせです。

今回買った構成と支払額

比較した筆者の2台は、次の構成です。

項目	M2 MacBook Air	M6 Mac mini
CPUコア数	8	12
メモリ	16GB	32GB
SSD	512GB	512GB
測定時のmacOS	26.0	27.0.1
今回の役割	サーバーから操作端末へ	サーバー機能の移行先

購入したのは2026年9月10日、到着したのは10月8日。支払額は257,800円でした。手元に動くMacがある状態での買い増しなので、気軽な金額ではありません。

購入にはApple Gift Cardを活用し、カード購入時に約10%程度のポイント還元を受けました。これは筆者の概算で、Mac mini本体が10%値引きされたという意味ではありません。ポイント額や充当した金額の細かい内訳はそろえていないため、還元後の「実質価格」は計算していません。

購入方法の考え方は、以前の記事でも紹介しています。2022年の記事なので、キャンペーンの条件は購入時に改めて確認してください。

Apple製品を安く買う方法

Appleギフトカードをお得に購入することでApple製品を安く購入する方法をご紹介！

inunishi.com

2022.07.31

Apple Gift Cardの購入先として、10,000円分の商品リンクを掲載します。ポイント還元の条件は購入時にご確認ください。

サーバーをMac miniへ、MacBook AirとiPadを操作端末へ

以前のMacBook Airに集めていたサーバー処理をMac miniへ移し、MacBook AirとiPadから使う構成にしました。処理を任せるMac miniは自宅に置き、操作する端末はMacBook AirとiPadから選ぶ形です。

履歴の移行では、ユーザー名の違いに引っかかった

手間がかかったのは、Codexの履歴をMacBook AirからMac miniへ移したときです。2台でmacOSのユーザー名が違い、以前のプロジェクトパスがそのまま通らなくなりました。

筆者は、以前のユーザーディレクトリ名から新しいホームディレクトリへシンボリックリンクを作る方法で対処しました。少し力技ですが、筆者の環境ではこれで使える状態になっています。

アプリを入れ直せば終わり、とはいかず、履歴に残ったパスまで引き継ぐ場合にはこういうところも見ておく必要がありました。

Mac miniはテレビ台へ

デスクに仮置きしていたMac miniは、10月10日の夜にテレビ台へ移しました。映像はテレビに出し、MacBook AirからはSSHやリモート接続でも操作する形です。

同じ処理でM2 MacBook AirとM6 Mac miniを比べる

実測では、動画のCPUエンコードと共通LLMの生成速度、どちらもMac miniのほうが速い結果でした。ただ、処理によって差の大きさはかなり違います。

以下の数値は、慣らし1回を除いた正式3回の中央値で、括弧内は最小〜最大です。以降の性能表では、比較対象の中で速かった結果の中央値を太字にしています。CPUやメモリだけでなく、macOSや筐体、冷却も異なる筆者の2台の比較として見てください。

同じ5分の動画をCPUでエンコード

動画素材は「Big Buck Bunny」のSunflower版、1080p・60fpsです。同一ファイルの先頭300秒を、FFmpegでCPUエンコードしました。

端末	処理時間：秒、中央値（最小〜最大）	正式回数
M2 MacBook Air	524.23（491.53〜525.57）	3
M6 Mac mini	83.49（83.48〜83.81）	3

この条件では、処理時間は約84%短縮しました。約8分44秒かかっていた処理が、約1分23秒で終わっています。

測定条件はFFmpeg 9.0.2、ソフトウェアデコードとlibx264、preset slow・CRF23・yuv420p・自動スレッドです。音声は除き、出力は保存しないnull出力としています。動画ファイルの書込みまで含む時間ではありません。時間はFFmpegの実経過時間（rtime）を採用しました。FFmpeg公式ドキュメント

MacBook Airは電源につなぎ、画面を閉じたクラムシェル状態。両機とも低電力モードOFF、ブラウザとDockerを停止して測っています。室温は記録していません。MacBook Airの正式3回は約492秒、524秒、526秒と長くなっていますが、温度を測っていないため、その原因を熱と断定はできません。

大きな差は出ましたが、この結果をそのまま「CPUが約6倍速い」「普段の動画編集が約6倍速い」と読むことはできません。今回の入力と、連続してCPUエンコードした条件での結果です。

使用素材：Big Buck Bunny / Blender Foundation（Sunflower版メタデータ：Janus Bager Kristensen）。作品の出典・利用条件：公式サイト / CC BY 3.0。

いつもの2モデルで生成速度と待ち時間を測る

LLMは、MacBook Airに入れていたGemma 12B QATとQwen2.5-Coder 7Bを、同じモデル・同じ入力で両機に処理させました。

モデル	端末	生成速度：tokens/s	最初の本文まで：秒	256トークン受信まで：秒
Gemma 12B QAT	M2 MacBook Air	11.76（11.75〜11.78）	1.86（1.85〜1.87）	23.64（23.57〜23.64）
Gemma 12B QAT	M6 Mac mini	19.99（19.95〜20.00）	0.48（0.48〜0.48）	13.29（13.28〜13.31）
Qwen2.5-Coder 7B	M2 MacBook Air	17.97（17.95〜17.98）	1.07（1.07〜1.08）	15.33（15.31〜15.34）
Qwen2.5-Coder 7B	M6 Mac mini	31.69（31.52〜32.04）	0.26（0.26〜0.27）	8.35（8.25〜8.38）

生成速度はGemmaで約1.70倍、Qwen2.5-Coderで約1.76倍です。最初の本文が出るまでの時間も短くなりました。

tokens/sは、1秒あたりに生成するトークン数です。文字数と同じではなく、今回の値はOllamaが返す生成トークン数と生成時間から計算しています。Ollamaの指標説明

共通試験はOllama 0.40.2で、モデルを識別するdigestも両機で一致しています。GemmaはQ4_0、CoderはQ4_K_M。各Mac自身のAPIへ接続し、モデルを読み込んだ後の応答を測りました。要求設定はcontext 4096、生成上限256、temperature 0、seed 42でそろえています。背景条件は動画試験と同様にブラウザ・Docker停止です。

なお、今回は256トークンの上限で打ち切る速度試験です。表の最後の列は「完成した回答を得る時間」ではありません。Gemmaには文章、Coderにはコードの課題を与えているため、モデル同士の優劣ではなく、同じモデルを動かしたときの端末差として比べています。

32GBで大型モデルも試してみる

32GBのMac miniでは、Gemma 26B QATとQwen3.8 27B MLXの両方から応答を得られました。MacBook Airとの速度差とは別に、新しい構成で試せるモデルの範囲を見たテストです。

モデル	量子化 / 実行エンジンの報告	生成速度：tokens/s	最初の本文まで：秒	256トークン受信まで：秒
gemma4:26b-a4b-it-qat	Q4_0 / llamacpp	52.31（52.30〜52.34）	0.22（0.22〜0.23）	5.12（5.12〜5.12）
qwen3.8:27b-mlx	nvfp4 / mlx	16.96（16.86〜17.01）	0.85（0.84〜0.85）	15.74（15.69〜15.83）

大型候補の速度試験はOllama 0.40.0です。共通モデルの比較とは版が異なるため、前の表と一つのランキングにはまとめません。両候補には同じ文章課題を与え、context 4096、生成上限256、読み込み済みの条件で各3回測っています。全正式回が正常に終了し、いずれも生成上限で打ち切っています。

今回の2候補ではGemmaの生成速度が高い結果でした。ただし、モデル・量子化・実行エンジンが違うので、これをMLX単体の性能差と読むことはできません。

モデルが動くことと、メモリに余裕があることは別

実行時のOllamaによるモデルSIZE報告は、Gemmaが約15.06GB、Qwenが約18.51GBでした。これはシステム全体の使用済みメモリを表す値ではありません。

また、試行前後のOS全体のスワップ使用量は、Gemmaのセッションが約137MB、Qwenが約1,473〜1,481MBでした。すでに使っていたスワップも含むため、そのモデルだけが必要とした量や、新たに発生した量ではありません。

今回の正式試験は短い入力です。入力そのものを増やした長文試験や、複数処理の同時実行までは検証していません。32GBでこの2候補を試せたことは確認できましたが、自分の会話履歴や普段のサービスを載せたときの余裕は、別に見る必要があります。

日記の相手とKB整理に使えるか

短い実用課題では、Gemmaは約1〜2秒台、Qwenは約4〜8秒台で回答が完了しました。一方、出力を確認すると、返答が速いことと、記録としてそのまま使えることは別でした。

筆者がローカルLLMに任せたいのは、OpenWebUIでの日記の対話と、日記からナレッジベース（KB）へ残す情報の整理です。今はQwen Cloudに任せている作業で、その一部をローカルへ移せるか試しています。

架空の日記で3つの課題を試した

机の配線整理を題材に、日記への応答、会話中の訂正、KBへ保存する候補文の作成を試しました。課題ごとに入力を変えており、プロンプトの要約は次のとおりです。

1. 日記対話：気持ちを決めつけず、質問を一つ返せるか

入力したのは、「2026年10月9日に机の配線を整理した。始めるまでは面倒だったが、一本ずつ外したら少し進んだ。まだ終わっておらず、疲れたので残りは来週にしたい」という架空の日記です。

記録にない出来事や気持ちを付け加えず、頑張ったことを短く受け止めたうえで、次に考えるための質問を一つだけ返すよう指示しました。

2. 履歴の訂正：前の発言より、訂正後の情報を優先できるか

最初に「配線整理は土曜日に終えたと思う。来週は外付けSSDを買うつもり」と伝え、AIがそれを受け止めた会話履歴を与えました。その後、「整理したのは10月9日の金曜日で、まだ途中。SSDも購入決定ではなく、今の容量で足りるか調べてから考える」と訂正しています。

訂正後の情報を優先し、確定したことと、まだ決めていないことを分けて短くまとめるよう指示しました。作業を始めた日は入力していません。

3. KB整理：事実・気づき・未確定事項を分けて保存候補を作れるか

入力したのは、「10月9日に配線を一部整理したが未完了。一本ずつ外すと着手しやすかったと感じた。次の作業は来週にしたいが日付は未定。SSDは未購入で、容量不足を確認してから購入を考える」という日記です。以前の「土曜日に完了」「来週SSDを購入決定」という内容は誤りだとも伝えています。

入力にない事実を足さず、「記録日」「確定事項」「気づき」「未確定事項」の4見出しでMarkdownの保存候補を作るよう指示しました。実際のファイル書込みは行わない条件です。

これらを2つのモデルに処理させた結果が、次の表です。

モデル	課題	最初の本文まで：秒	回答完了まで：秒	出力トークン数
Gemma 26B QAT	日記対話	0.18（0.18〜0.19）	1.33（1.33〜1.35）	62
Gemma 26B QAT	履歴の訂正	0.23（0.23〜0.23）	1.58（1.56〜1.61）	72
Gemma 26B QAT	KB整理	0.24（0.24〜0.24）	2.41（2.40〜2.43）	115
Qwen 27B MLX	日記対話	0.66（0.66〜0.67）	4.19（4.18〜4.19）	48
Qwen 27B MLX	履歴の訂正	0.87（0.86〜0.87）	3.96（3.94〜3.96）	59
Qwen 27B MLX	KB整理	0.84（0.84〜0.84）	8.20（8.19〜8.20）	171

こちらはOllama 0.40.2、各課題3回。生成上限は1024トークンに広げ、全18回で回答が自然に終了したことを確認しました。出力の長さや内容が違うので、完了時間の比率を端末の性能倍率としては使いません。

訂正や「感想」の扱いには、確認が必要だった

出力の点検は、測定前に決めた基準に沿ってAIが行った暫定評価です。筆者の普段の会話での好みや、自然さの最終評価とは分けています。

課題	Gemma 26B QATの暫定評価	Qwen 27B MLXの暫定評価
日記対話	表現を手直しすれば使える	着手前の面倒さを、現在の気持ちとして扱った
履歴の訂正	入力にない「開始日」を補った	日付・未完了・SSD未決定という必須条件を満たした
KB整理	個人の気づきを確定事項にも置いた。SSD未購入の明示も不足	個人の感想を、一般的な効果に広げた

たとえば、履歴の訂正課題では、金曜日に一部整理したという趣旨を伝えています。ところがGemmaの回答は、次のようになりました。

机の配線整理：2026年10月9日（金）に開始（現在も途中）

「一部整理した日」と「作業を開始した日」は、同じとは限りません。小さな違いに見えても、後で自分の記録として読み返すなら、そのまま保存したくない部分です。

KB整理でも、「一本ずつ外すと着手しやすかったと感じた」という個人の気づきが、確定事項に入ったり、一般的な効果のように言い換えられたりしました。今回の判定では、事実を足さず、事実と感想を分けることが必須なので、該当する出力は現状のままでは使えない扱いです。

ただし、これは固定した3課題の出力への判定です。モデル全体を否定する評価ではなく、保存前にどこを直す必要があるかを確認した結果になります。実際のKB書込みやツールによる自動更新は、今回試していません。

OpenWebUIの画面例と、サービス起動中のメモリ

OpenWebUIでも、記事の準備を題材にした架空の日記に対する応答例を用意しました。上の配線整理の3課題とは別の会話例です。

OpenWebUIからは、Mac mini上のOllamaに接続しています。この画面は入力と回答の例として載せています。先ほどの表はOllamaへ直接接続した測定なので、OpenWebUIを操作したときの待ち時間とは条件が違います。

Docker・Puma・nginxを起動して、Mac mini向けのLLMベンチマークを実行していた時点の画面も残しています。

この時点では使用済みメモリ25.13GB、スワップ4.01GB、メモリプレッシャーは緑でした。こちらは単独の正式試験とは別の場面です。サービスを起動していたときの様子は分かりますが、各サービスの応答や、共存時の速度・継続的な安定性まで測った結果ではありません。

日記の相手とKBの扱いは、引き続きQwen Cloudへ

10月12日の時点では、ローカルLLMはツール呼び出しに難があるため、日記の相手とKBの扱いは引き続きQwen Cloudに任せています。Mac miniでモデルが動いたからといって、いつもの作業をそのまま移せたわけではありません。

今回の実用テストは、候補文を生成するところまでです。ツールを呼び出してKBを読み書きする普段の運用とは、評価の範囲が違います。短い回答の速さに加えて、必要なツールを使えるか、記録を正確に残せるかも見ながら、任せる範囲を考えていく予定です。

良かった点・気になった点

まだ十分な作業時間を取れていないため、購入してよかったかどうかの総合評価は保留しています。ここでは、導入で進んだことと、残っている手間を整理します。

導入でよかったこと

• MacBook AirとiPadを操作端末として選べる構成になったこと。 自宅のMac miniに処理を任せ、MacBook Airは普段のPCとしても使う役割に分けました。
• 既存モデルの待ち時間が短くなり、大型候補も試せたこと。役割分離に加えて、処理の違いを実測で確認できました。

気になったこと・割り切ったこと

• 履歴まで移すと、以前のユーザー名を含むパスが問題になること。筆者の環境ではシンボリックリンクで対処しました。
• ローカルLLMのツール呼び出しには難が残ること。日記の対話・KBの扱いは、引き続きQwen Cloudです。短い課題の出力にも修正が必要なものがあり、候補文をそのまま記録へ保存する評価には至っていません。
• 長文や普段のサービスとの共存は、まだ定量的に評価できていないこと。32GBでの単独応答を、そのまま常時運用の余裕とは扱っていません。

音については、今回のベンチマークでMac miniのファン音が聞こえたのはFFmpeg試験のときだけでした。ほかのベンチマークでは筆者には聞こえませんでしたが、音量や回転数を測ったものではありません。

まとめ：使いたい端末と、処理を任せる端末を分ける

今回のMac mini導入で、筆者の環境はMacBook Airがサーバーも兼ねる構成から、Mac miniへ処理を集め、MacBook AirとiPadで操作する構成へ進みました。

同じ動画のCPUエンコードや、同じLLMの生成では待ち時間が短くなりました。32GBで大型候補を試すこともできましたが、ツール呼び出しの課題が残り、日記の相手とKBの扱いはQwen Cloudのままです。

役割を分ける環境はできてきたものの、257,800円の買い増しにどこまで満足できるかは、これから作業を重ねて判断したいと思います。

手元のMacBookを引き続き活かしながら、自宅にAIや開発環境を集めたい人には、こうした役割分離は検討する価値があるかと思います。構築や保守も含めて、自分の環境を育てるのが好きな人向けです。

一方、外出先で重い処理も端末本体だけで完結させたい人や、設定・保守をせずクラウドと同じ使い勝手を求める人には、今回の構成は合いにくいでしょう。32GBあればどんなモデルでも使える、という判断にもつながりません。

まずは、自分が使いたいモデルや入力の長さ、普段動かすサービス、そして手元のPCから離したい役割を整理してみると、専用機を足す意味が見えてくるのではないでしょうか。

筆者の構成と実測が、みなさんの自宅環境を考える参考になれば幸いです。

以下のAmazonリンクはメモリ24GB・SSD 512GBモデルです。筆者が購入・測定した32GBモデルとは構成が異なるため、この記事の実測結果を24GBモデルの性能としてご覧にならないようご注意ください。楽天市場・Yahoo!ショッピングは検索結果に移動するため、チップ・メモリ・SSD容量をご確認ください。