Liquid AI выпустила две новые небольшие модели-энкодеры, LFM2.5-Encoder-230M и LFM2.5-Encoder-350M, на Hugging Face, позиционируя их как NLP-модели для длинного контекста, способные обрабатывать нагрузки на уровне документов на CPU, а не требовать более крупных GPU-ориентированных развертываний. Согласно объявлению компании в Hugging Face Blog, новые модели поддерживают входы до 8 192 токенов и предназначены для производственных задач, таких как классификация, проверки политик, маршрутизация и обнаружение PII.

Запуск важен потому, что многие корпоративные NLP-задачи по-прежнему работают вне текущего внимания к большим языковым моделям. Фильтры безопасности, классификаторы входящих запросов, маршрутизаторы намерений и инструменты комплаенса часто непрерывно обрабатывают длинные документы с низкой маржой, и поэтому стоимость оборудования и задержка становятся важнее, чем качество генерации в стиле чат-бота. Позиция Liquid AI состоит в том, что эти энкодерные нагрузки можно перенести на существующую CPU-инфраструктуру, оставаясь конкурентоспособными по отношению к более крупным или более известным альтернативам, таким как ModernBERT.

Что выпустила Liquid AI и где это находится

В релиз входят две модели: LFM2.5-Encoder-230M и LFM2.5-Encoder-350M. Liquid AI описывает их как энкодеры общего назначения, а не узкие модели для извлечения, хотя они относятся к той же семье, что и более ранние LFM2.5-Retrievers. Компания говорит, что новые модели были предварительно обучены на masked-language objective, чтобы их можно было дообучать на более широком наборе задач, включая классификацию текста, разметку токенов и поиск.

Это различие важно для продуктовых команд, выбирающих между embeddings, retrievers и encoders. Модель извлечения может быть достаточной для многоязычного поиска, но корпоративные процессы часто требуют решения на уровне всего документа или токена: маршрутизации заявок в поддержку, проверки нарушений политик или поиска персонально идентифицируемой информации. Примеры Liquid AI явно ориентированы на такие сценарии. В объявлении компания подчеркнула демо zero-shot prompt routing, zero-shot policy linting, многоязычного обнаружения PII и даже эксперимент по генерации текста с masked diffusion, всё это работало в CPU-only Hugging Face Spaces.

Модели происходят из архитектуры LFM2 компании Liquid AI. По словам компании, энкодеры были инициализированы из декодерных backbone LFM2.5-230M и LFM2.5-350M, а затем преобразованы из каузальных декодеров в двунаправленные энкодеры путём изменения attention mask, делая короткие свёртки некаузальными и обучая их с masked language modeling. Liquid AI утверждает, что сначала обучала модели для языковой компетентности на коротком контексте в 1 024 токена, а затем адаптировала их к контексту в 8 192 токена на более широком наборе данных, чтобы усилить фактическую, юридическую и многоязычную производительность.

Почему производительность на CPU — главная история

Главный тезис касается не только качества бенчмарков, но и пропускной способности на длинных последовательностях. Liquid AI утверждает, что её энкодеры особенно сильны на CPU, где задержка длинного контекста часто становится решающим фактором стоимости внедрения. В собственном сравнении компании LFM2.5-Encoder-230M был быстрее ModernBERT-base на всех протестированных длинах последовательностей и примерно в 3,7 раза быстрее на 8 192 токенах.

Конкретный пример в Hugging Face Blog примечателен тем, что переводит скорость бенчмарка в операционное сообщение: полный контракт, стенограмма или длинная цепочка поддержки могут быть обработаны менее чем за 30 секунд на CPU ноутбука, тогда как ModernBERT-base при той же длине контекста требует более полутора минут. Для многих корпоративных команд это меняет вопрос о том, достаточно ли дёшево обходится классификация длинных документов для регулярного использования.

На GPU Liquid AI сообщает о более узком преимуществе. По словам компании, ModernBERT-base остаётся впереди ниже примерно 1 000 токенов на Apple GPU, тогда как модели LFM2.5-Encoder выходят вперёд примерно на 2 000 токенах и выше. Эта картина подчёркивает предполагаемую рыночную позицию: это не обязательно самый быстрый вариант для любого короткого входного сценария, но они продвигаются как решение для длинного контекста и always-on инференса, где важна экономика CPU.

