VPS-ல் Ollama vs llama.cpp: எது சிறந்தது?

Ollama மற்றும் llama.cpp: நீங்கள் எந்த அடுக்கில் (layer) இயக்க விரும்புகிறீர்கள்?

Ollama மற்றும் llama.cpp ஆகிய இரண்டும் இந்த கேள்வி குறிப்பிடுவது போன்ற போட்டியாளர்கள் அல்ல. llama.cpp என்பது ஒரு inference engine ஆகும்: இது ஒரு model கோப்பை ஏற்றி, ஒரு prompt-ஐ tokens-ஆக மாற்றுகிறது. Ollama என்பது ஒரு model manager, background daemon மற்றும் அந்த engine-க்கு மேலே இயங்கும் ஒரு HTTP API ஆகும். Ollama-வின் README கோப்பில் இன்றும் llama.cpp அதன் inference backend-ஆகக் குறிப்பிடப்பட்டுள்ளது (2 August 2026 அன்று சரிபார்க்கப்பட்டது). எனவே, எது வேகமானது என்பது கேள்வியல்ல, உங்கள் VPS-ல் எந்த அடுக்கில் நீங்கள் செயல்பட விரும்புகிறீர்கள் என்பதே உண்மையான கேள்வி.

பெயரின் அடிப்படையில் model-களைத் தரவிறக்கம் செய்து, எந்தக் கவனமும் இன்றித் தொடர்ந்து இயங்கும் ஒரு service தேவைப்படும்போது Ollama-வை இயக்கவும். உங்கள் VPS சிறியதாக இருந்து, சரியான model கோப்பு, சரியான context அளவு மற்றும் சரியான thread எண்ணிக்கை ஆகியவற்றை நீங்களே தீர்மானிக்க வேண்டியிருக்கும்போது, llama.cpp-ஐ நேரடியாக இயக்கவும். ஏனெனில், சிறிய VPS-ல் இந்த ஒவ்வொரு அமைப்பும் உங்களிடம் இல்லாத நினைவகத்தை (memory) செலவழிக்கும்.

ஒவ்வொரு திட்டமும் உண்மையில் என்ன

llama.cpp என்பது ggml library-ஐ அடிப்படையாகக் கொண்டு உருவாக்கப்பட்ட transformer inference-ன் C மற்றும் C++ செயலாக்கம் ஆகும். இது GGUF கோப்புகளை வாசிக்கிறது. GGUF (GGML universal file format) என்பது ஒரு ஒற்றைக் கோப்பு கொள்கலன் (container) ஆகும்; இது model-ஐ இயக்குவதற்குத் தேவையான weights, tokeniser மற்றும் metadata ஆகியவற்றை உள்ளடக்கியது. இந்தத் திட்டம் வெவ்வேறு பணிகளுக்காகத் தனித்தனி binaries-ஐ வழங்குகிறது. llama-server என்பது ஒரு HTTP server, llama-cli என்பது ஒரு interactive prompt, மற்றும் llama-bench என்பது throughput-ஐ அளவிடும் கருவி. இதன் releases, semantic version-க்கு பதிலாக build number மூலம் குறிக்கப்படுகின்றன. தற்போதைய tag b10224 ஆகும், இது 2 August 2026 அன்று வெளியிடப்பட்டது; பெரும்பாலான வேலை நாட்களில் புதிய tag வெளியிடப்படுகிறது.

Ollama என்பது ஒரு Go நிரல் ஆகும். ollama serve மூலம் தொடங்கப்படும் ஒரு background daemon, model-களை ஏற்றி HTTP கோரிக்கைகளுக்குப் பதிலளிக்கிறது; ஒரு command line client அந்த daemon-உடன் தொடர்பு கொள்கிறது. இவை இரண்டிற்கும் பின்னால், முன்கூட்டியே தொகுக்கப்பட்ட (prepacked) model-களைக் கொண்ட ollama.com என்ற registry உள்ளது. Ollama, semantic versions-ஐப் பயன்படுத்துகிறது; v0.32.5, 27 July 2026 அன்று வெளியிடப்பட்டது. ollama pull, ஒரு GGUF கோப்பை அதன் prompt template மற்றும் இயல்புநிலை அளவுருக்களுடன் (default parameters) பதிவிறக்கம் செய்து, Linux-ல் /usr/share/ollama/.ollama/models என்ற இடத்தில் சேமிக்கிறது. இந்தக் கோப்புகள் root disk-ல் அமர்ந்து ஒவ்வொன்றும் பல gigabytes அளவு வரை செல்கின்றன. எனவே, 25 GB root volume கொண்ட ஒரு VPS-ல், மூன்றாவது பதிவிறக்கத்திற்கு முன்பே pull கட்டளை எதை விட்டுச் செல்கிறது மற்றும் model directory-ஐ எவ்வாறு வேறு இடத்திற்கு மாற்றுவது என்பதைத் தெரிந்துகொள்வது அவசியம்.

