Accélérer l'inférence d'un modèle de garde encodeur : TensorRT, Triton, vLLM, Ray Serve

L'article décrit une tentative d'accélérer un modèle de garde qui se situe entre un LLM et l'utilisateur, vérifiant la présence de contenu dangereux. Le modèle est un encodeur PII zero-shot : il prend des types d'entités en entrée textuelle ainsi que le document, extrayant les entités et classifiant la sécurité en une seule passe forward. En raison de son architecture, il présente sept contraintes d'ingénierie : forme d'entrée variable, sortie non tensorielle nécessitant un décodage de spans sur CPU, opérations spécifiques comme gather et scoring bilinéaire, attention potentiellement non standard, coût du lot déterminé par l'élément le plus long, infrastructure de service optimisée pour les LLM autorégressifs, et importance de la latence de queue (P95, P99) car le garde est appelé deux fois par tour de dialogue. L'expérience compare cinq outils : le runtime TensorRT, NVIDIA Triton, vLLM, Ray Serve et un backbone Flash DeBERTa, avec des baselines utilisant LitServe. La piste runtime avec TensorRT a utilisé un profil de charge court (un worker, 50 utilisateurs, 60 secondes), tandis que les pistes de service ont utilisé un profil plus long (quatre workers, 100 utilisateurs, 15 minutes), donc les chiffres ne sont comparables que au sein de chaque piste. La variante TensorRT FP16 atteint 130,72 RPS contre 106,49 RPS pour PyTorch FP16, soit une amélioration de 23 %. Les tentatives de quantification INT8 ont échoué en raison du manque de prise en charge des opérations personnalisées, entraînant un RPS très faible et une latence élevée.