Ollamaలో Qwen 3.8 27Bని VPSపై నడపడం ఎలా

GPU లేని VPSపై Qwen 3.8 27B ను నడపగలరా?

VPSపై Qwen 3.8 27B ను నడపాలంటే ముందుగా ఉన్న model tag అవసరం. 4 August 2026 నాటికి Ollama libraryలో qwen3.8 entry అసలు లేదు. విడుదలైన సమీప 27B tag qwen3.6:27b: ఇందులో 27.8 billion parameters, Q4_K_M quantisation, Apache 2.0 licence ఉన్నాయి. కింద ఉన్న ప్రతి command మరియు ప్రతి number, 27 July 2026న విడుదలైన Ollama v0.32.5లోని ఆ tagనే ఉపయోగిస్తుంది.

సంక్షిప్త సమాధానం: 32 GB లేదా అంతకంటే ఎక్కువ RAM ఉన్న VPSపై ఇది సాధ్యమే, కానీ నెమ్మదిగా ఉంటుంది. Q4లోని 27B dense modelకు weights కోసం మాత్రమే సుమారు 17 GB RAM అవసరం. Contextలో ఒక్క token కూడా నిల్వ చేయకముందే ఈ RAM అవసరం ఉంటుంది. అందువల్ల 8 GB మరియు 16 GB plans పూర్తిగా సరిపోవు. సాధారణ two-channel DDR4 VPSలో గరిష్ఠ వేగం సుమారు 3 tokens per second ఉంటుంది. ఇది చాలామంది చదివే వేగం కంటే తక్కువ.

3.8 అనే సంఖ్య ఎక్కడి నుంచి వచ్చింది? ఎక్కువగా ఇది parameter count వల్ల వచ్చిన గందరగోళం కావచ్చు. qwen3.6:27b కోసం Ollama page 27.8B parameters చూపిస్తుంది. తరువాత గుర్తు చేసుకునేటప్పుడు 27.8 ను 3.8గా సులభంగా గుర్తుంచుకోవచ్చు. అదేవిధంగా qwen3.5:27b కూడా ఉంది. ఇది మునుపటి releaseలోని అదే Q4_K_M build. ఏ commandనైనా copy చేయడానికి ముందు live listను Ollama qwen3.6 tag pageలో తనిఖీ చేయండి. నిజమైన qwen3.8 తరువాత విడుదలైనా, ఇక్కడి లెక్కలు వర్తిస్తాయి. ఎందుకంటే అవి version numberపై కాకుండా parameter count మరియు bits per weightపై ఆధారపడతాయి.

ఏ Ollama tag ను pull చేయాలి, ఎలా తనిఖీ చేయాలి

లేని tag ను pull చేస్తే స్పష్టమైన error వస్తుంది. కాబట్టి దీన్ని అదే సిస్టమ్‌లో త్వరగా నిర్ధారించవచ్చు. ఉన్న tag అయినా స్థానికంగా run కాకపోవచ్చు. libraryలో ఉన్నా Ollama cloud నుంచే serve అయ్యే GLM 5.2 విషయంలో ఇదే సమస్య ఎదురవుతుంది.

ollama pull qwen3.8:27b
# Error: pull model manifest: file does not exist

ollama pull qwen3.6:27b
ollama show qwen3.6:27b

ollama show మీరు ప్రస్తుతం కలిగి ఉన్న tag యొక్క architecture, parameter count, context length, quantisation వివరాలను చూపుతుంది. parameter line 27.8B గా, quantisation line Q4_K_M గా ఉంటే, ఈ guide ఆధారపడిన build మీ వద్ద ఉంది. అదే weights కోసం libraryలో అధిక precision కలిగిన qwen3.6:27b-q8_0 మరియు qwen3.6:27b-bf16 కూడా ఉన్నాయి. అదనంగా 35b-a3b tags సమూహం ఉన్నాయి. ఇవి MoE (mixture of experts) models, కాబట్టి CPUపై చాలా భిన్నంగా పనిచేస్తాయి. వాటి గురించి దిగువన మరింత వివరించాం.

ఒక్కో weight కు bytes ఆధారంగా parameter count

[
  {
    "label": "Q4_K_M",
    "size_gb": 17,
    "bits_per_weight": 4.89,
    "notes": "published tag qwen3.6:27b"
  },
  {
    "label": "Q5_K_M",
    "size_gb": 19.8,
    "bits_per_weight": 5.7,
    "notes": "computed, no library tag exists"
  },
  {
    "label": "NVFP4",
    "size_gb": 20,
    "bits_per_weight": 5.76,
    "notes": "published tag 27b-nvfp4"
  },
  {
    "label": "Q8_0",
    "size_gb": 30,
    "bits_per_weight": 8.63,
    "notes": "published tag 27b-q8_0"
  },
  {
    "label": "BF16",
    "size_gb": 56,
    "bits_per_weight": 16.1,
    "notes": "published tag 27b-bf16"
  }
]

