Ollama-வில் Qwen 27B மாடலை VPS-ல் இயக்குவது எப்படி?

GPU இல்லாத VPS-ல் Qwen 3.8 27B-ஐ இயக்க முடியுமா?

VPS-ல் Qwen 3.8 27B-ஐ இயக்க, முதலில் சரியான model tag தேவை. ஆகஸ்ட் 4, 2026 நிலவரப்படி, Ollama library-ல் qwen3.8 என்ற பதிவே இல்லை. தற்போது வெளியிடப்பட்டுள்ள மிக நெருக்கமான 27B tag qwen3.6:27b ஆகும்: இது 27.8 பில்லியன் parameters, Q4_K_M quantisation மற்றும் Apache 2.0 உரிமம் கொண்டது. கீழே உள்ள அனைத்து கட்டளைகளும் எண்களும் ஜூலை 27, 2026 அன்று வெளியிடப்பட்ட Ollama v0.32.5-ல் அந்த tag-ஐப் பயன்படுத்துகின்றன.

சுருக்கமான பதில்: 32 GB அல்லது அதற்கு மேற்பட்ட RAM கொண்ட VPS-ல் இதை இயக்க முடியும், ஆனால் வேகம் குறைவாக இருக்கும். Q4 நிலையில் உள்ள ஒரு 27B dense model, context-ஐச் சேமிப்பதற்கு முன்பே, weights-க்காக மட்டும் சுமார் 17 GB RAM தேவைப்படும். இதனால் 8 GB மற்றும் 16 GB திட்டங்கள் முற்றிலும் பொருந்தாது. பொதுவான two-channel DDR4 VPS-ல் இதன் வேகம் தோராயமாக 3 tokens per second ஆக இருக்கும், இது பெரும்பாலானோர் வாசிக்கும் வேகத்தை விடக் குறைவானது.

3.8 என்பது எங்கிருந்து வந்தது? இது பெரும்பாலும் parameter எண்ணிக்கையைக் குறிப்பதாக இருக்கலாம். qwen3.6:27b-க்கான Ollama பக்கத்தில் 27.8B parameters என்று குறிப்பிடப்பட்டுள்ளது, 27.8 என்பதைப் பிற்காலத்தில் 3.8 என்று நினைவில் கொள்வது எளிது. மேலும், முந்தைய வெளியீட்டின் அதே Q4_K_M build-ஐக் கொண்ட qwen3.5:27b ஒன்றும் உள்ளது. எந்தவொரு கட்டளையையும் நகலெடுக்கும் முன், Ollama qwen3.6 tag பக்கத்தில் நேரடிப் பட்டியலைச் சரிபார்க்கவும். பிற்காலத்தில் உண்மையான qwen3.8 வெளியானாலும், இங்குள்ள கணக்கீடுகள் அப்படியே பொருந்தும், ஏனெனில் இது version எண்ணை விட parameter எண்ணிக்கை மற்றும் bits per weight ஆகியவற்றையே சார்ந்துள்ளது.

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

இல்லாத ஒரு tag-ஐ pull செய்ய முயன்றால், அது தெளிவான பிழையைக் காட்டும். எனவே, server-லேயே இதை விரைவாக உறுதிப்படுத்திக்கொள்ளலாம்.

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 எண்ணிக்கை, context length மற்றும் quantisation ஆகியவற்றை அச்சிடும். parameter வரிசையில் 27.8B என்றும், quantisation வரிசையில் Q4_K_M என்றும் இருந்தால், இந்த வழிகாட்டியில் பயன்படுத்தப்பட்டுள்ள அதே build உங்களிடம் உள்ளது என்று அர்த்தம். அதே weights-ஐ அதிக precision-ல் பெற, library-ல் qwen3.6:27b-q8_0 மற்றும் qwen3.6:27b-bf16 ஆகியவையும் உள்ளன. மேலும், 35b-a3b tags தொகுப்பில் MoE (mixture of experts) மாதிரிகள் உள்ளன; இவை 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 பிட்களில், 27.8 பில்லியன் அளவுருக்கள் 13.9 GB ஆக இருக்கும். வெளியிடப்பட்ட Q4_K_M tag 17 GB ஆகும், இது நடைமுறையில் ஒரு எடைக்கு 4.89 பிட்கள் என கணக்கிடப்படுகிறது.

