Režim mašrutizatora Llama-Server — динамическая переключение моделей без перезапуска

Долгое время llama.cpp страдал от очевидного ограничения: вы могли обслуживать только одну модель на процесс, а переключение требовало перезапуска.

Эта эпоха закончилась.

Недавние обновления привели режим роутера в llama-server, предложив нечто гораздо ближе к тому, чего пользователи ожидают от современных локальных рантаймов LLM:

• динамическая загрузка моделей
• разгрузка по запросу
• переключение для каждого запроса
• без перезапуска процесса

Другими словами: поведение, похожее на Ollama, но без «тренажёрных колёсиков».

Если вы всё ещё решаете, что выбрать: локальные рантаймы, облачные API или self-hosted инфраструктуру, то обзор хостинга LLM станет хорошей отправной точкой.

Требования

Для режима роутера требуется свежая сборка llama-server — ориентировочно с середины 2024 года. В старых сборках отсутствуют флаги --models-preset или --models-dir.

С вариантами установки (управленник пакетов, предсобранные бинарники или полная сборка из исходников с поддержкой CUDA) см. быстрый старт llama.cpp.

После того как у вас есть llama-server, убедитесь, что ваша сборка поддерживает режим роутера:

llama-server --help | grep -i models

Если --models-preset или --models-dir отображаются, всё в порядке. Если их нет, обновитесь до более новой сборки.

Мой текущий вывод помощи для моделей:

-cl,   --cache-list                     show list of models in cache
                                        Prefix/Suffix/Middle) as some models prefer this. (default: disabled)
                                        models with dynamic resolution (default: read from model)
                                        models with dynamic resolution (default: read from model)
                                        embedding models (default: disabled)
--models-dir PATH                       directory containing models for the router server (default: disabled)
                                        (env: LLAMA_ARG_MODELS_DIR)
--models-preset PATH                    path to INI file containing model presets for the router server
                                        (env: LLAMA_ARG_MODELS_PRESET)
--models-max N                          for router server, maximum number of models to load simultaneously
                                        (env: LLAMA_ARG_MODELS_MAX)
--models-autoload, --no-models-autoload
                                        for router server, whether to automatically load models (default:
                                        (env: LLAMA_ARG_MODELS_AUTOLOAD)

Что на самом деле делает режим роутера

Режим роутера превращает llama-server в диспетчер моделей.

Вместо привязки к одной модели через -m, сервер:

• запускается без загруженной модели
• получает запрос с указанием модели
• загружает эту модель, если она ещё не находится в памяти
• выполняет инференс (инференсинг)
• при необходимости разгружает модель после ответа или держит её в «тёплом» состоянии для следующего запроса

Ключевая идея

Вы больше не запускаете:

./llama-server -m model.gguf

Вы запускаете:

./llama-server --models-preset models.ini --port 8080

И позволяете серверу решать, что загружать и когда, в зависимости от того, что фактически запрашивает клиент.

Это важно, поскольку означает, что один постоянно работающий процесс может обслуживать целый флот моделей, где клиенты выбирают нужную для каждой задачи — модель для кода, модель для чата, модель для саммаризации — без каких-либо накладных расходов на согласование с вашей стороны.

Конфигурация: определение ваших моделей

Здесь всё ещё немного грубовато.

Пока нет полностью стабильного официального формата, но текущие сборки поддерживают определения моделей в стиле INI через файл конфигурации.

Пример models.ini

[llama3]
model = /opt/models/llama-3-8b-instruct.Q5_K_M.gguf
ctx-size = 8192
ngl = 35
threads = 8

[mistral]
model = /opt/models/mistral-7b-instruct-v0.3.Q4_K_M.gguf
ctx-size = 4096
ngl = 20
threads = 8

[qwen]
model = /opt/models/qwen2.5-coder-7b-instruct.Q5_K_M.gguf
ctx-size = 16384
ngl = 35
threads = 8

Имя каждого раздела становится идентификатором модели, который клиенты используют в поле "model" своих API-запросов.

Ключевые параметры конфигурации

Выбор правильного значения ngl зависит от доступного VRAM вашего GPU — для выбора GPU и анализа затрат на оборудование, руководство по вычислительному оборудованию будет полезным справочником. Чтобы отслеживать потребление VRAM в реальном времени при настройке, см. инструменты мониторинга GPU для Linux.

Запуск сервера с конфигурацией

./llama-server --models-preset /opt/llama.cpp/models.ini --port 8080

Убедитесь, что сервер запустился корректно:

curl http://localhost:8080/v1/models | jq '.data[].id'

Вы должны увидеть каждое имя раздела из вашего models.ini в виде идентификатора модели.

Примечание о стабильности

Интерфейс конфигурации INI ещё развивается:

• флаги могут меняться между коммитами
• некоторые параметры распознаются только в определённых конфигурациях сборки
• документация отстаёт от реализации

Фиксируйте конкретный коммит llama.cpp, если вам нужна воспроизводимость при перезапусках.

Использование API: переключение моделей по запросу

Когда сервер работает, переключение моделей происходит через стандартный OpenAI-совместимый API. Вам просто нужно задать поле "model".

Список зарегистрированных моделей

curl http://localhost:8080/v1/models

Запрос на补полнение — первая модель

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3",
    "messages": [
      {"role": "user", "content": "Explain router mode in one paragraph"}
    ]
  }'

