Ollama quantization: Q4, Q8 নাকি fp16 নেবেন?

Ollama quantization কী পরিবর্তন করে

Ollama quantization একটি model-এর প্রতিটি weight সেই model যে bit depth-এ train করা হয়েছিল, তার চেয়ে কম bit-এ সংরক্ষণ করে। q4_K_M দিয়ে শেষ হওয়া tag প্রতি weight-এ প্রায় চার bit রাখে, আর fp16 রাখে ষোলো bit। তাই download-এর আকার প্রায় এক-চতুর্থাংশ হয় এবং প্রতিটি token তৈরি করতে machine-কে প্রায় এক-চতুর্থাংশ byte পড়তে হয়। Weight বাদ দেওয়া হয় না; সেগুলোকে একটি মোটা grid-এর মানে round করা হয়। চার bit-এ বেশির ভাগ model full precision-এর কাছাকাছি উত্তর দেয়।

এটাই মূল trade-off: memory footprint অনেক কমে এবং প্রতি second-এ বেশি token তৈরি হয়, বিনিময়ে accuracy সামান্য কমে। নির্দিষ্ট model ও নির্দিষ্ট box-এর ক্ষেত্রে এই দুই দিক কী হতে পারে, তা আগে অনুমান করার পদ্ধতি নিচে দেওয়া হলো। এতে এমন একটি file download করতে বিশ মিনিট নষ্ট হবে না, যা পরে আপনার machine-এ fit করবে না।

Ollama এখনও চালু না থাকলে Ollama install করা দিয়ে শুরু করুন। এই পৃষ্ঠায় ধরে নেওয়া হয়েছে যে ollama ls ইতিমধ্যে কাজ করছে।

q4_K_M-এর মতো Ollama quantization tag কীভাবে পড়বেন

Local model GGUF file হিসেবে প্রকাশ করা হয়। এটি এমন একটি format, যা llama.cpp disk-এ weight সংরক্ষণ করতে ব্যবহার করে। Ollama llama.cpp-এর ওপর তৈরি, তাই Ollama tag-এ llama.cpp-এর quantization name অপরিবর্তিত থাকে।

সংখ্যাটি target width নির্দেশ করে। q4 মানে অধিকাংশ weight tensor প্রতি weight-এ চার bit করে packed থাকে। q8 মানে আট bit। fp16 কোনোভাবেই quantized নয়: এটি sixteen-bit floating point-এ model, যে precision-এ অধিকাংশ model প্রকাশ করা হয়।

K একটি K-quant নির্দেশ করে। Weight-গুলো ছোট ছোট block-এ ভাগ করা হয়, এবং প্রতিটি block-এ packed value-এর পাশে নিজস্ব scale সংরক্ষিত থাকে। কোনো block-এর সব weight যদি 0.01-এর কাছাকাছি থাকে, তাহলে সেটি সূক্ষ্ম scale পায়। কোনো block-এ একটি বড় outlier থাকলে সেটি অপেক্ষাকৃত মোটা scale পায়। প্রতি-block scale-ই চার-bit file-কে ব্যবহারযোগ্য রাখে। এ কারণেই চার-bit file-এ প্রতি weight ঠিক চার bit হয় না।

শেষের অক্ষরটি mixture নির্দেশ করে। S, M এবং L নির্ধারণ করে target width-এর চেয়ে বেশি bit-এ কতগুলো tensor সংরক্ষণ করা হবে। q4_K_M-এ rounding-এর কারণে যেসব tensor-এর মান সবচেয়ে বেশি ক্ষতিগ্রস্ত হয়, সেগুলো বেশি width-এ সংরক্ষণ করা হয়, আর অধিকাংশ tensor চার bit-এই থাকে। এ কারণেই প্রায় একই file size-এ q4_K_M পুরোনো q4_0-এর চেয়ে ভালো output দেয়।

আপনি যে name লিখেছেন তা দেখে অনুমান না করে, disk-এ Ollama কী সংরক্ষণ করেছে তা জিজ্ঞাসা করুন:

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

