स्वतः होस्ट करण्यासाठी कोणती AI मॉडेल्स निवडावीत?

स्वतः होस्ट करता येणारी AI मॉडेल्स कोणती हे कशावर ठरते

तुम्ही कोणती AI मॉडेल्स स्वतः होस्ट करू शकता हे एका संख्येवर ठरते: त्या मशीनवरील RAM. मॉडेल कुटुंब आणि framework यांचे महत्त्व, weights उपलब्ध memory मध्ये पुरेशी मोकळी जागा ठेवून बसतात की नाही यापेक्षा खूप कमी असते. हे ठरवण्यासाठी आवश्यक arithmetic या लेखात दिले आहे. Runtime install करणे हे स्वतंत्र काम आहे. त्यासाठी VPS वर Ollama चालवण्याचे मार्गदर्शक पहा.

दोन खर्च उत्तर ठरवतात. Weights हा fixed cost असतो. तो parameter count आणि quantisation यावर ठरतो. Context window हा running cost असतो. काल load झालेले model आज load होत नसताना लोकांना हा खर्च लक्षात येतो.

आकाराचे गणित: प्रत्येक parameter साठी bits

Model file मध्ये जवळजवळ पूर्णपणे weights असतात. प्रत्येक weight काही ठरावीक bits मध्ये साठवला जातो. Quantisation म्हणजे model ज्या precision वर train केला आहे त्यापेक्षा कमी bits मध्ये weights साठवणे. यामुळे accuracy थोडी कमी होते, पण memory मोठ्या प्रमाणात वाचते. आकार थेट पुढीलप्रमाणे ठरतो:

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

Models 16 bits मध्ये release केले जातात. म्हणजे प्रत्येक billion parameters साठी 2 GB. त्यामुळे VPS वर release precision वापरणारे जवळजवळ कोणीही नसते. प्रत्यक्षात तुम्हाला पुढील quantisations वापरलेल्या आढळतील. प्रत्येक weight साठी त्यांचे वास्तविक average bits पुढीलप्रमाणे आहेत:

• Q8_0 प्रत्येक weight साठी सुमारे 8.5 bits साठवते. त्यामुळे प्रत्येक billion parameters साठी सुमारे 1.1 GB लागतो.
• Q6_K सुमारे 6.6 bits साठवते. त्यामुळे प्रत्येक billion parameters साठी सुमारे 0.83 GB लागतो.
• Q5_K_M सुमारे 5.7 bits साठवते. त्यामुळे प्रत्येक billion parameters साठी सुमारे 0.71 GB लागतो.
• Q4_K_M सुमारे 4.8 bits साठवते. त्यामुळे प्रत्येक billion parameters साठी सुमारे 0.6 GB लागतो.

तुमच्या अंदाजासाठी प्रत्येक billion parameters साठी 0.6 GB हा आकडा वापरा. Memory bound box वर Q4_K_M हा योग्य default आहे. बहुतेक tasks मध्ये 8 bits च्या तुलनेत quality loss कमी असतो आणि file चा आकार जवळजवळ निम्मा असतो. 4 bits पेक्षा कमी गेल्यावर loss वेगाने वाढतो. त्यामुळे त्याच generation मधील 70B model 2 bits पर्यंत कमी केल्यास, 4 bits वरील 32B model पेक्षा त्याची उत्तरे सामान्यतः खराब असतात. Memory कमी असेल, तर 4 bits पेक्षा कमी जाण्याऐवजी एक 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
  }
]

वरील weight column मध्ये प्रत्येक billion parameters साठी 0.6 GB हा नियम लागू केला आहे. Real GGUF files या आकड्याच्या काही टक्क्यांच्या मर्यादेत असतात, कारण embedding आणि output layers उर्वरित भागापेक्षा higher precision वर ठेवल्या जातात. 4 bits वरील 3B model सुमारे 1.8 GB असतो. 8B model 4.8 GB असतो. 32B model 19.2 GB असतो आणि 70B model 42 GB असतो.

संदर्भ लांबीसाठी weights पेक्षा जास्त RAM का लागते