Переключение на другую модель — тот же эндпоинт, тот же порт

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen",
    "messages": [
      {"role": "user", "content": "Write a Python function that reads a CSV file"}
    ]
  }'

Сервер прозрачно обрабатывает цикл разгрузки/загрузки. Ваш клиентский код не меняется — меняется только поле model.

Пример на Python

Если вы используете Python-клиент openai:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8080/v1", api_key="not-needed")

# Use the coding model
response = client.chat.completions.create(
    model="qwen",
    messages=[{"role": "user", "content": "Write a Go HTTP handler"}],
)
print(response.choices[0].message.content)

# Switch to the chat model — same client, different model name
response = client.chat.completions.create(
    model="llama3",
    messages=[{"role": "user", "content": "What is the capital of Australia?"}],
)
print(response.choices[0].message.content)

Что происходит внутри

Когда приходит запрос для qwen, а llama3 сейчас загружена:

1. llama3 разгружается из VRAM
2. Веса qwen читаются с диска и загружаются в VRAM
3. Выполняется инференс
4. Следующий запрос определяет, нужно ли держать qwen загруженной или переключаться снова

Это напрямую отвечает на распространённый вопрос:

Как локальный LLM-сервер может переключать модели без перезапуска

За счёт динамической загрузки моделей по запросу, а не привязки при старте.

Systemd-сервис: готовое к производству решение

Создание выделенного пользователя и каталогов

sudo useradd --system --shell /usr/sbin/nologin --home-dir /opt/llama.cpp llm
sudo mkdir -p /opt/llama.cpp/models
sudo chown -R llm:llm /opt/llama.cpp

Копируем ваш бинарник и конфигурацию моделей на место:

sudo cp build/bin/llama-server /opt/llama.cpp/
sudo cp models.ini /opt/llama.cpp/

/etc/systemd/system/llama-server.service

[Unit]
Description=Llama.cpp Router Server
After=network.target

[Service]
Type=simple
User=llm
WorkingDirectory=/opt/llama.cpp
ExecStart=/opt/llama.cpp/llama-server --models-preset /opt/llama.cpp/models.ini --port 8080
Restart=always
RestartSec=5

Environment=LLAMA_LOG_LEVEL=info

[Install]
WantedBy=multi-user.target

Включение и запуск

sudo systemctl daemon-reload
sudo systemctl enable llama-server
sudo systemctl start llama-server

Проверка и просмотр логов

sudo systemctl status llama-server

journalctl -u llama-server -f

При успешном запуске вы увидите строки, указывающие на то, что сервер слушает, и реестр моделей загружен. Простая проверка:

curl -s http://localhost:8080/v1/models | jq '.data[].id'

Теперь у вас есть постоянный сервис с автоматическим перезапуском и централизованным переключением моделей — без ручного управления процессами. Если вы хотите применить тот же паттерн к другим бинарникам, размещение любого исполняемого файла как Linux-сервиса описывает общий подход.

Флаг --metrics в llama-server открывает Prometheus-совместимый эндпоинт. Для дашбордов, запросов PromQL и правил алертинга, специфичных для llama.cpp, см. руководство по мониторингу LLM-инференса. Для более широкой настройки наблюдаемости, руководство по наблюдаемости охватывает весь стек.

Ограничения, которые нужно понимать

Режим роутера действительно полезен, но он сопряжён с компромиссами, о которых нужно быть ясным перед тем, как полагаться на него в продакшене.

Только одна модель в памяти одновременно

Хотя в models.ini определено несколько моделей, в VRAM на каждый воркер в любой данный момент resides только одна. Переключение означает полный цикл разгрузки и перезагрузки.

• переключение означает перезагрузку
• скачок латентности неизбежен
• для типичной 7B модели в Q5 перезагрузка может занять от 3 до 10 секунд в зависимости от скорости диска и пропускной способности VRAM

Это отвечает на другой ключевой вопрос:

Поддерживает ли llama.cpp обслуживание нескольких моделей одновременно

Не совсем. Он поддерживает несколько определений, но не одновременное резидентство. Если вам действительно нужны две модели, загруженные параллельно, вам нужны два процесса на двух отдельных GPU.

