Новинка 2026: кластер Mac mini M4 — углублённый бенчмарк AI-инференса

Кратко: Когда tok/s одного M4 уже хватает, но параллельные запросы и ночной batch начинают стоять в очереди, возникает вопрос: удвоится ли пропускная способность, если докупить Mac mini в кластер? Редко где собраны в одной таблице кривые 2/4/8 узлов, различия фреймворков и реальный ROI. Ниже — среда тестирования, baseline одного узла, масштабирование кластера, разбор узких мест, чеклист развёртывания: воспроизводимый deep-dive 2026.

Итоги одним взглядом

В дата-центре ZavCloud 4 Mac mini M4 (24GB) и 4 экземпляра Cloud Mac M4 образуют масштабируемый стенд; две недели нагрузки при одинаковой сети и политике питания. Ключевые выводы:

• Параллелизм на уровне запросов близок к линейному: модель 7B, независимый Ollama на узле + Nginx round-robin — эффективность 2/4/8 узлов: 95% / 92% / 86%
• Нельзя «склеить память» для одной большой модели: модели 32B+ ограничены Unified Memory узла; кластер не заменяет апгрейд 24GB→64GB
• MLX быстрее на узле, Ollama удобнее в кластере: MLX на ~ 8%–15% быстрее Ollama на узле, но OpenAI API и hot-update делают Ollama практичнее для multi-node
• Узкое место смещается от compute к scheduling: на 8 узлах load balancing и cold start — 25%–40% end-to-end latency, не GPU/NPU
• Точка ROI — параллельный batch: embeddings RAG, сводки логов — 4 узла снижают стоимость на тысячу инференций на ~38% (амортизация простоя и очередей)

Зачем тестировать «кластер», а не только один узел?

Один M4 с 7B уже быстр — наш тест одного узла дал ~ 37 tok/s на 24GB без swap (qwen3:8b, фон рабочего стола). Когда Ollama становится приватным слоем инференса (см. Cloud Mac AI Stack L2), узкими местами часто становятся:

• Несколько agents / PR одновременно вызывают локальный API — очередь
• Ночной batch (embeddings, сводки логов) конкурирует с дневным интерактивом
• Нужен SLA: P95 latency < 2s — один узел не тянет

«Докупить Mac mini» — естественная мысль. Без tensor parallelism как у NVIDIA предел масштабирования нужно измерять в одинаковой среде, с той же моделью и нагрузкой — не экстраполировать цифры одного узла.

Среда тестирования и топология кластера

Baseline одного узла: инференс M4 Mac mini

Знаменатель эффективности масштабирования — steady-state одного узла. Baseline на этом стенде (Ollama · квантизация Q4_K_M):

Эти цифры — теоретический потолок для масштабирования: при идеально линейных 4 узлах для 7B ≈ 4 × 58 ≈ 232 tok/s.

Измеренное масштабирование (2 / 4 / 8 узлов)

Сценарий A: интерактивный API 7B (32 параллельных соединения)

На узле предзагружено: llama3.2:7b-instruct-q4_K_M. Клиент шлёт независимые prompt через LB — измеряем суммарные tok/s и P95 latency на запрос.

Эффективность = фактический множитель / число узлов. На 8 узлах падает до 86% — в основном overhead LB, исключения health check и очереди на входе при очень высокой concurrency.

Сценарий B: multi-tenant API 14B (16 параллельных соединений)

Сценарий C: batch embeddings RAG (offline throughput)

На узле nomic-embed-text; клиент отправляет 10 000 chunks — измеряем записей/мин:

Batch embeddings — один из сценариев с наивысшим ROI для кластера: идеально делится, без интерактивного TTFT, можно грузить ночью.

Сравнение фреймворков: Ollama vs MLX

Рекомендация для prod: Ollama — онлайн API-слой, MLX — ночной batch-инференс; оба могут сосуществовать на разных ролях узлов.

Параллелизм и batch: три реальные нагрузки

