Коротко: что показало сравнение LFM2.5 2.6B и MiniCPM5 2B на M1 Air
LFM2.5 2.6B обошла MiniCPM5 2B на MacBook Air M1 и по скорости, и по расходу памяти. Обработка промпта: 200 t/s против 162 t/s. Генерация ответа: 22 t/s против 16 t/s. Память при контексте 32k: около 2,5 ГБ против примерно 3,8 ГБ, причём у MiniCPM5 2B в этот замер входит draft-модель для спекулятивного декодирования. Эти цифры привёл пользователь Reddit, прогнавший обе модели в роли агентов с инструментами (исходный пост с замерами).
Обе модели справились с ролью агента: вызывали инструменты и использовали веб-поиск, чтобы ответить на простые вопросы. Дальше начинаются различия. LFM2.5 2.6B уверенно держит простые одношаговые задачи, но, по наблюдению автора теста, быстро начинает галлюцинировать, когда диалог удлиняется. MiniCPM5 2B при ответе на английском может оказаться сильнее в агентной работе, однако регулярно отвечает на китайском даже на англоязычный промпт.
Ниже: разбор метрик pp и tg, поведение моделей в агентных цепочках, готовые команды запуска через llama-server и критерии выбора под конкретный сценарий.
Производительность и потребление памяти: цифры на M1 Air
Сводка замеров, опубликованных в тесте (данные автора):
| Модель | pp, t/s | tg, t/s | Память при 32k |
|---|---|---|---|
| LFM2.5 2.6B (QAD-Q4_0) | 200 | 22 | около 2,5 ГБ |
| MiniCPM5 2B (Q8_0 + draft DSpark) | 162 | 16 | около 3,8 ГБ |
Главная странность сравнения: у LFM2.5 2.6B больше параметров, но она быстрее и экономичнее. Автор теста отдельно отметил это как неожиданный результат. Объяснения в замерах нет, и сама конфигурация не изолирует причину: кванты разные (Q4_0 против Q8_0), у MiniCPM5 2B дополнительно загружена draft-модель, архитектуры тоже различаются. Корректная формулировка вывода: результат конкретной сборки на конкретной машине, а не доказанное превосходство архитектуры.
Похожие практические конфигурации под слабое железо уже собирали на MacBook Air M1 с 8 ГБ памяти: разбор компактных моделей для локального запуска показывает, как выбирать модель под 8 ГБ и какие настройки для этого нужны.
Что означают pp и tg в контексте агентных задач
pp (prompt processing, он же prefill) - скорость, с которой модель читает вход: системный промпт, историю диалога, результаты вызова инструментов. tg (token generation) - скорость, с которой она пишет ответ или формирует аргументы для инструмента.
В агентном сценарии важны обе метрики. Агент получает от веб-поиска или другого инструмента несколько тысяч токенов текста, и их нужно переварить до генерации. Разница видна на простой арифметике: 100 токенов ответа при 22 t/s - это примерно 4,5 секунды, при 16 t/s - около 6,3 секунды. Ответ на 300 токенов растягивается с 13,6 до 18,8 секунды. С prefill похожая история: 2000 токенов результата поиска обрабатываются примерно за 10 секунд при 200 t/s и за 12,3 секунды при 162 t/s.
Как читать чужие заявленные tok/s и не попадать в ловушку разных методик, разбирали в материале о заявленной производительности локального инференса на Apple Silicon: часть цифр в отчётах пока не подтверждена независимыми замерами.
Ещё нюанс: pp в отчётах llama.cpp зависит от длины контекста и размера батча, а tg падает по мере роста контекста. Значения 200/22 и 162/16 получены в одном запуске на M1 Air, а не в стандартизированном бенчмарке.
Агентные возможности: веб-поиск, инструменты и галлюцинации
Обе модели работают с инструментами и умеют искать в интернете ответы на простые вопросы. Задачи, где они показали себя нормально: найти факт в вебе и сформулировать ответ, вызвать инструмент с корректными аргументами, обработать результат вызова и выдать финальный текст. Для моделей такого размера это рабочий уровень.
Разница проявляется на длине цепочки. LFM2.5 2.6B уверенно идёт по короткому маршруту "запрос - вызов инструмента - ответ". MiniCPM5 2B в англоязычном режиме автор теста оценил как потенциально более сильную в агентной работе, хотя количественно это не проверял.
Почему LFM2.5 2.6B галлюцинирует в длинных диалогах
По наблюдению автора, модель начинает выдумывать по мере роста диалога. Метрик в тесте нет, это качественная оценка. Механизм у малых моделей общий: чем длиннее история, тем больше доля постороннего контекста, и тем выше шанс, что модель подмешает в ответ то, чего не было ни в инструкции, ни в данных инструмента. Ситуацию усугубляет накопление результатов поиска с противоречивой информацией.
Что с этим делать на практике:
- держать диалог коротким и сбрасывать контекст между независимыми задачами;
- строить работу как одношаговые вызовы: агент получает задачу, делает один вызов инструмента и возвращает результат;
- передавать результат инструмента в урезанном виде, а не целиком;
- проверять критичные факты вторым проходом или внешней проверкой.
Границу, за которой начинается деградация, автор не измерял. Если сценарий требует длинных многошаговых цепочек, на M1 Air стоит смотреть в сторону моделей крупнее.
Языковая проблема MiniCPM5 2B: китайский вместо английского
MiniCPM5 2B регулярно отвечает на китайском, хотя промпт написан по-английски. Причины в тесте не разбираются, поэтому обходные пути строятся на общих практиках: явно фиксировать язык ответа в системном сообщении, добавлять один-два примера нужного языка и проверять первый ответ перед тем, как отдавать агенту длинную цепочку шагов. Гарантии нет, речь идёт о наблюдении одного пользователя на одной конфигурации.
Когда модель всё же отвечает на английском, автор теста оценил её как умную и возможно более сильную в агентных задачах, чем LFM2.5 2.6B. LFM2.5 2.6B, по его же словам, лучше выровнена под англоязычный разговор и стабильнее по языку ответа.
Как запустить обе модели через llama-server: команды и параметры
Обе модели запускались через llama-server с квантованными GGUF-файлами и включённым режимом рассуждений. Команды из теста (источник параметров запуска):
MiniCPM5 2B с draft-моделью:
llama-server --model MiniCPM5-2B-Q8_0.gguf -md MiniCPM5-2B-DSpark-Q8_0.gguf --load-mode none --spec-type draft-dspark --spec-draft-n-max 2 -ngl all -ngld all -fa on -np 1 -t 4 -c 32000 --reasoning on -fit off --temp 1.0 --top-p 0.95 --cache-type-k q5_1 --cache-type-v q5_1 --spec-draft-type-k q8_0 --spec-draft-type-v q8_0LFM2.5 2.6B:
llama-server -m LFM2.5-2.6B-QAD-Q4_0.gguf -ngl all -fa on --load-mode none --temp 0.1 --top-k 50 --top-p 0.9 -c 32000 --threads 4 --reasoning on -fit off --reasoning-preserveОбщие параметры: -ngl all отправляет все слои на GPU (на Apple Silicon - через Metal), -fa on включает Flash Attention, -c 32000 задаёт контекст 32k, --reasoning on включает режим рассуждений, -fit off отключает автоподгонку параметров под доступную память. У MiniCPM5 2B добавлены -np 1 (один слот обработки запросов) и -ngld all (все слои draft-модели на GPU), у LFM2.5 2.6B - --threads 4 и --reasoning-preserve, сохраняющий блок рассуждений в истории, чтобы агент видел собственные шаги.
Различия по семплингу показательны: у LFM2.5 2.6B --temp 0.1, --top-k 50 и --top-p 0.9, то есть почти детерминированная генерация. У MiniCPM5 2B --temp 1.0 и --top-p 0.95 - заметно более свободный режим. Эти настройки тоже влияют на поведение, поэтому сравнивать модели строго по приведённым запускам нельзя.
Спекулятивное декодирование для MiniCPM5 2B: зачем нужна draft-модель
Draft-модель (в тесте - DSpark) ускоряет генерацию через спекулятивное декодирование: компактная модель предлагает несколько следующих токенов, основная проверяет их за один проход и принимает те, что совпали с её распределением. Параметр --spec-draft-n-max 2 ограничивает длину гипотезы двумя токенами, --spec-type draft-dspark задаёт тип спекуляции, --spec-draft-type-k q8_0 и --spec-draft-type-v q8_0 - квантизацию KV-кэша draft-модели.
Цена схемы - дополнительная память: те самые примерно 3,8 ГБ при контексте 32k против 2,5 ГБ у LFM2.5 2.6B, которая запускается без второй модели. В этом тесте спекуляция не помогла: MiniCPM5 2B осталась медленнее и по prefill, и по генерации.
Настройки квантизации и контекста
LFM2.5 2.6B запускалась в квантизации QAD-Q4_0, MiniCPM5 2B и её draft-модель - в Q8_0. Q4_0 упаковывает веса грубее и экономит память, Q8_0 точнее, но требует больше места и трафика. Несмотря на более экономный квант, LFM2.5 2.6B не потеряла в скорости: prefill и генерация у неё выше.
KV-кэш MiniCPM5 2B сжат до q5_1 (--cache-type-k q5_1, --cache-type-v q5_1), что позволяет удержать 32k контекста без раздувания памяти. У LFM2.5 2.6B типы KV-кэша в команде не заданы, то есть использовались значения по умолчанию. Контекст 32k выбран в обоих запусках: для агента с веб-поиском этого хватает, а на 8-гигабайтной машине такой объём оставляет запас под систему.
Что выбрать для агентных задач на M1 Air: рекомендации по сценариям
Явного победителя нет: у моделей разные сильные стороны, и выбор зависит от того, что для вас важнее.
Когда LFM2.5 2.6B - лучший выбор
- Одношаговые задачи: ответить на вопрос через веб-поиск, вызвать один инструмент, разобрать небольшой файл.
- Сценарии, где важны скорость реакции и запас памяти. 2,5 ГБ при 32k оставляют место системе и другим приложениям.
- Англоязычные диалоги: язык ответа предсказуем.
- Короткие сессии, где деградация в длинных диалогах не успевает проявиться.
Когда стоит присмотреться к MiniCPM5 2B
- Задача ближе к настоящей агентной работе, чем к простому вопросу-ответу, и модель отвечает на английском.
- Есть запас памяти: 3,8 ГБ на модель плюс системные расходы на 8 ГБ уже ощутимо.
- Вы готовы экспериментировать с языком ответа через системный промпт.
- Скорость не критична, важнее потенциальное качество на сложных шагах.
Обе модели остаются компромиссом под слабое железо. Для длинных многошаговых агентов и больших контекстов разумнее смотреть на конфигурации посерьёзнее: есть практический пример с Mac mini M4 Pro в роли сервера локальных AI-агентов и разбором, какая конфигурация подходит для разных сценариев. Перед сменой рабочего стека стоит пройти чек-лист оценки новых AI-моделей, чтобы не переезжать из-за одной удачной цифры в чужом отчёте.
Ограничения теста и что важно помнить
- Замеры сделал один пользователь на MacBook Air M1. Воспроизводимость не проверялась, это набор наблюдений, а не стандартизированный бенчмарк.
- Скорость и память зависят от квантизации, версии llama.cpp, драйверов Metal, длины контекста и параллельных процессов на машине.
- Выводы о галлюцинациях LFM2.5 2.6B и об ответах MiniCPM5 2B на китайском качественные, без количественных метрик. Как часто это происходит, тест не показывает.
- Разные настройки семплинга (temp 0.1 против temp 1.0) и разные кванты не дают сравнивать архитектуры моделей напрямую.
- Обе модели малы по современным меркам: они годятся для одношаговых агентных задач, поиска и извлечения данных, но не заменят крупную модель в планировании.
Практический шаг: скачайте оба GGUF, поднимите llama-server с теми же флагами и прогоните два-три своих сценария, включая один длинный диалог. Разница между моделями такого размера проявляется на конкретных промптах, а не в общих рейтингах.