Ollama vs vLLM: ఏ LLM server ఎంచుకోవాలి?

Ollama vs vLLM, ఒక పేరాలో

Ollama అనేది server తో కూడిన model manager: ఇది quantized weights ను download చేసి, load చేసి, 127.0.0.1:11434 పై సమాధానాలు ఇస్తుంది; ఆ machine లో CPU మాత్రమే ఉన్నా అదే ఉపయోగిస్తుంది. vLLM అనేది throughput engine: ఒకేసారి అనేక requests నడుస్తున్నప్పుడు GPUని నిరంతరం పూర్తి సామర్థ్యంతో ఉపయోగిస్తుంది. GPU లేని machineలో ఇది సరైన సాధనం కాదు. నిర్ణయం మొత్తం ఇంతే. ఒక వ్యక్తి local assistant తో మాట్లాడటం Ollama పని. ఒక team కోసం application సేవలు అందించడం vLLM పని.

రెండూ OpenAI-compatible HTTP API ను ఉపయోగిస్తాయి. అందువల్ల base URL మార్చడం ద్వారా client code ను ఒకదానినుంచి మరొకదానికి మార్చవచ్చు. తేడా APIలో లేదు. మొదటి request tokens ను ఇంకా generate చేస్తుండగా రెండో request వచ్చినప్పుడు ఏమి జరుగుతుందో అదే అసలు తేడా.

Ollama వాస్తవానికి ఏమిటి

Ollama ఒక సౌకర్య పొర. ఒకే install command ద్వారా ఇది model registry (ollama pull llama3.1:8b), weights కోసం local store, chat prompt, systemd service, మరియు HTTP API అందిస్తుంది. ఇది అందించే models లో ఎక్కువ భాగం GGUF files. సాధారణంగా ఇవి 4-bit quantized గా ఉంటాయి. అందుకే 7B లేదా 8B model disk పై 16 GB కాకుండా సుమారు 5 GB స్థలాన్ని మాత్రమే ఉపయోగిస్తుంది. Quantization వల్ల CPU inference కు అవసరమైన memory తగ్గుతుంది. Apple Silicon Macs లో ఇది MLX engine ద్వారా safetensors ఆధారిత models ను కూడా నడపగలదు. v0.40.0 (September 2026) నుంచి మద్దతు ఉన్న architectures స్వయంచాలకంగా MLX పై నడుస్తాయి.

దీని GGUF runner llama.cpp పై ఆధారపడి ఉంటుంది. llama.cpp సాధారణ hardware పై GGUF quantization ను ఆచరణయోగ్యంగా చేసిన C++ inference library. October 2026 నాటికి Ollama రెండు engines కు మద్దతు ఇస్తుంది: llama.cpp మరియు MLX. Linux builds CUDA తో MLX inference కు కూడా మద్దతు ఇస్తాయి. Development guide లో cmake -B build . -DOLLAMA_MLX_BACKENDS=cuda_v13 ద్వారా ఈ backend ను enable చేయవచ్చు. దీనికి CUDA 13+ మరియు cuDNN 9+ prerequisites గా అవసరం. అందువల్ల Ollama ను llama.cpp తో పోల్చేటప్పుడు, వాస్తవానికి చాలావరకు ergonomics layer ను అది wrap చేసే software తో పోలుస్తున్నారు.

దీని design target ఒక user. October 2026 నాటికి OLLAMA_NUM_PARALLEL యొక్క default విలువ 1. అంటే ఒక model ఒకేసారి ఒక request ను process చేస్తుంది. మిగతా requests అన్నీ default గా 512 entries కలిగిన queue లో వేచి ఉంటాయి (OLLAMA_MAX_QUEUE). మీరు parallel setting ను పెంచవచ్చు. అయితే దాని వల్ల కలిగే ఖర్చును దిగువ section వివరిస్తుంది. మీరు ఇంతకు ముందు Ollama ను run చేయకపోతే, VPS పై Ollama ను host చేసి port 11434 ను మూసి ఉంచడం నుంచి ప్రారంభించండి. ఎందుకంటే local API కి authentication అవసరం లేదు.

vLLM అంటే వాస్తవంగా ఏమిటి

