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 पर इन मॉडलों को सर्व करने पर ध्यान केंद्रित करते हैं, जिसमें कर्नेल परिवर्तन, परिनियोजन विकल्प और गति-लागत संबंधी ट्रेड-ऑफ का विवरण दिया गया है।

Hopper पर GPT-OSS

ओपन-वेट मॉडल MXFP4 क्वांटाइजेशन का उपयोग करके शिप किए जाते हैं, जो उन्हें उपभोक्ता-ग्रेड हार्डवेयर पर फिट होने या NVIDIA Blackwell पर अधिकतम थ्रूपुट प्राप्त करने में मदद करता है। हालाँकि, प्रारंभिक मूल्यांकन के लिए, हम उन्हें न्यूनतम इन्फरेंस-इंजन परिवर्तनों के साथ मौजूदा H200 Hopper क्लस्टर पर चलाना चाहते थे। Hopper में समर्पित FP4 टेन्सर कोर नहीं हैं, जिन्हें Blackwell द्वारा पेश किया गया था। परिणामस्वरूप, हमने कस्टम कर्नेल की आवश्यकता को कम करने और उपलब्ध हार्डवेयर का सर्वोत्तम उपयोग करने के लिए मॉडलों को FP8 प्रिसिजन के साथ सर्व करने का निर्णय लिया।

उच्च स्तर पर, ट्रांसफॉर्मर LLM संरचनात्मक रूप से सरल हैं:

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

ट्रांसफॉर्मर परतों का एक क्रम। प्रत्येक में एक अटेंशन ब्लॉक, और एक डेंस MLP या स्पार्स MoE ब्लॉक शामिल होता है।

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

जब कोई नया ट्रांसफॉर्मर मॉडल लाया जाता है, तो हम मुख्य रूप से यह जानने में रुचि रखते हैं कि आवश्यक परिवर्तनों की पहचान करने के लिए वे मौजूदा मॉडलों से किस हद तक मेल खाते हैं। OpenAI ने समय से पहले अपने मॉडलों का अवलोकन साझा किया, जिससे हमें अपने इन्फरेंस सेटअप को तदनुसार समायोजित करने की अनुमति मिली। हमने पाया कि मॉडल को वास्तव में कई छोटे परिवर्तनों की आवश्यकता थी।

अटेंशन: अटेंशन सिंक के साथ GQA

प्रत्येक अटेंशन हेड में एक प्री-ट्रेंड सिंक पैरामीटर होता है जिसे सॉफ्टमैक्स में शामिल किया जाता है

YaRN पोजीशनल एन्कोडिंग, DeepSeek-V3 के समान

QKV प्रोजेक्शन में बायस हैं, Qwen 2 के समान

आउटपुट प्रोजेक्शन में बायस है

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

SwiGLU एक्टिवेशन फंक्शन, जो अधिकांश ओपन-वेट मॉडलों से अलग है

एक्सपर्ट वेट्स के लिए Top-K के बाद सॉफ्टमैक्स

एक्सपर्ट्स में बायस होते हैं

पैरामीटरों की संख्या लगभग 100B-200B होने की अपेक्षा करते हुए, हमने निर्णय लिया:

अटेंशन सिंक का समर्थन करने के लिए FlashInfer का विस्तार करना

DeepSeek-V3 मॉडल परिवार के लिए पहले से निर्मित MoE इम्प्लीमेंटेशन का पुन: उपयोग करना

क्वांटाइजेशन स्कीम के रूप में FP8 128x128 ब्लॉक स्केलिंग को चुनना, और बायस टर्म का समर्थन करने के लिए DeepGEMM कर्नेल का विस्तार करना।

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

हमारे इन्फरेंस प्रयास हमारे इन-हाउस इन्फरेंस इंजन, ROSE द्वारा समर्थित हैं। हम ROSE को एक लचीले फ्रेमवर्क के रूप में बना रहे हैं जो नए मॉडलों को जल्दी से लाने की अनुमति देता है। इसके अतिरिक्त, एक बार जब हम किसी मॉडल को बड़े पैमाने पर सर्व करने के लिए प्रतिबद्ध हो जाते हैं, तो यह अत्याधुनिक प्रदर्शन तक पहुँचने के लिए इसे अनुकूलित और बढ़ावा देने के लिए एक मंच प्रदान करता है।