KV cache (key value cache; सध्या संभाषणातील प्रत्येक token साठी model जतन करत असलेली attention state) हा RAM वापरातील दुसरा मोठा घटक आहे. Model load होताना तो allocate केला जातो. तुम्ही मागितलेल्या context length नुसार त्याचा आकार ठरतो. ही लांबी वाढली की cache सरळ प्रमाणात वाढतो.

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

Ollama च्या default context मध्ये तो 8B model cache साठी अर्धा gigabyte RAM वापरतो. 8192 tokens वर तो 1 GB वापरतो. त्याच्या model card मध्ये नमूद केलेल्या 128k context वर तो 16 GB वापरतो. हे weights पेक्षा तीन पटीहून अधिक आहे. 70B model मध्ये उलट स्थिती आहे: 128k context वर त्याचा cache 40 GB आहे. हे त्याच्या weights पेक्षा कमी आहे, कारण grouped query attention मुळे प्रत्येक token ची किंमत parameter count प्रमाणे जवळपास वेगाने वाढत नाही.

CPU only server वर Ollama ची default context length 4096 tokens असते. GPU उपलब्ध असल्यास Ollama त्याऐवजी VRAM नुसार default निवडते: 24 ते 48 GiB दरम्यान 32k, आणि 48 GiB किंवा त्याहून अधिक असल्यास 256k. Server वरील OLLAMA_CONTEXT_LENGTH variable वापरून ही लांबी वाढवा. त्यानंतर चालू model ला प्रत्यक्षात कोणती लांबी मिळाली आहे ते ollama ps मधील CONTEXT column मध्ये तपासा. या setting मागील memory arithmetic num_ctx आणि context length वरील लेखात सविस्तर समजावले आहे.

Cache कमी करण्याचे दोन मार्ग आहेत. Model card मध्ये जाहिरात केलेला context न मागता आवश्यक तेवढाच context मागा, कारण बहुतेक chat आणि coding काम 8k ते 32k मध्ये पूर्ण होते. किंवा cache स्वतः 8 bits वर quantise करा. यामुळे त्याचा आकार निम्मा होतो, परंतु long context recall काही प्रमाणात कमी होऊ शकते.

RAM मध्ये ठेवलेले मॉडेल unload होईपर्यंत ती मेमरी व्यापून ठेवते

शेवटच्या विनंतीनंतर Ollama मॉडेल 5 मिनिटे मेमरीमध्ये ठेवते आणि त्यानंतर ते unload करते. ही default सेटिंग laptop साठी योग्य आहे; server साठी ती योग्य नाही. प्रत्येक idle gap नंतर आलेल्या पहिल्या विनंतीला पुन्हा load time द्यावा लागतो.

ollama ps
ollama stop qwen3:4b

ollama ps मेमरीमध्ये सध्या resident असलेली मॉडेल्स दाखवते. त्यातील SIZE column मॉडेल किती मेमरी वापरते ते दाखवतो आणि UNTIL column ते कधी expire होईल ते दाखवतो. एखादे मॉडेल कायमचे memory मध्ये ठेवण्यासाठी service वर OLLAMA_KEEP_ALIVE=-1 सेट करा. 0 मूल्य दिल्यास प्रत्येक response पूर्ण होताच ते unload होते.

sudo systemctl edit ollama.service

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

sudo systemctl daemon-reload
sudo systemctl restart ollama

एक prompt पाठवा आणि दहा मिनिटांनी पुन्हा ollama ps चालवा. मॉडेल अजूनही सूचीमध्ये दिसेल. हाच मुख्य मुद्दा आहे: कोणी वापरत नसले तरी ते RAM व्यापून ठेवते. pinned model ही spare capacity नसते. 16 GB VPS वर 8k context असलेले 8B मॉडेल service चालू असेपर्यंत सुमारे 6 GB मेमरी व्यापते. त्यामुळे server ची क्षमता फक्त मॉडेलनुसार नव्हे, तर मॉडेल आणि तुमचे application या दोन्हींच्या एकत्रित गरजेनुसार ठरवा. मॉडेल मेमरीमध्ये कायम ठेवणे येथे cold start latency विरुद्धच्या या निवडीचे स्पष्टीकरण दिले आहे.

