क्या 300 उपयोगकर्ताओं के लिए self-hosted LLM server बनाना संभव है?

• Reddit /r/ollama सबरेडिट पर पोस्ट किए गए सवाल और जवाबों का संक्षेप
• 300 लोगों की एक कानूनी फर्म के सिस्टम एडमिनिस्ट्रेटर के रूप में, सभी कर्मचारियों को ChatGPT जैसे AI-आधारित दस्तावेज़ लेखन और प्रूफरीडिंग टूल देना चाहते हैं
• PII जैसी संवेदनशील जानकारी की सुरक्षा के लिए बाहरी सेवा के बजाय इन-हाउस सर्वर पर सीधे LLM होस्ट करने (login, 2FA, VPN आदि access control लागू करके) पर विचार कर रहे हैं
• मुख्य प्रश्न
  • क्या self-built LLM server वास्तव में 300 से अधिक उपयोगकर्ताओं को सपोर्ट कर सकता है?
  • अनुमान था कि कुछ PC+GPU से काम चल जाएगा, लेकिन क्या यह वास्तविकता में कम आकलन है?
  • क्या user creation/management बड़ा बोझ बन सकता है?
  • क्या मैं कोई महत्वपूर्ण बात मिस कर रहा हूँ?
• LLM क्षेत्र के विशेषज्ञ नहीं हैं, इसलिए scalability·operational burden·feasibility पर व्यावहारिक सलाह चाहते हैं

प्रमुख जवाबों का सार

1. हार्डवेयर·परफॉर्मेंस सीमाएँ और लागत

• अगर commercial model (जैसे ChatGPT) स्तर की उम्मीद है, तो करोड़ों won के बराबर का महँगा GPU cluster चाहिए होगा (अनुमान $200,000~$1,000,000+)
• open source model (30B~70B parameter class) तक downscale करने पर, परफॉर्मेंस गिरावट (latency, output quality) स्वीकार करनी पड़ेगी। 10~40 लोगों की simultaneous processing भी सीमा हो सकती है
• 10 लोगों से कम simultaneous use मानकर, gradual expansion (server बढ़ाना) की सिफारिश
• local environment की तुलना में cloud GPU rental ज़्यादा economical/flexible हो सकता है

2. PoC(पायलट) और क्रमिक approach की सिफारिश

• 1 server+1 GPU से PoC(पायलट) बनाकर, वास्तविक कार्य परिदृश्य/लोड मापने के बाद विस्तार करने की सलाह
• बड़े पैमाने पर simultaneous request आने पर queue system ज़रूरी है, और वास्तविक user concurrency 300 नहीं बल्कि 10~30 लोगों के स्तर की हो सकती है
• short term में छोटे model (3B~13B parameter) + workstation संयोजन से प्रयोग संभव

3. cloud/hybrid/वैकल्पिक विकल्प

• cloud-based LLM(API, VPS, Azure, AWS Bedrock आदि) को self-hosted infrastructure से जोड़कर, security requirement के अनुरूप hybrid architecture का प्रस्ताव
• self-hosting में security·performance·cost का बोझ बड़ा है, इसलिए व्यवहारिक रूप से ChatGPT Enterprise/Teams, Microsoft Copilot Studio जैसी commercial solution अधिक efficient हो सकती हैं
• कानूनी डेटा/PII processing के security requirement की समीक्षा आवश्यक

4. अन्य operations·management·technical issues

• user management/authentication: AD integration, OAuth, custom auth आदि से सरल बनाया जा सकता है
• model selection/tuning: वास्तविक उपयोग (जैसे document proofreading) के अनुसार medium/small open source model (LLama, Deepseek, Gemma, Qwen आदि) को टेस्ट करने की सिफारिश
• RAG, caching, load balancing आदि अतिरिक्त solutions अपनाने की संभावना पर विचार
• real usage scenario की परिभाषा और PoC के ज़रिए उपयुक्त budget/ROI की जाँच ज़रूरी

प्रतिनिधि जवाबों का संक्षेप

ithkuil

