LLM-инференс (Large Language Model Inference)#

Данная ИИ-функция имитирует когнитивные способности человека, связанные с пониманием и генерацией естественного языка, распознаванием и синтезом речи, а также обработкой визуальной информации (для визуально-языковых моделей, VLM). Она позволяет разворачивать и обслуживать крупные языковые (LLM) и визуально-языковые модели (VLM) в производственных средах:

Сценарий позволяет пользователю:

  • проверять готовность стека локального инференса ИИ-моделей;

  • выполнять инференс LLM-моделей через SGLang с использованием OpenAI-совместимого API;

  • обслуживать ML-модели через Triton Inference Server по протоколам HTTP/gRPC;

  • выполнять специализированный LLM-сервинг через Triton Inference Server vLLM;

  • организовывать многоузловой инференс LLM-моделей с помощью LWS (LeaderWorkerSet).

Примечание

При использовании ИИ-функций DropApp соблюдайте правила работы пользователя с ИИ-функциями.

Предусловия#

Предварительными условиями выполнения сценария являются:

  • Развернутый кластер DropApp с установленным программным компонентом K8S Artificial Intelligence (K8SI).

  • Доступ к кластеру с правами, достаточными для просмотра состояния узлов, pod и сервисов, а также для создания pod и сервисов.

  • Наличие GPU-узлов и настроенного GPU-стека (драйверы NVIDIA, Container Toolkit, K8s-device-plugin), обеспечивающего доступ к ресурсу nvidia.com/gpu.

  • Установленный компонент AI-inference, включающий сервисы LWS, SGLang и Triton Inference Server; сервис Triton Inference Server vLLM может быть установлен как инструмент (Tool) или включен в список spec.tools компонента AI-inference.

  • Подготовленные LLM-модели. Для выполнения сценариев необходима доступность моделей в соответствующем стеке инференса:

    • Для SGLang — модель должна быть доступна по идентификатору на Hugging Face (автозагрузка при старте, например meta-llama/Llama-3.1-8B-Instruct) либо по локальному пути к весам, заданному параметром sglang.modelPath.

    • Для Triton Inference Server и Triton Inference Server vLLM — модель должна быть размещена в Triton Model Repository (смонтирован из PersistentVolumeClaim или NFS), содержащем конфигурационные файлы config.pbtxt и, для варианта vLLM, model.json. Веса либо размещаются в репозитории вручную, либо загружаются при старте по идентификатору на Hugging Face, указанному в model.json.

Установка и настройка LLM-инференс-сервисов описана в разделах «Компонент AI-inference», «SGLang», «Triton Inference Server» Руководства по установке DropApp с помощью Dactl.

Дополнительная информация об инструментах LLM-инференса приведена в разделах «SGLang», «Triton Inference Server», «LeaderWorkerSet» Руководства администратора.

Проверка готовности стека LLM-инференса#

Проверьте, что сервисы локального инференса развернуты в кластере и готовы к обработке запросов к моделям. Стек локального инференса разворачивается компонентом AI-inference и включает сервисы SGLang, Triton Inference Server и LWS.

Сценарий проверки готовности стека LLM-инференса:

  1. Убедитесь, что сервисные pod инференса запущены и находятся в состоянии Running:

    kubectl get pods -A | grep -E "sglang|triton|lws"

    Пример вывода:

    NAME                                       READY   STATUS    RESTARTS   AGE
lws-controller-manager-xxxxxxxxx-xxxxx     1/1     Running   0          10m
sglang-xxxxxxxxx-xxxxx                     1/1     Running   0          5m
tritonserver-xxxxxxxxx-xxxxx               1/1     Running   0          8m

  2. Убедитесь, что сервисы инференса доступны в кластере:

    kubectl get services -A | grep -E "sglang|triton"

  3. Проверьте, что на GPU-узлах доступен ресурс GPU nvidia.com/gpu, необходимый сервисам инференса:

    kubectl get nodes -o json | jq '.items[] | {name: .metadata.name, gpu: .status.capacity["nvidia.com/gpu"]}'

    Если в выводе команды для узлов присутствует значение ресурса nvidia.com/gpu, стек готов к развертыванию и использованию LLM-инференса.

Выполнение инференса через SGLang#

Выполняйте инференс LLM-моделей через SGLang с использованием OpenAI-совместимого API. SGLang поднимает инференс-эндпоинт, совместимый с интерфейсом OpenAI, и оптимизирует исполнение модели на GPU (эффективное планирование, KV-кеш, batching, спекулятивное декодирование и др.).

