Ollama quantization: q4_K_M, q8_0, fp16లో ఏది?

Ollama quantization వల్ల కలిగే మార్పులు

Ollama quantizationలో modelలోని ప్రతి weightను, అది training జరిగిన fileలో ఉన్న bitల కంటే తక్కువ bitలలో నిల్వ చేస్తారు. q4_K_Mతో ముగిసే tag ప్రతి weightకు సుమారు నాలుగు bitలను ఉంచుతుంది. fp16 పదహారు bitలను ఉంచుతుంది. అందువల్ల download పరిమాణం సుమారు నాలుగో వంతు అవుతుంది. ప్రతి tokenను రూపొందించడానికి machine చదవాల్సిన bytes కూడా సుమారు నాలుగో వంతు అవుతాయి. Weightsను పూర్తిగా తొలగించరు. వాటిని coarse gridపై సమీప విలువలకు round చేస్తారు. నాలుగు bitల వద్ద కూడా చాలా models full precisionలో ఇచ్చిన సమాధానాలకు దగ్గరగా సమాధానాలు ఇస్తాయి.

ఇదే మొత్తం trade-off: memory footprint చాలా తగ్గుతుంది. సెకనుకు ఉత్పత్తి చేసే tokens సంఖ్య పెరుగుతుంది. దీనికి బదులుగా accuracy కొద్దిగా తగ్గుతుంది. మీరు fileను download చేయడానికి ఇరవై నిమిషాలు వెచ్చించే ముందు, నిర్దిష్ట modelను నిర్దిష్ట machineపై ఉపయోగించినప్పుడు ఈ రెండు ప్రభావాలను ఎలా అంచనా వేయాలో తరువాతి భాగం వివరిస్తుంది. Download చేసిన file machine memoryలో సరిపోకపోవచ్చు.

Ollama ఇంకా నడవకపోతే, VPSలో Ollamaను ఇన్‌స్టాల్ చేయడంతో ప్రారంభించండి. ఈ పేజీలో ollama ls ఇప్పటికే పనిచేస్తుందని భావిస్తున్నాం.

q4_K_M వంటి Ollama quantization tag ను ఎలా చదవాలి

Local models డిస్క్‌పై weights నిల్వ చేయడానికి llama.cpp ఉపయోగించే GGUF files రూపంలో విడుదలవుతాయి. Ollama, llama.cpp పై నిర్మించబడింది. అందువల్ల Ollama tags లో llama.cpp quantization పేర్లే మార్పు లేకుండా ఉంటాయి.

సంఖ్య లక్ష్య width ను సూచిస్తుంది. q4 అంటే ఎక్కువ weight tensors ఒక్కొక్కటి four bits చొప్పున pack చేయబడతాయని అర్థం. q8 అంటే eight bits. fp16 అసలు quantized కాదు. ఇది sixteen bit floating point లోని model. ఎక్కువ models ప్రచురించబడే precision ఇదే.

K ఒక K-quant ను సూచిస్తుంది. Weights ను చిన్న blocks గా group చేస్తారు. ప్రతి block లో packed values పక్కన దాని స్వంత scale కూడా నిల్వ ఉంటుంది. అన్ని weights 0.01 కు సమీపంగా ఉన్న block కు fine scale లభిస్తుంది. ఒక పెద్ద outlier ఉన్న block కు coarse scale లభిస్తుంది. ఈ per-block scales వల్ల four-bit file ఉపయోగించగలిగే స్థితిలో ఉంటుంది. అలాగే four-bit file లో ప్రతి weight కు సరిగ్గా four bits ఉండకపోవడానికి ఇవే కారణం.

చివరి అక్షరం mixture ను సూచిస్తుంది. S, M మరియు L target width కంటే ఎక్కువ width కు promote చేయాల్సిన tensors సంఖ్యను నిర్ణయిస్తాయి. q4_K_M లో rounding వల్ల ఎక్కువ నష్టం కలిగించే tensors ను ఎక్కువ width లో store చేస్తారు. మిగిలిన ఎక్కువ tensors four bits లోనే ఉంటాయి. అందువల్ల దాదాపు అదే file size వద్ద q4_K_M, పాత q4_0 కంటే మెరుగైన output ఇస్తుంది.

