Две локальные модели на быту и на коде: где сильная врёт, а слабая спешит

Тринадцатого октября в ленте мелькнула карточка новой модели: LFM2.5-24B-A2B от Liquid AI. Я открыл её из любопытства — и застрял на одной фразе. «Всегда думает перед ответом». Не «умеет думать», не «можно включить режим рассуждений», а именно всегда — служебный тег think вшит в шаблон чата, и отключить его нельзя.

В тот же вечер я скачал модель и задал ей первый вопрос: «сколько будет семнадцать умножить на двадцать три». Она честно расписала столбик, проверила себя через разность квадратов и выдала ответ — истратив на пример из второго класса больше тысячи токенов размышлений.

А рядом, в соседнем окне, у меня уже крутилась gemma-4-e4b — та самая, на которой держатся локальные задачи. И я вдруг понял, что мне интересно не «какая модель умнее». Интересно другое: что делает модель, когда думает всегда — и что происходит, когда она не думает вовсе.

Спойлер — если не хотите читать до конца. Модели разошлись по двум разным измерениям. По рассуждениям и коду вперёд ушла lfm2.5: она написала сервис на FastAPI с меньшим числом дефектов, быстрее и точнее по формату. А по бытовым знаниям сильнее оказалась gemma: она верно ответила про время суток и дала точную первую помощь при ожоге — там, где lfm2.5 запуталась с временем суток и посоветовала не накладывать повязку. Отсюда и мой выбор: для локального кодинга я меняю gemma на lfm2.5 — разрыв там слишком велик, чтобы его игнорировать. gemma остаётся на своём: быстрые бытовые ответы, где думать каждый раз не нужно. Точные числа и веса — ниже.

Что это за модель

Liquid AI выложили LFM2.5-24B-A2B 13 октября 2026 года — как «последнюю и самую большую в семействе LFM2.5», которое теперь тянется от 230M до 24B параметров.

По архитектуре это гибридная смесь экспертов: 24 млрд параметров всего, но лишь 2,45 млрд активных на каждый токен, 40 слоёв и 64 эксперта с маршрутизацией top-4. Контекст — 131 тысяча токенов, языков заявлено шестнадцать, и русский среди них. Для локальной модели это солидно.

Почему именно Gemma

Карточка не только описывает модель — она показывает, с кем та себя сравнивает. Главные соперники в бенчмарках — Qwen3.6-35B-A3B, Gemma-4-26B-A4B-it и Nemotron-3.5-Lightning.

То есть Liquid AI сами ставят свою модель против Gemma-4. А у меня на руках gemma-4-e4b — та самая, на которой держатся локальные задачи. Спорить с маркетингом смысла нет, поэтому я решил проверить на своём: прогнать обе модели на одном наборе вопросов и посмотреть, кто как ответит.

Что обещает карточка — и что говорят другие

Если верить производителю, сила LFM2.5 — агентность и следование инструкциям, а вовсе не знания. В карточке это сказано прямо: модель «не рекомендуется для задач, нагруженных знаниями, без retrieval» — то есть её надо подпирать поиском, а не спрашивать по памяти.

Цифры в бенчмарках против Gemma-4-26B-A4B-it это подтверждают:

Картина ровная и предсказуемая. На инструментах и следовании инструкциям LFM2.5 впереди — местами с большим отрывом. На знаниях, которые и меряют GPQA Diamond и HLE, преимущества нет: там Gemma-4 либо наравне, либо чуть выше.

Это важно для моего вопроса. Бытовые задачи — темнеет ли на улице, что делать с ожогом — ближе к знаниям, чем к инструментам. И как раз в этой зоне карточка не обещает ничего выдающегося.

Карточка — это то, что модель говорит о себе. Интересно и то, что о ней говорят другие. Формальные сигналы хорошие: за первые дни — около 420 лайков и почти 9,4 тысячи скачиваний, восемь живых обсуждений. В треде про требования к видеопамяти модель разбирают именно как «влезает на моё железо и работает быстро» — то есть хвалят за компактность и скорость, а не за ум. Просят зрение: это обсуждение собрало больше всего реакций. Кто-то мечтает усилить модель дублированием слоёв.

