Decision-модель Liquid AI d1-omni-600M запустили в браузере через WebGPU. Порт на библиотеку runntime сделал разработчик, который эту библиотеку и пишет: инференс идёт на чистом TypeScript поверх TypeGPU, без WASM и практически без этапа экспорта. Модель собрана из базовых операций, среди которых matmul, attention, нормализации и несколько поэлементных, а веса загружаются напрямую из safetensors на Hugging Face (сообщение автора порта).
Практическая часть порта - демо с имитацией ленты комментариев. Каждый комментарий прогоняется через модель по четырём вопросам: токсичный? спам? спрашивает что-то? какая общая тональность? Токсичные и спамовые сообщения удаляются из ленты автоматически. Скорость, которую называет автор: около 180 мс на комментарий по всем четырём вопросам, то есть примерно 45 мс на один вопрос.
Все цифры и детали ниже взяты из сообщения автора порта: независимых замеров в открытых источниках нет, а само демо работает на сгенерированной ленте комментариев, а не на реальном потоке данных.
Что такое Liquid AI d1-omni-600M и почему её запустили в браузере
d1-omni-600M - компактная модель от Liquid AI на 600 млн параметров. В сообщении о порте её называют decision-моделью. Разница с привычными LLM в назначении: модель не пишет связные тексты и не ведёт диалог, а отвечает на узкий прикладной вопрос - да или нет, к какой категории отнести вход, как оценить тональность. Такие модели встраивают в пайплайны как фильтр или классификатор, а не как чат-бота.
Ключевые особенности d1-omni-600M
- 600 млн параметров. Этот размер позволяет держать веса в памяти браузера и не требует дискретной видеокарты верхнего сегмента.
- Назначение - принимать решения по заданным вопросам, а не генерировать длинные тексты.
- Собрана из базовых операций: matmul, attention, нормализации и несколько поэлементных. Нестандартных слоёв, под которые пришлось бы писать отдельные ядра, тут нет.
- Веса лежат в safetensors на Hugging Face и загружаются напрямую, без промежуточной конвертации.
Отсюда и простота порта на WebGPU. Если архитектура состоит из стандартных операций, а веса лежат в открытом формате, перенос на новый бэкенд сводится к тому, чтобы аккуратно реализовать эти операции и связать их с загрузкой тензоров. Автор порта говорит об этом прямо: модель написана из core ops его библиотеки.
Почему запуск в браузере важен
Модерация комментариев на сервере означает, что каждый текст уходит наружу, на ваш сервер или в облачный API. Браузерный инференс убирает этот шаг: данные остаются на устройстве пользователя, сетевой round-trip исчезает, а расходы на GPU для инференса не ложатся на ваш бюджет. Для фильтрации пользовательского контента это меняет и экономику, и разговор о приватности.
Второй момент технический. WebGPU даёт браузеру доступ к GPU через стандартный API, и runntime использует именно его. Отсутствие WASM упрощает сборку: не нужно тащить бинарный бандл, следить за MIME-типами и границей между JavaScript и WASM-памятью. Код остаётся в одном языке - TypeScript.
Третий эффект - автономность. Модель, уже загруженная в браузер, работает без сети: это полезно для внутренних инструментов, редакционных панелей и приложений с нестабильным каналом. Как выглядят другие браузерные инференс-проекты, видно на примере LFM 2.5 на WebGPU со скоростью до 1440 токенов/с.
Как устроен runntime: WebGPU-инференс на чистом TypeScript без WASM
runntime - библиотека инференса, над которой работает автор порта. Технически это чистый TypeScript поверх TypeGPU, без WASM и практически без этапа экспорта. Модель не конвертируют в ONNX или отдельный бинарный формат: описание слоёв и вычислений собирается из тех же базовых операций, что и в оригинальной модели.
Остальные возможности runntime уже вышли и доступны: детекция объектов, сегментация, распознавание речи, эмбеддинги и другое. Порт d1-omni-600M в npm-релиз пока не попал (сообщение автора).
TypeGPU как основа для вычислений
TypeGPU позволяет описывать вычисления на GPU на TypeScript. Разработчик пишет ядра в привычной типизированной среде, а не вручную на WGSL: часть ошибок отсекается ещё на этапе типизации, а код остаётся читаемым. Для d1-omni-600M это значит, что matmul, attention и нормализации оформлены как обычные функции библиотеки, а не как набор шейдеров, написанных отдельно под каждую модель.
Второй эффект: код живёт в одном репозитории и одном языке. Нет прослойки из C++ и WASM, которую нужно собирать отдельным тулчейном, и нет отдельной отладки этой прослойки в браузере.
Загрузка весов из safetensors
Веса берутся напрямую из safetensors на Hugging Face. Формат хранит тензоры вместе с заголовком, в котором описаны типы и размерности, поэтому читать их можно без конвертации и без исполнения постороннего кода. Для браузера это убирает целый шаг: не нужно скачивать модель, прогонять её через скрипт экспорта и класть результат рядом с приложением. Обновилась версия модели на Hugging Face - подтягивается новая.
Практический кейс: live-модерация комментариев с помощью d1-omni-600M
Демо имитирует ленту комментариев и модерирует её в реальном времени. Каждый комментарий прогоняется через четыре независимых вопроса, и по ответам принимается решение: оставить сообщение или удалить.
Четыре вопроса для каждого комментария
- Токсичность: есть ли оскорбления, агрессия, переход на личности.
- Спам: реклама, повторяющиеся сообщения, ссылки на сторонние ресурсы.
- Наличие вопроса: требует ли сообщение ответа от автора поста или других участников.
- Общая тональность: позитив, негатив или нейтрально.
Дальше работает порог. Токсичное или спамовое сообщение удаляется, вопрос остаётся и может попасть в отдельную очередь на ответ, тональность влияет на сортировку или подсветку в интерфейсе.
На иллюстративных примерах логика такая: «Купите мои курсы, ссылка в профиле» уходит в спам и удаляется, «Как настроить WebGPU в Firefox?» остаётся как вопрос, сообщение с оскорблением удаляется по признаку токсичности, нейтральное замечание по теме остаётся в ленте. Это разбор схемы, а не результаты реального прогона: демо работает на сгенерированном потоке.
Производительность и задержки
Автор называет около 180 мс на комментарий для всех четырёх вопросов, то есть примерно 45 мс на один вопрос (сообщение автора порта). Если считать последовательно, десяток новых комментариев это порядка 1,8 секунды, а одиночное сообщение проходит проверку быстрее, чем пользователь успевает дописать следующее.
Замеры сделаны на текущей версии runntime, без отдельной настройки движка под эту модель. Автор ожидает, что скорость заметно вырастет после того, как движок подгонят под d1-omni-600M. Независимых бенчмарков на другом железе в открытых источниках нет, поэтому 180 мс стоит воспринимать как ориентир, а не как гарантированную цифру для вашего устройства.
Ограничения и что стоит учитывать перед внедрением
- Порт d1-omni-600M не входит в npm-релиз runntime, готового пакета нет.
- Демо работает на фейковой ленте комментариев, а не на реальном потоке данных.
- Цифры производительности приводит автор порта, независимых замеров нет.
- Decision-модель не рассчитана на генеративные задачи. Автор пробовал заставить её играть в змейку, и результат вышел неудачным. Это хороший маркер границ: просить у такой модели связный текст или стратегию игры - не её сценарий.
- WebGPU поддерживают не все браузеры, поэтому в продакшене нужен fallback: серверный инференс, WASM-вариант или отключение функции для неподдерживаемых клиентов.
Статус npm-релиза и доступность
Порт d1 пока живёт вне npm-релиза, остальные возможности runntime, включая детекцию, сегментацию, распознавание речи и эмбеддинги, уже доступны. Практический вывод: если нужна именно модерация на d1-omni-600M, проект придётся собирать из исходников и учитывать, что публичной документации и стабильного API может не быть. Для знакомства с самим подходом npm-части библиотеки достаточно.
Сравнение с другими решениями для браузерного инференса
ONNX Runtime Web и Transformers.js тоже запускают модели в браузере, но обычно идут через WASM. Это даёт широкую совместимость и зрелые инструменты конвертации, ценой этапа экспорта и дополнительного бинарного бандла. Разбор этого пути и форматов квантования есть в материале про Transformers.js v3, WebGPU и выбор dtype.
runntime выбирает другой компромисс: чистый TypeScript, прямая работа с WebGPU через TypeGPU, минимум промежуточных форматов. Плата за это - привязка к возможностям WebGPU и меньшая зрелость экосистемы. Соседние подходы видно по Bonsai-27B в браузере на 25-30 токенов/с и по набору WebGPU-кернелов от Hugging Face.
Для генерации текста модель на 600 млн параметров в браузере - не тот инструмент: там нужны другие архитектуры и другой объём памяти. Для классификации, фильтрации и модерации, где ответ укладывается в да/нет или короткую метку, подход работает.
Как попробовать d1-omni-600M в браузере
Требования к браузеру и железу
- Браузер с поддержкой WebGPU: актуальные Chrome и Edge, для остальных стоит отдельно проверять статус поддержки. Быстрая проверка - наличие объекта navigator.gpu в консоли разработчика.
- GPU с поддержкой WebGPU. Подходят современные дискретные и встроенные решения, но на слабых интегрированных чипах задержки будут заметно выше.
- Память под веса: если тензоры выложены в 16-битном формате, ориентир порядка 1,2 ГБ, в 8-битном - около 600 МБ. Точный размер зависит от того, в каком виде веса лежат в репозитории на Hugging Face.
Пошаговая инструкция по запуску демо
Готовых команд в исходном сообщении нет, поэтому последовательность зависит от текущего состояния репозитория автора. Общая схема такая:
- Поставить актуальную версию Node.js.
- Получить исходники runntime и установить зависимости проекта.
- Собрать проект локально: раз порт не в npm-релизе, готового пакета нет.
- Поднять локальный веб-сервер и открыть демо-страницу. WebGPU работает в защищённом контексте, поэтому нужен localhost или https: файл, открытый напрямую как file://, скорее всего не заработает.
- Дождаться загрузки весов из safetensors с Hugging Face: они подтягиваются на клиенте, серверная часть для этого не нужна.
- Подменить тестовый набор комментариев своим и посмотреть, как модель отвечает на примерах из вашего продукта.
Если цель - познакомиться с браузерным инференсом, а не именно с модерацией, проще начать с доступных возможностей runntime через npm: детекция, сегментация, распознавание речи и эмбеддинги там уже есть.
Итоги: кому и зачем нужен браузерный инференс d1-omni-600M
d1-omni-600M в браузере через runntime - рабочий пример компактной decision-модели, которая крутится на клиенте без серверов и без WASM. Модерация комментариев здесь прикладной сценарий: 180 мс на сообщение по четырём вопросам укладывается в интерактивный режим, а тексты пользователей не покидают устройство.
Кому смотреть в эту сторону:
- разработчикам, которым нужна клиентская фильтрация пользовательского контента без облачных API;
- продуктовым командам, где расходы на модерацию растут вместе с трафиком;
- тем, кто делает офлайн-приложения и расширения, работающие без сети.
Что мешает начать прямо сейчас: порт вне npm-релиза, демо на сгенерированных данных, отсутствие независимых бенчмарков и неполная поддержка WebGPU в браузерах. Ограничения снимаются по мере развития библиотеки, но продакшен стоит планировать с расчётом на fallback и на то, что цифры на вашем железе окажутся другими.
Практичный следующий шаг: проверить поддержку WebGPU в своём браузере, посмотреть уже доступные возможности runntime и прогнать на этом стеке свою модель или свой набор данных. Если модель собрана из базовых операций, как d1-omni-600M, шансы на удачный порт высоки.