Formula ఒకే లైన్‌లో ఉంటుంది. Weights యొక్క bytes = parameters * ఒక్కో weight కు bits / 8. ఖచ్చితంగా 4 bits వద్ద, 27.8 billion parameters విలువ 13.9 GB అవుతుంది. విడుదలైన Q4_K_M tag పరిమాణం 17 GB. అంటే ఆచరణలో ఒక్కో weight కు 4.89 bits ఉంటాయి.

ఈ తేడా లోపం కాదు. K-quant formats ప్రతి tensor ను nominal width వద్ద నిల్వ చేయవు. Compression వల్ల నాణ్యత ఎక్కువగా తగ్గే tensors ను 5 లేదా 6 bits వద్ద ఉంచుతారు. Token embedding మరియు output layers ను సాధారణంగా Q6_K లేదా Q8_0 వద్ద ఉంచుతారు. Format పేరు ఒక average ను సూచిస్తుంది. ఆ average సుమారు 4.9 వద్ద ఉంటుంది. Scale యొక్క మరో చివరలో కూడా ఇదే ప్రభావం కనిపిస్తుంది: BF16 కోసం 56 GB అంటే ఒక్కో weight కు flat 16 bits కాకుండా 16.1 bits ఉంటాయి. ఎందుకంటే file లో metadata మరియు full-precision embedding table కూడా ఉంటాయి.

ఈ model కు Q5_K_M కోసం published tag లేదు. అందువల్ల 19.8 GB row ను కొలిచిన విలువతో కాకుండా, ఆ format కు సాధారణమైన ఒక్కో weight కు 5.7 bits ఆధారంగా లెక్కించారు. Q8_0, Q4 పరిమాణాన్ని దాదాపు రెట్టింపు చేసి 30 GB కు చేరుతుంది. CPU-only box లో ఆ రెట్టింపు ప్రతి token కు memory traffic ను రెండింతలు చేస్తుంది. అందువల్ల మీ tokens per second కూడా సుమారు సగానికి తగ్గుతుంది. ఈ కారణం ఒక్కటే Q4_K_M ను ఇక్కడ సరైన default గా చేస్తుంది. Memory పరిమాణం కాకుండా quality పరంగా ఈ నిర్ణయాన్ని పరిశీలించాలనుకుంటే, Q4, Q8 మరియు fp16 యొక్క మరింత సన్నిహితమైన పోలిక output వాస్తవంగా ఎక్కడ degrade అవడం ప్రారంభమవుతుందో చూపిస్తుంది.

సందర్భ పరిమాణం పెరిగేకొద్దీ KV cache ఖర్చు

Weights ఒక స్థిరమైన ఖర్చు. KV cache (key మరియు value cache; మోడల్ ఇప్పటికే చూసిన ప్రతి token కోసం నిర్వహించే attention state) context length తో నేరుగా పెరుగుతుంది. ఎక్కువగా RAM అయిపోవడానికి ఇదే ప్రధాన కారణం.

[
  {
    "label": "4k tokens",
    "kv_f16_gb": 1,
    "kv_q8_gb": 0.5
  },
  {
    "label": "8k tokens",
    "kv_f16_gb": 2,
    "kv_q8_gb": 1
  },
  {
    "label": "16k tokens",
    "kv_f16_gb": 4,
    "kv_q8_gb": 2
  },
  {
    "label": "32k tokens",
    "kv_f16_gb": 8,
    "kv_q8_gb": 4
  },
  {
    "label": "64k tokens",
    "kv_f16_gb": 16,
    "kv_q8_gb": 8
  },
  {
    "label": "128k tokens",
    "kv_f16_gb": 32,
    "kv_q8_gb": 16
  }
]

ఈ గణాంకాలు ఈ పరిమాణ తరగతిలో Qwen ఇటీవలి dense models లో ఉపయోగించిన నిర్మాణాన్ని ఆధారంగా చేసుకున్నాయి: 64 layers, GQA (grouped-query attention) కింద 8 key/value heads, మరియు 128 head dimension. దీని ప్రకారం f16 వద్ద ప్రతి token కు 256 KiB అవసరం. అందువల్ల 32k tokens వద్ద 8 GB, 128k వద్ద 32 GB అవసరం. మీ స్వంత system పై ఈ లెక్కలను నేరుగా వర్తింపజేయవద్దు. Model ను load చేసి, ollama ps లోని SIZE column ను చూడండి. ఇది weights, cache మరియు overhead మొత్తాన్ని ఒకే గణాంకంగా చూపిస్తుంది.

అందుకే model card లోని 256K context ఒక ప్రధాన పరిమితిగా మాత్రమే చూడాలి; అది తప్పనిసరి వినియోగ ప్రణాళిక కాదు. దీన్ని f16 వద్ద పూర్తిగా నింపాలంటే weights కు అదనంగా 64 GB cache అవసరం. ఇప్పటికే weights కోసం 17 GB వినియోగించిన machine పై ఇది మరింత భారమవుతుంది. Ollama default గా పూర్తి window ను ఇవ్వదు. అది చాలా చిన్న window ను load చేస్తుంది. OLLAMA_CONTEXT_LENGTH ద్వారా మీరు దాన్ని ఉద్దేశపూర్వకంగా పెంచవచ్చు. Server-wide variable ఒక్కటే నియంత్రణ కాదు. వ్యక్తిగత request పై num_ctx సెట్ చేయడం ద్వారా మిగతా requests కు తక్కువ ఖర్చుతో కూడిన default ను ఉంచి, ఒక దీర్ఘకాలిక job కు మాత్రమే పెద్ద window ఇవ్వవచ్చు. దీన్ని దశలవారీగా పెంచండి. ప్రతి మార్పు తర్వాత ollama ps ను పరిశీలించండి.

