Ollama vs vLLM: எது சிறந்தது? முழுமையான ஒப்பீடு

Ollama மற்றும் vLLM ஒப்பீடு

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

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

Ollama என்றால் என்ன

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

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

இதன் வடிவமைப்பு ஒரு பயனருக்கானது. ஜூலை 2026 நிலவரப்படி, OLLAMA_NUM_PARALLEL-க்கான இயல்புநிலை மதிப்பு 1 ஆகும். இதன் பொருள், ஒரு நேரத்தில் ஒரு மாதிரி ஒரு கோரிக்கையை மட்டுமே செயலாக்கும்; மற்ற அனைத்தும் இயல்பாக 512 உள்ளீடுகளைக் கொண்ட வரிசையில் காத்திருக்கும் (OLLAMA_MAX_QUEUE). நீங்கள் parallel அமைப்பை அதிகரிக்கலாம், ஆனால் அதனால் ஏற்படும் விளைவுகள் கீழே உள்ள பகுதியில் விளக்கப்பட்டுள்ளன. நீங்கள் இதற்கு முன்பு Ollama-வை இயக்கியதில்லை என்றால், VPS-ல் Ollama-வை ஹோஸ்ட் செய்தல் மற்றும் port 11434-ஐ மூடி வைத்தல் என்பதிலிருந்து தொடங்கவும், ஏனெனில் இந்த API-ல் எந்தவிதமான அங்கீகாரமும் (authentication) இல்லை.

vLLM என்றால் என்ன

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

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

இதன் நடைமுறைப் பயன்: ஒரே GPU-வில், ஒரு concurrent user-லிருந்து முப்பது பயனர்களாக அதிகரிக்கும்போது, மொத்த tokens per second அளவு கணிசமாக உயர்கிறது; அதே சமயம் ஒரு பயனருக்கான வேகம் நீங்கள் எதிர்பார்ப்பதை விட மிகக் குறைவாகவே குறைகிறது. Ollama-வின் default அமைப்பில், ஒரு பயனரிடமிருந்து முப்பது பயனர்களாக மாறும்போது, இருபத்தொன்பது பேர் காத்திருக்க வேண்டிய சூழல் மட்டுமே உருவாகும்.

Continuous batching-தான் முழுமையான வேறுபாடு

ஒரே மாதிரியான வன்பொருளில் (hardware) ஐந்து கோரிக்கைகள் (requests) ஒரே நேரத்தில் ஒரு server-ஐ அடைவதாகக் கொள்வோம்.

இயல்புநிலை அமைப்புகளுடன் (default settings) இயங்கும் Ollama, முதல் கோரிக்கையை முழுமையாக முடித்த பிறகுதான் இரண்டாவது கோரிக்கையைத் தொடங்கும். ஐந்தாவது பயனர் நான்கு முழுமையான தலைமுறைகள் (generations) முடியும் வரை காத்திருக்க வேண்டும். processor ஒரே நேரத்தில் ஒரு sequence-ல் மட்டுமே வேலை செய்வதால், மொத்த throughput என்பது ஒரு தலைமுறையின் வேகத்திற்குச் சமமாகவே இருக்கும்.

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

