Локальные LLM наконец-то дошли до стадии, когда их можно обсуждать без двух крайностей.
С одной стороны, это уже давно не игрушка уровня «модель на 7B смешно отвечает на вопросы про столицу Франции». Нормальная локальная модель сегодня может писать код, разбирать документы, вытаскивать структурированные данные, работать с инструментами, переводить текст, помогать с черновиками, жить внутри голосового ассистента и не отправлять каждый ваш файл на сервер очередного API-провайдера.
С другой стороны, локальная LLM не превращает ваш ноутбук в личный дата-центр OpenAI. Если вы поставили модель в LM Studio, Ollama или Open WebUI, у вас не появился бесплатный GPT-5.5 без ограничений. У вас появился инструмент с вполне конкретными плюсами, минусами и границами применимости.
Главный смысл локальных LLM сейчас: контроль.
Контроль над данными. Контроль над стоимостью. Контроль над задержкой. Контроль над тем, что вообще можно собрать вокруг модели.
Если вы просто иногда просите нейросеть написать пост, объяснить статью или помочь с кодом, вам локальный запуск может быть не особо нужен. API или ChatGPT в браузере закроют задачу проще. Но если вы делаете свои кастомные обвязки вокруг LLM, ситуация меняется.
Например, вы хотите собрать локального голосового ассистента:
«Открой папку с документами и найди файл, где говорится про Х». «Сравни эти три PDF и выпиши расхождения». «Посмотри мои заметки и собери план на неделю». «Возьми лог сервера и объясни, что там сломалось». «Преобразуй таблицу в нормальный JSON». «Сделай черновик ответа клиенту по истории переписки».
Через API это тоже можно сделать. Просто каждый раз вы будете тащить личные данные наружу и платить за токены. Если данных много, это быстро перестаёт быть абстрактной проблемой. Сегодня вы отправили один документ. Завтра папку. Потом базу клиентов. Потом переписки. Потом внутренние логи сервера. И в какой-то момент вся ваша «локальная автоматизация» оказывается не совсем локальной.
Локальная LLM здесь работает не как замена всем облачным моделям, а как нижний слой инфраструктуры. Такой тихий рабочий механизм, который может крутиться у вас на компьютере или VPS и выполнять рутину без лишнего шума.
Особенно хорошо локальные модели подходят для задач, где важнее не абсолютный интеллект, а предсказуемая полезность.
Классификация писем. Извлечение полей из текста. Краткое резюме документов. Черновики сообщений. Поиск по собственной базе через RAG. Преобразование неструктурированного текста в таблицу. Простые агентные сценарии с инструментами. Локальный помощник в IDE. Работа с логами и конфигами. Перевод, если стоит специализированная модель.
На этом фоне новые небольшие и средние модели стали куда интереснее, чем условные «самые большие открытые модели», которые формально доступны, но на практике требуют железо уровня маленькой печки.
Gemma 4 31B — уже пример модели, которую можно рассматривать как серьёзный локальный вариант для рабочей станции. Не для старого ноутбука с 8 ГБ оперативки, конечно. Но для машины с нормальной видеокартой или большим запасом памяти это уже не выглядит как эксперимент ради эксперимента. У Gemma 4 также есть младшие E2B и E4B, которые больше подходят для on-device сценариев, и 26B A4B MoE, где активная часть меньше полной модели.
Qwen3.6-27B интересен с другой стороны. Это плотная 27B-модель, которую явно двигают в сторону агентного кодинга, работы с репозиториями и длинного контекста. Для локального ассистента программиста это уже не игрушечный размер. При этом с «младшими Qwen» надо быть аккуратнее: небольшие 0.6B, 1.7B, 4B, 8B и 14B относятся к линейке Qwen3, а не к Qwen3.6. Их тоже можно использовать локально, просто не нужно смешивать названия поколений в одну кашу.
LFM2.5-8B-A1B — другой показательный случай. Там ставка не на максимальный размер, а на пригодность для реальных on-device сценариев: быстрые ответы, работа с инструментами, небольшой активный объём параметров, запуск на потребительском железе. Именно такие модели важны для будущих локальных агентов. Не потому что они «умнее всех», а потому что их реально можно держать включёнными, дергать много раз в день и не превращать каждый запрос в ожидание у монитора.
HY-MT2 — хороший пример специализированной модели. Она не пытается быть универсальным собеседником обо всём на свете. Её задача — перевод. И в этом как раз есть здравый смысл: не всё должно быть одним большим чат-ботом. Иногда лучше взять узкую модель, которая хорошо делает конкретную работу, чем заставлять универсальную LLM изображать из себя переводчика, OCR, поисковик, кодера, психолога и бухгалтера одновременно.
Вообще, одна из главных ошибок в разговорах о локальных LLM — оценивать их только по принципу «насколько это похоже на последнюю облачную модель».
Для многих задач это неправильная метрика.
Если модель за 8B стабильно вытаскивает из 10 тысяч карточек товара название, цвет, размер и состав ткани, мне не так важно, что она хуже отвечает на философские вопросы. Если 1.8B модель хорошо переводит технические описания, мне не нужно, чтобы она рассуждала о будущем цивилизации. Если маленькая модель умеет быстро классифицировать входящие обращения, это уже полезно, даже если она не напишет великий роман.
Локальные модели надо оценивать не как «дешёвый ChatGPT», а как вычислительные модули.
Один модуль умеет переводить. Другой — выделять сущности. Третий — маршрутизировать запросы. Четвёртый — писать черновики. Пятый — работать с кодом. Шестой — вызывать инструменты.
В идеале локальный ИИ-ассистент вообще не обязан быть одной моделью. Наоборот, разумнее собрать систему из нескольких уровней. Маленькая модель быстро понимает тип задачи. Средняя модель делает основную работу. Большая локальная модель подключается для сложных случаев. Облачная модель используется только там, где действительно нужна максимальная мощность.
Это и есть нормальная гибридная схема.
Локально — всё, что часто, приватно, рутинно и дешево гоняется на своем железе. В облако — всё, что требует максимального качества, редкого сложного рассуждения или тяжёлой мультимодальности.
Границы применимости здесь довольно простые.
Локальная LLM хорошо подходит, когда данные чувствительные, задача повторяемая, качество можно проверить, а ошибка не приводит к катастрофе. Например, черновики, сортировка, извлечение данных, суммаризация, локальный поиск, технические подсказки, работа с личной базой знаний.
Локальная LLM хуже подходит, когда вам нужен гарантированно точный факт, актуальные новости, юридически значимый вывод, медицинское решение, финансовая рекомендация или сложный анализ, где ошибка выглядит убедительно и стоит дорого. Модель может отвечать уверенно даже тогда, когда несёт мусор. Локальность от этого не лечит. Галлюцинации не исчезают от того, что веса лежат на вашем SSD.
Отдельная иллюзия — длинный контекст.
Когда в карточке модели написано 128K или 256K токенов, это не значит, что можно бездумно закинуть туда пол-репозитория, три книги, историю переписки за год и получить идеальный ответ. Длинный контекст стоит памяти. Он замедляет обработку. Он может ухудшать внимание модели к нужным деталям. И он не заменяет нормальную архитектуру поиска, разбиения документов и проверки источников.
Для работы с документами обычно нужен RAG, нормальные чанки, метаданные, цитирование фрагментов и возможность вернуться к оригиналу. Просто «засунуть всё в промпт» — это типичный путь к дорогой и медленной каше.
То же самое с квантизацией. 4-bit модели сделали локальный запуск массово доступнее, но это не магия. Да, модель начинает помещаться туда, куда в BF16 она бы не влезла. Но вы платите качеством, иногда скоростью, иногда стабильностью. Плюс память нужна не только под веса модели, но и под KV-cache, контекст, бекенд, ОС и всё остальное, что у вас запущено. Поэтому фраза «31B запускается локально» без уточнения железа, кванта и контекста почти ничего не значит.
На практике граница выглядит примерно так.
Модели до 1–2B — это быстрые локальные утилиты. Маршрутизация, простая классификация, форматирование, короткие инструкции, иногда перевод и простая логика. Они хороши тем, что их можно вызывать часто и дешево.
4–8B — уже нормальный повседневный слой. Черновики, резюме, простая помощь с кодом, небольшие агенты, обработка текстов, быстрые локальные ассистенты. Здесь как раз интересны модели вроде LFM2.5-8B-A1B, Gemma 4 E4B или Qwen3 8B.
20–30B — это слой для более серьёзной работы. Код, длинные документы, более сложное рассуждение, локальные IDE-ассистенты, частичная замена облачной модели в рутинных сценариях. Сюда попадают Gemma 4 31B и Qwen3.6-27B. Но тут уже начинается разговор про железо, скорость, память и то, готовы ли вы вообще обслуживать такую систему.
MoE-модели вроде Gemma 4 26B A4B или Qwen3.6-35B-A3B интересны тем, что на каждый токен активируется только часть параметров. Это помогает со скоростью генерации. Но всю модель всё равно обычно нужно где-то держать в памяти. Поэтому «активных параметров меньше» не означает «запустится на калькуляторе».
Ещё одна важная граница — агентность.
Сейчас все любят слово «агент». Часто под ним подразумевается обычный чат-бот, которому дали возможность вызывать пару инструментов. Настоящая агентная система — это не просто модель с function calling. Это оркестрация: планирование, доступ к инструментам, память, проверки, ограничения, логи, откаты, права доступа, песочницы, тесты результата.
Локальная модель может быть частью такой системы. Иногда даже очень хорошей частью. Но если вы дали локальной LLM доступ к терминалу, файловой системе и браузеру, проблема уже не только в качестве модели. Проблема в том, что вы фактически дали вероятностной машине возможность действовать в вашей среде.
Для личного проекта это может быть нормально. Для продакшена без ограничений — сомнительно. Агент должен быть тупее в правах, чем кажется удобным. Иначе в какой-то момент он удобно удалит не ту папку, удобно перепишет не тот конфиг или удобно отправит не то сообщение.
Поэтому нормальная схема локального агента — это не «модель делает всё сама». Нормальная схема: модель предлагает, инструмент выполняет только разрешённые действия, система логирует, пользователь подтверждает опасные операции, результат проверяется отдельным шагом.
И вот тогда локальные LLM становятся действительно полезными.
Они могут работать рядом с вашими файлами. Они могут быть встроены в вашу систему. Они могут дергать локальные инструменты. Они могут обрабатывать приватные данные. Они могут стоить вам только железа и электричества. Они могут продолжать работать даже без доступа к API.
Но у них остаётся обычная цена: настройка, обслуживание, железо, память, скорость, качество, обновления, совместимость бекендов, странные баги шаблонов, разные форматы GGUF/MLX/ONNX, внезапно неработающий tool calling, кривая поддержка vision и всё то, что обычно начинается после фразы «да там просто поставить Ollama».
Поэтому мой вывод довольно приземлённый.
Локальные LLM стоит использовать там, где они дают конкретное инженерное преимущество: приватность, дешевую массовую обработку, низкую задержку, офлайн-режим, кастомную интеграцию или независимость от чужого API.
Их не стоит романтизировать. Их не стоит мерить только по бенчмаркам. Их не стоит ставить в задачи, где ошибка слишком дорогая. Их не стоит воспринимать как бесплатную копию топовых облачных моделей.
Самое интересное в локальных LLM сейчас не то, что они «догоняют ChatGPT». Интереснее другое: они становятся достаточно хорошими, чтобы исчезнуть в фоне.
Не как отдельный чатик, куда вы руками копируете текст. А как слой внутри обычных программ.
Почтовый клиент сам сортирует письма. Локальная база знаний сама находит нужный документ. IDE объясняет код без отправки репозитория наружу. Голосовой ассистент работает с файлами на компьютере. Магазин обрабатывает карточки товара локально. Переводчик сидит прямо на устройстве. Маленькая модель маршрутизирует задачи, большая подключается только когда нужно.
Вот это уже похоже на реальное применение, а не на очередную демонстрацию «смотрите, модель на ноутбуке написала стихотворение».
Локальные LLM не отменяют облачные модели. Они просто закрывают тот слой задач, где облако выглядит лишним посредником между вами и вашими собственными данными.