சொந்தமாக AI மாடல்களை ஹோஸ்ட் செய்வது எப்படி?

எந்த AI மாதிரிகளை நீங்கள் self-host செய்யலாம் என்பதைத் தீர்மானிப்பது எது

எந்த AI மாதிரிகளை நீங்கள் self-host செய்யலாம் என்பதை ஒரு எண் மட்டுமே தீர்மானிக்கிறது: அது உங்கள் கணினியில் உள்ள RAM அளவு. மாதிரியின் வகை (model family) மற்றும் framework-ஐ விட, மாதிரியின் weights நினைவகத்தில் இடம்பிடித்து, மீதமுள்ள இடமும் போதுமானதாக இருக்கிறதா என்பதே முக்கியம். இதைக் கணக்கிடுவதற்கான வழிமுறைகளை இந்தப் பதிவு விளக்குகிறது. Runtime-ஐ நிறுவுவது ஒரு தனி வேலை, அது VPS-ல் Ollama-வை இயக்குவதற்கான வழிகாட்டி-யில் விவரிக்கப்பட்டுள்ளது.

இரண்டு செலவுகள் இந்த முடிவைத் தீர்மானிக்கின்றன. Weights என்பது நிலையான செலவு; இது parameter எண்ணிக்கை மற்றும் quantisation-ஐப் பொறுத்தது. Context window என்பது இயங்கும் செலவு; இதைத்தான் பலரும் கவனிக்கத் தவறிவிடுகிறார்கள். நேற்று சரியாக இயங்கிய ஒரு மாதிரி, இன்று இயங்க மறுப்பதற்கு இதுவே காரணமாகிறது.

அளவு கணக்கீடு: ஒரு பாராமீட்டருக்கான பிட்கள் (bits per parameter)

ஒரு model கோப்பு பெரும்பாலும் weights-களை மட்டுமே கொண்டிருக்கும். ஒவ்வொரு weight-ம் குறிப்பிட்ட எண்ணிக்கையிலான பிட்களில் சேமிக்கப்படும். Quantisation என்பது, model பயிற்சியின்போது பயன்படுத்தப்பட்ட precision-ஐ விடக் குறைந்த பிட்களில் அவற்றைச் சேமிப்பதாகும். இது துல்லியத்தில் சிறிய இழப்பை ஏற்படுத்தினாலும், கணிசமான அளவு நினைவகத்தை (memory) மிச்சப்படுத்துகிறது. கோப்பின் அளவு இதைப் பொறுத்தே அமைகிறது:

weights in GB = (parameters in billions x bits per weight) / 8

Models பொதுவாக 16 பிட்களில் வெளியிடப்படுகின்றன; இது ஒரு பில்லியன் பாராமீட்டர்களுக்கு 2 GB ஆகும். இதனால்தான் VPS-ல் யாரும் release precision-ஐ நேரடியாக இயக்குவதில்லை. நீங்கள் நடைமுறையில் எதிர்கொள்ளும் quantisation முறைகள் மற்றும் அவற்றின் சராசரி பிட்கள் இதோ:

• Q8_0 ஒரு weight-க்கு சுமார் 8.5 பிட்களைச் சேமிக்கிறது, எனவே ஒரு பில்லியன் பாராமீட்டர்களுக்கு சுமார் 1.1 GB.
• Q6_K சுமார் 6.6 பிட்களைச் சேமிக்கிறது, எனவே ஒரு பில்லியன் பாராமீட்டர்களுக்கு சுமார் 0.83 GB.
• Q5_K_M சுமார் 5.7 பிட்களைச் சேமிக்கிறது, எனவே ஒரு பில்லியன் பாராமீட்டர்களுக்கு சுமார் 0.71 GB.
• Q4_K_M சுமார் 4.8 பிட்களைச் சேமிக்கிறது, எனவே ஒரு பில்லியன் பாராமீட்டர்களுக்கு சுமார் 0.6 GB.

கணக்கீடுகளுக்கு ஒரு பில்லியன் பாராமீட்டர்களுக்கு 0.6 GB என்ற அளவைப் பயன்படுத்தவும். நினைவகக் கட்டுப்பாடுள்ள சூழலில் Q4_K_M ஒரு சிறந்த இயல்புநிலை (default) தேர்வாகும்: பெரும்பாலான பணிகளில் 8 பிட்களுடன் ஒப்பிடும்போது இதில் தர இழப்பு மிகக் குறைவு, மேலும் கோப்பின் அளவு கிட்டத்தட்ட பாதியாகக் குறைகிறது. 4 பிட்களுக்குக் கீழே செல்லும்போது தர இழப்பு வேகமாக அதிகரிக்கும்; எனவே, ஒரே தலைமுறையைச் சேர்ந்த 32B model-ஐ 4 பிட்களில் பயன்படுத்துவது, 70B model-ஐ 2 பிட்களுக்குச் சுருக்குவதை விடச் சிறந்த முடிவுகளைத் தரும். நினைவகம் குறைவாக இருக்கும்போது, 4 பிட்களுக்குக் கீழே செல்வதற்குப் பதிலாக, சிறிய அளவிலான model-க்கு மாறுவது சிறந்தது.

