Mica v0.5 - decision-модель на базе Qwen3.5-4B с LoRA. Текст она не пишет: на входе состояние, вопрос и список опций, на выходе вероятность каждой опции за один forward pass. В сравнении на одной RTX 6000 Ada медиана решения в четырёх демо-задачах составила 11-18 мс. У другого 4B-решателя, PPLX Decider 1.2 Flash, те же задачи заняли 133-157 мс, у Laya на 395M-энкодере ModernBERT-large - 31-33 мс. То есть Mica примерно в 10 раз быстрее ровесника по размеру и примерно в 2 раза быстрее модели, которая вдесятеро меньше.
Прикладной результат заметнее миллисекунд. В демо с поиском вторжений Mica разобрала 150 блоков логов за 1,7 с и нашла 21 закладку из 22. PPLX нашла 18 за 23,5 с, Laya - ни одной, keyword grep - 6. Источник всех цифр - опубликованное автором сравнение, и он сам перечисляет ограничения: логи синтетические, замеры сделаны на одной машине.
Ниже - что именно измерялось, чем decision-подход отличается от обычного чата с LLM, почему меньшая модель проиграла по скорости и как проверить такую модель на своём кейсе, не полагаясь на публичные лидерборды.
Что такое decision-модель и зачем она нужна
Decision-модель решает задачу выбора. На вход подают состояние (блок логов, текст тикета, историю шагов агента), вопрос и именованный список опций. Ответ приходит как набор чисел: вероятность для каждой опции. В пайплайне берут вариант с максимальной вероятностью или отправляют решение человеку, если уверенность ниже порога.
Обычная LLM в такой же задаче генерирует текст токен за токеном. Нужен один из трёх вариантов, а модель пишет слово, потом точку, потом иногда пояснение на пол-абзаца. Время ответа зависит от длины вывода, а результат приходится разбирать парсером и проверять, не добавила ли модель четвёртый вариант от себя.
Чем decision-модель отличается от генеративной LLM
Один forward pass против авторегрессионной генерации. При генерации каждый следующий токен требует отдельного прохода по сети, и задержка растёт вместе с длиной ответа. Decision-модель считает вероятности по всем опциям сразу, поэтому задержка не зависит от того, насколько длинное объяснение вы бы хотели получить. Его просто нет.
Дальше три следствия, важные для продакшна. Нет парсинга: ответ уже структурирован. Нет варианта вне списка: модель физически не может выбрать опцию, которую вы не дали. Нет объяснения: почему выбрано именно это, из выхода не видно, и для аудита нужен отдельный слой логирования.
Типовые задачи: модерация, роутинг, действия агента
Список опций почти всегда короткий, и это ключевое условие применимости.
- Модерация и фильтрация. Варианты вида «разрешить», «заблокировать», «отправить человеку». Решение по сообщению занимает миллисекунды, поэтому проверять можно весь поток, а не выборку.
- Роутинг запроса. К какому инструменту или базе знаний отправить запрос: поиск, калькулятор, CRM, эскалация оператору. Тот же принцип вероятностного выбора инструментов используют и другие модели класса, например Aplomb 1 возвращает вероятность для каждого инструмента и аргумента.
- Шаг агента. Что делать дальше из фиксированного набора действий. Предсказуемая задержка здесь важнее красивого текста: цикл из двадцати шагов с ответом по 150 мс уже ощутимо тормозит.
- Приоритизация алертов. Шум, требует внимания, критично. Модель смотрит на контекст события целиком, а не на одно поле.
Как устроена Mica v0.5: Qwen3.5-4B плюс LoRA
База - Qwen3.5-4B, сверху LoRA-адаптер. Mica v0.5 - следующая версия после v0.1, и по классу это то же, что Jev: не генератор текста, а модель принятия решений. Отдельной архитектуры вывода в описании не заявлено, поэтому считать её «энкодером с головой» нет оснований.
Что даёт LoRA и почему база 4B
LoRA дообучает небольшие низкоранговые надстройки к весам базовой модели, оставляя сами веса неизменными. На практике адаптер можно снять, заменить или обновить, не пересобирая 4-миллиардную модель. Для задачи решений это удобно: поведение меняется, цена хранения остаётся низкой.
Размер 4B - компромисс между качеством и задержкой. Для сравнения: Laya построена на 395M-энкодере ModernBERT-large и вдесятеро меньше, PPLX Decider 1.2 Flash - такие же 4B. Точных требований по VRAM автор не приводит. Арифметика простая: 4B в bf16 - около 8 ГБ только под веса, плюс контекст и промежуточные буферы. Одна карта с 16 ГБ выглядит реалистичной, но это расчёт, а не измерение. В предыдущем разборе мы отдельно смотрели форматы INT8 и GGUF и запуск Mica на картах от 8 ГБ.
Ещё одна цифра от автора: Mica v0.5 обучалась более чем на 200 реальных сценариях и даёт около 95% правильных ответов на этих кейсах. Это результат на данных, которые модель видела при обучении, поэтому ждать те же 95% на своём трафике не стоит.
Сколько Mica v0.5 тратит на решение: цифры по четырём задачам
Условия одинаковые для всех: одна машина с RTX 6000 Ada, на каждом ходу модели видят один и тот же список опций, в таблице - медианное время решения.
| Задача | Mica v0.5 | PPLX Decider 1.2 Flash | Laya |
|---|---|---|---|
| Tetris | 14,5 мс | 150 мс | 32 мс |
| Шахматы против случайного соперника | 14 мс | 133 мс | 31 мс |
| Snake | 18 мс | 154 мс | 33 мс |
| Log hunt | 11 мс | 157 мс | 31 мс |
Игровые демо нужны ровно для одного: увидеть скорость в живом цикле. Ценность в них не в силе модели: ход делается часто, и задержка видна глазом.
Mica против PPLX Decider 1.2 Flash: два 4B, разница в 10 раз
Обе модели на 4B, обе запускались в быстром режиме, разница по медиане - от 8,4 до 13,9 раза. Почему при равном размере получился такой разрыв, автор не объясняет. Правдоподобная версия: PPLX генерирует ответ, а Mica читает вероятности из одного прохода, и именно это даёт основной выигрыш. Проверить её по опубликованным данным нельзя, так что относитесь к объяснению как к гипотезе, а не факту.
Mica против Laya: меньшая модель не всегда быстрее
Laya вдесятеро меньше Mica по параметрам, но в 1,8-2,8 раза медленнее: 31-33 мс против 11-18 мс. Размер модели и задержка связаны не напрямую, и это хороший аргумент против привычки выбирать «что поменьше, то и побыстрее».
Отдельная деталь: на первом длинном блоке логов у Laya был разовый прогрев 12,9 с. Автор исключил его из видео и указал это на экране, так что в медианы он не попал. Для продакшна вывод такой: первый вызов после старта может быть заметно дороже последующих, и прогревать модель стоит заранее.
Кейс log hunt: 21 из 22 закладок за 1,7 секунды
Сценарий: день security-логов нарезан на 150 блоков, каждый блок получает одно из трёх решений - allow, block или check. Закладок в данных 22. Mica прошла все 150 блоков за 1,7 с и нашла 21. PPLX Decider 1.2 Flash потратила 23,5 с и нашла 18. Laya не нашла ни одной. Обычный keyword grep нашёл 6.
Разрыв между 1,7 с и 23,5 с здесь важнее миллисекунд на блок: на длинных блоках у PPLX накапливается задержка, и полный проход по дню логов превращается в десятки секунд.
Почему grep проиграл и что это говорит о задаче
Grep ищет по ключевым словам и регуляркам. Закладки в тесте специально написали так, чтобы они не содержали очевидных маркеров. Decision-модель смотрит на блок целиком, вместе с контекстом вокруг подозрительной строки, и может среагировать на комбинацию признаков, под которую регулярку никто не писал.
Из этого не следует, что grep плох. Если у вас есть известные сигнатуры атак, grep отработает дешевле, быстрее и предсказуемее, а модель стоит подключать на то, что правилами не ловится.
Что не так с этим кейсом
Логи синтетические, написаны под тест. Один день, 22 закладки, малая выборка. В опубликованных цифрах нет данных о ложноположительных срабатываниях: сколько нормальных блоков модель пометила как block или check, неизвестно. Для security это половина оценки, потому что модель, которая находит всё и попутно заваливает аналитика ложными алертами, в работу не годится.
Вывод аккуратный: кейс показывает, что подход работает на задаче с неочевидными маркерами. Продакшн-бенчмарком он не становится.
Почему бенчмарки decision-моделей нельзя принимать на веру
Позиция автора теста: большинство бенчмарков для сравнения decision-моделей сильно загрязнены, многие открытые модели с весами плотно настроены под публичные бенчмарки вроде JDI, а сам JDI далёк от реальных решений. Это оценка участника рынка, а не независимая проверка, и держать её в голове стоит именно так.
Проблема JDI и переобучения под лидерборды
JDI - публичный индекс для моделей принятия решений. Как только индекс становится витриной, у разработчиков появляется стимул подгонять под него данные и формат задач. Дальше работает обычная механика: высокая строчка в таблице подтверждает соответствие конкретному набору задач, а не вашему пайплайну с вашими формулировками опций и вашим распределением классов.
Рекомендация автора простая: смотреть, сколько правильных решений модель даёт на вашем кейсе, и сколько времени тратит на ответ. Публичные рейтинги оставить как вспомогательный фильтр для отбора кандидатов. Про то, как вообще сравнивают такие модели и почему по одной публикации победителя не назвать, мы разбирали в материале про сравнение Clef Q8 и Jev.
Почему в тесте нет Jev
Jev относят к тому же классу моделей, что и Mica, и его отсутствие в таблице выглядит странно, пока не посмотреть на задержки. На одном наборе запросов Jev отвечает примерно за 498 мс против 15,6 мс у Mica, больше чем в 30 раз медленнее. Причём 498 мс - это время через API, с сетевым временем. Ставить такие числа рядом в одном столбце бессмысленно: вы измерите разницу между локальным инференсом и удалённым сервисом.
Честная формулировка: прямого сравнения с Jev нет, и по этому тесту нельзя сказать, кто из двух лучше по качеству. Сравнение скоростей тоже некорректно, пока Jev не запустят локально на том же железе.
Ограничения теста, которые важно учитывать
- Логи в демо синтетические, написаны специально под тест.
- Времена - это время вызова модели на одной машине, а не сетевые задержки.
- Сравнения с Jev нет, а его 498 мс включают сетевое время через API.
- У Laya был разовый прогрев 12,9 с, исключённый из медиан.
- Одна GPU, одна конфигурация, по одному прогону на задачу.
- Загрязнённость бенчмарков, включая JDI, - тезис автора, независимых подтверждений в источнике нет.
- 95% правильных ответов относятся к сценариям, на которых модель обучалась.
Время вызова модели против сетевой задержки
11-18 мс - это чистый инференс на локальной карте. В реальном пайплайне к ним добавляются сеть до вашего сервиса, очередь, препроцессинг (нарезка логов на блоки, токенизация) и постпроцессинг (запись решения, пороги, эскалация). Итоговая задержка на решение легко окажется в разы больше, даже когда сама модель отвечает за 11 мс.
Обратная ситуация с Jev: если вы вызываете модель по API, сетевое время входит в цифру по определению, и на разных каналах она будет разной. Поэтому сравнивать локальный и удалённый инференс по миллисекундам можно только с оговоркой, что вы измеряете разные вещи.
Где и как использовать такую модель локально
4B-модель реалистична для одной GPU. В тесте стояла RTX 6000 Ada, рабочая карта, а не домашняя сборка, поэтому те же 11-18 мс на потребительской видеокарте ждать не стоит: будет медленнее, насколько именно, зависит от карты и формата весов. Проверять нужно на своём железе.
Сценарии, где такой подход окупается:
- модерация пользовательского контента на потоке, с эскалацией спорных случаев человеку;
- роутинг запросов между инструментами и базами знаний;
- выбор следующего шага в цикле агента, где важна предсказуемая задержка;
- приоритизация алертов и очередей поддержки.
Общий признак: короткий фиксированный список вариантов и много вызовов. Если задача требует развёрнутого ответа, decision-модель не подходит, здесь нужна обычная LLM.
Как выбрать между Mica, PPLX и Laya под свою задачу
Универсального победителя нет, и таблица медиан его не создаёт. Критерии, по которым стоит раскладывать:
- Задержка на вашем железе. Mica выигрывает на RTX 6000 Ada, но это не гарантия для другой карты.
- Размер и требования к памяти. 4B против 395M у Laya: если памяти мало, компактный энкодер остаётся вариантом даже при 31-33 мс.
- Качество на вашем кейсе. Единственная метрика, которая что-то предсказывает. Чужие цифры на JDI её не заменят.
- Доступность весов и форматов. Локальный запуск требует понятной сборки, а не только API.
Грубый ориентир: Mica - когда критична скорость и есть готовый список опций; Laya - когда важен компактный энкодер и 31-33 мс приемлемы; PPLX - когда нужен 4B-решатель с другим балансом свойств, хотя в этом тесте он оказался самым медленным.
Чек-лист проверки decision-модели на своём кейсе
- Соберите набор из 100-300 реальных примеров с эталонными ответами.
- Зафиксируйте формулировки опций и их порядок. Перестановка вариантов не должна менять решение.
- Замерьте качество: доля верных решений и отдельно число ложноположительных срабатываний.
- Замерьте задержку на своём железе, отдельно первый вызов и установившийся режим.
- Сравните с простым бейзлайном: правила, grep, регулярки. Если разница в качестве невелика, берите бейзлайн.
- Посмотрите, как модель ведёт себя у порога уверенности: сколько решений уходит на эскалацию человеку.
Публичные лидерборды на этом шаге уже не нужны, они отработали своё на этапе отбора двух-трёх кандидатов. Если хочется сверить методику с открытыми инициативами, посмотрите locallm.top с краудсорсинговыми тестами: там видно, как выглядят доменные оценки, но принцип тот же - ваши данные важнее чужой таблицы.
Дальше - один вечер на прогон своего набора примеров. Если Mica укладывается в ваши пороги по задержке и ложным срабатываниям, её можно ставить в пайплайн; если нет, никакая строчка в бенчмарке этого не исправит.