Что такое Gevva0 и почему вокруг него столько шума
Gevva0 - каскадный движок принятия решений, построенный вокруг простой идеи: не гонять большую языковую модель там, где справится дешёвый уровень. Автор проекта описал в обсуждении на r/LocalLLaMA четыре ступени, которые обрабатывают запрос по очереди, с ранними выходами: статические правила, поглощающие цепи Маркова на базе EmbeddingGemma-2 (740M), один прямой проход по Gemma 4 26B-A4B (MoE, 4B активных) и ограниченный Chain-of-Thought до 256 токенов. Чем сложнее запрос, тем выше он поднимается по этой лестнице.
Шум вокруг проекта объясняется двумя событиями. Сначала автор заявил о 100% совпадении с GTO в блэкджеке, и это читалось как доказательство, что каскад выдаёт математически оптимальную стратегию. Затем заявление отозвали: в методике оценки нашёлся баг утечки промпта. После исправления реальная zero-shot точность на 340 канонических руках блэкджека составила около 15-29%, а модель показала сильное смещение в сторону действия STAND. Отзыв и исправление опубликованы в исходном посте.
Разберёмся в терминах. GTO (Game Theory Optimal) - равновесная стратегия, в блэкджеке это точный набор действий для каждой комбинации карт. MDP (марковский процесс принятия решений) - формальное описание задачи, где следующее решение зависит от текущего состояния, а не от всей истории партии. Zero-shot - режим без дообучения, когда модель применяет общие знания к новой задаче. В блэкджеке пространство состояний конечно и хорошо размечено, поэтому промахи по GTO измеряются точно: 340 канонических рук покрывают основные ситуации.
Дальше идут две линии разбора: как устроен каждый уровень каскада и где заявленные цифры расходятся с проверяемыми. Все значения производительности взяты из материалов автора проекта, независимых замеров нет.
Архитектура каскада: четыре уровня принятия решений
Это не ансамбль, где все модели голосуют одновременно, а последовательность с ранними выходами: запрос сначала проходит самые дешёвые проверки, и только при отсутствии однозначного ответа поднимается выше. Каждый уровень платит задержкой за качество. Статистика автора показывает распределение трафика: 77,9% запросов разрешаются без генерации единого токена, а самые сложные 17,1% эскалируются в Tier 2.
Tier -1: статические правила за микросекунды
Первый уровень - hot-reloadable regex и keyword guards, работающие меньше 50 µs без обращения к GPU. Правила отсекают очевидные случаи до любой нейросетевой обработки: если запрос попадает под известный шаблон, ответ отдаётся сразу, и вычислительный бюджет на модель не тратится. Роль уровня - фильтр и разгрузка: типовые паттерны закрываются строкой кода, всё нестандартное уходит дальше. Сколько именно трафика удастся снять на правилах, зависит от предметной области. Там, где набор формулировок предсказуем, один Tier -1 способен закрыть заметную долю запросов дешевле любого инференса.
Tier 0: поглощающие цепи Маркова на EmbeddingGemma-2
Второй уровень опирается на EmbeddingGemma-2 (740M): модель проецирует запрос в 768-мерное пространство. Дальше включается математика поглощающих цепей Маркова. Состояния удобно представить как узлы, между которыми случайное блуждание переходит с определёнными вероятностями. Часть узлов - поглощающие: попав в них, блуждание останавливается, и результат зафиксирован.
Вероятность добраться до конкретного поглощающего состояния из стартовой точки считается в замкнутой форме, то есть по готовой формуле, а не пошаговым моделированием. Именно это даёт около 2 мс на инференс: итеративный перебор занял бы кратно больше, ведь пришлось бы симулировать блуждание. Замкнутая форма убирает циклы расчёта, а ONNX-рантайм эффективно исполняет саму модель эмбеддингов. По данным автора, Tier 0 показывает 100% точность на ранних выходах и ноль ложных выходов на 344 out-of-domain элементах: когда уровень берётся отвечать, он не уводит запрос по ложному пути.
Tier 1: быстрый проход по Gemma 4 26B-A4B и микро-голова K=64
Третий уровень - один прямой проход по Gemma 4 26B-A4B, разреженной MoE-модели с 4B активных параметров. Задержку определяет активная часть: при обработке каждого токена вычислительно работает около 4B параметров, а не все 26B. По latency такая конфигурация ближе к 4B-модели, чем к плотной 26B.
Ключевая деталь - кастомная микро-голова K=64. Полный словарь Gemma 4 содержит 262 144 строки, и считать логиты по всему словарю ради выбора одного из 52 заранее определённых вариантов ответа бессмысленно. Микро-голова срезает словарь до этих 52 вариантов и снижает вычисления выходной головы на 99,98%. Результат: 77,9% запросов разрешаются на этом уровне без генерации единого токена, заявленная задержка около 35 мс.
Tier 2: Hot-KV Bounded CoT до 256 токенов
Четвёртый уровень достаётся самым сложным 17,1% запросов. Это ограниченный Chain-of-Thought: рассуждение обрывается на 256 токенах, что задаёт жёсткий потолок по времени. Важная часть механизма - reuse_kv=True. Tier 2 стартует не с нуля, а берёт KV-кэш, который Tier 1 уже предзаполнил тем же промптом. Повторной обработки входа не происходит, поэтому на длинном контексте задержка падает до 30%. Ограничение в 256 токенов - осознанный компромисс: более длинные рассуждения дают лучший ответ, но ломают бюджет latency, ради которого построен весь каскад.
Отзыв заявления о 100% GTO: что именно сломалось
Первоначальное заявление о 100% GTO-паритете в блэкджеке отозвано самим автором из-за бага утечки промпта. Это тот случай, когда ошибка в методике оценки создаёт иллюзию прорыва, а потом исчезает вместе с исправлением теста. Разбираем механику без конспирологии: что именно исказило результат и какая точность осталась после починки.
Как баг утечки промпта исказил результаты
Утечка промпта означает попадание информации об ожидаемом ответе в контекст модели: подсказки, метки класса, фрагмента эталона. Модель, которая видит такой сигнал, выбирает правильный вариант не потому, что решила задачу, а потому что ответ лежал рядом во входе. Метрика при этом показывает почти идеальный результат, и по итоговому числу отличить его от настоящего невозможно. Это классическая ошибка при оценке LLM: проверять нужно не только accuracy, но и то, что именно попало во вход.
Автор обнаружил баг сам и отозвал заявление о 100% GTO. Механика оказалась именно такой: тестовые примеры несли информацию, облегчавшую выбор. Как только утечку убрали, цифры просели до реального уровня. Похожий скепсис полезен к любым круглым обещаниям в AI: разбор заявления о 100% эффективности GPU показывает, как одна цифра без методики и сценария теряет смысл.
Реальная zero-shot точность 15-29% и смещение в сторону STAND
На всех 340 канонических руках блэкджека zero-shot точность оказалась в диапазоне 15-29%. Модель сильно смещена в сторону STAND и не улавливает тонкие MDP-границы без дообучения. Причина в природе GTO: оптимальное действие часто определяется разницей в десятых долях вероятности. На границе между HIT и STAND небольшое смещение в распределении переворачивает решение, и модель, склонная выбирать частотный класс, ошибается системно. Итог фиксируется в том же посте автора: 340 рук - стандартный набор ситуаций, и падение до 15-29% отделяет демонстрацию от практического применения в GTO-задачах.
Честные цифры производительности: от 2 мс до 44 мс
Собираем задержки по уровням: Tier -1 - меньше 50 µs, Tier 0 - около 2 мс, Tier 1 - около 35 мс, Tier 2 - ограниченный CoT до 256 токенов. Медианная задержка каскада на бенчмарке JevBench - 44 мс. При Decision Index 0.3 каскад на 4B-активной MoE обходит плотные 27B-модели (в частности Kev 27B) при p50 около 60 мс, что примерно в 7 раз быстрее 27B-альтернатив. Decision Index здесь отражает порог сложности, на котором каскад решает задачу: чем выше порог, тем больше запросов поднимается на дорогие уровни.
Все эти значения заявлены автором и независимо не проверялись. Насколько осторожно относиться к таким числам, хорошо видно на примере чужих замеров: тесты DeepSeek V4.1 Flash на восьми A40 показывают, что из красивых tok/s нельзя делать выводов без описания конфигурации и квантизации.
Почему ONNX и замкнутая форма дают ~2 мс
Две вещи складываются в низкую задержку Tier 0. ONNX-рантайм позволяет исполнять модель эмбеддингов предсказуемо и без лишних накладных расходов. Замкнутая форма решения вероятностей поглощения убирает итерации: не нужно шаг за шагом симулировать случайное блуждание, ответ берётся из формулы. Это принципиальное отличие от подхода, где каждую траекторию пришлось бы прогонять отдельно. Для каскада такая экономия критична: Tier 0 стоит вторым по счёту, значит через него проходит большая часть нестандартного трафика.
Экономия на KV-кэше: до 30% на длинном контексте
KV-кэш хранит промежуточные состояния внимания по уже обработанным токенам. Когда Tier 1 делает прямой проход, он наполняет этот кэш. Tier 2 через reuse_kv=True подхватывает готовые значения и не пересчитывает промпт заново. Если бы каждый уровень обрабатывал вход с нуля, каскад платил бы за один и тот же текст дважды, и на длинном контексте это съедало бы весь выигрыш. Переиспользование убирает двойную обработку и сокращает задержку до 30%.
Сравнение с Claude Opus 4.6 Thinking и Kev 27B на JevBench
На бенчмарке JevBench Gevva0 обходит Claude Opus 4.6 Thinking по chance-corrected intelligence со счётом 84,62 против 83,90. Медианная задержка при этом - 44 мс против 4 850 мс у Opus. Второе сравнение касается плотных моделей: при Decision Index 0.3 каскад на 4B-активной MoE превосходит 27B-модели вроде Kev 27B при p50 около 60 мс, примерно в 7 раз быстрее. Это заявленные автором результаты, независимой проверки нет, поэтому разумно относиться к ним как к отправной точке, а не как к финальному вердикту.
Что такое chance-corrected intelligence и почему это важно
Chance-corrected intelligence учитывает вероятность угадать ответ случайно. В задачах с ограниченным набором вариантов это критично: микро-голова K=64 работает с 52 вариантами ответа, и модель, которая просто выбирает самый частый класс, без поправки выглядела бы сильнее, чем есть. Поправка на случайность вычитает вклад угадывания и оставляет ту часть результата, которая действительно отражает качество решения. Без неё сравнивать модели на тестах с малым числом вариантов некорректно.
Готовность к real-time: 60 FPS и демо Pacman
Заявлена готовность к real-time игровому циклу на 60 FPS, в комплекте идёт демо Pacman. 60 FPS означает бюджет примерно 16,7 мс на кадр. Уровни Tier 0 и Tier 1 с задержками около 2 мс и 35 мс по-разному укладываются в этот бюджет: правила и марковский уровень проходят с большим запасом, а эскалация в CoT требует осторожности. Уложиться целиком помогает то, что не каждый кадр нуждается в Tier 2, а reuse_kv=True снимает часть накладных расходов. Что демо проверено независимо, из материалов не следует.
Практические ограничения: где каскад не спасёт
Главное ограничение кейса звучит прямо: модель не улавливает тонкие MDP-границы zero-shot без дообучения и сильно смещена в сторону STAND. Каскад режет задержку, но не подменяет качество базовой модели. Для задач с чёткими MDP-границами (блэкджек, игры, планирование) нужен либо fine-tuning, либо явные правила на нижних уровнях.
Почему zero-shot не хватает для MDP-задач
MDP-задачи требуют точных решений на границах состояний, где вероятности близки друг к другу. Zero-shot LLM склонны опираться на частотные паттерны и смещаться к популярному классу действий. В блэкджеке разница между HIT и STAND на границе может зависеть от десятых долей вероятности, и такое смещение переворачивает выбор. Дообучение на размеченных руках или явные правила закрывают этот разрыв, потому что добавляют именно ту информацию, которой не хватает статистике. Точность 15-29% на 340 руках - это далеко от практического применения в GTO-задачах, и заявление о 100% здесь только маскировало проблему.
Кому подходит каскадная архитектура
Схема имеет смысл там, где есть чёткие MDP-границы, ограниченный набор действий и требования к latency: игры, real-time агенты, локальный инференс LLM на своём железе. В открытых задачах без явной структуры ранние выходы и микро-голова теряют смысл: там нечего резать до 52 вариантов. Стек можно заменить: EmbeddingGemma-2 (740M) и Gemma 4 26B-A4B (MoE, 4B активных) - конкретный выбор автора, а не обязательное условие. Тема локального inference на MoE-моделях активно развивается, и запуск MoE-моделей класса 300B на одной машине показывает, насколько важен здесь бюджет памяти и железа. Ждать, что каскад заработает из коробки на любой задаче, не стоит.
Что в итоге: чему учит кейс Gevva0
Четыре вывода, которые стоит забрать в работу.
- Каскад с ранними выходами даёт реальный выигрыш по задержке. Распределение 77,9% без генерации токенов и 17,1% в CoT показывает, что большая часть трафика не требует дорогого инференса.
- Методика оценки важнее громкой цифры. Отзыв заявления о 100% GTO из-за утечки промпта - готовый пример того, как баг в тесте создаёт видимость прорыва.
- Zero-shot не заменяет дообучение на MDP-задачах. Смещение в сторону STAND и 15-29% точности на 340 руках говорят, что для GTO нужен либо fine-tuning, либо явные правила.
- Гибридные архитектуры с правилами и поглощающими цепями Маркова перспективны для real-time сценариев, но требуют аккуратной замены компонентов под конкретную задачу.
Практический шаг для тех, кто хочет повторить подход: начните с нижних уровней. Отдельно проверьте, какую долю запросов закрывают статические правила, и только потом добавляйте эмбеддинги и марковский слой. Заявленные цифры Gevva0 стоит воспринимать как ориентир из первоисточника, а собственные результаты измерять на своей задаче.