
Комментарии 15
Во вторую версию бенчмарка стоит внести спекулятивный декодинг если задача состоит в том, чтобы измерить скорость генерации за заданное количество озу. Запускать на чистой llama.cpp с вынесением слоев в интегрированную насколько возможно. Запуск на чистой системе если возможно с отключением графики если вопрос сколько реально можно выдать из системы против вопроса для комфортной работы с параллельным запуском модели.
Спекулятивный декодинг требует draft-модели той же архитектуры, а какую вы бы предложили в пару к, скажем, Llama 3.1 8B на 16 ГБ, чтобы обе модели вообще влезли в память вместе с KV-кэшем?
Если критична память, то Llama-3.2-1B-Instruct-Q4_K_M.gguf, если нет то Llama-3.2-1B-Instruct-Q8_0.gguf, не знаю насколько квантизация ухудшит драфтер
Примерно так:./llama-server \-m Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \-md Llama-3.2-1B-Instruct-Q8_0.gguf \--spec-type draft-simple \-c 8192 \--flash-attn \-ctk q8_0 \-ctv q8_0 \-ctkd q8_0 \-ctvd q8_0 \--spec-draft-n-max 4 \-ngl auto \-ngld auto
Если есть время то вот специализированная модель драфтер: yuhuili/EAGLE3-LLaMA3.1-Instruct-8B, которая создана именно для помощи оригиналу на llama.cpp
Для неё типо:./llama-server
-m Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
-md Llama-3.1-8B-EAGLE3.gguf
–spec-type draft-eagle3
-c 8192
–flash-attn
-ctk q8_0
-ctv q8_0
–spec-draft-n-max 4
На 8B нет гарантии ускорения от драфтера, можно попробовать использовать Llama-3.2-8B-Instruct-Q4_K_M.gguf, если цель экономить и больше загнать в KVкэш - можно попробовать vision слой отключить.
Спасибо за команды, забрал целиком. EAGLE3 не видел, буду смотреть. Согласен, что на 8B гарантий нет. На маке добавляется своя причина: у драфтера и основной модели одна полоса памяти, а именно в неё всё и упирается. Вполне может выйти ноль. Результат опубликую в любом случае, отрицательный тоже полезен, их обычно никто не пишет.
По памяти влезает. 8B в Q4_K_M это около 4.9 ГБ, драфтер 1B в Q8 около 1.3 ГБ, KV на 8к контекста с квантованием кэша до q8_0 меньше гигабайта. Суммарно в районе 7 ГБ, и это укладывается даже с поправкой на то, что память общая и система забирает своё. Вопрос не влезет ли, а даст ли прирост. На дискретной карте драфтер обычно выигрывает, потому что основная модель упирается в вычисления. На Apple Silicon горлышко это полоса памяти, и драфтер конкурирует за неё же. Может оказаться, что выигрыш съест сам себя.
Разумно, но это два разных замера, и я сознательно делал первый. Мой вопрос был такой: что получит человек, который поставил Ollama и запустил модель, ничего не настраивая. Так делает большинство, и для этого сценария цифры честнее всего. Ваш вопрос другой: сколько железо выдаёт на пределе. Это отдельная статья, и она интереснее. Спекулятивку и чистый llama.cpp заберу. Пара уточнений по маку. Выносить слои в интегрированную не нужно, на Apple Silicon память общая, отдельной видеопамяти нет, и ngl auto грузит всё в GPU по умолчанию. Потолок задаёт не количество слоёв, а wired limit: система отдаёт под GPU примерно две трети RAM, поднимается через sysctl iogpu.wired_limit_mb. Про графику по сути верно, но у меня машины стоят без монитора, рабочий стол на них почти ничего не ест. Разницу всё равно померяю, любопытно.
Статья хорошая, мало кто делает на реальном железе прогоны, большинству правда проще поставить ollama с gui увидеть, что "не тянет". Думаю и имеет смысл выжимать по максимуму. Тут просто два конкретных сценария: комфортная работа и локальная модель, локальная модель отдаёт ответ по апи и агент выжимает все соки.
Спасибо! Различение точное, и оно даже глубже, чем звучит. Это не просто «быстрее или медленнее», это разные оптимумы. Человеку за клавиатурой важны скорость одного потока и время до первого токена: пока ответ обгоняет чтение, всё нормально, дальше прирост почти не чувствуется. Агенту важна пропускная способность на параллельных запросах и то, как ведёт себя KV кэш на длинном контексте, а время до первого токена ему безразлично. Отсюда неочевидное следствие: под агента иногда выгоднее модель поменьше с большим окном, чем крупная и медленная, хотя по одиночному замеру вторая выглядит солиднее. И на 16 ГБ второй сценарий упирается не в скорость, а в память: параллельные запросы съедают её кэшем раньше, чем кончается вычислительный запас. Возьму оба сценария в следующий замер, разделю явно.
Есть сайт https://whatmodelscanirun.com/ там результаты примерно совпадают с вашими. 12т/сек у qwen14b

Еще неплохо было бы указать размер контекста
Справедливо, и это пробел в методике. В этих прогонах я не выставлял num_ctx явно, то есть работал дефолт Ollama. Промпт короткий, около тридцати токенов, генерация ограничена 512, так что окно фактически не использовалось и на эти конкретные цифры не влияло. Но для воспроизводимости указать было нужно, тут вы правы. В следующей серии зафиксирую значение явно и добавлю отдельный замер: как падает скорость по мере роста контекста. Это как раз то, что важно для сценария с агентом, про который пишет @adkomarov выше, там окно забивается быстро.
В целом да, есть куча сайтов и да, как правило достаточно знать скорость памяти и провести несложный расчёт.
А так в целом, 16 гб очень мало, и 32 маловато, но что то уже можно запускать. Так в целом этот вопрос почти такой же как на уровне, а сколько intel 5 8350u генерирует токенов? 3-5 токенов с маленькой LLM, вопрос зачем оно вам?
По расчёту согласен, я сам это правило в статье и привёл: полоса поделить на размер весов даёт хорошую первую прикидку. Спорить тут не с чем. Но расчёт даёт верхнюю границу, а не факт. На 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 не подходит, это тоже полезный ответ.
скажу даже больше как обладатель M1 Max 64 gb - все равно так только поиграться хватает )))) хотя и скорости лучше 400 ГБ/с по памяти. Тут недавно статья была - кластеры собирают из 2 макбуков по 16 гб оперативки... Вообщем баловство это все, почти как майнингом биткойна сейчас заниматься на ноутбуке - что то будет, но потери на электричестве - больше.
Те люди, кто у вас это спрашивают, не в теме... и все равно не разберутся скорее всего. Они только одно знают, "ооо, можно локально запустить и все будет дома, и "бесплатно" "))) а то что они получат так себе результат, их как будто не касается. Не тратьте на таких время.
Сколько токенов в секунду реально выдаёт Mac mini M4