For clean Markdown content of this page, append .md to this URL. For the complete documentation index, see https://docs.nvidia.com/dynamo/llms.txt. For full content including API reference and SDK examples, see https://docs.nvidia.com/dynamo/llms-full.txt.

Руководство по Frontend

Это руководство описывает настройку KServe gRPC frontend и его интеграцию с Dynamo Frontend.

KServe gRPC Frontend

Мотивация

KServe v2 API - один из отраслевых стандартных протоколов для инференса моделей машинного обучения. Triton inference server - одно из решений для инференса, совместимых с KServe v2 API, и оно получило широкое распространение. Чтобы пользователи Triton могли быстро познакомиться с преимуществами Dynamo, Dynamo предоставляет KServe gRPC frontend.

Эта документация предполагает, что читатели знакомы с использованием KServe v2 API, и сосредоточена на объяснении компонентов Dynamo, которые совместно обеспечивают поддержку KServe API, а также на том, как пользователи могут перенести существующее развертывание KServe в Dynamo.

Поддерживаемые конечные точки

• Конечная точка ModelInfer: стандартная конечная точка KServe, как описано здесь
• Конечная точка ModelStreamInfer: конечная точка расширения Triton, которая предоставляет двунаправленную потоковую версию inference RPC и позволяет отправлять последовательность запросов/ответов инференса через GRPC stream, как описано здесь
• Конечная точка ModelMetadata: стандартная конечная точка KServe, как описано здесь
• Конечная точка ModelConfig: конечная точка расширения Triton, как описано здесь

Запуск Frontend

Чтобы запустить KServe frontend, выполните следующую команду:

python -m dynamo.frontend --kserve-grpc-server

Настройка производительности gRPC

gRPC-сервер поддерживает дополнительную настройку HTTP/2 flow control через переменные окружения. Их можно задать перед запуском сервера, чтобы оптимизировать высокопроизводительные потоковые нагрузки.

Переменная окружения	Описание	Значение по умолчанию
DYN_GRPC_INITIAL_CONNECTION_WINDOW_SIZE	Размер окна HTTP/2 flow control на уровне соединения в байтах	значение по умолчанию tonic (64KB)
DYN_GRPC_INITIAL_STREAM_WINDOW_SIZE	Размер окна HTTP/2 flow control для каждого потока в байтах	значение по умолчанию tonic (64KB)

Пример: конфигурация с высоким ISL/OSL для потоковых нагрузок

# For 128 concurrent 15k-token requests
export DYN_GRPC_INITIAL_CONNECTION_WINDOW_SIZE=16777216  # 16MB
export DYN_GRPC_INITIAL_STREAM_WINDOW_SIZE=1048576      # 1MB
python -m dynamo.frontend --kserve-grpc-server

Если эти переменные не заданы, сервер использует значения tonic по умолчанию.

Настраивайте эти значения в соответствии со своей нагрузкой. Connection window должен вмещать concurrent_requests x request_size. Накладные расходы памяти равны размеру connection window (общему для всех потоков). Подробнее см. в лучших практиках производительности gRPC и аргументах канала gRPC.

Регистрация backend

Как и в случае с HTTP frontend, зарегистрированный backend будет автоматически обнаружен и добавлен в список моделей, обслуживаемых frontend. Для регистрации backend используется тот же API register_model(). Сейчас frontend поддерживает обслуживание следующих сочетаний типа модели и входа модели:

• ModelType::Completions и ModelInput::Text: сочетание для LLM backend, который использует пользовательский препроцессор
• ModelType::Completions и ModelInput::Token: сочетание для LLM backend, который использует препроцессор Dynamo (то есть Dynamo SGLang / TRTLLM / vLLM backend)
• ModelType::TensorBased и ModelInput::Tensor: сочетание для backend, который используется для обобщенного tensor-based inference

Первые два сочетания опираются на OpenAI Completions API, подробнее см. в разделе OpenAI Completions. Последнее сочетание наиболее близко к KServe API, и пользователи могут заменить существующее развертывание на Dynamo после того, как их backend реализует адаптер для NvCreateTensorRequest/NvCreateTensorResponse; подробнее см. в разделе Tensor:

OpenAI Completions

Большинство возможностей Dynamo адаптированы для LLM inference, а сочетания, основанные на OpenAI API, позволяют включить эти возможности и лучше всего подходят для знакомства с ними. Однако это подразумевает специальное преобразование между обобщенными tensor-based messages и сообщением OpenAI, а также накладывает определенную структуру на KServe request message.

Метаданные / конфигурация модели

Endpoint'ы metadata и config сообщат, что зарегистрированный backend имеет приведенные ниже параметры; обратите внимание, что это не точный ответ.

{
    "name": "$MODEL_NAME",
    "version": 1,
    "platform": "dynamo",
    "backend": "dynamo",
    "inputs": [
        {
            "name": "text_input",
            "datatype": "BYTES",
            "shape": [1]
        },
        {
            "name": "streaming",
            "datatype": "BOOL",
            "shape": [1],
            "optional": true
        }
    ],
    "outputs": [
        {
            "name": "text_output",
            "datatype": "BYTES",
            "shape": [-1]
        },
        {
            "name": "finish_reason",
            "datatype": "BYTES",
            "shape": [-1],
            "optional": true
        }
    ]
}

Инференс

При получении inference request будет выполнено следующее преобразование:

• text_input: ожидается, что элемент содержит строку пользовательского prompt и будет преобразован в поле prompt в OpenAI Completion request
• streaming: элемент будет преобразован в поле stream в OpenAI Completion request

При получении model response будет выполнено следующее преобразование:

• text_output: каждый элемент соответствует одному choice в OpenAI Completion response, а содержимое будет записано в text этого choice.
• finish_reason: каждый элемент соответствует одному choice в OpenAI Completion response, а содержимое будет записано в finish_reason этого choice.

Tensor

Это сочетание используется, когда пользователь переносит существующий backend на основе KServe в экосистему Dynamo.

Метаданные / конфигурация модели

При регистрации backend должен предоставить метаданные модели, поскольку tensor-based deployment является обобщенным, и frontend не может делать предположения, как в случае с моделью OpenAI Completions. Есть два способа передать метаданные модели:

• TensorModelConfig: это определенная в Dynamo структура для метаданных модели; backend может предоставить метаданные модели, как показано в этом примере. Для метаданных, предоставленных таким способом, следующие поля будут установлены в фиксированные значения: version: 1, platform: "dynamo", backend: "dynamo". Обратите внимание, что для endpoint model config остальные поля будут установлены в значения по умолчанию.
• triton_model_config: пользователи, у которых уже есть Triton model config и которым нужно возвращать полный config для логики на стороне клиента, могут задать config в TensorModelConfig::triton_model_config; он имеет приоритет над другими полями в TensorModelConfig и используется для ответов endpoint. Ожидается, что triton_model_config будет сериализованной строкой protobuf-сообщения ModelConfig; пример см. в echo_tensor_worker.py.

Инференс

При получении inference request backend получит NvCreateTensorRequest, и от него ожидается возврат NvCreateTensorResponse. Они являются отображением protobuf-сообщений ModelInferRequest / ModelInferResponse в Dynamo.

Привязки Python

Frontend можно запустить через Python binding; это полезно при интеграции Dynamo в существующую систему, где frontend должен выполняться в одном процессе с другими компонентами. Пример см. в server.py.

Интеграция

С Router

Frontend включает встроенный router для распределения запросов. Настройте режим маршрутизации:

python -m dynamo.frontend --router-mode kv --http-port 8000

Подробности настройки маршрутизации см. в документации Router.

С backend'ами

Backend'ы автоматически регистрируются во frontend, когда вызывают register_model(). Поддерживаемые backends:

• vLLM Backend
• SGLang Backend
• TensorRT-LLM Backend

См. также

Документ	Описание
Обзор Frontend	Быстрый старт и матрица возможностей
NVIDIA Request Extensions (nvext)	Расширения для маршрутизации, preprocessing, метаданных ответа и приоритета engine
Документация Router	Конфигурация маршрутизации с учетом KV