நீங்கள் OLLAMA_NUM_PARALLEL=4-ஐ அமைப்பதன் மூலம் இதில் சில பலன்களைப் பெறலாம். ஆனால், இதற்கு memory-யே விலை. ஒவ்வொரு parallel slot-க்கும் அதன் சொந்த KV cache தேவைப்படுகிறது. Ollama context window-ஐ slot-களுக்குப் பிரித்துவிடுகிறது. எனவே, 8192 tokens-க்கு கட்டமைக்கப்பட்ட ஒரு model-ல் நான்கு parallel கோரிக்கைகளை அனுப்பினால், ஒவ்வொரு கோரிக்கைக்கும் 2048 tokens மட்டுமே context-ஆகக் கிடைக்கும். அந்த 8192 என்பது ஒரு நிலையான அளவு அல்ல, அது ஒரு தேர்வுதான். எனவே, num_ctx-ஐ உயர்த்துவதும் அதற்குத் தேவையான RAM-ஐக் கணக்கிடுவதும் நான்கு slot-கள் பயன்பாட்டுக்கு வருமா என்பதைத் தீர்மானிக்கும் முக்கியப் படியாகும். vLLM-ன் paged cache இந்தச் சிக்கலைத் தவிர்க்கிறது, ஏனெனில் ஒரு கோரிக்கை வளரும்போது அதற்கேற்ப blocks ஒதுக்கப்படுகின்றன. எப்படியிருப்பினும், ஒரு server ஒரே நேரத்தில் எத்தனை பயனர்களுக்குச் சேவை செய்ய முடியும் என்பதற்கான உச்சவரம்பு என்பது KV cache அளவு, prefill செலவு மற்றும் queue depth ஆகியவற்றைப் பொறுத்தது. இதுவே ஒருவருக்குச் சரியாகச் செயல்படும் server, ஐந்து பேருக்குச் சேவை செய்யும்போது ஏன் மெதுவாகிறது என்பதற்கான காரணமாகும்.

Install and serve with 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."

The install script creates an ollama system user, installs the binary, and registers ollama.service bound to 127.0.0.1:11434. The eval rate line printed by --verbose is your real tokens per second on that box. Trust it over any published figure. One reading from one prompt is a starting point rather than a capacity number, so timing tokens per second across a concurrency sweep is what tells you whether the box holds up at the load you actually expect, and whether renting a GPU beats paying per token.

To raise concurrency, use a systemd drop-in so an upgrade does not overwrite the change:

sudo systemctl edit ollama.service

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

sudo systemctl restart ollama
ollama ps

ollama ps shows what is loaded, and its PROCESSOR column tells the truth. 100% CPU means no GPU is involved, which is the honest explanation for most reports that Ollama is slow. The OLLAMA_KEEP_ALIVE=30m line in that drop-in matters just as much on a quiet box, because the default unloads the model after five minutes without a request, and keeping the model resident between requests is what stops the first prompt after an idle hour from paying the full load time again.

vLLM-ஐ நிறுவுதல் மற்றும் இயக்குதல்

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

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

பின்பு ஒரு model-ஐ இயக்கவும். இதன் பெயர் Hugging Face repository id-ஆக இருக்க வேண்டும், சுருக்கமான tag-ஆக இருக்கக்கூடாது:

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

முதல்முறை தொடங்கும் போது, weights-ஐப் பதிவிறக்கம் செய்து, GPU-வில் எத்தனை KV cache blocks பொருந்தும் என்பதைக் கணக்கிடுவதால் தொடக்கம் மெதுவாக இருக்கும். இது 8000 port-ல் இயங்கும். 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?"}]}'

server-ல் ஏற்கனவே Docker இருந்தால், official 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 என்பது அவசியமானது, இது அலங்காரத்திற்காக அல்ல: PyTorch shared memory வழியாகவே processes-களுக்கு இடையே tensors-ஐப் பரிமாறுகிறது. Docker-ன் இயல்புநிலை shared-memory அளவு tensor-parallel inference-க்கு போதுமானதாக இருக்காது.

Production சூழலில் மிக முக்கியமான flags: --max-model-len (நீங்கள் பயன்படுத்த விரும்பும் context window அளவு), --gpu-memory-utilization (vLLM பயன்படுத்தக்கூடிய GPU-வின் பங்கு, ஜூலை 2026 நிலவரப்படி இயல்புநிலை 0.92), --tensor-parallel-size (ஒரு model-ஐப் பல GPU-க்களுக்குப் பிரித்து வழங்க), மற்றும் --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 இல்லாத கோரிக்கைகளுக்கு HTTP 401 பிழை கிடைக்கும். இது port 8000-ஐ பொதுவான interface-ல் வெளியிடுவதற்கான காரணம் அல்ல, ஏனெனில் vLLM-ல் rate limiting வசதி இல்லை மற்றும் plain HTTP token-ஐ போக்குவரத்தின் போது இடைமறிக்க முடியும். இருப்பினும், இது server-க்கு ஒரு caller-ஐ அடையாளம் காணும் திறன் உள்ளது என்பதைக் குறிக்கிறது.

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

