Что собрал Unlucky-Message8866: суть прототипа
Пользователь под ником Unlucky-Message8866 запустил Jev-подобный API поверх Ninfer на модели Swift-Qwen3.8-27B-NInfer и выложил исходный код на GitHub. На публичном наборе JevBench v1.2 из 231 задачи прототип выдал точность 84,4% (195/231), калибровку ECE 0,045 и Brier 0,081, медианную задержку 127 мс и p95 на уровне 699 мс. Прогон выполнялся на RTX 5090 с тремя одновременными решениями в полёте. Детали автор описал в посте на r/LocalLLaMA.
Ключевая деталь архитектуры: запуск идёт через нативный маршрут POST /v1/decisions, где на вход подаются состояние и вопрос, а на выходе получаются типизированные вероятности. Путь вербализации через chat-completions не использовался. Автор сам называет результат «очень грязным POC»: в коде есть баги, распределение ресурсов работает некорректно, а правильный способ интеграции в Ninfer ещё предстоит найти.
Материал пригодится тем, кто запускает decision-модели локально, разбирается в калибровке вероятностей и хочет понять, чего реально стоят самодельные API-обёртки. Ниже разбор цифр, слабых мест и границ применимости.
Почему это не очередной чат-бот, а decision-API
Обычная LLM-обёртка принимает текст и возвращает текст. Decision-модель работает иначе: получает структурированное состояние и вопрос с фиксированным набором вариантов ответа, а отдаёт вероятности по каждому варианту. Здесь нет разговора с моделью. Есть запрос: какой из вариантов вероятнее и насколько модель в этом уверена.
Из этого следуют два практических вывода. Первый: такой API не галлюцинирует в привычном смысле, потому что не сочиняет свободный текст. Второй: качество определяется не только долей правильных ответов, но и калибровкой. Поэтому в отчёте рядом с точностью стоят ECE и Brier. Если модель заявляет 0,95, а права в 60% случаев, строить на ней автоматику нельзя. Подробный разбор того, как устроены такие модели и чем они отличаются от генеративных, есть в статье про Jev от TypeSafe AI.
Что уже работает, а что ещё нет
Работает следующее: запуск на RTX 5090, обработка всех 231 задачи JevBench v1.2, ноль ошибок и ноль блокировок допуска, общее время прогона 19 секунд. Маршрут POST /v1/decisions принимает состояние с вопросом и возвращает типизированные вероятности.
Не работает или работает плохо: баги, некорректное распределение ресурсов, незавершённая интеграция в Ninfer. Автор прямо пишет, что ещё не разобрался, как правильно встроить решение в платформу. Это не продакшн-стек, а эксперимент с работающим ядром.
Результаты на JevBench v1.2: точность, калибровка и разбивка по уровням
JevBench v1.2 в публичной части содержит 231 типизированную задачу: 48 уровня easy, 111 hard и 72 original. Точность прототипа составила 84,4%, то есть 195 верных ответов из 231. Ошибочными оказались 36 ответов. Все задачи получили оценку, сбоев исполнения и блокировок допуска не было, полный прогон занял 19 секунд по данным автора.
| Уровень | Задач | Верных | Точность |
|---|---|---|---|
| easy | 48 | 48 | 100% |
| original | 72 | 70 | 97,2% |
| hard | 111 | 77 | 69,4% |
| Весь публичный набор | 231 | 195 | 84,4% |
Разрыв между easy и hard огромен: 100% против 69,4%. Прототип уверенно закрывает простые и «оригинальные» задачи, а на сложных теряет почти треть. Итоговые 84,4% складываются именно из этого контраста, и при реальной нагрузке с большей долей сложных кейсов результат будет ближе к hard-уровню.
Что такое ECE и Brier и почему они важны для decision-моделей
ECE (Expected Calibration Error) показывает, насколько заявленная уверенность расходится с фактической точностью. Значение считают по бинам (в этом прогоне их 10), а затем усредняют с весами. Простыми словами: ECE 0,045 означает, что в среднем уверенность модели расходится с реальностью примерно на 4,5 процентного пункта. Чем ниже, тем лучше.
Brier score - среднеквадратичная ошибка вероятностных предсказаний, тоже измеряется по принципу «чем меньше, тем лучше». Результат 0,081 говорит о том, что выдаваемые вероятности в среднем близки к фактическим исходам.
Для decision-API обе метрики критичнее доли правильных ответов. Автоматическая система редко смотрит на ответ в отрыве от уверенности: она ставит порог и отбрасывает всё, что ниже. Хорошая средняя калибровка позволяет настроить такой порог осмысленно.
Средняя калибровка не отменяет локальных провалов. Пять самых уверенных неверных ответов прототипа имеют уверенность от 0,729 до 0,949.
| Задача | Уверенность | Ответ модели | Верный ответ |
|---|---|---|---|
| hard-opus-b-tradeoff-01 | 0,949 | escalate_to_security | escalate_to_engineering |
| hard-opus-a-probability-08 | 0,852 | yes | no |
| hard-sol-b-judge-hard-02 | 0,852 | yes | no |
| hard-opus-c-temporal-numeric-02 | 0,798 | no | yes |
| hard-opus-a-probability-04 | 0,729 | late | on_time |
Высокий порог уверенности такие ответы пропустит, низкий срежет слишком много верных. Именно поэтому средняя калибровка 0,045 не даёт права считать модель надёжной на всём диапазоне задач.
Где прототип проваливается: temporal-numeric и probability
Внутри hard-уровня худшие категории выглядят так:
| Категория (hard) | Верных | Всего | Точность |
|---|---|---|---|
| temporal-numeric | 5 | 15 | 33% |
| probability | 5 | 10 | 50% |
Оба типа задач требуют аккуратной работы с числами и временем: сопоставить события по меткам, оценить вероятность, пересчитать доли. Модель на 27B параметров теряет здесь больше половины ответов. Если ваш сценарий подразумевает расчёты по временным меткам или вероятностные выводы, этот стек пока не подходит.
Производительность на RTX 5090: 127 мс медиана и что стоит за p95
Медианная задержка - 127 мс, p95 - 699 мс. Замеры сделаны на RTX 5090 при трёх одновременных решениях в полёте. Разрыв между медианой и хвостом составляет примерно 5,5 раза, и объясняется он не железом.
Почему p95 в 5,5 раз выше медианы
На hard-уровне p95 достигает 774 мс, и эта цифра определяется префиллом: состояния задач там объёмом около 3,7k токенов, и модель тратит время на их обработку до выдачи ответа. Чем длиннее состояние, тем дольше префилл.
Вторая причина роста хвоста - очередь. Один рабочий процесс сериализует выполнение, поэтому задача может ждать, пока освободится обработчик, занятый более тяжёлым решением. Из-за этого хвост раздувается и на строке easy, где сами задачи короткие.
Точность и калибровка от очереди не зависят. Разделение важное: производительность проседает, качество ответов остаётся тем же. Для интерактивного сценария 699 мс в худшем случае терпимо. Для API с высокой нагрузкой сериализация через один воркер становится узким местом, и автор сам указывает на некорректное распределение ресурсов как на известную проблему.
Что даёт RTX 5090 и где предел масштабирования
Запуск выполнялся на флагманской потребительской GPU NVIDIA. Модель Swift-Qwen3.8-27B-NInfer содержит 27B параметров, что требует заметного объёма видеопамяти. Точных данных о потреблении VRAM и полной конфигурации стенда в отчёте нет, поэтому подбирать железо под этот стек придётся самостоятельно, ориентируясь на требования 27B-моделей и выбранного движка. О практическом запуске Qwen 3.8 27B на одной RTX 5090, роли NVFP4, MTP и int8 KV cache читайте в отдельном разборе nInfer.
Сериализация через один рабочий процесс - ограничение кода, а не видеокарты. Его можно снять, но в текущем прототипе этого не сделано, и поведение под нагрузкой не проверялось. Выводы о масштабировании делать рано.
Сравнение с Jev 1.13.0 и SimpleJev: насколько результат конкурентоспособен
В сравнительной таблице по публичному набору 84,4% прототипа стоят рядом с Jev 1.13.0 (86,6%) и SimpleJev Qwen3.8-27B (86,6%). Разрыв - около 2 процентных пунктов. Для самодельного POC это близкий результат, но получен он на одном публичном наборе и без оценки разброса.
Доверительных интервалов автор не приводит. На 231 задаче разница в 2 п.п. - это примерно пять задач, и случайная вариативность такого масштаба вполне может объяснять часть разрыва. Утверждать, что прототип догнал Jev или безнадёжно отстал, по этим данным нельзя.
Почему нет композитного балла и что это меняет
Композитный балл учитывает не только точность, но и скорость, и стоимость. В этом запуске Speed/Cost не измерялись, поэтому композитный балл не публиковался: автор обозначил прогон как самостоятельный и не сравнивал совокупную эффективность.
Практический смысл прост: сравнение идёт только по точности на публичном наборе. Решение может быть точным, но медленным или дорогим, и по опубликованным числам этого не видно. Для выбора между Jev 1.13.0, SimpleJev и этим прототипом нужны замеры на своей нагрузке. Как оценивают System One-модели в роли судьи и почему разброс их оценок ниже, чем у LLM-судей, разобрано в статье Jev-as-a-Judge.
Ограничения прототипа: что автор признаёт сам
Список проблем начинается с самооценки автора: «очень грязный POC», баги, некорректное распределение ресурсов, незавершённая интеграция в Ninfer. Дальше идут ограничения, которые видны по цифрам: hard-уровень 69,4%, temporal-numeric 33%, probability 50%, хвостовая задержка, чувствительная к очереди, и отсутствие композитного балла по отчёту автора.
Уверенные ошибки: почему это опаснее всего
Пять разобранных выше промахов объединяет одно: модель ошиблась и при этом была уверена в себе на 0,729-0,949. Если автоматика получает такую вероятность и действует по порогу, она выполнит неверное действие и не получит ни одного сигнала о сомнении вплоть до последствий. ECE 0,045 описывает среднюю картину по 231 задаче и не спасает от отдельных провалов.
Отсюда практическое правило для подобных стеков: смотреть не только на среднюю калибровку, но и на распределение ошибок по категориям и на долю уверенных промахов. Автономные действия по ответам модели без дополнительной проверки на сложных категориях рискованны.
Незавершённая интеграция в Ninfer: что это значит на практике
Автор пишет, что ещё нужно разобраться, как правильно интегрировать решение в Ninfer. Текущий запуск скорее обходной путь, чем штатная работа через платформу. На практике это даёт риск нестабильности, сложности с обновлением и отсутствие поддержки. Деталей интеграции в отчёте нет, поэтому конкретные шаги и риски описать нельзя. Для быстрого эксперимента это не блокер, для рабочего процесса - блокер.
Практические выводы: кому и зачем это нужно
Прототип показывает, что «грязный» POC на 27B-модели вытягивает 84,4% на JevBench v1.2 при медианной задержке 127 мс на RTX 5090. Для исследования это содержательный результат. Для продакшна нет, пока не закрыты баги, интеграция и слабые категории.
Стоит ли пробовать: сценарии использования
- Изучение калибровки decision-моделей: ECE и Brier здесь измерены и опубликованы, есть на чём смотреть распределение ошибок.
- Эксперименты с Ninfer и нативным маршрутом POST /v1/decisions: видно, как выглядит вход (состояние плюс вопрос) и выход (типизированные вероятности).
- Сравнение с Jev 1.13.0 и SimpleJev на публичном наборе: есть готовая точка отсчёта 84,4% и разбор разрыва в 2 п.п.
- Воспроизведение: исходный код лежит на GitHub, но автор предупреждает о багах, так что запуск «с полпинка» не гарантирован.
Для автоматических решений в продакшне стек не готов: temporal-numeric 33% и probability 50% слишком слабые, а уверенные ошибки на 0,729-0,949 не отсекаются порогом. Как база для собственного дообучения прототип интересен: похожий путь через LoRA на Qwen3.5 4B и 25 млн синтетических токенов разобран в отдельном кейсе.
Что читать дальше на AI-Manual
Логичные следующие шаги: разобраться, как устроены decision-модели и зачем им типизированные вопросы (ссылка на разбор Jev от TypeSafe AI дана выше), посмотреть на практику локального запуска больших моделей на одной GPU и изучить, как калибровка и метрики работают в оценке агентов. Если планируете запускать 27B-модель у себя, начните с расчёта VRAM и выбора движка: от этого зависят и задержка, и стоимость решения. Перед любым практическим применением проверяйте прототип на своих задачах и своих категориях, а не только на общей цифре 84,4%.