Показательно тут другое — то, чего в отзывах нет. Я не нашёл жалоб ни на галлюцинации, ни на сломанный вызов инструментов, а для свежей модели это обычно первые темы. Портрет в сообществе выходит однозначный: «быстрый и удобный агент», а не «умный всезнайка». Ровно то же, что обещает карточка.

Тем интереснее было проверить, что получится на деле.

Что за стенд

Обе модели подняты на локальном сервере моделей и доступны через один REST-эндпоинт localhost:1234/api/v1/chat. Запросы я держал одинаковыми: temperature 0 для логики и temperature 0.7 для творчества. Ответ приходит двумя блоками — reasoning (видимые рассуждения) и message (собственно ответ), плюс статистика: скорость, время до первого токена, число токенов.

Пиковая скорость — это про число токенов в секунду, и здесь lfm2.5 впереди. Но выигрыш по времени у gemma: на простом вопросе она не тратит токенов на размышления вообще, поэтому её ответ приходит заметно раньше, хотя поток токенов у неё медленнее.

Как гонял

Здесь важно не смешивать два разных измерения, и я измерял их отдельно. Первое — как модель обращается с рассуждениями: думает всегда или по требованию. Второе — бытовые знания: что она помнит по фактам. От того, что важнее в задаче, и зависит победитель.

Дальше я буду называть модели по размеру: lfm2.5 — сильная (24 млрд), gemma — слабая (около 4 млрд). Разница в шесть раз, и в этом весь интерес.

Девять вопросов, одинаковых для обеих: инструкция «ровно одно слово», арифметика, функция на Python, логическая ловушка, поздравление на русском, времена года, время суток, бытовой выбор с зонтом и первая помощь при ожоге. Плюс отдельная роль — «отвечай только в рифму» — на проверку того, держит ли модель рамку.

Где обе справились

Обе выдали ровно OK, когда просили одно слово, и обе посчитали 17*23 = 391. Обе правильно перечислили времена года начиная с весны и обе удержали роль в рифму — с оговоркой, что у каждой рифма спотыкается в последней строке.

На этом согласие заканчивается.

Где разошлись

Отдельно стоит вопрос про зонт — «взять или остаться дома, если солнечно, но через час ливень». Обе ушли от прямого ответа: выдали разветвлённое «если выйдешь — бери, если можешь — останься». Формально это не ошибка, но и не ответ, поэтому обе получили по полбалла в рейтинге ниже.

Первая черта: думает всегда

У lfm2.5 видимые рассуждения включаются на каждом запросе и раздуваются в разы. На просьбу «ровно одно слово» — 56 токенов рассуждений, чтобы решить, что нужно сказать OK. На бытовой вопрос про зонт — около четырёхсот токенов только на размышления, при одной фразе ответа. А пример 17*23 она решала особенно вдумчиво — более тысячи токенов на два действия. Простой вопрос стоит сотен токенов и нескольких секунд.

Зато внутри этой болтовни она аккуратно проверяет себя и потому редко ошибается на условиях. Ловушку с яблоками прошла, арифметику проверила двумя способами.

Вторая черта: думает через раз

У gemma рассуждения включаются по необходимости, и это видно по триггерам. На «OK» и на 17*23 — ноль токенов рассуждений, ответ мгновенный и точный. Но на ловушке с яблоками рассуждения не включились — и модель выдала 4. Она сама решила, что думать не о чем, а задача именно этого и требовала.

Зато там, где рассуждения включились, они точнее: про время суток она ответила коротко и верно — «темнеет», а про ожог грамотно и по делу: прохладная вода вместо льда, не прокалывать волдыри, накрыть стерильной неприлипающей повязкой.

И вторая её слабость: формат. «Только код» она проигнорировала — выдала функцию, docstring и блок с примерами. «Три предложения» — написала четыре. А в стихотворении черновик выбирал «pure white», а в финал ушло «blue» — рассуждения и ответ разошлись.

Настоящая задача: сервис заявок

Бытовые вопросы — это разминка, где цена ошибки — неверный ответ. Но модели у меня крутятся не в чате, а в коде. Поэтому вторая часть опыта — реальная задача: написать сервис на FastAPI.

Бизнес-процесс я взял самый обычный — обработка заявок в поддержку:

