ამ ბლოგპოსტში სიღრმისეულად განვიხილავთ ყველა განახლებას და იმას, თუ როგორ ხდება ისინი ტრანსფორმერების ხელსაწყოთა ნაკრების ნაწილი, რათა სხვა მოდელებმა (მიმდინარე და მომავალი) ისარგებლონ მათით. ტრანსფორმერებში ახალი მეთოდების სუფთა იმპლემენტაციის უზრუნველყოფა საზოგადოებას საშუალებას აძლევს, სწრაფად გაიგოს და გამოიყენოს ისინი. MLX, llama.cpp ან vLLM-ის მსგავს ფრეიმვორკებს შეუძლიათ ტრანსფორმერების კოდი გამოიყენონ, როგორც საცნობარო მასალა საკუთარი იმპლემენტაციების შესაქმნელად. ამ გამოშვებისთვის ჩვენ ვიმუშავეთ: საუკეთესო ნაწილი: ამ ფუნქციების უმეტესობა ტრანსფორმერების ყველა ძირითად მოდელზე უნდა მუშაობდეს! ქერნელი არის სპეციალიზებული, კომპაქტური პროგრამა, რომელიც მუშაობს ამაჩქარებლებზე ისეთი ამოცანების შესასრულებლად, როგორიცაა მატრიცული გამრავლება, აქტივაციები ან ნორმალიზაცია. PyTorch-ის „eager“ რეჟიმში, ოპერაციები თანმიმდევრულად იწყებენ ინდივიდუალურ ქერნელებს, რაც მარტივია, მაგრამ შეიძლება გამოიწვიოს დამატებითი მეხსიერების გადაცემა და გაშვების ხარჯები. PyTorch 2.0-ის torch.compile-ი TorchInductor-ის მსგავსი ბექენდებით ამ პრობლემას აგვარებს ავტომატურად ქერნელების გაერთიანებითა და ოპტიმიზაციით, რაც 2-10-ჯერ ზრდის შესრულებას. გარდა ამისა, საზოგადოებამ შექმნა მორგებული ქერნელები ოპერაციების ხშირი კომბინაციებისთვის და არა მხოლოდ ინდივიდუალური PyTorch ოპერაციებისთვის, როგორიცაა matmul. მაგალითად, Flash Attention შეიქმნა ტრანსფორმერების არქიტექტურის განმსაზღვრელი კრიტიკული ყურადღების ბლოკის ოპტიმიზაციისთვის და წარმოდგენილია ბევრ მოდელში, მათ შორის LLM-ების უმეტესობაში. ყურადღების ყველა ოპერაციის ერთ ქერნელში ფრთხილად გაერთიანებით, მეხსიერების გადაცემა მინიმუმამდე მცირდება, მეხსიერების გამოყენება მცირდება და შესრულების დაჩქარება მიიღწევა. პრობლემა ის არის, რომ ეს სხვადასხვა ქერნელი ხელმისაწვდომია ცალკეულ ბიბლიოთეკებში, რაც ქმნის დამოკიდებულებების გაბერვას, თუ ისინი ტრანსფორმერების ბიბლიოთეკას დაემატებოდა. გარდა ამისა, ეს ქერნელები მხოლოდ Python კოდი არ არის, ისინი შედგება დაბალი დონის CUDA კოდისგან, რომელიც C++-ით არის შეკრული და Python ფენის მეშვეობით არის ხელმისაწვდომი. ეს ნიშნავს, რომ ისინი სამიზნე სისტემაში უნდა იყოს კომპილირებული, რაც თავის მხრივ მოითხოვს ნებისმიერი აგების სისტემას, რომელიც თითოეულ ქერნელის ბიბლიოთეკას სჭირდება. „kernels“ პაკეტი ამ პრობლემას აგვარებს Hub-იდან მხარდაჭერილი ქერნელების წინასწარ აგებული ბინარების ჩამოტვირთვით. თქვენ უბრალოდ მიუთითებთ ქერნელს, რომლის გამოყენებაც გსურთ, და „kernels“ მოძებნის თქვენს სისტემასთან თავსებად ვერსიას და ჩამოტვირთავს მას პირველი გამოყენებისას. GPT-OSS, Mixture of Experts (MoE) მოდელი, აქტიურად იყენებს Hub-იდან გადმოწერილ ქერნელებს. ის იყენებს რამდენიმე მორგებულ ქერნელს: მოდით გადავხედოთ პირველ ორს. კულისებში, დეკორატორები (1 და 2) უბრალოდ მიუთითებენ საზოგადოების მიერ შექმნილ ქერნელებს. მაგალითად, RMSNorm მოდის liger_kernels-დან, ხოლო MegaBlocksMoeMLP ქერნელი მოდის megablocks-იდან. თქვენი მოწყობილობის (CUDA ან ROCm) მიხედვით და იმის მიხედვით, ავარჯიშებთ თუ ინფერენსს აწარმოებთ, სწორი ქერნელი ავტომატურად გადმოიტვირთება. ეს დიზაინი როგორც სპეციფიკური, ასევე ზოგადია: RMSNorm liger ქერნელები უკვე გამოიყენება მრავალ მოდელში, ხოლო MoE ქერნელი შეიძლება გამოყენებულ იქნას მომავალი MoE-ებისთვისაც. რადგან ქერნელები Hub-იდან იღებენ კოდს, თქვენ უნდა გაააქტიუროთ ეს ფუნქცია use_kernels=True გადაცემით თქვენი მოდელის ინსტანციაციისას, როგორც ნაჩვენებია ქვემოთ. ჩვენ ვრთავთ INFO logging-ს მაგალითში, რათა ადვილად შეძლოთ იმის გადამოწმება, რომ გადმოსაწერი ქერნელები გამოიყენება. ეს ქერნელები არ არის თავსებადი mxfp4-თან, ამიტომ ინფერენსი bfloat16-ში მოხდება, თუ მათ გამოიყენებთ. გთხოვთ, შეაფასოთ თქვენი სისტემა მეხსიერებისა და გამტარუნარიანობის საუკეთესო კომბინაციისთვის, რომელიც შეესაბამება თქვენს პროექტს! სწრაფი გენერაცია აჩვენებს ლოგ შეტყობინებებს, როგორიცაა სურათი 1 გვიჩვენებს, რომ ჩვენს მიერ ტესტირებულ სისტემაში ეს ქერნელები საუკეთესოდ მუშაობს უფრო დიდი batch ზომებისთვის. ჩვენ ყოველთვის გირჩევთ, შეაფასოთ შესრულებასთან დაკავშირებული ნებისმიერი ცვლილება მაქსიმალურად ახლოს თქვენს საწარმოო პირობებთან. შეგიძლიათ შეისწავლოთ და ითამაშოთ ბენჩმარკინგის სკრიპტით აქ. OpenAI gpt-oss მოდელები იყენებენ „attention sinks“-ს, რაც აუმჯობესებს ხარისხს და ხელს უწყობს უფრო გრძელი კონტექსტების გამოყენებას. vLLM-ის გუნდმა ეს ფუნქცია Flash Attention-ის უახლეს ვერსიას (Flash Attention 3) დაამატა და მიღებული მორგებული ქერნელი ხელმისაწვდომია Hub-ზე. ამჟამად, ეს ქერნელი თავსებადია Hopper არქიტექტურასთან. თუ თქვენ გაქვთ ასეთი, მისი ჩართვის გზაა: დიდი ენობრივი მოდელები (LLMs) მეხსიერებაზე მომთხოვნია. კვანტიზაცია ამცირებს მეხსიერების ნაკვალევს წონების (და ზოგჯერ აქტივაციების) დაბალი სიზუსტის ფორმატებში შენახვით. ცნობისთვის, FP32 იყენებს 32 ბიტს თითო რიცხვზე, ხოლო BF16 იყენებს 16-ს. ბიტის სიგანის შემცირებით, ჩვენ ვცვლით გარკვეულ სიზუსტეს უფრო მცირე მოდელებსა და მეხსიერების სწრაფ გადაადგილებაზე. თუ გსურთ ვიზუალური შესავალი კვანტიზაციის კომპრომისებზე, მაარტენ გრუტენდორსტის სტატია შესანიშნავია: „კვანტიზაციის ვიზუალური გზამკვლევი“. MXFP4 არის 4-ბიტიანი მცურავი ფორმატი E2M1 განლაგებით: 1 ნიშნის ბიტი, 2 ექსპონენტის ბიტი და 1 მანტისის ბიტი, როგორც ნაჩვენებია სურათზე 2. თავისთავად, E2M1 ძალიან უხეშია. MXFP4 ამას ანაზღაურებს ბლოკური სკალირებით: ეს ბლოკური სქემა საშუალებას აძლევს MXFP4-ს შეინარჩუნოს დიაპაზონი ძალიან მცირე ბიტების გამოყენებისას. პრაქტიკაში, GPT-OSS 20B დაახლოებით 16 GB VRAM-ში ჯდება, ხოლო GPT-OSS 120B დაახლოებით 80 GB-ში, როდესაც MXFP4 აქტიურია, რაც არის განსხვავება „ვერ იტვირთება“ და „შეუძლია ერთ GPU-ზე მუშაობა“ შორის. ხრიკი იმაშია, რომ მატრიცულმა გამრავლებამ ახლა უნდა დაიცვას ბლოკური სკალები. ამის გაკეთება ე...