GPT-OSS-120B को NVIDIA GPU पर प्रति सेकंड 500 से अधिक टोकन गति से चलाने का तरीका

 (baseten.co)
7 पॉइंट द्वारा GN⁺ 2025-08-12 | 2 टिप्पणियां | WhatsApp पर शेयर करें
  • OpenAI का ओपन-सोर्स LLM GPT-OSS-120B को NVIDIA GPU वातावरण में प्रति सेकंड 500 से अधिक टोकन प्रोसेसिंग परफॉर्मेंस के साथ ऑप्टिमाइज़ किया।
  • TensorRT-LLM, vLLM, SGLang जैसे विविध इन्फरेंस फ्रेमवर्क का समानांतर परीक्षण किया गया और Hopper तथा Blackwell दोनों आर्किटेक्चर का समर्थन किया गया।
  • संगतता बग ठीक किए गए, Harmony जैसे नए response format को इंटीग्रेट किया, और KV cache-aware routing तथा Eagle-आधारित speculative decoding जैसी ऑप्टिमाइज़ेशन जोड़ी गईं।
  • Tensor Parallelism और Expert Parallelism की तुलना के बाद कम लेटेंसी पाने के लिए tensor parallelism चुना गया तथा Blackwell में TensorRT-LLM MoE backend उपयोग किया गया।
  • भविष्य में और performance सुधार के लिए छोटे draft मॉडल के साथ Speculative (पूर्वानुमान) Decoding सहित अतिरिक्त ऑप्टिमाइज़ेशन की योजना है।

परिचय

  • OpenAI के नए ओपन-सोर्स large language model GPT-OSS-120B के रिलीज़ होते ही Baseten ने टॉप परफॉर्मेंस हासिल करने की चुनौती ली।
    • Baseten, OpenAI का official launch partner है।
  • OpenRouter पर उपलब्ध वास्तविक उपयोगकर्ता डेटा से Baseten ने दिखाया कि NVIDIA GPU आधारित वातावरण में इसका प्रदर्शन अन्य विकल्पों से बेहतर था।
  • Flexible inference stack और मॉडल इंजीनियरिंग टीम की विशेषज्ञता की वजह से वे प्रति घंटे ऑप्टिमाइज़ेशन पैच तेजी से रोलआउट कर सके।
  • ब्लॉग लिखने के कुछ घंटों के भीतर भी प्रति सेकंड 100 अतिरिक्त टोकन का इज़ाफ़ा हुआ और 100% अपटाइम बरकरार रहा।

प्रदर्शन ऑप्टिमाइज़ेशन प्रयास

  • TensorRT-LLM, vLLM, SGLang जैसे विविध inference framework में testing और benchmarking किया गया।
  • Hopper, Blackwell GPU आर्किटेक्चर के साथ संगतता सुनिश्चित करने पर समानांतर काम किया गया।
  • Baseten की Flexible Inference Stack तथा प्रमुख components जैसे NVIDIA Dynamo को इंटीग्रेट किया गया।
  • KV cache-aware routing और Speculative decoding (Eagle आधारित) जैसी लगातार सत्यापित performance-optimization तकनीकों को लागू किया गया।

नीचे SOTA performance और पूर्ण context window सपोर्ट को साथ में achieve करने के मुख्य चरण दिए गए हैं।

Step 1: शुरुआती इन्फरेंस रन

  • किसी भी तरीके से शुरुआत में initial inference (baseline inference) को जितनी जल्दी हो सके रन करना ही शुरुआत थी।
  • GPU को ध्यान में रखते हुए कई इंजीनियरों ने समानांतर रूप से vLLM, SGLang, TensorRT-LLM के प्रयोग किए।
  • सबसे बेहतर परफॉर्मेंस देने वाला TensorRT-LLM जल्दी सफलतापूर्वक रन किया गया।
  • Hopper (जहाँ सबसे ज्यादा H100 GPU हैं) और Blackwell (जहाँ B200 GPU के साथ स्पीड बेहतर है) दोनों में TensorRT-LLM support सुनिश्चित किया गया।
  • Baseten Inference Runtime की लचीलापन के कारण नए आर्किटेक्चर मॉडल के अनुकूलन और stack के भीतर tools की तेज़ बदलत आसान हुई।

