Ollama vs vLLM: எந்த LLM server தேர்வு?

Ollama vs vLLM, ஒரு பத்தியில்

Ollama என்பது server இணைக்கப்பட்ட model manager ஆகும்: இது quantized weights-ஐ download செய்து, load செய்து, 127.0.0.1:11434-இல் பதிலளிக்கிறது; அந்த box-இல் CPU மட்டுமே இருந்தாலும் அதைப் பயன்படுத்தும். vLLM என்பது throughput engine ஆகும்: ஒரே நேரத்தில் பல requests இயங்கும்போது GPU-ஐ தொடர்ந்து முழுத் திறனில் பயன்படுத்துகிறது. GPU இல்லாத machine-இல் vLLM பொருத்தமான tool அல்ல. முடிவு இதுதான். ஒருவர் local assistant-உடன் பேசுவது Ollama job ஆகும். ஒரு application, ஒரு team-க்கு சேவை வழங்குவது vLLM job ஆகும்.

இரண்டும் OpenAI-compatible HTTP API-ஐப் பயன்படுத்துகின்றன. எனவே base URL-ஐ மாற்றுவதன் மூலம் client code-ஐ ஒன்றிலிருந்து மற்றொன்றுக்கு மாற்றலாம். API வேறுபாடு அல்ல. முதல் request இன்னும் tokens உருவாக்கிக்கொண்டிருக்கும்போது இரண்டாவது request வந்தால் என்ன நடக்கிறது என்பதே உண்மையான வேறுபாடு.

Ollama உண்மையில் என்ன

Ollama என்பது பயன்பாட்டை எளிதாக்கும் ஒரு அடுக்கு. ஒரே install command மூலம் இது ஒரு model registry (ollama pull llama3.1:8b), weights-க்கான local store, chat prompt, systemd service மற்றும் HTTP API ஆகியவற்றை வழங்குகிறது. இது வழங்கும் models, பொதுவாக 4-bit quantized செய்யப்பட்ட GGUF files ஆகும். அதனால் 7B அல்லது 8B model, disk-ல் 16 GB ஆக இல்லாமல் சுமார் 5 GB ஆக இருக்கும். CPU inference சாத்தியமாக இருப்பதற்கான காரணம் quantization ஆகும்.

இதன் runner, llama.cpp-ஐ அடிப்படையாகக் கொண்டது. llama.cpp என்பது சாதாரண hardware-ல் GGUF quantization-ஐ நடைமுறைக்கு ஏற்றதாக மாற்றிய C++ inference library ஆகும். பின்னர் சில புதிய model families-க்காக Ollama தனது சொந்த engine-ஐ சேர்த்துள்ளது. இருப்பினும், அது வழங்கும் பெரும்பாலானவற்றின் அடித்தளமாக llama.cpp இன்னும் உள்ளது. எனவே Ollama-வை llama.cpp-உடன் ஒப்பிடும்போது, பெரும்பாலும் ஒரு ergonomics layer-ஐ அது wrap செய்யும் component-உடன் ஒப்பிடுகிறார்கள்.

இதன் design target ஒரு user ஆகும். July 2026 நிலவரப்படி OLLAMA_NUM_PARALLEL-க்கான default மதிப்பு 1 ஆகும். இதன் பொருள், ஒரு model ஒரே நேரத்தில் ஒரு request-ஐ மட்டுமே process செய்யும். மற்ற அனைத்தும் default-ஆக 512 entries கொண்ட queue-ல் காத்திருக்கும் (OLLAMA_MAX_QUEUE). parallel setting-ஐ அதிகரிக்கலாம். அதனால் ஏற்படும் செலவை கீழே உள்ள section விளக்குகிறது. இதற்கு முன் Ollama-ஐ இயக்கவில்லை என்றால், VPS-ல் Ollama-ஐ host செய்து port 11434-ஐ மூடிய நிலையில் வைத்திருப்பது என்பதிலிருந்து தொடங்குங்கள். ஏனெனில் API-யில் எந்தவித authentication-மும் இல்லை.

