Self-host करने के लिए बेस्ट AI models कैसे चुनें

कौन से AI models को आप self-host कर सकते हैं, यह क्या तय करता है

आप किन AI models को self-host कर सकते हैं, यह केवल एक संख्या तय करती है: आपके सर्वर की RAM। मॉडल की फैमिली और फ्रेमवर्क इस बात से कहीं कम मायने रखते हैं कि क्या मॉडल के weights मेमोरी में फिट होते हैं और उसके बाद भी जगह बचती है या नहीं। यह पोस्ट इस गणना को समझने के लिए है। रनटाइम इंस्टॉल करना एक अलग काम है, जिसे Ollama को VPS पर चलाने की गाइड में कवर किया गया है।

दो लागतें इस उत्तर को निर्धारित करती हैं। Weights एक निश्चित लागत (fixed cost) हैं, जो पैरामीटर की संख्या और क्वांटाइजेशन (quantisation) द्वारा तय होती है। कॉन्टेक्स्ट विंडो (context window) एक चालू लागत (running cost) है, और यही वह चीज है जिसे लोग तब तक भूल जाते हैं जब तक कि कल लोड हुआ मॉडल आज लोड होने से मना न कर दे।

आकार की गणना: प्रति पैरामीटर बिट्स

मॉडल फ़ाइल लगभग पूरी तरह से वेट्स (weights) से बनी होती है। प्रत्येक वेट को कुछ निश्चित बिट्स में स्टोर किया जाता है। क्वांटाइजेशन (quantisation) का अर्थ है उन्हें उस प्रिसिजन (precision) से कम बिट्स में स्टोर करना जिस पर उन्हें ट्रेन किया गया था। इससे सटीकता में थोड़ी कमी आती है, लेकिन मेमोरी की काफी बचत होती है। फ़ाइल का आकार सीधे इसी से निर्धारित होता है:

weights in GB = (parameters in billions x bits per weight) / 8

मॉडल 16 बिट्स पर रिलीज किए जाते हैं, जो प्रति बिलियन पैरामीटर 2 GB के बराबर है। यही कारण है कि लगभग कोई भी VPS पर रिलीज प्रिसिजन का उपयोग नहीं करता है। ये वे क्वांटाइजेशन हैं जो आपको वास्तव में मिलेंगे, साथ ही प्रति वेट उनके वास्तविक औसत बिट्स:

• Q8_0 प्रति वेट लगभग 8.5 बिट्स स्टोर करता है, यानी प्रति बिलियन पैरामीटर लगभग 1.1 GB।
• Q6_K लगभग 6.6 बिट्स स्टोर करता है, यानी प्रति बिलियन लगभग 0.83 GB।
• Q5_K_M लगभग 5.7 बिट्स स्टोर करता है, यानी प्रति बिलियन लगभग 0.71 GB।
• Q4_K_M लगभग 4.8 बिट्स स्टोर करता है, यानी प्रति बिलियन लगभग 0.6 GB।

अपनी गणना के लिए प्रति बिलियन पैरामीटर 0.6 GB का उपयोग करें। मेमोरी की कमी वाले सर्वर पर Q4_K_M एक उचित डिफॉल्ट है: अधिकांश कार्यों में 8 बिट्स की तुलना में गुणवत्ता का नुकसान कम होता है, और फ़ाइल का आकार लगभग आधा हो जाता है। 4 बिट्स से नीचे जाने पर नुकसान तेजी से बढ़ता है, इसलिए 2 बिट्स पर कंप्रेस किया गया 70B मॉडल आमतौर पर उसी जनरेशन के 4 बिट्स वाले 32B मॉडल से खराब परिणाम देता है। जब मेमोरी कम हो, तो 4 बिट्स से नीचे जाने के बजाय मॉडल का आकार (size class) कम करें।

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

ऊपर दिया गया वेट कॉलम प्रति बिलियन 0.6 GB के नियम पर आधारित है। वास्तविक GGUF फ़ाइलें इसके कुछ प्रतिशत के भीतर ही रहती हैं, क्योंकि एम्बेडिंग और आउटपुट लेयर्स को बाकी हिस्सों की तुलना में उच्च प्रिसिजन पर रखा जाता है। 4 बिट्स पर 3B मॉडल लगभग 1.8 GB का होता है। 8B मॉडल 4.8 GB का होता है। 32B मॉडल 19.2 GB का होता है, और 70B मॉडल 42 GB का होता है।