[
  {
    "label": "3B",
    "weights_gb": 1.8,
    "kv_8k_gb": 0.9,
    "kv_128k_gb": 14
  },
  {
    "label": "8B",
    "weights_gb": 4.8,
    "kv_8k_gb": 1,
    "kv_128k_gb": 16
  },
  {
    "label": "14B",
    "weights_gb": 8.4,
    "kv_8k_gb": 1.5,
    "kv_128k_gb": 24
  },
  {
    "label": "32B",
    "weights_gb": 19.2,
    "kv_8k_gb": 2,
    "kv_128k_gb": 32
  },
  {
    "label": "70B",
    "weights_gb": 42,
    "kv_8k_gb": 2.5,
    "kv_128k_gb": 40
  }
]

மேலே உள்ள weight கணக்கீடு, ஒரு பில்லியன் பாராமீட்டர்களுக்கு 0.6 GB என்ற விதியின் அடிப்படையில் அமைந்தது. உண்மையான GGUF கோப்புகள் இந்த அளவிலிருந்து சில சதவீத வித்தியாசத்திலேயே இருக்கும், ஏனெனில் embedding மற்றும் output layers மற்ற பகுதிகளை விட அதிக precision-ல் பராமரிக்கப்படுகின்றன. 4 பிட்களில் உள்ள ஒரு 3B model சுமார் 1.8 GB இருக்கும். ஒரு 8B model 4.8 GB இருக்கும். ஒரு 32B model 19.2 GB இருக்கும், மற்றும் ஒரு 70B model 42 GB இருக்கும்.

Context length ஏன் weights-ஐ விட அதிக RAM-ஐப் பயன்படுத்துகிறது

KV cache (key value cache, உரையாடலில் உள்ள ஒவ்வொரு token-க்கும் model வைத்திருக்கும் attention state) என்பது இரண்டாவது செலவாகும். Model load ஆகும்போது இது ஒதுக்கீடு செய்யப்படுகிறது, நீங்கள் கோரிய context length-க்கு ஏற்ப இதன் அளவு அமையும், மேலும் அந்த நீளத்திற்கு ஏற்ப இது நேர்க்கோட்டில் வளரும்.

bytes per token = 2 x layers x kv_heads x head_dim x bytes per element

Ollama-வின் default context-ல், அந்த 8B model cache-க்காக அரை gigabyte-ஐப் பயன்படுத்துகிறது. 8192 tokens-ல் அது 1 GB-ஐப் பயன்படுத்துகிறது. அதன் model card-ல் குறிப்பிடப்பட்டுள்ள 128k context-ல், அது 16 GB-ஐப் பயன்படுத்துகிறது, இது weights-ஐ விட மூன்று மடங்கு அதிகம். 70B model இதற்கு நேர்மாறானது: 128k-ல் அதன் cache 40 GB மட்டுமே, இது அதன் weights-ஐ விடக் குறைவு, ஏனெனில் grouped query attention காரணமாக ஒரு token-க்கான செலவு parameter எண்ணிக்கையைப் போல வேகமாக அதிகரிப்பதில்லை.

CPU மட்டுமே உள்ள server-ல் Ollama-வின் default context length 4096 tokens ஆகும். GPU இருக்கும்போது, அது VRAM-லிருந்து default மதிப்பைத் தேர்ந்தெடுக்கும்: 24 முதல் 48 GiB வரை 32k, மற்றும் 48 GiB-க்கு மேல் 256k. Server-ல் OLLAMA_CONTEXT_LENGTH variable மூலம் இதை அதிகரிக்கலாம், பின்னர் இயங்கும் model உண்மையில் எவ்வளவு பெற்றுள்ளது என்பதை ollama ps-ன் CONTEXT column-ல் சரிபார்க்கலாம். அந்த ஒரு அமைப்பிற்குப் பின்னால் உள்ள memory கணக்கீடுகள் num_ctx மற்றும் context length குறித்த பதிவில் விளக்கப்பட்டுள்ளன.

Cache பயன்பாட்டைக் குறைக்க இரண்டு வழிகள் உள்ளன. Model card-ல் குறிப்பிடப்பட்டுள்ள context-ஐக் கோருவதற்குப் பதிலாக, உங்களுக்குத் தேவையான context-ஐ மட்டும் கோருங்கள், ஏனெனில் பெரும்பாலான chat மற்றும் coding வேலைகள் 8k முதல் 32k-க்குள் அடங்கிவிடும். அல்லது cache-ஐயே 8 bits-க்கு quantise செய்யுங்கள், இது அதன் அளவை பாதியாகக் குறைக்கும், ஆனால் நீண்ட context-ஐ நினைவு கூர்வதில் சிறிய பாதிப்பு ஏற்படலாம்.

