Open-source LLM 2026: Llama, Mistral, Qwen, DeepSeek — гайд

open-source LLM в 2026 году уже не про «запустили ради эксперимента на одной видеокарте», а про реальную альтернативу закрытым API для продакшена, внутреннего поиска, copilot-сценариев и локальных агентных систем. Ниже — практический гайд по семействам Llama 4, Mistral, Qwen 3, DeepSeek-V3/R1 и Gemma 3: что выбрать, как деплоить, когда квантизовать, когда дообучать и сколько GPU на это уйдёт.

Зачем open-source LLM в 2026

У корпоративного интереса к open-source LLM в 2026 году три простые причины: контроль, экономика и скорость итераций. Контроль нужен там, где данные нельзя гонять через внешний API: финтех, healthcare, legal, промышленность, крупный e-commerce, внутренние корпоративные базы. Экономика важна в сценариях с постоянным трафиком: если у вас тысячи или десятки тысяч запросов в день, self-hosted-модель почти всегда начинает выигрывать по себестоимости. А скорость итераций появляется тогда, когда команда сама решает, какой inference-стек поднять, какую квантизацию выбрать и когда докрутить модель через LoRA вместо ожидания дорожной карты внешнего вендора.

Что изменилось по сравнению с 2024–2025

Рынок стал заметно зрелее. Раньше под «открытой моделью» часто подразумевали либо компактный research-чекпойнт, либо красивую демку с очень условным продакшеном. В 2026-м у компаний уже есть нормальный выбор: длинный контекст, мультимодальность, reasoning-режимы, function calling, OpenAI-совместимые серверы, готовые quantized-варианты и понятные пайплайны дообучения. Иначе говоря, open-source LLM перестал быть игрушкой для ML-команды и стал обычным инфраструктурным решением рядом с Postgres, Kafka и Kubernetes.

Где подвох

Подвох в терминах. На рынке по-прежнему смешивают open source, open weight и source available. Для практики это не занудство, а вопрос лицензии, дистрибуции и коммерческого риска. Meta Llama 4 — это не Apache 2.0, а Llama 4 Community License с порогом в 700 млн MAU и обязательством показывать “Built with Llama” при распространении. У Qwen 3 и Mixtral ситуация проще: Apache 2.0. У DeepSeek-V3 и R1 — максимально мягкий MIT для репозитория и, в свежих релизах, очень либеральные условия на веса. У Gemma — открытая модель Google, но корпоративный юрист всё равно должен читать условия так же внимательно, как инженеры читают README.

Как выбирать без лишней романтики

• Если нужен максимум экосистемы и интеграций — смотрите на Llama 4 и Qwen 3.
• Если важна стоимость инференса на единицу качества — уместны MoE-модели Mistral, Qwen и DeepSeek.
• Если нужен reasoning без закрытого API — DeepSeek-R1 и Qwen 3 обычно в шорт-листе первыми.
• Если требуется on-device или одна GPU без фокусов — Gemma 3 и плотные Qwen 3 выглядят практичнее.
• Если важен русский плюс широкий мультиязык — у Qwen 3 шансы выше, чем у многих западных семейств.

Семейство	Лицензия	Тип открытости	Главный плюс
Llama 4	Custom, Llama 4 Community License	Open weight	Экосистема и long context
Mixtral / Mistral	Apache 2.0	Близко к классическому open source	Эффективные MoE
Qwen 3	Apache 2.0	Открытые веса	119 языков и гибридное reasoning
DeepSeek-V3 / R1	MIT / permissive	Максимально открытый вариант	Reasoning и цена/качество
Gemma 3	Открытая модель Google	Open model	Лёгкий запуск на одной GPU

Llama 4 и family — флагман

Если нужен open-source LLM, который знают все подрядчики, все облака и половина инженеров на рынке, Llama 4 остаётся самым «дефолтным» вариантом. У Meta в апреле 2025 вышли две основные модели: Llama 4 Scout и Llama 4 Maverick. Обе — нативно мультимодальные и построены на MoE-архитектуре, то есть не активируют все параметры на каждый токен. Для бизнеса это важно: качество растёт быстрее, чем счёт за железо.

Что важно по спецификациям