ROSE एक LLM इंजन को एक्सपोज करता है, जो एक मॉडल को लोड कर सकता है और इसके लिए कई डिकोडर के माध्यम से डिकोड किए गए टोकन उत्पन्न कर सकता है, जिसमें सट्टा (speculative) और MTP डिकोडर शामिल हैं। मॉडल स्वयं परतों के एक कस्टम सेट से बने होते हैं, जो क्वांटाइजेशन और समानता के लिए विभिन्न कॉन्फ़िगरेशन का समर्थन करते हैं। परतों के नीचे, यह Triton और CUDA दोनों कर्नेल को बंडल करता है जो व्यक्तिगत परतों द्वारा किए गए कंप्यूटेशन को कुशलतापूर्वक लागू और फ्यूज करते हैं।

ROSE मुख्य रूप से Python में बनाया गया है और मॉडल परिभाषाओं के लिए PyTorch पर निर्भर करता है। जबकि Python हमें लचीले होने और नए मॉडलों के अनुकूल होने की अनुमति देता है, हम अधिकांश प्रदर्शन-संवेदनशील घटकों, जैसे सर्विंग और बैच शेड्यूलिंग, को Rust में माइग्रेट कर रहे हैं।

एक नया मॉडल लाने के लिए, हम पहले मॉडल पदानुक्रम को परिभाषित करते हैं और इसके लिए एक वेट कन्वर्टर बनाते हैं। सभी वेट्स का लेखा-जोखा होने के बाद, हम सरलतम TP=1 उपयोग के मामले के लिए एक फॉरवर्ड पास परिभाषित करते हैं और सुनिश्चित करते हैं कि यह एंड-टू-एंड काम करता है। अंत में, हम एक नया कंटेनर जारी करने और मूल्यांकन के लिए क्लस्टर पर मॉडल तैनात करने से पहले विभिन्न प्रकार की समानता (parallelism) के लिए समर्थन लागू और परीक्षण करते हैं। इसके बाद हम डैशबोर्ड और सूक्ष्म बेंचमार्क दोनों से फीडबैक पर भरोसा करते हुए प्रदर्शन पर काम करते हैं।

ROSE संख्यात्मक टोकन पर संचालित होता है, और एकीकरण परीक्षणों के बाहर चैट प्रारूपों का बहुत कम ज्ञान रखता है। समानांतर में, हमें Harmony टोकेनाइज़र का समर्थन करने और इनपुट टोकन अनुक्रमों के लिए अनुरोधों को सही ढंग से मैप करने के लिए आसपास के इन्फ्रास्ट्रक्चर को समायोजित करने की दिशा में देखना पड़ा।

GPT OSS मॉडल के साथ, हमने पाया कि हमारे डिकोडर, CUDA ग्राफ हार्नेस या आसपास के इन्फ्रास्ट्रक्चर में किसी बदलाव की आवश्यकता नहीं थी, जिससे हमें मॉडल का समर्थन करने वाले कर्नेल को ट्विक करने पर अपने प्रयासों को केंद्रित करने की अनुमति मिली।

GPT-OSS के लिए कर्नेल

सिंक अटेंशन

सिंक अटेंशन सॉफ्टमैक्स से पहले एक अतिरिक्त बायस कारक पेश करता है, जो Q और K के उत्पाद के साथ संचित होता है:

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

जबकि एक सरल इम्प्लीमेंटेशन काफी सामान्य है, प्रभावी अटेंशन इम्प्लीमेंटेशन, जैसे कि FlashInfer, स्वतंत्र हेड्स और KV अनुक्रम लंबाई दोनों में अटेंशन की गणना को समानांतर (parallelize) करते हैं। इसके अतिरिक्त, संख्यात्मक स्थिरता के लिए, सॉफ्टमैक्स की गणना ऑनलाइन की जाती है जबकि संख्यात्मक स्थिरता के लिए अधिकतम तत्व को घटाया भी जाता है:

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

