Ollama quantization: Q4, Q8 மற்றும் fp16 ஒப்பீடு

Ollama quantization மாற்றங்கள்

Ollama quantization, ஒரு model-ல் உள்ள ஒவ்வொரு weight-ஐயும் அது உருவாக்கப்பட்ட கோப்பை விடக் குறைந்த bits-ல் சேமிக்கிறது. q4_K_M என முடியும் ஒரு tag, ஒவ்வொரு weight-க்கும் சுமார் நான்கு bits-ஐ வைத்திருக்கும், அதே சமயம் fp16 பதினாறு bits-ஐ வைத்திருக்கும். எனவே, download அளவு சுமார் நான்கில் ஒரு பங்காகக் குறைகிறது, மேலும் ஒவ்வொரு token-ஐ உருவாக்க machine வாசிக்கும் bytes-ன் அளவும் நான்கில் ஒரு பங்காகக் குறைகிறது. Weights நீக்கப்படுவதில்லை, மாறாக ஒரு coarse grid-ல் round செய்யப்படுகின்றன. நான்கு bits-ல் பெரும்பாலான models, full precision-ல் இருந்ததைப் போலவே பதிலளிக்கின்றன.

இதுவே இதன் முழுமையான பரிமாற்றம்: மிகக் குறைந்த memory பயன்பாடு மற்றும் நொடிக்கு அதிக tokens, இதற்குப் பதிலாகத் துல்லியத்தில் (accuracy) சிறிய இழப்பு ஏற்படும். ஒரு பெரிய கோப்பை download செய்துவிட்டு அது memory-ல் பொருந்தவில்லை என்று தெரிந்துகொள்வதற்குப் பதிலாக, ஒரு குறிப்பிட்ட machine-ல் ஒரு குறிப்பிட்ட model-க்கு இந்த மாற்றங்களை எவ்வாறு முன்கூட்டியே கணிப்பது என்பது கீழே கொடுக்கப்பட்டுள்ளது.

Ollama இன்னும் இயங்கவில்லை என்றால், VPS-ல் Ollama-வை நிறுவுதல் என்பதிலிருந்து தொடங்கவும். இந்தப் பக்கம் ollama ls ஏற்கனவே இயங்குகிறது என்று கருதுகிறது.

Ollama quantization tag-ஐ, உதாரணமாக q4_K_M-ஐ, எவ்வாறு வாசிப்பது

Local models என்பவை GGUF கோப்புகளாகவே விநியோகிக்கப்படுகின்றன; இது llama.cpp மென்பொருள் தனது எடைகளை (weights) வட்டில் சேமிக்கப் பயன்படுத்தும் வடிவமாகும். Ollama, llama.cpp-ஐ அடிப்படையாகக் கொண்டு கட்டமைக்கப்பட்டுள்ளதால், Ollama tags-ல் llama.cpp-ன் quantization பெயர்கள் மாற்றமின்றி பயன்படுத்தப்படுகின்றன.

அந்த எண் இலக்கு அகலத்தைக் (target width) குறிக்கிறது. q4 என்பது பெரும்பாலான weight tensors ஒவ்வொன்றும் நான்கு பிட்களாகச் சுருக்கப்பட்டுள்ளன என்பதைக் குறிக்கிறது. q8 என்பது எட்டு பிட்களைக் குறிக்கிறது. fp16 என்பது quantization செய்யப்படாதது: இது பதினாறு பிட் மிதப்புப் புள்ளி (floating point) துல்லியத்தில் உள்ள மாதிரியாகும், இதுவே பெரும்பாலான மாதிரிகள் வெளியிடப்படும் துல்லியமாகும்.

K என்பது K-quant-ஐக் குறிக்கிறது. எடைகள் சிறிய தொகுதிகளாகப் பிரிக்கப்படுகின்றன, மேலும் ஒவ்வொரு தொகுதியும் தனது சொந்த அளவுகோலை (scale) சுருக்கப்பட்ட மதிப்புகளுக்கு அருகிலேயே சேமித்துக்கொள்ளும். அனைத்து எடைகளும் 0.01-க்கு அருகில் உள்ள ஒரு தொகுதிக்கு நுணுக்கமான அளவுகோல் பயன்படுத்தப்படும். ஒரு பெரிய outlier-ஐக் கொண்ட தொகுதிக்குத் தடிமனான அளவுகோல் பயன்படுத்தப்படும். இந்த தொகுதி வாரியான அளவுகோல்களே நான்கு பிட் கோப்பைத் தரமானதாக வைத்திருக்கின்றன, மேலும் நான்கு பிட் கோப்பு என்பது ஒரு எடைக்குச் சரியாக நான்கு பிட்கள் என்று இருப்பதில்லை என்பதற்கும் இதுவே காரணம்.

