გაჩვენებთ, თუ როგორ უნდა გააკეთოთ ეს Hugging Face Space-ის მოხერხებულ გარემოში. შედეგების გამოყენება შესაძლებელია Inference Endpoint-ზე ან იგივე აპარატურის სხვა ასლზე. პროფილის შექმნის საჭიროების უკეთ გასაგებად, მოდით, ჯერ ზოგადი ინფორმაცია განვიხილოთ. დიდი ენობრივი მოდელები (LLM) ფუნდამენტურად არაეფექტურია. დეკოდერების მუშაობის პრინციპიდან გამომდინარე, გენერაცია მოითხოვს ახალ „forward pass“-ს (წინ მიმართულებით გაშვება) ყოველი დეკოდირებული ტოკენისთვის. რაც უფრო იზრდება LLM-ების ზომა და მათი მიღების ტემპი საწარმოებში, ხელოვნური ინტელექტის ინდუსტრიამ დიდი სამუშაო ჩაატარა ახალი ოპტიმიზაციებისა და წარმადობის გაუმჯობესების ტექნიკების შესაქმნელად. LLM-ების სერვისის მრავალ ასპექტში ათობით გაუმჯობესება განხორციელდა. ჩვენ ვნახეთ Flash Attention, Paged Attention, სტრიმინგის რეჟიმის მქონე პასუხები, გაუმჯობესებები ბატჩინგში, სპეკულაცია, მრავალი სახის კვანტიზაცია, გაუმჯობესებები ვებ სერვერებში, უფრო სწრაფი ენების დანერგვა (ბოდიში, Python 🐍) და მრავალი სხვა. ასევე არსებობს გამოყენების შემთხვევების გაუმჯობესებები, როგორიცაა სტრუქტურირებული გენერაცია და წყლის ნიშნის დასმა (watermarking), რომლებსაც ახლა უკვე აქვთ თავისი ადგილი LLM ინფერენსის სამყაროში. პრობლემა ისაა, რომ სწრაფი და ეფექტური იმპლემენტაციები მოითხოვს უფრო და უფრო სპეციფიკურ უნარებს [1]. Text Generation Inference (TGI) არის Hugging Face-ის მაღალწარმადობიანი LLM ინფერენსის სერვერი, რომელიც შექმნილია LLM-ების დეპლოიმენტისა და მოხმარების გაუმჯობესების უახლესი ტექნიკების მისაღებად და განვითარებისთვის. Hugging Face-ის ღია კოდის პარტნიორობის წყალობით, LLM-ების უმეტესობა (თუ არა ყველა) TGI-ში ხელმისაწვდომია მათი გამოშვებისთანავე. ხშირად მომხმარებლებს განსხვავებული მოთხოვნები აქვთ მათი გამოყენების შემთხვევების მიხედვით. განვიხილოთ „prompt“ და გენერაცია RAG (Retrieval Augmented Generation) გამოყენების შემთხვევაში: RAG-ში მნიშვნელოვანია სწორი დოკუმენტის ქონა ხარისხიანი პასუხის მისაღებად; ამ შანსს ზრდით N-ის გაზრდით, რაც მეტ დოკუმენტს მოიცავს. ეს ნიშნავს, რომ RAG ხშირად შეეცდება მაქსიმალურად გამოიყენოს LLM-ის კონტექსტის ფანჯარა ამოცანის წარმადობის გასაზრდელად. ამის საპირისპიროდ, ვიფიქროთ მარტივ ჩატზე. ტიპურ ჩატის სცენარებში მნიშვნელოვნად ნაკლები ტოკენია, ვიდრე RAG-ში: იმის გათვალისწინებით, რომ ასეთი განსხვავებული სცენარები გვაქვს, უნდა დავრწმუნდეთ, რომ LLM სერვერი შესაბამისად დავაკონფიგურიროთ, იმის მიხედვით, თუ რომელი მათგანია უფრო აქტუალური. Hugging Face-ს აქვს ბენჩმარკინგის ინსტრუმენტი, რომელიც დაგვეხმარება იმის გარკვევაში, თუ რომელი კონფიგურაციაა ყველაზე მიზანშეწონილი, და მე აგიხსნით, თუ როგორ შეგიძლიათ ამის გაკეთება Hugging Face Space-ზე. მოდით, დავრწმუნდეთ, რომ რამდენიმე ძირითადი კონცეფცია საერთო გაგება გვაქვს, სანამ ინსტრუმენტში ჩავუღრმავდებით. ლატენტურობა რთული საზომია, რადგან ის სრულ სურათს არ გვაძლევს. შესაძლოა გქონდეთ გრძელი ან მოკლე გენერაცია, რაც ბევრს არ გეტყვით თქვენი სერვერის რეალურ წარმადობაზე. მნიშვნელოვანია გვესმოდეს, რომ გამტარუნარიანობა (Throughput) და ლატენტურობა ორთოგონალური გაზომვებია და, იმის მიხედვით, თუ როგორ დავაკონფიგურირებთ ჩვენს სერვერს, შეგვიძლია ერთი ან მეორის ოპტიმიზაცია. ჩვენი ბენჩმარკინგის ინსტრუმენტი დაგვეხმარება კომპრომისის გაგებაში მონაცემთა ვიზუალიზაციის საშუალებით. აქ მოცემულია LLM-ის მიერ ტექსტის გენერირების გამარტივებული ხედი. მოდელი (ჩვეულებრივ) აგენერირებს ერთ ტოკენს ყოველი „forward pass“-ისთვის. ნარინჯისფრად მონიშნულ წინასწარ შევსების ეტაპზე, სრული „prompt“ (რა არის... აშშ-ის?) ეგზავნება მოდელს და გენერირდება ერთი ტოკენი (ვაშინგტონი). ლურჯად მონიშნულ დეკოდირების ეტაპზე, გენერირებული ტოკენი ემატება წინა შეყვანას და შემდეგ ეს (...აშშ-ის დედაქალაქი? ვაშინგტონი) ისევ იგზავნება მოდელში კიდევ ერთი „forward pass“-ისთვის. სანამ მოდელი არ შექმნის თანმიმდევრობის დასასრულის ტოკენს (), ეს პროცესი გაგრძელდება: შეყვანის გაგზავნა მოდელში, ტოკენის გენერირება, ტოკენის დამატება შეყვანაზე. მე მხოლოდ მოკლე მაგალითი მოვიყვანე საილუსტრაციოდ, მაგრამ გაითვალისწინეთ, რომ წინასწარი შევსება მხოლოდ 1 „forward pass“-ს საჭიროებს მოდელში, ხოლო დეკოდირებას შეიძლება დასჭირდეს ასობით ან მეტი. ჩვენს მოკლე მაგალითშიც კი ვხედავთ უფრო მეტ ლურჯ ისარს, ვიდრე ნარინჯისფერს. ახლა უკვე ვხედავთ, თუ რატომ სჭირდება LLM-ს ამდენი დრო გამოსავლის მისაცემად! დეკოდირება, როგორც წესი, ის ეტაპია, რომელზეც მეტ დროს ვხარჯავთ მრავალი „pass“-ის გამო. ყველას გვინახავს ინსტრუმენტების, ახალი ალგორითმების ან მოდელების შედარებები, რომლებიც გამტარუნარიანობას აჩვენებენ. მიუხედავად იმისა, რომ ეს LLM ინფერენსის მნიშვნელოვანი ნაწილია, მას აკლია ძირითადი ინფორმაცია. მინიმუმ (რა თქმა უნდა, უფრო ღრმად ჩასვლაც შეიძლება) ჩვენ უნდა ვიცოდეთ, როგორია გამტარუნარიანობა და როგორია ლატენტურობა, რათა სწორი გადაწყვეტილებები მივიღოთ. TGI ბენჩმარკინგის ინსტრუმენტის ერთ-ერთი მთავარი უპირატესობა სწორედ ამ შესაძლებლობაში მდგომარეობს. კიდევ ერთი მნიშვნელოვანი მოსაზრებაა იმის გათვალისწინება, თუ რა გამოცდილება გსურთ მიიღოს მომხმარებელმა. უფრო მეტად გაინტერესებთ ბევრი მომხმარებლის მომსახურება, თუ გსურთ, რომ თითოეულ მომხმარებელს, სისტემასთან დაკავშირების შემდეგ, სწრაფი პასუხი ჰქონდეს? გსურთ გქონდეთ უკეთესი „პირველი ტოკენის მიღების დრო“ (TTFT) თუ გსურთ, რომ პირველი ტოკენის მიღების შემდეგ დანარჩენი ტოკენები ელვის სისწრაფით გამოჩნდნენ, თუნდაც პირველი დაგვიანებული იყოს? აი, რამდენიმე იდეა, თუ როგორ შეიძლება ეს განვითარდეს. გახსოვდეთ, არ არსებობს უფასო სადილი. მაგრამ საკმარისი GPU-ებითა და სწორი კონფიგურაციით, შეგიძლიათ მიიღოთ თითქმის ნებისმიერი შედეგი, რაც გსურთ. ბენჩმარკინგის ინსტრუმენტი TGI-სთან ერთად ინსტალირდება, მაგრამ მის გასაშვებად სერვერზე წვდომა გჭირდებათ. ამის გათვალისწინებით, მე შევქმენი ეს „space“ derek-thomas/tgi-benchmark-space, რათა გაერთიანდეს TGI docker image (დაპინული უახლეს ვერსიაზე).