ऑनलाइन इम्प्लीमेंटेशन ने एक रनिंग मैक्सिमम m को ट्रैक किया, जिसे -inf पर इनिशियलाइज़ किया गया था, और एक स्केल d को 1 पर। मैक्सिमम को वर्तमान हेड के सिंक मान पर इनिशियलाइज़ करके, हम यह सुनिश्चित करेंगे कि यह सॉफ्टमैक्स में सही ढंग से जमा हो जाए। हमें यह सुनिश्चित करने के लिए सावधानी बरतनी पड़ी कि यदि अनुक्रम लंबाई के साथ अटेंशन को कई ब्लॉकों में विभाजित किया गया था, तो यह अधिकतम केवल पहले चंक में शामिल किया जाएगा।

हमने FlashInfer FA2 कर्नेल टेम्पलेट को समायोजित किया है, जिसका उपयोग प्रीफिल और डिकोड दोनों के लिए किया जाता है, ताकि सिंक पैरामीटर शामिल किए जा सकें।

MoE

विभिन्न मॉडलों की MoE परत के बीच मुख्य अंतर आमतौर पर राउटिंग स्कीम है। पर्याप्त परिवर्तनशीलता की अपेक्षा करते हुए, ROSE इस कर्नेल को Triton में लागू करता है, जिससे हमें इसे नए मॉडलों के अनुकूल बनाने में आसानी होती है। GPT-OSS के मामले में, हमें केवल Top-K चयनित एक्सपर्ट्स में सॉफ्टमैक्स करने के लिए वेट स्कोरिंग को समायोजित करना पड़ा, जो कुछ DeepSeek-शैली के मॉडलों से अलग है जो सभी एक्सपर्ट्स में सॉफ्टमैक्स की गणना करते हैं। हमने पाया कि एक्सपर्ट वेट्स की गणना bfloat16 प्रिसिजन में करना सटीकता के लिए महत्वपूर्ण है।

MoE परत के साथ चुनौती हमारे मौजूदा DeepGEMM कर्नेल का पुन: उपयोग करने के निर्णय के कारण थी, जिसमें बायस टर्म के लिए समर्थन की कमी थी। सौभाग्य से, समय के साथ हमने उनके साथ गहराई से एकीकरण किया, जिससे उन्हें हमारे कस्टम ऑल-टू-ऑल डिस्पैच कर्नेल के साथ बेहतर ढंग से जोड़ने के लिए बदलाव किए गए। हमने मेमोरी से लोड किए गए बायस मानों में WGMMA एक्युमुलेटर रजिस्टर को इनिशियलाइज़ करके DeepGEMM में बायस समर्थन जोड़ा। MN ब्लॉक के प्रसंस्करण के दौरान यह एक बार की प्रक्रिया है, इसलिए लागत संभवतः नगण्य है और L2 कैश इन मानों तक कुशल पहुंच सुनिश्चित करता है।

चूंकि ये मॉडल डेटा समानता (Data Parallelism) से आसानी से लाभान्वित नहीं होते हैं, इसलिए हमने केवल TP डिस्पैच और कंबाइन कर्नेल का पुन: उपयोग किया। डिस्पैच के इनपुट सभी रैंकों में प्रतिकृति होते हैं, इस प्रकार डिस्पैच स्थानीय रूप से उपलब्ध एक्सपर्ट्स के लिए टोकन का चयन करता है। कंबाइन NVLink में भारित संचय (weighted accumulation) करता है।

प्रदर्शन ट्विक्स

भले ही हमारा लक्ष्य मॉडलों को जल्दी से लाना था, लेकिन हम यह सुनिश्चित करना चाहते थे कि प्रदर्शन अभी भी उचित हो। OpenAI द्वारा प्रदान किए गए संदर्भ इम्प्लीमेंटेशन के खिलाफ शुद्धता सुनिश्चित करने के बाद, हमने डिफ़ॉल्ट PyTorch प्रोफाइलर का उपयोग करके अपने इम्प्लीमेंटेशन को प्रोफाइल किया, और कर्नेल में ब्लॉक और थ्रेड आवंटन पर नजर रखी। जिस कार्यक्षमता का हमने पुन: उपयोग किया था, वह उन मॉडलों के लिए बनाई गई थी जिनमें 7168 का बड़ा हिडन आयाम था, जो GPT-OSS मॉडलों के 2880 से काफी बड़ा था। हमने बेहतर ग्रिड आयाम चुनने के लिए कर्नेल लॉन्चर को विशेष रूप से तैयार किया, जिससे थ्रूपुट में काफी वृद्धि हुई।