4 GB VPS वर काय चालते

ऑपरेटिंग सिस्टम आणि model server साठी सुमारे 1 GB राखून ठेवा. त्यामुळे अंदाजे 3 GB उरतात. Default 4096 token context मध्ये 4 bits वर 1B ते 4B model या मर्यादेत येतो. August 2026 पर्यंत या वर्गात 3B मधील Llama 3.2, 1.7B आणि 4B मधील Qwen 3 तसेच लहान Gemma आणि Phi releases यांचा समावेश होतो. ही नावे शिफारसी नसून आकाराची उदाहरणे आहेत. दर काही महिन्यांनी models बदलतात; मात्र हे गणित बदलत नाही.

अंदाजे 6 ते 14 tokens प्रति सेकंद अपेक्षित ठेवा. एवढ्या लहान models कडून classification, tag extraction, लघु summaries आणि एखादा परिच्छेद ठरावीक house style मध्ये पुन्हा लिहिणे यांसारखी मर्यादित कामे चांगली होतात. अनेक टप्प्यांतील reasoning आणि अनेक files मध्ये पसरलेल्या code बाबतीत ते कमकुवत असतात. Prompting कितीही केले तरी ही मर्यादा दूर होत नाही.

या स्तरावरील मुख्य अपयश swap मुळे होते. Model memory मध्ये बसत नसेल, तर Linux तो load करण्यास नकार देत नाही. त्याऐवजी तो memory disk वर page out करतो. एक token generate करण्यासाठी प्रत्येक weight एकदा वाचावा लागतो. त्यामुळे generation चा वेग कमी होऊन प्रत्येक token साठी काही seconds लागतात. Model उत्तर देत असताना free -h तसेच si आणि so हे vmstat 1 मधील columns monitor करा. Generation दरम्यान swap in आणि swap out चे मूल्य शून्य नसणे म्हणजे या plan साठी model खूप मोठा आहे.

8 ते 16 GB VPS वर काय चालवता येते

याठिकाणी self-hosted model सामान्यतः उपयुक्त ठरतो. 8 GB वर तुम्ही 4 bits मधील 7B किंवा 8B model चालवू शकता. त्यासाठी सुमारे 4.8 GB weights आणि 8k context उपलब्ध राहतो. 16 GB वर तुम्ही 4 bits मधील 13B किंवा 14B model चालवू शकता. त्यासाठी सुमारे 8.4 GB memory लागते. किंवा parameter count पेक्षा precision साठी memory वापरायची असल्यास 8B model 8 bits वर ठेवू शकता.

वेग ही मर्यादा आहे. CPU वर 8B model प्रति सेकंद सुमारे 3 ते 7 tokens तयार करतो. 14B model सुमारे 1.5 ते 3.5 tokens तयार करतो. एखादी व्यक्ती साधारणपणे प्रति सेकंद 5 ते 10 tokens वाचते. त्यामुळे CPU VPS वरील 8B model वापरताना प्रतिसाद मंद टायपिंगसारखा वाटतो. Background job साठी हा वेग पुरेसा आहे. Interactive chat साठी मात्र तो त्रासदायक ठरतो. VPS वर 8B आणि त्याहून मोठ्या आकारातील Qwen 3 चे मोजलेले रन प्रत्यक्ष वापरातील स्थिती दाखवतात.

32 ते 64 GB VPS वर काय चालते

4 bits वर 32B मॉडेलला सुमारे 19.2 GB जागा लागते. त्यामुळे ते short context सह 32 GB plan मध्ये बसते आणि 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 चे उत्तर मिळण्यास सुमारे वीस मिनिटे लागतात. या वेगाने मॉडेलचे उत्तर पूर्ण होण्यापूर्वीच विनंती साधारणपणे अयशस्वी होते, कारण Ollama समोरील एखाद्या client किंवा proxy चा timeout आधी लागू होतो. त्यामुळे context deadline exceeded त्रुटी दिसते. ही batch tools आहेत. त्यांना documents ची queue रात्रभर प्रक्रिया करण्यासाठी दिल्यास वेग महत्त्वाचा ठरत नाही. त्यांना chat window मागे ठेवल्यास वेग अत्यंत महत्त्वाचा ठरतो.

