Ollamaలో Qwen 3.8 27Bను VPSలో ఎలా నడపాలి?

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

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

సంక్షిప్త సమాధానం: 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 మరియు ప్రతి weightకు ఉపయోగించే bitsపై ఆధారపడతాయి.

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

లేని tag ను pull చేస్తే స్పష్టమైన error వస్తుంది. అందువల్ల ఈ విషయాన్ని అదే సర్వర్‌లో త్వరగా నిర్ధారించవచ్చు.

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 కోసం అధిక precision కలిగిన qwen3.6:27b-q8_0 మరియు qwen3.6:27b-bf16 tags కూడా libraryలో ఉన్నాయి. అదనంగా 35b-a3b tags సమూహం ఉంది. ఇవి MoE (mixture of experts) models, CPUపై చాలా భిన్నంగా పనిచేస్తాయి. వీటి గురించి దిగువన మరింత వివరించాం.

బరువుకు బిట్లతో పరామితుల సంఖ్యను గుణించడం

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

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

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

ఈ model కోసం Q5_K_M కు ప్రచురిత tag లేదు. అందువల్ల 19.8 GB row ను కొలిచిన విలువగా కాకుండా, ఆ format కు సాధారణమైన ఒక్కో బరువుకు 5.7 bits ఆధారంగా లెక్కించారు. Q8_0, Q4 పరిమాణాన్ని దాదాపు రెట్టింపు చేసి 30 GBకు చేరుతుంది. CPU-only box లో ఈ రెట్టింపు ప్రతి token కు memory traffic ను కూడా రెండింతలు చేస్తుంది. అందువల్ల tokens per second కూడా సుమారు సగానికి తగ్గుతుంది. ఈ కారణం ఒక్కటే ఉన్నా ఇక్కడ Q4_K_M సరైన default.

కాంటెక్స్ట్ పెరిగే కొద్దీ KV cache వ్యయం

Weights స్థిరమైన వ్యయం. KV cache (key మరియు value cache; మోడల్ ఇప్పటికే చూసిన ప్రతి token కోసం ఉంచుకునే attention state) కాంటెక్స్ట్ పొడవుతో నేరుగా పెరుగుతుంది. వాస్తవంగా ఎక్కువ మంది 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 అవసరం. మీ స్వంత యంత్రంపై ఇదే లెక్క వర్తిస్తుందని అనుకోకండి. Model ను load చేసి, ollama ps లోని SIZE column ను చూడండి. అది weights, cache, overhead అన్నింటినీ కలిపిన మొత్తం పరిమాణాన్ని చూపిస్తుంది.

అందుకే model card లోని 256K context ఒక ప్రధాన సంఖ్య మాత్రమే, ఆచరణాత్మక ప్రణాళిక కాదు. f16 వద్ద దాన్ని పూర్తిగా నింపాలంటే weights కోసం ఇప్పటికే 17 GB ఖర్చు చేసిన యంత్రంలో, అదనంగా 64 GB cache అవసరం. Ollama default గా పూర్తి window ను అందించదు. అది చాలా చిన్న window ను load చేస్తుంది. OLLAMA_CONTEXT_LENGTH తో మీరు దాన్ని ఉద్దేశపూర్వకంగా పెంచాలి. దాన్ని దశలవారీగా పెంచి, ప్రతి మార్పు తర్వాత 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 ను కూడా set చేసి, అది అమలైందని ఊహించకుండా ollama ps లో తగ్గుదలని నిర్ధారించండి. OLLAMA_NUM_PARALLEL=1 కూడా అంతే ముఖ్యమైనది. Ollama ఒకేసారి అనేక requests ను serve చేయగలదు. ప్రతి slot కు దాని స్వంత context భాగం ఉంటుంది. అందువల్ల parallelism ను default వద్ద వదిలేస్తే, మీరు అంచనా వేసిన cache అవసరం గుర్తించకుండా అనేక రెట్లు పెరుగుతుంది. ఈ యంత్రాన్ని ఒకరి కంటే ఎక్కువ మంది ఉపయోగిస్తే, సమస్య అక్కడే ప్రారంభమవుతుంది. 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 తో పాటు, f16 cache వద్ద, headless Linux VPSలో సరిపోయే context వేల tokens గా చదవాలి. ఆ 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 వాటిని తొలగించి మళ్లీ చదవడం ప్రారంభిస్తుంది. అప్పుడు ప్రతి token కోసం disk నుంచి gigabytes చదవాల్సి వస్తుంది. ఫలితంగా boxలో iowait అధికంగా ఉంటుంది. వేగం ప్రతి సెకనుకు ఒక token కంటే చాలా తక్కువగా ఉంటుంది.

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

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

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 కారణంగా theoretical peak ను చేరుకోలేరు. అందువల్ల వాస్తవ output సాధారణంగా చూపిన విలువలో 50 నుంచి 70 శాతం ఉంటుంది. Two-channel DDR4-3200 VPS యొక్క ceiling సెకనుకు 3 tokens. కాబట్టి సుమారు 2 tokens ఆశించండి. Two-channel DDR5-4800 server యొక్క ceiling 4.5. కాబట్టి సుమారు 3 tokens ఆశించండి.

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

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

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

