← Все лидерборды

Этап 2: тестовое задание «биллинг LLM-токенов»

Отчёт подготовлен с 17 по 27 октября 2026 года в ZCode при содействии моделей GLM-5.3 и GLM-5.3-Flash.

1.Главные выводы

Этап с тестовым заданием разделил кандидатов очень контрастно. Лидер среди облачных — DeepSeek V4.1 Flash: полный зачёт и на low, и на max, на max — ещё и самый чистый код среди выполнивших задание. Локальную часть таблицы возглавляют три сборки qwen3.8 — базовая qwen3.8, huihui и orca; последние две — та же 27B-база со снятыми фильтрами безопасности (uncensored).

У qwen3.8 качество решения падает с ростом уровня размышлений: лучший уровень — low (три полного зачёта подряд, 13 из 13, ревью до 4.0), на medium — 12–13, max — 13, 11, 9, и без размышлений тоже слабее — 11–12 без полного зачёта. У huihui уровень размышлений на результат почти не влияет: 12–13 на low, medium и max (платя объёмом кода), а без размышлений — лотерея: 12, 2, 13. У orca без размышлений решение разваливается: 12, 2, 10 против 13 из 13 с размышлениями.

Худшие результаты выразительны: gemma4:31b не получила ни одного зачёта ни на родном уровне размышлений, ни на off; muse на любом из трёх проверенных уровней (high, low, medium) проходит быстро и дёшево, но ничего сверх обязательного: тесты (по TASK.md — «плюс, но не обязательны») и бонусную команду reprice («по желанию») не делает ни на одном прогоне; ornith не выполнила задание и потратила до 39 миллионов токенов за прогон; bonsai-2 на thinking-уровнях не написала ни одной строки кода, а на off пишет решения, которые не работают; GigaChat застрял в цикле из одинаковых запросов.

Слепой судья и ревью сходятся: в 84% прогонов расхождение оси A — не больше полбалла (шкала 0–4), из них ровно совпали в 46%; больше балла — 2 из 68 прогонов.

Аудит безопасности — нарушений нет: 30 прогонов чисто, 51 — пограничные (вспомогательные скрипты в /tmp), в сеть не выходил ни один агент.

Инсайты

Главные разочарования

2.Методика этапа

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

2.1Скелет задания

Модель получает каркас Symfony-проекта (composer.json: symfony/framework-bundle 8.0, console/yaml, doctrine-bundle 3.2, doctrine/migrations 3.3, PHP ≥ 8.4; docker-compose с PostgreSQL 17; заготовка src/ и мigrations/; в require-dev — phpunit, psalm 6 и phpcs PSR12 — инструменты самопроверки кандидата) и два документа:

• TASK.md — само тестовое задание: требования к «биллингу LLM-токенов», по которым работает кандидат — импорт тарифов и событий, тарификация с effective dating, оф-пик-окно 16:30–00:30 UTC через полночь ×0.5, идемпотентность по (provider, provider_request_id), unrated-события, деньги на bcmath без float с одним округлением HALF_UP 6 знаков на событие, эксклюзивный --to, бонус — ретро-пересчёт после коррекции цен;
• AGENTS.md — базовые агентские инструкции проекта тестового задания: код в src/, самопроверка приёмки, артефакты COMMIT_MESSAGE.md/PR_DESCRIPTION.md с обоснованием отступлений, русский язык. Харнес pi подхватывает его сам — как любому агенту в этом репозитории. Практики (миграции или schema:update, офлайн или онлайн, менять ли файлы каркаса) модель выбирает сама — чекер наблюдает выбор.

2.2Как запускается

Раннер разворачивает свежую копию скелета (без var/, .env — из .env.example) во временный каталог и запускает pi одной командой — реальный вызов (run-02 qwen3.8):

python3 test-assignment/backend/billing/runner_pi.py \
  --model qwen3.8:27b-pi-100k \
  --results models/qwen3.8-27b-pi-100k/backend/test-assignment/run-02 \
  --thinking max