Context length के लिए weights की तुलना में अधिक RAM की आवश्यकता क्यों होती है

KV cache (key value cache, वह attention state जिसे model conversation में मौजूद हर token के लिए सुरक्षित रखता है) दूसरा मुख्य खर्च है। इसे model load होते समय allocate किया जाता है, जिसका आकार आपके द्वारा मांगी गई context length के अनुसार तय होता है, और यह उस length के साथ सीधे अनुपात में बढ़ता है।

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

Ollama के default context पर, वह 8B model cache पर आधा gigabyte खर्च करता है। 8192 tokens पर यह 1 GB खर्च करता है। 128k context पर, जिसका विज्ञापन model card में दिया गया है, यह 16 GB खर्च करता है, जो weights से तीन गुना अधिक है। 70B model इसके विपरीत है: 128k पर इसकी cache 40 GB है, जो इसके weights से कम है, क्योंकि grouped query attention प्रति token लागत को parameter count की तुलना में बहुत धीमी गति से बढ़ने देता है।

CPU-only server पर Ollama की default context length 4096 tokens है। जब GPU मौजूद होता है, तो यह VRAM के आधार पर default चुनता है: 24 से 48 GiB के बीच 32k, और 48 GiB या उससे अधिक पर 256k। इसे server पर OLLAMA_CONTEXT_LENGTH variable के साथ बढ़ाएं, फिर जांचें कि चल रहे model को वास्तव में ollama ps के CONTEXT column में क्या मिला है। उस एक setting के पीछे की memory गणना num_ctx और context length पर पोस्ट में विस्तार से समझाई गई है।

cache की memory वापस पाने के दो तरीके हैं। model card द्वारा विज्ञापित context के बजाय केवल उस context की मांग करें जिसकी आपको आवश्यकता है, क्योंकि अधिकांश chat और coding कार्य 8k से 32k के भीतर पूरे हो जाते हैं। या फिर cache को ही 8 bits में quantise करें, जिससे यह आधी हो जाती है, हालांकि इससे long context recall पर कुछ प्रभाव पड़ सकता है।

रेसिडेंट मॉडल उस RAM को तब तक होल्ड करके रखता है जब तक कोई उसे अनलोड न कर दे

Ollama अंतिम अनुरोध के बाद 5 मिनट तक मॉडल को मेमोरी में रखता है, और फिर उसे अनलोड कर देता है। यह डिफ़ॉल्ट सेटिंग लैपटॉप के लिए उपयुक्त है, लेकिन सर्वर के लिए गलत है, जहाँ हर idle गैप के बाद आने वाले पहले अनुरोध पर फिर से लोड होने का समय लगता है।

ollama ps
ollama stop qwen3:4b

ollama ps यह सूची दिखाता है कि क्या रेसिडेंट है, जिसमें SIZE कॉलम यह दर्शाता है कि यह कितनी मेमोरी ले रहा है और UNTIL कॉलम यह दिखाता है कि यह कब एक्सपायर होगा। किसी मॉडल को स्थायी रूप से पिन करने के लिए, सर्विस पर OLLAMA_KEEP_ALIVE=-1 सेट करें। 0 का मान हर रिस्पॉन्स पूरा होते ही उसे अनलोड कर देता है।

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

एक प्रॉम्प्ट भेजें, फिर दस मिनट बाद दोबारा ollama ps चलाएं। मॉडल अभी भी सूची में है, और यही इसका मुख्य उद्देश्य है: यह उस RAM को होल्ड करके रखता है, चाहे कोई इसका उपयोग कर रहा हो या नहीं। एक पिन किया गया मॉडल अतिरिक्त क्षमता (spare capacity) नहीं है। 16 GB के VPS पर, 8k कॉन्टेक्स्ट वाला 8B मॉडल लगभग 6 GB मेमोरी लेता है जब तक सर्विस चलती है। इसलिए सर्वर का आकार केवल मॉडल के आधार पर नहीं, बल्कि मॉडल और आपके एप्लिकेशन की कुल आवश्यकता के अनुसार तय करें। मेमोरी में मॉडल को पिन करना कोल्ड स्टार्ट लेटेंसी के मुकाबले इसके ट्रेड-ऑफ को कवर करता है।

4 GB VPS पर क्या चलता है

