VPS-ல் Ollama-வை பாதுகாப்பாக நிறுவுவது எப்படி?

நீங்கள் உருவாக்குவது

உங்கள் சொந்த server-ல் இயங்கும் ஒரு open-weight language model-ஐ, HTTP API மூலமாகவும், விருப்பப்பட்டால் உங்கள் browser-ல் ஒரு chat பக்கம் மூலமாகவும் அணுகலாம். Ollama என்பது மாதிரியை (model) தரவிறக்கம் செய்து, அதை memory-ல் ஏற்றி, http://127.0.0.1:11434-ல் கோரிக்கைகளை (requests) கையாளும் மென்பொருளாகும். இதை நிறுவுவதற்கு ஒரே ஒரு command போதுமானது. இதில் கடினமான பகுதிகள் வேறு இடங்களில் உள்ளன: உங்கள் VPS-ன் RAM-ல் பொருந்தக்கூடிய மாதிரியைத் தேர்ந்தெடுப்பது மற்றும் அங்கீகாரம் (authentication) இல்லாத inference server-ஐ தவறுதலாக இணையம் முழுவதற்கும் பகிராமல் இருப்பது.

முதலில் இரண்டு எச்சரிக்கைகள். CPU-மட்டும் கொண்ட VPS-ல் சிறிய மாதிரிகள் மெதுவாகவே இயங்கும், மேலும் API-ல் உள்ளமைக்கப்பட்ட அங்கீகார வசதி (built-in authentication) எதுவும் இல்லை. இவை இரண்டைப் பற்றியும் கீழே விரிவாகக் கொடுக்கப்பட்டுள்ளது, ஏனெனில் இவைதான் பயனர்களுக்குப் பாதிப்பை ஏற்படுத்தக்கூடிய இடங்களாகும்.

எளிய எண்களில் அளவு குறித்த உண்மைச் சரிபார்ப்பு

ஒரு model-ன் memory footprint பொதுவாக அதன் file size-க்கு சமமாக இருக்கும். அதனுடன் சுமார் 1 gigabyte runtime overhead மற்றும் context window-க்குத் தேவையான கூடுதல் memory சேரும். llama3.2:3b, llama3.1:8b மற்றும் mistral:7b உட்பட பெரும்பாலான பிரபலமான Ollama models-ன் default tags, 4-bit quantized ஆகும். இவை Q4_K_M எனக் குறிக்கப்படும். ஒவ்வொரு 1 billion parameters-க்கும் சுமார் அரை gigabyte RAM தேவைப்படும். எல்லா default models-உம் Q4 ஆக இருப்பதில்லை. smollm2:135m போன்ற சிறிய models 16-bit நிலையில் release செய்யப்படுகின்றன. எனவே கணக்கிடுவதற்கு முன், அந்த model-ன் library page-ல் உள்ள quantization line-ஐ சரிபார்க்கவும். கணிதம் எளிதானது. அதுவே அனைத்தையும் தீர்மானிக்கும். கடைசி memory பகுதியை நீங்களே அமைக்கிறீர்கள்: Ollama-ன் சிறிய default-ஐ விட num_ctx-ஐ அதிகரிப்பது நீளமான prompts-க்கு இடமளிக்கும். ஆனால் RAM-ல் உள்ள KV cache பெரிதாகும். எனவே ஒரு model பொருந்துமா என்பதை மதிப்பிடுவதற்கு முன் context length-ஐ முடிவு செய்யவும்.

llama3.2:3b போன்ற 3B model-ஐ download செய்ய சுமார் 2 GB தேவைப்படும். அதை இயக்க சுமார் 4 GB free RAM தேவைப்படும். mistral:7b அல்லது llama3.1:8b போன்ற 7B அல்லது 8B model disk-ல் சுமார் 5 GB இடம் எடுத்துக்கொள்ளும். இதற்கு சுமார் 8 GB RAM தேவைப்படும். வசதியாக இயக்க 16 GB RAM தேவைப்படும். 13B அல்லது 14B model-க்கு சுமார் 16 GB RAM தேவைப்படும். 30B முதல் 70B வரையிலான எந்த model-க்கும் அதிக RAM கொண்ட server அல்லது நடைமுறையில் GPU தேவைப்படும். CPU VPS-ல் அது பொருந்தாமல் போகலாம். பொருந்தினாலும், பயன்படாத அளவுக்கு மெதுவாக பதிலளிக்கும்.

இப்போது speed பற்றி பார்க்கலாம். இதை பலர் குறைவாக மதிப்பிடுகின்றனர். CPU inference, clock speed-ஆல் அல்ல, memory bandwidth-ஆல் கட்டுப்படுத்தப்படுகிறது. Shared vCPU VPS-ல் memory bandwidth குறைவாக இருக்கும். Single-digit முதல் low-double-digit tokens per second வரை எதிர்பார்க்கலாம். 7-8B Q4 model ஒன்று 4 முதல் 10 tokens per second வரை செயல்படலாம். 3B model ஒன்று 10 முதல் 25 tokens per second வரை செயல்படலாம். GPU பொதுவாக இதைவிட சுமார் 10 மடங்கு வேகமாக இருக்கும். இவை திட்டமிட்டு தோராயமாகக் கொடுக்கப்பட்டுள்ள figures. உங்கள் server-ஐ நீங்களே அளவிடுவதே சரியான நடைமுறை. கீழே உள்ள run step அதை எவ்வாறு செய்வது என்பதைக் காட்டுகிறது. எந்தக் கட்டுரையிலும் உள்ள எண்ணை நம்ப வேண்டாம். இந்தக் கட்டுரையில் உள்ள எண்ணையும் நம்ப வேண்டாம். உங்கள் eval rate-ஐ நம்புங்கள்.

