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

तुम्ही self-host करू शकणारी AI मॉडेल्स कोणत्या गोष्टीवर ठरतात

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

दोन खर्च उत्तर ठरवतात. Weights हा fixed cost असतो. तो parameter count आणि quantisation यावर ठरतो. Context window हा running cost असतो. एखादे मॉडेल काल load झाले, पण आज load होण्यास नकार देईपर्यंत अनेकजण हा खर्च लक्षात घेत नाहीत.

आकारमानाचे गणित: प्रत्येक parameter मागील bits

Model file मध्ये जवळजवळ संपूर्णपणे weights असतात. प्रत्येक weight काही ठरावीक bits मध्ये साठवला जातो. Quantisation म्हणजे ज्या precision मध्ये model train केला होता त्यापेक्षा कमी bits मध्ये weights साठवणे. यामुळे अचूकता थोडी कमी होते, पण 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 साठी त्यांचे वास्तविक सरासरी 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 हा नियम लागू केला आहे. वास्तविक 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) हा दुसरा खर्च आहे. 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 वापरतो. 8192 tokens असताना तो 1 GB वापरतो. त्याच्या model card मध्ये नमूद केलेल्या 128k context वर तो 16 GB वापरतो. हे weights पेक्षा तीनपटहून अधिक आहे. 70B मध्ये उलट स्थिती आहे. 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 वापरून ही value वाढवा. त्यानंतर चालू model ला प्रत्यक्षात कोणती value मिळाली ते ollama ps मधील CONTEXT column मध्ये तपासा. या setting मागील memory arithmetic num_ctx आणि context length वरील post मध्ये सविस्तर दिले आहे.

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

RAM मध्ये ठेवलेले मॉडेल unload होईपर्यंत तिथेच राहते

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

ollama ps
ollama stop qwen3:4b

ollama ps कोणते मॉडेल memory मध्ये resident आहे ते दाखवते. SIZE column मध्ये ते किती memory वापरते ते दिसते आणि UNTIL column मध्ये ते कधी expire होईल ते दिसते. मॉडेल कायम memory मध्ये ठेवण्यासाठी service वर OLLAMA_KEEP_ALIVE=-1 सेट करा. 0 ची value दिल्यास प्रत्येक 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 मॉडेल spare capacity देत नाही. 16 GB VPS वर 8k context असलेले 8B मॉडेल service चालू असेपर्यंत अंदाजे 6 GB memory व्यापते. त्यामुळे server ची क्षमता केवळ मॉडेलच्या आधारावर नव्हे, तर मॉडेल आणि तुमच्या application या दोन्हींच्या गरजेनुसार ठरवा. मॉडेल memory मध्ये pin करणे येथे cold start latency विरुद्ध याचा trade-off स्पष्ट केला आहे.

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

Operating system आणि 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 समाविष्ट आहेत. ही नावे शिफारसी म्हणून नव्हे, तर आकाराची उदाहरणे म्हणून घ्या. ही नावे दर काही महिन्यांनी बदलतात; मात्र हे गणित बदलत नाही.

अंदाजे 6 ते 14 tokens per second अपेक्षित ठेवा. एवढे छोटे models classification, tag extraction, short summaries आणि एखादा paragraph ठरावीक house style नुसार पुन्हा लिहिणे यांसारखी मर्यादित कामे चांगली करतात. Multi-step reasoning आणि अनेक files मध्ये पसरलेला code हाताळण्यात ते कमकुवत असतात. कोणत्याही प्रकारचे prompting हे दुरुस्त करू शकत नाही.

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

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

या क्षमतेच्या सर्व्हरवर self-hosted model सर्वसाधारणपणे उपयुक्त ठरतो. 8 GB वर 4 bits मध्ये 7B किंवा 8B model चालवता येतो. त्याच्या weights साठी सुमारे 4.8 GB लागतात आणि 8k context ठेवता येतो. 16 GB वर 4 bits मध्ये 13B किंवा 14B model चालवता येतो. त्यासाठी सुमारे 8.4 GB लागतात. किंवा 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 वर Qwen 3 चे 8B आणि त्याहून मोठ्या model चे मोजलेले runs प्रत्यक्ष वापरातील परिस्थिती दाखवतात.

