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

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

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

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

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

llama.cpp என்பது ggml library-ஐ அடிப்படையாகக் கொண்டு உருவாக்கப்பட்ட transformer inference-ன் C மற்றும் C++ செயலாக்கம் ஆகும். இது GGUF கோப்புகளை வாசிக்கிறது. GGUF (GGML universal file format) என்பது ஒரு 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-உடன் தொடர்பு கொள்கிறது. இவை இரண்டிற்கும் பின்னால், முன்கூட்டியே தொகுக்கப்பட்ட 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 என்ற இடத்தில் சேமிக்கிறது.

இந்த பேக்கேஜிங் முறையே அவற்றுக்கிடையேயான முழுமையான வேறுபாடு ஆகும். 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-ல், இந்த ஒரு தேர்வுதான் மாதிரி இயங்குமா இல்லையா என்பதைத் தீர்மானிக்கிறது.

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-க்குச் செல்ல வேண்டும் என்பதை அமைக்கிறது (CPU-மட்டும் கொண்ட பெட்டியில் இது 0). இதில் எதுவும் தானாகக் கணிக்கப்படுவதில்லை.

Ollama-வில், நீங்கள் இழுக்கும் (pull) டேக்-உடன் குவாண்டைசேஷன் இணைந்து வரும், மேலும் 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 டோக்கன் கொண்ட ஆவணத்தை அனுப்பினால், கூடுதல் டோக்கன்கள் மாதிரிக்குச் செல்வதற்கு முன்பே நீக்கப்படும். இதனால், பாதியளவு மட்டுமே படித்த கோப்பைப் பற்றி மாதிரி தவறான பதிலை உறுதியாக அளிக்கும். இதை daemon-ல் OLLAMA_CONTEXT_LENGTH மூலமாகவோ அல்லது Modelfile-ல் PARAMETER num_ctx மூலமாகவோ அதிகரிக்கவும். llama.cpp-லும் நம்பகமான இயல்புநிலை எதுவும் இல்லை. -c-ஐத் தெளிவாக அமைத்து, நீங்கள் எதை அமைத்துள்ளீர்கள் என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள்.

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

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

Llama 3.1 8B-க்கு இதைக் கணக்கிடுவோம். இந்த model-ல் 32 layers, 8 key/value heads மற்றும் 128 head dimension உள்ளன. ஒவ்வொரு token-ம் key மற்றும் value ஆகிய இரண்டையும் f16 வடிவில் தலா 2 bytes-ல் சேமிக்கிறது. எனவே, ஒரு 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 மூலம் நேரலையாகக் கவனியுங்கள்; நீங்களாக அளவிடாத எந்தவொரு மதிப்பீட்டையும் நம்ப வேண்டாம்.

Ollama இதை மேலும் அதிகரிக்கும். OLLAMA_NUM_PARALLEL இயல்பாக 1 என இருக்கும். ஒரு model-க்குத் தேவையான நினைவகம், அந்த எண்ணையும் context length-ஐயும் பெருக்கினால் கிடைக்கும் அளவிற்கு அதிகரிக்கும். இரண்டையும் ஒரே நேரத்தில் உயர்த்தினால், நீங்கள் எதிர்பார்த்ததை விட பல மடங்கு அதிக RAM-ஐ daemon கேட்கும்.

அச்சு 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 நேரத்தை அமைப்பது இந்தத் தாமதத்தைச் சரிசெய்து, RAM-ஐ நிரந்தரமாகப் பயன்படுத்தும். இவை இரண்டுமே உண்மையான செலவுகள். உங்களுக்கு எது குறைவான பாதிப்பை ஏற்படுத்துமோ அதைத் தேர்ந்தெடுக்கவும்.

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

