Ask HN: अगर ChatGPT 70 करोड़ लोगों को सेवा दे सकता है, तो मैं एक भी GPT-4 को लोकल में क्यों नहीं चला सकता?

 (news.ycombinator.com)
13 पॉइंट द्वारा GN⁺ 2025-08-09 | 3 टिप्पणियां | WhatsApp पर शेयर करें
  • Sam Altman ने घोषणा की कि ChatGPT हर हफ्ते लगभग 70 करोड़ उपयोगकर्ताओं को संभालता है
  • GPT-4 स्तर के मॉडल को लोकल में चलाने पर VRAM की कमी और स्पीड में गिरावट गंभीर होती है, इसलिए यह जानने की जिज्ञासा है कि OpenAI इतनी बड़ी मात्रा के उपयोग को कम latency और high performance के साथ कैसे संभालता है
  • सिर्फ साधारण GPU cluster से आगे बढ़कर model optimization, distributed processing, dedicated hardware, और load balancing techniques के बारे में जानना चाहता है

मुख्य टिप्पणियों का सार

1. अल्ट्रा-लार्ज distributed inference संरचना

  • मॉडल शार्डिंग(Model Sharding)
    • पैरामीटर कई GPU में बाँटकर स्टोर किए जाते हैं
    • रिक्वेस्ट आने पर हर GPU अपने हिस्से के पैरामीटर पर computation करता है और फिर परिणाम जोड़े जाते हैं
  • टेंसर पैरेललिज़्म(Tensor Parallelism)
    • एक ही layer के अंदर का computation कई GPU समानांतर रूप से करते हैं
  • पाइपलाइन पैरेललिज़्म(Pipeline Parallelism)
    • layers को कई चरणों में बाँटकर pipeline की तरह क्रमिक और साथ-साथ प्रोसेस किया जाता है
  • मिश्रित parallel processing से GPU memory और computation load को optimize किया जाता है

2. मेमोरी और स्पीड optimization

  • क्वांटाइज़ेशन(Quantization): पैरामीटर को कम bit precision में बदलकर VRAM उपयोग घटाना
  • लेयर ऑफलोडिंग(Offloading): ज़रूरत पड़ने पर कुछ layers को CPU memory में भेजना
  • LoRA / Adapter Layers: सिर्फ विशेष tasks को fine-tuning करके पूरे मॉडल को दोबारा reload करने की ज़रूरत नहीं
  • KV caching(Key-Value Caching): context को दोबारा इस्तेमाल करके बार-बार की computation हटाना

3. dedicated hardware और networking

  • नवीनतम NVIDIA H100, A100, और कुछ TPU का बड़े पैमाने पर उपयोग
  • GPU के बीच NVLink और NVSwitch, तथा clusters के बीच Infiniband से ultra-fast data transfer
  • data centers के बीच global backbone network बनाकर latency को न्यूनतम करना

4. geographic distribution और load balancing

  • दुनिया भर के कई regions में GPU farm तैनात
  • GeoDNS के ज़रिए user requests को सबसे नज़दीकी region से जोड़ा जाता है
  • traffic patterns के आधार पर GPU clusters को dynamically scale up/down किया जाता है
  • किसी खास region पर load बढ़ने पर global traffic redistribution

5. request processing optimization

  • Batch Inference: कई users की requests को एक साथ बाँधकर inference चलाना
  • छोटे मॉडल से pre-processing: सरल requests छोटे मॉडल से संभालना, सिर्फ जटिल requests पर बड़े मॉडल को बुलाना
  • result caching: समान prompt या मिलती-जुलती requests के परिणाम cache से तुरंत लौटाना
  • prompt engineering से अनावश्यक token की बर्बादी रोकना

6. operations और cost optimization

  • GPU utilization monitoring और scheduling से idle resources को न्यूनतम करना
  • data center power efficiency बढ़ाना और liquid cooling अपनाना
  • अपने compiler और runtime optimization से inference speed बढ़ाना
  • model update और deployment के लिए automated pipeline चलाना

समग्र architecture flow का उदाहरण

  1. user request प्राप्त → GeoDNS से नज़दीकी region की routing
  2. pre-processing → सरल requests छोटे मॉडल को, जटिल requests बड़े मॉडल को
  3. distributed inference processing
    • model sharding + tensor parallel + pipeline parallel लागू
    • GPU के बीच high-speed network से intermediate results का आदान-प्रदान
  4. post-processing और result caching → समान या मिलती-जुलती requests के लिए cache store
  5. response return → 1~2 सेकंड के भीतर परिणाम प्रदान

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

