Пользователь Reddit под ником prestodigitarium описал в r/LocalLLaMA, для чего ему нужны локальные модели. Короткий ответ: не как замена ChatGPT или Claude, а как дешёвый исполнительный слой под управлением коммерческих frontier-моделей. Локальная DeepSeek v4.1 Flash 1017 собирает информацию в вебе, пишет небольшие фрагменты кода по готовым спецификациям, фильтрует новостные ленты, ведёт краулер событий, записывает рабочие сессии и превращает голос в текст. Верхние модели ставят задачи и интегрируют результат. Обсуждение опубликовано 8 ноября 2026 года.
Сетап автора: DeepSeek v4.1 Flash 1017, запущенная через BRRR Fraser Price на четырёх RTX 6000 Blackwell. О скорости он говорит примерно 550 tps при c=1 и, по его памяти, пару тысяч при c=16. Цифры приведены по памяти и ничем не заверены, это оценка одного пользователя, а не независимый замер. Все сценарии ниже получены на этой конкретной конфигурации, переносить их на две потребительские карты без проверки нельзя.
Главный вывод автор формулирует сам: процесс держится на ручном управлении. Он признаёт, что упирается в себя, и хотел бы, чтобы модели делали больше полезной работы, пока он спит. Такое признание полезнее списка успехов: оно показывает, где сейчас проходит граница между усилением активного оператора и автономной системой.
Что именно запускает автор и как это меняет картину
Четыре RTX 6000 Blackwell - это серверная конфигурация, а не домашний ПК с одной видеокартой. Автор не приводит объём VRAM, размер модели или настройки квантизации, поэтому его цифры стоит читать как ориентир по порядку величин, а не как воспроизводимый бенчмарк. Запуск идёт через BRRR Fraser Price - узкий inference-рантайм, каких в 2026 году появилось несколько: они дают прирост на конкретной модели и конкретном железе, но требуют своей обвязки и хуже переносятся на другие сетапы. Разбор таких рантаймов и их компромиссов помогает понять, почему автор не взял llama.cpp или vLLM.
Сама модель тоже часть картины. DeepSeek в 2026 году обсуждают с оговорками: позиции в бенчмарках зависят от версии, контекстного окна и условий запуска. Отдельный разбор про DeepSeek и его место среди открытых моделей полезен тем, кто выбирает модель под похожий сетап.
Роль локальной модели: исполнитель, а не замена frontier-модели
Ключевая деталь, без которой все дальнейшие сценарии читаются неправильно: автор не отказывается от коммерческих моделей. Он разгружает их. Frontier-модели остаются оркестраторами, локальная модель берёт на себя рутинное исполнение. Такая схема отвечает на частый вопрос «зачем локальная LLM, если есть API»: она нужна не вместо API, а там, где вызов API стоит денег, а работа простая и объёмная.
Локальные веб-агенты: исследование по запросу frontier-моделей
Первый сценарий автор называет «скаутами». Коммерческая frontier-модель вызывает его локальных веб-агентов и отправляет их собирать материал. Инициатива идёт сверху: не локальная модель решает, что пора что-то изучить, а верхняя модель ставит задачу и получает результат.
Мотивация прямая. По словам автора, frontier-модели тратили бы огромное количество токенов на исследование относительно тривиальных вопросов. Локальный агент делает ту же работу без счёта за токены: считаются электричество и занятое железо. Это не автономный исследователь, а вызов по инициативе верхней модели.
Почему это экономит токены и время
Экономия складывается из разделения операций. Дорогие токены верхней модели уходят на постановку задачи, проверку и сборку вывода. Дешёвые локальные токены закрывают рутину: пройти по страницам, вытащить факты, отбросить мусор, вернуть конспект. Платная модель не читает десять страниц ради одной цитаты.
Точных цифр экономии автор не приводит, и подставлять их из головы не стоит. Эффект здесь качественный: часть нагрузки переезжает с платного API на собственные GPU, а верхняя модель тратит контекст на то, что действительно требует её качества.
Сборка кода по спецификациям: локальная модель как «каменщик»
Вторая схема повторяет первую, только вместо веба код. Frontier-модели описывают спецификации небольших фрагментов, локальная модель реализует их и отдаёт обратно, интеграцию выполняет верхняя модель. Автор называет это разделением на проектировщика и исполнителя.
Масштаб важно не преувеличивать. Речь о небольших фрагментах по готовому описанию, а не о проектировании системы и не о целых проектах. Разница между таким паттерном и полноценной автономной разработкой видна по признанию автора: несколько попыток построить «фабрику софта» не дали выдающегося результата. Сборка кирпичей по чертежу работает, стройка без прораба пока нет.
Разработчику эта логика знакома по связке «модель + harness»: чем яснее спецификация и уже шаг, тем предсказуемее результат. Разбор локального кодинга и критериев, по которым оценивают такие заявления даёт контекст, если хочется воспроизвести схему у себя.
Фильтрация Hacker News, YouTube и других сайтов
Дальше начинается бытовая часть. Hermes-агенты фильтруют Hacker News, YouTube и другие сайты, отбирая новости, которые автору было бы интересно читать. Его оценка: агенты удивительно хорошо угадывают, на что он обычно кликает. Это субъективное впечатление без измеренной точности, и воспринимать его стоит именно так.
Механика сценария простая: локальная модель читает заголовки и описания, оценивает их под конкретного человека и выдаёт короткий список. Качество зависит от того, насколько удачно настроены критерии отбора под личные интересы, и от объёма материала, который проходит через фильтр. Побочная выгода: история чтения и предпочтения не уходят во внешний сервис.
Краулер событий с еженедельной рассылкой топ-10
Самый законченный пример автоматизации в описанном наборе. Краулер оценивает каждое событие и раз в неделю отправляет семье письмо с топ-10. Об этом автор пишет прямо в стартовом посте.
Сценарий ценен форматом выхода: не чат, который надо открыть и о чём-то спросить, а письмо по расписанию с готовым списком. Такие задачи закрываются локальной моделью целиком, потому что критерий отбора формулируется один раз, а дальше работа повторяется. Автор не уточняет, какие именно события собираются и как устроена оценка, так что детали реализации придётся проектировать под себя.
Персональный ассистент, который помнит, где вы остановились
Ассистент записывает всё использование терминала, включая harnesses, и использование браузера. Каждое утро он присылает сводку о том, над чем автор работал, когда прервался накануне вечером, чтобы тот сразу вернулся в контекст. Задача знакомая каждому, кто вечером закрывает десяток вкладок и утром не помнит, зачем их открывал.
Это самый «личный» сценарий в списке. Запись терминальных и браузерных сессий означает, что модель видит команды, пути, названия проектов и содержимое страниц. Логика локального запуска подсказывает, что такие данные незачем отправлять в чужое облако, но автор не уточняет, где хранятся записи и не уходит ли часть сводки во внешние сервисы. Перед повторением стоит самому решить, готовы ли вы к постоянному логированию активности и как ограничить доступ к этим логам.
Локальное распознавание речи: самый недооценённый сценарий
Автор называет распознавание речи на локальных моделях революционным: по его словам, это намного быстрее набора текста даже для человека, который печатает быстро, а сами модели отвечают почти мгновенно. Конкретные модели он не называет, поэтому подбирать их придётся самостоятельно.
Для повторения этот сценарий проще остальных: не нужны агенты, оркестрация и вызовы frontier-моделей. Достаточно локального движка распознавания и привычки говорить вместо печати. Именно поэтому с него разумно начинать: результат заметен сразу, а цена ошибки минимальна.
Где подход упирается: ручное управление и «фабрика софта»
Честная часть поста важнее списка удачных задач. Автор пишет, что его использование локальных моделей зависит от него, ограничено им, и ему хотелось бы, чтобы модели делали больше полезной работы, пока он спит. Формулировка про «bottlenecked by me» из того же обсуждения точно описывает текущее состояние: локальный слой ускоряет исполнение, но не снимает с человека роль диспетчера.
Второе ограничение связано с автономностью. Несколько попыток построить «фабрику софта» не дали выдающегося результата. Причина видна из описанных сценариев: они хорошо работают там, где задача узкая, спецификация готова, а результат проверяется быстро. Как только цепочка удлиняется, растёт цена ошибки на каждом шаге и человек всё равно возвращается в цикл.
Отсюда практический вывод: локальные LLM сегодня усиливают активного оператора, а не заменяют сотрудника. Опыт людей, которые доводят такие схемы до результата, обычно строится вокруг мелких фаз с проверкой и роли человека на стыках. Разбор одного такого марафона с файловой памятью агента и машинной проверкой фаз показывает, сколько дисциплины требует подобная работа.
Что из этого опыта стоит перенять
Порядок освоения напрашивается по возрастанию сложности. Сначала распознавание речи и фильтрация новостей: минимум обвязки, понятный результат, данные остаются у вас. Потом связка «frontier-модель плюс локальный исполнитель» для веб-исследования и небольших фрагментов кода: платная модель ставит задачу и проверяет, локальная делает объёмную часть. Автономные агенты с записью сессий и еженедельными рассылками идут последними, когда есть инфраструктура для логов и привычка контролировать цепочку.
| Сценарий | Что делает локальная модель | Что остаётся человеку и frontier-модели |
|---|---|---|
| Веб-исследование | Собирает материал по вызову верхней модели | Постановка задачи, проверка, выводы |
| Фрагменты кода | Реализует небольшой фрагмент по спецификации | Спецификация и интеграция |
| Фильтрация новостей | Отбирает ссылки под интересы владельца | Настройка критериев, чтение |
| Краулер событий | Оценивает события, готовит топ-10 | Формат рассылки, проверка списка |
| Персональный ассистент | Пишет утреннюю сводку по сессиям | Политика логирования и доступа |
| Распознавание речи | Превращает голос в текст | Ничего сверх правки распознанного |
Про железо стоит сказать отдельно. Четыре RTX 6000 Blackwell и BRRR - это конфигурация одного пользователя с серверным бюджетом, а не минимальные требования. Автор не публиковал замеры, поэтому нельзя утверждать, что его схема воспроизведётся на двух картах. Разумнее проверить самый дешёвый сценарий из списка на том, что уже есть, и двигаться дальше по мере пользы.
Автор задал вопрос сообществу в формате «какую модель запускаю и что мне это даёт» именно потому, что конкретные описания полезнее общих рассуждений. Если у вас есть работающий сценарий, его стоит описать так же: модель, железо, задача, результат и то, что не получилось.