# Локальные LLM в 2026: какие модели и на каком железе

> Как выбрать локальную LLM по объёму памяти: формула «веса + KV-кэш», таблица моделей Qwen, Gemma и gpt-oss, лицензии и замеры на Mac M4 Max 36 ГБ.
> Author: Roman Belov · Published: 2026-10-10 · Source: https://futurecraft.pro/ru/blog/local-llm-guide/

Локальная LLM - языковая модель с открытыми весами, которая работает на вашем компьютере без облачного API. Веса скачиваются и считаются в вашей памяти, поэтому выбор модели определяют три вещи: объём памяти (веса плюс KV-кэш контекста), лицензия и то, что важнее для задачи, скорость или качество.

Выбор обычно начинают с рейтинга «лучших моделей», а заканчивают тем, что модель не помещается в память или помещается, но с контекстом на 4 тысячи токенов. На карточке Qwen3.8-27B написано 262 144 токена контекста, на странице тега в Ollama файл весит 18 ГБ, а сколько памяти модель займёт на конкретной машине, не указано ни там, ни там. На Mac к этому добавляется лимит видеопамяти, для которого нет официальной формулы, а у одного и того же тега Ollama на Mac и на Linux оказываются разные файлы.

Статья о том, как выбирать локальную модель расчётом вместо рейтинга: формула памяти «веса + KV-кэш» со сверкой по замерам в Ollama, таблица «сколько памяти - какие модели» с контекстом и лицензиями, обзор семейств Qwen, Gemma 4, gpt-oss, DeepSeek, Mistral и Muse, раннеры и замеры на Mac с Apple M4 Max и 36 ГБ памяти. Установка Ollama, API и Modelfile разобраны отдельно в [гайде по Ollama](https://futurecraft.pro/ru/blog/ollama-guide/).

## Что такое локальная LLM и когда она оправдана

Локальную модель запускает раннер: Ollama, llama.cpp, LM Studio, vLLM или MLX. Он загружает веса в видеопамять (на Mac в unified memory), держит KV-кэш контекста и отдаёт API, чаще всего OpenAI-совместимый. Приложения и агенты подключаются к нему так же, как к облачному провайдеру, только `base_url` указывает на localhost.

| | Локальная модель | Облачный API |
|---|---|---|
| Данные | Остаются на машине | Уходят провайдеру |
| Стоимость | Железо и электричество | Оплата за токены |
| Качество | Ниже фронтирных моделей, растёт с размером | Фронтирные модели: Opus 5.5, Sonnet 5.5, Fable 5.1 |
| Контекст | Ограничен памятью, а не карточкой модели | Сотни тысяч токенов и больше |
| Работа без сети | Да, после загрузки весов | Нет |

Где локальная модель оправдана:

- данные нельзя отправлять наружу: персональные данные, внутренние логи, код под NDA. В [FAQ Ollama](https://docs.ollama.com/faq) сказано, что при локальном запуске Ollama не видит промпты и данные;
- задача массовая и простая: классификация, извлечение полей, черновые саммари, эмбеддинги для поиска;
- нужна работа офлайн или эксперименты без счёта за токены;
- нужен предсказуемый резерв на случай, когда облачный провайдер недоступен.

Где не оправдана: многошаговые агентные задачи и сложный рефакторинг. В тесте с OpenCode локальные 7-8B модели выполняли короткие правки, но многошаговую задачу стабильно не решила ни одна, подробности в [гайде по OpenCode](https://futurecraft.pro/ru/blog/opencode-guide/). В production локальная модель обычно становится одним из провайдеров рядом с облачными. Как распределять между ними задачи и строить fallback, разобрано в статьях [про провайдеров LLM в production](https://futurecraft.pro/ru/blog/multi-provider-llm-architecture/) и [Production LLM Stack](https://futurecraft.pro/ru/blog/production-llm-stack/).

## Сколько памяти нужно локальной LLM: формула

Память под модель складывается из весов, KV-кэша контекста и рабочих буферов раннера. Первые две части считаются по формуле, третью видно только в замере.

### Веса и квантизация

Веса = число параметров × бит на вес / 8. Квантизация уменьшает число бит на вес. Названия вроде «Q4» и «Q8» округлены: в квантизациях llama.cpp часть тензоров хранится с большей точностью, и реальная цифра выше. Таблица из [документации `llama-quantize`](https://github.com/ggml-org/llama.cpp/blob/master/tools/quantize/README.md) на примере Llama 3.1 8B:

| Квантизация | Бит на вес | Размер для 8B |
|---|---|---|
| Q4_K_M | 4,89 | 4,58 ГиБ |
| Q5_K_M | 5,70 | 5,33 ГиБ |
| Q6_K | 6,56 | 6,14 ГиБ |
| Q8_0 | 8,50 | 7,95 ГиБ |
| F16 | 16,0 | 14,96 ГиБ |

Отсюда быстрое правило для Q4_K_M: около 0,6 ГБ на миллиард параметров. Для 27B это ~17 ГБ, и файл `qwen3.8:27b-q4_K_M` на ollama.com весит 18 ГБ: в нём ещё vision-энкодер. Q8_0 почти вдвое больше, у той же модели 30 ГБ, BF16 - 56 ГБ.

Кроме GGUF-квантизаций llama.cpp, на Apple Silicon встречаются форматы MLX. В библиотеке Ollama это теги с суффиксами `nvfp4`, `mxfp8` и `mlx`. NVFP4 - 4-битный формат NVIDIA, по размеру файл близок к Q4_K_M: `qwen3.8:27b-nvfp4` тоже 18 ГБ. По данным [блога Ollama](https://ollama.com/blog/mlx-performance), на Gemma 4 12B потеря качества относительно BF16 (по перплексии) у NVFP4 примерно вдвое меньше, чем у q4_K_M. Это измерение вендора на одной модели.

### KV-кэш контекста

На каждый токен контекста модель хранит ключи и значения (K и V) во всех слоях с полным вниманием:

```text
KV на токен = 2 × слои_с_полным_вниманием × KV-головы × head_dim × байт_на_элемент
KV всего    = KV на токен × токены контекста
```

Параметры берут из `config.json` модели на Hugging Face. По умолчанию Ollama хранит кэш в f16, это 2 байта на элемент. Сверка с замерами из [гайда по Ollama](https://futurecraft.pro/ru/blog/ollama-guide/) (Ollama 0.40.14, контекст 32768, M4 Max):

| Модель | Слои / KV-головы / head_dim | KV на токен | KV при 32k | Память минус файл (`ollama ps`) |
|---|---|---|---|---|
| qwen2.5-coder:7b | 28 / 4 / 128 | 56 KiB | 1,75 ГиБ | 6,6 − 4,7 = 1,9 ГБ |
| qwen3:8b | 36 / 8 / 128 | 144 KiB | 4,5 ГиБ | 9,9 − 5,2 = 4,7 ГБ |

Для обычного трансформера с grouped-query attention расчёт сходится с замером в пределах 0,2 ГБ. У qwen3:8b KV-кэш при 32k почти равен весам. У qwen2.5-coder:7b, где KV-голов вдвое меньше, а слоёв 28 вместо 36, он в 2,5 раза меньше, хотя модели почти одного размера.

Сверять расчёт по `ollama ps` получается не для всех моделей. В замере ниже у моделей на раннере llamacpp колонка SIZE оказалась несопоставима с файлом: 1,6 ГБ у `gemma4:26b-a4b` при файле 18 ГБ. Перед сверкой посмотрите RUNNER в `ollama ps`, а для llama.cpp-моделей считайте занятость как файл плюс footprint процесса раннера.

### 256K на карточке не равно 256K в вашей памяти

Новые архитектуры держат полное внимание только в части слоёв, поэтому их контекст дешевле. Расчёт в таблице сделан по `config.json` моделей на Hugging Face и замером не подтверждён:

| Модель | Устройство внимания | KV на токен (оценка) | При 32k | При максимуме |
|---|---|---|---|---|
| Qwen3.8-27B | 64 слоя: 16 с полным вниманием (4 KV-головы, head_dim 256), 48 Gated DeltaNet с постоянным состоянием | 64 KiB | ~2 ГиБ | ~16 ГиБ при 256K |
| Gemma 4 31B | 10 глобальных слоёв (4 KV-головы, head_dim 512) + 50 со скользящим окном 1024 токена | 40-80 KiB + ~0,8 ГиБ на окна | ~2-3,3 ГиБ | ~11-21 ГиБ при 256K |
| Gemma 4 26B-A4B | 5 глобальных слоёв (2 KV-головы, head_dim 512) + 25 со скользящим окном | 10-20 KiB + ~0,2 ГиБ | ~0,5-0,8 ГиБ | ~2,7-5,2 ГиБ при 256K |
| gpt-oss-20b | 12 слоёв полного внимания (8 KV-голов, head_dim 64) + 12 со скользящим окном 128 | 24 KiB | ~0,75 ГиБ | ~3 ГиБ при 128K |

Вилка у Gemma 4 появляется из-за флага `attention_k_eq_v` в конфиге: в глобальных слоях ключи и значения общие, и если раннер это использует, кэш вдвое меньше.

На Mac с 36 ГБ, где GPU видит 28,1 ГиБ, эта разница становится практической. Qwen3.8-27B в 4 битах (18 ГБ) с полным окном 256K потребовала бы ещё ~16 ГиБ под кэш и в лимит не поместится. С 32k контекста она помещается, но впритык. В замере 7 ноября `qwen3.8:27b-nvfp4` при контексте 32768 работала на 100% GPU и занимала в `ollama ps` 18 ГБ сразу после загрузки, а после прогонов с промптом на 8,9K токенов уже 25 ГБ. KV-кэш на все 32k по расчёту занимает около 2 ГиБ, так что основную часть прироста дают рабочие буферы MLX-раннера: раскладку по частям Ollama не показывает. Поэтому запас «сверху» нельзя назначить одной цифрой, его проверяют на своей машине и на своих длинных промптах.

### Квантизация KV-кэша и Flash Attention

Кэш можно хранить в меньшей точности. По [FAQ Ollama](https://docs.ollama.com/faq):

- `OLLAMA_KV_CACHE_TYPE=q8_0` занимает примерно половину памяти f16, `q4_0` примерно четверть;
- квантизация кэша работает только с включённым Flash Attention (Ollama включает его сама, если бэкенд поддерживает);
- настройка глобальная и действует на все модели сервера;
- память растёт пропорционально `OLLAMA_NUM_PARALLEL × OLLAMA_CONTEXT_LENGTH`, поэтому каждый параллельный поток получает свой кэш.

Описание в FAQ относится к движку Ollama на основе llama.cpp. Действует ли переменная на MLX-раннер, для этой статьи не проверялось.

## Железо для локальных LLM: Mac, NVIDIA, CPU

Скорость генерации у локальной модели упирается в память: на каждый новый токен раннер читает из памяти все активные веса. Отсюда оценка сверху: пропускная способность памяти, делённая на объём активных весов в байтах. Это потолок, реальная скорость обычно ниже. Выше него поднимает спекулятивное декодирование, когда за одно чтение весов модель принимает больше одного токена. У тестового M4 Max с 36 ГБ пропускная способность 410 ГБ/с, и для qwen2.5-coder:7b с файлом 4,7 ГБ потолок около 87 токенов в секунду, а в замере на Ollama 0.40.14 вышло 69,5, примерно 80% от потолка. Обработка промпта (prefill) считает все токены параллельно и зависит в первую очередь от вычислительной мощности GPU.

### Apple Silicon

У Mac память общая для CPU и GPU (unified memory), поэтому на нём помещаются модели, которым на дискретной карте понадобилось бы 24-48 ГБ видеопамяти. M4 Max выпускается с объёмом до 128 ГБ и пропускной способностью до 546 ГБ/с, у M4 Pro до 64 ГБ и 273 ГБ/с ([Apple Newsroom](https://www.apple.com/newsroom/2024/10/apple-introduces-m4-pro-and-m4-max/)). 546 ГБ/с относится к старшей версии M4 Max с 16-ядерным CPU. Конфигурация на 36 ГБ, на которой сняты замеры в статье, бывает только с 14-ядерным CPU и 32-ядерным GPU, у неё [410 ГБ/с](https://support.apple.com/en-us/121553).

GPU получает не всю память. На M4 Max с 36 ГБ сервер Ollama пишет в лог `total_vram=28.1 GiB`, около 78% от объёма. Официальной формулы этой доли у Apple и Ollama нет, на машинах с другим объёмом её нужно смотреть в логе сервера. Системный лимит `iogpu.wired_limit_mb` на тестовой машине не переопределён (значение 0). Менять его для этой статьи не пробовали, и советовать это без проверки нельзя.

От `total_vram` зависит и контекст по умолчанию в Ollama ([docs.ollama.com/context-length](https://docs.ollama.com/context-length)): меньше 24 GiB - 4k токенов, 24-48 GiB - 32k, от 48 GiB - 256k. Mac с 36 ГБ попадает в средний диапазон и получает 32768.

Второй путь на Mac - MLX, фреймворк Apple для машинного обучения. Ollama показала движок на MLX для Apple Silicon в [версии 0.19](https://ollama.com/blog/mlx) (30 марта 2026, превью) и требовала для него Mac с unified memory больше 32 ГБ. Вендорский замер на Qwen3.5-35B-A3B: генерация 58 → 112 tok/s, обработка промпта 1154 → 1810 tok/s при переходе с Ollama 0.18 (Q4_K_M) на 0.19 (NVFP4). Чип в посте не указан, переносить эти цифры на свою машину нельзя. LM Studio на Apple Silicon запускает модели через llama.cpp или MLX ([документация LM Studio](https://lmstudio.ai/docs/app)).

Практическое следствие проверено на тестовой машине: на момент замера 7 ноября (Ollama 0.40.14) тег `qwen3.8:27b` на Mac скачивает MLX-сборку. `ollama show` показывает квантизацию nvfp4, формат safetensors и минимальную версию Ollama 0.32.12, а `ollama ps` - раннер `mlx`. GGUF в Q4_K_M на той же машине приходится запрашивать явным тегом `qwen3.8:27b-q4_K_M`. Манифест того же тега `qwen3.8:27b`, запрошенный не с Mac, указывает на GGUF. Один и тот же тег на разных платформах даёт разные файлы, и сравнивать скорость между машинами нужно по явным тегам с квантизацией.

### NVIDIA и AMD

На NVIDIA ограничение жёстче: модель и кэш должны поместиться в видеопамять карты. По [документации Ollama](https://docs.ollama.com/gpu) нужны compute capability 5.0+ и драйвер 550 и новее (для карт с compute capability 5.0-6.2 - 570+). RTX 5090 несёт 32 ГБ GDDR7 на 512-битной шине ([NVIDIA](https://www.nvidia.com/en-us/geforce/graphics-cards/50-series/rtx-5090/)). Для других карт ориентируйтесь на классы видеопамяти 8, 12, 16, 24 и 32 ГБ и проверяйте объём в спецификации своей модели карты.

AMD поддерживается через ROCm v7 на Linux и Windows. На Windows и Linux есть Vulkan-бэкенд, он включён по умолчанию, если установлен.

Если модель не помещается в видеопамять целиком, llama.cpp и Ollama делят слои между GPU и оперативной памятью. В `ollama ps` колонка PROCESSOR тогда показывает разделение вида `48%/52% CPU/GPU` вместо `100% GPU`. Скорость при этом падает, потому что часть весов читается из более медленной памяти. Для MoE разделение обычно обходится дешевле, потому что на токен читается малая часть весов. Насколько падает скорость в обоих случаях, для этой статьи не измерялось.

### CPU-only

llama.cpp - «plain C/C++ implementation without any dependencies» по [README](https://github.com/ggml-org/llama.cpp), он считает модель на CPU, если GPU нет, и умеет гибридный CPU+GPU режим для моделей больше видеопамяти. На CPU генерацию ограничивает пропускная способность оперативной памяти, а у обычного ПК она ниже, чем у видеопамяти или unified memory Mac. Для чата на моделях 1-4B этого хватает, для агентов и длинного контекста нет. Собственных замеров на CPU в статье нет, а цифры из обзоров в сети приводятся без методики.

## Сколько памяти - какие модели

Таблица собрана по страницам тегов [ollama.com/library](https://ollama.com/library) на 7 ноября 2026. Размеры - размеры файлов в 4 битах (Q4_K_M, QAT или MXFP4), к ним прибавляется KV-кэш и буферы раннера. Столбец «Память» - сколько видит GPU: на Mac это примерно три четверти unified memory (наблюдение на одной машине), на NVIDIA - объём видеопамяти.

| Память GPU | Модели (тег, размер файла) | Тип | Контекст | Лицензия |
|---|---|---|---|---|
| 8 ГБ | `gemma4:e2b-it-qat` (4,3 ГБ), `qwen3.5:4b` (3,3-4,0 ГБ) | dense | 128K / 256K | Apache 2.0 |
| 12-16 ГБ | `gemma4:e4b-it-qat` (6,1 ГБ), `qwen3.5:9b` (6,6-7,6 ГБ), `gemma4:12b-it-qat` (7,2 ГБ) | dense | 128K / 256K | Apache 2.0 |
| 16 ГБ, на пределе | `gpt-oss:20b` (14 ГБ) | MoE, 3,6B активных | 128K | Apache 2.0 |
| 24 ГБ | `qwen3.8:27b-q4_K_M` (18 ГБ), `gemma4:26b-a4b-it-q4_K_M` (18 ГБ), `muse-glimmer:30b` (18 ГБ), `gemma4:31b-it-q4_K_M` (20 ГБ) | dense; Gemma 26B - MoE, 3,8B активных | 128K-256K | Apache 2.0 |
| 28-32 ГБ (Mac 36 ГБ, RTX 5090) | то же с контекстом 32-64k, `qwen3.6:35b-a3b` (23 ГБ) | Qwen3.6 35B - MoE, 3B активных | 256K | Apache 2.0 |
| 48-64 ГБ | `qwen3.8:27b-q8_0` (30 ГБ), `gemma4:31b-it-q8_0` (34 ГБ), `qwen3.6:35b-a3b-q8_0` (39 ГБ) | dense и MoE в 8 битах | 256K | Apache 2.0 |
| 80-128 ГБ | `gpt-oss:120b` (65 ГБ), `llama4:scout` (67 ГБ), `qwen3.5:122b` (81 ГБ), BF16-версии 27-31B (56-64 ГБ) | MoE и dense BF16 | 128K-10M | Apache 2.0; Llama 4 - своя |
| Кластер GPU | DeepSeek V4.1 Flash, Mistral Large 4, Muse Spark Open | MoE, сотни миллиардов и больше | до 1M | MIT; у Mistral и Muse свои |

Как читать таблицу:

- У тегов с диапазоном размеров (`qwen3.5:9b`, `gemma4:e4b`) разные файлы под разные платформы. Диапазон не означает, что на Mac придёт MLX: `gemma4:e4b` на тестовом M4 Max скачал GGUF на 9,6 ГБ с раннером llamacpp. Какой файл достался вам, показывает `ollama show`.
- `gpt-oss:20b` в карточке OpenAI заявлена как модель, которая работает «within 16GB of memory». На Mac с 16 ГБ GPU видит меньше 16 ГБ, так что на такой машине модель окажется на пределе.
- На Mac с 36 ГБ `qwen3.8:27b-q8_0` (30 ГБ) не помещается в 28,1 ГиБ GPU-лимита даже без контекста. Это вывод из размеров, не замер.
- Плотная модель и MoE с одинаковым файлом занимают одинаковую память, но MoE на каждый токен читает в несколько раз меньше весов и поэтому генерирует быстрее: в замере 49,8 tok/s у `gemma4:26b-a4b` против 10,6 у `qwen3.8:27b-q4_K_M`.

Отдельные таблицы по Qwen и короткий ориентир «память → модели» для Ollama есть в [гайде по Ollama](https://futurecraft.pro/ru/blog/ollama-guide/).

## Семейства открытых моделей на ноябрь 2026

Даты ниже - даты публикации весов на Hugging Face или анонса вендора. Номера меняются каждые несколько месяцев, поэтому перед выбором откройте карточку модели и страницу тегов.

### Qwen

Самое широкое семейство по размерам. Все перечисленные локальные модели принимают картинки и поддерживают tool calls и режим рассуждения (метки vision, tools, thinking в Ollama).

- **Qwen3.8-27B** (август 2026, Apache 2.0) - плотная модель на 27B с гибридным вниманием: 48 слоёв Gated DeltaNet и 16 слоёв обычного внимания. Нативный контекст 262 144 токена, расширяемый до 1M. В Ollama: `qwen3.8:27b` (18 ГБ; на Mac это MLX-сборка), `q4_K_M` (18 ГБ), `q8_0` (30 ГБ), `bf16` (56 ГБ), MLX-варианты `nvfp4` (18 ГБ) и `mxfp8` (32 ГБ).
- **Qwen3.8-Flash-Next** (август 2026) - MoE на 125B параметров с 6B активных. Лицензия `qwen-community-1.0`, это не Apache 2.0. В библиотеке Ollama тега на 7 ноября не было.
- **Qwen3.6** (апрель 2026, Apache 2.0) - плотная 27B и MoE 35B-A3B (3B активных), контекст 256K. В Ollama есть теги с суффиксом `coding`; что изменено в этих сборках, на странице модели не расшифровано.
- **Qwen3.5** (февраль 2026, Apache 2.0) - линейка от 0.8B до 122B-A10B, в ней есть размеры для машин на 8-16 ГБ.

### Gemma 4

Google анонсировала Gemma 4 [2 апреля 2026](https://blog.google/innovation-and-ai/technology/developers-tools/gemma-4/) под Apache 2.0: «эффективные» E2B и E4B для телефонов и edge-устройств (контекст 128K), MoE 26B-A4B (3,8B активных) и плотная 31B (256K). В мае на Hugging Face появилась 12B. По словам Google, 26B и 31B в BF16 помещаются на один H100 на 80 ГБ, а квантизованные версии работают на потребительских GPU. В Ollama у Gemma 4 есть QAT-теги (квантизация с дообучением, файлы меньше обычных Q4) и MLX-варианты.

### gpt-oss

Открытые веса OpenAI августа 2025 года под Apache 2.0. `gpt-oss-20b` - MoE на 21B параметров с 3,6B активных, `gpt-oss-120b` - 117B с 5,1B активных ([карточка](https://huggingface.co/openai/gpt-oss-20b)). Веса экспертов хранятся в MXFP4, контекст 128K, уровень рассуждения задаётся в системном промпте (low, medium, high). По карточке 20b работает в 16 ГБ памяти, 120b - на одном GPU на 80 ГБ. В Ollama это `gpt-oss:20b` (14 ГБ) и `gpt-oss:120b` (65 ГБ), MLX-тегов у модели нет.

### DeepSeek

DeepSeek V4.1 Flash (сентябрь 2026, MIT, контекст 1M) - MoE на сотни миллиардов параметров. Веса открыты, но в Ollama модель есть только как облачная, без размеров файлов. То же у DeepSeek-V4-Pro. Локально из DeepSeek запускают R1 и его дистилляты (`deepseek-r1` от 1.5b до 70b, 94,8 млн загрузок в Ollama). Дистилляты построены на базовых моделях Qwen и Llama, их лицензию проверяйте по карточке конкретного размера.

### Mistral и Devstral

- **Mistral Small 4** (январь 2026, обновление `2603` в марте, Apache 2.0) - MoE на 119B с 6,5B активных, контекст 256K. В библиотеке Ollama на 7 ноября под этим именем не было.
- **Devstral Small 2** (ноябрь 2025, Apache 2.0) - 24B для кода, контекст 256K. В карточке вендор пишет, что модель работает на одной RTX 4090 или Mac с 32 ГБ.
- **Mistral Large 4** (30 сентября 2026) - MoE около 1T параметров с ~52B активных, контекст 1M. Примеры запуска в карточке рассчитаны на 8 GPU, в Ollama модель облачная. Лицензия - Mistral Ecosystem Open-Weight License, её текст нужно читать перед использованием.

### Llama и Muse

Последняя линейка под брендом Llama в организации meta-llama на Hugging Face - Llama 4 (апрель 2025): Scout (17B активных, 16 экспертов, 109B всего) и Maverick (128 экспертов). В Ollama `llama4:scout` весит 67 ГБ, `llama4:maverick` 245 ГБ. Лицензия Llama 4 Community License, доступ к весам на HF по запросу. По загрузкам в Ollama до сих пор лидируют `llama3.1` и `llama3.2`, но это модели 2024 года.

Свежие открытые веса Meta выходят под брендом Muse. **Muse Glimmer 30B** (август 2026, Apache 2.0) - 29,6B с vision-энкодером, контекст 131 072+. В карточке указаны цели по железу 24, 32 и 64 ГБ видеопамяти, в Ollama модель есть как `muse-glimmer:30b` (18 ГБ). **Muse Spark Open** (816B-A42B, сентябрь 2026) выложена под собственной лицензией с ручным одобрением доступа, в Ollama облачная.

### Открытые, но не локальные

У части моделей веса открыты, но на одной машине их не запустить. Это DeepSeek V4.1 Flash и V4-Pro, Mistral Large 4, Muse Spark Open и флагман Qwen3.8 на 2,4T параметров. Для читателя с одним Mac или одной видеокартой это облачные модели: через облако Ollama, API вендора или агрегатор. Для собственного запуска нужен сервер с несколькими GPU и серверный раннер: карточка Mistral Large 4, например, рекомендует vLLM и SGLang и приводит примеры на 8 GPU.

## Dense против MoE: память и скорость

Обозначение вида `35B-A3B` значит: 35 миллиардов параметров всего, 3 миллиарда активных на токен. MoE-модель (mixture of experts) держит в памяти все веса, но на каждый токен роутер выбирает несколько экспертов, и считаются только они.

Для выбора отсюда два следствия:

1. **Память определяет, что поместится.** `gemma4:26b-a4b-it-q4_K_M` и `qwen3.8:27b-q4_K_M` весят по 18 ГБ, и места в памяти им нужно одинаково.
2. **Активные параметры определяют скорость генерации.** На токен MoE читает из памяти около 3,8B параметров вместо 27B. По оценке «пропускная способность / активные байты» потолок у неё в несколько раз выше, чем у плотной модели того же размера: на тестовом M4 Max (410 ГБ/с) около 23 tok/s для 27B dense в Q4 против примерно 180 для 26B-A4B. Это теоретические потолки. В замере GGUF-сборки дали 10,6 и 49,8 tok/s: разрыв в 4,7 раза, меньше теоретического, но того же порядка.

Качество у MoE и плотной модели одного размера файла разное, и по самоотчётам вендоров с разными харнессами их честно не сравнить. Для своих задач сравнивайте модели на своих промптах. Скорость пяти моделей на одной машине собрана в разделе «Замеры на M4 Max 36 ГБ».

## Чем запускать локальные модели

| Инструмент | Что это | Лицензия | Когда брать |
|---|---|---|---|
| Ollama | CLI и сервер, REST и OpenAI-совместимый API, библиотека моделей, MLX на Apple Silicon | MIT | Локальный API для своего кода и агентов |
| LM Studio | Десктопное приложение и headless-сервер `llmster`, OpenAI-совместимые эндпоинты, llama.cpp и MLX | условия смотрите на сайте | Работа без CLI, подбор моделей в GUI |
| llama.cpp | Основа многих раннеров, GGUF, `llama-server` с OpenAI-совместимым API, 17 бэкендов | MIT | Полный контроль над квантами и сборкой |
| vLLM | Серверный раннер для GPU с батчингом запросов | Apache 2.0 | Сервер на NVIDIA для нескольких пользователей |
| Jan | Десктопное приложение | смотрите в репозитории `janhq/jan` | GUI-альтернатива LM Studio |
| MLX / mlx-lm | Фреймворк Apple и пакет для запуска LLM | MIT | Apple Silicon, когда нужен Python и свои эксперименты |

Номера версий в таблицу не вынесены: раннеры обновляются чаще, чем имеет смысл переписывать таблицу, а у llama.cpp сборки вообще нумеруются тегами `bNNNN`. Установка, API и настройки Ollama - в [гайде по Ollama](https://futurecraft.pro/ru/blog/ollama-guide/), сравнение двух самых популярных десктопных вариантов - в статье [LM Studio vs Ollama](https://futurecraft.pro/ru/blog/lm-studio-vs-ollama/).

## Замеры на M4 Max 36 ГБ

Цель замера - проверить два вывода статьи на одной машине: насколько MoE быстрее плотной модели того же размера файла и что даёт MLX-путь Ollama против GGUF на одной и той же модели.

**Проверено:** 7 ноября 2026 года, Ollama 0.40.14, Mac с Apple M4 Max (14-ядерный CPU, 32-ядерный GPU, 410 ГБ/с) и 36 ГБ unified memory, GPU видит 28,1 ГиБ, macOS 27.2, питание от сети. Тяжёлые приложения перед замером закрыты, открытыми остались Claude и системные процессы, около 17 ГБ памяти без модели. Swap к началу был занят на 7 ГБ из 8 после предыдущих прогонов и до конца не освобождался.

Методика:

- контекст 32768 (`num_ctx`) для всех моделей, temperature 0, рассуждение выключено (`think: false`), до 400 токенов ответа;
- два промпта: короткий (~55 токенов, «объясни KV-кэш примерно в 200 словах») и длинный (~8,9K токенов текста с просьбой пересказать его в 5 пунктах);
- 5 прогонов на промпт, в таблице медиана, в скобках минимум и максимум;
- перед каждым прогоном уникальный префикс, чтобы кэш промпта не завышал скорость обработки;
- скорости из полей ответа сервера: генерация по `eval_count / eval_duration`, обработка промпта по `prompt_eval_count / prompt_eval_duration`; TTFT - время до первого токена в стриме;
- между моделями все модели выгружались, для каждой считался прирост `Pageouts + Swapouts` в `vm_stat` за время замера (страница 16 КБ), чтобы видеть, ушла ли система в swap.

| Модель (тег) | Тип | Формат / RUNNER | Генерация, короткий промпт, tok/s | Генерация, длинный промпт, tok/s | Обработка промпта (~8,9K), tok/s | TTFT, длинный промпт, с | Swap за замер |
|---|---|---|---|---|---|---|---|
| `qwen3.8:27b-nvfp4` | dense 27B | safetensors nvfp4 / mlx | 32,4 (30,4-35,5) | 19,4 (14,2-19,7) | 104 | 85,7 | ≈ 11 ГБ |
| `qwen3.8:27b-q4_K_M` | dense 27B | GGUF Q4_K_M / llamacpp | 10,6 (9,6-10,7) | 10,1 (9,3-10,2) | 115 | 77,2 | ≈ 0,8 ГБ |
| `gemma4:26b-a4b-it-q4_K_M` | MoE 26B, 3,8B активных | GGUF Q4_K_M / llamacpp | 49,8 (48,7-52,0) | 49,3 (48,7-50,5) | 706 | 13,0 | ~0 |
| `gpt-oss:20b` | MoE 21B, 3,6B активных | GGUF MXFP4 / llamacpp | 45,3 (44,7-47,9) | 47,2 (46,2-47,6) | 862 | 11,7 | ~0 |
| `gemma4:e4b` | dense, 4,5B эффективных | GGUF / llamacpp | 75,3 (49,5-76,1) | 46,9 (45,5-50,0) | 679 | 13,4 | ~0 |

Длинный промпт у моделей разной длины из-за токенизаторов: 8 887 токенов у Qwen, 9 044 у Gemma 4 26B, 8 344 у gpt-oss, 9 040 у gemma4:e4b. Почему один и тот же текст даёт разное число токенов, разобрано в [статье о токенах и их подсчёте](https://futurecraft.pro/ru/blog/tokens-explained/). Широкий разброс у `gemma4:e4b` на коротком промпте дал первый прогон (49,5 tok/s), остальные шли около 75.

Тег `qwen3.8:27b` без суффикса на этой машине указывает на ту же MLX-сборку, что и `qwen3.8:27b-nvfp4`, поэтому GGUF для сравнения запрашивался явным `qwen3.8:27b-q4_K_M`.

### Память: почему `ollama ps` не годится для оценки

В Ollama 0.40.14 колонка SIZE в `ollama ps` для моделей на раннере llamacpp с файлом несопоставима: 1,6 ГБ у `gemma4:26b-a4b` при файле 18 ГБ, 1,1 ГБ у `gemma4:e4b` при 9,6 ГБ. Причина в том, как раннеры держат веса. llama.cpp отображает файл весов в память (mmap), и эти страницы не входят в footprint процесса. MLX держит веса в памяти самого процесса, и у MLX-сборки SIZE ближе к реальности, но растёт по ходу работы.

Footprint процесса раннера (`phys_footprint` из утилиты `footprint` в macOS) после короткого запроса при контексте 32768:

| Модель | Файл модели | Footprint раннера | Оценка занятости | `ollama ps` |
|---|---|---|---|---|
| `qwen3.8:27b-nvfp4` (mlx) | ~18 ГБ | 17 ГБ | 17 ГБ, веса внутри процесса | 18 ГБ, после длинных прогонов 25 ГБ |
| `qwen3.8:27b-q4_K_M` | 16,8 ГБ + 0,9 ГБ vision-проектор | 3,5 ГБ | ≈ 21,2 ГБ | 17 ГБ |
| `gemma4:26b-a4b` | 18,0 ГБ | 2,4 ГБ | ≈ 20,4 ГБ | 1,6 ГБ |
| `gpt-oss:20b` | 13,8 ГБ | 0,9 ГБ | ≈ 14,7 ГБ | 12 ГБ |
| `gemma4:e4b` | 9,6 ГБ | 1,7 ГБ | ≈ 11,3 ГБ | 1,1 ГБ |

Для llama.cpp-моделей реальная занятость примерно равна размеру файла плюс footprint раннера, в котором сидят KV-кэш и буферы. Для MLX смотрят footprint раннера или Activity Monitor. Решать по SIZE в `ollama ps`, влезет ли модель, на этой версии нельзя.

У MLX-сборки Qwen память выросла с 18 ГБ после загрузки до 25 ГБ после длинных прогонов при том же контексте. Вместе с 17 ГБ открытых приложений это больше 36 ГБ, и за замер система вытеснила в swap около 11 ГБ (676 тысяч страниц). GGUF-сборка той же модели почти не трогала swap (0,8 ГБ), хотя по оценке занимает не меньше. Объяснение, которое сходится с устройством раннеров: страницы mmap-файла система может сбросить и потом перечитать с диска без записи в swap, а память MLX-процесса приходится вытеснять.

### Что показал замер

MoE против dense подтвердилось с запасом. При одинаковом файле около 18 ГБ `gemma4:26b-a4b` генерирует 49,8 tok/s, а `qwen3.8:27b-q4_K_M` в том же формате и на том же раннере 10,6 tok/s, разница в 4,7 раза. На длинном промпте разрыв ещё больше: обработка 706 против 115 tok/s, TTFT 13,0 против 77,2 секунды. `gpt-oss:20b` ведёт себя так же. Память решает, поместится ли модель, активные параметры - как быстро она отвечает.

MLX против GGUF на одной модели дал выигрыш, но только при запасе памяти. На коротком промпте `nvfp4` быстрее `q4_K_M` втрое: 32,4 против 10,6 tok/s. На длинном выигрыш сократился до 1,9 раза (19,4 против 10,1), а разброс прогонов вырос до 14,2-19,7: MLX-сборке не хватило памяти, и система ушла в swap. Обработку длинного промпта MLX-путь на этой модели не ускорил: 104 против 115 tok/s.

32,4 tok/s выше оценки сверху для файла 18 ГБ на 410 ГБ/с (около 23 tok/s), и причина видна в логе сервера Ollama. MLX-раннер сам включает для `qwen3.8:27b` спекулятивное декодирование MTP (multi-token prediction): за прогон медиана acceptance 0,67, а `avg_accepted` 1,29 токена за итерацию сверх основного. У раннера llama.cpp MTP нет, поэтому выигрыш nvfp4 над q4_K_M складывается из формата, движка и MTP, и разделить их вклад этот замер не позволяет.

На Mac с 36 ГБ плотная 27B в 4 битах помещается в GPU-лимит, но с открытыми приложениями работает на грани, и на длинных промптах MLX-сборка теряет большую часть выигрыша. MoE того же размера файла здесь быстрее в разы и swap не трогает. На Mac с памятью больше 32 ГБ начинать с MLX-тегов имеет смысл, если модель помещается с запасом в несколько гигабайт.

Цифры относятся к одной машине на 36 ГБ с открытыми приложениями и занятым swap, к Ollama 0.40.14 и контексту 32K. На Mac с 64 ГБ и больше, на других чипах и на NVIDIA расклад может быть другим, это не проверялось. Не проверялись и параллельные запросы, скорость при контексте 64K, работа агентов с этими моделями и тепловой режим при долгой нагрузке.

## Какую модель выбрать под задачу

Рейтинга «лучшая модель» здесь нет: сравнений, которые можно проверить, у вендоров нет, а бенчмарки из карточек сняты с разными харнессами. У каждого типа задач свои требования к памяти, контексту и возможностям модели.

**Чат и работа с текстом.** Подойдёт самая большая модель, которая помещается в память с нужным контекстом. На 16 ГБ это 4-12B (Qwen3.5, Gemma 4), на 24-36 ГБ - 26-31B в 4 битах.

**Код в чате.** Нужен длинный контекст: файлы и диффы съедают десятки тысяч токенов. В Ollama есть отдельные кодовые теги (`qwen3.6:*-coding`, `qwen3-coder`), у Mistral - Devstral Small 2. Качество на своих задачах проверяйте сами.

**Агенты.** Модель для кода и модель для агента - разные требования. Агенту нужны стабильные tool calls в правильном формате и контекст от 64000 токенов, этот порог для агентов и инструментов для кода рекомендует [документация Ollama](https://docs.ollama.com/context-length). В тесте с OpenCode qwen2.5-coder:7b с меткой `tools` печатала вызовы инструментов текстом, а 8B-модели проходили задачу нестабильно ([гайд по OpenCode](https://futurecraft.pro/ru/blog/opencode-guide/)). Подключение Claude Code к локальной модели через Ollama описано в статье [Claude Code в России](https://futurecraft.pro/ru/blog/claude-code-russia/), Anthropic такую связку официально не поддерживает.

**Эмбеддинги и RAG.** Чат-модель для этого не нужна: в Ollama есть отдельные модели с меткой `embedding`, например `nomic-embed-text` и `qwen3-embedding`. Как выбирать эмбеддинги и строить retrieval, разобрано в [гайде по RAG](https://futurecraft.pro/ru/blog/rag-system-guide/), когда хватает длинного контекста без RAG - в статье [Context Engineering vs RAG](https://futurecraft.pro/ru/blog/context-engineering-vs-rag/).

**Картинки.** Изображения на входе принимают Qwen3.5-3.8, Gemma 4 и Muse Glimmer 30B. Метку `vision` смотрите на странице модели в библиотеке.

## Лицензии: что проверить перед коммерческим использованием

«Открытые веса» и «open source» - разные вещи: веса можно скачать, а условия использования задаёт лицензия конкретной модели. Лицензии ниже взяты из поля `license` и текста карточек на Hugging Face. Это не юридическая консультация.

| Лицензия | Модели |
|---|---|
| Apache 2.0 | Qwen3.8-27B, Qwen3.6, Qwen3.5, Gemma 4, gpt-oss, Mistral Small 4, Devstral Small 2, Muse Glimmer 30B |
| MIT | DeepSeek V4.1 Flash, DeepSeek-V4-Pro, DeepSeek R1 (у дистиллятов проверяйте базовую модель) |
| Собственная лицензия вендора | Qwen3.8-Flash-Next (`qwen-community-1.0`), флагман Qwen3.8 2,4T, Llama 4 (Llama 4 Community License), Mistral Large 4 (Mistral Ecosystem Open-Weight License), Mistral Medium 3.5, Muse Spark Open |

Что сделать перед продуктом на локальной модели:

1. Открыть карточку конкретной модели и конкретного размера: у Qwen3.8 27B и Flash-Next лицензии разные.
2. Для моделей из третьей строки прочитать полный текст лицензии и сверить его со своим сценарием: внутренний инструмент, продукт для клиентов, модель как сервис.
3. Проверить, на чём построена производная модель: дистиллят или файнтюн наследует условия базовой.
4. Записать версию модели и ссылку на лицензию в документацию проекта.

## Локальная и облачная модель вместе

Частая схема: простые и чувствительные задачи идут в локальную модель, сложные - в облачную, а при недоступности локального сервера запрос уходит в облако. Строить такую схему можно на трёх уровнях:

- **в коде приложения** - роутинг по типу задачи, ретраи и fallback, разобранные в статье [про провайдеров LLM в production](https://futurecraft.pro/ru/blog/multi-provider-llm-architecture/);
- **через self-hosted шлюз** - [LiteLLM](https://futurecraft.pro/ru/blog/litellm-guide/) описывает Ollama и облачных провайдеров в одном `config.yaml` с fallback между ними;
- **через облачный агрегатор** - [OpenRouter](https://futurecraft.pro/ru/blog/openrouter-guide/) даёт один ключ на облачные модели, в том числе на открытые модели, которые не запустить локально.

Как связать это с наблюдаемостью, бюджетами и evals, описано в [Production LLM Stack](https://futurecraft.pro/ru/blog/production-llm-stack/).

## Ограничения и подводные камни

### Контекст по умолчанию зависит от видеопамяти

На машинах, где GPU видит меньше 24 GiB, Ollama по умолчанию ставит контекст 4k. Системный промпт агента туда не помещается, и Ollama молча обрежет вход. Перед подключением агента проверьте колонку CONTEXT в `ollama ps`.

### Контекст не поднимается выше нативного окна

`num_ctx` больше окна, на котором обучена модель, не работает: у qwen3:8b при запросе 65536 Ollama выставила 40960. Ошибки при этом нет, реальное значение видно только в `ollama ps`. Подробности в [гайде по Ollama](https://futurecraft.pro/ru/blog/ollama-guide/).

### Один тег - разные файлы

`qwen3.8:27b` на Mac и на Linux - разные сборки (MLX nvfp4 и GGUF Q4_K_M). Цифры скорости и памяти из чужих замеров сравнимы только при одинаковом явном теге, версии раннера и контексте.

### `ollama ps` занижает память llama.cpp-моделей

В Ollama 0.40.14 у моделей на раннере llamacpp колонка SIZE может быть в разы меньше файла: 1,6 ГБ у `gemma4:26b-a4b` при 18 ГБ. Веса отображаются из файла через mmap и в счёт процесса не попадают. Оценивайте занятость как файл плюс footprint раннера, у MLX-моделей смотрите footprint или Activity Monitor.

### Лимит GPU-памяти на Mac не документирован

28,1 ГиБ из 36 ГБ - наблюдение на одной машине. На Mac с 16, 64 или 128 ГБ доля может быть другой, смотрите `total_vram` в логе сервера Ollama.

### Чужие цифры скорости не переносятся

Вендорские замеры MLX сняты на других чипах и моделях. Даже на одной машине скорость меняется от версии раннера: в гайде по Ollama та же qwen2.5-coder:7b при переходе с Ollama 0.24.0 на 0.40.14 стала занимать 6,6 ГБ вместо 8,2 ГБ.

### Таблица устаревает за месяцы

Qwen выпустил 3.5, 3.6 и 3.8 за полгода, а у тегов в библиотеке Ollama встречаются обновления недельной давности. Цифры в этой статье привязаны к дате проверки (7 ноября 2026) и версии Ollama 0.40.14. Пример реальной малой модели на Mac в продукте разобран в [постмортеме Ambient AI](https://futurecraft.pro/ru/blog/ambient-ai-mac-tauri-swift-ollama-postmortem/).

## С чего начать

1. Узнайте, сколько памяти видит GPU: на NVIDIA это объём видеопамяти, на Mac - `total_vram` в логе сервера Ollama.
2. Вычтите память под контекст: для агента нужно от 64k токенов, KV-кэш посчитайте по `config.json` модели.
3. Выберите модель из таблицы «память - модели», предпочитая MoE, если важна скорость генерации.
4. Проверьте лицензию в карточке модели на Hugging Face.
5. Скачайте модель явным тегом с квантизацией и запустите `ollama run <тег> --verbose`.
6. Сверьте `ollama ps`: CONTEXT, RUNNER и `100% GPU` в PROCESSOR. Память для моделей на llama.cpp считайте как файл плюс footprint раннера: SIZE в `ollama ps` 0.40.14 для них несопоставим с файлом.
7. Если модель не справляется с задачей, подключите облачную модель через fallback. Модель крупнее доступной памяти частично уйдёт на CPU и потеряет в скорости.