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 பயன்பாடு என்பது அதன் கோப்பு அளவைச் சார்ந்தது; அதனுடன் runtime overhead-க்காக சுமார் ஒரு gigabyte மற்றும் context window-க்காக கூடுதல் memory தேவைப்படும். Ollama-வின் default model-கள் 4-bit quantized (Q4 என குறிப்பிடப்படும்) முறையில் உள்ளன. இது ஒவ்வொரு ஒரு பில்லியன் parameters-க்கும் சுமார் அரை gigabyte RAM-ஐ எடுத்துக்கொள்ளும். எனவே, கணக்கீடு எளிதானது, இதுவே அனைத்தையும் தீர்மானிக்கிறது.

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

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

நடைமுறை முடிவு: சிறிய quantized model-கள் CPU-வில் drafting, summarizing மற்றும் classification பணிகளுக்குப் பயனுள்ளதாக இருக்கும், ஆனால் வேகம் குறைவாக இருப்பதை நீங்கள் ஏற்றுக்கொள்ள வேண்டும். பெரிய அல்லது வேகமான செயல்பாடுகளுக்கு, GPU instance-ஐத் தேர்வு செய்யவும்.

ஒரு குறிப்பிட்ட model-ஐ உங்கள் server-ன் திறனுடன் ஒப்பிட்டுப் பார்க்க, அதன் memory பயன்பாட்டை இங்கே கணக்கிடுங்கள்:

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-ஐ பதிவு செய்துவிட்டதால், கூடுதல் வேலை ஏதுமின்றி reboot-க்குப் பிறகு இது தானாகவே தொடங்கும். மாற்ற வேண்டிய முக்கியமான அமைப்பு, ஒரு model எவ்வளவு நேரம் நினைவகத்தில் (resident) இருக்க வேண்டும் என்பதுதான். சில அமைப்புகளில், bind address-ஐயும் மாற்ற வேண்டியிருக்கும். இவை இரண்டையும் ஒரு systemd drop-in கோப்பில் சேர்க்க வேண்டும்; அப்போதுதான் Ollama upgrade செய்யும்போது இந்த அமைப்புகள் மேலெழுதப்படாது (overwrite):

sudo systemctl edit ollama.service

Editor-ல் தோன்றும் [Service] தலைப்பின் கீழ் இதைக் சேர்க்கவும்:

[Service]
Environment="OLLAMA_KEEP_ALIVE=30m"

OLLAMA_KEEP_ALIVE என்பது கடைசி கோரிக்கைக்குப் பிறகு ஒரு model எவ்வளவு நேரம் நினைவகத்தில் இருக்க வேண்டும் என்பதைக் குறிக்கும் (இயல்புநிலை 5 நிமிடங்கள்). நாள் முழுவதும் நீங்கள் query செய்யும் server என்றால், ஒவ்வொரு முறையும் weights-ஐ மீண்டும் ஏற்றாமல் இருக்க இதை அதிகரிக்கவும்; RAM குறைவாக உள்ள server-ல், கோரிக்கை முடிந்தவுடன் நினைவகத்தை விடுவிக்க இதை 0 என அமைக்கவும். systemctl edit உங்களுக்காக unit கோப்புகளை மீண்டும் ஏற்றும் (reload), எனவே மாற்றங்களைச் செயல்படுத்த service-ஐ restart செய்யவும்:

sudo systemctl restart ollama

மிக முக்கியமான பாதுகாப்பு அம்சம்

இயல்பாகவே Ollama 127.0.0.1:11434-ல் பிணைக்கப்படுவதால் (bind), அந்த VPS-ல் உள்ள process-கள் மட்டுமே அதை அணுக முடியும். இந்த இயல்புநிலை அமைப்பே சரியானது. இதை மாற்ற வேண்டாம்.

