Можно ли собрать локальный Claude Code на одной видеокарте?

За последнее время я довольно много экспериментировал с локальными моделями и coding agents, и почти всегда всё упирается в один и тот же вопрос: насколько далеко вообще можно зайти без Claude, GPT и дорогой облачной инфраструктуры?

На этом фоне я наткнулся на интересный проект от UW–Madison — Efficient Coder.

Идея у него простая: собрать максимально сильного автономного coding agent, который работает на open-weight моделях и не требует огромного GPU-кластера.

То есть вместо привычного подхода «давайте возьмём модель ещё больше» здесь пытаются выяснить другое:

можно ли выжать хороший результат из относительно компактной модели за счёт того, как устроен сам агент?

Вот это мне в проекте понравилось больше всего.

Обычно обсуждение локальных LLM быстро скатывается в сравнение параметров: какая модель лучше, сколько у неё контекста, какой квант выбрать, сколько нужно VRAM.

Здесь же главный объект экспериментов — всё, что находится вокруг модели.

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

По сути, речь идёт уже не о простом чате с моделью, а о полноценном цикле:

получить задачу → изучить проект → изменить код → запустить → увидеть ошибку → исправить → проверить ещё раз.

И именно это сейчас отличает обычную LLM от нормального coding agent.

Для старта организаторы дают готовый baseline.

Можно подключить Ollama, локальную модель и сразу начать экспериментировать. В документации предлагают модели разного размера в зависимости от доступной видеопамяти.

То есть это не история из серии «исследователи что-то протестировали на восьми H100, а нам остаётся только посмотреть графики».

Проект можно скачать и попробовать дома.

И вот здесь становится особенно интересно.

Потому что даже если у вас модель заметно слабее Claude или GPT, это ещё не означает, что агент на её основе обязательно будет бесполезным.

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

По крайней мере именно эту гипотезу участники и пытаются проверить.

Для оценки используется Terminal-Bench 2.0.

Там агенту мало просто написать красивый ответ в чат.

Он получает рабочее окружение и должен реально выполнить задачу: открыть файлы, запускать команды, менять код, работать с терминалом и довести систему до состояния, при котором проходят тесты.

Это важное отличие.

Я вообще всё меньше доверяю benchmark'ам, где модель просто отвечает на вопросы. Для coding agents гораздо интереснее смотреть на то, может ли система сама довести задачу до конца.

В Efficient Coder агент работает внутри Docker-контейнера. Он может экспериментировать с окружением, что-то ломать, создавать файлы, запускать команды, а потом финальный результат проверяется автоматически.

То есть поведение уже довольно близко к тому, как сегодня работают Claude Code, Codex, OpenHands и другие агентные инструменты.

Допустим, модель получила задачу и ошиблась.

Что делать дальше?

Просто ещё раз отправить ей весь контекст?

Показать только ошибку?

Сначала попросить её составить новый план?

Дать отдельному агенту проверить изменения?

Сжать историю предыдущих действий?

Или вообще разделить работу между несколькими моделями: одна планирует, другая пишет код, третья проверяет?

Вот вокруг таких вещей и строится соревнование.

Причём разрешено использовать несколько моделей и даже делать fine-tuning, если решение можно воспроизвести.

Поэтому я бы смотрел на Efficient Coder не столько как на соревнование, сколько как на большой открытый эксперимент по архитектуре локальных coding agents.

Сейчас локальные LLM уже стали достаточно хорошими, чтобы писать код, разбирать проекты и пользоваться инструментами.

Но по ощущениям, главный прогресс дальше будет идти не только от новых моделей.

Очень многое начинает зависеть от того, как вокруг модели построен сам агент.

Например, вместо одного длинного диалога можно сделать систему, где агент сначала строит карту проекта, потом планирует изменения, отдельно запускает тесты, хранит краткую память о предыдущих попытках и только после этого снова обращается к модели.

И если такой подход позволит 20–30B модели нормально решать реальные задачи, это сильно изменит смысл локального ИИ.

Потому что тогда речь уже будет не про «у меня дома запущен чат с Qwen», а про:

«у меня дома работает автономный разработчик, которому можно отдать задачу и дождаться результата».

Вот это мне уже действительно интересно.

План у меня довольно простой.

Взять локальную coding-модель, подключить её к такому agent loop и посмотреть, насколько далеко она сможет зайти на обычном проекте.

Не написать одну функцию по промпту, а получить нормальную задачу уровня GitHub issue и пройти весь цикл самостоятельно: разобраться в коде, внести изменения, запустить тесты, увидеть проблему и исправить её.

Если получится хотя бы приблизиться к тому, как сейчас работают облачные coding agents, это будет очень хороший показатель.

Особенно учитывая, что всё можно гонять локально.

Сам проект здесь:

Efficient Coder на GitHub

Я регулярно ищу такие малоизвестные open-source проекты, локальные модели и инструменты для AI-разработки и стараюсь разбирать именно то, что можно реально запустить и попробовать самому.

Больше таких находок — в моём Telegram-канале «AI здорового человека».