நினைவகத்தில் ஒரு model-ஐத் தக்கவைத்தல்

கடைசி கோரிக்கைக்குப் பிறகு 5 நிமிடங்கள் வரை Ollama ஒரு model-ஐ நினைவகத்தில் வைத்திருந்து, அதன் பிறகு அதை நீக்கிவிடும். இந்த இயல்புநிலை அமைப்பு மடிக்கணினிகளுக்குப் பொருத்தமானது, ஆனால் server-களுக்கு இது உகந்ததல்ல; ஏனெனில் ஒவ்வொரு இடைவெளிக்குப் பிறகும் வரும் முதல் கோரிக்கையின்போது, model-ஐ மீண்டும் ஏற்ற வேண்டிய தாமதம் ஏற்படும்.

ollama ps
ollama stop qwen3:4b

ollama ps கட்டளையானது தற்போது நினைவகத்தில் உள்ளவற்றை பட்டியலிடும். இதில் SIZE நிரல் எவ்வளவு நினைவகத்தை அது ஆக்கிரமித்துள்ளது என்பதையும், UNTIL நிரல் அது எப்போது காலாவதியாகும் என்பதையும் காட்டும். ஒரு model-ஐ நிரந்தரமாக நினைவகத்தில் நிலைநிறுத்த (pin), அந்த service-ல் OLLAMA_KEEP_ALIVE=-1 அமைப்பை மாற்றவும். 0 என்ற மதிப்பை அமைத்தால், ஒவ்வொரு பதிலுக்கும் பிறகு model உடனடியாக நினைவகத்திலிருந்து நீக்கப்படும்.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_KEEP_ALIVE=-1"
Environment="OLLAMA_CONTEXT_LENGTH=8192"

sudo systemctl daemon-reload
sudo systemctl restart ollama

ஒரு prompt-ஐ அனுப்பிவிட்டு, பத்து நிமிடங்கள் கழித்து மீண்டும் ollama ps கட்டளையை இயக்கவும். அந்த model இன்னும் பட்டியலில் இருக்கும்; இதுவே இதன் நோக்கம்: யாராவது பயன்படுத்தினாலும் இல்லாவிட்டாலும், அது அந்த RAM-ஐத் தொடர்ந்து ஆக்கிரமித்திருக்கும். நிலைநிறுத்தப்பட்ட (pinned) model என்பது உபரித் திறன் அல்ல. 16 GB RAM கொண்ட VPS-ல், 8k context கொண்ட ஒரு 8B model, service இயங்கும் வரை சுமார் 6 GB-ஐ ஆக்கிரமிக்கும். எனவே, உங்கள் server-ன் அளவைத் தீர்மானிக்கும்போது, model-ன் அளவுடன் உங்கள் application-ன் தேவையையும் சேர்த்து கணக்கிடவும். நினைவகத்தில் ஒரு model-ஐ நிலைநிறுத்துதல் பகுதி, cold start தாமதத்திற்கும் நினைவகப் பயன்பாட்டிற்கும் இடையிலான சமநிலையை விளக்குகிறது.

4 GB VPS-ல் இயங்கக்கூடியவை

இயக்க முறைமை (operating system) மற்றும் model server-க்காக சுமார் 1 GB-ஐ ஒதுக்கிவிட்டால், மீதம் தோராயமாக 3 GB கிடைக்கும். இது 4 bits அளவில் 1B முதல் 4B வரையிலான model-களை, இயல்பான 4096 token context-ல் இயக்க போதுமானது. ஆகஸ்ட் 2026 நிலவரப்படி, இந்த வகையில் Llama 3.2 (3B), Qwen 3 (1.7B மற்றும் 4B), மற்றும் சிறிய Gemma, Phi releases ஆகியவை அடங்கும். இவற்றை பரிந்துரைகளாகக் கருதாமல், அளவுக்கான உதாரணங்களாகக் கொள்ளவும். model பெயர்கள் சில மாதங்களுக்கு ஒருமுறை மாறலாம், ஆனால் கணக்கீடு மாறாது.

தோராயமாக 6 முதல் 14 tokens per second வேகத்தை எதிர்பார்க்கலாம். இவ்வளவு சிறிய model-கள் வகைப்படுத்துதல் (classification), tag பிரித்தெடுத்தல், சுருக்கமான summary, ஒரு பத்தியை குறிப்பிட்ட நடைக்கு மாற்றுதல் போன்ற குறுகிய பணிகளைச் சிறப்பாகச் செய்யும். இவை பல கட்ட தர்க்கம் (multi step reasoning) மற்றும் பல கோப்புகளை உள்ளடக்கிய code பணிகளில் பலவீனமானவை; எவ்வளவு சிறந்த prompt கொடுத்தாலும் இதைச் சரிசெய்ய முடியாது.