vLLM உண்மையில் என்ன

vLLM என்பது inference server மட்டுமே. இது model library-ஐ நிர்வகிக்காது. இதில் chat prompt இல்லை. Request நேரத்தில் இது உங்களுக்காக model-ஐ download செய்யாது. Launch செய்யும்போது Hugging Face repository-ஐ குறிப்பிட வேண்டும். இது அந்த ஒரு model-ஐ load செய்து, process-ஐ நீங்கள் நிறுத்தும் வரை சேவை வழங்கும்.

இந்தக் குறுகிய செயல்பாட்டின் பயன் throughput ஆகும். இதை இரண்டு mechanisms செயல்படுத்துகின்றன. PagedAttention, KV cache-ஐ (key-value cache; active request ஒவ்வொன்றிற்கும் model வைத்திருக்கும் ஒவ்வொரு token-ன் attention state) fixed-size blocks-ல் சேமிக்கிறது. இது operating system memory-ஐ pages ஆகப் பிரிப்பதைப் போன்றது. Worst case-க்கான அளவில் ஒரு பெரிய contiguous reservation இனி ஒரு request-க்கு தேவையில்லை. ஆகவே முன்பு reserve செய்யப்பட்டிருந்தும் பயன்படுத்தப்படாத memory, கூடுதல் concurrent request-களுக்குக் கிடைக்கிறது. Continuous batching, இயங்கிக் கொண்டிருக்கும் batch முடியும் வரை காத்திருக்காமல், அடுத்த decoding step-ல் புதிய request-ஐ batch-ல் சேர்க்கிறது. ஒரு sequence முடிந்ததும் அது உடனடியாக batch-இலிருந்து வெளியேறுகிறது. அதன் slot உடனே மற்றொரு request-க்கு வழங்கப்படுகிறது.

நடைமுறை விளைவு இதுதான்: ஒரு GPU-ல் ஒரே நேரத்தில் பயன்படுத்தும் user எண்ணிக்கை 1-லிருந்து 30 ஆக உயரும்போது, மொத்த tokens per second குறிப்பிடத்தக்க அளவில் அதிகரிக்கிறது. அதே நேரத்தில், ஒவ்வொரு user-க்கும் கிடைக்கும் speed, எதிர்பார்ப்பதைவிட மிகக் குறைவாகவே குறைகிறது. Ollama-வின் default செயல்பாட்டில், user எண்ணிக்கை 1-லிருந்து 30 ஆக உயர்ந்தால், 29 பேர் காத்திருக்க வேண்டியதாகிறது.

Continuous batching தான் முழு வித்தியாசம்

ஒரே hardware-ல் இயங்கும் ஒவ்வொரு server-க்கும் ஒரே நேரத்தில் ஐந்து requests வருகின்றன என்று கருதுங்கள்.

Ollama-வின் default settings-ல் request one முழுமையாக முடிந்த பிறகே request two தொடங்கும். இதே வரிசையில் தொடர்ந்து செயல்படும். இதனால் fifth caller நான்கு முழு generations முடியும் வரை காத்திருக்க வேண்டும். மொத்த throughput, தோராயமாக, ஒரு generation-ன் வேகத்துக்கு மட்டுமே சமமாக இருக்கும். காரணம், processor ஒரே நேரத்தில் ஒரு sequence-ல் மட்டுமே செயல்படுகிறது.

vLLM ஒரே forward pass-ல் ஐந்து sequences-ஐயும் decode செய்கிறது. ஐந்து sequences-க்கு ஒரு token உருவாக்கும் செலவு, ஒரு sequence-க்கு ஒரு token உருவாக்கும் செலவைவிட மிகக் குறைவாகவே அதிகமாகும். காரணம், அதிக செலவான பணி model weights-ஐ memory-யிலிருந்து படிப்பதாகும். அந்த read முழு batch-க்கும் பகிரப்படுகிறது. CPU inference slow ஆக இருப்பதற்கும் இதே memory-bandwidth காரணம்தான்: arithmetic-க்காக அல்ல, weights-ஐ memory-க்கு இடையில் நகர்த்துவதற்காகவே செலவு ஏற்படுகிறது.

