Liquid AI d1 против Liquid AI d1-omni-600M: открытая модель принятия решений, которая слышит вас

Поищите название Liquid AI d1, и вы попадёте на модель с тремя миллиардами параметров, которая читает текст и изображения. Другой открытый чекпойнт в том же семействе в пять раз меньше, обрабатывает до тридцати секунд речи и является единственным из двух, который вообще способен принимать хоть какие-то решения насчёт голоса. Он называется Liquid AI d1-omni-600M, и если вы нашли это семейство через локальную библиотеку среды выполнения, а не через собственную документацию производителя, есть большая вероятность, что вы никогда не видели его названия. Именно эту ситуацию и призвано исправить это сравнение, потому что эти две модели — не конкурирующие ответы на один и тот же вопрос. Они — ответы на два разных вопроса, и только один из них предполагает слушание.

Все приведённые ниже показатели взяты из собственных материалов Liquid AI: карточки модели LiquidAI/d1-omni-600M, сопутствующего репозитория d1-omni-600M-GGUF и публикации о релизе от 7 октября, в которой были одновременно объявлены оба открытых чекпоинта. Строки с производительностью были оценены вендором по поддерживаемому им индексу, а не отправлены на публичное ранжирование, и в публикации прямо сказано, что специализированные бенчмарки для принятия решений на основе аудио остаются открытой проблемой. Ничто из этого не было воспроизведено кем-либо за пределами лаборатории.

Из чего состоят 587 миллионов параметров

Число в заголовке скрывает необычное разделение. Общее число параметров — 587M, и это не один стек: общий ствол на 381M с прикреплённой решающей головой, визуальный энкодер на 94M и аудиоэнкодер на 112M. Каждая модальность проходит через одни и те же веса ствола — именно это проектное решение позволяет держать всю конструкцию небольшой: модель — это не три модели в одном плаще, а один решающий ствол с двумя способами подачи в него.

Компоненты взяты из разных мест каталога Liquid. Основная часть происходит от LFM2.5-Encoder-350M — двунаправленного энкодера, а не от чисто декодерной линейки, из которой родом более крупный собрат. Визуальная башня — это SigLIP2, позаимствованная из LFM2.5-VL-450M, с адаптером и LoRA-обновлениями, применёнными к бэкбону. Аудиотракт — это 17-слойный энкодер FastConformer с собственным адаптером, дообученный при замороженном текстовом бэкбоне. В карточке указан контекст на 16 384 токена, общий для текстовых, визуальных и аудиопозиций вместе, при этом текст урезается до 896 токенов, когда присутствуют изображения, и словарь на 65 536 токенов — половина от 128 000 у более крупного собрата. На последнюю цифру стоит обратить внимание, если вы работаете с языком, который это семейство покрывает лишь частично.

Двунаправленность в сравнении с decoder-only — вот почему эти две модели ощущаются по-разному для любого, кто запускал обе. Ствол в форме энкодера читает всё состояние сразу, в обоих направлениях, прежде чем что-либо выдать. Вариант в форме декодера читает вперёд так, как это делает языковая модель. Обе обучены сообщать ответы из распределения при нулевом количестве выходных токенов, поэтому ни одна не пишет текст, — но лежащая в основе машинерия относится к другому классу моделей, а обсуждаемый ниже разрыв в точности — это видимая цена более компактной конструкции в форме энкодера.

Тридцать секунд речи, и нечем её оценить.

Аудио — причина существования этой контрольной точки. Она принимает один клип длительностью до 30 секунд, 16 кГц моно, в том же прямом проходе, который выдаёт ответ, и это единственный член семейства с открытыми весами, способный на это. Для работы на устройстве это не второстепенная функция. Камера, которая отмечает дефект на производственной линии, — это задача компьютерного зрения, с которой уже справляется более крупный собрат; устройство, которое маршрутизирует голосовой запрос, классифицирует высказывание или решает, просит ли звонящий о возврате средств, — это задача, на которую можно нацелить только эту модель.

На эту возможность накладываются два ограничения, и оба задокументированы, а значит, нет оправдания спотыкаться о них в продакшене. Во-первых, один запрос несёт изображения или аудио, но никогда и то и другое — передача обоих вызывает ValueError, вместо того чтобы тихо отбросить одно, поэтому сбой заметен и легко обнаруживается при тестировании. Во-вторых, аудиоветка обучалась на обменах репликами между англоязычным говорящим и ассистентом, причём клипы обрезались до 30 секунд. Это одна конфигурация говорящих, одна структура реплик и одно распределение акцентов. Направить её на записи колл-центров или полевые аудиозаписи — значит требовать поведения, которое карточка не заявляет, и это ровно тот пробел, который выявил бы бенчмарк, если бы он существовал.