இந்த இடைவெளி ஒரு பிழை அல்ல. K-quant வடிவங்கள் ஒவ்வொரு tensor-ஐயும் அதன் பெயரளவு அகலத்தில் சேமிப்பதில்லை. சுருக்கத்தின் போது அதிக தரத்தை இழக்கும் tensor-கள் 5 அல்லது 6 பிட்களில் வைக்கப்படுகின்றன, மேலும் token embedding மற்றும் output layers வழக்கமாக Q6_K அல்லது Q8_0 நிலையில் விடப்படுகின்றன. இந்த வடிவத்தின் பெயர் ஒரு சராசரியைக் குறிக்கிறது, அந்த சராசரி 4.9-க்கு அருகில் அமைகிறது. இதே விளைவு அளவுகோலின் மறுமுனையிலும் காணப்படுகிறது: BF16-க்கான 56 GB என்பது 16 பிட்கள் என்பதற்குப் பதிலாக ஒரு எடைக்கு 16.1 பிட்கள் ஆகும், ஏனெனில் அந்த கோப்பில் metadata மற்றும் முழு-துல்லியமான (full-precision) embedding table ஆகியவையும் உள்ளன.

இந்த மாதிரிக்கு Q5_K_M-க்கான tag வெளியிடப்படவில்லை, எனவே 19.8 GB வரிசையானது, அளவிடப்படுவதற்குப் பதிலாக அந்த வடிவத்திற்கான வழக்கமான 5.7 பிட்கள் ஒரு எடைக்கு என்ற அடிப்படையில் கணக்கிடப்படுகிறது. Q8_0, Q4-ஐ விட இருமடங்காகி 30 GB ஆகிறது. CPU-மட்டும் கொண்ட கணினியில், அந்த இருமடங்கு அதிகரிப்பு ஒரு token-க்கு இருமடங்கு memory traffic-ஐ உருவாக்குகிறது, எனவே இது உங்கள் tokens per second வேகத்தை தோராயமாக பாதியாகக் குறைக்கிறது. இந்த காரணத்திற்காகவே Q4_K_M இங்கு சரியான default தேர்வாக உள்ளது.

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

Weights என்பது நிலையான செலவாகும். KV cache (key and value cache, இது மாடல் ஏற்கனவே பார்த்த ஒவ்வொரு token-க்கும் பராமரிக்கும் attention state ஆகும்) context நீளத்திற்கு ஏற்ப நேர்க்கோட்டில் வளரும். பெரும்பாலான பயனர்களுக்கு 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 மாடல்களில் பயன்படுத்தும் கட்டமைப்பை அடிப்படையாகக் கொண்டவை: 64 layers, GQA (grouped-query attention)-ன் கீழ் 8 key/value heads, மற்றும் 128 head dimension. இது f16-ல் ஒரு token-க்கு 256 KiB ஆகும். எனவே, 32k tokens-க்கு 8 GB மற்றும் 128k tokens-க்கு 32 GB தேவைப்படும். எனது கணக்கீட்டை மட்டும் நம்பாமல், உங்கள் கணினியில் சரிபார்க்கவும். மாடலை load செய்து, ollama ps-ன் SIZE column-ஐப் பார்க்கவும்; இது weights, cache மற்றும் overhead ஆகியவற்றை உள்ளடக்கிய மொத்த அளவைக் காட்டும்.

இதனால்தான் மாடல் கார்டில் உள்ள 256K context என்பது ஒரு விளம்பரமே தவிர, நடைமுறைத் திட்டம் அல்ல. f16-ல் இதை நிரப்பினால், ஏற்கனவே 17 GB weights-க்கு செலவழித்த பிறகு, கூடுதலாக 64 GB cache தேவைப்படும். Ollama இயல்பாகவே முழு window-வையும் உங்களுக்குத் தராது. அது மிகச் சிறிய அளவையே load செய்யும், நீங்கள் OLLAMA_CONTEXT_LENGTH மூலம் அதைத் திட்டமிட்டு அதிகரிக்க வேண்டும். படிப்படியாக உயர்த்தி, ஒவ்வொரு மாற்றத்திற்குப் பிறகும் ollama ps-ஐச் சரிபார்க்கவும்.

