Ollama quantization: q4, q8 మరియు fp16 మధ్య తేడాలు

Ollama quantization లో మార్పులు ఏమిటి

Ollama quantization, ఒక మోడల్‌లోని ప్రతి weight ను అది శిక్షణ పొందిన ఫైల్ కంటే తక్కువ bits లో నిల్వ చేస్తుంది. q4_K_M తో ముగిసే tag ప్రతి weight కు సుమారు నాలుగు bits ను ఉంచుతుంది, అదే fp16 అయితే పదహారు bits ను ఉంచుతుంది. దీనివల్ల download పరిమాణం సుమారు నాలుగో వంతుకు తగ్గుతుంది మరియు ప్రతి token ను ఉత్పత్తి చేయడానికి యంత్రం చదవాల్సిన bytes కూడా నాలుగో వంతుకు తగ్గుతాయి. Weights ను తొలగించకుండా, ఒక స్థూల గ్రిడ్ (coarse grid) పైకి round చేస్తారు. నాలుగు bits వద్ద కూడా చాలా మోడల్స్ పూర్తి precision లో ఉన్నట్లుగానే సమాధానాలను ఇస్తాయి.

ఇది మొత్తం trade-off: తక్కువ మెమరీ వినియోగం మరియు సెకనుకు ఎక్కువ tokens లభిస్తాయి, దీనికి ప్రతిఫలంగా ఖచ్చితత్వంలో స్వల్ప తగ్గుదల ఉంటుంది. ఒక నిర్దిష్ట సర్వర్‌లో ఒక నిర్దిష్ట మోడల్ కోసం ఈ రెండింటినీ ఎలా అంచనా వేయాలో కింద వివరించబడింది. దీనివల్ల, మీ సర్వర్‌లో పట్టని ఫైల్‌ను డౌన్‌లోడ్ చేయడానికి ఇరవై నిమిషాలు వృథా చేయాల్సిన అవసరం ఉండదు.

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 జరగలేదని అర్థం: ఇది పదహారు బిట్ల ఫ్లోటింగ్ పాయింట్ వద్ద ఉన్న మోడల్, సాధారణంగా మోడల్స్ అన్నీ ఇదే precision లో విడుదలవుతాయి.

K అనేది K-quant ను సూచిస్తుంది. Weights ను చిన్న చిన్న బ్లాకులుగా విభజిస్తారు. ప్రతి బ్లాక్ తన సొంత scale ను ప్యాక్ చేసిన విలువల పక్కనే నిల్వ చేసుకుంటుంది. ఒక బ్లాక్‌లోని weights అన్నీ 0.01 కి దగ్గరగా ఉంటే, దానికి ఒక fine scale కేటాయించబడుతుంది. ఒక పెద్ద outlier ఉన్న బ్లాక్‌కు coarse scale కేటాయించబడుతుంది. ఈ per-block scales వల్లే నాలుగు బిట్ల ఫైల్ ఉపయోగకరంగా ఉంటుంది, మరియు అందుకే నాలుగు బిట్ల ఫైల్ ఎప్పుడూ ఖచ్చితంగా ప్రతి weight కి నాలుగు బిట్లు ఉండదు.

చివరి అక్షరం మిశ్రమాన్ని (mixture) సూచిస్తుంది. S, M మరియు L అనేవి ఎన్ని tensors లక్ష్య వెడల్పు కంటే ఎక్కువగా ఉండాలో నిర్ణయిస్తాయి. q4_K_M లో, రౌండ్ చేసినప్పుడు నాణ్యత దెబ్బతినే అవకాశం ఉన్న tensors ను ఎక్కువ వెడల్పుతో నిల్వ చేస్తారు, మిగిలినవి నాలుగు బిట్ల వద్దే ఉంటాయి. అందుకే పాత q4_0 తో పోలిస్తే, దాదాపు అదే ఫైల్ సైజులో q4_K_M మెరుగైన అవుట్‌పుట్‌ను ఇస్తుంది.