Scout — это 17B активных параметров при 109B total, 16 экспертов и контекст до 10 млн токенов. Да, цифра выглядит как будто кто-то забыл поставить десятичную точку, но именно длинный контекст делает Scout интересным для документных хранилищ, анализа кодовых баз и длинных агентных сценариев. Meta отдельно указывает, что Scout можно уместить на одной H100 с on-the-fly int4-квантизацией.

Maverick — это 17B активных параметров при 400B total, 128 экспертов и контекст до 1 млн токенов. Модель тяжелее, но лучше подходит под сильный ассистентский и мультимодальный use case. В карточках Meta есть BF16 и FP8-варианты; FP8-веса рассчитаны на более реальный деплой в крупных GPU-хостах.

Где Llama 4 сильна

• Очень длинный контекст у Scout, если ваш продукт живёт на документах, логах, политиках или монорепе.
• Нативная мультимодальность: текст плюс изображение без костылей из нескольких моделей.
• Большая экосистема: Hugging Face, Bedrock, NVIDIA NIM, TensorRT-LLM, vLLM, коммерческие провайдеры.
• Подготовленные quantized-чекпойнты и понятный путь к продакшену.

Но есть нюанс с лицензией

Llama 4 — это не Apache и не MIT. В Llama 4 Community License есть порог 700 млн monthly active users, а при распространении производных продуктов есть обязательства по атрибуции. Для большинства компаний это не стоп-фактор, но для платформенного бизнеса, OEM-решений и enterprise procurement это уже предмет разговора не только с ML-лидом, но и с legal.

Ещё один момент: в модельных карточках Meta указано только 12 поддерживаемых языков для tuned-моделей, хотя предобучение покрывало до 200 языков. Это значит, что Llama 4 пригодна для многоязычных задач, но для русского, восточноевропейских языков и сложного смешанного input Qwen 3 часто выглядит прагматичнее.

Итог простой. Llama 4 — это open-source LLM для тех, кому нужен сильный флагман с огромной экосистемой, очень длинным контекстом и понятным enterprise-путём. Но если у вас в приоритете максимально свободная лицензия или жёсткая мультиязычность, флагманом по умолчанию она становится не всегда.

Mistral, Mixtral — эффективные MoE

Mistral давно заняла нишу команды, которая не обещает «AGI к пятнице», а стабильно делает модели с хорошим отношением качества к цене инференса. Для рынка open-source LLM это важная роль: не все хотят тащить 400B-веса ради чат-бота, который отвечает на тикеты в техподдержке и суммаризирует PDF. Именно здесь Mixtral до сих пор остаётся эталоном инженерной адекватности.

Mixtral 8x7B: старый, но всё ещё очень полезный

У Mixtral 8x7B — 47B total, 13B active, контекст 32K и официальный диапазон памяти примерно 94 ГБ в bf16 до 13 ГБ в fp4. На практике это одна из немногих MoE-моделей, которую можно запустить не только «на кластерных молитвах», но и на вполне земном железе с квантизацией. Для self-hosted-пилотов, внутренних чат-ассистентов и базового code helper этого часто хватает.

Mixtral 8x22B: MoE без лишнего пафоса

Mixtral 8x22B — более серьёзная история: 141B total, 39B active, контекст 64K, Apache 2.0 и встроенная пригодность к function calling. Mistral отдельно подчёркивает пять сильных языков: английский, французский, итальянский, немецкий и испанский. Для европейских компаний это весомый аргумент: модель не выглядит англоязычной с насильно прикрученным переводчиком.

По духу Mixtral 8x22B — это модель для тех, кто считает не только benchmark score, но и стоимость ответа. Sparse-активация здесь не маркетинговый баннер, а прямой ответ на вопрос CFO: почему мы не покупаем ещё восемь GPU? Модель быстрее dense-70B по фактическому бюджету инференса и остаётся хорошей базой для fine-tuning.

Почему Mistral всё ещё в разговоре в 2026

У самой Mistral линейка уже ушла дальше: в документации 2026 года рядом с legacy Mixtral видны Mistral Small 4, Large 3 и другие новые open-weight-модели. Но Mixtral важен не только как конкретный чекпойнт, а как паттерн. Он показал рынку, что open-source LLM может быть не просто «большим», а именно эффективным.