రెండు settings cache ను సగానికి లేదా అంతకంటే తక్కువకు తగ్గిస్తాయి. OLLAMA_KV_CACHE_TYPE=q8_0 cache ను 16 bits బదులుగా 8 bits వద్ద నిల్వ చేస్తుంది. దీని వల్ల 32k tokens కు 8 GB నుంచి 4 GB కు తగ్గుతుంది. దీనికి flash attention అవసరం. అందువల్ల OLLAMA_FLASH_ATTENTION=1 ను కూడా సెట్ చేయండి. అమలైందని ఊహించకుండా ollama ps లో తగ్గుదల కనిపించిందో నిర్ధారించండి. OLLAMA_NUM_PARALLEL=1 కూడా అంతే ముఖ్యమైనది. Ollama ఒకేసారి అనేక requests ను అందించగలదు. ప్రతి slot కు context లో తనకంటూ ఒక భాగం లభిస్తుంది. కాబట్టి parallelism ను default వద్ద ఉంచితే, మీరు అంచనా వేసిన cache అవసరం నిశ్శబ్దంగా అనేక రెట్లు పెరుగుతుంది. ఈ machine ను ఒకరి కంటే ఎక్కువ మంది ఉపయోగిస్తే సమస్య మొదలయ్యేది ఈ పెరుగుదల వద్దే. self-hosted model అందించగల ఏకకాల వినియోగదారుల సంఖ్య core count కంటే చాలా ముందుగానే cache slots మరియు queue depth ద్వారా నిర్ణయించబడుతుంది.

8, 16, 32 మరియు 64 GB RAMలో ఏది సరిపోతుంది

[
  {
    "label": "8 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "Weights alone exceed the box. Use a 4b or 8b model."
  },
  {
    "label": "16 GB",
    "q4_max_ctx_ktok": 0,
    "q8_max_ctx_ktok": 0,
    "notes": "17 GB of weights does not fit in 16 GB of RAM."
  },
  {
    "label": "32 GB",
    "q4_max_ctx_ktok": 32,
    "q8_max_ctx_ktok": 0,
    "notes": "Q4 fits with room to spare. Q8 weights do not fit."
  },
  {
    "label": "64 GB",
    "q4_max_ctx_ktok": 128,
    "q8_max_ctx_ktok": 64,
    "notes": "Both fit. Q8 leaves much less room for context."
  }
]

ఈ రెండు సంఖ్యలను, weights తో పాటు సరిపోయే contextలోని వేల tokens గా చదవండి. ఇవి f16 cache ఉపయోగించే, headless Linux VPSలో, operating system కోసం సుమారు 1.5 GB మరియు కొద్దిగా అదనపు margin మిగిలే పరిస్థితికి సంబంధించినవి. సున్నా అంటే weightsకే స్థలం సరిపోదని అర్థం. కాబట్టి ఏ context కూడా సరిపోదు.

8 GB మరియు 16 GB మధ్య తేడా స్వల్పం కాదు. 17 GB weights 16 GB RAMలో సరిపోవు. ఏ context setting మార్చినా ఇది మారదు. Swap జోడించినా సమస్య పరిష్కారం కాదు. Ollama GGUF fileను memory-map చేస్తుంది. Resident pages RAM పరిమితిని దాటిన తర్వాత kernel వాటిని diskకు తొలగించి మళ్లీ చదవడం ప్రారంభిస్తుంది. అప్పుడు ప్రతి token కోసం disk నుంచి gigabytes డేటా తీసుకురావాలి. సిస్టమ్ high iowaitలో చిక్కుకుని, సెకనుకు ఒక tokenకంటే చాలా తక్కువ వేగంతో output ఇస్తుంది.

32 GB ప్రారంభానికి సరిపడే స్థాయి. Weights 17 GB తీసుకుంటాయి. మీకు సుమారు 13 GB మిగులుతుంది. Marginతో కలిపి ఇది సుమారు 32k tokens f16 contextకు సరిపోతుంది. 30 GB పరిమాణం ఉన్న Q8_0 weights ఈ స్థాయిలో అసలు సరిపోవు.

64 GB సౌకర్యవంతమైన స్థాయి. Q4 ఉపయోగిస్తే సుమారు 128k tokens contextకు స్థలం మిగులుతుంది. Q8_0 weights కూడా సరిపోతాయి. వాటి తర్వాత సుమారు 64k tokens contextకు స్థలం ఉంటుంది. Q8 కోసం 64 GBకు అదనంగా చెల్లించే ముందు, మీరు ఏమి పొందుతున్నారో స్పష్టంగా తెలుసుకోండి: ముందే నెమ్మదిగా ఉన్న యంత్రంలో, సగం వేగంతో కొద్దిగా మెరుగైన output. దాదాపు అందరికీ ఎక్కువ contextతో కూడిన Q4 మరింత ప్రయోజనకరమైన ఎంపిక.