நடைமுறை முடிவு இதுதான்: CPU-ல் இயங்கும் சிறிய quantized models, வேகம் ஏற்றுக்கொள்ளக்கூடியதாக இருந்தால், drafting, summarizing மற்றும் classification பணிகளுக்கு உண்மையில் பயனுள்ளதாக இருக்கும். பெரிய அல்லது வேகமான model தேவைப்பட்டால், GPU instance-க்கான செலவைத் திட்டமிடவும். ஒரு குறிப்பிட்ட model-ல் இந்தக் கணக்கை தொடக்கம் முதல் முடிவு வரை பார்க்க விரும்பினால், VPS-ல் Nemotron 3.5 Lightning-ஐ இயக்குதல் எந்த tag-ஐ pull செய்ய வேண்டும், உண்மையில் எவ்வளவு RAM தேவைப்படும், CPU-only போதுமான வேகத்தில் இயங்குமா என்பவற்றை விளக்குகிறது.

ஒரு குறிப்பிட்ட model-ஐ ஒரு குறிப்பிட்ட server-உடன் ஒப்பிட, அதன் memory footprint-ஐ இங்கே மதிப்பிடவும்:

Ollama-ஐ நிறுவுதல்

இதற்கு இரண்டு தெளிவான வழிகள் உள்ளன. ஒரு bare VPS-ல் அதிகாரப்பூர்வ script-ஐப் பயன்படுத்துவது மிகவும் எளிதானது:

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

இது ollama என்ற பெயரில் ஒரு system user-ஐ உருவாக்குகிறது, binary-ஐ /usr/local/bin/ollama-ல் நிறுவுகிறது, மேலும் boot-ன் போது தொடங்கி 127.0.0.1:11434-ல் இயங்கும் ollama.service என்ற systemd service-ஐப் பதிவு செய்கிறது. இது இயங்குகிறதா என்பதை உறுதிப்படுத்தவும்:

systemctl status ollama
ollama --version

நீங்கள் ஏற்கனவே Docker-ஐப் பயன்படுத்துகிறீர்கள் என்றால், அதற்குப் பதிலாக container-ஐப் பயன்படுத்தவும்:

docker run -d --name ollama \
  -p 127.0.0.1:11434:11434 \
  -v ollama:/root/.ollama \
  --restart always \
  ollama/ollama

Port mapping-ல் உள்ள 127.0.0.1: முன்னொட்டைக் கவனிக்கவும். இது port-ஐ localhost-ல் மட்டுமே பிணைக்கிறது (bind). இதற்குப் பதிலாக -p 11434:11434 என்று எழுதினால், அது அனைத்து interface-களிலும் வெளியாகும்; இதுவே பாதுகாப்புப் பகுதியில் எச்சரிக்கப்படும் தவறாகும். ஏதேனும் ஒரு நிறுவல் முறையைத் தேர்ந்தெடுக்கவும்; script மற்றும் container இரண்டையும் ஒரே நேரத்தில் இயக்க வேண்டாம், இல்லையெனில் இரண்டு process-களும் ஒரே port-க்காகப் போட்டியிடும்.

உங்கள் முதல் model-ஐ பதிவிறக்கி இயக்குதல்

ollama pull llama3.2:3b
ollama run llama3.2:3b

pull கட்டளையானது model-ன் அடுக்குகளை (layers) வட்டில் (disk) பதிவிறக்கும் (இதற்கு சுமார் 2 GB தேவைப்படும்). run கட்டளையானது அவற்றை நினைவகத்தில் (memory) ஏற்றி, உங்களை >>> prompt-க்குக் கொண்டு செல்லும். ஒரு கேள்வியைத் தட்டச்சு செய்யவும். வட்டில் இருந்து RAM-க்கு weights ஏற்றப்படும்போது முதல் token-ஐ உருவாக்க சில நொடிகள் ஆகலாம், அதன் பிறகு பதில் திரையில் தோன்றும். உரையாடலில் இருந்து வெளியேற /bye என்று தட்டச்சு செய்யவும்; Ollama பின்னணியில் தொடர்ந்து இயங்கிக்கொண்டிருக்கும்.

எவை ஏற்றப்பட்டுள்ளன மற்றும் அவை எவ்வாறு பொருந்துகின்றன என்பதைப் பார்க்க:

ollama ps

PROCESSOR நெடுவரிசை உண்மையான நிலையைத் தெரிவிக்கும். 100% CPU என்பது GPU பயன்படுத்தப்படவில்லை என்பதைக் குறிக்கிறது, வேகம் குறைவாக இருப்பதற்கு இதுவே காரணம். verbose flag-ஐப் பயன்படுத்தி உண்மையான வேகத்தை அளவிடவும்:

