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 tag-களில் அருகிலானது qwen3.6:27b: 27.8 billion parameters, Q4_K_M quantisation, Apache 2.0 licence. கீழே உள்ள ஒவ்வொரு command-மும் எண்ணும் 27 July 2026 அன்று வெளியிடப்பட்ட Ollama v0.32.5-ல் பயன்படுத்தப்படும் அந்த tag-ஐ அடிப்படையாகக் கொண்டவை.

சுருக்கமான பதில்: 32 GB அல்லது அதற்கு மேற்பட்ட RAM கொண்ட VPS-ல் இயக்கலாம்; ஆனால் வேகம் குறைவாக இருக்கும். Q4 நிலையில் உள்ள 27B dense model-க்கு weights மட்டும் சேமிக்க சுமார் 17 GB RAM தேவைப்படும். இதில் context-ன் ஒரு token கூட சேர்க்கப்படவில்லை. எனவே 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 என நினைவில் வைத்துக்கொள்வது எளிதாக இருக்கலாம். மேலும், முந்தைய release-ல் வெளியிடப்பட்ட அதே Q4_K_M build-க்கு qwen3.5:27b உள்ளது. எந்த command-ஐயும் copy செய்வதற்கு முன், Ollama qwen3.6 tag page-ல் உள்ள live list-ஐச் சரிபார்க்கவும். உண்மையான qwen3.8 பின்னர் வெளியிடப்பட்டாலும், இங்குள்ள கணக்கீடுகள் பொருந்தும். அவை version number-ஐ சார்ந்தவை அல்ல; parameter count மற்றும் ஒவ்வொரு weight-க்குமான bits-ஐ சார்ந்தவை.

எந்த Ollama tag-ஐ pull செய்வது, அதை எவ்வாறு சரிபார்ப்பது

இல்லாத tag-ஐ pull செய்தால் தெளிவான error கிடைக்கும். எனவே இதை அதே server-ல் விரைவாகத் தீர்மானிக்கலாம். உள்ள tag-ஐ pull செய்தாலும், அது local-ஆக இயக்க முடியாததாக இருக்கலாம். library-ல் பட்டியலிடப்பட்டிருந்தாலும் Ollama cloud-ல் மட்டுமே வழங்கப்படும் 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-க்கு அதிக precision கொண்ட qwen3.6:27b-q8_0 மற்றும் qwen3.6:27b-bf16 tags-ஐயும் library கொண்டுள்ளது. மேலும் CPU-ல் முற்றிலும் வேறுபட்ட முறையில் செயல்படும் MoE (mixture of experts) models-க்கான 35b-a3b tags-களும் உள்ளன. அவற்றைப் பற்றி கீழே மேலும் பார்க்கலாம்.

ஒரு weight-க்கான bytes-ஆல் பெருக்கப்படும் parameter எண்ணிக்கை

