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.

Metrics

Обзор

Dynamo предоставляет встроенные возможности метрик через Dynamo metrics API, который автоматически доступен при использовании framework DistributedRuntime. Этот документ служит справочником по всем доступным метрикам в Dynamo.

Инструкции по настройке визуализации см. в руководстве по настройке Prometheus и Grafana.

Для создания пользовательских метрик см. руководство разработчика по метрикам.

Переменные среды

Переменная	Описание	По умолчанию	Пример
DYN_SYSTEM_PORT	Порт метрик/health backend component	-1 (disabled)	8081
DYN_HTTP_PORT	HTTP-порт frontend (также настраивается через флаг --http-port)	8000	8000
NIXL_TELEMETRY_ENABLE	Включить NIXL telemetry (см. NIXL Telemetry Metrics). Значения: y, n	n (disabled)	y

Быстрый старт

Это пример для одной машины.

Запуск стека наблюдаемости

Чтобы визуализировать метрики с помощью Prometheus и Grafana, запустите стек наблюдаемости. Инструкции см. в разделе Начало работы с наблюдаемостью.

Запуск компонентов Dynamo

Запустите frontend и backend vLLM, чтобы проверить метрики:

# Запуск frontend (порт по умолчанию 8000, можно переопределить через `--http-port` или переменную среды `DYN_HTTP_PORT`)
$ python -m dynamo.frontend

# Включить системные метрики backend worker на порту 8081
$ DYN_SYSTEM_PORT=8081 python -m dynamo.vllm --model Qwen/Qwen3-0.6B  \
   --enforce-eager --no-enable-prefix-caching --max-num-seqs 3

Дождитесь запуска worker vLLM, затем отправьте запросы и проверьте метрики:

# Отправка запроса
curl -H 'Content-Type: application/json' \
-d '{
  "model": "Qwen/Qwen3-0.6B",
  "max_completion_tokens": 100,
  "messages": [{"role": "user", "content": "Hello"}]
}' \
http://localhost:8000/v1/chat/completions

# Проверка метрик backend worker
curl -s localhost:8081/metrics | grep dynamo_component

Публикуемые метрики

Dynamo публикует метрики в текстовом формате Prometheus Exposition Format на HTTP endpoint /metrics. Все метрики, генерируемые Dynamo, используют префикс dynamo_* и включают метки (dynamo_namespace, dynamo_component, dynamo_endpoint) для идентификации source component.

Пример текста в формате Prometheus Exposition Format:

# HELP dynamo_component_requests_total Total requests processed
# TYPE dynamo_component_requests_total counter
dynamo_component_requests_total{dynamo_namespace="default",dynamo_component="backend",dynamo_endpoint="generate"} 42

# HELP dynamo_component_request_duration_seconds Request processing time
# TYPE dynamo_component_request_duration_seconds histogram
dynamo_component_request_duration_seconds_bucket{dynamo_namespace="default",dynamo_component="backend",dynamo_endpoint="generate",le="0.005"} 10
dynamo_component_request_duration_seconds_bucket{dynamo_namespace="default",dynamo_component="backend",dynamo_endpoint="generate",le="0.01"} 15
dynamo_component_request_duration_seconds_bucket{dynamo_namespace="default",dynamo_component="backend",dynamo_endpoint="generate",le="+Inf"} 42
dynamo_component_request_duration_seconds_sum{dynamo_namespace="default",dynamo_component="backend",dynamo_endpoint="generate"} 2.5
dynamo_component_request_duration_seconds_count{dynamo_namespace="default",dynamo_component="backend",dynamo_endpoint="generate"} 42

Категории метрик

Dynamo публикует несколько категорий метрик:

• Метрики frontend (dynamo_frontend_*) - обработка запросов, обработка токенов и измерение задержек
• Метрики component (dynamo_component_*) - количество запросов, время обработки, передача байтов и uptime системы
• Специализированные метрики component (например, dynamo_preprocessor_*) - метрики конкретных component
• Метрики engine (Pass-through) - backend engine публикуют собственные метрики: vLLM (vllm:*), SGLang (sglang:*), TensorRT-LLM (trtllm_*)

