Локальные LLM сейчас — это действительно мощный инструмент. Они уже вплотную приблизились к проприетарным моделям вроде Claude, особенно в задачах кодинга. Я сам активно использую локальные модели для разработки на TypeScript и Go.
На данный момент самая интересная модель для моего стека — Qwen3.6-27B. Но один только выбор хорошей модели ничего не гарантирует. Без правильных параметров вы не получите ни скорости, ни качества.
В этой статье я расскажу, с какими конкретно параметрами запускаю Qwen3.6-27B в llama.cpp (мой текущий фаворит среди бэкендов), какие метрики считаю важными, и как нашел баланс между скоростью, стабильностью и качеством.
Многие гонятся за чистой скоростью генерации токенов, но я считаю, что приоритеты должны быть другими:
Удобство — размер контекста, в который должен помещаться весь ваш диалог или код.
Стабильность — чтобы процесс не падал с OOM или ошибками CUDA.
Качество — осмысленные ответы, а не «каша» из токенов.
Скорость — но только после выполнения первых трех пунктов.
К сожалению, люди часто врут про скорость. Например, один человек утверждал, что на M3 Studio выдает 55 токен/с на Qwen3.6-27B. При детальном расспросе выяснилось:
Модель — Qwen3.6-27B-UD-IQ2_XXS.gguf (сильнейшая квантизация с огромной потерей качества)
Контекст — всего 8000 токенов
Поэтому давайте сразу договоримся: мы говорим о честной скорости при нормальном качестве и комфортном контексте.
Какие метрики скорости мы измеряем
При работе с LLM важны две цифры:
pp (prompt processing) — скорость «чтения» моделью вашего запроса. Измеряется в токенах в секунду.
tg (token generation) — скорость генерации ответа. Именно эту метрику пользователь ощущает как «быстроту» модели.
Мои показатели на Qwen3.6-27B:
pp ~2800 токенов/сек
tg ~73 токена/сек
Что влияет на pp (обработка промпта)
pp — это вычислительная задача, она упирается в количество ядер GPU, а не в пропускную способность памяти.
Факторы по убыванию важности:
Количество активных ядер GPU. На обычном CPU вы получите 1-10 т/с, на слабом GPU — 30-100, мои 2800 — это уровень RTX 3060/4060 Ti и выше.
Batch size (
--batch-size). Движок обрабатывает промпт пачками. Чем больше пачка, тем эффективнее используются ядра. Но слишком большая пачка может переполнить VRAM.Размер модели. Модель на 8B параметров будет иметь более высокий pp, чем на 70B.
Формат квантизации. FP16/Q8_0 дают меньше т/с, Q4_K_M/Q5_K_M — больше.
Flash Attention. Сильно помогает на длинных промптах, в llama.cpp включена по умолчанию.
Что влияет на tg (генерация)
tg — это последовательный процесс. Модель не может начать вычислять следующий токен, пока не получила предыдущий. Здесь главное — пропускная способность памяти (memory bandwidth).
Формула очень простая: Время генерации ~ (Размер модели в ГБ) / (Пропускная способность памяти GPU)
Вы можете разогнать ядра хоть до 3 ГГц, но если шина памяти узкая, tg не вырастет.
Что еще влияет на tg:
Размер модели и квантизация. Q4_K_M даст в 3-4 раза более высокий tg, чем FP16.
KV-кэш. На длинных диалогах (10k+ токенов) он может вытесняться в медленную память, и tg падает.
Speculative decoding (MTP). Маленькая модель-черновик пишет варианты, большая проверяет. При высоком acceptance (0.95+) вы видите иллюзию высокой скорости, но реальная tg большой модели остается ~70-75.
Мои параметры запуска
Все примеры — для Qwen3.6-27B в llama.cpp, задача — написание кода.
--ctx-size 262144
Самый важный параметр для комфорта. Он не влияет на качество ответа, но влияет на скорость (чем больше контекст, тем медленнее генерация). Я ставлю максимальный — 262144. Если контекст слишком мал, то работать иногда становится некомфортно.
--temp
Чем выше температура, тем креативнее модель. Для кодинга креатив не нужен, нужна точность.
Рекомендация создателей Qwen для точных задач кодинга: temperature = 0.6.
Очень часто люди не обращают внимание на этот параметр, так как по умолчанию всегда стоит 1, но создатели моделей всегда пишут об этом.
--top_k 20
Модель смотрит только на K самых вероятных следующих токенов. top_k = 20 — жесткий контроль, отсекает мусор. Идеально для кода.
Опять же, по умолчанию другие цифры, которые не очень хорошо работают при агентском кодинге.
--top-p 0.95
Модель берет минимальный набор самых вероятных токенов, суммарная вероятность которых ≥ 0.95. top_p — динамический фильтр, адаптируется к контексту.
Параметр | Что фиксирует | Поведение |
|---|---|---|
| число вариантов | всегда одинаковое K |
| вероятность | число вариантов плавает |
Для кода я использую оба: top_k 20 для жесткого ограничения и top_p 0.95 для адаптивной фильтрации.
--presence_penalty 0.0
Штраф за уже использованные токены. Для обычных текстов penalty = 1.5, чтобы модель искала синонимы. В коде повторения — норма, поэтому я ставлю 0.0.
repetition_penalty я не трогаю (оставляю 1.0).
Тут тоже довольно важно поменять значение которое идет по умолчанию
--batch-size 512 и --ubatch-size 256
Эти параметры управляют обработкой токенов внутри GPU:
batch-size— сколько токенов обрабатывается за один шаг.ubatch-size— размер микробатча (на сколько кусков разбивается batch).
Мои 512/256 — консервативно, но стабильно. Если у вас 2×5090 и хватает VRAM, можно пробовать:
Стабильность:
1024 / 256Баланс:
1024 / 512Максимум скорости:
2048 / 512
Что будет, если значения слишком большие: OOM, краши сервера, фризы на prefill.
MTP (Multi-Token Prediction) — --spec-type draft-mtp --spec-draft-n-max 2
Попробовал MTP в vLLM — прирост был с 50 до 55 токенов. В llama.cpp результат гораздо лучше: с 50 до 75 токенов.
Мой draft acceptance = 0.74435 (527 accepted / 708 generated). Для Qwen MTP норма — 60-75%, у меня большую часть времени 80-97% — отлично.
Кстати, создатели модели говорят что надо обновиться до 13й куды. В репах убунты обычно лежит 12я. Так что обновиться надо обязательно. Причем авторы модели еще и предупреждают о том что на CUDA 13.2 MTP может выдавать бессвязный текст (NVIDIA чинит). На CUDA 12 ничего не работает. Но уже вышла CUDA 13.3 на которой все отлично работает. Так что обязательно следите за версиями.
--cache-type-k q8_0 --cache-type-v q8_0
Квантизация KV-кэша с 16 бит до 8 бит. При контексте 262k это сокращает потребление VRAM вдвое при минимальной потере качества. Явно стоит добавлять.
--flash-attn on
Включает более эффективную реализацию Attention. Дает:
Меньше VRAM под KV-кэш
Быстрее обработку длинных промптов
Чуть выше tg на больших контекстах
На современных версиях llama.cpp и RTX 5090 auto и on дают одинаковый результат, но я ставлю on, чтобы убрать сомнения.
--ts 1,1 (tensor splitting)
Если у вас несколько видеокарт:
На одинаковых картах можно
-ts 0,0(автораспределение) или-ts 1,1(поровну)Если карты разные (8GB, 12GB, 16GB, 24GB), используйте пропорции:
-ts 8,12,16,24
Узнать порядок карт: nvidia-smi -L
--parallel 2
Позволяет обрабатывать несколько запросов одновременно. При указании --parallel 2 вы можете отправить два параллельных запроса, и они будут обрабатываться конкурентно (но с разделением ресурсов). Полезно для server-режимов, когда модель используется несколькими пользователями или процессами.
Но если вы пользуетесь серваком один то можно ставить единичку.
--reasoning-budget 0
Этот параметр контролирует, сколько токенов модель тратит на внутренние «рассуждения» (Chain-of-Thought) перед ответом. --reasoning-budget 0 полностью отключает CoT. Это правильно для кодинга, потому что лишние рассуждения только замедляют генерацию и могут внести шум в код.
Я слышал много разных рассуждений на тему того включать ли thinking при кодинге. Для себя сделал вывод, что мне он не сильно то и помогает.
Выводы
Мои текущие настройки — не истина в последней инстанции. Я продолжаю экспериментировать:
Локальные LLM реально близки к проприетарным, но только при правильной настройке.
Скорость генерации упирается в пропускную способность памяти GPU, а не в тактовые частоты.
Для кодинга нужны низкая температура, жесткий top_k, penalty = 0.0 и отключенные рассуждения.
MTP в llama.cpp работает гораздо лучше, чем в vLLM. (Или это я не до конца разобрался).
Не верьте цифрам скорости, не узнав квантизацию и размер контекста.
Используйте CUDA 13.3, а не 13.2 или 12.
Если интересно то можете подписывать в телеге на наш маленький чатик в котором мы обсуждаем такие темы - homelabru