கடைசி எழுத்து கலவையைக் (mixture) குறிக்கிறது. S, M மற்றும் L ஆகியவை எத்தனை tensors இலக்கு அகலத்தை விட அதிகமாக உயர்த்தப்பட வேண்டும் என்பதைத் தீர்மானிக்கின்றன. q4_K_M-ல், rounding செய்யும்போது அதிக பாதிப்பை ஏற்படுத்தும் tensors அதிக அகலத்துடன் சேமிக்கப்படுகின்றன, அதே சமயம் மற்றவை நான்கு பிட்களிலேயே இருக்கும். இதனால்தான் 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 வரி என்பது பல மாதங்களுக்கு முன்பு நீங்கள் பதிவிறக்கம் செய்து, எதைத் தேர்ந்தெடுத்தீர்கள் என்று நினைவில் இல்லாத ஒரு மாதிரிக்கான உண்மையான தகவலாகும்.

Bits per weight என்பதுதான் கோப்பின் அளவைத் தீர்மானிக்கிறது

ஒவ்வொரு கோப்பின் அளவு மதிப்பீடும் ஒரு எண்ணிலிருந்து தொடங்குகிறது: ஒரு கோப்பு முழுவதும் சராசரியாக, ஒரு weight-க்கு எத்தனை bits அந்த format பயன்படுத்துகிறது என்பதே அது. llama.cpp தனது quantize ஆவணத்தில் 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
  }
]

அந்த அட்டவணையில் ஆச்சரியமான விஷயம் இரண்டாவது நெடுவரிசைதான். Q4_K_M என்பது ஒரு weight-க்கு நான்கு bits கிடையாது. இது 4.89 bits-ஐக் கொண்டுள்ளது. ஏனெனில், block scales மற்றும் promoted tensors ஆகியவையும் உண்மையான இடத்தைப் பிடிக்கும். அதே காரணத்திற்காக Q8_0 என்பது எட்டுக்கு பதிலாக 8.5 bits-ஐக் கொண்டுள்ளது. அளவிடப்பட்ட இந்த எண்ணைப் பயன்படுத்தினால், கணக்கீடு உண்மையான கோப்பின் அளவில் சில சதவீத வித்தியாசத்தில் மட்டுமே இருக்கும்:

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 ஏற்றப்பட்ட பிறகு அவை எடுத்துக்கொள்ளும் நினைவகத்தின் (memory) அளவும் ஆகும். Ollama ஏற்றும் போது எதையும் unpack செய்வதில்லை: quantized weights அதே packed வடிவிலேயே நினைவகத்தில் இருக்கும், ஒவ்வொரு block-ம் பயன்படுத்தப்படும்போது மட்டுமே மாற்றப்படும்.

ஒவ்வொரு model அளவிற்கும் Ollama உண்மையில் என்ன வழங்குகிறது

பெரும்பாலான model குடும்பங்களுக்கு, library ஒரு q4_K_M, ஒரு q8_0 மற்றும் ஒரு fp16 tag-ஐ வெளியிடுகிறது. சில புதிய குடும்பங்கள் இந்த முறையைப் பின்பற்றுவதில்லை; அவை library-ல் cloud-only tag-களாக மட்டுமே உள்ளன, எவ்விதமான தரவையும் பதிவிறக்கம் செய்ய முடியாது. GLM 5.2-ஐ VPS-ல் இயக்க முயற்சிக்கும்போது நீங்கள் சந்திக்கும் சிக்கல் இதுதான். இவை ஆகஸ்ட் 2026 நிலவரப்படி Qwen3 அளவுகள், model பக்கத்தில் உள்ள tag பட்டியலிலிருந்து பெறப்பட்டவை. கீழே உள்ள ஒவ்வொரு அளவும் RAM-க்கு வருவதற்கு முன்பான disk பயன்பாடு ஆகும். இவற்றில் இரண்டு அல்லது மூன்றை ஒன்றாகச் சேர்த்தால் ஒரு சிறிய 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 என்பது library தயக்கத்துடன் வழங்கும் ஒரு சமரசமல்ல. இது upstream தேர்ந்தெடுத்த default ஆகும். எனவே, நீங்கள் நீங்களாகவே சோதித்துப் பார்க்காத எந்தவொரு model-க்கும் இதையே தொடக்கப்புள்ளியாகக் கொள்வது அறிவுறுத்தத்தக்கது. Qwen 3-ஐ VPS-ல் இயக்குவதில் tag-களைத் தேர்ந்தெடுக்கும்போது இதே தர்க்கமே பயன்படுத்தப்படுகிறது.

