Ollama quantization: Q4, Q8 आणि fp16 मधील फरक

Ollama quantization मध्ये काय बदल होतात

Ollama quantization मध्ये मॉडेलमधील प्रत्येक weight मूळ फाईलच्या तुलनेत कमी bits मध्ये साठवले जाते. q4_K_M ने संपणारे टॅग प्रति weight सुमारे चार bits राखतात, तर fp16 सोळा bits राखते. त्यामुळे डाउनलोडचा आकार साधारणपणे एक चतुर्थांश होतो आणि प्रत्येक token तयार करण्यासाठी मशीनला एक चतुर्थांश कमी bytes वाचावे लागतात. weights हे एका ठळक ग्रीडवर राऊंड केले जातात, ते काढून टाकले जात नाहीत. चार bits वर बहुतेक मॉडेल्स पूर्ण precision प्रमाणेच उत्तरे देतात.

हाच मुख्य व्यवहार आहे: मेमरीचा वापर खूप कमी होतो आणि प्रति सेकंद अधिक tokens मिळतात, ज्याची किंमत अचूकतेमध्ये होणाऱ्या थोड्याशा घटीने मोजावी लागते. एखादी फाईल जी तुमच्या सिस्टिममध्ये मावणार नाही ती डाउनलोड करण्यासाठी 20 मिनिटे खर्च करण्यापूर्वी, विशिष्ट मॉडेल आणि विशिष्ट मशीनसाठी याचे परिणाम कसे ओळखायचे, हे खाली दिले आहे.

जर Ollama अजून सुरू नसेल, तर Ollama VPS वर इंस्टॉल करणे पासून सुरुवात करा. हे पान असे गृहीत धरते की ollama ls आधीच कार्यरत आहे.

Ollama quantization tag जसे की q4_K_M कसे वाचावे

स्थानिक मॉडेल्स GGUF फाइल्स म्हणून येतात, जे llama.cpp द्वारे वेट्स (weights) डिस्कवर साठवण्यासाठी वापरले जाणारे फॉरमॅट आहे. Ollama हे llama.cpp वर आधारित आहे, त्यामुळे Ollama टॅग्समध्ये llama.cpp ची क्वांटायझेशन नावे जशीच्या तशी वापरली जातात.

संख्या म्हणजे लक्ष्यित रुंदी (target width). q4 चा अर्थ असा की बहुतेक वेट टेन्सर्स प्रत्येकी चार बिट्समध्ये पॅक केलेले आहेत. q8 म्हणजे आठ बिट्स. fp16 चे अजिबात क्वांटायझेशन केलेले नसते: हे मॉडेल सोळा-बिट फ्लोटिंग पॉइंटमध्ये असते, ज्या अचूकतेमध्ये बहुतेक मॉडेल्स प्रकाशित केली जातात.

K हे K-quant दर्शवते. वेट्सना लहान ब्लॉक्समध्ये गटबद्ध केले जाते आणि प्रत्येक ब्लॉक पॅक केलेल्या मूल्यांच्या शेजारी स्वतःचे स्केल साठवतो. ज्या ब्लॉकचे सर्व वेट्स 0.01 च्या जवळ असतात, त्याला सूक्ष्म (fine) स्केल मिळते. ज्या ब्लॉक मध्ये एक मोठा आउटलायर असतो, त्याला स्थूल (coarse) स्केल मिळते. हे प्रति-ब्लॉक स्केल्सच चार-बिट फाइलला वापरण्यायोग्य ठेवतात आणि याच कारणामुळे चार-बिट फाइल कधीही प्रति वेट अचूक चार बिट्सची नसते.

शेवटचे अक्षर हे मिश्रण (mixture) दर्शवते. S, M आणि L हे ठरवतात की किती टेन्सर्सना लक्ष्यित रुंदीपेक्षा जास्त प्रमोट करायचे. q4_K_M मध्ये, ज्या टेन्सर्सना राउंड केल्यामुळे सर्वात जास्त नुकसान होते, ते अधिक रुंद साठवले जातात, तर उर्वरित भाग चार बिट्सवरच राहतो. म्हणूनच q4_K_M हे जुन्या q4_0 पेक्षा जवळजवळ समान फाइल आकारात अधिक चांगले आउटपुट देते.