Dense 27B model చాలా నెమ్మదిగా ఉంటే, CPUని వదిలేయకముందు qwen3.6:35b-a3b tags ను పరిశీలించండి. అవి మొత్తం 27.8 billion parameters బదులుగా ప్రతి token కు సుమారు 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 ను tune చేయడం ద్వారా ఈ అంతరాన్ని పూడ్చలేరు. Data centre card memory 1008 GB/s వేగంతో పనిచేస్తుంది, అయితే మీ VPS వేగం tens GB/s స్థాయిలో ఉంటుంది.

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

ఖర్చు పోలిక కనిపించినంత సులభంగా ఉండదు. Model loaded అయి ఉన్నా లేకపోయినా 64 GB VPS నెలలోని ప్రతి గంటకు billing చేస్తుంది. GPU instance ను మీరు నడిపే గంటలకు మాత్రమే billing చేస్తుంది. మీ వాస్తవ వినియోగం రోజుకు రెండు గంటలు అయితే rented GPU వేగంగా ఉండటమే కాకుండా చౌకగా కూడా ఉండవచ్చు. ముందుగా మీ duty cycle ను లెక్కించండి. తరువాత ధరను పోల్చండి. GPU కలిగిన VPS ను ఎంచుకోవడం instance లోనే ఏమి పరిశీలించాలో వివరిస్తుంది. GPU పై concurrent requests ను serve చేసినప్పుడు vLLM concurrent requests ను serve చేసిన తర్వాత Ollama కంటే ముందంజలో ఉంటుంది, ఎందుకంటే అది వాటిని సరిగ్గా 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 లేదా తదుపరి వెర్షన్‌ను చూపాలి. ఏదైనా డౌన్‌లోడ్ చేయడానికి ముందు free -g ను తనిఖీ చేయండి. Mem లైన్‌లోని total column విలువ 32 కంటే తక్కువగా ఉంటే ఇక్కడే ఆపండి. చిన్న modelను ఎంచుకోండి. మీరు అమలు చేయలేని 17 GB modelను download చేయడం వల్ల ఒక గంట సమయం మరియు ఎక్కువ 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 weightsను మళ్లీ load చేయడం, ఆ requestను అమలు చేయడం కంటే ఎక్కువ సమయం తీసుకుంటుంది.

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

ollama ps

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

వైఫల్య పరిస్థితులు మరియు మీరు ఖచ్చితంగా చూసే 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 మళ్లీ restart అవుతున్నట్లు చూపిస్తుంది. dmesg -T | tail అమలు చేయండి. అందులో Out of memory: Killed process ... (ollama) ఉన్న line కనిపిస్తే kernel OOM killer process ను terminate చేసిందని అర్థం. Pre-load check విజయవంతమైనా, దీర్ఘమైన 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 ఉన్న system లో ప్రతి second కు ఒక token కంటే తక్కువ వేగం ఉంటే, అది compute సమస్యకన్నా paging ను సూచిస్తుంది. Generate చేస్తున్నప్పుడు vmstat 1 అమలు చేయండి. si లేదా so column లో non-zero విలువ ఉంటే kernel swapping చేస్తోందని అర్థం. Context తగ్గించడం లేదా loaded models సంఖ్యను తగ్గించడం పరిష్కారం. Swap activity లేకుండా wa నిరంతరం ఎక్కువగా ఉంటే, memory-mapped weights ను disk నుంచి మళ్లీ చదువుతున్నారని అర్థం. అంటే అవి వాస్తవంగా memory లో సరిపోవడం లేదు.

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

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