இந்த பேக்கேஜிங் (packaging) முறையே இவற்றுக்கு இடையேயான முக்கிய வேறுபாடு ஆகும். Ollama உங்களுக்காக quantisation, template மற்றும் context length ஆகியவற்றைத் தீர்மானித்து, நினைவில் கொள்ள ஒரு பெயரை மட்டும் வழங்குகிறது. llama.cpp எதையும் தீர்மானிப்பதில்லை, மாறாக உங்களுக்குத் தேவையான flags-ஐ வழங்குகிறது.

அச்சு 1: மாதிரி மற்றும் குவாண்டைசேஷன் கட்டுப்பாடு

குவாண்டைசேஷன் (Quantisation) என்பது ஒவ்வொரு எடையையும் (weight) 16 அல்லது 32 பிட்களிலிருந்து 4, 5 அல்லது 8 பிட்களாகக் குறைப்பதாகும். இதுவே 8 பில்லியன் அளவுருக்கள் கொண்ட மாதிரியை ஒரு சாதாரண VPS-ன் RAM-ல் பொருத்த உதவுகிறது. GGUF பெயரிடும் முறையை ஒருமுறை புரிந்துகொண்டால் அது எளிது: Q4_K_M என்பது 4-பிட் K-quant, நடுத்தர அளவு என்பதைக் குறிக்கிறது. அதிக எண் அதிக துல்லியத்தைத் தரும், ஆனால் அதிக நினைவகத்தை (memory) எடுத்துக்கொள்ளும்.

[
  {
    "label": "Q2_K",
    "file_size_gib": 2.96
  },
  {
    "label": "Q3_K_M",
    "file_size_gib": 3.74
  },
  {
    "label": "Q4_K_M",
    "file_size_gib": 4.58
  },
  {
    "label": "Q5_K_M",
    "file_size_gib": 5.34
  },
  {
    "label": "Q6_K",
    "file_size_gib": 6.14
  },
  {
    "label": "Q8_0",
    "file_size_gib": 7.95
  }
]

இவை Hugging Face-ல் உள்ள bartowski/Meta-Llama-3.1-8B-Instruct-GGUF களஞ்சியத்தில் வெளியிடப்பட்ட கோப்பு அளவுகள். இவை 2 ஆகஸ்ட் 2026 அன்று கணக்கிடப்பட்டு, பைட்டுகளிலிருந்து GiB-க்கு மாற்றப்பட்டுள்ளன. 6 மாதிரியின் கட்டமைப்புகள் உள்ளன; அவற்றில் மிகச்சிறியது 2.96 GiB, மிகப்பெரியது 7.95 GiB ஆகும். பொதுவான இயல்புநிலை (default) தேர்வான Q4_K_M, 4.58 GiB ஆகும். 4 GiB VPS-ல், இந்த ஒரு தேர்வுதான் மாதிரி இயங்குமா இல்லையா என்பதைத் தீர்மானிக்கிறது. அளவு என்பது முடிவின் ஒரு பகுதி மட்டுமே; ஏனெனில் உங்களால் வாங்கக்கூடிய ஒரு கோப்பு, பயன்படுத்துவதற்குத் தகுதியானதாக இருக்க வேண்டிய அவசியமில்லை. Q4, Q8 மற்றும் fp16 ஆகியவற்றின் உண்மையான தரம் குறித்த புரிதல் மட்டுமே, கூடுதல் ஜிகாபைட்டுகள் உங்களுக்குத் தேவையான பலனைத் தருகிறதா என்பதைத் தீர்மானிக்க உதவும்.

llama.cpp-ல் கோப்பின் பெயரை நீங்களே குறிப்பிடுவதால், அந்த வரிசையை நீங்களே தேர்ந்தெடுக்கிறீர்கள்.

llama-server -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf \
  -c 4096 -t 4 --host 127.0.0.1 --port 8080

-c என்பது டோக்கன்களில் சூழல் அளவு (context size), -t என்பது த்ரெட் எண்ணிக்கை (thread count), மற்றும் -ngl என்பது GPU-க்கு எத்தனை அடுக்குகள் (layers) செல்ல வேண்டும் என்பதைத் தீர்மானிக்கிறது (CPU மட்டும் உள்ள கணினியில் இது 0). இதில் எதுவும் தானாகக் கணிக்கப்படுவதில்லை.

Ollama-வில், நீங்கள் இழுக்கும் (pull) டேக் (tag) உடன் குவாண்டைசேஷன் இணைந்து வரும். ollama ls உங்கள் வட்டில் உள்ளதைச் சரியாகக் காட்டும். பதிவேட்டில் (registry) உங்களுக்குத் தேவையான கட்டமைப்பு இல்லையெனில், நீங்களே ஒரு GGUF-ஐ இறக்குமதி செய்யலாம். ஒரு Modelfile-ஐ உருவாக்கவும்:

FROM ./Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf
PARAMETER num_ctx 4096

பின்பு அதை உருவாக்கி முடிவைச் சரிபார்க்கவும்:

ollama create llama31-q4 -f ./Modelfile
ollama ls

சூழல் நீளம் (Context length) என்பது பலரைத் தடுமாற வைக்கும் அமைப்பாகும். Ollama தனக்குக் கிடைக்கும் VRAM-ஐப் பொறுத்து இயல்புநிலையைத் தேர்ந்தெடுக்கும்; GPU இல்லாத கணினியில் இது மிகச்சிறிய அளவான 4096 டோக்கன்களாக இருக்கும். 20,000 டோக்கன்கள் கொண்ட ஆவணத்தை அனுப்பினால், மாதிரி பார்ப்பதற்கு முன்பே கூடுதல் டோக்கன்கள் நீக்கப்படும். இதனால், பாதியளவு மட்டுமே படித்த கோப்பைப் பற்றி மாதிரி தவறான பதிலைத் தரும். இதைச் சரிசெய்ய OLLAMA_CONTEXT_LENGTH மூலம் daemon-ல் அல்லது PARAMETER num_ctx மூலம் Modelfile-ல் அளவை அதிகரிக்கவும். ஒரு குறிப்பிட்ட பணிக்கு மட்டும் பெரிய விண்டோ தேவைப்பட்டால், num_ctx-ஐ ஒவ்வொரு கோரிக்கைக்கும் தனித்தனியாக அமைக்கலாம், இது daemon-ன் மற்ற பணிகளுக்குத் தேவையற்ற cache சுமையைத் தவிர்க்கும். llama.cpp-லும் நம்பகமான இயல்புநிலை அமைப்பு எதுவும் இல்லை. -c-ஐத் தெளிவாக அமைத்து, எதை அமைத்தீர்கள் என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள்.

யாரும் சொல்லாத நினைவகக் கணக்கீடு (Memory arithmetic)

Model கோப்பு மட்டுமே மொத்தச் செலவு அல்ல. KV cache (key/value cache) என்பது ஒவ்வொரு layer-க்கும், ஒவ்வொரு context token-க்கும் ஒரு entry-ஐ வைத்திருக்கும். உரையாடல் வளர வளர இதுவும் வளரும்.

Llama 3.1 8B-க்கு இதைக் கணக்கிடுவோம். இந்த model-ல் 32 layers, 8 key/value heads மற்றும் 128 head dimension உள்ளன. ஒவ்வொரு token-ம் f16 வடிவில் தலா 2 bytes கொண்ட key மற்றும் value-ஐச் சேமிக்கும். எனவே, ஒரு layer-க்கு 2 x 8 x 128 x 2 = 4096 bytes தேவை. 32 layers-க்கு இது ஒரு token-க்கு 128 KiB ஆகும். எனவே, 4096 token context-க்கு 512 MiB-ம், 32,768 token context-க்கு 4 GiB-ம் தேவைப்படும்.

ஆகவே, 4k context கொண்ட ஒரு Q4_K_M 8B model-க்கு weights-க்காக 4.58 GiB, cache-க்காக சுமார் 0.5 GiB மற்றும் runtime-க்குத் தேவையான நினைவகம் தேவை. இது 4 GiB RAM-ல் இயங்காது. 8 GiB RAM-ல் போதுமான இடவசதியுடன் இயங்கும். அதே 8 GiB கணினியில் context-ஐ 32k ஆக உயர்த்தினால், cache மட்டுமே மொத்த இடத்தையும் எடுத்துக்கொள்ளும். Model load ஆகும்போது free -h மூலம் நேரலையில் இதைக் கவனியுங்கள்; நீங்களாக அளவிடாத எந்தவொரு மதிப்பீட்டையும் நம்ப வேண்டாம். நீங்கள் 8B-க்கும் அதிகமான model-களைத் திட்டமிடுகிறீர்கள் என்றால், a 27B model on a CPU-only VPS-ல் விவரிக்கப்பட்டுள்ள அதே கணக்கீடு, 8 GB முதல் 64 GB வரையிலான ஒவ்வொரு நிலையிலும் எவ்வளவு கொள்ளளவு இருக்கும் என்பதைக் காட்டும்.

Ollama இதை மேலும் பெருக்கும். OLLAMA_NUM_PARALLEL இயல்பாக 1 என இருக்கும். ஒரு model-க்குத் தேவைப்படும் நினைவகம், அந்த எண்ணையும் context length-ஐயும் பெருக்கினால் கிடைக்கும் அளவிற்கு உயரும். இரண்டையும் ஒரே நேரத்தில் அதிகரித்தால், நீங்கள் எதிர்பார்த்ததை விட பல மடங்கு அதிக RAM-ஐ daemon கேட்கும். ஒரே நேரத்தில் பல பயனர்கள் பயன்படுத்தும்போது, ஒவ்வொரு கோரிக்கைக்கும் தனித்தனி KV cache தேவைப்படுவதால், இந்த கணக்கீடே உங்கள் வரம்பைத் தீர்மானிக்கிறது. இதனால்தான் why a server that feels fine for one person stalls at five என்ற நிலை ஏற்படுகிறது.