तुम्ही टाइप केलेल्या नावावरून अंदाज लावण्याऐवजी, डिस्कवर काय आहे हे Ollama ला विचारा:

ollama pull qwen3:8b-q4_K_M
ollama show qwen3:8b-q4_K_M

ollama show हे architecture, parameters, quantization, context length आणि embedding length प्रिंट करते. quantization ओळ ही तुम्ही काही महिन्यांपूर्वी पुल केलेल्या आणि निवडल्याचे आता आठवत नसलेल्या मॉडेलसाठी खरी माहिती (ground truth) असते.

फाईलचा आकार ठरवणारे 'बिट्स पर वेट' (Bits per weight)

फाईलच्या आकाराचा कोणताही अंदाज एका संख्येपासून सुरू होतो: संपूर्ण फाईलमध्ये सरासरी किती बिट्स प्रति वेट (bits per weight) वापरले जातात. llama.cpp ने त्यांच्या quantize दस्तऐवजीकरणामध्ये Llama 3.1 8B साठी मोजलेली आकडेवारी दिली आहे, जी समान रचनेच्या कोणत्याही dense मॉडेलसाठी लागू पडते.

[
  {
    "label": "F16",
    "bits_per_weight": 16,
    "file_gib": 14.96
  },
  {
    "label": "Q8_0",
    "bits_per_weight": 8.5,
    "file_gib": 7.95
  },
  {
    "label": "Q6_K",
    "bits_per_weight": 6.56,
    "file_gib": 6.14
  },
  {
    "label": "Q5_K_M",
    "bits_per_weight": 5.7,
    "file_gib": 5.33
  },
  {
    "label": "Q4_K_M",
    "bits_per_weight": 4.89,
    "file_gib": 4.58
  },
  {
    "label": "Q3_K_M",
    "bits_per_weight": 3.99,
    "file_gib": 3.74
  }
]

त्या तक्त्यातील दुसरा स्तंभ आश्चर्यकारक आहे. Q4_K_M म्हणजे चार बिट्स प्रति वेट असे नाही. याचे मोजमाप 4.89 बिट्स इतके येते, कारण ब्लॉक स्केल्स आणि प्रमोट केलेले टेन्सर्स (promoted tensors) यासाठी प्रत्यक्ष जागा लागते. याच कारणामुळे Q8_0 चे मोजमाप आठ ऐवजी 8.5 बिट्स येते. मोजलेल्या संख्येचा वापर केल्यास, गणिताचे उत्तर प्रत्यक्ष फाईलच्या आकाराच्या काही टक्के फरकाने मिळते:

weight bytes = parameter count x bits per weight / 8
8.03e9 params x 4.89 bits / 8 = 4.91e9 bytes = 4.57 GiB

ही 4.58 GiB आकाराची Q4_K_M फाईल आहे, जी दोन संख्यांवरून काढली आहे. लोड झाल्यानंतर वेट्स (weights) जेवढी मेमरी व्यापतात, ती देखील साधारणपणे इतकीच असते. Ollama लोड करताना कोणतीही गोष्ट अनपॅक (unpack) करत नाही: क्वांटाइज्ड वेट्स मेमरीमध्ये त्याच पॅक केलेल्या स्वरूपात राहतात आणि प्रत्येक ब्लॉक वापरला जातो तेव्हा त्याचे रूपांतर केले जाते.

Ollama प्रत्येक मॉडेल साईझसाठी नेमके काय रिलीज करते

बहुतेक फॅमिलीसाठी लायब्ररी एक q4_K_M, एक q8_0 आणि एक fp16 टॅग प्रकाशित करते. काही नवीन फॅमिली या पॅटर्नचे पालन करत नाहीत आणि लायब्ररीमध्ये केवळ क्लाउड-ओन्ली टॅग म्हणून दिसतात, ज्यामध्ये पुल करण्यासाठी काहीही नसते. जेव्हा तुम्ही VPS वर GLM 5.2 चालवण्याचा प्रयत्न करता तेव्हा तुम्हाला ही अडचण येते. ऑगस्ट 2026 पर्यंत Qwen3 च्या साईझ खालीलप्रमाणे आहेत, ज्या मॉडेल पेजवरील टॅग लिस्टवरून घेतल्या आहेत. खालील प्रत्येक आकडा हा रॅममध्ये येण्यापूर्वीचा डिस्कवरील आकार आहे. यातील दोन किंवा तीन मॉडेल्स एकत्र केल्यास लहान VPS चे रूट व्हॉल्यूम भरून जाऊ शकते. त्यामुळे टॅग गोळा करण्यापूर्वी Ollama डाउनलोड केलेले मॉडेल्स कुठे साठवते हे जाणून घेणे फायदेशीर ठरते.

