エンコーダーガードモデルの推論高速化:TensorRT、Triton、vLLM、Ray Serve
NVIDIA
vLLM
Ray
本記事では、LLMアプリの入力と出力をチェックするゼロショットPIIエンコーダーガードモデルの高速化ツールを比較します。著者はTensorRT、NVIDIA Triton、vLLM、Ray Serve、およびFlash DeBERTaバックボーンをテストし、RPSとレイテンシを測定します。TensorRT FP16はPyTorch FP16と比較して23%の向上を示しますが、INT8量子化はカスタム操作のために失敗します。
この記事では、LLMとユーザーの間に位置し、危険なコンテンツをチェックするガードモデルの高速化の試みについて説明しています。このモデルはゼロショットPIIエンコーダーで、エンティティタイプをテキスト入力としてドキュメントとともに受け取り、エンティティの抽出と安全性の分類を1回のフォワードパスで行います。そのアーキテクチャにより、7つの工学的制約があります:可変な入力形状、テンソルではない出力(CPUでのスパン復号が必要)、gather操作や双線形スコアリングなどの特定の演算、非標準的なアテンションの可能性、バッチコストが最も長い要素によって決まること、自己回帰型LLM向けに最適化されたサービス基盤、そしてテールレイテンシ(P95、P99)の重要性(ガードが対話のターンごとに2回呼び出されるため)。実験では、TensorRTランタイム、NVIDIA Triton、vLLM、Ray Serve、Flash DeBERTaバックボーンの5つのツールを比較し、ベースラインにはLitServeを使用しています。TensorRTを使用したランタイムトラックでは短い負荷プロファイル(ワーカー1、ユーザー50、60秒)を使用し、サービストラックでは長いプロファイル(ワーカー4、ユーザー100、15分)を使用したため、数値は各トラック内でのみ比較可能です。TensorRT FP16バリアントは毎秒130.72リクエスト(RPS)を達成し、PyTorch FP16の毎秒106.49リクエストに対して23%の改善です。INT8量子化の試みは、カスタム演算のサポート不足により失敗し、非常に低い毎秒リクエスト数と高いレイテンシをもたらしました。
出典: Habr — хаб ML —
原文
