dynamic_batching_triton

Skill para configurar y optimizar el dynamic batching nativo de NVIDIA Triton Inference Server, agrupando requests de inferencia facial, liveness y OCR en batches óptimos para maximizar el throughput GPU. A diferencia del batching genérico a nivel aplicación, esta skill se centra en la configuración específica de Triton y sus parámetros de scheduling para el pipeline de verificación KYC.

When to use

Usar esta skill cuando el model_server_agent necesite configurar, tunear o diagnosticar el dynamic batching dentro de Triton Inference Server. Aplica al desplegar nuevos modelos en Triton, optimizar latencia vs throughput, o resolver problemas de scheduling en modelos del pipeline KYC. Esta skill es complementaria a triton_inference_server (que cubre el servidor completo) y separada de dynamic_batching genérico.

Instructions

1. Habilitar dynamic batching en el model config de Triton para cada modelo del pipeline:

   # model_repository/arcface/config.pbtxt
   name: "arcface"
   platform: "onnxruntime_onnx"
   max_batch_size: 32
   dynamic_batching {
     preferred_batch_size: [8, 16, 32]
     max_queue_delay_microseconds: 100000  # 100ms max wait
   }
   input [{
     name: "input"
     data_type: TYPE_FP32
     dims: [3, 112, 112]
   }]
   

2. Configurar parámetros de batching diferenciados por modelo según su perfil de latencia:

   # Liveness model - latencia crítica, batches pequeños
   dynamic_batching {
     preferred_batch_size: [4, 8]
     max_queue_delay_microseconds: 50000  # 50ms - más agresivo
   }
   
   # OCR model - tolerante a latencia, batches grandes
   dynamic_batching {
     preferred_batch_size: [16, 32, 64]
     max_queue_delay_microseconds: 200000  # 200ms
   }
   

3. Configurar prioridades de scheduling para que liveness (crítico en UX) tenga prioridad sobre OCR:

   dynamic_batching {
     priority_levels: 3
     default_priority_level: 2
     default_queue_policy {
       timeout_action: REJECT
       default_timeout_microseconds: 500000
     }
   }
   

4. Habilitar métricas de batching en Triton para monitorizar la efectividad:

   # Arrancar Triton con métricas habilitadas
   tritonserver --model-repository=/models \
     --metrics-port=8002 \
     --allow-metrics=true \
     --metrics-interval-ms=1000
   

5. Monitorizar métricas clave de batching via Prometheus endpoint:

   nv_inference_request_success       # Requests exitosas
   nv_inference_queue_duration_us     # Tiempo en cola
   nv_inference_compute_infer_duration_us  # Tiempo de inferencia
   nv_inference_exec_count            # Batches ejecutados
   nv_inference_request_duration_us   # Duración total
   

6. Tunear el max_queue_delay basándose en el SLA de 8 segundos totales del pipeline:

   # Budget de latencia por modelo dentro del SLA de 8s
   LATENCY_BUDGET_MS = {
       "liveness": 500,      # Máx 500ms
       "arcface": 300,       # Máx 300ms
       "paddleocr": 1000,    # Máx 1000ms
       "antifraud": 200,     # Máx 200ms
   }
   # max_queue_delay = budget * 0.3 (30% del budget para queueing)
   

7. Configurar sequence batching para modelos que procesan múltiples frames (liveness con secuencia de frames):

   sequence_batching {
     max_sequence_idle_microseconds: 5000000
     control_input [{
       name: "START"
       control [{ kind: CONTROL_SEQUENCE_START }]
     }]
   }
   

Notes

• El dynamic batching de Triton opera a nivel de inference server, no de aplicación. Esto es más eficiente que batching manual porque Triton conoce el estado exacto de la GPU y puede optimizar la ejecución de kernels CUDA.
• El parámetro max_queue_delay es el trade-off principal: valores altos mejoran throughput pero aumentan latencia. Para el pipeline KYC con SLA de 8s, mantener delays conservadores en modelos de la ruta crítica (liveness, face_match).
• Sequence batching es necesario para el módulo de liveness que analiza múltiples frames consecutivos; no confundir con dynamic batching que agrupa requests independientes.