Self-host செய்யக்கூடிய சிறந்த AI மாதிரிகள் எவை?

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

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

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

அளவு கணக்கீடு: ஒரு பாராமீட்டருக்கான பிட்கள்

ஒரு மாடல் கோப்பு பெரும்பாலும் எடைகளால் (weights) ஆனது. ஒவ்வொரு எடையும் குறிப்பிட்ட எண்ணிக்கையிலான பிட்களில் சேமிக்கப்படுகிறது. குவாண்டிசேஷன் (Quantisation) என்பது, மாடல் பயிற்சியின்போது பயன்படுத்தப்பட்ட துல்லியத்தை விடக் குறைவான பிட்களில் அவற்றைச் சேமிப்பதாகும். இது சிறிதளவு துல்லியத்தைக் குறைத்தாலும், அதிகப்படியான நினைவகத்தைச் சேமிக்கிறது. மாடலின் அளவு இதிலிருந்து நேரடியாகத் தீர்மானிக்கப்படுகிறது:

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

மாடல்கள் 16 பிட்களில் வெளியிடப்படுகின்றன, இது ஒரு பில்லியன் பாராமீட்டர்களுக்கு 2 GB ஆகும். இதனால்தான் யாரும் VPS-ல் வெளியிடப்பட்ட துல்லியத்தில் (release precision) மாடல்களை இயக்குவதில்லை. நீங்கள் நடைமுறையில் எதிர்கொள்ளும் குவாண்டிசேஷன் முறைகள் மற்றும் அவற்றின் சராசரி பிட்கள் கீழே கொடுக்கப்பட்டுள்ளன:

• Q8_0 ஒரு எடைக்கு சுமார் 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 பிட்களுக்குக் கீழே செல்லும்போது தர இழப்பு வேகமாக அதிகரிக்கிறது. எனவே, 70B மாடலை 2 பிட்களுக்குச் சுருக்குவதை விட, அதே தலைமுறையைச் சேர்ந்த 4 பிட்களில் உள்ள 32B மாடல் சிறப்பாகச் செயல்படும். நினைவகம் குறைவாக இருக்கும்போது, 4 பிட்களுக்குக் கீழே செல்வதற்குப் பதிலாக, மாடலின் அளவைக் குறைப்பது (size class) சிறந்தது.

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

மேலே உள்ள எடை அட்டவணை, ஒரு பில்லியன் பாராமீட்டர்களுக்கு 0.6 GB என்ற விதியின் அடிப்படையில் கணக்கிடப்பட்டது. உண்மையான GGUF கோப்புகள் இந்த அளவிலிருந்து சில சதவீத மாற்றத்திலேயே இருக்கும், ஏனெனில் எம்பெடிங் (embedding) மற்றும் அவுட்புட் லேயர்கள் மற்ற பகுதிகளை விட அதிக துல்லியத்தில் பராமரிக்கப்படுகின்றன. 4 பிட்களில் உள்ள ஒரு 3B மாடல் சுமார் 1.8 GB ஆகும். ஒரு 8B மாடல் 4.8 GB ஆகும். ஒரு 32B மாடல் 19.2 GB ஆகும், மற்றும் ஒரு 70B மாடல் 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 தொழில்நுட்பம், parameter எண்ணிக்கையை விட token-க்கான செலவு மிக வேகமாக வளர்வதைத் தடுக்கிறது.

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 length-ஐப் பயன்படுத்துவதற்குப் பதிலாக, உங்களுக்குத் தேவையானதை மட்டும் கோருங்கள், ஏனெனில் பெரும்பாலான chat மற்றும் coding வேலைகள் 8k முதல் 32k-க்குள் அடங்கிவிடும். அல்லது cache-ஐயே 8 bits-க்கு quantise செய்யுங்கள்; இது அதன் அளவை பாதியாகக் குறைக்கும், ஆனால் நீண்ட context-ல் தகவல்களை நினைவுபடுத்துவதில் சிறிய பாதிப்பு ஏற்படலாம்.

நினைவகத்தில் தங்கியிருக்கும் மாதிரி (Resident model) அந்த RAM-ஐ அது நீக்கப்படும் வரை வைத்திருக்கும்

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

