Локальные ИИ и агенты: что реально работает в 2025

Мы в ZUB-AI пересмотрели около часа свежих технических разборов на одну сквозную тему: как перестать быть просто пользователем чат-бота и начать управлять инструментом. Не «спросил — скопировал ответ», а «поставил задачу — получил результат прямо в проекте». Три материала легли в основу: один про локальные LLM на своём железе, второй про ИИ-агента для программирования, третий про встроенного агента в дизайн-редакторе.

▶ 08:47

Кому это полезно. Тем, кто автоматизирует часть своей работы и хочет понять две вещи: где заканчивается облачный ChatGPT и начинается что-то более приватное и управляемое, и стоит ли уже сейчас вкладываться в железо и настройку. Если вы гоняете скрипты для парсинга рыночных данных, чините код торговых ботов или собираете дашборды — тема прямо ваша.

Главный вывод одним предложением: полностью заменить топовые облачные модели локальными пока нельзя, но точечные задачи — автоматизации, обработку данных, правки в коде — уже реально закрывать бесплатно и приватно, а связка «модель + агент» меняет саму механику работы сильнее, чем прирост «интеллекта» самой модели.

Локальная модель — это не магия, а арифметика памяти

Первое, что стоит выбросить из головы: локальная модель ничему у вас не учится. Вы не тренируете нейросеть, задавая ей вопросы. Вы используете готовый «мозг» — этот процесс называется инференс (получение ответа от уже обученной модели). Он отличается от тренировки и файн-тюнинга (дообучения под задачу) тем, что не требует миллионных бюджетов и кластеров видеокарт. Инференс можно запустить дома.

Дальше начинается арифметика, и она честнее любого маркетинга. Модель — это гигантская матрица чисел, миллиарды параметров. Чтобы получать ответы с нормальной скоростью, эту матрицу нужно перемножать быстро. Обычный процессор (CPU) считает последовательно, как один кассир на весь супермаркет. GPU (графический процессор из видеокарты) имеет тысячи ядер, работающих параллельно — тысяча кассиров одновременно. На CPU модель тоже запустится, но ответа вы будете ждать мучительно долго.

Ключевой момент: модель должна целиком поместиться в VRAM (видеопамять, расположенную прямо рядом с GPU). Не на жёсткий диск, не в оперативку — именно в видеопамять. Иначе всё упрётся в скорость чтения, и смысл теряется.

Базовое правило, которое стоит запомнить наизусть:

Чтобы запустить модель целиком, нужно примерно вдвое больше видеопамяти, чем у неё параметров.

Модель на 70 миллиардов параметров в полной точности займёт около 140 ГБ VRAM. Цифра, от которой у большинства домашних сборок случается инфаркт. И вот тут в игру входит квантизация.

Квантизация: как сжать модель без потери разума

По умолчанию каждое число в модели хранится в 16 битах — это как фотография в RAW-формате, максимум деталей и веса. Квантизация округляет числа, понижая точность до 8, 4 или 3 бит. Модель худеет, скорость растёт, а «интеллект» просаживается — вопрос лишь в том, насколько.

Практика из разборов сходится на цифре: 4 бита (q4) — рабочий компромисс для большинства задач. Три бита и ниже — уже перебор, качество падает заметно, и экономия памяти того не стоит.

Смотрите, как это выглядит на конкретных числах (по таблице проекта Unsloth):

• Модель на 31 млрд параметров в полной квантизации — 62 ГБ VRAM
• Она же при 8 битах — 36 ГБ
• Она же при 4 битах — около 17–20 ГБ

Разница в три раза. Именно квантизация превращает «нужен сервер за миллион» в «влезет на приличную игровую видеокарту».

Отдельная статья расходов — KV-Cache (кэш, хранящий контекст диалога: каждый ваш промпт и каждый ответ модели). Чем длиннее разговор и больше контекстное окно, тем прожорливее этот кэш. Наглядный пример на модели 9 млрд параметров в q4:

• Базово — 5,8 ГБ
• С контекстом 8 тысяч токенов — 6,2 ГБ
• С 32 тысячами — почти 7 ГБ
• Со 128 тысячами — уже 10 ГБ

То есть длинный контекст может удвоить требования к памяти. Планируя железо, закладывайте не только вес модели, но и запас под контекст. В LM Studio для этого есть удобный ползунок, который сразу показывает нужный объём под KV-cache.

Ещё один нюанс архитектуры. Модели типа Mixture of Experts (микс экспертов, MoE) с малым числом активных параметров работают заметно быстрее плотных (dense) моделей того же размера. Внутри у них много «специалистов», но на каждый запрос активируется только часть — отсюда прирост скорости.

Какое железо реально нужно