இந்த நிலையில் ஏற்படும் தோல்விக்கு swap-தான் காரணம். model-ன் அளவு அதிகமாக இருந்தால், Linux அதை ஏற்ற மறுக்காது. அதற்குப் பதிலாக, memory-ஐ disk-க்கு மாற்றும் (paging). ஒரு token-ஐ உருவாக்க ஒவ்வொரு weight-உம் ஒருமுறை வாசிக்கப்பட வேண்டும் என்பதால், generation வேகம் ஒரு token-க்கு பல நொடிகள் எனச் சரிந்துவிடும். model பதில் அளிக்கும்போது free -h-ஐயும், vmstat 1-ன் si மற்றும் so நெடுவரிசைகளையும் கவனிக்கவும். generation-ன் போது swap in மற்றும் swap out பூஜ்ஜியத்திற்கு மேல் இருந்தால், அந்த model-ன் அளவு உங்கள் plan-க்கு மிக அதிகம் என்று அர்த்தம்.

8 GB முதல் 16 GB வரையிலான VPS-ல் இயங்குபவை

இங்குதான் self-hosted மாதிரி பொதுவாகப் பயனுள்ளதாக மாறுகிறது. 8 GB RAM-ல், 4-bit அளவில் 7B அல்லது 8B மாதிரியை, சுமார் 4.8 GB எடையுடன் (weights), 8k context-ல் இயக்கலாம். 16 GB RAM-ல், 4-bit அளவில் 13B அல்லது 14B மாதிரியை, சுமார் 8.4 GB எடையுடன் இயக்கலாம். அல்லது, parameter எண்ணிக்கையை விட துல்லியத்திற்கு (precision) முக்கியத்துவம் அளிக்க விரும்பினால், 8B மாதிரியை 8-bit அளவில் பயன்படுத்தலாம்.

வேகம் தான் இதில் உள்ள சவால். CPU-ல் இயங்கும் ஒரு 8B மாதிரி வினாடிக்கு சுமார் 3 முதல் 7 tokens-ஐ உருவாக்கும்; ஒரு 14B மாதிரி வினாடிக்கு 1.5 முதல் 3.5 tokens-ஐ உருவாக்கும். ஒரு மனிதர் வினாடிக்கு சுமார் 5 முதல் 10 tokens வரை வாசிப்பார். எனவே, CPU VPS-ல் இயங்கும் 8B மாதிரி, மெதுவாகத் தட்டச்சு செய்பவரைப் பார்ப்பது போன்ற உணர்வைத் தரும். இது பின்னணி வேலைகளுக்கு (background jobs) சரியாக இருக்கும், ஆனால் நேரடி உரையாடலுக்கு (interactive chat) சோர்வைத் தரும். VPS-ல் Qwen 3 (8B மற்றும் அதற்கு மேற்பட்டவை) இயக்கப்பட்ட அளவீடுகள் நடைமுறையில் இது எப்படி இருக்கும் என்பதைக் காட்டுகின்றன.

32 GB முதல் 64 GB VPS-ல் என்ன இயங்கும்

4 bits-ல் உள்ள ஒரு 32B மாதிரி சுமார் 19.2 GB அளவு கொண்டது. எனவே, இது குறைந்த context அளவுடன் 32 GB திட்டத்தில் பொருந்தும்; 48 GB அல்லது 64 GB-ல் தாராளமாக இயங்கும். 4 bits-ல் உள்ள ஒரு 70B மாதிரி சுமார் 42 GB அளவு கொண்டது. எனவே, எந்தவித cache-ம் சேர்ப்பதற்கு முன்பே இதற்கு 64 GB தேவைப்படுகிறது.

அதன்பின் வேகத்தை நியாயமாக மதிப்பிடுங்கள். CPU-ல் 32B model ஒரு வினாடிக்கு சுமார் 0.6 முதல் 1.5 tokens வரையிலும், 70B model ஒரு வினாடிக்கு 0.2 முதல் 0.5 tokens வரையிலும் செயல்படும். அந்த 70B model-இலிருந்து 500 tokens கொண்ட பதிலை உருவாக்க சுமார் இருபது நிமிடங்கள் ஆகும். இந்த வேகத்தில் request பொதுவாக model முடிப்பதற்கு முன்பே தோல்வியடையும். காரணம், Ollama-க்கு முன் உள்ள ஏதேனும் client அல்லது proxy-யின் timeout முதலில் செயல்படுவதுதான். இதனால் context deadline exceeded error உருவாகிறது. இவை batch tools. இவற்றுக்கு documents-ன் queue-ஐ இரவு முழுவதும் வழங்கினால் வேகம் முக்கியமல்ல. இவற்றை chat window-க்கு பின்னால் வைத்தால் வேகம் மிகவும் முக்கியமாகிறது.

