अपने हार्डवेयर पर LLM लोकली चलाने की असली गाइड

पिछले साल मैंने एक लोकल इन्फरेंस रिग बनाने में $4,200 खर्च किए, जो 70B पैरामीटर वाला मॉडल ठीक-ठाक स्पीड पर चला सके। एक सहकर्मी ने मेरा सेटअप देखकर वही सीधा सवाल पूछा: 'API ही क्यों न इस्तेमाल करो? यह तो लगभग आठ साल के API क्रेडिट जितना है।' गणित के मामले में वह गलत नहीं था। लेकिन हिसाब लगाने के तरीके में वह गलत था।

लार्ज लैंग्वेज मॉडल को लोकली चलाना पहले रिसर्च लैब्स के रैक-माउंटेड GPU क्लस्टर्स तक सीमित था। यह बदलाव तेज़ी से हुआ है। कंज़्यूमर हार्डवेयर, क्वांटाइज़ेशन तकनीकों और ऑप्टिमाइज़्ड इन्फरेंस इंजनों ने 70B+ मॉडल को शौक़ीन लोगों और छोटी टीमों की पहुंच में ला दिया है। Tinybox जैसे डिवाइस इससे भी आगे जा रहे हैं — ये खास तौर पर बने हार्डवेयर हैं, जो 120B पैरामीटर वाले मॉडल को बिना क्लाउड के, ऑफ़लाइन चलाने के लिए डिज़ाइन किए गए हैं।

लेकिन 'संभव' और 'व्यावहारिक' में फर्क है। आइए देखते हैं कि बड़े मॉडल लोकली चलाने में असल में क्या लगता है, यह कब समझदारी भरा है, और कब API के लिए पैसे देना बेहतर है।

हम मॉडल लोकली चलाएं ही क्यों?

API मॉडल — डेटा को क्लाउड प्रोवाइडर को भेजना और नतीजे वापस पाना — ज़्यादातर इस्तेमाल के मामलों में ठीक काम करता है। यह सरल है, कम मात्रा में प्रति क्वेरी सस्ता है, और हमेशा नवीनतम मॉडल तक पहुंच देता है। तो फिर कोई लोकल इन्फरेंस की झंझट क्यों उठाए?

प्राइवेसी और कम्प्लायंस। कुछ डेटा आपके नेटवर्क से बाहर नहीं जा सकता। मेडिकल रिकॉर्ड, कानूनी दस्तावेज़, प्रोप्राइटरी कोड, वित्तीय डेटा — रेगुलेटेड इंडस्ट्रीज़ में अक्सर डेटा की लोकेशन को लेकर सख्त नियम होते हैं। मरीज़ों के रिकॉर्ड किसी API एंडपॉइंट पर भेजना, भले ही वह एन्क्रिप्टेड हो, HIPAA का उल्लंघन कर सकता है। लोकल इन्फरेंस सब कुछ ऑन-प्रिमाइसेस रखता है।
लेटेंसी। API कॉल्स में नेटवर्क राउंड ट्रिप, संभावित क्यू इंतज़ार और रेट लिमिट्स शामिल होते हैं। लोकल इन्फरेंस में नेटवर्क लेटेंसी शून्य होती है और आप कभी क्यू में नहीं होते। इंटरैक्टिव एप्लिकेशन्स — रीयल-टाइम कोडिंग असिस्टेंट, ऑन-डिवाइस ट्रांसलेशन, वॉयस इंटरफ़ेस — के लिए 50ms और 500ms का फर्क ही 'रिस्पॉन्सिव' और 'सुस्त' के बीच का फर्क है।
बड़े पैमाने पर लागत। API प्राइसिंग प्रति टोकन होती है। कम वॉल्यूम पर यह नगण्य है। ज़्यादा वॉल्यूम पर यह तेज़ी से बढ़ती है। जो टीम भारी कोड रिव्यू, डॉक्यूमेंट एनालिसिस या बैच प्रोसेसिंग करती है, वह API पर हर महीने हज़ारों डॉलर खर्च कर सकती है। लोकल हार्डवेयर की लागत एक बार तय होती है — एक बार खरीद लिया, तो इन्फरेंस लगभग मुफ़्त है।
उपलब्धता। क्लाउड API डाउन हो जाते हैं। रेट लिमिट लग जाती है। प्राइसिंग बिना बताए बदल जाती है। मॉडल डिप्रिकेट हो जाते हैं। अगर आपका प्रोडक्ट किसी थर्ड-पार्टी API पर निर्भर है, तो आप उनके बिज़नेस फैसलों के रहम पर हैं। लोकल इन्फरेंस का मतलब है कि किसी और के सर्वर के बुरे दिन से आपकी क्षमता गायब नहीं होती।
प्रयोग की आज़ादी। API प्रोवाइडर्स के उपयोग-नियम होते हैं। वे तय करते हैं कि आप मॉडल से क्या कर सकते हैं और क्या नहीं। लोकल मॉडल पर ऐसी कोई पाबंदी नहीं — आप उन्हें फाइन-ट्यून कर सकते हैं, बदल सकते हैं, किसी भी काम में इस्तेमाल कर सकते हैं, और जितनी बार चाहें चला सकते हैं।