இந்த விகிதங்கள் ஒவ்வொரு வரிசையிலும் மாறாமல் இருக்கும். q4_K_M-லிருந்து q8_0-க்கு மாறும்போது, சரியாக இரண்டு மடங்கு என்பதற்குப் பதிலாக எழுபது சதவீதம் கூடுதல் இடம் தேவைப்படுகிறது. ஏனெனில், embedding மற்றும் output tensors மற்ற பகுதிகளைப் போல ஒரே சீராக அளவிடப்படுவதில்லை. fp16 என்பது தோராயமாக q4_K_M-ஐ விட மூன்று மடங்கு பெரியது. q4_K_M நிலையில் உள்ள ஒரு 32B model 20 GB எடையைக் கொண்டது. இது 16 GB திறன் கொண்ட ஒரு server-ல் எந்தவொரு context window-உடனும் இயங்க முடியாத அளவைத் தாண்டிவிட்டது. எந்தெந்த machine-ல் எந்தெந்த model-கள் பொருந்தும் என்பதைப் பற்றிய விரிவான பார்வைக்கு, எந்த model-களை நீங்கள் self-host செய்யலாம் என்பதைப் பார்க்கவும்.

KV cache ஏன் இரண்டாவது, சூழலைச் சார்ந்த செலவாகிறது

Weights என்பது நிலையான செலவு. KV cache (key and value cache) என்பது மாறுபடும் செலவு. Context window-ல் உள்ள ஒவ்வொரு token-ம் ஒவ்வொரு layer-க்கும் அதன் key மற்றும் value vectors-ஐ வைத்திருக்கும், எனவே நீங்கள் அனுமதிக்கும் window அளவிற்கு ஏற்ப cache நேர்க்கோட்டில் வளரும். Model load ஆகும்போது முழு window-க்கும் நினைவகம் ஒதுக்கப்படும், உரையாடல் வளரும்போது ஒதுக்கப்படாது. இதனால்தான் ஒரு வார்த்தை கொண்ட prompt-க்குக் கூட நீண்ட window நினைவகத்தை அதிகம் பயன்படுத்துகிறது.

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 எண்கள் model-ன் சொந்த configuration-லிருந்து வருகின்றன: 36 layers, 8 key/value heads, மற்றும் 128 head dimension. ollama show உங்களுக்கு architecture மற்றும் parameter எண்ணிக்கையைத் தரும், Hugging Face-ல் உள்ள model-ன் config.json உங்களுக்கு மீதமுள்ள தகவல்களைத் தரும். ஒரு token-க்கான செலவை window அளவால் பெருக்கினால், 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-வின் இயல்புநிலை window ஆன 4096 tokens-ல், cache என்பது weights-க்கு மேல் 0.6 GB-ஐச் சேர்க்கிறது. Window-ஐ 32k-ஆக உயர்த்தினால், cache மட்டும் 4.83 GB-ஐ எட்டும், இது quantized weights-க்கு இணையான நினைவகமாகும், மேலும் முழு model-க்கும் தேவையான குறைந்தபட்ச நினைவகம் 10 GB ஆக உயரும். இது குறைந்தபட்ச அளவு என்று அழைக்கப்படுகிறது, ஏனெனில் compute buffers மற்றும் operating system ஆகியவை இதற்கு மேல் அமைகின்றன. Model load ஆன பிறகு ollama ps-ன் SIZE column-ல் உண்மையான அளவைப் பார்க்கவும்.