• Если у вас европейская языковая матрица — Mistral выглядит естественно.
• Если нужен Apache 2.0 без лицензионной экзотики — тоже плюс.
• Если задача — тонкая настройка внутреннего ассистента без GPU-апокалипсиса — Mixtral остаётся здравым выбором.

Слабое место у Mistral одно: экосистема вокруг неё меньше, чем вокруг Llama, а мультиязычность шире и агрессивнее продвигает Qwen. Но когда нужен не самый шумный, а самый рациональный MoE, у Mistral по-прежнему хорошая репутация человека, который пришёл на встречу с калькулятором, а не с презентацией на 80 слайдов.

Qwen 3 от Alibaba — мультиязык

Если бы в 2026 году нужно было назвать одно семейство, которое чаще всего появляется в шорт-листе «хотим open-source LLM для реального международного продукта», это был бы Qwen 3. Alibaba выпустила сразу восемь открытых моделей: две MoE и шесть dense. Флагман — Qwen3-235B-A22B, более компактный MoE — Qwen3-30B-A3B, плюс плотные модели на 32B, 14B, 8B, 4B, 1.7B и 0.6B. Всё это — под Apache 2.0, что для бизнеса резко упрощает жизнь.

Почему Qwen 3 так часто побеждает «на бумаге» ещё до пилота

Во-первых, у Qwen 3 очень сильная языковая история: 119 языков и диалектов. Это не только английский плюс ещё пара европейских языков «для галочки», а реально широкий охват, включая русский, украинский, польский, арабские варианты, индийские языки, Southeast Asia и китайские варианты письма. Для глобального SaaS, маркетплейса, travel-tech или B2B-платформы это экономит месяцы боли на этапе evaluation.

Во-вторых, у Qwen 3 есть интересная конструкция с hybrid thinking modes. Модель умеет работать в режимах thinking и non-thinking, а переключение можно контролировать прямо в шаблоне общения: через /think и /no_think. То есть вы не платите reasoning-токенами за каждый банальный вопрос пользователя и при этом не теряете «мозг» там, где нужен разбор логики, кода или длинной инструкции.

Что по цифрам

У Qwen3-235B-A22B — 235B total, 22B active, у Qwen3-30B-A3B — 30B total, 3B active. Контекст у старших dense и обеих MoE-моделей — 128K, у мелких dense 0.6B–4B — 32K. Предобучение выросло почти вдвое относительно Qwen2.5: около 36 трлн токенов. Для продакшена команда Qwen отдельно рекомендует SGLang и vLLM; для локальной работы — Ollama, LM Studio, MLX, llama.cpp и KTransformers.

Где Qwen 3 особенно хорош

• Мультиязычные чат-продукты и knowledge assistants.
• Code и agentic-сценарии, где нужно tool use и контролируемое reasoning.
• Локальный запуск моделей 8B, 14B, 32B без драматического железа.
• Дообучение на узких вертикалях, где лицензия Apache 2.0 важнее бренда Meta.

Ещё одна причина популярности Qwen 3 — хорошая «лесенка» размеров. Вы можете начать с 8B или 14B, потом перейти на 30B-A3B, а в тяжёлых сценариях уйти на 235B-A22B, не ломая весь стек промптов, evaluation и deployment. Для платформенной команды это очень удобный путь: open-source LLM остаётся одним семейством, а не зоопарком из пяти несовместимых моделей.

Если говорить коротко, Qwen 3 сейчас выглядит как самый практичный выбор там, где продукт живёт не только на английском и не только в США. И это, мягко говоря, немаленький кусок мирового рынка.

DeepSeek-V3 / R1 — рекордные бенчмарки

DeepSeek за последние полтора года сделал ровно то, что раздражает весь рынок больше всего: показал, что open-source LLM может не просто «быть неплохим за свои деньги», а реально лезть в territory, которое раньше считалось вотчиной закрытых reasoning-моделей. Главное имя здесь — связка DeepSeek-V3 и DeepSeek-R1.

DeepSeek-V3: гигант, но не бесполезный гигант

