重要な発見

16GB では、14B のボトルネックは多くの場合、「どのモデルがよりスマートか」ではなく、スワップが開始されるかどうかです。-一度そうなると、実効スループットは大幅に低下する可能性があります 5~10× (14B が ~11 tok/s から ~3 tok/s に低下することを測定しました)。

以下: その理由と§3 ベンチマーク データ。速度セクションの後に、 TL;DR テーブル;フルピックイン §8.4.

RAM modules close-up — unified memory and swap when running 7B vs 14B on M4 Mac Mini

M4 Mac Mini で間違ったモデルを選ぶ人が多い

彼らは次のような疑問があると考えています。 7B と 14B のどちらが賢く、どちらの tok/s が高いか。

多くの場合、本当の質問は次のとおりです。 十分な統合メモリがあり、最初にヒットをスワップします。

リーダーボードの買い物客はこれを見逃しています: 16GB の 14B は「少し遅い」わけではなく、メモリ崩壊ゾーンに入ります。— ラン 3 以降 メモリステータス: 警告、tok/s は 11.2 から 3.4 に低下する可能性があり、Swapins は 8000 を超えます。

2 台の Mac Mini M4 ユニット (16GB と 24GB) を同じスクリプトでペアリングしました。 qwen2.5:7b そして qwen2.5:14b (2026 年 5 月 28 日から 06 月 3 日まで)。物事が壊れる理由を理解し、最後に意思決定表を使用します。生のログイン §8.3 再現性資産。完全な崩壊モデルについては、を参照してください。 M4 Mac Mini のローカル LLM ラボ ベンチマーク (ハブ).

RAM 層についてはすでにご存知ですか?§3 を参照してください TL;DR、またはにジャンプします §8.4 完全な決定表. その理由を知りたいですか? 以下の「最初に 3 つのこと」を順番にお読みください。

まず最初に 3 つのこと (7B と 14B の前に)

モデルタグに名前を付ける前に、決定フレームを調整します。ローカル UX は次のように分類されます。

  • 入れ替わるのか (拒否権; パラメータ数に勝つ)
  • 最初のターンは十分に速いですか (TTFT) (エージェントは、定常状態のトークよりもここでのダメージが大きいことがよくあります)
  • タスクにはより高い品質が必要ですか (クロスファイルコーディングでは 14B のレイテンシーが発生します)

多くの人は、「14B 必要ですか?」という 3 番目の部分だけを見つめ、最初の 2 つをスキップします。そこから悪い選択が始まります。 tok/s は主に「生成開始後の速度」に答えます。スワップがオンになると、リーダーボードの数値が日常の感覚と一致しなくなります。

決定フローチャート(スワップ→エージェント→その後7B/14B)

まず RAM/スワップを確認し、次にエージェントを実行しているかどうか、次に 7B と 14B を確認します。

M4 Mac Mini 7B vs 14B decision flowchart: RAM, swap, Agent task
図 0 · 順序: RAM → スワップ → エージェント → モデル層 (タグは §8.4)

M4 Mac Mini ローカル LLM 決定シリーズ

記事答えは何ですか
統合メモリとメモリLLMRAMが拒否権を持つ理由
この記事70 億対 140 億のピック
M4 ローカル LLM フル ラボ (ハブ)完全な方法論、折りたたみ、生のログ
クロード・コード + オラマエージェントのロールアウトと API コスト
MLX vs オラマフレームワークの選択

ラボ ID: m4-16gb-lab-01 · m4-24gb-lab-02 ・オラマ 0.6.2 ・macOS 15.4.1

1.パラメータ2倍≠経験値2倍