இந்த API-ல் எந்தவிதமான அங்கீகாரமும் (authentication) இல்லை. இதில் API key, login, rate limit அல்லது allow-list எதுவுமே கிடையாது. port 11434-ஐ அணுகக்கூடிய எவரும் நீங்கள் தரவிறக்கம் செய்துள்ள எந்தவொரு model-ஐயும் இயக்கலாம், புதியவற்றைத் தரவிறக்கலாம், அவற்றை நீக்கலாம், மேலும் உங்கள் CPU அல்லது GPU-வை முழுமையாகப் பயன்படுத்தி சுமையேற்றலாம். Shodan போன்ற ஸ்கேனர்கள் ஆயிரக்கணக்கான திறந்த நிலையில் உள்ள Ollama instances-களைக் கண்டறிகின்றன; இணையத்தில் வெளிப்படையாக இருக்கும் ஒரு instance சில மணிநேரங்களிலேயே கண்டறியப்பட்டு தவறாகப் பயன்படுத்தப்படுகிறது.

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

இந்த server-க்கு வெளியே இருந்து model-ஐ அணுக மூன்று பாதுகாப்பான வழிகள் உள்ளன:

• உள்ளூர் நிலையிலேயே வைத்திருங்கள். அதே VPS-ல் உள்ள மற்றொரு program, ஒரு cron script, ஒரு bot அல்லது உங்கள் கருவிகளை model-உடன் இணைக்கும் MCP server மட்டுமே அழைப்பாளராக இருந்தால், bind-ஐ 127.0.0.1-லேயே வைத்திருங்கள். அந்த program http://127.0.0.1:11434-ஐ அழைக்கட்டும். எதுவும் வெளிப்படுத்தப்படாது, வேறு எதுவும் தேவையில்லை.
• ஒரு private tunnel வழியாக அணுகுங்கள். VPS-ஐ நீங்கள் சொந்தமாக நடத்தும் WireGuard VPN-ல் இணையுங்கள், OLLAMA_HOST-ஐ tunnel முகவரிக்கு (உதாரணமாக 10.8.0.1, 0.0.0.0 அல்ல) அமைத்துவிடுங்கள். இப்போது VPN-ல் உள்ளவர்கள் மட்டுமே இணைக்க முடியும். பொது இணையத்திற்கு 11434-ல் எதுவும் தெரியாது.
• முன்னால் ஒரு அங்கீகாரம் கொண்ட reverse proxy-ஐ வையுங்கள். nginx, Traefik அல்லது Caddy மூலம் TLS termination செய்து, password அல்லது token-ஐக் கட்டாயமாக்கி, பின் அதை 127.0.0.1:11434-க்கு proxy செய்யுங்கள். Ollama அதன் localhost bind-லேயே இருக்கும்; பொது port-ல் proxy மட்டுமே listening நிலையில் இருக்கும். இது எந்தவொரு local service-க்கும் முன்னால் nginx-ல் Let's Encrypt certificate வைப்பது போன்ற அதே அமைப்பாகும்.

அடுத்ததாகக் கொடுக்கப்படும் chat UI, உண்மையான login வசதியுடன் இந்த reverse-proxy முறையைத்தான் உங்களுக்கு வழங்குகிறது.

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

Open WebUI என்பது ஒரு self-hosted chat interface ஆகும். இதை Docker-ல் இயக்கி, உள்ளூர் 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 ஆகிறது. Ollama வேறு எந்த interface-லும் கேட்க வேண்டிய அவசியமின்றி, container அதை 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-ஐக் குறிக்கும். host-ல் 127.0.0.1-ல் பிணைக்கப்பட்டிருக்கும் ஒரு service-ஐ bridge வழியாக அணுக முடியாது, எனவே Open WebUI-ஆல் Ollama-வுடன் இணைய முடியவில்லை என்று பிழை காட்டும்.

Host networking-ன் குறைபாடு என்னவென்றால், Open WebUI இப்போது host-ன் 8080 port-ல் அனைத்து interface-களிலும் கேட்கும்; எந்தவொரு -p mapping-ம் நிராகரிக்கப்படும், மேலும் Docker இது குறித்து எச்சரிக்கை செய்யும். எனவே, host மற்றும் provider firewall ஆகிய இரண்டிலும் 8080-ஐ மூடிவிட்டு, TLS reverse proxy-ஐ மட்டுமே பொது நுழைவாயிலாக வைத்திருக்கவும். முதல்முறை நுழையும்போது, Open WebUI ஒரு admin account-ஐ உருவாக்கக் கேட்கும். அந்த account-தான் உங்கள் authentication layer, எனவே வலுவான password-ஐத் தேர்ந்தெடுக்கவும்.