మీరు టైప్ చేసిన పేరును బట్టి ఊహించడం కంటే, డిస్క్‌లో ఏముందో 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) కోసం ఆ ఫార్మాట్ ఎన్ని బిట్లను ఉపయోగిస్తుంది అనేది ముఖ్యం. llama.cpp తన quantize డాక్యుమెంటేషన్‌లో Llama 3.1 8B కోసం కొలిచిన గణాంకాలను ప్రచురించింది, ఇవి దాదాపు ఒకే ఆకృతిలో ఉండే ఏ dense మోడల్‌కైనా వర్తిస్తాయి.

[
  {
    "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 అంటే వెయిట్‌కు నాలుగు బిట్లు కాదు. ఇది 4.89 బిట్లను కొలుస్తుంది, ఎందుకంటే బ్లాక్ స్కేల్స్ మరియు ప్రమోట్ చేయబడిన టెన్సర్లు రెండూ కొంత స్థలాన్ని ఆక్రమిస్తాయి. ఇదే కారణంతో Q8_0 ఎనిమిది బిట్లకు బదులుగా 8.5 బిట్లను కొలుస్తుంది. కొలిచిన సంఖ్యను ఉపయోగించండి, అప్పుడు లెక్కలు వాస్తవ ఫైల్ పరిమాణానికి కొన్ని శాతం తేడాతో సరిపోతాయి:

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 ఫైల్, దీనిని రెండు సంఖ్యల నుండి తిరిగి పొందవచ్చు. వెయిట్స్ లోడ్ అయిన తర్వాత మెమరీలో ఆక్రమించే స్థలం కూడా దాదాపు ఇంతే ఉంటుంది. Ollama లోడ్ అయ్యేటప్పుడు దేనినీ అన్‌ప్యాక్ చేయదు: క్వాంటైజ్ చేయబడిన వెయిట్స్ మెమరీలో అదే ప్యాక్డ్ రూపంలో ఉంటాయి మరియు ప్రతి బ్లాక్ ఉపయోగించబడినప్పుడు మాత్రమే మార్చబడుతుంది.

ప్రతి మోడల్ పరిమాణానికి Ollama వాస్తవానికి ఏమి అందిస్తుంది

లైబ్రరీ చాలా మోడల్ కుటుంబాల కోసం ఒక q4_K_M, ఒక q8_0 మరియు ఒక fp16 ట్యాగ్‌ను ప్రచురిస్తుంది. కొన్ని కొత్త కుటుంబాలు ఈ పద్ధతిని పాటించవు మరియు లైబ్రరీలో కేవలం క్లౌడ్ ట్యాగ్‌లుగా మాత్రమే కనిపిస్తాయి, వీటిని ఏ పరిమాణంలోనూ డౌన్‌లోడ్ చేయలేము. GLM 5.2 ను VPSలో రన్ చేయడానికి ప్రయత్నిస్తున్నప్పుడు మీరు ఎదుర్కొనే సమస్య ఇదే. ఆగస్టు 2026 నాటికి Qwen3 పరిమాణాలు ఇక్కడ ఉన్నాయి, వీటిని మోడల్ పేజీలోని ట్యాగ్ జాబితా నుండి సేకరించడం జరిగింది. కింద ఉన్న ప్రతి సంఖ్య RAM లోకి రాకముందు డిస్క్ స్థలాన్ని సూచిస్తుంది. వీటిలో రెండు లేదా మూడు కలిపి ఒక చిన్న VPS root వాల్యూమ్‌ను నింపేయగలవు, కాబట్టి ట్యాగ్‌లను సేకరించడం ప్రారంభించే ముందు Ollama డౌన్‌లోడ్ చేసిన మోడళ్లను ఎక్కడ నిల్వ చేస్తుందో తెలుసుకోవడం మంచిది.

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

ఇక్కడ డిఫాల్ట్ ట్యాగ్ ముఖ్యమైనది. ollama pull qwen3:8b అనేది ollama pull qwen3:8b-q4_K_M లాగానే సరిగ్గా 5.2 GB పరిమాణాన్ని డౌన్‌లోడ్ చేస్తుంది, ఎందుకంటే సఫిక్స్ లేని ట్యాగ్ అంటేనే q4_K_M బిల్డ్ అని అర్థం. Q4_K_M అనేది లైబ్రరీ ఇష్టపూర్వకంగా ఇచ్చే రాజీ కాదు. ఇది అప్‌స్ట్రీమ్ ఎంచుకున్న డిఫాల్ట్, కాబట్టి మీరు స్వయంగా పరీక్షించని ఏ మోడల్‌కైనా దీన్ని ఎంచుకోవడమే సరైన మొదటి అడుగు. Qwen 3ని VPSలో రన్ చేయడంలో ట్యాగ్ ఎంపికల వెనుక ఉన్న కారణం కూడా ఇదే.

ఈ నిష్పత్తులు ప్రతి వరుసలోనూ స్థిరంగా ఉంటాయి. q4_K_M నుండి q8_0 కి మారినప్పుడు ఖర్చు సరిగ్గా రెట్టింపు కాకుండా సుమారు డెబ్బై శాతం పెరుగుతుంది, ఎందుకంటే ఎంబెడ్డింగ్ మరియు అవుట్‌పుట్ టెన్సర్‌లు మిగిలిన వాటిలాగే స్కేల్ అవ్వవు. fp16 అనేది సుమారుగా q4_K_M కంటే మూడు రెట్లు ఉంటుంది. q4_K_M వద్ద ఒక 32B మోడల్ 20 GB బరువును కలిగి ఉంటుంది, ఇది 16 GB మెమరీ ఉన్న సర్వర్‌లో ఎటువంటి కాంటెక్స్ట్ విండోను ఉంచడానికి కూడా సరిపోదు. ఏ యంత్రానికి ఏ మోడల్ సరిపోతుందో మరింత స్పష్టంగా తెలుసుకోవడానికి, మీరు ఏ మోడళ్లను self-host చేయవచ్చో చూడండి.

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

Weights అనేవి స్థిరమైన ఖర్చు. KV cache (key and value cache) అనేది మారుతూ ఉండే ఖర్చు. context window లోని ప్రతి token, ప్రతి layer కోసం దాని key మరియు value vectors ను కలిగి ఉంటుంది, కాబట్టి మీరు అనుమతించే window పరిమాణానికి అనుగుణంగా cache సరళ రేఖలో పెరుగుతుంది. మోడల్ లోడ్ అయినప్పుడే మొత్తం 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

ఆ మోడల్ సంఖ్యలు మోడల్ యొక్క సొంత configuration నుంచి వస్తాయి: 36 layers, 8 key/value heads, మరియు 128 head dimension. ollama show మీకు architecture మరియు parameter count ను ఇస్తుంది, మరియు Hugging Face లోని మోడల్ యొక్క 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 యొక్క డిఫాల్ట్ 4096 tokens window వద్ద, cache అనేది weights పైన అదనంగా 0.6 GB ను చేరుస్తుంది. window ను 32k కి పెంచితే, కేవలం cache మాత్రమే 4.83 GB కి చేరుకుంటుంది, ఇది దాదాపు quantized weights తీసుకునే మెమరీతో సమానం, మరియు మొత్తం మోడల్ కోసం కనీస మెమరీ అవసరం 10 GB అవుతుంది. దీనిని కనీస అవసరం అనడానికి కారణం, compute buffers మరియు ఆపరేటింగ్ సిస్టమ్ దీని పైన అదనంగా ఉంటాయి కాబట్టి. మోడల్ లోడ్ అయిన తర్వాత ollama ps లోని SIZE కాలమ్ నుండి అసలైన గణాంకాలను చూడండి.

మీరు Ollama ను సర్వీసుగా రన్ చేస్తున్నప్పుడు, window ను ప్రతి request కు కాకుండా సర్వర్ స్థాయిలో సెట్ చేస్తారు:

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 తో రీస్టార్ట్ చేయండి, ఆపై రన్ అవుతున్న మోడల్ ఏ window తో లోడ్ అయిందో నిర్ధారించుకోవడానికి ollama ps లోని CONTEXT కాలమ్ ను తనిఖీ చేయండి. OLLAMA_KV_CACHE_TYPE అనేది cache ను స్వయంగా quantize చేస్తుంది: f16 అనేది డిఫాల్ట్, q8_0 అనేది f16 లో సగం మెమరీని మాత్రమే వాడుకుంటుంది, మరియు q4_0 దాదాపు నాలుగో వంతు వాడుకుంటుంది. ఇది గ్లోబల్ ఆప్షన్, కాబట్టి ఆ సర్వర్‌లోని ప్రతి మోడల్ ఇదే పద్ధతిని అనుసరిస్తుంది. తక్కువ మెమరీ ఉన్న బాక్స్‌లో పెద్ద window వాడుతున్నప్పుడు, cache ను సగానికి తగ్గించడం వల్ల మరే ఇతర మార్పు కంటే ఎక్కువ మెమరీ ఖాళీ అవుతుంది. num_ctx సెట్ చేయడం మరియు దాని ఖర్చు విండో గురించి వివరంగా వివరిస్తుంది. cache అనేది సర్వర్‌కు ఒకసారి కాకుండా, ఏకకాలంలో వచ్చే ప్రతి request slot కు ఒకసారి కేటాయించబడుతుంది, కాబట్టి Ollama ఒకేసారి రెండు prompts కు సమాధానం ఇచ్చేలా అనుమతిస్తే, మీరు లెక్కించిన మెమరీ రెట్టింపు అవుతుంది; parallel slot count మరియు queue limit ఎంచుకోవడం వెనుక ఉన్న గణితం ఇదే.

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

మోడల్ బరువులు (weights), KV cache, మరియు ఆపరేటింగ్ సిస్టమ్ లేదా ఇతర రన్ అవుతున్న అప్లికేషన్ల కోసం అవసరమైన అదనపు మెమరీని పరిగణనలోకి తీసుకోవాలి. చిన్న VPS లలో 2 GB అదనపు మెమరీ (headroom) ఉండటం సౌకర్యవంతంగా ఉంటుంది.

8 GB. q4_K_M లోని 4B మోడల్ 2.6 GB ఉంటుంది మరియు ఇది సుదీర్ఘమైన window కోసం స్థలాన్ని వదులుతుంది. q4_K_M లోని 8B మోడల్ డిఫాల్ట్ 4k window తో సరిపోతుంది, కానీ చాలా తక్కువ ఖాళీ మాత్రమే ఉంటుంది. ఇక్కడ 32k window తో 8B మోడల్ వాడాలని అనుకోవద్దు, ఎందుకంటే 10 GB కనీస మెమరీ అవసరం ఇప్పటికే ఈ పరిమితిని దాటిపోతుంది.

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

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

క్వాంటైజేషన్ వల్ల మొదట దేని నాణ్యత తగ్గుతుంది

క్వాంటైజేషన్ లోపం మోడల్ చేసే అన్ని పనులపై సమానంగా ప్రభావం చూపదు. భాషా పటిమ (fluency) ఎక్కువ కాలం నిలబడుతుంది, అందుకే ఈ నష్టాన్ని గుర్తించడం సులభం కాదు: సరిగ్గా క్వాంటైజ్ చేయని మోడల్ కూడా స్పష్టమైన వాక్యాలను రాయగలదు. మొదట దెబ్బతినేది ఖచ్చితత్వం (precision). ఒక వెర్షన్ నంబర్, API సిగ్నేచర్ లేదా తేదీని ఖచ్చితంగా గుర్తుంచుకోవడం వంటివి దెబ్బతింటాయి. సుదీర్ఘమైన తార్కిక విశ్లేషణలో, రెండో దశలో జరిగే చిన్న పొరపాటు ఎనిమిదో దశలో తప్పుడు సమాధానానికి దారితీస్తుంది. కఠినమైన అవుట్‌పుట్ ఫార్మాట్‌లలో, ఒక తప్పుడు బ్రాకెట్ వల్ల టూల్ కాల్ విఫలమవుతుంది.

చివరిగా చెప్పిన అంశమే ఆచరణాత్మక పరీక్ష. మీ కోడ్ పార్స్ చేసే JSON ను మోడల్ తిరిగి ఇవ్వాల్సి వచ్చినప్పుడు, క్వాంటైజేషన్ వల్ల కలిగే నష్టం అస్పష్టమైన వచనంలా కాకుండా, పార్స్ ఎర్రర్‌గా కనిపిస్తుంది, కాబట్టి మీరు దీన్ని అదే రోజు గమనించవచ్చు. ఒక కోడింగ్ ఏజెంట్ ఈ పరీక్షకు అత్యంత కఠినమైన ఉదాహరణ, ఎందుకంటే ఇది మోడల్‌ను వరుసగా టూల్ కాల్స్ చేసేలా చేస్తుంది. కాబట్టి మీ Ollama సర్వర్‌కు ఏజెంట్‌ను అనుసంధానించడం ద్వారా, అతిగా క్వాంటైజేషన్ చేయడం వల్ల కలిగే నష్టాన్ని మీరు కొన్ని గంటల్లోనే గుర్తించవచ్చు.

నాలుగు బిట్ల కంటే తక్కువకు వెళ్తే నష్టం తీవ్రంగా ఉంటుంది. q3 మరియు రెండు బిట్ల రకాలు చిన్న హార్డ్‌వేర్‌పై పెద్ద మోడల్‌ను నడపాలనుకునే వారి కోసం ఉద్దేశించినవి, మోడల్‌ను అసలు రన్ చేయలేని పరిస్థితి ఉన్నప్పుడు ఇవి ఒక ప్రత్యామ్నాయం. ఇవి సాధారణ వినియోగానికి తగినవి కావు. q4_K_M మరియు q8_0 మధ్య వ్యత్యాసం చాలా తక్కువ, కాబట్టి ప్రచురించబడిన పర్‌ప్లెక్సిటీ (perplexity) పట్టికలు మీ పనితీరుకు ఏది సరిపోతుందో నిర్ణయించలేవు, కాబట్టి ఆ పద్ధతిలో ప్రయత్నించకండి. మీ సొంత ప్రాంప్ట్‌లలో ముప్పైంటిని రెండింటిపై రన్ చేసి, అవుట్‌పుట్‌ను స్వయంగా పరిశీలించండి.

q8_0 లేదా fp16 ఎప్పుడు RAMకు విలువైనవిగా ఉంటాయి

మీ దగ్గర మెమరీ నిజంగా ఖాళీగా ఉన్నప్పుడు మరియు చిన్న చిన్న తప్పులు కూడా పనిని దెబ్బతీసే సందర్భాల్లో మాత్రమే q8_0ని ఉపయోగించండి: ఉదాహరణకు స్ట్రక్చర్డ్ ఎక్స్‌ట్రాక్షన్ (structured extraction), టూల్ కాలింగ్ (tool calling), మరియు కంపైల్ కావాల్సిన కోడ్ వంటివి. మీరు ఇక్కడ ఒక తెలివైన మోడల్ కోసం కాకుండా, తప్పులు జరగకుండా భద్రత కోసం ఖర్చు చేస్తున్నారు.

fp16ని కేవలం రెండు కారణాల కోసం మాత్రమే ఉపయోగించండి. మీరు మోడల్‌ను మీరే క్వాంటైజ్ (quantize) చేస్తూ సోర్స్ ఫైల్ అవసరమైనప్పుడు, లేదా మీ నాలుగు-బిట్ (four-bit) బిల్డ్ ఎంత నాణ్యతను కోల్పోయిందో తెలుసుకోవడానికి బేస్‌లైన్‌ను కొలిచేటప్పుడు మాత్రమే దీన్ని వాడండి. fp16 నుంచి సర్వ్ చేయడం వల్ల q4_K_M కంటే మూడు రెట్లు ఎక్కువ మెమరీ ఖర్చవుతుంది, కానీ చాలా మందికి ఈ రెండింటి మధ్య తేడా తెలియదు. కేవలం CPU మాత్రమే ఉన్న సిస్టమ్‌లలో ఇది మీ టోకెన్ రేటును మూడవ వంతుకు తగ్గిస్తుంది.

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

CPU-మాత్రమే ఉపయోగించే inference మెమరీ బ్యాండ్‌విడ్త్ ద్వారా పరిమితం చేయబడుతుంది

చాలా VPS ప్లాన్‌లలో GPU ఉండదు, కాబట్టి మోడల్ హోస్ట్ CPUలోని సిస్టమ్ మెమరీలో రన్ అవుతుంది. ఒక టోకెన్‌ను ఉత్పత్తి చేయడానికి ప్రతి వెయిట్‌ను ఒకసారి చదవాల్సి ఉంటుంది కాబట్టి, జనరేషన్ అనేది అంకగణితం (arithmetic) మీద కాకుండా మెమరీ బ్యాండ్‌విడ్త్ మీద ఆధారపడి ఉంటుంది. మీరు ఎన్ని కోర్లను కొనుగోలు చేశారనే దానితో సంబంధం లేకుండా, ఇది ఒక గరిష్ట పరిమితిని (ceiling) విధిస్తుంది.

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

డ్యూయల్ ఛానల్ DDR4-3200 హోస్ట్ కోసం 50 GB/s అనేది సుమారుగా సిద్ధాంతపరమైన గణాంకం. VPSలో ఆ బస్సును మెషీన్‌లోని ఇతర వినియోగదారులందరితో పంచుకోవాల్సి ఉంటుంది కాబట్టి, మీ వాటా అంతకంటే తక్కువగానే ఉంటుంది. కాబట్టి ఈ సంఖ్యలను ఎవరూ చేరుకోలేని గరిష్ట పరిమితిగా పరిగణించండి. ఇక్కడ ముఖ్యమైన విషయం ఏమిటంటే: CPUపై, వెయిట్ బిట్‌లను సగానికి తగ్గిస్తే టోకెన్ రేటు సుమారుగా రెట్టింపు అవుతుంది. GPU లేని బాక్స్‌లో వేగాన్ని పెంచడానికి క్వాంటైజేషన్ (Quantization) అతిపెద్ద మార్గం. మీకు మిగిలిన రేటు ఆమోదయోగ్యంగా ఉందో లేదో అనేది మోడల్‌పై ఆధారపడి ఉంటుంది, మరియు VPSపై Nemotron 3.5 Lightning ఒక నిర్దిష్ట బిల్డ్, ట్యాగ్ మరియు RAM గణాంకాల కోసం ఆ విభజనను వివరిస్తుంది. వేచి ఉండే సమయంలో మిగిలిన సగం మోడల్ ఎంత సమాచారాన్ని రాయాలనుకుంటుంది అనే దానిపై ఆధారపడి ఉంటుంది. సెకనుకు పది టోకెన్ల వేగంతో, ఆరు వందల టోకెన్ల సమాధానానికి ఒక నిమిషం సమయం పడుతుంది, కాబట్టి num_predict తో సమాధానాన్ని పరిమితం చేయడం అనేది ప్రెసిషన్ తగ్గించడం కంటే ఎక్కువ సమయాన్ని ఆదా చేస్తుంది.

ప్రాంప్ట్ ప్రాసెసింగ్ భిన్నంగా పనిచేస్తుంది. సుదీర్ఘమైన ప్రాంప్ట్‌ను చదవడం అనేది బ్యాండ్‌విడ్త్ కంటే కంప్యూట్ (compute) మీద ఆధారపడి ఉంటుంది, కాబట్టి జనరేషన్ వేగంపై ఎటువంటి ప్రభావం చూపకపోయినా, అదనపు కోర్లు ఇక్కడ సహాయపడతాయి. 4k ప్రాంప్ట్‌ను వేగంగా తీసుకుని, ఆపై నెమ్మదిగా జనరేట్ చేసే బాక్స్ సాధారణంగానే పనిచేస్తున్నట్లు లెక్క.

ఏ అంకగణితాన్ని కూడా గుడ్డిగా నమ్మవద్దు. ప్రతి క్వాంటైజేషన్ వద్ద ఒకే ప్రాంప్ట్‌తో మీ బాక్స్‌లో సెకనుకు ఎన్ని టోకెన్లు వస్తున్నాయో కొలవండి, మరియు మీ గణాంకాలనే ప్రామాణికంగా తీసుకోండి.

మీరే స్వయంగా ఒక మోడల్‌ను క్వాంటైజ్ చేయడం

మీరు ఏదైనా మోడల్‌ను ఫైన్-ట్యూన్ చేసినప్పుడు మరియు దానికి సంబంధించి ఎటువంటి లైబ్రరీ ట్యాగ్ అందుబాటులో లేనప్పుడు, Ollama ఒక fp16 లేదా fp32 సోర్స్ నుండి క్వాంటైజ్డ్ మోడల్‌ను తయారు చేయగలదు. క్వాంటైజ్ చేయని వెయిట్స్ (weights) వైపు Modelfile ను పాయింట్ చేయండి:

FROM /path/to/my/model/f16

ఆ తర్వాత బిల్డ్ చేసి నిర్ధారించుకోండి:

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 యొక్క సొంత టూల్‌తో క్వాంటైజ్ చేసి, పూర్తయిన GGUF ఫైల్‌ను ఇంపోర్ట్ చేసుకోవాలి. ఆ ఇంపోర్ట్ పద్ధతిలో ఒక సమస్య ఉంది; చాట్ టెంప్లేట్ సరిపోలకపోతే మోడల్ అర్థం లేని సమాధానాలను ఇస్తుంది. దీని గురించి Ollama లోకి GGUF ఫైల్‌ను ఇంపోర్ట్ చేయడం అనే విభాగంలో వివరించబడింది. మీరు కోరిన విధంగా బిల్డ్ జరిగిందో లేదో నిర్ధారించుకోవడానికి ollama show నుండి వచ్చే quantization లైన్ ఉపయోగపడుతుంది.

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

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

ollama ps

ఇది 100% GPU, 100% CPU, లేదా 48%/52% CPU/GPU వంటి విభజనను చూపిస్తుంది. విభజన అంటే weights మరియు KV cache రెండూ VRAM (గ్రాఫిక్స్ కార్డ్‌లోని మెమరీ) లో సరిపోలేదని అర్థం, కాబట్టి మోడల్‌లో కొంత భాగం సిస్టమ్ మెమరీలో ఉంచబడింది. అప్పుడు వేగం CPU వేగానికి దగ్గరగా పడిపోతుంది, ఎందుకంటే ప్రతి token నెమ్మదిగా ఉన్న సగం భాగం కోసం వేచి ఉంటుంది. కాంటెక్స్ట్ విండోను తగ్గించండి, cache ను క్వాంటైజ్ చేయండి లేదా చిన్న బిల్డ్‌ను ఉపయోగించండి. కోర్లను పెంచడం వల్ల ప్రయోజనం ఉండదు.

లోడ్ అవుతున్నప్పుడు మోడల్ నిలిపివేయబడుతుంది (killed). కెర్నల్ మరియు సర్వీస్ లాగ్‌ను తనిఖీ చేయండి:

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

Out of memory: Killed process ఉన్న లైన్ అంటే weights, KV cache మరియు బఫర్‌ల మొత్తం మెమరీ పరిమితిని దాటిందని అర్థం. Swap కాన్ఫిగర్ చేయని VPSలో, ఆ లైన్ కనిపించే ముందు మొత్తం మెషిన్ కొన్ని సెకన్ల పాటు నిలిచిపోవచ్చు.

మీరు ఏమీ మార్చకపోయినా సమాధానాలు నాణ్యత తగ్గింది. ఒకే మోడల్ యొక్క రెండు బిల్డ్‌లు ollama ls లో వేర్వేరు ట్యాగ్‌ల కింద పక్కపక్కనే ఉండవచ్చు, మరియు సఫిక్స్ లేని పేరును పుల్ చేసే స్క్రిప్ట్ లైబ్రరీ దేనిని సూచిస్తే దానిని అనుసరిస్తుంది. మీ క్లయింట్ అభ్యర్థించే ఖచ్చితమైన ట్యాగ్‌పై ollama show రన్ చేయండి మరియు quantization లైన్‌ను చదవండి, అంతే కానీ మీ కాన్ఫిగరేషన్ ఫైల్‌లోని పేరును నమ్మకండి.

FAQ

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

q4_K_M తో ప్రారంభించండి. చాలా మోడల్స్‌కు Ollama లైబ్రరీ డిఫాల్ట్ ట్యాగ్‌గా దీనినే అందిస్తుంది, కాబట్టి ollama pull qwen3:8b మరియు ollama pull qwen3:8b-q4_K_M రెండూ ఒకే ఫైల్‌ను డౌన్‌లోడ్ చేస్తాయి. మెమరీ ఎక్కువగా ఉన్నప్పుడు మరియు టూల్ కాలింగ్ (tool calling) లేదా స్ట్రక్చర్డ్ JSON అవుట్‌పుట్ వంటి చిన్న తప్పులను కూడా సహించని పనుల కోసం మాత్రమే q8_0 కి మారండి. మెమరీ బడ్జెట్ పరిమితంగా ఉన్నప్పుడు, సాధారణంగా చిన్న మోడల్ q8_0 కంటే పెద్ద మోడల్ q4_K_M మెరుగైన ఫలితాలను ఇస్తుంది, కాబట్టి RAM ను ఖర్చు చేసే ముందు ఈ రెండింటిని పరీక్షించండి.

q4_K_M అంటే నిజంగా ప్రతి వెయిట్‌కు నాలుగు బిట్లు అని అర్థమా?

కాదు. Llama 3.1 8B పై కొలిచినప్పుడు ఇది 4.89 బిట్లుగా ఉంటుంది, ఎందుకంటే ప్రతి వెయిట్ బ్లాక్ తన సొంత స్కేల్‌ను కలిగి ఉంటుంది మరియు అత్యంత ముఖ్యమైన టెన్సర్లు (tensors) అధిక బిట్ రకానికి మార్చబడతాయి. ఇదే కారణంతో Q8_0 కూడా ఎనిమిది బిట్లకు బదులుగా 8.5 బిట్లను కలిగి ఉంటుంది. అంచనా వేసేటప్పుడు ఈ కొలతను ఉపయోగించండి: పారామీటర్ల సంఖ్యను ప్రతి వెయిట్ బిట్లతో గుణించి, ఎనిమిదితో భాగిస్తే వచ్చే విలువ ఫైల్ సైజును బైట్లలో తెలియజేస్తుంది.

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

వెయిట్స్, KV క్యాష్ మరియు అదనపు మెమరీని పరిగణనలోకి తీసుకోండి. Qwen3 8B (q4_K_M) వెయిట్స్ పరిమాణం 5.2 GB. డిఫాల్ట్ 4096 టోకెన్ విండో వద్ద, క్యాష్ అదనంగా 0.6 GB తీసుకుంటుంది, దీనివల్ల కంప్యూట్ బఫర్లు మరియు ఆపరేటింగ్ సిస్టమ్‌కు ముందు కనీసం 5.8 GB RAM అవసరమవుతుంది. 32k విండో వద్ద కేవలం క్యాష్ మాత్రమే 4.83 GB తీసుకుంటుంది. తక్కువ విండో కోసం 8 GB, ఎక్కువ విండో కోసం 16 GB RAM ఉండేలా ప్లాన్ చేసుకోండి.

నా సర్వర్‌లో GPU ఉన్నప్పటికీ మోడల్ 100% CPUని ఎందుకు వాడుతోంది?

ollama ps రన్ చేసి PROCESSOR కాలమ్‌ను గమనించండి. 100% CPU, లేదా 48%/52% CPU/GPU వంటి విభజన కనిపిస్తే, వెయిట్స్ మరియు KV క్యాష్ VRAMలో సరిపోలేదని అర్థం. అప్పుడు Ollama మోడల్‌లో కొంత భాగాన్ని లేదా మొత్తాన్ని సిస్టమ్ మెమరీలో ఉంచుతుంది. మోడల్ లోడ్ అయినప్పుడు మొత్తం విండో కోసం క్యాష్ కేటాయించబడుతుంది కాబట్టి, గ్రాఫిక్స్ కార్డ్ సామర్థ్యం కంటే పెద్ద కాంటెక్స్ట్ విండో ఉండటం దీనికి ప్రధాన కారణం. OLLAMA_CONTEXT_LENGTH తో విండోను తగ్గించండి, OLLAMA_KV_CACHE_TYPE=q8_0 ద్వారా క్యాష్‌ను సగానికి తగ్గించండి లేదా చిన్న quantization మోడల్‌ను pull చేయండి.