Mixture of experts (MoE) routing இந்த கணக்கீட்டை மாற்றுகிறது. இது கற்றுக்கொள்ள வேண்டிய ஒரு முக்கியமான architecture விவரமாகும். ஒரு MoE மாதிரி ஒவ்வொரு token-ஐயும் அதன் weights-ன் ஒரு சிறிய பகுதி வழியாக மட்டுமே அனுப்புகிறது. மொத்தம் 30B parameters மற்றும் ஒரு token-க்கு 3B active parameters கொண்ட ஒரு மாதிரிக்கு, 30B மாதிரிக்குத் தேவையான memory தேவைப்படும். ஆனால், இது ஒரு dense 3B மாதிரியின் வேகத்திற்கு நெருக்கமாகச் செயல்படும். ஏனெனில், ஒவ்வொரு token-ம் active experts-ஐ மட்டுமே வாசிக்கிறது. 32 GB வசதி கொண்ட ஒரு server-ல், இத்தகைய MoE மாதிரி ஒரு dense 30B மாதிரியை விட அதிக பயன்பாட்டுத் திறன் கொண்டது. கவனத்தில் கொள்ள வேண்டிய விதி: total parameters memory-ஐத் தீர்மானிக்கின்றன, active parameters வேகத்தைத் தீர்மானிக்கின்றன.

CPU inference உண்மையில் எவ்வளவு வேகமானது?

ஒரு token-ஐ உருவாக்குவதற்கு, நினைவகத்தில் (memory) உள்ள ஒவ்வொரு active weight-ஐயும் ஒருமுறை வாசிக்க வேண்டும். இதைத் தவிர்க்க முடியாது என்பதால், CPU-வில் generation வேகம் என்பது core-களின் எண்ணிக்கையைச் சார்ந்தது அல்ல, அது memory bandwidth-ஐ மட்டுமே சார்ந்தது. இதன் உச்ச வரம்பு ஒரு கணக்கீடு: பயன்படுத்தக்கூடிய memory bandwidth-ஐ, weights-ன் அளவால் (bytes-ல்) வகுக்க வேண்டும். ஒரு சிறிய shared VPS பொதுவாக அதன் vCPU-கள் வழியாக வினாடிக்கு 10 முதல் 25 GB வரை வழங்குகிறது. எனவே, 4.8 GB அளவுள்ள ஒரு model வினாடிக்கு 2 முதல் 5 tokens என்ற அளவில் இயங்கும்.

[
  {
    "label": "3B",
    "tokens_per_second_low": 6,
    "tokens_per_second_high": 14
  },
  {
    "label": "8B",
    "tokens_per_second_low": 3,
    "tokens_per_second_high": 7
  },
  {
    "label": "14B",
    "tokens_per_second_low": 1.5,
    "tokens_per_second_high": 3.5
  },
  {
    "label": "32B",
    "tokens_per_second_low": 0.6,
    "tokens_per_second_high": 1.5
  },
  {
    "label": "70B",
    "tokens_per_second_low": 0.2,
    "tokens_per_second_high": 0.5
  }
]

இவை சாதாரண VPS வன்பொருளில் பொதுவாகக் கிடைக்கும் அளவுகள், ஒரு குறிப்பிட்ட இயந்திரத்தின் benchmark அல்ல. உங்கள் வேகம் என்பது memory தலைமுறை (generation), host-ல் உள்ள channel-களின் எண்ணிக்கை மற்றும் உங்களுடன் போட்டியிடும் பிற பயனர்கள் ஆகியவற்றைப் பொறுத்தது. உங்களிடம் ஏற்கனவே உள்ள ஏதேனும் ஒரு model tag-ஐப் பயன்படுத்தி நீங்களே அளவிடலாம்:

ollama run qwen3:4b --verbose "Write three sentences about disk latency."

பதில் முடிந்ததும் அச்சிடப்படும் சுருக்கத்தின் இறுதியில் eval rate: ... tokens/s என்று தொடங்கும் ஒரு வரி இருக்கும். அதுவே உங்கள் generation வேகம். ஒரு session-ன் முதல் இயக்கத்தைப் புறக்கணிக்கவும், ஏனெனில் அதே சுருக்கத்தில் உள்ள load duration என்பது disk-லிருந்து weights-ஐ வாசிக்கும் நேரத்தையும் உள்ளடக்கியது. Tokens per second-ஐ முறையாக அளவிடுதல் பகுதியில் ஒப்பீடு செய்யத்தக்க மதிப்பை எவ்வாறு பெறுவது என்பது விளக்கப்பட்டுள்ளது.

இங்கே இரண்டு முடிவுகள் மக்களை ஆச்சரியப்படுத்துகின்றன. vCPU-களை அதிகரிப்பது விரைவில் பலனளிக்காமல் போகிறது, ஏனெனில் சுமார் 8 core-களுக்கு மேல், கூடுதல் core-கள் கணக்கீடுகளைச் செய்வதை விட நினைவகத்திற்காகக் காத்திருக்கின்றன. மேலும், shared plan-ல் ஒரே கட்டளை ஒவ்வொரு மணிநேரமும் வெவ்வேறு எண்களைக் காட்டலாம். இது நீங்கள் தவறாக அமைத்ததல்ல, மாறாக CPU steal time from a noisy neighbour ஆகும்.

