重要な発見
16GB では、14B のボトルネックは多くの場合、「どのモデルがよりスマートか」ではなく、スワップが開始されるかどうかです。-一度そうなると、実効スループットは大幅に低下する可能性があります 5~10× (14B が ~11 tok/s から ~3 tok/s に低下することを測定しました)。
以下: その理由と§3 ベンチマーク データ。速度セクションの後に、 TL;DR テーブル;フルピックイン §8.4.
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 ラボ ベンチマーク (ハブ).
まず最初に 3 つのこと (7B と 14B の前に)
モデルタグに名前を付ける前に、決定フレームを調整します。ローカル UX は次のように分類されます。
- 入れ替わるのか (拒否権; パラメータ数に勝つ)
- 最初のターンは十分に速いですか (TTFT) (エージェントは、定常状態のトークよりもここでのダメージが大きいことがよくあります)
- タスクにはより高い品質が必要ですか (クロスファイルコーディングでは 14B のレイテンシーが発生します)
多くの人は、「14B 必要ですか?」という 3 番目の部分だけを見つめ、最初の 2 つをスキップします。そこから悪い選択が始まります。 tok/s は主に「生成開始後の速度」に答えます。スワップがオンになると、リーダーボードの数値が日常の感覚と一致しなくなります。
決定フローチャート(スワップ→エージェント→その後7B/14B)
まず RAM/スワップを確認し、次にエージェントを実行しているかどうか、次に 7B と 14B を確認します。
M4 Mac Mini ローカル LLM 決定シリーズ
| 記事 | 答えは何ですか |
|---|---|
| 統合メモリとメモリLLM | RAMが拒否権を持つ理由 |
| この記事 | 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プロ |
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:7b 対 qwen2.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/14B ペアのベンチマーク ログ (完全なファイル §8.3 再現アセット)。 中央値と 5 つの生の実行すべての両方を保持します—実際のベンチがきちんとした等差数列になることはほとんどありません。
3.1 クリーン システム: 16GB · qwen2.5:7b (5 回実行)
| 走る | トク/秒 | メモ |
|---|---|---|
| 1 | 28.7 | — |
| 2 | 31.4 | ファン ~3900rpm |
| 3 | 26.9 | 外れ値は低いが、まだ中央値にある |
| 4 | 22.3 | 捨てられた (Chrome 12 タブ + Slack) |
| 5 | 33.0 | GC ジッターが高い |
| 中央値 (実行 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 | スワピン |
|---|---|---|---|
| 1 | 11.2 | 2.71秒 | 0 |
| 2 | 8.4 | 2.88秒 | 1204 |
| 3 | 3.4 | 5.81秒 | 上昇中 |
| 4 | — | — | ランナー 殺されました(おお?) |
16GB の 14B には、 報告できる安定した中央値がありません: 3 を実行 メモリステータス: 警告、実行 4 プロセスが強制終了されました - のメモリ崩壊と一致します。 フルラボ。したがって、毎日 16GB を使用しても、14B を常駐させておく必要はありません。
3.3 クリーン システム: 24GB ペアリング (m4-24gb-lab-02)
| モデル | 5× tok/s (生) | 中央値 | ~500トークンの壁 |
|---|---|---|---|
| qwen2.5:7b | 49.2 / 53.8 / 51.1 / 48.6 / 52.4 | 51.1 | ~9.8秒 |
| qwen2.5:14b | 14.2 / 16.8 / 15.1 / 17.3 / 14.9 | 15.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.1 | 15.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 ブラインドレビューの概要 (そのまま採用率)
| タスクの種類 | 7B | 14B | 感じた隙間 |
|---|---|---|---|
| メール/会議メモの概要 | 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 がすぐに埋まってしまいます。
| 構成 | 7B | 14B | アドバイス |
|---|---|---|---|
| 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 |
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ピーク速度ではなく、なぜ「ベンチマークは素晴らしく見えるのに、エージェントはひどいと感じたのか」。
7.1 TTFT がエージェントにとって「実際の」指標である理由
トーク/秒対策 開始後の安定した発電; TTFTは 最初のトークンへのリクエスト。エージェントの場合:
- 各ツールラウンドはモデルが話すのを待ちます。 TTFT×ラウンド、256 トークンの tok/s スライスではありません。
- オーケストレーターはよく タイムアウト (数十秒)。スワップ中、TTFT ~2s → 5.8秒以上 複数ラウンドのループを中断します。
- 高トーク/秒はストリーミングの開始後にのみ役立ちます。最初のトークンの 6 秒前に壊れたように感じます。
| シナリオ | 7B TTFT | 14B TTFT | エージェント向け |
|---|---|---|---|
| モデル居住者、クリーン | 0.48~0.55秒 | 0.62~0.71秒 | わかりました |
| コールドスタート後 | 1.78~2.14秒 | 2.64~2.91秒 | その日の最初のタスクが遅くなる |
| 16GBスワップ+14B | — | 5.81秒以上 | マルチラウンドループは使用不可 |
ユニファイド メモリとスワップが TTFT を拡張する仕組み: 統合メモリとメモリLLM 推論.
7.2 推奨される組み合わせ (概要 - 全表 §8.4)
| ラム | モデルタグ | フィット |
|---|---|---|
| 16ギガバイト | qwen2.5-coder:7b | 個人エージェント、軽いバグ修正 |
| 24GB | qwen2.5-coder:14b | 毎日のコーディング エージェント、小規模チーム Ollama |
| 16GB 常駐回避 | qwen2.5:14b | スワップ → TTFT スパイク、ツールチェーンのタイムアウト |
オラマプル、スクリプト パス、および §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 以降のすべての実行を確認します。
- 7B/14B ペアのベンチマーク ログ — tok/s、TTFT、実行ごとのスワピン (§3 テーブルのソース)
- ターミナルセッションの抜粋 —
オラマ ps,vm_stat,記憶圧 - 16GB 14B Ollama デバッグログ — スワップ/OOMセッション
- ベンチマーク再現スクリプト — と同じロジック フルラボ
8.4 デシジョンテーブル (完全な回答はこちら)
上記のデータの後、RAMとシナリオで選択します。 §3 の実行をすべて監査するには、 ペアベンチマークログ.
ユニファイド メモリ別 (GB、モデルの順に選択)
| あなたのRAM | 推奨モデル | 14Bノート |
|---|---|---|
| 16ギガバイト | qwen2.5:7b (中央値 ~29 トーク/秒) | 14B ロードされますが、スワップ → ~3 tok/s—居住用ではない |
| 24GB | チャット: 7B (~51 トーク/秒);コーディングエージェント: qwen2.5-coder:14b | 14B 中央値 ~15 トーク/秒、スワップなし |
シナリオ別
- チャット/サマリー/ライトスクリプト(16GB): →
qwen2.5:7b - クロスファイルコーディング / ローカルエージェント (24GB を推奨): →
qwen2.5-coder:14b(レイテンシの品質 - を参照 §7) - 人間による最速のレビュー OK: → 7B または
ジェマ3:4b
ペルソナ別
| あなたは… | 選ぶ | 避ける |
|---|---|---|
| 個別 16GB、チャット + ライト スクリプト | qwen2.5:7b | 14B 居住者 |
| 個別の 24GB、ローカル コーディング エージェント | qwen2.5-coder:14b | クロスファイルリファクタリングの速度については 14B |
| チーム共有推論ノード | 24GB + 7B または 32GB + 14B | 16GB + 同時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 ノード.