ollama ps
ollama stop qwen3:4b

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

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 கட்டளையை இயக்கவும். அந்த மாதிரி இன்னும் பட்டியலிடப்பட்டிருக்கும். இதுவே இதன் நோக்கம்: யாராவது பயன்படுத்தினாலும் இல்லாவிட்டாலும், அது அந்த RAM-ஐத் தொடர்ந்து வைத்திருக்கும். நிலைநிறுத்தப்பட்ட (pinned) மாதிரி என்பது உபரித் திறன் (spare capacity) அல்ல. 16 GB VPS-ல், 8k context கொண்ட 8B மாதிரி, சேவை இயங்கும் வரை தோராயமாக 6 GB-ஐ ஆக்கிரமிக்கும். எனவே, மாதிரியின் அளவை மட்டும் கணக்கில் கொள்ளாமல், உங்கள் application-ன் தேவைக்கும் சேர்த்து server-ன் அளவைத் தீர்மானிக்கவும். நினைவகத்தில் மாதிரியை நிலைநிறுத்துதல் பகுதி, cold start latency-க்கு எதிரான சமரசத்தை விளக்குகிறது.

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 பிரித்தெடுத்தல், சுருக்கமான தொகுப்புகள், ஒரு பத்தியை குறிப்பிட்ட நடையில் மாற்றுதல் போன்ற குறுகிய பணிகளைச் சிறப்பாகச் செய்யும். இவை பல கட்ட பகுத்தறிவு (multi-step reasoning) மற்றும் பல கோப்புகளை உள்ளடக்கிய நிரலாக்கப் பணிகளில் பலவீனமானவை; எவ்வளவு சிறந்த prompting செய்தாலும் இதை சரிசெய்ய முடியாது.

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

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 மாதிரி வினாடிக்கு 0.6 முதல் 1.5 tokens வேகத்தில் இயங்கும். 70B மாதிரி வினாடிக்கு 0.2 முதல் 0.5 tokens வேகத்தில் இயங்கும். அந்த 70B மாதிரியில் 500 tokens கொண்ட ஒரு பதிலைப் பெற சுமார் இருபது நிமிடங்கள் ஆகும். இவை batch முறையில் செயலாக்கப்படுபவை. ஆவணங்களின் வரிசையை (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-ல், dense 30B மாதிரியை விட இத்தகைய MoE மாதிரி அதிக பயன்பாட்டுத் திறன் கொண்டது. நீங்கள் நினைவில் கொள்ள வேண்டிய விதி: total parameters memory-ஐத் தீர்மானிக்கின்றன, active parameters வேகத்தைத் தீர்மானிக்கின்றன.

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

ஒரு token-ஐ உருவாக்குவதற்கு, செயல்பாட்டில் உள்ள அனைத்து weight-களையும் நினைவகத்திலிருந்து (memory) ஒருமுறை வாசிக்க வேண்டும். இதைத் தவிர்க்க முடியாது என்பதால், CPU-வில் generation வேகம் என்பது core-களின் எண்ணிக்கையைச் சார்ந்தது அல்ல, மாறாக memory bandwidth-ஐச் சார்ந்தது. இதன் உச்ச வரம்பு ஒரு கணக்கீடு: பயன்படுத்தக்கூடிய memory bandwidth-ஐ, weight-களின் அளவால் (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-ன் முதல் run-ஐக் கணக்கில் கொள்ளாதீர்கள், ஏனெனில் அதே சுருக்கத்தில் உள்ள load duration, weight-களை வட்டில் (disk) இருந்து வாசிக்கும் நேரத்தையும் உள்ளடக்கும். Tokens per second-ஐச் சரியாக அளவிடுதல் என்ற பகுதி, ஒப்பீட்டிற்கு ஏற்ற சரியான எண்ணைப் பெறுவது எப்படி என்பதை விளக்குகிறது.

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

உங்கள் prompt-ஐ வாசிப்பது, பதிலை உருவாக்குவதிலிருந்து மாறுபட்ட ஒரு பணி. Prompt processing என்பது compute bound, எனவே இது core-களின் எண்ணிக்கைக்கு ஏற்ப அதிகரிக்கும்; இங்குதான் GPU அதிக வேகத்தை வெளிப்படுத்துகிறது. ஒரு நீண்ட ஆவணத்தை வாசிக்க CPU-க்கு சில நிமிடங்கள் ஆகும், ஆனால் GPU-க்கு சில நொடிகள் மட்டுமே ஆகும்.

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 மற்றும் அதற்கு மேற்பட்டவை 4-bit அளவில் 70B மாதிரியை, cache மற்றும் concurrency-க்கு இடமளித்து கையாளும்.

ஒரு மாதிரி (model) பொருந்தவில்லை என்றால், 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 மாதிரியைப் பயன்படுத்தும் பத்து concurrent பயனர்களுக்கு, weights தவிர கூடுதலாக பத்து மடங்கு 1 GB cache தேவைப்படும். ஒரே self-hosted மாதிரியிலிருந்து concurrent பயனர்களுக்குச் சேவை வழங்குதல் அந்த வரம்பு எங்கே அமைகிறது என்பதை விளக்குகிறது.

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 வடிவமைப்புகள் ஆகும். அவற்றுக்கும் அதே விதிதான் பொருந்தும்: 4 bits-ல் 400B total parameter கொண்ட ஒரு மாதிரிக்கு, cache-க்கு முன்பே weights-க்காக மட்டும் சுமார் 240 GB தேவைப்படும். இது ஒரு சிறப்பு வன்பொருள் (specialist hardware), இதை மாதந்தோறும் வாடகைக்கு எடுப்பது, பெரும்பாலானோர் ஒரு வருடத்தில் API tokens-க்காகச் செலவிடும் தொகையை விட மிக அதிகம். Kimi வகை மாதிரியை self-host செய்யத் தேவையானவை என்பது உண்மையான தேவைகளை விளக்குகிறது.

இவ்விரண்டிற்கும் இடையிலான தெளிவான எல்லை இதுதான்: சுமை (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-ஐ நிரப்பியவுடன், மற்ற cores காத்திருக்கத் தொடங்கும். மற்றொரு பொதுவான காரணம் swap ஆகும். model பதில் அளிக்கும்போது vmstat 1 கட்டளையில் si மற்றும் so பூஜ்ஜியமற்ற மதிப்புகளைக் காட்டினால், weights RAM-ல் முழுமையாகப் பொருந்தவில்லை என்று அர்த்தம். ஒவ்வொரு token-ன் ஒரு பகுதி disk-லிருந்து எடுக்கப்படுகிறது, இது எதிர்பார்த்ததை விட அதிக தாமதத்தை ஏற்படுத்தும்.

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

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

ஒரு பெரிய model-ஐ 2 bits-லும், சிறிய model-ஐ 4 bits-லும் இயக்குவது எது சிறந்தது?

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

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

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