உங்கள் prompt-ஐ வாசிப்பது, பதிலை உருவாக்குவதிலிருந்து மாறுபட்ட பணியாகும். Prompt processing என்பது compute bound என்பதால், அது core-களின் எண்ணிக்கைக்கு ஏற்ப அதிகரிக்கும். இங்கேயே GPU மற்றவற்றை விட முன்னிலை பெறுகிறது. ஒரு நீண்ட ஆவணத்தை வாசிக்க CPU-க்கு நிமிடங்கள் தேவைப்படும், ஆனால் GPU-க்கு வினாடிகள் மட்டுமே ஆகும். நீங்கள் pointing a coding agent at a model you host செய்யும்போது எதிர்கொள்ளும் முதல் தடையே இதுதான், ஏனெனில் பதிலை உருவாக்குவதற்கு முன்பே, ஒவ்வொரு முறையும் file context மற்றும் tool definitions மீண்டும் அனுப்பப்படுகின்றன.

GPU-வைச் சேர்க்கும்போது என்ன மாற்றங்கள் நிகழ்கின்றன

கணக்கீட்டு முறை மாறுவதில்லை, அது பயன்படுத்தப்படும் வளம் (pool) மட்டுமே மாறுகிறது. VRAM என்பது ஒரு கடுமையான வரம்பு, எனவே நீங்கள் வாடகைக்கு எடுப்பதற்கு முன்பே எவை பொருந்தும் என்பதைக் கணக்கிடுங்கள்:

• 8 GB VRAM-ல் 4-bit அளவில் 7B அல்லது 8B மாடல்களைக் குறுகிய context-உடன் இயக்கலாம்.
• 16 GB VRAM-ல் 4-bit அளவில் 14B மாடலை முறையான context-உடனும், அல்லது 8-bit அளவில் 8B மாடலையும் இயக்கலாம்.
• 24 GB VRAM-ல் 4-bit அளவில் 32B மாடலைக் குறுகிய context-உடன் இயக்கலாம்.
• 48 GB மற்றும் அதற்கு மேற்பட்ட VRAM-ல் 4-bit அளவில் 70B மாடலை cache மற்றும் concurrency-க்கான இடவசதியுடன் இயக்கலாம்.

ஒரு மாடல் பொருந்தவில்லை என்றால், Ollama அதை இரண்டாகப் பிரிக்கிறது: சில அடுக்குகள் (layers) GPU-விலும், மீதமுள்ளவை CPU-விலும் இயங்கும். ollama ps அந்தப் பிரிவை அதன் PROCESSOR நிரலில் 78%/22% CPU/GPU என்பது போன்ற தகவலாகக் காட்டும். இதை ஒரு வசதியாகக் கருதாமல், ஒரு எச்சரிக்கையாகக் கருதுங்கள். CPU-வில் உள்ள பகுதிதான் வேகத்தைத் தீர்மானிக்கிறது, ஏனெனில் ஒவ்வொரு token-ம் அந்த அடுக்குகளுக்காகக் காத்திருக்க வேண்டியுள்ளது. எனவே, கால்வாசி அடுக்குகள் CPU-வில் இருக்கும் ஒரு மாடல், GPU வேகத்தை விட CPU வேகத்திற்கே மிக நெருக்கமாக இயங்கும். நீங்கள் எதிர்பாராத ஒரு பிரிப்பு நிகழ்ந்தால், முதலில் context length-ஐக் குறைக்கவும். பொதுவாக cache-தான் அந்த வரம்பைத் தாண்டச் செய்கிறது.

Concurrency என்பது அளவை அதிகரிப்பதற்கான மற்றொரு காரணம். ஒரே நேரத்தில் வரும் கோரிக்கைகளுக்கு (simultaneous requests) weights பகிரப்படுகின்றன, ஆனால் ஒவ்வொரு active கோரிக்கைக்கும் தனித்தனி KV cache தேவைப்படுகிறது. எனவே, 8k context-ல் 8B மாடலைப் பயன்படுத்தும் பத்து பயனர்களுக்கு, weights-க்கு மேலதிகமாக பத்து மடங்கு 1 GB cache தேவைப்படும். ஒரே self-hosted மாடலில் இருந்து பல பயனர்களுக்குச் சேவை வழங்குதல் அந்த வரம்பு எங்கே அமைகிறது என்பதை விளக்குகிறது.

GPU-வை வாடகைக்கு எடுப்பது லாபகரமானதா என்பது ஒரு கணிதக் கேள்வி, இது நீங்கள் மாதத்திற்கு எத்தனை tokens உருவாக்குகிறீர்கள் என்பதைப் பொறுத்தது. GPU VPS மற்றும் API tokens-க்கு இடையிலான சமநிலை (break even) அந்த எண்களைக் கொண்டுள்ளது.