VPSపై CPU inference ఎంత వేగంగా ఉంటుంది?

Dense model నుంచి ఒక token రూపొందించాలంటే ప్రతి weight ను memory నుంచి ఒక్కసారి చదవాలి. కొన్ని weights మాత్రమే కాదు. అన్నీ చదవాలి. అందువల్ల వేగ పరిమితిని మీ core count నిర్ణయించదు. అది weights పరిమాణంతో భాగించిన memory bandwidth పై ఆధారపడి ఉంటుంది. Q4లో ప్రతి token కు 17 GB memory traffic అవసరం.

[
  {
    "label": "DDR4-2666, 2 channel",
    "mem_bandwidth_gb_s": 42.6,
    "ceiling_tok_s": 2.5
  },
  {
    "label": "DDR4-3200, 2 channel",
    "mem_bandwidth_gb_s": 51.2,
    "ceiling_tok_s": 3
  },
  {
    "label": "DDR5-4800, 2 channel",
    "mem_bandwidth_gb_s": 76.8,
    "ceiling_tok_s": 4.5
  },
  {
    "label": "DDR4-3200, 8 channel",
    "mem_bandwidth_gb_s": 204.8,
    "ceiling_tok_s": 12
  },
  {
    "label": "DDR5-4800, 12 channel",
    "mem_bandwidth_gb_s": 460.8,
    "ceiling_tok_s": 27.1
  }
]

అవి గరిష్ఠ పరిమితులు మాత్రమే, కొలిచిన ఫలితాలు కావు. Memory latency మరియు పరిపూర్ణంగా లేని prefetching కారణంగా వాస్తవ output సాధారణంగా చూపిన విలువలో 50 నుంచి 70 శాతం వరకు ఉంటుంది. Two-channel DDR4-3200 VPS గరిష్ఠంగా సెకనుకు 3 tokens ఉత్పత్తి చేయగలదు. కాబట్టి సుమారు 2 tokens ఆశించాలి. Two-channel DDR5-4800 సర్వర్ గరిష్ఠంగా 4.5 tokens ఉత్పత్తి చేయగలదు. కాబట్టి సుమారు 3 tokens ఆశించాలి.

పెద్ద server rows విషయంలో ఒక హెచ్చరిక ఉంది. Twelve-channel EPYC platform కు 460.8 GB/s memory bandwidth మరియు సెకనుకు 27.1 tokens గరిష్ఠ పరిమితి ఉంది. అయితే మీరు మొత్తం EPYC సర్వర్‌ను అద్దెకు తీసుకోరు. ఆ machine లోని ప్రతి tenant memory bandwidth ను పంచుకుంటాడు. అందువల్ల 8 vCPU slice కు twelve channels ప్రత్యేకంగా కేటాయించబడవు. GPUపై దృష్టి పెట్టే guides ఈ విషయాన్ని పూర్తిగా విస్మరిస్తాయి. అదే model పై ఒకే vCPU count ఉన్న రెండు VPS plans వేగంలో మూడు రెట్లు తేడా చూపడానికి ఇదే కారణం.

అదే కారణంతో ఎక్కువ vCPUs త్వరగానే ప్రయోజనం ఇవ్వడం ఆపేస్తాయి. Memory controller అందించగల వేగం కంటే cores data ను వేగంగా అభ్యర్థించడం ప్రారంభించిన తర్వాత, అదనపు threads scheduling overhead ను మాత్రమే పెంచుతాయి. OLLAMA_NUM_THREAD ను మీ physical core count కు సెట్ చేసి కొలవండి. తరువాత ఆ సంఖ్యలో సగం ప్రయత్నించండి. అనేక shared plans లో తక్కువ setting వేగంగా ఉంటుంది.

Prompt processing భిన్నంగా ఉంటుంది. మొదటి token కనిపించే ముందు input పై చేసే pass ను prefill అంటారు. ఇది bandwidth bound కాకుండా compute bound గా ఉంటుంది. అందువల్ల ఇది cores పెరిగినప్పుడు వేగం పెంచుకుంటుంది. ఆచరణలో పెద్ద prompt కోసం output ప్రారంభమయ్యే ముందు ఎక్కువసేపు వేచి ఉండాలి. తరువాత పైన పేర్కొన్న స్థిరమైన నెమ్మది రేటుతో output వస్తుంది. --verbose తో ఈ రెండు దశలను విడిగా కొలవండి. ఇది ప్రతి request కు ఒక prompt eval rate మరియు ఒక eval rate ను చూపిస్తుంది.

