Что такое llama-manager и зачем он нужен
llama-manager это обёртка над форком llama.cpp, которая позволяет менять конфигурацию модели без перезапуска сервера и без потери KV-кэша. Инструмент представил разработчик, и главная идея простая: выжать из одной видеокарты больше контекста, не сбрасывая состояние диалога. На ходу доступны три рычага: включение и отключение speculative decoding, перенос мультимодального проектора mmproj на CPU и квантование KV-кэша прямо во время генерации.
Проект находится в статусе беты. Поддерживается только одна GPU, работа с CPU и мульти-GPU конфигурациями пока не реализована. Это стоит держать в голове до того, как нести инструмент на домашний сервер с двумя картами.
Чем llama-manager отличается от llama-server
llama-server забирает настройки один раз при запуске. Захотелось отключить speculative decoding или перевести mmproj на CPU, придётся гасить процесс, править команду и поднимать сервер заново. Вместе с процессом умирает KV-кэш: все токены, которые модель уже обработала, обнуляются.
llama-manager переносит эти переключатели в рантайм. Обёртка живёт поверх форка llama.cpp и меняет параметры, не трогая накопленное состояние. Базовое сравнение ниже.
| Параметр | llama-server | llama-manager |
|---|---|---|
| Смена конфигурации | Только через перезапуск | Во время работы |
| KV-кэш при смене настроек | Обнуляется | Сохраняется |
| Speculative decoding | Фиксируется на старте | Включается и отключается на ходу |
| mmproj | Остаётся там, где загружен | Переносится на CPU динамически |
| Квантование KV-кэша | Задаётся при запуске | Применяется во время генерации |
Отдельный движок тут не появляется. Это форк llama.cpp, поэтому модели в GGUF, флаги, сэмплеры и общая логика производительности остаются знакомыми.
Почему потеря KV-кэша - это боль
KV-кэш хранит ключи и значения внимания для всех токенов, которые модель уже прошла. Проще говоря, это память диалога в векторном виде. Пока она на месте, каждый новый токен опирается на весь предыдущий текст: документ, кусок кода, двадцать шагов агентной цепочки.
Перезапустите сервер, и кэш уйдёт. Следующий запрос заставит модель заново прогнать весь промпт через prefill. На коротком чате это секунды, на документе в 150 тысяч токенов это минуты ожидания и лишняя работа GPU. Для агентов, которые возвращаются к одному и тому же контексту десятки раз, счёт идёт на часы.
Динамическая реконфигурация закрывает ровно этот разрыв: параметры меняются под текущую задачу, а контекст остаётся тем же.
Как работает ladder: последовательность стратегий при исчерпании контекста
ladder это заданная пользователем последовательность стратегий, которую llama-manager применяет, когда контекст упирается в потолок. Логика такая: сначала освободить память способами, которые не трогают точность KV-кэша, и только потом идти на компромиссы. Порядок шагов определяет сам пользователь, а не алгоритм по умолчанию.
Цель ladder - расширить окно, сохраняя полную точность KV-кэша как можно дольше. В примере от разработчика цепочка выглядит так: отключение mtp, затем перенос mmproj на CPU, затем квантование KV до q8.
Отключение mtp и перенос mmproj на CPU
MTP (multi-token prediction) предсказывает несколько токенов за шаг и ускоряет генерацию. Плата за ускорение - дополнительная VRAM под драфт-часть. Отключили mtp, освободили память, потеряли в скорости, но точность основного KV-кэша не пострадала.
mmproj это мультимодальный проектор, который переводит изображения в эмбеддинги для модели. Если работа идёт с текстом, держать его в видеопамяти незачем. Перенос на CPU освобождает VRAM и бьёт по latency только тогда, когда в промпт реально попадает картинка. Как параметры mtp влияют на скорость и память в llama.cpp, разбираем в статье про spec-type draft-mtp, batch-size и KV-кэш.
Квантование KV-кэша до q8
Квантование KV до q8 снижает разрядность хранения ключей и значений, и кэш занимает меньше памяти. Это последний шаг в цепочке, потому что он единственный трогает точность самого контекста. Восемь бит на элемент по-прежнему много, но прирост окна покупается именно снижением точности.
Плюс llama-manager в том, что переключение идёт на ходу: перезапуск не нужен, накопленный контекст остаётся. Границы такого компромисса и методику проверки мы разбирали на примере форка beellama в материале про кванты KV и длинный контекст.
Практический пример: Qwen3.8-27B-UD-Q4_K_XL на 32 ГБ GPU
Разработчик приводит замер на одной видеокарте с 32 ГБ VRAM и модели Qwen3.8-27B-UD-Q4_K_XL. Стартовое окно в 167k токенов упирается в лимит памяти. Дальше в работу вступает ladder.
Что даёт каждый шаг ladder в этом примере
- Отключение mtp. Уходит драфт-часть, VRAM освобождается, окно растёт. Скорость генерации при этом падает.
- Перенос mmproj на CPU. Мультимодальный проектор покидает видеопамять. Для текстовой задачи вы этого не заметите.
- Квантование KV до q8. Крайняя мера, когда другие рычаги исчерпаны: контекст растёт, точность KV снижается.
Итог: 262k токенов против стартовых 167k, то есть примерно плюс 57 процентов окна. Все три шага идут без перезапуска сервера, KV-кэш не обнуляется.
Оговорка важная: это пример из описания инструмента, а не результат независимого тестирования на другом железе. На другой карте, другом драйвере или другом кванте модели цифры будут отличаться. Как отделять подтверждённые результаты от предположений при локальном запуске, показываем в разборе Qwen 3.8 27B на одной RTX 5090, NVFP4 и int8 KV.
Ограничения llama-manager: что важно знать до установки
Бета-статус означает, что API и поведение могут меняться, а часть багов ловится на живых пользователях. Для инструмента, который появился недавно, это нормально, но для продакшена риск реальный.
- Только одна GPU. Мульти-GPU конфигурации не поддерживаются, tensor-split недоступен.
- CPU не поддерживается. Запустить модель совсем без видеокарты не выйдет.
- Статус беты. Интерфейс и поведение могут меняться, отдельные сценарии не отлажены.
На практике это значит: инструмент имеет смысл, если у вас одна карта с большим объёмом VRAM и вы гоняете длинные сессии. Для сервера с двумя или четырьмя GPU, для CPU-фермы или для сценария, где недопустимы сюрпризы, он пока не подходит.
Сборка на Windows/MSVC: известная проблема и обходной путь
Если вы собираете форк llama.cpp под Windows, есть шанс упереться в ошибку линковки llama-server: LNK2001 unresolved external symbol "__". Проблема проявляется после изменения #28091 в связке с PCH и unity build. Сборка с этой ошибкой воспроизводится на MSVC 19.44.35228.0, CUDA 13.1, CMake 4.3.2, Ninja и RTX 3090.
Причина в конфликте двух возможностей CMake. Свойство WINDOWS_EXPORT_ALL_SYMBOLS ON заставляет CMake выгружать все символы из объектных файлов в сгенерированный exports.def. Когда рядом включаются precompiled headers, в этот файл попадают и служебные PCH-символы. Сгенерированный файл в таком случае содержит 5672 строки, и линковщик спотыкается на служебных именах.
Обходной путь: сборка с отключёнными precompiled headers.
cmake -B build -DCMAKE_DISABLE_PRECOMPILE_HEADERS=ONБинарник на выходе ведёт себя так же: при одной модели и одинаковых флагах decode дал 18.5 против 17.9 токенов в секунду. Платите вы временем сборки, которое как раз и экономили precompiled headers. Патч для самой ошибки на момент публикации предложен только в виде вариантов исправления и не протестирован, так что готового решения из коробки ждать не стоит.
Подчеркну отдельно: это известная несовместимость двух функций CMake, а не что-то специфичное именно для репозитория llama.cpp. Комбинация стала достижимой только после #28091.
Стоит ли пробовать llama-manager сейчас
Инструмент решает узкую задачу: не перезапускать сервер, когда нужно поменять конфигурацию под растущий контекст. Если вы запускаете локальную модель на одной GPU с 24 или 32 ГБ, работаете с длинными документами, кодом или агентными цепочками и устали смотреть, как после каждого перезапуска prefill заново пережёвывает 150 тысяч токенов, llama-manager стоит попробовать. Ставка здесь на выигрыш в контексте, а не на скорость генерации.
Если нужна стабильность, несколько GPU, работа на CPU или предсказуемый продакшен, спешить некуда. Бета-статус и отсутствие мульти-GPU поддержки не мелкие неудобства, а границы применимости. Разумный промежуточный вариант: поднять сборку на одной карте, прогнать свой типичный длинный сценарий и посмотреть, на каком шаге ladder вы упираетесь в потолок VRAM.