வன்பொருள்: ஒவ்வொன்றிற்கும் தேவையானவை

Ollama CPU-வில் இயங்குகிறது. 4-bit quantized model-க்கு ஒரு பில்லியன் parameters-க்கு சுமார் அரை gigabyte RAM தேவைப்படும். இதனுடன் runtime overhead-க்காக ஒரு gigabyte மற்றும் context-க்காக கூடுதல் RAM தேவைப்படும். எனவே, 3B model-க்கு சுமார் 4 GB-ம், 8B model-க்கு சுமார் 8 GB-ம் இலவச RAM தேவை. பகிரப்பட்ட vCPU-வில் வேகம் என்பது வினாடிக்கு ஒற்றை இலக்கத்திலிருந்து குறைந்த இரட்டை இலக்க tokens வரை மட்டுமே இருக்கும். இது memory bandwidth சார்ந்த சிக்கல், தவறான configuration அல்ல; எந்த flag-ஐயும் பயன்படுத்தி இதைச் சரிசெய்ய முடியாது. பொதுவான விதியைப் பயன்படுத்துவதற்குப் பதிலாக, ஒரு குறிப்பிட்ட release-ல் இந்த கணக்கீடு எவ்வாறு செயல்படுகிறது என்பதைப் பார்க்க, running Nemotron 3.5 Lightning on a VPS என்பதைப் பார்க்கவும். இது பதிவிறக்க வேண்டிய சரியான tag, load ஆன பிறகு அது எடுத்துக்கொள்ளும் RAM, மற்றும் CPU-only முறை பயன்பாட்டிற்குப் போதுமானதா என்பதைத் தெளிவுபடுத்தும்.

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

எனவே, வன்பொருள் குறித்த கேள்வி பெரும்பாலும் மென்பொருள் குறித்த கேள்விக்கான பதிலைத் தருகிறது. GPU இல்லை என்றால் Ollama-வைப் பயன்படுத்தவும். கோரிக்கைகள் வரிசைப்படுத்தப்படுவதால் (serialised) 5 சதவீத பயன்பாட்டில் இருக்கும் வாடகை GPU-வை வைத்திருந்தால், vLLM-ஐப் பயன்படுத்தவும்.

உங்கள் பணிச்சுமைக்கு எது சிறந்தது

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

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

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

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.

மாதிரியானது (model) எடையை (weights) ஏற்றிய பிறகு மீதமுள்ள நினைவகத்தை விட பெரிய context window-ஐக் கோருகிறது. --max-model-len 8192 மூலம் அதைக்குறைக்கவும், அல்லது வேறு எதுவும் அந்த card-ஐப் பயன்படுத்தவில்லை என்றால் --gpu-memory-utilization-ஐ அதிகரிக்கவும். பயன்பாட்டை 0.95-க்கு மேல் அதிகரிப்பது, இந்தத் தொடக்கப் பிழையைத் தவிர்த்து, பிற்காலத்தில் சுமை அதிகரிக்கும்போது CUDA out-of-memory crash-க்கு வழிவகுக்கும்; இதுவே மோசமான விளைவாகும்.

Ollama generation-ன் போது Killed என்று அச்சிடுகிறது. மாதிரிக்குத் தேவையான RAM அந்த கணினியில் இல்லாததால், Linux out-of-memory killer அந்தச் செயல்பாட்டை நிறுத்திவிட்டது. sudo dmesg | grep -i oom மூலம் இதை உறுதிப்படுத்தவும். இதற்குத் தீர்வு அமைப்புகளை மாற்றுவதல்ல, சிறிய அல்லது அதிக அளவில் quantized செய்யப்பட்ட மாதிரியைப் பயன்படுத்துவதாகும்.