அச்சு 2: நீங்கள் இயக்க வேண்டிய daemon

Ollama நிறுவல் script ஒரு systemd unit-ஐ எழுதி, ollama system user-ஐ உருவாக்கி, அந்தச் சேவையை enable செய்கிறது. நீங்கள் எதையும் எழுதாமலேயே lifecycle நிர்வாகத்தைப் பெறுகிறீர்கள். configuration-ஐ systemd மூலமாகவே கையாள வேண்டும்:

sudo systemctl edit ollama

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl daemon-reload
sudo systemctl restart ollama
journalctl -e -u ollama

OLLAMA_KEEP_ALIVE என்பது CPU VPS-ல் மற்ற இடங்களை விட மிக முக்கியமானது. மாதிரிகள் (models) முன்னிருப்பாக 5 நிமிடங்கள் நினைவகத்தில் (memory) வைக்கப்பட்டு, பின் நீக்கப்படுகின்றன. அடுத்த கோரிக்கையின் போது, முழு கோப்பையும் வட்டில் (disk) இருந்து மீண்டும் படிக்க வேண்டும். எனவே, 4.58 GiB அளவுள்ள கோப்பை மீண்டும் ஏற்றும்போது, மெதுவான சேமிப்பகத்தில் இரண்டு வினாடி பதில் முப்பது வினாடியாக மாறும். நீண்ட keep-alive அமைப்பானது இந்த latency-ஐச் சரிசெய்து, RAM-ஐ நிரந்தரமாகப் பயன்படுத்தும். இவை இரண்டுமே உண்மையான செலவுகள். எது குறைவான பாதிப்பை ஏற்படுத்துமோ அதைத் தேர்வு செய்யவும். மாதிரி எப்போதும் நினைவகத்தில் இருக்க வேண்டும் என்று நீங்கள் முடிவு செய்தால், keep_alive-ஐ அமைப்பதன் மூலம் அது செயலற்ற காலங்களிலும் reboot-க்குப் பிறகும் நீடிக்கும், இது சில வரிகளில் முடிந்துவிடும் மற்றும் ஒவ்வொரு முறை box restart ஆகும்போதும் மாதிரியை நீங்களே மீண்டும் தயார் செய்யும் வேலையைத் தவிர்க்கும்.

llama.cpp-ல் daemon கிடையாது, எனவே நீங்கள் unit-ஐ /etc/systemd/system/llama-server.service என நீங்களே எழுத வேண்டும்:

[Unit]
Description=llama.cpp server
After=network-online.target

[Service]
ExecStart=/usr/local/bin/llama-server -m /srv/models/model-Q4_K_M.gguf -c 4096 -t 4 --host 127.0.0.1 --port 8080
Restart=always
RestartSec=3
User=llama

[Install]
WantedBy=multi-user.target

இதை sudo systemctl enable --now llama-server மூலம் enable செய்யவும். இந்தச் செயல்முறை அதன் வாழ்நாள் முழுவதும் மாதிரியைத் தன் வசம் வைத்திருக்கும். செயலற்ற நிலையில் எதுவும் நீக்கப்படாது, எனவே திடீர் reload இருக்காது, சேவையை நிறுத்துவதைத் தவிர நினைவகத்தை மீட்டெடுக்க வேறு வழியும் இல்லை. unit-களை எழுதுவது உங்களுக்குப் புதியது என்றால், அது VPS-ல் systemd கீழ் உங்கள் சொந்தச் சேவைகளை இயக்குவது போன்ற அதே முறையே ஆகும்.

அச்சு 3: உங்கள் செயலி தொடர்பு கொள்ளும் API

இந்த அச்சு மிகவும் சுருங்கிவிட்டது. இரண்டு திட்டங்களும் இப்போது OpenAI chat format-ஐ ஆதரிக்கின்றன, எனவே base URL-ஐ மாற்றிய பிறகு பெரும்பாலான client libraries இரண்டிலும் வேலை செய்யும்.

Ollama 127.0.0.1:11434-ல் இயங்குகிறது. அதன் OpenAI-compatible route http://localhost:11434/v1/chat/completions ஆகும், மேலும் இது அதனுடன் சேர்த்து /api/chat-ல் ஒரு native API-ஐயும் கொண்டுள்ளது. Anthropic-compatible route-ம் ஆவணப்படுத்தப்பட்டுள்ளது.

curl -X POST http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model": "llama31-q4", "messages": [{"role": "user", "content": "Say this is a test"}]}'

