Сначала считайте не параметры, а задачу и память
Для локальной LLM на мощном железе главный вопрос не в том, сколько у модели миллиардов параметров. Важно, что именно она должна делать. Чат с документами, генерация кода, анализ логов, поиск по базе знаний, агент с инструментами, локальный помощник для команды, обработка персональных данных — это разные сценарии. Одна модель может хорошо писать тексты, но слабее держать длинный контекст. Другая отлично пишет код, но отвечает сухо и хуже понимает русский. Третья быстро работает в 4-битной квантизации, но заметно теряет в точности на сложных задачах.
В 2026 году для локального использования стоит смотреть не только на размер модели, но и на связку: модель, формат весов, квантизация, движок инференса, длина контекста, скорость дисковой подсистемы, объем VRAM и качество охлаждения. На бумаге модель на 70B может выглядеть сильнее, чем 32B. Но если она не помещается в видеопамять и постоянно выгружает слои в RAM, ответ будет медленным. Иногда хорошо настроенная 32B в Q5 или Q6 даст лучший реальный опыт, чем 70B в слишком грубой квантизации.
Если у вас одна видеокарта на 24 ГБ, разумный рабочий диапазон — модели 7B, 8B, 14B и часть 32B в 4-битной квантизации. Для длинного контекста запас быстро заканчивается, потому что KV cache тоже занимает память. На 48 ГБ уже можно комфортнее запускать 32B, а некоторые 70B — с компромиссами. На 80–96 ГБ VRAM проще работать с 70B в хорошей квантизации и нормальным контекстом. С несколькими GPU и 160–192 ГБ VRAM можно смотреть на крупные MoE и плотные модели высокого класса, но там уже важны межкарточные связи, скорость PCIe или NVLink, настройка tensor parallel и стабильность сервера.
Для локальной работы с русским языком смотрите на реальные тесты, а не только на общие рейтинги. Многие модели хорошо проходят англоязычные бенчмарки, но хуже пишут по-русски, путают падежи, делают странные формулировки или не понимают юридический и технический контекст. Проверьте модель на своих промптах: письма, инструкции, фрагменты договоров, куски кода, внутренние регламенты, диалоги поддержки. Десять живых задач часто полезнее, чем одна высокая строка в лидерборде.
Лицензия тоже важна. Для личного использования это может быть не критично. Для компании — уже да. У разных открытых весов разные условия: где-то есть ограничения на коммерческое применение, где-то требования к атрибуции, где-то лимиты по масштабу продукта. Перед внедрением в бизнес лучше проверить лицензию модели, датасета, токенизатора и возможных адаптеров. Иначе можно собрать сильный локальный стек, а потом понять, что его нельзя легально использовать в нужном сценарии.
Еще один практический критерий — экосистема. Хорошая локальная LLM должна без боли запускаться в vLLM, llama.cpp, Ollama, LM Studio, Text Generation Inference, TensorRT-LLM или другом удобном для вас движке. Нужны готовые GGUF, AWQ, GPTQ, EXL2 или safetensors-веса. Нужны шаблоны чата, нормальная поддержка system prompt, function calling или хотя бы стабильный JSON-вывод, если вы строите агента. Модель без нормальной обвязки может быть сильной, но дорогой в обслуживании.
Для SEO, контента и офисных задач обычно важны связность, русский язык, умение не выдумывать лишнее и работа с длинными документами. Для разработки — качество кода, понимание репозитория, исправление ошибок, генерация тестов, работа с терминальными логами. Для RAG — не столько красота ответа, сколько умение опираться на найденные фрагменты и не спорить с источником. Для аналитики — устойчивость к таблицам, числам и многошаговым рассуждениям. Поэтому выбор локальной модели начинается с короткого набора тестов под вашу работу.
Если нужно универсальное решение для локального сервера, в первую очередь стоит смотреть на свежие открытые веса из семейств Llama, Qwen, Mistral, DeepSeek, Gemma и специализированные coder-модели. Конкретные версии к 2026 году могут меняться, но логика выбора останется такой же: берите не самую громкую модель, а ту, которая лучше проходит ваши задачи, имеет понятную лицензию и хорошо поддерживается инструментами инференса.
Семейство Llama обычно выбирают как базовый вариант для универсального локального ассистента. У таких моделей сильная экосистема, много квантизованных сборок, адаптеров, гайдов и готовых интеграций. Это удобно, если вы не хотите тратить недели на настройку. Для чата, суммаризации, классификации, работы с базой знаний и внутренних помощников Llama-подобные модели часто дают ровный результат. Минус простой: для русского языка и кода они не всегда лучшие в своем размере. Поэтому их стоит сравнивать с Qwen и DeepSeek на одинаковых промптах.
Какие семейства моделей смотреть в первую очередь
Qwen стоит рассматривать, если вам важны русский язык, многоязычность, код и длинный контекст. В локальных установках эти модели часто показывают хороший баланс между качеством и размером. Они подходят для корпоративного ассистента, анализа документов, генерации инструкций, помощи разработчикам и смешанных задач, где в одном диалоге могут быть русский текст, английская документация, JSON, SQL и Python. Для мощного железа особенно интересны средние и крупные варианты, потому что они меньше страдают от поверхностных ответов и лучше держат сложную структуру.
Mistral и Mixtral обычно интересны тем, кто хочет хорошую скорость и сильную работу на европейских языках, включая приемлемый русский в новых версиях. MoE-модели могут быть выгодны: общее число параметров большое, но на каждый токен активируется часть экспертов. Это дает хороший баланс качества и скорости, если движок инференса нормально поддерживает такую архитектуру. Но MoE не всегда проще в эксплуатации. Нужно смотреть, как модель ведет себя на вашем железе, сколько памяти требует и нет ли проблем с батчингом.
DeepSeek и близкие coder-семейства стоит брать в шорт-лист для программирования, математики, анализа кода и инженерных задач. Если локальная LLM нужна разработчикам, не ограничивайтесь общим чат-ботом. Проверьте модели на реальных задачах: исправление багов, рефакторинг, объяснение stack trace, генерация unit-тестов, работа с SQL, анализ Dockerfile, Terraform, CI-конфигов. Хорошая coder-модель может писать менее «красивые» тексты, но заметно лучше справляться с репозиторием и точными инструкциями.
Gemma и небольшие модели вроде Phi-подобных решений полезны там, где нужна скорость, низкая задержка и простая установка. Они не заменят крупную 70B-модель в сложном анализе, но хорошо подходят для локального помощника на рабочей станции, предварительной классификации, маршрутизации запросов, извлечения сущностей, коротких ответов, проверки формата и дешевого инференса. В продакшене часто работает схема с двумя моделями: маленькая быстро сортирует запросы, большая отвечает на сложные.
Для русского языка не забывайте про дообученные варианты. Иногда базовая международная модель уступает локально адаптированной версии на русскоязычных данных. Но тут есть риск. Часть fine-tune-моделей становится лучше в стиле ответа, но хуже в фактах, логике или коде. Проверяйте не только красивые демо, а устойчивость: одинаковые вопросы в разных формулировках, длинные документы, отказ от выдуманных ссылок, соблюдение ограничений, работа с таблицами и датами.
Если нужна модель для RAG, не выбирайте LLM отдельно от эмбеддингов и reranker. Локальный поиск по документам часто ломается не на генераторе ответа, а на плохом извлечении фрагментов. Для русскоязычной базы знаний нужны хорошие multilingual embedding-модели, нормальная нарезка документов, хранение метаданных и rerank найденных кусков. После этого даже средняя LLM может отвечать лучше, чем крупная модель без доступа к правильным источникам.
Для агентных сценариев важны tool use, JSON, function calling и устойчивость к инструкциям. Модель должна не просто красиво рассуждать, а возвращать валидный формат, вызывать нужный инструмент, не смешивать текст ответа и служебные поля, корректно обрабатывать ошибки. Здесь крупная модель не всегда лучше. Иногда средняя instruct-модель с хорошим шаблоном и строгим декодированием работает надежнее, чем более мощная, но болтливая.
Для одной мощной рабочей станции хороший старт — видеокарта с 24–48 ГБ VRAM, 64–128 ГБ RAM, быстрый NVMe и современный CPU. На таком железе можно комфортно тестировать 7B–32B модели, запускать RAG, держать локальный интерфейс и не зависеть от облака. Для личного использования этого часто достаточно. Для команды лучше сразу думать о сервере с несколькими GPU, очередями запросов, мониторингом, логированием и ограничениями доступа.
Если у вас 24 ГБ VRAM, выбирайте 8B–14B для быстрых задач и 30B–32B в 4-битной квантизации для более сложных. Не гонитесь за 70B, если после запуска остается мало памяти на контекст. Для русского текста и кода лучше иметь стабильную 14B или 32B, чем еле живую большую модель, которая отвечает по минуте. Форматы GGUF через llama.cpp удобны для простого запуска. EXL2, AWQ и GPTQ часто дают хорошую скорость на NVIDIA, но требуют чуть больше внимания к настройкам.
Практичная конфигурация: от рабочей станции до локального сервера
Если у вас 48 ГБ VRAM, можно строить более серьезную локальную систему. Хороший вариант — держать одну универсальную 32B-модель в качественной квантизации и отдельную coder-модель для разработки. Для RAG можно добавить локальные эмбеддинги и reranker. В таком режиме сервер уже способен обслуживать несколько пользователей, если запросы не слишком длинные. Но стоит настроить лимиты на контекст и max tokens, иначе один большой документ съест память и задержит очередь.
Если у вас 80–96 ГБ VRAM, имеет смысл тестировать 70B-класс. Такие модели лучше справляются с неоднозначными задачами, длинными инструкциями, аналитикой, сложным стилем и диалогами с большим количеством условий. Но прирост не всегда пропорционален цене. Для рутинных запросов большая модель может быть избыточной. Поэтому практичная схема — маршрутизация: простые задачи идут на 8B–14B, средние на 32B, сложные на 70B. Это снижает задержку и экономит ресурс.
С несколькими GPU можно запускать крупные плотные модели и MoE. Но это уже не «поставил и забыл». Нужно проверять совместимость драйверов, CUDA, PyTorch, vLLM или TensorRT-LLM, режим parallelism, скорость обмена между картами и поведение под нагрузкой. Две видеокарты с большой VRAM не всегда дают в два раза больше удобства. Если связь между ними медленная, часть моделей будет отвечать заметно хуже, чем ожидалось. Перед покупкой железа лучше найти тесты именно вашей модели на похожей конфигурации.
Квантизация — нормальная практика, а не признак слабого железа. Q4 часто дает хороший баланс для чата и общего использования. Q5 и Q6 лучше сохраняют качество, особенно в коде, математике и сложных инструкциях. FP16 или BF16 нужны, если вы дообучаете модель, проводите точные сравнения или работаете с задачами, где потеря качества критична. Для продакшена обычно выбирают самый дешевый вариант, который проходит внутренние тесты без заметной деградации.
Контекст — отдельная статья расходов. Модель с заявленным контекстом 128K не всегда будет полезна на 128K в реальной работе. Длинный контекст требует памяти, замедляет ответы и может ухудшать внимание к деталям. Для документов чаще лучше RAG с хорошим поиском, чем огромный промпт. Большой контекст нужен для анализа репозитория, длинных переписок, юридических пакетов и технических отчетов. Но даже там стоит нарезать данные и давать модели только нужное.
Для WordPress, SEO и редакционных задач локальная LLM может решать много рутинной работы: кластеризация запросов, черновики статей, метаописания, структуры страниц, переписывание фрагментов, проверка дублей, адаптация тона. Но ее надо ограничивать. Модель не должна сама выдумывать факты, цены, характеристики и ссылки. Хороший процесс выглядит так: данные берутся из проверенного источника, модель помогает оформить текст, человек проверяет смысл, затем материал публикуется. Так локальный запуск дает приватность и контроль, но не превращается в фабрику ошибок.
Для выбора в 2026 году я бы делал так: собрать 20–30 своих тестовых запросов, выбрать по две-три модели из Llama, Qwen, Mistral, DeepSeek и Gemma, запустить их в одинаковой квантизации, измерить качество, скорость, потребление VRAM и стабильность формата ответа. Потом оставить не одну модель, а набор. Маленькая — для быстрых задач. Средняя — для основной работы. Крупная — для сложного анализа. Отдельная coder-модель — для разработки, если код важен. Такой подход обычно лучше, чем поиск одной «самой сильной» LLM на все случаи.
Главный критерий простой: локальная модель должна решать вашу задачу быстрее, дешевле или безопаснее, чем облачная. Если она требует постоянной ручной настройки и дает нестабильные ответы, мощное железо не спасет. Если же модель хорошо подобрана, имеет понятную лицензию, запускается в надежном движке и проходит ваши тесты, локальный стек становится сильным рабочим инструментом. Не идеальным. Но предсказуемым, контролируемым и удобным для задач, где данные лучше держать у себя.
Данная статья носит информационный характер.