Ни одного не существует. В посте о релизе специализированные бенчмарки для принятия аудиорешений названы «на данный момент открытой проблемой», и сообществу предлагается создать такой бенчмарк — откровенное заявление для лаборатории и реальное ограничение для всех, кто оценивает модель. Liquid AI d1-omni-600M приходится оправдывать себя за счёт возможности, которую пока никто не может измерить. Производитель также полностью не раскрыл показатели инференса, объяснив это тем, что модель — ранний исследовательский релиз, находящийся в активной разработке. Так что цифр задержки для 600M нет вообще — ни для текста, ни для зрения, ни для аудиопути, ради которого всё и затевалось.

Всё, что можно сказать, ничего не выдумывая, — это арифметика на основе опубликованного количества параметров: при точности float16, которую карточка рекомендует для GPU, 587 млн параметров — это порядка 1,2 ГБ весов до активаций, против примерно 6,2 ГБ у родственной модели на 3,12 млрд при той же точности. В карточке также есть предупреждение о точности, которое легко пропустить при беглом просмотре — и пропускать его не стоит: модель обучалась в float32, для GPU рекомендуется float16, а bfloat16 во время тестирования изменил лучший ответ в некоторых строках. Если ваш стек обслуживания по умолчанию использует bfloat16, то это модель, для которой такое значение по умолчанию небезопасно.

Почему меньшую половину семьи легко не заметить

Причина, по которой читатель доходит до 3B и останавливается, структурная, а не случайная. В индексе документации Liquid AI под decision models перечислены три строки, и они читаются неодинаково: d1-3B и d1-omni-600M содержат ссылки Hugging Face и GGUF, а в столбце trainable стоит «No», тогда как d1 находится в отдельной строке, где на месте ссылок для скачивания, которые были бы у всех остальных моделей, стоят просто буквы «API». В посте о релизе d1 обозначается как название семейства, и в нем никогда не различаются обслуживаемый эндпоинт и открытый чекпойнт. Локальные runtime-библиотеки затем берут 3B, потому что именно у него размер и количество модальностей совпадают с записью, которую они хотят опубликовать, а 600M вообще не появляется в том же списке.

Результат — это семейство, чья опубликованная история доступа при беглом чтении выглядит как одна модель и одна строка API. На самом деле предлагаются два открытых чекпоинта с разными стволами, разными модальностями и разрывом в 32 пункта между их оценками в собственном индексе вендора, плюс хостируемый эндпоинт, связь которого с любым из этих чекпоинтов вендор никогда не подтверждал. 600M ничем не скрыта. У неё просто нет имени, которое поиск по запросу d1 выдаст, и это единственная из двух, которая слышит.

Баллы, которые существуют, и единственная колонка, которую стоит прочитать

На Decision Index 0.2.1 поставщик сообщает 15,95 для Liquid AI d1-omni-600M против 48,57 для его более крупного собрата — разрыв настолько велик, что итог почти бесполезен как основа для выбора. Суб-оценки информативнее суммы, и одна из них действительно удивляет.

• Знания — 8,3 против 23,8

• Язык — 12.9 против 56.4

• Поиск — 35,0 против 52,8

• Инструменты — 15,1 против 74,5

• Искусства — 6,8 против 36,3

Поиск — это то, где малая модель не сдаёт позиции: она теряет менее трети оценки более крупной модели, тогда как в остальных четырёх столбцах она теряет 60–80 процентов. Эта закономерность соответствует тому, в чём обученный энкодер должен быть силён: сопоставление состояния с содержимым близко к тому, для чего создавался ствол, и гораздо меньше зависит от многослойной языковой способности, которую декодероподобный собрат унаследовал от куда более масштабного предобучения. Столбец «Инструменты» — прямо противоположная история, и разрыв в 59 пунктов в этом столбце — это число, на которое стоит пристально смотреть, если ваша рабочая нагрузка заключается в маршрутизации запроса к нужной функции.

На семи публичных текстовых бенчмарках картина смягчается. Производитель сообщает среднее 78,4 для 600M против 82,9 для 3B, при этом меньшая модель немного уступает на SQuAD 2.0 (74,0 против 85,3), PubMedQA (61,3 против 66,0), BoolQ (77,7 против 86,7) и XNLI (74,7 против 85,0), но выигрывает в обнаружении токсичности Civil Comments (95,8 против 93,0) и идентификации парафраз PAWS-X (79,5 против 76,9). Сама Liquid формулирует это так: 600M превосходит средний показатель 77,1 у 2B-модели принятия решений, располагая лишь четвертью параметров. Два набора бенчмарков дают два разных кажущихся вердикта, причём оба основаны на самоотчётах, и честная интерпретация состоит в том, что ни один из них ничего не решает в отношении аудиотракта, поскольку аудиотракт отсутствует в обоих наборах.

