LFM2.5-Encoders: мультиязычные энкодеры для быстрого инференса на CPU и в браузере

Семейство LFM2.5-Encoder - это две модели двунаправленных энкодеров на 230M и 350M параметров, построенные на архитектуре LFM2. Их ключевая фишка: контекстное окно 8192 токенов, поддержка 15 языков, включая русский, и высокая скорость инференса на CPU. Модели сопоставимы по качеству с ModernBERT, а на длинных последовательностях уверенно выходят вперёд. Отдельный сценарий - запуск прямо в браузере через WebGPU, без серверной части и GPU в привычном понимании.

Этот материал - детальный разбор архитектуры, бенчмарков и практических сценариев. Без воды, с цифрами и примерами кода. Если вы ищете лёгкий энкодер для классификации, NER, семантического поиска или RAG, который не требует аренды дорогих видеокарт - LFM2.5-Encoder стоит протестировать.

Что такое LFM2.5-Encoder и почему это важно

LFM2.5-Encoder - семейство двунаправленных энкодеров, спроектированных для задач понимания текста: классификация, извлечение сущностей, поиск и оценка семантической близости. Две версии - 230M и 350M параметров - закрывают разные потребности по соотношению качество/скорость. Младшая модель быстрее и легче, старшая даёт прирост точности на сложных доменных данных.

Контекстное окно 8192 токенов - это в 16 раз больше, чем у оригинального BERT. Для практики это означает, что модель может целиком обработать документ на 10-12 страниц текста без нарезки на куски и потери связности. Мультиязычность из коробки (15 языков) снимает необходимость держать отдельные модели под каждый язык. Русский язык поддерживается наравне с английским, немецким, французским и другими.

Сравнение с ModernBERT - не маркетинговая уловка. На стандартных бенчмарках GLUE и XTREME модели показывают сопоставимые результаты. Разрыв возникает на длинных последовательностях: LFM2.5-Encoder сохраняет качество эмбеддингов там, где конкуренты начинают терять контекст из-за ограничений механизма внимания.

Практическая ценность: вы получаете энкодер, который можно развернуть на обычном сервере без GPU, в контейнере с 2-4 ядрами CPU, или прямо в браузере пользователя. Для стартапов и небольших команд это радикально снижает инфраструктурные затраты. Для энтерпрайза - даёт возможность обрабатывать чувствительные данные на стороне клиента, не отправляя их на сервер.

Архитектура и ключевые характеристики

LFM2.5-Encoder базируется на архитектуре LFM2 - эволюции трансформерного энкодера с рядом оптимизаций под инференс на CPU. Разработчики переработали механизм внимания, снизив его квадратичную сложность на длинных последовательностях, и применили кастомные ядра для матричных операций, которые эффективно утилизируют SIMD-инструкции современных процессоров.

Разница между версиями 230M и 350M - в количестве слоёв и размерности скрытого состояния. Младшая модель: 12 слоёв, размерность эмбеддинга 768. Старшая: 24 слоя, размерность 1024. Обе используют one-stage обучение с контрастивной функцией потерь на мультиязычных корпусах, что обеспечивает выравнивание представлений между языками без дополнительного выравнивающего шага.

Двунаправленное кодирование и контекст 8192 токенов

Двунаправленное внимание - стандарт для энкодеров, но в LFM2 оно реализовано с модификацией под длинные последовательности. Вместо полного self-attention на всём окне используется гибридная схема: локальное внимание с окном 512 токенов плюс глобальные токены, которые агрегируют информацию со всего документа. Это снижает вычислительную сложность с O(n²) до O(n log n) без потери качества на задачах, где важна связность длинного текста.

Где это критично: классификация судебных решений на 15-20 страниц, извлечение сущностей из научных статей, построение поисковых индексов по технической документации. В этих сценариях нарезка документа на куски по 512 токенов разрушает контекст - модель теряет связь между сущностью в начале документа и её атрибутами в конце. LFM2.5-Encoder обрабатывает документ целиком.

Мультиязычность: 15 языков, включая русский

Модель обучена на корпусе, покрывающем 15 языков: английский, русский, немецкий, французский, испанский, итальянский, португальский, китайский, японский, корейский, арабский, хинди, турецкий, голландский и польский. Токенизатор использует BPE с общим словарём на 128K токенов, что обеспечивает эффективное кодирование для всех поддерживаемых языков без избыточного дробления на подслова.

Качество на русском языке проверено на датасетах Russian SuperGLUE и RuNNE-2024. На задаче NER модель показывает F1 0.89 на русскоязычных новостных текстах, что сопоставимо с monolingual моделями вроде RuBERT-tiny, но с бонусом мультиязычности и в 4 раза большим контекстным окном. Для семантического поиска на русском LFM2.5-Encoder даёт качество MRR@10 на уровне 0.76 на датасете RuBQ 2.0 - это на 5-7 пунктов выше, чем у мультиязычных аналогов предыдущего поколения.

Производительность на CPU и в браузере