[
  {
    "label": "Qwen3 4B",
    "q4_K_M_gb": 2.6,
    "q8_0_gb": 4.4,
    "fp16_gb": 8.1
  },
  {
    "label": "Qwen3 8B",
    "q4_K_M_gb": 5.2,
    "q8_0_gb": 8.9,
    "fp16_gb": 16
  },
  {
    "label": "Qwen3 14B",
    "q4_K_M_gb": 9.3,
    "q8_0_gb": 16,
    "fp16_gb": 30
  },
  {
    "label": "Qwen3 32B",
    "q4_K_M_gb": 20,
    "q8_0_gb": 35,
    "fp16_gb": 66
  }
]

येथे डिफॉल्ट टॅग महत्त्वाचा आहे. ollama pull qwen3:8b हे अगदी ollama pull qwen3:8b-q4_K_M इतकेच 5.2 GB डाउनलोड करते, कारण ज्या टॅगला कोणताही सफिक्स नाही तोच q4_K_M बिल्ड असतो. Q4_K_M हा लायब्ररीने नाईलाजाने दिलेला पर्याय नाही. हा अपस्ट्रीमने निवडलेला डिफॉल्ट पर्याय आहे, त्यामुळे तुम्ही स्वतः टेस्ट न केलेल्या कोणत्याही मॉडेलसाठी हाच पहिला योग्य पर्याय ठरतो. VPS वर Qwen 3 चालवताना टॅग निवडण्यामागे हेच तर्कशास्त्र असते.

हे प्रमाण प्रत्येक ओळीसाठी लागू होते. q4_K_M वरून q8_0 वर जाण्यासाठी दुप्पट खर्च येत नाही, तर सुमारे सत्तर टक्के जास्त जागा लागते, कारण एम्बेडिंग आणि आउटपुट टेन्सर्स इतर भागांप्रमाणे स्केल होत नाहीत. fp16 हे q4_K_M च्या तुलनेत साधारणपणे तीन पट असते. q4_K_M वरील 32B मॉडेलचे वजन 20 GB असते, जे 16 GB च्या सर्व्हरवर कोणत्याही कॉन्टेक्स्ट विंडोसह मावणे कठीण आहे. कोणत्या मशीनवर कोणते मॉडेल बसू शकते, याच्या अधिक माहितीसाठी तुम्ही कोणते मॉडेल्स self-host करू शकता हे पहा.

KV cache हा संदर्भावर आधारित दुसरा खर्च का आहे

Weights हा स्थिर खर्च आहे. KV cache (key and value cache) हा परिवर्तनीय खर्च आहे. कॉन्टेक्स्ट विंडोमधील प्रत्येक टोकन प्रत्येक लेयरसाठी त्याचे key आणि value वेक्टर्स राखून ठेवते, त्यामुळे तुम्ही परवानगी दिलेल्या विंडोच्या आकारानुसार हा cache रेषीय पद्धतीने वाढतो. मॉडेल लोड होतानाच संपूर्ण विंडोसाठी मेमरी आरक्षित केली जाते, संभाषणादरम्यान ती हळूहळू भरली जात नाही. म्हणूनच, केवळ एका शब्दाच्या प्रॉम्प्टसाठीही मोठ्या विंडोमुळे मेमरीचा वापर होतो.

KV bytes per token = 2 (key and value) x layers x kv_heads x head_dim x bytes_per_element
Qwen3 8B at f16:  2 x 36 x 8 x 128 x 2 = 147456 bytes = 144 KiB per token

मॉडेलचे हे आकडे त्याच्या स्वतःच्या कॉन्फिगरेशनमधून येतात: 36 लेयर्स, 8 key/value हेड्स आणि 128 चा हेड डायमेन्शन. ollama show तुम्हाला आर्किटेक्चर आणि पॅरामीटरची संख्या देते, तर Hugging Face वरील मॉडेलचे config.json तुम्हाला उर्वरित माहिती देते. प्रति टोकन खर्चाला विंडोच्या आकाराने गुणले की, cache हा केवळ नगण्य आकडा राहत नाही.