இரண்டு அமைப்புகள் cache-ன் அளவை பாதியாகவோ அல்லது அதற்கும் மேலோ குறைக்கின்றன. OLLAMA_KV_CACHE_TYPE=q8_0, cache-ஐ 16-bit-க்கு பதிலாக 8-bit-ல் சேமிக்கிறது. இது 32k tokens-க்கான தேவையை 8 GB-லிருந்து 4 GB-ஆகக் குறைக்கும். இதற்கு flash attention தேவை, எனவே OLLAMA_FLASH_ATTENTION=1-ஐயும் set செய்யவும். இது சரியாகச் செயல்படுகிறதா என்பதை உறுதிப்படுத்த ollama ps-ஐச் சரிபார்க்கவும். OLLAMA_NUM_PARALLEL=1-ம் மிக முக்கியமானது. Ollama ஒரே நேரத்தில் பல கோரிக்கைகளை (requests) கையாள முடியும். ஒவ்வொரு slot-க்கும் தனித்தனி context தேவைப்படும். எனவே, parallelism-ஐ இயல்பு நிலையில் (default) அப்படியே விட்டால், நீங்கள் கணக்கிட்ட cache அளவு பல மடங்காகும். ஒன்றுக்கும் மேற்பட்ட பயனர்கள் இந்த server-ஐப் பயன்படுத்தினால், இந்த அதிகரிப்பே சிக்கலைத் தொடங்கும். ஒரு self-hosted மாடல் கையாளக்கூடிய ஒரேநேரப் பயனர்களின் எண்ணிக்கை, 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-ல், இயங்குதளத்திற்கு (operating system) சுமார் 1.5 GB மற்றும் ஒரு சிறிய கூடுதல் இடைவெளி ஒதுக்கப்பட்ட, headless Linux VPS-ல் கணக்கிடப்பட்டுள்ளன. பூஜ்ஜியம் (0) என்பது weights-களே பொருந்தாது என்பதைக் குறிக்கிறது, எனவே எதுவும் இயங்காது.

8 GB மற்றும் 16 GB என்பது மிக நெருக்கமான அளவுகள் அல்ல. 17 GB அளவுள்ள weights, 16 GB RAM-ல் பொருந்தாது; context அமைப்புகளை மாற்றினாலும் இது மாறாது. Swap சேர்ப்பதும் இதற்குத் தீர்வாகாது. Ollama, GGUF கோப்பை memory-map செய்கிறது; எனவே resident pages RAM-ஐத் தாண்டும்போது, kernel அவற்றை நீக்கிவிட்டு மீண்டும் படிக்கத் தொடங்கும். அப்போது ஒவ்வொரு token-க்கும் gigabytes அளவிலான தரவு disk-லிருந்து எடுக்கப்படும். இதனால் கணினியில் high iowait ஏற்பட்டு, ஒரு வினாடிக்கு ஒரு token-க்கும் குறைவான வேகத்திலேயே output கிடைக்கும்.

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

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

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

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

இவை வெறும் உச்சவரம்புகள் (ceilings) மட்டுமே, அளவீடுகள் அல்ல. நினைவகத்தின் தாமதம் (latency) மற்றும் முழுமையற்ற prefetching காரணமாக, கோட்பாட்டு ரீதியான உச்சத்தை உங்களால் ஒருபோதும் எட்ட முடியாது என்பதால், உண்மையான வெளியீடு காட்டப்பட்டுள்ள மதிப்பில் சுமார் 50 முதல் 70 சதவீதம் மட்டுமே இருக்கும். ஒரு two-channel DDR4-3200 VPS-ன் உச்சவரம்பு 3 tokens per second ஆகும், எனவே சுமார் 2 tokens-ஐ எதிர்பார்க்கலாம். ஒரு two-channel DDR5-4800 வசதி கொண்ட பெட்டியின் உச்சவரம்பு 4.5 ஆகும், எனவே சுமார் 3 tokens-ஐ எதிர்பார்க்கலாம்.

