მე გაჩვენებთ, როგორ გააკეთოთ ეს მოხერხებულ Hugging Face Space-ში. შედეგების გამოყენება შეგიძლიათ ინფერენსის ენდპოინტზე ან იგივე აპარატურის სხვა ასლზე. იმისათვის, რომ უკეთ გაიგოთ პროფაილირების საჭიროება, მოდით, ჯერ განვიხილოთ ზოგადი ინფორმაცია. დიდი ენობრივი მოდელები (LLM-ები) ფუნდამენტურად არაეფექტურია. დეკოდერების მუშაობის პრინციპიდან გამომდინარე, გენერაცია მოითხოვს ახალ ფორვარდულ გატარებას (forward pass) ყოველი დეკოდირებული ტოკენისთვის. რადგან LLM-ების ზომა იზრდება და საწარმოებში მათი გამოყენება ფართოვდება, AI ინდუსტრიამ დიდი სამუშაო გასწია ახალი ოპტიმიზაციებისა და მუშაობის გაუმჯობესების ტექნიკების შესაქმნელად. LLM-ების სერვირების მრავალ ასპექტში ათობით გაუმჯობესებაა. ჩვენ ვიხილეთ Flash Attention, Paged Attention, ნაკადური პასუხები, გაუმჯობესებები ბეჩინგში (batching), სპეკულაცია, მრავალი სახის კვანტიზაცია, ვებ სერვერების გაუმჯობესება, უფრო სწრაფი ენების დანერგვა (ბოდიში, Python 🐍) და მრავალი სხვა. ასევე არსებობს გამოყენების შემთხვევების გაუმჯობესებები, როგორიცაა სტრუქტურირებული გენერაცია და ვატერმარკინგი, რომლებმაც თავისი ადგილი დაიკავეს LLM ინფერენსის სამყაროში. პრობლემა ისაა, რომ სწრაფი და ეფექტური იმპლემენტაციები სულ უფრო მეტ ვიწრო სპეციალიზაციის უნარებს მოითხოვს [1]. Text Generation Inference (TGI) არის Hugging Face-ის მაღალეფექტური LLM ინფერენსის სერვერი, რომელიც შექმნილია LLM-ების განთავსებისა და მოხმარების გასაუმჯობესებლად უახლესი ტექნიკების დასანერგად და განვითარებისთვის. Hugging Face-ის ღია კოდის პარტნიორობის წყალობით, უმეტესი (თუ არა ყველა) ძირითადი ღია კოდის LLM ხელმისაწვდომია TGI-ში გამოშვების დღესვე. ხშირად მომხმარებლებს ძალიან განსხვავებული მოთხოვნილებები აქვთ, მათი გამოყენების შემთხვევის მიხედვით. განვიხილოთ მოთხოვნა და გენერაცია RAG გამოყენების შემთხვევაში: RAG-ში მნიშვნელოვანია სწორი დოკუმენტის ქონა ხარისხიანი პასუხის მისაღებად; ამ შანსს ზრდით N-ის გაზრდით, რაც მეტ დოკუმენტს მოიცავს. ეს ნიშნავს, რომ RAG ხშირად შეეცდება მაქსიმალურად გამოიყენოს LLM-ის კონტექსტის ფანჯარა დავალების შესრულების გასაუმჯობესებლად. ამის საპირისპიროდ, დაფიქრდით საბაზისო ჩატზე. ტიპურ ჩატის სცენარებს RAG-თან შედარებით გაცილებით ნაკლები ტოკენი აქვთ: იმის გათვალისწინებით, რომ ასეთი განსხვავებული სცენარები გვაქვს, უნდა დავრწმუნდეთ, რომ ჩვენი LLM სერვერი შესაბამისად არის კონფიგურირებული, იმის მიხედვით, თუ რომელია უფრო აქტუალური. Hugging Face-ს აქვს ბენჩმარკინგის ინსტრუმენტი, რომელიც დაგვეხმარება იმის გარკვევაში, თუ რომელი კონფიგურაციაა ყველაზე მიზანშეწონილი, და მე აგიხსნით, როგორ შეგიძლიათ ეს გააკეთოთ Hugging Face Space-ში. მოდით, დავრწმუნდეთ, რომ რამდენიმე ძირითადი კონცეფციის საერთო გაგება გვაქვს, სანამ ინსტრუმენტში ჩავუღრმავდებით. ლატენტურობა (Latency) რთული საზომია, რადგან ის სრულ სურათს არ გიჩვენებთ. შეიძლება გქონდეთ გრძელი ან მოკლე გენერაცია, რაც ბევრს არ გეტყვით თქვენი სერვერის რეალური მუშაობის შესახებ. მნიშვნელოვანია გვესმოდეს, რომ გამტარუნარიანობა (Throughput) და ლატენტურობა (Latency) ორთოგონალური გაზომვებია, და იმის მიხედვით, თუ როგორ დავაკონფიგურირებთ ჩვენს სერვერს, შეგვიძლია ერთი ან მეორე ოპტიმიზაცია გავაკეთოთ. ჩვენი ბენჩმარკინგის ინსტრუმენტი დაგვეხმარება კომპრომისის გაგებაში მონაცემთა ვიზუალიზაციის საშუალებით. აქ მოცემულია LLM-ის მიერ ტექსტის გენერაციის გამარტივებული ხედვა. მოდელი (ტიპიურად) ყოველი ფორვარდული გატარებისთვის ერთ ტოკენს აგენერირებს. ნარინჯისფრად ნაჩვენები წინასწარი შევსების (pre-filling) ეტაპისთვის, სრული მოთხოვნა (რა არის.. აშშ-ის?) ეგზავნება მოდელს და გენერირდება ერთი ტოკენი (ვაშინგტონი). ლურჯად ნაჩვენები დეკოდირების (decoding) ეტაპზე, გენერირებული ტოკენი ერთვის წინა შეყვანას და შემდეგ ეს (... აშშ-ის დედაქალაქი? ვაშინგტონი) ეგზავნება მოდელს კიდევ ერთი ფორვარდული გატარებისთვის. სანამ მოდელი არ შექმნის თანმიმდევრობის დასრულების ტოკენს (), ეს პროცესი გაგრძელდება: შეყვანის გაგზავნა მოდელის გავლით, ტოკენის გენერირება, ტოკენის შეყვანაზე დამატება. მე მხოლოდ მოკლე მაგალითი მოვიყვანე ილუსტრაციისთვის, მაგრამ გაითვალისწინეთ, რომ წინასწარი შევსება მხოლოდ 1 ფორვარდულ გატარებას საჭიროებს მოდელის გავლით, ხოლო დეკოდირებას შეიძლება დასჭირდეს ასობით ან მეტი. ჩვენს მოკლე მაგალითშიც კი ვხედავთ უფრო მეტ ლურჯ ისარს, ვიდრე ნარინჯისფერს. ახლა ჩვენ შეგვიძლია დავინახოთ, რატომ სჭირდება LLM-დან გამოსავლის მიღებას ამდენი დრო! დეკოდირება, როგორც წესი, ის ეტაპია, რომელზეც მეტ დროს ვხარჯავთ მრავალი გატარების გამო. ჩვენ ყველას გვინახავს ინსტრუმენტების, ახალი ალგორითმების ან მოდელების შედარებები, რომლებიც აჩვენებენ გამტარუნარიანობას. მიუხედავად იმისა, რომ ეს LLM ინფერენსის ისტორიის მნიშვნელოვანი ნაწილია, მას აკლია ზოგიერთი ძირითადი ინფორმაცია. მინიმუმ (რა თქმა უნდა, შეგიძლიათ უფრო სიღრმისეულად შეისწავლოთ), ჩვენ უნდა ვიცოდეთ გამტარუნარიანობა და ლატენტურობა, რათა კარგი გადაწყვეტილებები მივიღოთ. TGI ბენჩმარკინგის ინსტრუმენტის ერთ-ერთი მთავარი უპირატესობა ის არის, რომ მას აქვს ეს შესაძლებლობა. კიდევ ერთი მნიშვნელოვანი მოსაზრებაა, თუ რა გამოცდილების ქონა გსურთ მომხმარებლისთვის. უფრო მეტად ზრუნავთ ბევრი მომხმარებლის მომსახურებაზე, თუ გსურთ, რომ თითოეულ მომხმარებელს, სისტემასთან ჩართვის შემდეგ, სწრაფი პასუხი ჰქონდეს? გსურთ გქონდეთ უკეთესი პირველი ტოკენის მიღების დრო (Time To First Token – TTFT) თუ გსურთ, რომ ტოკენები ელვის სისწრაფით გამოჩნდეს პირველი ტოკენის მიღების შემდეგაც კი, მაშინაც კი, თუ პირველი დაგვიანებულია? აი, რამდენიმე იდეა, თუ როგორ შეიძლება ეს განვითარდეს. გახსოვდეთ, არ არსებობს უფასო სადილი. მაგრამ საკმარისი GPU-ებით და სწორი კონფიგურაციით, შეგიძლიათ გქონდეთ თითქმის ნებისმიერი კერძი, რაც გსურთ. ბენჩმარკინგის ინსტრუმენტი დაინსტალირებულია TGI-თან ერთად, მაგრამ მის გასაშვებად საჭიროა სერვერზე წვდომა. ამის გათვალისწინებით, მე მოგაწოდეთ ეს Hugging Face Space (derek-thomas/tgi-benchmark-space), რათა გააერთიანოთ TGI docker image (დამაგრებული უახლეს ვერსიაზე).