Acelerando la inferencia de un modelo guardián encoder: TensorRT, Triton, vLLM, Ray Serve
NVIDIA
vLLM
Ray
El artículo compara herramientas para acelerar un modelo guardián encoder PII de cero disparos que verifica la entrada y salida de una aplicación LLM. El autor prueba TensorRT, NVIDIA Triton, vLLM, Ray Serve y un backbone Flash DeBERTa, midiendo RPS y latencia. TensorRT FP16 da un impulso del 23% sobre PyTorch FP16, pero la cuantización INT8 falla debido a operaciones personalizadas.
El artículo describe un intento de acelerar un modelo de guardia que se sitúa entre un LLM y el usuario, comprobando si hay contenido peligroso. El modelo es un codificador PII de disparo cero: toma los tipos de entidad como entrada de texto junto con el documento, extrayendo entidades y clasificando la seguridad en una sola pasada hacia adelante. Debido a su arquitectura, plantea siete restricciones de ingeniería: forma de entrada variable, salida no tensorial que requiere decodificación de span en CPU, operaciones específicas como gather y puntuación bilineal, posible atención no estándar, costo de lote determinado por el elemento más largo, infraestructura de servicio optimizada para LLM autorregresivos, y la importancia de la latencia de cola (P95, P99) porque la guardia se llama dos veces por turno de diálogo. El experimento compara cinco herramientas: runtime de TensorRT, NVIDIA Triton, vLLM, Ray Serve y un backbone Flash DeBERTa, con líneas base usando LitServe. La pista de runtime con TensorRT usó un perfil de carga corto (un trabajador, 50 usuarios, 60 segundos), mientras que las pistas de servicio usaron un perfil más largo (cuatro trabajadores, 100 usuarios, 15 minutos), por lo que los números solo son comparables dentro de cada pista. La variante TensorRT FP16 logra 130.72 RPS frente a 106.49 RPS para PyTorch FP16, una mejora del 23%. Los intentos de cuantificación INT8 fallaron debido a la falta de soporte para operaciones personalizadas, resultando en RPS muy bajos y alta latencia.
Fuente: Habr — хаб ML —
original