OLLAMA_NUM_PARALLEL=4-ஐ அமைத்து இதன் ஒரு பகுதியைப் பெறலாம். இதற்கான செலவு memory ஆகும். ஒவ்வொரு parallel slot-க்கும் தனித்த KV cache தேவைப்படும். மேலும், Ollama context window-ஐ slots-க்கு இடையில் பிரிக்கிறது. ஆகவே, 8192 tokens-க்கு configured செய்யப்பட்ட model-க்கு எதிராக நான்கு parallel requests இயக்கினால், ஒவ்வொரு request-க்கும் 2048 tokens context மட்டுமே கிடைக்கும். vLLM-ன் paged cache இந்த trade-ஐத் தவிர்க்கிறது. காரணம், request உண்மையில் வளரும்போது அதற்குத் தேவையான blocks ஒதுக்கப்படுகின்றன.

Ollama மூலம் நிறுவி சேவை வழங்குதல்

curl -fsSL https://ollama.com/install.sh | sh
ollama pull llama3.1:8b
ollama run --verbose llama3.1:8b "Write two sentences about Linux."

நிறுவல் script ஒரு ollama system user-ஐ உருவாக்கி, binary-ஐ நிறுவி, 127.0.0.1:11434-க்கு bind செய்யப்பட்ட ollama.service-ஐ register செய்கிறது. --verbose அச்சிடும் eval rate வரி, அந்த server-ல் உண்மையாகக் கிடைக்கும் tokens per second மதிப்பாகும். வெளியிடப்பட்ட எந்த எண்ணிக்கையையும் விட இதை நம்புங்கள்.

concurrency-ஐ அதிகரிக்க, upgrade செய்தாலும் இந்த மாற்றம் மேலெழுதப்படாதபடி systemd drop-in-ஐ பயன்படுத்துங்கள்:

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_KEEP_ALIVE=30m"

sudo systemctl restart ollama
ollama ps

ollama ps தற்போது load செய்யப்பட்டுள்ளவற்றைக் காட்டுகிறது. அதன் PROCESSOR column உண்மையான நிலையைத் தெரிவிக்கிறது. 100% CPU என்றால் GPU பயன்படுத்தப்படவில்லை என்பதாகும். Ollama மெதுவாக இருப்பதாக வரும் பெரும்பாலான அறிக்கைகளுக்கான நேர்மையான விளக்கம் இதுவே.

vLLM மூலம் நிறுவி சேவை வழங்குதல்

vLLM-க்கு Linux மற்றும் Python 3.10 முதல் 3.13 வரை தேவை. குறிப்பிட்ட PyTorch build-ஐ vLLM நிறுவுவதால், அதை தனி virtual environment-ல் நிறுவவும்:

uv venv --python 3.12 --seed
source .venv/bin/activate
uv pip install vllm --torch-backend=auto

பின்னர் ஒரு model-ஐ சேவை வழங்கவும். இங்குள்ள பெயர் short tag அல்ல; அது Hugging Face repository id ஆகும்:

vllm serve Qwen/Qwen2.5-1.5B-Instruct

முதல் முறையில் startup மெதுவாக இருக்கும். முதலில் weights பதிவிறக்கப்படும். அதன் பிறகு, எத்தனை KV cache blocks பொருந்தும் என்பதைத் தீர்மானிக்க GPU profile செய்யப்படும். இது port 8000-ல் listening செய்யும். Client code எழுதுவதற்கு முன் இதைச் சரிபார்க்கவும்:

curl http://localhost:8000/v1/models
curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{"model": "Qwen/Qwen2.5-1.5B-Instruct", "messages": [{"role": "user", "content": "Who won the world series in 2020?"}]}'

