ვინაიდან დეკოდირების ცალკეული ნაბიჯები გამოთვლითად ინტენსიური არ არის, გამტარუნარიანობის გაზრდა შესაძლებელია მრავალი მოთხოვნის დეკოდირების დაჯგუფებით. თუმცა, პრეფილისთვის ეს მიდგომა არ მუშაობს. მოთხოვნის (prompt) ყველა ტოკენის პარალელური დამუშავების გამო, ერთმა პრეფილის ეტაპმა შეიძლება უკვე სრულად დატვირთოს GPU. შესაბამისად, vLLM-ის ნაგულისხმევ დანაწევრებულ-პრეფილის (chunked-prefill) სტრატეგიაში, ყოველი პრეფილის ნაწილი (chunk) შეიცავს მხოლოდ ერთი მოთხოვნის პრომპტის ტოკენებს. რიგში მომდევნო მოთხოვნას უწევს ლოდინი, სანამ წინა პრეფილის ფაზა არ დასრულდება, რათა მისი საკუთარი პრეფილის ფაზა დაიწყოს. მოთხოვნების პრეფილის ნაწილების (chunks) ეს თანმიმდევრული განრიგი ქმნის გამოწვევას: როდესაც ძალიან გრძელი პრომპტის მქონე მოთხოვნა განისაზღვრება პრეფილისთვის, ნებისმიერ მომდევნო მოთხოვნას უწევს ლოდინი გრძელი პრეფილის დასრულებამდე, სანამ მისი დამუშავება დაიწყება; გრძელი პრომპტი ბლოკავს პრეფილის რიგს. (აღსანიშნავია, რომ პრეფილების თანმიმდევრული დამუშავება არის დანაწევრებული პრეფილის ნაგულისხმევი მახასიათებელი და ვლინდება მხოლოდ მაშინ, როდესაც უკვე არსებობს პარალელური მოთხოვნა დეკოდირების ფაზაში; აქედან გამომდინარეობს სახელწოდება „ნაწილობრივი პრეფილი“.) სამწუხაროდ, ამ გამოწვევის გადაჭრა შეუძლებელია არც vLLM-ის მხრიდან პრიორიტეტული განრიგით (იხ. ამ სერიის პირველი სტატია) და არც უფრო დახვეწილი ზედა დონის სქეჯულერით. მიზეზი ის არის, რომ გრძელი პრომპტი შეიძლება დაიგეგმოს მანამ, სანამ რაიმე შემდგომი მოთხოვნა იარსებებს, ამიტომ არაფერია ისეთი, რასაც სქეჯულერი დაელოდება. მარტივი გამოსავალი იქნებოდა სხვადასხვა მოთხოვნის პრეფილის ნაწილების პარალელურად დამუშავება. ეს შესაძლოა არ იყოს რესურსულად ოპტიმიზებული, რადგან ერთი მოთხოვნის პრეფილის ნაწილებმაც კი შეიძლება უკვე სრულად დატვირთოს გამოთვლითი სიმძლავრე. ნებისმიერი დამატებითი პრეფილი, რომელიც პარალელურად შესრულდება, სავარაუდოდ, ოდნავ გაახანგრძლივებს პრეფილის ხანგრძლივობას და კიდევ უფრო შეანელებს ნებისმიერ პარალელურ დეკოდირების მოთხოვნას. ეს მისაღები იქნებოდა, თუ ის შეამცირებდა მოკლე მოთხოვნების შეყოვნებას და სისტემას უფრო რეაგირებადს გახდიდა. თუმცა, ეს მიდგომა მარცხდება, როდესაც რიგში მომდევნო მოთხოვნასაც გრძელი პრომპტი აქვს. ასეთ შემთხვევაში, ორი გამოთვლითად ინტენსიური პრეფილი ერთად დაჯგუფდება, რაც გამოიწვევს მნიშვნელოვან შენელებას. vLLM-ის ერთ-ერთ უახლეს განახლებაში, დანერგილია გაუმჯობესებული სტრატეგია: ის იძლევა სხვადასხვა მოთხოვნის პარალელური პრეფილის საშუალებას, მაგრამ გრძელი პრომპტის მქონე მოთხოვნების ერთდროულად დამუშავებული რაოდენობა ლიმიტირებულია. მაგალითად, კონფიგურაციამ შეიძლება ოთხი მოთხოვნის პრეფილის დაჯგუფება დაუშვას, მაგრამ მათგან მხოლოდ ერთი შეიძლება იყოს 10,000 პრომპტის ტოკენზე გრძელი. ასეთი კონფიგურაციით, გრძელი მოთხოვნების ქცევა კვლავ იგივეა, რაც ადრე: გრძელი პრომპტები თანმიმდევრულად მუშავდება. მოკლე მოთხოვნებს, თუმცა, აღარ უწევთ ლოდინი წინა მოთხოვნის გრძელი პრეფილის დასრულებამდე; მოკლე პრომპტებს შეუძლიათ „სწრაფი ზოლის“ გამოყენება. ეს მოთხოვნები აღარ განიცდიან ხანგრძლივ ლოდინის დროს და აჩვენებენ გაცილებით დაბალ „პირველი ტოკენის მიღების დროის“ (time-to-first-token) მაჩვენებლებს. რა თქმა უნდა, პარალელური პრეფილები მხოლოდ ლოდინის დროს ამცირებს; მაგრამ გამომავალი ტოკენის დრო (time-per-output-token) რჩება მომატებული პარალელური გრძელი პრეფილის ოპერაციის დროს. ამ მხრივ, მოთხოვნაზე პარალელური პრეფილები აჩვენებენ იმავე ქცევასა და შესრულებას, როგორც სტანდარტული დანაწევრებული პრეფილი, უბრალოდ „პირველი ტოკენის მიღების დრო“ (time-to-first-token) უფრო მოკლეა. როდესაც სხვადასხვა მოთხოვნის პრეფილი და დეკოდირება სრულდება ერთსა და იმავე GPU ოპერაციაში, ეს უფრო მეტ დროს მოითხოვს, ვიდრე იზოლირებული დეკოდირების ეტაპისთვის. მომხმარებელი განიცდის შეფერხებას ან ტოკენის გენერაციის შენელებას მომდევნო მოთხოვნის გამო. კერძოდ, ერთი მოთხოვნა გრძელი პრომპტით საკმარისია იმისთვის, რომ შეანელოს ყველა ადრე დაგეგმილი მოთხოვნა, რომელიც უკვე დეკოდირების ფაზაშია. ეს არის ფუნდამენტური ნაკლი პრეფილის და დეკოდირების ერთდროული დამუშავებისას იმავე GPU-ებზე, რადგან ცოტა რამის გაკეთება შეგიძლიათ: განსხვავება იდეალურ პარალელურ დამუშავებას (რომელიც არ განსხვავდებოდა იზოლირებული მოთხოვნებისგან), რეალურ პარალელურ დამუშავებას და დეზაგრეგირებულ პრეფილის სტრატეგიას შორის ნაჩვენებია შემდეგი გაზომვებით: პრეფილის და დეკოდირების განცალკევება დიდწილად გამორიცხავს ტოკენის გენერაციის შენელებას სხვა მოთხოვნების არსებობისას, რაც მას ძალიან მიმზიდველ სტრატეგიად აქცევს. ეს მიიღწევა მეორე სრული ზომის vLLM განთავსების ფასად (მაგალითად, Llama-3.3-70B-ისთვის დაგჭირდებათ ოთხი H100 GPU პრეფილის მუშაკისთვის და კიდევ ოთხი H100 GPU დეკოდირების მუშაკისთვის, თუ გსურთ 130k ტოკენის მაქსიმალური კონტექსტის სიგრძის მხარდაჭერა). კიდევ ერთი მინუსი არის GPU-ს არათანაბარი დატვირთვა: რადგან პრეფილი გამოთვლითად ინტენსიურია, დეკოდირება კი არა, პრეფილის მუშაკი, სავარაუდოდ, გაცილებით ადრე დატვირთავს GPU-ს სრულად, ვიდრე დეკოდირების მუშაკი. მეორეს მხრივ, დიდ კლასტერებს შეუძლიათ შედგებოდეს პრეფილის და დეკოდირების მუშაკების განსხვავებული რაოდენობით (დატვირთვის სქემებიდან გამომდინარე), რათა მოხდეს რესურსების გამოყენების ოპტიმიზაცია. დეზაგრეგირებული პრეფილი არ არის გამიზნული მთლიანი გამტარუნარიანობის (throughput) გასაზრდელად, არამედ მთლიანი „ეფექტური გამტარუნარიანობის“ (goodput) გასაუმჯობესებლად (ანუ მოთხოვნების სიჩქარე, რომელიც აკმაყოფილებს შეყოვნების სამიზნეებს). შესაბამისად, ის არ არის GPU რესურსების საუკეთესო გამოყენება, თუ თქვენი აპლიკაცია არ არის მგრძნობიარე ცალკეული მოთხოვნების შეყოვნების მიმართ. კიდევ ერთი გაფრთხილება: vLLM-ში დეზაგრეგირებული პრეფილის ფუნქცია ჯერ კიდევ ექსპერიმენტულია, და ზოგიერთი ოპტიმიზაცია და ფუნქცია