У V3 спецификации такие: 671B total, 37B active, 14.8 трлн токенов предобучения. Архитектурно это MoE плюс Multi-head Latent Attention. В репозитории DeepSeek отдельно подчёркивают, что полный training budget составил 2.788 млн H800 GPU-часов. Для читателя это не повод срочно строить дата-центр, а индикатор зрелости: перед нами не красивый академический макет, а серьёзная производственная модель.

У DeepSeek-V3 важное лицензионное преимущество. Репозиторий кода лицензирован по MIT, серия поддерживает коммерческое использование, а свежие релизы идут по максимально либеральной модели. Для компаний, которым не хочется объяснять юристам, чем permissive license отличается от community license с отдельными условиями, это почти отдых.

DeepSeek-R1: reasoning как главный продукт

R1 — это уже история не про «универсальный ассистент», а про reasoning-first. Официально DeepSeek пишет, что DeepSeek-R1 достигает результатов, сопоставимых с OpenAI o1 на задачах математики, кода и рассуждения. У полной модели те же 671B total, 37B active, контекст 128K. Но главное здесь не только full-модель, а её distill-линейка: 1.5B, 7B, 14B, 32B и 70B на базах Qwen и Llama.

Вот это, пожалуй, и есть самое практичное достижение DeepSeek. Полный R1 локально нужен далеко не всем. А вот R1-Distill-Qwen-32B или R1-Distill-Llama-70B — уже вполне рабочие кандидаты для внутренних аналитических ассистентов, code review, QA по документации и сложных agentic-пайплайнов.

Когда выбирать DeepSeek

• Если на первом месте reasoning и benchmark-driven выбор.
• Если нужен permissive open-source LLM без лицензии с сюрпризами.
• Если команда готова жить с китайским стеком экосистемы и не боится более «инженерного» UX.
• Если full-модель не нужна, но distill-варианты выглядят сильнее конкурентов того же размера.

Слабое место DeepSeek очевидно: full V3 и full R1 очень тяжёлые по инфраструктуре. Они прекрасны как ориентир и как base для distillation, но не каждая команда хочет тащить сотни гигабайт весов ради чат-бота для helpdesk. Поэтому практический совет простой: смотрите на полные модели как на витрину возможностей, а на distill — как на реальный путь в прод.

Gemma 3 от Google — лёгкая для on-device

Gemma 3 — хороший пример того, что open-source LLM не обязан быть чудовищем на пол-стойки. Google прямо позиционирует семейство как набор lightweight open models, рассчитанных на запуск «на устройствах»: от ноутбуков до рабочих станций. Линейка простая и удобная: 1B, 4B, 12B и 27B. То есть не нужно устраивать конкурс по выбору между десятью почти одинаковыми SKU.

Что у Gemma 3 хорошо по спецификациям

У семейства есть 128K context window, поддержка function calling и структурированного вывода, текстово-визуальные возможности и очень приличная языковая история: свыше 35 языков из коробки и предобучение на 140+ языках. Google отдельно пишет, что Gemma 3 — это «most capable model you can run on a single GPU or TPU», а 27B-вариант на их графиках выглядит особенно выгодно: высокая пользовательская оценка при требованиях всего к одной GPU.

Где Gemma 3 реально удобна

• On-device и edge deployment.
• Локальные copilots для команд разработки и аналитики.
• Прототипы, которым не нужен огромный MoE и миллион токенов контекста.
• Продукты, где важны цена, latency и простота эксплуатации.

С практической точки зрения Gemma 3 особенно интересна командам, которые не хотят начинать с тяжёлой инфраструктуры. Если проекту нужна одна сильная модель на 27B, которую реально разместить на одном ускорителе, а не на «сервере мечты», Google предлагает понятный баланс. Плюс есть quantized-варианты, так что переход от эксперимента к локальному продакшену проходит без спектакля с ручной конвертацией весов.

Ограничения

Gemma 3 — не чемпион по экосистеме и не король reasoning-бенчмарков. В глобальном enterprise-разговоре Llama узнают быстрее, Qwen покрывает больше языков, DeepSeek громче шумит в сравнительных таблицах. Но у Gemma другая сильная сторона: она редко выглядит избыточной. А для большого числа команд это уже очень серьёзный комплимент.

