Дисклеймер: я держу сервис аренды маков, поэтому у меня под рукой флот одинаковых машин и повод их гонять. Цифры ниже с этих машин, методика описана полностью, данные открыты под CC BY. Ссылок на сервис в статье нет.
Зачем очередной бенчмарк
Запросов «сколько тянет мак» в чатах много, ответов тоже, но почти все без методики: неизвестно квантование, неизвестна версия Ollama, один прогон вместо серии, непонятно, что происходило на машине в этот момент. Такие числа нельзя ни перепроверить, ни сравнить между собой.
Я замерил шесть моделей на одной конфигурации и описываю всё, что может повлиять на результат.
Методика
Железо: Mac mini M4, 16 ГБ unified memory, пропускная способность 120 ГБ/с. Машина в остальном простаивала только системные демоны.
Софт: Ollama 0.31.2, macOS 15.3.1 (Sequoia).
Квантование: Q4_K_M у всех моделей.
Промпт: одинаковый для всех просьба объяснить механизм внимания в трансформерах на 300 слов для джуна, с одной конкретной аналогией.
num_predict = 512,temperature = 0.7.Прогоны: 3 на модель, плюс один прогревочный (отбрасывается). Разброс между прогонами до 0.5%.
Прогрев важнее, чем кажется: первый запуск включает загрузку весов в память, и если его не отбросить, картина смещается на десятки процентов.
Результаты
Модель |
Параметров |
Генерация, ток/с |
Обработка промпта, ток/с |
|---|---|---|---|
Llama 3.2 3B |
3B |
46.7 |
1720 |
Mistral 7B |
7B |
22.8 |
645 |
Qwen 2.5 7B |
7B |
22.3 |
1130 |
Llama 3.1 8B |
8B |
21.2 |
587 |
DeepSeek R1 8B |
8B |
20.0 |
531 |
Qwen 2.5 14B |
14B |
11.7 |
606 |
Разброс между тремя прогонами каждой модели 0.5%, то есть цифры устойчивые.
Отдельно любопытна разница в обработке промпта у Mistral 7B (645) и Qwen 2.5 7B (1130) при почти одинаковой скорости генерации: модели одного размера, но по разному устроен токенизатор и внимание, и на префилле это видно, а на генерации нет.
Что из этого следует
Генерация упирается в память, а не в вычисления. Скорость почти линейно следует за пропускной способностью памяти и обратно за размером модели. Отсюда практическое правило: прикинуть скорость можно, поделив полосу на размер весов. Для 8B в Q4 (~4.7 ГБ) при 120 ГБ/с получается около 25 ток/с измеренные 21 попадают в ожидание с поправкой на накладные расходы.
Поэтому на M4 Pro (273 ГБ/с) и M4 Max (546 ГБ/с) прирост будет примерно кратен полосе, а не числу ядер. Своих замеров на них у меня пока нет, поэтому конкретных чисел не даю как появятся, добавлю в таблицу.
Комфортный потолок 16 ГБ - 8B. До 8B модели выдают 20+ ток/с, это быстрее, чем читает человек: ассистент по коду, разбор документов, локальный RAG работают нормально. 14B формально запускается, но 11.7 ток/с это уже ожидание, и на длинных ответах оно раздражает. Для 14B и выше нужны 24-32 ГБ и другая полоса.
Длинный контекст не проблема. Обработка промпта идёт от 530 до 1720 ток/с в зависимости от модели, то есть на порядок два быстрее генерации. Закинуть в контекст большой документ дёшево; дорого потом это генерировать.
Чего в замерах нет
Честно про ограничения: одна конфигурация, одно квантование, один тип задачи (генерация связного текста). На кодовых задачах с длинными выводами картина может отличаться, батчинг я не мерил вовсе это отдельная история, и на 16 ГБ он упирается в KV-кэш быстрее, чем в скорость.
Данные и методика: https://macyou.co/benchmarks лицензия CC BY, можно брать и перепроверять.
Если у вас есть машины на M1/M2/M3 или на 24-64 ГБ присылайте свои замеры по этой же методике, соберу сводную таблицу. Разрозненных цифр по интернету много, воспроизводимых почти нет.
Комментарии (15)
malyazin_2010
03.08.2026 10:04Есть сайт https://whatmodelscanirun.com/ там результаты примерно совпадают с вашими. 12т/сек у qwen14b
Macyou Автор
03.08.2026 10:04Спасибо, сайт не знал, полезный. Забавно, что сошлось: у них 12 на qwen14b, у меня в замере 11.7. При этом у них расчёт по объёму и полосе, а у меня прогон на живой машине. Когда независимая оценка и фактический замер сходятся в пределах пары процентов, это хороший знак для обоих.
0x00fe
03.08.2026 10:04Еще неплохо было бы указать размер контекста
Macyou Автор
03.08.2026 10:04Справедливо, и это пробел в методике. В этих прогонах я не выставлял
num_ctxявно, то есть работал дефолт Ollama. Промпт короткий, около тридцати токенов, генерация ограничена 512, так что окно фактически не использовалось и на эти конкретные цифры не влияло. Но для воспроизводимости указать было нужно, тут вы правы. В следующей серии зафиксирую значение явно и добавлю отдельный замер: как падает скорость по мере роста контекста. Это как раз то, что важно для сценария с агентом, про который пишет @adkomarov выше, там окно забивается быстро.
spiteman
03.08.2026 10:04В целом да, есть куча сайтов и да, как правило достаточно знать скорость памяти и провести несложный расчёт.
А так в целом, 16 гб очень мало, и 32 маловато, но что то уже можно запускать. Так в целом этот вопрос почти такой же как на уровне, а сколько intel 5 8350u генерирует токенов? 3-5 токенов с маленькой LLM, вопрос зачем оно вам?
Macyou Автор
03.08.2026 10:04По расчёту согласен, я сам это правило в статье и привёл: полоса поделить на размер весов даёт хорошую первую прикидку. Спорить тут не с чем. Но расчёт даёт верхнюю границу, а не факт. На 8B он обещает около 25 ток/с, замер даёт 21. Пятнадцать процентов разницы, и для вопроса «хватит или нет» это как раз тот диапазон, где решение меняется. А главное, из полосы вообще не выводится префилл. У Mistral 7B и Qwen 2.5 7B на одной машине генерация практически одинаковая, 22.8 против 22.3, а обработка промпта отличается почти вдвое: 645 против 1130. Разница не в памяти, она в токенизаторе и устройстве внимания. Для агента с длинным контекстом префилл важнее генерации, и никакой калькулятор эту цифру не даст. Про Intel аналогия хромает не в ту сторону. У 8350U двухканальный DDR4 это порядка 35-40 ГБ/с, и встроенная графика к этой памяти доступа толком не имеет. У M4 это 120 ГБ/с, и GPU работает со всей памятью напрямую. Разница не в процентах, а в классе: 3-5 токенов против 21 на той же 8B. Зачем это мне: у меня люди арендуют маки и спрашивают, потянет ли машина их модель. Раньше я отвечал «наверное, да», теперь показываю таблицу. И тем, кому нужно 32-64 ГБ, отвечаю честно, что базовый M4 не подходит, это тоже полезный ответ.
spiteman
03.08.2026 10:04скажу даже больше как обладатель M1 Max 64 gb - все равно так только поиграться хватает )))) хотя и скорости лучше 400 ГБ/с по памяти. Тут недавно статья была - кластеры собирают из 2 макбуков по 16 гб оперативки... Вообщем баловство это все, почти как майнингом биткойна сейчас заниматься на ноутбуке - что то будет, но потери на электричестве - больше.
Те люди, кто у вас это спрашивают, не в теме... и все равно не разберутся скорее всего. Они только одно знают, "ооо, можно локально запустить и все будет дома, и "бесплатно" "))) а то что они получат так себе результат, их как будто не касается. Не тратьте на таких время.
adkomarov
Во вторую версию бенчмарка стоит внести спекулятивный декодинг если задача состоит в том, чтобы измерить скорость генерации за заданное количество озу. Запускать на чистой llama.cpp с вынесением слоев в интегрированную насколько возможно. Запуск на чистой системе если возможно с отключением графики если вопрос сколько реально можно выдать из системы против вопроса для комфортной работы с параллельным запуском модели.
FlashFunction
Спекулятивный декодинг требует draft-модели той же архитектуры, а какую вы бы предложили в пару к, скажем, Llama 3.1 8B на 16 ГБ, чтобы обе модели вообще влезли в память вместе с KV-кэшем?
adkomarov
Macyou Автор
Спасибо за команды, забрал целиком. EAGLE3 не видел, буду смотреть. Согласен, что на 8B гарантий нет. На маке добавляется своя причина: у драфтера и основной модели одна полоса памяти, а именно в неё всё и упирается. Вполне может выйти ноль. Результат опубликую в любом случае, отрицательный тоже полезен, их обычно никто не пишет.
Macyou Автор
По памяти влезает. 8B в Q4_K_M это около 4.9 ГБ, драфтер 1B в Q8 около 1.3 ГБ, KV на 8к контекста с квантованием кэша до q8_0 меньше гигабайта. Суммарно в районе 7 ГБ, и это укладывается даже с поправкой на то, что память общая и система забирает своё. Вопрос не влезет ли, а даст ли прирост. На дискретной карте драфтер обычно выигрывает, потому что основная модель упирается в вычисления. На Apple Silicon горлышко это полоса памяти, и драфтер конкурирует за неё же. Может оказаться, что выигрыш съест сам себя.
Macyou Автор
Разумно, но это два разных замера, и я сознательно делал первый. Мой вопрос был такой: что получит человек, который поставил Ollama и запустил модель, ничего не настраивая. Так делает большинство, и для этого сценария цифры честнее всего. Ваш вопрос другой: сколько железо выдаёт на пределе. Это отдельная статья, и она интереснее. Спекулятивку и чистый llama.cpp заберу. Пара уточнений по маку. Выносить слои в интегрированную не нужно, на Apple Silicon память общая, отдельной видеопамяти нет, и
ngl autoгрузит всё в GPU по умолчанию. Потолок задаёт не количество слоёв, а wired limit: система отдаёт под GPU примерно две трети RAM, поднимается черезsysctl iogpu.wired_limit_mb. Про графику по сути верно, но у меня машины стоят без монитора, рабочий стол на них почти ничего не ест. Разницу всё равно померяю, любопытно.adkomarov
Статья хорошая, мало кто делает на реальном железе прогоны, большинству правда проще поставить ollama с gui увидеть, что "не тянет". Думаю и имеет смысл выжимать по максимуму. Тут просто два конкретных сценария: комфортная работа и локальная модель, локальная модель отдаёт ответ по апи и агент выжимает все соки.
Macyou Автор
Спасибо! Различение точное, и оно даже глубже, чем звучит. Это не просто «быстрее или медленнее», это разные оптимумы. Человеку за клавиатурой важны скорость одного потока и время до первого токена: пока ответ обгоняет чтение, всё нормально, дальше прирост почти не чувствуется. Агенту важна пропускная способность на параллельных запросах и то, как ведёт себя KV кэш на длинном контексте, а время до первого токена ему безразлично. Отсюда неочевидное следствие: под агента иногда выгоднее модель поменьше с большим окном, чем крупная и медленная, хотя по одиночному замеру вторая выглядит солиднее. И на 16 ГБ второй сценарий упирается не в скорость, а в память: параллельные запросы съедают её кэшем раньше, чем кончается вычислительный запас. Возьму оба сценария в следующий замер, разделю явно.