ollama run --verbose llama3.2:3b "Write two sentences about Linux."

முடிவில் அச்சிடப்படும் eval rate வரியானது, இந்த வன்பொருளில் (hardware) ஒரு வினாடிக்கு எத்தனை tokens உருவாக்கப்படுகின்றன என்பதைக் குறிக்கும். இதைக் கொண்டே நீங்கள் திட்டமிட வேண்டும்.

மாதிரிகள் சேமிக்கப்படும் இடம் மற்றும் தேவையான வட்டு அளவு

ஸ்கிரிப்ட் மூலம் நிறுவப்பட்டு, service-ஆக இயங்கும்போது, மாதிரிகள் ollama பயனரின் home directory-ல் சேமிக்கப்படும்:

sudo du -sh /usr/share/ollama/.ollama/models

உங்கள் சொந்த பயனராக interactive முறையில் இயக்கும்போது, அவை ~/.ollama/models-ல் அமையும். Container-க்குள் அவை ollama என்ற பெயரிடப்பட்ட volume-ல் இருக்கும். Quantized weights விரைவாக இடத்தைப் பிடிக்கும் என்பதால் இது முக்கியமானது: ஒரு 3B மாதிரி ~2 GB, ஒரு 7-8B மாதிரி ~5 GB, ஒரு 14B மாதிரி ~9 GB அளவு இருக்கும். நான்கு மாதிரிகளை ஒப்பிட்டுப் பார்க்க அவற்றை download செய்தால், கவனிக்காமலேயே 20 GB இடம் செலவாகிவிடும். நீங்கள் வைத்திருக்க விரும்பும் மாதிரிகளுக்கு ஏற்ப வட்டு அளவைத் தீர்மானியுங்கள், மீதமுள்ளவற்றை ollama rm <model> மூலம் நீக்கிவிடுங்கள். அதே VPS-ல் ஏற்கனவே அதிக இடம் தேவைப்படும் பிற சேவைகள், உதாரணமாக புகைப்பட நூலகத்தை வைத்திருக்கும் PhotoPrism அல்லது Immich போன்றவை இயங்கினால், அந்த இடத்தை மொத்தக் கொள்ளளவிலிருந்து கழித்துவிட்டு, மீதமுள்ளதை உங்கள் மாதிரிகளுக்கான உண்மையான பட்ஜெட்டாகக் கருதுங்கள்.

நீங்கள் கட்டுப்படுத்தும் service-ஆக இயக்கவும்

Install script ஏற்கனவே ollama.service-ஐ பதிவு செய்துவிட்டது. எனவே கூடுதல் பணியின்றி boot நேரத்தில் அது restart ஆகும். மாற்ற வேண்டிய முக்கிய setting, model memory-ல் எவ்வளவு நேரம் resident ஆக இருக்க வேண்டும் என்பதாகும். சில setups-ல் bind address-ஐயும் மாற்ற வேண்டியிருக்கும். இந்த இரண்டு settings-ஐயும் systemd drop-in-ல் வைக்க வேண்டும். அப்போது Ollama upgrade அவற்றை overwrite செய்யாது:

sudo systemctl edit ollama.service

Editor காட்டும் [Service] header-ன் கீழ் இதைச் சேர்க்கவும்:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

கடைசி request-க்கு பிறகு ஒரு model memory-ல் எவ்வளவு நேரம் இருக்க வேண்டும் என்பதை OLLAMA_KEEP_ALIVE குறிப்பிடுகிறது. இதன் default 5 minutes. நாள் முழுவதும் query செய்யும் box-ல் இதை அதிகரிக்கவும். அப்போது ஒவ்வொரு முறையும் weights-ஐ மீண்டும் load செய்ய வேண்டியதில்லை. RAM குறைவாக உள்ள box-ல் request முடிந்தவுடன் memory-ஐ விடுவிக்க இதை 0 என அமைக்கவும். ஒரு model-ஐ குறிப்பிட்ட காலத்திற்கு பதிலாக நிரந்தரமாக resident நிலையில் வைத்திருக்க விரும்பினால், Ollama model-ஐ நிரந்தரமாக loaded நிலையில் வைத்திருத்தல் என்ற பகுதியில் per-request keep_alive field பற்றியும், reboot பிறகு முதல் slow request நேரத்தில் அல்லாமல் முன்கூட்டியே weights மீண்டும் warm ஆவது பற்றியும் விளக்கப்பட்டுள்ளது. systemctl edit unit files-ஐ உங்களுக்காக reload செய்யும். எனவே மாற்றத்தைப் பயன்படுத்த restart செய்யவும்:

sudo systemctl restart ollama

மிகவும் முக்கியமான security அம்சம்

இயல்பாக Ollama 127.0.0.1:11434-க்கு bind ஆகும். எனவே VPS-ல் இயங்கும் processes மட்டுமே அதை அணுக முடியும். இந்த default சரியானது. இதையே வைத்திருக்கவும்.