32 ते 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 प्रति सेकंद या वेगाने चालते. 70B मॉडेलचा वेग 0.2 ते 0.5 tokens प्रति सेकंद असतो. त्या 70B मॉडेलकडून 500 tokens चे उत्तर तयार होण्यासाठी सुमारे वीस मिनिटे लागतात. ही batch कामांसाठी योग्य साधने आहेत. दस्तऐवजांची queue त्यांना रात्रभर दिल्यास speed महत्त्वाची राहत नाही. त्यांना chat window मागे ठेवले, तर speed अत्यंत महत्त्वाची ठरते.

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

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

एक token तयार करण्यासाठी memory मधील प्रत्येक सक्रिय weight एकदा वाचावा लागतो. हे टाळता येत नाही. त्यामुळे CPU वरील generation speed ही core count पेक्षा memory bandwidth वर अवलंबून असते. कमाल वेग काढण्यासाठी वापरता येणारी memory bandwidth ही weights च्या bytes मधील आकाराने भागावी लागते. छोटा 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
  }
]

ही range सामान्य VPS hardware वर नोंदवली जाते. ती एखाद्या एकाच machine ची benchmark नाही. तुमचा आकडा memory generation, host वरील channel count आणि त्याच memory साठी स्पर्धा करणाऱ्या शेजारील tenants च्या संख्येवर अवलंबून असतो. तुमच्याकडे आधीपासून असलेला कोणताही 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 प्रति सेकंद योग्य प्रकारे मोजणे यामध्ये तुलना करण्यायोग्य आकडा कसा मिळवायचा ते दिले आहे.

येथे दोन गोष्टी लोकांना अनपेक्षित वाटतात. vCPUs वाढवल्यानंतर फायदा लवकरच थांबतो. कारण साधारण 8 cores नंतर अतिरिक्त cores arithmetic करण्याऐवजी memory ची वाट पाहत असतात. तसेच shared plan वर एकाच command मधून तासानुसार वेगवेगळे आकडे मिळू शकतात. याचे कारण तुम्ही चुकीचे configuration केलेले नसून noisy neighbour मुळे होणारा CPU steal time हे असते.

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

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

गणित बदलत नाही; ते लागू होणारा pool बदलतो. VRAM ही कठोर मर्यादा आहे. त्यामुळे server भाड्याने घेण्यापूर्वी काय बसते ते ठरवा:

• 8 GB VRAM मध्ये short context सह 4 bits वर 7B किंवा 8B बसते.
• 16 GB मध्ये real context सह 4 bits वर 14B किंवा 8 bits वर 8B बसते.
• 24 GB मध्ये context short ठेवून 4 bits वर 32B बसते.
• 48 GB किंवा त्याहून अधिक VRAM मध्ये cache आणि concurrency साठी जागा ठेवून 4 bits वर 70B बसते.

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

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

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

तुम्ही self-host करू शकत नाही अशा गोष्टी

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

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

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

या दोन मर्यादांमधील प्रामाणिक निष्कर्ष असा आहे: 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 लागतो. Conversation वाढल्यानंतर cache allocate होत नाही. Model load होताना तो 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 पर्यंत कमी केल्यास, त्याच model generation मधील 4 bits वरील 32B model पेक्षा सामान्यतः खराब उत्तरे मिळतात. जास्त quantisation असल्यास error message दिसत नाही. त्याऐवजी repetition आणि instructions गाळणे दिसते. त्यामुळे दोष prompt मध्ये आहे असे समजणे सोपे जाते. 4 bits ही किमान मर्यादा माना आणि त्याऐवजी parameter count बदला.

मोठ्या commercial models इतके सक्षम model self-host करता येईल का?

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