Сценарий выполнения инференса через SGLang:

  1. Определите имя сервиса SGLang и его порт в пространстве имен, в котором установлен компонент AI-inference:

    kubectl get services -A | grep sglang

    По умолчанию SGLang доступен по порту 80 сервиса (внутри контейнера сервер слушает порт 30000). Точное имя сервиса и пространство имен уточняются в конфигурации установки.

  2. Переадресуйте трафик к SGLang с локального порта 8080 на порт сервиса:

    kubectl port-forward svc/<sglang_service> 8080:80 -n <namespace> &

  3. Проверьте работоспособность инференс-сервера:

    curl -sL http://<localhost_ip>:8080/health

    Ответ OK означает, что сервер SGLang запущен и готов к обработке запросов.

  4. Отправьте запрос на генерацию текста с использованием OpenAI-совместимого API:

    curl -sL http://<localhost_ip>:8080/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{
          "model": "meta-llama/Llama-3.1-8B-Instruct",
          "messages": [
            {"role": "user", "content": "Объясните, что такое искусственный интеллект, кратко."}
          ],
          "max_tokens": 128
        }'

    Пример вывода:

    {
  "id": "chatcmpl-xxxxxxxxxxxxxxxx",
  "object": "chat.completion",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": "Искусственный интеллект (ИИ) — это область информатики, ..."
      },
      "finish_reason": "length"
    }
  ],
  "usage": {
    "prompt_tokens": 16,
    "completion_tokens": 128,
    "total_tokens": 144
  }
}

    Ответ содержит сгенерированный моделью контент в поле choices[0].message.content, что подтверждает корректность выполнения инференса через SGLang.

    Где:

    • <sglang_service> — имя сервиса SGLang в кластере;

    • <namespace> — пространство имен, в котором установлен компонент AI-inference;

    • <localhost_ip> — IP-адрес локального хоста (обычно 127.0.0.1), на который переадресован порт.

Обслуживание моделей через Triton Inference Server#

Обслуживайте ML-модели через Triton Inference Server — универсальный инференс-сервер, поддерживающий широкий спектр бэкендов (TensorRT, ONNX Runtime, PyTorch, Python backend и др.) и стандартизованные протоколы HTTP/gRPC. Протокол Triton позволяет выполнять модель, получать метаданные модели и управлять ее жизненным циклом.

Сценарий обслуживания моделей через Triton Inference Server:

  1. Определите имя сервиса Triton в пространстве имен, в котором установлен компонент AI-inference:

    kubectl get services -A | grep triton

  2. Переадресуйте трафик к Triton с локального порта 8000 на порт сервиса:

    kubectl port-forward svc/<triton_service> 8000:80 -n <namespace> &

  3. Проверьте доступность сервера и получите сведения о загруженных моделях:

    curl -sL http://<localhost_ip>:8000/v2/health/ready

    curl -sL http://<localhost_ip>:8000/v2/models

    Пример вывода запроса метаданных сервера:

    {
  "name": "triton",
  "version": "26.01",
  "extensions": ["classification", "sequence", "model_repository", <...>]
}

  4. Выполните запрос к загруженной модели с отправкой входных данных в формате JSON:

    curl -sL http://<localhost_ip>:8000/v2/models/<model_name>/infer \
    -H "Content-Type: application/json" \
    -d '{
          "inputs": [
            {"name": "input", "shape": [1, 1], "datatype": "INT32", "data": [[4]]}
          ]
        }'

    Пример вывода:

    {
  "model_name": "<model_name>",
  "outputs": [
    {"name": "output", "datatype": "FP32", "shape": [1, 1], "data": [[16.0]]}
  ]
}

    Ответ содержит результат вычисления модели в поле outputs[].data.

    Где:

    • <triton_service> — имя сервиса Triton в кластере;

    • <model_name> — имя модели, загруженной в репозиторий моделей Triton;

    • <namespace> — пространство имен, в котором установлен компонент AI-inference;

    • <localhost_ip> — IP-адрес локального хоста, на который переадресован порт.

Выполнение LLM-сервинга через Triton Inference Server vLLM#

Выполняйте специализированный LLM-сервинг через Triton Inference Server vLLM. В этом варианте Triton обеспечивает платформенную инфраструктуру (обработку запросов по HTTP/gRPC, управление репозиторием моделей), а генерацию токенов выполняет движок vLLM, обеспечивающий высокую пропускную способность и низкую задержку (например, за счет paged KV cache).