• создание — POST /tickets с телом {"title", "description"}, статус new, уникальный целочисленный id, ответ 201;
• список с фильтром — GET /tickets?status=new|in_progress|closed;
• взять в работу — POST /tickets/{id}/take, переход new → in_progress, иначе 409;
• закрыть — POST /tickets/{id}/close, переход in_progress → closed, иначе 409;
• не найдено — 404, хранение — словарь в памяти, без базы.

Требования простые и проверяемые: модели Pydantic, непустой заголовок, понятные HTTP-ошибки, докстринги, один файл. Ровно тот класс задач, где видно, думала ли модель на самом деле или просто угадала.

Задание обе получили одинаковое, temperature 0. Но верить на слово я не стал: код извлёк, поставил приложением и прогнал функциональным тестом — пятнадцать проверок от создания заявки до недопустимых переходов через TestClient.

Оба кода я проверил строго по спецификации: фильтр вызывается как ?status=. И тут вылезло то, что и отличает «написала код» от «написала правильный код» — дефекты оказались разной природы.

У lfm2.5 — отклонение от контракта. Логика безупречна: переходы состояний, коды 201/404/409, отсечение пробельного заголовка — всё на месте. Провалилась ровно одна проверка, и по неожиданной причине: параметр фильтра она назвала status_filter, а спецификация требует ?status=. Под своим именем её код проходит все пятнадцать проверок, но клиент, вызвавший ?status=new как в задании, получит весь список без фильтра. Одна строка — и публичный контракт сервиса сломан.

У gemma — два функциональных дефекта. Первый — дыра в валидации: заголовок из одних пробелов она пропустила, вернув 201. lfm2.5 в том же месте отдала корректный 422. Второй — тонкий и куда неприятнее: в обработчике списка она назвала аргумент status, и это имя перекрыло импортированный из FastAPI модуль status. Строка, где нужен код ошибки 400, обращается к аргументу-строке и падает: при неверном фильтре сервис отдаёт 500. То есть механизм, который должен вежливо ругаться, сам ломается.

Ирония тут сама себя показывает: у сильной модели дефект косметический — имя переменной, — а у слабой функциональный, причём ровно тот, что превращается в прод-инцидент. Но заметьте: имя параметра не поймает ни один тест, написанный под самим автором, — расхождение с ТЗ увидит только тот, кто вызовет ?status=, как в задании.

А теперь — в паре

Одиночный прогон показал характеры, но не ответил на другой вопрос: что будет, если столкнуть модели вместе? Идея простая — пусть работают над одной задачей по очереди, а роль ведущего меняется:

1. автор пишет первую версию;
2. ревью — вторая модель ищет и правит ошибки, возвращая полный файл;
3. финал — автор делает последний проход.

Код на каждом шаге целиком уходит следующей модели в промпт (эндпоинт однотуровый, истории нет). Я сделал два зеркальных прогона: в одном ведёт lfm2.5, в другом — gemma.

Формально обе цепочки дошли до чистых 15/15 — и это уже результат. Одиночный gemma давал 12/15, а после ревью партнёра его дефект с валидацией исчез: пробельный заголовок перестал проходить. Одиночный lfm2.5 терял балл на имени параметра — и в парном прогоне авторства оно оказалось уже правильным.

Но интереснее, как распределились роли. gemma в роли ревьюера сработала неожиданно хорошо: она привела контракт к заданию — добавила перечисление допустимых статусов, модели ответа и Optional в аннотации. Код автора был уже корректен, так что фикс был по части дисциплины, а не логики.

А вот lfm2.5 в роли ревьюера, к которой я как раз возлагал надежды, повела себя неровно. Она починила валидацию — пробельный заголовок перестал проходить, — но не заметила перекрытие имени. И баг с 500 прошёл через все три стадии прогона, где ведёт gemma, нетронутым: финальный проход оставил код ровно таким же.

Итог по краевым случаям виден только в тестах, а не в ревью:

Так думать или не думать

Вернёмся к главному различию — к тому, как модели обращаются с рассуждениями. За двумя чертами стоят разные инженерные решения, а не разное качество. lfm2.5 поставила на «думать всегда»: предсказуемо, но простой вопрос стоит как сложный. gemma — на «думать по требованию»: дёшево и точно на простом, но она сама решает, где думать не надо, и иногда решает неверно.

