TRL მხარს უჭერს LLM-ების (დიდი ენობრივი მოდელების) წვრთნას GRPO-ს გამოყენებით, ონლაინ სწავლების ალგორითმის, რომელიც ცოტა ხნის წინ DeepSeekMath-ის ნაშრომში იქნა წარმოდგენილი. GRPO-ში მოდელი სწავლობს საკუთარი გამოსავლებიდან: ის წარმოქმნის პასუხებს წვრთნის დროს, იღებს უკუკავშირს და იყენებს ამ უკუკავშირს დროთა განმავლობაში საკუთარი თავის გასაუმჯობესებლად. ეს გენერაციას წვრთნის მარყუჟში კრიტიკულ ნაბიჯად აქცევს — და ასევე მნიშვნელოვან ბოთლნეკად. გენერაციის დასაჩქარებლად TRL ინტეგრირდება vLLM-თან. ეს კომბინაცია საშუალებას გაძლევთ, უფრო ეფექტურად ავარჯიშოთ ძლიერი მოდელები GRPO-ს დაყენების ფარგლებში. თუმცა, არსებობდა შეზღუდვა. TRL v0.18.0-მდე, vLLM მხარდაჭერილი იყო მხოლოდ სერვერის რეჟიმში, რომელიც მუშაობდა ცალკეულ პროცესად, წვრთნის დავალებისგან განსხვავებულ GPU-ებზე. ის წვრთნის სკრიპტს HTTP-ის საშუალებით უკავშირდებოდა, რაც დაყენებას მოდულურს და მარტივად გამოსაყენებელს ხდიდა — მაგრამ ასევე იწვევდა GPU-ის არაეფექტურობას. აი, რა ხდებოდა: წვრთნასა და გენერაციას შორის ეს „პინგ-პონგი“ იწვევდა: ონლაინ სწავლების მეთოდებში, როგორიცაა GRPO — სადაც გენერაცია მუდმივად ხდება — ეს არაეფექტურობა კიდევ უფრო მტკივნეული იყო. მეტს ხარჯავდით აპარატურაზე, მაგრამ ვერ იღებდით მოსალოდნელ შესრულებას. ამრიგად, მთავარი კითხვა ჩნდება: შეგვიძლია თუ არა ერთი და იგივე GPU-ების გაზიარება როგორც წვრთნისთვის, ისე გენერაციისთვის, ნაცვლად მათი განცალკევებისა? მთავარი პრობლემა ის იყო, რომ წვრთნა და ინფერენცია ცალკეულ GPU-ებზე მიმდინარეობდა, რაც იწვევდა უმოქმედო დროს და რესურსების არასაკმარის გამოყენებას. ბუნებრივი გადაწყვეტა? ორივეს გაშვება ერთსა და იმავე GPU-ებზე. ნაცვლად იმისა, რომ vLLM მოქმედებდეს როგორც დამოუკიდებელი სერვერი საკუთარ პროცესსა და მოწყობილობებზე, რა მოხდება, თუ vLLM იმუშავებს წვრთნის კოდთან ერთად, იმავე განაწილებულ პროცესთა ჯგუფში? ეს საშუალებას მოგვცემს, გავუშვათ ერთი განაწილებული დავალება, სადაც წვრთნა და ინფერენცია ერთსა და იმავე მოწყობილობებს გაიზიარებენ, ამოცანებს შორის ეფექტურად გადაირთვებიან რესურსების გაფლანგვის გარეშე. ამ მიდგომას ჩვენ „კოლოკაციას“ ვუწოდებთ. წვრთნა და ინფერენცია თანა-განთავსებულია ერთსა და იმავე GPU-ებზე და კოორდინირებულია იმავე პროცესთა ჯგუფის საშუალებით, რაც მათ საშუალებას აძლევს, შეუფერხებლად ცვალონ ერთმანეთი — დამატებითი აპარატურა არ არის საჭირო. მანამდე ეს შეუძლებელი იყო TRL-ში, რომელიც vLLM-ს გარე HTTP სერვერად ეყრდნობოდა. ეს შეიცვალა ჩვენი PR #3394-ით, რომელმაც დაამატა vLLM-ის გარე გამშვების მხარდაჭერა და ნამდვილი ინტეგრაცია წვრთნის პროცესში. **კოლოკაციის უპირატესობები:** * **ერთიანი შესრულება:** vLLM-ის იმავე პროცესთა ჯგუფში ჩაშენებით, როგორც წვრთნის, ისე ინფერენციის ამოცანებს შეუძლიათ ერთი და იგივე GPU-ების გაზიარება, რიგრიგობით მოქმედება ერთმანეთის მოლოდინის ნაცვლად. ეს ამცირებს უმოქმედო დროს და ზრდის საერთო ეფექტურობას. * **HTTP კომუნიკაციის გამოტოვება:** აღარ არის საჭირო REST API ზარები ან ქსელური კავშირი — vLLM მუშაობს წვრთნის მარყუჟის პარალელურად, რაც თავიდან აცილებს ზედმეტ დანახარჯებსა და ლატენტურობას. * **Torchrun-თან თავსებადობა:** შეუფერხებლად მუშაობს torchrun-თან, რაც აადვილებს კვანძებზე სკალირებას მინიმალური კონფიგურაციის ცვლილებებით. * **TP და DP მხარდაჭერა:** თავსებადია ტენზორულ პარალელიზმთან (Tensor Parallelism) და მონაცემთა პარალელიზმთან (Data Parallelism), რაც მას შესაფერისს ხდის ფართომასშტაბიანი წვრთნის ოპერაციებისთვის. * **SPMD შესრულების ნიმუში:** იყენებს „ერთი პროგრამა, მრავალი მონაცემი“ (Single Program, Multiple Data - SPMD) მოდელს, სადაც ყოველი GPU აწარმოებს ძრავის საკუთარ ინსტანციას სინქრონულად. იდეალურია განაწილებული მრავალ-GPU, მრავალ-კვანძიანი დაყენებებისთვის. * **გამარტივებული დეპლოირება:** აღარ გჭირდებათ ცალკეული სერვერის სკრიპტის შენარჩუნება — vLLM პირდაპირ თქვენი წვრთნის დავალების შიგნით იშვება და კონტროლდება. * **გაუმჯობესებული გამტარუნარიანობა:** უმოქმედო GPU-ების თავიდან აცილებით და პროცესთაშორისი კომუნიკაციის აღმოფხვრით, სისტემა უზრუნველყოფს უფრო სწრაფ წვრთნას და გენერაციას, რაც განსაკუთრებით მნიშვნელოვანია ონლაინ სწავლების დაყენებებში, როგორიცაა GRPO. * **მყარი პროცესთაშორისი კომუნიკაცია:** ეს უფრო მყარია, რადგან თავიდან აცილებს დამოუკიდებელ პროცესებს შორის განაწილებული პროცესთა ჯგუფების დაყენების სირთულეს, როგორც ეს სერვერის რეჟიმში იყო საჭირო. ამ ფუნქციის წყალობით, თანა-განთავსებული წვრთნა და ინფერენცია აღარ არის „ხაკი“ — ის ახლა არის პირველი კლასის, მასშტაბირებადი და საწარმოო მზადყოფნის გადაწყვეტა. სერვერის TRL-დან კოლოცირებულ TRL-ზე გადასვლა არის GPU-ის უფრო ჭკვიანური გამოყენება. **განსხვავება სერვერულ და კოლოცირებულ დაყენებებს შორის:** * **სერვერის TRL დაყენებაში:** წვრთნა და ინფერენცია მიმდინარეობს ცალკეულ GPU-ებზე. მაგალითად: წვრთნის ნაბიჯების დროს GPU 3 უმოქმედოდ ზის. გენერაციის (ინფერენციის) ნაბიჯების დროს, GPU 0-2 უმოქმედოა, სანამ GPU 3 წარმოქმნის გამოსავლებს. ეს იწვევს არაეფექტურობას. * **კოლოცირებული TRL დაყენებისგან განსხვავებით:** კოლოცირებული TRL დაყენება მუშაობს როგორც წვრთნის, ისე vLLM-ის ერთსა და იმავე GPU-ებზე. ყოველი GPU: წვრთნა და ინფერენცია რიგრიგობით იყენებენ GPU-ის რესურსებს — არ არის საჭირო გამოყოფილი მოწყობილობები ან ცალკეული პროცესები. ეს დიზაინი: ნაცვლად იმისა, რომ vLLM გაუშვას სერვერად, ტრენერი ახლა vLLM-ს პროცესშივე უშვებს გარე გამშვების გამოყენებით. კოლოცირებული vLLM პატივს სცემს `torch.distributed` პროცესთა ჯგუფს და რანგის სტრუქტურას. ეს საშუალებას აძლევს vLLM-ს, ინიციალიზდეს წვრთნასთან ერთად კონფლიქტის გარეშე და უზრუნველყოფს TP/DP დაყენებების შეუფერხებელ მუშაობას. კოლოცირებული vLLM აღარ ეყრდნობა REST API-ებს — ის მუშაობს პირდაპირ მეხსიერებაში და ურთიერთობს მშობლიური Python ზარებით. **როგორ გამოვიყენოთ:** ამ დაყენების გამოსაყენებლად, უბრალოდ დააყენეთ `vllm_mode="colocate"` თქვენს GRPO კონფიგურაციაში. **შენიშვნა:** მოდელის ზომისა და წვრთნისთვის GPU მეხსიერების საერთო მოთხოვნების მიხედვით, შესაძლოა დაგჭირდეთ `vllm_gpu_memory_utilization` პარამეტრის დარეგულირება GRPOConfig-ში, რათა თავიდან აიცილოთ რესურსების არასაკმარისი გამოყენება ან მეხსიერებიდან გასვლის შეცდომები. კოლოკაციის გავლენის გასაზომად, ჩვენ ჩავატარეთ ექსპერიმენტების სერია ტრადიციული სერვერის რეჟიმის შედარებით.