Иерархия runtime

Dynamo metrics API доступен на DistributedRuntime, Namespace, Component и Endpoint, обеспечивая иерархический подход к сбору метрик, который соответствует распределённой архитектуре Dynamo:

• DistributedRuntime: глобальные метрики по всему runtime
• Namespace: метрики, ограниченные конкретным dynamo_namespace
• Component: метрики для конкретного dynamo_component внутри namespace
• Endpoint: метрики для отдельного dynamo_endpoint внутри component

Эта иерархическая структура позволяет создавать метрики на нужном уровне детализации для задач мониторинга.

Доступные метрики

Примечание: метрики с метками (HistogramVec, CounterVec, GaugeVec) регистрируют metric family, а не отдельные time series. Серия для конкретной комбинации меток появляется в /metrics только после первого вызова with_label_values(...) для этой комбинации, то есть после обработки первого подходящего запроса. Например, dynamo_frontend_request_duration_seconds{model="Qwen/Qwen3-0.6B"} не появится на только что запущенном frontend, пока не будет обработан запрос для этой модели. Это ожидаемое поведение Prometheus client, а не отсутствие метрики.

Метрики backend component

Worker backend (python -m dynamo.vllm, python -m dynamo.sglang, и т. д.) публикуют метрики dynamo_component_* на порту system status (настраивается через DYN_SYSTEM_PORT, по умолчанию выключен). В Kubernetes operator обычно задаёт DYN_SYSTEM_PORT=9090; для локальной разработки его нужно задать явно, например DYN_SYSTEM_PORT=8081.

Основная backend-система Dynamo публикует метрики на endpoint /metrics с префиксом dynamo_component_* для всех component, использующих framework DistributedRuntime:

• dynamo_component_inflight_requests: Requests currently being processed (gauge)
• dynamo_component_request_bytes_total: Total bytes received in requests (counter)
• dynamo_component_request_duration_seconds: Request processing time (histogram)
• dynamo_component_requests_total: Total requests processed (counter)
• dynamo_component_errors_total: Total errors encountered while handling a request (counter, labeled with error_type). See Component Error Types.
• dynamo_component_response_bytes_total: Total bytes sent in responses (counter)
• dynamo_component_uptime_seconds: DistributedRuntime uptime (gauge). Automatically updated before each Prometheus scrape on both the frontend (/metrics on port 8000) and the system status server (/metrics on DYN_SYSTEM_PORT when set).

Доступ к метрикам backend component:

# Set DYN_SYSTEM_PORT to enable the system status server
DYN_SYSTEM_PORT=8081 python -m dynamo.vllm --model <model>
curl http://localhost:8081/metrics

Метки component

Серии dynamo_component_* backend содержат две группы меток: те, которые выводит Dynamo runtime, и те, которые Prometheus/Kubernetes добавляют во время scrape.

Автоматически добавляются Dynamo runtime (через create_metric() в lib/runtime/src/metrics.rs для каждой метрики, зарегистрированной через иерархию namespace/component/endpoint):

Метка	Описание	Пример
dynamo_namespace	Namespace runtime Dynamo - логическая область, общая для каждого component (router / prefill / decode / encode) в одном deployment. Не K8s namespace.	dynamo_cloud_vllm_v1_disagg_router_071de157
dynamo_component	Роль службы: см. ниже Component Names.	backend, prefill, router
dynamo_endpoint	RPC внутри этого component: см. ниже Endpoint Names.	generate, clear_kv_blocks, worker_kv_indexer_query_dp0
worker_id	Hex-encoded discovery instance ID endpoint, который даёт стабильную идентичность каждого worker'а и не зависит от Kubernetes. Добавляется только когда у hierarchy endpoint есть connection ID.	1a2b3c4d