vLLM కేవలం inference server మాత్రమే. ఇది model library ను నిర్వహించదు, నడుస్తున్న server కోసం vllm chat client ను అందిస్తుంది, అలాగే request వచ్చినప్పుడు మీ కోసం model ను download చేయదు. ప్రారంభించే సమయంలో మీరు Hugging Face repository ను పేర్కొంటారు. vLLM ఆ ఒక్క model ను load చేసి, మీరు process ను ఆపే వరకు దానిని serve చేస్తుంది.

ఈ పరిమిత పరిధి వల్ల మీకు లభించేది throughput. దీన్ని రెండు విధానాలు సాధ్యం చేస్తాయి. PagedAttention KV cache ను (key-value cache, ప్రతి active request కోసం model నిర్వహించే ప్రతి token కు సంబంధించిన attention state) fixed-size blocks లో నిల్వ చేస్తుంది. ఇది operating system memory ని pages గా నిర్వహించే విధానంతో సమానం. ఇప్పుడు request కు worst case కోసం ముందుగానే పరిమాణం నిర్ణయించిన ఒకే పెద్ద contiguous reservation అవసరం లేదు. అందువల్ల ఇంతకుముందు reserve చేసి ఉపయోగించకుండా ఉన్న memory మరిన్ని concurrent requests కోసం అందుబాటులోకి వస్తుంది. Continuous batching వల్ల కొత్త request, ప్రస్తుత batch పూర్తయ్యే వరకు వేచి ఉండకుండా, తదుపరి decoding step వద్ద నడుస్తున్న batch లో చేరుతుంది. ఒక sequence పూర్తయిన వెంటనే batch నుంచి తొలగిపోతుంది, దాని slot ను మరో request తో నింపుతారు.

ప్రాయోగిక ఫలితం: ఒకే GPU పై concurrent users సంఖ్యను ఒకటి నుంచి ముప్పైకి పెంచితే మొత్తం tokens per second గణనీయంగా పెరుగుతుంది. అయితే ఒక్కో user speed మీరు ఊహించినంతగా తగ్గదు. Ollama యొక్క default ప్రవర్తనలో, ఒక user నుంచి ముప్పై users కు పెంచితే, మిగిలిన ఇరవై తొమ్మిది మంది కేవలం వేచి ఉండాల్సి వస్తుంది.

Continuous batching అనేది అసలైన వ్యత్యాసం

ఒకే హార్డ్‌వేర్‌పై ఐదు అభ్యర్థనలు ఒకే సమయంలో ఒక సర్వర్‌కు వస్తున్నాయని ఊహించుకోండి.

డిఫాల్ట్ సెట్టింగ్‌లతో ఉన్న Ollama మొదటి అభ్యర్థన పూర్తయ్యే వరకు వేచి ఉండి, ఆపై రెండో అభ్యర్థనను చేపడుతుంది. ఐదవ వినియోగదారుడు నాలుగు పూర్తి జనరేషన్ల వరకు వేచి ఉండాలి. మొత్తం త్రూపుట్ (throughput) ఒక జనరేషన్ వేగానికి సమానంగా ఉంటుంది, ఎందుకంటే ప్రాసెసర్ ఒక సమయంలో ఒక సీక్వెన్స్‌పై మాత్రమే పనిచేస్తుంది.

vLLM ఐదు అభ్యర్థనలను ఒకే ఫార్వర్డ్ పాస్‌లో డీకోడ్ చేస్తుంది. ఐదు సీక్వెన్స్‌ల కోసం ఒక టోకెన్‌ను జనరేట్ చేయడం, ఒక సీక్వెన్స్ కోసం ఒక టోకెన్‌ను జనరేట్ చేయడం కంటే పెద్దగా ఖర్చుతో కూడుకున్నది కాదు. ఎందుకంటే మోడల్ వెయిట్స్‌ను మెమరీ నుండి చదవడం అనేది ఖరీదైన ప్రక్రియ, మరియు ఈ రీడ్ ఆపరేషన్ మొత్తం బ్యాచ్‌ అంతటికీ భాగస్వామ్యం చేయబడుతుంది. CPU ఇన్ఫరెన్స్ నెమ్మదిగా ఉండటానికి కూడా ఇదే మెమరీ-బ్యాండ్‌విడ్త్ కారణం: మీరు వెయిట్స్‌ను తరలించడానికి చెల్లిస్తారు, అంకగణితానికి (arithmetic) కాదు.