Раннер передаёт агенту один промпт — константа TASK_PROMPT, одна и та же для всех моделей и прогонов. Внутри это вызов pi, промпт — последний аргумент:

pi -p --session-dir <run>/pi-session --model qwen3.8:27b-pi-100k --thinking max   "Прочитай TASK.md в корне репозитория и выполни задание."

System prompt у сессии есть — типовой, от pi: простой, ~1.8 тыс. символов (исходники); одинаковый для всех моделей.

Облачная модель запускается через тот же раннер с провайдером:

python3 test-assignment/backend/billing/runner_pi.py \
  --model openai/gpt-6.1-sol --provider openrouter \
  --results models/openai-gpt-6.1-sol/backend/test-assignment/run-02 \
  --thinking max

2.3Окружение

cwd (current working directory — рабочая папка запускаемого pi) — свежая копия скелета. Поведение pi настраивают переменные окружения (документированы в pi): PI_CODING_AGENT_DIR переносит каталог конфигурации pi (~/.pi/agent — настройки, сессии, пакеты) в одноразовую папку, чтобы прогон не читал и не оставлял следов в глобальном состоянии машины; PI_OFFLINE=1 запрещает автоматическую сетевую активность pi вне сессии (обновления каталога моделей и подобные фоновые запросы). CLI-параметров у обеих нет — в pi это заведомо переменные окружения: они настраивают сам процесс, а не задание; раннер проставляет их на каждый запуск.

Железо и софт (снято 2026-10-29; с отчёта интервью обновлялся только софт — ollama, драйвер NVIDIA с CUDA и ядро сервера; железо не менялось):

Мой nserv (нейроша) — сервер локальных моделей; дисплей на корпусе показывает телеметрию: CPU и GPU (ватты, температуры), VRAM, RAM, нагрузка, помпа; в кружке — дисплей крупно в простое (13 Вт на CPU, 21 Вт на GPU). Код для отображения телеметрии написал агент по моей просьбе.

Компонент	Версия / модель	Ключевое
Процессор	AMD Ryzen 9 9950X3D	16 ядер / 32 потока, Zen 5, до 5.7 ГГц
Видеокарта	Palit GeForce RTX 5090 GameRock OC	32 ГБ GDDR7, 21760 CUDA-ядер, power limit 600 Вт не урезан
Память	96 ГБ DDR5-6000 (G.Skill Trident Z5 Neo, 2×48 ГБ)	работает на JEDEC-дефолте 5600 MT/s, как и в интервью
ОС и ядро	AlmaLinux 10.2, ядро 6.12.0-211.67.1	в интервью — ядро 6.12.0-211.49.1; точечные обновления между сериями
Драйвер и CUDA	NVIDIA 615.71.09, CUDA 13.4	в интервью — 610.57.04 / CUDA 13.3; кубы llama.cpp под актуальную CUDA
ollama	0.40.7 (llama.cpp-based)	в интервью — 0.40.0; уровни мышления и квант KV-кэша — фичи линейки 0.40
KV-кэш	OLLAMA_KV_CACHE_TYPE=q8_0	единственный нестандартный env демона, как и в интервью

Нейроша под нагрузкой:

Общий кадр: 5090, белые кабели в разъёме видюхи; в кружке — дисплей телеметрии крупно (GPU 599 Вт — впритык к лимиту 600, 82 °C).

Тепловизор, весь корпус — распределение температур: максимум 86.8 °C на карте под нагрузкой.

Разъём крупно: самое горячее место — 93.7 °C у разъёма питания, это известное больное место топовых GeForce — расплавы разъёма на 4090/5090 задокументированы (разбор Tom’s Hardware), поэтому разъём держите на контроле.

nserv считает только инференс (адрес сервера — env OLLAMA_BASE_URL, в git не хранится); раннер, чекер и судьи крутятся на рабочей машине: Python 3.14.8; харнес pi 1.4.0 (@earendil-works/pi-coding-agent); podman 5.8.9 + compose 5.6.0 (чистая база чекера — контейнер postgres:17-alpine); PHP 8.5.11. Сбором данных и подготовкой отчёта управляет ZCode 3.16.3 (агент на GLM-5.3-Flash).

