Day 0 वर GPT-OSS

FP8, सिंक अटेंशन आणि MoE ऑप्टिमायझेशनसह ROSE जुळवून घेऊन H200 वर GPT‑OSS साठी Day‑0 सपोर्ट

लेखकPerplexity Engineering

Perplexity अचूक आणि विश्वासार्ह उत्तरे आणि एजंट कृतींची मागणी करणाऱ्या जिज्ञासू लोकांसाठी सर्वोत्तम AI मॉडेल्स उपलब्ध करून देण्यासाठी कटिबद्ध आहे. OpenAI ने अलीकडेच त्यांचे ओपन-वेट मॉडेल्स (gpt-oss-20b आणि gpt-oss-120b) जाहीर केले. अनेक अग्रगण्य मॉडेल्सप्रमाणेच, Perplexity हे gpt-oss-20b आणि gpt-oss-120b यांचे मूल्यांकन करणाऱ्या पहिल्या संस्थांपैकी एक आहे.

या पोस्टमध्ये, आम्ही आमच्या इन-हाउस इन्फरन्स स्टॅकचे इन्फ्रास्ट्रक्चर निर्णय सामायिक करतो ज्याने Day-0 सपोर्ट शक्य केला. आम्ही NVIDIA H200 GPU वर ही मॉडेल्स सर्व्ह करण्यावर लक्ष केंद्रित करतो, कर्नल बदल, उपयोजन निवडी आणि गती-किंमत ट्रेड-ऑफ यांचे तपशीलवार वर्णन करतो.

हॉपरवर GPT-OSS

ओपन-वेट मॉडेल्स MXFP4 क्वांटायझेशन वापरून पाठवले जातात, ज्यामुळे ते ग्राहक-ग्रेड हार्डवेअरवरील मेमरीमध्ये बसण्यास किंवा NVIDIA Blackwell वर पीक थ्रुपुट साध्य करण्यास मदत करतात. तथापि, प्रारंभिक मूल्यांकनासाठी, आम्हाला किमान इन्फरन्स-इंजिन बदलांसह विद्यमान H200 हॉपर क्लस्टरवर चालवायचे होते. हॉपरकडे ब्लॅकवेल द्वारे सादर केलेले समर्पित FP4 ट्यूसर कोअर्स नाहीत. परिणामी, आम्ही कस्टम कर्नलची गरज कमी करण्यासाठी आणि उपलब्ध हार्डवेअरचा जास्तीत जास्त वापर करण्यासाठी त्याऐवजी FP8 अचूकतेसह मॉडेल्स सर्व्ह करण्याचा निर्णय घेतला.

उच्च पातळीवर, ट्रान्सफॉर्मर LLM संरचनेच्या दृष्टीने सोपे आहेत:

इनपुट एम्बेडिंग

ट्रान्सफॉर्मर लेयर्सचा एक क्रम. प्रत्येकामध्ये एक अटेंशन ब्लॉक आणि एक डेंस MLP किंवा स्पार्स MoE ब्लॉक असतो.

आउटपुट लॉजिट प्रोजेक्शन

नवीन ट्रान्सफॉर्मर मॉडेल आणताना, आवश्यक बदल ओळखण्यासाठी ते विद्यमान मॉडेल्सशी किती जुळतात हे शिकण्यात आम्हाला प्रामुख्याने रस असतो. OpenAI ने दयाळूपणे त्यांच्या मॉडेल्सचे विहंगावलोकन आगाऊ सामायिक केले, ज्यामुळे आम्हाला आमचे इन्फरन्स सेटअप त्यानुसार सुधारायला मिळाले. आम्हाला आढळले की मॉडेलला खरोखरच अनेक लहान बदलांची आवश्यकता होती.

अटेंशन: अटेंशन सिंकसह GQA

प्रत्येक अटेंशन हेडमध्ये प्री-ट्रेन केलेले सिंक पॅरामीटर असते ज्याचा Softmax मध्ये समावेश केला जातो

DeepSeek-V3 प्रमाणेच YaRN पोझिसन एनकोडिंग

Qwen 2 प्रमाणेच QKV प्रोजेक्शनमध्ये बायसेस असतात

आउटपुट प्रोजेक्शनमध्ये बायस असतो