Если формулировать без рекламных эпитетов, Gemma 3 — это open-source LLM для тех, кому нужна не самая большая модель в мире, а самая удобная модель в пределах одной видеокарты.

vLLM, TensorRT-LLM, llama.cpp

Даже лучшая модель превращается в дорогую грелку для GPU, если деплой сделан кое-как. В 2026 году у рынка есть три базовых стека, которые закрывают почти все сценарии: vLLM, TensorRT-LLM и llama.cpp. Выбирать между ними лучше не по любви к логотипу, а по железу и latency/throughput-профилю.

vLLM: дефолт для серверного деплоя

vLLM остаётся стандартом де-факто для self-hosted API. У проекта сильный набор фич: PagedAttention, continuous batching, OpenAI-compatible API server, tensor parallelism, streaming, поддержка NVIDIA и AMD, плюс работа с GPTQ, AWQ и LoRA. Если коротко, это самый удобный путь превратить open-source LLM в нормальный сервис, который понимают и backend-инженеры, и MLOps.

Главный плюс vLLM не в том, что он «быстрый» — это пишут все. Главный плюс в том, что он экономит память на KV-cache, умеет упаковывать запросы без лишних пауз и даёт предсказуемую эксплуатацию. Для многопользовательского продукта это обычно важнее, чем красивый single-request benchmark.

TensorRT-LLM: когда у вас NVIDIA и амбиции

TensorRT-LLM — это уже история для тех, кто живёт внутри экосистемы NVIDIA и хочет выжать максимум из H100, H200, B200 и похожих ускорителей. NVIDIA описывает его как Python API для сборки TensorRT-движков со state-of-the-art оптимизациями, плюс Python/C++ runtime и отдельный support matrix по GPU и моделям. Если ваш сценарий — высоконагруженный inference, multi-GPU и SLA, TensorRT-LLM часто даёт лучшую предельную производительность. Цена вопроса — большая сложность внедрения и более высокая зависимость от железа NVIDIA.

llama.cpp: король локалки и edge

llama.cpp — это противоположный полюс. Его сила не в максимальной серверной пропускной способности, а в portability. GGUF, CPU, Mac, небольшие GPU, локальные бинарники, простая упаковка в десктопный или edge-сценарий — вот его территория. Если вам нужно, чтобы модель запускалась у разработчика на ноутбуке, у аналитика на Mac Studio или в on-prem-инсталляции без полноценного GPU-кластера, llama.cpp почти всегда в игре.

Стек	Лучший сценарий	Плюсы	Компромиссы
vLLM	Self-hosted API, production inference	Высокий throughput, OpenAI-совместимость, LoRA, AWQ/GPTQ	Требует аккуратного тюнинга под batch и память
TensorRT-LLM	NVIDIA-only high-end production	Максимум производительности на NVIDIA	Сложнее стек, сильная привязка к вендору
llama.cpp	Локальный запуск, CPU/Mac/edge	GGUF, portability, простота	Не лучший выбор для большого многопользовательского API

Если нужен один совет без лирики: для большинства серверных пилотов берите vLLM, для NVIDIA-heavy enterprise — TensorRT-LLM, для локальных инсталляций и on-device — llama.cpp.

Quantization: GGUF, AWQ, GPTQ

Квантизация — это место, где open-source LLM перестаёт быть красивой статьёй в блоге и становится исполняемым файлом. Почти всегда вопрос звучит не «квантизовать или нет», а «во что именно и под какой стек». Ошибка тут типичная: люди выбирают формат по популярности на Hugging Face, а не по целевой инфраструктуре.

GGUF: формат для llama.cpp и локального мира

GGUF — это бинарный формат, который llama.cpp использует для хранения и распространения квантованных моделей. Внутри лежат веса, метаданные и описатели тензоров; поддерживаются F16/BF16, K-quants вроде Q2_K–Q8_K, I-quants и legacy-форматы. Практически это значит одно: если вы запускаете модель на CPU, Mac, локальной GPU или в десктопной упаковке, GGUF — почти всегда первый кандидат.

Самые ходовые варианты в реальной жизни — Q4_K_M и Q5_K_M. Первый даёт хороший баланс между качеством и памятью, второй — чуть лучшее качество ценой большего VRAM/RAM. Для узких и дешёвых локальных сценариев иногда берут Q3, но там деградация уже заметнее.