API-ல் authentication இல்லை. முற்றிலும் இல்லை. API key இல்லை, login இல்லை, rate limit இல்லை. இதில் உள்ள ஒரே allow-list ஆன OLLAMA_ORIGINS, எந்த browser origins இதை அழைக்கலாம் என்பதை மட்டும் கட்டுப்படுத்துகிறது (CORS). வேறு machine-ல் இயங்கும் curl அல்லது script-ஐ தடுக்க இது எந்த உதவியும் செய்யாது. Port 11434-ஐ அணுகக்கூடிய எவரும் நீங்கள் pull செய்துள்ள எந்த model-ஐயும் இயக்கலாம், புதியவற்றை pull செய்யலாம், அவற்றை delete செய்யலாம், மேலும் உங்கள் CPU அல்லது GPU-ஐ நீண்ட நேரம் முழு load-ல் வைத்திருக்கலாம். Shodan போன்ற scanners திறந்திருக்கும் Ollama instances-ஐ ஆயிரக்கணக்கில் index செய்கின்றன. வெளிப்படுத்தப்பட்ட instance சில மணி நேரங்களுக்குள் கண்டறியப்பட்டு தவறாகப் பயன்படுத்தப்படும்.

எனவே ஒருபோதும் செய்யக்கூடாத ஒரே தவறு இதுதான்: OLLAMA_HOST=0.0.0.0-ஐ அமைத்து உங்கள் firewall-ல் 11434-ஐ திறக்க வேண்டாம். இது authentication இல்லாத inference server-ஐ முழு internet-க்கும் வெளியிடும். Raw 11434-on-0.0.0.0 அமைப்பை எந்த configuration-மும் பாதுகாப்பானதாக மாற்றாது. காரணம், Ollama-வின் documented settings எதுவும் local API-க்கு authentication சேர்ப்பதில்லை. Origin allow-list என்பது login அல்ல. இது இந்த particular service-க்கு உரிய விதி மட்டுமே; port-ஐ ஒருபோதும் திறக்கக்கூடாது என்பதல்ல: remote desktop-க்கான self-hosted RustDesk relay தனது பணியைச் செய்ய public traffic-ஐ ஏற்க வேண்டும். அதற்காக அது தனது key-based authentication-ஐயும், குறுகிய மற்றும் documented port பட்டியலையும் கொண்டுள்ளது. Ollama-வில் இவை இரண்டும் இல்லை.

இந்த model-ஐ server-ஐத் தவிர வேறு இடத்திலிருந்து அணுகுவதற்கு 3 பாதுகாப்பான வழிகள் உள்ளன:

• Local-ஆக வைத்திருக்கவும். ஒரே VPS-ல் இயங்கும் மற்றொரு program, cron script, bot, அல்லது உங்கள் tools-ஐ model-உடன் இணைக்கும் MCP server மட்டுமே caller என்றால், bind-ஐ 127.0.0.1-ல் வைத்திருந்து அந்த program http://127.0.0.1:11434-ஐ call செய்யுமாறு அமைக்கவும். எதுவும் வெளிப்படாது; வேறு எதுவும் தேவையில்லை.
• Private tunnel மூலம் அணுகவும். VPS-ஐ நீங்கள் host செய்யும் WireGuard VPN-ல் இணைக்கவும். OLLAMA_HOST-ஐ tunnel address-ஆக அமைக்கவும்; உதாரணமாக 10.8.0.1, 0.0.0.0 அல்ல. VPN peers மட்டுமே connect செய்ய முடியும். Public internet-க்கு 11434-ல் எதுவும் தெரியாது.
• Authentication கொண்ட reverse proxy-ஐ முன்புறத்தில் அமைக்கவும். TLS-ஐ terminate செய்து, nginx, Traefik, அல்லது Caddy-ல் password அல்லது token-ஐ கட்டாயமாக்கவும். பின்னர் 127.0.0.1:11434-க்கு proxy செய்யவும். Ollama தனது localhost bind-ஐ வைத்திருக்கும். Public port-ல் listening செய்யும் ஒரே component proxy ஆகும். எந்த local service-க்கும் முன்பாக nginx-ல் Let's Encrypt certificate அமைப்பதற்குப் பயன்படுத்தும் அதே முறையாகும்.

அடுத்ததாக chat UI வழங்கும் option இதுவே. இதில் உண்மையான login இணைக்கப்பட்டுள்ளது.

TLS-க்கு பின்னால் Open WebUI மூலம் chat UI சேர்த்தல்

Open WebUI என்பது self-hosted chat interface ஆகும். இதை Docker-ல் இயக்கி, local Ollama-வை நோக்கிச் சுட்டிக்காட்டவும்:

docker run -d \
  --name open-webui \
  --network=host \
  -e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
  -v open-webui:/app/backend/data \
  --restart always \
  ghcr.io/open-webui/open-webui:main

