LFM3-1.7B против Granite 4.2 30B: две агентные модели, чей вердикт расходится по осям

Поставьте LFM3-1.7B и Granite 4.2 30B на одну страницу — и сводные средние показатели будут указывать в противоположные стороны в зависимости от того, какую строку вы читаете. В Berkeley Function Calling Leaderboard V4 модель Liquid AI с 1,73 млрд параметров набирает 71,39 против 61,39 у IBM — преимущество в десять баллов для модели примерно в семнадцать раз меньшей. В SWE-bench Verified Granite набирает 57,00 против 43,40 у LFM3-1.7B — преимущество в 13,6 балла в обратную сторону. Маршрутизация не добавляет наценку к цене провайдера из прайс-листа. Цены провайдеров из прайс-листа передаются как есть при наценке 0%.

Обе модели созданы для агентов, обе вышли в 2026 году в течение двух месяцев друг от друга, и оба поставщика публикуют достаточно пересекающихся бенчмарков, чтобы можно было провести настоящее сравнение, а не собрать коллаж. Это делает данное противостояние редким случаем, когда интересный вопрос не в том, какая модель лучше, а в том, на какой оси на самом деле находится ваша рабочая нагрузка. Очень немногие задачи требуют одновременно оценки 71 по BFCL и 57 по SWE-bench, а те, что требуют, не получают хорошего решения ни от одной из моделей по отдельности.

Два числа, которые пересекаются

Granite 4.2 30B вышла 25 августа 2026 года под лицензией Apache 2.0 — это плотная модель примерно на 30 млрд параметров, построенная на базе Granite 4.1 30B и обученная примерно на 15 трлн токенов. IBM позиционирует её для корпоративного применения: три настраиваемых режима рассуждения, нативный вызов инструментов в соответствии со схемой OpenAI, двенадцать протестированных языков и трёхэтапный конвейер обучения, завершающийся многофазным обучением с подкреплением GRPO.

LFM3-1.7B вышла двумя месяцами позже — её анонсировали 27 октября 2026 года — и была дообучена специально на агентных харнессах: Liquid называет Hermes Agent, PI и OpenClaw в карточке модели. Это плотная модель с 1,73 млрд параметров и контекстом 256K, и она явно позиционируется для локальных агентов и вызова инструментов, а не для общего рассуждения.

Пересечение бенчмарков — не случайность одного слабого показателя. Вся опубликованная таблица LFM3-1.7B смещена в сторону агентных задач: 71.39 BFCL V4, 80.36 ToolSandbox, 68.01 τ³-bench, 45.60 LiveClaw, 38.42 WebArena-Verified. Таблица Granite смещена в сторону инженерных задач: 57.00 SWE-bench Verified, 33.29 SWE-bench Pro, 41.89 SWE-bench Multilingual, 38.76 SciCode, 29.24 в TerminalBench 2.1. Каждый производитель оптимизировал модель под своё определение «агента», и таблицы бенчмарков честно отражают, под какое именно.

τ³ на уровне 68,01 против 68,05 — вот настоящая главная новость.

Под двумя драматическими разрывами скрывается полная ничья. В τ³-bench — оценке использования инструментов, измеряющей выполнение многоходовых задач с помощью пользовательских симуляторов и доменных политик, — LFM3-1.7B набирает 68,01, а Granite 4.2 30B — 68,05; разница составляет четыре сотых балла, что неотличимо от шума.

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

То, что это даёт, видно по BFCL и SWE-bench, которые измеряют разные вещи. BFCL V4 проверяет корректность одноходовых вызовов функций в соответствии со схемой — показатель LFM3-1.7B, равный 71.39, говорит о том, что постобучение Liquid на реальных агентных средах напрямую себя оправдало. SWE-bench Verified проверяет исправление реальной задачи GitHub от начала до конца, что требует удержания репозитория в контексте, планирования в масштабе нескольких файлов и создания патча, проходящего тесты — 57.00 у Granite отражает модель, способную это делать, и обучающий набор, созданный для этого.

Итак, разделение вполне закономерно. Малая модель, хорошо обученная на схемах инструментов: побеждает в тесте вызова функций. Большая модель, обученная исправлению кода: побеждает в тесте репозитория. Ничья в многоходовой промежуточной области, где обе были специально обучены.

Именно в контексте спецификации расходятся сильнее всего.

• Контекст — 262 144 токена для LFM3-1.7B; 128K нативно для Granite 4.2 30B, с возможностью расширения до 512K. Расширение не бесплатно, и IBM честно признаёт, что это расширение, а не нативное окно.

• Сохранение длинного контекста — 65,56 по RULER на 128K у LFM3-1.7B против 81,4 у Granite 4.2 30B в том же семействе бенчмарков. Более крупная модель удерживает больше информации из длинного документа, что противоположно тому, что предполагают заявленные цифры контекста.

• Объём памяти — около 1 ГБ в 4-битном формате против примерно 30 млрд параметров в весах BF16, с официальными сборками FP8, NVFP4 и MXFP4. Это модель для одного GPU, а не для ноутбука.

• Языки — шестнадцать для LFM3-1.7B против двенадцати протестированных для Granite, с иным пересечением. Двенадцать у Granite включают чешский и нидерландский; у Liquid — тайский, вьетнамский и индонезийский.