మీరు టైప్ చేసిన పేరును బట్టి ఊహించకుండా, డిస్క్‌పై ఉన్న వివరాలను Ollama ద్వారా చూడండి:

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

ollama show, architecture, parameters, quantization, context length మరియు embedding length ను print చేస్తుంది. నెలల క్రితం pull చేసి, ఏ model ఎంచుకున్నారో ఇప్పుడు గుర్తులేని సందర్భంలో quantization line అసలు ఉపయోగించిన వివరాలను చూపుతుంది.

Weightకు బిట్లలో కొలతే ఫైల్ పరిమాణాన్ని నిర్ణయిస్తుంది

ప్రతి పరిమాణ అంచనా ఒకే సంఖ్యతో ప్రారంభమవుతుంది: మొత్తం ఫైల్‌లో సగటున, format ప్రతి weight కోసం ఎన్ని bits ఉపయోగిస్తుందో అది. 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
  }
]

ఆ పట్టికలో ఆశ్చర్యకరమైనది రెండో column. Q4_K_M ప్రతి weightకు నాలుగు bits కాదు. block scales మరియు promoted tensors కూడా వాస్తవంగా స్థలాన్ని ఆక్రమిస్తాయి కాబట్టి ఇది 4.89 bitsగా కొలవబడుతుంది. అదే కారణంగా Q8_0 కూడా ఎనిమిది bits కాకుండా 8.5 bitsగా కొలవబడుతుంది. కొలిచిన సంఖ్యను ఉపయోగిస్తే, ఈ లెక్కింపు వాస్తవ fileకు కొన్ని శాతం తేడాతో సరిపోతుంది:

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 file. Load చేసిన తర్వాత weights ఆక్రమించే memory కూడా దాదాపు ఇంతే. Ollama load సమయంలో ఏదీ unpack చేయదు: quantized weights memoryలో అదే packed రూపంలో ఉంటాయి. ప్రతి blockను ఉపయోగించే సమయంలోనే convert చేస్తుంది.

ప్రతి model size కోసం Ollama వాస్తవంగా అందించేది

చాలా model familyల కోసం library ఒక q4_K_M, ఒక q8_0 మరియు ఒక fp16 tagను ప్రచురిస్తుంది. ఇవి August 2026 నాటికి Qwen3 పరిమాణాలు. ఇవి 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 ఇష్టంలేక అందించే మధ్యస్థ ఎంపిక కాదు. upstream ఎంచుకున్న default ఇదే. అందువల్ల మీరు స్వయంగా పరీక్షించని ఏ modelకైనా మొదటి ప్రయత్నంగా దీనితో సరిపోల్చడం సమంజసం. VPSపై Qwen 3 నడపడంలో tag ఎంపికలకు ఇదే కారణం.

ఈ నిష్పత్తులు ప్రతి వరుసలోనూ వర్తిస్తాయి. q4_K_M నుంచి q8_0కు మారితే పరిమాణం ఖచ్చితంగా రెండింతలు కాకుండా సుమారు 70 శాతం పెరుగుతుంది. దీనికి కారణం embedding మరియు output tensorలు మిగతా tensorలతో సమానంగా scale కావు. fp16 పరిమాణం q4_K_M కంటే సుమారు మూడు రెట్లు ఉంటుంది. q4_K_Mలోని 32B model weights పరిమాణం 20 GB. ఏ context windowకైనా 16 GB machineలో ఇది ఇప్పటికే సరిపోదు. ఏ machineలో ఏ model సరిపోతుందో విస్తృతంగా చూడటానికి మీరు self-host చేయగల models చూడండి.

KV cache ఎందుకు రెండవది, contextపై ఆధారపడే ఖర్చు

