დიდი ენობრივი მოდელების ოპტიმიზაცია: ინფერენციის ფაზების გამოწვევები

TNG-ში ჩვენ ვახორციელებთ მრავალი დიდი ენობრივი მოდელის (LLM) თვით-ჰოსტინგს ჩვენს 24 H100 GPU-ს კლასტერზე. ის მხარს უჭერს 50 სხვადასხვა აპლიკაციას, საათში ამუშავებს 5000-ზე მეტ ინფერენციას და ყოველდღიურად აგენერირებს ათ მილიონზე მეტ ტოკენს. LLM-ების უმეტესობა ტექსტს ტოკენ-ტოკენით აგენერირებს, რაც უზრუნველყოფს, რომ ყოველი ახალი ტოკენი გამოითვლება ყველა წინამორბედი ტოკენის საფუძველზე (მოდელის ამ თვისებას ავტორეგრესული ეწოდება). პირველი გამომავალი ტოკენი დამოკიდებულია ყველა საწყის ტოკენზე (prompt tokens), ხოლო მეორე გამომავალი ტოკენი უკვე დამოკიდებულია ყველა საწყის ტოკენზე პლუს პირველ გამომავალ ტოკენზე და ასე შემდეგ. შესაბამისად, ტოკენების გენერაცია ცალკეული მოთხოვნის დონეზე პარალელიზებას ვერ ახდენს. LLM-ებში, სადაც ყურადღების მექანიზმებია (attention mechanisms), ახალი ტოკენის გამოთვლა მოითხოვს key, value და query ვექტორების გამოთვლას თითოეული წინამორბედი ტოკენისთვის. საბედნიეროდ, ზოგიერთი კონკრეტული გამოთვლის შედეგების ხელახლა გამოყენება შესაძლებელია შემდგომი ტოკენებისთვის. ამ კონცეფციას key-value (KV) ქეში ეწოდება. ყოველ დამატებით გამომავალ ტოკენზე, მხოლოდ ერთი ახალი key და value ვექტორების ნაკრები უნდა გამოითვალოს და დაემატოს KV ქეშს. თუმცა, პირველი გამომავალი ტოკენისთვის, ჩვენ ვიწყებთ თავდაპირველად ცარიელი KV ქეშით და უნდა გამოვთვალოთ იმდენი key და value ვექტორების ნაკრები, რამდენიც არის ტოკენი შემავალ საწყის ტექსტში (input prompt). საბედნიეროდ, და ნებისმიერი შემდგომი ტოკენის გენერაციისგან განსხვავებით, ყველა შემავალი ტოკენი თავიდანვე ცნობილია და ჩვენ შეგვიძლია მათი შესაბამისი key და value ვექტორების გამოთვლის პარალელიზება. ეს განსხვავება განაპირობებს პრეფილის (პირველი გამომავალი ტოკენის გამოთვლა) და დეკოდირების ფაზის (ნებისმიერი შემდგომი გამომავალი ტოკენის გამოთვლა) გამიჯვნას. პრეფილის ფაზაში, ყველა შემავალი ტოკენის გამოთვლა შესაძლებელია პარალელურად შესრულდეს, ხოლო დეკოდირების ფაზაში, პარალელიზაცია შეუძლებელია ინდივიდუალური მოთხოვნების დონეზე. განსხვავება პრეფილისა და დეკოდირების ფაზებს შორის ასევე აისახება ტექსტის გენერაციის ორ ძირითად მეტრიკაში: პირველი ტოკენის დრო (Time to first token) და დრო თითო გამომავალ ტოკენზე (time per output token). პირველი ტოკენის დრო განისაზღვრება პრეფილის ფაზის შეყოვნებით, ხოლო დრო თითო გამომავალ ტოკენზე არის ერთი დეკოდირების ეტაპის შეყოვნება. მიუხედავად იმისა, რომ პრეფილის ფაზაც მხოლოდ ერთ ტოკენს აგენერირებს, ის გაცილებით მეტ დროს მოითხოვს, ვიდრე ერთი დეკოდირების ეტაპი, რადგან ყველა შემავალი ტოკენი უნდა დამუშავდეს. მეორე მხრივ, პრეფილის ფაზა გაცილებით სწრაფია შემავალი ტოკენების რაოდენობის მიხედვით, ვიდრე დეკოდირების ფაზა იგივე რაოდენობის გამომავალი ტოკენებისთვის (ეს განსხვავებაა იმის მიზეზი, თუ რატომ იხდიან კომერციული LLM API-ები შემავალ ტოკენებს გაცილებით დაბალ ფასად, ვიდრე გამომავალ ტოკენებს). ორივე შეყოვნება მნიშვნელოვანი მეტრიკაა ინტერაქტიული აპლიკაციებისთვის, როგორიცაა ჩატბოტები. თუ მომხმარებლებს 5 წამზე მეტ ხანს უწევთ ლოდინი პასუხის სანახავად, მათ შეიძლება იფიქრონ, რომ აპლიკაცია გაფუჭებულია და დატოვონ იგი. ანალოგიურად, თუ ტექსტის გენერაცია წამში 1 ტოკენის სიჩქარით მიმდინარეობს, ისინი არ იქნებიან საკმარისად მომთმენნი, რომ დაელოდონ მის დასრულებას. ინტერაქტიული აპლიკაციების ტიპიური შეყოვნების სამიზნეებია 100-300 მილიწამი თითო გამომავალ ტოკენზე (ანუ ტოკენების გენერაციის სიჩქარე 3-10 ტოკენი წამში, სულ მცირე, კითხვის სიჩქარესთან ახლოს, რაც იდეალურად იძლევა გამომავალი ტექსტის სწრაფად გადახედვის საშუალებას მისი გენერირების პროცესში), და პირველი ტოკენის დრო 3 წამი ან ნაკლები. ორივე ეს შეყოვნების სამიზნე საკმაოდ რთული მისაღწევია, რაც დამოკიდებულია მოდელის ზომაზე, აპარატურაზე, საწყისი ტექსტის სიგრძეზე და ერთდროულ დატვირთვაზე. სხვა, არაინტერაქტიულ გამოყენების შემთხვევებში, შესაძლოა, ინდივიდუალური მოთხოვნების შეყოვნება არ იყოს საინტერესო, არამედ მხოლოდ ტოკენების საერთო გამტარუნარიანობა (ტოკენები წამში, შეჯამებული ყველა ერთდროული მოთხოვნის მიხედვით). ეს შეიძლება აქტუალური იყოს, როდესაც გსურთ წიგნების თარგმანების გენერირება, ან კოდის ფაილების შეჯამება დიდ საცავში (repository). როგორც მოგვიანებით განყოფილებაში ვნახავთ, ზოგადად, არსებობს კომპრომისი მთლიანი გამტარუნარიანობის მაქსიმიზაციასა და თითოეული ინდივიდუალური მოთხოვნის შეყოვნების მინიმიზაციას შორის. ყველა შემავალი ტოკენის პარალელიზებული გამოთვლის გამო, პრეფილის ფაზა ძალიან GPU-ს გამოთვლითი სიმძლავრის ინტენსიურია. ამის საპირისპიროდ, ინდივიდუალური გამომავალი ტოკენის დეკოდირების ეტაპი ძალიან მცირე გამოთვლით ძალას იყენებს; აქ სიჩქარე, როგორც წესი, შეზღუდულია GPU მეხსიერების გამტარუნარიანობით, ანუ რამდენად სწრაფად შეიძლება მოდელის წონების (weights) და აქტივაციების (აქტივაციები, მათ შორის key და value ვექტორები) ჩატვირთვა და მათზე წვდომა GPU მეხსიერებიდან. ზოგადად, ტოკენების გამტარუნარიანობა შეიძლება გაიზარდოს მანამ, სანამ GPU-ს გამოყენება (გამოთვლითი სიმძლავრის თვალსაზრისით) არ გაჯერდება. პრეფილის ფაზაში, ერთი მოთხოვნა გრძელი საწყისი ტექსტით (prompt) უკვე შეუძლია მაქსიმალური GPU გამოყენების მიღწევა. დეკოდირების ფაზაში, GPU-ს გამოყენება შეიძლება გაიზარდოს მრავალი მოთხოვნის ბატჩური დამუშავებით (batch processing). შესაბამისად, როდესაც გამოსახავთ ტოკენების გამტარუნარიანობას ერთდროული მოთხოვნების რაოდენობის ფუნქციად, ხედავთ გამტარუნარიანობის თითქმის ხაზოვან ზრდას დაბალი ერთდროულობის დროს, რადგან ეს მეხსიერებით შეზღუდული რეჟიმი სარგებლობს უფრო დიდი ბატჩის ზომებით. მას შემდეგ, რაც GPU-ს გამოყენება გაჯერდება და გამოთვლითი სიმძლავრით შეზღუდული რეჟიმი დაიწყება, გამტარუნარიანობა უცვლელი რჩება ერთდროულობის ზრდის მიუხედავად. ახლა განვიხილავთ, თუ როგორ ამუშავებს ინფერენციის ძრავა (inference engine) რამდენიმე მოთხოვნას, რომლებიც მოკლე დროის ინტერვალში შემოდის. ორივე