Step 2: संगतता बग फिक्स

  • नए मॉडल आर्किटेक्चर आने पर framework integration में अक्सर बग सामने आते हैं।
  • GPT OSS में Harmony जैसे नए response format जोड़ने से पुराने frameworks के साथ integration करते समय बग आए।
  • स्पीड और accuracy दोनों को साथ रखने के लिए बार-बार fixes व टेस्ट चलाए गए, और प्रभावी बदलाव ओपन सोर्स में contribute किए गए।
  • ग्लोबल ओपन-सोर्स कम्युनिटी के सहयोग से कई optimization paths और bug fixes तेजी से आगे बढ़ रहे हैं।

Step 3: मॉडल कॉन्फ़िगरेशन ऑप्टिमाइज़ेशन

  • OpenAI ने GPT OSS 120B के लिए उल्लेख किया है कि यह single H100 पर भी चल सकता है, लेकिन वास्तविक सेटअप में 4~8 GPU parallelism performance के लिए बेहतर है।
  • Tensor Parallelism latency पर, जबकि Expert Parallelism throughput पर मजबूत है।
    • Baseten का लक्ष्य लो लेटेंसी ऑप्टिमाइज़ेशन होने के कारण Tensor Parallelism चुना गया।
  • Blackwell पर TensorRT-LLM MoE Backend लागू करने से पुराने Triton backend की तुलना में CUDA kernel performance बेहतर हुआ।
  • Hopper और Blackwell दोनों environments के लिए अलग-अलग ऑप्टिमाइज़्ड सेटिंग्स जारी की गईं, और Model API में Blackwell-आधारित सेटिंग अपनाई गई।

अतिरिक्त performance ऑप्टिमाइज़ेशन

  • प्रथम optimization से ही SOTA स्तर का throughput और latency achieve हो गया, लेकिन अभी भी और सुधार की पर्याप्त गुंजाइश है।
  • अगला प्रमुख अपडेट होगा Speculative Decoding का introduction।
    • इस तरीके में तेज़ छोटे “draft” मॉडल संभावित टोकन generate करते हैं और मुख्य मॉडल उनका सत्यापन करता है।
    • Baseten Eagle 3 recommend करता है, लेकिन inference stack में 10 से अधिक algorithms स्थिति अनुसार लचीले तरीके से रन किए जाते हैं।
  • Speculative decoding एक साथ कई टोकन का inference करके efficient speedup देने में मदद करता है।

संबंधित पढ़ाई

2 टिप्पणियां

 
jjw951215 2025-08-12

काश किसी ने मुझे भी एक छोटा-सा प्यारा H100 दे दिया होता..
 
