LiquidAI выпустила две decision-модели: d1-3B на базе LFM2.5-VL-3B и d1-omni-600M на базе LFM2.5-Encoder-350M. Обе не генерируют текст. Вы подаёте состояние (текст, JSON, изображения, а omni-версия ещё и до 30 секунд речи) и набор именованных вопросов, а на выходе получаете типизированные ответы за один forward pass с нулевыми выходными токенами. Ответ считывается напрямую из распределения модели по вариантам, без генерации и парсинга.
Коротко о главном. d1-3B заявлена как лучшая decision-модель до 10B по Decision Index 0.2.1 с результатом 48.57 против 47.11 у Decider 35B-A3B. Задержка решения заявлена на уровне 8 мс на NVIDIA RTX 4090, 9 мс на AMD MI325X и 30 мс на Apple M5 Pro. d1-omni-600M укладывается в 587M параметров и обрабатывает текст, картинки и речь одними и теми же весами trunk. Веса обеих моделей, включая GGUF-версии, опубликованы на Hugging Face.
Все цифры ниже приведены в формулировках разработчика: обсуждение релиза. Независимых измерений на момент публикации нет, и там, где это важно, я это отмечаю отдельно.
Что такое decision-модели и почему нулевые выходные токены - это важно
Decision-модель отвечает не текстом, а выбором из заданного набора вариантов. Вы формулируете вопросы заранее: «токсичный: да/нет», «категория: спам / вопрос / жалоба / нейтрально». Модель читает состояние и возвращает ответ по каждому вопросу. Нулевые выходные токены означают, что после forward pass не запускается авторегрессивная генерация: нет ни сэмплирования слов, ни разбора строки. Ответ берётся прямо из распределения модели по вариантам.
Практическая разница видна в агентных пайплайнах и RAG. Вместо того чтобы гонять большую LLM ради решения «вызывать инструмент или нет», вы получаете тот же ответ за миллисекунды и в проверяемом формате. Классификация, маршрутизация запросов, отсев нерелевантных документов перед подачей в контекст: везде, где нужен выбор, а не сочинение, decision-модель дешевле и предсказуемее.
Чем decision-модель отличается от обычной LLM
| Критерий | Обычная LLM | Decision-модель |
|---|---|---|
| Выход | Свободный текст | Один вариант из заданного списка, типизированный ответ |
| Скорость | Растёт с длиной ответа: каждый токен - отдельный шаг генерации | Один forward pass, шагов генерации нет |
| Стабильность | Формулировки плавают: «да», «конечно», «скорее всего» | Фиксированный набор вариантов и вероятность по каждому |
| Интеграция | Парсинг и валидация свободного текста | Готовый словарь ответов по именам вопросов |
Пример на пальцах. На вопрос «это спам?» обычная LLM может ответить «Да», «Похоже на спам», «Скорее всего, да, но не уверена». Decision-модель вернёт один из заранее заданных вариантов, и вам не придётся писать регулярку, которая переживёт все формулировки.
Похожую механику с вероятностями разбирали на примере Aplomb 1: там модель возвращает вероятность для каждого инструмента и аргумента, чтобы агент действовал на уверенных вариантах и передавал остальные более крупной модели.
Как работает forward pass без генерации
Схема такая: состояние (текст, JSON, картинки, речь) кодируется в эмбеддинги, к нему добавляются именованные вопросы, всё вместе проходит через трансформер, а decision head выдаёт распределение вероятностей по вариантам ответа. Дальше берётся argmax или сэмплирование из распределения. Авторегрессии нет, декодирования нет.
Отсюда три следствия. Задержка не зависит от длины ответа, потому что ответа-текста не существует. Поведение предсказуемо: один и тот же вход даёт один и тот же набор вариантов. Интеграция сводится к словарю, а не к разбору свободного текста. Название базовой модели d1-omni-600M, LFM2.5-Encoder-350M, указывает на энкодерный стек, что логично для архитектуры без авторегрессивной генерации; деталей архитектуры источник не раскрывает.
d1-3B: 3B-параметров для сложных решений на GPU
d1-3B построена на LFM2.5-VL-3B и рассчитана на серверные GPU. Модель принимает состояние из текста, JSON, изображений или их смеси и возвращает калиброванные типизированные ответы за один forward pass с нулевыми выходными токенами. Аудиомодальность для неё не заявлена: голос есть только у omni-версии.
Архитектура и мультимодальность d1-3B
Изображения и текст попадают в одно состояние. Vision-энкодер переводит картинки в эмбеддинги, они объединяются с текстовыми, дальше общий трансформер вместе с decision head выдаёт ответы на именованные вопросы. Разработчик отдельно подчёркивает мультимодальность как свойство модели: изображения и текст в одном состоянии, без переключения между разными моделями внутри пайплайна.
На практике вы задаёте вопросы к этому состоянию как к единому объекту. Условный вопрос «есть ли на фото дефект: да/нет» и вопрос «какая категория у этого обращения» обрабатываются одним вызовом, а не двумя разными моделями. Для агентных сценариев это сокращает число сетевых вызовов и точек отказа.
Бенчмарки и сравнение с конкурентами
LiquidAI заявляет d1-3B как лучшую decision-модель до 10B по Decision Index 0.2.1: 48.57. Для сравнения, Decider 35B-A3B получает 47.11, то есть модель на 3B обходит соперника с 35B. Заявлено также превосходство над всеми decision-моделями на 4B и 9B.
На 11 публичных image-бенчмарках результат 74.1 против 73.9 у базовой LFM2.5-VL-3B. Прирост есть, но небольшой, и это важно, если вы ждали качественного скачка именно на vision-задачах: основная ставка здесь на формат вывода и скорость, а не на новый уровень распознавания.
Все эти цифры идут от производителя (источник релиза). Независимых прогонов на момент публикации нет, методику Decision Index 0.2.1 источник не описывает. Воспринимайте результат как ориентир для выбора, а не как гарантию.
d1-omni-600M: edge-модель с поддержкой речи и изображений
d1-omni-600M - компактная версия того же подхода: 587M параметров на базе LFM2.5-Encoder-350M. Разбивка по блокам: 381M общий trunk и decision head, 94M vision-энкодер, 112M audio-энкодер. Источник называет модель 600M-моделью, тогда как в детализации фигурируют 587M; расхождение в материале не поясняется, и это стоит держать в голове при чтении округлённых цифр.
Как устроена мультимодальность в d1-omni-600M
Ключевая деталь: все модальности используют одни и те же веса trunk. Vision-энкодер и audio-энкодер только переводят вход в эмбеддинги, дальше последовательность обрабатывает общий стек, и уже decision head отдаёт распределение по вариантам ответа. Вы не держите в памяти три набора весов под три модальности и не платите за отдельную модель на каждый тип входа.
Что модель принимает: текст или JSON, изображения (с тайлингом для больших кадров и несколькими изображениями в одном состоянии) и до 30 секунд речи, всё за один forward pass. 30 секунд здесь означают жёсткий потолок для аудиоклипа: более длинные записи придётся нарезать на фрагменты и обрабатывать по частям.
Сценарии использования на edge-устройствах
Модерация голосового канала без облака, проверка кадров с камеры на наличие события, разбор сенсорных логов, маршрутизация запросов между моделями прямо на устройстве: задачи, где нужен один ответ по типу «да/нет» или выбор категории, а не текст. 587M параметров позволяют запускать модель на одноплатных компьютерах, мобильных чипах и встраиваемых системах.
Если бюджет памяти особенно жёсткий, посмотрите, как устроены 1-битные модели для edge: те же ограничения по VRAM решаются агрессивным квантованием весов, и decision-модель на 587M здесь выглядит более щадящим вариантом по умолчанию.
Скорость и требования к железу: где запускать d1-3B и d1-omni-600M
| Параметр | d1-3B | d1-omni-600M |
|---|---|---|
| Базовая модель | LFM2.5-VL-3B | LFM2.5-Encoder-350M |
| Параметры | 3B | 587M: 381M trunk и decision head, 94M vision, 112M audio |
| Модальности | Текст, JSON, изображения и их смесь | Текст, JSON, изображения, до 30 секунд речи |
| Заявленная задержка | 8 мс на RTX 4090, 9 мс на AMD MI325X, 30 мс на Apple M5 Pro | Не указана |
| Целевое железо | Серверные и десктопные GPU | Edge-устройства, мобильные чипы, одноплатники |
Сколько VRAM нужно для запуска
Точных требований к видеопамяти источник не публикует, поэтому цифры ниже - арифметическая оценка по числу параметров, а не замер. Веса d1-3B в FP16 займут около 6 ГБ, в GGUF-квантовании Q4 - примерно 2 ГБ плюс запас на контекст и промежуточные активации. У d1-omni-600M веса в FP16 укладываются примерно в 1,2 ГБ, в 4-битном квантовании - в доли гигабайта. Реальный расход зависит от длины состояния, числа изображений и количества вопросов в одном запросе.
Если ваша карта попадает в диапазон 4-12 ГБ, полезно сравнить decision-модель с компактными MoE-вариантами: разбор по MoE-моделям с ~2B активных параметров показывает, чем плотная архитектура отличается от разреженной при одном и том же объёме VRAM.
Задержка в реальных сценариях
8 мс - это время одного forward pass в условиях теста производителя, и в пайплайне к нему добавятся предобработка (токенизация, извлечение эмбеддингов изображений или аудио) и постобработка. Чем длиннее состояние и чем больше вопросов в одном вызове, тем больше вычислений на тот же forward pass. Задержки измерены на RTX 4090, AMD MI325X и Apple M5 Pro и автоматически на другое железо не переносятся.
Для d1-omni-600M цифр по задержке в источнике нет. Аудиоэнкодер добавляет работу на входе, но 587M параметров и общие веса trunk говорят о том, что модель проектировалась под устройства без дискретной видеокарты. Конкретные миллисекунды придётся мерить самостоятельно на своей платформе.
Как запустить и где скачать веса
Веса обеих моделей, включая GGUF-версии, опубликованы на Hugging Face. Дату релиза, лицензию и условия коммерческого использования источник не указывает, поэтому перед продакшеном откройте карточки моделей на Hugging Face: там же обычно лежит и промпт-шаблон, без которого decision-модель не выдаст ожидаемый набор вариантов ответа.
Запуск через llama.cpp и GGUF
GGUF - формат для запуска с частичной или полной выгрузкой на GPU через llama.cpp и совместимые рантаймы. Общая последовательность такая: скачать GGUF-файл, поднять рантайм, подать состояние и список вопросов по шаблону из карточки модели. Точный синтаксис команд в llama.cpp меняется от версии к версии, а официальную поддержку d1 в Ollama источник не подтверждает, так что рассчитывайте на llama.cpp и библиотеки вокруг него.
Интеграция в Python-проекты
Для Python есть два пути: transformers, если есть GPU и нужны полные веса, и llama-cpp-python или аналогичная обёртка для GGUF. Логика вызова отличается от привычной генерации: вы готовите состояние и список именованных вопросов, а на выходе получаете словарь с ответами, без обрезки текста по стоп-токенам и без ретраев на кривой парсинг. Чтобы понимать, где decision-модель заменяет вызов большой LLM, а где нет, полезно свериться с обзором open-weights релизов 2026 года.
Ограничения и на что обратить внимание
Когда decision-модель не подойдёт
Генерация текстов, диалог, пересказ, творческие задачи, объяснения и многошаговые рассуждения с промежуточными выводами: здесь decision-модель не помощник, потому что она физически не пишет текст. Она выбирает из вариантов, которые вы ей дали. Задачи, где она сильна, выглядят иначе: классификация, маршрутизация, извлечение структурированных ответов, проверки по чек-листу, отсев документов перед RAG.
Точность и калибровка
Формулировка вопросов становится частью качества системы. Если спросить «насколько это плохо» и дать варианты «плохо / очень плохо», модель выберет один из них даже тогда, когда правильный ответ не помещается в шкалу. Ответы жёстко привязаны к заданным вариантам, и плохой список вариантов не спасёт никакая архитектура.
Про калибровку вероятностей известно только со слов производителя: d1-3B возвращает калиброванные ответы. На данных, отличающихся от обучающих, уверенность модели стоит проверять на своей выборке, прежде чем строить на ней автоматические решения без человека в цикле.
Что ещё стоит учесть. Речь ограничена 30 секундами и доступна только в omni-версии. Бенчмарки (48.57 по Decision Index 0.2.1, 74.1 на image-бенчмарках, миллисекундные задержки) не подтверждены независимыми измерениями (детали релиза). Лицензия и дата релиза в источнике не указаны. Для сложных многошаговых рассуждений decision-модель проиграет генеративной LLM, и это нормальный сценарий их совместной работы: быстрый выбор на дешёвой модели, сложный разбор на большой.
Итог: кому и зачем нужны decision-модели LiquidAI
Decision-модели закрывают узкий, но частый класс задач: быстрый выбор из вариантов там, где генерация текста избыточна. d1-3B подойдёт серверным сценариям с GPU, где важны мультимодальность и калиброванные ответы, например проверка изображений и маршрутизация запросов между инструментами агента. d1-omni-600M рассчитан на edge: текст, картинки и до 30 секунд речи на устройстве без обращения к облаку.
Стартовать проще с omni-версии: 587M параметров и GGUF-сборки снижают порог входа, а простой сценарий вроде модерации комментариев или разметки кадров покажет, как модель ведёт себя на ваших данных. Дальше прогоните d1-3B на той же задаче и сравните точность и задержку. Начните с одного вопроса с двумя вариантами ответа, посмотрите на распределение вероятностей, и только потом расширяйте список вопросов.