HTTPS வழியாக உங்கள் laptop-லிருந்து chat-ஐத் திறக்க, 127.0.0.1:8080-க்கு முன்னால் ஒரு TLS reverse proxy-ஐ வைக்கவும். ஏற்கனவே அந்த server-ல் பல Docker apps-ஐ நீங்கள் route செய்கிறீர்கள் என்றால், பல apps-க்கு இடையே தானியங்கி TLS கொண்ட Traefik என்பதே மிகச் சிறந்த தேர்வாகும்: ஒரு label block மூலம் certificate வழங்கப்பட்டு, chat.example.com ஆனது Open WebUI-க்கு route செய்யப்படும். பாதுகாப்புப் பகுதியிலுள்ள விதி இப்போதும் பொருந்தும்; proxy பொது port மற்றும் login-ஐக் கையாளும், அதே சமயம் Ollama localhost-லேயே இருக்கும் மற்றும் Open WebUI-ன் சொந்த 8080 firewall-ஆல் பாதுகாக்கப்பட்டிருக்கும்.

உங்கள் குறியீட்டிலிருந்து OpenAI-இணக்கமான endpoint-ஐப் பயன்படுத்துதல்

Ollama, /v1-ல் OpenAI chat API-ன் ஒரு பகுதியை ஆதரிக்கிறது. எனவே, base URL மற்றும் ஒரு தற்காலிக key ஆகிய இரண்டையும் மாற்றினால் பெரும்பாலான 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, try pulling it first பிழை வரும். ஒரு சாதாரண curl அழைப்பும் இதே தத்துவத்தில்தான் செயல்படுகிறது:

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"}]}'

இதே முறையில் தான் model-ஐ agent மற்றும் editor கருவிகளுடன் இணைக்க வேண்டும். நீங்கள் ஏற்கனவே அந்த server-ல் உருவாக்கப்பணிகளைச் செய்கிறீர்கள் என்றால், ஒரு local model-ஐ ஸ்கிரிப்ட்கள் மற்றும் பிளகின்களுக்குப் பயன்படுத்தலாம். இதனுடன் tmux-க்குள் VPS-ல் இயங்கும் Claude Code-ஐப் பயன்படுத்தும்போது, சாதாரண வரைவுப் பணிகளை மலிவான, தனிப்பட்ட முறையில் வைத்துக்கொண்டு, சிக்கலான பகுப்பாய்வுப் பணிகளுக்கு மட்டும் கட்டண API-ஐப் பயன்படுத்தலாம்.

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

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

"Error: model requires more system memory". Ollama மாதிரியைத் தொடங்க மறுத்து Error: model requires more system memory (X GiB) than is available (Y GiB) என்ற செய்தியைக் காட்டும். இது முந்தைய முடக்கத்தின் நாகரிகமான வடிவம்: Ollama கணக்கீடுகளைச் செய்து, OOM killer தலையிடுவதற்கு முன்பே நிறுத்திவிட்டது. அதுவே உங்களுக்குத் தேவையான இரண்டு எண்களையும் வழங்கும். உங்கள் கணினியில் உள்ள இலவச RAM அளவுக்குள் (free -h மூலம் சரிபார்க்கவும்) இருக்கும் மாதிரியைத் தேர்ந்தெடுக்கவும், context length-ஐக் குறைக்கவும் அல்லது பெரிய VPS-க்கு மாறவும். எந்தவொரு flag-ஐயும் பயன்படுத்தி நினைவகத் தேவையை மாற்ற முடியாது, இது வன்பொருள் சார்ந்த உண்மை.