நீங்கள் எவற்றை self-host செய்ய முடியாது

இங்கே இரண்டு வெவ்வேறு தடைகள் உள்ளன, நீங்கள் எதில் சிக்கியுள்ளீர்கள் என்பதை அறிவது பயனுள்ளதாக இருக்கும்.

முதலாவது closed weights. முன்னணி வணிக ரீதியான மாதிரிகள் (commercial models) விநியோகிக்கப்படுவதில்லை, எனவே பதிவிறக்கம் செய்ய கோப்புகள் எதுவும் இல்லை, RAM-ஐ எவ்வளவு மாற்றினாலும் இதை மாற்ற முடியாது. அவற்றைச் சுற்றியுள்ள அனைத்தையும் நீங்கள் self-host செய்யலாம்: interface, retrieval layer, agent loop, மற்றும் logs. மாதிரி (model) மட்டும் ஒரு remote API-ஆகவே இருக்கும். Claude-ஐ உங்களால் self-host செய்ய முடியுமா என்பது குறித்து அது விரிவாக விளக்குகிறது.

இரண்டாவது, மிகப்பரிய அளவிலான open weights. மிகப்பெரிய open releases என்பவை நூற்றுக்கணக்கான பில்லியன் அளவுள்ள parameters கொண்ட mixture of experts வடிவமைப்புகள் ஆகும். அவற்றுக்கும் அதே விதிதான் பொருந்தும்: 400B total parameter கொண்ட ஒரு மாதிரிக்கு, 4 bits அளவில், cache-க்கு முன்பே weights-க்காக மட்டும் சுமார் 240 GB தேவைப்படும். இது ஒரு சிறப்பு வன்பொருள் (specialist hardware), இதை மாதந்தோறும் வாடகைக்கு எடுப்பது, பெரும்பாலானோர் ஓராண்டில் API tokens-க்காகச் செலவிடும் தொகையை விட மிக அதிகம். Kimi வகை மாதிரியை self-host செய்யத் தேவையானவை என்பது உண்மையான தேவைகளை விளக்குகிறது. இதே வேறுபாடு Ollama-வின் சொந்த library-யிலும் காணப்படுகிறது, அங்கு GLM 5.2 ஒரு cloud model-ஆக மட்டுமே பட்டியலிடப்பட்டுள்ளது, மேலும் அதைவிட மிகச்சிறிய பதிப்பு மட்டுமே VPS-ல் பதிவிறக்கம் செய்யக்கூடியதாக உள்ளது.

இவ்விரண்டிற்கும் இடையிலான தெளிவான வேறுபாடு இதுதான்: சுமை (load) சீராக இருக்கும்போதும், தரவு உங்கள் server-ஐ விட்டு வெளியேறக்கூடாது என்று நினைக்கும்போதும் self-host செய்யுங்கள். சுமை அவ்வப்போது திடீரென அதிகரிக்கும்போதும், அல்லது முன்னணி மாதிரிகளின் துல்லியமான பதில் தரம் உங்களுக்குத் தேவைப்படும்போதும் tokens-ஐ வாங்குங்கள்.

தேர்வு செய்வதற்கு முன் உங்களிடம் உள்ளதைச் சரிபார்க்கவும்

free -h
nproc
lscpu | grep 'Model name'

available நிரலில் உள்ள free -h மதிப்பை அடிப்படையாகக் கொண்டு திட்டமிடுங்கள், total நிரலை அல்ல. ஏனெனில் total என்பது கணினி ஏற்கனவே பயன்படுத்தும் நினைவகத்தையும் உள்ளடக்கியது. இயக்க முறைமை (operating system) மற்றும் model server-க்காக சுமார் 1 GB-ஐக் கழித்துக்கொள்ளுங்கள். மீதமுள்ள மதிப்பை 0.6-ஆல் வகுத்தால், 4 bits-ல் நீங்கள் கையாளக்கூடிய அதிகபட்ச parameter எண்ணிக்கை (பில்லியன் கணக்கில்) கிடைக்கும். அதன் பிறகு, நீங்கள் பயன்படுத்த விரும்பும் context-க்கான KV cache-ஐக் கழித்துவிடுங்கள். எஞ்சியிருப்பதே உங்கள் விடை. இது model பெயர்களின் பட்டியலைப் போல காலாவதியாகாது.

FAQ

8B model-ஐ இயக்க எனக்கு எவ்வளவு RAM தேவை?

4-bit quantisation-ல் உள்ள weights-க்கு சுமார் 4.8 GB RAM தேவைப்படும். இதனுடன் உங்கள் context length-க்கான KV cache மற்றும் operating system மற்றும் model server-க்காக சுமார் 1 GB RAM கூடுதலாகத் தேவைப்படும். 8192 token context-ல் cache சுமார் 1 GB-ஐச் சேர்க்கும், எனவே 8 GB plan போதுமானது, ஆனால் 4 GB plan போதாது. model card-ல் குறிப்பிடப்பட்டுள்ள முழுமையான 128k context உங்களுக்குத் தேவைப்பட்டால், cache மட்டுமே 16 GB தேவைப்படும், அதற்கு நீங்கள் 32 GB plan-ஐத் தேர்ந்தெடுக்க வேண்டும்.