Linux VPS-ல் --network=host flag முக்கியமானது. இது container-ஐ host-ன் network namespace-ல் இயக்குகிறது. எனவே container-க்குள் உள்ள 127.0.0.1 என்பது host-ன் சொந்த loopback ஆகும். Container, Ollama-வை வேறு எந்த interface-லும் listening செய்ய வைக்காமல் 127.0.0.1:11434 மூலம் அணுகும். வேறு இடத்தில் காணப்படும் bridge-network முறையான --add-host=host.docker.internal:host-gateway மற்றும் OLLAMA_BASE_URL=http://host.docker.internal:11434 இங்கு செயல்படாது. அந்தப் பெயர் Docker bridge gateway-க்கு resolve ஆகிறது. Host-ல் 127.0.0.1-க்கு bind செய்யப்பட்ட service-ஐ bridge வழியாக அணுக முடியாது. ஆகவே Open WebUI, Ollama-வுடன் இணைக்க முடியவில்லை என்று தொடர்ந்து தெரிவிக்கும்.

Host networking-ன் trade-off என்னவென்றால், Open WebUI இப்போது host-ன் port 8080-ல் அனைத்து interfaces-லும் listening செய்யும். எந்த -p mapping-மும் நிராகரிக்கப்படும்; Docker இதைத் தெரிவிக்கும் warning-ஐ காட்டும். ஆகவே host firewall மற்றும் provider firewall இரண்டிலும் 8080-ஐ மூடவும். TLS reverse proxy மட்டுமே public access point ஆக இருக்க வேண்டும். முதல் முறையாக Open WebUI-ஐத் திறக்கும்போது, admin account உருவாக்குமாறு கேட்கும். அந்த account-தான் authentication layer ஆகும். எனவே வலுவான password-ஐத் தேர்ந்தெடுக்கவும்.

Laptop-ல் இருந்து HTTPS வழியாக chat-ஐத் திறக்க, 127.0.0.1:8080-க்கு முன்னால் TLS reverse proxy-ஐ அமைக்கவும். அந்த server-ல் ஏற்கனவே பல Docker apps-ஐ route செய்தால், பல apps-க்கு automatic TLS உடன் Traefik சிறந்த தேர்வாகும். ஒரே label block certificate-ஐப் பெற்று, chat.example.com-ஐ Open WebUI-க்கு route செய்யும். இதே label-per-app routing முறையைத்தான் server-ல் உள்ள மற்ற browser front-end-களும் பயன்படுத்தும். அவை status dashboard ஆக இருந்தாலும், Jellyfin library-ஐ 90s rental store போன்று காட்டும் Halcyon போன்ற வேறு வகை application ஆக இருந்தாலும், ஒவ்வொன்றும் தனித்தனி hostname-ல் தனித்தனி login-க்கு பின்னால் இயங்கும். Security section-ல் கூறிய விதி இங்கும் பொருந்தும். Public port மற்றும் login-ஐ proxy கையாளும். Ollama localhost-ல் தொடர்ந்தும் இருக்கும். Open WebUI-ன் சொந்த 8080 firewall மூலம் மூடப்பட்டிருக்கும்.

உங்கள் code-இலிருந்து OpenAI-compatible endpoint-ஐ பயன்படுத்தவும்

Ollama, /v1-ல் OpenAI chat API-ன் ஒரு பகுதியை வழங்குகிறது. எனவே base URL மற்றும் பயன்பாட்டுக்கான ஒரு தற்காலிக key ஆகிய 2 விஷயங்களை மாற்றிய பிறகு, பெரும்பாலான OpenAI client libraries இயங்கும்.

from openai import OpenAI

client = OpenAI(base_url="http://127.0.0.1:11434/v1", api_key="ollama")

resp = client.chat.completions.create(
    model="llama3.2:3b",
    messages=[{"role": "user", "content": "Name three Linux distributions."}],
)
print(resp.choices[0].message.content)

api_key client library-க்கு தேவைப்படுகிறது; ஆனால் Ollama அதை புறக்கணிக்கும். எனவே எந்த string-ஐயும் பயன்படுத்தலாம். model, நீங்கள் ஏற்கனவே pull செய்த model-ன் பெயராக இருக்க வேண்டும். தெரியாத பெயர் பயன்படுத்தினால், model 'x' not found உடன் 404 பிழை திரும்பும். எளிய curl call-லும் இதே முறையே பயன்படுத்தப்படுகிறது:

curl http://127.0.0.1:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"llama3.2:3b","messages":[{"role":"user","content":"Hello"}]}'

Agent மற்றும் editor tooling-உடன் model-ஐ இணைப்பதும் இதே முறையில்தான். நீங்கள் ஏற்கனவே அந்த box-ல் development செய்கிறீர்கள் என்றால், VPS-ல் tmux-க்குள் இயங்கும் Claude Code உடன் local model-ஐ scripts மற்றும் plugins-க்கு பயன்படுத்தலாம். இதனால் குறைந்த செலவிலான, தனிப்பட்ட drafting பணிகள் paid API-யிலிருந்து விலகி இயங்கும்; அதிக reasoning தேவைப்படும் பணிகள் hosted model-ல் தொடரும்.

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

