LiquidAI выложила LFM3-Omni-2B в формате GGUF, и поддержка этой архитектуры в llama.cpp появилась в день анонса. Пост об этом опубликован 27 октября 2026 года в r/LocalLLaMA: автор благодарит участника с ником tdakhran за оперативную координацию релиза рантайма и команду LiquidAI за саму модель (исходный пост).
Суть в двух пунктах. Первый: это омни-модель на 2B параметров, то есть один чекпоинт закрывает текст и речь, а не только текстовый чат. Второй: по утверждению автора поста, это первая открытая модель от передовой лаборатории с поддержкой польского TTS и STT. Формулировка принадлежит автору поста, независимого подтверждения в исходнике нет, поэтому держим её в голове с поправкой на источник.
Отдельно про размер. В посте сказано, что всё упаковано в "compact 2B package that makes it viable for on-device deployment", то есть 2B задуманы как размер, при котором модель держат на устройстве, а не только в облаке. Ниже: что именно подтверждено, как запускать, чего ждать по памяти и где ограничения.
Что такое LFM3-Omni-2B-GGUF и почему о ней говорят
LFM3-Omni-2B относится к линейке LFM (Liquid Foundation Models) от LiquidAI. Это не первый GGUF-релиз лаборатории: раньше она выкладывала decision-модели d1-3B и d1-omni-600M в том же формате, о них есть отдельный разбор с инструкцией по локальному запуску.
GGUF в названии означает формат файла: веса и метаданные в одном контейнере, который читают рантаймы вроде llama.cpp и Ollama. Практический смысл в том, что модель не нужно конвертировать самому и тащить Python-стек с CUDA-зависимостями. Скачали файл, запустили рантайм, получили инференс.
GGUF обычно публикуют в нескольких квантованиях, от почти исходного Q8_0 до заметно урезанных вариантов вроде Q4_K_M. Чем сильнее сжатие, тем меньше файл и тем выше шанс, что модель начнёт путаться в редких словах и числах. Для речевых задач это критичнее, чем для чата: ошибки распознавания и сломанная интонация в синтезе вылезают раньше, чем деградация на простом тексте. Список доступных квантований смотрите в карточке модели, в исходном посте его нет.
Омни-модель vs обычная LLM: в чём разница
Обычная текстовая LLM принимает токены и возвращает токены. Голосовой сценарий на ней собирают из трёх частей: STT превращает речь в текст, LLM отвечает текстом, TTS озвучивает ответ. Каждый компонент - отдельная модель со своими весами, форматами входа и аппетитом к памяти.
Омни-модель держит несколько модальностей в одном чекпоинте. Для LFM3-Omni-2B в исходнике прямо названы TTS и STT, про изображения, видео и прочие модальности данных нет. Приписывать модели зрение не стоит только потому, что слово «омни» намекает на всё сразу. Как устроен омни-подход и какие сценарии он открывает, подробно разобрано в материале про Qwen3.8-Omni-Flash и мультимодальные модели.
Цена компактности предсказуема. Один чекпоинт на 2B параметров дешевле по памяти и проще в интеграции, чем три отдельные модели. Каждая модальность внутри него при этом, как правило, слабее лучшего специализированного решения того же класса. Это общее свойство small-моделей: на 2B параметров невозможно одновременно догнать крупную LLM и большой STT-энкодер.
Почему релиз называют «zero-day» в llama.cpp
«Zero-day» здесь про скорость, а не про уязвимость. Поддержку архитектуры добавили в llama.cpp в день анонса модели, координацию автор поста приписывает tdakhran. Обычно между публикацией весов и рабочим запуском в llama.cpp проходят недели или месяцы: кто-то описывает архитектуру, добавляет её в код, проходит ревью, дожидается сборки. Здесь этот этап сжали до нуля.
Практический смысл простой. GGUF-файл бесполезен, если рантайм не знает архитектуру: пользователь получает ошибку при загрузке и ждёт. С поддержкой модель проверяется в тот же вечер. Точных дат и сроков в исходнике нет, есть только формулировка про релиз в день анонса.
Польский TTS и STT: в чём новость и насколько ей верить
Ключевая фраза исходного поста: это первая открытая модель от передовой лаборатории с поддержкой польского TTS и STT (пост в r/LocalLLaMA). Читать её нужно как заявление автора, а не как проверенный факт. Сравнения с другими открытыми моделями в посте нет, критерий «передовая лаборатория» тоже не определён.
Ценность заявления в охвате языков. Английский закрыт открытыми речевыми моделями плотно: класс Whisper для STT, десятки TTS-проектов. Польский встречается реже, и рабочая модель с распознаванием и синтезом в одном чекпоинте закрывает нишу, где раньше приходилось собирать пайплайн из разнородных инструментов или уходить в облако.
Чего в исходнике нет: ни одного примера польской речи, ни метрик WER для STT, ни оценки естественности синтеза, ни сравнения с альтернативами. Любые цифры качества придётся получать самому.
Что известно о поддержке других языков
Ничего конкретного. В исходном посте упомянут только польский, полного списка языков нет. Додумывать покрытие русского, английского или украинского нельзя: у мультиязычных small-моделей языки распределены неравномерно, и заявленная поддержка одного ничего не говорит о соседних.
Порядок проверки: открыть карточку модели в репозитории LiquidAI и README llama.cpp, найти перечень поддерживаемых языков и форматы аудио, затем прогнать собственные записи на нужном языке. Если в документации языка нет, рассчитывать на него не стоит, даже когда модель выдаёт что-то осмысленное на пробном примере.
Как запустить LFM3-Omni-2B-GGUF локально через llama.cpp
Дальше общий порядок действий, а не готовый рецепт под конкретную сборку. Флаги и способ подачи аудио в llama.cpp меняются между версиями, поэтому перед запуском сверяйтесь с README и примерами в репозитории проекта.
- Обновить llama.cpp. Поддержку LFM3-Omni-2B добавили недавно, старые сборки архитектуру не знают. Соберите из свежего исходника или возьмите свежий релиз. Для сборки понадобятся CMake и компилятор, для ускорения на GPU - бэкенд CUDA, Metal или Vulkan под вашу платформу.
- Скачать GGUF. Файл лежит в официальном репозитории LiquidAI с именем LiquidAI/LFM3-Omni-2B-GGUF. Квантование выбирайте под доступную память: Q8_0 ближе к исходным весам, Q4_K_M компактнее и быстрее, но с потерей точности.
- Проверить текстовый режим. Начните с обычного промпта через llama-cli. Если текст работает, архитектура загрузилась правильно, и можно переходить к звуку.
- Поднять llama-server. Для интеграции с приложением удобнее HTTP-сервер: один раз запустили, дальше стучитесь запросами. Набор параметров и полей запроса смотрите в документации к вашей версии.
- Подать аудио. Аудиовход в llama.cpp обслуживают мультимодальные утилиты, их состав и флаги зависят от сборки. Формат файла, частоту дискретизации и число каналов сверяйте с README, а не с примерами из старых руководств.
Шаблон команды для проверки текстового режима выглядит так. Это иллюстрация синтаксиса, путь к файлу и параметры подставьте свои.
llama-cli -m /path/to/model.gguf -p "тестовая фраза"Что понадобится перед запуском
- свежая сборка llama.cpp с поддержкой архитектуры;
- GGUF-файл модели из официального репозитория;
- десяток WAV-записей на польском для теста STT и текстовые фразы для проверки TTS;
- утилита конвертации аудио, если исходники в mp3 или m4a;
- запас свободной RAM или VRAM под веса, контекст и аудио-буферы.
Про формат входа: мультимодальные утилиты llama.cpp ждут конкретный контейнер и частоту дискретизации, при несовпадении выдают мусор без внятной ошибки. Требования смотрите в README под свою версию. Общие подводные камни запуска GGUF-моделей разобраны в обзоре набора GGUF-моделей от LLMFan46.
Типичные ошибки при первом запуске
- Устаревшая сборка. Симптом: рантайм не узнаёт архитектуру или падает при загрузке. Лечится обновлением, а не подбором флагов.
- Неверный аудиоформат. Не та частота, стерео вместо моно, сжатый контейнер. Распознавание выдаёт бессмыслицу, и легко решить, что модель плохая.
- Нехватка памяти. Квантование выбрали по размеру файла, но забыли про контекст и аудио-буферы. Начните с более агрессивного сжатия и коротких аудио.
- Путаница режимов. Текстовый промпт уходит в речевой пайплайн или наоборот. Держите текстовый и аудио-сценарии раздельно, пока оба не заработают.
- Сборка без нужного бэкенда. Собрали без CUDA или Metal и удивляетесь скорости на CPU.
Принцип диагностики простой: сначала текст, потом аудио, на каждом шаге сверка с README актуальной версии. Конкретные тексты ошибок не привожу, они зависят от сборки.
Требования к железу: что реально нужно для 2B-модели
Замеров RAM и VRAM для LFM3-Omni-2B в исходнике нет, поэтому считаем от числа параметров. Два миллиарда весов в 8-битном квантовании дают около 2 ГБ только на веса, в 4-битном - около 1 ГБ, плюс метаданные. Это арифметика, а не замер: реальный размер файла смотрите в карточке модели.
К весам добавляется контекст: KV-cache растёт с длиной контекста и числом слоёв. Дальше аудио-буферы и оверхед рантайма. Рабочая формула: память ≈ размер GGUF + KV-cache под нужный контекст + запас на аудио + небольшой резерв сверху. Для омни-модели запас на аудио важнее, чем для чисто текстовой.
Автор поста описывает модель как "compact 2B package that makes it viable for on-device deployment" (исходный пост). Из этой формулировки следует только одно: по мнению автора, размер позволяет запуск на устройстве. Замеров скорости на конкретном железе в посте нет.
On-device сценарии: где это оправдано
- Офлайн-ассистент на польском: распознавание, ответ и озвучка без отправки аудио наружу.
- Приватная обработка записей: встречи, звонки, заметки, которые нельзя отдавать в облачный API.
- Прототипы голосовых интерфейсов: быстро проверить сценарий voice-to-voice на одном чекпоинте.
- Десктопные приложения и мини-ПК, где 2B-модель укладывается в память с запасом под контекст.
Границы по железу. Ноутбук или мини-ПК с 8-16 ГБ памяти - реалистичная площадка. Одноплатник класса Raspberry Pi с 8 ГБ файл формально вместит, но на CPU-ядре цикл «распознавание, генерация, синтез» будет заметно медленнее, и об интерактивности придётся договариваться отдельно. Микроконтроллеры и бюджетные телефоны для 2B-модели не площадка.
Где локальный запуск не оправдан
- Нужно качество распознавания на десятке языков и на шумных записях: специализированные STT-сервисы или крупные открытые модели дадут больше.
- Жёсткие SLA и предсказуемая задержка: облачный API с гарантиями проще, чем самостоятельная сборка llama.cpp.
- Нет времени на обновление рантайма и отладку аудиоформата: первый запуск потребует возни.
- Нужны подтверждённые метрики под конкретную задачу: публичных замеров по этой модели пока нет.
2B - компромисс между памятью и качеством. Для черновика транскрипта на польском его может хватить, для конвейера с юридическими последствиями вряд ли.
Ограничения LFM3-Omni-2B, о которых стоит знать заранее
- Заявление про первую модель с польским TTS/STT - мнение автора поста без сравнения с другими открытыми моделями.
- Качество польского TTS/STT не подтверждено. Ни примеров, ни метрик, ни слепых сравнений в источнике нет.
- Другие языки не раскрыты. Полного списка языков в исходнике нет.
- Архитектура и набор модальностей не детализированы. Известны TTS и STT, про зрение и видео данных нет.
- «Zero-day» говорит о скорости релиза поддержки, а не о стабильности. Свежая интеграция в llama.cpp означает и свежие баги.
- 2B-класс ограничивает глубину рассуждений и чувствителен к квантованию: чем сильнее сжатие, тем заметнее ошибки на числах, именах и диакритике.
Качество польского TTS/STT: что проверять самому
Без собственного теста опираться на заявление из поста нельзя. Минимальный чек-лист:
- STT на своих записях. 10-20 фраз: чистая студия, шум улицы, телефонный канал, разные дикторы, включая женский и мужской голос.
- Сложные места. Числа, даты, имена, топонимы и диакритика (ą, ć, ę, ł, ń, ó, ś, ź, ż). Small-модели сыпятся на них первыми.
- Ручная сверка. Считайте WER на своём наборе вручную или скриптом и сравнивайте с базовой линией, например со специализированным STT класса Whisper.
- TTS на слух. Типичные фразы, длинные предложения, числительные, аббревиатуры. Слушайте интонацию, паузы, ударения и произношение заимствований.
- Стабильность. Прогоните одну фразу несколько раз: повторы, обрывы и уплывающая интонация видны только на серии.
Результаты записывайте в таблицу: фраза, тип шума, ожидаемый текст, полученный текст. После двух десятков примеров станет ясно, где модель ломается.
Омни-модель vs специализированные TTS/STT: что выбрать
Сравниваем не абсолютное качество (данных по LFM3-Omni-2B нет), а инженерные свойства пайплайна.
| Критерий | Омни-модель на 2B | Связка STT + LLM + TTS |
|---|---|---|
| Компоненты | Один чекпоинт и один рантайм | Три модели, три формата, часто три рантайма |
| Память | Одни веса на все модальности | Сумма весов всех компонентов |
| Гибкость | Меняется только вместе с моделью | Каждый компонент заменяется отдельно |
| Качество модальности | Не подтверждено, ожидаемо ниже лучших специализированных решений | Можно взять сильнейший инструмент в каждом классе |
| Отладка | Одна точка отказа и одна точка диагностики | Ошибка локализуется по этапам |
| Языковой охват | Зависит от одного чекпоинта | Подбирается под язык на каждом шаге |
Практический вывод: омни-модель выигрывает там, где важны компактность и минимум движущихся частей, например во встраиваемом ассистенте или прототипе. Связка специализированных моделей выигрывает там, где критично качество каждой модальности и есть память под несколько моделей.
Про ориентиры: Whisper остаётся популярной базой для STT, и польское распознавание логично сравнивать именно с ним. Превосходство или отставание LFM3-Omni-2B относительно Whisper в исходнике не заявлено, так что вопрос закрывается только собственным тестом.
Кому стоит попробовать LFM3-Omni-2B-GGUF уже сейчас
Стоит попробовать, если:
- вы работаете с польским языком и нужен офлайн-сценарий распознавания и синтеза;
- уже используете llama.cpp и умеете собирать рантайм из исходников;
- нужен прототип голосового интерфейса на одном компактном чекпоинте;
- готовы сами измерять качество, а не опираться на формулировки из анонса.
Стоит подождать, если:
- нужна гарантированная мультиязычность и понятный список поддерживаемых языков;
- есть требования к SLA и предсказуемой задержке;
- для решения нужны опубликованные метрики, а не собственные замеры;
- нет времени на отладку аудиоформата и свежих багов интеграции.
LFM3-Omni-2B-GGUF интересна как компактный омни-эксперимент и как сигнал, что омни-модели перебираются на устройство. Заявления про польский TTS/STT и «первую открытую модель от передовой лаборатории» проверяются только практикой.
Следующий шаг конкретный: обновить llama.cpp до свежей сборки, скачать GGUF из официального репозитория LiquidAI, прогнать десяток своих польских записей через STT и послушать синтез на типичных фразах. Результаты этого теста и будут ответом, подходит ли модель под вашу задачу.