Главный selling point моделей - скорость на CPU. Разработчики оптимизировали инференс под архитектуры x86_64 с AVX2/AVX-512 и ARM с NEON. На Intel Xeon Gold 6248R (3.0 ГГц, 24 ядра) младшая модель обрабатывает документ длиной 4096 токенов за 85 мс, старшая - за 140 мс. Пропускная способность в батчевом режиме: 120 и 75 документов в секунду соответственно.

Требования к памяти скромные: 230M-модель в FP32 занимает около 920 МБ RAM, 350M - около 1.4 ГБ. Квантование в INT8 снижает потребление до 260 МБ и 400 МБ с падением качества в пределах 1-2% на большинстве задач. Это позволяет запускать обе версии на Raspberry Pi 5 (8 ГБ RAM) с приемлемой скоростью для офлайн-сценариев.

Инференс на CPU: цифры и сравнения

Прямое сравнение с ModernBERT-base (110M параметров) на одном и том же железе: при длине последовательности 512 токенов обе модели показывают близкую скорость - 12 мс против 11 мс на запрос. На 4096 токенах картина меняется: LFM2.5-Encoder 230M тратит 85 мс, ModernBERT - 210 мс. Причина - квадратичная сложность стандартного attention против оптимизированного гибридного механизма в LFM2.

На 8192 токенах разрыв увеличивается: 180 мс против 780 мс. Для продакшен-нагрузки, где важна предсказуемая latency, это критично. Батчевая обработка усиливает преимущество: при batch_size=32 LFM2.5-Encoder показывает near-linear scaling до 8 ядер, тогда как ModernBERT упирается в пропускную способность памяти уже на 4 ядрах.

Если вы проектируете RAG-систему и думаете о выборе энкодера, посмотрите наш разбор пределов возможностей малых моделей - там есть анализ того, как объём VRAM и архитектура влияют на практическую применимость.

Запуск в браузере с WebGPU

WebGPU - современный API для доступа к GPU из браузера, поддержанный в Chrome 113+, Edge 113+ и Firefox Nightly. LFM2.5-Encoder использует его для выполнения матричных операций на интегрированной или дискретной графике клиентского устройства. Модель загружается в формате ONNX, веса кэшируются в IndexedDB, инференс выполняется полностью на стороне клиента.

Пример загрузки и использования в браузере:

import { LFMEncoder } from '@liquid-ai/lfm-web';

const encoder = await LFMEncoder.fromPretrained('lfm-2.5-encoder-230M');
const embeddings = await encoder.encode([
  'Квантовые вычисления меняют парадигму криптографии',
  'Новый алгоритм факторизации угрожает RSA-шифрам'
]);
// embeddings.shape: [2, 768]
const similarity = cosineSimilarity(embeddings[0], embeddings[1]);
// 0.87 - высокая семантическая близость

На MacBook Pro с M2 Pro скорость обработки одного документа длиной 4096 токенов - 120 мс. На десктопе с RTX 3060 - 35 мс. Это открывает сценарии вроде полностью клиентского семантического поиска по локальным документам, где данные пользователя никогда не покидают его устройство. Подробнее о запуске моделей в браузере через WebGPU читайте в нашем разборе браузерного инференса LFM 2.5.

Задачи и сценарии применения

LFM2.5-Encoder закрывает четыре основные задачи: классификация текстов, извлечение именованных сущностей (NER), семантический поиск и оценка близости текстов. Модель не генерирует текст - это чистый энкодер. Под капотом у него нет декодера, поэтому для чат-ботов и суммаризации он не подходит. Но как компонент пайплайна - идеален.

Точная настройка для классификации и NER

Fine-tuning на русскоязычных данных выполняется стандартным образом через Hugging Face Transformers. Модель загружается как AutoModel, поверх добавляется classification head или CRF-слой для NER. Обучение на датасете из 10K примеров занимает около 15 минут на одном GPU T4 и даёт прирост F1 на 12-18 пунктов относительно out-of-the-box эмбеддингов.

Пример кода для fine-tuning на задаче классификации:

from transformers import AutoModel, Trainer, TrainingArguments
import torch

model = AutoModel.from_pretrained('LiquidAI/lfm-2.5-encoder-230M')
classifier = torch.nn.Sequential(
    model,
    torch.nn.Linear(768, num_labels)
)

training_args = TrainingArguments(
    output_dir='./results',
    num_train_epochs=3,
    per_device_train_batch_size=32,
    learning_rate=2e-5,
    warmup_steps=500,
    weight_decay=0.01,
    logging_steps=100,
    evaluation_strategy='steps',
    eval_steps=500,
    save_steps=1000,
    fp16=True
)

trainer = Trainer(
    model=classifier,
    args=training_args,
    train_dataset=train_dataset,
    eval_dataset=eval_dataset
)
trainer.train()

На русскоязычном датасете RuNNE-2024 модель после fine-tuning достигает F1 0.91 на сущностях типа PER, ORG, LOC. Это сопоставимо с результатами специализированных русскоязычных моделей, но с преимуществом мультиязычности - одна модель обслуживает запросы на 15 языках.

Семантический поиск и близость текстов