Docker ஏற்கனவே அந்த server-ல் இருந்தால், அதிகாரப்பூர்வ image-ஐப் பயன்படுத்துவது CUDA dependency-களைத் தனியாக அமைக்கும் பணியைத் தவிர்க்கிறது:

docker run --runtime nvidia --gpus all \
    -v ~/.cache/huggingface:/root/.cache/huggingface \
    --env "HF_TOKEN=$HF_TOKEN" \
    -p 8000:8000 \
    --ipc=host \
    vllm/vllm-openai:latest \
    --model Qwen/Qwen3-0.6B

--ipc=host அவசியமானது; இது அலங்காரத்திற்கான flag அல்ல. PyTorch, processes இடையே tensors-ஐ shared memory மூலம் மாற்றுகிறது. Tensor-parallel inference-க்கு default Docker shared-memory allocation மிகவும் குறைவாக உள்ளது.

Production-ல் முக்கியமான flags இவை: --max-model-len (பயன்படுத்த விரும்பும் context window), --gpu-memory-utilization (vLLM பயன்படுத்த அனுமதிக்கப்படும் GPU card memory-யின் பகுதி; July 2026 நிலவரப்படி default 0.92), ஒரு model-ஐ பல GPUs-களில் பிரிப்பதற்கான --tensor-parallel-size, மற்றும் --api-key.

vLLM-ல் authentication ஒரு flag மூலம் உள்ளது; Ollama-ல் அது இல்லை

நீங்கள் bearer token வழங்கினால், vLLM அதைக் கட்டாயமாக்குகிறது:

vllm serve Qwen/Qwen2.5-1.5B-Instruct --api-key token-abc123

அதே மதிப்பை VLLM_API_KEY environment variable மூலமும் வழங்கலாம். இந்த token இல்லாத request-க்கு HTTP 401 கிடைக்கும். இருப்பினும், இதனால் port 8000-ஐ public interface-ல் வெளியிடுவது பாதுகாப்பானது என்று கருதக்கூடாது. vLLM-ல் rate limiting இல்லை. மேலும், சாதாரண HTTP token network traffic வழியாகப் படிக்கக்கூடியதாக இருக்கும். ஆனால் server-க்கு request அனுப்புபவர் என்ற கருத்து vLLM-ல் உள்ளது.

Ollama-ல் இத்தகைய authentication வசதி எதுவும் இல்லை. key இல்லை, login இல்லை, allow-list இல்லை. port 11434-ஐ அணுகக்கூடிய எந்த process-மும் models-ஐ இயக்கலாம், pull செய்யலாம் அல்லது delete செய்யலாம். அதை loopback-ல் மட்டும் வைத்திருந்து, நீங்கள் நேரடியாக நிர்வகிக்கும் WireGuard VPN மூலம் அணுகவும். மாற்றாக, TLS (transport layer security)-ஐ முடிக்கும் authentication கொண்ட reverse proxy மூலம் அணுகவும்.

Hardware: ஒவ்வொன்றுக்கும் தேவையானவை

Ollama CPU-யில் இயங்கும். 4-bit quantized model-க்கு, ஒவ்வொரு billion parameter-க்கும் தோராயமாக அரை gigabyte RAM தேவைப்படும். இதனுடன் சுமார் 1 gigabyte runtime overhead மற்றும் context-க்கு கூடுதல் memory தேவைப்படும். எனவே, 3B model-க்கு சுமார் 4 GB free memory-யும், 8B model-க்கு சுமார் 8 GB memory-யும் தேவைப்படும். பகிரப்பட்ட vCPU-யில் வேகம், ஒரு வினாடிக்கு single digit முதல் குறைந்த double digit tokens வரை இருக்கும். இது memory bandwidth காரணமாகும்; misconfiguration காரணமல்ல. எந்த flag-உம் இதைச் சரிசெய்யாது.