Сценарий выполнения LLM-сервинга через Triton Inference Server vLLM:

  1. Убедитесь, что сервис Triton Inference Server vLLM развернут в кластере:

    kubectl get pods -A | grep triton

    О том, что используется вариант с бэкендом vLLM, свидетельствует тег образа, содержащий vllm (например, 26.01-vllm-python-py3).

  2. Определите имя сервиса и переадресуйте трафик на локальный порт:

    kubectl port-forward svc/<triton_vllm_service> 8000:80 -n <namespace> &

  3. Убедитесь, что сервер готов и модель загружена:

    curl -sL http://<localhost_ip>:8000/v2/health/ready

    curl -sL http://<localhost_ip>:8000/v2/models

  4. Выполните LLM-запрос к модели, описанной в репозитории моделей Triton (конфигурационные файлы config.pbtxt и model.json):

    curl -sL http://<localhost_ip>:8000/v2/models/<llm_model>/generate \
    -H "Content-Type: application/json" \
    -d '{
          "text_input": "Сформулируйте краткое определение термина «инференс»."
        }'

    Пример вывода:

    {
  "model_name": "<llm_model>",
  "model_version": "1",
  "text_output": "Инференс — это этап применения обученной модели к новым данным для получения предсказаний."
}

    Ответ содержит сгенерированный моделью текст в поле text_output.

    Где:

    • <triton_vllm_service> — имя сервиса Triton Inference Server vLLM в кластере;

    • <llm_model> — имя LLM-модели в репозитории моделей Triton;

    • <namespace> — пространство имен, в котором установлен сервис;

    • <localhost_ip> — IP-адрес локального хоста, на который переадресован порт.

Организация многоузлового инференса с LWS#

Организуйте многоузловой (multi-node) инференс LLM-моделей с помощью LWS (LeaderWorkerSet). LeaderWorkerSet позволяет управлять группой pod «лидер + рабочий» как единой репликационной единицей, что необходимо, когда большая LLM-модель шардируется и запускается на нескольких GPU/узлах.

Примечание

Оркестрация распределенных AI/ML-нагрузок описана в сценарии «Оркестрация распределенных ИИ-нагрузок» настоящего документа.

Сценарий организации многоузлового инференса через LWS:

  1. Убедитесь, что пользовательский ресурс LeaderWorkerSet зарегистрирован в кластере:

    kubectl get crd leaderworkertsets.leaderworkerset.x-k8s.io

    Если в выводе команды присутствует пользовательский ресурс leaderworkertsets.leaderworkerset.x-k8s.io, контроллер LWS готов к управлению группами pod.

  2. Убедитесь, что ограничения на планирование групп pod корректны. Для многоузлового инференса настройте топологию размещения группы pod через конфигурацию LWS таким образом, чтобы pod группы размещались на разных GPU-узлах.

  3. Разверните рабочую нагрузку инференса, описанную с помощью LeaderWorkerSet. Пример манифеста группы pod:

    apiVersion: leaderworkerset.x-k8s.io/v1
kind: LeaderWorkerSet
metadata:
  name: llm-inference
spec:
  replicas: 1
  leaderWorkerTemplate:
    size: 2
    workerTemplate:
      spec:
        containers:
          - name: sglang
            image: <sglang-image>
            ports:
              - containerPort: 30000
                name: http
            resources:
              limits:
                nvidia.com/gpu: 1

    Где:

    • replicas — количество реплик группы pod;

    • size — размер группы pod (количество экземпляров контейнера в группе);

    • workerTemplate — шаблон рабочих pod группы;

    • nvidia.com/gpu — ресурс GPU, запрашиваемый каждым pod группы.

  4. Примените манифест:

    kubectl apply -f - <<EOF
apiVersion: leaderworkerset.x-k8s.io/v1
kind: LeaderWorkerSet
metadata:
  name: llm-inference
spec:
  replicas: 1
  leaderWorkerTemplate:
    size: 2
    workerTemplate:
      spec:
        containers:
          - name: sglang
            image: <sglang_image>
            ports:
              - containerPort: 30000
                name: http
            resources:
              limits:
                nvidia.com/gpu: 1
EOF

  5. Убедитесь, что все pod группы созданы и запущены:

    kubectl get pods -l leaderworkerset.sigs.k8s.io/name=llm-inference

    Пример вывода:

    NAME                  READY   STATUS    RESTARTS   AGE
llm-inference-0-0     1/1     Running   0          2m
llm-inference-0-1     1/1     Running   0          2m

    Pod группы запущены совместно, что подтверждает оркестрацию многоузлового инференса средствами LWS.

  6. После завершения проверки удалите группу pod:

    kubectl delete leaderworkerset llm-inference

Результат#

Ожидаемым результатом являются:

  • готовность стека локального инференса к обработке запросов;

  • успешное выполнение инференса LLM-моделей через SGLang и Triton Inference Server vLLM с получением сгенерированного контента;

  • обслуживание ML-моделей реализовано через Triton Inference Server, а многоузловой инференс организован средствами LWS.