ollama show, architecture, parameters, quantization, context length এবং embedding length প্রকাশ করে। কয়েক মাস আগে pull করা এবং তখন কোনটি বেছে নিয়েছিলেন তা আর মনে না থাকা model-এর ক্ষেত্রে quantization line-ই নির্ভরযোগ্য তথ্য।

প্রতি weight-এ bit থেকেই ফাইলের আকার নির্ধারিত হয়

প্রতিটি আকারের হিসাব একটি সংখ্যা থেকে শুরু হয়: পুরো ফাইল জুড়ে গড়ে format প্রতি weight-এ কত bit ব্যবহার করে। llama.cpp তার quantize documentation-এ Llama 3.1 8B-এর পরিমাপ করা মান প্রকাশ করে, এবং একই ধরনের dense model-এর ক্ষেত্রেও এই মানগুলো ভালোভাবে প্রযোজ্য।

[
  {
    "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
  }
]

ওই table-এর দ্বিতীয় column-টিই সবচেয়ে গুরুত্বপূর্ণ। Q4_K_M প্রতি weight-এ চার bit ব্যবহার করে না। এর পরিমাপ করা মান 4.89 bit, কারণ block scale এবং promoted tensor-গুলোর জন্যও বাস্তব storage space লাগে। একই কারণে Q8_0 আট bit-এর পরিবর্তে 8.5 bit ব্যবহার করে। পরিমাপ করা মান ব্যবহার করলে হিসাবটি বাস্তব ফাইলের আকারের কয়েক শতাংশের মধ্যেই থাকে:

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

দুটি সংখ্যা থেকে হিসাব করে পাওয়া Q4_K_M ফাইলটির আকার 4.58 GiB। ফাইল load করার পর weight-গুলো যত memory দখল করে, সেটিও প্রায় একই। Ollama load করার সময় কিছু unpack করে না। Quantized weight-গুলো একই packed form-এ memory-তে থাকে এবং ব্যবহারের সময় প্রতিটি block convert করা হয়।

Ollama প্রতিটি model size-এর জন্য আসলে যা প্রকাশ করে

বেশিরভাগ family-এর জন্য library একটি q4_K_M, একটি q8_0 এবং একটি fp16 tag প্রকাশ করে। কয়েকটি নতুন family এই ধারা অনুসরণ করে না। সেগুলো library-তে শুধু cloud-only tag হিসেবে দেখা যায়; কোনো width-এর জন্যই pull করার মতো কিছু থাকে না। VPS-এ GLM 5.2 চালানোর চেষ্টা করার সময় আপনি এই সীমাবদ্ধতার মুখোমুখি হন। এগুলো August 2026 অনুযায়ী Qwen3-এর size, এবং model page-এর tag list থেকে নেওয়া। নিচের প্রতিটি figure disk-এর মাপ, RAM-এর নয়। এর মধ্যে দুই বা তিনটি একসঙ্গে একটি ছোট VPS-এর root volume পূর্ণ করে দিতে পারে। তাই tag সংগ্রহ শুরু করার আগে Ollama ডাউনলোড করা model কোথায় সংরক্ষণ করে তা জানা গুরুত্বপূর্ণ।

[
  {
    "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
  }
]

এখানে default tag গুরুত্বপূর্ণ। ollama pull qwen3:8b ঠিক ollama pull qwen3:8b-q4_K_M-এর মতোই 5.2 GB ডাউনলোড করে, কারণ suffix-বিহীন tag-টিই q4_K_M build। Q4_K_M এমন কোনো compromise নয়, যা library অনিচ্ছায় দেয়। এটিই upstream-এর নির্বাচিত default। তাই নিজে পরীক্ষা না করা যেকোনো model-এর ক্ষেত্রে এটিই প্রথমে ব্যবহার করা যুক্তিসঙ্গত। VPS-এ Qwen 3 চালানোর ক্ষেত্রেও একই যুক্তিতে tag বেছে নেওয়া হয়।

