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.
Дисагрегированное обслуживание
AIConfigurator - это инструмент оптимизации производительности, который помогает подобрать оптимальную конфигурацию для развёртывания LLM с Dynamo. Он автоматически определяет лучшее число prefill- и decode-worker'ов, настройки параллелизма и параметры развёртывания, чтобы выполнить ваши SLA-цели и одновременно максимизировать throughput.
Зачем использовать AIConfigurator?
При развёртывании LLM с Dynamo вам нужно принять несколько критически важных решений:
- Aggregated vs Disaggregated: какая архитектура даст лучшую производительность для вашей нагрузки?
- Worker Configuration: сколько prefill- и decode-worker'ов разворачивать?
- Parallelism Settings: какую конфигурацию tensor/pipeline parallel использовать?
- SLA Compliance: как выполнить цели по TTFT и TPOT?
AIConfigurator отвечает на эти вопросы за секунды и предоставляет:
- Рекомендуемые конфигурации, которые соответствуют вашим SLA-требованиям
- Готовые к развёртыванию конфигурационные файлы Dynamo (включая Kubernetes manifests)
- Сравнение производительности разных стратегий развёртывания
- До 1.7x более высокий throughput по сравнению с ручной конфигурацией
Полный workflow
Сравнение aggregated и disaggregated архитектур
AIConfigurator оценивает две архитектуры развёртывания и рекомендует лучшую для вашей нагрузки:
Когда использовать каждую архитектуру
Быстрый старт
# Установка
pip3 install aiconfigurator
# Найдите оптимальную конфигурацию для backend vLLM
aiconfigurator cli default \
--model Qwen/Qwen3-32B-FP8 \
--total-gpus 8 \
--system h200_sxm \
--backend vllm \
--backend-version 0.12.0 \
--isl 4000 \
--osl 500 \
--ttft 600 \
--tpot 16.67 \
--save-dir ./results_vllm
# Развёртывание в Kubernetes
kubectl apply -f ./results_vllm/agg/top1/agg/k8s_deploy.yaml
Полный пример: vLLM на H200
В этом разделе разбирается проверенный пример развёртывания Qwen3-32B-FP8 на 8× H200 GPU с использованием vLLM.
Шаг 1: запустите AIConfigurator
aiconfigurator cli default \
--model Qwen/Qwen3-32B-FP8 \
--system h200_sxm \
--total-gpus 8 \
--isl 4000 \
--osl 500 \
--ttft 600 \
--tpot 25 \
--backend vllm \
--backend-version 0.12.0 \
--generator-dynamo-version 1.0.0 \
--generator-set K8sConfig.k8s_namespace=$YOUR_NAMESPACE \
--generator-set K8sConfig.k8s_pvc_name=$YOUR_PVC \
--save-dir ./results_vllm
Пояснение параметров:
--model: ID модели HuggingFace или локальный путь (например,Qwen/Qwen3-32B-FP8)--system: тип GPU-системы (h200_sxm,h100_sxm,a100_sxm)--total-gpus: количество GPU, доступных для развёртывания--isl/--osl: длины входной/выходной последовательности в токенах--ttft/--tpot: SLA-цели - Time To First Token (ms) и Time Per Output Token (ms)--backend: backend инференса (vllm,trtllmилиsglang)--backend-version: версия backend'а (например,0.12.0для vLLM)--save-dir: каталог для сохранения сгенерированных конфигов развёртывания
Шаг 2: изучите результаты
AIConfigurator выводит сравнение стратегий aggregated и disaggregated развёртывания:
********************************************************************************
* Dynamo aiconfigurator Final Results *
********************************************************************************
----------------------------------------------------------------------------
Input Configuration & SLA Target:
Model: Qwen/Qwen3-32B-FP8 (is_moe: False)
Total GPUs: 8
Best Experiment Chosen: disagg at 446.85 tokens/s/gpu (disagg 1.38x better)
----------------------------------------------------------------------------
Overall Best Configuration:
- Best Throughput: 3,574.80 tokens/s
- Per-GPU Throughput: 446.85 tokens/s/gpu
- Per-User Throughput: 53.58 tokens/s/user
- TTFT: 453.18ms
- TPOT: 18.66ms
- Request Latency: 9766.51ms
----------------------------------------------------------------------------
Pareto Frontier:
Qwen/Qwen3-32B-FP8 Pareto Frontier: tokens/s/gpu_cluster vs tokens/s/user
┌─────────────────────────────────────────────────────────────────────────┐
850.0┤ •• agg │
│ ff disagg │
│ xx disagg best │
│ │
708.3┤ │
│ f │
│ f │
│ fff │
566.7┤ f │
│ f │
│ f │
│ •• fffffffffffffffffx │
425.0┤ •••• ff │
│ ••• f │
│ ••••• f │
│ •••••••••• f │
283.3┤ ••• f │
│ •• f │
│ •• f │
│ ••••f │
141.7┤ •f• │
│ f••••• │
│ f ••••••• │
│ fffff •••• │
0.0┤ •••• │
└┬─────────────────┬─────────────────┬─────────────────┬─────────────────┬┘
0 30 60 90 120
tokens/s/gpu_cluster tokens/s/user
----------------------------------------------------------------------------
Детали развёртывания:
(p) означает prefill, (d) означает decode, bs означает batch size, а replica означает минимальную масштабируемую единицу xPyD в disagg-системе
Немного математики: total gpus used = replicas * gpus/replica
gpus/replica = (p)gpus/worker * (p)workers + (d)gpus/worker * (d)workers; для Agg gpus/replica = gpus/worker
gpus/worker = tp * pp * dp = etp * ep * pp для MoE models; tp * pp для dense models (underlined numbers are the actual values in math)
agg Top Configurations: (отсортировано по tokens/s/gpu)
+------+---------+--------------+---------------+--------+-----------------+-------------+-------------------+----------+--------------+-------------+----------+----+
| Место | backend | tokens/s/gpu | tokens/s/user | TTFT | request_latency | concurrency | total_gpus (used) | replicas | gpus/replica | gpus/worker | parallel | bs |
+------+---------+--------------+---------------+--------+-----------------+-------------+-------------------+----------+--------------+-------------+----------+----+
| 1 | vllm | 322.69 | 41.78 | 546.92 | 12490.03 | 64 (=32x2) | 8 (8=2x4) | 2 | 4 | 4 (=4x1x1) | tp4pp1 | 32 |
| 2 | vllm | 293.94 | 44.43 | 593.10 | 11823.67 | 56 (=14x4) | 8 (8=4x2) | 4 | 2 | 2 (=2x1x1) | tp2pp1 | 14 |
| 3 | vllm | 208.87 | 42.90 | 460.58 | 12093.52 | 40 (=40x1) | 8 (8=1x8) | 1 | 8 | 8 (=8x1x1) | tp8pp1 | 40 |
+------+---------+--------------+---------------+--------+-----------------+-------------+-------------------+----------+--------------+-------------+----------+----+
disagg Top Configurations: (отсортировано по tokens/s/gpu)
+------+---------+--------------+---------------+--------+-----------------+-------------+-------------------+----------+--------------+------------+----------------+-------------+-------+------------+----------------+-------------+-------+
| Место | backend | tokens/s/gpu | tokens/s/user | TTFT | request_latency | concurrency | total_gpus (used) | replicas | gpus/replica | (p)workers | (p)gpus/worker | (p)parallel | (p)bs | (d)workers | (d)gpus/worker | (d)parallel | (d)bs |
+------+---------+--------------+---------------+--------+-----------------+-------------+-------------------+----------+--------------+------------+----------------+-------------+-------+------------+----------------+-------------+-------+
| 1 | vllm | 446.85 | 53.58 | 453.18 | 9766.51 | 76 (=76x1) | 8 (8=1x8) | 1 | 8 (=2x2+1x4) | 2 | 2 (=2x1) | tp2pp1 | 1 | 1 | 4 (=4x1) | tp4pp1 | 76 |
| 2 | vllm | 446.85 | 41.14 | 453.18 | 12581.87 | 144 (=72x2) | 8 (8=2x4) | 2 | 4 (=1x2+1x2) | 1 | 2 (=2x1) | tp2pp1 | 1 | 1 | 2 (=2x1) | tp2pp1 | 72 |
| 3 | vllm | 333.73 | 40.22 | 453.18 | 12860.32 | 72 (=36x2) | 8 (8=2x4) | 2 | 4 (=1x2+2x1) | 1 | 2 (=2x1) | tp2pp1 | 1 | 2 | 1 (=1x1) | tp1pp1 | 18 |
+------+---------+--------------+---------------+--------+-----------------+-------------+-------------------+----------+--------------+------------+----------------+-------------+-------+------------+----------------+-------------+-------+
Как читать вывод:
- tokens/s/gpu: общая эффективность throughput - чем выше, тем лучше
- tokens/s/user: скорость генерации на запрос (обратная величина TPOT)
- TTFT: прогнозируемое время до первого токена
- concurrency: общее число одновременных запросов по всем replica'м (например,
56 (=14x4)означает batch size 14 × 4 replica) - agg Rank 1 рекомендует TP4 с 2 replica'ми - проще в развёртывании
- disagg Rank 1 рекомендует 2 prefill-worker'а (TP2) + 1 decode-worker (TP4) - выше throughput, но требуется RDMA
Шаг 3: развёртывание в Kubernetes
--save-dir генерирует готовые к использованию Kubernetes manifests:
├── agg
│ ├── best_config_topn.csv
│ ├── exp_config.yaml
│ ├── pareto.csv
│ ├── top1
│ │ ├── agg_config.yaml
│ │ ├── bench_run.sh # aiperf benchmark sweep script (bare-metal)
│ │ ├── generator_config.yaml
│ │ ├── k8s_bench.yaml # aiperf benchmark sweep Job (Kubernetes)
│ │ ├── k8s_deploy.yaml # Kubernetes DynamoGraphDeployment
│ │ └── run_0.sh
│ ...
├── disagg
│ ├── best_config_topn.csv
│ ├── exp_config.yaml
│ ├── pareto.csv
│ ├── top1
│ │ ├── bench_run.sh # aiperf benchmark sweep script (bare-metal)
│ │ ├── decode_config.yaml
│ │ ├── generator_config.yaml
│ │ ├── k8s_bench.yaml # aiperf benchmark sweep Job (Kubernetes)
│ │ ├── k8s_deploy.yaml # Kubernetes DynamoGraphDeployment
│ │ ├── prefill_config.yaml
│ │ ├── run_0.sh
│ │ └── run_1.sh (for multi-node setups)
│ ...
└── pareto_frontier.png
Предварительные требования
Перед развёртыванием убедитесь, что у вас есть:
-
HuggingFace Token Secret (для gated models):
kubectl create secret generic hf-token-secret \-n your-namespace \--from-literal=HF_TOKEN="your-huggingface-token" -
Model Cache PVC (рекомендуется для более быстрых перезапусков):
apiVersion: v1kind: PersistentVolumeClaimmetadata:name: model-cachenamespace: your-namespacespec:accessModes:- ReadWriteManyresources:requests:storage: 100Gi
Разверните конфигурацию
Сгенерированный k8s_deploy.yaml даёт стартовую точку. Обычно его нужно адаптировать под свою среду:
kubectl apply -f ./results_vllm/agg/top1/agg/k8s_deploy.yaml
Полный пример развёртывания с model cache и production-настройками:
apiVersion: nvidia.com/v1alpha1
kind: DynamoGraphDeployment
metadata:
name: dynamo-agg
namespace: your-namespace
spec:
backendFramework: vllm
pvcs:
- name: model-cache
create: false # Use existing PVC
services:
Frontend:
componentType: frontend
replicas: 1
volumeMounts:
- name: model-cache
mountPoint: /opt/models
envs:
- name: HF_HOME
value: /opt/models
extraPodSpec:
mainContainer:
image: nvcr.io/nvidia/ai-dynamo/vllm-runtime:1.2.0
imagePullPolicy: IfNotPresent
VLLMWorker:
envFromSecret: hf-token-secret
componentType: worker
replicas: 4
resources:
limits:
gpu: "2"
sharedMemory:
size: 16Gi # Требуется для vLLM
volumeMounts:
- name: model-cache
mountPoint: /opt/models
envs:
- name: HF_HOME
value: /opt/models
extraPodSpec:
mainContainer:
image: nvcr.io/nvidia/ai-dynamo/vllm-runtime:1.2.0
workingDir: /workspace
imagePullPolicy: IfNotPresent
command:
- python3
- -m
- dynamo.vllm
args:
- --model
- "Qwen/Qwen3-32B-FP8"
- "--no-enable-prefix-caching"
- "--tensor-parallel-size"
- "2"
- "--pipeline-parallel-size"
- "1"
- "--data-parallel-size"
- "1"
- "--kv-cache-dtype"
- "fp8"
- "--max-model-len"
- "6000"
- "--max-num-seqs"
- "1024"
Ключевые настройки развёртывания:
| Параметр | Назначение | Примечания |
|---|---|---|
backendFramework: vllm | Сообщает Dynamo, какой runtime использовать | Обязательно на уровне spec |
pvcs + volumeMounts | Кэширует веса модели между перезапусками | Монтируйте в /opt/models (не в /root/) |
HF_HOME env var | Указывает HuggingFace расположение кэша | Должна совпадать с mountPoint |
sharedMemory.size: 16Gi | IPC memory для vLLM | 16Gi для vLLM, 80Gi для TRT-LLM |
envFromSecret | Внедряет HF_TOKEN | Требуется для gated models |
Шаг 4: проверьте с помощью AIPerf
После развёртывания проверьте прогнозы на фактической производительности с помощью AIPerf.
ℹ️ Запускайте AIPerf внутри кластера, чтобы сетевые задержки не влияли на измерения.
AIC автоматически генерирует скрипты AIPerf вместе с конфигами Dynamo и сохраняет их в папку результатов (если указан --save-dir ...). Для развёртываний Kubernetes можно запускать бенчмарки через k8s_bench.yaml, а для bare-metal систем использовать скрипт bench_run.sh. Эти скрипты запускают AIPerf по списку concurrency: набор по умолчанию (1 2 8 16 32 64 128) вместе с BenchConfig.estimated_concurrency и значениями в пределах ±5%. При необходимости этот список concurrency можно настроить.
По умолчанию результаты AIPerf сохраняются в /tmp/bench_artifacts контейнеров. Если в --generator-set K8sConfig.k8s_pvc_name=$YOUR_PVC указан PVC, артефакты результатов будут сохраняться в volume mount PVC.
| Вывод AIC | Параметр AIPerf | Примечания |
|---|---|---|
concurrency: 56 (=14x4) | --concurrency 56 | Используйте общее значение concurrency при бенчмаркинге через frontend |
| ISL/OSL targets | --isl 4000 --osl 500 | Сопоставьте с вашими входными данными AIC |
| - | --num-requests 800 | Используйте минимум concurrency × 40 для статистической устойчивости |
| - | --extra-inputs "ignore_eos:true" | Обеспечивает точную генерацию токенов OSL |
Примечание о concurrency: AIC сообщает concurrency как
total (=bs × replicas). При бенчмаркинге через frontend (который маршрутизирует на все replica'и) используйте общее значение. Если бенчмарка идёт напрямую на один replica, используйте значениеbsна replica.
apiVersion: batch/v1
kind: Job
metadata:
name: aiperf-benchmark
namespace: your-namespace
spec:
template:
spec:
restartPolicy: Never
containers:
- name: aiperf
image: python:3.10
command:
- /bin/bash
- -c
- |
pip install aiperf
aiperf profile \
-m Qwen/Qwen3-32B-FP8 \
--endpoint-type chat \
-u http://dynamo-agg-frontend:8000 \
--isl 4000 --isl-stddev 0 \
--osl 500 --osl-stddev 0 \
--num-requests 800 \
--concurrency 56 \
--streaming \
--extra-inputs "ignore_eos:true" \
--num-warmup-requests 40 \
--ui-type simple
kubectl apply -f k8s_bench.yaml
kubectl logs -f -l job-name=aiperf-benchmark
Проверенные результаты (Qwen3-32B-FP8, 8× H200, TP2×4 replica'и, aggregated):
| Metric | AIC Prediction | Actual (avg) | Status |
|---|---|---|---|
| TTFT (ms) | 509 | 209 | Better than target |
| ITL/TPOT (ms) | 16.49 | 15.06 | Within 10% |
| Throughput (req/s) | ~6.3 | 6.9 | Within 10% |
| Total Output TPS | ~3,178 | 3,462 | Within 10% |
Фактический throughput обычно достигает ~85-90% от прогнозов AIC, при этом ITL/TPOT - самая точная метрика. Между запусками бенчмарков возможен некоторый разброс; рекомендуется запускать их несколько раз. Для дополнительного улучшения TTFT при повторяющихся prompt'ах включите prefix caching (--enable-prefix-caching).
Тонкая настройка развёртывания
AIConfigurator даёт хорошую стартовую конфигурацию. Ниже - как донастраивать её для production.
Настройка под реальную нагрузку
Если ваша реальная нагрузка отличается от параметров бенчмарка:
# For longer outputs (chat/code generation):
# increase OSL, relax TTFT target
aiconfigurator cli default \
--model Qwen/Qwen3-32B-FP8 \
--total-gpus 8 \
--system h200_sxm \
--backend vllm \
--backend-version 0.12.0 \
--isl 2000 \
--osl 2000 \
--ttft 1000 \
--tpot 10 \
--save-dir ./results_long_output
Исследование альтернативных конфигураций
Используйте режим exp, чтобы сравнить собственные конфигурации:
# custom_exp.yaml
exps:
- exp_tp2
- exp_tp4
exp_tp2:
mode: "patch"
serving_mode: "agg"
model_path: "Qwen/Qwen3-32B-FP8"
total_gpus: 8
system_name: "h200_sxm"
backend_name: "vllm"
backend_version: "0.12.0"
isl: 4000
osl: 500
ttft: 600
tpot: 16.67
config:
agg_worker_config:
tp_list: [2]
exp_tp4:
mode: "patch"
serving_mode: "agg"
model_path: "Qwen/Qwen3-32B-FP8"
total_gpus: 8
system_name: "h200_sxm"
backend_name: "vllm"
backend_version: "0.12.0"
isl: 4000
osl: 500
ttft: 600
tpot: 16.67
config:
agg_worker_config:
tp_list: [4]
aiconfigurator cli exp --yaml-path custom_exp.yaml --save-dir ./results_custom
Критично: disaggregated-развёртывания требуют RDMA для передачи KV cache. Без RDMA производительность падает в 40x раз (TTFT растёт с 355ms до 10+ секунд). См. раздел Disaggregated Deployment ниже.
Развёртывание disaggregated (требуется RDMA)
Disaggregated-развёртывания передают KV cache между prefill- и decode-worker'ами. Без RDMA эта передача становится серьёзным узким местом, вызывая 40x ухудшение производительности.
Предварительные требования для disaggregated
- Сеть с поддержкой RDMA (InfiniBand или RoCE)
- RDMA device plugin, установленный в кластере (предоставляет ресурсы
rdma/ib) - Инфраструктура discovery и event-plane, настроенная для вашего развёртывания (например, нативный Kubernetes discovery с ZMQ- или NATS-событиями, либо etcd/NATS, когда выбраны эти backend'ы)
Disaggregated DGD с RDMA
apiVersion: nvidia.com/v1alpha1
kind: DynamoGraphDeployment
metadata:
name: dynamo-disagg
namespace: your-namespace
spec:
backendFramework: vllm
pvcs:
- name: model-cache
create: false
services:
Frontend:
componentType: frontend
replicas: 1
volumeMounts:
- name: model-cache
mountPoint: /opt/models
envs:
- name: HF_HOME
value: /opt/models
extraPodSpec:
mainContainer:
image: nvcr.io/nvidia/ai-dynamo/vllm-runtime:1.2.0
imagePullPolicy: IfNotPresent
VLLMPrefillWorker:
envFromSecret: hf-token-secret
componentType: worker
subComponentType: prefill
replicas: 2
resources:
limits:
gpu: "2"
sharedMemory:
size: 16Gi
volumeMounts:
- name: model-cache
mountPoint: /opt/models
envs:
- name: HF_HOME
value: /opt/models
- name: UCX_TLS
value: "rc_x,rc,dc_x,dc,cuda_copy,cuda_ipc" # Enable RDMA transports
- name: UCX_RNDV_SCHEME
value: "get_zcopy"
- name: UCX_RNDV_THRESH
value: "0"
extraPodSpec:
mainContainer:
image: nvcr.io/nvidia/ai-dynamo/vllm-runtime:1.2.0
workingDir: /workspace
imagePullPolicy: IfNotPresent
securityContext:
capabilities:
add: ["IPC_LOCK"] # Required for RDMA memory registration
resources:
limits:
rdma/ib: "2" # Request RDMA resources
requests:
rdma/ib: "2"
command: ["python3", "-m", "dynamo.vllm"]
args:
- --model
- "Qwen/Qwen3-32B-FP8"
- "--tensor-parallel-size"
- "2"
- "--kv-cache-dtype"
- "fp8"
- "--max-num-seqs"
- "1" # Prefill workers use batch size 1
- --disaggregation-mode
- prefill
VLLMDecodeWorker:
envFromSecret: hf-token-secret
componentType: worker
subComponentType: decode
replicas: 1
resources:
limits:
gpu: "4"
sharedMemory:
size: 16Gi
volumeMounts:
- name: model-cache
mountPoint: /opt/models
envs:
- name: HF_HOME
value: /opt/models
- name: UCX_TLS
value: "rc_x,rc,dc_x,dc,cuda_copy,cuda_ipc"
- name: UCX_RNDV_SCHEME
value: "get_zcopy"
- name: UCX_RNDV_THRESH
value: "0"
extraPodSpec:
mainContainer:
image: nvcr.io/nvidia/ai-dynamo/vllm-runtime:1.2.0
workingDir: /workspace
imagePullPolicy: IfNotPresent
securityContext:
capabilities:
add: ["IPC_LOCK"]
resources:
limits:
rdma/ib: "4"
requests:
rdma/ib: "4"
command: ["python3", "-m", "dynamo.vllm"]
args:
- --model
- "Qwen/Qwen3-32B-FP8"
- "--tensor-parallel-size"
- "4"
- "--kv-cache-dtype"
- "fp8"
- "--max-num-seqs"
- "1024" # Decode workers handle high concurrency
- --disaggregation-mode
- decode
Критические настройки RDMA:
| Параметр | Назначение |
|---|---|
rdma/ib: "N" | Запрашивает N ресурсов RDMA (соответствует размеру TP) |
IPC_LOCK capability | Требуется для регистрации RDMA memory |
UCX_TLS env var | Включает RDMA transports (rc_x, dc_x) |
UCX_RNDV_SCHEME=get_zcopy | Zero-copy RDMA transfers |
Проверка, что RDMA активно
После развёртывания проверьте логи worker'ов на инициализацию UCX:
kubectl logs <prefill-worker-pod> | grep -i "UCX\|NIXL"
You should see:
NIXL INFO Backend UCX was instantiated
Если видны только TCP transports, RDMA не активен - проверьте RDMA device plugin и resource requests.
Настройка параметров vLLM
Переопределяйте параметры движка vLLM с помощью --generator-set:
aiconfigurator cli default \
--model Qwen/Qwen3-32B-FP8 \
--total-gpus 8 \
--system h200_sxm \
--backend vllm \
--backend-version 0.12.0 \
--isl 4000 --osl 500 \
--ttft 600 --tpot 16.67 \
--save-dir ./results_tuned \
--generator-set Workers.agg.kv_cache_free_gpu_memory_fraction=0.85 \
--generator-set Workers.agg.max_num_seqs=2048
Запустите aiconfigurator cli default --generator-help, чтобы увидеть все доступные параметры.
Что учитывать для Prefix Caching
Для нагрузок с повторяющимися префиксами (например, system prompt'ами):
- Включайте prefix caching, когда доля совпадений префиксов высокая
- Отключайте prefix caching (
--no-enable-prefix-caching) для разнообразных prompt'ов
Прогнозы AIConfigurator по умолчанию исходят из отсутствия prefix caching. Включите его после развёртывания, если ваша нагрузка от этого выигрывает.
Поддерживаемые конфигурации
Backend'ы и версии
Полный список комбинаций model/system/backend/version, поддерживаемых как в aggregated, так и в disaggregated режимах, см. в support matrix. Исходные данные доступны как CSV-файлы для каждой системы, которые автоматически генерируются и тестируются, чтобы обеспечить точность для всех поддерживаемых конфигураций.
Проверить, поддерживается ли комбинация system / framework version, можно и через команду aiconfigurator cli support. Например:
aiconfigurator cli support --model Qwen/Qwen3-32B-FP8 --system h100_sxm --backend-version 1.2.0rc5
Типовые сценарии использования
# Жёсткие SLA по задержке (чат в реальном времени)
aiconfigurator cli default \
--model meta-llama/Llama-3.1-70B \
--total-gpus 16 \
--system h200_sxm \
--backend vllm \
--backend-version 0.12.0 \
--ttft 200 --tpot 8
# Высокий throughput (пакетная обработка)
aiconfigurator cli default \
--model Qwen/Qwen3-32B-FP8 \
--total-gpus 32 \
--system h200_sxm \
--backend trtllm \
--ttft 2000 --tpot 50
# Ограничение по request latency (end-to-end SLA)
aiconfigurator cli default \
--model Qwen/Qwen3-32B-FP8 \
--total-gpus 16 \
--system h200_sxm \
--backend vllm \
--backend-version 0.12.0 \
--request-latency 12000 \
--isl 4000 --osl 500
Дополнительные опции
# Веб-интерфейс для интерактивного исследования
pip3 install aiconfigurator[webapp]
aiconfigurator webapp # Visit http://127.0.0.1:7860
# Быстрая генерация конфигурации (без перебора параметров)
aiconfigurator cli generate \
--model Qwen/Qwen3-32B-FP8 \
--total-gpus 8 \
--system h200_sxm \
--backend vllm
# Проверка поддержки model/system
aiconfigurator cli support \
--model Qwen/Qwen3-32B-FP8 \
--system h200_sxm \
--backend vllm
Устранение неполадок
Проблемы AIConfigurator
Модель не найдена: используйте полный путь HuggingFace (например, Qwen/Qwen3-32B-FP8, а не QWEN3_32B)
Несовпадение версии backend'а: проверьте поддерживаемые версии через aiconfigurator cli support --model <model> --system <system> --backend <backend>
Проблемы развёртывания
Pods падают с "Permission denied" в каталоге кэша:
- Монтируйте PVC в
/opt/models, а не в/root/.cache/huggingface - Задайте переменную окружения
HF_HOME=/opt/models - Убедитесь, что у PVC есть режим доступа
ReadWriteMany
Worker'ы застряли в CrashLoopBackOff:
- Проверьте логи:
kubectl logs <pod-name> --previous - Убедитесь, что задан
sharedMemory.size(16Gi для vLLM, 80Gi для TRT-LLM) - Проверьте, что secret с токеном HuggingFace существует и назван правильно
Скачивание модели медленное при каждом рестарте:
- Добавьте PVC для кэширования модели (см. пример развёртывания выше)
- Проверьте, что на worker'ах настроены
volumeMountsиHF_HOME
Ошибки "Context stopped or killed" (только disaggregated):
- Проверьте, что сервисы discovery и event-plane доступны для выбранных backend'ов. Передача KV cache использует data path NIXL/RDMA; etcd или NATS нужны только тогда, когда ваше развёртывание выбирает эти discovery- или event-backend'ы.
- См. Dynamo Kubernetes Guide для настройки платформы
Проблемы производительности
Ошибки OOM: уменьшите --max-num-seqs или увеличьте tensor parallelism
Производительность ниже прогнозов:
- Проверьте, что warmup requests достаточно (рекомендуется 40+)
- Проверьте, нет ли конкурирующих нагрузок в кластере
- Убедитесь, что доля памяти под KV cache оптимизирована
- Запускайте бенчмарки изнутри кластера, чтобы исключить сетевые задержки
Disaggregated TTFT чрезвычайно высокий (10+ секунд): Почти всегда это вызвано отсутствием конфигурации RDMA. Без RDMA передача KV cache откатывается на TCP и становится серьёзным узким местом.
Чтобы диагностировать:
# Check if RDMA resources are allocated
kubectl get pod <worker-pod> -o yaml | grep -A5 "resources:"
# Check UCX transport in logs
kubectl logs <worker-pod> | grep -i "UCX\|transport"
Чтобы исправить:
- Убедитесь, что в кластере установлен RDMA device plugin
- Добавьте requests ресурсов
rdma/ibв worker pod'ы - Добавьте capability
IPC_LOCKв security context - Добавьте переменные окружения UCX (см. раздел Disaggregated Deployment)
Disaggregated работает, но throughput ниже aggregated: Для сбалансированных нагрузок (отношение ISL/OSL между 2:1 и 10:1) aggregated часто лучше. Disaggregated особенно хорош для:
- Очень длинных входов (ISL > 8000) с короткими выходами
- Нагрузок, которым нужно независимое масштабирование prefill/decode