[
  {
    "label": "4k",
    "kv_cache_gb": 0.6,
    "floor_ram_gb": 5.8
  },
  {
    "label": "8k",
    "kv_cache_gb": 1.21,
    "floor_ram_gb": 6.4
  },
  {
    "label": "16k",
    "kv_cache_gb": 2.42,
    "floor_ram_gb": 7.6
  },
  {
    "label": "32k",
    "kv_cache_gb": 4.83,
    "floor_ram_gb": 10
  }
]

Ollama च्या 4096 टोकन्सच्या डीफॉल्ट विंडोवर, cache हा weights च्या वर 0.6 GB इतकी भर घालतो. जर विंडो 32k पर्यंत वाढवली, तर केवळ cache चा आकार 4.83 GB पर्यंत पोहोचतो, जो quantized weights च्या मेमरीच्या जवळपास इतकाच असतो. अशा वेळी संपूर्ण मॉडेलसाठी लागणारी किमान मेमरी 10 GB होते. याला 'किमान' (floor) म्हणण्याचे कारण असे की, यावर compute buffers आणि ऑपरेटिंग सिस्टमचा अतिरिक्त भार असतो. मॉडेल लोड झाल्यानंतर ollama ps मधील SIZE कॉलममधून प्रत्यक्ष आकडा तपासा.

जेव्हा तुम्ही Ollama सर्व्हिस म्हणून चालवता, तेव्हा विंडो सर्व्हर स्तरावर सेट केली जाते, प्रति विनंती (per request) नाही:

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

systemd इन्स्टॉलेशनसाठी, ती एका drop-in फाईलमध्ये ठेवा:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

sudo systemctl restart ollama वापरून सर्व्हिस रीस्टार्ट करा, त्यानंतर चालू असलेल्या मॉडेलची विंडो कन्फर्म करण्यासाठी ollama ps मधील CONTEXT कॉलम तपासा. OLLAMA_KV_CACHE_TYPE हे cache ला स्वतःलाच quantize करते: f16 हा डीफॉल्ट पर्याय आहे, q8_0 हा f16 च्या तुलनेत निम्मी मेमरी वापरतो, आणि q4_0 हा सुमारे एक चतुर्थांश मेमरी वापरतो. हा एक जागतिक (global) पर्याय आहे, त्यामुळे सर्व्हरवरील प्रत्येक मॉडेलला तोच नियम लागू होतो. मोठ्या विंडो असलेल्या लहान मशीनवर, cache अर्धा केल्याने इतर कोणत्याही बदलापेक्षा जास्त मेमरी मोकळी होते. num_ctx सेट करणे आणि त्याचा खर्च मध्ये विंडोबद्दल सविस्तर माहिती दिली आहे. तसेच, cache चे आकारमान प्रति सर्व्हर एकदा नसून प्रति concurrent request स्लॉट एकदा ठरवले जाते. त्यामुळे Ollama ला एकाच वेळी दोन प्रॉम्प्ट्सना उत्तर देण्याची परवानगी दिल्यास, तुम्ही मोजलेला आकडा दुप्पट होतो. पॅरलल स्लॉट संख्या आणि रांगेची मर्यादा निवडणे यामागील हेच गणित आहे.

8, 16 किंवा 32 GB VPS वर काय बसू शकते

मॉडेलचे वजन (weights), KV cache आणि ऑपरेटिंग सिस्टम व इतर चालू असलेल्या प्रक्रियांच्या गरजा यांचा विचार करणे आवश्यक आहे. लहान VPS वर 2 GB ची अतिरिक्त जागा (headroom) पुरेशी असते.

8 GB. q4_K_M मधील 4B मॉडेल 2.6 GB जागा घेते आणि मोठ्या window साठी पुरेशी जागा शिल्लक ठेवते. q4_K_M मधील 8B मॉडेल डीफॉल्ट 4k window सह बसते, पण त्यात फारशी मोकळी जागा उरत नाही. येथे 32k window सह 8B मॉडेल चालवण्याचा विचार करू नका, कारण 10 GB ची किमान मर्यादा आधीच मर्यादेच्या बाहेर जाते.

