M4 Mac Mini を買う前に、よく検索されるのは次の三点です。M4 Mac Mini ローカル LLMはどこまで実用的か、16GB と 24GB の差はどれくらいか、Mac Mini で LLMを回すと swap は頻発するか。2026 年時点で Qwen2.5・Llama 3.1 などの重みは Ollama で Apple Silicon 上に載せられます。ボトルネックは多くの場合、統合メモリであり、ディスクリート GPU の有無ではありません。
7B と 14B だけを選びたい場合：決定 Spoke M4 Mac Mini：7B vs 14B 実使用差（2026 実測）（フローチャート、Agent TTFT、§8.4 選定表）。本 Hubは方法論・失敗サンプル・raw dump 用です。
この記事は「モデル チェックリストの概要」ではありません。失敗したサンプルと生のダンプを含むラボ記録（2026 年 5 月 20 日から 06 月 2 日まで）です。リソース：sample-benchmark-run.log、raw-vm-stat-dump.txt、ollama-debug-excerpt.log。
フレームワーク比較は MLX vs Ollama 実測、統合メモリの仕組みは 統合メモリと LLM 推論 を参照してください。
1. システム因果モデルとハード制約
ベースの Mac Mini M4 (Pro ではありません) には同梱されています。16GB、24GB、または32GBユニファイド メモリ、10 コア GPU、およびおおよそ120GB/秒メモリ帯域幅 (M4 Pro ~273 GB/秒)。以下のすべての tok/s、スワップ、TTFT 番号はこれにマッピングされます。3層リソースモデル-理解するwhyまず、§3 ～ §5 で何が起こったかを読んでください。
M4 ローカル LLM 推論: 3 層リソース因果モデル
| Layer | コントロール | 因果メカニズム | この記事の観察アンカー |
|---|---|---|---|
| L1 容量 メモリ容量 |
載せられるか、OOM か | 占有 ≈ 重み + KV cache（∝ num_ctx）+ OS/フォアグラウンド。物理メモリ超過 → 圧縮 → swap → runner 終了 |
14B @ 16GB OOM;num_ctx=65536サイレントタイムアウト |
| L2帯域幅 メモリ帯域幅 |
クリーンステートトーク天井 | decode では各 token が重みストリーム全体を読む。tok/s ≈ 有効帯域 ÷ 1 token あたりのバイト移動量。同チップ・同モデルでは L2 が baseline ~29 tok/s を決め、メモリ GB 数そのものではない | 16GB クリーン 8B 中央値 28.8; 24GB 同じモデル 51.2 (§1.4 を参照) |
| L3 圧力 プレッシャー/争い |
非線形パフォーマンスの崩壊 | wired 上昇 → compressor 稼働 → 記憶状態 WARN/致命的 → swapins → GPU ページフォルト → tok/s 断崖（非線形、§5 Phase 2–3） | スワピン 8421 → 3.4 トーク/秒;クリティカル @ 14.8GB 有線 |
因果関係チェーン (ログ読み取り時):設定の変更→どの層が最初ですか？より大きなモデル/ctx → L1;負荷が同じ 16GB と 24GB → 多くの場合、L1 ヘッドルームが L3 を起動するかどうかを決定します。熱 -12% → L2 実効帯域幅が低下。 Metal を使用しない Ollama → L2 パスは CPU にフォールバックします。
1.1 L1 容量: 重み + KV は統合メモリに収まる必要があります
推論の占有 ≈ 量子化された重み + KV キャッシュ（num_ctx に比例）+ macOS とフォアグラウンドアプリ。L1 に余裕がある間は L3 は発火しない——baseline 28.8 tok/s の前提です。L1 が限界に達すると、システムは「均等に遅くなる」のではなく §5 の Phase 2/3 に入ります。経験則としてモデル関連の占有は総メモリの約 70% 未満に；16GB で Xcode + Chrome + Ollama を同時に開くと、実効余裕は 10GB 強にまで縮みます。
1.2 L2 帯域幅: クリーン状態の tok/s に上限がある理由
自己回帰デコードは通常、次によって制限されます。重みをユニファイド メモリから GPU 計算ユニットに移動する。 ラマ 3.1 8B Q4 の重量は最大 4.9GB。 M4 @ 120GB/秒 は、約 25 ～ 35 tok/s の帯域に収まり、測定された中央値 28.8 と一致します。ウォーム マシン 25.1 と異常値 31.1 は L2 ノイズ (スロットル/GC) であり、L3 スワップではありません。 §3 ～ §7 の生ログを参照してください。
1.3 L1 前提条件: 量子化によって適合性が決定される
デフォルトの Ollama タグはほとんどが Q4 (GGUF; を参照)ラマ.cpp）。 8B: Q4_K_M ~5GB、Q8_0 ~8GB — 16GB で Q8 8B を実行できますが、KV ヘッドルームが小さく、L3 トリガーが容易です。この記事は次のことを前提としていますQ4_K_M特に記載がない限り。
1.4 24GB が「非線形」アップグレードである理由
24GB では L2 帯域幅が 2 倍になるわけではありません。同じ M4 ダイ、同様の L2 シーリング。 24GB 8B 中央値 51.2 の主な理由は、重み + KV は、L3 競合なしで GPU に優しい常駐状態を維持します。、Ollama/Metal はより大きなバッチとより安定したバッファーを使用できます。クリーンな 16GB 8B はすでに L1 エッジ近くにあり、どの Chrome タブもフェーズ 1 に進みます。16GB→24GB を購入L1 ヘッドルーム → 遅延 L3「+8GB = +8 tok/s」の線形スケーリングではありません。
2. ベースライン: 最初のクリーン システム実行
後のすべての比較のアンカー: Mac Mini M416GB, Terminal + Ollama only, ラマ 3.1 8B Q4, 512 prompt / 256 gen, temperature=0.2. マシン ID m4-16gb-lab-01、macOS 15.4。
| Metric | 2026-05-28 最初のベースライン | Notes |
|---|---|---|
| tok/s (5 実行) | 28.1 / 29.8 / 27.2 / 20.8* / 31.1 | *run4 には Chrome が含まれていました。除外される |
| 中央値/平均値 | 28.8 / 29.05 | 非単調; §3 を参照 |
| TTFT掛け時計 | 1.82 / 2.61 / 1.94 / 2.08秒 | run2 ジッター 2.61 秒 |
| Swapins | 0 | vm_stat スナップショット |
| Metal | ggml_metal_init: Apple M4 | デバッグログを参照 |
これは「1 つのベンチマークと概要」ではなく、ベンチマークの始まりです。3週間のエンジニアリングログ;同じ構成の中央値は日付によって 27.9 ～ 29.2 に変動する可能性があります (§6.3)。
3. ログと生のシステム ダンプを実行します。
以下は未整理の Lab 成果物（要約ではありません）。完全な benchmark：resources/sample-benchmark-run.log；システム dump：resources/raw-vm-stat-dump.txt；Ollama debug：resources/ollama-debug-excerpt.log。
3.1 ベンチマークスクリプトの出力（抜粋）
--- run 2 / 5 --- (machine warm, fan ~4200rpm)
eval_count=256 elapsed=8.6s tok/s=29.8 TTFT_wall=2.61s
--- run 5 / 5 --- (outlier: GC pause mid-decode)
eval_count=256 elapsed=8.0s tok/s=31.1 TTFT_wall=2.08s
中央値トク/秒: 28.8
mean: 29.05
p90: 30.43.2 vm_stat +記憶状態 (実行 3 と同じウィンドウ)
Pages wired down: 201888.
Pages stored in compressor: 94208.
Swapins: 0.
# 14B failure session later same day:
記憶状態: pressure level 4 (致命的)
記憶状態: killing_low_priority_processes完全なダンプには以下が含まれますトップ -l 1 and ログ表示 … メモリステータス; see raw-vm-stat-dump.txt.
3.3 システムレベルのノイズ (非モデル要因)
| ノイズ源 | 観察 | tok/s への影響 |
|---|---|---|
| 熱機 / ファン 4200rpm | 約 20 分の継続後に実行 | 29.8 → 25.1 (~−12%)、除外されていない |
| TTFTジッター | 1.82 → 2.61 → 1.94 秒 | エージェントの最初のターンの感触 |
| メモリコンプレッサー | 94208 ページを圧縮 | スワップ前。まだ使える |
| メタルバッファの再割り当て | デバッグ時の 1 つの WARN 行 | 単一実行 -3 ～ 5%、致命的ではない |
| 午後の環境 | 2026-06-02 14:00 再テスト | 中央値 27.9、外れ値 24.3 |
3.4 再現
chmod +x リソース/benchmark-m4-mac-mini-ollama.sh
./リソース/benchmark-m4-mac-mini-ollama.sh ラマ3.1:8b
# recommended second terminal:
log stream --predicate 'subsystem == "com.apple.記憶状態"' --level debug4. Resource exhaustion taxonomy（失敗の帰属）
§3 生のログは時系列です。このセクションでは次のように分類します。枯渇タイプ—障害が発生した場合は、L1、L2、または L3 を尋ねてください。
| Type | Layer | 典型的な症状 | この記事の事例 | 方向を固定する |
|---|---|---|---|---|
| E1 容量枯渇 容量の枯渇 |
L1 | ロード OOM、ランナーが死亡、モデルが適合しません | qwen2.5:14b @ 16GB →信号: 殺されました (おっと?) |
小型モデル / RAM 24GBまで |
| E2 圧力崩壊 圧力崩壊 |
L3→L2をドラッグ | スワピンスパイク、トーク/秒クリフ、TTFT 5秒以上 | スワピン 8421 → 11.2→3.4 トーク/秒 | 低い ctx / 背景を閉じる / §5 フェーズ 2–3 |
| E3 帯域幅パスの低下 帯域幅パスの低下 |
L2 | スワップはありませんが、トーク/秒が非常に低いです。金属が装填されていません | オラマ 0.5.13 いいえggml_metal_initセッション全体 → 4.2 tok/s |
オラマをアップグレードします。金属警告を確認してください |
| E4 レイテンシのみの障害 レイテンシのみの障害 |
L1 エッジ + L3 プリカーサー | ロードは OK、最初のトークンは 60 秒以上。安定したトーク/秒の前に使用不可 | num_ctx=65536+ 14B @ 16GB |
低いctx; 24GB の同じ構成 TTFT ~2.8 秒 |
| E5 総枯渇 総枯渇 |
L1 + L3 | 単一パスOK;マルチエージェント / mmap 大型モデルは使用不可 | 5 エージェント + 14B; 70B mmap <3 トーク/秒 | 分割ノード; 70B には M4 プロ 48GB+ が必要です |
4.1 E2 の例: スワップ主導の圧力崩壊 (qwen2.5:14b @ 16GB)
time=2026-05-29T11:03:12 level=WARN msg="model requires more memory than available, offloading to CPU"
time=2026-05-29T11:03:44 level=ERROR msg="llama runner process has terminated: 信号: 殺されました (おっと?)"
# causal: L1 full → L3 swap → L2 GPU waits on pages → E2
# run sequence: 11.2 → 8.4 → 3.4 → 2.9 tok/s
Swapins: 8421 (then > 20k)4.2 E3 の例: メタル パスの喪失 (Ollama 0.5.13、2026-04-18)
# entire session: NO ggml_metal_init → L2 path = CPU only
eval rate=4.2 token/s
# fix:にアップグレードする0.6.2 → Metal restored, median back to ~294.3 E4 の例: num_ctx 65536 + 14B サイレント タイムアウト
ロードは成功しましたが、最初のトークンは 60 秒以上で応答がありませんでした -L1 は安定した測定可能な tok/s の前に KV 寸法に達します。 24GB の同じ構成 TTFT ~2.8 秒: ロード可能 ≠ 毎日使用可能。
4.4 E5 とその他の境界（概要）
- E1+E5:70B mmap、tok/s < 3 - 容量レイヤーが不十分です
- E1+E5:5 人の同時エージェント + 14B、スタックされた KV OOM
- E2 前駆体:Xcode CI + 14B 同じマシン、DerivedData が L1 を使用 - ワークロードを分割
- L2 ノイズ (E クラス障害ではない): Metal
バッファの再割り当て警告、単一実行 -3 ～ 5%、§3.3 を参照
5. 三フェーズ collapse モデル
§1 L3 圧力の具体的な抽象化: 同じ M4 16GB、ラマ 3.1 8B Q4、有線メモリの増加 tok/s は直線的に減少せず、3 つのフェーズに分割されます。 16GB の 14B はフェーズ 3 に早く入ります。これは、単に「パラメータが多い」だけではなく、「14B が遅い」という因果関係を説明しています。
5.1 フェーズの定義 (8B Q4、段階的負荷)
| Phase | 記憶状態 | 有線約 | 8B トーク/秒 | 14Bトーク/秒 | メカニズム（層） |
|---|---|---|---|---|---|
| Phase 1 直線的な劣化 |
NORMAL | 11.8→14.1GB | 28.8 → 22.1 | — → 6.2 | L1 ヘッドルームが縮小します。 L2 帯域幅は依然として優勢ですが、ほぼ直線的 |
| Phase 2 競合ゾーン |
警告→重大 | 14.1→14.8GB | 22.1 → 18.6 | 6.2 → 3.4 | L3 開始: コンプレッサーがアクティブ、GPU が再利用を待機、より急な坂 |
| Phase 3 スワップの崩壊 |
スワップアクティブ | 15.2GB以上 | 9.1 → 3.2 | 2.9 | L3 フル: スワピン 8421+、非線形の崖; E2失敗 |
読み上げる：フェーズ 1 - 多くの場合、モデルを小さくするか、タブの数を減らします。フェーズ 2—切断する必要があるnum_ctxまたはRAMを追加します。フェーズ 3 - 負荷が減るか RAM が増えるだけです。温度を調整しても何も起こりません。
5.2 測定されたスナップショット (クロスフェーズ)
| システム状態 | 崩壊フェーズ | tok/s | TTFT | Swapins |
|---|---|---|---|---|
| クリーンなベースライン | — (L2 安定) | 28.8 メディカル (28.1 ～ 31.1) | ~1.99s | 0 |
| 熱機 20min | — (L2ノイズ) | 25.1 | 2.4s | 0 |
| Chrome + Xcode | フェーズ 1 後期 | 20.8 | 2.38s | 0 |
| 16GB + 14B 実行 1–2 | Phase 2 | 11.2 / 8.4 | ~2.8s | 0→1204 |
| スワップアクティブ + 14B | Phase 3 | 3.4 → 2.9 | 5.8s | 8421+ |
| 24GB クリーン + 8B | — (大きな L1 ヘッドルーム、フェーズ 1 なし) | 51.2メディカル | ~1.6s | 0 |
5.3 生データの段階的なロード (16 GB、有線 + 匿名)
1:1 をフェーズ 1→3 にマッピングします。再現するときは信頼してください記憶状態GB 単独ではなく段階:
| 有線 + 匿名約 | 記憶状態 | Phase | 8B トーク/秒 | 14Bトーク/秒 |
|---|---|---|---|---|
| 11.8 GB | NORMAL | — | 28.8 | — |
| 13.2 GB | NORMAL | Phase 1 | 26.4 | 10.8 |
| 14.1 GB | WARN | フェーズ1→2 | 22.1 | 6.2 |
| 14.8 GB | 致命的 | Phase 2 | 18.6 | 3.4 |
| 15.2GB以上 | スワップアクティブ | Phase 3 | 9.1 | 2.9 |
5.4 スワップが「非線形ブレークポイント」である理由
フェーズ 1 ではまだデコードされていますmostlyL2 帯域幅パスに従います。フェーズ 2 に入ると、macOS の積極的な再利用とコンプレッサーにより GPU バッファの割り当てが待機します。フェーズ 3 各トークンはスワップからページフォールトを起こす可能性があります—レイテンシはμsからmsへ。 tok/s ~20 → ~3 は「20% 遅い」わけではありません。それはパススイッチ。 §4 E2 Swapins 8421 はフェーズ 3 のフィンガープリントです。
6. TTFT、コンテキスト、および時間/バージョンのドリフト
6.1 TTFT とエージェントの感触
| シナリオ | TTFT サンプル | Notes |
|---|---|---|
| モデル居住者 | 0.41 / 0.58 / 0.52 | 許容できる |
| プル後のコールドスタート | 1.82 / 2.61 / 1.94 / 2.08 | システムウェイクジッター |
| スワップ+14B | 4.5 / 5.8 / 6.2 | 使用不可 |
6.2 num_ctx の減衰 (8B Q4)
| num_ctx | 16GB トーク/秒の実行 | 24GB トーク/秒の実行 |
|---|---|---|
| 2048 | 28.1 / 29.8 / 27.2 / 31.1 | 51.2 / 54.6 / 49.8 / 52.1 |
| 8192 | 24.1 / 26.3 / 22.7 | 47.8 / 50.1 / 48.6 |
| 32768 | 14.6 / 13.8 (スワップエッジ) | 38.2 / 36.9 |
6.3 時間のドリフト: 同じマシン、同じスクリプト、異なる日付
| Date | Ollama | 中央値トク/秒 | 走行範囲 | Notes |
|---|---|---|---|---|
| 2026-05-20 | 0.6.1 | 29.2 | 26.8～31.4 | 古いアロケータ |
| 2026-05-28 | 0.6.2 | 28.8 | 27.2～31.1 | この記事のベースライン |
| 2026-06-02 | 0.6.2 | 27.9 | 24.3～30.1 | 午後の暑さ、異常値24.3 |
0.6.1 → 0.6.2 中央値デルタ ~1.4 tok/s、日々の変動±12%より小さい—バージョン間の比較には、日付と室温を固定する必要があります。
6.4 Ollama のマイナー バージョンの比較 (同じマシン/モデル、2026 年 5 月 29 日)
| Version | 中央値トク/秒 | Metal |
|---|---|---|
| 0.6.1 | 29.2 | OK |
| 0.6.2 | 28.8 | わかりました;時折バッファーの再割り当てが発生する 警告 |
| 0.6.3 | 29.6 | わかりました;再割り当ての減少 警告 |
7. 対照実験 (直観に反する 3 つのセット)
7.1 公平な負荷: 軽いものと重いもの (目標は異なります)
「14Bの16GBより8Bの24GBの方がスムーズに感じる」not同品質の比較。同じ壁時計 500 トークン:
| Config | Model | 中央値トク/秒 | ~500トークン | 品質レベル |
|---|---|---|---|---|
| 16GB クリーン | ジェマ3:4b | 39.8 | ~12.6 s | light |
| 16GB クリーン | ラマ3.1:8b | 28.8 | ~17.4 s | general |
| 16GB搭載 | qwen2.5:14b | 3.4 (交換後) | ~147 s | 高品質だが失敗した |
| 24GB クリーン | qwen2.5:14b | 15.8 | ~31.6 s | コーディングのスイートスポット |
条件付き結論:14B の品質が必要な場合は、24GB が限界です。速度だけが必要な場合は、16GB + 8B で十分です。no「より良い価値を得るには、16GB に 14B を強制します。」
7.2 同一マシン A/B: スワップオフとオン (8B; §5 フェーズ 1→3)
| 状態 | run1 | run2 | run3 |
|---|---|---|---|
| 交換する、掃除する | 28.1 | 29.8 | 27.2 |
| 人為的な負荷からクリティカルまで | 18.6 | 9.1 | 3.2 |
7.3 MLX 対 Ollama (同じプロンプト / ctx / デコード)
ラマ 3.1 8B 4 ビット、512/256、num_ctx=2048、temp=0.2、16GB クリーン:
| フレームワーク | 実行シーケンス tok/s | median | TTFTサンプル |
|---|---|---|---|
| オラマ 0.6.2 | 28.1 / 29.8 / 27.2 / 31.1 | 28.8 | 1.82 / 2.61 / 1.94秒 |
| mlx-lm 0.22.x | 30.4 / 29.1 / 31.6 / 28.3 | 29.8 | 1.71 / 2.10 / 1.88秒 |
MLX は同様の実行ジッターで最大 3 ～ 8% 高速です。エージェント配信では依然として Ollama HTTP が優先されます。詳細:関連記事.
8. M4 Mac Mini LLM メモリマトリックス (16GB / 24GB / 32GB 測定値)
§1 因果モデルと§4 ～ §7 の測定結果からの工学的判断 (公式仕様ではありません)。
| モデル (Q4_K_M) | 重み目安 | 16GB | 24GB | 32GB |
|---|---|---|---|---|
| クウェン2.5 / クウェン3 7B | ~4.5 GB | ✅ 推奨 | ✅ 推奨 | ✅ 推奨 |
| ラマ 3.1 8B | ~4.9 GB | ✅ 推奨 | ✅ 推奨 | ✅ 推奨 |
| DeepSeek-R1-蒸留 8B | ~5.5 GB | ✅ 推奨 | ✅ 推奨 | ✅ 推奨 |
| ジェマ 3 4B / ファイ-4-ミニ | ~3 GB | ✅ 高速 | ✅ 高速 | ✅ 高速 |
| Qwen2.5-Coder 14B | ~9 GB | ⚠️ 境界 | ✅ 推奨 | ✅ 推奨 |
| ラマ 3.1 13B / ファイ-4 14B | ~8–9 GB | ⚠️ 境界 | ✅ 推奨 | ✅ 推奨 |
| クウェン2.5 32B | ~20 GB | ❌ | ⚠️ 境界 | ✅ 利用可 |
| ラマ 3.1 70B | ~40 GB | ❌ | ❌ | ❌ |
70B には M4 プロ 48GB+ が必要です。M4 Pro ローカル LLM 運用ガイドを参照してください。
9. シナリオ別のモデルの選択
9.1 日常会話・メール要約
16GB: ラマ3.1:8b or qwen2.5:7b一般英語用。強力な多言語能力qwen2.5:7b. 24GB:にアップグレードするqwen2.5:14b命令に従うのが難しく、スレッドが長い場合。
9.2 コーディングとクロードコードのローカルエージェント
Agent には安定した HTTP と長いコンテキストが必要です。オラマ API の serve 1 本で Claude Code に接続できます。16GB は qwen2.5-coder:7b、24GB は qwen2.5-coder:14b。ローカル AI Agent の設定と API コストは M4 Mac Mini ローカル AI Agent 実測 を参照してください。
9.3 推論/数学/思考連鎖
DeepSeek-R1 蒸留は 8B で輝きます:ディープシーク-r1:8b(16GB) またはディープシーク-r1:14b(24GB)。 R1 はより長い推論チェーンを発行します。同じ tok/s はより長い壁時計を意味します。これはモデルの動作であり、Mac のせいではありません。
9.4 多言語およびオープンソースのエコシステム
ラマ 3.18B / 13B には最も多くのツールと Modelfile ドキュメントがあります。チームがすでに Llama ベースの RAG を実行している場合は、Llama を使い続けることで移行コストが削減されます。
9.5 超軽量アシスタント
ジェマ3:4bクリーンラン: 38.2 / 41.0 / 36.7 / 39.6 tok/s (中央値 39.4、非整数)。
10. Ollama の最小限のセットアップ
コマンドは新しい Mac Mini M4 で検証されました。 Ollama は Metal を自動的に使用します。手動の GPU フラグは必要ありません。
10.1 インストールと確認
curl -fsSL https://ollama.com/install.sh | sh
ollama --version
ollama run qwen2.5:7b "統合メモリがローカル LLM にとって重要な理由を三文で説明してください"First runモデル (約 4 ～ 5GB) をプルします。維持 > SSD に 20GB の空きがあります。ログ行ggml_metal_initメタルバックエンドがロードされていることを意味します。
10.2 メモリ層によるプル
# —— 16GB Mac Mini M4 ——
ollama pull qwen2.5:7b
ollama pull qwen2.5-coder:7b
ollama pull ラマ3.1:8b
ollama pull ディープシーク-r1:8b
# —— 24GB Mac Mini M4 ——
ollama pull qwen2.5:14b
ollama pull qwen2.5-coder:14b
ollama pull llama3.1:13b
# —— 32GB: optional 32B (slower) ——
ollama pull qwen2.5:32b10.3 チーム共有API
OLLAMA_HOST=0.0.0.0:11434 ollama serveクライアントに次の点を指示しますhttp://<mac-ip>:11434LAN上で。運用環境ではファイアウォールまたは Tailscale を使用します。11434 を公共のインターネットに公開しないでください。
10.4 ベンチマークの実行と生のログの差分
ollama pull ラマ3.1:8b
./リソース/benchmark-m4-mac-mini-ollama.sh ラマ3.1:8b 2>&1 | tee my-run.log
diff -u リソース/サンプル-ベンチマーク-run.log my-run.log11. 16GB → 24GB → M4 Proの決定
| 主な目標 | 推奨される構成 | 理論的根拠 |
|---|---|---|
| 個人トライアル、7B チャット / ライトコーディング | M4 16GB | 最低コスト、完全な 8B 第 4 四半期エクスペリエンス |
| クロード コード エージェント、14B コーディング、小規模なチーム シェア | M4 24GB | 安定した 14B + API ヘッドルーム、最高の価値 |
| 32B をローカルで実行する必要がある、long-ctx 実験 | M4 32GB または M4 プロ 48GB | 32GB ベースは動作しますが、速度が遅いです。 Pro はより高い帯域幅を備えています |
| 70B、高速 32B、マルチモデル同時実行 | M4 プロ 48GB+ | 帯域幅とメモリのデュアルゲート。プロの記事を参照 |
不明な場合は、次の環境で 1 週間のベンチマークを実行します。クリーンシステム、ログ スワップ ピークと §5 の三相崩壊を考慮して、24GB と M4 Pro を決定します。最大スペックを事前に購入するよりも安価です。
12. 実験上の差異に関するメモ
同じ構成、同じスクリプト:中央値は日付によって±12%異なる場合があります- ローカル LLM ベンチマークでは正常であり、失敗した実行ではありません。
| 変数 | 観測範囲 | 報告原則 |
|---|---|---|
| 日付/室温 | 中央値 27.9 ～ 29.2 (8B 16GB) | 単一ポイントではなく、レポート間隔 + 未処理の実行 |
| オラマ 0.6.1→0.6.3 | ~±1 トーク/秒 | 日の差異よりも小さい。レコードバージョン |
| 熱機 / ファン | 29.8 → 25.1 (−12%) | ログに記録し、除外しないでください |
| GC / メタル リアロック | 単一実行の外れ値 31.1 または -5% | 中央値のみではなく、p90 をレポートします |
| クロムの背景 | 20.8トーク/秒 | ベースラインではなく別の行 |
中央値がこの記事と 15% を超えて異なる場合は、まず Ollama バージョン、num_ctx、温度、切り替えのはい/いいえ、サーマル。未加工ファイル:サンプルベンチマーク実行.log, raw-vm-stat-dump.txt, ollama-debug-excerpt.log.
We 意図的に保管するウォームラン (25.1 tok/s) と午後の異常値 (24.3 tok/s) — かなりの中央値だけでは、構成ミスによるノイズを区別することはできません。それが、ラボノートとマーケティングベンチマークの間の境界線です。
FAQ
M4 Mac Mini 16GB は 70B を実行できますか?
No. 70B Q4 の重量は最大 40 GB 以上で、16 GB の物理 RAM を超えます。 「16GB で 70B を実行」 mmap トリックは SSD を RAM として使用します。通常は <; 3 - 実用的ではありません。
24GB は 16GB よりどれくらい速いですか?
同じ 8B、クリーン: 16GB 5 回の実行中央値28.8トーク/秒、24GB 中央値51.2。 Chrome を使用すると、1 回の実行で 16 GB が 20.8 まで低下する可能性があります。バックグラウンド負荷の感触は RAM 層を上回ることがよくあります.
オラマかMLXか？
API、クロードコード、マルチモデル切り替え→Ollama。 Python の評価、カスタム サンプリング → MLX。どちらもインストールできます。 2 つの大きなモデルを同時に常駐させないでください。
Q4 と Q8 の量子化?
16GB: Q4_K_M を開始します。 8B の 24GB では、Q8 の品質を試すことができます。 14BはまだQ4。 Q8 24GB の 14B はメモリの上限に近づいています。
スワップ中かどうかはどうすればわかりますか?
アクティビティ モニター → メモリ → スワップの増加を監視します。またはsysctl vm.swapusage。 §5 フェーズ 3 の Swapins > 0 および tok/s (1 桁) は、E2 圧力崩壊です。ハイパーパラメータ調整ではなく、より小型のモデルまたはより多くの RAM です。
なぜ 24GB は 16GB よりもはるかに速いのでしょうか?
帯域幅が 2 倍になっていない (同じ M4 ダイ、同様の L2)—L1 のヘッドルームが増加、L3 は発火しない: 16GB クリーン 8B 中央値 ~28.8、24GB ~51.2。 §1.4 および §5.2 を参照してください。
ベースM4対M4プロ?
同じ 8B Q4、クリーン: M4 24GB 中央値 51.2、M4 Pro 48GB 中央値 75.9 (同じラボ スクリプト)。 Pro は同時バッチ処理の方が有利です。シングルユーザーのエージェントには Pro は必要ないかもしれません。
エージェント: tok/s それとも TTFT?
最初のターンは TTFT (§6.1) を考慮します。長い返信はトークを気にします。スワップ下では、TTFT は 1.82 秒→ 5.8 秒になる可能性があります。フレームワークを切り替える前にメモリを修正します。
チームに物理的な Mac がありませんか?
Ollama を専用の macOS ホストに展開します。メンバーは LAN 上でこれをヒットします。ここと同じコマンドを実行します。リモート macOS で§5 の崩壊と§4 の障害を再現するには、以下の「ラボ環境の開示」を参照してください。
Summary
M4 Mac Mini のローカル LLM 制限は、L1 容量 + L2 帯域幅 + L3 圧力によって設定されます。16GB コンフォート ゾーン 7B ～ 8B (L2 安定中央値 ~29 tok/s)。 24GB 安定した 14B (~16 トーク/秒); 32Bの前は32GB。 70BにはM4 Proが必要です（E1容量枯渇）。
条件付きアドバイス:シングルユーザー エージェント、7B ～ 14B 範囲 - 8B で 24GB は、16GB で 14B を強制するよりも多くの場合 (§7.1 フェアロード テーブル)。複数の同時実行またはバッチ推論には、より多くのノードまたは Pro が必要です。ハードウェア上で§1 因果モデル + §3 生ログ + §5 フェーズ 1 ～ 3 を使用して再検証します。中央値だけをコピーしないでください.
参考文献
- オラマのドキュメント— インストール、API、メタル バックエンド
- Apple Metal のドキュメント— GPU 推論の基本
- メタラマ 3.1— モデルのスペックとライセンス
- Qwen2.5 リリースノート— 7B / 14B の能力限界
- Apple MLX プロジェクト— フレームワーク比較リファレンス
- ラマ.cpp— Ollama エンジンと GGUF 量子化
この記事は、3週間のエンジニアリングログ、ワンショットのスナップショットではありません。未加工のアーティファクト:
リソース/サンプル-ベンチマーク-run.log— ベンチマーク出力リソース/raw-vm-stat-dump.txt— vm_stat / トップ / メモリステータスリソース/ollama-debug-excerpt.log— Ollama 冗長 + 失敗セッションリソース/benchmark-m4-mac-mini-ollama.sh— 再現スクリプト
ラボ環境開示（インフラ開示）
ベンチマークは実行されました物理的なMac Mini M4ハードウェア: いくつかの Mac Stripe 専用リース ノード (ノイジー ネイバー仮想化なし)、いくつかのラボ ベンチ マシン。 macOS 15.4、オラマ 0.6.2。 Mac Stripe は M4 Mac Mini のリモート リースを提供します。ここでの結論依存しないでください特定のベンダーで動作する場合は、独自のハードウェアで再現できます。
リモート macOS (ローカル Mac を持たないチームなど) で§5 の崩壊と§4 の障害分類を再現するには、次のモデルとリージョンを参照してください。Macstripe ホーム- オプションのインフラストラクチャであり、この記事の結果の前提条件ではありません。
関連書籍 (トピッククラスター)
この記事では、どのモデルが適合するか、およびラボの生データについて説明します。コンパニオンは、分割されたフレームワーク、プロ レベル、およびエージェントのロールアウトを投稿するため、1 つのページが広がりません。
- M4 Mac Mini：7B vs 14B 実測（決定 Spoke：TL;DR + TTFT）
- MLX 対 Ollama: Apple Silicon 推論フレームワーク（テクニカル）
- M4 Pro ローカル LLM 運用ガイド(70B/32B層)
- M4 Mac Mini のローカル AI エージェントのセットアップと API のコスト(展開)
- 統合メモリが LLM 推論に与える影響（理論）
