Ollama নাকি vLLM: কোন LLM server চালাবেন?

Ollama বনাম vLLM, একটি অনুচ্ছেদে

Ollama হলো সংযুক্ত server-সহ একটি model manager: এটি quantized weights download ও load করে এবং 127.0.0.1:11434-এ উত্তর দেয়; server-এ শুধু CPU থাকলেও এটি CPU ব্যবহার করে। vLLM হলো throughput engine: এটি একই সময়ে চলমান অনেক request দিয়ে GPU-কে পূর্ণ ক্ষমতায় ব্যবহার করে, তাই GPU-বিহীন machine-এ এটি উপযুক্ত নয়। সিদ্ধান্তটি এতটুকুই। একজন ব্যক্তি local assistant-এর সঙ্গে কথা বললে সেটি Ollama-এর কাজ। একটি application কোনো team-কে service দিলে সেটি vLLM-এর কাজ।

উভয়ই OpenAI-compatible HTTP API ব্যবহার করে, তাই base URL পরিবর্তন করলেই client code একটির পরিবর্তে অন্যটিতে ব্যবহার করা যায়। API তাদের পার্থক্য নয়। পার্থক্য হলো, প্রথম request এখনও token generate করার সময় দ্বিতীয় request এলে কী ঘটে।

Ollama আসলে কী

Ollama একটি সুবিধাজনক স্তর। একটি install command-এর মাধ্যমে এটি আপনাকে model registry (ollama pull llama3.1:8b), weights সংরক্ষণের জন্য local store, chat prompt, systemd service এবং HTTP API দেয়। এটি যে model পরিবেশন করে, সেগুলো GGUF file। এগুলো সাধারণত 4-bit quantized হয়। তাই 7B বা 8B model disk-এ 16 GB-এর বদলে প্রায় 5 GB জায়গা নেয়। Quantization না থাকলে CPU inference কার্যত সম্ভব হতো না।

এর runner llama.cpp-এর ওপর তৈরি। llama.cpp হলো C++ inference library, যা সাধারণ hardware-এ GGUF quantization ব্যবহারিক করে তুলেছে। পরে Ollama কিছু নতুন model family-এর জন্য নিজস্ব engine যোগ করেছে। তবে এটি যে অধিকাংশ model পরিবেশন করে, তার ভিত্তি এখনও llama.cpp। তাই Ollama এবং llama.cpp তুলনা করার সময় মূলত একটি ergonomics layer-এর সঙ্গে সেটি যে component-কে wrap করে, তার তুলনা করা হয়।