செயல்முறை (process) உருவாக்கத்தின் பாதியில் "Killed" ஆகிறது. நீங்கள் ஒரு பெரிய model-ஐத் தொடங்கும்போது terminal-ல் Killed என்று அச்சிடப்படும், அல்லது server log-ல் (journalctl -u ollama) llama-server process has terminated என்று தொடங்கும் வரி தோன்றும். இது அக்டோபர் 21, 2026 அன்று சரிபார்க்கப்பட்ட Ollama 0.40.7-ன் வாசகமாகும்; பழைய releases-களில் llama runner process has terminated: signal: killed என்று இருந்தது. அந்த model-க்குத் தேவையான RAM, server-ல் இல்லாததால் Linux OOM killer அதை நிறுத்திவிட்டது. sudo dmesg | grep -i oom மூலம் காரணத்தை உறுதிப்படுத்தவும், அதில் Out of memory: Killed process ... போன்ற ஒரு வரியைக் காண்பீர்கள். இதற்கான தீர்வு, சிறிய அல்லது அதிக அளவு quantized செய்யப்பட்ட model-ஐப் பயன்படுத்துவது, அதாவது 13B-க்கு பதிலாக llama3.2:3b-ஐப் பயன்படுத்துவது, அல்லது swap-ஐச் சேர்ப்பது. இதன் மூலம் physical RAM-ஐ விடச் சற்று அதிகமான சுமை ஏற்பட்டால், அது உடனடியாக செயலிழக்காமல் மெதுவாக இயங்கும். Swap-ஐச் சேர்ப்பது crash-ஐ மெதுவான பதிலளிப்பாக மாற்றும்; இது 4 GB RAM-ல் 70B model-ஐச் செயல்பட வைக்காது. நீங்கள் terminal-ஐக் கவனிக்கவில்லை என்றால் இந்த kill நிகழ்வு அமைதியாகவே நடக்கும். எனவே, நீங்கள் வேறொரு இடத்திலிருந்து அணுகும் server-ல், OnFailure= unit-ஐ ollama.service-உடன் இணைத்து, நீங்கள் நிர்வகிக்கும் ntfy server-க்கு push alerts அனுப்பினால், அது செயலிழந்த அடுத்த நொடியே உங்களுக்குத் தெரிந்துவிடும்.

Ollama model-ஐ ஏற்ற மறுக்கிறது. crash ஆவதற்குப் பதிலாக, கோரிக்கை (request) உடனடியாக error-உடன் தோல்வியடையும் மற்றும் server log-ல் model is too large for system memory என்று பதிவாகும் (அக்டோபர் 21, 2026 அன்று சரிபார்க்கப்பட்ட Ollama 0.40.7). பழைய releases-களில் prompt-லேயே Error: model requires more system memory (X GiB) than is available (Y GiB) என்று அச்சிடப்பட்டது. இது மேலே குறிப்பிட்ட crash-ன் மென்மையான வடிவம்: Ollama கணக்கீடுகளைச் செய்துவிட்டு, OOM killer-ஐ அனுமதிப்பதற்குப் பதிலாகத் தானே நிறுத்திவிட்டது. உங்கள் இலவச RAM-க்கு உட்பட்ட model-ஐத் தேர்ந்தெடுக்கவும் (free -h மூலம் சரிபார்க்கவும்), context length-ஐக் குறைக்கவும், அல்லது பெரிய VPS-க்கு மாறவும். எந்த flag-ஐயும் பயன்படுத்தி model-ஐப் பொருத்த முடியாது, ஏனெனில் memory என்பது உண்மையானது.

முதல் token வர நீண்ட நேரம் ஆகிறது, பிறகு சரியாக இயங்குகிறது. ஒரு cold model முதல் ஐந்து முதல் முப்பது வினாடிகளுக்கு எதையும் அச்சிடாது, பிறகு சாதாரணமாக இயங்கும். அந்த இடைவெளி, weights disk-லிருந்து RAM-க்கு முதன்முதலில் ஏற்றப்படுவதால் ஏற்படுகிறது; slow storage இதை இன்னும் மோசமாக்கும். ஏற்றப்பட்ட பிறகு, OLLAMA_KEEP_ALIVE கால அளவு வரை model resident-ஆக இருக்கும், எனவே இரண்டாவது prompt உடனடியாகப் பதிலளிக்கும். அந்த முதல் ஏற்றம் call path-ல் உள்ள ஏதேனும் timeout-ஐ விட அதிகமாக இருந்தால், மெதுவான பதிலுக்குப் பதிலாக error கிடைக்கும். எந்த layer context deadline exceeded என்று தெரிவிக்கிறது என்பதைக் கண்டறிவது, client, proxy அல்லது load ஆகியவற்றில் எது பொறுமையிழந்தது என்பதைத் தெளிவுபடுத்தும். அந்த இடைவெளி உங்களுக்குத் தொந்தரவாக இருந்தால் அந்த மதிப்பை அதிகரிக்கவும், மேலும் ஒரு model தற்போது ஏற்றப்பட்டுள்ளதா என்பதைப் பார்க்க ollama ps-ஐப் பயன்படுத்தவும்.