2.4Генерация

Лимит по времени — 90 минут на прогон — общий для всех провайдеров. Контекст у всех прогонов этапа — 102400: pi ужимает историю по этому порогу (автокомпакты — на графиках раздела 6), реальные окна моделей больше и до них работа не доходит; единый порог — условие равенства, все модели живут при одинаковом прессе контекста. Исключение — Opus 5.5 через OrcaRouter: pi взял нативное окно 1M (разбор — в 4.3).

2.4.1Ollama — локальные модели

Провайдер — ollama /v1 (openai-completions) внутреннего сервера. models.json раннера задаёт:

• окно контекста (contextWindow) — 102400;
• лимит выходных токенов (maxTokens) — 8192; для xhigh/max — 32768, иначе thinking съедает его весь и ответ пуст;
• карту уровней размышлений (thinkingLevelMap) — из фактической шкалы модели (/api/show).

Фактические лимиты выходных токенов по группам прогонов — в шапке таблиц раздела 6.

2.4.2OpenRouter — облачные SOTA

Облачные модели идут нативным openrouter-провайдером pi: модель берётся из каталога pi и вызывается своим родным протоколом — Anthropic (Opus 5.5, Haiku 5.5) через anthropic-messages, GPT (Sol 6.1, Luna 6) через openai-completions; точка — openrouter.ai/api, ключ через OPENROUTER_API_KEY. Окно контекста и лимит выходных токенов — нативные из каталога (128K), шкала мышления с xhigh/max. Лимит выхода на прогоне — 8192 у большинства моделей, 32768 у Anthropic-моделей (высокие уровни размышлений съедают лимит; первый запуск Haiku с 8192 обрывался по нему — см. журнал прогонов). Прежняя кастомная запись openai-completions с переопределениями на Haiku 5.5 max дала два прогона подряд stop=length посреди размышлений — в этом протоколе reasoning и ответ делят один лимит выходных токенов (оба прогона вне метрик).

2.4.3OrcaRouter — Opus 5.5

Тот же нативный anthropic-messages (/v1/messages, Bearer-ключ), прайс Anthropic без наценки; Haiku 5.5 в каталоге OrcaRouter нет (2026-10-22). Мышление — штатными лимитами reasoning pi (low 2048 / medium 8192 / high и max 16384 токенов на вызов): adaptive-режим, включавшийся compat-флагами из каталога pi, не имеет потолка — первый «low»-прогон в нём потратил 70.8K reasoning и $4.38 (прерван лимитом ключа, вне метрик; разбор в model.md).

2.4.4DeepSeek — родной API

OpenAI-совместимый API api.deepseek.com без прокси, ключ DEEPSEEK_API_KEY; лимит выходных токенов 16000 — дефолт API 4096 режет ответы в полуслове. Размышления включаются параметром reasoning_effort: наш низший уровень (low) передаётся как low, высший (max) — как high. Алиас deepseek-flash указывает на актуальный снапшот: прогоны этапа застали V4.1-Flash-1017, интервью этапа 1 шло на базовом V4.1 Flash — при сопоставлении этапов DeepSeek это две разные версии.

2.4.5GigaChat — через локальный мост

API GigaChat не совпадает с тем, что ожидает pi: инструменты у GigaChat называются functions, авторизация — OAuth с регулярным обновлением токена. Поэтому раннер включает между pi и api.giga.chat локальный прокси gigachat_proxy — самописанный скрипт в папке billing: переводит вызовы инструментов в легаси-формат GigaChat (современный формат тот молча игнорирует) и обновляет OAuth-токен посреди прогона. Размышлений у GigaChat нет. Оба прогона решения не написали — вне метрик.