llama-server ஆனது 127.0.0.1:8080-ல் இயங்கி, /v1/chat/completions, /v1/completions மற்றும் /v1/embeddings ஆகியவற்றை வழங்குகிறது. இதனுடன் அதன் சொந்த /completion endpoint மற்றும் உள்ளமைக்கப்பட்ட web UI ஆகியவையும் உள்ளன. இது Ollama-வில் இல்லாத செயல்பாட்டு வழித்தடங்களையும் (operational routes) வழங்குகிறது: readiness probe-க்கு /health, ஏற்றப்பட்ட model-ன் அமைப்புகளுக்கு /props, ஒவ்வொரு request slot-ன் செயல்பாட்டிற்கு /slots, மற்றும் Prometheus format-ல் /metrics. நீங்கள் இந்தச் சேவையை monitor செய்யத் திட்டமிட்டால், இந்த வேறுபாடே முடிவெடுக்கும் காரணியாக இருக்கும்.

எந்தவொரு server-ம் உங்களுக்காக authentication-ஐத் தானாகச் செயல்படுத்துவதில்லை. பாதுகாப்பு காரணங்களுக்காக இரண்டுமே இயல்பாக loopback-ல் இயங்குகின்றன. இவற்றை SSH tunnel மூலமாகவோ அல்லது reverse proxy-க்கு பின்னால் இருந்தோ அணுகுங்கள்; ஒருபோதும் 11434 அல்லது 8080 ports-ஐ இணையத்திற்குத் திறந்து வைக்காதீர்கள்.

CPU-மட்டும் கொண்ட VPS-ஆல் உண்மையாக என்ன செய்ய முடியும்

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

llama-bench -m ~/models/Meta-Llama-3.1-8B-Instruct-Q4_K_M.gguf -p 512 -n 128

pp நெடுவரிசை prompt செயலாக்க வேகத்தையும், tg நெடுவரிசை token உருவாக்கும் வேகத்தையும் குறிக்கிறது; இவை இரண்டும் ஒரு வினாடிக்கு எத்தனை tokens என்ற அளவில் கணக்கிடப்படுகின்றன. பகிரப்பட்ட vCPU திட்டத்தில், 8B மாடல் Q4_K_M நிலையில் இருக்கும்போது, tg-க்கு பொதுவாக ஒற்றை இலக்க வேகத்தையே தரும். Prompt செயலாக்கம் தான் அதிக பாதிப்பை ஏற்படுத்துகிறது: முதல் output token தோன்றுவதற்கு முன்பே முழு prompt-ம் செயலாக்கப்பட வேண்டும், எனவே நீண்ட system prompt ஒவ்வொரு கோரிக்கைக்கும் காத்திருப்பு நேரத்தை அதிகரிக்கும். பதிலின் நீளத்தை உங்களால் கட்டுப்படுத்த முடியும், ஏனெனில் வினாடிக்கு மூன்று tokens என்ற வேகத்தில் 600 tokens கொண்ட ஒரு நீண்ட பதில் மூன்று நிமிடங்கள் வரை அந்த server-ஐ ஆக்கிரமிக்கும், எனவே num_predict மூலம் output-ஐக் கட்டுப்படுத்துவது ஒரு நீண்ட பதில் timeout ஆவதைத் தடுப்பதற்கான மலிவான வழியாகும்.

CPU-வில் பயன்படுத்தக்கூடியவை: வகைப்படுத்துதல் (classification), பிரித்தெடுத்தல் (extraction), சுருக்கமான குறிப்புகள் (short summaries) அல்லது routing செய்யும் 1B முதல் 4B வரையிலான மாடல்கள். பதில்கள் சில வினாடிகளில் கிடைக்கும் மற்றும் நினைவகம் (memory) சாதாரண திட்டங்களுக்குள் அடங்கும். இந்த அளவில் ஒரு செயல்முறை உதாரணத்திற்கு, VPS-ல் Nemotron 3.5 Lightning-ஐ பதிவிறக்கி அளவிடுதல் என்ற கட்டுரை சரியான tag, அதற்குத் தேவையான RAM மற்றும் GPU இல்லாமல் அது தரும் வேகம் ஆகியவற்றை விளக்குகிறது. CPU-வில் பயன்படுத்த முடியாதவை: வாசிக்கும் வேகத்தில் நடக்கும் interactive chat, coding assistants, நீண்ட ஆவணப் பணிகள், அல்லது வரிசையாகப் பல அழைப்புகளைச் செய்யும் agent loop. நான்கு வினாடிகள் எடுக்கும் பன்னிரண்டு அழைப்புகளைக் கொண்ட ஒரு loop, முடிவைத் தருவதற்கு ஒரு நிமிடம் வரை எடுக்கும். ஒரு coding assistant-ஐ உருவாக்கத் திட்டமிட்டிருந்தால், நீங்கள் சொந்தமாக host செய்யும் மாடலில் agent-ஐப் பயன்படுத்துதல் என்ற கட்டுரை, சிறிய local மாடல்கள் எவற்றில் சிறப்பாகச் செயல்படும் மற்றும் எவை hosted API-ல் இருக்க வேண்டும் என்பதைத் தெளிவுபடுத்துகிறது.

