Технический контекст
Я сегодня внимательно посмотрел первые полевые отзывы по LFM2.5-8B-A1B, и картина уже понятная: модель быстрая, для своего размера бодрая, но в reasoning все еще любит застревать в циклах. Для задач, где я делаю AI automation и structured output, это не мелочь, а прямое условие пригодности в проде.
Официально Liquid AI рекомендует осторожный пресет: temperature 0.2, top_k 80, repetition_penalty 1.05. Логика у них здравая, потому что модель как раз дообучали против doom loops. Но сообщество уже показывает, что в реальном рантайме на части стеков этот набор не всегда лучший.
Что у меня вызвало интерес: пользователи, которые гоняют BF16 и GGUF сразу после релиза, сходятся на одном симптоме. Если reasoning раскрутился неудачно, модель начинает повторять один и тот же ход по кругу. Не think-теги, не случайный мусор, а именно зацикленный внутренний трек.
Самый любопытный альтернативный пресет сейчас такой: context 8192, reasoning on, reasoning-format deepseek, reasoning-budget 4096, temp 0, top-k 80, repeat-penalty 1.03, repeat-last-n 64. И вот здесь я бы не спорил теоретически, а просто тестировал на своих задачах, потому что разница между 1.03 и 1.05 у таких моделей иногда ощущается сильнее, чем кажется по цифрам.
Еще один практический вывод: кванты от разработчиков пока выглядят слабее полной версии. Если мне нужно отладить поведение модели, я бы брал BF16 как базовую точку и только потом шел вниз по памяти. Иначе можно долго лечить не модель, а артефакты квантования.
Влияние на бизнес и автоматизацию
Если вы строите пайплайн с tool use, формами ответа и агентным маршрутом, temp 0 здесь выглядит не скучным, а здравым решением. Чуть поднимаете температуру, и формат начинает плыть. Для автоматизации это сразу минус в надежность.
Выигрывают те, кому нужна компактная и быстрая reasoning-модель под локальный или недорогой inference. Проигрывают те, кто надеялся просто взять официальный пресет и без настройки получить железобетонный результат в проде.
Я бы смотрел на LFM2.5-8B-A1B как на интересную заготовку для AI integration, но не как на модель, которую можно ставить в критичный контур без обвязки. Нужны лимиты на длину, стоп-последовательности и нормальная проверка выходного формата. Мы в Nahornyi AI Lab как раз такие вещи и собираем для клиентов: не просто выбираем модель, а доводим AI solution development до состояния, где оно реально экономит время, а не рождает ночные алерты.
Если у вас похожая история и модель уже жует токены по кругу вместо пользы, можно быстро пройтись по вашему стеку и собрать нормальную конфигурацию. В Nahornyi AI Lab я обычно начинаю именно с этого: убираю нестабильность, а потом уже строю AI automation вокруг процесса, который действительно работает.