நீங்கள் Ollama-வை service-ஆக இயக்கும்போது, window என்பது ஒவ்வொரு request-க்கும் அல்லாமல், server-ல் அமைக்கப்படுகிறது:

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 மூலம் restart செய்யவும், பின்னர் இயங்கும் model எந்த window-டன் load ஆகியுள்ளது என்பதை உறுதிப்படுத்த ollama ps-ன் CONTEXT column-ஐச் சரிபார்க்கவும். OLLAMA_KV_CACHE_TYPE என்பது cache-ஐயே quantize செய்கிறது: f16 என்பது இயல்புநிலை, q8_0 என்பது f16-ஐ விட பாதி நினைவகத்தையே பயன்படுத்தும், மற்றும் q4_0 என்பது கால் பங்கு நினைவகத்தைப் பயன்படுத்தும். இது ஒரு global option, எனவே அந்த server-ல் உள்ள அனைத்து model-களும் ஒரே மாதிரியான மாற்றத்தைப் பெறும். நீண்ட window கொண்ட சிறிய கணினியில், cache-ஐ பாதியாகக் குறைப்பது மற்ற எந்த மாற்றத்தை விடவும் அதிக நினைவகத்தை விடுவிக்கும். num_ctx அமைத்தல் மற்றும் அதன் செலவு என்பது window-ஐப் பற்றி விரிவாக விளக்குகிறது. Cache என்பது server-க்கு ஒருமுறை அல்லாமல், ஒவ்வொரு concurrent request slot-க்கும் ஒருமுறை அளவிடப்படுகிறது, எனவே Ollama ஒரே நேரத்தில் இரண்டு prompt-களுக்குப் பதிலளிக்க அனுமதிப்பது நீங்கள் கணக்கிட்ட தொகையை இரட்டிப்பாக்கும், இதுவே parallel slot எண்ணிக்கை மற்றும் queue limit-ஐத் தேர்ந்தெடுப்பதற்கான கணித அடிப்படையாகும்.

8, 16 அல்லது 32 GB VPS-ல் எவை பொருந்தும்

Budget weights, KV cache, மற்றும் operating system-க்குத் தேவையான கூடுதல் இடம் ஆகியவற்றை கணக்கில் கொள்ள வேண்டும். சிறிய VPS-ல் 2 GB கூடுதல் இடம் (headroom) இருப்பது போதுமானது.

8 GB. q4_K_M-ல் உள்ள 4B model 2.6 GB அளவு கொண்டது, இது நீண்ட window-க்கு போதுமான இடவசதியை அளிக்கிறது. q4_K_M-ல் உள்ள 8B model, default 4k window-உடன் மிகக் குறைந்த இடைவெளியில் பொருந்தும். இங்கு 32k window-உடன் 8B model-ஐப் பயன்படுத்தத் திட்டமிட வேண்டாம், ஏனெனில் 10 GB என்ற குறைந்தபட்ச அளவு ஏற்கனவே வரம்பைத் தாண்டிவிட்டது.

16 GB. 16k அல்லது 32k window-உடன் q4_K_M-ல் உள்ள 8B model தாராளமாகப் பொருந்தும். q4_K_M-ல் உள்ள 14B model 9.3 GB எடையைக் கொண்டது, இது ஒரு மிதமான window-உடன் பொருந்தும். q8_0-ல் உள்ள 8B model 8.9 GB அளவு கொண்டது, எனவே இதுவும் பொருந்தும். உங்கள் சொந்த prompts-களைக் கொண்டு இவை இரண்டையும் ஒப்பிட்டுப் பார்ப்பது, இந்தத் தலைப்பில் நீங்கள் செலவிடும் மிக பயனுள்ள நேரமாக இருக்கும்.

32 GB. q8_0-ல் உள்ள 14B model (16 GB) மற்றும் q4_K_M-ல் உள்ள 32B model (20 GB) ஆகிய இரண்டுமே load ஆகும். பெரிய window-உடன் கூடிய 32B build, நினைவகத்தின் உச்ச வரம்பை நெருங்கும். எனவே, எதையும் ஊகிப்பதற்குப் பதிலாக ollama ps-ஐக் கவனிக்கவும்.

எந்த குவாண்டிசேஷன் (quantization) முதலில் சிதைகிறது