எல்லாம் மிக மெதுவாக உள்ளது. error ஏதுமின்றி, வினாடிக்கு பத்து token-கள் அல்லது அதற்கும் குறைவாகவே கிடைக்கிறது. இது CPU inference-ன் இயல்பான செயல்பாடு. ollama ps-ல் 100% CPU என்று காட்டினால், GPU இல்லை என்று அர்த்தம். இது bug அல்ல, எந்த அமைப்பும் CPU-வை GPU-வாக மாற்ற முடியாது, ஏனெனில் முக்கியத் தடை memory bandwidth ஆகும். VM-ல் ஒரு அமைப்பைச் சோதிக்கலாம்: Ollama தான் கண்டறியும் physical cores-லிருந்து thread count-ஐத் தேர்வு செய்யும், hypervisor இதைத் தவறாகக் காட்டலாம். ஒரு ollama run --verbose session-ல், /set parameter num_thread 4 (அல்லது உங்கள் vCPU எண்ணிக்கை) முயற்சி செய்து, அதே prompt-ஐ மீண்டும் இயக்கவும். எது சிறந்த eval rate-ஐத் தருகிறதோ அதைத் தக்கவைக்கவும். அதற்கு மேல், சிறிய model-ஐப் பயன்படுத்தவும், வேகத்தை ஏற்றுக்கொள்ளவும் அல்லது GPU instance-க்கு மாறவும். எதற்கும் முன் --verbose மூலம் உங்கள் உண்மையான வேகத்தை அளவிடவும். பதில் மெதுவாக இருப்பதற்குப் பதிலாக, பதிலின் நீளம் காரணமாகத் தாமதம் ஏற்பட்டால், num_predict மூலம் பதிலைச் சுருக்குவது, தேவையற்ற நீண்ட பதில்களைத் தவிர்க்க உதவும்.

மற்றொரு இயந்திரத்திலிருந்து Connection refused. உங்கள் laptop-லிருந்து, தற்போதைய curl (அக்டோபர் 21, 2026 அன்று சரிபார்க்கப்பட்ட 8.23.0) curl: (7) Failed to connect to <ip>:11434 after <n> ms: Could not connect to server என்று அச்சிடும், Ubuntu 24.04-ல் உள்ள curl 8.5.0 curl: (7) Failed to connect to <ip> port 11434 after <n> ms: Couldn't connect to server என்று அச்சிடும். நீங்கள் -v-ஐச் சேர்த்தால் மட்டுமே "Connection refused" என்ற சொற்கள் தோன்றும், அது connect to <ip> port 11434 from ... failed: Connection refused என்று இருக்கும். இது வடிவமைக்கப்பட்டபடியே செயல்படுகிறது: Ollama localhost-ல் மட்டுமே இணையும். 0.0.0.0-ஐ bind செய்வதன் மூலம் இதை "சரிசெய்ய" முயற்சிக்காதீர்கள், அது மேலே குறிப்பிட்ட பாதுகாப்புச் சிக்கலை ஏற்படுத்தும். VPN மூலமாகவோ அல்லது அங்கீகரிக்கப்பட்ட proxy மூலமாகவோ model-ஐ அணுகவும்.

நீங்கள் 11434-ஐ இணையத்திற்குத் திறந்துவிட்டீர்கள். நீங்கள் OLLAMA_HOST=0.0.0.0-ஐ அமைத்து, firewall-ஐத் திறந்து, நீங்கள் தொடங்காத model pulls-ஐக் கண்டாலோ அல்லது தெரியாத clients-களால் CPU 100% பயன்பாட்டில் இருந்தாலோ, நீங்கள் கண்டறியப்பட்டு பயன்படுத்தப்பட்டுள்ளீர்கள் என்று அர்த்தம். இது ஒரு சிறிய சிக்கல் அல்ல, மிகப்பெரிய தவறு. 127.0.0.1 அல்லது VPN முகவரிக்கு மீண்டும் bind செய்யவும், firewall-ல் 11434-ஐ மூடவும், முன்னால் authentication-ஐச் சேர்க்கவும். அந்த முகவரி திறந்திருந்தபோது, அந்நியர்கள் அதை அணுகியிருக்கலாம் என்று கருதிச் செயல்படவும்.

Backups மற்றும் upgrades

இழக்கக்கூடிய state மிகக் குறைவு. Models-ஐ மீண்டும் download செய்ய முடியும். எனவே backup செய்ய வேண்டியவை Open WebUI-ன் data volume, accounts, chat history, settings, மற்றும் நீங்கள் எழுதிய systemd drop-in ஆகியவை மட்டுமே. தற்காலிக container மூலம் volume-ஐ backup செய்யவும்:

docker run --rm -v open-webui:/data -v "$PWD":/backup alpine \
  tar czf /backup/open-webui.tgz -C /data .