எண்கள் சரியாக அமையாதபோது இரண்டு வழிகள் உள்ளன. சிக்கல் concurrency-ஆக இருந்தால், அதாவது பல பயனர்கள் ஒரே நேரத்தில் ஒரு மாடலை அணுகினால், engine-ஐ மாற்ற வேண்டும்; ஒரே நேரத்தில் பல கோரிக்கைகளைச் சமாளிக்க Ollama மற்றும் vLLM ஒப்பீடு இந்தத் தகவலை வழங்குகிறது. சிக்கல் வேகத்தைப் பொறுத்ததாக இருந்தால், GPU இணைக்கப்பட்ட VPS-ஐத் தேர்வு செய்வதே தீர்வாகும், அங்குதான் -ngl-க்கு அர்த்தம் இருக்கும். எதையும் செய்வதற்கு முன், வன்பொருளுக்கான baseline-ஐப் பெறுங்கள், ஏனெனில் disk மற்றும் memory bandwidth ஆகியவை CPU-வைப் போலவே load நேரத்தைத் தீர்மானிக்கின்றன. மீண்டும் செய்யக்கூடிய VPS benchmark-க்கு ஒரு மணிநேரம் செலவிடுவது பயனுள்ளது.

llama.cpp-ஐ நிறுவுதல் மற்றும் ஒரு குறிப்பிட்ட build-ஐ நிலைப்படுத்துதல் (pinning)

இரண்டு திட்டங்களும் வாரந்தோறும் மாற்றமடைவதால், நீங்கள் பயன்படுத்தும் version-ஐ குறித்து வைத்துக்கொள்ளுங்கள். Upstream-ல் உள்ள ஒற்றை வரி கட்டளை தற்போதைய build-ஐ நிறுவுகிறது:

curl -LsSf https://llama.app/install.sh | sh
llama serve -hf ggml-org/Qwen3.5-0.8B-GGUF

ஒரு குறிப்பிட்ட build-ஐ நிலைப்படுத்த, releases பக்கத்திலிருந்து முன்கூட்டியே தொகுக்கப்பட்ட (prebuilt) tarball-ஐப் பயன்படுத்தவும். 2 ஆகஸ்ட் 2026 நிலவரப்படி, b10224 என்பது தற்போதைய tag ஆகும்:

curl -LO https://github.com/ggml-org/llama.cpp/releases/download/b10224/llama-b10224-bin-ubuntu-x64.tar.gz
tar xf llama-b10224-bin-ubuntu-x64.tar.gz
find . -type f -name 'llama-server'

அல்லது அதே tag-ஐ source-லிருந்து தொகுக்கவும்:

sudo apt update && sudo apt install -y build-essential cmake git libssl-dev
git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
git checkout b10224
cmake -B build
cmake --build build --config Release -j $(nproc)

HTTPS வசதிகளுக்கு libssl-dev ஒரு தேவையான dependency என்று ஆவணப்படுத்தப்பட்டுள்ளது. தொகுக்கும் (compile) செயல்முறை பல நிமிடங்கள் எடுக்கும் மற்றும் மிகச்சிறிய திட்டங்களில் (plans) உள்ளதை விட அதிக RAM தேவைப்படும். எனவே, சிறிய server-ல் memory பற்றாக்குறை ஏற்பட்டால், பெரிய server-ல் தொகுத்துவிட்டு binaries-ஐ நகலெடுக்கவும்.

Ollama-வை நிறுவுதல், ஒரு குறிப்பிட்ட version-ல் நிலைநிறுத்துதல்

curl -fsSL https://ollama.com/install.sh | OLLAMA_VERSION=0.32.5 sh
ollama -v

இந்த script OLLAMA_VERSION-ஐ வாசிக்கிறது, எனவே இன்று வெளியிடப்பட்ட புதிய version-ஐ எடுப்பதற்குப் பதிலாக, உங்களுக்குத் தெரிந்த சரியான release-ஐ நீங்கள் பயன்படுத்தலாம். v0.32.5 ஆனது 27 July 2026 அன்று வெளியிடப்பட்டது. ஒரு script-ஐ நேரடியாக shell-க்கு pipe செய்ய விரும்பவில்லை என்றால், manual வழிமுறையும் உள்ளது:

sudo rm -rf /usr/lib/ollama
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst | sudo tar x -C /usr
ollama -v

இந்த manual வழிமுறை systemd unit-ஐயோ அல்லது service user-ஐயோ உருவாக்காது, எனவே அவற்றை நீங்கள் நீங்களே சேர்க்க வேண்டும். Ollama-வை VPS-ல் நிறுவுவதற்கான முழுமையான வழிகாட்டி அந்த service அமைப்பை படிப்படியாக விளக்குகிறது.

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

