M4 Mac Mini: 7B vs 14B — насколько отличается в реальной работе? (лаборатория 2026)

На M4 Mac Mini многие выбирают не ту модель

Мы прогнали два Mac Mini M4 (16 GB и 24 GB) одним и тем же скриптом на qwen2.5:7b и qwen2.5:14b (2026-05-28 — 06-03). Сначала разберитесь, почему всё ломается, затем используйте таблицы решений в конце; сырые логи — в §8.3 артефакты воспроизведения. Полная модель коллапса — в лаборатории локального LLM на M4 Mac Mini (хаб).

Три вещи сначала (до 7B vs 14B)

Прежде чем называть тег модели, выровняйте рамку решения. Локальный UX складывается из:

• Будет ли swap (вето; важнее числа параметров)
• Достаточно ли быстр первый ответ (TTFT) (в агентах это часто больнее, чем устойчивый tok/s)
• Нужно ли более высокое качество (межфайловый код — там 14B оправдывает задержку)

Многие смотрят только на третье — «нужен ли 14B?» — и пропускают первые два. Отсюда плохие выборы. tok/s отвечает в основном на «после старта генерации — как быстро»; когда swap включился, цифры с лидербордов перестают совпадать с ощущениями в работе.

Блок-схема решения (swap → агент → затем 7B/14B)

Сначала RAM/swap, затем агент или нет, затем 7B vs 14B:

Серия решений: локальный LLM на M4 Mac Mini

ID лабораторий: m4-16gb-lab-01 · m4-24gb-lab-02 · Ollama 0.6.2 · macOS 15.4.1

1. Удвоение параметров ≠ удвоение опыта

7B vs 14B на бумаге — «2× параметров», но на Mac Mini одновременно действуют три ограничения:

• Размер весов: при Q4 7B ~4,5 GB, 14B ~9 GB — второй съедает почти вдвое больше запаса L1; с ростом KV на 16 GB почти не остаётся места для «Chrome в фоне».
• Потолок bandwidth: тот же кристалл M4; decode по-прежнему сканирует полный поток весов на каждый токен — 14B естественно медленнее 7B, когда память чистая и достаточная (медиана 24 GB ~15 против ~51 tok/s), а не потому что macOS «ленится».
• Нелинейное давление: после исчерпания RAM включается swap — tok/s не падает линейно, а обрывается с ~10 до ~3 — см. полную лабораторию, «трёхфазный коллапс»; 14B на 16 GB легче попадает в последнюю фазу.

Итоговый вопрос покупки: выдержит ли ваша основная нагрузка «налог на память» 14B и более медленный decode? 14B — не «хуже модель», а модель с ограничением по памяти: стабильность зависит от tier unified memory, а не только от числа параметров.

1.1 Трёхсостоянная модель 14B (ограничение памятью, без финальных тегов)

14B — не «на ступень ниже», а зависит от tier RAM: те же веса могут быть зоной коллапса, sweet spot или зоной стабильного качества.

Конкретные теги 7b / 14b — в блок-схеме и таблицах §8.4.

2. Методика тестов и честность сравнения

Железо: базовый Mac Mini M4, GPU 10 ядер, unified memory bandwidth ~120 GB/s; две конфигурации 16 GB и 24 GB. ПО: macOS 15.4, Ollama 0.6.2, по умолчанию Q4_K_M (GGUF).

2.1 Фиксированные переменные

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-бенчмарка (та же линия, что benchmark-m4-mac-mini-ollama.sh в статье полной лаборатории), измеряет eval_count / wall_time через HTTP API Ollama.

2.3 Чего мы не тестируем

Мы не гоняем публичные «IQ-лидерборды» — разброс по промптам огромен. Качество — фиксированный набор задач + слепая человеческая оценка (§5); по скорости — воспроизводимые цифры и сырые последовательности прогонов (включая отброшенные выбросы).

2.4 Среда лаборатории и заметки по воспроизведению

Для воспроизведения на своей машине или вставки во внутренние доки используйте блок среды ниже; далее — сводная таблица. Полная таксономия сбоев и коллапс: лаборатория локального LLM на M4 Mac Mini (хаб).

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 Сводка достоверности

2.6 Следы лаборатории: терминал и ID машин

Перед воспроизведением проверьте Metal и базовую память. Выдержка терминала ниже (полная версия в артефактах, «terminal session excerpt»):

$ 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. Скорость: tok/s, TTFT и время на 500 токенов

Цифры из Lab парного лога бенчмарка 7B/14B (полный файл в §8.3 артефактах). Сохраняем и медиану, и все пять сырых прогонов — реальные бенчмарки редко дают аккуратную арифметическую прогрессию.