VPS-ல் அதிக vCPU-கள் இருந்தும் ஏன் model மெதுவாக இயங்குகிறது?

ஏனெனில் generation என்பது cores-ஐப் பொறுத்தது அல்ல, memory bandwidth-ஐப் பொறுத்தது. ஒவ்வொரு token-ஐ உருவாக்கும்போதும் முழு active weight set-ம் RAM-லிருந்து எடுக்கப்பட வேண்டும். எனவே, சில cores memory channels-ஐ நிரப்பியவுடன், மற்றவை காத்திருக்கத் தொடங்கும். மற்றொரு பொதுவான காரணம் swap ஆகும். model பதில் அளிக்கும்போது vmstat 1 கட்டளையில் si மற்றும் so பூஜ்ஜியமற்ற மதிப்புகளைக் காட்டினால், weights RAM-ல் முழுமையாகப் பொருந்தவில்லை என்று அர்த்தம். ஒவ்வொரு token-ன் ஒரு பகுதி disk-லிருந்து எடுக்கப்படுகிறது, இது எதிர்பார்த்ததை விட அதிக தாமதத்தை ஏற்படுத்தும்.

நீண்ட context window-க்கு அதிக memory தேவைப்படுமா?

ஆம், tokens-ன் எண்ணிக்கைக்கு ஏற்ப memory தேவை நேரியல் முறையில் (linearly) அதிகரிக்கும். ஒரு வழக்கமான 8B model ஒவ்வொரு token-க்கும் சுமார் 128 KiB KV cache-ஐப் பயன்படுத்துகிறது. எனவே 8192 tokens-க்கு 1 GB-ம், 131072 tokens-க்கு 16 GB-ம் தேவைப்படும். உரையாடல் வளரும்போது cache ஒதுக்கப்படாமல், model load ஆகும்போது முன்பே ஒதுக்கப்படுவதால், நீங்கள் 128k context-ஐக் கோரினால், உங்கள் prompt சிறியதாக இருந்தாலும் அந்த memory உடனடியாக ஒதுக்கப்பட்டுவிடும்.

நான் ஒரு பெரிய model-ஐ 2 bits-லும் அல்லது சிறிய model-ஐ 4 bits-லும் இயக்க வேண்டுமா?

சிறிய model-ஐ 4 bits-ல் இயக்குவதே சிறந்தது. 8 bits-லிருந்து 4 bits வரை தரம் மெதுவாகவே குறையும், ஆனால் 4 bits-க்குக் கீழே தரம் மிக வேகமாக வீழ்ச்சியடையும். எனவே, 70B model-ஐ 2 bits-க்குச் சுருக்குவதை விட, அதே generation-ல் உள்ள 32B model-ஐ 4 bits-ல் இயக்குவது சிறந்த முடிவுகளைத் தரும். அதிகப்படியான quantisation-ன் விளைவாகப் பதில்களில் மீண்டும் மீண்டும் ஒரே வார்த்தைகள் வருதல் அல்லது அறிவுறுத்தல்களைப் புறக்கணித்தல் போன்ற சிக்கல்கள் ஏற்படும். இதைத் தவிர்க்க, 4 bits-ஐக் குறைந்தபட்ச அளவாகக் கொண்டு, அதற்குப் பதிலாக model-ன் parameter எண்ணிக்கையை மாற்றியமைக்கவும்.

பெரிய commercial model-களுக்கு இணையான திறனுடைய model-ஐ என்னால் self-host செய்ய முடியுமா?

சாதாரண VPS-ல் இது சாத்தியமில்லை. மிகச்சிறந்த open weight model-கள் பல நூறு பில்லியன் parameters கொண்டவை. 4 bits-ல் கூட, KV cache-க்கு முன்பே இதற்கு 200 GB-க்கும் அதிகமான RAM தேவைப்படும். மேலும், மிகச்சிறந்த commercial model-கள் பொதுப்பயன்பாட்டிற்காக வெளியிடப்படுவதில்லை. சாதாரண hardware-ல் ஒரு குறிப்பிட்ட பணிக்காக 8B முதல் 32B வரையிலான நல்ல model-களை இயக்குவது சிறப்பாக இருக்கும். ஒரு குறிப்பிட்ட பணிக்குத் துல்லியமாக prompt செய்யப்பட்ட சிறிய model, பொதுவான பெரிய model-க்கு இணையாகச் செயல்படும். உங்களுக்கு மிக உயர்ந்த தரம் தேவைப்பட்டால், hardware வாங்குவதற்கு முன்பே API விலையுடன் ஒப்பிட்டுப் பார்க்கவும்.