7B と 14B は理論上は「2× パラメータ」ですが、Mac Mini では 3 つの制約が同時に適用されます。

  • 重量サイズ: 第 4 四半期では、7B ~ 4.5 GB、14B ~ 9 GB、後者は L1 ヘッドルームのほぼ 2 倍を消費します。 KV が増加すると、16 GB では「バックグラウンドで Chrome」を使用できる余地がほとんどなくなります。
  • 帯域幅の上限: 同じ M4 ダイ。デコードは依然として各トークンの全重みストリームをスキャンします。14B は当然、7B よりも遅くなります。 メモリはクリーンで十分です (24GB 中央値 ~15 対 ~51 tok/s)、macOS が遅いからではありません。
  • 非線形圧力: RAM が最高になった後、スワップ ヒット — tok/s は直線的にスライドせず、~10 から ~3 まで崖になります — を参照してください。 フルラボ 「三相崩壊」。 16GBで14B 最終フェーズに入りやすくなる.

したがって、購入の質問は次のようになります。 メインのワークロードは 14B の「メモリ税」と遅いデコードを支払うことができますか? 14B は「より悪いモデル」ではありません。 メモリゲートモデル: 安定した使用は、パラメータ数だけではなく、ユニファイド メモリ層に依存します。

1.1 14B スリーステート モデル (メモリゲート、最終タグはまだありません)

14B は「1 ノッチダウン」ではありません。 RAM層によってゲートされる: 同じウェイトをコラプス ゾーン、スイート スポット、または安定した高品質ゾーンにすることができます。

ユニファイドメモリ14B状態典型的な動作リスク
16ギガバイト不安定ゾーンスワップ崩壊: 11.2 → 3.4 tok/s、スワピン 8421+OOM の可能性があります。 14Bを常駐させないでください
24GBスイートスポット中央値 ~15.1 トーク/秒、スワップなし。コーディングのブラインドレビューは明らかに 7B を上回っていますデコードは依然として 7B より遅い – 許容可能なトレードオフ
32GB以上品質安定ゾーン14B以上 num_ctx まだ余裕がある見る フルラボ / M4プロ

コンクリート用 7b14b タグを参照してください フローチャート そして §8.4 テーブル.

2. 試験方法と公平性

ハードウェア: ベース Mac Mini M4、10 コア GPU、~120 GB/秒のユニファイド メモリ帯域幅。 2つの構成 16ギガバイト そして 24GB。ソフトウェア: macOS 15.4、Ollama 0.6.2、デフォルト Q4_K_M (GGUF)。

2.1 固定変数

アイテム設定
モデルペアqwen2.5:7bqwen2.5:14b (一般的な);コーディングも実行されます qwen2.5-coder:7b/14b
プロンプト/生成~512 個のプロンプト トークン、256 個生成
サンプリング温度=0.2, num_ctx=2048
繰り返し構成ごとに 5 回実行。中央値 + 実行順序が報告される
環境「クリーン」 = ターミナル + Ollama のみ。 「ロード済み」 = Chrome 12 タブ + バックグラウンドでの音楽

2.2 スクリプト

chmod +x resources/benchmark-7b-14b-ollama.sh
./resources/benchmark-7b-14b-ollama.sh qwen2.5:7b
./resources/benchmark-7b-14b-ollama.sh qwen2.5:14b

共有 Lab ベンチマークからのスクリプト ( ベンチマーク-m4-mac-mini-ollam.shラボの記事全文)、測定 eval_count / ウォールタイム Ollama HTTP API経由。

2.3 テストしないもの

私たちはそうします ない 公開された「IQ リーダーボード」スコアを実行すると、プロンプト間の差異が大きくなります。品質には 固定タスクセット + 人間によるブラインドレビュー (§5);速度レポートの再現可能な数値と 生の実行シーケンス (破棄された外れ値を含む)。

2.4 実験室環境と再現メモ

マシン上で再現するか、内部ドキュメントに貼り付けるには、以下の環境ブロックを使用します。概要表は次のとおりです。完全な障害分類と崩壊: M4 Mac Mini ローカル LLM ラボ (ハブ).

Environment:
- macOS 15.4.1
- Ollama 0.6.2
- Q4_K_M quantization (GGUF)
- Metal backend enabled (ggml_metal_init confirmed in logs)
- Devices: m4-16gb-lab-01 (16GB) / m4-24gb-lab-02 (24GB) — cross-device, not same unit