మీరు OLLAMA_NUM_PARALLEL=4 సెట్ చేయడం ద్వారా ఇందులో కొంత ప్రయోజనాన్ని పొందవచ్చు. దీనికి మెమరీ ఖర్చు అవుతుంది. ప్రతి పారలల్ స్లాట్‌కు దాని స్వంత KV cache అవసరం, మరియు Ollama కాంటెక్స్ట్ కేటాయింపును విభజించడానికి బదులుగా గుణిస్తుంది: దీని FAQ ప్రకారం అవసరమైన RAM అనేది OLLAMA_NUM_PARALLEL మరియు OLLAMA_CONTEXT_LENGTH ల లబ్ధానికి అనుగుణంగా పెరుగుతుంది. కాబట్టి 8192 టోకెన్ల కోసం కాన్ఫిగర్ చేసిన మోడల్‌పై నాలుగు పారలల్ అభ్యర్థనలు వస్తే, ప్రతి ఒక్కటి 8192 టోకెన్లను ఉంచుకుంటాయి, కానీ సర్వర్ మొత్తం 32768 టోకెన్ల కోసం కాష్‌ను నిల్వ చేయాల్సి ఉంటుంది. ఆ 8192 అనేది ఒక నిర్ణీత విలువ కాదు, కాబట్టి num_ctx పెంచడం మరియు దానికి అవసరమైన RAMను లెక్కించడం అనేది నాలుగు స్లాట్లు సరిపోతాయా లేదా అని నిర్ణయించే కీలక దశ. vLLM యొక్క paged cache ప్రతి స్లాట్ కోసం పూర్తి విండోను ముందుగానే రిజర్వ్ చేయకుండా నిరోధిస్తుంది, ఎందుకంటే అభ్యర్థన పెరిగే కొద్దీ బ్లాక్‌లు కేటాయించబడతాయి. ఏది ఏమైనప్పటికీ, ఒక సర్వర్ ఒకేసారి ఎంతమందికి సేవలు అందించగలదనే పరిమితి KV cache పరిమాణం, prefill ఖర్చు మరియు క్యూ డెప్త్‌పై ఆధారపడి ఉంటుంది, అందుకే ఒక వ్యక్తికి సరిగ్గా అనిపించిన సర్వర్ ఐదుగురు రాగానే నెమ్మదిస్తుంది.

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."

ఈ ఇన్‌స్టాల్ స్క్రిప్ట్ ఒక ollama సిస్టమ్ యూజర్‌ను సృష్టిస్తుంది, బైనరీని ఇన్‌స్టాల్ చేస్తుంది మరియు 127.0.0.1:11434 కి బైండ్ చేయబడిన ollama.service ని రిజిస్టర్ చేస్తుంది. --verbose ద్వారా ప్రింట్ చేయబడిన eval rate లైన్, ఆ బాక్స్‌పై మీ అసలైన టోకెన్ల పర్ సెకండ్ (tokens per second) వేగాన్ని సూచిస్తుంది. ఏదైనా ప్రచురించబడిన గణాంకాల కంటే దీనినే నమ్మండి. ఒక ప్రాంప్ట్ నుండి వచ్చే రీడింగ్ అనేది ఒక ప్రారంభ బిందువు మాత్రమే, అది సామర్థ్య సంఖ్య కాదు. కాబట్టి, concurrency sweep ద్వారా టోకెన్ల పర్ సెకండ్ వేగాన్ని కొలవడం అనేది, మీరు ఆశించే లోడ్ వద్ద ఆ బాక్స్ ఎలా పనిచేస్తుందో మరియు GPUని అద్దెకు తీసుకోవడం అనేది పర్-టోకెన్ చెల్లింపు కంటే మెరుగైనదా కాదా అని తెలియజేస్తుంది.