Где эти двое на самом деле встречаются

При всех различиях модель программирования идентична, и именно это делает их взаимозаменяемыми в одном конкретном смысле. Обе отвечают на вопросы noul, выбора и оценки по состоянию, обе возвращают выбранный ответ с картой вероятностей и значением уверенности от 0 до 1, и обе сообщают output_tokens: 0. Поле уверенности — это то, которое люди понимают неправильно: оно измеряет, насколько сильно вероятности благоприятствуют одному ответу, а не шансы на то, что ответ верен. 0,96 на плохо поставленный вопрос — это уверенный неправильный ответ, и это поле вас не предупредит.

На практике они встречаются в виде каскада. Проводите первичную фильтрацию с помощью Liquid AI d1-omni-600M — дёшево, локально и с охватом аудиослучаев, с которыми не справится ни один скорер, работающий только с текстом, — затем эскалируйте элементы, которые он относит ближе к середине своей шкалы, к более крупному чекпойнту для более точного вердикта. Правила эскалации — это уверенность и распределение, которые 600M уже возвращает, поэтому логике маршрутизации не требуется дополнительная модель, и при рабочей нагрузке, в которой явно преобладают лёгкие элементы, большая часть трафика вообще не достигает второй стадии. Такая композиция работает, потому что обе модели возвращают объект одного и того же типа. Две произвольные модели — нет.

Если этот каскад когда-либо управляет вызовом генеративной модели, которую вы арендуете, а не запускаете, то слой под ним — это место, где инфраструктура становится интересной, и именно здесь появляемся мы. Маршрутизация решения через цепочку моделей — это именно та задача, для которой предназначено правило маршрутизации: OrcaRouter объединяет несколько моделей за одной конечной точкой, совместимой с OpenAI, каждая по списочной цене провайдера, переданной с 0% наценки, с автоматическим переключением при сбое между провайдерами так что эскалация, которая терпит неудачу на уровне провайдера, повторяется на резервном варианте вместо того, чтобы запрос завершился ошибкой. Мы не размещаем никакую модель Liquid AI — мы проверили это перед написанием — так что ничто выше не является утверждением о вызове этих весов через нас. Суть в том, что модель принятия решений — это дешёвая часть конвейера, а заимствованная модель на другой стороне — это та часть, которая выходит из строя.

Откуда берется файл, если вы хотите запустить его сегодня

Для локального развёртывания собственный GGUF-репозиторий производителя для 600M содержит Q8_0 размером 407 МБ, а F16 и BF16 — по 764 МБ каждый, при этом 4-битная сборка не указана, поэтому самая маленькая официальная загрузка примерно в семь раз меньше соответствующей сборки более крупной модели и примерно такого же размера, как фотография среднего разрешения. В собственном примере карты запускается сервер llama.cpp с флагами пакетной обработки 4096 и предлагается увеличить их до 16384 для более длинных состояний, после чего выполняется запрос к тому же эндпоинту /v1/systemone, который использует более крупный собрат.

Единственное, чего локальный маршрут вам не даёт, — это цифры по аудиопути, потому что их не существует. Если вы собираетесь запускать речь через это перед реальными пользователями, оценку придётся строить вам: размеченный набор клипов, те же три типа вопросов и измеренная доля правильных ответов по каждому классу. Это не отмахивание от модели — чекпоинт на 587M, который за один проход принимает решение по голосовому клипу, — это действительно другой инструмент по сравнению с текстовым классификатором, прикрученным к этапу транскрипции, и он заслуживает настоящего теста, а не теста, основанного на ощущениях.

Если этот каскад когда-нибудь станет шлюзом для вызова генеративной модели, которую вы арендуете, а не запускаете сами, OrcaRouter объединяет несколько моделей за одной конечной точкой, совместимой с OpenAI, каждая по прейскурантной цене своего провайдера, передаваемой с наценкой 0%.

Выбор омни-чекпоинта вместо текстового — также хороший повод посмотреть, что уже пошло не так в этом классе: задокументированные инциденты с ИИ и сбои агентов, связанные с небольшими мультимодальными моделями, собраны в OrcaRouter AI Incident Archive, где каждая запись содержит собственные источники, степень серьёзности, оценку уверенности и флаг спорности.