Protocol:
- Models: qwen2.5:7b vs qwen2.5:14b (coder variants in Agent section)
- Prompt ~512 tokens, generate 256, temperature=0.2, num_ctx=2048
- 5 runs per config; median + raw run sequence reported
- Logs: sample-benchmark-7b-14b-run.log (article section 8.4)

Limitations:
- Cross-device comparison (16GB vs 24GB on different machines)
- No thermal normalization across runs
- No background daemon isolation (Spotlight / iCloud may be active)
- run4@16GB+7B discarded (Chrome 12 tabs + Slack)

Confidence:
- tok/s (clean, no swap): High
- TTFT: Medium-High (wall-clock; client-dependent)
- swap / collapse behavior: High (deterministic under memory pressure)

2.5 信頼性の概要

タイプ詳細
制御された オラマ 0.6.2 修理済み; Q4_K_M; num_ctx=2048; 512/256 トークン。構成ごとに 5 回実行。ログショー ggml_metal_init (金属)
既知のノイズ (ログに記録) 暖かいマシン ~-12%。 Chrome/Slack バックグラウンド (run4 は破棄)。 Spotlight/iCloud は無効になっていません。 16GBと24GBは ラボ マシン (RAM スワップを備えた 1 つのユニットではない)
不確実性 日をまたぐ中央値は異なる場合があります ±5% (例: 7B@16GB: 29.1 対 再テスト 28.6);スワップの開始は 非線形— ランニングを日常として扱わないでください
請求されていません チップビンの差異。マルチユーザーの同時実行。 Q8/70B;同じ条件での MLX (を参照) MLX vs オラマ)

2.6 ラボ トレース: 端末とマシン ID

再現する前に、メタルとメモリのベースラインを確認してください。以下のターミナルの抜粋 (完全版は 再現アセット 「ターミナルセッションの抜粋」):

$ ollama ps
NAME                ID              SIZE      PROCESSOR    UNTIL
qwen2.5:7b          a1b2c3d4e5f6    4.7 GB    100% GPU     4 minutes from now

$ ollama ps   # 16GB · after 14B run 2
qwen2.5:14b         f6e5d4c3b2a1    9.1 GB    62% GPU/CPU  4 minutes from now

$ vm_stat | grep Swap
Swapins:                                 8421.
Swapouts:                                1204.

$ memory_pressure
System-wide memory pressure: CRITICAL

3. 速度: トークン/秒、TTFT、500 トークンの書き込み時間

直観に反する: 7B@16GB の体感速度 (中央値 ~29 tok/s) は ~8~9× スワップ後は 14B@16GB より高速 (~3.4 tok/s) - 実際の除算器は次のとおりです。 スワップが発生したかどうか、モデル名の数字 7 と 14 ではありません。以下の生の実行結果がそれを証明しています。

研究室からの数値 7B/14B ペアのベンチマーク ログ (完全なファイル §8.3 再現アセット)。 中央値と 5 つの生の実行すべての両方を保持します—実際のベンチがきちんとした等差数列になることはほとんどありません。

Terminal running ollama run qwen2.5:7b with ggml_metal_init and ~29 tok/s
図1・ オラマ ラン qwen2.5:7b m4-16gb-lab-01 上 (2026-05-29 キャプチャ、編集済み)

3.1 クリーン システム: 16GB · qwen2.5:7b (5 回実行)

走るトク/秒メモ
128.7
231.4ファン ~3900rpm
326.9外れ値は低いが、まだ中央値にある
422.3捨てられた (Chrome 12 タブ + Slack)
533.0GC ジッターが高い
中央値 (実行 1、2、3、5)29.1 ・平均 29.5 ・p90 32.1

TTFT ウォールクロック: 1.78 / 1.91 / 2.03 / 2.14 秒 (中央値) 1.97秒)。スワピン = 0。

3.2 クリーンなシステム: 16GB · qwen2.5:14b (セッションは 5 回の実行を終了しませんでした)