Dense 27B చాలా నెమ్మదిగా ఉంటే, CPUపై ప్రయత్నం విరమించే ముందు qwen3.6:35b-a3b tags ను పరిశీలించండి. అవి ప్రతి token కు మొత్తం 27.8 billion parameters బదులుగా సుమారు 3 billion parameters ను మాత్రమే activate చేస్తాయి. అందువల్ల diskపై file పెద్దదిగా ఉన్నప్పటికీ, ప్రతి token కు memory traffic దాదాపు ఒక order of magnitude తగ్గుతుంది. RAM footprint కు బదులుగా వేగాన్ని పొందుతారు. ఇక్కడ runtime ఎంపిక కూడా ముఖ్యమే. ఒకే underlying inference code పై Ollama మరియు llama.cpp వేర్వేరు CPU tuning controls ను అందిస్తాయి.

GPU గంటను అద్దెకు తీసుకోవాల్సిన సందర్భం

[
  {
    "label": "L40S, 48 GB",
    "mem_bandwidth_gb_s": 864,
    "ceiling_tok_s": 51
  },
  {
    "label": "RTX 4090, 24 GB",
    "mem_bandwidth_gb_s": 1008,
    "ceiling_tok_s": 59
  },
  {
    "label": "A100, 80 GB",
    "mem_bandwidth_gb_s": 2039,
    "ceiling_tok_s": 120
  },
  {
    "label": "H100 SXM, 80 GB",
    "mem_bandwidth_gb_s": 3350,
    "ceiling_tok_s": 197
  }
]

ప్రచురించబడిన GPU memory bandwidth కు ఇదే సూత్రాన్ని వర్తింపజేస్తే, వేరే రకమైన ఫలితం వస్తుంది. 24 GB consumer card ఈ weights పై సెకనుకు గరిష్ఠంగా 59 tokens ను ప్రాసెస్ చేయగలదు. ప్రస్తుత data centre card 197 వరకు చేరుతుంది. Thread counts ను సర్దుబాటు చేయడం ద్వారా ఈ వ్యత్యాసాన్ని తొలగించలేరు. Data centre card తన memory ను 1008 GB/s వేగంతో నడుపుతుంది; మీ VPS మాత్రం tens స్థాయిలో ఉంటుంది.

కాబట్టి నిర్ణయం మీ అభిరుచిపై కాకుండా workload పై ఆధారపడాలి. పని asynchronous గా ఉండి, దాని కోసం ఎవరూ వేచి ఉండనప్పుడు CPU inference సరైన ఎంపిక: ఉదాహరణకు, పత్రాల సమూహాన్ని రాత్రంతా summarise చేయడం లేదా మీరు నిద్రిస్తున్న సమయంలో nightly classification job ను అమలు చేయడం. ఒక వ్యక్తి output కోసం వేచి ఉన్న వెంటనే, లేదా requests ప్రతి 30 seconds కంటే వేగంగా వచ్చిన వెంటనే GPU ను అద్దెకు తీసుకోండి. CPU-only box కు batching headroom ఉండదు; queue కేవలం పెరుగుతూనే ఉంటుంది.

ఖర్చు పోలిక మొదట కనిపించినంత స్పష్టంగా ఉండదు. Model loaded గా ఉన్నా లేకపోయినా 64 GB VPS నెలలోని ప్రతి గంటకు billing చేస్తుంది. GPU instance మాత్రం మీరు దాన్ని నడిపిన గంటలకు మాత్రమే billing చేస్తుంది. మీ వాస్తవ వినియోగం రోజుకు రెండు గంటలు అయితే, rented GPU వేగంగా ఉండటమే కాకుండా చౌకగా కూడా ఉండవచ్చు. ముందుగా మీ duty cycle ను లెక్కించి, తరువాత ధరను పోల్చండి. GPU కలిగిన VPS ను ఎంచుకోవడం instance లోనే ఏ అంశాలను పరిశీలించాలో వివరిస్తుంది. అలాగే GPU పై concurrent requests ను serve చేసినప్పుడు vLLM, Ollama కంటే ముందంజలో ఉంటుంది; కారణం అది requests ను సరిగ్గా batch చేయడం.

ప్రజలు తరచుగా మరచిపోయే మూడవ ఎంపిక కూడా ఉంది. Batch work కోసం 27B ను CPU పై ఉంచి, interactive path ముందు hosted API model ను ఉంచండి. రెండు పనులకూ ఒకే model ను ఉపయోగించాల్సిన అవసరం లేదు.

Ollamaను ఇన్‌స్టాల్ చేసి మీ స్వంత సిస్టమ్‌ను కొలవండి

ఇన్‌స్టాల్ స్క్రిప్ట్ అధికారికమైనది. ఇది ప్రత్యేకమైన ollama user గా నడిచే systemd service ను ఏర్పాటు చేస్తుంది.

curl -fsSL https://ollama.com/install.sh | sh
ollama --version
free -g

ollama --version 0.32.5 లేదా అంతకంటే కొత్త version ను చూపాలి. ఏదైనా pull చేయడానికి ముందు free -g ను తనిఖీ చేయండి. Mem line లోని total column 32 కంటే తక్కువగా ఉంటే ఇక్కడే ఆపండి. చిన్న model ను ఎంచుకోండి. నడపలేని 17 GB model ను pull చేయడం వల్ల ఒక గంట సమయం మరియు అధిక disk స్థలం వృథా అవుతుంది.