AWQ: хороший компромисс для GPU-сервинга

AWQ — это Activation-aware Weight Quantization. Проект MIT Han Lab стал фактическим стандартом для точной 4-битной квантизации с упором на сохранение качества и ускорение инференса. У AWQ сильная сторона в том, что он хорошо живёт в серверном GPU-мире, особенно когда модель крутится не в локальном UI, а в нормальном inference-движке.

Если вы деплоите через vLLM или похожий стек на NVIDIA, AWQ — один из самых практичных путей уменьшить память без слишком болезненного падения качества. Особенно это полезно на моделях 30B–70B и MoE-чекпойнтах, которые иначе быстро съедают бюджет по VRAM.

GPTQ: старый знакомый, который всё ещё полезен

GPTQ — посттренировочная квантизация, которая долго была стандартом для 4-битного запуска больших моделей на GPU. В 2026-м она уже не выглядит единственным вариантом, но никуда не делась. Поддержка в экосистеме есть, качество обычно предсказуемое, а для части моделей готовые GPTQ-сборки доступны быстрее, чем аккуратно собранные AWQ-варианты.

• Для CPU, Mac, desktop и edge чаще всего выбирайте GGUF.
• Для GPU-сервинга на vLLM или близких стеках обычно смотрите в сторону AWQ.
• Если под конкретную модель есть хороший GPTQ-чекпойнт и стек его поддерживает — это по-прежнему нормальный выбор.

Правило простое: не квантизуйте вслепую самую большую модель, которую нашли. Сначала определите latency budget, доступную память, длину контекста и тип запросов. Иногда 14B в Q5 выигрывает у 32B в агрессивном Q3 просто потому, что вторая модель «формально больше», но фактически уже потеряла пол-лица.

Fine-tuning: LoRA, QLoRA, Unsloth

Самая дорогая ошибка команд в работе с open-source LLM — начинать с fine-tuning там, где хватило бы нормального RAG, хорошего system prompt и пары недель evaluation. Дообучение нужно не для лечения лени, а для повторяющихся, измеримых, бизнес-критичных паттернов: свой стиль ответа, узкий домен, структурированный вывод, стабильное tool use, внутренняя терминология, специфика саппорта или кодовой базы.

LoRA: стандартный минимум без лишней драмы

LoRA — это low-rank adaptation: базовые веса замораживаются, а обучаются компактные адаптеры. Классическая статья Microsoft показывает сокращение числа обучаемых параметров до 10 000 раз и примерно 3 раза меньше требований к памяти по сравнению с полным fine-tuning. Для команды это означает простую вещь: можно держать один базовый чекпойнт и несколько лёгких адаптеров под разные департаменты, рынки или продукты.

QLoRA: когда GPU мало, а амбиции остались

QLoRA сделал параметрически эффективное дообучение по-настоящему массовым. Идея проста: базовая модель загружается в 4-битном виде, а градиенты идут через LoRA-адаптеры. В оригинальной работе авторы показали, что 65B-модель можно дообучать на одной GPU с 48 ГБ без потери качества относительно полноценного 16-bit fine-tuning. В реальной практике QLoRA — это то, с чего начинается большинство вменяемых корпоративных пилотов на моделях 14B–70B.

Unsloth: ускоритель для тех, кто не хочет собирать всё руками

Unsloth в 2026 году стал очень удобным слоем над training-пайплайном. По собственной документации проект обещает до 2x faster и примерно 70% less VRAM для обучения и RL-сценариев без потери точности. Поддержка большого числа моделей, экспорт в GGUF и дружба с Ollama, llama.cpp и vLLM делают его полезным не только для ресерча, но и для вполне прагматичного MLOps.

1. Сначала собирайте и чистите датасет. Для SFT плохие данные ломают модель быстрее, чем плохой learning rate.
2. Потом делайте baseline без обучения: prompt + RAG + retrieval filters.
3. Если метрики не дотягивают, переходите на LoRA или QLoRA.
4. Начинайте с 8B–14B или с компактного MoE, а не с full-флагмана.
5. Оценивайте не только win-rate, но и latency, hallucination rate, JSON validity, tool success rate.