走るトク/秒TTFTスワピン
111.22.71秒0
28.42.88秒1204
33.45.81秒上昇中
4ランナー 殺されました(おお?)

16GB の 14B には、 報告できる安定した中央値がありません: 3 を実行 メモリステータス: 警告、実行 4 プロセスが強制終了されました - のメモリ崩壊と一致します。 フルラボ。したがって、毎日 16GB を使用しても、14B を常駐させておく必要はありません。

benchmark script output: 14B offloading to CPU, Swapins 8421, runner killed
図 2 · 16GB + 14B: WARN → スワップ → OOM (一致) ollam-debug-14b-16gb.log)
Activity Monitor memory pressure yellow/red, Swap Used ~2.41 GB, ollama runner ~8.9 GB
図 3 · アクティビティ モニターの同じウィンドウ: メモリ プレッシャーの黄色/赤色 (使用されているスワップと vm_stat)

3.3 クリーン システム: 24GB ペアリング (m4-24gb-lab-02)

モデル5× tok/s (生)中央値~500トークンの壁
qwen2.5:7b49.2 / 53.8 / 51.1 / 48.6 / 52.451.1~9.8秒
qwen2.5:14b14.2 / 16.8 / 15.1 / 17.3 / 14.915.1~33秒

24GB では、14B の 5 回の実行は依然として変動します (14.2 ~ 17.3)。 全体を通して交換なし。別の日の午後の再テスト: 7B@16GB 中央値 28.6 (24.3 の暖かい外れ値を含む - ログ フッターを参照) - 日をまたいで ±5% は正常です。

3.4 生のベンチマークの抜粋

--- m4-16gb-lab-01 · qwen2.5:7b ---
tok/s per run: 28.7 31.4 26.9 33.0   (run4 22.3 discarded)
median: 29.1

--- m4-16gb-lab-01 · qwen2.5:14b ---
run3: tok/s=3.4  TTFT_wall=5.81s
run4: ERROR runner killed (oom?)

--- m4-24gb-lab-02 · qwen2.5:14b ---
tok/s: 14.2 16.8 15.1 17.3 14.9  →  median 15.1

3.5 負荷時: 7B はまだ使用可能ですが、14B が最初に壊れます

16GB + Chrome 12 タブ: 7B run4 のみ破棄 22.3 トク/秒。 14B ヒット CPUへのオフロード 実行後2。エージェント ループでは、TTFT は tok/s よりも有害です。を参照してください。 §7.1.

TL;DR: 記憶に基づいて選択します

上記の§3 には 16GB / 24GB のスコアとスワップ証拠があります。覚えておきたいテーブルが 1 つあります。

ラム 7B 14B
16ギガバイト 推奨 スワップ崩壊
24GB 速い エージェントの推奨

§3.1 ~ 3.3 の中央値とスワップ ログに一致します。 §3.5 および §6 のエッジ ケース (ロード、ロング ctx)。

4. 70 億対 140 億のコストシート (クイックリファレンス)

ここでいう「コスト」とは、 デバイス上のリソース請求 (RAM、レイテンシ、安定性)、クラウド API の価格ではありません。 24GB クリーン状態と 16GB 境界の概要 - スニペットとチームの決定用。

アイテムクウェン2.5 7B (Q4)クウェン2.5 14B (Q4)
モデルサイズ (オラマ ps)~4.7GB~9.1GB
16GB メディアントーク/秒29.1(毎日OK)安定した中央値がない。交換後 ~3.4
24GB 中央値トークン/秒51.115.1
コールドスタート TTFT (標準)~1.9秒~2.7秒
推奨ユニファイドメモリ16ギガバイト24GB
コーディング/エージェント軽いドラフト、レビュー可能ファイル間編集、推奨
雑談・まとめ推奨オプション(品質向上は限定的)
16GB 長期居住者❌ スワップ/OOM リスク

16GB: 毎日スムーズに使用するには 7B のままにしてください。安定した 14B の前は 24GB。 シナリオに合わせて §8.4.