vLLM, GPU இருப்பதாகக் கருதுகிறது. இதன் default path, 16-bit precision-ல் unquantized weights-ஐ வழங்குகிறது. இதற்கு ஒவ்வொரு billion parameters-க்கும் தோராயமாக 2 GB video memory தேவைப்படும். ஆகவே, 8B model-க்கு weights-க்கே சுமார் 16 GB video memory தேவைப்படும். நீங்கள் vLLM-ஐ இயக்கிய concurrency-க்கு தேவையான KV cache இதற்கு மேலாகத் தேவைப்படும். 24 GB card-ல் cache-க்கு பயன்படுத்தக்கூடிய memory மீதமாக இருக்கும். 16 GB card-ல் அது போதாது. எனவே, சிறிய model-ஐத் தேர்ந்தெடுக்க வேண்டும் அல்லது quantized checkpoint உடன் --quantization-ஐ pass செய்ய வேண்டும். CPU backend உள்ளது. ஆனால் standard wheels அதற்காக build செய்யப்படவில்லை. மேலும், vLLM-ஐ இயக்குவதற்கான முக்கிய காரணத்தையே அது நீக்கிவிடுகிறது.

எனவே, பெரும்பாலான நேரங்களில் hardware பற்றிய கேள்வியே software பற்றிய கேள்விக்கும் பதிலளிக்கிறது. GPU இல்லையெனில் Ollama-ஐப் பயன்படுத்துங்கள். வாடகைக்கு எடுத்த GPU-யில் requests serialise செய்யப்படுவதால் utilisation 5 percent-ஆக இருந்தால், vLLM-ஐப் பயன்படுத்துங்கள்.

உங்கள் workload-க்கு எது பொருத்தமானது

• ஒரே நபர் பயன்படுத்தும் CPU VPS-ல் வரைவு எழுதுதல் மற்றும் சுருக்கம் செய்தல்: Ollama. வேகம் ஏற்றுக்கொள்ளத்தக்கது; இதைவிட எளிமையானது எதுவும் இல்லை.
• coding assistant அல்லது உங்கள் tools-ஐ local model-ுடன் இணைக்கும் MCP server, அதை நீங்கள் மட்டுமே அழைக்கும் நிலை: Ollama. ஒரே நேரத்தில் ஒரு கோரிக்கை மட்டுமே இருப்பதே உண்மையான workload.
• இந்த வாரம் ஐந்து models-ஐ ஒப்பிடுதல்: Ollama. tags செய்யப்பட்ட models-ஐ pull செய்து delete செய்வதற்கு இது மிகவும் பொருத்தமானது; vLLM-ல் ஒவ்வொரு model-க்கும் process restart தேவைப்படும்.
• உண்மையான users பயன்படுத்தும் internal app, chat product அல்லது retrieval pipeline: vLLM. இங்குதான் batching GPU செலவை நியாயப்படுத்துகிறது.
• இரவு நேரத்தில் நூறாயிரம் documents-ஐ மதிப்பிடும் batch job: அதிக --max-num-seqs உடன் vLLM. முக்கியமான ஒரே அளவுகோல் throughput; ஒவ்வொரு document-க்கான latency முக்கியமல்ல.
• பல self-hosted AI agents ஒரே நேரத்தில் model-ஐ அணுகும் agent platform: vLLM. agent traffic திடீர் அதிகரிப்புகளுடன் வரும்; இயல்பாகவே parallel ஆக இருக்கும்.

நீங்கள் காணும் strings உடனான தோல்வி நிலைகள்

KV cache பிழையுடன் vLLM தொடங்க மறுக்கிறது. செய்தியில் இரண்டு எண்களும் குறிப்பிடப்படும்:

ValueError: The model's max seq len (32768) is larger than the maximum number of tokens that can be stored in KV cache (8192). Try increasing gpu_memory_utilization or decreasing max_model_len when initializing the engine.