हार्डवेयर की असलियत

LLM इन्फरेंस की मूल बाधा कंप्यूट नहीं, मेमोरी है। किसी भी काम से पहले मॉडल के पैरामीटर्स को मेमोरी (GPU VRAM या सिस्टम RAM) में फिट होना पड़ता है। 16-bit फ्लोटिंग पॉइंट में 70B पैरामीटर वाले मॉडल को लगभग 140 GB मेमोरी चाहिए। यह किसी भी एक कंज़्यूमर GPU से ज़्यादा है।

यहीं पर क्वांटाइज़ेशन खेल बदल देता है। मॉडल वेट्स की प्रिसिशन को 16-bit से घटाकर 8-bit, 4-bit, या यहां तक कि 2-bit पर लाकर, आप मेमोरी की ज़रूरत को काफी हद तक कम कर सकते हैं:

Memory requirements for a 70B parameter model:
FP16 (full precision):  ~140 GB  → requires multiple A100s
INT8 (8-bit quant):     ~70 GB   → requires 2x RTX 4090 (48GB total)
Q4_K_M (4-bit quant):   ~40 GB   → fits on 2x RTX 3090 or 1x A6000
Q2_K (2-bit quant):     ~25 GB   → fits on 1x RTX 4090 (24GB)
For a 120B parameter model:
FP16:                   ~240 GB  → enterprise GPU territory
INT8:                   ~120 GB  → 5x RTX 4090 or purpose-built device
Q4_K_M:                 ~70 GB   → 3x RTX 4090
Q2_K:                   ~40 GB   → 2x RTX 4090

4-bit क्वांटाइज़ेशन (llama.cpp इकोसिस्टम में Q4_K_M) इस वक्त सबसे अच्छा संतुलन है। क्वालिटी में गिरावट मापी जा सकती है, पर व्यावहारिक इस्तेमाल के लिए अक्सर स्वीकार्य होती है — ज़्यादातर लोग ब्लाइंड टेस्ट में Q4 आउटपुट को फुल प्रिसिशन से अलग नहीं पहचान पाते। 2-bit क्वांटाइज़ेशन क्वालिटी पर साफ असर डालता है, खासकर रीज़निंग-भारी कामों में, लेकिन टेक्स्ट क्लासिफिकेशन या समरीज़ेशन जैसे सरल एप्लिकेशन्स के लिए अब भी काम करता है।

कंज़्यूमर हार्डवेयर बिल्ड्स

अगर आप अपना लोकल इन्फरेंस सेटअप बना रहे हैं, तो आपके पास तीन बुनियादी रास्ते हैं, और हर एक की प्राइस-परफॉर्मेंस अलग है।

सिंगल GPU रास्ता

एक RTX 4090 (24 GB VRAM, लगभग $1,600) 4-bit क्वांटाइज़्ड मॉडल को लगभग 30B पैरामीटर तक आराम से चला सकता है, या आक्रामक 2-bit क्वांटाइज़ेशन पर 70B मॉडल। ज़्यादातर 7B–13B मॉडल के लिए तो यह ओवरकिल है — आपको 40+ टोकन प्रति सेकंड मिलेंगे, जो ज़्यादातर लोगों की पढ़ने की रफ्तार से भी तेज़ है। यह सबसे आसान रास्ता है: GPU खरीदें, llama.cpp या Ollama इंस्टॉल करें, और शुरू हो जाएं।