Weights స్థిరమైన ఖర్చు. KV cache (key మరియు value cache) మారే ఖర్చు. Context windowలోని ప్రతి token కోసం ప్రతి layerకు చెందిన key మరియు value vectors నిల్వ ఉంటాయి. అందువల్ల మీరు అనుమతించే 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 సంఖ్యలు model స్వంత configuration నుంచి వస్తాయి: 36 layers, 8 key/value heads, మరియు head dimension 128. ollama show architecture మరియు parameter countను అందిస్తుంది. Hugging Faceలోని model యొక్క config.json మిగతా వివరాలను అందిస్తుంది. ప్రతి tokenకు అయ్యే ఖర్చును window పరిమాణంతో గుణిస్తే 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 యొక్క default window 4096 tokens వద్ద, cache weightsకు అదనంగా 0.6 GB memoryని వినియోగిస్తుంది. Windowను 32kకు పెంచితే cache ఒక్కటే 4.83 GBకు చేరుతుంది. ఇది quantized weights వినియోగించే memoryకి దాదాపు సమానం. అప్పుడు మొత్తం modelకు అవసరమైన కనిష్ఠ memory 10 GB అవుతుంది. దీనిని కనిష్ఠ పరిమితి అని అంటాం, ఎందుకంటే compute buffers మరియు operating system memory దీనికి అదనంగా ఉంటాయి. Model load అయిన తర్వాత ollama ps లోని SIZE column నుంచి వాస్తవ విలువను చూడండి.

Ollamaను serviceగా నడిపినప్పుడు window server స్థాయిలో సెట్ అవుతుంది; ప్రతి requestకు విడిగా కాదు:

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 వాస్తవంగా load అయిన windowను నిర్ధారించడానికి ollama ps లోని CONTEXT columnను చూడండి. OLLAMA_KV_CACHE_TYPE cacheను కూడా quantize చేస్తుంది: f16 default. q8_0, f16 వినియోగించే memoryలో సుమారు సగం మాత్రమే ఉపయోగిస్తుంది. q4_0 సుమారు నాలుగో వంతు memoryని ఉపయోగిస్తుంది. ఇది global option. అందువల్ల ఆ serverలోని ప్రతి modelకు ఇదే విధానం వర్తిస్తుంది. పెద్ద window ఉన్న చిన్న systemలో cacheను సగానికి తగ్గించడం, మరే ఒక్క మార్పుకన్నా ఎక్కువ memoryని విడుదల చేస్తుంది. Setting num_ctx మరియు దాని ఖర్చులో windowకు సంబంధించిన వివరాలను చూడండి.

8, 16 లేదా 32 GB VPSలో ఏది సరిపోతుంది

బడ్జెట్‌లో 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తో సరిపోతుంది. అయితే slack చాలా తక్కువగా ఉంటుంది. ఇక్కడ 32k windowతో 8B modelను ప్రణాళిక చేయవద్దు, ఎందుకంటే 10 GB కనిష్ఠ అవసరం ఇప్పటికే ఈ machine సామర్థ్యాన్ని మించిపోయింది.

16 GB. q4_K_M వద్ద 8B modelకు 16k లేదా 32k window సౌకర్యంగా సరిపోతుంది. q4_K_M వద్ద 14B model weights 9.3 GB ఉంటాయి. ఇది modest windowతో సరిపోతుంది. q8_0 వద్ద 8B model 8.9 GB ఉంటుంది. కాబట్టి ఇది కూడా సరిపోతుంది. ఈ రెండు modelsను మీ స్వంత promptsపై పోల్చడం ఈ అంశంపై మీరు కేటాయించగల అత్యంత ఉపయోగకరమైన గంట.

32 GB. q8_0 వద్ద 14B model (16 GB), q4_K_M వద్ద 32B model (20 GB) రెండూ load అవుతాయి. పెద్ద windowతో 32B build పరిమితిని చేరువ చేస్తుంది. కాబట్టి ముందుగా ఊహించకుండా ollama ps ను monitor చేయండి.

క్వాంటైజేషన్‌లో ముందుగా ఏ సామర్థ్యం తగ్గుతుంది

