Mistral Large 4 को खुद होस्ट करना: कड़वे अनुभवों से सीख

जब Mistral ने Mistral Large 4 के weights जारी किए, लगभग 1 ट्रिलियन पैरामीटर वाला मॉडल जिसमें लगभग 52 बिलियन active parameters हैं, तो मेरे इनबॉक्स में एक ही सवाल भर गया: क्या हम इसे खुद चला सकते हैं? Open weights को खुद होस्ट करना अब शौकिया सपना नहीं, बल्कि एक असली architectural विकल्प बन गया है, और इसका मतलब है कि टीमें जल्द ही कई महंगी गलतियाँ करने वाली हैं। मैंने उनमें से कई को होते देखा है। यह लेख उन्हीं सबक का निचोड़ है: practitioners self-hosting में कैसे गलती करते हैं, और हर बार सही तरीका क्या होता है।

गलती 1: "Open Weights" को "कुछ भी करने के लिए मुफ्त" समझ लेना

पहली गलती किसी GPU को छूने से पहले ही हो जाती है। Mistral Large 4 एक संशोधित MIT-style license के तहत आता है, जिसमें एक अहम प्रतिबंध है: अगर आप या आपकी affiliates model-as-a-service का कारोबार चलाते हैं, तो मॉडल का व्यावसायिक उपयोग करने से पहले Mistral से अलग commercial license लेनी होगी। किसी कंपनी के लिए जो अंदरूनी तौर पर inference चलाती है, जैसे दस्तावेज़ों का सारांश बनाना या कर्मचारियों के लिए coding assistant चलाना, यह शायद ठीक है। लेकिन जो स्टार्टअप inference को दोबारा बेचने की योजना बना रहा है, उसके लिए Mistral को ईमेल करने तक यह एक सख्त रुकावट है।

टीमें इसमें दोनों तरफ से गलती करती हैं। कुछ टीमें प्रेस रिलीज़ में "open" शब्द देखकर weights पर commercial product बना लेती हैं, और प्रतिबंध का पता funding-diligence audit के दौरान चलता है, जो सबसे बुरा समय है। वहीं कुछ टीमें ज़रूरत से ज़्यादा सावधान होकर मान लेती हैं कि लाइसेंस सभी commercial उपयोग रोकता है, जबकि असल में वह सिर्फ competing inference providers को निशाना बनाता है। उपाय उबाऊ लेकिन ज़रूरी है: अपने legal team से असली license text पढ़वाएँ, announcement post नहीं। इसे "open weights" कहें या "weight-available", यह बहस समुदाय में जोर-शोर से चलती है और उसमें दम भी है, पर engineering का फैसला इस बात से होना चाहिए कि लाइसेंस की शर्तें आपके कारोबार को असल में क्या करने देती हैं।

एक और बारीकी: यह licensing pattern अब बड़े weight releases में आम हो गया है, अपवाद नहीं। अगर आपका architecture Mistral, Qwen और दूसरे frontier-weight models के बीच बदलने पर निर्भर है, तो आपको एक बार की समीक्षा नहीं, बल्कि एक licensing matrix चाहिए। Cluster बनाने से पहले यह spreadsheet बना लीजिए।

गलती 2: Hardware का आकार marketing page से तय करना, math से नहीं

सबसे ज़्यादा पैसा यहीं बर्बाद होता है। एक engineer "1T parameters" पढ़ता है, कंपनी के server room में रखे चार H200 देखता है और सोचता है कि 540 GB VRAM काफी है। ऐसा नहीं है, और इसका कारण एक ऐसा गणित है जिसे करने में नब्बे सेकंड लगते हैं, पर जो एक तिमाही की शर्मिंदगी बचा सकता है।

BF16 precision पर एक ट्रिलियन parameters के लिए सिर्फ weights के वास्ते लगभग 2 TB memory चाहिए। 8-bit में quantize करें तो लगभग 1 TB। 4-bit पर लगभग 500–560 GB, और यह KV cache, activations और serving overhead जोड़ने से पहले की बात है। वह 540 GB का server 4-bit मॉडल तभी संभाल पाएगा जब आप छोटे context window और गिने-चुने concurrent users से संतुष्ट हों। Mixture-of-experts architecture (हर token पर 52B active parameters) प्रति token compute को हल्का करता है, पर memory पर कोई असर नहीं डालता: सभी ट्रिलियन parameters को कहीं न कहीं addressable रहना ही होगा, और MoE में expert weights अनिश्चित तरीके से इस्तेमाल होते हैं, इसलिए उन्हें CPU RAM में offload करने से latency उस तरह बर्बाद होती है जैसी dense models में नहीं होती।