Mixture of experts routing मुळे हे गणित बदलते. हा architecture मधील शिकण्यासारखा सर्वात महत्त्वाचा तपशील आहे. MoE model प्रत्येक token ला आपल्या weights च्या केवळ एका लहान भागातून process करते. एखाद्या model मध्ये एकूण 30B parameters आणि प्रत्येक token साठी 3B active parameters असतील, तर त्याला memory साठी 30B model एवढी जागा लागते आणि त्याचा generation speed dense 3B model च्या जवळचा असतो. कारण प्रत्येक token वेळी केवळ active experts वाचले जातात. 32 GB box वर अशा स्वरूपाचे MoE model dense 30B model पेक्षा अधिक वापरण्यायोग्य असते. लक्षात ठेवण्याचा नियम: total parameters memory ठरवतात आणि active parameters speed ठरवतात.

CPU inference प्रत्यक्षात किती वेगवान असते?

एक token तयार करण्यासाठी प्रत्येक सक्रिय weight एकदा memory मधून वाचावा लागतो. हे टाळता येत नाही. त्यामुळे CPU वरील generation speed ही core count पेक्षा memory bandwidth वर अधिक अवलंबून असते. कमाल वेग काढण्यासाठी usable memory bandwidth ला weights च्या bytes मधील आकाराने भाग द्यावा लागतो. छोटा shared VPS त्याच्या vCPUs मधून प्रत्यक्षात 10 ते 25 GB प्रति सेकंद इतकी bandwidth देतो. त्यामुळे 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 आणि त्याच memory साठी स्पर्धा करणाऱ्या neighbours च्या संख्येवर अवलंबून असतो. तुमच्याकडे आधीपासून असलेल्या कोणत्याही model tag चा वापर करून स्वतः मोजा:

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

उत्तर पूर्ण झाल्यानंतर छापल्या जाणाऱ्या summary मध्ये 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 वेगवेगळ्या तासांत वेगवेगळे आकडे देते. हे noisy neighbour मुळे होणारा CPU steal time असते; तुमच्या configuration मधील चुकीमुळे ते होत नाही.

तुमचा prompt वाचणे आणि उत्तर तयार करणे ही वेगवेगळी कामे आहेत. Prompt processing हे compute bound असते. त्यामुळे ते cores वाढवल्यावर वेगवान होते आणि याच ठिकाणी GPU सर्वाधिक आघाडीवर असतो. मोठा document वाचण्यासाठी CPU ला काही minutes लागतात, तर GPU ला काही seconds लागतात. तुम्ही host केलेल्या model कडे coding agent निर्देशित करताना ही पहिली अडचण येते, कारण प्रत्येक turn मध्ये उत्तरातील एकही token परत येण्यापूर्वी file context आणि tool definitions पुन्हा पाठवाव्या लागतात.

GPU जोडल्यावर काय बदलते

अंकगणित बदलत नाही; ते लागू होणारा pool बदलतो. 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 किंवा त्याहून अधिक VRAM मध्ये cache आणि concurrency साठी जागा ठेवून 4 bits वर 70B मॉडेल बसते.

मॉडेल बसत नसेल, तर Ollama ते विभाजित करते: काही layers GPU वर आणि उर्वरित CPU वर ठेवते. ollama ps च्या PROCESSOR column मध्ये हे विभाजन 78%/22% CPU/GPU सारख्या स्वरूपात दिसते. याकडे feature म्हणून नव्हे, तर इशारा म्हणून पाहा. CPU वरील भाग वेग ठरवतो, कारण प्रत्येक token साठी त्या layers चे काम पूर्ण होण्याची प्रतीक्षा करावी लागते. त्यामुळे एक-चतुर्थांश layers CPU वर असलेले मॉडेल GPU speed पेक्षा CPU speed जवळ चालते. अपेक्षित नसलेले split दिसल्यास प्रथम context length कमी करा. बहुतेक वेळा cache मुळे मर्यादा ओलांडली जाते.