முதல் token வருவதற்கு அதிக நேரம் ஆகிறது; அதன் பிறகு சரியாக இயங்குகிறது. Cold model முதல் ஐந்து முதல் முப்பது விநாடிகள் வரை எதையும் காட்டாமல் இருக்கலாம். அதன் பிறகு output இயல்பாக stream ஆகும். முதல் முறையாக weights-ஐ disk-இலிருந்து RAM-க்கு load செய்வதே இந்த இடைவெளிக்குக் காரணம். Storage மெதுவாக இருந்தால் இந்த தாமதம் மேலும் அதிகரிக்கும். Load முடிந்ததும், OLLAMA_KEEP_ALIVE கால அளவு முழுவதும் model memory-ல் resident-ஆக இருக்கும். எனவே இரண்டாவது prompt-க்கு உடனடியாக பதில் கிடைக்கும். Call path-இல் உள்ள ஏதேனும் timeout-ஐ விட முதல் load நேரம் அதிகமாக இருந்தால், மெதுவான பதிலுக்குப் பதிலாக error கிடைக்கும். எந்த layer context deadline exceeded எனத் தெரிவித்தது என்பதை கண்டறிதல் மூலம் client, proxy அல்லது model load ஆகியவற்றில் எது timeout-ஐ எட்டியது என்பதை அறியலாம். இடைவெளிகள் சிரமமாக இருந்தால், அந்த value-ஐ அதிகரிக்கவும். தற்போது model load செய்யப்பட்டுள்ளதா என்பதைப் பார்க்க ollama ps-ஐ பயன்படுத்தவும்.

எல்லாமே மிக மெதுவாக இயங்குகிறது. பிழைகள் ஏதுமின்றி, வினாடிக்கு பத்து tokens அல்லது அதற்கும் குறைவாகவே கிடைக்கிறது. இது CPU inference-ன் இயல்பான வேகம். ollama ps கட்டளை 100% CPU என்று காட்டினால், அங்கு GPU இல்லை என்று அர்த்தம். இது ஒரு பிழை அல்ல, எந்த அமைப்பாலும் இதை மாற்ற முடியாது; ஏனெனில் இதன் எல்லை memory bandwidth-ஐச் சார்ந்தது, தவறான அமைப்பால் அல்ல. சிறிய மாதிரியைப் பயன்படுத்தவும், இந்த வேகத்தை ஏற்றுக்கொள்வும் அல்லது GPU instance-க்கு மாறவும். எதாவது பழுதடைந்துள்ளதாக முடிவெடுக்கும் முன் --verbose மூலம் உங்கள் உண்மையான வேகத்தை அளவிடவும்.

மற்றொரு கணினியிலிருந்து Connection refused என்று வருகிறது. உங்கள் laptop-லிருந்து முயற்சிக்கும்போது curl: (7) Failed to connect to <ip> port 11434: Connection refused என்று வரும். இது வடிவமைக்கப்பட்டபடியே இயங்குகிறது: Ollama localhost-ல் மட்டுமே இயங்கும். இதைச் சரிசெய்ய 0.0.0.0-க்கு bind செய்ய வேண்டாம், அது மேலே குறிப்பிட்ட பாதுகாப்பு மீறலுக்கு வழிவகுக்கும். VPN மூலமாகவோ அல்லது authentication வசதி கொண்ட proxy மூலமாகவோ மாதிரியை அணுகவும்.

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

Backups and upgrades

இழப்பதற்கு பெரிய அளவில் தரவுகள் இல்லை. Models-ஐ மீண்டும் தரவிறக்கம் செய்ய முடியும் என்பதால், Open WebUI-ன் data volume, கணக்குகள், chat history, settings மற்றும் நீங்கள் உருவாக்கிய systemd drop-in கோப்புகளை மட்டும் backup எடுத்தால் போதுமானது. ஒரு தற்காலிக container-ஐப் பயன்படுத்தி volume-ஐ backup எடுக்கவும்:

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

Ollama-வை மேம்படுத்த, install script-ஐ மீண்டும் இயக்கவும்; Open WebUI-ஐ மேம்படுத்த docker pull ghcr.io/open-webui/open-webui:main கட்டளையை இயக்கி, அதன் பிறகு container-ஐ மீண்டும் உருவாக்கவும். எதையும் நீண்ட காலத்திற்கு pin செய்ய வேண்டாம்: model தரம் மற்றும் runtime ஆகிய இரண்டும் வேகமாக மாறிக்கொண்டே இருக்கின்றன. எனவே, கடந்த கால புள்ளிவிவரங்களை நம்புவதை விட, release notes-ஐப் படித்து உங்கள் கணினியில் மீண்டும் benchmark செய்து பார்க்கவும்.

