Кстати, поскольку судьба Телеграм неизвестна, на всякий случай, чтобы не потерять связь, завёл страничку на Бусти:
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)

ACPBox - что обновилось за последние коммиты

Пока ковырялся в агентных интеграциях, довел ACPBox до состояния когда его реально удобно поднимать как универсальный OpenAI-совместимый шлюз поверх ACP агентов.
- Добавил вдобавок к OpenCode и Cursor поддержку Claude и Codex в контейнере
- Установка агентов перенесена в runtime, раньше я думал что логичнее будет ставить их на этапе сборки, это норм когда агент один, но когда их четыре... при помощи переменной AGENTS в environment можно перечислить через запятую список нужных агентов, чтобы лишнее не ставить, по дефолту ставится OpenCode
- Единый префикс ACPBOX_ в env для настроек приложения
- Добавил GitHub Actions для публикации Docker образа по тегам, улучшил публикацию в PyPI и связал tagging workflow с публикациями

Минимальная конфигурация для запуска

Такой docker-compose.yaml понадобится чтобы запустить агента OpenCode в формате ACPBox:

services:
  acpbox:
    restart: unless-stopped
    image: evilfreelancer/acpbox:latest
    environment:
      - ACPBOX_ACP_COMMAND=["opencode","acp","--log-level","ERROR"]
      - ACPBOX_ACP_WORKSPACE=/workspace
      - AGENTS=opencode
    ports:
      - "8080:8080"
    volumes:
      - ./workspace:/workspace
      - ./opencode.json:/home/user/.config/opencode/opencode.json:ro

Конфиг OpenCode кладём в папку рядом с docker-compose.yaml, а вот его содержимое:

{
  "$schema": "https://opencode.ai/config.json",
  "model": "rpa/gpt-oss:20b",
  "provider": {
    "rpa": {
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "https://api.rpa.icu",
        "apiKey": "https://t.me/evilfreelancer"
      },
      "models": {
        "gpt-oss:20b": {
          "tool_call": true
        }
      }
    }
  }
}

Исходники тут: https://github.com/EvilFreelancer/acpbox
PyPi пакет: https://pypi.org/project/acpbox/
Docker-образ тут: https://hub.docker.com/r/evilfreelancer/acpbox

Всех с праздником!

Zloibit, pimp my LLM

Запостил на Boosty небольшой тизер публикации на Хабр про увеличение контекста у модели ruGPT3XL с 2k до 8k токенов, моделька уже лежит на HF вот тут:

https://huggingface.co/evilfreelancer/ruGPT3XL-8k

Вечерняя мудрость:

Использование термина агентский вместо агентный в контексте ИИ агентов - маркер дилетанта