क्षमता वाढवण्याचे दुसरे कारण म्हणजे concurrency. एकाच वेळी येणाऱ्या requests मध्ये weights सामायिक केले जातात. मात्र प्रत्येक active request साठी स्वतंत्र KV cache आवश्यक असतो. त्यामुळे 8k context वर 8B मॉडेल वापरणाऱ्या दहा concurrent users साठी weights व्यतिरिक्त 1 GB cache आवश्यक असतो. एका self-hosted मॉडेलमधून concurrent users ना सेवा देणे यात ही मर्यादा कुठे येते ते स्पष्ट केले आहे.

GPU भाड्याने घेणे फायदेशीर आहे का, हा देखील अंकगणिताचा प्रश्न आहे. तुम्ही दरमहा प्रत्यक्षात किती tokens तयार करता यावर उत्तर अवलंबून असते. GPU VPS आणि API tokens यांच्यातील break-even मध्ये हे आकडे दिले आहेत.

स्वतः होस्ट करता न येणाऱ्या गोष्टी

इथे दोन वेगवेगळ्या मर्यादा आहेत. तुम्ही कोणत्या मर्यादेला सामोरे जात आहात हे समजून घेणे उपयुक्त ठरते.

पहिली मर्यादा म्हणजे बंद weights. Frontier commercial models वितरित केले जात नाहीत. त्यामुळे download करण्यासाठी कोणतीही file उपलब्ध नसते आणि RAM वाढवल्यानेही हे बदलत नाही. त्यांच्याभोवतालची सर्व रचना तुम्ही self-host करू शकता: interface, retrieval layer, agent loop आणि logs. मात्र model स्वतः remote API वरच राहतो. Claude self-host करता येतो का याचे सविस्तर स्पष्टीकरण देते.

दुसरी मर्यादा म्हणजे उपलब्ध असलेले weights अतिशय मोठे असणे. सर्वात मोठे open releases हे mixture of experts रचनेवर आधारित असून त्यांमध्ये एकूण शेकडो billions parameters असतात. त्यांच्यासाठीही हाच नियम लागू होतो: 4 bits वर 400B total parameter model साठी कोणताही cache धरून न घेता, फक्त weights साठी सुमारे 240 GB आवश्यक असतात. यासाठी specialist hardware लागतो. ते महिन्याला rent करणे बहुतेक लोक वर्षभरात API tokens वर खर्च करतात त्यापेक्षा खूप महाग असते. Kimi class model self-host करण्यासाठी काय आवश्यक आहे याचे वास्तविक requirements स्पष्ट करते. हाच फरक Ollama च्या स्वतःच्या library मध्येही दिसतो. तिथे GLM 5.2 केवळ cloud model म्हणून सूचीबद्ध आहे आणि प्रत्यक्षात VPS वर download होणारा model त्याचा खूप लहान sibling आहे.

या दोन्हीमध्ये प्रामाणिक निर्णय असा आहे: load स्थिर असेल आणि data तुमच्या server च्या बाहेर जाऊ नये असेल, तर self-host करा. Load bursty असेल किंवा तुम्हाला प्रत्यक्षात frontier answer quality आवश्यक असेल, तर tokens खरेदी करा.

निवड करण्यापूर्वी तुमच्याकडे काय उपलब्ध आहे ते तपासा

free -h
nproc
lscpu | grep 'Model name'

free -h च्या available स्तंभावर आधारित नियोजन करा, total स्तंभावर नाही. कारण total मध्ये सिस्टम आधीच वापरत असलेली memory समाविष्ट असते. Operating system आणि model server साठी सुमारे 1 GB वजा करा. उरलेल्या रकमेचा 0.6 ने भागाकार करा. 4 bits वर हाताळता येणारी अब्जांमधील सर्वाधिक parameter count यामुळे मिळेल. त्यानंतर तुम्हाला प्रत्यक्षात हवा असलेल्या context साठी KV cache वजा करा. उरलेली रक्कम हे तुमचे उत्तर आहे. Model names च्या यादीप्रमाणे ते कालबाह्य होत नाही.

