Self-host करने के लिए सर्वश्रेष्ठ AI models कैसे चुनें

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

आप कौन से AI models को self-host कर सकते हैं, यह केवल एक संख्या से तय होता है: आपके सर्वर की RAM। मॉडल की श्रेणी और framework इस बात से कहीं कम महत्वपूर्ण हैं कि क्या model weights मेमोरी में फिट होते हैं और उसके बाद कितनी जगह बचती है। यह पोस्ट इस गणना को समझने के लिए है। Runtime install करना एक अलग कार्य है, जिसे the guide to running Ollama on a VPS में कवर किया गया है।

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

साइजिंग का गणित: प्रति पैरामीटर बिट्स

मॉडल फाइल लगभग पूरी तरह से वेट्स (weights) से बनी होती है। प्रत्येक वेट को कुछ बिट्स में स्टोर किया जाता है। क्वांटाइजेशन का अर्थ है उन्हें उस प्रिसिजन (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 बिट्स से नीचे जाने के बजाय मॉडल का साइज क्लास कम कर दें।

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

cache को कम करने के दो तरीके हैं। 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 कॉलम यह दिखाता है कि यह कब समाप्त (expire) होगा। किसी मॉडल को स्थायी रूप से पिन करने के लिए, सर्विस पर 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-bit पर 1B से 4B मॉडल और डिफ़ॉल्ट 4096 टोकन कॉन्टेक्स्ट के लिए पर्याप्त है। अगस्त 2026 तक, इस श्रेणी में Llama 3.2 (3B), Qwen 3 (1.7B और 4B), तथा छोटे Gemma और Phi releases शामिल हैं। इन्हें केवल आकार के उदाहरण मानें, अनुशंसा नहीं। मॉडल्स के नाम कुछ महीनों में बदलते रहते हैं, लेकिन गणित वही रहता है।

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

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

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

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

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

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 की आवश्यकता होती है।

फिर speed को ईमानदारी से देखें। CPU पर 32B लगभग 0.6 से 1.5 tokens प्रति second और 70B लगभग 0.2 से 0.5 tokens प्रति second की गति से चलता है। 70B का 500 tokens वाला उत्तर तैयार होने में लगभग twenty minutes लगते हैं। इस गति पर model के पूरा होने से पहले request अक्सर समाप्त हो जाती है, क्योंकि Ollama के सामने मौजूद कोई client या proxy timeout पहले लागू हो जाता है। इसी कारण context deadline exceeded error आता है। ये batch tools हैं। इन्हें रात भर documents की queue दें, तो speed मायने नहीं रखती। इन्हें chat window के पीछे रखें, तो speed का बहुत अधिक महत्व होता है।

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 मॉडल एक dense 30B मॉडल की तुलना में कहीं अधिक उपयोगी होता है। याद रखने योग्य नियम: कुल 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 पर channels की संख्या, और उस पर compete कर रहे अन्य neighbours पर निर्भर करता है। अपने पास मौजूद किसी भी model tag का उपयोग करके स्वयं मापें:

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

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

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

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

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

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

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

जब कोई मॉडल फिट नहीं होता है, तो 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 जनरेट करते हैं। GPU VPS और API tokens के बीच break even में वे आंकड़े दिए गए हैं।

जिसे आप self-host नहीं कर सकते

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

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

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

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

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

free -h
nproc
lscpu | grep 'Model name'

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

FAQ

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

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

VPS में पर्याप्त vCPU होने के बावजूद मेरा model धीमा क्यों है?

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

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

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

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

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

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

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