एन्कोडर गार्ड मॉडल के इन्फेरेंस को तेज़ करना: TensorRT, Triton, vLLM, Ray Serve
NVIDIA
vLLM
Ray
यह लेख एक ज़ीरो-शॉट PII-एन्कोडर गार्ड मॉडल को तेज़ करने के लिए उपकरणों की तुलना करता है, जो LLM ऐप के इनपुट और आउटपुट की जाँच करता है। लेखक TensorRT, NVIDIA Triton, vLLM, Ray Serve, और एक Flash DeBERTa बैकबोन का परीक्षण करता है, जिसमें RPS और लेटेंसी मापी जाती है। TensorRT FP16 PyTorch FP16 की तुलना में 23% का सुधार देता है, लेकिन कस्टम ऑपरेशनों के कारण INT8 क्वांटाइज़ेशन विफल हो जाता है।
यह लेख एक गार्ड मॉडल को तेज करने के प्रयास का वर्णन करता है जो एलएलएम और उपयोगकर्ता के बीच बैठकर खतरनाक सामग्री की जाँच करता है। यह मॉडल एक ज़ीरो-शॉट पीआईआई-एनकोडर है: यह इकाई प्रकारों को टेक्स्ट इनपुट के रूप में दस्तावेज़ के साथ लेता है, एक ही फॉरवर्ड पास में इकाइयों को निकालता है और सुरक्षा को वर्गीकृत करता है। अपनी वास्तुकला के कारण, यह सात इंजीनियरिंग बाधाएँ प्रस्तुत करता है: परिवर्तनीय इनपुट आकार, गैर-टेंसर आउटपुट जिसके लिए सीपीयू स्पैन डिकोडिंग की आवश्यकता होती है, गैदर और बिलीनियर स्कोरिंग जैसे विशिष्ट संचालन, संभावित रूप से गैर-मानक ध्यान, बैच लागत सबसे लंबे तत्व द्वारा निर्धारित होती है, ऑटोरेग्रेसिव एलएलएम के लिए अनुकूलित सर्विंग इंफ्रास्ट्रक्चर, और टेल लेटेंसी (पी95, पी99) का महत्व क्योंकि गार्ड को प्रति संवाद टर्न दो बार बुलाया जाता है। प्रयोग पाँच उपकरणों की तुलना करता है: TensorRT रनटाइम, NVIDIA Triton, vLLM, Ray Serve, और Flash DeBERTa बैकबोन, बेसलाइन के रूप में LitServe के साथ। TensorRT के साथ रनटाइम ट्रैक ने एक छोटा लोड प्रोफाइल (एक वर्कर, 50 उपयोगकर्ता, 60 सेकंड) इस्तेमाल किया, जबकि सर्विंग ट्रैक ने एक लंबा प्रोफाइल (चार वर्कर, 100 उपयोगकर्ता, 15 मिनट) इस्तेमाल किया, इसलिए संख्याएँ केवल प्रत्येक ट्रैक के भीतर तुलनीय हैं। TensorRT FP16 वेरिएंट 130.72 आरपीएस प्राप्त करता है जबकि PyTorch FP16 के लिए 106.49 आरपीएस, 23% सुधार। INT8 क्वांटाइजेशन प्रयास कस्टम संचालन के लिए समर्थन की कमी के कारण विफल रहे, जिसके परिणामस्वरूप बहुत कम आरपीएस और उच्च विलंबता हुई।
स्रोत: Habr — хаб ML —
मूल