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

Week 3 · Infrastructure & Hosting

  1. Day 15Introduction to AI Infrastructure — Hardware, Runtimes and Compute
  2. Day 16Local Model Execution: Running Open-Weight LLMs Securely (Ollama, vLLM)Coming soon · 2026-10-16 · 7 PM IST
  3. Day 17Containerizing AI Workloads: Writing Production Dockerfiles for Python APIsComing soon · 2026-10-17 · 7 PM IST
  4. Day 18Docker Compose for Multi-Container AI Stacks (Web UI, Vector DB, LLM Engine)Coming soon · 2026-10-18 · 7 PM IST
  5. Day 19Kubernetes for AI 101: Pods, Deployments, and Services for Model ServingComing soon · 2026-10-19 · 7 PM IST
  6. Day 20Persistent Storage in Kubernetes: Managing State, Weights, and Vector IndicesComing soon · 2026-10-20 · 7 PM IST
  7. Day 21High-Performance Networking: Configuring Ingress and Egress for AI ClustersComing soon · 2026-10-21 · 7 PM IST

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 15: Introduction to AI Infrastructure — Hardware, Runtimes and Compute

2026-10-15 · 7 min read

Until now we called AI over an API. Moving to self-hosted models is how you guarantee your data never leaves your network, and it also means you now own the hardware, the runtime and the operating system. This week starts with the three building blocks.

In plain terms: Hosting your own model is like running your own kitchen instead of ordering delivery. You get control and privacy, but you now need the right stove, the right pans and a kitchen that stays up.

1. The hardware constraint: VRAM

A model has to fit in the memory of the GPU, called VRAM, before it can run. The parameter count sets the requirement: memory is roughly the number of parameters times the bytes used per parameter. Shrinking the numbers (quantization) is how you fit bigger models on smaller cards.

VRAM is the bottleneck An 8-billion-parameter model, by number precision16-bit (FP16)≈ 16 GB8-bit≈ 8 GB4-bit (quantized)≈ 4 GB8 GB cardWeights only. Add 1 to 3 GB for the KV cache and runtime overhead.So a 4-bit 8B model needs roughly 6 to 8 GB in practice.
The weights of an 8-billion-parameter model take about 16 GB at 16-bit precision, 8 GB at 8-bit and 4 GB at 4-bit. The KV cache and runtime add roughly 1 to 3 GB, so a 4-bit 8B model needs roughly 6 to 8 GB of VRAM in practice.

The figures are for the weights alone. The KV cache, which holds the conversation so far, and the runtime itself take extra space, so plan for a little headroom. A quantized 8-billion-parameter model needs roughly 6 to 8 GB of VRAM in practice.

2. Inference runtimes

You do not run a raw Python script in production. You use a dedicated, optimized runtime. llama.cpp is a lean C++ runtime that runs quantized models well on laptops and small servers. vLLM is built for GPU servers and serves many requests at once with smart batching and memory management. Same model, far more speed from the same hardware.

Production uses optimized runtimes Raw Python scriptEasy to writeSlower, less efficientOne request at a timeFine for a demollama.cpp or vLLMOptimized C++ and CUDABatching, paged KV cacheMany requests at onceBuilt for productionSame model, far more speed from the same hardware.llama.cpp suits laptops and small servers. vLLM suits GPU servers.
You do not run raw Python scripts in production. Dedicated runtimes such as llama.cpp and vLLM squeeze much more speed from limited hardware using optimized code, batching and efficient memory use.

3. The hosting OS

Linux is the standard host for production AI. A headless Ubuntu Server, which means no desktop environment at all, is a common choice. It leaves every bit of memory and CPU for your workloads, and it passes GPU resources cleanly into Docker containers and Kubernetes pods.

Why headless Ubuntu Server? No desktop to runall the memory and CPU go to your workloadsDirect GPU accessdrivers pass cleanly into Docker and KubernetesStable and scriptablelong-term support releases, easy to automateLinux is the standard host for production AI.
Headless Ubuntu Server has no desktop overhead, passes GPU drivers cleanly to Docker and Kubernetes, and offers long-term support releases that are easy to automate, which is why Linux is the standard host for production AI.

Put the pieces together and you get a stack that is built from the bottom up.

The self-hosting stack Model + runtimellama.cpp or vLLMContainerDocker or a Kubernetes podNVIDIA container toolkitexposes the GPU to containersGPU driver on Ubuntu Serverheadless, no desktopHardwareGPU with enough VRAMBuilt from the bottom up: each layer depends on the one below.
A self-hosted AI server is built bottom up: GPU hardware, a headless Ubuntu Server with the GPU driver, the NVIDIA container toolkit that exposes the GPU to containers, Docker or Kubernetes pods, and finally the model running in an optimized runtime.

Once the driver and the container toolkit are in place, you can check the GPU from inside a container. The commands below are the standard checks, and they need an NVIDIA GPU on the host.

# On the host: is the GPU visible to the driver?
nvidia-smi

# Inside a container: is the GPU passed through?
docker run --rm --gpus all ubuntu nvidia-smi

If the second command prints the same GPU table as the first, your containers can use the GPU. The next lessons build on that: local models with Ollama and vLLM, then Dockerfiles and Kubernetes.

Coming Up Next

Day 16: Local model execution: running open-weight LLMs securely with Ollama and vLLM.

#AIInfrastructure #Hardware #Ubuntu #Docker #SelfHostedAI