குவாண்டிசேஷன் பிழை ஒரு மாடலின் அனைத்து செயல்பாடுகளிலும் சமமாகப் பரவுவதில்லை. சரளமான மொழித்திறன் (fluency) நீண்ட நேரம் நீடிக்கும், இதனால்தான் சேதத்தை கண்டறிவது கடினம்: மோசமாக குவாண்டிஸ் செய்யப்பட்ட மாடல் கூட தெளிவான வாக்கியங்களை எழுதும். துல்லியம் (precision) தான் முதலில் பாதிக்கப்படும். ஒரு பதிப்பு எண் (version number), API கையொப்பம் அல்லது தேதியைச் சரியாக நினைவுகூருதல் போன்றவை பாதிக்கப்படும். நீண்ட தர்க்க ரீதியான சங்கிலித் தொடர்களில், இரண்டாவது கட்டத்தில் ஏற்படும் சிறிய பிழை எட்டாவது கட்டத்தில் தவறான பதிலாக மாறும். கடுமையான வெளியீட்டு வடிவங்களில் (strict output formats), ஒரு தவறான அடைப்புக்குறி (bracket) கூட ஒரு tool call-ஐ தோல்வியடையச் செய்யும்.

கடைசியாகக் குறிப்பிட்டதுதான் நடைமுறைச் சோதனை. உங்கள் குறியீடு (code) பகுப்பாய்வு செய்யும் JSON-ஐ ஒரு மாடல் வழங்க வேண்டியிருக்கும் போது, குவாண்டிசேஷன் பாதிப்பு தெளிவற்ற உரைநடையாக இல்லாமல், ஒரு parse error-ஆக வெளிப்படும்; எனவே அதை அன்றே நீங்கள் கவனித்துவிடலாம். ஒரு coding agent இந்தச் சோதனையின் மிகக் கடுமையான வடிவம், ஏனெனில் அது மாடலைத் தொடர்ந்து tool call செய்யத் தூண்டுகிறது. எனவே உங்கள் Ollama server-ல் ஒரு agent-ஐப் பயன்படுத்துவது மிகையான குவாண்டிசேஷனை ஒரு மதியத்திற்குள் வெளிச்சத்திற்குக் கொண்டுவரும்.

நான்கு பிட்களுக்குக் கீழே இழப்பு கடுமையாகிறது. q3 மற்றும் இரண்டு பிட் வகைகள், பெரிய மாடலைச் சிறிய வன்பொருளில் (hardware) பொருத்த முயற்சிப்பவர்களுக்காக உள்ளன. மாடலை இயக்கவே முடியாத சூழலில் இவை ஒரு சிறந்த மாற்றாகும். ஆனால், இவை இயல்பான பயன்பாட்டிற்கு ஏற்றவை அல்ல. q4_K_M மற்றும் q8_0 ஆகியவற்றுக்கு இடையேயான இடைவெளி மிகக் குறைவு என்பதால், வெளியிடப்பட்ட perplexity அட்டவணையை வைத்து உங்கள் பணிச்சுமைக்கு எது சிறந்தது என்பதை முடிவு செய்ய முடியாது. எனவே, அந்த வழியில் முடிவெடுக்க வேண்டாம். உங்கள் சொந்த முப்பது prompts-களை இரண்டிலும் இயக்கி, அதன் வெளியீட்டை நீங்களே படித்துப் பாருங்கள்.

q8_0 அல்லது fp16 எப்போது RAM-க்கு மதிப்புடையது

நினைவகம் (memory) தாராளமாக இருக்கும்போதும், சிறிய பிழைகள் கூட பாதிப்பை ஏற்படுத்தும் பணிகளுக்கும் q8_0-ஐப் பதிவிறக்கவும்: கட்டமைக்கப்பட்ட தரவு பிரித்தெடுத்தல் (structured extraction), tool calling, மற்றும் compile ஆக வேண்டிய code போன்றவை இதற்கு உதாரணம். நீங்கள் இங்கே காப்பீடு செய்கிறீர்கள், மாடல் புத்திசாலித்தனமாக மாறாது.