FAQ

CPU-மட்டும் கொண்ட VPS-ல் என்னால் LLM-ஐ இயக்க முடியுமா?

ஆம், சில கட்டுப்பாடுகளுடன் முடியும். 3B முதல் 8B வரையிலான சிறிய quantized மாதிரிகள் CPU-ல் இயங்கும். இவை வரைவு தயாரித்தல், சுருக்கம் எழுதுதல் மற்றும் வகைப்படுத்துதல் போன்ற பணிகளுக்குப் பயனுள்ளதாக இருக்கும். ஆனால், பகிரப்பட்ட vCPU-ல் இவை வினாடிக்கு ஒற்றை இலக்கம் அல்லது குறைந்த இரட்டை இலக்க tokens வேகத்திலேயே இயங்கும். 13B-க்கு மேற்பட்ட மாதிரிகள் மிகவும் மெதுவாக இருக்கும் அல்லது RAM-ல் இடம் கொள்ளாது. அதிக வேகம் அல்லது பெரிய மாதிரிகளுக்கு உங்களுக்கு GPU instance தேவைப்படும்.

ஒவ்வொரு மாதிரிக்கும் எவ்வளவு RAM தேவை?

இயல்பான 4-bit quantized மாதிரிகளுக்கு ஒரு பொதுவான விதி: weights-க்காக ஒரு பில்லியன் parameters-க்கு சுமார் 0.5 GB RAM தேவைப்படும். இதனுடன் சுமார் 1 GB overhead மற்றும் context-க்காகச் சிறிது கூடுதல் RAM தேவைப்படும். எனவே, ஒரு 3B மாதிரிக்கு சுமார் 4 GB, 7-8B மாதிரிக்கு சுமார் 8 GB, மற்றும் 14B மாதிரிக்கு சுமார் 16 GB RAM தேவைப்படும். free -h மூலம் உங்கள் RAM இருப்பைச் சரிபார்க்கவும்; இயங்குதளம் (OS) மற்றும் பிற பயன்பாடுகளுக்குத் தேவையான இடத்தையும் விட்டு வைக்கவும்.

Ollama API-க்கு authentication உள்ளதா?

இல்லை. Ollama-வில் உள்ளமைக்கப்பட்ட authentication, API key அல்லது rate limit வசதிகள் இல்லை. port 11434-ஐ அணுகக்கூடிய எவரும் அதைக் கட்டுப்படுத்த முடியும். இதனால்தான் இது இயல்பாகவே 127.0.0.1-ல் பிணைக்கப்பட்டுள்ளது (bind). எனவே, 11434-ஐ ஒருபோதும் 0.0.0.0 வழியாக இணையத்தில் நேரடியாகத் திறக்க வேண்டாம். இதை local-ஆகவோ, private VPN வழியாகவோ அல்லது login வசதியைச் சேர்க்கும் reverse proxy மூலமாகவோ அணுகவும்.

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

Open WebUI-ஐ Docker-ல் --network=host உடன் இயக்கவும். இது host-ன் loopback-ஐப் பகிர்ந்து கொண்டு, http://127.0.0.1:11434-ல் உள்ள native Ollama-வை அணுகும். பின்னர், உங்கள் laptop-லிருந்து அணுகுவதற்கு அதன் port 8080-க்கு முன்னால் ஒரு TLS reverse proxy-ஐ அமைக்கவும். 8080-ஐ firewall-ல் மூடி வைக்கவும், அப்போதுதான் proxy மட்டுமே பொதுவான நுழைவாயிலாக இருக்கும். Open WebUI-ன் சொந்த admin கணக்கு login வசதியை வழங்கும், முதல்முறை இயக்கும்போது அதற்கான கடவுச்சொல்லை (password) நீங்கள் அமைக்கலாம்.

எனது சொந்த application-லிருந்து இதை எவ்வாறு அழைப்பது?

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