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 நீக்கப்படாமல், ஒரு குறிப்பிட்ட grid-க்கு மாற்றப்படுகின்றன (rounded). நான்கு bits-ல் பெரும்பாலான models, முழு precision-ல் இருந்ததைப் போலவே பதிலளிக்கின்றன.

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

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

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

பெரும்பாலான குடும்பங்களுக்கு இந்த library ஒரு q4_K_M, ஒரு q8_0 மற்றும் ஒரு fp16 tag-ஐ வெளியிடுகிறது. இவை ஆகஸ்ட் 2026 நிலவரப்படி Qwen3 அளவுகள் ஆகும், இவை model பக்கத்தில் உள்ள tag பட்டியலில் இருந்து பெறப்பட்டவை.

[
  {
    "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-க்கும் இதைப் பொருத்துவதே அறிவுப்பூர்வமான முதல் நடவடிக்கையாகும். VPS-ல் Qwen 3-ஐ இயக்குதல் என்பதில் tag தேர்வுகள் இதே காரணத்தாலேயே மேற்கொள்ளப்படுகின்றன.

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

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

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

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

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

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

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

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

எந்த வகையான quantization முதலில் சிதைகிறது

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

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

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

q8_0 அல்லது fp16 எப்போது RAM-க்கு உகந்தது

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

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

நிலையான நினைவக வரம்பில் (fixed memory budget) ஒரு வலுவான விதி உள்ளது: q4_K_M-ல் உள்ள பெரிய மாடல், q8_0-ல் உள்ள சிறிய மாடலை விடச் சிறப்பாகச் செயல்படும். 9.3 GB அளவுள்ள 14B weights மற்றும் 8.9 GB அளவுள்ள 8B weights ஆகிய இரண்டுக்கும் ஏறக்குறைய ஒரே அளவு RAM (random access memory) தேவைப்படும், ஆனால் பெரிய மாடலுக்கு அதிக அறிவு இருக்கும். இதை மற்றவர் சொல்வதை நம்புவதை விட, உங்கள் சொந்த 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-ஐ அந்த machine-ல் உள்ள மற்ற அனைத்து பயனர்களும் பகிர்ந்துகொள்வதால், உங்கள் பங்கு மிகக் குறைவு. எனவே, இந்த எண்களை யாராலும் எட்ட முடியாத ஒரு உச்ச வரம்பாகக் கருதவும். இதில் கவனிக்க வேண்டிய முக்கியமான அம்சம் என்னவென்றால், CPU-ல் ஒரு weight-க்கு ஒதுக்கப்பட்ட bits-ஐ பாதியாகக் குறைத்தால், token வேகம் தோராயமாக இரண்டு மடங்காகும். GPU இல்லாத ஒரு machine-ல் வேகத்தை அதிகரிக்க Quantization-தான் மிகச்சிறந்த வழியாகும்.

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

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

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

fp16 அல்லது fp32 source-லிருந்து quantized model-ஐ Ollama-வால் உருவாக்க முடியும். நீங்கள் ஒரு model-ஐ fine-tune செய்திருக்கும்போது, அதற்குத் தேவையான library tag எதுவும் இல்லாத நிலையில் இது பயனுள்ளதாக இருக்கும். 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 செய்யவும். ollama show-லிருந்து வரும் quantization வரியானது, நீங்கள் கேட்டபடி build சரியாக நடந்துள்ளதா என்பதைச் சரிபார்க்க உதவும்.

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

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

ollama ps

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

மாதிரி ஏற்றப்படும்போது (loading) நிறுத்தப்படுகிறது. 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-ல், அந்த வரி தோன்றுவதற்கு முன்பு முழு இயந்திரமும் பல நொடிகள் முடங்கக்கூடும்.

எந்த மாற்றமும் செய்யாத நிலையில் பதில்கள் மோசமடைந்துள்ளன. ஒரே மாதிரியின் இரண்டு build-கள் 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 சிறப்பாகச் செயல்படும். எனவே, துல்லியத்திற்காக (precision) 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 மற்றும் கூடுதல் இடவசதி (headroom) ஆகியவற்றைச் சேர்க்கவும். Qwen3 8B மாடலின் q4_K_M பதிப்பு 5.2 GB weights-ஐக் கொண்டுள்ளது. Default 4096 token window-வில் cache கூடுதலாக 0.6 GB-ஐச் சேர்க்கிறது. கணக்கீட்டு 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-ஐப் பயன்படுத்தவும்.