उपाय यह है कि अपनी serving ज़रूरतों से पीछे की ओर काम करें, hardware से आगे की ओर नहीं। पहले target context length, concurrency और tokens-per-second तय करें, फिर वह quantization level निकालें जो आप वहन कर सकते हैं, और उसके बाद hardware। अगर नतीजा आठ H200 या NVL72-class nodes की जोड़ी निकले, और वह संख्या आपको सिहरा दे, तो ठीक है, वह सिहरन ही इस तरीके का असर है। इससे मिलती-जुलती समस्या पर हमने जब आपकी GPU का VRAM खत्म हो जाए तो क्या करें में लिखा था, और वहाँ के विकल्प (offloading, छोटे quants, छोटे मॉडल) यहाँ भी लागू होते हैं, बस datacenter के पैमाने पर।

# The 90-second sizing check before you buy anything
params = 1_000e9
for bits in (16, 8, 4, 3):
weights_gb = params * bits / 8 / 1e9
# KV cache ballpark for MoE: ~0.5-1.5 GB per 32k-token session
kv_gb = 20 * 1.0          # 20 concurrent 32k sessions
overhead_gb = weights_gb * 0.05
total = weights_gb + kv_gb + overhead_gb
print(f"{bits}-bit: weights {weights_gb:.0f} GB, total ~{total:.0f} GB")
# 16-bit: weights 2000 GB, total ~2120 GB
#  8-bit: weights 1000 GB, total ~1070 GB
#  4-bit: weights  500 GB, total  ~545 GB
#  3-bit: weights  375 GB, total  ~414 GB

ध्यान दीजिए कि सच्ची तालिका में KV cache और overhead शामिल होता है। झूठी तालिका, यानी सिर्फ weights वाली, वही तरीका है जिससे टीमें ऐसा मॉडल पाती हैं जो लोड तो हो जाता है, पर तीन से ज़्यादा users को सेवा नहीं दे पाता।

गलती 3: Quantization को मुफ्त का भोजन मानना

जब टीमें मान लेती हैं कि quantize करना होगा, तो अगली गलती यह मानना होती है कि 4-bit का मतलब है "लगभग वही मॉडल।" कभी-कभी होता है। अक्सर नहीं होता, और जो failure modes सामने आते हैं वे ठीक वही होते हैं जिनकी आपको सबसे ज़्यादा परवाह है।

जो पैटर्न मैंने बार-बार देखा है: एक टीम अपनी 4-bit deployment को MMLU-style multiple choice पर benchmark करती है, 1% गिरावट देखती है और ship कर देती है। फिर production users शिकायत करते हैं कि लंबे multi-file code refactors पटरी से उतर जाते हैं, या tool-calling JSON कम संभावना पर पर बार-बार थोड़ा बिगड़ जाता है। आक्रामक quantization उन कामों को ज़्यादा नुकसान पहुँचाता है जो लंबी दूरी के, structured और low-temperature होते हैं, यानी ठीक वही agentic और coding workloads जिनके लिए frontier model लिया जाता है। औसत लगभग नहीं हिलता; पूँछ (tail) बिखर जाती है।

उपाय यह है कि quantize उतना करें जितना आपकी task eval सह सके, न कि उतना जितना VRAM मजबूर करे। अपने workload के prompts FP8, 4-bit और 3-bit builds पर चलाकर तुलना करें। अगर 3-bit आपके evals पास कर ले, तो बधाई, आपका hardware बिल आधा हो गया। अगर फेल हो, तो कोई benchmark average आपको नहीं बचाएगा। और जब lab खुद quantized releases दे, तो उन्हें प्राथमिकता दें। Mistral ने BF16 weights के साथ NVFP4 variant भी जारी किया है, और उसकी measured quality deltas वाली first-party quant उस community GPTQ conversion से बेहतर है जिसे आपने एक दोपहर में जाँचा हो।

Quantization level एक quality budget है, compression setting नहीं। इसे वहीं खर्च करें जहाँ आपका workload नुकसान झेल सके।

गलती 4: API की कीमत को GPU की कीमत से तोलकर उसे TCO विश्लेषण कह देना

क्लासिक spreadsheet: "API की कीमत $2.10 प्रति मिलियन output tokens है, reserved GPU node की कीमत $X प्रति घंटा है, इसलिए Y tokens प्रति महीने पर self-hosting फायदेमंद है।" यह spreadsheet लगभग हमेशा गलत होती है, और गलती हमेशा महंगी दिशा में होती है।