Добавляются кодом backend во время регистрации (передаются через metrics_labels=, когда worker вызывает serve_endpoint() - не добавляются автоматически, поэтому наличие зависит от backend):

Метка	Описание	Пример
model	Обслуживаемая модель (метка в стиле OpenAI). Добавляется worker'ами vLLM, SGLang и TRT-LLM на inference endpoint; отсутствует на внутренних endpoint вроде worker_kv_indexer_query_dp{N}.	Qwen/Qwen3-0.6B
model_name	Тот же идентификатор модели под вторым именем метки, сохранённый для engine-native совместимости и обратной совместимости дашбордов. Добавляется worker'ами vLLM и TRT-LLM; не добавляется SGLang.	Qwen/Qwen3-0.6B

Добавляется самой метрикой:

Метка	Описание	Пример
error_type	Только у dynamo_component_errors_total - категория сбоя. См. Component Error Types.	generate, publish_response

Добавляются Prometheus / Kubernetes (scraper, а не сама метрика):

Метка	Описание	Пример
instance	Scrape target в формате <podIP>:<metricsPort>.	192.168.133.236:9090
pod	Имя pod Kubernetes; различитель между replicas.	vllm-v1-disagg-router-vllmdecodeworker-...
container	Имя container внутри pod (обычно main).	main
namespace	Kubernetes namespace, в котором работает pod. Не то же самое, что dynamo_namespace.	dynamo-cloud
job	Имя scrape-job Prometheus, <k8s-namespace>/<service-name>.	dynamo-cloud/dynamo-worker
endpoint	Именованный port на Service K8s, который скопировал Prometheus. Не то же самое, что dynamo_endpoint.	system

Остерегайтесь этих совпадений:

• dynamo_namespace (область deployment Dynamo) vs. namespace (namespace K8s).
• dynamo_endpoint (RPC Dynamo) vs. endpoint (имя порта Service K8s).

Имена component

Значения, которые вы увидите в метке dynamo_component у серий dynamo_component_*. HTTP frontend (python -m dynamo.frontend) не входит в этот список — он публикует собственное семейство метрик dynamo_frontend_*, а не dynamo_component_*.

Значение	Значение
router	Отдельный KV router (python -m dynamo.router).
Planner	Компонент planner (python -m dynamo.planner). Обратите внимание на заглавную P.
prefill	Worker prefill в disaggregated serving (все backend).
backend	Worker decode в disaggregated serving для всех backend, а также объединённый worker для vLLM в aggregated mode.
encode	Worker encode для vLLM, SGLang и TRT-LLM.
diffusion	Worker diffusion для TRT-LLM.

Внутренние subsystem'ы (например, kvbm из block manager, sequences из KV router) тоже создают component и могут появляться в сериях dynamo_component_*. Значение по умолчанию для vLLM/SGLang можно переопределить, передав --endpoint dyn://<ns>.<component>.<endpoint> в командной строке worker'а.

Имя backend для decode worker историческое. В runtime есть TODO ввести константу decode и перейти на неё (см. lib/runtime/src/metrics/prometheus_names.rs::component_names).

Имена endpoint

Значения, которые вы увидите в метке dynamo_endpoint у backend workers:

Значение	Значение
generate	Основной inference RPC; один инкремент на каждый полученный запрос. На worker prefill это считает вызовы generate на stage prefill (по одному на каждый запрос, который пропускает router); на worker decode это считает вызовы generate на stage decode.
clear_kv_blocks	Административный RPC для очистки KV cache worker'а. Зарегистрирован и на prefill, и на decode worker'ах.
worker_kv_indexer_query_dp{N}	Запросы KV-router к локальному KV indexer worker'а о его кэшированных prefix blocks. По одному endpoint на каждый data-parallel rank (_dp0, _dp1, …). Появляется у worker'а, владеющего prefix caches, которые запрашивает router — в disaggregated serving это prefill worker.

Типы ошибок component

