Router в llama.cpp: как управлять резидентными моделями и их выгрузкой

Model router llama.cpp нужно проверять по фактической резидентности моделей и состоянию дочерних процессов. Наличие модели в списке presets не означает, что ее веса уже загружены. Ограничение количества моделей и резерв памяти решают разные задачи. Составьте карту переходов load, idle и unload для конкретного набора, чтобы отличать cold start от ошибки API имени и понимать, что происходит при конкуренции нескольких checkpoints за ресурсы.

Preset и работающий процесс

Документация server описывает router presets и управление загружаемыми моделями. Preset задает конфигурацию, а реальный экземпляр имеет жизненный цикл. Если клиент использует правильный model ID, запрос все равно может ждать загрузку. Поэтому отдельно проверяйте объявленное имя, наличие процесса и готовность inference. Не меняйте alias, пытаясь исправить нехватку места для нескольких моделей: публичная идентификация не определяет, какие веса фактически остаются на устройствах между обращениями и каким процессом они обслуживаются.

Два ограничения резидентности

Количество одновременно загруженных моделей ограничивает состав, а memory margin учитывает необходимый свободный резерв по устройствам. Одинаковое число моделей может занимать разную память из-за весов, context и служебных buffers. Зафиксируйте настройки, поддерживаемые вашей сборкой, и не считайте их обещанием любого сочетания checkpoints. Реализация model management помогает проследить состояния и reload/unload. Приемка должна учитывать, можно ли выгрузить конкретную idle модель и не занят ли экземпляр активным запросом в момент решения.

Пример трех presets

Задайте три учебных presets при допустимой резидентности двух моделей. Сначала обратитесь к двум, затем к третьей и снова к первой. Это сценарий проверки политики, а не обещание, что все три модели подходят конкретной GPU. Сохраните для каждого шага выбранный процесс, load события, готовность и задержку ответа. Если возвращение к первой модели требует загрузки, отметьте cold path отдельно. Сравнивать его напрямую с уже загруженной моделью как разницу вычислительной скорости было бы ошибкой.

Проверьте изменения конфигурации

Обновление preset может требовать reload, что отличается от простого изменения видимого списка. Сохраните исходный и новый вариант, события завершения дочернего процесса и запуск замены. Если состояние показывает загрузку или выгрузку, не считайте это эквивалентом готового serving экземпляра. Для диагностики сопоставляйте request identity и model state во времени. При одновременных обращениях повторите сценарий с известным расписанием: ручные последовательные запросы не покрывают конкуренцию, которая влияет на допустимость выгрузки и реальное ожидание клиентов.

Приемка политики router

Артефакт содержит presets, сборку, карту памяти, предел количества моделей и последовательность обращений. Отдельно укажите горячий и холодный путь для каждого model ID. Не обещайте нулевой cold start или автоматическую выгрузку занятой модели, если это не соответствует поддерживаемому поведению выбранной версии. При добавлении нового checkpoint повторите сценарий с его реальными требованиями. Полезный итог объясняет, какие модели доступны конфигурационно, какие резидентны и какие готовы отвечать сейчас. Это предотвращает неверное отождествление списка API с текущим содержимым GPU памяти и позволяет обсуждать задержки с учетом загрузки и политики residency, а не только скорости token generation уже работающей модели.

Связанные материалы

vLLM served-model-name: почему API не находит загруженную модель; Планирование GPU-пула: когда действительно нужен следующий сервер.