பெரிய server-களைப் பயன்படுத்தும்போது எச்சரிக்கை தேவை. பன்னிரண்டு-channel (twelve-channel) EPYC தளம் 460.8 GB/s அலைவரிசையையும், 27.1 tokens per second உச்சவரம்பையும் கொண்டுள்ளது. ஆனால், நீங்கள் முழு EPYC-ஐயும் வாடகைக்கு எடுப்பதில்லை. நினைவக அலைவரிசை என்பது அந்த machine-ல் உள்ள அனைத்து வாடிக்கையாளர்களும் பகிர்ந்து கொள்ளும் ஒரு பொதுவான வளமாகும். எனவே, 8 vCPU கொண்ட ஒரு slice-க்கு பன்னிரண்டு channel-களின் பிரத்யேக அலைவரிசை கிடைக்காது. GPU-ஐ மையமாகக் கொண்ட வழிகாட்டிகள் இதை முழுமையாகத் தவிர்த்துவிடுகின்றன. ஒரே மாதிரியான vCPU எண்ணிக்கை கொண்ட இரண்டு VPS திட்டங்கள், ஒரே மாதிரியான model-ல் மூன்று மடங்கு வரை வேக வேறுபாட்டைக் காட்டுவதற்கு இதுவே காரணம்.

அதிக vCPU-களைப் பயன்படுத்துவது இதே காரணத்திற்காக விரைவில் பலனளிக்காமல் போகிறது. நினைவகக் கட்டுப்படுத்தி (memory controller) தரவை வழங்கும் வேகத்தை விட, core-கள் தரவைக் கோரும் வேகம் அதிகரிக்கும்போது, கூடுதல் threads-கள் scheduling சுமையை மட்டுமே அதிகரிக்கும், வேறு எந்தப் பயனும் இருக்காது. OLLAMA_NUM_THREAD-ஐ உங்கள் physical core-களின் எண்ணிக்கைக்கு அமைத்து அளவிடுங்கள், பிறகு அந்த எண்ணிக்கையில் பாதியை அமைத்துச் சோதியுங்கள். பல shared திட்டங்களில், குறைந்த அமைப்பே வேகமானது.

Prompt processing இதிலிருந்து மாறுபட்டுச் செயல்படும். முதல் token தோன்றுவதற்கு முன்பு உள்ளீட்டைச் செயலாக்கும் Prefill, அலைவரிசையை விட கணக்கீட்டுத் திறனை (compute) சார்ந்திருக்கும், எனவே இது core-களின் எண்ணிக்கைக்கு ஏற்ப அதிகரிக்கும். இதன் நடைமுறை விளைவு என்னவென்றால், பெரிய prompt-களுக்கு வெளியீடு தொடங்குவதற்கு முன் நீண்ட இடைவெளி இருக்கும், அதைத் தொடர்ந்து மேலே குறிப்பிட்ட மெதுவான, நிலையான வேகம் இருக்கும். --verbose மூலம் இந்த இரண்டு பகுதிகளையும் தனித்தனியாகக் கணக்கிடுங்கள்; இது ஒவ்வொரு கோரிக்கைக்கும் ஒரு prompt eval rate மற்றும் eval rate-ஐ அச்சிடும்.

dense 27B model மிகவும் மெதுவாக இருந்தால், CPU-ஐக் கைவிடுவதற்கு முன் qwen3.6:35b-a3b tags-ஐப் பாருங்கள். இவை 27.8 பில்லியன் parameters-க்கு பதிலாக, ஒரு token-க்கு சுமார் 3 பில்லியன் parameters-ஐ மட்டுமே செயல்படுத்துகின்றன. இதனால், disk-ல் உள்ள கோப்பின் அளவு பெரியதாக இருந்தாலும், ஒரு token-க்கான நினைவகப் போக்குவரத்து கணிசமாகக் குறைகிறது. நீங்கள் RAM பயன்பாட்டைக் கொடுத்து வேகத்தைப் பெறுகிறீர்கள். இதில் runtime தேர்வு முக்கியமானது; Ollama மற்றும் llama.cpp ஆகியவை ஒரே அடிப்படை inference code-க்கு வெவ்வேறு CPU tuning கட்டுப்பாடுகளை வழங்குகின்றன.

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 per second என்ற உச்சவரம்பு உள்ளது. தற்போதைய data centre card 197 என்ற அளவை எட்டுகிறது. thread counts-ஐ மாற்றுவதன் மூலம் இந்த இடைவெளியை ஈடுகட்ட முடியாது. உங்கள் VPS சில பத்துகளில் இயங்கும்போது, இந்த card அதன் memory-ஐ 1008 GB/s வேகத்தில் இயக்குகிறது.

