ვინაიდან დეკოდირების ცალკეული ნაბიჯები გამოთვლითად ინტენსიური არ არის, გამტარობის გაზრდა შესაძლებელია მრავალი მოთხოვნის დეკოდირების დაჯგუფებით. თუმცა, პრეფილისთვის ეს მიდგომა არ მუშაობს. მოთხოვნის ყველა ტოკენის პარალელური დამუშავების გამო, ერთმა პრეფილის ნაბიჯმა შეიძლება უკვე სრულად დატვირთოს GPU. შესაბამისად, vLLM-ის სტანდარტული დანაწევრებული პრეფილის სტრატეგიაში, თითოეული პრეფილის ნაწილი მხოლოდ ერთი მოთხოვნის ტოკენებს შეიცავს. შემდეგ მოთხოვნას ლოდინი უწევს მანამ, სანამ წინა პრეფილის ფაზა დასრულდება, რის შემდეგაც მისი საკუთარი პრეფილის ფაზა დაიწყება. მოთხოვნებისთვის პრეფილის ნაწილების ეს თანმიმდევრული განრიგი ქმნის გამოწვევას: როდესაც ძალიან გრძელი მოთხოვნა განრიგდება პრეფილისთვის, ნებისმიერ შემდგომ მოთხოვნას უწევს ლოდინი გრძელი პრეფილის ხანგრძლივობის განმავლობაში, სანამ მისი დამუშავება დაიწყება; გრძელი მოთხოვნა ბლოკავს პრეფილის რიგს. (აღსანიშნავია, რომ პრეფილების თანმიმდევრული დამუშავება არის დანაწევრებული პრეფილის სტანდარტული მახასიათებელი და ვლინდება მხოლოდ მაშინ, როდესაც უკვე არსებობს კონკურენტული მოთხოვნა დეკოდირების ფაზაში; აქედან მოდის სახელწოდება "ნაწილობრივი პრეფილი".) სამწუხაროდ, ამ გამოწვევის გადაჭრა შეუძლებელია არც vLLM-ის მხრიდან პრიორიტეტული განრიგით (იხ. ამ სერიის პირველი სტატია) და არც უფრო დახვეწილი ზედა დონის დამგეგმავით. მიზეზი ისაა, რომ გრძელი მოთხოვნა შეიძლება განრიგდეს მანამდე, სანამ რაიმე შემდგომი მოთხოვნა იარსებებს, ამიტომ არაფერია, რასაც დამგეგმავი დაელოდება. მარტივი გადაწყვეტა იქნებოდა სხვადასხვა მოთხოვნის პრეფილის ნაწილების პარალელურად დამუშავება. ეს შესაძლოა არ იყოს რესურსების ოპტიმიზებული, რადგან ერთი მოთხოვნის პრეფილის ნაწილმა უკვე შეიძლება სრულად დატვირთოს გამოთვლითი სიმძლავრე. ნებისმიერი დამატებითი პარალელურად შესრულებული პრეფილი სავარაუდოდ ოდნავ გაახანგრძლივებს პრეფილის ხანგრძლივობას და კიდევ უფრო შეანელებს ნებისმიერ კონკურენტულ დეკოდირების მოთხოვნას. ეს მისაღები იქნებოდა, თუ შეამცირებდა მოკლე მოთხოვნების შეყოვნებას და სისტემას უფრო სწრაფად რეაგირებადს გამოაჩენდა. თუმცა, ეს მიდგომა მარცხდება, როდესაც რიგში მომდევნო მოთხოვნასაც აქვს გრძელი "პრომპტი". ასეთ შემთხვევაში, ორი გამოთვლითად ინტენსიური პრეფილი ერთად დაჯგუფდებოდა და გამოიწვევდა მნიშვნელოვან შენელებას. vLLM-ის ერთ-ერთ უახლეს განახლებაში, გაუმჯობესებული სტრატეგია დაინერგა: ის იძლევა სხვადასხვა მოთხოვნის პარალელური პრეფილის საშუალებას, მაგრამ ზღუდავს ერთდროულად დამუშავებული გრძელი "პრომპტის" მოთხოვნების რაოდენობას. მაგალითად, კონფიგურაციამ შეიძლება ჩართოს ოთხი მოთხოვნის პრეფილის დაჯგუფება, მაგრამ მხოლოდ ერთი მათგანი შეიძლება იყოს 10,000-ზე მეტი "პრომპტის" ტოკენის სიგრძის. ასეთი კონფიგურაციით, გრძელი მოთხოვნების ქცევა კვლავ იგივეა, რაც ადრე: გრძელი "პრომპტები" თანმიმდევრულად მუშავდება. მოკლე მოთხოვნებს კი აღარ უწევთ ლოდინი წინა მოთხოვნის გრძელი პრეფილის დასრულებამდე; მოკლე "პრომპტებს" შეუძლიათ სწრაფი ზოლის გამოყენება. ეს მოთხოვნები აღარ განიცდიან ხანგრძლივ ლოდინის დროს და აჩვენებენ პირველ ტოკენამდე დროის ბევრად დაბალ მეტრიკას. რა თქმა უნდა, პარალელურ პრეფილს შეუძლია მხოლოდ ლოდინის დროის შემცირება; მაგრამ გამოსახულ ტოკენზე დრო რჩება მომატებული კონკურენტული გრძელი პრეფილის ოპერაციის დროს. ამ მხრივ, მოთხოვნის პარალელური პრეფილები აჩვენებენ იგივე ქცევას და შესრულებას, როგორც სტანდარტული დანაწევრებული პრეფილი, უბრალოდ პირველ ტოკენამდე უფრო მოკლე დროით. ყოველთვის, როდესაც სხვადასხვა მოთხოვნის პრეფილი და დეკოდირება სრულდება ერთსა და იმავე GPU ოპერაციაში, ეს უფრო მეტხანს გრძელდება, ვიდრე იზოლირებული დეკოდირების ნაბიჯისთვის. მომხმარებელი განიცდის შეფერხებას ან ტოკენის გენერაციის შენელებას შემდგომი მოთხოვნის გამო. კერძოდ, ერთი გრძელი "პრომპტის" მქონე მოთხოვნა საკმარისია იმისათვის, რომ შეანელოს ყველა ადრე განრიგებული მოთხოვნა, რომლებიც უკვე დეკოდირების ფაზაშია. ეს არის ფუნდამენტური ნაკლი პრეფილის და დეკოდირების ერთდროულ დამუშავებაში იმავე GPU-ებზე, რადგან ცოტა რამის გაკეთება შეგიძლიათ: იდეალურ კონკურენტულ დამუშავებას (რომელიც არ განსხვავდებოდა იზოლირებული მოთხოვნებისგან), რეალურ კონკურენტულ დამუშავებას და დეზაგრეგირებული პრეფილის სტრატეგიას შორის განსხვავება ნაჩვენებია შემდეგი გაზომვებით: პრეფილის და დეკოდირების განცალკევება დიდწილად გამორიცხავს ტოკენის გენერაციის შენელებას სხვა მოთხოვნების არსებობისას, რაც მას ძალიან მიმზიდველ სტრატეგიად აქცევს. ეს მიიღწევა მეორე სრული ზომის vLLM განთავსების ფასად (მაგალითად, Llama-3.3-70B-ისთვის, დაგჭირდებათ ოთხი H100 GPU პრეფილის მუშა პროცესისთვის და კიდევ ოთხი H100 GPU დეკოდირების მუშა პროცესისთვის, თუ გსურთ 130k ტოკენის მაქსიმალური კონტექსტის სიგრძის მხარდაჭერა). კიდევ ერთი მინუსი არის GPU-ს არათანაბარი გამოყენება: რადგან პრეფილი გამოთვლითად ინტენსიურია, დეკოდირება კი არა, პრეფილის მუშა პროცესი სავარაუდოდ სრულად დატვირთავს GPU-ს დეკოდირების მუშა პროცესამდე. მეორეს მხრივ, დიდ კლასტერებს შეიძლება ჰქონდეთ პრეფილის და დეკოდირების მუშა პროცესების განსხვავებული რაოდენობა (დატვირთვის სქემების მიხედვით), რესურსების გამოყენების ოპტიმიზაციის მიზნით. დეზაგრეგირებული პრეფილი არ ისახავს მიზნად მთლიანი გამტარობის გაზრდას, არამედ მთლიანი "goodput"-ის (ანუ მოთხოვნების მაჩვენებელი, რომლებიც აკმაყოფილებენ შეყოვნების სამიზნეებს) გაზრდას. შესაბამისად, ის არ არის GPU რესურსების საუკეთესო გამოყენება, თუ თქვენი აპლიკაცია არ არის მგრძნობიარე ცალკეული მოთხოვნების შეყოვნების მიმართ. კიდევ ერთი შენიშვნა: vLLM-ში დეზაგრეგირებული პრეფილის ფუნქცია ჯერ კიდევ ექსპერიმენტულია და ზოგიერთი ოპტიმიზაცია და ფუნქცია