Что такое Mica v0.5 и зачем нужна отдельная модель для принятия решений
Mica v0.5 - обновление компактной 4B-модели, которая принимает решения и работает на одной потребительской видеокарте. Автор замеряет на RTX 6000 Ada 19,8 мс на решение при входе в 256 токенов и около 1,2 с при входе в 32k токенов. Для пайплайнов, где decision-модель вызывается на каждом шаге, это другой режим работы по сравнению с 27B-моделью или сетевым API.
Класс задач узкий. Модель не пишет текст и не ведёт диалог. Она возвращает вердикт по входному тексту: да или нет, один из предложенных вариантов, оценку по заданной шкале. Так устроены проверки в RAG (релевантен ли найденный фрагмент), маршрутизация запросов между инструментами, автооценка ответов и модерация. Чем decision-модель отличается от обычной чат-LLM и почему её выделяют в отдельный класс, разбирали в материале про Qev 0.8B.
Версия v0.5 - продолжение Mica v0.1, а не новая архитектура. Автор называет её follow-up и делает акцент на трёх вещах: скорость, точность на бенчмарках решений и устойчивость к перестановке вариантов ответа. Все цифры ниже получены самим автором модели; независимых измерений в опубликованном материале нет.
Чем v0.5 отличается от v0.1
Детального changelog между версиями автор не публикует. Из доступного описания следует, что v0.5 - follow-up к v0.1 с упором на скорость, точность и устойчивость к перестановке вариантов; конкретный список изменений в архитектуре, данных или обучении не раскрыт. Тем, кто уже пробовал v0.1 и хочет понять, что именно поменялось, стоит смотреть карточку модели на Hugging Face: там же автор описывает оптимизации, поверх которых работает режим Mica Fast. Сравнить v0.1 и v0.5 по цифрам в этом материале нельзя: замеров первой версии в нём нет.
Скорость: 19,8 мс на коротких входах и около 1,2 с на 32k токенах
Замеры сделаны на одной RTX 6000 Ada. Вход в 256 токенов обрабатывается за 19,8 мс, вход в 32k токенов - примерно за 1,2 с. Время выросло примерно в 60 раз при росте входа в 128 раз: длинный контекст стоит дороже, но не линейно.
| Длина входа | Задержка на одной RTX 6000 Ada |
|---|---|
| 256 токенов | 19,8 мс |
| 32k токенов | около 1,2 с |
Сравнения из публикации автора: до 3,8 раза быстрее других 4B-моделей, которые он измерял, в 12-19 раз быстрее 27B-модели Perplexity и в 25-340 раз быстрее API-моделей принятия решений. Широкий разброс во втором случае говорит о том, что сравнение шло сразу с несколькими API-моделями, а не с одной. Все эти цифры относятся к конкретной карте и к тем моделям, которые автор прогонял сам (публикация в r/LocalLLaMA).
Почему разница между 256 токенами и 32k важна. В RAG и агентских пайплайнах вход редко бывает коротким: описание инструментов, история диалога и найденные фрагменты накапливаются, и decision-модель получает уже десятки тысяч токенов. Модель, которая на таком входе отвечает за секунду, остаётся пригодной для интерактивного сценария. Модель, которой нужно 10-20 секунд, выпадает из него и уходит в фоновые задачи.
Ограничение: производительность на других картах автор не приводит. Переносить 19,8 мс на RTX 4090 или на карту с 8 ГБ нельзя, там другой объём памяти и другая пропускная способность.
Mica Fast: что даёт ускорение длинных входов
Mica Fast дополнительно ускоряет длинные входы примерно в 1,4-1,5 раза поверх оптимизаций, описанных в карточке модели на Hugging Face. Выигрыш относится именно к длинному контексту. На запросах в 256 токенов, где почти всё время уходит на фиксированные накладные расходы, прирост будет меньше заявленного. Практический вывод простой: включать Mica Fast стоит там, где в модель летят большие контексты - длинные документы, истории диалога, длинные описания инструментов.
Точность и надёжность: JevBench Hard, JDI и устойчивость к перестановке
На JevBench Hard модель набирает 84/111. Автор утверждает, что это лучший результат среди 4B-моделей, которые ему удалось найти, и что выше только Microsoft Decision-1 с 9B параметров. Формулировка важна: речь о моделях, доступных для сравнения, а не обо всех существующих.
На JDI результат 58,8, и здесь Mica v0.5 опережает все 9B- и 35B-модели, которые автор тестировал. Отдельно он оговаривает, что топовые 4B-модели на JDI ориентированы на бенчмарк, а как минимум одна обучалась только на данных в стиле бенчмарков. Про собственную модель автор говорит, что тренировал её в том числе на данных из областей, которые покрывают бенчмарки, но без загрязнения, а основной упор делал на реальную работу (детали у автора).
Устойчивость к перестановке вариантов - 97,3%. Если перемешать варианты ответа, модель выбирает тот же ответ в 97,3% случаев. Эта цифра важнее, чем кажется на первый взгляд. В multiple choice модели часто меняют вердикт при смене порядка A/B/C/D, и на этом ломаются автоматические пайплайны: один и тот же документ получает разные оценки в зависимости от порядка списка. Проверить это на своей задаче несложно, и сделать это стоит до внедрения.
Общая оговорка по разделу: JevBench Hard и JDI выбраны автором модели, независимых прогонов в опубликованном материале нет. Цифры стоит воспринимать как ориентир для собственного теста, а не как доказанное превосходство над всеми моделями класса.
Порог уверенности: как модель отказывается угадывать
Модель поддерживает порог уверенности: если он задан, при низкой уверенности она сообщает об этом вместо того, чтобы угадывать. В пайплайне появляется третий исход помимо «да» и «нет»: решение уходит на эскалацию к крупной модели или к человеку. Схема рабочая: дешёвая 4B-модель закрывает простые случаи, спорные отдаёт дальше.
Порог подбирают под задачу. Слишком высокий превращает модель в генератор отказов и обнуляет экономию. Слишком низкий пропускает уверенные ошибки, и эскалация не срабатывает там, где нужна. Настраивать значение стоит на своих данных, а не брать дефолт вслепую.
Форматы ответов и входов: yes/no, multiple choice и шкалы до 255 уровней
Модель работает с тремя типами выходов: бинарный yes/no, выбор одного варианта из нескольких и оценка по шкале с числом уровней от 2 до 255. Вход - до 32k токенов. 32k здесь верхняя граница входа, и скорость на всём этом диапазоне не одинакова: на 32k задержка около 1,2 с против 19,8 мс на 256 токенах.
Примеры применения: бинарная модерация комментария (пропустить или заблокировать), маршрутизация запроса в один из N инструментов через multiple choice, оценка качества ответа другой модели по 5-балльной шкале, скоринг релевантности документа по шкале из 100 уровней. Точность попадания в нужный формат на практике важнее самих бенчмарков: если модель периодически возвращает текст вместо номера варианта, парсер пайплайна падает.
Для каких задач модель подходит, а для каких нет
Подходит: классификация и маршрутизация запросов, валидация ответов в RAG, автооценка, модерация, бинарные фильтры перед дорогим вызовом. Самый выгодный сценарий - дешёвый фильтр на входе, который снимает с большой модели часть вызовов и оставляет ей только сложные случаи.
Не подходит: генерация длинных текстов, многошаговые рассуждения, задачи, где нужен широкий запас знаний. Узкая специализация и есть причина, по которой модель быстрая. Если нужен универсальный ассистент, это другой класс моделей, и 4B-модель решений его не заменит.
Как запустить Mica v0.5 локально: INT8 для NVIDIA и GGUF для остальных
Автор даёт простое правило: на NVIDIA брать INT8-версию, на остальном железе - GGUF. INT8 на той же карте работает примерно в 2-2,7 раза быстрее, чем Q8_0 GGUF в llama.cpp. Оба формата хранят веса в 8 битах, поэтому разница возникает на стороне формата и рантайма, а не за счёт урезания точности.
Для AMD, Apple и CPU выложены GGUF в трёх вариантах: BF16, Q8_0 и IQ4_XS. Логика выбора: BF16 и Q8_0 - когда хватает памяти и нужно максимальное качество, IQ4_XS - когда VRAM в обрез. Модель заявлена работающей на картах от 8 ГБ, лицензия - Apache-2.0 (варианты запуска у автора).
Что выбрать при 8 ГБ VRAM
Заявление про 8 ГБ - общая нижняя граница, а не гарантия для любого формата. Точных замеров потребления памяти по каждому квантованию в опубликованном материале нет, поэтому на 8 ГБ разумно начинать с IQ4_XS и смотреть фактическое потребление своей карты. Оно зависит от длины контекста: KV-кэш на 32k токенов сам занимает память, и на бюджетной карте контекст лучше ограничивать, если задача не требует длинных входов.
Лицензия Apache-2.0: что можно делать с моделью
Mica v0.5 распространяется под Apache-2.0. Лицензия разрешает коммерческое использование, модификацию и распространение, требует сохранять уведомления об авторстве и текст лицензии, а также содержит патентную оговорку. Для продукта, который встраивает модель в закрытый сервис, это удобный вариант: отдельного соглашения с правообладателем заключать не нужно.
Юридические детали стоит читать в самом тексте лицензии, особенно если модель дообучается и распространяется дальше: при изменении файлов Apache-2.0 требует отмечать факт изменений.
Стоит ли переходить с большой модели или API на Mica v0.5
Аргументы за переход: задержка в десятки миллисекунд на коротких входах, одна потребительская карта, отсутствие сетевых вызовов и оплаты за токены, Apache-2.0. Добавьте приватность: входные данные не покидают машину, что для модерации и обработки внутренних документов часто решающее.
Риски тоже конкретные. 4B - это компромисс по глубине знаний, и на сложных решениях модель будет ошибаться чаще крупной. Бенчмарки поставлены автором модели, независимых прогонов нет. На JevBench Hard есть результат выше: Microsoft Decision-1 на 9B, так что при жёстких требованиях к точности смотреть стоит и в её сторону. Класс компактных decision-моделей в 2026 году оживился, помимо Mica есть, например, Aplomb 1 на 5.3B параметров с контекстом 1M токенов, и сравнивать их по своим задачам полезнее, чем по сводкам с чужих бенчмарков.
Когда API остаётся разумным: редкие вызовы со сложными решениями, задачи, где качество важнее задержки, отсутствие своего железа. Когда локальная 4B выигрывает: высокая частота вызовов, чувствительность к задержке, требования к приватности, работа офлайн. О том, где вообще проходит предел малых моделей и упирается ли он в число параметров или в объём VRAM, разбирали в отдельном материале про пределы возможностей небольших моделей.
Как проверить модель на своих данных
Соберите 50-100 реальных кейсов из своего пайплайна с эталонными ответами. Прогоните Mica v0.5 и текущую модель, сравните точность и задержку на одинаковых входах. Отдельно проверьте устойчивость: подайте те же кейсы с перемешанными вариантами и посчитайте, сколько вердиктов изменилось. Отдельно - с включённым порогом уверенности: сколько получилось отказов и попала ли в них основная часть ошибок.
Автор собирал сценарии для модели из 200+ реальных случаев, которые люди публиковали на Reddit, Twitter и других площадках. Этот же набор годится как источник идей для собственного теста: бытовые и рабочие задачи там ближе к реальности, чем синтетические примеры из документации.
Итог: кому подходит Mica v0.5
Mica v0.5 - узкая и быстрая 4B-модель для принятия решений на одной потребительской видеокарте. Для своего размера она показывает сильные результаты: 84/111 на JevBench Hard, 58,8 на JDI, устойчивость к перестановке вариантов 97,3% и порог уверенности с отказом от угадывания. Запуск от 8 ГБ, лицензия Apache-2.0, INT8 для NVIDIA и GGUF для AMD, Apple и CPU.
Подходит тем, кто строит локальные пайплайны с высокой частотой вызовов decision-модели: маршрутизация, фильтрация перед RAG, автооценка, модерация. Как универсальный ассистент она не работает, и ждать от 4B глубины 27B-модели не стоит. Все цифры производительности - замеры автора на одной RTX 6000 Ada; на вашей карте они будут другими.
Первый шаг практический: возьмите десяток своих реальных кейсов с известными правильными ответами, прогоните модель в подходящем для вашего железа формате и сравните с тем, что используете сейчас. Если задержка падает, а точность держится на приемлемом уровне, есть смысл расширять тест до полного пайплайна.