Nex N2.5 Mini в 4-битном MLX-кванте выдала 133,6 токена в секунду на Apple M5 Max. Так звучит заявленный результат бенчмарка на llm-bench.io: автор теста прогнал модель в рекомендованных настройках для качества (temperature 0.7, top_p 0.95, top_k 40, reasoning_effort high) и назвал итог удачным. Высокая скорость генерации и обработки промпта, приемлемый объём памяти, стабильное качество на разных задачах, а значит, модель можно рассматривать как кандидата в движки для AI-агентов и, возможно, для написания кода.
Короткий ответ на главный вопрос. По имеющимся данным Nex N2.5 Mini - компактная языковая модель, выложенная на Hugging Face в 4-битном MLX-кванте под Apple Silicon, а отчёт о её скорости лежит на llm-bench.io. Независимых подтверждений ни существования модели, ни этого бенчмарка в доступных источниках на момент подготовки статьи нет: разработчик, число параметров, архитектура, лицензия и объём памяти тестового Mac не подтверждены. Все цифры ниже взяты из описания теста и требуют сверки с первоисточником. Причина банальная: релизы и кванты выходят быстрее, чем сообщество успевает их перепроверять, и часть данных живёт только в отчётах авторов тестов.
Практический вывод из этого не «ждём подтверждений», а «проверяем сами». Дальше - что именно смотреть, как быстро оценить цифру 133,6 tok/s и стоит ли вообще тащить модель на свой Mac.
Что такое Nex N2.5 Mini и почему о ней заговорили
Название говорит ровно две вещи: это модель из линейки Nex и вариант Mini. Что стоит за словом Mini у этого разработчика, неизвестно. У одних вендоров суффикс означает 3-4 млрд параметров, у других - 20-30 млрд с урезанным контекстом. Считать модель маленькой только по названию нельзя.
Вторая часть названия кванта - MLX 4-bit. MLX - фреймворк Apple для вычислений на Apple Silicon, который умеет работать с унифицированной памятью напрямую. 4-битный квант означает, что веса модели хранятся примерно по 4 бита на параметр вместо 16: файл весов сжимается примерно вчетверо, требования к памяти падают, но точность численных операций снижается. Для локального запуска на Mac это стандартный компромисс, а не экзотика.
Интерес к таким тестам возникает по одной причине: 133,6 tok/s - это уровень, на котором модель становится пригодной для агентных пайплайнов, где на одну задачу уходят десятки вызовов. Если каждый вызов упирается в медленную генерацию, агент превращается в игрушку.
Где скачать квант и где смотреть полные результаты
Два адреса, с которых надо начинать проверку: репозиторий модели на Hugging Face и отчёт на llm-bench.io. Точные имена репозитория и страницы бенчмарка я не привожу сознательно: в доступных материалах они не подтверждены, а подставлять похожие адреса опасно, легко попасть на чужой репозиторий или зеркало. Быстрый путь - поиск по названию модели на Hugging Face и по строке с числом 133,6 на llm-bench.io.
Чек-лист проверки перед скачиванием:
- карточка модели: кто автор, дата публикации, лицензия, заявленное число параметров;
- список файлов: есть ли вариант с пометкой 4bit, сколько весит файл весов в гигабайтах;
- страница бенчмарка: какая конфигурация Mac, длина контекста, длина промпта, версия MLX и версия модели;
- дата теста: кванты иногда перезаливают, и цифры меняются вместе с файлом;
- шаблон чата (chat template): от него зависит поддержка ролей, tool calling и параметра reasoning_effort.
Почему вокруг модели столько неопределённости
Схема повторяется от релиза к релизу. Модель появляется в квантованном виде на платформе для моделей, практик прогоняет её на своём Mac, публикует таблицу со скоростью, и дальше цифра живёт сама по себе: её пересказывают, цитируют, добавляют в подборки «что запустить на M5 Max». Независимых прогонов на момент написания нет, карточка модели может быть минимальной, автор теста не обязан раскладывать методику по шагам.
Отсюда рабочее правило: новую модель до продакшна проверяют на своих задачах. Бенчмарк отвечает на вопрос «сколько токенов в секунду на этом железе в этих условиях», а не «подойдёт ли модель вашему агенту». Первое можно взять из отчёта, второе - только из собственного теста.
Что показывает бенчмарк: 133,6 tok/s на Apple M5 Max
133,6 токена в секунду - это скорость декодирования, то есть генерации новых токенов. Метрика отвечает на вопрос, как быстро модель печатает ответ после того, как уже начала. Для локального инференса на Mac такая цифра выглядит очень высокой: модели среднего размера в 4-битном кванте на Apple Silicon обычно выдают десятки токенов в секунду, и уже 20-30 tok/s хватает, чтобы читать ответ быстрее, чем он появляется.
Вторая метрика - скорость обработки промпта, prefill. Она показывает, сколько входных токенов модель переваривает за секунду перед первым выходным токеном. В коротком чате prefill почти незаметен. В агенте с системным промптом на несколько тысяч токенов и историей вызовов инструментов он становится главным источником задержки. Поэтому в отчёте важны обе скорости: 133,6 tok/s на генерации сами по себе не доказывают, что агент из десяти шагов отработает быстро.
Третья величина, без которой картина неполна, - время до первого токена (TTFT). Оно складывается из prefill и накладных расходов рантайма. Если в отчёте нет ни TTFT, ни длины промпта, ни длины контекста, оценить интерактивность по одной цифре генерации нельзя. Автор теста отдельно отмечает высокую скорость обработки промпта и приемлемый объём памяти, но конкретные значения в описании не раскрыты.
Про качество сказано «стабильное на разных задачах». Какие задачи входили в набор, на какой длине контекста они решались и сравнивался ли 4-битный вариант с более точным, неизвестно. Пока это оценка одного прогона на одной машине, а не характеристика модели.
Настройки сэмплинга: temperature 0.7, top_p 0.95, top_k 40, reasoning_effort high
Автор выбрал параметры как рекомендованные для лучшего качества, а не для максимальной скорости. Разберём, что каждый из них делает.
- temperature 0.7 - баланс между предсказуемостью и вариативностью. Значения около 0.6-0.8 дают живые, но не хаотичные ответы; при 0 модель почти всегда выбирает самый вероятный токен и начинает повторяться на длинных генерациях.
- top_p 0.95 - нуклеарная выборка: в рассмотрение берутся токены, сумма вероятностей которых достигает 95%. Отсекает длинный хвост маловероятных вариантов, оставляя пространство для манёвра.
- top_k 40 - жёсткое ограничение: на каждом шаге выбирать можно только из 40 самых вероятных токенов. Работает как страховка от редких выбросов, особенно в структурированном выводе.
- reasoning_effort high - режим длинных рассуждений. Модель тратит больше токенов на промежуточные шаги перед финальным ответом. Для агентов и кода это чаще плюс: меньше ошибок в многошаговых задачах. Для скорости это минус: итоговое число токенов на один запрос растёт, и пропускная способность в реальном пайплайне падает относительно чистого декодирования.
Именно последний пункт стоит держать в голове, когда видите 133,6 tok/s. Если высокая настройка reasoning удваивает длину ответа, пользователь получает вдвое больше времени на задачу при той же скорости генерации. Для быстрых задач разумно сравнить high с более низкими уровнями на своих промптах и посмотреть, где качество реально проседает, а где нет.
Как читать чужие бенчмарки и не обмануться
Чек-лист, который экономит вечер экспериментов:
- длина контекста и длина промпта: скорость декодирования на 128k токенов заметно ниже, чем на 2k;
- конфигурация машины: чип, объём унифицированной памяти, версия macOS;
- версия рантайма: между релизами MLX меняются ядра внимания и скорость prefill;
- число прогонов: одна цифра без разброса ничего не говорит о стабильности;
- что именно измеряли: генерация, prefill, TTFT или всё вместе;
- был ли включён кеш промпта: с кешированием повторный prefill почти бесплатен, без него агент платит полную цену на каждом шаге.
Если хотя бы половины пунктов нет, цифра ориентировочная. Как выглядят такие отчёты на практике и почему заявленные значения не всегда переносятся на реальную работу, разобрано в материале про Qwen3.8-Flash-Next-oQ4e-mtp на Apple Silicon: там как раз случай, когда 45 tok/s на M4 Max и 25 tok/s на M2 Ultra требуют контекста, а не прямого сравнения.
Требования к Apple Silicon: какой Mac потянет Nex N2.5 Mini в MLX
MLX работает только на Apple Silicon, то есть на M1 и новее. На Intel-маках и на Windows с NVIDIA этот путь закрыт, там остаётся llama.cpp с GGUF. Ключевой ресурс на Mac один - унифицированная память: она служит и оперативной, и видеопамятью, поэтому отдельной строки «VRAM» не будет, всё упирается в общий объём чипа.
Прикидка по весам считается в одну строку: память под веса ≈ (число параметров × биты на параметр) / 8 плюс служебный запас рантайма. Для 4-битного кванта это около 0,5 байта на параметр: модель на 7 млрд параметров даст примерно 3,5 ГБ, на 30 млрд - порядка 15 ГБ. Число параметров Nex N2.5 Mini не подтверждено, поэтому считайте по фактическому размеру файла весов в репозитории на Hugging Face. Это самый надёжный ориентир, он доступен до скачивания.
Второй по величине потребитель - KV-кеш, который растёт линейно с длиной контекста. Его объём считается как 2 × число слоёв × число KV-голов × размерность головы × байты на элемент × длина контекста. Точные значения берутся из config.json модели, но правило простое: удвоили контекст, удвоили кеш. На длинных контекстах кеш легко съедает больше памяти, чем сами веса. В MLX есть квантование KV-кеша, оно снимает часть давления ценой небольшой потери точности на длинных дистанциях.
Практическое правило по запасу: оставляйте 20-30% памяти свободными под систему, браузер, редактор и сам контекст. Когда память кончается, macOS уходит в своп, и скорость падает не в разы, а на порядок. Комфортный запуск на пределе по памяти выглядит нормально в первый час и разваливается на длинном диалоге.
Apple M5 Max в описании теста указан как платформа, но конкретная конфигурация (объём памяти, версия macOS, версия MLX) не подтверждена. Разбираться, как раскладывать бюджет памяти по моделям и квантам на этом чипе, удобнее на живых примерах: в материале про то, какие локальные модели запускать на M5 Max, показано, как 4-, 6- и 8-битные форматы меняют требования к памяти и итоговую скорость.
MLX, llama.cpp и Ollama: что выбрать на Mac
MLX - нативный фреймворк Apple, заточенный под унифицированную память и Metal. 4-битный MLX-квант требует именно MLX-рантайма: файл в формате GGUF он не подхватит. llama.cpp кроссплатформенный, проще в установке и богаче по форматам квантования, но на Apple Silicon обычно не обгоняет MLX. Ollama - удобная обёртка для быстрого старта: скачал, запустил, получил OpenAI-совместимый эндпоинт. Утверждать, что MLX всегда быстрее, нельзя: результат зависит от модели, длины контекста и версии рантайма.
Выбор сводится к задаче. Нужен быстрый старт и минимум возни - Ollama. Нужен контроль над квантом, шаблоном чата и режимом рассуждений - MLX напрямую. Нужна одна сборка под Mac, Linux и Windows - llama.cpp.
Сколько памяти реально нужно под агента
Агент ест память быстрее чата. К весам добавляются длинный системный промпт, описания инструментов, история вызовов с результатами, RAG-контекст из найденных фрагментов. Всё это лежит в KV-кеше и растёт с каждым шагом. Чем длиннее контекст, тем больше памяти и тем ниже скорость генерации.
Поэтому тестировать память на коротком промпте бессмысленно. Соберите минимальный реальный пайплайн: системный промпт как в продакшне, два-три инструмента, типовой запрос пользователя. Прогоните его и посмотрите на пиковое потребление памяти и на время каждого шага. Если на третьем шаге система уходит в своп, дальше обсуждать нечего.
Подходит ли Nex N2.5 Mini для AI-агентов и написания кода
Заявленная оценка автора теста: скорость генерации и обработки промпта высокая, память расходуется приемлемо, качество держится на разных задачах, значит, модель годится для питания агентов и, возможно, для кода. Это оценка одного теста, а не подтверждённый опыт эксплуатации. Для агента важны вещи, которые в tok/s не измеряются: поддержка tool calling, стабильный JSON, длинный контекст и предсказуемая задержка.
Агентные сценарии: tool calling, RAG, автоматизация
Типовые задачи, где такая модель имеет смысл: локальный ассистент с доступом к файлам, RAG по внутренней базе документов, автоматизация рутины вроде сортировки писем и заполнения таблиц, первичная обработка логов. Во всех случаях критично, умеет ли модель вызывать инструменты по шаблону и не ломает ли структуру ответа на пятом шаге.
Что проверить до внедрения:
- поддерживает ли шаблон чата роли system, user, assistant и блок tools;
- выдаёт ли модель валидный JSON при вызове функции на серии из 20-30 запросов подряд;
- как ведёт себя на контексте 8k, 16k, 32k: где начинаются обрывы и повторы;
- сколько занимает полный цикл из пяти-десяти шагов с учётом prefill.
Риски стандартные для локальных агентов: галлюцинации в аргументах функций, битый JSON, деградация на длинной истории. Лечится валидацией выходов на стороне оркестратора, ограничением числа шагов и fallback-моделью. Как выглядит агентная модель, изначально заточенная под такие сценарии, разобрано в разборе POCKET-35B для CPU и смартфонов: там наглядно видно, какие метрики вообще стоит смотреть у агентных моделей.
Написание кода: на что смотреть кроме tok/s
Для генерации кода скорость вторична. Первичны корректность и удержание контекста проекта: понимание структуры файлов, следование принятому стилю, аккуратная правка вместо переписывания всего файла. Модель, которая выдает 130 tok/s и ломает импорты, хуже модели на 30 tok/s, которая их не ломает.
Второй момент - квантование. 4-битные веса экономят память, но на задачах с точными рассуждениями и длинными цепочками разница с 8-битным или 16-битным вариантом заметна. Для автодополнения и мелких правок её можно не почувствовать, для рефакторинга на несколько файлов - вполне. Если память позволяет, сравните 4-битный и более точный квант на своих репозиториях, прежде чем делать выводы.
Как запустить Nex N2.5 Mini в 4-битном MLX-кванте
Общий порядок действий одинаков для любого MLX-кванта. Сначала ставится рантайм, потом скачиваются веса из репозитория на Hugging Face, затем запускается генерация или сервер. Команды ниже - стандартный скелет mlx-lm с подстановкой имени репозитория, конкретные флаги сверяйте с --help вашей версии: набор опций меняется от релиза к релизу.
# рантайм MLX для языковых моделей
pip install -U mlx-lm
# генерация из командной строки; repo-id возьмите из карточки модели
mlx_lm.generate --model <repo-id> --prompt "тестовый запрос" --temp 0.7 --top-p 0.95
# локальный сервер с OpenAI-совместимым API для агентов
mlx_lm.server --model <repo-id> --port 8080Если репозиторий и точное имя кванта не подтверждены, начните с короткого прогона на стандартном промпте. Три вещи, которые надо замерить сразу: скорость генерации в токенах в секунду, пиковое потребление памяти и качество на вашем типовом запросе. Без этих трёх цифр обсуждать пригодность модели нечего.
Воспроизведение настроек из бенчмарка
Чтобы повторить условия теста, выставляются temperature 0.7, top_p 0.95, top_k 40 и reasoning_effort high. Первые три параметра задаются при генерации напрямую, reasoning_effort обычно передают через шаблон чата или параметры запроса к серверу, отдельным флагом командной строки он появляется не во всех версиях.
Дальше начинается практика. Высокий уровень рассуждений увеличивает длину ответа и расход токенов: для агентов это обмен скорости на качество. Разумный подход - прогнать один и тот же набор из пяти-десяти агентных задач на high и на более низком уровне и сравнить не только ответы, но и суммарное время. Часто оказывается, что на типовых задачах разница в качестве нулевая, а в задержке заметная.
Типичные ошибки при запуске MLX-квантов
- старая версия MLX: новые архитектуры и типы квантования не подхватываются, модель падает при загрузке;
- попытка скормить GGUF-файл MLX-рантайму: форматы несовместимы, нужен либо MLX-квант, либо llama.cpp;
- игнорирование шаблона чата: без него ломаются роли, tool calling и режим рассуждений, ответы выглядят «глупее», чем есть на самом деле;
- работа на пределе памяти: своп убивает скорость prefill, иногда в десять раз;
- тест на коротком промпте с последующим запуском в агент: самый частый источник разочарования;
- отсутствие замера после обновления рантайма: цифры меняются, старые замеры перестают быть ориентиром.
Ограничения и кому Nex N2.5 Mini не подойдёт
Начнём с главного ограничения: характеристики модели и результаты бенчмарка независимо не подтверждены. Ни числа параметров, ни лицензии, ни поддержки инструментов, ни стабильности на длинном контексте. Всё это придётся проверять самостоятельно, а значит, закладывать время на эксперименты.
Второе ограничение - платформа. MLX-квант работает на Apple Silicon и только на нём. Пользователям Windows, Linux и владельцам дискретных NVIDIA-карт этот конкретный файл бесполезен, им нужны GGUF-сборки, если они вообще существуют.
Риски 4-битного квантования
4 бита на параметр экономят память, и за это платят точностью. На простых задачах разница с 8-битным вариантом часто незаметна: пересказ, черновики, извлечение фактов, простые правки кода. На сложных она проявляется: многошаговые рассуждения, точная арифметика, аккуратное следование формату на длинной дистанции, редкие языки и узкие домены.
Для агентов и кода это критично. Ошибка в вызове инструмента или в имени поля JSON рушит весь шаг, и модель приходится переспрашивать. Если памяти хватает на 6- или 8-битный квант, сравнение стоит потраченного времени: иногда более точная версия на меньшей длине контекста даёт лучший итог, чем быстрая 4-битная. Как выбирать между уровнями квантования на Apple Silicon, подробно разобрано в материале про выбор квантизации oQ3e, oQ4e, oQ6e или oQ8e.
Когда лучше взять другую модель
Конкретные модели называть «лучшими» не буду: сравнительного теста нет, а переносить чужие цифры на свои задачи бессмысленно. Вместо этого критерии выбора:
- есть ли готовый MLX-квант, а не только GGUF;
- заявленная длина контекста и то, как модель ведёт себя на её середине;
- поддержка tool calling в шаблоне чата и качество JSON на серии вызовов;
- активность сообщества: обновления кванта, отчёты о проблемах, исправления;
- лицензия, подходящая под ваш сценарий использования;
- размер файла весов относительно свободной памяти Mac.
Если нужен пример модели с прозрачно описанными бенчмарками, скоростью и готовыми конфигурациями для локального запуска, посмотрите разбор Macaron-V1 на архитектуре MoE: там показано, какие данные о модели вообще стоит требовать от авторов перед запуском.
Кому Nex N2.5 Mini точно не подойдёт: пользователям Windows и Linux без Apple Silicon; тем, кто хочет ставить модель сразу в продакшн без собственных тестов; тем, кому нужна максимальная точность на сложных рассуждениях и строгом структурированном выводе; тем, у кого Mac с 16 ГБ памяти и плотным набором рабочих приложений.
Итог: стоит ли пробовать Nex N2.5 Mini на Apple Silicon
Заявленные 133,6 tok/s на Apple M5 Max с настройками temperature 0.7, top_p 0.95, top_k 40 и reasoning_effort high выглядят интересно для локальных агентов: такой скорости хватает, чтобы многошаговые пайплайны не раздражали задержками. Обратная сторона - отсутствие независимой проверки. Пока это один отчёт на llm-bench.io, а не воспроизведённый результат, и относиться к нему стоит соответственно.
Три шага, которые закрывают вопрос за один вечер. Первый: найти модель на Hugging Face, посмотреть автора, лицензию, размер файла весов и требования к памяти. Второй: открыть полный отчёт на llm-bench.io и проверить, указаны ли там длина контекста, длина промпта и конфигурация Mac. Третий: прогнать свой тест на реальной задаче, замерив скорость генерации, prefill и пиковое потребление памяти.
Решение зависит от трёх вещей: сколько памяти у вашего Mac, какие задачи вы собираетесь отдать модели и готовы ли вы возиться с MLX и шаблонами чата. Если ответы складываются, модель стоит попробовать. Если нужен результат без настройки и проверок, локальный запуск в целом не ваш сценарий, и облачный API закроет задачу быстрее.