რამდენიმე კვირის განმავლობაში მივაღწიეთ ლატენტურობის 5-ჯერ შემცირებას (და გამტარუნარიანობის 50-ჯერ გაზრდას). გვინდოდა გაგვეზიარებინა ყველა ის სირთულე და ეპიკური გამარჯვება, რაც გავიარეთ ასეთი სიჩქარის გაუმჯობესების მისაღწევად. ამ პროცესში მრავალი განსხვავებული ადამიანი იყო ჩართული მრავალ ეტაპზე, ამიტომ ყველაფერი აქ არ იქნება განხილული. გთხოვთ, გაგებით მოეკიდოთ, რომ ზოგიერთი შინაარსი შეიძლება იყოს მოძველებული ან უბრალოდ არასწორი, რადგან ჩვენ ჯერ კიდევ ვსწავლობთ, როგორ მოვახდინოთ უკიდურესად დიდი მოდელების ოპტიმიზაცია და რეგულარულად გამოდის უამრავი ახალი აპარატურული შესაძლებლობა და ინფორმაცია. თუ თქვენი საყვარელი ოპტიმიზაციის მეთოდი არ არის განხილული ან არასწორად არის წარმოდგენილი, ბოდიშს გიხდით, გთხოვთ, გაგვიზიაროთ იგი – ჩვენ სიამოვნებით ვცდით ახალ მეთოდებს და გამოვასწორებთ ჩვენს შეცდომებს. თავისთავად ცხადია, რომ დიდი მოდელის თავიდანვე ხელმისაწვდომობის გარეშე, არ იქნებოდა მისი ინფერენსის ოპტიმიზაციის რეალური მიზეზები. ეს იყო წარმოუდგენელი ძალისხმევა, რომელსაც მრავალი განსხვავებული ადამიანი ხელმძღვანელობდა. ტრენინგის დროს GPU-ს მაქსიმალურად გამოსაყენებლად, რამდენიმე გადაწყვეტა იქნა განხილული და საბოლოოდ, Megatron-Deepspeed აირჩიეს საბოლოო მოდელის გასაწვრთნელად. ეს ნიშნავდა, რომ კოდი ისე, როგორც იყო, არ იყო აუცილებლად თავსებადი „ტრანსფორმერების“ (transformers) ბიბლიოთეკასთან. თავდაპირველი ტრენინგის კოდის გამო, ჩვენ დავიწყეთ იმის გაკეთება, რასაც რეგულარულად ვაკეთებთ: არსებული მოდელის „ტრანსფორმერებზე“ პორტირება. მიზანი იყო ტრენინგის კოდიდან შესაბამისი ნაწილების ამოღება და მათი „ტრანსფორმერების“ ფარგლებში განხორციელება. ამ ძალისხმევას იუნესმა გაართვა თავი. ეს არავითარ შემთხვევაში არ იყო მცირე ძალისხმევა, რადგან ამას თითქმის ერთი თვე და 200 კომიტი დასჭირდა. გასათვალისწინებელია რამდენიმე რამ, რაც მოგვიანებით ისევ გამოჩნდება: გვჭირდებოდა უფრო მცირე მოდელები bigscience/bigscience-small-testing და bigscience/bloom-560m. ეს უკიდურესად მნიშვნელოვანია, რადგან ისინი უფრო მცირე ზომის არიან, ამიტომ მათთან მუშაობისას ყველაფერი უფრო სწრაფია. პირველ რიგში, თქვენ უნდა მიატოვოთ ყოველგვარი იმედი, რომ გექნებათ ზუსტად იგივე ლოგიტები ბოლოს, ბაიტების დონეზე. PyTorch-ის ვერსიებს შეუძლიათ შეცვალონ ქერნელები და შემოიტანონ დახვეწილი განსხვავებები, ხოლო სხვადასხვა აპარატურამ შეიძლება განსხვავებული შედეგები გამოიღოს სხვადასხვა არქიტექტურის გამო (და თქვენ ალბათ არ გსურთ მუდმივად A100 GPU-ზე მუშაობა ხარჯების მიზეზით). კარგი მკაცრი სატესტო კომპლექტის ქონა ნამდვილად მნიშვნელოვანია ყველა მოდელისთვის. საუკეთესო ტესტი, რაც ვიპოვეთ, იყო ფიქსირებული მოთხოვნების (prompts) ნაკრები. თქვენ იცით მოთხოვნა, თქვენ იცით დასრულება, რომელიც უნდა იყოს დეტერმინისტული, ამიტომ ხარბი (greedy). თუ ორი გენერაცია იდენტურია, შეგიძლიათ ძირითადად უგულებელყოთ ლოგიტების მცირე განსხვავებები. ყოველთვის, როდესაც შეამჩნევთ გადახრას, საჭიროა გამოძიება. ეს შეიძლება ნიშნავდეს, რომ თქვენი კოდი არ აკეთებს იმას, რაც უნდა, ან რომ თქვენ რეალურად ხართ მოდელის დომენის მიღმა და ამიტომ მოდელი უფრო მგრძნობიარეა ხმაურის მიმართ. თუ გაქვთ რამდენიმე მოთხოვნა და საკმარისად გრძელი მოთხოვნები, ნაკლებია შანსი, რომ შემთხვევით გამოიწვიოთ ეს ყველა მოთხოვნისთვის. რაც მეტი მოთხოვნაა, მით უკეთესი, რაც უფრო გრძელია, მით უკეთესი. პირველი მოდელი (small-testing) არის bfloat16 ფორმატში, ისევე როგორც დიდი bloom, ამიტომ ყველაფერი ძალიან მსგავსი უნდა იყოს, მაგრამ ის არ იყო ბევრი ნაწვრთნი ან უბრალოდ არ მუშაობს კარგად, ამიტომ მისი გამომავალი მონაცემები ძლიერად მერყეობს. ეს ნიშნავს, რომ გვქონდა პრობლემები ამ გენერაციის ტესტებთან. მეორე მოდელი უფრო სტაბილურია, მაგრამ გაწვრთნილი და შენახული იყო float16 ფორმატში, bfloat16-ის ნაცვლად. ეს ტოვებს შეცდომის მეტ ადგილს ორ მოდელს შორის. რომ ვიყოთ სამართლიანები, bfloat16 -> float16 კონვერტაცია ინფერენსის რეჟიმში ნორმალური ჩანდა (bfloat16 ძირითადად დიდი გრადიენტების დამუშავებისთვის არსებობს, რომლებიც ინფერენსში არ არსებობს). ამ ეტაპზე ერთი მნიშვნელოვანი კომპრომისი აღმოაჩინეს და განახორციელეს. რადგან bloom გაწვრთნილი იყო განაწილებულ გარემოში, კოდის ნაწილი აკეთებდა ტენზორულ პარალელიზმს Linear layer-ზე, რაც ნიშნავდა, რომ იგივე ოპერაციის ერთ GPU-ზე შესრულება განსხვავებულ შედეგებს იძლეოდა. ამის დადგენას გარკვეული დრო დასჭირდა და ჩვენ ან მივდიოდით 100% შესაბამისობაზე და მოდელი ბევრად ნელი იყო, ან მივიღებდით მცირე განსხვავებას გენერაციაში, მაგრამ ის ბევრად სწრაფად მუშაობდა და კოდი უფრო მარტივი იყო. ჩვენ ავირჩიეთ კონფიგურირებადი დროშა. ახლა ჩვენ გვაქვს „ტრანსფორმერების“ სუფთა, გამოსადეგი ვერსია, რათა დავიწყოთ მისი გაშვება. Bloom არის 352GB (176 მილიარდი პარამეტრი bf16-ში) მოდელი, ჩვენ გვჭირდება მინიმუმ ამდენი GPU RAM, რომ ის მოთავსდეს. მოკლედ განვიხილეთ CPU-ზე გადმოტვირთვა მცირე მანქანებზე, მაგრამ ინფერენსის სიჩქარე რიგითობით ნელი იყო, ამიტომ უარი ვთქვით. შემდეგ გვინდოდა ძირითადად „ფაიფლაინის“ (pipeline) გამოყენება. ეს არის ის, რასაც API მუდმივად იყენებს. თუმცა „ფაიფლაინები“ არ არის განაწილებული სისტემებისთვის (ეს მათი მიზანი არ არის). ვარიანტების მოკლე განხილვის შემდეგ, ჩვენ საბოლოოდ გამოვიყენეთ accelerate-ის ახლად შექმნილი `device_map="auto"` მოდელის შარდინგის (დანაწილების) სამართავად. მოგვიწია რამდენიმე შეცდომის გამოსწორება და „ტრანსფორმერების“ კოდის ოდნავ შეცვლა, რათა accelerate-ს სწორად ემუშავა. ის მუშაობს „ტრანსფორმერების“ სხვადასხვა ფენის გაყოფით და მოდელის ნაწილის თითოეული GPU-სთვის მიცემით. ასე რომ, GPU0 იწყებს მუშაობას, შემდეგ გადასცემს GPU1-ს და ასე შემდეგ. საბოლოოდ, მცირე HTTP სერვერით, ჩვენ შევძელით Bloom-ის (დიდი მოდელის) გაშვება! მაგრამ ჩვენ ჯერ არც კი დაგვიწყია ოპტიმიზაციების განხილვა! ჩვენ რეალურად ბევრი გვაქვს გასაკეთებელი, მთელი ეს პროცესი ქვიშის ციხეა.