Weights-ஐ ஏற்றிய பிறகு மீதமுள்ள memory-யை விட model அறிவிக்கும் context window பெரியதாக உள்ளது. இதை --max-model-len 8192 மூலம் குறைக்கவும். Card-ஐ வேறு எதுவும் பயன்படுத்தவில்லை என்றால் --gpu-memory-utilization-ஐ அதிகரிக்கவும். Utilisation-ஐ சுமார் 0.95-ஐ கடந்தும் அதிகரித்தால், இந்த startup பிழைக்குப் பதிலாக load நேரத்தில் பின்னர் CUDA out-of-memory crash ஏற்படக்கூடும். இவ்விரண்டில் அதுவே மிகவும் மோசமானது.

Generation நடுவில் Ollama Killed என அச்சிடுகிறது. Model-க்கு கிடைக்கும் RAM-ஐ விட அதிக RAM தேவைப்பட்டதால் Linux out-of-memory killer process-ஐ நிறுத்தியது. sudo dmesg | grep -i oom மூலம் உறுதிப்படுத்தவும். தீர்வு குறைந்த அளவிலான அல்லது அதிகமாக quantized செய்யப்பட்ட model-ஐ பயன்படுத்துவதாகும்; setting-ஐ மாற்றுவது தீர்வல்ல.

தனியாக இயங்கும்போது Ollama சரியாகப் பதிலளிக்கிறது; load-இல் தடைபடுகிறது. எங்கும் எந்தப் பிழையும் தோன்றாது. Caller-கள் அதிகரிக்கும்போது requests அதிக நேரம் எடுக்கும். காரணம் OLLAMA_NUM_PARALLEL=1 அவற்றை serialise செய்வதாகும். இதன் மதிப்பை அதிகரித்து, ஒவ்வொரு request-க்குமான context அளவு குறைவதை ஏற்கவும். அல்லது workload-ஐ vLLM-க்கு மாற்றவும்.

ஒவ்வொரு call-க்கும் vLLM 401 திருப்பி அளிக்கிறது. --api-key உடன் அதைத் தொடங்கியுள்ளீர்கள்; client எந்த Authorization header-ஐயும் அனுப்பவில்லை. பெரும்பாலான OpenAI client libraries key ஆக நீங்கள் வழங்கும் மதிப்பையே அனுப்பும். எனவே flag-ஐ நீக்குவதற்குப் பதிலாக, அந்த key-ஐ client-இல் அமைக்கவும்.

Model காணப்படவில்லை என்று vLLM கூறுகிறது. Ollama தேவைக்கேற்ப model-ஐ pull செய்கிறது; vLLM அவ்வாறு செய்யாது. Request body-யில் உள்ள model field, நீங்கள் launch செய்த repository id-க்கு ஒத்திருக்க வேண்டும். அல்லது --served-model-name-ஐ அமைத்திருந்தால், அதன் மதிப்புடன் ஒத்திருக்க வேண்டும். சரியான string-ஐ curl http://localhost:8000/v1/models மூலம் உறுதிப்படுத்தவும்.

இரண்டையும் இயக்குவது பொருத்தமான தீர்வாகும்

இவை ஒன்றுக்கொன்று விலக்கானவை அல்ல. பொதுவாக, application-க்கு சேவை வழங்கும் GPU instance-ல் vLLM இயங்கும். அதனுடன் உள்ள வழக்கமான VPS-ல் local scripts, cron jobs மற்றும் புதிய model releases-ஐச் சோதிப்பதற்காக Ollama இயங்கும். இரு endpoints-உம் OpenAI-compatible ஆக உள்ளன. எனவே, ஒரே client library மற்றும் base-URL மாற்றம் போதுமானது. இங்கு engine-களைத் தேர்ந்தெடுப்பதைவிட cost control முக்கியமானது. காரணம், idle GPU-க்கும் busy GPU-க்கும் ஒரே கட்டணம் விதிக்கப்படுகிறது. மேலும், agent மற்றும் inference செலவுகளை முன்கூட்டியே கணிக்கக்கூடியதாக வைத்திருப்பது server-ஐத் தேர்ந்தெடுப்பதிலிருந்து வேறுபட்ட ஒரு செயல்முறையாகும்.