История сессии. Вся история сессии (сообщения, tool-вызовы, размышления, токены) остаётся в <run>/pi-session/*.jsonl — у всех провайдеров — и коммитится в репозиторий вместе с остальными артефактами прогона: её можно разбирать построчно.

2.5Конвейер оценки: пять ярусов

Ярусы 1–2 — детерминированные, без LLM. 3–4 — два независимых модельных судьи (изолированные pi-сессии, GLM-5.3-Flash): ревью знает факты ярусов 1–2, судья — нет. Пятый — гибрид: сигналы собирает детектор кодом, классифицирует их судья-аудитор.

python3 test-assignment/backend/billing/checker/check.py --repo <репозиторий кандидата>

python3 test-assignment/backend/billing/checker/metrics.py --repo <репозиторий кандидата>

python3 test-assignment/backend/billing/checker/judge_tier3.py \
  --run models/<модель>/backend/test-assignment/run-XX --thinking low

Ты — изолированный ревьюер (ярус 3) тестового задания «биллинг LLM-токенов» (PHP/Symfony/Doctrine). Тебе дают текст задания (TASK.md), дифф решения против каркаса, результат детерминированного чекера и метрики качества. Оцени решение по ДВУМ осям рубрики.

Ось A «код и архитектура» (0–4):
0 — решение нерабочее/отсутствует;
1 — частично работает; домен не смоделирован; деньги или время на float;
2 — обязательная часть в целом работает; сущности есть, границы слоёв условные; edge-case'ы (границы окон, unrated, дубли) поверхностно;
3 — корректная доменная модель (тарификация отделена от приёма и отчёта); точные деньги (bcmath, одно округление) и время; схема воспроизводима; edge-case'ы покрыты;
4 — то же + бонус; «дешёвые» решения где можно, явность где нужно; тесты добавляют уверенность.

Ось B «процесс и коммуникация» (0–4):
0 — нет артефактов, самопроверок, след хаотичен;
1 — артефакты формальные; самопроверок нет; commit/PR без обоснования;
2 — самопроверки точечные (прогнал команды, не проверил вывод); артефакты шаблонные;
3 — систематическая самопроверка (тесты, приёмка по шагам, статанализ); commit/PR объясняют решения; отступления от задания осознанны;
4 — то же + самопроверка на границах условий (граничные значения, дубли, ретро-бонус); артефакты читаются как отчёт инженера.

Правила: верь чекеру, а не внешнему виду кода; находи дефекты, которых не видно в диффе (float в деньгах, N+1, мёртвый код) — citируй строки диффа как доказательства; не наказывай за стиль, который не оговорён заданием.

Финальное сообщение — ТОЛЬКО JSON одной строкой:
{"axis_a":<0-4, шаг 0.5>,"axis_b":<0-4, шаг 0.5>,"note":"5-10 предложений по-русски: сильные стороны, дефекты с цитатами, что учтено из чекера/метрик"}

Чекер: обязательных 11/11, бонус 2/2
Метрики: phpcs 61, psalm 76, phpstan 32, loc 1325
AST: cc_max 12, lcom4>1: 13, превышения порогов {'method_cc_over_10': 2, 'method_loc_over_50': 1, 'class_loc_over_300': 0, 'class_wmc_over_50': 0, 'class_lcom4_over_1': 13}

python3 test-assignment/backend/billing/checker/judge_tier2.py \
  --run models/<модель>/backend/test-assignment/run-XX --thinking low

Ты — изолированный судья-ревьюер (ярус 4, слепой) тестового задания «биллинг LLM-токенов» (PHP/Symfony/Doctrine). Тебе дают текст задания (TASK.md) и дифф решения против пустого каркаса. Оцени код по ОСИ A рубрики — «код и архитектура».

Шкала оси A (0–4):
0 — решения нет / не работает вовсе;
1 — частично; домен не смоделирован (всё в командах); деньги или время на float;
2 — обязательная часть в целом работает; сущности есть, но границы слоёв условные; к edge-case'ам (границы окон, unrated, дубли) отношение поверхностное;
3 — корректная доменная модель (тарификация отделена от приёма и отчёта); точная работа с деньгами (bcmath/decimal, без float) и временем; схема воспроизводима; edge-cases покрыты кодом или тестами;
4 — то же + решения «дешёвые» там, где можно проще, и явные там, где нужна явность; тесты добавляют уверенность; код читается как объяснение домена.

Обращай внимание: одна схема округления HALF_UP до 6 знаков на уровне события; выбор строки цены по valid_from <= ts; оф-пик-окно через полночь в UTC; идемпотентность по (provider, provider_request_id); исключение float для денег.

Финальное сообщение — ТОЛЬКО JSON одной строкой:
{"axis_a": <0-4, шаг 0.5>, "quotes": ["2-4 короткие цитаты из диффа как доказательства"], "note": "2-4 предложения по-русски: сильные стороны, слабости, что смутило"}

python3 test-assignment/backend/billing/checker/judge_audit.py \
  --run models/<модель>/backend/test-assignment/run-XX

3.Модели

Кто участвовал и почему: семь облачных моделей — потолок качества, вилка цен и российские облака; девять локальных — кандидаты основного набора, его вариации и квант-эксперимент (у двух облачных — по одному прогону). Состав отвечает на два вопроса этапа: дотягиваются ли локальные модели до полного зачёта и что даёт повышение уровня размышлений.

У каждой модели под именем — её папка в models/; условия каждого прогона — thinking и контекст 102400; детали и артефакты — в разделе 6.

4.Результаты моделей

Треугольник: быстро, качественно, дёшево

«Железное» правило — быстро, качественно, дёшево: выбери любые два. Три оси — цена прогона (лог-сжатие, чтобы дешёвые модели не слипались), балл ревью оси A и длительность прогона в минутах. Каждый шарик — строка таблицы результатов (модель в одном режиме мышления), радиус шарика — выходные токены сессии. Сцену можно вращать мышью и приближать колесом; золотой каркасный октандр у вершины качества — маркер недостижимого идеала (максимально дёшево + быстро + качественно), вокруг него пусто.

Цвета повторяют группы карт выше: синие облака, голубые российские, зелёные локальные. Наведите курсор на шарик — карточка с ревью, чекером, ценой, минутами и выходными токенами. Модели без ревью (bonsai-2) на сцене не показаны.

Уровень размышлений: от низшего к высшему

Серии уровней размышлений есть у всех моделей этапа, у каждой — на прочих равных: облачные — low/max, локальные — off/low/medium/max (orca и gemma4 — вкл/выкл). Полную базу 11/11 Haiku 5.5, Sol 6.1 и DeepSeek V4.1 Flash-1017 закрывают уже на low; Luna добирает её только на max. DeepSeek на max пишет заметно более чистый код — цена вопроса от ×3 (Luna) до ×10 (Sol) по API. У локальных уровень цены не меняет, а качество ведёт себя по-разному: huihui ровный на low/medium/max, qwen3.8 лучший на low.

Полоса — средняя сумма сценариев чекера из 13 (★ — бонусные); Δ — максимальное отклонение прогона от среднего по сумме чекера, мера постоянства серии (зелёная — меньше одного сценария); справа — средний балл ревью (ось A), тестов написано и стоимость прогона. У облачных уровни low/max, у локальных off/low/medium/max; « · MTP» — ретаг-серия тех же весов, « · tuned» — ornith с сэмплингом из карточки HF (temperature 0.6, top_p 0.95, top_k 20; веса те же), « · orca» — прогон через OrcaRouter; уровни без живых прогонов не показаны (у Haiku max — вне метрик).

4.1Структура кода: src/ и tests/

Задание не подсказывает устройство кода: скелет — это src/Kernel.php и пустой tests/. Про архитектуру в TASK.md одна строка: «Архитектура, разбиение на слои/модули, именование — на ваше усмотрение (это предмет оценки)». Раскладка классов в src/ — датчик врождённых предпочтений модели и оценка постоянства этих предпочтений между прогонами. Смотрим на успешные решения — 37 прогонов 9 моделей, чьи режимы набрали в среднем не меньше 3 баллов ревью по оси A (верхние квадранты карт выше).

4.1.1. Сводная структура

Все каталоги и файлы классов, которые модели создали в src/ и tests/, слитые в одно дерево. Типовая раскладка — гибрид Symfony-конвенций и DDD: Command (команды), Domain (домен) и Entity (сущности) есть у большинства, но у моделей в целом нет общего правила раскладки файлов классов (детали ниже).

Процент — доля прогонов, где каталог или файл существует; яркость имени — ступени по тому же проценту: ≥50% — чернильный, 25–49% — тёмно-серый, 10–24% — серый, 4% (один прогон) — бледный. Все каталоги свёрнуты по умолчанию, клик по [+]/[−] раскрывает и сворачивает; внутри каталогов — файлы классов: PSR-4 ставит имя файла в соответствие имени класса, так что это срез того, как модели называют классы. Каркасный src/Kernel.php не показан; src/ и tests/ — серые корни каркаса.

4.1.2. Распределение имён: общие и уникальные

По оси X — скольким прогонам встречено имя (путь каталога или имя файла-класса), по оси Y — сколько таких имён; панель каталогов включает src/ и tests/. Например, левый столбик: 76 путь каталога и 229 имя класса существуют ровно в одном прогоне. Медиана у обеих панелей — тот же один прогон: 64% путей каталогов и 62% имён классов — уникальные имена. Но есть и общие: Provider.php — в 36, UsageEvent.php — в 35, Model.php — в 30. Полные пути файлов переменчивее самих имён: 81% путей — одиночные против 62% у имён — класс переиспользуется чаще, чем его расположение. Выборка — успешные прогоны, как и во всей подсекции.

4.1.3. Размер решения: классы и строки

По оси X — размер решения (диапазон файлов или строк), по оси Y — число успешных прогонов с размером из диапазона. Это другой счёт, чем на гистограмме имён выше: там класс учтён один раз — как имя (371 разных имён), здесь — каждый файл каждого прогона (988 файлов src в сумме); классы переиспользуются между прогонами, поэтому экземпляров больше, чем имён. Типовой объём успешного решения — 25 файлов и 1407 строк (разброс 12–39 файлов, 466–2018 строк); в отличие от частоты имён, распределение одновершинное. Полюса: Sol 6.1 · 01 уместил задание в 466 строк при 12 файлах — почти вдвое компактнее следующего (824), DeepSeek V4.1 Flash-1017 · 01 растянул до 2018 строк при 37 файлах — при одинаковом полном зачёте обоих.

4.1.4. Слепки по режимам и постоянство структуры

4.2Инструменты и утилиты в работе

История сессии pi: что модели вызывали сами. Популяция — 37 успешных прогонов; поиск несуществующих утилит — по всем 68 живым.

4.2.3. Микс инструментов по моделям

Пончик режима — доли bash/write/edit/read в его вызовах (порядок и цвета — как на агрегате слева); наведение — числа. Строки — группы моделей из раздела 3, внутри строки — порядок списка, внутри модели — уровень мышления по возрастанию.

4.2.4. Утилиты bash по моделям

Доля утилиты в вызовах утилит режима; заливка — та же доля. Колонки — топ-8 утилит агрегата плюс обязательные утилиты приёмки, как в пончике 4.2.2.

4.2.5. Ошибки tool-вызовов

Доля — вызовы, завершившиеся isError, от всех вызовов этого инструмента в 37 прогонах; типы — классификация по тексту результата. isError не равно «авария»: для bash это ненулевой код выхода — часто рабочий исход (упавшие тесты, замечания линтера, пустой diff) — детализация ниже. Цвет доли: серый — isError нет, синий — до 5%, янтарный — до 10%, красный — выше.

bash: неуспешные вызовы — что в выводе

Вывод неуспешного вызова — вывод всей цепочки: часть строк может быть успешной, маркер — по источнику ошибки.

edit — единственный инструмент с заметной долей отказов: промахивается по «точному тексту» на переформатированных файлах. Разброс по режимам: чаще всех промахивается qwen3.8 (26% edit-вызовов), реже — Sol 6.1 (0%). write ошибок не даёт вовсе.

Все ли модели ошибаются