इसमें क्या छूटता है: utilization। API आपको किसी और की capacity का 100% utilization देता है, जिसका बिल token के हिसाब से आता है। आपका self-hosted cluster उतना ही utilization देता है जितना आपका traffic pattern देता है, और ज़्यादातर अंदरूनी workloads bursty होते हैं: कारोबारी घंटों में भारी, रात में खाली, रिलीज़ के आसपास अचानक बढ़ने वाले। Peak के हिसाब से बना cluster दिन के ज़्यादातर हिस्से में आधा खाली पड़ा रहता है। फिर वे खर्च भी जोड़िए जो spreadsheet में कभी नहीं आते: on-call rotation, क्योंकि serving stack में अब vLLM upgrades, CUDA driver mismatches और सुबह 2 बजे का पेज भी शामिल है जब KV cache fragment हो जाता है; model update की भागदौड़ (क्या आप हर नए weight release को दोबारा validate करते हैं? आपकी eval suite कहती है हाँ); और उस ML engineer का opportunity cost, जो अब product बनाने के बजाय GPU की देखभाल कर रहा है।

एक moving-target समस्या भी है जिसकी कीमत कोई नहीं लगाता। Mistral ने preview और full release के बीच इस मॉडल की API कीमत लगभग आधी कर दी: input tokens $1.36 से घटकर $0.70 प्रति मिलियन हो गए। पुरानी कीमत के हिसाब से किया गया हर self-hosting ROI अब कल्पना है। Frontier inference हर तिमाही सस्ता होता जाता है, जबकि आपका hardware कई सालों के हिसाब से घिसता है। यह असमानता self-hosting के business cases की चुपचाप जान लेती है।

उपाय: सिर्फ उन कारणों से self-host करें जो API संरचनात्मक रूप से नहीं दे सकती। ऐसे कारण मौजूद हैं और असली हैं, पर "बड़े पैमाने पर सस्ता" उनमें से शायद ही कभी होता है, उन पैमानों पर जहाँ ज़्यादातर कंपनियाँ काम करती हैं।

जब Self-Hosting सच में जीतता है

तो Mistral-class weights को लोकल चलाना API से कब बेहतर है? टीमों को सही और गलत करते देखने के बाद, जीतने वाले मामले चार वर्गों में आते हैं:

• Data residency और sovereignty। नियंत्रित उद्योग, रक्षा से जुड़ा काम, और वे EU संगठन जिनकी न्यायिक सीमाएँ सख्त हैं। एक व्यावहारिक बाधा जो मैंने देखी: एक कंपनी को अनुपालन कारणों से चीनी-मूल के मॉडल इस्तेमाल करने से रोका गया था। एक यूरोपीय lab के open weights, जिनकी provenance जाँची जा सकती है, वह समस्या हल कर गए जो कोई API contract नहीं कर सका।
• Air-gapped या कभी-कभार जुड़ने वाले वातावरण। अगर नेटवर्क के भरोसे नहीं रहा जा सकता, तो लोकल weights ही पूरा architecture हैं। इस pattern पर हमने ऐसा LLM बनाना जो offline काम करे में चर्चा की थी।
• लगातार, अनुमानित और बड़ी मात्रा वाले workloads। 24/7 स्थिर throughput पर चलने वाली batch document processing सचमुच per-token pricing को मात दे सकती है, क्योंकि यह utilization की समस्या अपने आप हल कर देती है।
• Fine-tuning और बदलाव। किसी और के API में, उनके fine-tuning endpoint की सीमा से आगे fine-tune नहीं कर सकते। weights के मालिक होने का मतलब है training loop का मालिक होना: domain corpora पर continued pretraining, custom alignment, छोटे deployments के लिए distillation।

ध्यान दीजिए कि सूची में क्या नहीं है: latency। एक trillion-parameter MoE को self-host करने से वह latency नहीं मिलती जो अच्छी तरह provisioned API देती है, जब तक आप speculative decoding और batch-1 के लिए optimized serving पर भारी खर्च करने को तैयार न हों। और यह भी ध्यान दीजिए कि क्या नहीं है: "किसी vendor पर निर्भरता से बचना।" आज जो weights आप डाउनलोड करते हैं, वे एक साल में दो पीढ़ी पीछे होंगे, और आप फिर वही फैसला करने की स्थिति में होंगे। यह संयोग से उस archival सोच का अच्छा तर्क है, जिसके तहत कुछ practitioners बड़े weight releases की लोकल कॉपी रखते हैं। Storage सस्ता है; विकल्प कीमती हैं।