• commercial model की तुलना में open source model में performance gap बड़ा है, और 300 लोगों के पैमाने पर बहुत महँगा हार्डवेयर लग सकता है
• अगले 2 साल में hardware और open model की प्रगति की उम्मीद की जा सकती है

SlimeQ

• single instance+queue से छोटे पैमाने पर शुरू करें, usage बढ़ने पर धीरे-धीरे expand करें
• सभी 300 लोग एक साथ इस्तेमाल नहीं कर पाएँगे; पहले वास्तविक usage मापें, फिर expansion तय करें

Ok-Internal9317

• वास्तविक simultaneous users 10 से कम हो सकते हैं, और 4~5 GPU पर्याप्त भी हो सकते हैं
• long term में API cost self-owned hardware से अधिक economical हो सकती है

dyoh777

• Ollama+WebUI से आसानी से demo बनाया जा सकता है, लेकिन model quality महत्वपूर्ण है

careful-monkey

• Mac Studio + large RAM के साथ छोटे model चलाना संभव, लगभग 20token/sec की speed

tshawkins

• Microsoft Copilot Studio जैसी SaaS-आधारित solution की सिफारिश, Power Platform के भीतर integration

roman_fyseek, Cergorach, Space__Whiskey

• model VRAM limit: 1 session=1GPU, 300 simultaneous process करने के लिए 300 GPU चाहिए
• व्यवहारिक रूप से concurrent access limit, caching, hybrid structure की ज़रूरत होगी

Siderox, SandboChang, unrulywind

• PoC के लिए छोटे server से प्रयोग (उदा. 1~2 लोग/model, वास्तविक कार्य में उपयोगिता जाँच) → फिर gradual expansion की सिफारिश
• वास्तविक scenario definition/benchmarking के बाद budget और ROI validate करने की ज़रूरत

Little_Marzipan_2087, morosis1982, Daemonero

• cloud GPU rental सस्ता है और scalability भी बेहतर है, यह अक्सर इस्तेमाल किया जाने वाला समाधान है
• operations और maintenance burden को देखते हुए, hardware investment के बजाय cloud usage की सिफारिश

CtiPath, alew3, faldore, Wheynelau

• vLLM, OpenWebUI, TGI, sglang आदि high-performance open source LLM server framework की सिफारिश
• queue+load balancer architecture की सिफारिश

अन्य

• security/legal issues: cloud इस्तेमाल करने पर भी data location, encryption, compliance आदि की कड़ी समीक्षा ज़रूरी
• Mac Studio, RTX 6000 Pro, 4090 आदि कई hardware options का उल्लेख
• caching, RAG, context limit, offload आदि से load कम करने की संभावना है

निष्कर्ष सार

• self-hosted LLM server के लिए छोटे पैमाने के पायलट(PoC) से शुरू करके वास्तविक user scale/requirements/performance/cost को चरणबद्ध तरीके से validate करना ही व्यावहारिक है
• 300 concurrent users को संभालना काफी बड़े hardware/operational cost के साथ आता है, और वास्तविक use case व budget के अनुसार cloud, hybrid, commercial solution अधिक उपयुक्त हो सकते हैं
• अंततः security, cost, user experience, maintenance जैसे कई पहलुओं को समग्र रूप से विचार करना चाहिए

[xodnrdl201]