క్వాంటైజేషన్ లోపం మోడల్ చేసే ప్రతి పనిపై సమానంగా ప్రభావం చూపదు. Fluency ఎక్కువకాలం నిలిచి ఉంటుంది. అందుకే నష్టం గుర్తించడం కష్టం: తీవ్రంగా quantize చేసిన మోడల్ కూడా శుభ్రమైన వాక్యాలను రాయగలదు. ముందుగా Precision తగ్గుతుంది. Version number, API signature లేదా date ను కచ్చితంగా గుర్తుచెప్పే సామర్థ్యం ముందుగా దెబ్బతింటుంది. అలాగే reasoning యొక్క పొడవైన క్రమాల్లో రెండో దశలోని చిన్న లోపం ఎనిమిదో దశలో తప్పు సమాధానంగా మారుతుంది. Strict output formats లో ఒక bracket తప్పినా tool call విఫలమవుతుంది.

చివరి అంశమే ఆచరణాత్మక పరీక్ష. మోడల్ తిరిగి ఇచ్చే JSON ను మీ code parse చేయాల్సి ఉంటే, quantization నష్టం అస్పష్టంగా నాసిరకం prose రూపంలో కాకుండా parse error రూపంలో కనిపిస్తుంది. అందువల్ల అదే రోజున సమస్యను గుర్తించగలరు.

Four bits కంటే దిగువకు వెళ్తే నాణ్యత తగ్గుదల వేగంగా పెరుగుతుంది. q3 మరియు two bit రకాలు పెద్ద మోడల్‌ను చిన్న hardware పై అమర్చడానికి ప్రయత్నించే వారికి ఉపయోగపడతాయి. మోడల్‌ను అసలు నడపలేకపోవడం కంటే అవి నిజమైన ప్రత్యామ్నాయం కావచ్చు. అయితే అవి సాధారణ default గా సరైన ఎంపిక కావు. q4_K_M మరియు q8_0 మధ్య తేడా తక్కువగా ఉంటుంది. అందువల్ల published perplexity table మీ workload కోసం నిర్ణయం తీసుకోలేకపోవచ్చు. ఆ విధంగా నిర్ణయించడానికి ప్రయత్నించవద్దు. మీ స్వంత prompts లో ముప్పై prompts పై రెండింటినీ అమలు చేసి, వచ్చిన output ను పరిశీలించండి.

q8_0 లేదా fp16 కోసం RAM వినియోగించడం ఎప్పుడు సముచితం

మెమరీ నిజంగా ఖాళీగా ఉన్నప్పుడు, చిన్న పొరపాట్ల వల్ల పని విఫలమయ్యే సందర్భాల్లో మాత్రమే q8_0 ను డౌన్‌లోడ్ చేయండి: నిర్మిత డేటా వెలికితీత, tool calling, compile కావాల్సిన code. ఇక్కడ మీరు మరింత తెలివైన model ను కొనడం లేదు; అదనపు భద్రతను పొందుతున్నారు.

fp16 ను రెండు కారణాల వల్ల మాత్రమే డౌన్‌లోడ్ చేయండి. మీరు model ను స్వయంగా quantize చేస్తున్నప్పుడు source file అవసరమైతే ఒక కారణం. లేదా baseline ను కొలిచి, మీ four bit build ఎంత సామర్థ్యాన్ని కోల్పోయిందో తెలుసుకోవాలనుకుంటే మరో కారణం. fp16 నుంచి serving చేస్తే q4_K_M కంటే మూడు రెట్లు ఎక్కువ మెమరీ అవసరం అవుతుంది. చాలా మందికి తేడా తెలియదు. CPU మాత్రమే ఉన్న box లో token rate కూడా మూడో వంతుకు తగ్గుతుంది.

స్థిరమైన మెమరీ పరిమితిలో మరింత బలమైన నియమం ఇది: q4_K_M వద్ద ఉన్న పెద్ద model సాధారణంగా q8_0 వద్ద ఉన్న చిన్న model కంటే మెరుగ్గా పనిచేస్తుంది. 14B weights కు చెందిన 9.3 GB మరియు 8B weights కు చెందిన 8.9 GB దాదాపు సమాన RAM (random access memory) వినియోగిస్తాయి. పెద్ద model కు ఎక్కువ జ్ఞానం ఉంటుంది. దీన్ని మీ స్వంత prompts పై పరీక్షించండి; కేవలం నమ్మకంతో నిర్ణయించవద్దు.