এই অনুপাত প্রতিটি row-তেই প্রযোজ্য। q4_K_M থেকে q8_0-তে গেলে আকার ঠিক দ্বিগুণ না হয়ে প্রায় সত্তর শতাংশ বাড়ে। কারণ embedding এবং output tensor-এর আকার বাকি tensor-এর মতো একই হারে বাড়ে না। fp16-এর আকার q4_K_M-এর প্রায় তিন গুণ। q4_K_M-এ একটি 32B model-এর weights-এর আকার 20 GB। কোনো context window রাখার আগেই এটি 16 GB-এর machine-এর ধারণক্ষমতা ছাড়িয়ে যায়। কোন machine-এ কোন model চলে, তার বিস্তৃত ধারণার জন্য কোন model আপনি self-host করতে পারবেন তা দেখুন।

KV cache কেন দ্বিতীয়, context নির্ভর খরচ

Weights হলো স্থির খরচ। KV cache (key এবং value cache) হলো পরিবর্তনশীল খরচ। context window-এর প্রতিটি token-এর জন্য প্রতিটি layer-এ key এবং value vector সংরক্ষিত থাকে। তাই অনুমোদিত window-এর আকারের সঙ্গে cache সরলরেখায় বাড়ে। model load হওয়ার সময় পুরো window-এর জন্য cache বরাদ্দ করা হয়; conversation যত বড় হয়, তত ধীরে ধীরে এটি বরাদ্দ হয় না। এ কারণেই এক শব্দের prompt হলেও দীর্ঘ window memory খরচ করে।

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

এই model number-গুলো model-এর নিজস্ব configuration থেকে এসেছে: 36টি layer, 8টি key/value head এবং 128 head dimension। ollama show-এ architecture ও parameter count পাওয়া যায়। Hugging Face-এ model-এর config.json থেকে বাকি তথ্য পাওয়া যায়। প্রতি token-এর খরচকে window size দিয়ে গুণ করলে cache আর rounding error থাকে না।