3 टिप्पणियां

 
popkins 2025-08-11

OpenAI के मामले में inference के लिए सिर्फ Nvidia hardware ही नहीं, बल्कि AMD का MI300X भी इस्तेमाल हो रहा है; training में भले ही सिर्फ Nvidia हो।
Inference में वे किसी भी तरह investment cost के मुकाबले VRAM सुरक्षित करने के लिए बेताब हैं।
Microsoft के मामले में भी यही है; inference के लिए वे Nvidia और AMD को मिलाकर इस्तेमाल कर रहे हैं।
 
popkins 2025-08-11

खासकर एशिया वाले Azure region में OpenAI जो AMD इस्तेमाल करता है, उसका अनुपात लगभग
NVIDIA 8 / AMD 2 है
 
GN⁺ 2025-08-09
Hacker News राय

  • मैं Google में ऐसे सिस्टम्स को सीधे संभालने का काम करता हूँ (यह मेरी निजी राय है) और यह पक्के तौर पर कह सकता हूँ कि बहुत होशियार लोग इस समस्या के हर पहलू पर गंभीरता से सोचते हैं। मैं इससे ज़्यादा नहीं बता सकता, लेकिन अपने सहकर्मियों द्वारा लिखी गई सामग्री साझा करना चाहूँगा। accelerator architecture और high-speed optimization के बारे में शानदार व्याख्या scaling book में मिलती है। खासकर अगर inference के बारे में जानना चाहते हैं, तो inference chapter मददगार है। इसके अलावा unsloth guide भी सुझाऊँगा। यह अलग-अलग models में गहराई से जाकर optimizations ढूँढता है और उन्हें अच्छी तरह व्यवस्थित करके पेश करता है। Gemma 3n guide के अलावा भी कई guides हैं

    • इसे थोड़ा कम रहस्यमय तरीके से समझाएँ तो inference ज़्यादातर stateless काम है। इसलिए training की तरह लाखों machines के बीच memory consistency या machine failure की चिंता नहीं करनी पड़ती। बस थोड़ा data बहुत बड़ी machines तक अच्छे से पहुँचाना होता है। जहाँ मैं काम करता था, वहाँ research machines 8 GPU वाले ultra-high-performance machines थे, और अगर model कुल मिलाकर VRAM में फिट हो जाए, तो कोई भी काम ठीक से हो जाता था। बड़े पैमाने पर scale करने का गुप्त ingredient था 'बहुत बड़ी मात्रा में पूंजी'। NVIDIA ने हमें कभी gold-plated DGX machines भी भेजी थीं, लेकिन वे dense नहीं थीं और बहुत महंगी थीं। ज़्यादातर बड़ी कंपनियों के पास reliable RPC और orchestration systems होते हैं, इसलिए असली मुश्किल messaging नहीं, बल्कि model को उस hardware पर फिट करना है जहाँ वह चलेगा (यह मेरा core expertise नहीं है)

    • आधुनिक large-scale inference racks, अच्छी तरह ज्ञात RDMA और low-latency networking techniques, मज़बूत MLA और cache optimizations को किसी रहस्यमय तकनीक की तरह पेश करने की ज़रूरत नहीं है। ये चीज़ें पहले से सार्वजनिक रूप से अच्छी तरह समझी जा चुकी हैं, और कई बार बड़ी कंपनियों में बहुत custom कुछ करना legacy compatibility की वजह से उल्टा बोझ बन जाता है। असल में महत्वपूर्ण बात है बड़े systems चलाने के लिए ज़रूरी discipline और processes का होना। इसमें equipment procurement, SRE training, और नए TPU के लिए RTL तक सब शामिल है। अगर कोई 10x आगे निकल जाए, तो सबको तुरंत पता चल जाएगा (10 साल का TOP-5 large-scale inference अनुभव रखने वाला व्यक्ति)

    • "हम ऐसे होशियार लोग हैं जो हर समस्या पर बहुत गंभीरता से सोचते हैं" वाली बात को देखें तो, असल में यह 1970s mainframe-style time-sharing system जैसा ही है

    • मुझे यह जिज्ञासा है कि क्या TPU की वजह से Google के अपने model inference की profitability, NVIDIA cards किराए पर लेने की तुलना में बहुत बेहतर होगी। मेरी समझ से OpenAI ज़्यादातर Microsoft partnership के जरिए GPU हासिल करता है। लिंक और किताब दोनों दिलचस्प लगीं

    • "आजकल 'छोटे' models भी hardware limits के बेहद करीब चल रहे हैं" यह पंक्ति ध्यान खींचने वाली थी। यह 60s और 70s के उस वाक्य जैसा लगता है कि "छोटे programs भी hardware limits के हिसाब से चलते हैं"। भले ही software engineering में optimization और efficiency कम हो गई हो, LLM development में वह अब भी ज़िंदा है

  • एक H100 की कीमत $20,000 है और उसमें 80GB VRAM है। आप कल्पना कर सकते हैं कि एक 2U rack server में ऐसी cards के $100,000 लगे हों। अगर ऐसा equipment पूरे rack में हो, और उसमें CPU, RAM, cooling सब जोड़ दें, तो एक rack की कीमत लगभग $1 million होती है (operating cost और maintenance staff अलग हैं)। 'सस्ता' equipment भी यहाँ बहुत बड़े scale की unit में आता है। मुझे उम्मीद है कि जब AI bubble फूटेगा, तब अच्छे local models को realistically चलाना संभव होगा। 10 साल बाद शायद ऐसे $100,000 servers eBay पर $3,000 में मिलें, और electricians को garage या अस्थायी server room में 240V power लगाने के अनुरोध मिलें

    • 10 साल इंतज़ार करने की भी ज़रूरत नहीं, DGX-1 अभी eBay पर $10,000 से कम में खरीदा जा सकता है। इसमें 256GB VRAM(HBM2), NVLink, 512GB RAM, 40-core CPU, 8TB SSD, और 100Gbit HBA है। non-NVIDIA branded products $6,000 में भी मिल सकते हैं। लेकिन यह बेहद भारी है, कल्पना से भी ज़्यादा शोर करता है, और एक machine लगभग पूरा 240V 16A circuit खा जाती है। साथ ही यह प्रति घंटे 13,000 BTU heat भी पैदा करती है

    • AI bubble न भी फूटे, तब भी संभावना है कि ये servers 10 साल बाद eBay पर आ जाएँगे। data centers hardware upgrade करेंगे और पुराना सामान third parties को बेचेंगे

    • निजी तौर पर मुझे शक है कि open models हमारी सोच से कहीं कम compute इस्तेमाल करते हैं। नए Mixture of Experts models में top-k sampling, यानी कुछ experts (parameters) को ही activate करके evaluate करने की वजह से, SOTA models भी non-MoE 70-80B models की तुलना में बहुत ज़्यादा compute नहीं माँगते

    • enterprise स्तर की AI serving में असली सवाल "users को कैसे serve करेंगे" नहीं, बल्कि यह है कि investors किसी दिन ROI की उम्मीद करेंगे। जितनी infrastructure चाहिए, उतनी investment आती रहे तो बनाई जा सकती है। optimization न भी हो, तो ज़रूरत पड़ने पर जितने warehouse और racks चाहिए, बना कर service दी जा सकती है

    • मैं अमेरिकी नहीं हूँ, इसलिए 240V वाली बात मज़ेदार लगी

  • आपके पास अगर कुछ हज़ार डॉलर हैं, तो उनके पास दसियों अरब डॉलर हैं। scale का अंतर 1,000 बनाम 10,000,000,000 है। उनकी efficiency भी scale की वजह से एक-दो orders of magnitude बेहतर है। और MacBook (24GB RAM) पर भी ऐसे local models चलाए जा सकते हैं जिनका performance GPT-4 launch के शुरुआती दौर के बराबर है। performance comparison link

    • 700 million users को अगर एक दिन या एक हफ़्ते में time-distribute कर दें, तो वास्तविकता में शायद केवल 10 million sessions ही एक समय पर active हों। individual user एक हफ़्ते की computing resources जमा करके एक साथ इस्तेमाल नहीं कर सकता, लेकिन service provider horizontal scaling के जरिए सिर्फ peak को match करता है। इसलिए समान performance requirement पर local setup को कहीं ज़्यादा hardware चाहिए होता है

  • एक ही GPU node बहुत high FLOPs और memory bandwidth दे सकता है। जब requests कम हों, तो अक्सर GPU compute units तक RAM से weights stream होने का इंतज़ार ही करता रहता है। लेकिन जब requests को batch में बाँधकर चलाते हैं, तो एक बार weights पढ़कर कई requests को parallel process किया जा सकता है, जिससे efficiency बहुत बढ़ जाती है। इसके अलावा model को 8-bit या उससे कम format में compress करके stream होने वाले data को घटाया जा सकता है, और आधुनिक GPU 8-bit/4-bit computation support करते हैं। Mixture of Experts models हर token पर सिर्फ कुछ parameters का इस्तेमाल करते हैं, इसलिए कम weights लाने पड़ते हैं। speculative decoding तकनीक में एक छोटा model पहले कई tokens का अनुमान लगाता है, और फिर main model उनमें से सिर्फ वही स्वीकार करता है जो उससे मेल खाते हों। ये सारी optimizations मिलकर शानदार efficiency देती हैं (Databricks inference team director के अनुभव पर आधारित)

  • OpenAI के secret sauce में से एक है अरबों डॉलर का loss। 2024 में उसने $5 billion गंवाए। संबंधित लेख

    • आजकल agentic approaches आने से स्थिति काफ़ी बदल गई है। पहले 1 request पर 1 processing होती थी, अब एक task पर सैकड़ों processing एक साथ चलती हैं। इस parallelism की वजह से OAI/Azure को local models पर बढ़त मिलती है

    • अगर R&D हटा दें और सिर्फ मौजूदा models serve करें, तो शायद break-even संभव हो सकता है

    • आपने सही core point पकड़ा। Microsoft का $10 billion तक का investment pretraining, R&D, और inference cost को cover करने के बाद भी multi-billion loss बना रहा। यह VC-style, growth-oriented capitalism का ढाँचा है

  • बड़े पैमाने के inference में requests को batch करके एक साथ चलाना, individual users को अलग-अलग GPU allocation देने की तुलना में कहीं ज़्यादा efficient है। अगर medium-level engineering tricks जाननी हों, तो हमारी team ने Fin AI blog पर जो लिखा है, उसे देखें। (OpenAI वगैरह शायद इसके अलावा कुछ private techniques भी इस्तेमाल करते होंगे) संबंधित पोस्ट

    • यही असली जवाब है। ऊपर की कई चर्चाओं से ज़्यादा batching ही वह चीज़ है जो लागत को बहुत नीचे लाती है। उदाहरण के लिए अगर एक request को process करने में $50,000 लगते हों, तो batching की वजह से लगभग बिना किसी नुकसान के उसी $50,000 में 100 requests एक साथ process की जा सकती हैं। असल में एक hardware पर कितने users संभाले जा सकते हैं, यह मुझे नहीं पता, लेकिन शायद सैकड़ों के स्तर पर होगा। यानी प्रभावी लागत $50,000 से घटकर $500 तक आ सकती है (अगर पर्याप्त users हों)। LLM processing में bottleneck ज़्यादातर weights को GPU पर लाने का समय होता है, इसलिए हर request को अलग-अलग चलाने के बजाय कई requests की computation साथ में करने से efficiency अधिकतम होती है। मान लें कि 3 weight sets (A, B, C) GPU cache में फिट होते हैं, और 2 requests (1, 2) हैं। सामान्य तरीका होगा कि हर request के लिए weights फिर से लोड किए जाएँ, लेकिन batching में एक बार weights लाकर कई requests पर computation की जाती है। weight loading time और compute time की तुलना करें तो batching से पहले और बाद का speed difference बहुत बड़ा दिखता है। वास्तविक दुनिया में weight loading, computation की तुलना में बहुत धीमा होता है, इसलिए users बढ़ने पर यह अंतर और बढ़ता है। व्यवहार में ज़्यादा users को serve करने के लिए activation-state memory भी चाहिए, इसलिए यह संतुलन बनाना पड़ता है कि एक GPU cluster पर कितने users रखे जाएँ। निष्कर्ष यह है कि LLM serving hardware बहुत महँगा है, लेकिन अगर आपके पास वह है, तो सैकड़ों users को लगभग बिना performance loss के एक साथ serve किया जा सकता है

  • सिर्फ यह कहना कि साप्ताहिक 700 million users हैं, असल load के बारे में बहुत कम बताता है। ज़्यादातर ChatGPT users अगर हर दिन एक घंटा, पूरे हफ़्ते भी इस्तेमाल करें, तब भी 96% समय system खाली रहेगा। बहुत से लोग कम complex models ही इस्तेमाल करते हैं। 'weekly users' का ज़िक्र करने का मतलब ही यह है कि daily active users में भी कुछ लोग दिन में एक बार भी इस्तेमाल नहीं करते। असली चुनौतियाँ हैं 1) ऐसे servers बनाना जिनमें model memory में फिट हो और tokens पर्याप्त speed से process हो सकें, 2) peak aggregate token throughput के हिसाब से पर्याप्त servers रखना, 3) सभी requests को efficiently servers में distribute/trap करना। इसमें कई details हैं, लेकिन आख़िरी समस्या कुछ हद तक search engine चलाने जैसी लगती है। सारी state chat history में होती है, इसलिए ज़रूरी नहीं कि उसी chat को हमेशा वही server संभाले। जब "Thinking..." दिखता है, तब यह साफ़ नहीं होता कि model सचमुच compute कर रहा है या queue में server का इंतज़ार कर रहा है

  • बड़े scale पर LLM को अच्छे से चलाने का सबसे बड़ा राज़ों में से एक है 'batch size'। आजकल ज़्यादातर LLM "Mixture of Experts" architecture का उपयोग करते हैं, जिसमें कुल parameters का सिर्फ एक हिस्सा ही हर पल activate होता है। इससे बड़े batches को चलाना बहुत efficient हो जाता है। अगर आप घर पर GPT-4 चलाना चाहें, तो पूरा model VRAM में लाने के लिए H100 जैसी कई GPUs चाहिए होंगी (एक की कीमत लगभग $40,000)। लेकिन व्यक्तिगत usage से ऐसी cards का पूरा उपयोग नहीं हो पाता। यह कुछ वैसा है जैसे पूछना: “Apple अरबों लोगों के लिए iPhone बना सकता है, लेकिन मैं अपने garage में एक भी क्यों नहीं बना सकता?”

    • सार यह है कि inference load बहुत सारे users में अच्छी तरह बँट जाता है, इसलिए system efficient चलता है

    • तो क्या ऐसा design संभव है जिसमें कम इस्तेमाल होने वाले parts main memory में हों और अक्सर इस्तेमाल होने वाले parts VRAM में रखे जाएँ?

    • यह analogy बहुत सटीक है

  • एक trick जो घर पर भी लागू की जा सकती है और Cerebras की performance में महत्वपूर्ण भूमिका निभाती है, वह है speculative decoding। इसमें एक बहुत छोटे draft model से बहुत कम compute और memory के साथ tokens का अनुमान लगाया जाता है, और main model उनमें से वही tokens स्वीकार करता है जिन्हें वह खुद भी चुनता। अच्छे setup में इससे 3x तक speedup मिल सकता है। structured output के मामले में "fast forwarding" भी लागू किया जा सकता है, जहाँ predictable tokens को skip करके JSON जैसी outputs का शुरुआती format पहले से भर दिया जाता है, और इससे भी 3x तक speed बढ़ सकती है

    • LM Studio में gpt-oss-120b और gpt-oss-20b को मिलाकर speculative drafting आज़माया जा सकता है। हालाँकि, मुझे महसूस नहीं हुआ कि performance में बहुत बड़ा फ़र्क आया हो

  • LLM inference का मूल matrix-vector multiplication है। जब कई queries को एक साथ process करना हो, तो हर query के vectors को इकट्ठा करके matrix बनाया जा सकता है और फिर matrix-matrix multiplication के ज़रिए सबकी गणना एक साथ की जा सकती है। hardware के नज़रिए से matrix-vector multiplication को बार-बार करने के बजाय एक matrix-matrix multiplication कहीं ज़्यादा efficient होता है। यही batching है। दूसरी trick speculative decoding है। inference में prompt processing और token generation के दो चरण होते हैं, और दोनों असल में समान संरचना वाले 'forward pass' ही हैं। prompt processing को matrix-matrix multiplication से parallel किया जा सकता है, और उसके आख़िरी result से token generation शुरू होती है। लेकिन भविष्य के tokens पहले से पता नहीं होते, इसलिए आम तौर पर इसे parallel नहीं किया जा सकता। इसलिए एक तेज़ draft model आगे के N tokens का अनुमान लगाता है, उन्हें input prompt में जोड़ दिया जाता है, और फिर main model से parallel forward pass चलाया जाता है। उत्पन्न हुए N tokens में से पहला mismatch आने तक के सारे matching tokens सीधे valid tokens के रूप में निकाले जा सकते हैं। सिद्धांततः इससे 2~4x तक inference speedup की उम्मीद की जा सकती है। मैंने इसे खुद production work में implement नहीं किया है, लेकिन मेरा अनुमान है कि इसके अलावा query length के हिसाब से parallel grouping या real-time load balancing जैसी तकनीकें भी लगाई जाती होंगी (क्योंकि सभी requests एक ही length की नहीं होतीं, और resource imbalance रोकने के लिए यह ज़रूरी है)