এর design target হলো একজন user। July 2026 অনুযায়ী OLLAMA_NUM_PARALLEL-এর default মান 1। এর অর্থ, একটি model একসঙ্গে একটি request process করে। অন্য সব request queue-তে অপেক্ষা করে। এই queue-তে default হিসেবে 512টি entry রাখা যায় (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 করবে না। চালুর সময় আপনি একটি Hugging Face repository নির্দিষ্ট করবেন। vLLM সেই একটি model load করবে এবং process বন্ধ না করা পর্যন্ত সেটিই serve করবে।

এই সীমিত কাজের বিনিময়ে আপনি পান বেশি throughput। এখানে দুটি mechanism কাজ করে। PagedAttention KV cache (key-value cache; প্রতিটি active request-এর জন্য model যে per-token attention state সংরক্ষণ করে) fixed-size block-এ রাখে, যেভাবে operating system memory page করে। ফলে কোনো request-এর জন্য worst-case অনুযায়ী একটি বড় contiguous reservation প্রয়োজন হয় না। আগে যে memory reserved থেকেও unused থাকত, তা এখন আরও বেশি concurrent request-এর জন্য ব্যবহার করা যায়। Continuous batching-এর মাধ্যমে নতুন request-কে চলমান batch-এ পরবর্তী decoding step-এ যুক্ত করা যায়। বর্তমান batch শেষ হওয়া পর্যন্ত অপেক্ষা করতে হয় না। কোনো sequence শেষ হলে সেটি সঙ্গে সঙ্গে batch থেকে বের হয় এবং তার slot নতুন request দিয়ে পূরণ করা হয়।

বাস্তব ফলাফল হলো: একটি GPU-তে একসঙ্গে চলা user-এর সংখ্যা 1 থেকে 30 করলে মোট tokens per second তীব্রভাবে বাড়ে, কিন্তু প্রতি user-এর speed আপনার প্রত্যাশার তুলনায় অনেক কম হারে কমে। Ollama-এর default আচরণে user-এর সংখ্যা 1 থেকে 30 করলে শুধু 29 জনকে অপেক্ষা করতে হয়।

Continuous batching-ই পুরো পার্থক্য তৈরি করে

একই hardware-এ একই সময়ে প্রতিটি server-এ পাঁচটি request পৌঁছেছে—এমন পরিস্থিতি ধরুন।

Ollama-এর default settings-এ প্রথম request সম্পূর্ণ হওয়া পর্যন্ত চলে, তারপর দ্বিতীয়টি, এভাবে একে একে। পঞ্চম caller-কে চারটি সম্পূর্ণ generation শেষ হওয়া পর্যন্ত অপেক্ষা করতে হয়। মোট throughput প্রায় একটি generation-এর গতির সমান থাকে, কারণ processor একসঙ্গে কেবল একটি sequence-এই কাজ করে।

vLLM একই forward pass-এ পাঁচটিই decode করে। একটি sequence-এর জন্য একটি token generate করার চেয়ে পাঁচটি sequence-এর জন্য একটি token generate করতে সামান্যই বেশি খরচ হয়। কারণ ব্যয়বহুল অংশ হলো model weights memory থেকে পড়া, আর পুরো batch-এর মধ্যে সেই read ভাগ হয়ে যায়। CPU inference ধীর হওয়ার পেছনেও একই memory-bandwidth বিষয়টি কাজ করে: arithmetic-এর জন্য নয়, weights সরানোর জন্য খরচ দিতে হয়।

আপনি OLLAMA_NUM_PARALLEL=4 সেট করে এর কিছু সুবিধা পেতে পারেন। এর খরচ হলো memory। প্রতিটি parallel slot-এর নিজস্ব KV cache দরকার। Ollama context window-টি slot-গুলোর মধ্যে ভাগ করে দেয়। তাই 8192 tokens-এর জন্য configured model-এর বিরুদ্ধে চারটি parallel request চালালে প্রতিটি request-এর context থাকে 2048 tokens। ওই 8192-ও পূর্বনির্ধারিত কোনো মান নয়; এটি একটি configuration choice। তাই num_ctx বাড়ানো এবং এর জন্য প্রয়োজনীয় RAM নির্ধারণ করাই ঠিক করে চারটি slot আদৌ ব্যবহারযোগ্য কি না। vLLM-এর paged cache এই trade-off এড়ায়, কারণ request বাস্তবে যত বড় হয়, blocks ততটাই সেই request-এর জন্য allocate করা হয়। যেকোনো ক্ষেত্রেই একটি box একসঙ্গে কতজনকে serve করতে পারবে, তার সীমা নির্ভর করে KV cache size, prefill cost এবং queue depth-এর ওপর। এ কারণেই একজনের জন্য ঠিকঠাক চলা server পাঁচজন ব্যবহারকারীর সময় ধীর হয়ে যায়।

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 system user তৈরি করে, binary ইনস্টল করে এবং 127.0.0.1:11434-এ bind করা ollama.service নিবন্ধন করে। --verbose যে eval rate line দেখায়, সেটিই ওই সিস্টেমে প্রতি সেকেন্ডে প্রকৃত token-এর সংখ্যা। প্রকাশিত যেকোনো পরিসংখ্যানের চেয়ে এটিকে বেশি নির্ভরযোগ্য ধরে নিন। একটি prompt থেকে পাওয়া একটি reading ক্ষমতার নির্দিষ্ট সংখ্যা নয়; এটি শুধু শুরুর মান। তাই বিভিন্ন concurrency স্তরে প্রতি সেকেন্ডে token-এর সময় মাপুন। এতে বোঝা যায়, প্রত্যাশিত load-এ সিস্টেমটি স্থিতিশীল থাকে কি না এবং প্রতি token-এর মূল্য দেওয়ার চেয়ে GPU ভাড়া করা বেশি সাশ্রয়ী কি না।

Concurrency বাড়াতে systemd drop-in ব্যবহার করুন, যাতে upgrade-এর সময় পরিবর্তনটি overwrite না হয়:

sudo systemctl edit ollama.service

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

sudo systemctl restart ollama
ollama ps

ollama ps কী loaded আছে তা দেখায় এবং এর PROCESSOR column প্রকৃত অবস্থা জানায়। 100% CPU মানে কোনো GPU ব্যবহৃত হচ্ছে না। Ollama ধীর হওয়ার অধিকাংশ report-এর এটিই সঠিক ব্যাখ্যা। ওই drop-in-এর OLLAMA_KEEP_ALIVE=30m line শান্ত অবস্থার সিস্টেমেও সমান গুরুত্বপূর্ণ। কারণ request না থাকলে default পাঁচ মিনিট পরে model unload করে। request-এর মধ্যবর্তী সময়ে model resident রাখা-ই idle অবস্থায় এক ঘণ্টা থাকার পর প্রথম prompt-এ আবার সম্পূর্ণ load time ব্যয় হওয়া বন্ধ করে।

vLLM ইনস্টল ও পরিবেশন

vLLM-এর জন্য Linux এবং Python 3.10 থেকে 3.13 প্রয়োজন। এটি নিজস্ব virtual environment-এ ইনস্টল করুন, কারণ এটি নির্দিষ্ট একটি PyTorch build ইনস্টল করে:

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

প্রথমবার startup ধীর হয়, কারণ এটি প্রথমে weights download করে এবং এরপর GPU profile করে নির্ধারণ করে কতগুলি KV cache block রাখা যাবে। এটি 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?"}]}'

যদি box-এ আগে থেকেই 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 process-গুলোর মধ্যে tensor পাঠাতে shared memory ব্যবহার করে, আর tensor-parallel inference-এর জন্য Docker-এর default shared-memory allocation খুব ছোট।

Production-এ সবচেয়ে গুরুত্বপূর্ণ flag হলো --max-model-len, অর্থাৎ আপনি যে context window-এর জন্য অর্থ ব্যয় করতে প্রস্তুত; --gpu-memory-utilization, অর্থাৎ vLLM GPU card-এর কত অংশ ব্যবহার করতে পারবে—July 2026 অনুযায়ী default 0.92; একটি model একাধিক GPU-তে ভাগ করার জন্য --tensor-parallel-size; এবং --api-key।

vLLM-এ authentication একটি flag দিয়ে সক্রিয় করা যায়, কিন্তু Ollama-তে এটি নেই

আপনি token দিলে vLLM bearer token যাচাই করে:

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

একই value VLLM_API_KEY environment variable থেকেও দেওয়া যায়। এই token ছাড়া কোনো request পাঠালে HTTP 401 পাওয়া যায়। তবুও public interface-এ port 8000 প্রকাশ করার এটি কোনো কারণ নয়। কারণ vLLM-এ rate limiting নেই এবং সাধারণ HTTP-তে পাঠানো token network traffic-এর সময় পড়ে ফেলা যায়। তবে এর অর্থ হলো, server-এর কাছে request প্রেরণকারী শনাক্ত করার একটি ব্যবস্থা আছে।

Ollama-তে এমন কোনো ব্যবস্থা নেই। কোনো key, login বা allow-list নেই। 11434-এ পৌঁছাতে পারে এমন যেকোনো process model চালাতে, pull করতে বা মুছে ফেলতে পারে। এটিকে loopback-এ রাখুন এবং নিজে পরিচালিত WireGuard VPN-এর মাধ্যমে অথবা authentication-সমর্থিত reverse proxy ব্যবহার করে এতে পৌঁছান। ওই proxy TLS (transport layer security) termination করবে।

Hardware: প্রতিটির যা প্রয়োজন

Ollama CPU-তে চলে। 4-bit quantized model-এ প্রতি 1 billion parameter-এর জন্য মোটামুটি আধা gigabyte RAM লাগে। এর সঙ্গে প্রায় 1 gigabyte runtime overhead এবং context-এর জন্য অতিরিক্ত RAM লাগে। তাই 3B model-এর জন্য প্রায় 4 GB free RAM এবং 8B model-এর জন্য প্রায় 8 GB RAM দরকার। Shared vCPU-তে গতি প্রতি second-এ এক অঙ্ক থেকে কম দুই অঙ্কের tokens। এটি memory bandwidth-এর সীমাবদ্ধতা, misconfiguration নয়। কোনো flag দিয়ে এটি ঠিক করা যায় না। Rule of thumb-এর বদলে নির্দিষ্ট release-এ এই হিসাব কীভাবে দেখা যায় তা জানতে VPS-এ Nemotron 3.5 Lightning চালানো দেখুন। সেখানে pull করার exact tag, model load হওয়ার পর ব্যবহৃত RAM এবং CPU-only mode ব্যবহারযোগ্য গতির কি না—সব নির্দিষ্ট করা আছে।

vLLM একটি GPU ধরে নিয়ে কাজ করে। এর default path 16-bit precision-এ unquantized weights serve করে। এতে প্রতি 1 billion parameter-এর জন্য প্রায় 2 GB video memory লাগে। তাই 8B model-এর weights-এর জন্যই প্রায় 16 GB video memory দরকার। এর বাইরে vLLM-এর concurrency সামলাতে KV cache-এর জন্য অতিরিক্ত memory লাগে। 24 GB card-এ ব্যবহারযোগ্য cache-এর জন্য কিছু memory অবশিষ্ট থাকে। 16 GB card-এ তা থাকে না। তাই ছোট model বেছে নিতে হবে, অথবা quantized checkpoint-এর সঙ্গে --quantization pass করতে হবে। CPU backend আছে। তবে standard wheels এর জন্য build করা নয়। এ ছাড়া vLLM চালানোর মূল কারণটিও এতে আর থাকে না।

তাই বেশিরভাগ ক্ষেত্রে hardware-এর প্রশ্নই software-এর উত্তর নির্ধারণ করে। GPU না থাকলে Ollama ব্যবহার করুন। Rented GPU-তে requests serialised হওয়ার কারণে utilisation 5 percent-এ আটকে থাকলে vLLM ব্যবহার করুন।

আপনার workload-এর জন্য কোনটি

• একজন ব্যবহারকারী, একটি CPU VPS, এবং খসড়া তৈরি ও সারসংক্ষেপ করার কাজ: Ollama। গতি গ্রহণযোগ্য, আর এর চেয়ে সহজ সমাধান আর নেই।
• একটি coding assistant, অথবা আপনার tools-কে একটি local model-এর সঙ্গে সংযুক্ত করা MCP server, যা শুধু আপনিই ব্যবহার করেন: Ollama। concurrency এক হওয়াই এখানে প্রকৃত workload।
• এই সপ্তাহে পাঁচটি model তুলনা করছেন: Ollama। tagged model pull করা এবং delete করা এর উপযোগী কাজ; vLLM-এর ক্ষেত্রে প্রতিটি model-এর জন্য process restart প্রয়োজন।
• একটি internal app, chat product, অথবা প্রকৃত user-সমৃদ্ধ retrieval pipeline: vLLM। এখানেই batching-এর কারণে GPU খরচ সার্থক হয়।
• রাতারাতি এক লাখ document-এর score নির্ধারণ করা একটি batch job: vLLM, উচ্চ --max-num-seqs সহ। এখানে throughput-ই একমাত্র গুরুত্বপূর্ণ metric; প্রতিটি document-এর latency গুরুত্বপূর্ণ নয়।
• একটি agent platform, যেখানে একসঙ্গে একাধিক self-hosted AI agent model-এ অনুরোধ পাঠায়: vLLM, কারণ agent traffic স্বভাবতই bursty এবং parallel।

ব্যর্থতার ধরন এবং যে বার্তাগুলো দেখবেন

vLLM KV cache-সংক্রান্ত error দেখিয়ে start হতে অস্বীকার করে। বার্তায় উভয় সংখ্যা উল্লেখ থাকে:

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 load করার পরে অবশিষ্ট memory-এর তুলনায় model-এর context window বড়। --max-model-len 8192 ব্যবহার করে এটি কমান, অথবা card-এ অন্য কিছু না চললে --gpu-memory-utilization বাড়ান। utilisation প্রায় 0.95-এর বেশি করলে startup error-এর বদলে পরে load-এর মধ্যে CUDA out-of-memory crash হওয়ার সম্ভাবনা বাড়ে। এই দুটি সমস্যার মধ্যে দ্বিতীয়টি বেশি গুরুতর।

Ollama generation-এর মাঝখানে Killed দেখায়। Linux out-of-memory killer process-টি বন্ধ করেছে, কারণ model-এর প্রয়োজনীয় RAM মেশিনে থাকা RAM-এর চেয়ে বেশি। sudo dmesg | grep -i oom দিয়ে নিশ্চিত করুন। সমাধান হলো ছোট বা আরও বেশি quantized model ব্যবহার করা; কোনো setting পরিবর্তন করে এটি ঠিক হবে না।

Ollama একা ভালোভাবে উত্তর দেয়, কিন্তু load-এর মধ্যে আটকে যায়। কোথাও কোনো error দেখা যায় না। Caller-এর সংখ্যা বাড়লে request-এর সময়ও বাড়ে, কারণ OLLAMA_NUM_PARALLEL=1 request-গুলোকে ধারাবাহিকভাবে চালায়। দীর্ঘ উত্তর queue আরও বাড়ায়। একজন caller model-এর থামার সিদ্ধান্ত না নেওয়া পর্যন্ত একমাত্র slot ধরে রাখলে তার পেছনের সবাই অপেক্ষা করে। তাই num_predict দিয়ে উত্তরের সীমা নির্ধারণ করলে একটি turn কতক্ষণ server-এর slot ধরে রাখতে পারবে, তার সর্বোচ্চ সীমা নির্ধারিত হয়। Parallel setting বাড়িয়ে প্রতি request-এ ছোট context গ্রহণ করুন, অথবা workload vLLM-এ স্থানান্তর করুন।

vLLM প্রতিটি call-এ 401 ফেরত দেয়। আপনি এটি --api-key দিয়ে start করেছেন, কিন্তু client কোনো Authorization header পাঠাচ্ছে না। অধিকাংশ OpenAI client library key হিসেবে আপনি যে মান দেন, সেটিই পাঠায়। তাই flag বাদ না দিয়ে client-এ key সেট করুন।

vLLM বলে model পাওয়া যায়নি। Ollama প্রয়োজন অনুযায়ী model pull করে, vLLM তা করে না। Request body-র model field-এ launch করার সময় ব্যবহৃত repository id থাকতে হবে। আপনি --served-model-name সেট করে থাকলে তার মানও ব্যবহার করা যায়। curl http://localhost:8000/v1/models দিয়ে সঠিক string নিশ্চিত করুন।

দুটিই চালানো একটি যুক্তিসঙ্গত সমাধান

এগুলো পরস্পর-বিরোধী নয়। একটি প্রচলিত বিন্যাস হলো application পরিবেশনের জন্য GPU instance-এ vLLM চালানো এবং তার পাশাপাশি সাধারণ VPS-এ local script, cron job ও নতুন model release পরীক্ষা করার জন্য Ollama চালানো। উভয় endpoint OpenAI-compatible হওয়ায় একটি client library এবং base-URL পরিবর্তন করলেই দুটিতে কাজ করা যায়। এখানে engine বেছে নেওয়ার চেয়ে cost control বেশি গুরুত্বপূর্ণ, কারণ idle GPU-এর বিল busy GPU-এর মতোই হয়। আর agent ও inference-এর খরচ পূর্বানুমানযোগ্য রাখা server বেছে নেওয়া থেকে আলাদা একটি ব্যবস্থাপনা কাজ।

FAQ

vLLM কি Ollama-এর চেয়ে দ্রুত?

একই GPU-তে একটি অনুরোধের ক্ষেত্রে পার্থক্য সামান্য, কারণ উভয়ই একই গাণিতিক গণনা করে। একসঙ্গে অনেক অনুরোধ এলে vLLM অনেক এগিয়ে থাকে। কারণ continuous batching একটি forward pass-এ সব সক্রিয় sequence decode করে, যেখানে Ollama-এর default এগুলো একটির পর একটি চালায়। শুধু CPU-ভিত্তিক মেশিনে এই তুলনা প্রযোজ্য নয়: সেখানে Ollama চলে, কিন্তু vLLM কার্যত চলে না।

GPU ছাড়া vLLM কি চালানো যায়?

ব্যবহারযোগ্যভাবে নয়। প্রচলিত wheels NVIDIA বা AMD GPU লক্ষ্য করে তৈরি, আর batched request দিয়ে 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 যেসব বিষয় আপনার ওপর ছেড়ে দেয়, সেগুলো যোগ করে: model registry, automatic download, resident server, একটি systemd unit এবং একটি OpenAI-compatible endpoint। কিছু নতুন model family-এর জন্য Ollama নিজস্ব engine যোগ করেছে। তাই ভেতরের কাঠামোতে এখন আর দুটিকে অভিন্ন বলা যায় না।

একটি 8B model-এর জন্য vLLM-এর কত GPU memory প্রয়োজন?

16-bit precision-এ শুধু weights-এর জন্য প্রায় 16 GB লাগে, অর্থাৎ প্রতি billion parameter-এ আনুমানিক 2 GB। এর অতিরিক্ত KV cache-এর জন্যও জায়গা প্রয়োজন। 24 GB card স্বচ্ছন্দে কাজ করে। 16 GB card-এর জন্য quantized checkpoint অথবা ছোট model প্রয়োজন। vLLM card-এর মোট memory-এর যে ভগ্নাংশ ব্যবহার করে, তা --gpu-memory-utilization নির্ধারণ করে। July 2026 অনুযায়ী এর default মান 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-এ service দেয় এবং key সেট করলে তা যাচাই করে। Model name-এর format আলাদা: Ollama-এর জন্য llama3.1:8b, আর vLLM-এর জন্য Qwen/Qwen2.5-1.5B-Instruct-এর মতো একটি পূর্ণ repository id।