Concurrencyని పెంచడానికి, 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 ఏమి లోడ్ అయిందో చూపిస్తుంది, మరియు దాని PROCESSOR కాలమ్ అసలు నిజాన్ని చెబుతుంది. 100% CPU అంటే ఎటువంటి GPU ఉపయోగించబడటం లేదని అర్థం; Ollama నెమ్మదిగా ఉందని వచ్చే చాలా రిపోర్టులకు ఇదే నిజమైన కారణం. ఆ డ్రాప్-ఇన్‌లో ఉన్న OLLAMA_KEEP_ALIVE=30m లైన్ తక్కువ లోడ్ ఉన్న బాక్స్‌పై కూడా అంతే ముఖ్యం. ఎందుకంటే, డిఫాల్ట్‌గా ఐదు నిమిషాల పాటు ఎటువంటి అభ్యర్థన లేకపోతే మోడల్ అన్‌లోడ్ అవుతుంది. అభ్యర్థనల మధ్య మోడల్‌ను మెమరీలో ఉంచడం ద్వారా, అరగంట విరామం తర్వాత వచ్చే మొదటి ప్రాంప్ట్‌కు మళ్ళీ పూర్తి లోడ్ సమయం పట్టకుండా నివారించవచ్చు. మీ విరామ సమయాలు అంతకంటే ఎక్కువగా ఉంటే, ఎక్కువ విలువను సెట్ చేయండి.

vLLMను ఇన్‌స్టాల్ చేసి సర్వ్ చేయడం

vLLM యొక్క GPU builds కు Linux అవసరం. Apple Siliconలోని macOSకు CPU-only మద్దతు మాత్రమే ఉంది; 0.32.0 releaseలో prebuilt wheel అందుబాటులో ఉంది. ఆ Macలలో GPU acceleration కోసం MLXపై నిర్మించిన, community-maintained ప్రత్యేక plugin అయిన vLLM-Metal ఉపయోగించాలి. Python విషయంలో ప్రస్తుత release (0.32.0, October 2026) 3.11 నుంచి 3.14 వరకు అంగీకరిస్తుంది. Install guide కూడా ఇదే పరిధిని పేర్కొంటుంది. 0.32.0లో Python 3.10కు మద్దతు తొలగించారు. కాబట్టి కింద ఉపయోగిస్తున్న 3.12 సురక్షితమైన ఎంపిక. vLLM నిర్దిష్ట PyTorch buildను ఇన్‌స్టాల్ చేసుకుంటుంది కాబట్టి, దీన్ని ప్రత్యేక virtual environmentలో ఇన్‌స్టాల్ చేయండి:

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

October 2026 నాటికి vLLM యొక్క NVIDIA install guideలో చివరి line ఇదే ఉంది. ఇది FlashInfer యొక్క precompiled kernels ను ఇన్‌స్టాల్ చేస్తుంది. అవి లేకపోతే vLLM startup సమయంలో kernels ను download చేసి compile చేస్తుంది. Hopper మరియు ఆ తరువాతి GPUsలో దీనివల్ల several minutes అదనంగా పట్టవచ్చని guide చెబుతుంది. ప్రతి vLLM upgrade తర్వాత దీన్ని మళ్లీ run చేయండి. Kernels సరిపోలకపోతే FlashInfer import విఫలమవుతుంది.

తరువాత ఒక modelను serve చేయండి. ఇక్కడి పేరు short tag కాదు; అది Hugging Face repository id:

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

మొదటిసారి startup నెమ్మదిగా ఉంటుంది. ముందుగా weights download అవుతాయి. తరువాత ఎన్ని KV cache blocks సరిపోతాయో నిర్ణయించడానికి GPU profiling జరుగుతుంది. ఇది port 8000పై listening చేస్తుంది. Client code రాయడానికి ముందు దీన్ని check చేయండి:

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

ఈ machineలో 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 ద్వారా containerకు host shared memory అందుబాటులోకి వస్తుంది. --shm-size ను పెంచడం మరో మార్గం. ముఖ్యంగా tensor-parallel inference సమయంలో PyTorch processes మధ్య tensors ను shared memory ద్వారా పంపుతుంది.

Productionలో ముఖ్యమైన flags ఇవి: --max-model-len (మీరు ఖర్చు చేయడానికి సిద్ధంగా ఉన్న context window), --gpu-memory-utilization (vLLM ఉపయోగించగల GPU memory fraction; October 2026 నాటికి defaultగా 0.92), ఒక modelను అనేక GPUs మధ్య విభజించడానికి --tensor-parallel-size, మరియు --api-key.

