Ollama quantization: q4_K_M, q8_0 নাকি fp16?

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

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

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

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

Ollama quantization tag যেমন q4_K_M পড়বেন

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

সংখ্যাটি target width নির্দেশ করে। q4 মানে অধিকাংশ weight tensor প্রতি weight-এ four bit করে pack করা। q8 মানে eight 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 থাকে, সেটিতে অপেক্ষাকৃত coarse scale ব্যবহার করা হয়। এই per-block scale-গুলোর কারণেই four-bit file ব্যবহারযোগ্য থাকে। একই কারণে four-bit file-এ প্রতি weight-এর জন্য ঠিক four bit ব্যবহার হয় না।

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

আপনি যে নাম লিখেছেন তা দেখে অনুমান না করে, 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 প্রয়োজন। একই কারণে 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

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

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

বেশিরভাগ family-এর জন্য library একটি q4_K_M, একটি q8_0 এবং একটি fp16 tag প্রকাশ করে। এগুলো August 2026 অনুযায়ী Qwen3-এর size, যা model page-এর tag list থেকে নেওয়া হয়েছে।

[
  {
    "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 download করে, কারণ suffix-বিহীন tag-টিই q4_K_M build। Q4_K_M library অনিচ্ছায় দেওয়া কোনো compromise নয়। এটিই 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-এর weight-এর আকার 20 GB, যা কোনো context window রাখার আগেই 16 GB box-এর ধারণক্ষমতার বাইরে চলে যায়। কোন 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 বড় হওয়ার সঙ্গে সঙ্গে নয়। এই কারণে one-word 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-এর সংখ্যাগুলো তার নিজস্ব configuration থেকে এসেছে: 36টি layer, 8টি key/value head এবং 128 head dimension। ollama show-এ architecture ও parameter count পাওয়া যায়। Model-এর Hugging Face config.json-এ বাকি তথ্য রয়েছে। প্রতি token-এর খরচকে window size দিয়ে গুণ করলে 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-এর default 4096 token 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 ব্যবহার করলে লাগে প্রায় এক-চতুর্থাংশ। এটি একটি global option। তাই ওই server-এর প্রতিটি model একইভাবে প্রভাবিত হবে। ছোট server-এ বড় window ব্যবহার করলে cache অর্ধেক করা অন্য যেকোনো একক পরিবর্তনের চেয়ে বেশি memory মুক্ত করে। num_ctx সেট করা এবং এর খরচ অংশে window সম্পর্কে বিস্তারিত ব্যাখ্যা আছে।

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

Budget weight, KV cache, operating system এবং অন্য যেকোনো চলমান প্রক্রিয়ার জন্য অতিরিক্ত memory—সব হিসাব করতে হবে। ছোট VPS-এ 2 GB অতিরিক্ত memory রাখলে সাধারণত স্বচ্ছন্দে কাজ করা যায়।

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

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

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

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

Quantization error মডেল যা কিছু করে, তার সব অংশে সমানভাবে ছড়ায় না। Fluency সবচেয়ে দীর্ঘ সময় অক্ষুণ্ণ থাকে। এ কারণেই ক্ষতি বোঝা কঠিন: খারাপভাবে quantized মডেলও পরিষ্কার বাক্য লিখতে পারে। প্রথমে 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-এর মাধ্যমে মডেলকে পরিচালনা করে। তাই কোনো agent-কে আপনার Ollama server-এর দিকে নির্দেশ করলে এক বিকেলের মধ্যেই অতিরিক্ত aggressive quantization ধরা পড়বে।

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

q8_0 বা fp16 কখন RAM ব্যবহারের উপযোগী

মেমরি সত্যিই অব্যবহৃত থাকলে এবং কাজে সামান্য ভুলও বড় সমস্যা তৈরি করলে q8_0 ব্যবহার করুন: structured extraction, tool calling, অথবা compile হওয়া আবশ্যক এমন code। এখানে আপনি বেশি বুদ্ধিমান model কিনছেন না; ঝুঁকির বিরুদ্ধে সুরক্ষা কিনছেন।

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

নির্দিষ্ট memory budget-এ আরও কার্যকর নিয়ম হলো: q4_K_M-এ একটি বড় model সাধারণত q8_0-এ একটি ছোট model-কে ছাড়িয়ে যায়। 14B weights-এর 9.3 GB এবং 8B weights-এর 8.9 GB প্রায় একই 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 প্রায় theoretical figure। আপনার ভাগ এর চেয়ে কম, কারণ একই machine-এর অন্য সব tenant-এর সঙ্গে VPS ওই bus ভাগ করে ব্যবহার করে। তাই এই সংখ্যাগুলোকে এমন একটি ceiling হিসেবে দেখুন, যেখানে বাস্তবে কেউ পৌঁছায় না। গুরুত্বপূর্ণ বিষয় হলো প্রবণতাটি: CPU-তে প্রতি weight-এর bit অর্ধেক করলে token rate প্রায় দ্বিগুণ হয়। GPU ছাড়া কোনো box-এ quantization-ই সবচেয়ে বড় speed lever।

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

কোনো arithmetic যাচাই না করে বিশ্বাস করবেন না। একই prompt ব্যবহার করে প্রতিটি quantization-এ নিজের box-এ প্রতি সেকেন্ডে token পরিমাপ করুন, এবং আপনার measurement-কে এই সংখ্যার চেয়ে অগ্রাধিকার দিন।

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

Ollama একটি fp16 বা fp32 source থেকে quantized model তৈরি করতে পারে। আপনি কোনো মডেল fine-tune করার পর তার জন্য library tag না থাকলে এটি গুরুত্বপূর্ণ। একটি Modelfile-এ unquantized weights-এর অবস্থান নির্ধারণ করুন:

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 করুন। ollama show-এর quantization line দেখে build আপনার নির্ধারিত নির্দেশনা অনুযায়ী হয়েছে কি না যাচাই করা যায়।

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

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

ollama ps

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

Loading-এর সময় 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 usage মেশিনের available memory অতিক্রম করেছে। Swap configured না থাকা VPS-এ ওই line দেখা যাওয়ার আগে পুরো মেশিন কয়েক সেকেন্ড stall করতে পারে।

আপনি কিছু পরিবর্তন না করলেও উত্তর খারাপ হয়েছে। একই model-এর দুটি build ভিন্ন tag-সহ ollama ls-এ পাশাপাশি থাকতে পারে। Unsuffixed name pull করা একটি script library বর্তমানে যেদিকে নির্দেশ করছে, সেটিই ব্যবহার করবে। 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 করে। শুধু তখনই q8_0 ব্যবহার করুন, যখন অতিরিক্ত memory আছে এবং task-এ ছোট ভুলের জন্য সমস্যা হয়, যেমন tool calling বা structured JSON output। 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 সংরক্ষণ করে এবং সবচেয়ে sensitive tensor-গুলোকে আরও প্রশস্ত type-এ উন্নীত করা হয়। একই কারণে Q8_0-এর পরিমাপ আট bit নয়, 8.5 bit। হিসাব করার সময় measured figure ব্যবহার করুন: parameter count-কে bits per weight দিয়ে গুণ করে আট দিয়ে ভাগ করলে 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-এর জন্য অতিরিক্ত memory ধরার আগে ন্যূনতম প্রয়োজন প্রায় 5.8 GB। 32k window-এ শুধু cache-এর আকারই 4.83 GB। ছোট window-এর জন্য 8 GB এবং বড় window-এর জন্য 16 GB ধরে পরিকল্পনা করুন।

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

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