CPU ద్వారా మాత్రమే inference చేయడం memory bandwidth వల్ల పరిమితం అవుతుంది

చాలా VPS ప్లాన్‌లలో GPU ఉండదు. అందువల్ల model host యొక్క CPU లోని system memoryలో నడుస్తుంది. అప్పుడు generation arithmetic వల్ల కాకుండా memory bandwidth వల్ల పరిమితం అవుతుంది. ఎందుకంటే ప్రతి token ను ఉత్పత్తి చేయడానికి ప్రతి 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

Dual channel DDR4-3200 host కోసం సైద్ధాంతిక పరిమితి సుమారుగా 50 GB/s ఉంటుంది. VPS ఈ bus ను machine లోని ఇతర tenants అందరితో పంచుకుంటుంది కాబట్టి, మీకు లభించే భాగం ఇంకా తక్కువగా ఉంటుంది. అందువల్ల ఈ సంఖ్యలను ఎవరూ చేరుకోలేని గరిష్ఠ పరిమితిగా పరిగణించండి. ఉపయోగకరమైన విషయం దాని ధోరణి: CPUపై ప్రతి weight కు ఉపయోగించే bits ను సగానికి తగ్గిస్తే token rate సుమారుగా రెట్టింపు అవుతుంది. GPU లేని machineలో వేగాన్ని పెంచడానికి అందుబాటులో ఉన్న అతిపెద్ద మార్గం quantization.

Prompt processing భిన్నంగా పనిచేస్తుంది. పొడవైన prompt ను చదవడం bandwidth వల్ల కాకుండా compute వల్ల పరిమితం అవుతుంది. అందువల్ల అక్కడ అదనపు cores సహాయపడతాయి. అయితే generation speed పై అవి దాదాపు ఎలాంటి ప్రభావం చూపవు. ఒక machine 4k prompt ను వేగంగా స్వీకరించి, తరువాత నెమ్మదిగా generation చేస్తే, అది సాధారణంగానే పనిచేస్తోంది.

ఏ arithmeticనైనా పరిశీలించకుండా నమ్మవద్దు. ప్రతి quantization వద్ద అదే prompt ను ఉపయోగించి మీ స్వంత machineలో సెకనుకు ఎన్ని tokens ఉత్పత్తి అవుతున్నాయో కొలవండి. తరువాత మీ కొలతలనే ఈ అంచనాల కంటే ప్రామాణికంగా పరిగణించండి.

మీరు స్వయంగా మోడల్‌ను quantize చేయడం

మీరు fp16 లేదా fp32 source నుంచి quantized model ను Ollama తో నిర్మించవచ్చు. మీరు ఏదైనా 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 option లేదు. అందువల్ల వాటి కోసం llama.cpp స్వంత tool తో quantize చేసి, పూర్తయిన GGUF file ను import చేయాలి. Build మీరు కోరిన విధంగానే జరిగిందో నిర్ధారించడానికి ollama show లోని quantization line ను ఉపయోగించండి.

ఏదైనా తప్పు జరిగినప్పుడు మీరు చూసేది

GPU ఉపయోగిస్తుందని ఆశించినప్పటికీ ప్రతిదీ CPU పైనే నడుస్తోంది. PROCESSOR కాలమ్‌ను చూడండి:

ollama ps

ఇది 100% GPU, 100% CPU లేదా 48%/52% CPU/GPU వంటి విభజిత విలువను చూపిస్తుంది. విభజిత విలువ అంటే weights మరియు KV cache VRAMలో (వీడియో RAM, graphics cardలోని మెమరీ) సరిపోలేదని అర్థం. అందువల్ల modelలో కొంత భాగం system memoryలో ఉంచబడింది. ప్రతి token నెమ్మదైన భాగం కోసం వేచి ఉండాల్సి వస్తుంది కాబట్టి వేగం CPU-only రేటుకు దగ్గరగా పడిపోతుంది. context windowను తగ్గించండి, cacheను quantize చేయండి లేదా చిన్న buildను ఉపయోగించండి. మరిన్ని cores జోడించడం వల్ల ప్రయోజనం ఉండదు.

