hermes-hub/agents/inbox/2026-08-31-A44-restore-server-and-swap.md
Hermes Team 8b67f0dadb docs(agents): вернуть в репозиторий постановки A42-A56 и отчёт A30
Тринадцать файлов существовали только на диске ПК владельца, в рабочей
копии, отставшей от origin/main на 122 коммита. Их реализация и тесты
давно влиты: tests/test_a42_provider_connect.py,
test_a49_subagents_skills_memory.py, test_a51_hub_controls_hermes.py,
test_a52_local_models_supervisor_dual.py, test_a55_account_connection.py,
test_a56_context_compression.py и другие. Постановок, объясняющих, что
эти тесты обязаны доказывать, в репозитории не было.

Правило записано в agents/AGENTS.md: задание живёт в репозитории, а не в
переписке и не в личных папках на диске.

A48, A50 и A54 не переносятся: они уже есть на origin под другими именами,
содержимое совпадает с точностью до перевода строки в конце файла.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-03 18:16:35 +07:00

14 KiB
Raw Blame History

Задание A44: вернуть кодер в строй, поставить llama-swap, поправить отчёт A40

Дата поступления

2026-08-31

База

Ветка A40 (origin/antigravity/a40-benchmark-redo, d545252) — правки отчёта ложатся туда же, где он живёт.

git fetch origin --prune
git checkout -b antigravity/a44-restore-server origin/antigravity/a40-benchmark-redo
git merge origin/main   # ветка A40 отстала: в main уже A41 и правки ревьюера

В main напрямую не пушить.

Порядок исполнения

Два прохода: Flash исполняет, Pro проводит аудит. Пункт P0-5 написан для аудитора.

Задание по коду и серверу. Вёрстка — A43, провайдеры — A42, туда не залезать.


Что признано и переделке не подлежит

Ревьюер проверил A40 исполнением на сервере. Проверка таблицы пройдена:

все семь файлов GGUF существуют по указанным путям
размеры совпадают с отчётом ДО БАЙТА (stat -c %s по каждому)
sha256 первых 64 МБ granite-4.2 пересчитана независимо — совпала:
  f155ab58fe3ff46c4daa7d65633347da343143771238ddf63ecba25b8e10a06d
DeepSeek-Coder-V2-Lite и Phi-4, выдуманные в A38, действительно скачаны
  и измерены; прежние числа отозваны

Это хорошая работа, и требование P0-1 из A40 выполнено. Стенд, набор задач и таблицу не переделывать.

Претензии ниже касаются состояния сервера и двух столбцов отчёта.


Что сломано — проверено ревьюером

Кодер владельца не запущен как служба

systemctl is-active qwen-coder        →  inactive
systemctl show qwen-coder SubState    →  dead

порт 8081 при этом отвечает: его обслуживает процесс, поднятый ВРУЧНУЮ
  PID 2713480, ELAPSED 07:50 на момент проверки
  /home/ochenstarik/llama.cpp/build/bin/llama-server -m .../Qwen3.8-27B-Q4_K_M.gguf

Перезагрузка сервера или падение процесса — и локального кодера нет. Владелец пользуется этой машиной ежедневно.

Контекст урезан вшестеро против штатного

/etc/systemd/system/qwen-coder.service  ExecStart ... -c 196608
фактически запущено                                  -c 32768

У Hermes порог 64К контекста: при 32768 модель не проходит отбор, и локальный кодер бесполезен. Это ровно та проблема, ради которой делалось A39.

Отсюда же расхождение скоростей в отчёте

Отчёт даёт Qwen3.8-27B 30,31 ток/с. Независимый замер ревьюера на штатной конфигурации давал 13,6 ток/с. Разницу объясняет контекст: замеры шли на 32К, служба владельца работает на 192К.

В строке «Условия измерений» перечислены квантование, -ngl 99, --flash-attn on, --cache-type-k/v q8_0, --parallel 1, --temp 0.2 — и размер контекста не указан вовсе. Без него числа нельзя соотнести с реальной установкой владельца, а именно ради этого отчёт и делался.

Столбец VRAM измеряет не то

отчёт:  Qwen3 4B Instruct 2507 → 24 894 МиБ
живой замер того же процесса:
  nvidia-smi --query-compute-apps=pid,used_memory
  1570163  5 440 МиБ  llama-server ... Qwen3-4B ...

В отчёт попала общая занятость карты вместе с соседней резидентной моделью, а не потребление самого процесса. Отсюда абсурд: 4B «занимает» 24 894 МиБ, а 27B — 24 696 МиБ. Для планирования «сколько моделей поместится» столбец непригоден, а владелец задаёт именно этот вопрос.

llama-swap не установлен

command -v llama-swap        → не найден
systemctl is-active llama-swap → inactive

Установка llama-swap была критерием приёмки 2 в A38 и не выполнена ни там, ни здесь.

Мусор от прерванной закачки

/srv/ai/models/nemotron-3.5-30b   511 МБ

Отчёт честно говорит, что модель не проверена. Но огрызок остался лежать.


P0-1. Кодер возвращается в штатное состояние

Это первое по важности: сейчас у владельца сломан рабочий инструмент.

  1. Ручной процесс на 8081 остановить.
  2. qwen-coder поднять штатно, через systemd, с контекстом 196608 из юнита.
  3. Убедиться, что после systemctl restart служба поднимается сама и порт отвечает.
  4. Проверить включение в автозапуск (systemctl is-enabled): служба обязана пережить перезагрузку.
  5. qwen-compressor на 8082 проверить тем же порядком.

Юнит-файлы не переписывать без нужды: это машина владельца, он правит их сам. Если правка всё же необходима — обосновать в отчёте отдельным пунктом.