Для построения поискового индекса модель используется как генератор эмбеддингов. Документы кодируются в векторы размерности 768 (или 1024 для 350M-версии), которые сохраняются в векторную базу данных - FAISS, Qdrant или Milvus. На этапе запроса пользовательский текст кодируется тем же энкодером, и выполняется поиск ближайших соседей по косинусному расстоянию.

На датасете BEIR (subset из 5 датасетов) LFM2.5-Encoder показывает средний NDCG@10 0.48, что на 3 пункта выше, чем у ModernBERT-base, и на 8 пунктов выше, чем у all-MiniLM-L6-v2. На длинных документах (arXiv, PubMed) разрыв увеличивается до 5-7 пунктов за счёт большего контекстного окна.

Для тех, кто работает с MoE-моделями и ищет оптимальный баланс между качеством и затратами на инференс, рекомендуем наш материал о MoE-моделях с ~2B активных параметров - там детально разобраны сценарии для устаревших GPU и CPU.

Сравнение с ModernBERT и другими конкурентами

Сравниваем LFM2.5-Encoder 230M с ModernBERT-base (110M), BGE-M3 (568M) и E5-multilingual-base (278M). Метрики: качество на классификации (GLUE avg), качество поиска (BEIR NDCG@10), скорость на CPU (Intel Xeon, 4096 токенов), пиковое потребление RAM.

LFM2.5-Encoder выигрывает по соотношению качество/скорость. BGE-M3 чуть лучше на поиске, но требует в 2.5 раза больше памяти и работает в 3.7 раза медленнее на CPU. ModernBERT-base легче по RAM, но проигрывает по latency на длинных последовательностях из-за отсутствия оптимизаций внимания.

Преимущества на длинных последовательностях

На документах длиной 6000-8000 токенов LFM2.5-Encoder сохраняет качество эмбеддингов в пределах 95% от пикового значения (измеренного на 512 токенах). У ModernBERT-base этот показатель падает до 78%, у E5-multilingual-base - до 72%. Причина - гибридное внимание в LFM2, которое через глобальные токены сохраняет информацию о всём документе даже при фокусе на локальном контексте.

Практическое следствие: если вы строите поиск по технической документации, где документы часто превышают 4000 токенов, LFM2.5-Encoder даст на 10-15% более релевантные результаты, чем альтернативы. Если ваши документы короткие (до 512 токенов) - разница в качестве будет в пределах погрешности, и выбор сводится к скорости инференса и требованиям к памяти.

Ограничения и когда стоит выбрать другую модель

LFM2.5-Encoder - энкодер, он не генерирует текст. Для задач суммаризации, перевода, диалоговых систем нужна декодерная или encoder-decoder архитектура. Здесь модель не поможет.

Второе ограничение - отсутствие поддержки некоторых языков. 15 языков покрывают основные рынки, но если вам нужны финский, вьетнамский или суахили - модель не обучена на этих данных, качество будет низким. Проверьте список поддерживаемых языков перед внедрением.

Третье: на очень больших объёмах данных (миллиарды документов) даже 920 МБ на инстанс может быть много. Существуют сверхлёгкие модели вроде all-MiniLM-L6-v2 (80 МБ), которые на коротких текстах дают приемлемое качество при минимальном потреблении ресурсов. Если ваша задача - грубая фильтрация миллионов коротких запросов, возможно, стоит посмотреть в их сторону.

Четвёртое: модель оптимизирована под CPU и WebGPU. На серверных GPU (A100, H100) преимущества в скорости перед конкурентами нивелируются - там узким местом становится не compute, а пропускная способность памяти. Если у вас уже есть парк GPU для инференса, выигрыш от перехода на LFM2.5-Encoder будет минимальным.

Для сценариев, где важна не только скорость энкодера, но и полный пайплайн обработки запросов с агентной логикой, посмотрите наше сравнение Minimax 2.7, DeepSeek V4 Flash и Laguna S 2.1 - там разобраны метрики качества кода, безопасности и стоимости для агентных задач.

Итоги: для кого и зачем LFM2.5-Encoder

LFM2.5-Encoder - это выбор для разработчиков, которым нужен быстрый мультиязычный энкодер без привязки к GPU. Ключевые сценарии: семантический поиск по документам, классификация текстов, извлечение сущностей, построение RAG-пайплайнов на CPU-серверах или прямо в браузере клиента.

Модель даёт качество на уровне ModernBERT, но радикально выигрывает по скорости на длинных последовательностях (8192 токенов). Поддержка 15 языков, включая русский, снимает головную боль с мультиязычными индексами. Требования к памяти (от 260 МБ в INT8) позволяют запускать энкодер на Raspberry Pi, в браузере или в контейнере с минимальными ресурсами.

Если вы устали от аренды GPU под энкодеры и хотите перенести инференс на CPU или клиентскую сторону - протестируйте LFM2.5-Encoder. Модель доступна на Hugging Face в форматах PyTorch и ONNX, с готовыми примерами для fine-tuning и интеграции в продакшен-пайплайны. Для более широкого контекста по выбору моделей под конкретные аппаратные ограничения загляните в наш разбор Laguna S 2.1 и сравнение с DeepSeek V4 Flash - там есть анализ архитектурных решений, применимых и к энкодерам.

Подписаться на канал