GN⁺ 2025-08-12
Hacker News टिप्पणी

  • widely-available H100 GPUs
    इसे इसलिए खोजते-खोजते मैं घर के पार्ट्स वाले ड्रॉअर में देखता रहा, लेकिन जितना खोजा उतना ही सवाल बढ़ता गया कि 25,000 डॉलर वाला H100 GPU आखिर है कहाँ।

    • मैंने NVIDIA के प्रोडक्ट पेज पर सीधे देखकर चेक किया कि H100 वास्तव में GPU के रूप में ही categorized है। अब लगता है कि गेमिंग-फोकस वाले लेकिन LLM inference केवल सीमित रूप से कर सकने वाले consumer-grade hardware और AI training या LLM inference को primary उद्देश्य बनाने वाले business-grade professional hardware के बीच फर्क साफ दिखाने के लिए बेहतर नामकरण की जरूरत है।
    • मैंने Ollama से 20B मॉडल को 8 पुराने TitanX कार्ड (2015 वाले) पर चलाकर देखा। Ollama ने कुल 15GB VRAM को 8 कार्ड्स में बराबर distribute कर दिया और token speed भी read speed से तेज़ थी।
    • ये GPUs किराये पर बहुत आसान से मिल जाते हैं। अगर लंबे समय तक 24/7 GPU रन नहीं करना हो, तो खरीदने की बजाय hosting किराये पर लेना कहीं ज़्यादा economical है। पर्सनल उपयोग में सबसे नए datacenter-grade कार्ड शायद ही चाहिए; उस केस में Mac Studio या Strix Halo पर्याप्त हैं, बस speed थोड़ी कम होती है।
    • इस comment की वजह से आज का दिन सच में मज़ेदार रहा। यह पूरी तरह datacenter दृष्टिकोण से लिखा गया था, और मेरे पास जो सबसे तेज़ हार्डवेयर है शायद किसी पुराने iPhone 8 से ज्यादा नहीं।
    • ‘घर में $25,000 GPU नहीं है’ का मतलब यह नहीं कि खरीदना असंभव है। मतलब बस इतना कि stock उपलब्ध और हासिल किया जा सकता है, लेकिन यह ज़रूरी नहीं कि आपके पास उसे खरीदने के लिए पैसा भी हो।
  • मैंने MacBook Pro (M4, 128GB RAM) पर अटलांटिक पार करने वाली फ्लाइट में GPT-OSS-120B चला कर देखा।
    कंटेक्स्ट विंडो छोटा हो और कुल टोकन कम हों तभी तेज़ी मिलती है। दस हजार टोकन से ऊपर जाते ही लगभग हर प्रोसेस स्लो होने लगा और queue बन गई।
    MCPs, web search और URL patch पहले ही LLM यूज़ेज़ के लिए बहुत ज़रूरी हो चुके हैं। ये फीचर न हों तो LLM utility काफी गिर जाती है।
    ऑफलाइन यूज़ के लिए पहले से सेट किए हुए CLI/TUI coding tools (opencode आदि) model के साथ reliably काम नहीं कर पाए।
    OSS मॉडल्स की अन्य quirks पहले की टिप्पणियों के अलावा भी हैं:
    • पहले Wikipedia को भी लोकल में स्टोर करके इस्तेमाल करते थे, इसलिए लगता है कि जल्द ही बहुत सारा data MCP के जरिए expose करके AI को local में ही 'web search' जैसा search करना पड़ेगा। web search का 99% उसी 100~1000 साइट्स पर होता है। कुल मिलाकर कुछ GB ही रखकर काम चल सकता है, इसलिए copyright issue अभी बाकी है।
    • पूछना चाहता हूँ कि Ollama, LMStudio या llama.cpp में से कौन-सा इस्तेमाल किया जाए ggerganov ट्वीट
    • iogpu.wired_limit_mb सेटिंग आपने कैसे की है? default पर लगभग 70% RAM यानी करीब 90GB ही GPU core इस्तेमाल कर सकता है। ज्यादा प्रयोग के लिए setting बदलनी पड़ेगी।
    • मैंने इसे M2 Max processor पर चलाया। छोटा conversation हो तो 60+ tokens/s दिखे, लेकिन लंबा होते-होते 30 तक गिर गया। मैं जानना चाहता हूँ slowdown क्यों था; लगता नहीं कि यह heat-related issue था।
    • मैं इसे compute-bound prefill (jab CPU bandwidth/compute ratio high हो) और decode के बीच का फर्क मानता हूँ। 10k context पर भी पहले token तक 0.5 सेकंड से कम लगता है।
  • कई engineers parallel में vLLM, SGLang और TensorRT-LLM चला रहे हैं। TensorRT-LLM शायद सबसे fast हो, लेकिन setup करना आमतौर पर सबसे कठिन है, latest architecture support ठीक से reflect नहीं होता, और production-जैसे hardware-driver-library stack पर मॉडल सीधे compile करना पड़ता है, जो बहुत cumbersome है। एक समय multimodal लगभग impossible था; flagship Llama multimodal मॉडल तक ठीक से काम नहीं कर पा रहे थे। value है भी कि नहीं, यह सवाल है; उदाहरण के लिए GPT-OSS-120B को H100 पर vLLM से चलाने पर बिना issue के ठीक से चलता है और token output steady 130~140 t/s देता है। शीर्षक देखकर लगता था कि एक GPU पर 500 t/s मिलेगा, पर असल में वह tensor parallel setup है। gpt-oss के लिए TRT-LLM अलग से package करना थोड़ा मज़ाकिया-सा लगता है। TRT-LLM खुद भी थोड़ा confusing tool है।
    • अगर TRT-LLM का DX angle देखें तो चुनौतियाँ ज़्यादा हैं। multimodal में अभी भी vLLM ही ज्यादा use होता है। फिर भी हमारे service traffic की तरह भारी और low-latency environment में benchmarks में TRT-LLM बार-बार बेहतर रहा, इसलिए इस tooling में हमने काफी निवेश किया।
  • GPT-OSS 20B की installation सच में आसान है। Llama की वजह से मैं इसे अपने Mac पर 5 मिनट में चला पाया।
    • अगर CPU resources पर्याप्त हों तो 120B चलाना कठिन नहीं। घर पर LLM CPU inference server के लिए GGUF file डाउनलोड करो, git pull करके फिर llama-server rebuild करो, और बस चल पड़ा। बिना बदलाव के 40t/s मिला, थोड़ा सा tune करने पर लगभग 50t/s भी मिल गया। अफसोस कि 120B से बेहतर कई models पहले ही आ चुके हैं, इसलिए इसे चलाना शायद जरूरी नहीं। ggerganov और llama.cpp टीम ने जो काम करके LLM को personal computing में democratize किया है, वह सच में शानदार है।
    • लोग कहते हैं LLM सेट करना कठिन होता है। क्या LLM से सेटअप नहीं करवा सकते? अगर इतनी simple चीज़ भी नहीं हो पाए तो LLM का मतलब क्या रह जाता है?
    • कल चलाकर देखा तो हर session में तथ्य गलत आते रहे। speed और convenience बढ़िया हैं, लेकिन अगर accuracy की बलि चढ़े तो कोई फ़ायदा नहीं।
    • अगर memory पर्याप्त हो तो 120B सच में बहुत आसान चल जाता है।
  • पढ़ते-पढ़ते समझ आया कि मॉडल को ठीक से चलाने के लिए भारी pre-processing और tuning की जरूरत पड़ती है। मुझे पहले नहीं पता था कि यह इतना भारी काम है; मैं समझा था कि default सेटिंग्स पर ही ठीक से चल जाएगा।
    • मेरा मानना है कि बड़ी कंपनियों को LLM रिलीज़ से पहले ही popular inference-engine developers के साथ aggressively collaborate कर के अपने LLM support में शामिल करना चाहिए। अभी सब कुछ experimental है शायद, लेकिन developers सच में बड़ा प्रयास कर रहे हैं ताकि LLM को low-cost hardware पर भी चलाया जा सके।
  • US AI Action Plan में open source और open-weight AI encourage करने वाला पॉइंट, frontier AI से free expression और US values protect करने वाले पॉइंट के ठीक नीचे आता है। पूरी तरह logical नहीं लगता, लेकिन इस समय OpenAI OSS मॉडल पढ़ना थोड़ा uncanny महसूस होता है। फिर भी OSS मॉडल डेवलपर्स द्वारा hardware पर चर्चा अच्छी लगी। अधिकांश developers के लिए hardware अभी भी entry barrier है, इसलिए यह topic सुनना अच्छा लगा।
    • इसमें frontier AI और US values protect करने वाली लाइन भी थी, पर मैं अभी अपनी राय को organize कर रहा हूँ, इसलिए थोड़ा समय दें। AI मॉडल में worldview तो होता ही है, और मुझे personal तौर पर पश्चिमी worldview ज़्यादा पसंद है। इससे बेहतर society बने हैं इसके उदाहरण भी बहुत हैं। कम से कम मॉडल अपना worldview document करके उसी पर चलना चाहिए, ताकि user पर धीरे-धीरे social engineering के नाम पर सोच थोपने की कोशिश न हो।
  • क्या किसी को कोई साइट पता है जो साफ बताए कि OS और GPU के हिसाब से कौन-सा LLM मॉडल अच्छी तरह चलता है। VRAM अंदाज़ा लगाने का सबसे भरोसेमंद empirical formula मेरे पास यही था: parameters × (Precision/8) × 1.2 (संदर्भ)
    • मैं भी इसी तरह का calculator बनाना चाहता था, लेकिन वास्तविकता में variables (जैसे concurrent traffic आदि) बहुत ज्यादा होते हैं। वह formula लगभग सही है, लेकिन high concurrent traffic हो तो 2x factor लेना safe लगता है।
    • huggingface में hardware/software specs डालने पर, प्रत्येक मॉडल के detail page पर उस मॉडल की availability दिखाने वाला विकल्प है huggingface सेटिंग्स
    • मेरी इंटरनेट speed अच्छी है, इसलिए मॉडल वेट फाइलें डाउनलोड करके सीधे कई runners (llama.cpp, LM Studio, vLLM, SGLang आदि) पर चलाना सबसे तेज़ रहा। runner/implementation/hardware जैसे variables इतने ज्यादा हैं कि कोई भी calculator सीधे वास्तविक अनुभव से match नहीं हुआ। तरीका बस खुद रन करके देखना है।
    • आपके input के लिए धन्यवाद। अगर calculation मुश्किल लगे तो शायद community एक DB साइट बना सकती है जहाँ runner, hardware, मॉडल, parameters, quantization, काम करता है/नहीं, tokens/s जैसे metrics को लोग experiment करके share करें। अगर hardware/runner combo के हिसाब से filter करके सीधे उपयोगी entries मिल जाएं तो बहुत practical होगा।
  • GPT-OSS-120B मॉडल का वास्तविक array-size जैसा सटीक डेटा खोज पाना अपेक्षा से ज़्यादा कठिन लगा। यदि भाषा static type की होती तो अंदाज़ा लगा सकते थे, लेकिन मैं देखना चाहता था कि real data (weights के अलावा) कैसे flow करती है और output stream कितनी wide है। gigabit Ethernet पर token output bandwidth की max कितनी t/s हो सकती है—यही जानना चाहा, इसलिए मैं GitHub repo gpt-oss देख रहा था, लेकिन ठीक से दिखा नहीं।
    • मुझे यह जानना है कि कौन से use-cases सभी continuous tokens पर logits को streaming तरीके से process करना चाहते हैं, जबकि sampling भी protocol के हिसाब से हो। साथ ही यह भी सोचना होता है कि सामान्यतः आगे की inference में जाने से पहले sampling के पहले logits post-process और token return होना चाहिए।
    • huggingface मॉडल सेटिंग्स में 2880 values दिखती हैं (dtype multiplication)।
  • GPT-OSS fp4 support की वजह से Blackwell chips पर तेज़ चलता है। मैं Rust में training/inference engine बना रहा हूँ और cudarc व candle में fp8, fp4 support जोड़ रहा हूँ। cudarc PR, candle PR, और Mixlayer engine में इन्हें support देने के लिए यही काम चल रहा है।
    • मैं RTX Pro 6000 यूज़र हूँ और पूछना चाहता हूँ कि अभी gpt-oss-120b inference शायद संभव है या नहीं। लगता तो है कि PR पहले ही merge हो चुके हैं, बस देखना चाहता हूँ कि practical रन तो कर पाऊँगा या नहीं.