"What I cannot create I do not understand" (c) Richard Feynman

Решил провести небольшой эксперимент чтобы узнать:

может ли кодовый агент создать кодовый агент?

Если кратко, то да, может, но обо всём по порядку.

В качестве кодогенератора взял Cursor, но не простой, а используя модельку Sonnet 4.6 от Antropic, при этом, поскольку Claude Code мне так и не удалось настроить нормально, пришлось юзать модельку через API.

Заранее написал и предоставил агенту подробные спецификации по разработке кодового агента, агент этот должен собираться в один бинарник (да да, выбрал golang), должен уметь работать в формате Agent Client Protocol (ACP) агента, приложил ссылки на документацию, спецификации ACP, примеры того как работает Cursor, Codex и Claude Code, информацию о том как работать со скилами и MCP-серверами, плюс информацию о разных протоколах общения с моделями (OpenAI, Antripic, Ollama, OpenAI-like) и что мне нужен агент способный работать в режиме агента и в режиме планировщика (два моих любимых режима), плюс нужен визард конфига для первичной настройки.

Флоу стандартный BDD, сначала модель должна изучить все документы что я предоставил, потом синтезировать спецификации того, что конкретно она будет делать, потом по слоям создавать решение, сначала тесты, потом класс и так далее. В финале она должна убедиться, что полученное решение проходит все тесты, собирается по инструкции и что его можно по ACP использовать. Моделька соннет 4.6 где-то полчаса пилила проект, составил документацию хорошую. потом итеративно реализовала код. Отскакивая в сторону могу сказать, что качество кода для one-shot в целом очень приемлемое, понимаю почему людям так нравится клод код и эти модельки.

Далее я попробовал через плагин obsidian-agent-client для Obsidian настроить созданный мой агент и о чудо, он работает, хотя конечно у меня есть вопросики к интерфейсу ACP-клиента в Obsidian (форкну@пофикшу, ага), но это пока что мелочи.

Исходники Coddy Agent тут: https://github.com/coddy-project/coddy-agent

Кстати, поскольку судьба Телеграм неизвестна, на всякий случай, чтобы не потерять связь, завёл страничку на Бусти:
https://boosty.to/evilfreelancer

Планирую там публиковать посты про внутрянку проектов, лонгриды, которые не попадают в формат телеги, размышления на разные темы, ну и анонсы проектов для тех кому будет интересно принять участие в тестировании новинок.

Проблема долговременной памяти чатов

Хоть я и считаю себя сторонником памяти агентных систем, даже большой пост на эту тему писал, но работая с чатами в которых есть память истории всех сообщений периодически ловлю себя на мысли, что надо напилить какой-нибудь пост на тему того, что память эта частенько работает плохо, вносит искажения в ответы модели и единственный годный режим её работы это "off", то есть отключена.

Пока ещё не придумал как сделать долговременную память хорошо, самое удачное решение на данный момент это кажется концепция которую я условно назвал "долговременная доменная память" (LDM), постараюсь кратко её описать, представим что мы создали Project в ChatGPT, это такая группа чатов, в которую мы закидываем файлы, промты, там же все чаты находятся, вот память в таком компактном домене была к месту.

Развивая эту мысль было бы удобно связать домены памяти, и скажем когда я работаю с доменом спецификаций некоего проекта я мог бы дать доступ к домену с нормативами от ИБ и или скажем домену оформления схем данных, при информационные потоки между доменами чтобы были однонаправленные, типа отсюда сюда я могу запросить память, а в другую сторону не могу.

Проще всего описать это в формате графа, где синие узлы это группы, а серые это чаты, чаты в пределах своего домена и в пределах доменов в которые есть доступ могут искать данные, но в других нет.

Ловите мой новый пост на Бусти, в нём я рассказываю про модельку ruGPT3XL на 1.3B, которую мне удалось отреставрировать и заставить работать на современном железе.

upd. Пост на бусти так как ещё не всё готово, но всех кому интересно приглашаю принять участие в тестировании.

https://github.com/ggml-org/llama.cpp/pull/21011

Смерджили

Встречайте мой новый пост "Реставрация ruGPT-3 XL или как я вернул к жизни забытую русскую языковую модель" на Хабр, в нём я подробно рассказал о том как была реализована конвертация, как проводилось её тестирование, как запустить локально, как конвертировать в GGUF.

А вот ссылочки:
- evilfreelancer/ruGPT3XL - сконвертированная модель в формате HuggingFace (safetensors)
- evilfreelancer/ruGPT3XL-GGUF - квантизированные GGUF-веса для llama.cpp и Ollama
- evilfreelancer/rugpt3 - GGUF загруженные на Ollama
- EvilFreelancer/rugpt3xl-convert - исходники скриптов конвертации

Выгрузить модель на HuggingFace не так-то просто

Конвертировал тут новинку chromadb/context-1 в mxfp4 формат и пытаюсь загрузить веса на HuggingFace, но по какой-то причине huggingface-cli перестал подхватывать переменные прокси, в результате чего из моего контура запросы не уходят, пришлось лезть в исходники и оказалось, что авторы HF добавили в свой тул хранилища типа Xet включенные по умолчанию, а эта штука не использует httpx и как следствие игнорирует настройки прокси.