fp16-ஐ இரண்டு காரணங்களுக்காக மட்டுமே பதிவிறக்கவும். நீங்கள் மாடலை நீங்களே quantization செய்கிறீர்கள் மற்றும் source file தேவைப்படுகிறது என்றால், அல்லது உங்கள் நான்கு பிட் (four bit) build எவ்வளவு தரத்தை இழக்கிறது என்பதை அறிய baseline-ஐ அளவிடுகிறீர்கள் என்றால் மட்டுமே இதைப் பயன்படுத்தவும். fp16-ல் இருந்து சேவை வழங்குவது q4_K_M-ஐ விட மூன்று மடங்கு நினைவகத்தை எடுத்துக்கொள்ளும், ஆனால் பெரும்பாலானவர்களால் இதிலுள்ள வித்தியாசத்தைக் கண்டறிய முடியாது. CPU மட்டுமே உள்ள கணினியில், இது உங்கள் token வேகத்தை மூன்றில் ஒரு பங்காகக் குறைக்கும்.

நிலையான நினைவக வரம்பில், ஒரு பொதுவான விதி இதுதான்: q4_K_M-ல் உள்ள பெரிய மாடல், q8_0-ல் உள்ள சிறிய மாடலை விடச் சிறப்பாகச் செயல்படும். 9.3 GB அளவுள்ள 14B weights மற்றும் 8.9 GB அளவுள்ள 8B weights ஆகிய இரண்டும் ஏறக்குறைய ஒரே அளவு RAM-ஐயே எடுத்துக்கொள்ளும், ஆனால் பெரிய மாடலுக்கு அதிக அறிவு இருக்கும். இதை மற்றவர்கள் சொல்வதை நம்புவதை விட, உங்கள் சொந்த prompts-களைக் கொண்டு நீங்களே சோதித்துப் பாருங்கள்.

CPU மட்டும் பயன்படுத்தும் inference, memory bandwidth-ஆல் கட்டுப்படுத்தப்படுகிறது

பெரும்பாலான VPS திட்டங்களில் GPU கிடையாது, எனவே model-ஆனது host CPU-ன் system memory-ல் இயங்குகிறது. ஒரு token-ஐ உருவாக்க ஒவ்வொரு weight-ஐயும் ஒருமுறை படிக்க வேண்டியிருப்பதால், கணக்கீட்டை விட memory bandwidth-ஆலேயே generation வேகம் தீர்மானிக்கப்படுகிறது. நீங்கள் எத்தனை CPU 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

Dual channel DDR4-3200 host-ன் கோட்பாட்டு ரீதியான வேகம் சுமார் 50 GB/s ஆகும். ஒரு VPS-ல் அந்த bus-ஐ மற்ற பயனர்களும் பகிர்வதால், உங்கள் பங்கு மிகக் குறைவு. எனவே, இந்த எண்களை எட்ட முடியாத ஒரு உச்ச வரம்பாகக் கருதவும். இதில் கவனிக்க வேண்டியது என்னவென்றால், CPU-ல் ஒரு weight-க்கான bits-ஐ பாதியாகக் குறைத்தால், token வேகம் தோராயமாக இரண்டு மடங்காகும். GPU இல்லாத கணினியில் வேகத்தை அதிகரிக்க Quantization-தான் மிகச்சிறந்த வழி. உங்களுக்குக் கிடைக்கும் வேகம் போதுமானதா என்பது model-ஐப் பொறுத்தது. VPS-ல் Nemotron 3.5 Lightning என்ற கட்டுரை, ஒரு குறிப்பிட்ட build, tag மற்றும் RAM அளவிற்கு இந்த வேகக் கணக்கீட்டை விளக்குகிறது. காத்திருப்பு நேரத்தின் மற்றொரு பாதி, model எவ்வளவு எழுத வேண்டும் என்பதில் உள்ளது. வினாடிக்கு பத்து tokens வீதம், அறுநூறு tokens கொண்ட பதிலுக்கு ஒரு நிமிடம் ஆகும். எனவே, num_predict மூலம் பதிலைக் கட்டுப்படுத்துவது, precision-ஐக் குறைப்பதை விட அதிக நேரத்தைச் சேமிக்க உதவும்.

Prompt processing இதற்கு மாறாகச் செயல்படும். நீண்ட prompt-ஐப் படிப்பது bandwidth-ஐ விட compute-ஆல் கட்டுப்படுத்தப்படுகிறது. எனவே, generation வேகத்தை அதிகரிக்காத கூடுதல் cores, prompt-ஐப் படிக்கும் வேகத்தை அதிகரிக்கும். ஒரு கணினி 4k prompt-ஐ வேகமாக உள்வாங்கிவிட்டு, மெதுவாக generation செய்தால், அது இயல்பான செயல்பாடே.