Такое позиционирование также отражает более широкое разделение в ИИ-инфраструктуре. Генеративные модели по-прежнему привлекают основное внимание, но многие production-системы полагаются на более маленькие модели, которые оценивают, классифицируют, фильтруют и маршрутизируют текст до или вокруг вызова большой модели. Если такие модели могут работать локально или на обычных CPU, разработчики смогут снизить затраты, улучшить возможности по размещению данных и уменьшить зависимость от доступности GPU.

История архитектуры совпадает с более широкими тенденциями дизайна длинного контекста

Хотя анонс Liquid AI сосредоточен на моделях-энкодерах, второй источник в этом наборе, публикация NVIDIA Developer Blog о дизайне attention для длинного контекста, помогает понять, почему релиз выходит именно сейчас. NVIDIA утверждает, что по мере того, как агентные и длинноконтекстные нагрузки становятся всё более распространёнными, attention всё больше доминирует в стоимости инференса, делая архитектурные решения модели важнейшим фактором производительности.

Пост NVIDIA не посвящён Liquid AI и фокусируется на GPU-инференсе, а не на CPU-first развертывании. Тем не менее его ключевая мысль напрямую релевантна: производительность на длинном контексте определяется архитектурными решениями, такими как размер группы, размерность головы и управление KV-состоянием, а не только инженерией kernel-ов. В посте рекомендуется hardware-conscious проектирование attention, включая более крупный размер группы для эффективности декодирования, размерности голов, согласованные с памятью GPU и размерами тайлов, а также уменьшение эффективного KV-состояния через сжатие или sparse и hybrid attention подходы. NVIDIA приводит TensorRT-LLM и архитектуры вроде NVIDIA Nemotron 3 как примеры такого co-design подхода.

Этот более широкий контекст делает запуск Liquid AI чем-то большим, чем обычная загрузка модели. Компания, по сути, утверждает, что та же логика эффективности attention, которая движет co-design для GPU, может дать практическую выгоду и для CPU-ограниченных энкодерных нагрузок. Liquid AI говорит, что LFM2.5-Encoders унаследовали от backbone LFM2.5 свойство, при котором стоимость медленно растёт с увеличением длины входа. Для пользователей, оценивающих корпоративные ИИ-системы, это часто ценнее, чем пиковая производительность на коротких синтетических задачах.

Доказательства, бенчмарки и то, что по-прежнему заявлено самим вендором

Самые сильные заявления о производительности в этой истории исходят от вендора. Результаты качества и сравнения скорости взяты из собственного поста Liquid AI в Hugging Face Blog, а не из независимой бенчмарк-лаборатории или стороннего исследования корпоративного внедрения. Liquid AI утверждает, что полностью дообучила каждую модель на каждой задаче и оценила 14 моделей по 17 задачам из GLUE, SuperGLUE и многоязычной классификации, сообщая средние значения по пяти удержанным seed-ам. Также компания заявляет, что весь фреймворк оценки и сырые результаты открыты.

Согласно этим результатам, LFM2.5-Encoder-350M занял четвёртое место среди 14 протестированных моделей, и выше него были только более крупные модели, включая одну модель 3.5B. Liquid AI также утверждает, что LFM2.5-Encoder-230M в своей заявленной конфигурации опередил ModernBERT-base и все модели EuroBERT, будучи меньше большинства из них. Это значимые утверждения, но читателям следует считать их заявленными самой компанией до появления внешних репликаций.

NVIDIA Developer Blog даёт технический контекст, а не независимую валидацию моделей Liquid AI. Его анализ тоже написан вендором и основан на предположениях о железе NVIDIA, включая измеренное поведение kernels с FP8 attention compute и KV cache. Это полезно для понимания того, почему дизайн attention для длинного контекста важен, но не должно восприниматься как стороннее подтверждение превосходства Liquid AI на CPU-бенчмарках.