లోడ్ అవుతున్నప్పుడు 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 మరియు buffers మొత్తం సర్వర్‌లోని అందుబాటులో ఉన్న memoryని మించాయని అర్థం. swap configure చేయని VPSలో, ఆ line కనిపించే ముందు మొత్తం machine కొన్ని seconds పాటు స్పందించకుండా ఉండవచ్చు.

మీరు ఏ మార్పూ చేయకపోయినా సమాధానాలు నాణ్యతలో తగ్గాయి. ఒకే modelకు చెందిన రెండు builds ollama lsలో వేర్వేరు tagsతో పక్కపక్కనే ఉండవచ్చు. unsuffixed nameను ఉపయోగించే script, library ప్రస్తుతం సూచిస్తున్న buildను అనుసరిస్తుంది. మీ client అభ్యర్థించే ఖచ్చితమైన tagపై ollama show అమలు చేసి, configuration fileలోని nameపై ఆధారపడకుండా quantization lineను చదవండి.

FAQ

నేను ఏ Ollama quantization ను pull చేయాలి?

ముందుగా q4_K_M తో ప్రారంభించండి. చాలా models కోసం Ollama library దీన్నే default tag గా విడుదల చేస్తుంది. అందువల్ల ollama pull qwen3:8b మరియు ollama pull qwen3:8b-q4_K_M ఒకే file ను fetch చేస్తాయి. Memory spare గా ఉన్నప్పుడు, tool calling లేదా structured JSON output వంటి చిన్న పొరపాట్లను కూడా తట్టుకోని పనుల కోసం మాత్రమే q8_0 కు మారండి. Memory budget స్థిరంగా ఉన్నప్పుడు, q4_K_M లోని పెద్ద model సాధారణంగా q8_0 లోని చిన్న model కంటే మెరుగ్గా పనిచేస్తుంది. కాబట్టి precision కోసం RAM కేటాయించే ముందు ఆ pairing ను పరీక్షించండి.

q4_K_M అంటే నిజంగా ప్రతి weight కు four bits అని అర్థమా?

కాదు. Llama 3.1 8B పై కొలిచినప్పుడు ఇది ప్రతి weight కు 4.89 bits ఉంటుంది. ప్రతి weights block తన scale ను స్వంతంగా నిల్వ చేస్తుంది. అత్యంత sensitive tensors ను wider type కు promote చేస్తారు. అదే కారణంతో Q8_0 ఎనిమిది bits కాకుండా 8.5 bits గా కొలవబడుతుంది. అంచనా వేస్తున్నప్పుడు measured figure ను ఉపయోగించండి: parameter count ను bits per weight తో గుణించి, ఎనిమిదితో భాగిస్తే bytes లో file size లభిస్తుంది.

CPU మాత్రమే ఉన్న VPS లో 8B model కు ఎంత RAM అవసరం?

Weights, KV cache మరియు headroom ను కలిపి లెక్కించండి. q4_K_M లోని Qwen3 8B కు 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 ఉంటుంది. Short window కోసం 8 GB, long window కోసం 16 GB RAM ను ప్రణాళికలో ఉంచండి.

నా system లో GPU ఉన్నప్పటికీ model 100% CPU పై ఎందుకు నడుస్తోంది?

ollama ps ను run చేసి PROCESSOR column ను చదవండి. 100% CPU లేదా 48%/52% CPU/GPU వంటి split కనిపిస్తే, weights మరియు KV cache VRAM లో సరిపోలేదని అర్థం. అందువల్ల Ollama model లో కొంత భాగాన్ని లేదా మొత్తం model ను system memory లో ఉంచింది. సాధారణ కారణం card లో సరిపడే పరిమితికంటే context window పెద్దగా ఉండటం. ఎందుకంటే model load అయ్యేటప్పుడు మొత్తం window కోసం cache allocate అవుతుంది. OLLAMA_CONTEXT_LENGTH తో window ను తగ్గించండి. Cache ను సగానికి తగ్గించడానికి OLLAMA_KV_CACHE_TYPE=q8_0 ను set చేయండి. లేదా చిన్న quantization ను pull చేయండి.