எந்தவொரு கணக்கீட்டையும் அப்படியே நம்ப வேண்டாம். ஒவ்வொரு quantization-க்கும் ஒரே prompt-ஐப் பயன்படுத்தி உங்கள் கணினியில் tokens per second-ஐ அளவிடுங்கள், அந்த முடிவுகளே இறுதியானவை.

நீங்களாகவே ஒரு model-ஐ quantize செய்தல்

நீங்கள் ஒரு model-ஐ fine-tune செய்த பிறகு அதற்கு library tag இல்லாத சூழலில், fp16 அல்லது fp32 source-லிருந்து quantized model-ஐ உருவாக்க Ollama உதவுகிறது. Quantize செய்யப்படாத weights-ஐக் குறிக்க Modelfile-ஐப் பயன்படுத்தவும்:

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 விருப்பங்கள் இல்லை; எனவே அவற்றுக்கு llama.cpp-ன் சொந்த கருவியைப் பயன்படுத்தி quantize செய்து, முழுமையடைந்த GGUF கோப்பை import செய்ய வேண்டும். அந்த import முறையில் ஒரு சிக்கல் உள்ளது; chat template பொருந்தாதபோது model தவறான பதில்களைத் தரும். இது குறித்து Ollama-வில் GGUF கோப்பை import செய்தல் பகுதியில் விளக்கப்பட்டுள்ளது. ollama show-லிருந்து வரும் quantization வரியைக் கொண்டு, நீங்கள் கேட்டபடி build சரியாக நடந்துள்ளதா என்பதைச் சரிபார்க்கலாம்.

பிழைகள் ஏற்படும்போது நீங்கள் காண்பவை

நீங்கள் GPU-வை எதிர்பார்த்த நிலையில், அனைத்தும் CPU-வில் இயங்குகின்றன. PROCESSOR நெடுவரிசையை கவனிக்கவும்:

ollama ps

இது 100% GPU, 100% CPU, அல்லது 48%/52% CPU/GPU போன்ற பிரிவினையைக் காட்டும். ஒரு பிரிவினை என்பது, weights மற்றும் KV cache ஆகியவை VRAM-ல் (graphics card-ல் உள்ள நினைவகம்) பொருந்தவில்லை என்று பொருள்; எனவே மாதிரியின் ஒரு பகுதி system memory-க்கு மாற்றப்பட்டுள்ளது. ஒவ்வொரு token-ம் மெதுவான பாதியைக் காத்திருப்பதால், வேகம் CPU-வின் வேகத்திற்கு நெருக்கமாகக் குறையும். Context window-ஐக் குறைக்கவும், cache-ஐ quantize செய்யவும் அல்லது சிறிய build-ஐப் பயன்படுத்தவும். கூடுதல் cores-ஐச் சேர்ப்பது உதவாது.

மாதிரி ஏற்றப்படும்போது நிறுத்தப்படுகிறது (killed). Kernel மற்றும் service log-ஐச் சரிபார்க்கவும்:

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

Out of memory: Killed process என்ற வரியைக் கொண்ட ஒரு வரி, weights, KV cache மற்றும் buffers ஆகியவற்றின் மொத்த அளவு கணினியின் நினைவகத்தை விட அதிகமாகிவிட்டது என்று பொருள். Swap வசதி இல்லாத VPS-ல், அந்த வரி தோன்றுவதற்கு முன்பு முழு இயந்திரமும் பல நொடிகள் முடங்கக்கூடும்.

எந்த மாற்றமும் செய்யாத நிலையில் பதில்கள் மோசமடைந்துள்ளன. ஒரே மாதிரியின் இரண்டு builds ollama ls-ல் வெவ்வேறு tags-களுடன் அருகருகே இருக்கலாம்; suffix இல்லாத பெயரைப் பதிவிறக்கும் script, அந்த library தற்போது எதைச் சுட்டிக்காட்டுகிறதோ அதையே பின்பற்றும். உங்கள் configuration கோப்பில் உள்ள பெயரை நம்புவதற்குப் பதிலாக, உங்கள் client கோரும் சரியான tag-க்கு எதிராக ollama show-ஐ இயக்கி, quantization வரியைப் படிக்கவும்.