16 GB. 16k किंवा 32k window सह q4_K_M मधील 8B मॉडेल आरामात चालते. q4_K_M मधील 14B मॉडेलचे वजन 9.3 GB आहे आणि ते एका मर्यादित window सह बसते. q8_0 मधील 8B मॉडेल 8.9 GB चे आहे, त्यामुळे ते देखील बसते. या दोन्ही मॉडेल्सची तुमच्या स्वतःच्या प्रॉम्प्ट्सवर तुलना करणे, हा या विषयावर घालवलेला सर्वात उपयुक्त वेळ ठरेल.

32 GB. q8_0 मधील 14B (16 GB) आणि q4_K_M मधील 32B (20 GB) ही दोन्ही मॉडेल्स लोड होतात. मोठ्या window सह 32B बिल्ड वापरताना ते क्षमतेच्या मर्यादेपर्यंत पोहोचेल, त्यामुळे गृहीत धरण्यापेक्षा ollama ps वर लक्ष ठेवा.

क्वांटायझेशनमध्ये प्रथम काय खराब होते

क्वांटायझेशनमुळे होणारी त्रुटी मॉडेलच्या सर्व कार्यांवर समान रीतीने पसरत नाही. भाषेचा ओघ (fluency) सर्वात जास्त काळ टिकून राहतो, आणि म्हणूनच हे नुकसान ओळखणे कठीण असते: खराब क्वांटायझेशन केलेले मॉडेल देखील स्पष्ट वाक्ये लिहू शकते. अचूकता (precision) सर्वात आधी कमी होते. जसे की, व्हर्जन नंबर, API सिग्नेचर किंवा तारखेची तंतोतंत आठवण. तर्कशास्त्राच्या लांब साखळ्या, जिथे दुसऱ्या पायरीवरील एक छोटी चूक आठव्या पायरीवर चुकीचे उत्तर देते. तसेच, कठोर आउटपुट फॉरमॅट्स, जिथे एक चुकीचा कंस (bracket) टूल कॉल अयशस्वी करतो.

शेवटचा मुद्दा ही एक व्यावहारिक चाचणी आहे. जेव्हा मॉडेलला JSON फॉरमॅटमध्ये उत्तर द्यावे लागते जे तुमचा कोड पार्स करतो, तेव्हा क्वांटायझेशनचे नुकसान हे अस्पष्ट लेखनाऐवजी पार्सिंग एरर म्हणून समोर येते, त्यामुळे तुम्हाला ते त्याच दिवशी समजते. कोडिंग एजंट ही या चाचणीची सर्वात कठीण आवृत्ती आहे, कारण ते मॉडेलला एकामागून एक टूल कॉल करायला भाग पाडते. त्यामुळे तुमच्या Ollama सर्व्हरवर एजंट वापरून पाहणे तुम्हाला काही तासांतच अति-आक्रमक क्वांटायझेशनचे परिणाम दाखवून देईल.

चार बिट्सच्या खाली कार्यक्षमता वेगाने कमी होते. q3 आणि दोन बिट प्रकार अशा लोकांसाठी आहेत जे मोठ्या मॉडेलला लहान हार्डवेअरवर बसवण्याचा प्रयत्न करत आहेत, आणि जेव्हा मॉडेल न चालवण्यापेक्षा हा पर्याय निवडणे भाग असते, तेव्हा ते उपयुक्त ठरतात. मात्र, हे डिफॉल्ट म्हणून वापरणे चुकीचे आहे. q4_K_M आणि q8_0 मधील फरक इतका कमी आहे की केवळ प्रसिद्ध केलेली perplexity टेबल तुमच्या वर्कलोडसाठी निर्णय घेऊ शकत नाही, त्यामुळे त्या आधारावर निर्णय घेऊ नका. तुमच्या स्वतःच्या तीस प्रॉम्प्ट्सवर दोन्ही चालवून पहा आणि आउटपुट तपासा.

q8_0 किंवा fp16 कधी वापरावे

जेव्हा मेमरी मुबलक उपलब्ध असते आणि कामात लहान चुकाही चालत नाहीत, तेव्हा q8_0 वापरा: जसे की स्ट्रक्चर्ड एक्सट्रॅक्शन (structured extraction), टूल कॉलिंग किंवा कोड जो कंपाईल होणे आवश्यक आहे. येथे तुम्ही मॉडेलची बुद्धिमत्ता वाढवत नसून, त्रुटींपासून संरक्षण मिळवत आहात.