எனவே, விருப்பத்தின் அடிப்படையில் அல்லாமல், பணிச்சுமையின் (workload) அடிப்படையில் முடிவெடுங்கள். பணி asynchronous-ஆக இருந்து, யாரும் காத்திருக்கவில்லை என்றால் CPU inference சரியான தேர்வாகும்: ஆவணங்களை இரவு நேரத்தில் சுருக்கம் செய்தல் அல்லது நீங்கள் தூங்கும்போது இயங்கும் nightly classification பணி போன்றவை இதற்கு உதாரணம். ஒரு நபர் வெளியீட்டிற்காகக் காத்திருக்கும்போதோ அல்லது 30 வினாடிகளுக்கு ஒருமுறை என்ற வேகத்தை விட அதிகமாக கோரிக்கைகள் வரும்போதோ GPU-வை வாடகைக்கு எடுங்கள். ஏனெனில், CPU-மட்டும் கொண்ட பெட்டியில் batching வசதி இல்லை, இதனால் வரிசை (queue) வளர்ந்துகொண்டே செல்லும்.

செலவு ஒப்பீடு பார்ப்பதை விட எளிதானது அல்ல. 64 GB VPS-ல் model ஏற்றப்பட்டிருந்தாலும் இல்லாவிட்டாலும் ஒவ்வொரு மணிநேரத்திற்கும் கட்டணம் வசூலிக்கப்படும், ஆனால் GPU instance-ல் நீங்கள் இயக்கும் மணிநேரங்களுக்கு மட்டுமே கட்டணம் வசூலிக்கப்படும். உங்கள் உண்மையான பயன்பாடு ஒரு நாளைக்கு இரண்டு மணிநேரம் மட்டுமே என்றால், வாடகைக்கு எடுக்கப்பட்ட GPU வேகமாகவும் மலிவாகவும் இருக்கும். முதலில் உங்கள் duty cycle-ஐக் கணக்கிடுங்கள், பிறகு விலையை முடிவு செய்யுங்கள். GPU உடன் கூடிய VPS-ஐத் தேர்ந்தெடுத்தல் பகுதியில் instance-ல் எதைச் சரிபார்க்க வேண்டும் என்பது விளக்கப்பட்டுள்ளது, மேலும் GPU-வில் ஒரே நேரத்தில் பல கோரிக்கைகளைச் செயல்படுத்தும்போது vLLM, Ollama-வை விட முன்னிலையில் உள்ளது ஏனெனில் அது கோரிக்கைகளைச் சரியாக batch செய்கிறது.

மக்கள் மறந்துவிடும் மூன்றாவது ஒரு வழி உள்ளது. batch பணிகளுக்கு 27B-ஐ CPU-வில் வைத்திருங்கள், interactive பணிகளுக்கு hosted API model-ஐப் பயன்படுத்துங்கள். இரண்டு பணிகளுக்கும் ஒரே model-தான் இருக்க வேண்டும் என்ற கட்டாயம் இல்லை.

Ollama-ஐ நிறுவுதல் மற்றும் உங்கள் கணினியின் செயல்திறனை அளவிடுதல்

நிறுவல் ஸ்கிரிப்ட் அதிகாரப்பூர்வமானது. இது ollama என்ற பிரத்யேக பயனரின் கீழ் இயங்கும் systemd service-ஐ அமைக்கிறது.

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

ollama --version கட்டளையானது 0.32.5 அல்லது அதற்குப் பிந்தைய பதிப்பைக் காட்ட வேண்டும். எதையும் pull செய்வதற்கு முன் free -g-ஐச் சரிபார்க்கவும். Mem வரியில் உள்ள total நெடுவரிசை 32-க்குக் குறைவாக இருந்தால், இங்கேயே நிறுத்திவிட்டு சிறிய மாடலைத் தேர்ந்தெடுக்கவும். ஏனெனில், உங்களால் இயக்க முடியாத 17 GB அளவிலான மாடலைப் பதிவிறக்குவது ஒரு மணிநேரத்தையும் அதிக வட்டு இடத்தையும் வீணடிக்கும்.