Runtime options ను మీ shell లో కాకుండా systemd override లో సెట్ చేయండి. Model service లోపల నడుస్తుంది. అందువల్ల అది మీ interactive environment ను చూడదు.

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_NUM_PARALLEL=1"
Environment="OLLAMA_MAX_LOADED_MODELS=1"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"
Environment="OLLAMA_KEEP_ALIVE=60m"

sudo systemctl restart ollama
ollama pull qwen3.6:27b
ollama run qwen3.6:27b --verbose "Name two Linux distributions."

మీకు కావాల్సిన కొలతను --verbose output అందిస్తుంది. Generation సమయంలో మీ tokens per second వేగం eval rate. Prefill వేగం prompt eval rate. Disk నుంచి weights చదవడానికి పట్టిన సమయం load duration. అందుకే OLLAMA_KEEP_ALIVE=60m సెట్ చేయబడింది. CPUపై ప్రతి request సమయంలో disk నుంచి 17 GB ను మళ్లీ load చేయడానికి పట్టే సమయం, request ను ప్రాసెస్ చేయడానికి పట్టే సమయం కంటే ఎక్కువగా ఉంటుంది. Default idle timeout ఐదు నిమిషాలు. Items మధ్య విరామాలు ఉన్న batch queue ఈ load ఖర్చును పదేపదే భరిస్తుంది. Model ను memoryలో ఉంచే options request కు సంబంధించిన keep_alive field ను, అలాగే reboot తర్వాత కూడా అమలులో ఉండే setting ను కవర్ చేస్తాయి.

Model load అయి ఉన్నప్పుడు, రెండవ terminal నుంచి దాని memory footprint ను తనిఖీ చేయండి.

ollama ps

SIZE column KV cache తో సహా వాస్తవ memory footprint ను చూపుతుంది. ఇది weights పరిమాణానికి, అలాగే KV chart లోని మీ context length row కు దగ్గరగా ఉండాలి. 8-bit cacheతో 8192 tokens వద్ద, weights కు అదనంగా సుమారు ఒక gigabyte memory అవసరమవుతుంది. Cache f16 వద్ద ఉండి ఉంటే ఈ పరిమాణం 2 GB అయ్యేది. PROCESSOR column 100% CPU ను చూపాలి. అది మరేదైనా చూపిస్తే, ఏదో ఒక ప్రక్రియ GPU ను ఉపయోగిస్తోంది. ఈ guide లోని speed numbers మీ సిస్టమ్‌కు వర్తించవు.

విఫలత పరిస్థితులు మరియు మీరు ఖచ్చితంగా చూసే strings

మోడల్ load కావడం లేదు. Ollama రెండు figures పేర్లను కలిగిన ఒక line ను model requires more system memory (18.6 GiB) than is available (15.2 GiB) ఆకృతిలో చూపిస్తుంది. ఇది మంచి failure, ఎందుకంటే kernel నిర్ణయించే వరకు వేచి ఉండకుండా Ollama allocation కు ముందే తనిఖీ చేసింది. Context length తగ్గించండి, చిన్న tag కు మారండి లేదా పెద్ద plan ఉపయోగించండి.

సమాధానం మధ్యలో process కనిపించకుండా పోతుంది. Client ఉపయోగకరమైన సమాచారం ఏదీ చూపించదు, కానీ journalctl -u ollama -n 50 service మళ్లీ ప్రారంభమవుతున్నట్లు చూపిస్తుంది. dmesg -T | tail అమలు చేయండి. Out of memory: Killed process ... (ollama) కు సరిపడే line కనిపిస్తే kernel OOM killer ఆ process ను నిలిపివేసిందని అర్థం. Pre-load తనిఖీ విజయవంతమైనప్పటికీ, దీర్ఘమైన conversation సమయంలో cache అంచనాను మించి పెరిగినప్పుడు ఇది జరుగుతుంది. Context length తగ్గించండి.

Pull వెంటనే విఫలమవుతుంది. Error: pull model manifest: file does not exist అంటే ఆ tag library లో లేదని అర్థం. qwen3.8:27b టైప్ చేసినా ఇదే కనిపిస్తుంది. Version number లో ఏదైనా typo ఉన్నా ఇదే జరుగుతుంది. Network ను నిందించే ముందు library page లో tag ను నిర్ధారించండి.

అన్నీ పనిచేస్తున్నాయి, కానీ వేగం భరించలేనంత తక్కువగా ఉంది. తగినంత RAM ఉన్న machine లో token వేగం one per second కంటే తక్కువగా ఉంటే compute సమస్యకన్నా paging సమస్య ఉండే అవకాశం ఉంది. Generate చేస్తున్నప్పుడు vmstat 1 అమలు చేయండి. Non-zero si లేదా so column కనిపిస్తే kernel swapping చేస్తోందని అర్థం. Context తక్కువ చేయడం లేదా loaded models సంఖ్యను తగ్గించడం పరిష్కారం. Swap activity లేకుండా wa నిరంతరం ఎక్కువగా ఉంటే memory-mapped weights disk నుంచి మళ్లీ చదవబడుతున్నాయని అర్థం. అంటే అవి వాస్తవంగా memory లో సరిపోవడం లేదు.