[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 வடிவத்தைப் பயன்படுத்துகின்றன, எனவே base URL-ஐ மாற்றிய பிறகு பெரும்பாலான client libraries இரண்டிலும் வேலை செய்யும்.

Ollama 127.0.0.1:11434-ல் இயங்குகிறது. இதன் OpenAI-க்கு இணக்கமான route http://localhost:11434/v1/chat/completions ஆகும், மேலும் இது அதன் சொந்த native API-ஐ /api/chat-ல் தொடர்ந்து வழங்குகிறது. Anthropic-க்கு இணக்கமான 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-வில் இல்லாத செயல்பாட்டு route-களையும் இது வழங்குகிறது: readiness probe-க்காக /health, ஏற்றப்பட்ட model-ன் அமைப்புகளுக்காக /props, ஒவ்வொரு request slot-ன் செயல்பாட்டைக் காண /slots, மற்றும் Prometheus வடிவத்தில் /metrics. நீங்கள் இந்தச் சேவையை monitor செய்யத் திட்டமிட்டால், இந்த வேறுபாடே முடிவெடுப்பதற்கான காரணியாக இருக்கும்.

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

CPU-மட்டும் கொண்ட VPS-ன் உண்மையான திறன்

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

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

pp நெடுவரிசை prompt செயலாக்க வேகத்தையும், tg நெடுவரிசை token உருவாக்கும் வேகத்தையும் குறிக்கிறது; இவை இரண்டும் வினாடிக்கு எத்தனை tokens (tokens per second) என்ற அடிப்படையில் அளவிடப்படுகின்றன. பகிரப்பட்ட vCPU திட்டத்தில், 8B மாதிரியானது Q4_K_M அளவில் இயங்கும்போது, tg-ல் ஒற்றை இலக்க வேகத்தையே பெரும்பாலும் எட்டும். Prompt செயலாக்கமே இதில் சவாலான பகுதி: முதல் output token தோன்றுவதற்கு முன்பே முழு prompt-ம் செயலாக்கப்பட வேண்டும். எனவே, நீண்ட system prompt ஒவ்வொரு கோரிக்கைக்கும் (request) காத்திருப்பு நேரத்தை அதிகரிக்கும்.

CPU-ல் பயன்படுத்தக்கூடியவை: வகைப்படுத்துதல் (classification), தரவு பிரித்தெடுத்தல் (extraction), சுருக்கமான தொகுப்பு (short summaries) அல்லது routing செய்யும் 1B முதல் 4B வரையிலான மாதிரிகள். பதில்கள் சில வினாடிகளில் கிடைக்கும், மேலும் நினைவகத் தேவையும் சாதாரண திட்டங்களுக்குள் அடங்கும். CPU-ல் பயன்படுத்த முடியாதவை: வாசிப்பு வேகத்தில் நடக்கும் உரையாடல் (interactive chat), நிரலாக்க உதவியாளர்கள் (coding assistants), நீண்ட ஆவணப் பணிகள் அல்லது தொடர்ச்சியாகப் பல அழைப்புகளைச் செய்யும் agent loop. தலா நான்கு வினாடிகள் எடுக்கும் பன்னிரண்டு அழைப்புகளைக் கொண்ட ஒரு loop, முடிவுகளைத் தருவதற்கு ஒரு நிமிடம் வரை எடுத்துக்கொள்ளும்.

எண்கள் சரியாக அமையாதபோது இரண்டு தீர்வுகள் உள்ளன. சிக்கல் concurrency-ஆக இருந்தால், அதாவது ஒரே நேரத்தில் பல பயனர்கள் ஒரு மாதிரியை அணுகினால், engine தேர்வை மாற்ற வேண்டும். Ollama மற்றும் vLLM-ன் concurrent serving ஒப்பீடு இதற்கான விளக்கத்தை அளிக்கிறது. சிக்கல் அடிப்படை வேகத்தில்தான் என்றால், GPU இணைக்கப்பட்ட VPS-ஐத் தேர்ந்தெடுப்பதே தீர்வு; அங்குதான் -ngl-ன் மதிப்பு அர்த்தமுள்ளதாகிறது. எதையும் செய்வதற்கு முன், வன்பொருளின் அடிப்படைத் திறனை (baseline) அளவிடவும்; ஏனெனில் வட்டு (disk) மற்றும் நினைவக அலைவரிசை (memory bandwidth) ஆகியவை CPU-க்கு இணையாக சுமை நேரத்தைத் தீர்மானிக்கின்றன. மீண்டும் செய்யக்கூடிய 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 நிலவரப்படி, build 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-ல் போதிய நினைவகம் இல்லையெனில், பெரிய server-ல் தொகுத்துவிட்டு binaries-ஐ நகலெடுக்கவும்.

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

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

இந்த script OLLAMA_VERSION-ஐ வாசிக்கும், எனவே இன்று வெளியிடப்பட்ட புதிய பதிப்பிற்குப் பதிலாக, உங்களுக்குத் தெரிந்த சரியான பதிப்பை நீங்கள் பயன்படுத்தலாம். 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 தானாக உருவாக்கப்படாது, எனவே அவற்றை நீங்கள் நீங்களே உருவாக்க வேண்டும். VPS-ல் Ollama-வை முழுமையாக நிறுவுவதற்கான வழிகாட்டி அந்த service அமைப்பை படிப்படியாக விளக்குகிறது.

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

Ollama மாதிரியை ஏற்ற மறுக்கிறது. 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-ஐ விட பெரிய கோப்பும் தொடங்குகிறது. ஒவ்வொரு token-க்கும் கர்னல் வட்டில் (disk) இருந்து எடைகளை (weights) உள்ளேயும் வெளியேயும் மாற்றுகிறது, இதனால் வட்டு 100 சதவீதம் பயன்பாட்டில் இருந்து, ஒரு token-க்கு பல நொடிகள் வரை தாமதம் ஏற்படுகிறது. உண்மையான ஒதுக்கீட்டை (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). OLLAMA_HOST=0.0.0.0:11434-ஐ systemctl edit ollama வழியாக அமைக்கவும், ஆனால் போர்ட் ஒரு firewall அல்லது private network-க்கு பின்னால் இருக்கும்போது மட்டுமே இதைச் செய்யவும், ஏனெனில் இந்த API-க்கு முன்னால் அங்கீகாரம் (authentication) இல்லை.

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

எதை இயக்க வேண்டும்?

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

நினைவகப் பற்றாக்குறை (memory constraint) காரணமாக நீங்களே 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 போன்ற வெவ்வேறு இயல்புநிலை அமைப்புகளாலேயே ஏற்படுகின்றன. எந்தவொரு தரவையும் நம்புவதற்கு முன், உங்கள் server-ல் llama-bench -m <file> -p 512 -n 128 மூலம் அளவிட்டு, tg column-ஐ ஒப்பிட்டுப் பாருங்கள்.

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

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

8B மாதிரியை இயக்க எனக்கு எவ்வளவு RAM தேவை?

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