Runtime விருப்பங்களை உங்கள் shell-ல் அமைக்காமல், systemd override-ல் அமைக்கவும். மாடல் service-க்குள் இயங்குவதால், அது உங்கள் interactive சூழலைப் பார்க்காது.

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 வெளியீடுதான் நீங்கள் எதிர்பார்க்கும் அளவீடு. eval rate என்பது generation-ன் போது ஒரு வினாடிக்கு உருவாக்கப்படும் tokens-ன் எண்ணிக்கை ஆகும். prompt eval rate என்பது உங்கள் prefill வேகம் ஆகும். load duration என்பது வட்டில் இருந்து weights-ஐப் படிக்க எடுத்துக்கொண்ட நேரம். இதனால்தான் OLLAMA_KEEP_ALIVE=60m அமைக்கப்பட்டுள்ளது: CPU-வில், ஒவ்வொரு கோரிக்கையின் போதும் வட்டில் இருந்து 17 GB-ஐ மீண்டும் ஏற்றுவது, கோரிக்கையை விட அதிகச் செலவை ஏற்படுத்தும்.

மாடல் ஏற்றப்பட்டிருக்கும் போது, இரண்டாவது terminal மூலம் அதன் பயன்பாட்டைச் சரிபார்க்கவும்.

ollama ps

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

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

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

பதில் அளிக்கும்போது செயல்முறை மறைந்துவிடுகிறது. client பயனுள்ள எதையும் காட்டாது, மேலும் journalctl -u ollama -n 50 சேவை மறுதொடக்கம் செய்யப்படுவதைக் காட்டும். dmesg -T | tail-ஐ இயக்கவும், Out of memory: Killed process ... (ollama) என்று வாசிக்கும் ஒரு வரி இருந்தால், கர்னல் OOM killer அதை நிறுத்தியுள்ளது என்று அர்த்தம். pre-load சோதனை தேர்ச்சி பெற்றாலும், நீண்ட உரையாடலின் போது cache மதிப்பீட்டை விட வளர்ந்தால் இது நிகழும். context length-ஐக் குறைக்கவும்.

பதிவிறக்கம் (pull) உடனடியாகத் தோல்வியடைகிறது. Error: pull model manifest: file does not exist என்பது அந்த tag library-ல் இல்லை என்று பொருள். qwen3.8:27b என்று தட்டச்சு செய்வது இதைத்தான் குறிக்கும், version எண்ணில் ஏதேனும் எழுத்துப் பிழை இருந்தாலும் இதுவே நிகழும். உங்கள் நெட்வொர்க்கைக் குறை கூறுவதற்கு முன் library பக்கத்தில் tag-ஐ உறுதிப்படுத்தவும்.

எல்லாம் வேலை செய்கிறது ஆனால் மிக மெதுவாக உள்ளது. போதுமான RAM உள்ள கணினியில் ஒரு வினாடிக்கு ஒரு token-க்கும் குறைவாக இருந்தால், அது கணக்கீட்டை விட paging-ஐக் குறிக்கிறது. உருவாக்கும்போது vmstat 1-ஐ இயக்கவும். si அல்லது so நெடுவரிசையில் பூஜ்ஜியம் அல்லாத மதிப்பு இருந்தால், கர்னல் swapping செய்கிறது என்று பொருள்; இதற்கு context-ஐக் குறைப்பது அல்லது குறைவான மாதிரிகளை ஏற்றுவது தீர்வாகும். swap செயல்பாடு இல்லாமல் wa தொடர்ந்து அதிகமாக இருந்தால், memory-mapped weights வட்டில் (disk) இருந்து மீண்டும் படிக்கப்படுகிறது என்று பொருள், அதாவது அவை உண்மையில் பொருந்தவில்லை என்று அர்த்தம்.

முதல் token வர 30 வினாடிகள் ஆகிறது, பிறகு வேகம் அதிகரிக்கிறது. இது prefill, இது சாதாரணமானது. cache-ல் இல்லாத ஒவ்வொரு கோரிக்கைக்கும் நீண்ட system prompt-க்கு கட்டணம் செலுத்தப்படுகிறது, எனவே வேறு எதையும் மாற்றும் முன் system prompt-ஐச் சுருக்கவும்.