मल्टी-GPU रास्ता

दो या उससे ज़्यादा GPU आपको मॉडल को कई डिवाइसेज़ में बांटने (tensor parallelism) देते हैं। दो RTX 3090 (कुल 48 GB VRAM, लगभग $2,200 यूज़्ड) आराम से 4-bit 70B मॉडल चला सकते हैं। पेच यह है: आपको ऐसा मदरबोर्ड चाहिए जिसमें पर्याप्त PCIe lanes हों, और कई फुल-साइज़ GPU के लिए जगह भी। एयरफ्लो एक असली चिंता बन जाता है — केस में दो 350W GPU बहुत गर्मी पैदा करते हैं।

यूनिफाइड मेमोरी रास्ता

बड़ी यूनिफाइड मेमोरी वाले Apple Silicon Mac एक हैरान करने वाला व्यावहारिक विकल्प हैं। 192 GB यूनिफाइड मेमोरी वाला M2 Ultra पूरे प्रिसिशन वाले 70B मॉडल को पूरी तरह मेमोरी में फिट कर सकता है। इन्फरेंस की स्पीड डेडिकेटेड GPU से धीमी है — 70B मॉडल के लिए शायद 10-15 टोकन प्रति सेकंड — पर सादगी को हराना मुश्किल है। कोई ड्राइवर समस्या नहीं, कोई मल्टी-GPU कॉन्फ़िगरेशन नहीं, कोई थर्मल मैनेजमेंट नहीं। बस आपकी डेस्क पर रखा Mac Studio, जो 70B मॉडल चला रहा है।

M-सीरीज़ चिप्स यह यूनिफाइड मेमोरी आर्किटेक्चर से हासिल करती हैं: CPU और GPU एक ही मेमोरी पूल शेयर करते हैं, इसलिए CPU RAM और GPU VRAM के बीच डेटा कॉपी करने की कोई रुकावट नहीं होती। मेमोरी बैंडविड्थ डेडिकेटेड GPU सेटअप से कम है, इसीलिए इन्फरेंस धीमा है, लेकिन 60 वॉट में चलने वाले डिवाइस में 192 GB एड्रेसेबल मेमोरी होना सच में प्रभावशाली है।

पर्पस-बिल्ट इन्फरेंस डिवाइस

सबसे नई श्रेणी है पर्पस-बिल्ट लोकल इन्फरेंस हार्डवेयर — ऐसे डेडिकेटेड डिवाइस जो खास तौर पर बड़े मॉडल को कुशलता से चलाने के लिए बनाए गए हैं। ये मल्टी-GPU की झंझट खत्म करने का लक्ष्य रखते हैं: कंज़्यूमर GPU को केबल मैनेजमेंट के दुःस्वप्न के साथ जोड़ने के बजाय, आपको एक ऐसा एप्लायंस मिलता है जो शुरू से इन्फरेंस के लिए डिज़ाइन किया गया है।

इसका आकर्षण साफ है। आप उसे प्लग इन करते हैं, अपनी एप्लिकेशन को उसकी ओर इंगित करते हैं, और वह आपका मॉडल चलाता है। कोई ड्राइवर कॉन्फ्लिक्ट नहीं, CUDA वर्ज़न मैनेजमेंट नहीं, और किसी ने तीन GPU बहुत पास रख दिए इसलिए थर्मल थ्रॉटलिंग नहीं। ट्रेड-ऑफ़ लागत है — पर्पस-बिल्ट डिवाइस आमतौर पर समान कंज़्यूमर GPU की तुलना में प्रति FLOP महंगे होते हैं। आप इंटीग्रेशन, भरोसेमंदता, और PCIe lane allocation डीबग न करने की कीमत चुका रहे हैं।

छोटी कंपनियों के लिए, जिन्हें लोकल इन्फरेंस चाहिए पर जिनके पास हार्डवेयर इंजीनियर नहीं हैं, ये डिवाइस समझदारी भरे हैं। जिन शौक़ीनों को चीज़ें खुद बनाना पसंद है, उनके लिए DIY मल्टी-GPU रिग अब भी सस्ते और ज़्यादा लचीले हैं।