FAQ

8B model चालवण्यासाठी मला किती RAM आवश्यक आहे?

4 bit quantisation मध्ये weights साठी सुमारे 4.8 GB, तसेच तुमच्या context length साठी KV cache आणि operating system व model server साठी अंदाजे 1 GB आवश्यक असते. 8192 token context मध्ये cache सुमारे 1 GB वाढवते. त्यामुळे 8 GB plan चालतो, पण 4 GB plan चालत नाही. Model card मध्ये नमूद केलेला संपूर्ण 128k context वापरायचा असल्यास, केवळ cache साठी 16 GB आवश्यक असते. अशा वेळी 32 GB plan लागेल.

VPS मध्ये भरपूर vCPUs असूनही माझे model धीमे का आहे?

कारण generation हे cores पेक्षा memory bandwidth मुळे मर्यादित होते. प्रत्येक token साठी संपूर्ण active weight set RAM मधून वाचावे लागते. त्यामुळे काही cores memory channels ची क्षमता पूर्ण वापरू लागल्यानंतर उर्वरित cores प्रतीक्षा करतात. दुसरे सामान्य कारण swap आहे. Model उत्तर देत असताना vmstat 1 मध्ये non zero si आणि so दिसत असल्यास, weights RAM मध्ये बसत नाहीत. त्यामुळे प्रत्येक token चा काही भाग disk वरून दिला जातो. यासाठी अपेक्षेपेक्षा खूप अधिक वेळ लागतो.

मोठ्या context window साठी खरोखर अधिक memory आवश्यक असते का?

होय. ही वाढ tokens च्या संख्येनुसार linear असते. सामान्य 8B model प्रत्येक token साठी सुमारे 128 KiB KV cache वापरतो. त्यामुळे 8192 tokens साठी 1 GB आणि 131072 tokens साठी 16 GB लागतात. Model load होताना cache allocate केला जातो. Conversation वाढत असताना तो allocate केला जात नाही. त्यामुळे 128k context मागितल्यास ही memory त्वरित reserve होते, जरी तुम्ही पाठवलेला प्रत्येक prompt 200 tokens इतकाच लहान असला तरी.

मोठे model 2 bits वर चालवावे की छोटे model 4 bits वर?

4 bits वरचे छोटे model निवडा. 8 bits पासून 4 bits पर्यंत quality हळूहळू कमी होते, पण 4 bits पेक्षा खाली ती झपाट्याने कमी होते. त्यामुळे 70B model ला 2 bits पर्यंत quantise केल्यास, त्याच model generation मधील 4 bits वरील 32B model पेक्षा सामान्यतः खराब answers मिळतात. Heavy quantisation मुळे error message दिसण्याऐवजी repetition आणि instructions गाळल्या जाणे दिसते. त्यामुळे दोष prompt मध्ये आहे असे समजणे सोपे जाते. 4 bits ही किमान मर्यादा मानून त्याऐवजी parameter count बदला.

मोठ्या commercial models इतका सक्षम model मी self-host करू शकतो का?

सामान्य VPS वर नाही. सर्वात सक्षम open weight models मध्ये शेकडो billions parameters असतात. 4 bits वर त्यांना कोणताही KV cache धरून चालण्यापूर्वीच 200 GB पेक्षा अधिक RAM लागते. तसेच सर्वात सक्षम commercial models वितरितच केले जात नाहीत. सामान्य hardware वर एका विशिष्ट कामासाठी चांगले 8B ते 32B model चालवता येते. अशा मर्यादित उद्देशासाठी योग्य prompt केलेले छोटे model अनेकदा general model इतकीच कामगिरी देते. Frontier quality आवश्यक असल्यास, hardware खरेदी करण्यापूर्वी API ची किंमत आणि hardware चा खर्च यांची तुलना करा.