① Multi-agent coding assistant (пик 8–12 QPS)

Как архитектура 24/7 AI Coding Agent: Claude API даёт diff, локальный Ollama — сводки логов и embeddings retrieval. Один узел 16GB сильно swap'ит на пиках; кластер 2×24GB снижает P95 с 4,2s до 2,1s.

② Приватный RAG (500 000 token embeddings/день)

4 узла сжимают ночную перестройку индекса с 9 ч до 2,6 ч; днём 2 узла оставляют интерактивные 7B-запросы, остальные ночью в batch (cron stop → embed → утром снова online).

③ Внутренний API gateway (несколько команд)

Отдельный API key и rate limit на команду; LB по least_conn. 8 узлов держат ~ 35–40 параллельных диалогов (7B) — дальше очередь или HTTP 429.

Где узкие места кластера?

1. Cold start модели: после перезапуска TTFT 8–15s (веса в Unified Memory). Смягчение: warmup-скрипт + health check перед pool LB
2. Unified Memory не шарится между узлами: нет tensor parallelism как на GPU; полная копия модели на каждом узле
3. Входная полоса: на 8 узлах ~400 tok/s Internet 1Gbps может стать узким местом (~1,6 MB/s текста — обычно хватает; следите за возвратом embedding-векторов)
4. Skew scheduling: round_robin при неравной длине запросов — неравная нагрузка; лучше least_conn
5. Сложность ops: обновления macOS, версия Ollama, sync моделей на N машин — Infrastructure as Code (Ansible / свои скрипты)

Стоимость и ROI

Пример 4 узла × Mac mini M4 24GB — TCO за три года vs один узел (электричество, ops):

Точка ROI: если параллельный batch давит idle одного узла < 40% или интерактивный P95 стабильно > 3s — второй узел часто окупается за 6–9 месяцев (vs почасовая аренда Cloud Mac). С 4+ узлов нужны явные multi-tenant или SLA.

Развёртывание и эксплуатация

Минимальный кластер 2 узла — чеклист:

# 1. Установить Ollama и pull модели
brew install ollama
ollama pull llama3.2:7b-instruct-q4_K_M
OLLAMA_HOST=0.0.0.0:11434 ollama serve &

# 2. Warmup (обязательно перед pool LB)
curl http://localhost:11434/api/generate -d '{"model":"llama3.2:7b-instruct-q4_K_M","prompt":"warmup","stream":false}'

# 3. Endpoint health check
curl -s http://localhost:11434/api/tags | jq '.models | length'

# /etc/nginx/conf.d/ollama-cluster.conf
upstream ollama_backend {
    least_conn;
    server 10.0.1.11:11434 max_fails=2 fail_timeout=10s;
    server 10.0.1.12:11434 max_fails=2 fail_timeout=10s;
}
server {
    listen 443 ssl;
    location / { proxy_pass http://ollama_backend; proxy_read_timeout 300s; }
}

• Мониторинг: на узле экспорт ollama ps, Memory Pressure, Swap, tok/s (свой exporter)
• Rolling update: на узле drain → pull → warmup → join — без cold start всего кластера
• Безопасность: mTLS или API key на входе; Ollama по умолчанию без auth — не выставлять в Internet без защиты
• Развести с CI: пики build Runner — временно убрать узлы инференса из pool LB (см. планирование памяти)

Матрица выбора

Скрипты воспроизведения

Baseline одного узла на любом M4, затем расширение backend LB:

# Concurrency 32 · 256 token на запрос · 5 мин
wrk -t4 -c32 -d300s -s ollama_bench.lua http://lb.internal:443/

# Выборка суммарных tok/s (вывод wrk + метрики Ollama)
python3 scripts/cluster_aggregate_tps.py --nodes 4 --duration 300

Полное определение benchmark: один узел M4 Ollama · приложение воспроизведения. Эффективность масштабирования измеряйте в steady-state ≥ 5 мин, исключая cold start.