Короче чтобы решить эту проблему и из рабочего контура подключиться к проксику надо вырубить Xet переменной HF_HUB_DISABLE_XET, а дальше передать проксики и команду:

HF_HUB_DISABLE_XET=1 \
ALL_PROXY=socks5://192.168.1.21:1080 \
HTTPS_PROXY=socks5://192.168.1.21:1080 \
HTTP_PROXY=socks5://192.168.1.21:1080 \
huggingface-cli upload evilfreelancer/context-1-mxfp4 ./context-1-mxfp4 . --repo-type model

После этого загрузка начала работать.

Размышлял о памяти нейросетей и очень захотелось перечитать труд Марвина Мински про фреймы знаний.

Конвертация Chroma Context-1 в MXFP4 для домашней 4090

Позавчера Chroma выкатила техрепорт по своей модельке chromadb/context-1, прочёл я его сегодня и был крайне впечатлен.

Это 20B параметров, MoE-архитектура на базе openai/gpt-oss-20b, модель натренирована на агентный поиск, делает декомпозицию сложных запросов на подзапросы, выполнняет итеративный поиск по корпусу документов, и самое интересное - self-editing context, когда модель сама решает какие из найденных документов оставить, а какие выкинуть чтобы не засорять контекстное окно. На бенчмарках показывает результаты сопоставимые с топовыми LLM при скорости как у gpt-oss-20b.

Естественно, захотелось потрогать руками, но... модель выложена в BF16, а это 39 ГБ только веса, ну а моя 4090 хоть и прокачана до 48 ГБ VRAM, но 39 ГБ чистых весов + KV-кеш + накладные расходы CUDA в неё не влезут, нужно минимум ~45-50 ГБ чтобы хоть что-то сгенерировать с минимальным контекстом, но нужен не минимальный, а хотя бы 30-60к токенов, агенты же.

Что делать? Смотрю на оригинальную gpt-oss-20b от OpenAI, она в формате MXFP4, это Microscaling FP4, хитрый 4-битный формат, где каждый вес хранится как E2M1 (2 бита экспонента, 1 бит мантиссы), а группа из 32 весов делит общий 8-битный масштаб (E8M0), нативно поддерживается в vLLM через Marlin-ядра и должно отлично работать на RTX 50xx серии, в таком формате модель занимает ~14 ГБ, на мою 4090 влезает с запасом.

Сформировал спеки для кодового агента в Cursor, говорю мол вот тебе веса модели gpt-oss-20b как референс, вот спецификация по методам сжатия MXFP4, вот веса модели context-1 в BF16 которую надо конвертировать, вот docker-compose.yaml с vLLM 0.18.0 на которой агент должен проверять модель.

Задача написать скрипт конвертации, конвертировать модель, запустить в vLLM, убедиться по HTTP что приходят адекватные ответы.

Агент написал скрипт, который читает safetensors, для MoE-экспертов (gate_up_proj и down_proj) транспонирует веса в layout который ожидает vLLM, квантует и пакует всё в MXFP4, по аналогии с gpt-oss-20b, а слои внимания, роутера и эмбеддингов копируются как есть в BF16. В результате 39 ГБ превращаются в ~14 ГБ.

Запустил на vLLM, всё работает, reasoning что-то там рефлексирует, ответы вроде адекватные, но при тестировании tool calling (function calling) выяснилась забавная штука - модель при вызове инструментов валится с ошибкой:

openai_harmony.HarmonyError: Unexpected token 12606 while expecting start token 200006

Покопавшись в конфигах gpt-oss-20b обнаружил, что в generation_config.json модели отсутствует токен <|call|> (id 200012) в списке eos_token_id, из-за этого модель не останавливает генерацию после вызова tool call и harmony ломается. По сути баг в vLLM, но фикс элементарный, добавить 200012 в eos_token_id в generation_config.json модели, после этого и обычный чат и tool calling заработали как надо.

Создал PR с фиксом в трекере оригинальной модели.

Ну а квантованную в MXFP4 версию загрузил на HuggingFace: evilfreelancer/context-1-mxfp4

PS. Поднял её на домашней видяшке и сделал доступной через мою апишку, пример как заюзать через openai-клиент добавил в комментарии.

Мой третий PR в llama.cpp

По совету хабровчанина внёс правки в код класса модели чтобы она обучалась без ошибок, проблема появилась после фикса Sparse Attention, надо было мне чуть дотошнее всё проверить.

Вдобавок ко всему по рекомендации от того же пользователя добавил в модель поддержку Triton, в результате чего на динамическом графе модели удалось достигнуть прироста в скорости инференса до 40%, а если выполнить torch.compile то и все 50% прирост.

Код класса модели тут: modeling_rugpt3xl.py
Подробнее про SDPA и бенчмаркинг тут: Training throughput (SDPA and Inductor)