Рейтинг инструментов инференса LLM 2026: самые экономные по памяти

1. Почему память стала первым узким горлышком локального инференса

Когда вы гоняете большую модель локально, первым «ломается» не счёт за электричество, а пик RAM или VRAM. На дискретных NVIDIA VRAM — жёсткий потолок. На Apple Silicon CPU, GPU и Neural Engine делят один пул unified memory: кажется, что «стены VRAM нет», но macOS, Xcode и браузер всё равно съедают 3–5 ГБ — пул для модели оказывается теснее, чем обещает наклейка на корпусе.

Типичный конфликт 2026 года: разработчик хочет IDE + локальную 13B для автодополнения кода, запускает Archive — memory_pressure уходит в Warn, процесс инференса убивает система. Это не «глупая» модель; просто раскладка памяти runtime (где лежит KV cache, есть ли double-buffer, уровень квантизации) не была заложена в бюджет вместе со сборкой.

Параллельно созрела экосистема квантизации: llama.cpp GGUF от Q2 до Q8, MLX нативно работает с unified memory на M-чипах. Рейтинги, которые сравнивают только tok/s, вводят в заблуждение; рейтинг по экономии памяти должен учитывать пик RAM, поддержку квантизации и гибкость layer offload вместе.

Если вы ещё взвешиваете локальный путь против облачного API, начните с бенчмарка стоимости локального OpenAI API на Mac mini — гибрид часто выигрывает у чистого API или чисто локального варианта по совокупным затратам.

В 2026 году инференс уже не «скрипт для хобби»: он встроен в плагины IDE, RAG-пайплайны и tool calls агентов. Каждый слой добавляет контекст, embedding-модели и иногда вторую копию весов в RAM. Сравнивать инструменты только по VRAM из одной сессии ollama run — значит не видеть реальный стек workflow. Поэтому в таблицах ниже фиксированный класс модели (Qwen3 8B Q4) и явно указан overhead обёрток.

Для мобильных и кроссплатформенных команд картина другая: Flutter hot reload плюс локальная coder-модель на 16 ГБ — плотнее, чем 13B general рядом с эмулятором Android. Планирование памяти начинается с пикового RSS в худшей реалистичной комбинации, а не с пустого стола и одного терминала.

В российских и СНГ-командах 2026 года часто встречается схема: ноутбук на 16 ГБ, а от заказчика требование «всё локально и без утечки в облако». Без явного выбора runtime легко поставить 13B в дефолтной квантизации Ollama — и удивляться, почему индексатор Xcode и инференс вытесняют друг друга из памяти. Таблицы ниже намеренно завязаны на пик RAM под реальной нагрузкой, а не на цифры из демо на пустом столе.

2. Как классифицировать инструменты инференса? (What)

Не тоните в десяти названиях — сначала три уровня, потом сопоставление:

2.1 Уровень runtime (здесь реально тратится память)

MLX, llama.cpp, MLC LLM, ExLlamaV3 (NVIDIA) — напрямую грузят веса и управляют KV cache. Экономия памяти в основном здесь.

2.2 Уровень обёртки (developer experience)

Ollama, LM Studio, Jan, KoboldCpp — поверх runtime: pull моделей, OpenAI-совместимый API, GUI. Обычно +5–15 % к памяти в обмен на установку в один клик и каталог моделей.

2.3 Уровень сервинга (throughput для многих пользователей)

vLLM, LocalAI, llama-server — concurrency и шлюзы. Не первый выбор для экономии памяти одного запроса, но удобны, чтобы выставить edge-узел как API.

Маркетинг вендора сопоставляйте с уровнем: «70B на ноутбуке» чаще всего означает агрессивный Q4 и layer offload в llama.cpp — не то, что GUI магически сжимает веса. «Локальный ChatGPT в один клик» почти всегда обёртка с унаследованным runtime. Уровень подсказывает, куда крутить, когда Activity Monitor растёт после пятого промпта.

На Apple Silicon выбор runtime влияет и на Neural Engine: MLX и Metal-llama.cpp по-разному планируют matmul и держат ли промежуточные активации в unified memory. В спецификации этого нет, в пиковом RSS при удвоении контекста — есть.

3. Рейтинг 2026: самые экономные по памяти (How Compare)

Критерии: пик памяти при той же модели и квантизации (бенчмарки сообщества и вендоров, Q1–Q2 2026), гибкость layer offload и квантизации, развёртывание на Mac. Колонки единые: инструмент | вход | исполнение | контекст | аудитория.

3.1 Пик памяти на одной модели (класс Qwen3 8B Q4)

Ориентиры на M4 / 24 ГБ unified memory, один запрос, context ~4k (фактически ±10 % от нагрузки системы):

С марта 2026 Ollama на Mac 32 ГБ+ предлагает MLX-бэкенд с пиками близко к нативному MLX — при 24 ГБ и ниже по-прежнему llama.cpp или MLX напрямую. Больше про локальные узлы Apple Silicon: Mac mini как локальный AI execution node.

Два инструмента вне топ-10: vLLM и TensorRT-LLM доминируют в дата-центрах, где память меняют на batch-throughput — чтобы вы не копировали серверные конфиги на MacBook. Jan и KoboldCpp ниже в сырой эффективности, но выигрывают, когда операторы не должны трогать терминал; закладывайте этот ops-overhead в бюджет.

Свои бенчмарки: тот же GGUF, та же длина контекста, тот же batch, та же minor-версия macOS — меняете только runtime. Пик RSS из Activity Monitor или ps -o rss= -p $(pgrep -f llama); средние обманывают, когда KV cache растёт mid-session.