मुझे लगता है कि आपने 300 उपयोगकर्ताओं के लिए जिन reasoning क्षमताओं का मानक रखा है, उसका दायरा कुछ ज़्यादा ही व्यापक मान लिया है। अगर सच में सामान्य common sense से लेकर research paper या advanced topics तक सब कुछ संभालना है, तो यह तरीका सही हो सकता है। लेकिन अगर उन वास्तविक कामों के स्तर को देखें जिन्हें प्रोसेस करना है, तो लगभग 30B मॉडल में RAG जुड़ा हो तो ज़्यादातर काम संभाले जा सकते हैं। ऐसा लग रहा है कि base open source के सभी weights बढ़ाकर high reasoning capability पर फीचर्स को निर्भर बनाने की वजह से स्केल बहुत बड़ा हो गया है, क्या ऐसा नहीं है?? और जो चीज़ें तुरंत प्रोसेस की जा सकती हैं और दस्तावेज़ों की search/exploration हैं, उन्हें अलग-अलग फ़ंक्शन के रूप में विभाजित करना सही लगता है.
एक साथ 300 लोगों को संभालने के लिए KV cache के target token range भी, अगर प्रति उपयोगकर्ता लगभग 20000 token के quantized value के स्तर पर रखा जाए, तो काफ़ी आराम से इस्तेमाल किया जा सकता है; हो सकता है यह हिस्सा भी ज़रूरत से ज़्यादा आंका गया हो... ??
अगर सच में वे 300 लोग research paper लिखने वाले PhD स्तर के लोग नहीं हैं, तो reasoning level को high school student (14~30B) के स्तर पर रखकर, अलग-अलग आंतरिक दस्तावेज़ों को RAG logic के अनुसार उपयुक्त CoT के साथ खोजने की प्रक्रिया के रूप में सेट कर दिया जाए, तो शायद यह एक उचित लागत पर pilot operation स्तर का प्रोजेक्ट बन सकता है.

[tsboard]

ज़रूरत के चलते मैं भी उन दुर्लभ H100 GPU की 4 कार्ड लगाकर एक RAG solution बना रहा हूँ, लेकिन सिर्फ hardware में direct investment ही नहीं, बल्कि बिजली बिल और अलग-अलग cooling solution की लागत वगैरह को भी देखें तो बार-बार यही लगता है कि बस API call करना कहीं ज़्यादा बेहतर होता।

मैंने भी शुरुआत में Ollama से testing शुरू की थी, और यह देखने के बाद कि वह 3 concurrent users को भी ठीक से cover नहीं कर पा रहा था, मैं तुरंत vLLM पर चला गया और जैसे-तैसे RAG solution का setup किया, लेकिन (10 concurrent users मानें) सिर्फ इसी के लिए ही H100 GPU की 2 कार्ड लगभग पूरी तरह इस्तेमाल करनी पड़ रही हैं। Embedding और search जैसे काम भी vLLM पर खोलकर चला रहा हूँ, तो H100 की 4 कार्ड भी सच में बहुत तंग पड़ रही हैं। जबकि एक कार्ड में लगभग 90GB VRAM है, फिर भी हालत ऐसी है।

बेशक, मुझे AI की बहुत गहरी समझ नहीं है, बस विभाग की ज़रूरतें और कंपनी के अंदर के security नियमों को किसी तरह मिलाते-बिठाते हुए मैं ज़बरदस्ती करके यह सब आज़मा रहा हूँ... पर समझ नहीं आता कि क्या यह सही रास्ता है। ChatGPT Enterprise था शायद? मुझे तो वह सच में बहुत किफायती कीमत लगती है।

[chinnotching]

शायद बस एक जबरदस्त कीमत वाली जबरदस्त मशीन से काम चल जाएगा? कोई बड़ा लॉ फर्म तो खरीद ही लेगा। लेकिन फिर उसे फैक्ट्री की मशीन की तरह 24 घंटे चलाना पड़ेगा, haha

[neinomu]

ऐसा शख्स जो सिर्फ Porsche की कीमत के बारे में सोचता है और maintenance, fuel cost, insurance वगैरह के बारे में ज़रा भी नहीं सोचता।

[beepp]

स्ट्रीमिंग फीचर देने वाली चैटबॉट जैसी सेवाओं में concurrent processing के दौरान Prefill काम decode तक को प्रभावित कर देता है, इसलिए VRAM पर्याप्त होने पर भी यूज़र की नज़र में परफॉर्मेंस बहुत खराब दिखती है।

मैंने chunk prefill से जुड़े options और vLLM में experimental तौर पर दिए जाने वाले Disaggregated Prefilling फीचर भी लागू करके देखे, लेकिन फिर भी नया request आते ही पहले से generate हो रहे जवाब बीच-बीच में टूटने लगते हैं। शुरुआती डेवलपर के नज़रिए से GPU या nodes बढ़ाने के अलावा सबसे efficient तरीका क्या हो सकता है, यही जानना चाहता हूँ।

[iolothebard]

आख़िरकार—यह स्थिति पर निर्भर करती है!