Счётчик dynamo_component_errors_total имеет метку error_type, которая показывает, на каком stage обработки запроса произошёл сбой:

error_type	Stage	Значение
deserialization	Ingress	Не удалось разобрать входной payload запроса.
invalid_message	Ingress	Нарушение wire format во входящем сообщении.
response_stream	Pre-generate	Worker получил запрос, но не смог открыть response stream обратно в frontend (transport issue до вызова generate).
generate	Engine	Сам generate() engine вернул ошибку. Этот счётчик отражает сбои engine/inference.
publish_response	Streaming	Engine сгенерировал response chunks, но worker не смог отправить один из них обратно в frontend (сбой записи в середине stream). Также срабатывает при отмене клиентом - когда frontend отключается до завершения stream, - поэтому счётчик может увеличиваться из-за прерванных пользователем запросов.
publish_final	Teardown	Все response chunks были отправлены, но worker не смог доставить финальный marker завершения stream. Соединение оборвалось в самом конце.

Специализированные метрики component

Некоторые component публикуют дополнительные метрики, специфичные для их функциональности:

• dynamo_preprocessor_*: Метрики, специфичные для preprocessor component

Метрики frontend

Важно: frontend и backend workers - это разные component, которые публикуют метрики на разных портах. Метрики backend см. в разделе Метрики backend component.

Dynamo HTTP Frontend (python -m dynamo.frontend) публикует метрики dynamo_frontend_* на порту 8000 по умолчанию (настраивается через --http-port или DYN_HTTP_PORT) на endpoint /metrics. Большинство метрик включают метки model с именем модели:

| dynamo_frontend_active_requests | Количество запросов, которые сейчас обрабатывает frontend, от входа HTTP handler до завершения response stream (gauge). Это верхнеуровневый счётчик in-flight без разбивки по stage. | | dynamo_frontend_stage_requests | Количество запросов, которые сейчас находятся на заданном stage pipeline frontend (gauge, метки: stage, phase). См. ниже Метки stage и phase. | | dynamo_frontend_inflight_requests | Inflight requests (gauge). Устарело - сохранено для обратной совместимости; используйте dynamo_frontend_active_requests, у которого те же semantics, но более понятное имя. | | dynamo_frontend_queued_requests | Количество запросов в очереди HTTP processing (gauge). Устарело - сохранено для обратной совместимости; окно "waiting for first token" теперь равно сумме dynamo_frontend_stage_requests на stages preprocess, route и dispatch. | | dynamo_frontend_disconnected_clients | Количество отключившихся клиентов (gauge) | | dynamo_frontend_input_sequence_tokens | Длина входной последовательности (histogram) | | dynamo_frontend_cached_tokens | Количество кэшированных токенов (prefix cache hits) на запрос (histogram) | | dynamo_frontend_inter_token_latency_seconds | Inter-token latency (histogram) | | dynamo_frontend_output_sequence_tokens | Длина выходной последовательности (histogram) | | dynamo_frontend_output_tokens_total | Общее количество сгенерированных выходных токенов (counter) | | dynamo_frontend_request_duration_seconds | Длительность LLM-запроса (histogram) | | dynamo_frontend_requests_total | Общее количество LLM-запросов (counter) | | dynamo_frontend_time_to_first_token_seconds | Время до первого токена (histogram) | | dynamo_frontend_model_migration_total | Общее количество миграций запросов из-за недоступности worker'а (counter, метки: model, migration_type) |

Доступ к метрикам frontend:

curl http://localhost:8000/metrics

Метки stage и phase

dynamo_frontend_stage_requests раскладывает жизненный цикл активного запроса frontend на три последовательных stage pipeline. Запрос одновременно учитывается ровно в одном stage (через RAII guard, который увеличивает счётчик при входе в stage и уменьшает при выходе), а в dynamo_frontend_active_requests он учитывается весь свой lifetime. Между stage - и после выхода из dispatch, пока backend стримит токены - запрос всё ещё находится в active_requests, но не попадает ни в один bucket stage_requests.