vLLMలో Authentication ఒక flag ద్వారా అమలవుతుంది; Ollama local APIలో అది ఉండదు

మీరు bearer token ఇస్తే vLLM దాన్ని తప్పనిసరిగా అమలు చేస్తుంది:

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

అదే విలువను VLLM_API_KEY environment variable నుంచి కూడా తీసుకోవచ్చు. ఆ token లేకుండా /v1 routes కు పంపిన request HTTP 401తో విఫలమవుతుంది. అయితే ఈ key మొత్తం serverకు వర్తించదు. vLLM security guide మరియు 0.32.0 sourceలోని authentication code దీన్ని /v1, /v2, /inference, /cohere path prefixes కింద ఉన్న endpointsకు మాత్రమే వర్తింపజేస్తాయి. vllm serve pageలోని --api-key help text మొదటి మూడు prefixesను మాత్రమే చూపిస్తుంది. కానీ code నాలుగు prefixesనూ తనిఖీ చేస్తుంది. Guide మరియు help text రెండూ ఇతర endpointsకు authentication ఉండదని చెబుతున్నాయి. ముఖ్యంగా /invocations endpoint, /v1 వలే అదే inferenceను అందిస్తుంది, authentication లేకుండానే అందుబాటులో ఉంటుంది. అందువల్ల port 8000ను public interfaceపై publish చేయకపోవడానికి ఇది సరిపడే కారణం. vLLM security guide rate limitingను ముందున్న reverse proxyకు అప్పగిస్తుంది. Plain HTTPపై పంపిన tokenను మార్గమధ్యంలో చదవవచ్చు. అయినప్పటికీ ఈ flag వల్ల serverకు request పంపే caller గురించి ఒక authentication భావన ఉంటుంది.

Ollama local APIకు authentication అవసరం లేదు. Cloud models, model publishing, private model downloads కోసం sign-in అవసరం. ollama.comకు direct API access కోసం API key అవసరం. 11434కు చేరుకోగల ఏ process అయినా modelsను run, pull లేదా delete చేయగలదు. దాన్ని loopbackపై మాత్రమే ఉంచి, మీరు స్వయంగా నిర్వహించే WireGuard VPN ద్వారా లేదా TLS (transport layer security)ను terminate చేసే authentication కలిగిన reverse proxy ద్వారా చేరుకోండి.

హార్డ్‌వేర్: ప్రతిదానికి ఏమి అవసరం

Ollama CPUపై నడుస్తుంది. 4-bit క్వాంటైజ్డ్ మోడల్ కోసం ప్రతి బిలియన్ పారామీటర్లకు సుమారు అర గిగాబైట్ RAM అవసరం, దీనికి అదనంగా రన్‌టైమ్ ఓవర్‌హెడ్ కోసం ఒక గిగాబైట్ మరియు కాంటెక్స్ట్ కోసం మరికొంత RAM కావాలి. కాబట్టి 3B మోడల్‌కు సుమారు 4 GB ఖాళీ RAM, 8B మోడల్‌కు సుమారు 8 GB అవసరం. షేర్డ్ vCPUపై వేగం సెకనుకు సింగిల్ డిజిట్ నుండి తక్కువ డబుల్ డిజిట్ టోకెన్ల వరకు ఉంటుంది. ఇది మెమరీ బ్యాండ్‌విడ్త్ పరిమితి, కాన్ఫిగరేషన్ తప్పు కాదు, దీనిని ఏ ఫ్లాగ్ సరిచేయలేదు. ఒక సాధారణ నియమం కంటే, ఒక నిర్దిష్ట రిలీజ్‌లో ఈ గణన ఎలా పనిచేస్తుందో చూడటానికి, running Nemotron 3.5 Lightning on a VPS చూడండి; ఇది ఏ ట్యాగ్‌ను పుల్ చేయాలో, లోడ్ అయిన తర్వాత ఎంత RAM ఆక్రమిస్తుందో మరియు CPU-మాత్రమే వాడటం ఆచరణాత్మకమేనా అని స్పష్టం చేస్తుంది.