Есть и практические неизвестные. Источники не дают подробных корпоративных цен, условий поддержки или кейсов из производства. Они также не показывают, как модели ведут себя в условиях реального шумного документа, ограничений задержки в многопользовательских средах или юридических и комплаенс-наборах данных с domain shift. Разработчикам, заинтересованным во внедрении, вероятно, придётся тестировать LFM2.5-Encoder-230M и LFM2.5-Encoder-350M на своих собственных корпусах и целевых SLA.

Что это значит для разработчиков и корпоративных покупателей

Для AI-разработчиков немедленная привлекательность заключается в проектировании рабочих процессов. Более маленький энкодер, который остаётся пригодным при 8 192 токенах на CPU, можно встроить в системы, которым иначе потребовались бы обрезка, chunking или дорогой GPU-инференс. Это актуально для конвейеров проверки контрактов, триажа поддержки клиентов, фильтрации trust and safety, многоязычного intake и enforcement политик. Это также актуально для гибридных стеков, где компактная модель фильтрует или маршрутизирует запросы до вызова более крупной модели.

Для корпоративных AI-команд история стоимости может быть даже важнее позиции в лидерах. CPU-friendly инференс может упростить развёртывание в регулируемых или бюджетно-ограниченных средах, особенно там, где GPU-мощности дефицитны или данные должны оставаться в существующей on-prem инфраструктуре. Длинноконтекстные энкодеры также могут снизить инженерную сложность, если устраняют необходимость разбивать документы на множество фрагментов и собирать результаты обратно downstream.

Для разработчиков моделей этот релиз — ещё один знак того, что рынок расширяется за пределы frontier chat-моделей в сторону специализированных инференс-примитивов. ModernBERT остаётся важной точкой сравнения, но Liquid AI пытается конкурировать на более конкретном обещании: лучшая экономика длинного контекста при маленьких размерах модели. Если это утверждение подтвердится на практике, разработчики могут относиться к энкодерам не как к commodity-утилитам, а как к архитектурным решениям с прямым влиянием на бюджеты задержки и стоимость системы.

Что наблюдать дальше

Следующим важным сигналом станет независимая репликация. Если внешние разработчики подтвердят заявленный Liquid AI разрыв с ModernBERT-base, особенно на обычных CPU и реальных документных нагрузках, запуск может повлиять на то, как команды проектируют недорогие корпоративные NLP-системы.

Ещё один сигнал — принятие внутри экосистемы Hugging Face. Если LFM2.5-Encoder-230M и LFM2.5-Encoder-350M начнут появляться в production-демо, дообученных классификаторах или корпоративных evaluation-стэках, это будет означать, что модели решают реальную операционную проблему, а не просто публикуют сильные внутренние бенчмарки.

Также стоит наблюдать, будет ли Liquid AI дальше расширять семейство LFM2. Связь между LFM2.5-Retrievers и этими новыми энкодерами указывает на более широкую стратегию вокруг небольших, эффективных длинноконтекстных моделей для различных слоёв рабочего процесса: поиска, маршрутизации, разметки и фильтрации. На инфраструктурной стороне принципы, изложенные NVIDIA и реализованные в TensorRT-LLM, продолжат определять, какие архитектуры практичны при более длинных окнах контекста.

Взгляд Creati.ai

Этот релиз интересен не потому, что пытается победить самые большие модели, а потому, что он нацелен на недооценённую часть стека: понимание длинных документов, которое должно работать постоянно и дёшево. Во многих реальных системах именно этот слой решает, будет ли вообще вызван дорогой модельный запрос. Если CPU-утверждения Liquid AI подтвердятся, LFM2.5-Encoders могут стать полезными строительными блоками для корпоративных AI-команд, пытающихся контролировать расходы на инференс, не отказываясь от длинноконтекстного покрытия.

Более важный урок — архитектурный. Рынок уходит от простой истории «более крупная модель = лучший продукт». Будь то CPU с LFM2.5-Encoder-230M или GPU-стэки, сформированные рекомендациями NVIDIA по co-design, производительность всё больше зависит от того, насколько структура модели соответствует рабочей нагрузке и железу. Для разработчиков это означает, что конкурентное преимущество может всё меньше зависеть от наличия foundation model и всё больше — от выбора правильной маленькой модели в правильном месте.