llama.cpp: несколько моделей в одном сервере через router

Когда нужен router, а когда обычный сервер

Обычный llama-server -m /путь/к/model.gguf обслуживает выбранный GGUF. Router запускается без -m: основной процесс предоставляет список доступных моделей, поднимает нужный экземпляр и пересылает запрос в него. Для POST к /v1/chat/completions выбор делается по JSON-полю model; для некоторых GET-эндпоинтов — через параметр ?model=.... Ключ в том, чтобы брать точный ID из /models, а не угадывать имя файла в API. s1 s4

Эта схема полезна, когда одной локальной точке API нужно попеременно обслуживать, например, два проверенных текстовых GGUF для разных задач. Она не превращает один компьютер в кластер и не делает несовместимую модель работоспособной. Если достаточно одного файла и нет задачи переключения, начните с обычного гайда llama.cpp. Если нужен второй физический компьютер, router не заменяет RPC. s1 s4

Что подготовить для двух моделей

Нужны git, CMake и компилятор для исходной сборки, curl и jq для диагностических примеров, место под два совместимых текстовых GGUF-файла и ресурсы для запуска хотя бы одного из них. Совместимость, происхождение, лицензию и условия каждого файла проверяйте по первоисточнику модели. Здесь нет универсального минимума RAM/VRAM: вес GGUF не равен всему потреблению памяти, которое зависит также от выбранного контекста и KV-кэша. Modelium не проверял конкретное железо. s3 s4

В примере два ваших файла лежат в $HOME/models, по одному GGUF в корне каталога. Если модель состоит из нескольких частей либо требует мультимодальный projector, документация размещает относящиеся к ней файлы в отдельном подкаталоге. Не используйте здесь случайно скачанные веса из чужого репозитория; политика безопасности рекомендует проверять происхождение и изолировать недоверенные модели. s1 s5

Как запустить router локально

Соберите стабильную ревизию, на которую опирается материал. Команды CMake следуют официальному CPU-пути; если нужен GPU, его backend, toolkit и драйвер требуют отдельной проверки. Никакого GPU-ускорения эти строки сами по себе не обещают. s3

git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
git checkout 7fe450e19305b828c199d602c23a8337aaa1f03b
cmake -B build
cmake --build build --config Release

Создайте каталог и самостоятельно положите туда два доверенных текстовых GGUF; это не команда на загрузку весов. Сначала убедитесь, что каждая модель по отдельности даёт ответ через обычный llama-server -m, и только затем сравнивайте переключение. В данном руководстве имена моделей и их объём намеренно не выдуманы. s1 s4

mkdir -p "$HOME/models"
./build/bin/llama-server --models-dir "$HOME/models" --models-max 1 --host 127.0.0.1 --port 8080

Команду сервера держите в отдельном терминале. --models-max 1 ограничивает число одновременно работающих экземпляров для наглядной проверки вытеснения; штатное значение в этой ревизии — 4, 0 снимает ограничение. Автозагрузка по обращению включена по умолчанию. Она не означает, что две тяжёлые модели одновременно поместятся в ваше устройство: для этого опыта достаточно доступной памяти для каждой модели по отдельности, а загрузка следующей может потребовать времени. s1 s2

Не заменяйте 127.0.0.1 на публичный адрес ради удалённого клиента. Документация указывает loopback по умолчанию, а политика безопасности исключает router из поддерживаемых сценариев для недоверенных сетей. Даже наличие --api-key само по себе не делает такой контур безопасным. s1 s5

Как увидеть ID и выбрать модель в запросе

В другом терминале запросите список. Должно быть как минимум две записи; их id и status.value смотрите в выводе, а не в названии файла на диске. Если список пуст, проверьте содержимое каталога, формат GGUF и логи router; при добавлении файлов документация рекомендует перезапустить сервер или обновить список через /models?reload=1. s1 s4

curl -fsS http://127.0.0.1:8080/models | jq -r '.data[] | [.id, .status.value] | @tsv'

Для следующей проверки вручную скопируйте два разных ID из этого списка в переменные MODEL_A и MODEL_B. Ниже это маркеры для ваших реальных ID, а не заявка на существование моделей с такими именами. jq -n создаёт JSON корректно даже если ID содержит кавычки или пробелы. Промпт для учебного теста без чувствительных данных; содержимое ответа зависит от выбранных моделей. s1 s5

MODEL_A='вставьте-первый-id-из-models'
MODEL_B='вставьте-второй-id-из-models'
jq -n --arg m "$MODEL_A" '{model:$m,messages:[{role:"user",content:"Ответь одним словом: тест"}],stream:false}' \
| curl -fsS http://127.0.0.1:8080/v1/chat/completions -H 'Content-Type: application/json' -d @- \
| jq '{model,choices,error}'
curl -fsS http://127.0.0.1:8080/models | jq -r '.data[] | [.id, .status.value] | @tsv'

Повторите команду, заменив "$MODEL_A" на "$MODEL_B", затем ещё раз запросите /models. Проверяемый признак при лимите в один слот: после завершённого ответа второй модели её статус становится loaded, а первая переходит в unloaded (с учётом времени асинхронной смены). Читайте также лог llama-server: код планировщика вытесняет не занятую другим запросом модель с самым давним временем последнего использования. Если запрос A ещё идёт, scheduler ждёт освобождения слота, а не убивает активную генерацию ради B. Это ожидаемое поведение по исходникам, не результат прогона Modelium. s1 s2

После B вновь запросите A и сравните статусы/логи. Тогда увидите именно переключение A → B → A, а не просто два ID в списке. Загрузка после вытеснения может давать задержку первого ответа; скорость и расход памяти оцените на собственном железе, не по размерам файлов. При необходимости явного управления документация описывает POST /models/load и POST /models/unload; автозагрузку можно отключить флагом --no-models-autoload, но тогда клиент сам отвечает за загрузку. s1 s2

Если сервер не переключается

• Одна модель в списке. Проверьте, что в --models-dir находятся именно доступные GGUF, второй файл не скрыт неверной структурой каталога, и вызовите /models?reload=1 или перезапустите router. Для multipart или multimodal GGUF нужен каталог на модель. s1
• Ошибка загрузки второй. Посмотрите status.failed и exit_code в /models, затем логи процесса. Файл, успешно видимый в списке, ещё не доказывает корректную загрузку или достаточность памяти. Вернитесь к отдельному запуску каждой модели и выбору GGUF. s1 s4
• Обе модели значатся loaded. Убедитесь, что действительно запущен этот процесс с --models-max 1, а не оставленный сервер с лимитом по умолчанию 4; сверяйте адрес и порт. Статус loaded описывает экземпляры, а не байты, возвращённые ОС. s1 s2
• Второй запрос ждёт. При занятом единственном экземпляре scheduler не выбирает его для вытеснения. Дождитесь конца первого запроса, затем повторите проверку; не повышайте лимит вслепую без замера доступной памяти. s2
• Есть ответ, но нет уверенности в выборе. Проверьте model в отправленном JSON, поле model в ответе и статусы /models; осмысленность текста не доказывает, что использован нужный файл. s1

Для завершения опыта остановите сервер в его терминале и не передавайте туда рабочие документы до отдельного анализа угроз. Основной следующий шаг — убедиться, что выбранная модель устойчиво работает в обычном локальном llama.cpp, а потом повторить тест A → B → A с собственными файлами и сохранёнными логами. s1 s5