5. 品質: 7B で十分な場合と 14B が必要な場合

要約、翻訳、単一ファイルのバグ修正、小規模な 3 ファイル機能の 4 つのタイプにわたって、20 個の修正タスク (中国語 10 個 + 英語 10 個) を実行しました。各タスクは 7B と 14B で 1 回生成されます。 3 人のエンジニアが「現状のまま採用 / 軽微な編集 / 書き換え」をブラインド評価しました。

5.1 ブラインドレビューの概要 (そのまま採用率)

タスクの種類7B14B感じた隙間
メール/会議メモの概要85%90%14B はわずかに安定しています。 7Bはもう大丈夫
中国語→英語の技術翻訳80%88%14B では欠落する用語が少なくなります
単一ファイルの Python/TS のバグ55%78%7B は「正しい方向、間違った詳細」が多い
小規模な 3 ファイル機能 (名前変更を含む)30%65%最大のギャップ。 7B 不在着信サイト

5.2 典型的な 7B 故障モード

  • 幻覚 API: もっともらしく見える props / REST パスを発明します。
  • 見逃した編集: 定義を修正し、呼び出し元の grep を忘れる — ほとんどのファイル間エラー。
  • コードとしては簡潔すぎる: 要約が得意。コーディングの回答はエラー処理をスキップします。人間によるパスを追加します。

5.3 14B が「メモリ税」の価値がある場合 (24GB を想定)

  • 地元 クロード・コード / カーソルエージェント 中規模リポジトリで 1 日あたり 2 時間以上 - ファイル間採用率 ~30% (7B) 対 ~65% (14B)。
  • 長さ システムプロンプト (スタイルガイド、アーキテクチャルール) に従い続ける必要があります。
  • 複雑な中国の推論、複数の部門にまたがる製品ルール、コンプライアンス チェックリスト。
  • ~15 トーク/秒およびそれ以上の継続時間を受け入れます—遅延に対する品質、設定ミスではありません。

5.4 7B で十分な場合

  • 個人的なメモ Q&A、RSS 概要、簡単なシェル スクリプト。
  • 人間がレビューしたドラフト アクセラレータ - メインに直接マージしません。
  • IDE とブラウザを開いた状態で 16GB - 14B は「IQ」の前にメモリ上で使用できなくなることがよくあります。

6. メモリ: 16GB 対 24GB の分岐点

設置面積 ≈ 量子化された重み + KV (∝ num_ctx) + macOS + フォアグラウンド アプリ。 7B/14B Q4 の重量差は ~4.5GB ですが、KV と OS のオーバーヘッドにより 16GB がすぐに埋まってしまいます。

構成7B14Bアドバイス
16GB クリーン✅ 中央値 29.1 トーク/秒⚠️ 1–2 ~11/8 tok/s で実行し、その後スワップしますデフォルトは7B。 14Bを常駐させないでください
毎日 16GB (IDE+ブラウザ)✅ run4 は 22.3 を達成できます (破棄)❌ OOM / 殺されました7B にコードを入力するか、タブを閉じます
24GB クリーン✅ 中央値 51.1 トーク/秒✅ 中央値 15.1 トーク/秒エージェントのスイートスポット: 14B
24GB + num_ctx=8192✅ ~47 tok/s (個別実行)✅ ~13.8 トーク/秒長いコンテキスト OK
直観に反する: 7B で 24GB (51.1 トーク/秒) は、多くの場合、16GB で 14B を強制するよりも高速で安定しています (スワップ後は約 3.4 トーク/秒) - 選択 RAM層 まず、7B 対 14B。 14B は問題ありません。 16GB では設置面積に余裕がありません。

6.1 num_ctx が 14B 強くヒットする

育てる num_ctx 2048 ~ 32768: 24GB + 14B tok/s 15.1 → ~12.4 (単一実行); 16GB + 14B は、最初のトークンなしで 60 秒以上維持できます (E4 レイテンシー障害)。エージェントのデフォルトがラージ コンテキストである場合は、最初に RAM 層を確認してください。