3.1 Чистая система: 16 GB · qwen2.5:7b (пять прогонов)

TTFT по wall clock: 1,78 / 1,91 / 2,03 / 2,14 с (медиана 1,97 с). Swapins = 0.

3.2 Чистая система: 16 GB · qwen2.5:14b (сессия не дошла до пяти прогонов)

На 16 GB у 14B нет стабильной медианы: в run 3 memorystatus: WARN, в run 4 процесс убит — как коллапс памяти в полной лаборатории. Значит, в ежедневной работе на 16 GB 14B не держат резидентом.

3.3 Чистая система: пара на 24 GB (m4-24gb-lab-02)

На 24 GB пять прогонов 14B всё ещё разбросаны (14,2–17,3), но swap не было ни разу. Повторный прогон другим днём: медиана 7B@16GB 28,6 (включая тёплый выброс 24,3 — см. footer лога) — ±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 ломается первым

16 GB + Chrome 12 вкладок: отброшен только run4 у 7B — 22,3 tok/s; у 14B после run2 offloading to CPU. В циклах агента TTFT бьёт сильнее tok/s — см. §7.1.

Кратко: выбор по памяти

В §3 выше — оценки 16 GB / 24 GB и доказательства swap. Одна таблица на память:

4. Сводка «стоимости» 7B vs 14B (шпаргалка)

«Стоимость» здесь — счёт ресурсов на устройстве (RAM, задержка, стабильность), не цены облачного API. Сводка для чистого 24 GB и границ 16 GB — для сниппетов и командных решений.

16 GB: для плавной ежедневной работы оставайтесь на 7B; стабильный 14B — с 24 GB. Сценарий — в §8.4.

5. Качество: когда хватает 7B и когда нужен 14B

20 фиксированных задач (10 китайских + 10 английских), четыре типа: суммаризация, перевод, багфикс в одном файле, небольшая фича из 3 файлов. Каждая задача — по одной генерации на 7B и 14B; три инженера слепо оценивали «принять как есть / мелкие правки / переписать».

5.1 Сводка слепого обзора (доля «принять как есть»)

5.2 Типичные сбои 7B

• Галлюцинации API: выдумывает правдоподобные props / REST-пути.
• Пропущенные правки: чинит определение, забывает grep по вызовам — главная причина межфайловых провалов.
• Слишком кратко в коде: в суммаризациях хорош; в коде режет обработку ошибок — нужен человеческий проход.

5.3 Когда 14B оправдывает «налог на память» (при 24 GB)

• Локальный Claude Code / Cursor Agent >2 ч/день на средних репозиториях — доля «принять как есть» межфайлово ~30% (7B) vs ~65% (14B).
• Длинные системные промпты (гайды стиля, правила архитектуры) должны соблюдаться.
• Сложные рассуждения на китайском, многоветвевые продуктовые правила, compliance-чеклисты.
• Вы принимаете ~15 tok/s и больший wall time — качество в обмен на задержку, не «неправильная настройка».

5.4 Когда достаточно 7B

• Личные заметки Q&A, сводки RSS, простые shell-скрипты.
• Ускоритель черновиков с человеческим ревью — не merge в main как есть.
• 16 GB с открытыми IDE и браузером — 14B часто падает по памяти раньше, чем по «IQ».

6. Память: водораздел 16 GB vs 24 GB

След ≈ квантованные веса + KV (∝ num_ctx) + macOS и foreground-приложения. Разрыв весов 7B/14B Q4 ~4,5 GB, но KV и overhead ОС быстро заполняют 16 GB.

6.1 num_ctx бьёт по 14B сильнее

Подъём num_ctx с 2048 до 32768: 24 GB + 14B tok/s 15,1 → ~12,4 (один прогон); 16 GB + 14B может сидеть 60+ с без первого токена (сбой задержки E4). Если агент по умолчанию с большим контекстом — сначала проверьте tier RAM.

7. Агент, TTFT и выбор для Claude Code

Цикл агента = много раундов план → инструмент → чтение → генерация. Локальная боль часто в накопленном TTFT по раундам, а не в пиковом tok/s — отсюда «в бенчмарке отлично, в агенте ужасно».

7.1 Почему TTFT — «настоящая» метрика для агентов

tok/s измеряет устойчивую генерацию после старта; TTFT — от запроса до первого токена. Для агентов:

• Каждый раунд инструмента ждёт, пока модель «заговорит» — ощущается TTFT × число раундов, а не срез tok/s на 256 токенах.
• Оркестраторы часто таймаутят (десятки секунд). Под swap TTFT ~2 с → 5,8 с+ рвёт многораундовые циклы.
• Высокий tok/s помогает только после начала стрима; 6 с до первого токена ощущаются как поломка.