FAQ

நான் எந்த Ollama quantization-ஐ pull செய்ய வேண்டும்?

q4_K_M-ல் தொடங்கவும். பெரும்பாலான மாடல்களுக்கு Ollama library-யில் default tag-ஆக இதுவே வழங்கப்படுகிறது, எனவே ollama pull qwen3:8b மற்றும் ollama pull qwen3:8b-q4_K_M ஆகிய இரண்டும் ஒரே கோப்பையே பதிவிறக்கும். நினைவகம் (memory) அதிகமாக இருக்கும்போதும், tool calling அல்லது structured JSON output போன்ற துல்லியம் தேவைப்படும் பணிகளுக்கு மட்டும் q8_0-க்கு மாறவும். நினைவக வரம்பு நிர்ணயிக்கப்பட்டிருக்கும்போது, சிறிய மாடலின் q8_0-ஐ விட பெரிய மாடலின் q4_K_M சிறப்பாகச் செயல்படும். எனவே, அதிக துல்லியத்திற்காக RAM-ஐ செலவிடும் முன் இந்த இணைப்பைச் சோதிக்கவும்.

q4_K_M என்பது உண்மையில் ஒரு weight-க்கு நான்கு பிட்கள் என்று பொருள்படுமா?

இல்லை. Llama 3.1 8B மாடலில் இது 4.89 பிட்கள் என்று கணக்கிடப்படுகிறது. ஏனெனில், ஒவ்வொரு weight தொகுதியும் அதன் சொந்த scale-ஐக் கொண்டுள்ளது மற்றும் மிக முக்கியமான tensors அதிக பிட் கொண்ட வகைக்கு மாற்றப்படுகின்றன. இதே காரணத்திற்காக, Q8_0 என்பது எட்டு பிட்களுக்குப் பதிலாக 8.5 பிட்களைக் கொண்டுள்ளது. மதிப்பீடு செய்யும்போது இந்த அளவைப் பயன்படுத்தவும்: parameter எண்ணிக்கை பெருக்கல் ஒரு weight-க்கான பிட்கள், வகுத்தல் எட்டு, இது கோப்பின் அளவை bytes-ல் தரும்.

CPU மட்டும் கொண்ட VPS-ல் 8B மாடலுக்கு எவ்வளவு RAM தேவைப்படும்?

Weights, KV cache மற்றும் கூடுதல் நினைவகத்தைக் கூட்டவும். Qwen3 8B மாடலின் q4_K_M அளவு 5.2 GB weights ஆகும். Default 4096 token window-வில், cache கூடுதலாக 0.6 GB-ஐச் சேர்க்கிறது. இதனால், compute buffers மற்றும் operating system-க்கு முன்பே இதன் அடிப்படைத் தேவை 5.8 GB ஆகிறது. 32k window-வில் cache மட்டுமே 4.83 GB ஆகும். சிறிய window-க்கு 8 GB-யும், பெரிய window-க்கு 16 GB-யும் திட்டமிடவும்.

GPU இருந்தும் எனது மாடல் ஏன் 100% CPU-வில் இயங்குகிறது?

ollama ps-ஐ இயக்கி, PROCESSOR நிரலைப் பார்க்கவும். 100% CPU அல்லது 48%/52% CPU/GPU போன்ற பிரிப்பு இருந்தால், weights மற்றும் KV cache ஆகியவை VRAM-ல் பொருந்தவில்லை என்று பொருள். இதனால் Ollama மாடலின் ஒரு பகுதியை அல்லது முழுவதையும் system memory-ல் வைத்துள்ளது. பொதுவாக, card-ன் கொள்ளளவை விட context window பெரியதாக இருக்கும்போது இது நிகழும், ஏனெனில் மாடல் load ஆகும்போது முழு window-க்கும் cache ஒதுக்கப்படும். OLLAMA_CONTEXT_LENGTH மூலம் window-ஐக் குறைக்கவும், OLLAMA_KV_CACHE_TYPE=q8_0 மூலம் cache-ஐ பாதியாகக் குறைக்கவும் அல்லது சிறிய quantization-ஐப் பயன்படுத்தவும்.