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

Локальная 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.

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

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

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

• данные нельзя отправлять наружу: персональные данные, внутренние логи, код под NDA. В FAQ Ollama сказано, что при локальном запуске Ollama не видит промпты и данные;
• задача массовая и простая: классификация, извлечение полей, черновые саммари, эмбеддинги для поиска;
• нужна работа офлайн или эксперименты без счёта за токены;
• нужен предсказуемый резерв на случай, когда облачный провайдер недоступен.

Где не оправдана: многошаговые агентные задачи и сложный рефакторинг. В тесте с OpenCode локальные 7-8B модели выполняли короткие правки, но многошаговую задачу стабильно не решила ни одна, подробности в гайде по OpenCode. В production локальная модель обычно становится одним из провайдеров рядом с облачными. Как распределять между ними задачи и строить fallback, разобрано в статьях про провайдеров LLM в production и Production LLM Stack.

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

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

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

Веса = число параметров × бит на вес / 8. Квантизация уменьшает число бит на вес. Названия вроде «Q4» и «Q8» округлены: в квантизациях llama.cpp часть тензоров хранится с большей точностью, и реальная цифра выше. Таблица из документации llama-quantize на примере Llama 3.1 8B:

Отсюда быстрое правило для 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, на Gemma 4 12B потеря качества относительно BF16 (по перплексии) у NVFP4 примерно вдвое меньше, чем у q4_K_M. Это измерение вендора на одной модели.

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

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

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

Параметры берут из config.json модели на Hugging Face. По умолчанию Ollama хранит кэш в f16, это 2 байта на элемент. Сверка с замерами из гайда по Ollama (Ollama 0.40.14, контекст 32768, M4 Max):

Для обычного трансформера с 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 и замером не подтверждён:

Вилка у 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:

• 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). 546 ГБ/с относится к старшей версии M4 Max с 16-ядерным CPU. Конфигурация на 36 ГБ, на которой сняты замеры в статье, бывает только с 14-ядерным CPU и 32-ядерным GPU, у неё 410 ГБ/с.

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): меньше 24 GiB - 4k токенов, 24-48 GiB - 32k, от 48 GiB - 256k. Mac с 36 ГБ попадает в средний диапазон и получает 32768.

Второй путь на Mac - MLX, фреймворк Apple для машинного обучения. Ollama показала движок на MLX для Apple Silicon в версии 0.19 (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).

Практическое следствие проверено на тестовой машине: на момент замера 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 нужны compute capability 5.0+ и драйвер 550 и новее (для карт с compute capability 5.0-6.2 - 570+). RTX 5090 несёт 32 ГБ GDDR7 на 512-битной шине (NVIDIA). Для других карт ориентируйтесь на классы видеопамяти 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, он считает модель на CPU, если GPU нет, и умеет гибридный CPU+GPU режим для моделей больше видеопамяти. На CPU генерацию ограничивает пропускная способность оперативной памяти, а у обычного ПК она ниже, чем у видеопамяти или unified memory Mac. Для чата на моделях 1-4B этого хватает, для агентов и длинного контекста нет. Собственных замеров на CPU в статье нет, а цифры из обзоров в сети приводятся без методики.

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

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

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

• У тегов с диапазоном размеров (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.

Семейства открытых моделей на ноябрь 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 под 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 активных (карточка). Веса экспертов хранятся в 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 ГБ».

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

Номера версий в таблицу не вынесены: раннеры обновляются чаще, чем имеет смысл переписывать таблицу, а у llama.cpp сборки вообще нумеруются тегами bNNNN. Установка, API и настройки Ollama - в гайде по Ollama, сравнение двух самых популярных десктопных вариантов - в статье 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.

Длинный промпт у моделей разной длины из-за токенизаторов: 8 887 токенов у Qwen, 9 044 у Gemma 4 26B, 8 344 у gpt-oss, 9 040 у gemma4:e4b. Почему один и тот же текст даёт разное число токенов, разобрано в статье о токенах и их подсчёте. Широкий разброс у 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:

Для 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. В тесте с OpenCode qwen2.5-coder:7b с меткой tools печатала вызовы инструментов текстом, а 8B-модели проходили задачу нестабильно (гайд по OpenCode). Подключение Claude Code к локальной модели через Ollama описано в статье Claude Code в России, Anthropic такую связку официально не поддерживает.

Эмбеддинги и RAG. Чат-модель для этого не нужна: в Ollama есть отдельные модели с меткой embedding, например nomic-embed-text и qwen3-embedding. Как выбирать эмбеддинги и строить retrieval, разобрано в гайде по RAG, когда хватает длинного контекста без RAG - в статье Context Engineering vs RAG.

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

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

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

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

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

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

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

• в коде приложения - роутинг по типу задачи, ретраи и fallback, разобранные в статье про провайдеров LLM в production;
• через self-hosted шлюз - LiteLLM описывает Ollama и облачных провайдеров в одном config.yaml с fallback между ними;
• через облачный агрегатор - OpenRouter даёт один ключ на облачные модели, в том числе на открытые модели, которые не запустить локально.

Как связать это с наблюдаемостью, бюджетами и evals, описано в Production LLM Stack.

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

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

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

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

num_ctx больше окна, на котором обучена модель, не работает: у qwen3:8b при запросе 65536 Ollama выставила 40960. Ошибки при этом нет, реальное значение видно только в ollama ps. Подробности в гайде по Ollama.

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

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.

С чего начать

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 и потеряет в скорости.