Есть и неприятная правда: fine-tuning не исправляет фундаментально слабую модель. Если вам нужен reasoning на уровне R1, то LoRA на произвольной 8B-модели не превратит её в математического монстра. Дообучение должно усиливать уже существующие способности, а не заменять их магией из презентации для совета директоров.

Сколько GPU нужно под какую модель

На этом месте обычно начинается самое полезное: не «какая модель лучше на бенчмарке», а «что вообще запустится у нас без закупки нового крыла дата-центра». Ниже — практическая таблица по типовым конфигурациям. Это не физика в вакууме: реальная память зависит от длины контекста, batch size, KV-cache, формата весов и inference-движка. Но для планирования бюджета таких диапазонов обычно достаточно.

Модель	Локальный минимум	Комфортный прод-старт	Комментарий
Gemma 3 4B	8–12 ГБ в 4-bit	1 x 16–24 ГБ	Подходит для ноутбуков, Mac, простых локальных ассистентов
Gemma 3 27B	24–40 ГБ в 4-bit	1 x 48–80 ГБ	Один из лучших вариантов «сильная модель на одной GPU»
Qwen3 8B	8–12 ГБ в 4-bit	1 x 24 ГБ	Хороший базовый старт для RAG и чатов
Qwen3 14B / 32B	14–20 ГБ / 24–40 ГБ	1 x 48 ГБ или 1 x 80 ГБ	14B часто самый рациональный компромисс
Qwen3-30B-A3B	20–32 ГБ в 4-bit	1 x 48–80 ГБ	Активно только 3B, но хранить нужно все 30B весов
Mixtral 8x7B	13–24 ГБ в fp4/4-bit	1 x 48 ГБ	Официально около 94 ГБ bf16 и 13 ГБ fp4
Mixtral 8x22B	70–90 ГБ в 4-bit	2 x 80 ГБ	141B total, под bf16 уже нужен совсем другой бюджет
Llama 4 Scout	72–96 ГБ в int4	1 x H100 80 ГБ	Meta прямо указывает запуск на одной H100 с int4
Llama 4 Maverick	320–450 ГБ в FP8/4-bit	4–8 x 80 ГБ	400B total, уже инфраструктурная модель
DeepSeek-V3 / R1 full	350–450 ГБ в 4-bit	8 x 80 ГБ и выше	Для большинства команд разумнее смотреть на distill-версии
R1-Distill 32B / 70B	24–40 ГБ / 40–80 ГБ	1 x 80 ГБ или 2 x 48 ГБ	На практике часто лучший путь к reasoning

Что чаще всего недооценивают

• KV-cache может съесть десятки гигабайт при длинном контексте и большом concurrent load.
• 4-bit решает проблему весов, но не отменяет память под runtime и batch.
• MoE уменьшает активные параметры на токен, но не убирает необходимость хранить все эксперты.
• На production важнее tokens/sec на реальной нагрузке, чем лабораторный single-user benchmark.

Практическая схема выбора

Если бюджет маленький, начинайте с Gemma 3 27B, Qwen3 14B или Qwen3 30B-A3B. Если нужен разумный корпоративный старт на одном сильном узле — Qwen3 32B, Mixtral 8x7B или Llama 4 Scout. Если обсуждается Llama 4 Maverick или full DeepSeek-R1, значит разговор уже не про «какую модель скачать», а про архитектуру всего inference-кластера, балансировку, prefix caching и стоимость владения на квартал вперёд.

И последнее: для большинства команд хороший open-source LLM в 30B–70B классе, грамотно квантизованный и нормально задеплоенный, даёт больше пользы, чем «самая мощная модель на рынке», которая три недели живёт в статусе пилота и боится каждого лишнего токена.

Глубже на тему — исследования it-institute.ru

На партнёрском портале it-institute.ru опубликована подборка релевантных исследований с медианами, выборками и методологией:

• Карта вендоров: AI-инструменты
• Тренды Data/ML платформ
• AI в разработке ПО: реальное внедрение

Партнёрские проекты

• Stackfort — on-prem CDP-платформа

FAQ о open-source LLM

Следите за обновлениями itech-news.ru — мы держим эту страницу актуальной.