2025-10-22 · Обновлено 2026-07-15

[!NOTE] Автоматический перевод Эта статья была автоматически переведена с оригинальной английской версии.

Руководство по LoRAX Сервинг: Управление множеством LoRA адаптеров в Kubernetes

Один базовый модель в сочетании с множеством адаптеров типа LoRA приводит к возникновению специфической проблемы с сервинг. Базовые компоненты веса используются общими, однако для каждого запроса может потребоваться свой набор адаптеров веса. Традиционный подход, при котором создается по одному объекту типа деплой на каждый вариант, приводит к избыточному расходу памяти GPU, поскольку большинство вариантов находятся в неактивном состоянии.

LoRAX Этот подход решает проблему длинного хвоста. Система загружает адаптеры по мере необходимости, группирует запросы к разным адаптерам и перемещает адаптер веса между памятью типа GPU и CPU. Привлекательный слоган звучит так: «Тысячи отрегулированных модели на одном GPU». Однако технический вопрос более узок: приносит ли правильное планирование смены активных адаптеров, характер распределения новых моделей и цели латентность достаточную пользу, чтобы оправдать использование ещё одного сервинг рантайм?

В этом руководстве дается ответ на этот вопрос, происходит локальная проверка API, после чего стартовая диаграмма Helm из репозитория преобразуется в конкретный план развертывания в продакшене.

Кратко. Используйте LoRAX, когда требуется большое количество совместимых LoRA Адаптеры используют общую базовую структуру. модель а трафик либо разреженный, либо имеет длинный хвост. Пропускная способность определяется активным набором данных, а не размером каталога. Фиксируйте рантаймаутентифицировать и добавить ID адаптеров в список разрешённых, внедрить механизм долговременной кэшировки артефактов с применением зондирования, настроить маршрутизацию для кэш локальность, и бенчмарк Обрабатывать холодные и теплые пути отдельно.

Проблема сервинг заключается в рабочем наборе

LoRA замораживает базовый модель и вычисляет обновления низкого ранга для отдельных вес матриц. Полученный адаптер как правило значительно меньше по размеру, чем полноценный чекпоинт, однако его объём всё равно определяется рангом, целевыми модулями, количеством слоёв и типом данных. Такие утверждения вроде «каждый адаптер занимает 100 МБ» являются неточными оценками его емкости.

Для сервинг необходимо различать три величины:

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

Каталог может включать тысячи адаптеров, при этом в VRAM не умещается столько же единиц. Критически важными являются частота изменения активного набора, размер этих адаптеров, а также возможность совместного использования полезных пакетов запросов к различным адаптерам.

LoRAX объединяет четыре механизма:

1. База модель остаётся в памяти для всех совместимых адаптеров.
2. Запрос содержит указание адаптера, который может быть получен из Hugging Face, Predibase или файловой системы.
3. Механизм планирования обмена адаптерами выполняет предзагрузку и перенос веса между памятью типа GPU и CPU.
4. Гетерогенные continuous batching группы объединяют запросы, направленные к разным адаптерам.

В отчёте проекта указано, что гетерогенное группирование данных позволяет сохранять значения throughput и латентность практически неизменными по мере увеличения количества одновременно работающих адаптеров в рамках его бенчмарки. Рассматривайте это как гипотезу для анализа вашей рабочей нагрузки. Длительность Промпт, длина выводимых данных, ранг, целевые модули, степень заполнения батча, уровень смены состава кэш и процесс генерации GPU могут повлиять на получаемые результаты.

Когда LoRAX является подходящим решением

LoRAX заслуживает бенчмарк, если выполняются все эти условия:

• Адаптеры обучались на тех же поддерживаемых базах данных. модель и токенизатор contract — контракт traffic — трафик спаны множество адаптеров с заметным длинным хвостом предпочтительнее загружать холодный адаптер по мере необходимости, вместо того чтобы резервировать его заранее деплой для IT
• тенант или задача роутинг уже существует на границе приложения — команда может использовать специализированный инструмент инференс рантайм и его кэш поведение

К типичным примерам относятся ассистенты, настроенные под конкретных арендаторов, множество вариантов для различных доменов, а также онлайн-эксперименты, которые используют общую базу чекпоинт.

Такой подход менее эффективен в ситуациях, когда небольшое число адаптеров контролирует весь трафик, модели не имеют общей основы, жесткие латентность цели не могут работать при низкой нагрузке, или платформа не может надежно определять, какие artefакты должен загружать сервер. В подобных случаях более простым решением может стать использование стандартного vLLM или TGI деплой с фиксированным набором адаптеров.

Не стоит использовать Kubernetes только из-за большого объёма каталога. Сначала необходимо подтвердить совместимость рантайм и адаптера на отдельном GPU.