ऑपरेटिंग सिस्टम और मॉडल सर्वर के लिए लगभग 1 GB सुरक्षित रखें, जिससे लगभग 3 GB मेमोरी शेष बचती है। यह 4-बिट पर 1B से 4B मॉडल और डिफ़ॉल्ट 4096 टोकन कॉन्टेक्स्ट के लिए पर्याप्त है। अगस्त 2026 तक, इस श्रेणी में Llama 3.2 (3B), Qwen 3 (1.7B और 4B), तथा छोटे Gemma और Phi रिलीज़ शामिल हैं। इन्हें केवल आकार के उदाहरण मानें, अनुशंसाएं नहीं। मॉडल के नाम कुछ महीनों में बदलते रहते हैं, लेकिन गणित वही रहता है।

लगभग 6 से 14 टोकन प्रति सेकंड की गति की अपेक्षा रखें। इतने छोटे मॉडल सीमित कार्यों में अच्छा प्रदर्शन करते हैं: वर्गीकरण (classification), टैग निकालना, संक्षिप्त सारांश, और किसी पैराग्राफ को एक विशिष्ट शैली में फिर से लिखना। ये बहु-चरणीय तर्क (multi-step reasoning) और कई फाइलों में फैले कोड के लिए कमजोर हैं, और किसी भी प्रकार की प्रॉम्प्टिंग इसे ठीक नहीं कर सकती।

इस स्तर पर विफलता का मुख्य कारण swap है। यदि मॉडल मेमोरी में फिट नहीं होता है, तो Linux उसे लोड करने से मना नहीं करता है। इसके बजाय, यह मेमोरी को डिस्क पर पेज (page) कर देता है, और चूंकि एक टोकन जनरेट करने के लिए हर वेट (weight) को एक बार पढ़ना पड़ता है, इसलिए जनरेशन की गति गिरकर प्रति टोकन कई सेकंड हो जाती है। मॉडल के उत्तर देते समय free -h और vmstat 1 के si और so कॉलम पर नज़र रखें। जनरेशन के दौरान swap in और swap out का मान शून्य से अधिक होने का अर्थ है कि मॉडल इस प्लान के लिए बहुत बड़ा है।

8 GB से 16 GB VPS पर क्या चलता है

यहीं पर self-hosted मॉडल वास्तव में उपयोगी हो जाता है। 8 GB पर आप 4 bits पर 7B या 8B मॉडल चला सकते हैं, जिसमें लगभग 4.8 GB weights और 8k context का उपयोग होता है। 16 GB पर आप 4 bits पर 13B या 14B मॉडल चला सकते हैं, जो लगभग 8.4 GB लेता है, या यदि आप parameter count के बजाय precision पर memory खर्च करना चाहते हैं, तो 8B मॉडल को 8 bits पर रख सकते हैं।

गति यहाँ एक बाधा है। CPU पर 8B मॉडल लगभग 3 से 7 tokens प्रति सेकंड generate करता है, और 14B मॉडल लगभग 1.5 से 3.5 tokens प्रति सेकंड। एक सामान्य व्यक्ति लगभग 5 से 10 tokens प्रति सेकंड की गति से पढ़ता है, इसलिए CPU VPS पर 8B मॉडल का अनुभव एक धीमे टाइपिस्ट को देखने जैसा होता है। यह background job के लिए तो ठीक है, लेकिन interactive chat के लिए थकाऊ हो सकता है। VPS पर Qwen 3 के 8B और उससे बड़े मॉडल्स के मापे गए runs दिखाते हैं कि व्यवहार में यह कैसा दिखता है।

32 GB से 64 GB VPS पर क्या चलता है

4 bits पर 32B मॉडल लगभग 19.2 GB का होता है, इसलिए यह छोटे context के साथ 32 GB प्लान पर फिट हो जाता है और 48 GB या 64 GB पर आसानी से चलता है। 4 bits पर 70B मॉडल लगभग 42 GB का होता है, इसलिए किसी भी cache को जोड़ने से पहले इसे 64 GB की आवश्यकता होती है।

इसके बाद गति को निष्पक्ष रूप से देखें। CPU पर 32B मॉडल लगभग 0.6 से 1.5 tokens प्रति सेकंड की गति से चलता है, और 70B मॉडल 0.2 से 0.5 की गति से। उस 70B मॉडल से 500 tokens का उत्तर प्राप्त करने में लगभग बीस मिनट लगते हैं। ये batch tools हैं। इन्हें रात भर के लिए documents की एक queue दें, तो गति मायने नहीं रखती। इन्हें chat window के पीछे रखें, तो गति बहुत मायने रखती है।