Для замеров потребления VRAM и токенов в секунду для разных размеров моделей, бенчмарки производительности LLM охватывают всю картину. Для цифр, специфичных для llama.cpp на GPU с 16 ГБ — плотные и MoE-модели при разных размерах контекста — см. бенчмарки llama.cpp для 16 ГБ VRAM.

Нет умного кэширования

В отличие от Ollama, который поддерживает «тёплый» пул и вытесняет модели на основе недавности использования:

• нет автоматической стратегии вытеснения моделей
• нет фоновой предварительной загрузки
• нет очереди приоритетов для часто используемых моделей

Если вы отправляете чередующиеся запросы для llama3 и mistral, каждый отдельный запрос запускает перезагрузку. Это фундаментальная цена за близость к железу.

Латентность непредсказуема для смешанных нагрузок

Хорошо работающая нагрузка, которая последовательно использует одну модель, будет быстрой. Нагрузка, чередующая несколько моделей, будет медленной. Планируйте логику маршрутизации клиента соответственно — группируйте запросы по моделям wherever possible.

Конфигурация нестабильна

Поддержка INI существует и работает в большинстве последних сборок, но она не полностью стандартизирована. Флаги и имена параметров менялись между версиями. Если вы обновляете llama-server, протестируйте ваш models.ini на новой сборке перед развёртыванием.

Llama.cpp против Ollama

Режим роутера сокращает старый разрыв в жизненном цикле с Ollama — динамическая загрузка и переключение по запросу теперь существуют нативно в llama-server — но не закрывает его полностью. Управление памятью остаётся базовым (нет политики вытеснения, нет тёплого пула), стабильность конфигурации всё ещё экспериментальна, и переключение между двумя разными моделями всегда требует полной разгрузки и перезагрузки, в отличие от TTL-основанного keep-alive в Ollama. Кратко: режим роутера даёт вам максимальный контроль и «хакерскую» базу; Ollama даёт более отточенный, opinionated опыт с меньшим количеством конфигурации.

Для полного попарного сравнения — установка, управление моделями, расположение GPU, управление KV-кэшем, API, производительность, режимы отказов и конкретные триггеры для выбора одного или миграции между ними — см. llama.cpp против Ollama в 2026, которое является каноническим сравнением этих двух рантаймов на этом сайте.

Если вы выбираете Ollama, шпаргалка по CLI Ollama охватывает повседневные команды. Для более широкого сравнения, включающего также vLLM, LM Studio и LocalAI, см. как сравниваются разные локальные рантаймы в 2026.

Llama.cpp против llama-swap

llama-swap — это внешний оркестратор, который находится перед одной или несколькими инстанциями llama-server:

• он перехватывает запросы и проверяет поле model
• он запускает соответствующий процесс llama-server для этой модели
• он выключает бездействующие инстансы после настраиваемого тайм-аута
• он проксирует запрос, когда модель готова

Для практической настройки см. быстрый старт llama-swap.

Ключевое отличие

Когда использовать llama-swap

llama-swap даёт вам изоляцию процессов на уровне модели, что означает, что сбой в одной инстансе модели не влияет на другие. Это также позволяет каждой модели работать с полностью независимыми флагами llama-server.

Используйте его, если вам нужно:

• лучшее управление жизненным циклом и изоляция
• более умная логика переключения с настраиваемыми тайм-аутами простоя
• более предсказуемая латентность (каждая модель имеет «тёплый» процесс после первой загрузки)
• стабильность продакшена сегодня, а не когда-нибудь

Когда встроенного режима роутера достаточно

Используйте встроенный роутер, если вы хотите:

• нулевые внешние зависимости
• один процесс для управления
• более простое развёртывание (один бинарник, один файл конфигурации)
• минимальный стек для dev- или single-user сценариев

Итоги

Режим роутера — это значительный шаг вперёд для llama-server.

Он отвечает на давно существующий спрос:

Что такое режим роутера в сервере llama.cpp

Это недостающий слой, который превращает статичный бинарник в динамическую инференс-службу — один процесс, который может принимать запросы для целого каталога моделей.

Но он не завершен.

Сегодня он:

• достаточно мощный для реальных нагрузок
• перспективный как фундамент для более сложной маршрутизации
• слегка «шероховатый» на краях конфигурации и стабильности

Если ваша нагрузка предсказуема и вы можете группировать запросы по моделям, режим роутера хорошо работает уже сегодня. Если вам нужна надежность уровня продакшена и изоляция на уровне моделей, обращайтесь к llama-swap, пока нативная реализация созревает.

Когда вам нужно освободить VRAM без перезапуска — для прогона бенчмарка, окна обслуживания или чистой перезагрузки разработки — скриптуемый подход заключается в получении списка загруженных моделей и вызове эндпоинта разгрузки для каждой из них. Полный паттерн с curl и jq описан в Разгрузка всех моделей роутера llama.cpp без перезапуска.

В любом случае, вы получаете поведение, похожее на Ollama, не пряча механизмы.