Режим маршрутизации Llama-Server — динамическое переключение моделей без перезапуска

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

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

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

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

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

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

Предварительные требования

Режим маршрутизатора требует свежей сборки llama-server — примерно после середины 2024 года. В старых сборках нет флага --models.

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

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

llama-server --help | grep -i models

Если флаг --models появился, всё в порядке. Если его нет, обновитесь до более новой сборки.

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

-cl,   --cache-list                     показать список моделей в кэше
                                        Префикс/Суффикс/Середина) так как некоторые модели предпочитают это. (по умолчанию: отключено)
                                        модели с динамическим разрешением (по умолчанию: читать из модели)
                                        модели с динамическим разрешением (по умолчанию: читать из модели)
                                        модели для эмбеддингов (по умолчанию: отключено)
--models-dir PATH                       директория, содержащая модели для сервера-маршрутизатора (по умолчанию: отключено)
                                        (env: LLAMA_ARG_MODELS_DIR)
--models-preset PATH                    путь к INI-файлу с предустановками моделей для сервера-маршрутизатора
                                        (env: LLAMA_ARG_MODELS_PRESET)
--models-max N                          для сервера-маршрутизатора, максимальное количество моделей для одновременной загрузки
                                        (env: LLAMA_ARG_MODELS_MAX)
--models-autoload, --no-models-autoload
                                        для сервера-маршрутизатора, автозагрузка моделей (по умолчанию:
                                        (env: LLAMA_ARG_MODELS_AUTOLOAD)

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

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

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

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

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

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

./llama-server -m model.gguf

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

./llama-server --models 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 и анализа аппаратной экономики руководство по вычислительному оборудованию будет полезным справочником. Чтобы отслеживать потребление VRAM в реальном времени при настройке, см. инструменты мониторинга GPU для Linux.

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

./llama-server --models /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": "Объясни режим маршрутизатора в одном абзаце"}
    ]
  }'

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

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen",
    "messages": [
      {"role": "user", "content": "Напишите функцию на Python для чтения CSV-файла"}
    ]
  }'

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

Пример на Python

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

from openai import OpenAI

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

# Используем модель для кода
response = client.chat.completions.create(
    model="qwen",
    messages=[{"role": "user", "content": "Напишите HTTP-обработчик на Go"}],
)
print(response.choices[0].message.content)

# Переключаемся на чат-модель — тот же клиент, другое имя модели
response = client.chat.completions.create(
    model="llama3",
    messages=[{"role": "user", "content": "Какая столица Австралии?"}],
)
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 /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. Для дашбордов, специфичных для llama.cpp, запросов PromQL и правил оповещения см. руководство по мониторингу инференса LLM. Для более широкой настройки наблюдаемости руководство по наблюдаемости охватывает полный стек.

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

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

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

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

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

Это отвечает на ещё один ключевой вопрос:

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

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

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

Отсутствует умная кэшизация

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

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

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

Задержка непредсказуема для смешанных нагрузок

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

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

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

Llama.cpp против Ollama: честное сравнение

Личное мнение

Выбирайте режим маршрутизатора llama.cpp, если вам нужно:

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

Выбирайте Ollama, если вам нужно:

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

Оба варианта правильны. Выбор зависит от того, сколько вы хотите контролировать самостоятельно.

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

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

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

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

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

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

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

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

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

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

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

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

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

Финальные мысли

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

Он отвечает на давний запрос:

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

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

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

Сегодня это:

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

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

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