CPU-மட்டும் கொண்ட 27B மாடல் எதற்குப் பயன்படும்

எதிர்பார்ப்புகளை நம்பிக்கையின் அடிப்படையில் அல்லாமல், எண்களின் அடிப்படையில் நிர்ணயித்துக் கொள்ளுங்கள். வினாடிக்கு இரண்டு முதல் நான்கு tokens என்ற வேகத்தில், 500 tokens கொண்ட ஒரு பதிலைப் பெற இரண்டு முதல் நான்கு நிமிடங்கள் வரை ஆகும். இது chat பயன்பாட்டிற்கு ஏற்றதல்ல, ஆனால் ஒரு queue முறைக்கு மிகச் சரியாக இருக்கும். ஆவணங்களைச் சுருக்குதல் (document summarisation), மொத்தமாக tagging செய்தல், கோப்புகளின் backlog-லிருந்து தகவல்களைப் பிரித்தெடுத்தல் (field extraction) மற்றும் தானியங்கி code review ஆகிய பணிகளுக்கு இது போதுமானது, ஏனெனில் இதற்கு உடனடி பதில் தேவைப்படாது. Coding உதவி இந்த எல்லையில் அமைகிறது, எனவே நீங்கள் host செய்யும் ஒரு model-ஐ coding agent-க்கு பயன்படுத்துவது commit messages மற்றும் test scaffolding போன்ற பின்னணி வேலைகளுக்குப் பயனுள்ளதாக இருக்கும், ஆனால் நீங்கள் காத்திருந்து பெறும் inline பரிந்துரைகளுக்கு இது ஏற்றதல்ல.

தனியுரிமை (privacy) சார்ந்த வாதமே இதில் முக்கியமானது. இந்த model நீங்கள் வாடகைக்கு எடுத்து நிர்வகிக்கும் hardware-ல் இயங்குகிறது, எந்தவொரு கோரிக்கையும் அந்த server-ஐ விட்டு வெளியேறாது, மேலும் token-க்கு கட்டணம் ஏதுமில்லை. ஒழுங்குமுறைக்கு உட்பட்ட (regulated) தரவுகளுக்கு வினாடிக்கு மூன்று tokens என்ற வேகத்தில் இயங்கினாலும் இது மிகவும் மதிப்புமிக்கது. மாற்றாக உள்ளவற்றுடன் இதை நேர்மையாக ஒப்பிட்டுப் பாருங்கள்: frontier-scale model-ஐ நீங்களே host செய்ய பல மடங்கு கூடுதல் hardware தேவைப்படும், மேலும் CPU-ல் இயங்கும் 27B மாடல் என்பது, வாசிப்பதற்குத் தகுதியான வெளியீட்டைத் தரும் மிகக் குறைந்த செலவிலான தீர்வாகும்.

இதுவே உங்கள் முதல் Ollama நிறுவல் என்றால், VPS-ல் Ollama-வை இயக்குவதற்கான முழுமையான வழிகாட்டி, இந்த guide-ல் குறிப்பிடப்பட்டுள்ள service அமைப்பு, HTTP API மற்றும் firewall விதிகள் ஆகியவற்றை விளக்குகிறது. 11434 port-ஐ இணையத்திற்கு நேரடியாகத் திறந்து வைக்காதீர்கள். Ollama-வில் சொந்தமாக authentication வசதி இல்லை, எனவே அந்த port-ஐ அணுகும் எவரும் உங்கள் model-ஐப் பயன்படுத்தவும், உங்கள் prompts-ஐப் படிக்கவும் முடியும்.

FAQ

Ollama-வில் Qwen 3.8 27B மாதிரி உள்ளதா?

இல்லை. 4 August 2026 நிலவரப்படி, Ollama library-ல் qwen3.8 namespace கிடையாது. தற்போதுள்ள 27B tags என்பவை qwen3.5:27b மற்றும் qwen3.6:27b ஆகும்; இவை இரண்டும் 27.8 billion parameter கொண்ட dense model-ன் Q4_K_M builds ஆகும். தேடல் வார்த்தையில் உள்ள 3.8 என்பது, 27.8B parameter எண்ணிக்கையை version number எனத் தவறாகக் கருதியதால் வந்திருக்கலாம். தற்போதைய பட்டியலைப் பார்க்க https://ollama.com/library/qwen3.6/tags-ஐச் சரிபார்க்கவும், புதிய 27B release-ஐப் பெற qwen3.6:27b-ஐப் பயன்படுத்தவும். இல்லாத ஒரு tag-ஐப் பயன்படுத்தினால் Error: pull model manifest: file does not exist பிழை ஏற்படும்.

