Тринадцать файлов существовали только на диске ПК владельца, в рабочей копии, отставшей от 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>
14 KiB
Задание 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. Кодер возвращается в штатное состояние
Это первое по важности: сейчас у владельца сломан рабочий инструмент.
- Ручной процесс на 8081 остановить.
qwen-coderподнять штатно, через systemd, с контекстом196608из юнита.- Убедиться, что после
systemctl restartслужба поднимается сама и порт отвечает. - Проверить включение в автозапуск (
systemctl is-enabled): служба обязана пережить перезагрузку. qwen-compressorна 8082 проверить тем же порядком.
Юнит-файлы не переписывать без нужды: это машина владельца, он правит их сам. Если правка всё же необходима — обосновать в отчёте отдельным пунктом.
P0-2. llama-swap
- Поставить
mostlygeek/llama-swap(Go, MIT) рядом с работающими службами, не ломая их. - В конфигурацию внести все модели, лежащие в
/srv/ai/models/, каждую отдельной записью со своими параметрами запуска. - Таймаут выгрузки настраивается.
- Проверить замером
nvidia-smi, что выгрузка действительно освобождает видеопамять — по документации не принимать. - Откат одной командой описать и проверить: если llama-swap мешает,
qwen-coderиqwen-compressorвозвращаются в прежний вид. - Штатные порты 8081 и 8082 остаются за службами владельца. llama-swap слушает свой порт и в работу Hermes не вмешивается, пока владелец не переключит.
Обоснование, почему это стоит делать: суммарно четыре интересующие владельца модели занимают 25,5 ГиБ, а на сервере 45 ГБ уже занято страничным кэшем при 62 ГБ всего. Модели помещаются в оперативную память целиком, поэтому переключение между ними — копирование по PCIe, а не чтение с диска на 187 МБ/с. Это снимает главное возражение против свопа.
P0-3. Две правки отчёта
Таблицу не трогать, кроме следующего.
- Размер контекста внести в условия измерений. Если замеры шли на 32768 — так и написать. Числа, снятые на 32К, не выдавать за характеристику установки владельца, работающей на 192К.
- Столбец VRAM пересчитать на потребление процесса, а не карты:
nvidia-smi --query-compute-apps=pid,used_memory. Если пересчёт требует повторных запусков — либо перезамерить, либо честно пометить столбец как неизмеренный и убрать числа. Оставлять заведомо неверные значения нельзя. - Добавить строку про порог 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. Аудит вторым проходом
- Перезагрузить сервер (согласовав окно с владельцем) и убедиться, что кодер и компрессор поднялись сами. Это единственная настоящая проверка пункта P0-1.
- Убедиться, что контекст 196608, а не 32768: запросить у сервера и сверить.
- Проверить, что llama-swap не мешает штатным службам: обе работают, порты отвечают.
- Сверить пересчитанный столбец VRAM с
--query-compute-appsнезависимо. - Убедиться, что в отчёте не осталось чисел без указания условий, при которых они сняты.
- Побочные изменения объяснить.
- Пропущенный пункт назвать пропущенным.
Ограничения
- Сервер рабочий. Окно для перезагрузки согласовать с владельцем.
- Учётные данные и
~/.hermes/agy_profiles/не трогать. - Конфигурацию хаба не менять.
- Юнит-файлы владельца без обоснования не переписывать.
- Место на диске контролировать: свободно 257 ГБ.
- Версию
0.1.1не поднимать, тег не создавать. - Правило честности без исключений.
Критерии приёмки
- Ветка в
origin,git statusчист. qwen-coderработает через systemd с контекстом 196608, включён в автозапуск, пережил перезагрузку — вывод приложен.qwen-compressorпроверен тем же порядком.- llama-swap установлен, содержит все модели из
/srv/ai/models/, выгрузка освобождает видеопамять — подтвержденоnvidia-smi; откат описан и проверен. - Штатные службы llama-swap не сломал.
- В условиях измерений отчёта указан размер контекста.
- Столбец VRAM показывает потребление процесса либо честно помечен неизмеренным.
- В отчёте есть ответ, какие модели держат 64К и с какой скоростью.
- Замерено и приложено, сколько моделей помещается одновременно и с каким контекстом.
- Огрызок
nemotron-3.5-30bубран либо докачан; выбор объяснён. ruff check .чисто; релизный гейт не ухудшен.- Отчёт:
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.