Mixture of experts (MoE) routing इस गणना को बदल देती है, और यह आर्किटेक्चर का वह विवरण है जिसे सीखना सार्थक है। एक MoE मॉडल प्रत्येक token को अपने weights के केवल एक छोटे हिस्से से गुजारता है। 30B कुल parameters और प्रति token 3B active parameters वाले मॉडल को 30B जितनी memory की आवश्यकता होती है, लेकिन यह 3B dense मॉडल के करीब की गति से generate करता है, क्योंकि प्रत्येक token केवल active experts को ही read करता है। 32 GB के सर्वर पर इस आकार का MoE, 30B dense मॉडल की तुलना में कहीं अधिक उपयोगी है। याद रखने योग्य नियम: कुल parameters memory निर्धारित करते हैं, और active parameters गति निर्धारित करते हैं।

CPU inference वास्तव में कितनी तेज है?

एक token generate करने के लिए हर active weight को एक बार memory से पढ़ना पड़ता है। इससे बचने का कोई तरीका नहीं है, इसलिए CPU पर generation की गति memory bandwidth से तय होती है, न कि core count से। इसकी अधिकतम सीमा एक विभाजन है: उपलब्ध memory bandwidth को bytes में weights के आकार से विभाजित करना। एक छोटा shared VPS आमतौर पर अपने vCPUs के माध्यम से 10 से 25 GB प्रति सेकंड की गति देता है, इसलिए 4.8 GB का model लगभग 2 से 5 tokens प्रति सेकंड की गति तक पहुँचता है।

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

ये सामान्य VPS hardware पर देखी जाने वाली ranges हैं, न कि किसी एक machine का benchmark। आपका आंकड़ा memory generation, host पर मौजूद channel count और उस पर प्रतिस्पर्धा कर रहे अन्य neighbours की संख्या पर निर्भर करता है। अपने पास मौजूद किसी भी model tag का उपयोग करके स्वयं मापें:

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

उत्तर समाप्त होने के बाद छपा सारांश एक पंक्ति के साथ समाप्त होता है जो eval rate: ... tokens/s पढ़ती है। यह आपकी generation गति है। session के पहले run को अनदेखा करें, क्योंकि उसी सारांश पर load duration में disk से weights को पढ़ना भी शामिल होता है। Tokens प्रति सेकंड को सही ढंग से मापना विषय में बताया गया है कि तुलना करने योग्य संख्या कैसे प्राप्त करें।

यहाँ दो परिणाम लोगों को आश्चर्यचकित करते हैं। vCPUs जोड़ने से मदद मिलना जल्दी बंद हो जाता है, क्योंकि लगभग 8 cores के बाद अतिरिक्त cores arithmetic करने के बजाय memory का इंतज़ार कर रहे होते हैं। और shared plan पर वही command हर घंटे अलग-अलग संख्याएँ देती है, जो कि noisy neighbour से CPU steal time के कारण होता है, न कि आपकी किसी गलत configuration के कारण।

आपके prompt को पढ़ना, उत्तर generate करने से अलग काम है। Prompt processing compute bound है, इसलिए यह cores के साथ scale करती है, और यही वह जगह है जहाँ GPU सबसे आगे निकल जाता है। एक लंबे document को पढ़ने में CPU को मिनटों का समय लगता है, जबकि GPU इसे सेकंडों में पढ़ लेता है। जब आप coding agent को अपने host किए गए model की ओर निर्देशित करते हैं तो यह पहली बाधा है जिसका आप सामना करते हैं, क्योंकि उत्तर का एक भी token वापस आने से पहले हर बार file context और tool definitions को फिर से भेजा जाता है।

GPU जोड़ने पर क्या बदलता है

गणित नहीं बदलता, केवल वह पूल बदलता है जिस पर यह लागू होता है। VRAM एक सख्त सीमा है, इसलिए रेंट पर लेने से पहले गणना करें कि क्या फिट होगा:

• 8 GB VRAM में छोटे context के साथ 4 bits पर 7B या 8B मॉडल आ जाता है।
• 16 GB में वास्तविक context के साथ 4 bits पर 14B, या 8 bits पर 8B मॉडल आ जाता है।
• 24 GB में छोटे context के साथ 4 bits पर 32B मॉडल आ जाता है।
• 48 GB और उससे अधिक में cache और concurrency के लिए जगह के साथ 4 bits पर 70B मॉडल आ जाता है।