VPS-ல் Qwen 27B மாதிரியை இயக்க எவ்வளவு RAM தேவை?

Q4_K_M-க்கு 32 GB என்பது நடைமுறைக்குரிய குறைந்தபட்ச அளவு. இதன் weights 17 GB அளவு இருக்கும், operating system-க்கு சுமார் 1.5 GB தேவைப்படும், மேலும் f16-ல் ஒவ்வொரு 4000 tokens context-க்கும் KV cache சுமார் 1 GB-ஐ எடுத்துக்கொள்ளும். 16 GB plan-ல் இந்த weights-ஐ ஏற்ற முடியாது. Swap memory-ஐப் பயன்படுத்தினாலும் பலன் இருக்காது, ஏனெனில் இந்த file memory-mapped முறையில் இருப்பதால், ஒவ்வொரு token-க்கும் kernel அதை disk-லிருந்து மீண்டும் மீண்டும் வாசிக்கும். 64 GB இருந்தால் நீண்ட context-க்கு அல்லது 30 GB அளவுள்ள Q8_0 weights-ஐப் பயன்படுத்த இடவசதி கிடைக்கும்.

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

உங்கள் memory bandwidth-ஐ weights-ன் அளவால் வகுத்து, அதில் 50 முதல் 70 சதவீதத்தைக் கணக்கிடுங்கள். இரண்டு channel கொண்ட DDR4-3200 VPS-ன் உச்ச வரம்பு 3 tokens/sec ஆகும், இது வினாடிக்கு சுமார் 2 tokens-ஐ வழங்கும். இரண்டு channel கொண்ட DDR5-4800 வசதி கொண்ட box-ன் உச்ச வரம்பு 4.5 ஆகும், இது வினாடிக்கு சுமார் 3 tokens-ஐ வழங்கும். அதிக channel கொண்ட server தளங்கள் காகித அளவில் சிறப்பாகத் தெரிந்தாலும், host-ல் உள்ள அனைத்து பயனர்களுக்கும் memory bandwidth பகிரப்படுவதால், ollama run qwen3.6:27b --verbose மூலம் உங்கள் சொந்த வேகத்தைச் சோதித்து eval rate வரியைப் பார்க்கவும்.

CPU-மட்டும் கொண்ட 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 மாதிரியில் Q4_K_M மற்றும் Q8_0-க்கு இடையிலான தரம் மிகக் குறைவே. அந்த RAM-ஐ நீண்ட context-க்குச் செலவிடுங்கள், ஏனெனில் அது மாதிரியின் செயல்பாட்டை மாற்றும், phrasing-ஐ மட்டும் மாற்றாது.

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

உங்கள் பயன்பாடு குறைவாக இருக்கும்போது அல்லது ஒரு பயனர் காத்திருக்கும் சூழலில் இது மலிவானது. 24 GB memory கொண்ட ஒரு GPU, இந்த weights-ஐப் பயன்படுத்தி வினாடிக்கு சுமார் 59 tokens-ஐ வழங்கும், இது சாதாரண VPS-ன் 2 அல்லது 3 tokens வேகத்தை விட அதிகம். மேலும், GPU பயன்பாட்டிற்கு மட்டுமே கட்டணம் வசூலிக்கப்படும். 64 GB VPS-க்கு மாதிரி இயங்கினாலும் இல்லாவிட்டாலும் மாதம் முழுவதும் கட்டணம் செலுத்த வேண்டும். ஒரு நாளில் எத்தனை மணிநேரம் tokens உருவாக்குகிறீர்கள் என்பதைக் கணக்கிடுங்கள். இரண்டு அல்லது மூன்று மணிநேரத்திற்கும் குறைவாக இருந்தால், வேகத்திலும் செலவிலும் GPU வாடகை சிறந்தது. தொடர்ந்து இயங்க வேண்டிய low-priority batch வேலைகளுக்கு எப்போதும் இயங்கும் VPS சிறந்தது.