P0-2. llama-swap

  1. Поставить mostlygeek/llama-swap (Go, MIT) рядом с работающими службами, не ломая их.
  2. В конфигурацию внести все модели, лежащие в /srv/ai/models/, каждую отдельной записью со своими параметрами запуска.
  3. Таймаут выгрузки настраивается.
  4. Проверить замером nvidia-smi, что выгрузка действительно освобождает видеопамять — по документации не принимать.
  5. Откат одной командой описать и проверить: если llama-swap мешает, qwen-coder и qwen-compressor возвращаются в прежний вид.
  6. Штатные порты 8081 и 8082 остаются за службами владельца. llama-swap слушает свой порт и в работу Hermes не вмешивается, пока владелец не переключит.

Обоснование, почему это стоит делать: суммарно четыре интересующие владельца модели занимают 25,5 ГиБ, а на сервере 45 ГБ уже занято страничным кэшем при 62 ГБ всего. Модели помещаются в оперативную память целиком, поэтому переключение между ними — копирование по PCIe, а не чтение с диска на 187 МБ/с. Это снимает главное возражение против свопа.

P0-3. Две правки отчёта

Таблицу не трогать, кроме следующего.

  1. Размер контекста внести в условия измерений. Если замеры шли на 32768 — так и написать. Числа, снятые на 32К, не выдавать за характеристику установки владельца, работающей на 192К.
  2. Столбец VRAM пересчитать на потребление процесса, а не карты: nvidia-smi --query-compute-apps=pid,used_memory. Если пересчёт требует повторных запусков — либо перезамерить, либо честно пометить столбец как неизмеренный и убрать числа. Оставлять заведомо неверные значения нельзя.
  3. Добавить строку про порог Hermes: какие из моделей держат 64К контекста и с какой скоростью. Это тот вопрос, ради которого владелец сравнение и заказывал.

P0-4. Ответ на вопрос владельца

Владелец спрашивает, можно ли держать несколько лёгких моделей сразу: Qwen2.5-Coder-14B, Qwen3-4B-Instruct-2507, DeepSeek-Coder-V2-Lite, Granite-4.2-8B.

Арифметика ревьюера по проверенным размерам файлов:

Qwen2.5-Coder-14B     8 571 МиБ
DeepSeek-V2-Lite      9 884 МиБ
Granite-4.2-8B        5 283 МиБ
Qwen3-4B-2507         2 382 МиБ
                     ──────────
только веса          26 120 МиБ из 32 768
остаётся              6 648 МиБ на четыре контекста и буферы

Замеренная надбавка у живых процессов на 32К — от 1 154 МиБ до 3 058 МиБ на экземпляр.

Требуется проверить это замером, а не расчётом: поднять три модели без DeepSeek одновременно и снять nvidia-smi по процессам; затем попробовать четыре. Дать владельцу таблицу «сколько моделей и с каким контекстом помещается» с настоящими числами.

P0-5. Аудит вторым проходом

  1. Перезагрузить сервер (согласовав окно с владельцем) и убедиться, что кодер и компрессор поднялись сами. Это единственная настоящая проверка пункта P0-1.
  2. Убедиться, что контекст 196608, а не 32768: запросить у сервера и сверить.
  3. Проверить, что llama-swap не мешает штатным службам: обе работают, порты отвечают.
  4. Сверить пересчитанный столбец VRAM с --query-compute-apps независимо.
  5. Убедиться, что в отчёте не осталось чисел без указания условий, при которых они сняты.
  6. Побочные изменения объяснить.
  7. Пропущенный пункт назвать пропущенным.

Ограничения

  • Сервер рабочий. Окно для перезагрузки согласовать с владельцем.
  • Учётные данные и ~/.hermes/agy_profiles/ не трогать.
  • Конфигурацию хаба не менять.
  • Юнит-файлы владельца без обоснования не переписывать.
  • Место на диске контролировать: свободно 257 ГБ.
  • Версию 0.1.1 не поднимать, тег не создавать.
  • Правило честности без исключений.

Критерии приёмки

  1. Ветка в origin, git status чист.
  2. qwen-coder работает через systemd с контекстом 196608, включён в автозапуск, пережил перезагрузку — вывод приложен.
  3. qwen-compressor проверен тем же порядком.
  4. llama-swap установлен, содержит все модели из /srv/ai/models/, выгрузка освобождает видеопамять — подтверждено nvidia-smi; откат описан и проверен.
  5. Штатные службы llama-swap не сломал.
  6. В условиях измерений отчёта указан размер контекста.
  7. Столбец VRAM показывает потребление процесса либо честно помечен неизмеренным.
  8. В отчёте есть ответ, какие модели держат 64К и с какой скоростью.
  9. Замерено и приложено, сколько моделей помещается одновременно и с каким контекстом.
  10. Огрызок nemotron-3.5-30b убран либо докачан; выбор объяснён.
  11. ruff check . чисто; релизный гейт не ухудшен.
  12. Отчёт: START_HEAD, FINAL_HEAD, origin/main, git status, X passed / Y skipped / Z failed. После слияния с origin/main ожидается 491 passed.

Главное

Замеры в A40 сделаны честно, и это заметный шаг после A38. Но ради них у владельца остановили кодер, запустили его вручную с контекстом вшестеро меньше штатного и в таком виде оставили — а при 32К модель не проходит порог Hermes и в работе бесполезна. Сначала вернуть инструмент в строй, потом договорить в отчёте то, что осталось недосказанным: при каком контексте сняты числа и сколько памяти занимает каждая модель на самом деле.

Порядок сдачи

Передать точный FINAL_COMMIT_SHA.