Beschleunigung der Inferenz eines Encoder-Guard-Modells: TensorRT, Triton, vLLM, Ray Serve

Der Artikel beschreibt einen Versuch, ein Schutzmodell zu beschleunigen, das zwischen einem LLM und dem Benutzer sitzt und auf gefährliche Inhalte prüft. Das Modell ist ein Zero-Shot-PII-Encoder: Es nimmt Entitätstypen als Texteingabe zusammen mit dem Dokument entgegen, extrahiert Entitäten und klassifiziert die Sicherheit in einem einzigen Forward-Pass. Aufgrund seiner Architektur stellt es sieben technische Herausforderungen: variable Eingabeformen, nicht-tensorbasierte Ausgaben, die eine CPU-Spandekodierung erfordern, spezifische Operationen wie Gather und bilineares Scoring, potenziell nicht-standardmäßige Aufmerksamkeit, Stapelverarbeitungskosten, die durch das längste Element bestimmt werden, eine Serving-Infrastruktur, die für autoregressive LLMs optimiert ist, und die Bedeutung der Tail-Latenz (P95, P99), da das Schutzmodell pro Dialogrunde zweimal aufgerufen wird. Das Experiment vergleicht fünf Tools: TensorRT-Runtime, NVIDIA Triton, vLLM, Ray Serve und einen Flash-DeBERTa-Backbone, mit Baseline-Werten unter Verwendung von LitServe. Die Runtime-Track mit TensorRT verwendete ein kurzes Lastprofil (ein Worker, 50 Benutzer, 60 Sekunden), während die Serving-Tracks ein längeres Profil verwendeten (vier Worker, 100 Benutzer, 15 Minuten), sodass Zahlen nur innerhalb der jeweiligen Spur vergleichbar sind. Die TensorRT-FP16-Variante erreicht 130,72 RPS gegenüber 106,49 RPS für PyTorch FP16, eine Verbesserung von 23 %. INT8-Quantisierungsversuche schlugen fehl, da keine Unterstützung für benutzerdefinierte Operationen vorhanden war, was zu sehr niedrigen RPS und hoher Latenz führte.