Разберём по пунктам, без иллюзий. Золотой стандарт — NVIDIA из-за технологии CUDA, под которую написан почти весь софт. Работает без танцев с бубном, но платите за удобство.

▶ 28:06

• RTX 4090 — 24 ГБ, самый ходовой вариант. Новая 220–300 тысяч, б/у от 160.
• RTX 5090 — 32 ГБ, вдвое быстрее 4090, цена уходит за 350–450 тысяч.

AMD даёт те же объёмы памяти дешевле. Radeon RX 7900 XTX — 24 ГБ за 70–120 тысяч. Минус в софте: вместо CUDA технология ROCm, не всё запускается гладко, придётся гуглить и патчить. Экономия есть, но платите временем и нервами.

Отдельная категория — устройства с унифицированной памятью, где CPU и GPU делят один общий пул:

• Mac Studio — лидер по объёму. M4 Max от 300 тысяч, версия на 128 ГБ — 430–510 тысяч, M3 Ultra тянет до 512 ГБ в топовых конфигах.
• AMD Strix Halo (Ryzen AI Max+ 395) — 128 ГБ, открытая платформа, мини-ПК от 180 до 490 тысяч.
• NVIDIA DGX Spark — 128 ГБ, полный CUDA-стек, заявлено до 200 млрд параметров, от 519 тысяч и попробуй найди в наличии.

Для новичков хватит и макбука: M4 Pro на 24 ГБ около 200 тысяч, на 48 ГБ — от 300. На таком железе уже крутятся модели среднего размера с адекватной скоростью.

Есть и четвёртый путь — аренда облачного GPU. Не покупать ничего, а брать мощности в аренду, объединять видеокарты в кластер и запускать хоть 700-миллиардные модели на железе уровня H200 (141 ГБ). Плюсы очевидны: топовые чипы без забот об охлаждении и электричестве. Минус тоже: данные уходят на чужой сервер, это уже не локальное приватное решение. Хотя для проектов с персданными есть инфраструктура, соответствующая требованиям ЦБ РФ — компромисс возможен.

Где считать и что скачивать

Прежде чем что-то покупать, посчитайте. Онлайн-калькуляторы и таблицы (Unsloth) показывают требования по памяти, а на Hugging Face можно добавить своё устройство и сразу увидеть, влезет модель или нет.

Скачиваете модель обычно в формате GGUF — популярный формат для квантизованных моделей, запускается через фреймворк llama.cpp и приложения поверх него: Ollama и LM Studio. Для Mac есть ещё формат MLX. Небольшой лайфхак из разборов: если в названии модели фигурирует Unsloth — это команда, которая делает качественные квантизованные версии, хороший знак.

Что показали тесты моделей

Самая ценная часть — не теория, а живые прогоны. В одном из разборов модели разбили на пять групп (крошки, малые, средние, большие, гиганты) и дали всем одну задачу: прочитать список навыков, вызвать скрипты для сбора статистики с YouTube и построить HTML-дашборд. Контекст 64 тысячи токенов, референс — топовая open source модель GLM 5.2, метрика — агрегированный «индекс интеллекта».

Что получилось:

• Qwen 3,5 (4 млрд) — самая мелкая. 6 ГБ VRAM, 24 токена/сек, индекс интеллекта всего 20. Дашборд простенький, без анализа, но все инструменты вызвала честно.
• Ornys 1.0 (9 млрд) — 34 токена/сек, 8,3 ГБ в пике. Результат «не отвратительный», но с инструкциями работает слабовато.
• Gemma (12 млрд) — через агента не запустилась вовсе, хотя внутри LM Studio жила нормально.
• GPT-OSS 120B — запущена в облаке, 90–110 токенов/сек на H200. И при этом дашборд позорный, уступает моделям втрое меньше. Возраст модели решает больше, чем размер.
• Qwen 3 (27 млрд) — на RTX 4090, 44 токена/сек, 21 ГБ VRAM, индекс интеллекта 37 — второе место. Хороший вариативный результат.
• Ornys (35 млрд) — самая свежая, 166 токенов/сек, абсолютный рекорд скорости, 22 ГБ. Сильные показатели на бенчмарках кода и терминала.

Что мы вычитали из этих цифр. Размер модели — не главный предиктор качества. Свежая 27-миллиардная уделывает старую 120-миллиардную в одну калитку. Дата релиза и архитектура важнее числа параметров. Это хорошая новость для тех, у кого «всего» 24 ГБ VRAM: гнаться за гигантами не обязательно.

Честный итог этого блока: полноценно заменить подписки на ChatGPT и Claude локальными моделями пока нельзя. От крошек до средних они заметно проигрывают топовым решениям. Но несложные автоматизации, категоризацию данных, точечные правки в коде — уже закрывают. И прогноз оптимистичный: через пару лет маленькие open source модели вполне могут дотянуться до нынешних топовых проприетарных.