सॉफ्टवेयर स्टैक

हार्डवेयर कहानी का सिर्फ आधा हिस्सा है। इन्फरेंस सॉफ्टवेयर स्टैक तेज़ी से विकसित हुआ है, और सही सॉफ्टवेयर चुनने से उसी हार्डवेयर पर आपका थ्रूपुट दोगुना हो सकता है।

llama.cpp — लोकल इन्फरेंस का स्विस आर्मी नाइफ़। C/C++ में लिखा गया, Raspberry Pi से लेकर मल्टी-GPU सर्वर तक हर चीज़ पर चलता है। दर्जनों मॉडल आर्किटेक्चर और क्वांटाइज़ेशन फ़ॉर्मेट सपोर्ट करता है। हमेशा सबसे तेज़ नहीं, पर सबसे पोर्टेबल और सक्रिय रूप से मेंटेन किया जाने वाला है।
vLLM — NVIDIA GPU पर थ्रूपुट के लिए ऑप्टिमाइज़्ड। GPU मेमोरी कुशलता से मैनेज करने के लिए PagedAttention का इस्तेमाल करता है, जो बैच्ड इन्फरेंस को नाटकीय रूप से बेहतर बनाता है। अगर आप एक ही मशीन से कई यूज़र्स को सर्व कर रहे हैं, तो vLLM आमतौर पर सबसे अच्छा विकल्प है।
Ollama — 'LLM के लिए Docker' वाला तरीका। llama.cpp को मॉडल रजिस्ट्री वाले यूज़र-फ्रेंडली इंटरफ़ेस में लपेटता है। ollama run llama3:70b चलाइए और यह मॉडल डाउनलोड करता है, क्वांटाइज़ेशन कॉन्फ़िगर करता है, और सर्व करना शुरू कर देता है। शुरुआत के लिए शानदार, पर कच्चे llama.cpp से कम कॉन्फ़िगरेबल।
MLX — Apple का मशीन लर्निंग फ्रेमवर्क, जो Apple Silicon के लिए ऑप्टिमाइज़्ड है। अगर आप M-सीरीज़ Mac पर हैं, तो MLX आमतौर पर llama.cpp से बेहतर परफॉर्मेंस देता है, क्योंकि यह यूनिफाइड मेमोरी आर्किटेक्चर का ज़्यादा प्रभावी उपयोग करता है।

# Getting started with Ollama (the easiest path)
# Install: https://ollama.ai
# Run a 7B model (downloads automatically, ~4GB)
$ ollama run mistral
# Run a 70B model (needs ~40GB RAM/VRAM)
$ ollama run llama3:70b-instruct-q4_K_M
# Serve as an API endpoint (OpenAI-compatible)
$ ollama serve
$ curl http://localhost:11434/v1/chat/completions \
-H 'Content-Type: application/json' \
-d '{
"model": "mistral",
"messages": [{"role": "user", "content": "Explain TCP handshakes"}]
}'

ईमानदार लागत तुलना

चलिए वह गणित करते हैं जो असल में मायने रखता है। मान लीजिए आप 70B मॉडल चला रहे हैं और रोज़ लगभग 10 लाख टोकन प्रोसेस कर रहे हैं (यानी लगभग 50-100 दस्तावेज़ों के एनालिसिस या कुछ सौ चैट बातचीत संभालने के बराबर)।

Cloud API (approximate pricing for 70B-class model):
Input:  $0.50 per million tokens
Output: $1.50 per million tokens
Daily cost: ~$2.00
Monthly cost: ~$60
Yearly cost: ~$720
Local inference (2x RTX 4090 build):
Hardware: $4,200 (one-time)
Electricity: ~$30/month (assuming 700W, 8h/day, $0.15/kWh)
Break-even: ~5.5 years
Local inference (Mac Studio M2 Ultra 192GB):
Hardware: $5,800 (one-time)
Electricity: ~$3/month (60W)
Break-even: ~8 years