మొదటి token రావడానికి 30 seconds పడుతుంది, తరువాత output వేగం పెరుగుతుంది. దాన్ని prefill అంటారు. ఇది సాధారణమే. Cache ఉపయోగించలేని ప్రతి request లో long system prompt కోసం సమయం వెచ్చించాలి. అందువల్ల మరేదైనా tuning చేయడానికి ముందు system prompt ను సంక్షిప్తం చేయండి.

CPU-only 27B వాస్తవంగా దేనికి ఉపయోగపడుతుంది

ఆశల ఆధారంగా కాకుండా, సంఖ్యల ఆధారంగా అంచనాలను నిర్ణయించండి. సెకనుకు రెండు నుంచి నాలుగు tokens వేగంతో 500 tokens సమాధానం ఇవ్వడానికి రెండు నుంచి నాలుగు నిమిషాలు పడుతుంది. ఇది chat కోసం ఉపయోగించలేనిది, కానీ queue కోసం పూర్తిగా అనుకూలంగా ఉంటుంది. సమాధానం ఇచ్చే ముందు ఆలోచించే model ఈ లెక్కను మరింత నెమ్మదిస్తుంది, ఎందుకంటే hidden reasoning tokens కూడా సమాధానం tokens మాదిరిగానే అదే తక్కువ వేగంతో రూపొందుతాయి. అందువల్ల పని ఆధారంగా reasoning effort స్థాయిని సరిపోల్చడం model మార్చకుండా సమాధానాన్ని తక్కువ సమయంలో పొందడానికి ఉన్న కొద్ది మార్గాల్లో ఒకటి. Document summarisation, bulk tagging, పెద్ద సంఖ్యలో ఉన్న files నుంచి fields వెలికితీయడం, unattended code review వంటి పనులు ఈ వేగాన్ని తట్టుకుంటాయి, ఎందుకంటే సమాధానం కోసం ఏదీ వేచి ఉండదు. Coding assistance ఈ పరిమితి రేఖపైనే ఉంటుంది. అందువల్ల మీరు host చేసే model కు coding agent ను అనుసంధానించడం commit messages, test scaffolding వంటి background jobs కోసం ప్రయోజనకరం. మీరు కూర్చొని వేచి చూసే inline suggestions కోసం మాత్రం కాదు.

నిజమైన కారణం privacy. Model మీరు అద్దెకు తీసుకుని నియంత్రించే hardware పై నడుస్తుంది. ఏ request కూడా ఆ machine బయటకు వెళ్లదు. ప్రతి token కు విడిగా bill ఉండదు. సెకనుకు మూడు tokens వేగం ఉన్నప్పటికీ regulated data కోసం ఇది చాలా విలువైనది. అయితే ప్రత్యామ్నాయంతో నిజాయితీగా పోల్చండి: frontier-scale model ను self-host చేయడానికి దాదాపు ఒక క్రమ పరిమాణం ఎక్కువ hardware అవసరం. Output చదవదగిన స్థాయిలో ఉండే ఆ curve పై CPUలో 27B అత్యల్ప ఖర్చు point.

దీన్ని benchmark చేయడానికి నిజమైన structured input అవసరం. throughput కొలవడానికి ముందే చాలా public data APIs account కోరుతాయి. Strasmore demo endpoint (దీన్ని మేమే నిర్వహిస్తాము) 22 సంవత్సరాల US market data పై read-only SQL కు key లేదా signup లేకుండా సమాధానం ఇస్తుంది. https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM delayed_stocks_minute_aggs LIMIT 5 కు GET request పంపితే JSON లభిస్తుంది. దాన్ని నేరుగా prompt loop కు pipe చేయవచ్చు. దాన్ని రూపొందించిన ఖచ్చితమైన SQL కూడా response లో ఉంటుంది. అందువల్ల model summarise చేయడానికి, మీరు స్వతంత్రంగా తనిఖీ చేయడానికి వీలున్న data ఉంటుంది. పరిమితులు ఒక్కో call కు 500 rows మరియు 20 seconds. సెకనుకు రెండు tokens వేగం ఉన్న machine కూడా దీనిని పూర్తిగా వినియోగించుకునేలోపే ఈ పరిమితుల్లోనే ఉంటుంది. పూర్తి column list https://api.strasmore.com/v1/schema వద్ద ఉంది.

ఇది మీ మొదటి Ollama install అయితే, VPS పై Ollama నడపడానికి పూర్తి walkthrough ఈ guide ఇప్పటికే అందుబాటులో ఉందని భావించే service setup, HTTP API, firewall rules ను వివరిస్తుంది. Port 11434 ను internet కు expose చేయవద్దు. Ollama కు స్వంత authentication లేదు. అందువల్ల ఆ port కు చేరుకోగల ఎవరైనా మీ model ను ఉపయోగించి, మీ prompts ను చదవగలరు.