Агент против чата: в чём реальная разница

Локальная модель — это половина истории. Вторая половина интереснее: что вы с этой моделью делаете. И тут в свежих разборах чётко проступает разграничение между обычной нейросетью и ИИ-агентом.

Обычный чат работает по замкнутому кругу боли. Вы задаёте вопрос — получаете ответ с куском кода — копируете его в проект — запускаете — ловите ошибку — копируете ошибку обратно в чат — и всё по новой. А если вы сами что-то поправили в коде, а потом задали новый вопрос, модель отвечает в контексте старой версии. Приходится заново всё объяснять. Долго, муторно, теряется контекст.

Агент рвёт этот круг. Он подключается напрямую к проекту, видит все файлы, держит контекст, создаёт и правит файлы сам. Вы не копируете код — он появляется в проекте. Ошибка возникла — агент видит структуру и понимает, где чинить. Плюс агенты умеют то, чего чат не умеет в принципе:

• планировать задачу и разбивать её на пункты (декомпозиция);
• выполнять шаги по очереди или параллельно;
• подключаться к браузеру, к файловой системе, к внешним сервисам вроде Telegram или заметочных приложений.

Нейросеть перестаёт просто отвечать — она выстраивает стратегию и выполняет её пошагово. Разница как между советчиком и исполнителем.

Как это выглядит на практике: агент для кода

В одном из разборов подробно показан открытый бесплатный агент для программирования — назовём его инструментом класса «терминальный агент». Что он умеет из коробки:

• поддержка около 100 провайдеров моделей — облачные, бесплатные, локальные через Ollama и LM Studio;
• несколько встроенных агентов под разные роли;
• MCP, скиллы, тонкая настройка.

Ключевая механика — два режима, переключаемых по клавише Tab:

1. Plan — агент анализирует проект и составляет пошаговый план с описанием. План можно перечитать и отредактировать до запуска.
2. Build — выполняет утверждённый план шаг за шагом, создавая файлы прямо в проекте.

Живой пример из разбора: создание игры с нуля на бесплатной модели. Создаётся папка, запускается агент, переключается на Plan — тот выкатывает план: игровой процесс, структура файлов, логика игрока, платформы. План правится, переключаемся на Build, Enter — и файлы начинают появляться в проекте сами. Ничего не копируется руками. В итоге игра получилась плавной, с анимацией и персонажем в стиле Super Mario. На бесплатной модели.

▶ 10:08

Отдельно про управление стилем через файл AGENTS.md. В него прописываются правила проекта. Типичная боль: нейросеть генерирует разные страницы в разных стилях. Решение — правило «всегда соблюдать интерфейс из такого-то файла». И агент перестаёт заниматься самодеятельностью.

Про безопасность, потому что это не мелочь. Агент, имеющий доступ к файловой системе, при галлюцинации способен снести проект или отформатировать диск. Поэтому:

• любое редактирование требует подтверждения;
• на bash-команды запрашивается разрешение (а на безобидный просмотр списка файлов — выдаётся автоматически);
• не открывайте агента в корне системы;
• держите git и делайте бэкапы.

MCP (Model Context Protocol) — протокол, через который модель общается с внешними сервисами. Показательный кейс: подключаете автоматизированный браузер (аналог Selenium) и управляете им обычным языком. «Зайди на сайт, собери объявления, запиши в JSON» — и агент это делает. Для трейдера, который парсит данные с бирж или новостных лент, механика прямо на поверхности лежит.

Скиллы (skills) — готовые блоки поведения, которые подкладываются в папку проекта и расширяют возможности агента под конкретные задачи. Копируете, вставляете, агент подхватывает.

▶ 01:32

Для кода в разборе рекомендуют модель Deepseek — она заточена под программирование сильнее универсальных. И запускать агента можно где угодно: в терминале, в веб-версии на localhost (управляй с телефона и планшета из локальной сети), в десктопном интерфейсе или как плагин в VS Code, Cursor, Zed.

Агент внутри инструмента: пример из дизайна

Третий разбор показывает ту же идею с другого угла — агент, встроенный прямо в рабочий инструмент. Речь про Figma Agent, ИИ-чат внутри дизайн-редактора. Логика та же, что у кодового агента: пишешь запрос — ждёшь — получаешь результат прямо в рабочей области. Пока в бете, а значит бесплатно и без сжигания кредитов, но с оговоркой — глючит и ошибается.

Что тут важно для нашей темы — не про дизайн как таковой, а про паттерн использования. Главная ценность агента оказалась не в генерации «с нуля», а в автоматизации рутины:

▶ 10:58

• замена текстов пачкой;
• подбор и генерация изображений по смыслу заголовков;
• создание адаптивных версий под разные разрешения (960, 768, 480, 360 — за пару-тройку минут);
• подготовка спецификаций;
• переключение тем оформления.