vLLM కు GPU అవసరం. దీని డిఫాల్ట్ పాత్ 16-bit ప్రెసిషన్ వద్ద క్వాంటైజ్ చేయని వెయిట్స్‌ను అందిస్తుంది, అంటే ప్రతి బిలియన్ పారామీటర్లకు సుమారు 2 GB అవసరం: 8B మోడల్‌కు వెయిట్స్ కోసమే సుమారు 16 GB వీడియో మెమరీ కావాలి. మీరు vLLMను ఇన్‌స్టాల్ చేసిన ఉద్దేశ్యమైన కాన్‌కరెన్సీని ఇచ్చే KV కాష్‌కు ముందుగానే ఇది అవసరం. 24 GB కార్డ్‌పై ఇది పని చేయడానికి వీలైనంత కాష్‌ను మిగిలిస్తుంది. 16 GB కార్డ్‌పై ఇది సరిపోదు, కాబట్టి మీరు చిన్న మోడల్‌ను ఎంచుకోవాలి, --quantization ఫ్లాగ్‌ను పాస్ చేయాలి (క్వాంటైజ్డ్ చెక్‌పాయింట్‌తో, లేదా లోడ్ అయ్యేటప్పుడు ఫుల్-ప్రెసిషన్ వెయిట్స్‌ను క్వాంటైజ్ చేయడానికి), లేదా --cpu-offload-gb తో వెయిట్స్‌లో కొంత భాగాన్ని సిస్టమ్ RAMలోకి పంపాలి. ఇది ప్రెసిషన్‌ను అలాగే ఉంచుతుంది కానీ నెమ్మదిగా ఉంటుంది, ఎందుకంటే ప్రతి ఫార్వర్డ్ పాస్‌లో ఆ వెయిట్స్ GPUకి బదిలీ అవ్వాలి. CPU బ్యాకెండ్ అందుబాటులో ఉంది, దీనికి ప్రత్యేకమైన వీల్స్ ఉన్నాయి, కానీ ఇది vLLMను వాడటంలోని అసలు ఉద్దేశ్యాన్నే దెబ్బతీస్తుంది.

కాబట్టి, హార్డ్‌వేర్ ఎంపికే చాలా సందర్భాలలో సాఫ్ట్‌వేర్ ఎంపికను నిర్ణయిస్తుంది. GPU లేకపోతే Ollama వాడాలి. అభ్యర్థనలు సీరియలైజ్ అవ్వడం వల్ల 5 శాతం వినియోగం వద్ద ఆగిపోయిన అద్దె GPU ఉంటే, vLLM వాడాలి.

మీ workload కోసం ఏది?

• ఒక వ్యక్తి ఉపయోగించే CPU VPS లో drafting మరియు summarising కోసం: Ollama. దీని వేగం సరిపోతుంది. ఇంతకంటే సరళమైన ప్రత్యామ్నాయం లేదు.
• మీరు మాత్రమే ఉపయోగించే coding assistant కోసం లేదా మీ సాధనాలను local model కు అనుసంధానించే MCP server కోసం: Ollama. వాస్తవ workload concurrency ఒకటే.
• ఈ వారం ఐదు models ను పోల్చి చూస్తున్నారా: Ollama. tagged models ను pull చేసి delete చేయడం దీనికి సరిగ్గా సరిపోతుంది. అయితే vLLM కు ప్రతి model కోసం process restart అవసరం.
• నిజమైన users ఉపయోగించే internal app, chat product లేదా retrieval pipeline కోసం: vLLM. ఇక్కడ batching వల్ల GPU ఖర్చు సమర్థవంతంగా ఉపయోగపడుతుంది.
• రాత్రికి లక్ష documents ను score చేసే batch job కోసం: vLLM, అధిక --max-num-seqs తో. ఇక్కడ throughput మాత్రమే ముఖ్యం. ప్రతి document latency ముఖ్యం కాదు.
• ఒకేసారి అనేక self-hosted AI agents model ను ఉపయోగించే agent platform కోసం: vLLM. Agent traffic సహజంగానే bursty మరియు parallel గా ఉంటుంది.

మీరు చూడగల సందేశాలతో వైఫల్య పరిస్థితులు

KV cache లోపంతో vLLM ప్రారంభం కావడం నిరాకరిస్తుంది. సందేశంలో రెండు సంఖ్యలు కనిపిస్తాయి:

ValueError: To serve at least one request with the model's max seq len (32768), (4.00 GiB KV cache is needed, which is larger than the available KV cache memory (1.00 GiB). Based on the available memory, the estimated maximum model length is 8192. Try increasing `gpu_memory_utilization` (which also controls CPU memory on the CPU backend) or decreasing `max_model_len` when initializing the engine. See https://docs.vllm.ai/en/latest/configuration/conserving_memory/ for more details.

Weights లోడ్ చేసిన తర్వాత మిగిలిన memory కంటే model ప్రకటించిన context window పెద్దదిగా ఉంది. దీన్ని --max-model-len 8192 తో తగ్గించండి. Card ను మరే ఇతర పని ఉపయోగించకపోతే --gpu-memory-utilization ను పెంచండి.

Generation మధ్యలో Ollama Killed ను ప్రింట్ చేస్తుంది. Model కు అందుబాటులో ఉన్న RAM కంటే ఎక్కువ అవసరం కావడంతో Linux out-of-memory killer ఆ process ను ఆపింది. sudo dmesg | grep -i oom తో నిర్ధారించండి. దీనికి పరిష్కారం చిన్నది లేదా ఎక్కువగా quantize చేసిన model ఉపయోగించడం. ఇది setting తో పరిష్కరించలేరు.

ఒంటరిగా నడిపినప్పుడు Ollama సరిగ్గా సమాధానం ఇస్తుంది, కానీ load కింద నిలిచిపోతుంది. ఎక్కడా error కనిపించదు. Callers సంఖ్య పెరిగే కొద్దీ requests ఎక్కువ సమయం తీసుకుంటాయి, ఎందుకంటే OLLAMA_NUM_PARALLEL=1 వాటిని serialise చేస్తుంది. ఒక caller model ఆగాలని నిర్ణయించే వరకు ఏకైక slot ను ఆక్రమించడం వల్ల దీర్ఘ సమాధానాలు queue ను మరింత పెంచుతాయి. అందువల్ల num_predict తో reply పరిమితం చేయడం ద్వారా ప్రతి turn server ను ఎంతసేపు ఆక్రమించవచ్చో పరిమితి విధించవచ్చు. Parallel setting ను పెంచి, ప్రతి slot యొక్క context కు అవసరమయ్యే అదనపు RAM ను అంగీకరించండి. లేదా workload ను vLLM కు తరలించండి.

ప్రతి /v1 call పై vLLM 401 ను తిరిగి ఇస్తుంది. మీరు దీన్ని --api-key తో ప్రారంభించారు, కానీ client Authorization header ను పంపడం లేదు. చాలా OpenAI client libraries మీరు keyగా పంపిన విలువనే పంపిస్తాయి. కాబట్టి flag ను తొలగించకుండా అక్కడే ఆ విలువను సెట్ చేయండి.

Model కనుగొనబడలేదని vLLM చెబుతుంది. Ollama అవసరమైనప్పుడు model ను pull చేస్తుంది; vLLM అలా చేయదు. Request body లోని model field, మీరు ప్రారంభించిన repository id తో సరిపోలాలి. లేదా మీరు ఒకటి సెట్ చేసి ఉంటే --served-model-name విలువతో సరిపోలాలి. ఖచ్చితమైన string ను curl http://localhost:8000/v1/models తో నిర్ధారించండి.

రెండింటినీ నడపడం సముచితమైన ఎంపిక

ఇవి పరస్పర ప్రత్యామ్నాయాలు కావు. సాధారణ నిర్మాణంలో అప్లికేషన్‌కు సేవలందించడానికి GPU instance పై vLLM నడుస్తుంది. దాని పక్కన ఉన్న సాధారణ VPS పై స్థానిక scripts, cron jobs, కొత్త model releases ను పరీక్షించడం కోసం Ollama నడుస్తుంది. రెండు endpoints కూడా OpenAI-compatible గా ఉంటాయి. అందువల్ల ఒకే client library మరియు base-URL మార్పు వాటిని నిర్వహించడానికి సరిపోతాయి. ఇక్కడ రెండు engines లో ఏదో ఒకదాన్ని ఎంచుకోవడం కంటే ఖర్చు నియంత్రణ ముఖ్యమైనది. ఎందుకంటే ఉపయోగంలో లేని GPU కి కూడా ఉపయోగంలో ఉన్న GPUతో సమానంగా billing జరుగుతుంది. అలాగే agent మరియు inference ఖర్చులను ఊహించదగిన స్థాయిలో ఉంచడం అనేది server ఎంపికకు భిన్నమైన ప్రత్యేక నిర్వహణ విధానం.