• Режимы мышления — Granite 4.2 30B выпускается с режимами полного мышления, низких усилий и без мышления. У LFM3-1.7B такой возможности нет, и в его карточке сказано, что он изначально не предназначен для сложных многошаговых рассуждений.

• Лицензия — Apache 2.0 для Granite в сравнении с LFM Open License v1.0, которая бесплатна при годовой выручке ниже 10 млн долларов и требует коммерческой лицензии при её превышении.

Что стоит 30B dense такого, чего не стоит 1.73B

Granite 4.2 30B — плотная модель, а значит, все тридцать миллиардов параметров задействуются при обработке каждого токена. Здесь нет никакого выигрыша за счёт активных параметров: вычислительные затраты на токен примерно в семнадцать раз выше, чем у малой модели, а затраты памяти равны полному файлу весов. IBM выпускает квантованные варианты, чтобы сделать это практически осуществимым, но не существует конфигурации, в которой она работала бы на телефоне.

Преимущество LFM3-1.7B заключается не в первую очередь в скорости. Оно в том, что модель помещается в тот же бюджет памяти, что и остальная часть вашего приложения. Модель на 1 ГБ оставляет место для хранилища документов, кеша и второй модели на том же устройстве — именно это делает локального агента возможным, а не лишь теоретически локальным. Liquid сообщает о декодировании в 1,8–2,8 раза быстрее, чем у предшественников, на протестированном оборудовании, и о KV-кеше объёмом 1,6 ГБ при 128K; и то, и другое важно для агента на устройстве, ведущего длительный диалог.

Противовесом служит то, что возможности Granite 30B реально отражаются в показателях SWE-bench. Если задача вашего агента — вносить изменения в код по всему репозиторию, то разрыв в 13,6 пункта не компенсировать меньшей моделью с помощью промптинга, а экономия вычислений оборачивается худшим результатом.

Лицензирование, подписание и вопрос закупок

Apache 2.0 — причина, по которой крупная организация может внедрить Granite 4.2 30B без юридической проверки. Здесь нет порога по выручке, коммерческого триггера, переговоров. IBM также с апреля 2026 года криптографически подписывает выпущенные модели Granite — это звучит как деталь, пока вы не окажетесь человеком, которому нужно доказать, что веса в продакшене — это те веса, которые прошли проверку.

LFM Open License v1.0 от Liquid действительно разрешительна на масштабе стартапа — бесплатна для коммерческого использования при годовой выручке ниже 10 млн долларов, — но выше этого порога требуется платная коммерческая лицензия. Для индивидуального разработчика или небольшой команды это не проблема. Для бизнес-подразделения внутри более крупной компании это разговор, который начинается до первого развёртывания и может затянуться. Эта асимметрия не отражается ни в одном бенчмарке и часто сама по себе решает вопрос.

Запускать оба, не делая ставку ни на один из них

Практический подход для команды, оценивающей эти две модели, — не выбирать одну из них заранее. Обе имеют открытые веса, и обе не проверены независимыми оценщиками, а значит, единственный бенчмарк, который имеет значение, — ваш собственный. Направьте модели-кандидаты через единый эндпоинт, прогоните через обе одни и те же трассировки агента и сравнивайте на своей задаче, а не на BFCL или SWE-bench.

OrcaRouter здесь полезен не столько как хост, сколько как интерфейс управления: один ключ и один счёт для более чем 200 моделей, цены из прайс-листов провайдеров передаются с наценкой 0%, а автоматическое переключение при сбое не даёт прогону оценки сорваться из-за того, что у одного провайдера выдался неудачный час. Ни LFM3-1.7B, ни Granite 4.2 30B сегодня нет в нашем каталоге — обе представляют собой загружаемые модели с открытыми весами, и в каждом случае путь — самостоятельный хостинг. Маршрутизация оправдывает себя в окружающем стеке: передовая модель, на которую переключается ваш агент при необходимости, или второе мнение, с которым вы сверяетесь, когда патч локальной модели не проходит её тесты.

Кто что должен взять?

Берите LFM3-1.7B, если агент работает на устройстве пользователя, если задача — вызов инструментов и структурированное извлечение данных через API и если контекст 256K при объёме 1 ГБ — это то, что делает продукт возможным. Примите предупреждение самого поставщика о том, что модель не предназначена для агентного программирования, и держите за ней более крупную модель для случаев, когда она нужна.

Выбирайте Granite 4.2 30B, если агент работает с кодовой базой, если вам нужны Apache 2.0 и подписанные веса для закупок, если рабочей нагрузке идёт на пользу настраиваемый уровень рассуждений и если у вас есть GPU для его обслуживания. Отставание по BFCL реально, но узко: оно измеряет корректность схемы при одном вызове, а модель 30B с хорошо продуманной схемой инструментов на практике закрывает большую часть этого разрыва.

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

Вопрос, за которым стоит следить, — переносится ли рецепт агентного постобучения Liquid на более крупный чекпоинт. Если будущая модель LFM сохранит поведение BFCL класса 71.39 и добавит ёмкость для работы с репозиториями, разделение по осям исчезнет, и это сравнение превратится в простое решение о размере. До тех пор две модели не конкурируют за одну и ту же задачу — они две половины одного целого.