И вот тут всплывает урок, который бьёт по всем трём материалам сразу: формулировка решает всё. Команда «пересобери» была понята буквально — агент просто перекомпоновал элементы, не тронув дизайн. А «измени дизайн блока» дало осмысленный результат. Агент выполняет ровно то, что написано, а не то, что вы имели в виду.

Ещё пара наблюдений, которые переносятся на любого агента:

• работайте на копии. Отмена действий не всегда возвращает всё как было. Оригинал должен оставаться нетронутым — прямая параллель с бэкапами и git в кодовом агенте.
• агент понимает контекст среды. Если шрифт не подгружен агенту — он не сработает корректно, подставит похожий и исказит макет. Всегда проверяйте, что у агента есть доступ ко всему нужному.
• результат неоднородный. На мелких задачах агент хорош: подправит отступы, уголки, аккуратно соберёт компонент. На крупных перестройках что-то «разваливается», приходится добивать руками.

И честный тезис, общий для всех разборов: агент не заменит опытного специалиста, который видит, где результат хорош, а где мусор. Но он снимает всю «черняжку» — скучную техническую работу — и вполне заменяет новичков, которые делают ту же рутину дольше и хуже.

Что делать прямо сейчас: чек-лист

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

Трек 1. Запустить локальную модель

1. Разберитесь с терминами: инференс, VRAM, квантизация, KV-cache. Без этого будете тыкаться вслепую.
2. Посчитайте свой лимит памяти через калькулятор Unsloth или карточку устройства на Hugging Face.
3. Выберите модель и квантизацию под своё железо. Ориентир — q4, свежий релиз, размер под ваш объём VRAM с запасом на контекст.
4. Установите LM Studio (проще для старта) или Ollama.
5. Скачайте модель в формате GGUF (или MLX для Mac), запустите, выставьте ползунок KV-cache под свои задачи.
6. Прогоните на реальной задаче, а не на «расскажи анекдот». Категоризация данных, разбор логов, правка скрипта — то, что вы делаете каждый день.

Трек 2. Подключить агента

▶ 04:02

1. Поставьте кодового агента (через CURL, NPM, brew — что удобнее вашей системе).
2. Подключите модель: облачную по API либо локальную через Ollama/LM Studio командой connect.
3. Сразу настройте безопасность: подтверждение на редактирование и bash-команды. Не запускайте в корне системы. Включите git.
4. Освойте цикл Plan → проверка плана → Build. Не пропускайте фазу планирования — там ловятся кривые задачи до того, как агент наломает дров.
5. Пропишите правила в AGENTS.md, чтобы агент не занимался творчеством там, где нужна дисциплина.
6. Подключите MCP под свою задачу — браузер для парсинга, файловую систему, нужный сервис.
7. Первый серьёзный прогон делайте на копии проекта.

Начните с малого. Одна автоматизация, которую вы делаете руками каждую неделю. Переложите её на связку «локальная модель + агент» и замерьте, сколько времени сэкономили. Это честнее любого бенчмарка.

Что мы заметили

Когда собираешь три разбора в одну картину, вылезают вещи, которых в отдельном ролике не видно.

Где всё сходится. Три материала независимо приходят к одной формуле: агент — исполнитель, человек — постановщик и контролёр. Никто не обещает «нажми кнопку и получи готовое». Везде подчёркивается, что результат надо проверять, что агент понимает команды буквально и что точность формулировки прямо определяет качество. Это редкое единодушие в нише, где обычно все продают волшебство.

Второе общее место — безопасность и обратимость. Работа на копии, бэкапы, git, подтверждение опасных операций. Как только модель получает руки (доступ к файлам, к системе, к браузеру), цена ошибки растёт, и все разборы это проговаривают.

Где подходы расходятся. Тут интереснее. Просматриваются два взгляда на то, где должен жить ИИ.

Подход А — приватность и контроль. Ставка на локальные модели: свои данные не уходят наружу, платите один раз за железо, работаете офлайн. Плата за это — компромисс по качеству и возня с настройкой. Более консервативный, «инженерный» взгляд: лучше медленнее и своё, чем удобно и в чужом облаке.

Подход Б — удобство и мощность. Ставка на лучшую доступную модель через агента, неважно, локальную или облачную. Здесь приоритет — скорость получения результата и качество, а приватность решается точечно (проверенная инфраструктура, прокси). Прагматичный взгляд: инструмент должен работать, а где крутится модель — вопрос второй.

Забавно, что эти подходы не воюют, а склеиваются. Кодовый агент спокойно подключает и локальную модель через Ollama, и облачную по API. То есть можно быть на подходе А для чувствительных задач и на подходе Б для остального — в рамках одного инструмента.

**