fp16 केवळ दोन कारणांसाठी वापरा. एकतर तुम्ही स्वतः मॉडेलचे क्वांटायझेशन करत आहात आणि तुम्हाला सोर्स फाईलची गरज आहे, किंवा तुम्ही बेसलाईन मोजत आहात जेणेकरून तुमच्या फोर-बिट बिल्डमध्ये किती अचूकता कमी झाली हे तुम्हाला समजेल. fp16 वरून सर्व्हिंग केल्यास q4_K_M च्या तुलनेत तीनपट मेमरी खर्च होते, ज्यातील फरक बहुतेक लोकांना ओळखता येत नाही. तसेच, केवळ CPU असलेल्या मशीनवर यामुळे तुमचा टोकन रेट एक-तृतीयांश होतो.

निश्चित मेमरी बजेट असताना एक महत्त्वाचा नियम: q4_K_M वरील मोठे मॉडेल हे सहसा q8_0 वरील लहान मॉडेलपेक्षा सरस ठरते. 9.3 GB चे 14B वेट्स आणि 8.9 GB चे 8B वेट्स यासाठी जवळपास सारखीच RAM (random access memory) लागते, परंतु मोठे मॉडेल अधिक माहितीपूर्ण असते. हे कोणाच्या सांगण्यावर विश्वास ठेवण्यापेक्षा स्वतःच्या प्रॉम्प्ट्सवर तपासून पहा.

केवळ CPU वर आधारित इन्फरन्स मेमरी बँडविड्थमुळे मर्यादित असतो

बहुतेक VPS प्लॅन्समध्ये GPU नसतो, त्यामुळे मॉडेल होस्ट CPU च्या सिस्टिम मेमरीमध्ये चालते. अशा वेळी जनरेशनचा वेग हा गणिताच्या क्षमतेवर नाही, तर मेमरी बँडविड्थवर अवलंबून असतो, कारण एक टोकन तयार करण्यासाठी प्रत्येक वेट (weight) एकदा वाचावे लागते. यामुळे एक अशी मर्यादा येते ज्याचा तुम्ही किती कोअर्स (cores) विकत घेतले आहेत याच्याशी काहीही संबंध नसतो.

tokens per second ceiling = memory bandwidth / bytes read per token
50 GB/s / 5.2 GB  =  9.6 tokens/s    qwen3 8B q4_K_M
50 GB/s / 8.9 GB  =  5.6 tokens/s    qwen3 8B q8_0
50 GB/s / 16 GB   =  3.1 tokens/s    qwen3 8B fp16

50 GB/s हा ड्युअल चॅनेल DDR4-3200 होस्टसाठीचा अंदाजे सैद्धांतिक आकडा आहे. तुमचा वाटा त्यापेक्षा कमी असतो, कारण VPS वर मशीनमधील इतर सर्व भाडेकरूंसोबत (tenants) ती बस शेअर केली जाते. त्यामुळे या आकड्यांकडे अशी मर्यादा म्हणून पहा जिथे कोणीही पोहोचू शकत नाही. यातील महत्त्वाचा भाग म्हणजे आकारमान: CPU वर, प्रति वेट बिट्स निम्म्यावर आणल्यास टोकन रेट साधारणपणे दुप्पट होतो. GPU नसलेल्या बॉक्सवर क्वांटायझेशन (quantization) हे वेग वाढवण्याचे सर्वात प्रभावी साधन आहे. उरलेला वेग तुमच्यासाठी स्वीकारार्ह आहे का, हे मॉडेलवर अवलंबून असते आणि VPS वर Nemotron 3.5 Lightning हे विशिष्ट बिल्ड, टॅग आणि RAM च्या आकडेवारीसह त्याचे विश्लेषण करते. प्रतीक्षेचा दुसरा भाग म्हणजे मॉडेल किती मजकूर लिहिण्याचे ठरवते, कारण 10 टोकन्स प्रति सेकंद या वेगाने 600 टोकन्सचे उत्तर मिळण्यासाठी पूर्ण एक मिनिट लागतो. त्यामुळे num_predict वापरून उत्तरावर मर्यादा घालणे हे अचूकता (precision) कमी करण्यापेक्षा जास्त वेळ वाचवू शकते.