[
  {
    "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 காரணமாக quality அதிகமாகக் குறையும் tensors 5 அல்லது 6 bits-ல் வைக்கப்படுகின்றன. Token embedding மற்றும் output layers பொதுவாக Q6_K அல்லது Q8_0-ல் வைக்கப்படுகின்றன. Format-ன் பெயர் ஒரு average-ஐ குறிக்கிறது. அந்த average சுமார் 4.9 ஆகிறது. இதே விளைவு scale-ன் மறுபுறத்திலும் உள்ளது: BF16-க்கான 56 GB என்பது ஒரு weight-க்கு 16.1 bits ஆகும்; flat 16 அல்ல. ஏனெனில் 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 ஆகத் தொடங்குகிறது என்பதை காட்டும்.

Context வளரும்போது KV cache-க்கான செலவு

Weights ஒரு நிலையான செலவு. KV cache (key மற்றும் value cache; ஏற்கனவே பார்த்த ஒவ்வொரு token-க்கும் model வைத்திருக்கும் 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-வும் தேவைப்படும். உங்கள் சொந்த machine-ல் இந்தக் கணக்கை அப்படியே பயன்படுத்த வேண்டாம். Model-ஐ load செய்து, ollama ps-ன் SIZE column-ஐப் பார்க்கவும். இது weights, cache மற்றும் overhead ஆகியவற்றின் மொத்த அளவை ஒரே மதிப்பாகக் காட்டும்.

இதனால் model card-ல் குறிப்பிடப்படும் 256K context என்பது ஒரு தலைப்புச் சிறப்பம்சம் மட்டுமே; நடைமுறைத் திட்டம் அல்ல. இதை f16-ல் முழுமையாகப் பயன்படுத்த, weights-க்கு ஏற்கனவே செலவான 17 GB-க்கு மேலாக 64 GB cache தேவைப்படும். Ollama இயல்பாக முழு window-ஐ வழங்காது. அது மிகவும் சிறிய window-ஐ load செய்யும். OLLAMA_CONTEXT_LENGTH மூலம் அதை நீங்கள் திட்டமிட்டு அதிகரிக்கலாம். இந்த server-wide variable மட்டும் ஒரே கட்டுப்பாடு அல்ல. தனிப்பட்ட request-ல் num_ctx அமைத்தல் மூலம், மற்ற எல்லாவற்றுக்கும் குறைந்த செலவுடைய 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 வழங்கக்கூடிய ஒரே நேரத்தில் இணையும் users எண்ணிக்கை 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 நிலையில் பொருந்தக்கூடிய context அளவைக் காட்டும் ஆயிரக்கணக்கான tokens என்ற வகையில் இந்த இரண்டு எண்களையும் படிக்கவும். இவை headless Linux VPS-ல், operating system-க்கு சுமார் 1.5 GB மற்றும் சிறிய கூடுதல் margin ஒதுக்கிய பிறகான அளவுகள். 0 என்பது 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 அளவிலான data எடுக்கப்படும். box-ல் iowait அதிகமாக இருக்கும்; output வேகம் ஒரு second-க்கு ஒரு token-க்கும் குறைவாக இருக்கும்.

32 GB என்பது தொடக்க நிலை. Weights 17 GB எடுத்துக்கொள்ளும். உங்களிடம் சுமார் 13 GB மீதமாக இருக்கும். இது margin உடன் சுமார் 32k tokens அளவிலான f16 context-ஐ கையாளும். 30 GB அளவுள்ள Q8_0 weights, இந்த memory tier-ல் முற்றிலும் பொருந்தாது.

64 GB வசதியான அளவு. Q4 பயன்படுத்தும்போது சுமார் 128k tokens context-க்கு இடம் இருக்கும். Q8_0 weights-ஐ பயன்படுத்தினால், அவற்றுக்கு பின்னால் சுமார் 64k tokens பொருந்தும். Q8 பெறுவதற்காக 64 GB RAM-க்கு பணம் செலுத்தும் முன், நீங்கள் உண்மையில் எதைப் பெறுகிறீர்கள் என்பதைத் தெளிவாகப் புரிந்துகொள்ளவும்: ஏற்கனவே மெதுவாக இருந்த machine-ல், பாதி வேகத்தில் இயங்கும் சற்றே மேம்பட்ட output. பெரும்பாலானவர்களுக்கு நீளமான context உடன் Q4 பயன்படுத்துவது சிறந்த சமநிலை.

VPS-ல் CPU inference எவ்வளவு வேகமாக இருக்கும்?

Dense model-லிருந்து ஒரு token உருவாக்கும்போது, ஒவ்வொரு weight-ஐயும் memory-லிருந்து ஒருமுறை படிக்க வேண்டும். சிலவற்றை மட்டும் அல்ல. அனைத்தையும் படிக்க வேண்டும். ஆகவே வேக வரம்பை நிர்ணயிப்பது உங்கள் core எண்ணிக்கை அல்ல; 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
  }
]

இவை உச்சவரம்புகள்; அளவீடுகள் அல்ல. காட்டப்பட்ட மதிப்பின் சுமார் 50 முதல் 70 சதவீதம் அளவில்தான் உண்மையான output இருக்கும். காரணம், memory latency மற்றும் முழுமையற்ற prefetching காரணமாக theoretical peak-ஐ எட்ட முடியாது. Two-channel DDR4-3200 VPS-ன் உச்சவரம்பு ஒரு வினாடிக்கு 3 tokens. ஆகவே சுமார் 2 tokens எதிர்பார்க்கலாம். Two-channel DDR5-4800 server-ன் உச்சவரம்பு 4.5. ஆகவே சுமார் 3 tokens எதிர்பார்க்கலாம்.

பெரிய server rows-க்கு ஒரு எச்சரிக்கை உள்ளது. Twelve-channel EPYC platform-ல் 460.8 GB/s memory bandwidth மற்றும் ஒரு வினாடிக்கு 27.1 tokens என்ற உச்சவரம்பு உள்ளது. ஆனால் நீங்கள் முழு EPYC server-ஐ rent செய்வதில்லை. அந்த machine-ல் உள்ள அனைத்து tenants-மும் memory bandwidth-ஐ பகிர்ந்து கொள்கின்றனர். ஆகவே 8 vCPU slice-க்கு twelve channels கொண்ட exclusive bandwidth கிடைக்காது. GPU-ஐ மையப்படுத்திய guides இதை முழுமையாகத் தவிர்க்கின்றன. அதனால்தான் ஒரே model-ல், ஒரே vCPU எண்ணிக்கை கொண்ட இரண்டு VPS plans-ன் செயல்திறன் மூன்று மடங்கு வரை மாறுபடலாம்.

அதே காரணத்தால் அதிக vCPUs விரைவாகவே பயனற்றதாகிவிடும். Memory controller வழங்கக்கூடிய வேகத்தைவிட cores அதிக வேகத்தில் data-ஐ கோரத் தொடங்கியதும், கூடுதல் threads scheduling overhead-ஐ மட்டுமே அதிகரிக்கும். OLLAMA_NUM_THREAD-ஐ உங்கள் physical core எண்ணிக்கைக்கு அமைத்து அளவிடுங்கள். பின்னர் அந்த எண்ணிக்கையின் பாதியை முயற்சிக்கவும். பல shared plans-ல் குறைந்த setting வேகமாக இருக்கும்.

Prompt processing வேறுபட்ட முறையில் செயல்படும். முதல் token தோன்றுவதற்கு முன் உங்கள் input முழுவதையும் process செய்யும் கட்டமான prefill, bandwidth bound அல்ல; அது compute bound ஆகும். ஆகவே அது cores-ன் எண்ணிக்கையுடன் scale ஆகும். நடைமுறையில், பெரிய prompt-க்கு output தொடங்குவதற்கு முன் நீண்ட இடைவெளி இருக்கும். அதன் பிறகு மேலே குறிப்பிடப்பட்ட மெதுவான, நிலையான rate கிடைக்கும். ஒவ்வொரு request-க்கும் ஒரு prompt eval rate மற்றும் ஒரு eval rate-ஐ அச்சிடும் --verbose மூலம் இந்த இரண்டு பகுதிகளின் நேரத்தையும் தனித்தனியாக அளவிடுங்கள்.

Dense 27B மிகவும் மெதுவாக இருந்தால், 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 hour வாடகைக்கு எடுப்பது எப்போது சிறந்தது

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

Published GPU memory bandwidth-க்கு இதே formula-ஐப் பயன்படுத்தினால், வேறுபட்ட வகையான முடிவு கிடைக்கும். 24 GB consumer card-க்கு, இந்த weights மீது அதிகபட்சமாக 59 tokens per second கிடைக்கும். தற்போதைய data centre card 197 வரை அடையும். Thread counts-ஐ tune செய்வதால் இந்த இடைவெளியை குறைக்க முடியாது. உங்கள் VPS memory bandwidth-ல் சில பத்து GB/s மட்டுமே கொண்டிருக்கும்போது, அந்த card memory-ஐ 1008 GB/s வேகத்தில் இயக்குகிறது.

எனவே, preference அடிப்படையில் அல்லாமல் workload அடிப்படையில் வரம்பை நிர்ணயிக்கவும். வேலை asynchronous ஆக இருந்து, அதன் output-க்காக யாரும் காத்திருக்கவில்லை என்றால் CPU inference சரியான தேர்வாகும். உதாரணமாக, பல documents-ஐ இரவில் summarise செய்வது அல்லது நீங்கள் தூங்கும்போது nightly classification job இயக்குவது இதற்கு பொருந்தும். ஒருவர் output-க்காக காத்திருக்கும்போது GPU-ஐ rent செய்யவும். Requests ஒவ்வொரு 30 seconds-க்கும் ஒன்றுக்கு மேல் வரும் தருணத்திலும் GPU-ஐ rent செய்யவும். CPU-only box-ல் batching-க்கு போதிய headroom இருக்காது; queue தொடர்ந்து பெரிதாகும்.

Cost comparison தோற்றத்தில் இருப்பதைவிட தெளிவானதல்ல. Model loaded நிலையில் இருந்தாலும் இல்லாவிட்டாலும், 64 GB VPS மாதத்தின் ஒவ்வொரு hour-க்கும் கட்டணம் வசூலிக்கும். GPU instance-க்கு, அதை running நிலையில் வைத்திருக்கும் hours-க்கு மட்டுமே கட்டணம் வசூலிக்கப்படும். உங்கள் உண்மையான usage ஒரு நாளைக்கு இரண்டு hours என்றால், rented GPU வேகமாகவும் குறைந்த செலவாகவும் இருக்கலாம். முதலில் உங்கள் duty cycle-ஐ கணக்கிடுங்கள். பின்னர் அதன் விலையை ஒப்பிடுங்கள். GPU கொண்ட VPS-ஐ தேர்வு செய்தல் instance-ல் சரிபார்க்க வேண்டியவற்றை விளக்குகிறது. GPU-ல் concurrent requests-ஐ serve செய்யும்போது Ollama-வை விட vLLM முன்னிலை பெறுகிறது; காரணம், அது requests-ஐ முறையாக batch செய்கிறது.

மக்கள் மறந்துவிடும் மூன்றாவது option ஒன்றும் உள்ளது. Batch work-க்காக 27B model-ஐ CPU-ல் வைத்திருக்கலாம். Interactive path-க்கு முன்னால் hosted API model-ஐ பயன்படுத்தலாம். ஒரே model இரண்டையும் serve செய்ய வேண்டும் என்ற கட்டாயம் இல்லை.

Ollama-ஐ நிறுவி, உங்கள் server-ஐ அளவிடவும்

நிறுவல் script அதிகாரப்பூர்வமானது. இது தனிப்பட்ட 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 வரியில் உள்ள 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-தான் நீங்கள் எதிர்பார்த்த அளவீட்டை வழங்குகிறது. eval rate என்பது generation நேரத்தில் கிடைக்கும் tokens per second ஆகும். prompt eval rate என்பது prefill speed ஆகும். load duration என்பது weights-ஐ disk-இலிருந்து வாசிக்க எடுத்த நேரமாகும். அதனால் OLLAMA_KEEP_ALIVE=60m அமைக்கப்பட்டுள்ளது. CPU-ல் ஒவ்வொரு request-க்கும் 17 GB-ஐ disk-இலிருந்து மீண்டும் ஏற்றுவது, அந்த request-ஐச் செயல்படுத்துவதைவிட அதிக நேரம் எடுக்கும். இயல்புநிலை idle timeout ஐந்து நிமிடங்கள். Items இடையில் இடைவெளிகள் உள்ள batch queue-ல், இந்த load cost மீண்டும் மீண்டும் ஏற்படும். model-ஐ memory-ல் resident-ஆக வைத்திருப்பதற்கான options ஒவ்வொரு request-க்கான keep_alive field-ஐயும், reboot பிறகும் setting நீடிப்பதையும் கையாள்கின்றன.

Model loaded நிலையில் இருக்கும்போது, இரண்டாவது terminal-இலிருந்து அதன் memory footprint-ஐச் சரிபார்க்கவும்.

ollama ps

SIZE column என்பது KV cache-ஐ உள்ளடக்கிய உண்மையான memory footprint ஆகும். இது weights அளவுக்கும், KV chart-ல் உங்கள் context length-க்கான row-க்கும் நெருக்கமாக இருக்க வேண்டும். 8192 tokens மற்றும் 8-bit cache பயன்படுத்தும்போது, weights-க்கு மேலாக சுமார் ஒரு gigabyte தேவைப்படும். Cache f16 நிலையில் இருந்தால் இந்த மதிப்பு 2 GB ஆக இருக்கும். PROCESSOR column, 100% CPU என்று காட்ட வேண்டும். வேறு ஏதேனும் காட்டினால், ஏதோ ஒன்று GPU-ஐப் பயன்படுத்துகிறது. இந்த வழிகாட்டியில் உள்ள speed அளவீடுகள் உங்கள் server-க்கு பொருந்தாது.

தோல்வி நிலைகள் மற்றும் நீங்கள் காணும் துல்லியமான strings

Model load ஆக மறுக்கிறது. Ollama இரண்டு figures-ஐயும் குறிப்பிடும் ஒரு line-ஐ model requires more system memory (18.6 GiB) than is available (15.2 GiB) என்ற வடிவில் காட்டும். இது நல்ல தோல்வி நிலையாகும். ஏனெனில் kernel முடிவு செய்வதற்காக விட்டுவிடாமல், memory allocate செய்வதற்கு முன்பே Ollama சரிபார்த்துவிட்டது. context length-ஐக் குறைக்கவும், சிறிய tag-க்கு மாறவும், அல்லது அதிக memory கொண்ட plan-ஐத் தேர்ந்தெடுக்கவும்.

Answer நடுவில் process மறைந்து விடுகிறது. Client பயனுள்ள தகவல் எதையும் காட்டாது. journalctl -u ollama -n 50 service restart ஆகிக் கொண்டிருப்பதைக் காட்டும். dmesg -T | tail-ஐ இயக்கவும். Out of memory: Killed process ... (ollama) என்று இருக்கும் line, kernel OOM killer அதை நிறுத்தியதைக் குறிக்கும். Pre-load check வெற்றி பெற்ற பிறகு, நீண்ட conversation-ன் போது cache estimate-ஐ விட அதிகமாக வளரும்போது இது நிகழும். context length-ஐக் குறைக்கவும்.

Pull உடனடியாக தோல்வியடைகிறது. Error: pull model manifest: file does not exist என்பது அந்த tag library-ல் இல்லை என்பதைக் குறிக்கும். qwen3.8:27b என்று type செய்தால் இதே output கிடைக்கும்; version number-ல் ஏதேனும் typo இருந்தாலும் இதே நடக்கும். உங்கள் network-ஐக் குறை கூறுவதற்கு முன் library page-ல் tag-ஐ உறுதிப்படுத்தவும்.

எல்லாம் செயல்படுகிறது, ஆனால் தாங்க முடியாத அளவுக்கு மெதுவாக உள்ளது. போதுமான RAM உள்ள box-ல் ஒரு second-க்கு ஒரு token-க்கும் குறைவான வேகம் இருந்தால், compute பிரச்சினையை விட paging பிரச்சினையாக இருக்கலாம். Generate செய்யும் போது vmstat 1-ஐ இயக்கவும். si அல்லது so column-ல் non-zero value இருந்தால், kernel swapping செய்கிறது. context-ஐக் குறைப்பது அல்லது loaded models-ன் எண்ணிக்கையைக் குறைப்பது இதற்கான தீர்வாகும். Swap activity இல்லாமல் wa தொடர்ந்து அதிகமாக இருந்தால், memory-mapped weights disk-லிருந்து மீண்டும் மீண்டும் read செய்யப்படுகின்றன. அவை உண்மையில் RAM-ல் பொருந்தவில்லை என்பதே இதன் பொருள்.

முதல் token வர 30 seconds ஆகிறது, பின்னர் output வேகமாகிறது. இது prefill ஆகும்; இது இயல்பானது. Cache-ஐப் பயன்படுத்த முடியாத ஒவ்வொரு request-க்கும் நீண்ட system prompt-ஐ மீண்டும் process செய்ய வேண்டியிருக்கும். எனவே வேறு எதையும் tune செய்வதற்கு முன் system prompt-ஐச் சுருக்கவும்.

CPU-only 27B உண்மையில் எதற்குப் பயன்படும்

நம்பிக்கையை அடிப்படையாகக் கொள்ளாமல், இந்த எண்ணிக்கைகளை அடிப்படையாகக் கொண்டு எதிர்பார்ப்புகளை அமைக்கவும். ஒரு வினாடிக்கு 2 முதல் 4 tokens என்ற வேகத்தில், 500 tokens கொண்ட பதில் உருவாக 2 முதல் 4 நிமிடங்கள் ஆகும். Chat பயன்பாட்டுக்கு இது பயன்படுத்த முடியாத அளவு மெதுவாகும்; ஆனால் queue-க்கு இது முற்றிலும் ஏற்றது. பதிலளிப்பதற்கு முன் சிந்திக்கும் model ஒன்று பதிலளிப்பு நேரத்தை மேலும் அதிகரிக்கும். ஏனெனில் hidden reasoning tokens-உம் பதிலின் tokens உருவாகும் அதே மெதுவான வேகத்திலேயே உருவாகின்றன. எனவே வேலையின் தன்மைக்கு ஏற்ப reasoning effort level-ஐ பொருத்துவது model-ஐ மாற்றாமல் பதிலின் நேரத்தைக் குறைக்கும் சில வழிகளில் ஒன்றாகும். Document summarisation, bulk tagging, files-ன் தொகுப்பிலிருந்து field extraction, மற்றும் unattended code review ஆகியவை இந்த வேகத்தை ஏற்றுக்கொள்ளும். ஏனெனில் பதிலுக்காக யாரும் காத்திருக்கவில்லை. Coding assistance இந்த வரம்பின் சரியான விளிம்பில் உள்ளது. எனவே நீங்கள் host செய்யும் model-க்கு coding agent-ஐ இணைப்பது commit messages மற்றும் test scaffolding போன்ற background jobs-க்கு பயனுள்ளதாக இருக்கும்; நீங்கள் அமர்ந்து காத்திருக்கும் inline suggestions-க்கு அல்ல.

Privacy பற்றிய காரணமே உண்மையான காரணம். Model, நீங்கள் rent செய்து கட்டுப்படுத்தும் hardware-ல் இயங்கும். எந்த request-உம் அந்த machine-ஐ விட்டு வெளியேறாது. மேலும், ஒவ்வொரு token-க்கும் தனிக் கட்டணம் இல்லை. ஒரு வினாடிக்கு 3 tokens மட்டுமே கிடைத்தாலும், regulated data-க்கு இது அதிக மதிப்புடையது. இதை மாற்று வழியுடன் நேர்மையாக ஒப்பிடவும்: frontier-scale model-ஐ self-host செய்ய ஒரு order of magnitude அதிக hardware தேவைப்படும். அந்த அளவீட்டில், output இன்னும் படிக்கத் தகுந்ததாக இருக்கும் குறைந்த செலவுடைய நிலை CPU-ல் இயங்கும் 27B model ஆகும்.

இதுபோன்ற எதையும் benchmark செய்ய, உண்மையான structured input தேவை. பெரும்பாலான public data APIs throughput-ஐ அளவிடுவதற்கே account தேவைப்படுகின்றன. Strasmore-ன் demo endpoint (அதை நாங்களே இயக்குகிறோம்), key அல்லது signup எதுவும் இல்லாமல் 22 ஆண்டுகளுக்கான US market data மீது read-only SQL queries-க்கு பதிலளிக்கிறது. https://ai.strasmore.com/api/demo/sql?sql=SELECT ticker, close FROM delayed_stocks_minute_aggs LIMIT 5-க்கு GET request அனுப்பினால் JSON கிடைக்கும். அதை நேரடியாக prompt loop-க்கு pipe செய்யலாம். அந்த JSON-உடன் அதை உருவாக்கிய exact SQL-உம் கிடைக்கும். இதனால் model summarise செய்யக்கூடிய, நீங்கள் தனியாகச் சரிபார்க்கக்கூடிய input கிடைக்கிறது. ஒவ்வொரு call-க்கும் வரம்புகள் 500 rows மற்றும் 20 seconds ஆகும். ஒரு வினாடிக்கு 2 tokens உருவாக்கும் machine பயன்படுத்தும் அளவைவிட இது போதுமான அளவு அதிகமாகும். முழுமையான column list https://api.strasmore.com/v1/schema-ல் உள்ளது.

இது உங்கள் முதல் 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 model தேவைப்பட்டால் qwen3.6:27b-ஐ pull செய்யவும். இல்லாத tag-ஐ பயன்படுத்தினால் Error: pull model manifest: file does not exist காரணமாக command தோல்வியடையும்.

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 முழுவதையும் memory-ல் வைத்திருக்க முடியாது. File memory-mapped ஆக இருப்பதால் swap உதவாது. ஒவ்வொரு token-க்கும் kernel அதை disk-லிருந்து மீண்டும் படிக்கும். 64 GB plan-ல் நீண்ட context அல்லது 30 GB அளவுள்ள Q8_0 weights-க்கு போதிய இடம் இருக்கும்.

CPU-ல் 27B model விநாடிக்கு எத்தனை tokens வழங்கும்?

உங்கள் memory bandwidth-ஐ weights அளவால் வகுக்கவும். அதன் 50 முதல் 70 சதவீதத்தை எடுத்துக்கொள்ளவும். Two-channel DDR4-3200 VPS-ன் உச்சவரம்பு விநாடிக்கு சுமார் 3 tokens ஆகும்; நடைமுறையில் சுமார் 2 tokens வழங்கும். Two-channel DDR5-4800 machine-ன் உச்சவரம்பு சுமார் 4.5 ஆகும்; நடைமுறையில் சுமார் 3 tokens வழங்கும். அதிக channels கொண்ட server platforms, கணக்கீட்டில் சிறப்பாகத் தோன்றும். ஆனால் host-ல் உள்ள அனைத்து tenants-க்கும் memory bandwidth பகிரப்படும். எனவே ollama run qwen3.6:27b --verbose மூலம் உங்கள் system-ஐ அளந்து, 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-ல் பெரும்பாலான tasks-க்கு Q4_K_M மற்றும் Q8_0 இடையிலான quality difference குறைவு. RAM-ஐ நீண்ட context-க்கு பயன்படுத்துவது சிறந்தது. அது model செய்யக்கூடிய செயல்களை மாற்றும்; பதில்களை எழுதும் பாணியை மட்டும் மாற்றாது.

பெரிய RAM VPS-ஐவிட GPU வாடகை எப்போது மலிவாகும்?

உங்கள் duty cycle குறைவாக இருக்கும்போது அல்லது ஒருவர் முடிவுக்காகக் காத்திருக்கும்போது GPU வாடகை மலிவாகும். 24 GB memory கொண்ட GPU, இந்த weights-ல் விநாடிக்கு சுமார் 59 tokens வழங்கும். Typical VPS-ல் இது 2 அல்லது 3 tokens மட்டுமே. GPU இயங்கும் மணிநேரங்களுக்கு மட்டும் கட்டணம் வசூலிக்கப்படும். 64 GB VPS-க்கு model loaded ஆக இருந்தாலும் இல்லாவிட்டாலும் முழு மாதத்திற்கும் கட்டணம் செலுத்த வேண்டும். உண்மையில் ஒரு நாளில் எத்தனை மணி நேரம் tokens generate செய்கிறீர்கள் என்பதை கணக்கிடவும். இரண்டு அல்லது மூன்று மணிநேரத்திற்குக் குறைவாக இருந்தால், hourly GPU rental பொதுவாக speed மற்றும் cost இரண்டிலும் சிறந்தது. தொடர்ந்து இயங்க வேண்டிய low-priority batch work-க்கு always-on VPS சிறந்தது.