रोज़ 10 लाख टोकन पर क्लाउड API कई सालों तक सस्ता है। लेकिन अगर आपका वॉल्यूम बढ़ता है तो यह हिसाब नाटकीय रूप से बदल जाता है। रोज़ 1 करोड़ टोकन पर API की लागत सालाना $7,200 होती है और लोकल हार्डवेयर लगभग 7 महीनों में अपनी लागत निकाल लेता है। रोज़ 5 करोड़ टोकन पर लोकल इन्फरेंस कुछ हफ्तों में खुद का भुगतान कर देता है।

लागत तुलना में गैर-वित्तीय पहलू छूट जाते हैं: प्राइवेसी, लेटेंसी, उपलब्धता और प्रयोग की आज़ादी। अगर इनमें से कोई भी ज़रूरत है (सिर्फ 'अच्छा होता' नहीं), तो वित्तीय तुलना दूसरे नंबर पर आ जाती है।

क्वांटाइज़ेशन में क्या खो जाता है

क्वांटाइज़ेशन ही बड़े मॉडल के लिए लोकल इन्फरेंस को संभव बनाता है, पर यह मुफ़्त नहीं है। प्रिसिशन घटाने का मतलब है कुछ जानकारी खोना, और यह नुकसान हर काम में एक जैसा नहीं होता।

मेरे टेस्ट में 4-bit क्वांटाइज़्ड मॉडल फुल प्रिसिशन के लगभग बराबर प्रदर्शन करते हैं: टेक्स्ट जनरेशन, समरीज़ेशन, सरल Q&A, ट्रांसलेशन, और आम पैटर्न के लिए कोड जनरेशन। गिरावट इन पर दिखती है: जटिल मल्टी-स्टेप रीज़निंग, गणितीय गणना, ट्रेनिंग डेटा को सटीक याद रखने वाले काम, और बारीक इंस्ट्रक्शन फॉलोइंग।

व्यावहारिक निष्कर्ष यह है: अगर आप लोकल मॉडल कोड कम्प्लीशन, डॉक्यूमेंट समरीज़ेशन, या conversational AI के लिए इस्तेमाल कर रहे हैं, तो 4-bit क्वांटाइज़ेशन पूरी तरह ठीक है। अगर आप इसे जटिल विश्लेषणात्मक रीज़निंग या ऐसे कामों के लिए इस्तेमाल कर रहे हैं जहां बारीक सटीकता का फर्क मायने रखता है, तो ध्यान से टेस्ट करें और शायद ज़्यादा प्रिसिशन अपनाएं, जिसकी कीमत ज़्यादा मेमोरी या छोटे मॉडल के रूप में चुकानी होगी।

फैसला कैसे लें

एक साल तक मॉडल लोकली चलाने के बाद, लोकल और क्लाउड इन्फरेंस के बीच चुनने का मेरा ढांचा यह है:

क्लाउड API तब इस्तेमाल करें जब: आपको सबसे बेहतरीन मॉडल क्वालिटी चाहिए, आपका वॉल्यूम कम से मध्यम है, आपके पास हार्डवेयर विशेषज्ञता नहीं है, आपको बार-बार मॉडल बदलने पड़ते हैं, या लेटेंसी उतनी अहम नहीं (कुछ सौ मिलीसेकंड चल जाएंगे)।

लोकली चलाएं जब: आपका डेटा आपके नेटवर्क से बाहर नहीं जा सकता, आपको लगातार 100ms से कम लेटेंसी चाहिए, आपका टोकन वॉल्यूम हार्डवेयर लागत को जायज़ ठहराने लायक ऊंचा है, आप प्रति क्वेरी लागत के बिना खुलकर प्रयोग करना चाहते हैं, या आपको तीसरे पक्ष के अपटाइम से स्वतंत्र इन्फरेंस उपलब्धता चाहिए।

यह परिदृश्य तेज़ी से बदल रहा है। मॉडल छोटे और ज़्यादा कुशल हो रहे हैं। क्वांटाइज़ेशन तकनीकें बेहतर हो रही हैं। हार्डवेयर सस्ता हो रहा है। वह वॉल्यूम सीमा, जिस पर लोकल इन्फरेंस आर्थिक रूप से समझदारी भरा बन जाता है, हर साल घट रही है। अगर आज यह आपके लिए समझदारी भरा नहीं है, तो अठारह महीनों में हो सकता है — और तब तक सॉफ्टवेयर स्टैक इस्तेमाल में और आसान हो चुका होगा।