MLP: स्पार्स मिक्चर-ऑफ-एक्सपर्ट (MoE)

SwiGLU ॲक्टिव्हेशन फंक्शन, बहुतांश ओपन-वेट मॉडेल्सपेक्षा वेगळे

एक्सपर्ट वजनांसाठी Top-K नंतर Softmax

एक्सपर्ट्सकडे बायसेस असतात

पॅरामीटर्सची संख्या सुमारे 100B-200B असण्याची अपेक्षा करून, आम्ही खालील निर्णय घेतले:

अटेंशन सिंकला समर्थन देण्यासाठी FlashInfer विस्तृत करणे

DeepSeek-V3 मॉडेल कुटुंबासाठी आधीच तयार केलेले MoE इम्प्लिमेंटेशन पुन्हा वापरणे

बायस टर्मला समर्थन देण्यासाठी DeepGEMM कर्नल्स वाढवून, क्वांटायझेशन योजना म्हणून FP8 128x128 ब्लॉक स्केलिंग निवडणे.

इन-हाउस इन्फरन्स इंजिन

आमचे इन्फरन्स प्रयत्न आमच्या इन-हाउस इन्फरन्स इंजिन, ROSE द्वारे समर्थित आहेत. नवीन मॉडेल्स जलदगतीने आणण्याची परवानगी देणारी लवचिक फ्रेमवर्क म्हणून आम्ही ROSE विकसित करत आहोत. याशिवाय, एकदा आम्ही एखाद्या मॉडेलला मोठ्या प्रमाणावर सर्व्ह करण्यासाठी वचनबद्ध झालो की, ते अत्याधुनिक स्तरावर पोहोचण्यासाठी कामगिरी ऑप्टिमाइझ आणि बूस्ट करण्यासाठी एक प्लॅटफॉर्म प्रदान करते.

ROSE एक LLM इंजिन उघड करते, जे एखादे मॉडेल लोड करू शकते आणि स्पेक्युलेटिव्ह आणि MTP डिकोडर्ससह अनेक डिकोडर्सद्वारे त्यासाठी डिकोड केलेले टोकन्स जनरेट करू शकते. मॉडेल्स स्वतः कस्टम लेयर्सच्या संचपासून बनलेले असतात, जे क्वांटायझेशन आणि पॅरालेलिझमसाठी विविध कॉन्फिगरेशन नॉब्सना समर्थन देतात. लेयर्सच्या खाली, यात ट्रिटॉन आणि कुडा (CUDA) दोन्ही कर्नल्स समाविष्ट आहेत जे वैयक्तिक लेयर्सद्वारे केलेल्या संगणनांची कार्यक्षमतेने अंमलबजावणी आणि संलयन करतात.

ROSE प्रामुख्याने Python मध्ये तयार केले आहे आणि मॉडेल व्याख्यांसाठी PyTorch वर अवलंबून आहे. Python आम्हाला लवचिक राहण्याची आणि नवीन मॉडेल्सशी जुळवून घेण्याची परवानगी देत असताना, आम्ही सर्व्हिंग आणि बॅच शेड्यूलिंगसारखे बहुतेक कामगिरी-संवेदनशील घटक Rust मध्ये मायग्रेट करत आहोत.

नवीन मॉडेल आणण्यासाठी, आम्ही प्रथम मॉडेल पदानुक्रम परिभाषित करतो आणि त्यासाठी वजन कनवर्टर तयार करतो. सर्व वजनांचा हिशोब लागल्यानंतर, आम्ही सर्वात सोप्या TP=1 वापर प्रकरणासाठी फॉरवर्ड पास परिभाषित करतो आणि ते एंड-टू-एंड काम करत असल्याची खात्री करतो. शेवटी, आम्ही नवीन कंटेनर रिलीज करण्यापूर्वी आणि मूल्यांकनासाठी क्लस्टरवर मॉडेल तैनात करण्यापूर्वी विविध प्रकारच्या पॅरालेलिझमसाठी समर्थनाची अंमलबजावणी आणि चाचणी करतो. डॅशबोर्ड आणि बारीक-बारीक बेंचमार्क दोन्हीच्या अभिप्रायवर अवलंबून राहून, आम्ही नंतर कामगिरीवर पुनरावृत्ती करतो.