प्रॉम्प्ट प्रोसेसिंगची वागणूक वेगळी असते. मोठा प्रॉम्प्ट वाचणे हे बँडविड्थपेक्षा कॉम्प्युटवर (compute) अवलंबून असते, त्यामुळे तिथे अतिरिक्त कोअर्स मदत करतात, तर जनरेशनच्या वेगावर त्यांचा काहीही परिणाम होत नाही. जो बॉक्स 4k प्रॉम्प्ट वेगाने स्वीकारतो आणि त्यानंतर हळू जनरेट करतो, तो सामान्यपणे काम करत आहे असे समजावे.

कोणत्याही गणितावर आंधळेपणाने विश्वास ठेवू नका. तुमच्या स्वतःच्या बॉक्सवर प्रति सेकंद टोकन्स मोजा आणि प्रत्येक क्वांटायझेशनसाठी समान प्रॉम्प्ट वापरून मिळालेल्या आकड्यांनाच अंतिम माना.

स्वतः मॉडेलचे क्वांटायझेशन करणे

तुमच्याकडे जर एखादे फाइन-ट्यून केलेले मॉडेल असेल आणि त्यासाठी कोणतीही लायब्ररी टॅग उपलब्ध नसेल, तर Ollama fp16 किंवा fp32 सोर्सपासून क्वांटाइज्ड मॉडेल तयार करू शकते. Modelfile मध्ये अनक्वांटाइज्ड वेट्सचा (weights) संदर्भ द्या:

FROM /path/to/my/model/f16

त्यानंतर मॉडेल बिल्ड करा आणि खात्री करा:

ollama create --quantize q4_K_M mymodel
ollama show mymodel

--quantize मध्ये q8_0, q4_K_S आणि q4_K_M स्वीकारले जातात. येथे q6_K किंवा q5_K_M चा पर्याय उपलब्ध नाही, त्यामुळे अशा मॉडेल्ससाठी तुम्हाला llama.cpp च्या स्वतःच्या टूलचा वापर करून क्वांटायझेशन करावे लागेल आणि तयार झालेली GGUF फाइल इम्पोर्ट करावी लागेल. या इम्पोर्ट प्रक्रियेत चॅट टेम्पलेट जुळत नसल्यास मॉडेल चुकीचे उत्तर देऊ शकते, या समस्येचे निराकरण Ollama मध्ये GGUF फाइल इम्पोर्ट करणे या मार्गदर्शिकेत दिले आहे. बिल्ड तुमच्या अपेक्षेप्रमाणे झाले आहे की नाही हे तपासण्यासाठी ollama show मधील quantization ओळ वापरा.

जेव्हा काही बिघडते तेव्हा काय दिसते

तुम्ही GPU ची अपेक्षा केली असताना सर्व काही CPU वर चालते. PROCESSOR कॉलम वाचा:

ollama ps

हे 100% GPU, 100% CPU, किंवा 48%/52% CPU/GPU सारखे विभाजन दर्शवते. विभाजनाचा अर्थ असा आहे की weights आणि KV cache हे VRAM (ग्राफिक्स कार्डवरील मेमरी) मध्ये मावले नाहीत, त्यामुळे मॉडेलचा काही भाग सिस्टम मेमरीमध्ये ठेवला गेला आहे. प्रत्येक टोकन धीम्या भागाची वाट पाहत असल्याने वेग थेट CPU च्या वेगाच्या जवळ येतो. कॉन्टेक्स्ट विंडो कमी करा, कॅशे क्वांटाइज करा किंवा लहान बिल्ड वापरा. अधिक कोअर्स जोडल्याने काहीही उपयोग होणार नाही.

लोड होत असताना मॉडेल बंद (kill) केले जाते. कर्नल आणि सर्व्हिस लॉग तपासा:

sudo dmesg -T | grep -i "out of memory"
sudo journalctl -u ollama -n 50

Out of memory: Killed process असलेली ओळ दर्शवते की weights, KV cache आणि बफरची एकूण मेमरी बॉक्समधील मेमरीपेक्षा जास्त झाली आहे. ज्या VPS वर swap कॉन्फिगर केलेले नाही, तिथे ती ओळ दिसण्यापूर्वी संपूर्ण मशीन काही सेकंदांसाठी स्तब्ध होऊ शकते.

