TRL მხარს უჭერს დიდი ენობრივი მოდელების (LLM) წვრთნას GRPO-ს გამოყენებით, რომელიც არის ონლაინ სწავლების ალგორითმი, ახლახან წარმოდგენილი DeepSeekMath-ის ნაშრომში. GRPO-ში მოდელი სწავლობს საკუთარი გამონათქვამებიდან: ის ქმნის პასუხებს წვრთნის დროს, იღებს უკუკავშირს და იყენებს ამ უკუკავშირს დროთა განმავლობაში გასაუმჯობესებლად. ეს გენერაციას გადამწყვეტ ნაბიჯად აქცევს წვრთნის ციკლში – და ასევე მნიშვნელოვან შეფერხების წყაროდ (bottleneck). გენერაციის დასაჩქარებლად, TRL ინტეგრირდება vLLM-თან. ეს კომბინაცია საშუალებას გაძლევთ, უფრო ეფექტურად ავარჯიშოთ ძლიერი მოდელები GRPO-ს კონფიგურაციაში. თუმცა, არსებობდა ერთი პრობლემა. TRL v0.18.0 ვერსიამდე, vLLM მხარდაჭერილი იყო მხოლოდ სერვერის რეჟიმში, რომელიც მუშაობდა როგორც ცალკეული პროცესი, წვრთნის სამუშაოსგან განსხვავებულ GPU-ებზე. ის უკავშირდებოდა წვრთნის სკრიპტს HTTP-ის საშუალებით, რაც კონფიგურაციას მოდულურს და მარტივად გამოსაყენებელს ხდიდა – მაგრამ ამავე დროს GPU-ების არაეფექტურობას იწვევდა. აი, რა ხდებოდა: წვრთნასა და გენერაციას შორის ეს „პინგ-პონგი“ იწვევდა პრობლემებს. ონლაინ სწავლების მეთოდებში, როგორიცაა GRPO – სადაც გენერაცია მუდმივად მიმდინარეობს – ეს არაეფექტურობა კიდევ უფრო მტკივნეული ხდება. მეტს ხარჯავთ აპარატურაზე, მაგრამ ვერ იღებთ მოსალოდნელ შესრულებას. ამიტომ, მთავარი კითხვა ჩნდება: შეგვიძლია თუ არა ერთი და იგივე GPU-ების გაზიარება როგორც წვრთნისთვის, ასევე გენერაციისთვის, ნაცვლად მათი განცალკევებისა? მთავარი პრობლემა ის იყო, რომ წვრთნა და ინფერენცია ცალკეულ GPU-ებზე მიმდინარეობდა, რაც იწვევდა უქმ დროს და რესურსების არასრულ გამოყენებას. ბუნებრივი გამოსავალი? ორივეს ერთი და იგივე GPU-ებზე გაშვება. იმის ნაცვლად, რომ vLLM მუშაობდეს როგორც დამოუკიდებელი სერვერი საკუთარ პროცესსა და მოწყობილობებზე, რა მოხდებოდა, თუ vLLM იმუშავებდა წვრთნის კოდთან ერთად, იმავე განაწილებული პროცესის ჯგუფში? ეს საშუალებას მოგვცემდა, გაგვეშვა ერთი განაწილებული სამუშაო, სადაც წვრთნა და ინფერენცია იზიარებენ ერთსა და იმავე მოწყობილობებს, ეფექტურად გადართვა ამოცანებს შორის რესურსების გაფლანგვის გარეშე. ამ მიდგომას ჩვენ კოლოკაციას ვუწოდებთ. წვრთნა და ინფერენცია კოლოცირებულია ერთსა და იმავე GPU-ებზე და კოორდინირებულია იმავე პროცესის ჯგუფის საშუალებით, რაც მათ საშუალებას აძლევს, შეუფერხებლად ცვალონ ერთმანეთი – დამატებითი აპარატურის საჭიროების გარეშე. ადრე, ეს შეუძლებელი იყო TRL-ში, რომელიც ეყრდნობოდა vLLM-ს, როგორც გარე HTTP სერვერს. ეს შეიცვალა ჩვენი PR #3394-ით, რომელმაც დაამატა vLLM-ის გარე გამშვების (external launcher) მხარდაჭერა და ნამდვილი ინტეგრაცია წვრთნის პროცესში. ამ ახალმა მიდგომამ მოიტანა შემდეგი უპირატესობები: * **ერთიანი შესრულება:** 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 კონფიგურაცია აწარმოებს როგორც წვრთნას, ასევე 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-ში, რათა თავიდან აიცილოთ რესურსების არასრულად გამოყენება ან მეხსიერების ამოწურვის შეცდომები. კოლოკაციის გავლენის გასაზომად, ჩვენ ჩავატარეთ ექსპერიმენტების სერია, ტრადიციული სერვერის რეჟიმთან შედარებით (სადაც vLLM ცალკე მუშაობდა).