Ollama தனியாக இயங்கும்போது சரியாகப் பதிலளிக்கிறது, ஆனால் சுமை அதிகரிக்கும்போது தேங்குகிறது. எந்தப் பிழையும் தெரிவதில்லை. OLLAMA_NUM_PARALLEL=1 கோரிக்கைகளை வரிசைப்படுத்துவதால், பயனர்கள் அதிகரிக்க அதிகரிக்க பதிலளிக்கும் நேரம் அதிகரிக்கிறது. நீண்ட பதில்கள் வரிசையை மோசமாக்குகின்றன, ஏனெனில் மாதிரி முடிவெடுக்கும் வரை ஒரு பயனர் மட்டுமே அந்த இடத்தை ஆக்கிரமித்திருப்பார். எனவே num_predict மூலம் பதிலைக் கட்டுப்படுத்துவது ஒரு குறிப்பிட்ட சுழற்சி எவ்வளவு நேரம் server-ஐ ஆக்கிரமிக்கலாம் என்பதற்கு ஒரு வரம்பை அமைக்கும். Parallel அமைப்பை அதிகரித்து, ஒவ்வொரு கோரிக்கைக்கான சிறிய context-ஐ ஏற்றுக்கொள்ளுங்கள், அல்லது workload-ஐ vLLM-க்கு மாற்றவும்.

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

மாதிரி (model) காணப்படவில்லை என்று vLLM கூறுகிறது. Ollama தேவைப்படும்போது மாதிரியைப் பதிவிறக்கும், ஆனால் vLLM அவ்வாறு செய்யாது. கோரிக்கை உடலில் (request body) உள்ள model புலம், நீங்கள் தொடங்கிய repository id-உடன் பொருந்த வேண்டும், அல்லது நீங்கள் அமைத்திருந்தால் --served-model-name-ன் மதிப்புடன் பொருந்த வேண்டும். curl http://localhost:8000/v1/models மூலம் சரியான string-ஐ உறுதிப்படுத்தவும்.

இரண்டையும் ஒரே நேரத்தில் இயக்குவது ஒரு நியாயமான தீர்வாகும்

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

FAQ

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

ஒரே GPU-வில் ஒரு கோரிக்கையை (request) கையாளும்போது, இரண்டிலும் கணித செயல்பாடுகள் சமமாக இருப்பதால் வேகத்தில் பெரிய வித்தியாசம் இருக்காது. ஆனால், ஒரே நேரத்தில் பல கோரிக்கைகள் வரும்போது vLLM மிக வேகமாகச் செயல்படும். ஏனெனில், vLLM-ன் continuous batching வசதி, அனைத்து active sequences-களையும் ஒரே forward pass-ல் decode செய்கிறது. Ollama-வின் இயல்புநிலை அமைப்பு, கோரிக்கைகளை ஒவ்வொன்றாகவே கையாள்கிறது. CPU-மட்டும் கொண்ட கணினிகளில் இந்த ஒப்பீடு பொருந்தாது: அங்கு Ollama இயங்கும், ஆனால் vLLM திறம்பட இயங்காது.

GPU இல்லாமல் vLLM-ஐ இயக்க முடியுமா?

பயனுள்ள வகையில் இயக்க முடியாது. இதன் standard wheels அனைத்தும் NVIDIA அல்லது AMD GPU-களை இலக்காகக் கொண்டவை. vLLM-ன் முக்கிய நோக்கமே, batched requests மூலம் accelerator-ஐ முழுமையாகப் பயன்படுத்துவதுதான்; CPU-வில் இந்த வசதி இல்லை. மேம்பாட்டுப் பணிகளுக்காக (development work) ஒரு 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 தேவைப்படும் (ஒரு பில்லியன் parameters-க்கு தோராயமாக 2 GB). இதனுடன் KV cache-க்கும் கூடுதல் இடம் தேவை. 24 GB card போதுமானதாக இருக்கும். 16 GB card-ஐப் பயன்படுத்தினால், quantized checkpoint அல்லது சிறிய model-ஐப் பயன்படுத்த வேண்டும். vLLM, --gpu-memory-utilization மூலம் நிர்ணயிக்கப்பட்ட GPU நினைவகத்தின் ஒரு பகுதியை எடுத்துக்கொள்ளும்; ஜூலை 2026 நிலவரப்படி இதன் இயல்புநிலை மதிப்பு 0.92 ஆகும்.

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

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