Если колеблетесь между LM Studio и чистой CLI: GUI помогает на первом проходе подобрать -ngl и размер окна контекста, но постоянно держит в памяти интерфейс. Для круглосуточного headless на Cloud Mac имеет смысл перейти на llama-server или ollama serve, как только параметры зафиксированы. Разница в мегабайтах невелика, зато пики стабильнее неделями — и меньше сюрпризов после незапланированного перезапуска GUI.

4. Матрица сценариев — как выбрать?

При оркестрации агентов и долгих задачах узел исполнения часто отделён от инференса — см. ландшафт режимов разработки агентов 2026 и мощный ПК, локаль и облако в эпоху ИИ.

Короткий shortcut: боль OOM при compile → разделение (облачный инференс или меньшая квант), не «более быстрая» модель. Боль латентности на токен при стабильной 7B → тюнинг runtime и Metal-слоёв, не скачок на 13B. Боль формата API для команды → примите overhead обёртки, стандартизируйте Ollama/LocalAI за HTTPS, потом оптимизируйте память по tier'ам.

Для Flutter-iOS-команд с Cloud Mac CI типична схема: сборка и подпись удалённо, локально остаётся 7B coder — но только если пик укладывается в красную линию. Если параллельно держите embedding для RAG, вторую весовую матрицу нужно явно внести в бюджет; многие «загадочные» OOM — это забытый bge-small рядом с основным LLM.

5. Рекомендуемые стеки

Стек A — минимум памяти на 16 ГБ Mac

• mlx-lm или llama-cli -m model.Q4_K_M.gguf -ngl 99
• Модели 7B–8B instruction-tuned; embedding на меньшей (например bge-small)
• Сложный reasoning — в облачный API; локально только приватные фрагменты

Стек B — 24 ГБ dev-машина + Cloud Mac для инференса

• Локально: Cursor / Xcode; на Cloud Mac: Ollama с 13B, OpenAI API на http://cloud-mac:11434/v1
• Ноутбук можно закрыть; CI на отдельной машине — unified memory не делите

Стек C — скриптуемый data pipeline

• llama-cpp-python + cron; квантизация Q4_K_M; лог пикового RSS
• При риске OOM — авто-fallback на Q3_K_M, а не краш

Стек D — кроссплатформенная команда

• Mac — MLX; Linux CI — llama.cpp CPU smoke
• LocalAI как единый API; бэкенды по платформе

6. Типичные ошибки

• «Чем больше параметров, тем лучше» → При фиксированной RAM стабильная 8B Q4 лучше 13B с OOM.
• «Ollama самый экономный» → Самый удобный, не самый экономный; для жёстких пиков — llama.cpp или MLX.
• «Unified memory — VRAM не планируем» → macOS убивает фон; Xcode и инференс не делят пик по умолчанию.
• «Чем ниже квант, тем лучше» → Q2 часто режет качество; Q4_K_M — sweet spot 2026.
• «vLLM на ноутбук» → Целевой стек — GPU-сервер; для локальной экономии — другой выбор.
• «Сравниваем только tok/s, пики игнорируем» → KV cache на длинном контексте растёт быстро; пик RSS решает, будет ли краш.

7. Семь шагов: начать экономить память сегодня

1. Baseline: замерьте систему в простое через memory_pressure и Activity Monitor; посчитайте доступный пул.
2. Квант: Q4_K_M GGUF с Hugging Face / ModelScope или веса, сконвертированные под MLX.
3. Runtime: Apple Silicon → сначала MLX; нужен API → Ollama; нужен контроль → llama.cpp.
4. Стресс пика: фиксированная длина prompt, 100 токенов вывода; логируйте пик RSS, не среднее.
5. Красная линия: пик >85 % пула → уменьшите модель или ужесточите квант.
6. Разделите IDE: при full compile / Archive останавливайте локальный инференс или переносите на Cloud Mac.
7. Операционализируйте: Ollama под launchd с memorymax или периодический ollama ps.

Зафиксируйте результат в вики команды: файл модели, тег квантизации, версия runtime, пик RSS, был ли открыт Xcode. Через полгода у вас свои данные вместо ссылок на форумы. Baseline повторяйте после крупных обновлений macOS — Apple иногда меняет поведение memory pressure в point-release.

Последний шаг: назначьте ответственного за патчи Cloud Mac (Homebrew, версия Ollama, ротация моделей). Устаревшая пара runtime + свежий GGUF даёт регрессии памяти, похожие на «плохую модель». Пятиминутная ежемесячная проверка с тем же эталонным prompt экономит часы отладки.

# После загрузки GGUF — часть слоёв на GPU, остальное CPU (ниже пик unified memory)
./llama-cli -m ./Qwen3-8B-Q4_K_M.gguf \
  -ngl 20 \
  -c 4096 \
  --temp 0.7 \
  -p "Объясни в трёх предложениях, как GGUF-квантизация снижает пик памяти при инференсе"

# Ollama для быстрой проверки той же квант-класса
ollama pull qwen3:8b
ollama run qwen3:8b "Тот же вопрос"

8. Итог

Рейтинг самых экономных по памяти инструментов инференса LLM в 2026 ведут MLX (Apple Silicon) и тонко настраиваемый llama.cpp; Ollama и LM Studio меняют немного RAM на сильно проще ops; vLLM / LocalAI — когда важнее multi-tenant serving, чем пик одного запроса.

Несимметричная линия: водораздел — в runtime и стратегии квантизации, а не в числе параметров. Сначала бюджет пика памяти, потом спор 7B vs 13B.

Дополнительно: репозиторий MLX · документация llama.cpp · Ollama