जब कोई मॉडल फिट नहीं होता, तो Ollama उसे विभाजित कर देता है: कुछ layers GPU पर, बाकी CPU पर। ollama ps इस विभाजन को अपने PROCESSOR कॉलम में 78%/22% CPU/GPU जैसे किसी मान के रूप में रिपोर्ट करता है। इसे एक फीचर के बजाय चेतावनी के रूप में पढ़ें। CPU वाला हिस्सा गति निर्धारित करता है, क्योंकि हर token को उन layers का इंतजार करना पड़ता है, इसलिए जिस मॉडल की एक-चौथाई layers CPU पर होती हैं, वह GPU गति के बजाय CPU गति के काफी करीब चलता है। यदि आप ऐसा विभाजन देखते हैं जिसकी आपने योजना नहीं बनाई थी, तो पहले context length कम करें। आमतौर पर cache ही वह चीज है जो इसे सीमा से बाहर ले जाती है।

Concurrency आकार बढ़ाने का दूसरा कारण है। weights को एक साथ आने वाले requests के बीच साझा किया जाता है, लेकिन प्रत्येक सक्रिय request को अपनी KV cache की आवश्यकता होती है, इसलिए 8k context पर 8B मॉडल के दस समवर्ती (concurrent) उपयोगकर्ताओं को weights के अलावा दस गुना 1 GB cache की आवश्यकता होती है। एक self-hosted मॉडल से समवर्ती उपयोगकर्ताओं को सर्व करना बताता है कि यह सीमा कहाँ समाप्त होती है।

GPU रेंट पर लेना सार्थक है या नहीं, यह भी गणित का ही सवाल है, और यह इस बात पर निर्भर करता है कि आप वास्तव में प्रति माह कितने tokens generate करते हैं। GPU VPS और API tokens के बीच break even में ये आंकड़े दिए गए हैं।

आप क्या self-host नहीं कर सकते

यहाँ दो अलग-अलग बाधाएं हैं, और यह जानना मददगार है कि आप किस बाधा का सामना कर रहे हैं।

पहली बाधा closed weights है। अग्रणी commercial models वितरित (distributed) नहीं किए जाते हैं, इसलिए डाउनलोड करने के लिए कोई फाइल उपलब्ध नहीं है और RAM में कोई भी बदलाव इसे नहीं बदल सकता। आप उनके आसपास की हर चीज को self-host कर सकते हैं: interface, retrieval layer, agent loop, और logs। मॉडल स्वयं एक remote API बना रहता है। क्या आप Claude को self-host कर सकते हैं इस विषय पर विस्तार से चर्चा करता है।

दूसरी बाधा open weights हैं जो बहुत बड़े हैं। सबसे बड़े open releases, hundreds of billions of total parameters वाले mixture of experts designs हैं। उन पर भी यही नियम लागू होता है: 400B total parameter वाला मॉडल 4 bits पर, किसी भी cache से पहले, केवल weights के लिए लगभग 240 GB RAM की मांग करता है। यह specialist hardware है, और इसे महीने के आधार पर किराए पर लेना, अधिकांश लोगों द्वारा एक वर्ष में API tokens पर खर्च की जाने वाली राशि से कहीं अधिक महंगा है। Kimi class मॉडल को self-host करने के लिए क्या आवश्यक है वास्तविक आवश्यकताओं के बारे में बताता है।

इन दोनों के बीच की स्पष्ट रेखा यह है: जब load स्थिर हो और डेटा को आपके सर्वर से बाहर नहीं जाना चाहिए, तब self-host करें। जब load अचानक बढ़ता (bursty) हो, या जब आपको वास्तव में frontier answer quality की आवश्यकता हो, तब tokens खरीदें।

चुनाव करने से पहले उपलब्ध संसाधनों की जाँच करें

free -h
nproc
lscpu | grep 'Model name'

अपनी योजना free -h के available कॉलम के आधार पर बनाएँ, न कि total कॉलम के आधार पर, क्योंकि total में वह मेमोरी भी शामिल होती है जिसे सिस्टम पहले से उपयोग कर रहा है। ऑपरेटिंग सिस्टम और मॉडल सर्वर के लिए लगभग 1 GB घटा दें। जो शेष बचता है उसे 0.6 से विभाजित करें ताकि आपको 4 bits पर समर्थित अधिकतम पैरामीटर संख्या (billions में) प्राप्त हो सके। इसके बाद, उस context के लिए KV cache घटाएँ जिसकी आपको वास्तव में आवश्यकता है। जो शेष बचेगा वही आपका उत्तर है, और मॉडल नामों की सूची के विपरीत, यह कभी पुराना नहीं होता।