FAQ

vLLM, Ollama కంటే వేగంగా పనిచేస్తుందా?

అదే GPUపై ఒకే అభ్యర్థనకు వేగంలో తేడా తక్కువగా ఉంటుంది, ఎందుకంటే రెండూ ఒకే గణనను నిర్వహిస్తాయి. అనేక సమకాలిక అభ్యర్థనలు ఉన్నప్పుడు vLLM చాలా వేగంగా ఉంటుంది. Continuous batching ప్రతి active sequence ను ఒకే forward pass లో decode చేస్తుంది. Ollama యొక్క default విధానం వాటిని ఒక్కొక్కటిగా అమలు చేస్తుంది. CPU మాత్రమే ఉన్న యంత్రంలో రెండింటికీ inference paths అందుబాటులో ఉన్నాయి. vLLM కోసం ప్రత్యేక CPU wheels ఉపయోగించాలి.

GPU లేకుండా vLLM నడుస్తుందా?

అవును, దాని CPU backend ద్వారా నడుస్తుంది. సాధారణ wheels NVIDIA లేదా AMD GPUs కోసం రూపొందించబడ్డాయి. Batched requests తో accelerator ను నిరంతరం వినియోగంలో ఉంచడమే vLLM ఉద్దేశం. CPUపై ఆ ప్రయోజనం ఉండదు. x86 మరియు Arm కోసం ప్రత్యేక wheels తో CPU backend అందుబాటులో ఉంది. నిజమైన CPU inference కోసం Ollama లేదా llama.cpp ను నేరుగా ఉపయోగించండి.

Ollama మరియు llama.cpp మధ్య తేడా ఏమిటి?

llama.cpp inference library. GGUF దాని quantized weight format. Ollama, GGUF inference కోసం llama.cpp ను ఉపయోగించి, model registry, tagged downloads, model management మరియు systemd unit ను అదనంగా అందిస్తుంది. Apple Siliconపై safetensors ఆధారిత models ను నడిపే MLX engine ను కూడా Ollama విడుదల చేస్తుంది. Linuxపై CUDA builds కు కూడా మద్దతు ఇస్తుంది. అందువల్ల అంతర్గతంగా ఈ రెండూ ఎల్లప్పుడూ ఒకే విధంగా ఉండవు.

8B model కోసం vLLM కు ఎంత GPU memory అవసరం?

16-bit precision వద్ద weights కు మాత్రమే సుమారు 16 GB అవసరం. ఇది ప్రతి billion parameters కు సుమారు 2 GB. దీనికి అదనంగా KV cache కోసం స్థలం అవసరం. 24 GB card సౌకర్యవంతంగా ఉంటుంది. 16 GB card కోసం quantized model, చిన్న model లేదా --cpu-offload-gb అవసరం. --cpu-offload-gb కొంత weights ను system RAM లోకి తరలిస్తుంది. దీనివల్ల వేగం తగ్గుతుంది. vLLM card memoryలో --gpu-memory-utilization ద్వారా నిర్ణయించబడిన భాగాన్ని ఉపయోగిస్తుంది. October 2026 నాటికి దీని default విలువ 0.92.

వీటి మధ్య మారడానికి application code ను మార్చాలా?

సాధారణంగా base URL, API key మరియు model name మాత్రమే మార్చాలి. Ollama తన OpenAI-compatible surface ను http://127.0.0.1:11434/v1 వద్ద అందిస్తుంది. ఇది key ను పట్టించుకోదు. మీరు key ను సెట్ చేస్తే vLLM http://localhost:8000/v1 ను అందించి, దాని /v1 routes పై key ను తప్పనిసరి చేస్తుంది. Model names యొక్క రూపం వేర్వేరుగా ఉంటుంది. Ollama కోసం llama3.1:8b ఉపయోగించాలి. vLLM కోసం Qwen/Qwen2.5-1.5B-Instruct వంటి పూర్తి repository id ఉపయోగించాలి.