Короткий ответ: MTP ускоряет не флаг, а удачный сценарий
Флаг spec-type draft-mtp сам по себе не гарантирует ускорения. MTP полезен, когда модель действительно поддерживает такой драфтинг, черновые токены достаточно часто принимаются основной моделью, а запуск не ограничен VRAM, длинным контекстом, меж-GPU обменом или конкурирующими запросами. Нормальную производительность нельзя свести к одному числу tokens/s: сравнивать нужно одинаковую модель, квантизацию, железо, длину промпта, длину ответа и режим нагрузки.
В статье разберём, как параметры llama-server влияют на скорость MTP-драфтинга и как понять, есть ли ещё запас для ускорения. Сначала проверим, есть ли у MTP пространство для ускорения, затем настроим длину драфта, потом рассмотрим влияние контекста, пакетов и KV-кэша, и отдельно обсудим параллелизм и multi-GPU.
Сначала проверьте, есть ли у MTP пространство для ускорения
MTP работает как speculative decoding: система предлагает несколько черновых токенов и затем проверяет их основной моделью. Выигрыш формируется не максимальным числом предложенных токенов, а сочетанием длины драфта, доли принятых предложений и стоимости их проверки. Если модель не обучена предсказывать несколько токенов, драфтинг не даст эффекта, а иногда даже замедлит генерацию.
Что означает llama-server spec-type draft-mtp
spec-type draft-mtp выбирает MTP как тип speculative-драфтинга в llama-server. Применимость зависит от конкретной модели и её поддержки данного режима. Нельзя считать MTP взаимозаменяемой настройкой для любой GGUF-модели: если модель не имеет MTP-головы, драфтинг будет случайным и бесполезным.
Почему принятие черновых токенов важнее самого длинного драфта
Длинный драфт потенциально уменьшает число шагов генерации, но непринятые токены не превращаются в бесплатное ускорение. Стиль задачи, температура и предсказуемость продолжения влияют на практическую эффективность. Выводы следует делать по логам и повторяемым замерам, а не по одному удачному ответу. Если acceptance rate низкий, увеличение spec-draft-n-max не поможет, а только увеличит накладные расходы.
Когда узкое место уже не в MTP
Признаки ограничений: нехватка VRAM и перенос части работы на более медленные ресурсы, большой активный контекст, медленный prefill длинного промпта, загрузка GPU несколькими слотами, распределение модели между GPU с заметными накладными расходами. В этих случаях сначала нужно измерить соответствующую фазу запроса. Например, если prefill занимает 10 секунд, а генерация 2 секунды, ускорение MTP на 20% сократит общее время лишь на 0.4 секунды.
Настройка MTP в llama-server: как выбирать spec-draft-n-max
Параметр spec-draft-n-max задаёт максимальное число черновых токенов. Увеличение может дать больше полезной работы за один шаг, но повышает стоимость неудачного драфта и может не улучшить итоговую скорость, если принятие токенов недостаточно высокое. Подбирать значение нужно последовательно, меняя только этот параметр и замеряя результат.
Что ограничивает spec-draft-n-max
Увеличение spec-draft-n-max может ускорить генерацию, если модель часто принимает предложенные токены. Однако при низком acceptance rate длинный драфт тратит ресурсы на проверку бесполезных токенов. Кроме того, больший драфт требует больше памяти для хранения состояний и может увеличить задержку на шаг.
Как подбирать длину драфта по одному параметру за раз
Методика: зафиксируйте модель, квантизацию, prompt, параметры сэмплирования, длину ответа, размер контекста и число параллельных слотов. Выполните несколько сопоставимых запусков с разными значениями spec-draft-n-max. Записывайте TTFT, скорость prefill, скорость decode, общую длительность и доступную VRAM. Не предлагайте универсальные числа без привязки к модели и системе.
Признаки, что драфт стал слишком агрессивным
Итоговая скорость перестала расти или снизилась, потребление памяти приблизилось к лимиту, выросла нестабильность времени ответа, а прирост в коротком тесте исчезает на рабочем контексте. Выбирать следует не максимальное значение, а лучший стабильный результат в целевом сценарии.
Контекст, batch-size и KV-кэш: настройки, которые часто съедают выигрыш MTP
MTP в первую очередь относится к генерации, тогда как длинный prompt и KV-кэш могут определять воспринимаемую задержку пользователя. Разберём параметры, влияющие на память, prefill и фактическую скорость ответа при реальных, а не минимальных промптах.
Размер контекста: почему запас ctx-size не бывает бесплатным
KV-кэш хранит состояние обработанного контекста, поэтому выделенный и фактически используемый контекст влияет на потребление памяти. Рабочий размер контекста нужно выбирать по реальным задачам, а не держать завышенным «на всякий случай», если это создаёт давление на VRAM или ограничивает параллелизм. Например, контекст 32K на модели 27B может занимать несколько гигабайт VRAM даже при коротком промпте.
batch-size и ubatch-size: различайте скорость prefill и лимиты памяти
batch-size и ubatch-size относятся к обработке токенов пакетами и могут влиять на загрузку GPU, скорость prefill и расход памяти. Увеличение значений может быть полезно до момента, когда упирается в память или даёт diminishing returns. Сравнивать следует отдельно на коротком и длинном входном контексте. Например, большой batch-size ускоряет prefill, но может вызвать OOM на длинном промпте.
Типы KV-кэша: экономия VRAM с проверкой качества и совместимости
Форматы KV-кэша, включая варианты вроде f16 и q8_0, меняют компромисс между потреблением памяти, качеством и поведением конкретного запуска. Снижение точности KV-кэша может освободить VRAM для большего контекста или дополнительных слотов, но его влияние на скорость и качество нужно проверять на целевых задачах. Например, q8_0 обычно почти не ухудшает качество, но экономит до 50% памяти KV-кэша по сравнению с f16.
Flash Attention: когда flash-attn помогает, а когда сначала нужно проверить сборку и GPU
Flash Attention может снизить расход памяти и ускорить attention, особенно заметный при работе с длинными контекстами, но доступность и эффект зависят от backend, сборки llama.cpp, архитектуры GPU и конфигурации. Не описывайте параметр как обязательный универсальный ускоритель; подтверждайте эффект сравнением при одинаковом контексте. На некоторых GPU Flash Attention может не поддерживаться или даже замедлять вычисления.
Parallel и tensor-split: не путайте скорость одного чата с пропускной способностью сервера
Параметры совместного обслуживания запросов решают иную задачу, чем MTP: parallel масштабирует число одновременных слотов, а tensor-split помогает разместить модель на нескольких GPU. Оба могут быть необходимы, но оба способны ухудшить latency одного пользователя.
parallel: больше одновременных запросов, но не обязательно быстрее ответ
parallel в llama-server позволяет обслуживать несколько запросов одновременно, что важно для API и нескольких пользователей. При ограниченных вычислительных ресурсах рост параллелизма делит GPU-время, увеличивает конкуренцию за KV-кэш и может ухудшить TTFT или decode latency отдельного запроса. Если вам нужен быстрый ответ в одном чате, держите parallel минимальным.
tensor-split: сначала решает проблему VRAM, затем становится вопросом скорости
tensor-split распределяет тензоры модели между GPU и часто нужен, когда модель не помещается на одном устройстве. Фактическая скорость зависит от баланса VRAM, производительности карт и скорости связи между ними. Неравномерное распределение или медленный обмен данными могут не дать ожидаемого прироста. Например, на двух RTX 3090 без NVLink скорость может упасть из-за передачи данных через PCIe.
Как тестировать одну GPU и несколько GPU честно
Сравнивайте идентичные модель, квантизацию, контекст, prompt, длину генерации, параметры MTP и число параллельных запросов. Отдельно измеряйте случаи, когда нужна минимальная задержка одного пользователя, и случаи, когда важна суммарная пропускная способность. Не делайте выводы по одному прогону: повторяйте тесты несколько раз и усредняйте результаты.
Как понять нормальный диапазон производительности llama.cpp
Нормальный диапазон производительности определяется не только GPU, но и моделью, квантизацией, backend, длиной контекста, MTP, параллелизмом и тем, какую метрику пользователь пытается улучшить. Универсального числа tokens/s не существует: для одной модели 20 tokens/s может быть отлично, для другой - медленно.
Четыре метрики, которые нужно смотреть вместе
Tokens/s во время генерации, TTFT как время до первого токена, скорость обработки prompt или prefill и полное время запроса. Высокая decode-скорость не компенсирует медленный ответ на длинный prompt, а хороший throughput сервера не равен комфортному TTFT для одного чата. Например, если prefill занимает 5 секунд, а генерация 1 секунду, то оптимизация decode не улучшит общее время.
Сравнивайте только сопоставимые прогоны
Фиксируйте точную модель и её квантизацию, версию и backend llama.cpp, GPU и размещение слоёв, размер и фактическую длину контекста, параметры KV-кэша, flash-attn, MTP-настройки, sampling, число запросов и длину ответа. Смена нескольких параметров одновременно не позволяет установить причину результата. Готовые цифры из чужих конфигураций часто мало полезны, потому что условия могут сильно отличаться.
Практический критерий: стало ли быстрее в вашей рабочей нагрузке
Сформируйте 2-3 постоянных сценария: короткий интерактивный запрос, длинный документ или RAG-контекст, параллельные API-запросы. Для каждого задайте приоритет: минимальный TTFT, максимальная скорость генерации либо суммарная пропускная способность. Нормальным считайте стабильный результат, который соответствует этому приоритету и не выходит за лимиты памяти. Если после изменения параметра целевая метрика улучшилась на 10% и стабильна, это хороший результат.
Порядок настройки: где искать следующий прирост скорости
Компактный порядок действий: зафиксируйте целевую нагрузку и базовые метрики; убедитесь, что модель и spec-type draft-mtp работают в ожидаемом режиме; подберите spec-draft-n-max; проверьте реальный размер контекста и запас VRAM; подберите batch-size и ubatch-size; оцените flash-attn; затем отдельно настройте parallel и tensor-split. После каждого изменения нужен повторяемый замер, а при падении стабильности или росте TTFT стоит откатиться к последней измеримо лучшей конфигурации.
Минимальный журнал замеров, который экономит часы
Записывайте конфигурацию запуска, сценарий запроса, длину входа и выхода, TTFT, prefill, decode tokens/s, суммарное время, число параллельных запросов, использование VRAM и наблюдаемые признаки нестабильности. Для первичной диагностики не нужен сложный бенчмарк-стенд: достаточно таблицы с результатами нескольких прогонов.
Когда оптимизацию лучше остановить
Признаки достаточного результата: целевой сценарий укладывается в приемлемую задержку, VRAM не работает на пределе, нагрузка стабильна, а дальнейшие изменения не улучшают ключевую метрику. Предел может задаваться моделью, GPU, объёмом VRAM или типом нагрузки, а не отсутствием «секретного» параметра. Если вы потратили несколько часов и получили прирост 2%, возможно, стоит остановиться и заняться другими задачами.