तुम्ही काहीही बदलले नसताना उत्तरे खराब झाली आहेत. एकाच मॉडेलचे दोन बिल्ड्स ollama ls मध्ये वेगवेगळ्या टॅग्स अंतर्गत असू शकतात आणि जो स्क्रिप्ट unsuffixed नाव पुल करते, ती लायब्ररी सध्या ज्याला पॉइंट करत आहे त्याचे अनुसरण करेल. तुमच्या क्लायंटने विनंती केलेल्या नेमक्या टॅगवर ollama show चालवा आणि quantization ओळ वाचा, तुमच्या कॉन्फिगरेशन फाईलमधील नावावर विश्वास ठेवण्याऐवजी हे करा.

FAQ

मी Ollama चे कोणते quantization pull करावे?

q4_K_M ने सुरुवात करा. Ollama लायब्ररी बहुतेक मॉडेल्ससाठी डीफॉल्ट टॅग म्हणून हेच देते, त्यामुळे ollama pull qwen3:8b आणि ollama pull qwen3:8b-q4_K_M दोन्ही एकाच फाईलला फेच करतात. जेव्हा मेमरी मुबलक असते आणि कामामध्ये लहान चुकाही चालत नाहीत, जसे की tool calling किंवा structured JSON output, तेव्हाच q8_0 कडे वळा. जेव्हा मेमरी बजेट मर्यादित असते, तेव्हा q4_K_M वरील मोठे मॉडेल हे q8_0 वरील लहान मॉडेलपेक्षा सरस ठरते, त्यामुळे अचूकतेसाठी RAM खर्च करण्यापूर्वी या जोडीची चाचणी घ्या.

q4_K_M चा अर्थ खरोखरच प्रति वेट चार बिट्स असा होतो का?

नाही. Llama 3.1 8B वर मोजल्यास हे 4.89 बिट्स प्रति वेट आहे, कारण प्रत्येक वेट ब्लॉक स्वतःचे स्केल साठवतो आणि सर्वात संवेदनशील tensors अधिक मोठ्या प्रकारात (wider type) रूपांतरित केले जातात. याच कारणामुळे Q8_0 हे आठ ऐवजी 8.5 बिट्स मोजले जाते. अंदाज लावताना मोजलेल्या आकड्याचा वापर करा: पॅरामीटर संख्या गुणिले बिट्स प्रति वेट, भागिले आठ, यावरून फाईलचा आकार बाईट्समध्ये मिळतो.

फक्त CPU असलेल्या VPS वर 8B मॉडेलला किती RAM लागते?

वेट्स, KV cache आणि हेडरुम यांची बेरीज करा. q4_K_M वरील Qwen3 8B चे वेट्स 5.2 GB आहेत. डीफॉल्ट 4096 टोकन विंडोवर, कॅशे 0.6 GB भर घालते, ज्यामुळे compute buffers आणि ऑपरेटिंग सिस्टमच्या आधीच किमान 5.8 GB ची गरज पडते. 32k विंडोवर, फक्त कॅशेच 4.83 GB असते. लहान विंडोसाठी 8 GB आणि मोठ्या विंडोसाठी 16 GB RAM चे नियोजन करा.

सर्व्हरवर GPU असूनही माझे मॉडेल 100% CPU का वापरत आहे?

ollama ps चालवा आणि PROCESSOR कॉलम वाचा. 100% CPU, किंवा 48%/52% CPU/GPU सारखे स्प्लिट, याचा अर्थ असा की वेट्स आणि KV कॅशे VRAM मध्ये मावत नाहीत, म्हणून Ollama ने मॉडेलचा काही भाग किंवा पूर्ण मॉडेल सिस्टम मेमरीमध्ये ठेवले आहे. याचे सामान्य कारण म्हणजे कार्डच्या क्षमतेपेक्षा मोठी असलेली कॉन्टेक्स्ट विंडो, कारण मॉडेल लोड होताना संपूर्ण विंडोसाठी कॅशे अलोकेट केली जाते. OLLAMA_CONTEXT_LENGTH वापरून विंडो कमी करा, OLLAMA_KV_CACHE_TYPE=q8_0 सेट करून कॅशे अर्धी करा, किंवा लहान quantization pull करा.