Зачем вообще тестировать tool-calling у малышей?
Все говорят про GPT-5, Gemini Ultra 2.0 или Claude 3.7 Sonnet. Но попробуй запустить их локально на своей RTX 4070 Ti. Не получится. Совсем. Там даже контекст в 128K токенов не влезет в память. А ведь именно локальные агенты — это будущее автоматизации. Бот, который сам чинит твой CI/CD, скрипт, который мониторит логи и пишет алерты, помощник в VS Code, который не отправляет твой код на сервера OpenAI.
Проблема в том, что tool-calling — это не просто "генерируй JSON". Это сложная задача restraint (сдержанности). Модель должна понимать, когда инструмент действительно нужен, а когда можно ответить сама. И вот эта способность у маленьких моделей (1-4 миллиарда параметров) до недавнего времени была на уровне случайного угадывания.
Методология: как мы ломали модели
Я не стал использовать стандартные бенчмарки вроде AgentBench или SWE-bench. Они слишком общие. Вместо этого собрал 200 специфичных промптов, которые проверяют именно restraint в tool-calling. Условно разделил их на три категории:
- Прямые вызовы (70 промптов): "Посчитай 15*24", "Найди погоду в Москве" — здесь инструмент нужен.
- Сложные многошаговые задачи (60 промптов): "У меня есть список чисел: [2, 5, 8]. Умножь каждое на 3, потом сложи результаты и найди квадратный корень" — нужна цепочка вызовов.
- Ловушки (70 промптов): "Привет, как дела?", "Расскажи анекдот", "Что такое tool-calling?" — здесь инструмент НЕ нужен, модель должна ответить сама.
Именно последняя категория — ловушки — оказалась самой показательной. Большинство маленьких моделей с треском проваливались здесь еще год назад. Они пытались вызвать калькулятор для "Привет" или искать в интернете определение tool-calling.
Тестировал на RTX 6000 Pro Blackwell 96GB (да, я один из тех счастливчиков), чтобы исключить влияние квантования. Все модели в FP16. Контекст — 4096 токенов. Температура — 0.1, чтобы минимизировать случайность.
Неожиданный лидер: lfm2.5-1.2B, который обогнал всех
Вот тут начинается самое интересное. Когда я увидел результаты, то перепроверил все три раза. Думал, ошибся в скрипте.
| Модель | Параметры | Точность вызовов | Restraint (ловушки) | Общий балл |
|---|---|---|---|---|
| lfm2.5-1.2B | 1.2B | 94.3% | 91.4% | 92.9 |
| Qwen2.5-Coder-3B | 3.0B | 92.1% | 88.6% | 90.4 |
| Ministral-3-3B | 3.0B | 90.0% | 87.1% | 88.6 |
| Qwen3-1.7B-Instruct | 1.7B | 81.4% | 72.9% | 77.2 |
| Phi-4-2.3B | 2.3B | 78.6% | 75.7% | 77.2 |
| Qwen3-0.6B-Instruct | 0.6B | 65.7% | 61.4% | 63.6 |
lfm2.5-1.2B — модель, о которой мало кто слышал вне узких кругов. Разработана Latent Flux Models, вышла в конце 2025 года. И она не просто выиграла — она унизила модели в 2-3 раза больше себя. 91.4% точности на ловушках! Это уровень, который раньше был доступен только моделям от 7B параметров.
Как они этого добились? Секрет в тренировке. lfm2.5 тренировали не просто на вызовах инструментов, а на специальном датасете с негативными примерами — ситуациями, когда инструмент вызывать НЕ нужно. И это видно. Модель действительно думает, прежде чем сгенерировать JSON.
Внимание на Qwen3-1.7B. Это та самая "долина возможностей". Модель на 0.5 миллиарда параметров больше, чем lfm2.5, но показывает результаты на 15 баллов хуже. Причем хуже именно в restraint. Она слишком часто вызывает инструменты без необходимости. Видимо, команда Alibaba сосредоточилась на других аспектах, упустив эту критичную для агентов метрику.
Почему restraint важнее, чем ты думаешь
Кажется, что если модель ошибается и вызывает инструмент без необходимости — ну и что? Отмени вызов, ответь сам. Но в продакшене все иначе.
Представь агента, который мониторит логи. Каждые 5 минут он получает новый чанк логов. Если на каждый чанк он будет делать 3-5 ненужных вызовов к внешним API (поиск в базе знаний, калькулятор для подсчета строк, кто знает), то:
- Твои лимиты API сгорят за день
- Латентность вырастет в разы
- Стоимость инфраструктуры взлетит
- Агент начнет отставать от реального времени
Именно поэтому в моем предыдущем исследовании про цепочки инструментов в продакшене я предупреждал — без качественного restraint агенты становятся непредсказуемыми и дорогими.
Странность Qwen3: чем больше, тем хуже (до определенного предела)
Посмотри на динамику в семействе Qwen3:
- Qwen3-0.6B: 63.6 балла
- Qwen3-1.7B: 77.2 балла (рост!)
- Qwen3-4B: 84.3 балла (еще рост, но уже меньше)
- Qwen3-7B: 89.3 балла (почти догнал лидеров)
Есть явный провал в эффективности между 0.6B и 1.7B. Модель на 1.7B параметров должна быть значительно лучше, чем на 0.6B. Но она лишь немного лучше. И хуже, чем lfm2.5 на 1.2B. Это говорит о проблемах в архитектуре или тренировочных данных именно для этого диапазона размеров.
Если ты выбираешь модель для Mac Studio M4 Max с ограниченной памятью, то Qwen2.5-Coder-3B выглядит надежнее, чем Qwen3-1.7B, несмотря на меньшую версию в названии.
Практические выводы: какую модель ставить в продакшен
Исходя из результатов, вот мои рекомендации на начало 2026 года:
1 Для embedded-систем и совсем слабого железа
lfm2.5-1.2B — абсолютный чемпион. Запускается на 2 ГБ VRAM с квантованием Q4_K_M. Если у тебя Raspberry Pi 5 с нейроускорителем или старый ноутбук с GTX 1650 — это твой выбор. Только учти, что сообщество вокруг модели пока малочисленное, документации не много.
2 Для рабочих станций с 8-12 ГБ VRAM
Qwen2.5-Coder-3B или Ministral-3-3B. Обе модели показывают отличные результаты, но у них разные сильные стороны. Qwen2.5 лучше в коде (что логично из названия), Ministral-3 более сбалансирован. Ministral-3, кстати, специально создавалась для tool-calling, о чем я писал в отдельном обзоре.
3 Чего избегать прямо сейчас
Qwen3-1.7B-Instruct для агентов. Ее restraint настолько плох, что она будет делать ненужные вызовы в 27% случаев на простых промптах. Это каждый четвертый запрос! Лучше взять либо меньшую 0.6B (если сильно ограничен по памяти), либо перейти сразу к 4B версии.
Где взять эти модели и как запустить
Большинство моделей из теста доступны на Hugging Face. Для локального запуска я использую комбинацию llama.cpp для инференса и собственных оберток для управления агентами. LM Studio тоже подходит, особенно его последняя версия с улучшенной поддержкой tool-calling.
Для lfm2.5-1.2B пока нет готовых GGUF файлов в официальном репозитории, но сообщество уже сделало конвертации. Ищи на Hugging Face в сообществе или используй собственные скрипты конвертации из safetensors.
Важный нюанс: при квантовании моделей для tool-calling избегай агрессивных методов вроде Q2_K. Они могут сломать способность модели генерировать валидный JSON. Q4_K_M — оптимальный баланс между размером и качеством для большинства случаев.
Что будет дальше: прогноз на 2026-2027
Результаты lfm2.5-1.2B — это сигнал для всей индустрии. Оказывается, для качественного tool-calling не нужны гигантские модели. Нужны правильные данные для тренировки и архитектура, заточенная именно под эту задачу.
Я ожидаю, что в 2026 году мы увидим:
- Взрыв специализированных моделей 1-3B параметров для конкретных доменов (DevOps, аналитика данных, мониторинг)
- Интеграцию tool-calling напрямую в edge-устройства — камеры, роутеры, промышленные контроллеры
- Появление стандартизированных бенчмарков именно для restraint, потому что текущие AgentBench и другие слишком общие
Уже сейчас, если тебе нужен агент для автоматизации рутины, не гонись за 7B или 14B моделями. Возьми lfm2.5-1.2B или Qwen2.5-Coder-3B, правильно настрой промпты и инструменты — и получишь 90% результата за 20% вычислительных затрат.
А если хочешь глубже разобраться в выборе моделей для разных задач, посмотри мой большой обзор лучших LLM с tool-calling, где я разбираю не только маленькие, но и средние модели до 14B параметров.
P.S. Самый главный вывод из этого исследования: размер — не главное. Архитектура и данные решают. 1.2B модель может бить 1.7B, если ее правильно тренировали. Запомни это, когда в следующий раз будешь выбирать модель по числу параметров.