FAQ

Ollamaలో Qwen 3.8 27B model ఉందా?

లేదు. 4 August 2026 నాటికి Ollama libraryలో qwen3.8 namespace లేదు. ప్రస్తుతం ఉన్న 27B tags qwen3.5:27b మరియు qwen3.6:27b. ఇవి రెండూ 27.8 billion parameters కలిగిన dense model యొక్క Q4_K_M builds. Search termలోని 3.8 అనేది version numberగా గుర్తున్న 27.8B parameter count అయి ఉండే అవకాశం చాలా ఎక్కువ. ప్రస్తుత జాబితా కోసం https://ollama.com/library/qwen3.6/tags ను చూడండి. తాజాగా విడుదలైన 27B కావాలంటే qwen3.6:27b ను pull చేయండి. లేని tagతో pull విఫలమైతే Error: pull model manifest: file does not exist కనిపిస్తుంది.

VPSలో Qwen 27B model నడపడానికి ఎంత RAM అవసరం?

Q4_K_M కోసం 32 GB ఆచరణాత్మక కనిష్ఠం. Weights పరిమాణం 17 GB. Operating systemకు సుమారు 1.5 GB అవసరం. f16లో contextలోని ప్రతి 4000 tokensకు KV cache సుమారు 1 GB అదనంగా తీసుకుంటుంది. 16 GB planలో weights పూర్తిగా సరిపోవు. Swap ఉపయోగపడదు, ఎందుకంటే file memory-mappedగా ఉంటుంది. ప్రతి token సమయంలో kernel దాన్ని disk నుంచి మళ్లీ చదువుతుంది. 64 GB planలో long contextకు లేదా 30 GB పరిమాణం గల Q8_0 weightsకు తగినంత స్థలం ఉంటుంది.

CPUపై 27B modelతో సెకనుకు ఎన్ని tokens వస్తాయి?

మీ memory bandwidthను weights పరిమాణంతో భాగించండి. వచ్చిన విలువలో 50 నుంచి 70 శాతం వరకు పరిగణించండి. రెండు-channel DDR4-3200 VPS గరిష్ఠంగా సుమారు 3 tokens per second అందించగలదు. సాధారణంగా ఇది సుమారు 2 tokens per second ఇస్తుంది. రెండు-channel DDR5-4800 server గరిష్ఠంగా సుమారు 4.5 tokens per second అందించగలదు. సాధారణంగా ఇది సుమారు 3 tokens per second ఇస్తుంది. ఎక్కువ channels ఉన్న server platforms కాగితంపై మెరుగ్గా కనిపిస్తాయి. అయితే hostలోని ప్రతి tenant memory bandwidthను పంచుకుంటుంది. అందువల్ల ollama run qwen3.6:27b --verbose తో మీ స్వంత కొలత తీసుకుని eval rate lineను చదవండి.

CPU-only VPSలో Q4 లేదా Q8 ఉపయోగించాలా?

దాదాపు ప్రతి సందర్భంలో Q4_K_M ఉపయోగించండి. Q8_0 పరిమాణం 30 GB, Q4_K_M పరిమాణం 17 GB. అందువల్ల Q8_0 కోసం 64 GB plan అవసరం. ఇది ప్రతి tokenకు దాదాపు రెండింతల memoryని తరలిస్తుంది. ఫలితంగా tokens per second సుమారు సగానికి తగ్గుతుంది. 27B modelలో Q4_K_M మరియు Q8_0 మధ్య quality difference చాలా tasksకు స్వల్పంగా ఉంటుంది. RAMను longer context కోసం ఉపయోగించండి. Context పొడవు model చేయగల పనులను మార్చుతుంది, కానీ అది సమాధానాల phrasingను మాత్రమే మార్చదు.

పెద్ద RAM VPS కంటే GPUను అద్దెకు తీసుకోవడం ఎప్పుడు చౌకగా ఉంటుంది?

మీ duty cycle తక్కువగా ఉన్నప్పుడు లేదా ఒక వ్యక్తి output కోసం వేచి ఉన్నప్పుడు. 24 GB memory గల GPU ఈ weightsపై సుమారు 59 tokens per second అందిస్తుంది. సాధారణ VPSలో ఇది 2 లేదా 3 tokens per second మాత్రమే ఉంటుంది. GPU నడుస్తున్న గంటలకు మాత్రమే billing జరుగుతుంది. 64 GB VPSలో model loadedగా ఉన్నా లేకపోయినా నెలంతా billing జరుగుతుంది. మీరు నిజంగా రోజుకు ఎన్ని గంటలు tokens generate చేస్తారో లెక్కించండి. రోజుకు రెండు లేదా మూడు గంటల కంటే తక్కువైతే hourly GPU rental సాధారణంగా speed మరియు cost రెండింటిలోనూ మెరుగ్గా ఉంటుంది. నిరంతరం తక్కువ ప్రాధాన్యతతో నడిచే batch work కోసం always-on VPS ప్రయోజనకరం.