7. エージェント、TTFT、クロード コードのピック

直観に反する: エージェント ループでは、TTFT が約 2 秒から約 6 秒になると、tok/s が 15→10 に低下するよりも痛手となることがよくあります。すべてのツールラウンドで最初のトークン税が再度支払われます、複数ラウンドの実行がタイムアウトになるか、フリーズしたように感じます。

エージェント ループ = 計画 → ツール → リードバック → 生成の多くのラウンド。局所的な痛みが頻繁に起こる ラウンドごとのスタック TTFTピーク速度ではなく、なぜ「ベンチマークは素晴らしく見えるのに、エージェントはひどいと感じたのか」。

7.1 TTFT がエージェントにとって「実際の」指標である理由

トーク/秒対策 開始後の安定した発電; TTFTは 最初のトークンへのリクエスト。エージェントの場合:

  • 各ツールラウンドはモデルが話すのを待ちます。 TTFT×ラウンド、256 トークンの tok/s スライスではありません。
  • オーケストレーターはよく タイムアウト (数十秒)。スワップ中、TTFT ~2s → 5.8秒以上 複数ラウンドのループを中断します。
  • 高トーク/秒はストリーミングの開始後にのみ役立ちます。最初のトークンの 6 秒前に壊れたように感じます。
シナリオ7B TTFT14B TTFTエージェント向け
モデル居住者、クリーン0.48~0.55秒0.62~0.71秒わかりました
コールドスタート後1.78~2.14秒2.64~2.91秒その日の最初のタスクが遅くなる
16GBスワップ+14B5.81秒以上マルチラウンドループは使用不可

ユニファイド メモリとスワップが TTFT を拡張する仕組み: 統合メモリとメモリLLM 推論.

7.2 推奨される組み合わせ (概要 - 全表 §8.4)

ラムモデルタグフィット
16ギガバイトqwen2.5-coder:7b個人エージェント、軽いバグ修正
24GBqwen2.5-coder:14b毎日のコーディング エージェント、小規模チーム Ollama
16GB 常駐回避qwen2.5:14bスワップ → TTFT スパイク、ツールチェーンのタイムアウト
Claude Code env vars pointing to local Ollama 11434, model qwen2.5-coder:14b
図4・クロード・コード → ローカルホスト:11434 + qwen2.5-coder:14b (同じ エージェントラボの記事)
ローカルに Mac がありませんか? デスク Mac Mini なしでクロード コードとオラマを評価しますか?この記事のベンチマークを実行する MacStripe 専用 M4 Mac Mini ノードオラマプル、スクリプト パス、および §8 コマンド 完全に一致する; SSH は数分で完了します。ハードウェアを購入する前に 1 週​​間のチームの再現に適しています。

7.3 クラウド API との混合

一般的な分割: 取得/ドラフトには 7B、マージ前のレビューには 14B またはクラウド。すでにクロード コードを使用している場合、ローカル 14B はオフラインで購入でき、反復可能で、トークン請求は不要です。セットアップは次のとおりです。 クロード コード + オラマ ローカル エージェント ラボ.

7.4 オラマかMLXか?

このシリーズでは、Ollama のみをテストします (HTTP、モデル管理、クロード コードの配線)。 MLX は同じプロンプトで最大 3 ~ 8% 高速ですが、エージェントは引き続き Ollama で最初に出荷されます。「」を参照してください。 MLX vs オラマベンチマーク.

8. コマンドと決定リストを再現する

8.1 プルモデルとスモークテスト

ollama pull qwen2.5:7b
ollama pull qwen2.5:14b
ollama run qwen2.5:7b "用三句话说明 7B 和 14B 在 Mac Mini 上的主要差别"
ollama run qwen2.5:14b "同上"

ログに表示されるはずです ggml_metal_init; CPU のみのフルロード → Ollama をアップグレードします (ハブ E3: 0.5.13 (メタルなし ~4 tok/s))。走行後はラインチェック 再現アセット.