इंटिग्रेशन चाचण्यांच्या बाहेर चॅट स्वरूपांच्या अल्प ज्ञानासह, ROSE अंकीय टोकन्सवर ऑपरेट करते. समांतरपणे, आम्हाला Harmony टोकनायझरला समर्थन देण्यासाठी आणि इनपुट टोकन अनुक्रमांवर विनंत्या योग्यरित्या मॅप करण्यासाठी सभोवतालच्या इन्फ्रास्ट्रक्चरमध्ये डोकावून पाहणे आवश्यक होते.

GPT OSS मॉडेलसह, आम्हाला आढळले की आमच्या डिकोडर्स, CUDA graph harnesses किंवा सभोवतालच्या पायाभूत सुविधांमध्ये कोणतेही बदल आवश्यक नव्हते, ज्यामुळे आम्हाला मॉडेलला आधार देणाऱ्या kernels चे सूक्ष्म समायोजन करण्यावर आमचे प्रयत्न केंद्रित करता आले.

GPT-OSS साठी कर्नल्स

सिंक अटेंशन

सिंक अटेंशन Softmax च्या आधी एक अतिरिक्त बायस फॅक्टर सादर करते, जो Q आणि K च्या गुणाकाराशी संचित केला जातो:

plaintext
attn = softmax(q @ k^T * sm_scale + sink) * V

जरी एक साधे इम्प्लिमेंटेशन अगदी क्षुल्लक असले, तरी कार्यक्षम अटेंशन इम्प्लिमेंटेशन्स, जसे की FlashInfer, स्वतंत्र हेड आणि KV अनुक्रम लांबी या दोन्हीमध्ये अटेंशनचे संगणन समांतर करतात. याशिवाय, संख्यात्मक स्थिरतेसाठी, संख्यात्मक स्थिरता मिळवण्याकरिता जास्तीत जास्त घटक वजा करताना Softmax ऑनलाइन संगणन केले जाते:

plaintext
softmax(x) = e^x / sum(e^x) = e ^ (x - max(x)) / sum(e ^ (x - max(x))

-inf वर इनिशिएलाइज केलेले चालू कमाल m आणि 1 वर स्केल d ऑनलाइन इम्प्लिमेंटेशनने ट्रॅक केले. वर्तमान हेडच्या सिंक मूल्यावर कमाल इनिशिएलाइज करून, आम्ही याची खात्री करू शकू की ते Softmax मध्ये योग्यरित्या संचित होईल. अनुक्रम लांबीसह अनेक ब्लॉकमध्ये अटेंशन विभाजित केले गेले असल्यास, हे कमाल केवळ पहिल्या ब्लॉकमध्ये समाविष्ट केले जाईल याची खात्री करण्यासाठी आम्हाला काळजी घ्यावी लागली.

सिंक पॅरामीटर्स समाविष्ट करण्यासाठी प्रीफिल आणि डिकोड दोन्हीसाठी वापरल्या जाणाऱ्या FlashInfer FA2 कर्नल टेम्पलेटमध्ये आम्ही बदल केला आहे.

MoE

वेगवेगळ्या मॉडेल्सच्या MoE लेयरमधील मुख्य फरक सामान्यत: रूटिंग योजना असते. मोठ्या प्रमाणातील बदलाची अपेक्षा करून, ROSE हे कर्नल Triton मध्ये लागू करते, ज्यामुळे आम्हाला नवीन मॉडेल्सशी ते सहजपणे जुळवून घेता येते. GPT-OSS च्या बाबतीत, सर्व्ह मॉडेल्सवर सॉफ्टमॅक्सची गणना करणाऱ्या काही DeepSeek-शैलीतील मॉडेल्सच्या विपरीत, आम्हाला केवळ Top-K निवडलेल्या एक्सपर्ट्सवर सॉफ्टमॅक्स करण्यासाठी वजन स्कोअरिंग समायोजित करावे लागले. bfloat16 अचूकतेमध्ये एक्सपर्ट वजनांची गणना करणे अचूकतेसाठी महत्त्वपूर्ण असल्याचे आम्हाला आढळले.

बायस टर्म्ससाठी समर्थनाचा अभाव असलेल्या विद्यमान DeepGEMM कर्नल्सचा पुनर्वापर करण्याच्या आमच्या निर्णयामुळे MoE लेयरसह आव्हान निर्माण झाले होते. सुदैवाने, कालांतराने आम्ही त्यांच्याशी सखोलपणे एकरूप झालो, आमच्या कस्टम ऑल-टू-ऑल डिस्पॅच कर्नल्सशी त्यांना अधिक चांगल्या प्रकारे जोडण्यासाठी बदल केले. मेमरीमधून लोड केलेल्या बायस मूल्यांवर WGMMA एक्युमलेटर रजिस्टर इनिशिएलाइज करून आम्ही DeepGEMM मध्ये बायस समर्थन जोडले. MN ब्लॉकच्या प्रक्रियेदरम्यान ही एक-वेळची गोष्ट आहे, त्यामुळे खर्च नगण्य असण्याची शक्यता आहे आणि L2 कॅशे या मूल्यांपर्यंत कार्यक्षम प्रवेश सुनिश्चित करते.

ही मॉडेल्स डेटा पॅरालेलिझमचा सहज फायदा घेत नसल्यामुळे, आम्ही TP-फक्त डिस्पॅच आणि कम्बाइन कर्नल्सचा पुनर्वापर केला. डिस्पॅचमधील इनपुट सर्व रँकवर प्रतिकृती बनवले जातात, त्यामुळे डिस्पॅच स्थानिक पातळीवर उपलब्ध एक्सपर्ट्ससाठी टोकन्स निवडतो. कम्बाइन NVLink ओलांडून भारित संचय (weighted accumulation) करते.

कार्यप्रदर्शन सुधारणा

जरी आमचे ध्येय मॉडेल्स जलदगतीने आणणे हे होते, तरी कार्यप्रदर्शन अद्याप वाजवी असेल याची आम्हाला खात्री करायची होती. OpenAI द्वारे प्रदान केलेल्या संदर्भ अंमलबजावणीविरुद्ध अचूकता सुनिश्चित केल्यानंतर, आम्ही डीफॉल्ट PyTorch प्रोफायलर वापरून आमच्या अंमलबजावणीचे प्रोफाईल तयार केले, कर्नल्समधील ब्लॉक आणि थ्रेड वाटपावर लक्ष ठेवून. GPT-OSS मॉडेल्सच्या 2880 पेक्षा लक्षणीयरीत्या मोठे असलेल्या 7168 चे मोठे लपलेले परिमाण (hidden dimension) असलेल्या मॉडेल्ससाठी आम्ही पुनर्वापर केलेले कार्यक्षमता तयार केले होते. थ्रुपुटमध्ये लक्षणीय वाढ करत, उत्तम ग्रिड परिमाणे निवडण्यासाठी आम्ही कर्नल लाँचर्स विशेष केले.

टोकनायझेशन आणि चॅनेल

संभाषणे, तर्क सामग्री आणि फंक्शन कॉलची रचना करण्यासाठी Harmony च्या चॅट स्वरूपात अनेक महत्त्वपूर्ण संकल्पना आहेत. या स्वरूपात, प्रत्येक संदेशात एक हेडर आणि सामग्री असते:

plaintext
<|start|>{header}<|message|>{content}<|end|>

हेडर मेटाडेटा वाहून नेतो — सर्वात महत्त्वाचे म्हणजे भूमिका (सिस्टम, डेव्हलपर, वापरकर्ता, सहाय्यक, साधन), चॅनेल, आणि साधन कॉल करताना to=functions.<function-name> सारखा प्राप्तकर्ता.

चॅनेल्स (जसे की विश्लेषण, टिप्पणी आणि अंतिम उत्तर) मॉडेलचे आउटपुट अधिक पारदर्शक आणि विभागलेले बनवतात. स्वरूप हे विभाजन लागू करत असल्याने, प्रॉडक्शनमध्ये चेन-ऑफ-थॉट लीक न करता मॉडेल पारदर्शकपणे तर्क करू शकते (आणि डीबगिंगसाठी तपासले जाऊ शकते). प्राप्तकर्ता टॅग्ज (to= हेडर) रनटाइमला तंतोतंत सांगतात की पुढील पेलोड कोणत्या अभिनेत्याला प्राप्त झाला पाहिजे — मग ते फंक्शन असो, मॉडेल स्वतः असो किंवा अंतिम वापरकर्ता असो.

आमचे इन्फरन्स इंजिन ROSE स्वरूप-अज्ञेयवादी आहे. ते इनपुट टोकन्सचा एक बॅच प्राप्त करते आणि आउटपुट टोकन्स परत प्रवाहित करते. आमच्या इन्फरन्स स्टॅकमध्ये, इनपुटला टोकनाइज्ड प्रॉम्प्टमध्ये स्वरूपित करण्याचे आणि LLM परिणामांचे संरचित संदेशांमध्ये पार्स करण्याचे कार्य समर्पित JSON API फ्रंटएंड सर्व्हिसद्वारे हाताळले जाते. या फ्रंटएंडमध्ये नवीन प्लगेबल फॉर्मेटर/पार्सर जोडून आम्ही Harmony समाकलित केले, ज्यामुळे फ्रंटएंड चॅट-स्वरूप नियम, टूल कॉल्स आणि स्ट्रीमिंग व्यवस्थित व्यवस्थापित करत असताना बॅकएंड बदल न करता राहू शकतो. चिंतेचे हे विभाजन आर्किटेक्चरला मॉड्यूलर ठेवते, ज्यामुळे किमान बॅकएंड बदलांसह नवीन स्वरूप, प्रतिसाद वैशिष्ट्यांचा जलद स्वीकार सक्षम होतो.

किंमत आणि कार्यप्रदर्शन

GPT-OSS मॉडेल्सचा आकार तुलनेने लहान असल्याने, नोड्समधील संवादाचा अतिरिक्त भार टाळण्यासाठी आम्ही एका replica चे deployment एका single node वर मर्यादित ठेवतो. आमची implementation expert parallelism (EP), data parallelism (DP), आणि tensor parallelism (TP) यांचे flexible combinations support करते. सर्वोत्तम deployment setup ठरवण्यासाठी, आम्ही batch sizes 1 ते 128 पर्यंत sharding strategies च्या सर्व combinations चे benchmarking केले. Prefill-Decode Disaggregation मुळे, आम्ही prefill आणि decode साठी performance-cost trade-off वेगळे चर्चा करू शकतो.

किमतीच्या अंदाजासाठी, आम्ही $3.00/तास या नाममात्र H200 बाजार दराचे गृहीत धरतो (टीप: ही आमची वास्तविक GPU किंमत नाही).

आम्हाला आढळले की batch_size=1 आणि DP=1 सेट केल्याने सर्वोत्तम प्रीफिल कार्यप्रदर्शन मिळते. भिन्न TP कॉन्फिगरेशन नंतर पहिल्या-टोकन लेटन्सी आणि किंमत यांच्यात भिन्न ट्रेड-ऑफ प्रदान करतात. खालील सारण्या विविध कॉन्फिगरेशन आणि इनपुट लांबीसाठी प्रीफिल लेटन्सी आणि प्रति दशलक्ष इनपुट टोकन्सची किंमत प्रस्तुत करतात.

GPT-OSS 120B:

इनपुट लांबी

8192

32768

65536

128000

EP1 DP1 TP1

0.364s, $0.037

2.421s, $0.062

7.375s, $0.094

23.902s, $0.156

EP2 DP1 TP2

0.190s, $0.039

1.245s, $0.063

3.786s, $0.096

12.116s, $0.158

EP4 DP1 TP4

0.165s, $0.067

0.900s, $0.092

2.449s, $0.125

7.165s, $0.187

EP8 DP1 TP8

0.179s, $0.145

0.839s, $0.171

2.003s, $0.204

5.119s, $0.267

समांतरता कॉन्फिगरेशन आणि इनपुट लांबी यांनुसार GPT-OSS 120B प्रीफिल विलंब आणि प्रति दशलक्ष इनपुट टोकन्सचा खर्च.

GPT-OSS 20B:

इनपुट लांबी

8192

32768

65536

128000

EP1 DP1 TP1

0.239s, $0.024

1.610s, $0.041

4.895s, $0.062

16.037s, $0.104

EP2 DP1 TP2

0.127s, $0.026

0.833s, $0.042

2.522s, $0.064

8.143s, $0.106

EP4 DP1 TP4

0.108s, $0.044

0.593s, $0.060

1.616s, $0.082

4.766s, $0.124

EP8 DP1 TP8

0.116s, $0.094

0.547s, $0.111

1.310s, $0.133

3.365s, $0.175

समांतरता कॉन्फिगरेशन आणि इनपुट लांबी यांनुसार GPT-OSS 20B प्रीफिल विलंब आणि प्रति दशलक्ष इनपुट टोकन्सचा खर्च.

डिकोडसाठी, आम्हाला आढळले की बहुतेक प्रकरणांसाठी EP4 DP1 TP4 ही सर्वोत्तम कॉन्फिगरेशन आहे. खालील चार आलेख 8192 आणि 32768 च्या अनुक्रम लांबीवर 120B आणि 20B दोन्ही मॉडेल्ससाठी डिकोड गती आणि प्रति दशलक्ष आउटपुट टोकन्सची किंमत यांच्यातील ट्रेड-ऑफ दर्शवतात.

8,192 अनुक्रम लांबीवर GPT-OSS 120B साठी फक्त डिकोड खर्च प्रति दशलक्ष आउटपुट टोकन्स विरुद्ध डिकोडिंग गती, EP1, EP2, EP4, आणि EP8 कॉन्फिगरेशन्सची तुलना.
32,768 अनुक्रम लांबीवर GPT-OSS 120B साठी फक्त डिकोड खर्च प्रति दशलक्ष आउटपुट टोकन्स विरुद्ध डिकोडिंग गती, EP1, EP2, EP4, आणि EP8 कॉन्फिगरेशन्सची तुलना.
8,192 अनुक्रम लांबीवर GPT-OSS 20B साठी फक्त डिकोड खर्च प्रति दशलक्ष आउटपुट टोकन्स विरुद्ध डिकोडिंग गती, EP1, EP2, EP4, आणि EP8 कॉन्फिगरेशन्सची तुलना.
32,768 अनुक्रम लांबीवर GPT-OSS 20B साठी फक्त डिकोड खर्च प्रति दशलक्ष आउटपुट टोकन्स विरुद्ध डिकोडिंग गती, EP1, EP2, EP4, आणि EP8 कॉन्फिगरेशन्सची तुलना.

मोठ्या 120B मॉडेलसाठी लहान 20B मॉडेलचा स्पेक्युलेटिव्ह डिकोडिंग ड्राफ्ट मॉडेल म्हणून वापरण्याचाही आम्ही विचार केला आहे. तथापि, सक्रिय केलेल्या पॅरामीटर्सची संख्या समान (3B विरुद्ध 5B) असल्यामुळे, परिणामी गती वाढ नगण्य होती.

संदर्भ

डिसअॅग्रीगेटेड प्रीफिल आणि डिकोड

अॅक्सिलरेटिंग सोनार थ्रू स्पेक्युलेशन​

लोअर लेटन्सी अँड हायर थ्रुपुट विथ मल्टि-नोड डीपसीक डिप्लॉयमेंट

​एफिशिएंट अँड पोर्टेबल मिक्चर-ऑफ-एक्सपर्ट्स कम्युनिकेशन

​pplx-kernels

DeepGEMM

FlashInfer: एलएलएम इन्फरन्स सर्व्हिंगसाठी कार्यक्षम आणि सानुकूल करण्यायोग्य अटेंशन इंजिन

अटेंशन सिंकसह कार्यक्षम प्रवाह भाषा मॉडेल्स

DeepSeek-V3 तांत्रिक अहवाल​

​OpenAI Harmony प्रतिसाद स्वरूप | OpenAI कुकबुक​

उद्धरण

BibTeX
@online{perplexity2025GptOssOnDay0,
  author = {{Perplexity} and Nandor Licker and Lequn Chen and Vladimir Zaytsev and Kevin Hu and Lauren Kolm and Jesse Dwyer},
  title = {{GPT-OSS on day 0}},
  date = {2025-08-08},
  url = {https://www.perplexity.ai/hub/blog/gpt-oss-on-day-0}
}