FAQ

vLLM, Ollama-வை விட வேகமானதா?

அதே GPU-யில் ஒரு request-க்கு வேக வித்தியாசம் குறைவாக இருக்கும். இரண்டும் ஒரே கணிதச் செயல்பாடுகளைச் செய்கின்றன. ஒரே நேரத்தில் பல requests இருக்கும்போது vLLM மிகவும் வேகமானது. காரணம், continuous batching மூலம் செயல்பாட்டில் உள்ள ஒவ்வொரு sequence-யையும் ஒரே forward pass-ல் decode செய்கிறது. Ollama-வின் இயல்புநிலை செயல்பாடு அவற்றை ஒன்றன்பின் ஒன்றாக இயக்குகிறது. CPU மட்டும் உள்ள machine-ல் இந்தக் கேள்வி பொருந்தாது. Ollama அங்கு இயங்கும். vLLM நடைமுறையில் இயங்காது.

GPU இல்லாமல் vLLM இயங்குமா?

பயனுள்ள முறையில் இயங்காது. வழக்கமான wheels, NVIDIA அல்லது AMD GPUs-ஐ இலக்காகக் கொண்டவை. Batched requests மூலம் accelerator-ஐ முழுமையாகப் பயன்படுத்துவதே vLLM-ன் நோக்கம். CPU-யில் அந்தப் பயன்பாடு கிடையாது. Development பணிகளுக்காக CPU backend உள்ளது. உண்மையான CPU inference-க்கு Ollama அல்லது llama.cpp-ஐ நேரடியாகப் பயன்படுத்துங்கள்.

Ollama-வுக்கும் llama.cpp-க்கும் என்ன வித்தியாசம்?

llama.cpp என்பது inference library. GGUF என்பது அதற்கான quantized weight format. Ollama-வின் runner, llama.cpp-ஐ அடிப்படையாகக் கொண்டது. llama.cpp உங்களிடம் ஒப்படைக்கும் பகுதிகளுக்கு Ollama கூடுதல் வசதிகளை வழங்குகிறது: model registry, automatic download, resident server, systemd unit மற்றும் OpenAI-compatible endpoint. சில புதிய model families-க்காக Ollama தனக்கென engine-ஐச் சேர்த்துள்ளது. எனவே அடிப்படை செயல்பாட்டில் இவை இரண்டும் இனி ஒரே மாதிரியானவை அல்ல.

8B model-க்கு vLLM-க்கு எவ்வளவு GPU memory தேவை?

16-bit precision-ல் weights-க்கு மட்டும் சுமார் 16 GB தேவைப்படும். இது ஒரு billion parameters-க்கு தோராயமாக 2 GB ஆகும். இதற்கு மேலாக KV cache-க்கும் இடம் தேவை. 24 GB card போதுமானது. 16 GB card-க்கு quantized checkpoint அல்லது சிறிய model தேவை. --gpu-memory-utilization அமைக்கும் card memory-யின் ஒரு பகுதியை vLLM பயன்படுத்துகிறது. July 2026 நிலவரப்படி இதன் இயல்புநிலை மதிப்பு 0.92.

இவற்றுக்கிடையில் மாறும்போது application code-ஐ மாற்ற வேண்டுமா?

பொதுவாக base URL, API key மற்றும் model name ஆகியவற்றை மட்டும் மாற்ற வேண்டும். Ollama தனது OpenAI-compatible surface-ஐ http://127.0.0.1:11434/v1-ல் வழங்குகிறது. அது key-ஐ புறக்கணிக்கிறது. vLLM, http://localhost:8000/v1-ஐ வழங்குகிறது. நீங்கள் key-ஐ அமைத்திருந்தால் அதை vLLM சரிபார்க்கும். Model names-ன் வடிவம் வேறுபடும்: Ollama-க்கு llama3.1:8b, vLLM-க்கு Qwen/Qwen2.5-1.5B-Instruct போன்ற முழுமையான repository id.