Значения метки stage:

Stage	Что покрывает	Входит, когда	Выходит, когда
preprocess	Токенизация и применение chat-template	Frontend входит в preprocess_request	Возвращается preprocessing
route	Выбор worker'а (включая ожидание в очереди KV-router, пока worker освобождается)	Вызывается generate() router'а	Worker выбран или запрос поставлен в очередь к нему
dispatch	Сериализация, транспорт к выбранному worker'у и ожидание первого ответа backend (включая время prefill backend)	generate() вызывается в AddressedPushRouter	Из backend получен первый ответ

Значения метки phase:

Phase	Значение
prefill	Запрос обрабатывается worker'ом prefill в disaggregated serving
decode	Запрос обрабатывается worker'ом decode в disaggregated serving
aggregated	Aggregated (не disaggregated) serving - один worker обрабатывает и prefill, и decode
"" (empty)	Stage не различает phase (используется preprocess)

Производные сигналы, которые обычно нужны operator'ам. Это cluster-wide totals по всем frontend pods. У stage_requests нет метки model, поэтому разделить их по model нельзя; добавьте by (pod) или by (instance) к любому sum(...) ниже, если нужна видимость по pod. Фильтр stage stage=~"preprocess|route|dispatch" используется явно, чтобы сохранить семантику "pre-first-token" стабильной, если в будущем появятся дополнительные stages, например postprocess.