Проверка одной базы и двух адаптеров локально

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

mkdir -p data

docker run --rm --gpus all --shm-size 1g \
    -p 8080:80 \
    -v "$PWD/data:/data" \
    ghcr.io/predibase/lorax:main \
    --model-id mistralai/Mistral-7B-Instruct-v0.1

Согласно документации, минимальными требованиями являются операционная система Linux, среда Docker, видеокарта от компании Ampere или новее с чипами NVIDIA GPU, а также драйверы, совместимые с версией CUDA 11.8. Лицензии типа Модель и репозитории с ограничениями доступа также могут требовать наличия Hugging Face токен.

Начнём с базовой версии модель:

curl http://127.0.0.1:8080/generate \
    -H 'Content-Type: application/json' \
    -d '{
      "inputs": "[INST] Give one reason to measure cold-adapter latency. [/INST]",
      "parameters": {"max_new_tokens": 64}
    }'

Затем отправьте совместимый адаптер:

curl http://127.0.0.1:8080/generate \
    -H 'Content-Type: application/json' \
    -d '{
      "inputs": "[INST] Solve: Natalia sold 48 clips in April and half as many in May. What is the total? [/INST]",
      "parameters": {
        "max_new_tokens": 64,
        "adapter_id": "vineetsharma/qlora-adapter-Mistral-7B-Instruct-v0.1-gsm8k"
      }
    }'

Первый запрос может загрузить адаптер, после чего последующие запросы смогут использовать кэшированные версии модулей и уже находящийся в памяти веса. Необходимо записывать оба пути. Один лишь запрос типа «warm request» почти ничего не говорит о поведении системы при обработке редких запросов.

Используйте текущий клиент OpenAI

LoRAX предоставляет конечную точку чата, совместимую с OpenAI. model field определяет адаптер:

from openai import OpenAI


client = OpenAI(
    api_key="EMPTY",
    base_url="http://127.0.0.1:8080/v1",
)

response = client.chat.completions.create(
    model="alignment-handbook/zephyr-7b-dpo-lora",
    messages=[
        {"role": "user", "content": "Explain cache locality in two sentences."},
    ],
    max_tokens=100,
)

print(response.choices[0].message.content)

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

Определение шлюза совместимости

Перед тем, как адаптер попадёт в каталог, необходимо проверить по меньшей мере:

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

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

Понимание правил размещения перед развертыванием

база модель потребляет доминирующую фиксированную долю GPU память. адаптер веса, KV cache, рабочее пространство пакетной обработки, и рантайм Ядра конкурируют за оставшиеся ресурсы. CPU RAM позволяет хранить откладываемые адаптеры, в то время как /data хранит загруженные артефакты.

Эти уровни не являются взаимозаменяемыми. Артефакт диска или хаба должен быть прочитан и материализован, прежде чем он сможет стать адаптером типа CPU- или GPU-. Измеряйте процессы перехода отдельно:

Параметр планирование должен воспроизводить реальное распределение популярности адаптеров. Использование одинаковых случайных идентификаторов адаптеров приводит к иной проблеме кэш по сравнению с рабочей нагрузкой тенантов, характерной для закона Зипфа.

Аккуратно развертывайте диаграмму репозитория

В этом репозитории хранятся charts/loraxСледовательно, воспроизводимой отправной точкой являются фиксированная ревизия репозитория и локальная диаграмма:

git clone https://github.com/predibase/lorax.git
cd lorax
git checkout <reviewed-commit-or-release>

helm dependency update charts/lorax
helm template lorax charts/lorax -f values.production.yaml
helm upgrade --install lorax charts/lorax \
    --namespace inference \
    --create-namespace \
    -f values.production.yaml

Как было отмечено при анализе 15 июля 2026 года, стандартные диаграммы должны соответствовать аттеншн:

• тег изображения — latest
• /data является emptyDir, в результате чего замена пода приводит к утилизации загруженных артефактов
• зонды жизнеспособности и готовности пусты
• Hugging Face токен моделируется как литеральное значение окружения
• по умолчанию запрашивается один GPU

Это превращает диаграмму в полезный инструмент для планирования, а не в правило, применяемое в производственной среде.

Начните с реальной структуры значений графика

График вкладывает конфигурацию рантайм внутрь deployment, а аргументы запуска представляют собой список пар «имя/значение». Минимальный вид оверлея выглядит следующим образом:

deployment:
    replicas: 1

    image:
        repository: ghcr.io/predibase/lorax
        tag: "<tested-tag>" # Prefer an immutable digest in rendered manifests.

    args:
        - name: "--model-id"
          value: "mistralai/Mistral-7B-Instruct-v0.1"
        - name: "--max-input-length"
          value: "2048"
        - name: "--max-total-tokens"
          value: "3072"
        - name: "--max-batch-total-tokens"
          value: "8192"
        - name: "--max-batch-prefill-tokens"
          value: "4096"

    resources:
        requests:
            nvidia.com/gpu: "1"
        limits:
            nvidia.com/gpu: "1"

    readinessProbe:
        httpGet:
            path: /health
            port: http
        periodSeconds: 5
        failureThreshold: 600

service:
    serviceType: ClusterIP
    port: 80

Указанные выше пределы токен являются примерными начальными значениями, а не рекомендациями по оптимизации размеров. Их необходимо рассчитать на основе характерных значений промпты, ожидаемой конкурентности, объёма памяти GPU и параметров load tests.

Прямо устраняйте имеющиеся пробелы

Текущий шаблон диаграммы содержит жёстко заданные значения. emptyDir объёмы и простые значения среды. Поэтому упрочнённая версия деплой требует пересмотренной диаграммы форк, патча после генерации или более высокого уровня манифеста для добавления следующего:

• PersistentVolumeClaim или локальный на узле артефакт кэш, монтируемый в /data
• секретный источник для учетных данных хаба;
• запусковой тест перед более интенсивным тестом жизнеспособности;
• политика прерывания работы подов и стратегия распределения по топологии для нескольких реплик;
• правила NetworkPolicy, ограничения учетных записей сервисов и авторизованный шлюз;
• фиксация хэша образа и проверка целостности артефактов.

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

Маршрут для региона кэш

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

Ключ роутинг должен поступать из состояния аутентифицированного приложения, а не из произвольного параметра публичного URL. В противном случае злоумышленник может принудительно запустить удалённые загрузки, вызвать отток кэши, или выяснить имена приватных адаптеров.

LoRAX или vLLM?

Текущий vLLM способен обслуживать LoRA-модули, объявленные при запуске, а также динамически загружать их с помощью конечных точек или плагинов-резолверов. В его собственной документации указано, что обновление адаптера рантайм сопряжено с рисками для безопасности, поэтому его не следует использовать в продакшене за пределами изолированной, надёжной среды.

Полезное сравнение носит операционный, а не числовой характер:

Избегайте подобных формулировок вроде «LoRAX для 1 000 адаптеров, vLLM — для десяти». Размер каталога сам по себе не определяет производительность. Бенчмарк, учитывая одинаковую базу, адаптеры, промпты, рейтинги, время доставки трейс и аппаратное обеспечение.

Тест приемки в продакшене

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

1. Фиксированный набор «горячих» устройств для формирования состояний warm throughput и латентность.
2. Распределение с длинным хвостом для измерения количества случаев CPU и появления артефактов кэш.
3. Всплеск использования ранее не виденных, но включённых в список разрешённых адаптеров.
4. Замена подов для оценки скорости восстановления базовых компонентов и адаптеров.
5. Один недоступный или повреждённый адаптер для проверки механизмов изоляции и перехода на резервные решения.
6. Конкурирующие пользователи для проверки процедур аутентификации, соблюдения квот и корректности меток метрик.

Отслеживайте скорость поступления запросов, время ожидания в очереди, время до первого токен, интервалы между токен латентность, общее количество латентность, время загрузки адаптера, класс запросов типа кэш, объём памяти GPU и CPU, количество загруженных байтов, а также количество сбоев в зависимости от причины. Не включайте идентификаторы адаптеров в метки метрик без ограничений; вместо этого отображайте их через контролируемые измерения или выборочные трейсы.

Необходимо заранее определить пороги приемлемости для тестирования. К примерам относятся максимальная доля ошибок в режиме холодного запуска, целевое значение P99 в режиме активной работы, целевой показатель кэш-hit для наблюдаемой распределенности популярности, а также целевой срок восстановления после потери пода.

Заключение

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

Сначала протестируйте эти механизмы на одном GPU. Затем начните серьёзно подходить к Kubernetes: фиксируйте версии artefaktов, сохраняйте кэш, защищайте учётные данные, авторизуйте адаптеры, определяйте маршруты с учётом локальности и отслеживайте каждый путь размещения данных. Если LoRAX показывает лучшие результаты по сравнению с текущей конфигурацией vLLM при одинаковых условиях тестирования, то решение деплой будет обоснованным.

Список литературы

• репозиторий LoRAX и файл README — поддерживаемые функции, требования, APIs, и харта Helm
• Значения графика LoRAX и Деплой шаблон — текущие значения по умолчанию и поведение объёма данных адаптеры LoRA vLLM — статический и динамический адаптер сервинг
• LoRA статья — метод адаптации с низким рангом документация для Hugging Face и PEFT — форматы адаптеров и интеграция с процессом обучения