Ollama மாதிரியை (model) ஏற்ற மறுக்கிறது. ollama run இந்த வடிவிலான வரியை வழங்கும்:

Error: model requires more system memory (5.6 GiB) than is available (3.2 GiB)

Ollama ஏற்றுவதற்கு முன்பே அளவைச் சரிபார்க்கிறது, எனவே அது விரைவாகத் தோல்வியடைந்து அதற்கான காரணத்தைக் கூறுகிறது. ஒரு குவாண்டிசேஷன் (quantisation) வரிசை கீழே செல்லுங்கள், context length-ஐக் குறைக்கவும், அல்லது சிறிய மாதிரியைத் தேர்ந்தெடுக்கவும்.

llama.cpp தோல்வியடையவில்லை, ஆனால் மிக மெதுவாக இயங்குகிறது. llama.cpp இயல்பாகவே GGUF-ஐ memory-map செய்கிறது, எனவே RAM-ஐ விட பெரிய கோப்பும் தொடங்கும். ஒவ்வொரு டோக்கனுக்கும் கர்னல் (kernel) வட்டில் (disk) இருந்து எடையை (weights) உள்ளேயும் வெளியேயும் மாற்றுகிறது, இதனால் disk பயன்பாடு 100 சதவீதத்தை எட்டி, ஒரு டோக்கனுக்கு சில நொடிகள் என வேகம் குறைகிறது. உண்மையான ஒதுக்கீட்டை (allocation) கட்டாயப்படுத்த --no-mmap-ஐப் பயன்படுத்தவும், அப்போது அது தரம் குறைவதற்குப் பதிலாக உடனடியாகத் தோல்வியடையும். கர்னல் தலையிடும்போது, dmesg அதற்கான காரணத்தைக் காட்டும்:

Out of memory: Killed process 1234 (llama-server)

மாதிரிக் கோப்பு (model file) ஏற்றப்படவே இல்லை. உங்கள் இன்ஜினை விட புதிய மாடல் குடும்பத்திற்காக உருவாக்கப்பட்ட GGUF, தனக்குத் தெரியாத ஆர்க்கிடெக்சரைக் குறிப்பிட்டு பிழையைத் தரும்:

error loading model architecture: unknown model architecture: 'qwen3next'

இதற்கான தீர்வு இன்ஜினை மேம்படுத்துவது (upgrade), வேறு கோப்பைத் தேர்ந்தெடுப்பது அல்ல. இது pinning-ன் விளைவு, இதனால்தான் நீங்கள் build எண்ணைக் குறித்து வைக்க வேண்டும். நீங்கள் எதிலிருந்து மேம்படுத்துகிறீர்கள் என்பதை நீங்கள் அறிந்திருக்க வேண்டும்.

API உள்ளூர் அளவில் பதிலளிக்கிறது, ஆனால் உங்கள் ஆப் (app) மூலம் பதிலளிக்கவில்லை. Ollama 127.0.0.1:11434-ல் பிணைக்கப்பட்டுள்ளது (bind), எனவே மற்றொரு ஹோஸ்ட் இணைப்பை மறுக்கும் (connection refused). போர்ட் (port) ஒரு ஃபயர்வால் (firewall) அல்லது தனியார் நெட்வொர்க்கிற்குப் பின்னால் இருக்கும்போது மட்டுமே OLLAMA_HOST=0.0.0.0:11434-ஐ systemctl edit ollama மூலம் அமைக்கவும், ஏனெனில் இந்த API-க்கு முன்னால் அங்கீகாரம் (authentication) இல்லை.

இடைவேளைக்குப் பிறகு வரும் முதல் பதில் மிக மெதுவாக உள்ளது. 5 நிமிட செயலற்ற நிலை (idle) காரணமாக unload நிகழ்ந்துவிட்டது, மாதிரி மீண்டும் வட்டில் இருந்து படிக்கப்படுகிறது. கோரிக்கைக்குச் சற்று முன்பு ollama ps-ஐ இயக்கினால் எதுவும் ஏற்றப்படவில்லை என்று காட்டும், இதுவே அதை உறுதிப்படுத்துகிறது. OLLAMA_KEEP_ALIVE-ஐ அதிகரிக்கவும்.

எதை நீங்கள் இயக்க வேண்டும்?

உங்களுக்கு மாதிரிகள் (models) நிர்வகிக்கப்பட வேண்டும் மற்றும் கூடுதல் வேலைகள் இன்றி OpenAI போன்ற endpoint தேவைப்படும்போது Ollama-வை இயக்கவும். முதல்முறை deployment செய்வதற்கும், அடிக்கடி மாதிரிகளை மாற்ற வேண்டிய சூழல்களுக்கும் இதுவே சரியான தேர்வாகும்.