Как unified memory и swap раздувают TTFT: Unified memory и LLM-инференс.

7.2 Рекомендуемые связки (кратко — полная таблица §8.4)

7.3 Смешение с облачными API

Частое разделение: 7B для retrieval/черновиков, 14B или облако для ревью перед merge. Если уже есть Claude Code, локальный 14B даёт офлайн, повторяемость, без счёта токенов — настройка в лаборатории Claude Code + Ollama.

7.4 Ollama или MLX?

В серии тестируем только Ollama (HTTP, управление моделями, проводка Claude Code). MLX на тех же промптах ~на 3–8% быстрее, но агенты по-прежнему чаще едут на Ollama — см. бенчмарки MLX vs Ollama.

8. Команды воспроизведения и таблицы решений

8.1 Скачать модели и smoke test

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 без Metal ~4 tok/s). После прогонов сверьте с артефактами.

8.2 Самопроверка по сценарию (затем таблицы ниже)

• Агент ежедневно правит один и тот же средний репозиторий?
• 16 GB с всегда открытыми Xcode + Chrome?
• Устраивает ли ~33 с на запись 500 токенов 14B на 24 GB?
• Нужен num_ctx > 8192?
• Общий Mac inference для команды?

8.3 Артефакты воспроизведения (скачать для проверки)

Статические файлы в resources/ этой статьи — не внешние ссылки — откройте или сохраните в браузере, чтобы сверить каждый прогон из §3.

• Парный лог бенчмарка 7B/14B — tok/s, TTFT, Swapins по прогонам (источник таблиц §3)
• Выдержка терминальной сессии — ollama ps, vm_stat, memory_pressure
• Отладочный лог 14B @ 16 GB — сессия swap / OOM
• Скрипт воспроизведения бенчмарка — та же логика, что в полной лаборатории

8.4 Таблицы решений (полный ответ здесь)

После данных выше — выбор по RAM и сценарию. Чтобы проверить каждый прогон §3, откройте парный лог бенчмарка.

По unified memory (сначала GB, затем модель)

По сценарию

• Чат / сводки / лёгкие скрипты (16 GB): → qwen2.5:7b
• Межфайловый код / локальный агент (рекомендуется 24 GB): → qwen2.5-coder:14b (качество в обмен на задержку — см. §7)
• Максимальная скорость, ревью человеком OK: → 7B или gemma3:4b

По роли

Практический вывод: 16 GB → 7B; 14B имеет смысл с 24 GB — иначе swap роняет UX на порядок.

FAQ

M4 Mac Mini: 7B или 14B?

Сначала риск swap, затем tier модели. Полный выбор (16 GB→7B, 24 GB→14B) — в §8.4. Ключевой вывод объясняет почему.

Тянет ли 16 GB 14B?

Загружается; для ежедневной резидентности — нет. См. §1.1 три состояния, §3.2 и §8.4.

Насколько 7B быстрее 14B?

Медиана 7B @ 16 GB — 29,1; медиана 14B @ 24 GB — 15,1. Насильный 14B на 16 GB после swap ~3,4 tok/s. Подробности — §3.

7B или 14B для обычного чата?

Большинство чатов — 7B. Межфайловый код — §5 и §8.4.

Локальная модель для Claude Code?

16 GB → qwen2.5-coder:7b; 24 GB → qwen2.5-coder:14b. Для агентов в приоритете TTFT — §7.1.

Стоит ли апгрейд 16 GB → 24 GB ради 14B?

Да, если опираетесь на локального агента и 7B часто «понимает, но правит неверно»; для чистого чата часто нет. См. §8.4.

Qwen2.5-Coder vs общие 7B/14B?

В слепом обзоре кода примерно на 8–12 п.п. выше; в чате общие 7B/14B звучат естественнее.

Итог

16 GB → 7B; стабильный 14B — с 24 GB. Работает ли 14B — в основном вопрос RAM и swap, а не «на ступень умнее». Воспроизведение — через §8.3 логи и скрипты и §2.4 блок среды.

Читать дальше

Ещё из этой серии:

• Локальный LLM на M4 Mac Mini (хаб: методика и сырые логи)
• Claude Code + Ollama: локальный агент
• Бенчмарки MLX vs Ollama
• Unified memory и LLM-инференс

Тесты на физических Mac Mini M4 (Macstripe Lab и настольные машины), macOS 15.4.1, Ollama 0.6.2. Загрузки — в §8.3. Нет своего железа? Воспроизведите на узлах Macstripe M4.