टोकनीकरण और चैनल

Harmony के चैट प्रारूप में बातचीत, तर्क सामग्री और फंक्शन कॉल की संरचना के लिए कई महत्वपूर्ण अवधारणाएँ हैं। इस प्रारूप में, प्रत्येक संदेश में एक हेडर और सामग्री शामिल होती है:

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

हेडर में मेटाडेटा होता है - सबसे महत्वपूर्ण रूप से भूमिका (सिस्टम, डेवलपर, उपयोगकर्ता, सहायक, टूल), चैनल, और टूल कॉल को लागू करते समय प्राप्तकर्ता जैसे to=functions.<function-name>।

चैनल (जैसे विश्लेषण, टिप्पणी, और अंतिम उत्तर) मॉडल के आउटपुट को अधिक पारदर्शी और खंडित बनाते हैं। क्योंकि प्रारूप इस अलगाव को लागू करता है, मॉडल पारदर्शी रूप से तर्क कर सकता है (और डिबगिंग के लिए निरीक्षण किया जा सकता है) बिना उत्पादन में चेन-ऑफ-थॉट को लीक किए। प्राप्तकर्ता टैग (to= हेडर) रनटाइम को ठीक बताते हैं कि किस एक्टर को अगला पेलोड प्राप्त करना चाहिए - चाहे वह कोई फंक्शन हो, मॉडल स्वयं हो, या अंतिम उपयोगकर्ता।

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

लागत और प्रदर्शन

GPT-OSS मॉडलों के अपेक्षाकृत छोटे आकार को देखते हुए, हम इंटर-नोड संचार ओवरहेड से बचने के लिए एक प्रतिकृति (replica) की तैनाती को एक ही नोड तक सीमित करते हैं। हमारा इम्प्लीमेंटेशन एक्सपर्ट पैरेललिज्म (EP), डेटा पैरेललिज्म (DP), और टेन्सर पैरेललिज्म (TP) के लचीले संयोजनों का समर्थन करता है। इष्टतम परिनियोजन सेटअप निर्धारित करने के लिए, हमने 1 से 128 तक के बैच आकारों में शार्डिंग रणनीतियों के सभी संयोजनों का बेंचमार्क किया। प्रीफिल-डिकोड डिसएग्रीगेशन के लिए धन्यवाद, हम प्रीफिल और डिकोड के लिए प्रदर्शन-लागत ट्रेड-ऑफ पर अलग से चर्चा करने में सक्षम हैं।

लागत अनुमानों के लिए, हम $3.00/घंटा की नाममात्र H200 बाजार दर मानते हैं (नोट: यह हमारी वास्तविक GPU कीमत नहीं है)।

हमने पाया कि batch_size=1 और DP=1 सेट करने से सर्वोत्तम प्रीफिल प्रदर्शन मिलता है। विभिन्न TP कॉन्फ़िगरेशन तब पहले-टोकन विलंबता (latency) और लागत के बीच अलग-अलग ट्रेड-ऑफ प्रदान करते हैं। नीचे दी गई तालिकाएँ विभिन्न कॉन्फ़िगरेशन और इनपुट लंबाई के लिए प्रति मिलियन इनपुट टोकन पर प्रीफिल विलंबता और लागत प्रस्तुत करती हैं।

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), परिणामी गति बहुत कम थी।

संदर्भ

डिसएग्रीगेटेड प्रीफिल और डिकोड

स्पेक्युलेशन के माध्यम से Sonar को तेज करना

मल्टी-नोड DeepSeek तैनाती के साथ कम विलंबता और उच्च थ्रूपुट

कुशल और पोर्टेबल मिक्सचर-ऑफ-एक्सपर्ट संचार

pplx-kernels

DeepGEMM

FlashInfer: LLM इन्फरेंस सर्विंग के लिए कुशल और अनुकूलन योग्य अटेंशन इंजन

अटेंशन सिंक के साथ कुशल स्ट्रीमिंग भाषा मॉडल

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}
}