நினைவகத் திறன் (memory) குறைவாக இருந்து, நீங்களே quantisation வரிசையைத் தேர்ந்தெடுக்க வேண்டியிருக்கும்போது, கண்காணிப்பிற்காக /health, /slots மற்றும் /metrics தேவைப்படும்போது, அல்லது Ollama வழங்காத ஒரு குறிப்பிட்ட flag தேவைப்படும்போது llama.cpp-ஐ நேரடியாக இயக்கவும். ஒரு VPS-ல் மாதிரி மிகக் குறைந்த இடவசதியிலேயே பொருந்தும் சூழலில் இதுவே சிறந்த தேர்வாகும், ஏனெனில் அந்த மாதிரியைப் பொருத்துவதற்குத் தேவையான அமைப்புகளை Ollama உங்களுக்காகவே தானாகவே கையாள்கிறது.

இவ்விரண்டையும் இயக்குவது இயல்பான ஒன்றுதான். சோதனைகளுக்கு Ollama-வையும், production-ல் வைத்து மாற்றாமல் பயன்படுத்த விரும்பும் ஒரு குறிப்பிட்ட மாதிரிக்கு llama.cpp-யையும் பயன்படுத்தலாம்.

FAQ

Ollama என்பது llama.cpp-ன் வெறும் wrapper மட்டும்தானா?

இல்லை, இது வெறும் wrapper மட்டுமல்ல, கூடுதல் பணிகளையும் செய்கிறது. Ollama-வின் README, llama.cpp-ஐ அதன் inference backend-ஆகக் குறிப்பிடுகிறது (2 August 2026 அன்று சரிபார்க்கப்பட்டது). அதன் மேல், Ollama ஒரு model registry, chat செய்திகளை prompt-ஆக மாற்றும் prompt template, இயல்பான sampling parameters, idle நிலையில் இருக்கும்போது model-ஐ நீக்கும் daemon, மற்றும் ஒரு HTTP API ஆகியவற்றை வழங்குகிறது. ஒரே மாதிரியான அமைப்புகளில் tokens per second-ஐ ஒப்பிடும்போது, நீங்கள் ஒரே engine-ஐத்தான் ஒப்பிடுகிறீர்கள். நீங்கள் உண்மையில் தேர்வு செய்வது அதன் மேலாண்மை அடுக்கு (management layer) ஆகும்.

CPU-மட்டும் கொண்ட VPS-ல் எது வேகமானது?

இரண்டும் ஒரே engine-ஐப் பயன்படுத்துவதால், ஒரே model file, quantisation, context size மற்றும் thread count ஆகியவற்றைப் பயன்படுத்தும்போது அவற்றின் வேகம் சமமாகவே இருக்கும். மக்கள் தெரிவிக்கும் வேறுபாடுகள் பெரும்பாலும் engine-ஆல் ஏற்படுவதில்லை; மாறாக, context length மற்றும் thread count போன்ற இயல்பான அமைப்புகளில் (defaults) ஏற்படும் மாற்றங்களாலேயே ஏற்படுகின்றன. எந்தவொரு தரவையும் நம்புவதற்கு முன், llama-bench -m <file> -p 512 -n 128 மூலம் நீங்களே அளவிட்டு, உங்கள் server-ல் உள்ள tg column-ஐ ஒப்பிட்டுப் பாருங்கள்.

Ollama-வில் எனது சொந்த GGUF கோப்பைப் பயன்படுத்த முடியுமா?

ஆம். கோப்பை server-ல் பதிவேற்றி, ஒரு Modelfile-ஐ உருவாக்கவும். அதன் முதல் வரியாக FROM ./your-model.gguf இருக்க வேண்டும். உங்களுக்குத் தேவையான PARAMETER வரிகளைச் சேர்க்கவும் (உதாரணமாக num_ctx). பிறகு ollama create your-name -f ./Modelfile கட்டளையை இயக்கவும். ollama ls கட்டளையானது, நீங்கள் registry-யிலிருந்து பதிவிறக்கிய மற்ற மாடல்களுடன் இதையும் பட்டியலிடும். registry-யில் இல்லாத quantisation-ஐப் பயன்படுத்த இதுவே வழி.

8B model-க்கு எவ்வளவு RAM தேவை?

கோப்பின் அளவு, KV cache, மற்றும் runtime ஆகியவற்றை கணக்கில் கொள்ள வேண்டும். Llama 3.1 8B-ன் Q4_K_M build, வட்டில் சுமார் 4.58 GiB அளவு இருக்கும். 4096 token context-க்கு சுமார் 512 MiB cache தேவைப்படும். எனவே, 8 GiB RAM போதுமானது, ஆனால் 4 GiB போதாது. Cache அளவு context-க்கு ஏற்ப அதிகரிக்கும்: அதே மாடலுக்கு 32,768 token context-ல் சுமார் 4 GiB cache தேவைப்படும். Ollama-வைப் பயன்படுத்தும்போது, இந்தத் தேவை OLLAMA_NUM_PARALLEL-ஐப் பொறுத்தும் அதிகரிக்கும் என்பதை நினைவில் கொள்க.