FAQ

8B model चलाने के लिए मुझे कितनी RAM की आवश्यकता है?

4-bit quantisation पर weights के लिए लगभग 4.8 GB, साथ ही आपके context length के लिए KV cache, और ऑपरेटिंग सिस्टम व मॉडल सर्वर के लिए लगभग 1 GB RAM की आवश्यकता होती है। 8192 token context पर cache लगभग 1 GB जोड़ता है, इसलिए 8 GB का प्लान काम करेगा लेकिन 4 GB का प्लान पर्याप्त नहीं है। यदि आप मॉडल कार्ड में बताए गए पूरे 128k context का उपयोग करना चाहते हैं, तो केवल cache ही 16 GB का होगा और आपको 32 GB के प्लान की आवश्यकता होगी।

VPS में पर्याप्त vCPUs होने के बावजूद मेरा मॉडल धीमा क्यों है?

क्योंकि generation की गति cores से नहीं, बल्कि memory bandwidth से सीमित होती है। प्रत्येक token के लिए RAM से पूरे active weight set को लोड करना पड़ता है, इसलिए जैसे ही कुछ cores memory channels को saturate कर देते हैं, बाकी cores केवल प्रतीक्षा करते हैं। दूसरा सामान्य कारण swap है। यदि मॉडल उत्तर देते समय vmstat 1 में si और so का मान शून्य से अधिक दिखता है, तो इसका मतलब है कि weights RAM में पूरी तरह फिट नहीं हो रहे हैं और प्रत्येक token का एक हिस्सा disk से सर्व किया जा रहा है, जिसकी लागत उम्मीद से कहीं अधिक होती है।

क्या लंबे context window के लिए वास्तव में अधिक मेमोरी की आवश्यकता होती है?

हाँ, और यह वृद्धि tokens के साथ linear होती है। एक सामान्य 8B मॉडल प्रति token लगभग 128 KiB KV cache का उपयोग करता है, इसलिए 8192 tokens के लिए 1 GB और 131072 tokens के लिए 16 GB की लागत आती है। Cache को conversation बढ़ने के बजाय मॉडल लोड होते समय ही allocate कर दिया जाता है, इसलिए 128k context की मांग करने पर वह मेमोरी तुरंत आरक्षित हो जाती है, भले ही आपका प्रत्येक prompt केवल 200 tokens का ही क्यों न हो।

क्या मुझे 2 bits पर एक बड़ा मॉडल चलाना चाहिए या 4 bits पर एक छोटा मॉडल?

4 bits पर छोटा मॉडल चुनें। 8 bits से 4 bits तक quality धीरे-धीरे गिरती है, लेकिन 4 bits के नीचे यह तेजी से गिरती है। इसलिए, एक ही मॉडल जनरेशन में 2 bits पर संकुचित किया गया 70B मॉडल आमतौर पर 4 bits वाले 32B मॉडल से खराब परिणाम देता है। भारी quantisation का प्रभाव error message के बजाय वाक्यों को दोहराने और निर्देशों का पालन न करने के रूप में दिखता है, जिसे अक्सर prompt की गलती मान लिया जाता है। 4 bits को न्यूनतम सीमा मानें और इसके बजाय parameter count को बदलें।

क्या मैं बड़े commercial मॉडल्स के समान सक्षम मॉडल को self-host कर सकता हूँ?

साधारण VPS पर ऐसा संभव नहीं है। सबसे शक्तिशाली open weight मॉडल्स में सैकड़ों अरबों parameters होते हैं, जिसका अर्थ है कि 4 bits पर भी किसी भी KV cache से पहले 200 GB से अधिक RAM की आवश्यकता होगी, और सबसे शक्तिशाली commercial मॉडल्स तो वितरित ही नहीं किए जाते। साधारण हार्डवेयर किसी विशिष्ट कार्य के लिए 8B से 32B के अच्छे मॉडल्स को चलाने में सक्षम है, जहाँ एक सीमित और अच्छी तरह से prompt किया गया छोटा मॉडल अक्सर एक सामान्य मॉडल के बराबर प्रदर्शन करता है। यदि आपको frontier quality की आवश्यकता है, तो हार्डवेयर खरीदने से पहले API की कीमत की तुलना कर लें।