• Запросы, ожидающие, пока worker начнёт генерировать (старый semantic "queued"): sum(dynamo_frontend_stage_requests{stage=~"preprocess|route|dispatch"}) - то есть запрос всё ещё находится в preprocess, route или dispatch.
• Запросы, которые сейчас обрабатывает backend worker: используйте gauge на стороне worker sum(dynamo_component_inflight_requests{dynamo_component="backend",dynamo_endpoint="generate"}) - это authoritative count, доступный, когда на worker задан DYN_SYSTEM_PORT (см. Метрики backend component).
  • Вариант с точки зрения frontend (полезно, если метрики worker не собираются или если вы оцениваете размеры frontend pods, а не worker'ов): sum(dynamo_frontend_active_requests) - sum(dynamo_frontend_stage_requests{stage=~"preprocess|route|dispatch"}). Это отличается от gauge worker, потому что его окно начинается, когда первый токен попадает во frontend, и продолжается до стриминга клиенту, поэтому включает время transit и client-buffering.
• Насыщение router: всплеск sum(dynamo_frontend_stage_requests{stage="route"}) означает, что worker'ы не удаётся выбрать достаточно быстро (например, все backend заняты, очередь KV-router переполнена).
• Насыщение prefill backend: всплеск sum(dynamo_frontend_stage_requests{stage="dispatch"}) означает, что backend медленно выдаёт первые токены.

Устаревшие gauges frontend

Следующие gauges по-прежнему публикуются, но будут удалены в будущем релизе. Они были заменены указанными выше gauges в рамках переработки frontend metrics (PR #8162). Дашборды и alert'ы должны уйти с них.

Устаревшая метрика	Замена
dynamo_frontend_inflight_requests	dynamo_frontend_active_requests (те же semantics, более понятное имя)
dynamo_frontend_queued_requests	sum(dynamo_frontend_stage_requests{stage=~"preprocess|route|dispatch"})

Метрики конфигурации model

Frontend также публикует метрики конфигурации model (на endpoint /metrics порта 8000) с префиксом dynamo_frontend_model_*. Эти метрики заполняются из службы регистрации worker backend, когда worker'ы регистрируются в системе. Все метрики конфигурации model включают метку model.

Метрики runtime config (из ModelRuntimeConfig): Эти метрики берутся из runtime configuration, которую worker backend передаёт во время регистрации.

• dynamo_frontend_model_total_kv_blocks: Общее количество KV blocks, доступных worker'у, обслуживающему модель (gauge)
• dynamo_frontend_model_max_num_seqs: Максимальное число sequences для worker'а, обслуживающего модель (gauge)
• dynamo_frontend_model_max_num_batched_tokens: Максимальное число batched tokens для worker'а, обслуживающего модель (gauge)

Метрики MDC (из ModelDeploymentCard): Эти метрики берутся из информации Model Deployment Card, которую передают worker backend во время регистрации. Обратите внимание: если несколько worker instances регистрируются с одним и тем же именем модели, будут заполнены только метрики конфигурации первого instance (runtime config и MDC metrics). Последующие instances с дублирующимися именами модели будут пропущены при обновлении метрик конфигурации.

• dynamo_frontend_model_context_length: Максимальная длина контекста для worker'а, обслуживающего модель (gauge)
• dynamo_frontend_model_kv_cache_block_size: Размер блока KV cache для worker'а, обслуживающего модель (gauge)
• dynamo_frontend_model_migration_limit: Лимит миграции запросов для worker'а, обслуживающего модель (gauge)

Поток обработки запросов

Устаревшая схема. Двухметричная модель ниже (inflight против HTTP queue) описывает legacy gauges dynamo_frontend_inflight_requests и dynamo_frontend_queued_requests и оставлена только для помощи operator'ам, которые читают существующие дашборды. Для новых задач следует использовать dynamo_frontend_active_requests и per-stage gauges dynamo_frontend_stage_requests, описанные в разделе Метки stage и phase.

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

1. Inflight: Отслеживает запросы от начала HTTP handler до полного завершения ответа
2. HTTP Queue: Отслеживает запросы от начала HTTP handler до начала генерации первого токена (включая время prefill)

Пример потока запроса:

curl -s localhost:8000/v1/completions -H "Content-Type: application/json" -d '{
  "model": "Qwen/Qwen3-0.6B",
  "prompt": "Hello let's talk about LLMs",
  "stream": false,
  "max_tokens": 1000
}'

Временная шкала:

sequenceDiagram
    participant Client
    participant Frontend as Frontend:8000
    participant Backend as Backend (SGLang/TRT/vLLM)

    Client->>Frontend: Request start
    Note over Frontend,Backend: HTTP queue begins
    Frontend->>Backend: Forward request
    Note over Backend: Start prefill
    Backend-->>Frontend: First token
    Note over Frontend,Backend: HTTP queue ends
    loop Token generation
        Backend-->>Frontend: Tokens
    end
    Backend-->>Frontend: Last token
    Frontend-->>Client: Complete response
    Note over Frontend: Inflight ends

Пример параллелизма: Предположим, backend допускает 3 одновременных запроса, а 10 клиентов непрерывно отправляют запросы во frontend:

• Все 10 запросов будут считаться inflight (от начала до полного ответа)
• 7 запросов большую часть времени будут находиться в HTTP queue
• 3 запроса будут активно обрабатываться (между первым и последним токеном)

Ключевые различия:

• Inflight: Измеряет полный lifetime запроса, включая время обработки
• HTTP Queue: Измеряет время ожидания до начала обработки (включая время prefill)
• HTTP Queue ≤ Inflight (HTTP queue является подмножеством времени inflight)

Метрики router

Router публикует метрики для мониторинга routing decisions и overhead. Определены в lib/llm/src/kv_router/metrics.rs.

Режимы deployment router см. в Router Guide. Флаги router и tuning см. в Configuration and Tuning.

Доступность метрик по конфигурации

Не все метрики появляются в каждом deployment. Таблица ниже показывает, какие группы метрик регистрируются и заполняются в каждой конфигурации:

Группа метрик	Frontend + KV (agg)	Frontend + KV (disagg)	Frontend + non-KV (round-robin/random/direct)	Standalone Router
dynamo_component_router_* (request metrics)	Регистрируются и заполняются	Регистрируются и заполняются	Регистрируются, всегда ноль	Заполняются (на DYN_SYSTEM_PORT)
dynamo_router_overhead_* (routing overhead)	Регистрируются и заполняются	Регистрируются и заполняются	Не регистрируются	Не создаются
dynamo_frontend_router_queue_* (queue depth)	Регистрируются; заполняются, когда задан --router-queue-threshold	Регистрируются; заполняются, когда задан --router-queue-threshold	Не регистрируются	Не создаются
dynamo_component_kv_cache_events_applied (indexer)	Заполняются, когда получены KV events	Заполняются, когда получены KV events	Не регистрируются	Заполняются, когда получены KV events
dynamo_frontend_worker_* (per-worker load/timing)	Регистрируются и заполняются	Регистрируются и заполняются (worker_type=prefill/decode)	Регистрируются и заполняются (worker_type=decode)	Не создаются

Легенда:

• Регистрируются и заполняются: метрика появляется в /metrics с реальными значениями
• Регистрируются, всегда ноль: метрика появляется в /metrics, но счётчик/histogram никогда не увеличивается (полезно для дашбордов, которые ожидают существование метрики)
• Не регистрируются / Не создаются: метрика вообще не появляется в /metrics

Точки scrape:

• Frontend: /metrics на HTTP port (по умолчанию 8000, настраивается через --http-port или DYN_HTTP_PORT)
• Standalone router: /metrics на DYN_SYSTEM_PORT (нужно задать явно; по умолчанию -1 / disabled)
• Backend workers: /metrics на DYN_SYSTEM_PORT (отдельно от метрик frontend)

Метрики request router (dynamo_component_router_*)

Histogram и counter для агрегированной статистики уровня request. Регистрируются заранее через from_component() в иерархии DRT MetricsRegistry. На frontend публикуются на HTTP port (по умолчанию 8000) через bridge drt_metrics. На standalone router (python -m dynamo.router) публикуются на DYN_SYSTEM_PORT, если он задан. Заполняются по каждому запросу, когда активен --router-mode kv; в non-KV режимах регистрируются со значением ноль.

Все метрики содержат стандартные метки иерархии (dynamo_namespace, dynamo_component, dynamo_endpoint).

Метрика	Тип	Описание
dynamo_component_router_requests_total	Counter	Общее число запросов, обработанных router
dynamo_component_router_time_to_first_token_seconds	Histogram	Время до первого токена (секунды)
dynamo_component_router_inter_token_latency_seconds	Histogram	Средняя межтокенная задержка (секунды)
dynamo_component_router_input_sequence_tokens	Histogram	Длина входной последовательности (токены)
dynamo_component_router_output_sequence_tokens	Histogram	Длина выходной последовательности (токены)
dynamo_component_router_kv_hit_rate	Histogram	Предсказанный коэффициент попадания KV cache во время routing (0.0-1.0)

Накладные расходы routing на запрос (dynamo_router_overhead_*)

Histogram (в миллисекундах), которые отслеживают время, затраченное на каждую фазу routing decision для каждого запроса. Регистрируются на порту frontend (по умолчанию 8000) в /metrics с меткой router_id (discovery instance ID frontend). Эти метрики создаются только когда у frontend включён DRT discovery, то есть при --router-mode kv; в non-KV режимах и на standalone router они не появляются.

Метрика	Тип	Описание
dynamo_router_overhead_block_hashing_ms	Histogram	Время вычисления block hashes
dynamo_router_overhead_indexer_find_matches_ms	Histogram	Время выполнения find_matches в indexer
dynamo_router_overhead_seq_hashing_ms	Histogram	Время вычисления sequence hashes
dynamo_router_overhead_scheduling_ms	Histogram	Время выбора worker'а scheduler'ом
dynamo_router_overhead_total_ms	Histogram	Общие routing overhead на запрос

Метрики очереди router (dynamo_frontend_router_queue_*)

Gauge, который отслеживает число запросов, ожидающих в scheduler queue router'а. Регистрируется только когда задан --router-queue-threshold. Имеет метку worker_type, чтобы различать очереди prefill и decode в disaggregated mode.

Метрика	Тип	Описание
dynamo_frontend_router_queue_pending_requests	Gauge	Запросы, ожидающие в scheduler queue router'а

Метки: worker_type (prefill или decode)

Метрики KV indexer

Отслеживает KV cache events, применённые к radix tree index router'а. Появляется только когда --router-kv-overlap-score-credit больше 0 (по умолчанию) и worker'ы публикуют KV events. Не появится, если задан --router-kv-overlap-score-credit 0 или если KV events не были получены.

Метрика	Тип	Описание
dynamo_component_kv_cache_events_applied	Counter	KV cache events, применённые к index

Дополнительные метки: status (ok / parent_block_not_found / block_not_found / invalid_block), event_type (stored / removed / cleared)

Gauges нагрузки и timing по worker (dynamo_frontend_worker_*)

Они появляются, когда worker'ы регистрируются и начинают обслуживать запросы. Они регистрируются в локальном Prometheus registry frontend (не на уровне component) и не содержат меток dynamo_namespace или dynamo_component. Эти метрики доступны только на frontend и недоступны на standalone router.

Метрика	Тип	Описание
dynamo_frontend_worker_active_decode_blocks	Gauge	Активные decode blocks KV cache на worker
dynamo_frontend_worker_active_prefill_tokens	Gauge	Активные prefill tokens, ожидающие на worker
dynamo_frontend_worker_last_time_to_first_token_seconds	Gauge	Последнее наблюдаемое TTFT на worker (секунды)
dynamo_frontend_worker_last_input_sequence_tokens	Gauge	Последняя наблюдаемая длина входной последовательности на worker
dynamo_frontend_worker_last_inter_token_latency_seconds	Gauge	Последняя наблюдаемая ITL на worker (секунды)

Метки:

Метка	Пример значения	Описание
worker_id	7890	Идентификатор instance worker'а (etcd lease ID)
dp_rank	0	Ранг data-parallel
worker_type	prefill или decode	Роль worker'а

В disaggregated mode метка worker_type принимает значения и "prefill", и "decode"; в aggregated mode все worker'ы сообщают "decode".

Метрики NIXL Telemetry

NIXL публикует собственные метрики Prometheus на отдельном порту от метрик Dynamo. Эти метрики отслеживают передачи KV cache и embedding data и заполняются только во время disaggregated serving или multimodal embedding transfers.

Чтобы включить их, задайте следующие переменные среды в процессе worker:

# Worker prefill
NIXL_TELEMETRY_ENABLE=y NIXL_TELEMETRY_EXPORTER=prometheus \
  NIXL_TELEMETRY_PROMETHEUS_PORT=19090 DYN_SYSTEM_PORT=8081 \
  python -m dynamo.vllm --model <model> --disaggregation-mode prefill

# Worker decode (другой порт NIXL, чтобы избежать конфликта)
NIXL_TELEMETRY_ENABLE=y NIXL_TELEMETRY_EXPORTER=prometheus \
  NIXL_TELEMETRY_PROMETHEUS_PORT=19091 DYN_SYSTEM_PORT=8082 \
  python -m dynamo.vllm --model <model> --disaggregation-mode decode

# Сбор метрик NIXL (отдельно от метрик Dynamo на 8081/8082)
curl http://localhost:19090/metrics

Полный список метрик, опций конфигурации и архитектурных подробностей см. в upstream документации NIXL Telemetry и README Prometheus exporter. Для Kubernetes см. Enable NIXL Telemetry.

Связанная документация

• Distributed Runtime Architecture
• Dynamo Architecture Overview
• Backend Guide
• Forward Pass Metrics (SGLang) — телеметрия scheduler на каждой итерации через ZMQ/NATS для scaling на основе planner (целевой architecture; недоступно в runtime image SGLang 1.2.0)
• Forward Pass Metrics RFC - Обоснование дизайна метрик по итерациям