[
  {
    "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 token-এর default window-এ weights-এর ওপর cache আরও 0.6 GB memory যোগ করে। Window 32k করলে শুধু cache-ই 4.83 GB-এ পৌঁছায়। এটি quantized weights-এর প্রায় সমান memory। ফলে পুরো model-এর ন্যূনতম memory হয়ে যায় 10 GB। এটিকে ন্যূনতম হিসাব বলা হচ্ছে, কারণ compute buffer এবং operating system-এর memory এর ওপর অতিরিক্ত যোগ হয়। model load হওয়ার পরে ollama ps-এর SIZE column থেকে প্রকৃত মান দেখুন।

আপনি যখন Ollama-কে service হিসেবে চালান, তখন window server-এ নির্ধারিত হয়, প্রতিটি request-এর জন্য আলাদাভাবে নয়:

OLLAMA_CONTEXT_LENGTH=8192 ollama serve

systemd install-এর ক্ষেত্রে এর বদলে একটি drop-in file-এ সেটিংটি দিন:

sudo systemctl edit ollama

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

sudo systemctl restart ollama দিয়ে restart করুন। এরপর ollama ps-এর CONTEXT column পরীক্ষা করে চলমান model আসলে কোন window নিয়ে load হয়েছে তা নিশ্চিত করুন। OLLAMA_KV_CACHE_TYPE cache-টিকেও quantize করে। f16 হলো default। q8_0, f16-এর প্রায় অর্ধেক memory ব্যবহার করে। q4_0 ব্যবহার করলে memory প্রায় এক-চতুর্থাংশ হয়। এটি একটি global option। তাই ওই server-এর প্রতিটি model একইভাবে প্রভাবিত হয়। দীর্ঘ window-সহ ছোট server-এ cache অর্ধেক করলে অন্য যেকোনো একক পরিবর্তনের তুলনায় বেশি memory খালি হয়। num_ctx সেট করা এবং এর খরচ-এ window সম্পর্কে বিস্তারিত ব্যাখ্যা আছে। প্রতিটি server-এর জন্য একবার নয়, প্রতিটি concurrent request slot-এর জন্যও cache-এর আকার নির্ধারিত হয়। তাই Ollama-কে একসঙ্গে দুটি prompt-এর উত্তর দিতে দিলে আপনি যে হিসাব করেছেন, তা দ্বিগুণ হবে। এই হিসাবের ভিত্তিই হলো parallel slot count এবং queue limit নির্বাচন করা।

8, 16 বা 32 GB VPS-এ কী চালানো যায়

Budget weights, KV cache এবং operating system ও অন্য চলমান উপাদানগুলোর জন্য headroom—সব বিবেচনায় রাখুন। ছোট VPS-এ 2 GB headroom আরামদায়ক।

8 GB। q4_K_M-এ একটি 4B model-এর আকার 2.6 GB, তাই দীর্ঘ window-এর জন্য জায়গা থাকে। q4_K_M-এ একটি 8B model default 4k window-সহ চালানো যায়, তবে অব্যবহৃত memory খুব কম থাকে। এখানে 32k window-সহ 8B চালানোর পরিকল্পনা করবেন না, কারণ 10 GB-এর ন্যূনতম প্রয়োজনই এই VPS-এর memory সীমা ছাড়িয়ে যায়।

16 GB। q4_K_M-এ 8B model 16k বা 32k window-সহ স্বাচ্ছন্দ্যে চলে। q4_K_M-এ 14B model-এর weights-এর আকার 9.3 GB, তাই মাঝারি window-সহ এটি চালানো যায়। q8_0-এ 8B model-এর আকার 8.9 GB, তাই এটিও চালানো যায়। আপনার নিজের prompt দিয়ে এই দুই configuration তুলনা করাই এই বিষয়ে ব্যয় করা সবচেয়ে কার্যকর এক ঘণ্টা।

32 GB। q8_0-এ 14B (16 GB) এবং q4_K_M-এ 32B (20 GB)—দুটিই load করা যায়। বড় window-সহ 32B build memory ceiling-এর কাছাকাছি চলে যাবে। তাই অনুমান না করে ollama ps monitor করুন।

কোন দিকটি quantization-এ প্রথম ক্ষতিগ্রস্ত হয়

Quantization error মডেল যা করে তার সব অংশে সমানভাবে ছড়ায় না। Fluency সবচেয়ে বেশি সময় অক্ষুণ্ণ থাকে। এ কারণেই ক্ষতি বোঝা কঠিন হয়: অতিরিক্ত quantization করা মডেলও পরিষ্কার বাক্য লিখতে পারে। প্রথমে ক্ষতিগ্রস্ত হয় precision। যেমন কোনো version number, API signature বা date হুবহু মনে রাখা। দীর্ঘ reasoning chain-এ দ্বিতীয় ধাপের একটি ছোট ভুল অষ্টম ধাপে ভুল উত্তরে পরিণত হতে পারে। Strict output format-এ একটি ভুল bracket থাকলেই tool call ব্যর্থ হতে পারে।

শেষের সমস্যাটিই ব্যবহারিক পরীক্ষা। কোনো মডেলকে এমন JSON ফেরত দিতে হলে যা আপনার code parse করে, quantization-এর ক্ষতি অস্পষ্টভাবে খারাপ prose হিসেবে নয়, parse error হিসেবে দেখা দেয়। ফলে একই দিনেই সমস্যাটি বুঝতে পারবেন। Coding agent এই পরীক্ষার সবচেয়ে কঠোর রূপ, কারণ এটি একের পর এক tool call-এর মাধ্যমে মডেলকে চালায়। তাই আপনার Ollama server-এর দিকে কোনো agent নির্দেশ করলে এক বিকেলের মধ্যেই অতিরিক্ত aggressive quantization ধরা পড়বে।

চার bit-এর নিচে গেলে ক্ষতি দ্রুত বাড়ে। q3 এবং two bit type তাদের জন্য, যারা ছোট hardware-এ বড় model চালাতে চান। Model একেবারেই না চালানোর বিকল্প থাকলে এগুলো বাস্তবসম্মত বিকল্প। তবে এগুলো ভালো default নয়। q4_K_M এবং q8_0-এর মধ্যে পার্থক্য এতটাই কম যে প্রকাশিত perplexity table আপনার workload-এর জন্য সিদ্ধান্ত দেবে না। তাই ওইভাবে সিদ্ধান্ত নেওয়ার চেষ্টা করবেন না। আপনার নিজের ত্রিশটি prompt দিয়ে দুটিই চালিয়ে output পড়ুন।

q8_0 বা fp16 কখন অতিরিক্ত RAM ব্যবহারের যোগ্য

মেমরি সত্যিই অব্যবহৃত থাকলে এবং কাজটি ছোট ভুলও সহ্য না করলে q8_0 ব্যবহার করুন: structured extraction, tool calling, অথবা compile হতে হবে এমন code। এখানে আপনি উল্লেখযোগ্যভাবে বেশি বুদ্ধিমান model কিনছেন না; বরং নির্ভরযোগ্যতার জন্য অতিরিক্ত RAM ব্যবহার করছেন।

শুধু দুটি কারণে fp16 ব্যবহার করুন। হয় আপনি নিজেই model quantize করছেন এবং source file প্রয়োজন, অথবা baseline মাপছেন, যাতে আপনার four bit build কতটা সক্ষমতা হারিয়েছে তা বোঝা যায়। fp16 থেকে serving করলে q4_K_M-এর তুলনায় তিন গুণ memory লাগে, অথচ পার্থক্যটি অধিকাংশ মানুষ blind comparison-এ ধরতে পারেন না। শুধু CPU-নির্ভর machine হলে token rate-ও এক-তৃতীয়াংশে নেমে যায়।

নির্দিষ্ট memory budget-এ আরও কার্যকর নিয়ম হলো: q4_K_M-এ একটি বড় model সাধারণত q8_0-এ একটি ছোট model-এর চেয়ে ভালো ফল দেয়। 9.3 GB 14B weights এবং 8.9 GB 8B weights-এর RAM (random access memory) ব্যবহার প্রায় সমান, কিন্তু বড় model বেশি তথ্য জানে। এটি নিশ্চিতভাবে মেনে নেওয়ার বদলে নিজের prompt দিয়ে পরীক্ষা করুন।

CPU-তে শুধু inference চালালে memory bandwidth সীমাবদ্ধতা তৈরি হয়

বেশিরভাগ VPS plan-এ GPU থাকে না। তাই model-টি host CPU-এর system memory-তে চলে। এই ক্ষেত্রে generation arithmetic-এর বদলে memory bandwidth দ্বারা সীমাবদ্ধ হয়, কারণ প্রতিটি token তৈরি করতে প্রতিটি weight একবার পড়তে হয়। ফলে একটি সর্বোচ্চ সীমা তৈরি হয়, যা আপনি কতটি core কিনেছেন তার সঙ্গে সম্পর্কিত নয়।

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

Dual-channel DDR4-3200 host-এর জন্য 50 GB/s প্রায় তাত্ত্বিক মান। আপনার অংশ আরও কম, কারণ VPS একই machine-এর অন্য সব tenant-এর সঙ্গে ওই bus ভাগ করে ব্যবহার করে। তাই এই সংখ্যাগুলোকে এমন সর্বোচ্চ সীমা হিসেবে ধরুন, যেখানে বাস্তবে কেউ পৌঁছায় না। এখানে প্রবণতাটিই গুরুত্বপূর্ণ: CPU-তে প্রতি weight-এর bit অর্ধেক করলে token rate প্রায় দ্বিগুণ হয়। GPU ছাড়া machine-এ speed বাড়ানোর সবচেয়ে কার্যকর উপায় হলো quantization। শেষ পর্যন্ত যে rate পাওয়া যায় তা গ্রহণযোগ্য কি না, তা model-এর ওপর নির্ভর করে। VPS-এ Nemotron 3.5 Lightning নির্দিষ্ট একটি build, tag এবং RAM পরিমাণের জন্য এই হিসাবটি দেখায়। অপেক্ষার বাকি অংশ নির্ভর করে model কতটা লিখবে তার ওপর। কারণ প্রতি second-এ 10 token হলে 600 token-এর উত্তর তৈরি করতে পুরো 1 minute লাগে। তাই num_predict দিয়ে reply-এর সীমা নির্ধারণ করা precision আরও এক ধাপ কমানোর চেয়ে প্রায়ই বেশি অপেক্ষার সময় কমায়।

Prompt processing ভিন্নভাবে কাজ করে। দীর্ঘ prompt পড়া bandwidth-bound নয়, বরং compute-bound। তাই সেখানে অতিরিক্ত core কাজে লাগে, কিন্তু generation speed প্রায় বাড়ায় না। কোনো machine 4k prompt দ্রুত গ্রহণ করে তারপর ধীরে generation করলে সেটি স্বাভাবিক আচরণ করছে।

কোনো হিসাব যাচাই না করে গ্রহণ করবেন না। প্রতিটি quantization-এ একই prompt ব্যবহার করে নিজের machine-এ প্রতি second-এ token পরিমাপ করুন। আপনার পরিমাপকেই এই হিসাবের চেয়ে বেশি গুরুত্ব দিন।

নিজে একটি মডেল quantize করা

Ollama একটি fp16 বা fp32 source থেকে quantized model তৈরি করতে পারে। আপনি কোনো কিছু fine-tune করার পরে library tag না থাকলে এই সুবিধাটি গুরুত্বপূর্ণ। Unquantized weights নির্দেশ করতে একটি Modelfile-এ path দিন:

FROM /path/to/my/model/f16

এরপর build করে নিশ্চিত করুন:

ollama create --quantize q4_K_M mymodel
ollama show mymodel

--quantize, q8_0, q4_K_S এবং q4_K_M গ্রহণ করে। এখানে q6_K বা q5_K_M option নেই। তাই এগুলোর জন্য llama.cpp-এর নিজস্ব tool ব্যবহার করে quantize করুন এবং তৈরি GGUF file import করুন। এই import পদ্ধতিতেও একটি সমস্যা আছে। chat template mismatch হলে model অপ্রাসঙ্গিক উত্তর দিতে পারে। Ollama-তে একটি GGUF file import করা অংশে এর ধাপগুলো দেখানো হয়েছে। ollama show-এর quantization line দেখে build আপনার নির্দেশ অনুযায়ী হয়েছে কি না যাচাই করুন।

কাজ ভুল হলে যা দেখবেন

আপনি GPU ব্যবহার আশা করলেও সবকিছু CPU-তে চলছে। PROCESSOR কলামটি দেখুন:

ollama ps

এখানে 100% GPU, 100% CPU বা 48%/52% CPU/GPU-এর মতো একটি split দেখাবে। split-এর অর্থ হলো weights এবং KV cache VRAM-এ (video RAM, অর্থাৎ graphics card-এর memory) ধরেনি। তাই model-এর কিছু অংশ system memory-তে রাখা হয়েছে। এরপর গতি প্রায় CPU-only rate-এ নেমে যায়, কারণ প্রতিটি token-কে ধীর অংশটির জন্য অপেক্ষা করতে হয়। context window কমান, cache quantize করুন অথবা ছোট build ব্যবহার করুন। অতিরিক্ত core যোগ করলে উপকার হবে না।

লোড করার সময় model বন্ধ হয়ে যায়। kernel এবং service log পরীক্ষা করুন:

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

Out of memory: Killed process থাকা কোনো line-এর অর্থ হলো weights, KV cache এবং buffer-এর মোট memory ব্যবহার সিস্টেমের available memory ছাড়িয়ে গেছে। swap configured না থাকা VPS-এ ওই line দেখানোর আগে পুরো machine কয়েক সেকেন্ডের জন্য stall করতে পারে।

আপনি কিছু পরিবর্তন না করেও উত্তরগুলোর মান খারাপ হয়েছে। একই model-এর দুটি build ভিন্ন tag-এর অধীনে ollama ls-এ পাশাপাশি থাকতে পারে। unsuffixed name pull করা কোনো script library বর্তমানে যে build-টির দিকে নির্দেশ করছে, সেটিই ব্যবহার করবে। আপনার client যে exact tag request করছে, তার বিরুদ্ধে ollama show চালান এবং quantization line পড়ুন। configuration file-এর name-এর ওপর নির্ভর করবেন না।

FAQ

কোন Ollama quantization ডাউনলোড করা উচিত?

q4_K_M দিয়ে শুরু করুন। অধিকাংশ model-এর জন্য Ollama library এটিকে default tag হিসেবে release করে, তাই ollama pull qwen3:8b এবং ollama pull qwen3:8b-q4_K_M একই file fetch করে। Memory অব্যবহৃত থাকলে এবং task-এ ছোট ভুলের জন্য ফলাফল খারাপ হলে, যেমন tool calling বা structured JSON output-এর ক্ষেত্রে, শুধু তখন q8_0 ব্যবহার করুন। Memory budget নির্দিষ্ট থাকলে q4_K_M-এ বড় model সাধারণত q8_0-এ ছোট model-এর চেয়ে ভালো ফল দেয়। তাই precision-এর জন্য অতিরিক্ত RAM বরাদ্দের আগে এই pairing পরীক্ষা করুন।

q4_K_M কি সত্যিই প্রতি weight-এ চার bit বোঝায়?

না। Llama 3.1 8B-এ পরিমাপ করলে এটি প্রতি weight-এ 4.89 bit, কারণ প্রতিটি weight block নিজস্ব scale সংরক্ষণ করে এবং সবচেয়ে সংবেদনশীল tensor-গুলোকে wider type-এ উন্নীত করা হয়। একই কারণে Q8_0-এ আটের পরিবর্তে 8.5 bit পরিমাপ করা হয়। হিসাব করার সময় পরিমাপ করা মান ব্যবহার করুন: parameter count-কে প্রতি weight-এর bit দিয়ে গুণ করে আট দিয়ে ভাগ করলে bytes-এ file size পাওয়া যায়।

শুধু CPU-তে চলা VPS-এ 8B model-এর কত RAM প্রয়োজন?

Weights, KV cache এবং headroom যোগ করে হিসাব করুন। q4_K_M-এ Qwen3 8B-এর weights-এর আকার 5.2 GB। Default 4096 token window-এ cache আরও 0.6 GB যোগ করে। ফলে compute buffer এবং operating system-এর জন্য RAM ধরার আগেই ন্যূনতম প্রয়োজন প্রায় 5.8 GB। 32k window-এ শুধু cache-এর আকারই 4.83 GB। ছোট window-এর জন্য 8 GB এবং দীর্ঘ window-এর জন্য 16 GB RAM রাখার পরিকল্পনা করুন।

Server-এ GPU থাকা সত্ত্বেও model 100% CPU-তে চলছে কেন?

ollama ps চালিয়ে PROCESSOR column দেখুন। 100% CPU বা 48%/52% CPU/GPU-এর মতো split-এর অর্থ হলো weights এবং KV cache VRAM-এ fit করেনি। তাই Ollama model-এর আংশিক বা সম্পূর্ণ অংশ system memory-তে রেখেছে। সাধারণ কারণ হলো এমন একটি context window, যা GPU card ধারণ করতে পারে না, কারণ model load হওয়ার সময় সম্পূর্ণ window-এর জন্য cache বরাদ্দ করা হয়। OLLAMA_CONTEXT_LENGTH দিয়ে window ছোট করুন, cache অর্ধেক করতে OLLAMA_KV_CACHE_TYPE=q8_0 সেট করুন, অথবা ছোট quantization download করুন।