Отсюда и разные точки отказа: сильная проваливается на фактах (время суток, первая помощь), слабая — на внимательности к условию (те самые яблоки). И на коде повторилось ровно то же: у gemma — пропущенная валидация и перекрытое имя, у lfm2.5 — единственная, но контрактная ошибка в имени параметра.

Числовой рейтинг

Впечатления — это хорошо, но хочется числа. Я свёл всё, что измерял, в пять критериев и оценил каждую модель по шкале от 0 до 10. Бытовые знания и логика — это чистые доли верных ответов: один вопрос — один балл, уклончивый ответ — полбалла. Код, скорость и формат — с поправкой на тяжесть ошибки и задержку, поэтому их балл не сводится к простому отношению; в колонке «что считал» видно основу каждого числа.

Про ожог отдельно: lfm2.5 ответила в целом разумно — снять с источника жара, охлаждать прохладной водой 10–20 минут, не мазать маслом, — но добавила «повязку не накладывать». Совет спорный: свободная неприлипающая повязка как раз рекомендуется, чтобы защитить ожог от инфекции. gemma в этом пункте оказалась точнее: не прокалывать волдыри, накрыть стерильной неприлипающей повязкой. Поэтому балл за ожог уходит gemma, а у lfm2.5 засчитаны только времена года — отсюда «1 из 3». Уклончивый ответ обеих про зонт — полбалла каждой.

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

Вот и весь ответ на языке чисел. В роли справочника выигрывает gemma: 7,0 против 6,3. Её единственное, но решающее преимущество — бытовые факты, где она ответила верно трижды из трёх, а lfm2.5 один раз прямо ошиблась и один раз дала спорный совет. В роли кодинг-агента выигрывает lfm2.5: 8,3 против 4,9. Здесь её берут качество кода, дисциплина и скорость разом, а слабое место в знаниях почти не весит.

И вот где сходятся два измерения из начала статьи. Рассуждения решают исход кодинга: стратегия «думать всегда» даёт lfm2.5 качество и скорость на большой задаче, а «думать по требованию» подводит gemma там, где она решила не думать. Бытовые знания решают исход роли справочника — и здесь всё наоборот. Каждая модель выигрывает на своём — но не одинаково уверенно.

Смотрите на разрыв между сценариями. В кодинге он 3,4 балла в пользу lfm2.5, а в роли справочника — всего 0,7 в пользу gemma. Значит, переходить на lfm2.5 для кода стоит: там её преимущество решающее. А вот менять gemma на lfm2.5 для бытовых вопросов смысла нет — отрыв мизерный, а плата реальная: лишние токены рассуждений и задержка на каждом ответе.

Оговорка про честность оценки: критерии немноголюдные (по три-пятнадцать проверок каждый), это один прогон, а веса — моя субъективная развесовка. Считайте это не приговором, а каркасом: подставьте свои веса — и рейтинг пересчитается.

Что понял

Сравнивать локальные модели «по уму» бессмысленно вне контекста. На бумаге обе сильны, а по-настоящему расходятся и на быту, и на коде — и ломаются по-разному: одна на фактах, другая на внимательности.

Парная схема это сглаживает, но не лечит. Слабая модель рядом с сильной вытягивается, если сильная пишет, — но ревью моделью не заменяет тестов. Показательный случай — баг с перекрытием имени: его не поймала ни одна из моделей ни в одном прогоне, потому что он проявляется только на неверном входе. Нашёл его мой тест, а не ревьюер.

Для себя я сделал один вывод, самый практичный. В локальном кодинге можно переходить с gemma на lfm2.5. Разрыв в пользу сильной здесь слишком велик, чтобы его игнорировать: она пишет более корректный код, быстрее и лучше держит формат. gemma остаётся там, где нужно знать, а не сделать: короткие бытовые вопросы, справка по фактам, дешёвые ответы без рассуждений на каждый чих.

И общий вывод не про «кто лучше», а про то, где ты согласен платить. За скорость и дешевизну gemma расплачиваешься редкими провалами внимания — а на коде такой провал превращается в 500 на проде. За надёжность lfm2.5 — латентностью на каждом запросе: четыре с половиной тысячи токенов рассуждений на задачу, которую можно было написать вдвое короче. Идеальный вариант — не выбирать одну, а разводить по типу вопроса, но закрывать результат тестами в любом случае.