Install script-ஐ மீண்டும் இயக்கி Ollama-ஐ upgrade செய்யவும். docker pull ghcr.io/open-webui/open-webui:main இயக்கிய பின்னர் container-ஐ recreate செய்வதன் மூலம் Open WebUI-ஐ upgrade செய்யவும். 0.40 line-க்கு தொடர்பான disk குறிப்பு: Ollama 0.40.2, முந்தைய versions மூலம் pull செய்யப்பட்ட models-ஐ background-ல் upgrade செய்யத் தொடங்கியது. Original copies-ஐ backups-ஆக வைத்திருப்பதால், அவை நீக்கப்படும் வரை கூடுதல் disk space பயன்படுத்தப்படும். 0.40.3 (11 October 2026) அந்த background upgrade-ஐ pause செய்தது. Upgrade செய்த பிறகு df -h-ஐச் சரிபார்க்கவும். அந்த backups-ஐ நீக்கும் command-க்கு release notes-ஐப் பார்க்கவும். நீண்ட காலத்திற்கு எந்த version-ஐயும் pin செய்ய வேண்டாம். Model quality மற்றும் runtime இரண்டும் வேகமாக மாறுகின்றன. எனவே release notes-ஐப் படித்து, கடந்த காலாண்டின் numbers-ஐ நம்புவதற்குப் பதிலாக, உங்கள் சொந்த box-ல் மீண்டும் benchmark செய்யவும்.

FAQ

CPU-only VPS-ல் உண்மையாகவே LLM இயக்க முடியுமா?

ஆம், சில வரம்புகளுடன் இயக்கலாம். 3B முதல் 8B வரையிலான சிறிய quantized models CPU-ல் இயங்கும். அவை drafting, summarizing, classification போன்ற பணிகளுக்கு உண்மையாகப் பயன்படும். ஆனால் shared vCPU-ல் அவை மெதுவாகவே இயங்கும்; பொதுவாக single-digit முதல் low-double-digit tokens per second வேகம் இருக்கும். 13B அல்லது அதற்கு மேற்பட்ட models மிகவும் மெதுவாக இயங்கும் அல்லது RAM-ல் பொருந்தாது. உண்மையான வேகம் அல்லது பெரிய models தேவைப்பட்டால் GPU instance பயன்படுத்த வேண்டும்.

ஒவ்வொரு model-க்கும் எவ்வளவு RAM தேவைப்படும்?

பெரும்பாலான models default-ஆக பயன்படுத்தும் 4-bit (Q4) tags-க்கு ஒரு தோராயமான விதி உள்ளது: weights-க்கு, ஒவ்வொரு billion parameters-க்கும் சுமார் 0.5 GB RAM தேவைப்படும். இதனுடன் சுமார் 1 GB overhead மற்றும் context-க்கு சிறிது கூடுதல் memory தேவைப்படும். எனவே, 3B model-க்கு சுமார் 4 GB free memory, 7-8B model-க்கு சுமார் 8 GB, 14B model-க்கு சுமார் 16 GB தேவைப்படும். free -h மூலம் headroom-ஐ சரிபார்க்கவும். Operating system மற்றும் அந்த box-ல் இயங்கும் பிற components-க்கும் memory விடவும்.

Ollama API authenticated ஆக உள்ளதா?

இல்லை. Ollama-வில் built-in authentication, API key, அல்லது rate limit எதுவும் இல்லை. Port 11434-ஐ அணுகக்கூடிய எவரும் அதை முழுமையாகக் கட்டுப்படுத்த முடியும். அதன் OLLAMA_ORIGINS setting எந்த browser origins அதை call செய்யலாம் என்பதை மட்டும் கட்டுப்படுத்தும்; யார் connect செய்யலாம் என்பதை கட்டுப்படுத்தாது. அதனால்தான் அது default-ஆக 127.0.0.1-ல் bind ஆகிறது. மேலும், 11434-ஐ 0.0.0.0 வழியாக internet-க்கு ஒருபோதும் expose செய்யக்கூடாது. அதை local-ஆக, private VPN வழியாக, அல்லது login சேர்க்கும் reverse proxy மூலம் அணுகவும்.

Web chat interface-ஐ எவ்வாறு சேர்ப்பது?

--network=host உடன் Docker-ல் Open WebUI-ஐ இயக்கவும். இதனால் அது host-ன் loopback-ஐ share செய்து, native Ollama-ஐ http://127.0.0.1:11434 வழியாக அணுகும். பின்னர், உங்கள் laptop-லிருந்து அணுகுவதற்காக அதன் port 8080-க்கு முன்பாக TLS reverse proxy அமைக்கவும். Firewall-ல் 8080 மூடப்பட்டிருக்க வேண்டும்; எனவே proxy மட்டுமே public access point ஆக இருக்கும். Open WebUI-ன் சொந்த admin account login-ஐ வழங்கும். முதல் launch-இல் அதன் password-ஐ அமைக்கவும்.

எனது சொந்த application-லிருந்து அதை எவ்வாறு call செய்வது?

http://127.0.0.1:11434/v1-ல் உள்ள OpenAI-compatible endpoint-ஐ பயன்படுத்தவும். எந்த OpenAI SDK-யையும் அந்த base URL-ஐ நோக்கி அமைக்கலாம். API key புறக்கணிக்கப்படுவதால், அதற்கு எந்த string-ஐயும் வழங்கலாம். model-ஐ நீங்கள் pull செய்த model name-ஆக அமைக்கவும். Base URL மற்றும் key-ஐத் தவிர, ஏற்கனவே உள்ள OpenAI code பொதுவாக எந்த மாற்றமும் இல்லாமல் இயங்கும்.