సంఖ్యల ఆధారంగా అంచనాలను నిర్ణయించండి; ఆశల ఆధారంగా కాదు. సెకనుకు రెండు నుంచి నాలుగు tokens వేగంతో, 500 tokens ఉన్న సమాధానానికి రెండు నుంచి నాలుగు నిమిషాలు పడుతుంది. ఇది chat కోసం ఉపయోగించలేనంత నెమ్మదిగా ఉంటుంది, కానీ queue కోసం పూర్తిగా అనుకూలంగా ఉంటుంది. Document summarisation, bulk tagging, ఫైళ్ల backlog నుంచి field extraction, unattended code review వంటి పనులు ఈ వేగాన్ని తట్టుకుంటాయి, ఎందుకంటే సమాధానం కోసం ఎవరూ వేచి ఉండరు. Coding assistance ఈ సరిహద్దులోనే ఉంటుంది. అందువల్ల మీరు host చేసే మోడల్‌కు coding agent‌ను అనుసంధానించడం commit messages, test scaffolding వంటి background jobs‌కు ప్రయోజనకరం. మీరు వెంటనే చూసే inline suggestions కోసం మాత్రం ఇది అనుకూలం కాదు.

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

ఇది మీ మొదటి Ollama install అయితే, VPSపై Ollama నడిపే పూర్తి విధానం service setup, HTTP API, అలాగే ఈ guideలో మీరు ఇప్పటికే అమలు చేసి ఉన్నారని భావించే 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లో ప్రతి 4000 context tokensకు KV cache సుమారు 1 GB అదనంగా తీసుకుంటుంది. 16 GB planలో weights పూర్తిగా సరిపోవు. File memory-mapped కావడం వల్ల swap సహాయం చేయదు. ప్రతి token సమయంలో kernel దాన్ని disk నుంచి మళ్లీ చదవాల్సి వస్తుంది. 64 GB ఉంటే long context కోసం లేదా 30 GB పరిమాణం కలిగిన Q8_0 weights కోసం తగిన స్థలం ఉంటుంది.

CPUపై 27B model సెకనుకు ఎన్ని tokens ఇస్తుంది?

మీ memory bandwidthను weights పరిమాణంతో భాగించండి. వచ్చిన విలువలో 50 నుంచి 70 శాతం వరకు వాస్తవ వేగంగా పరిగణించండి. Two-channel DDR4-3200 VPS ceiling సుమారు 3 tokens per second ఉంటుంది. వాస్తవ వేగం సుమారు 2 tokens per second ఉంటుంది. Two-channel DDR5-4800 server ceiling సుమారు 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 తేడా చాలా tasksలో తక్కువగా ఉంటుంది. RAMను longer context కోసం వినియోగించండి. అది model ఎలా పదాలను రూపొందిస్తుందన్నదికన్నా model చేయగల పనుల పరిధిని ఎక్కువగా మారుస్తుంది.

పెద్ద 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 load అయి ఉన్నా లేకపోయినా నెలంతా billing జరుగుతుంది. మీరు రోజుకు నిజంగా ఎన్ని గంటలు tokens generate చేస్తారో లెక్కించండి. రెండు లేదా మూడు గంటల కంటే తక్కువ వినియోగం ఉంటే hourly GPU rental సాధారణంగా వేగం మరియు ఖర్చు రెండింటిలోనూ మెరుగ్గా ఉంటుంది. నిరంతరం తక్కువ ప్రాధాన్యతతో batch work నడిపే సందర్భంలో always-on VPS చౌకగా ఉంటుంది.