ईमानदार नज़रिया यह है कि open weights और APIs प्रतिस्पर्धी नहीं, पूरक हैं। मेरी जानकारी की कई टीमें hybrid चलाती हैं: bursty interactive traffic के लिए API, और नियंत्रित या batch-heavy हिस्से के लिए लोकल weights। कौशल एक जगह से दूसरी जगह काम आते हैं, आपका vLLM config, eval harness और prompt templates दोनों दुनियाओं में चलते हैं। अगर frontier scale पर उतरने से पहले आपको operational बुनियादी बातें चाहिए, तो हमारी गाइड अपने hardware पर large language models चलाना में पूरा serving stack समझाया गया है।

गलती 5: Workload के बजाय benchmarks से evaluate करना

आखिरी गलती वह है जो बाकी सब कुछ बिगाड़ देती है। एक टीम सब कुछ सही करती है, जैसे license की समीक्षा, hardware का आकार, public benchmarks पर quantization की जाँच, और फिर ऐसा मॉडल ship करती है जिससे users नफरत करते हैं, क्योंकि evals ने कभी वह नहीं मापा जो users असल में करते हैं।

Public benchmarks सवाल का जवाब देते हैं: "क्या यह मॉडल आम तौर पर सक्षम है?" वे यह नहीं बताते कि "क्या यह मॉडल हमारे support tickets को सही tone और format में, 4-bit पर, हमारे concurrency load के नीचे वर्गीकृत कर सकता है?" AI benchmarks असली काम का 90% क्यों छूट जाते हैं, इस पर हम पहले लिख चुके हैं। Self-hosting में यह अंतर कम नहीं, बल्कि और तीखा हो जाता है: अब हर वह variable आपकी जिम्मेदारी है जिसे API provider पहले संभालता था। Deployment stack, sampler settings, system prompt की वे परंपराएँ जिन पर मॉडल प्रशिक्षित हुआ था, सब कुछ आपके हाथ में है और सब कुछ गलत होने की गुंजाइश भी आपकी है।

उपाय है तीन परतों का eval, जिसे आप hardware पर प्रतिबद्ध होने से पहले बनाएँ:

1. Production से golden set। कुछ सौ असली prompts, जिनके आदर्श output की समीक्षा हो चुकी हो, और जो आपके असली task distribution को कवर करें, जिसमें लंबे, उलझे और multi-turn मामले भी शामिल हों।
2. Regression harness। हर उम्मीदवार (API बनाम लोकल, FP8 बनाम 4-bit, पुराने weights बनाम नया release) golden set पर अपने-आप चले। एक मजबूत judge model के साथ स्कोर करें और साथ में human spot review भी; structured outputs पर judge पर आँख मूँदकर भरोसा न करें।
3. Shadow period। लोकल deployment को API के साथ दो हफ्ते तक live traffic पर चलाएँ, outputs की तुलना करें और असली load के नीचे असली latency मापें। यहीं KV-cache sizing की गलतियाँ और quantization की पूँछ वाली विफलताएँ सचमुच सामने आती हैं।

यह harness तब अपनी कीमत वसूल कर देता है जब कोई नया weight release आए और आप "क्या हमें अपग्रेड करना चाहिए?" का जवाब एक दोपहर में आंकड़ों से दे सकें, न कि मीटिंग में अंदाज़ों से।

असली सबक: Open weights ने सवाल बदला, जवाब नहीं

एक साल पहले, "क्या हमें frontier model खुद होस्ट करना चाहिए?" एक काल्पनिक सवाल था, क्योंकि frontier डाउनलोड करने योग्य ही नहीं था। Mistral Large 4 ने, ट्रिलियन-parameter releases की लहर के साथ मिलकर, इसे असली पैसे वाला असली फैसला बना दिया है। लेकिन फैसले का ढाँचा नहीं बदला; बस अब वह अनिवार्य हो गया है।

Self-host तब करें जब sovereignty, connectivity, लगातार बड़ी मात्रा, या मॉडल में बदलाव की ज़रूरत उसकी माँग करे। API के लिए पैसे दें जब आपका traffic bursty हो, टीम छोटी हो, और आपकी असली पहचान product हो, inference stack नहीं। और जो भी चुनें, नब्बे सेकंड का memory गणित करें, license पढ़ें, और किसी भी चीज़ पर दस्तखत करने से पहले eval harness बना लें। Weights अब open हैं। गलतियाँ, दुर्भाग्य से, वे भी open हैं।