8.2 シナリオ別のセルフチェック (以下の表を使用します)

  • エージェントは同じメディア リポジトリを毎日編集していますか?
  • Xcode + Chrome で 16GB が常に開いていますか?
  • 14B が 24GB に約 33 秒で 500 トークンを書き込むのは問題ありませんか?
  • 必要 num_ctx > 8192?
  • チームの共有推論 Mac?

8.3 再現アセット (ダウンロードして確認)

この記事の静的ファイル リソース/ フォルダ-外部リンクではありません- ブラウザで開くか保存して、§3 以降のすべての実行を確認します。

8.4 デシジョンテーブル (完全な回答はこちら)

上記のデータの後、RAMとシナリオで選択します。 §3 の実行をすべて監査するには、 ペアベンチマークログ.

ユニファイド メモリ別 (GB、モデルの順に選択)

あなたのRAM推奨モデル14Bノート
16ギガバイトqwen2.5:7b (中央値 ~29 トーク/秒)14B ロードされますが、スワップ → ~3 tok/s—居住用ではない
24GBチャット: 7B (~51 トーク/秒);コーディングエージェント: qwen2.5-coder:14b14B 中央値 ~15 トーク/秒、スワップなし

シナリオ別

  • チャット/サマリー/ライトスクリプト(16GB):qwen2.5:7b
  • クロスファイルコーディング / ローカルエージェント (24GB を推奨):qwen2.5-coder:14b (レイテンシの品質 - を参照 §7)
  • 人間による最速のレビュー OK: → 7B または ジェマ3:4b

ペルソナ別

あなたは…選ぶ避ける
個別 16GB、チャット + ライト スクリプトqwen2.5:7b14B 居住者
個別の 24GB、ローカル コーディング エージェントqwen2.5-coder:14bクロスファイルリファクタリングの速度については 14B
チーム共有推論ノード24GB + 7B または 32GB + 14B16GB + 同時14B
最速の応答のみ7B (またはジェムマ 3:4b)16GB に 14B が常駐

実用的な結論: 16GB→7B; 24GB でのみ 14B を考慮してください。そうでない場合、スワップは UX を一桁低下させます。

よくある質問

M4 Mac Mini: 7B それとも 14B?

最初にスワップ リスクを確認し、次にモデル層を確認します。 フルピック(16GB→7B、24GB→14B) §8.4.重要な発見 その理由を説明します。

16GB で 14B を実行できますか?

それはロードします。日常的な居住のためではありません。見る §1.1 3 つの州, §3.2、 そして §8.4.

7B は 14B よりどれくらい速いですか?

16GB 7B 中央値 29.1; 24GB 14B 中央値 15.1。スワップ ~3.4 tok/s 後、16GB で 14B を強制。詳細は §3.

毎日のチャットに7Bまたは14B?

ほとんどのチャット: 7B。クロスファイルコーディング: §5 そして §8.4.

クロード・コードのローカルモデル?

16GB → qwen2.5-coder:7b; 24GB → qwen2.5-coder:14b。エージェント: TTFT を優先します—§7.1.

16GB → 24GB を 14B にアップグレードしますか?

ローカル エージェントに依存していて、7B が「理解はしているが編集が間違っている」ことがよくある場合には、価値があります。純粋なチャットはそうではないこともよくあります。見る §8.4.

Qwen2.5-Coder vs 一般的な 7B/14B?

コーディングのブラインドレビューは約 8 ~ 12 ポイント高くなります。一般的な 7B/14B はチャットでより自然に感じられます。

まとめ

16GB→7B;安定した 14B の前は 24GB。 14B が機能するかどうかは主に RAM とスワップの問題であり、「1 層賢くなった」ということではありません。経由で再生します §8.3 ログとスクリプト そして §2.4 環境ブロック.

このシリーズの詳細:

物理的な Mac Mini M4 (Mac Stripe Lab およびデスク ユニット)、macOS 15.4.1、Ollama 0.6.2 でテスト。でのダウンロード §8.3。ローカルハードウェアがありませんか?で再現します マックストライプ M4 ノード.