30 Days of AIDay 16 of 30 · Week 3: Infrastructure & Hosting
Course outline▾

Week 4 · Enterprise Workflows

  1. Day 22Autonomous Agents: From Passive LLMs to Goal-Driven ExecutionComing soon · 2026-10-22 · 7 PM IST
  2. Day 23Tool Use & Function Calling: Connecting LLMs to APIs, Databases, and ShellsComing soon · 2026-10-23 · 7 PM IST
  3. Day 24Multi-Agent Orchestration: Supervisor, Worker, and Evaluator PatternsComing soon · 2026-10-24 · 7 PM IST
  4. Day 25Automated CI/CD: Automating the Software Lifecycle for AI ModelsComing soon · 2026-10-25 · 7 PM IST
  5. Day 26Zero-Trust Security for AI: Sandboxing Ephemeral Execution & Model EgressComing soon · 2026-10-26 · 7 PM IST
  6. Day 27Observability & Tracing for Agentic Systems (Telemetry, Logs, and Metrics)Coming soon · 2026-10-27 · 7 PM IST
  7. Day 28Human-in-the-Loop Architecture: Machine Second, Human First in PracticeComing soon · 2026-10-28 · 7 PM IST
  8. Day 29Managing Technical Debt, Drift, and Model Governance in Enterprise ITComing soon · 2026-10-29 · 7 PM IST
  9. Day 30The 10-Year Horizon: Architecting IT Strategy for the AI-Native EnterpriseComing soon · 2026-10-30 · 7 PM IST
Open the course page →

Day 16: Local Model Execution — Running Open-Weight LLMs Securely with Ollama and vLLM

2026-10-16 · 9 min read

Relying only on commercial cloud APIs carries real exposure: vendor lock-in, recurring cost for every token, rate limits, and the need to send sensitive intellectual property across public networks. Running an open-weight model such as Llama 3, Mistral or Gemma 2 on your own infrastructure addresses each of those. The price is that you now operate the hardware, so choosing the right runtime matters.

In plain terms: Ordering from a restaurant is easy, but you pay per dish, you queue at busy hours, and the restaurant sees what you ate. Cooking at home means buying the stove, and in return the menu, the speed and the privacy are yours.

Cloud API or your own hardware? Cloud API riskSelf-hostedVendor lock-inyour app is tied to one providerOpen-weight models are portableRunning costspay for every token, foreverFixed hardware costRate limitsproviders throttle busy appsYou set the capacityData exposuresensitive text leaves your networkData stays insidePredictable latency, full data sovereignty.You also take on the hardware and the operations.
Relying only on commercial cloud APIs brings vendor lock-in, recurring costs, rate limits and the transmission of sensitive data over public networks. Running open-weight models on your own infrastructure addresses each of these, at the price of operating the hardware yourself.

1. Prototyping and edge: Ollama and llama.cpp

On a workstation, a laptop or an edge box with limited memory (a 16 GB machine is a typical target), a plain Python script adds overhead you do not want. Ollama is built on llama.cpp, a lean C and C++ engine, so it avoids most of that Python overhead.

  • GGUF quantization: Ollama runs models stored in the GGUF format, usually at 4-bit or 8-bit precision. That shrinks multi-gigabyte weights enough to fit in ordinary RAM or a modest GPU, with a small loss in quality for most tasks. Check the quality on your own prompts.
  • Operational simplicity: it runs a local service and handles downloading models, spreading them across GPU and CPU memory, and formatting prompts. It exposes an OpenAI-compatible REST API at http://localhost:11434.

2. High-throughput serving: vLLM

When hundreds of users hit the same model at once, handling requests one after another creates a queue. vLLM is a serving engine built for that case, with two key ideas.

PagedAttention. Older engines reserve one contiguous block of KV-cache memory per request, sized for the longest possible reply, so much of it sits empty. The vLLM authors measured 60 to 80% waste in earlier systems. PagedAttention borrows the idea of virtual-memory paging from operating systems and splits the cache into small blocks that are handed out as a request grows.

PagedAttention: no wasted memory KV-cache memory for three requestsContiguous blocksAwastedBwastedCwastedSpace reserved for the maximum length, so most of it sits emptyPaged blocksSmall blocks are handed out only as a request growsBorrowed from how an operating system pages memory.Earlier engines could waste 60 to 80% of KV-cache memory.
Older inference engines reserve one contiguous block of KV-cache memory per request, sized for the maximum length, and much of it sits empty. vLLM's PagedAttention splits the cache into small blocks allocated as a request grows, like paging in an operating system. The vLLM authors reported 60 to 80% waste in earlier systems.

Continuous batching. A static batch must finish completely before new requests are accepted, so slots sit idle while the longest reply completes. vLLM slips new requests into the running batch at the token level. Reported gains are commonly 2x to 4x higher throughput than basic pipelines, but the real figure depends on your model, hardware and traffic.

Continuous batching keeps the GPU busy Static batch: wait for the longest replyAidleBidleC (long reply)Continuous: new requests join at the next tokenADGBEC (long reply)Often 2x to 4x more throughput than basic pipelines.Depends on the model, hardware and traffic. Measure your own.
With static batching, a whole batch must finish before new requests are accepted, so slots sit idle while the longest reply finishes. Continuous batching slips new requests into free slots at the token level, which commonly raises throughput by 2x to 4x depending on the model, hardware and traffic.

Which one should you pick?

Pick the engine for the job Ollama + llama.cppPrototyping and edgeLaptops, workstations16 GB RAM is enoughGGUF 4-bit and 8-bit modelsOne command to runLocal API on port 11434vLLMHigh-concurrency servingGPU serversHundreds of users at oncePagedAttentionContinuous batchingOpenAI-compatible APIMatch the engine to your hardware and your traffic.Both can serve an OpenAI-style API, so your app code barely changes.
Ollama, built on llama.cpp, suits prototyping and edge machines with limited memory and runs quantized GGUF models with a single command. vLLM suits GPU servers handling many users at once. Both expose an OpenAI-style API.

Here is how little your application code changes. Both engines speak an OpenAI-style API, so you can point the same client at either one. This assumes you have installed Ollama and pulled a model, or started a vLLM server.

# Ollama: pull and chat with a quantized 8B model in one command
ollama run llama3.1:8b

# vLLM: serve a model with an OpenAI-compatible API on port 8000 (needs an NVIDIA GPU)
vllm serve Qwen/Qwen2.5-7B-Instruct
from openai import OpenAI

# Same client, different base_url. Ollama listens on 11434, vLLM on 8000.
client = OpenAI(base_url="http://localhost:11434/v1", api_key="not-needed")

reply = client.chat.completions.create(
    model="llama3.1:8b",
    messages=[{"role": "user", "content": "Summarise RAG in one sentence."}],
)
print(reply.choices[0].message.content)

Self-hosting turns an LLM from an outside cost center into a private utility inside your own network boundary. The next lessons package it properly, starting with containers.

Coming Up Next

Day 17: Containerizing AI workloads: writing production Dockerfiles for Python APIs.

#LocalAI #vLLM #Ollama #OpenSourceAI #DataSovereignty