Суть кейса: 20 против 100 токенов в секунду
Автор кейса запускал Qwen 3.8 27B на MacBook M5 Pro с 48 ГБ унифицированной памяти через llama.cpp и квантование Unsloth Q6: около 20 токенов в секунду. На настольной Linux-системе с RTX 3090, той же моделью в Q4 и движком vLLM средняя скорость поднялась примерно до 100 токенов в секунду. Прирост пятикратный, и он пришёл сразу от двух изменений: сменился движок инференса и класс железа.
Две детали стоит держать в голове с самого начала. Переход с Q6 на Q4 на Mac почти не дал прироста. На Linux-связке с vLLM вызовы инструментов (tool calls) срабатывают хуже, но модель достаточно умна, чтобы исправлять ошибки самостоятельно. Модель отдаётся через OpenAI-совместимый эндпоинт, а поверх работает кастомное десктопное приложение автора.
Что означают эти цифры на практике. 20 токенов в секунду это примерно 900 слов в минуту, быстрее, чем читает человек, так что для живого диалога с моделью скорости хватает. 100 токенов в секунду меняют режим работы: ответ на 1500 токенов приходит за 15 секунд вместо 75. В агентном сценарии, где модель делает десяток шагов с вызовами инструментов, разрыв превращается в минуты ожидания на каждую задачу.
Оговорки, без которых цифры вводят в заблуждение. Это опыт одного разработчика, а не воспроизводимый бенчмарк. В описании кейса нет версий llama.cpp и vLLM, версии драйверов, сборки операционной системы и параметров запуска. Не сказано, как именно измерялась скорость: только генерация или среднее по запросам, на какой длине контекста, с каким размером батча. Поэтому 20 и 100 токенов в секунду стоит читать как порядок величин для конкретной конфигурации, а не как гарантированный результат на похожем железе.
Почему на Mac не помогло квантование Q6 и Q4
На Apple Silicon память общая для CPU и GPU, и от её пропускной способности зависит почти вся скорость декодирования. Mac mini с M5 Pro конфигурируется вплоть до 18 ядер CPU, 20 ядер GPU, 64 ГБ унифицированной памяти и пропускной способности до 307 ГБ/с. При генерации каждого токена модель читает из памяти все активные веса, поэтому скорость декодирования упирается в объём этих весов, поделённый на пропускную способность памяти.
Логика подсказывает простой вывод: если Q4-веса вдвое компактнее Q6, декодирование должно ускориться примерно вдвое. В кейсе этого не произошло. Правдоподобное объяснение одно: узкое место лежало не в объёме читаемых весов. Кандидаты на эту роль: накладные расходы бэкенда llama.cpp на Metal, обработка длинного контекста, трафик KV-кэша, а также пошаговые издержки на хосте при сэмплинге и работе с токенами. Пока эти издержки доминируют, экономия на весах ничего не даёт.
Отсюда практический вывод для владельца Mac: снижать квантование ради скорости имеет смысл только после того, как вы проверили, где реально теряются токены. Если Q4 не ускоряет генерацию, вы платите качеством ответов без выигрыша во времени. Обратный вывод тоже неверен: называть Q4 бесполезным нельзя, потому что на дискретной GPU та же 4-битная модель выдала около 100 токенов в секунду.
Для калибровки ожиданий по Apple Silicon полезны заявленные цифры по другим моделям: 45 токенов в секунду на M4 Max и 25 токенов в секунду на M2 Ultra для Qwen3.8-Flash-Next-oQ4e-mtp. Это маркетинговые ориентиры, а не независимые измерения, и разбор этих цифр и чек-лист для собственного теста локального инференса помогают понять, почему сравнивать такие числа напрямую с 20 токенами в секунду из этого кейса нельзя.
llama.cpp против vLLM: что именно даёт пятикратный разрыв
Разрыв объясняется не одной причиной. llama.cpp проектировался как универсальный движок: формат GGUF, работа на CPU, на Metal, на CUDA и Vulkan, запуск одной модели на самом разном железе. vLLM решает другую задачу: выжать максимум токенов в секунду из NVIDIA GPU, когда запросов много и они приходят потоком.
На стороне vLLM работу делают два механизма.
PagedAttention и continuous batching простыми словами
KV-кэш хранит состояния внимания для всех предыдущих токенов запроса. Наивная реализация отводит каждому запросу непрерывный участок памяти под максимально возможную длину контекста, и большая часть этого участка простаивает. PagedAttention режет кэш на блоки фиксированного размера, как страницы виртуальной памяти в операционной системе, и выдаёт их по мере надобности. Фрагментация памяти падает, и в те же 24 ГБ VRAM помещается больше одновременных запросов и более длинный контекст.
Continuous batching работает на уровне планировщика: сервер не ждёт, пока завершится вся пачка запросов, а подставляет новые на каждом шаге декодирования, как только освобождается место. GPU не простаивает между итерациями, и суммарная пропускная способность растёт. Для одиночного чата на RTX 3090 это не даёт почти ничего. Для агента, который генерирует несколько параллельных веток, или для сервера на несколько пользователей выигрыш большой.
Когда llama.cpp всё ещё выигрывает
- macOS и Apple Silicon, где Metal-бэкенд работает из коробки и не требует CUDA.
- Машины без NVIDIA GPU, включая системы только на CPU.
- Жёсткая нехватка VRAM, когда нужны агрессивные кванты уровня Q3 и ниже.
- Один пользователь и один поток запросов, где батчинг нечего оптимизировать.
- Быстрый старт эксперимента: один GGUF-файл и запуск сервера, который тоже отдаёт OpenAI-совместимый API.
Честное сравнение движков усложняет ещё один нюанс: под Q4 в мире vLLM обычно понимают не GGUF, а AWQ, GPTQ или FP8-веса. В кейсе сменились сразу три переменные: железо, движок и формат квантования. Разложить пятикратный прирост на вклад каждой из них по описанию невозможно.
Если выбираете движок под свою конфигурацию, полезно начать со сравнения Ollama, MLX, vLLM и SGLang для локального запуска Qwen 3.8 27B: там собраны тесты скорости, известные баги FP8 и рекомендации под конкретное железо.
Tool calls на Linux и vLLM: хуже, но модель исправляется
Наблюдение из кейса звучит так: на связке Linux и vLLM вызовы инструментов срабатывают хуже, при этом Qwen 3.8 27B достаточно умна, чтобы исправлять ошибки самостоятельно. Причины в описании не раскрыты, поэтому дальше речь о том, что стоит проверить у себя, а не о готовом диагнозе.
Первое, на что смотреть, это шаблон вызова инструментов. У каждой модели свой формат разметки вызова, и сервер должен его правильно распарсить. Если шаблон в конфиге сервера не совпадает с тем, на котором модель обучали, вызовы будут ломаться на уровне синтаксиса, а не рассуждений. Второй подозреваемый это уровень квантования: 4 бита снижают точность генерации, а жёсткая структура JSON или XML страдает от этого первой. Третий фактор это параметры сэмплинга: высокая температура повышает шанс синтаксической ошибки в структурированном выводе.
Практические меры для тех, кто строит агента на такой связке:
- Прогонять реальные сценарии вызова инструментов, а не один демо-запрос: ошибки проявляются на длинных цепочках и специфичных схемах аргументов.
- Включать структурированный вывод и валидацию схемы на стороне приложения, чтобы ловить битый ответ до исполнения инструмента.
- Оставлять fallback: повторный запрос, понижение температуры, откат на более мягкий квант.
- Логировать сырые ответы модели вместе с распарсенным результатом, иначе причину сбоя не найти.
Способность модели самостоятельно исправляться снижает число видимых сбоев, но не заменяет контроль. Самокоррекция съедает лишние токены и время, а на длинном пайплайне один неудачный вызов может увести всю цепочку в сторону. Для продакшн-агента это риск, который нужно измерять на своих задачах.
Практический стек: как воспроизвести конфигурацию
Архитектура из кейса состоит из четырёх слоёв. Снизу железо: настольная Linux-система с RTX 3090. Выше движок vLLM, который держит Qwen 3.8 27B в 4-битном варианте и обслуживает запросы на GPU. Затем OpenAI-совместимый эндпоинт: приложение обращается к нему теми же SDK и форматами, что и к облачным API. Наверху кастомное десктопное приложение, которое и создаёт нагрузку.
Такая схема удобна тем, что смена движка или железа не требует переписывать приложение: пока эндпоинт совместим с OpenAI API, клиентский код остаётся прежним. Тот же приём работает и на Mac, где вместо vLLM поднимают llama.cpp или LM Studio, а модель берут в GGUF-кванте вроде Unsloth Q6.
Ориентир по зрелости софта на Apple Silicon дают тесты самой Apple: Mac mini с M6 обрабатывает команды больших языковых моделей в LM Studio до 4,8 раза быстрее модели на M4. Это внутренние измерения производителя, но они показывают, что стек для локального инференса на Mac развивается, а не замирает.
Если планируете считать бюджет памяти под конкретный квант и длину контекста, пригодится практическая схема запуска Qwen3.8-27B в true Q4_K_M с раскладкой слоёв и настройкой KV-кэша: логика распределения памяти там разобрана по шагам, вплоть до selective FFN placement.
Mac или дискретная GPU: критерии выбора без иллюзий
Сравнивать платформы по одной цифре токенов в секунду бессмысленно. У каждой стороны свои сильные места, и решение зависит от того, что для вас дороже: время генерации, тишина в комнате, объём доступной памяти или простота настройки.
Сколько VRAM нужно для Qwen 3.8 27B
Грубая арифметика для плотной модели на 27 млрд параметров: 4 бита на параметр это около 13,5 ГБ только под веса, плюс служебные расходы на эмбеддинги и метаданные, итого ориентировочно 15-16 ГБ. 6-битный вариант требует примерно вдвое большего объёма. К этому добавляется KV-кэш, который растёт вместе с длиной контекста и числом одновременных запросов.
Отсюда расклад по железу: 24 ГБ VRAM у RTX 3090 спокойно вмещают Q4 с запасом под KV-кэш на умеренном контексте, а Q6 туда влезает уже впритык или не влезает вовсе. MacBook M5 Pro с 48 ГБ унифицированной памяти держит Q6 целиком, но работает медленнее на генерации. Точные границы зависят от длины контекста и батча, поэтому бюджет памяти стоит считать под свой сценарий, а не по чужой таблице. Приёмы экономии памяти на длинном контексте разобраны в материале о запуске Qwen 3 с контекстом 200K+ на 16 ГБ VRAM.
Энергопотребление, шум и стоимость владения
RTX 3090 потребляет порядка 350 Вт по паспорту, и это только видеокарта. К ней нужны мощный блок питания, продуваемый корпус и продуманное охлаждение, а всё вместе означает шум под нагрузкой и заметный вклад в счёт за электричество при круглосуточной работе. Mac mini с M5 Pro в этом смысле противоположность: тихая и энергоэффективная машина, которая к тому же поддерживает Thunderbolt 5 и позволяет соединять несколько устройств для запуска крупных моделей.
Как считать деньги, показывает разбор экономики инференса на Apple Silicon со стоимостью за миллион токенов: там энергопотребление и цена токенов измерены для пяти моделей, и результат неочевидный. Стоимость сборки с RTX 3090 зависит от того, что у вас уже есть: если корпус, БП и платформа в наличии, апгрейд сводится к цене видеокарты, а сборка с нуля обходится дороже. Считайте по актуальным прайсам своей конфигурации, а не по средним цифрам из обзоров.
Сценарии, где выбор очевиден. Для интерактивной работы с высокой скоростью генерации и для агентных пайплайнов, которые запускаются часто, дискретная GPU с vLLM даёт кратный выигрыш. Для тихой и энергоэффективной системы с большим объёмом памяти под тяжёлый квант Mac остаётся практичным вариантом, особенно если скорость генерации не критична, а настройка не должна занимать вечер.
Что это значит для локальных LLM в 2026 году
Кейс показывает, что гонка за токенами в секунду быстро упирается в потолок железа. Пока вы наращиваете скорость инференса, расходы растут линейно: больше GPU, больше энергии, больше шума. Альтернативный путь описан в концепции оптимизационного слоя: цель не в том, чтобы экономить токены, а в том, чтобы сократить объём вычислений и перемещения данных до того, как запрос дойдёт до дорогого инференса.
Такой слой может фильтровать и дедуплицировать входные данные, сжимать контекст, выполнять детерминированные операции без участия LLM и отправлять на дорогую модель только те задачи, где действительно нужны рассуждения. Простые классификации и извлечение полей закрывает маленькая модель или обычный код, а большая модель получает только сложные случаи. Метрика здесь меняется: считать стоит не сэкономленные токены, а полезный результат задачи на потреблённые вычислительные ресурсы.
Отсюда практический вывод для выбора между Mac и дискретной GPU. Если ваш пайплайн пропускает через модель всё подряд, никакое железо не даст комфортной скорости: вы будете платить временем или электричеством за работу, которую можно было не делать. Сначала стоит убрать из потока лишнее и оценить реальную нагрузку, и только потом решать, нужна ли RTX 3090 с vLLM или хватает Mac с llama.cpp.