Self-Hosted AI Stack — Part 1: Planning & Hardware
Part 1 of the self-hosted AI stack series. Understand what actually determines what you can run — VRAM budgets, model sizing, and the hardware decisions that affect everything else.
Goal for this part: understand what actually determines what you can run, so the rest of this series makes sense instead of feeling like a list of magic numbers.
The one constraint that matters most: VRAM
Every decision in this stack — which models you can run, how many at once, what image-generation checkpoints are usable — traces back to one number: how much VRAM your GPU has. System RAM and CPU matter too, but VRAM is the hard ceiling. A model that doesn't fit in VRAM either won't load at all, or gets partially offloaded to system RAM and slows to a crawl.
This series is built and tested on a machine with an RTX 5090 (32GB VRAM), but the principles and the Docker Compose stack are the same regardless of your GPU. The hardware tier table below will help you size things to your own setup.
Some large models use a Mixture-of-Experts (MoE) architecture, where only a fraction of the model's total parameters activate per token — this lets you offload inactive experts to system RAM and still get reasonable speed. If your system RAM is limited, you lose that offloading option and need models that fit entirely in VRAM instead. More system RAM buys flexibility to run larger MoE models even on the same GPU.
Hardware tiers — what fits where
Use this as a rough sizing guide. None of these are hard cutoffs — quantization level, context length, and whether you're running anything else simultaneously all shift the numbers — but it'll keep you from downloading a model that simply won't load.
| VRAM | What comfortably fits |
|---|---|
| 32GB+ | A 30B-class coding model and a 30–35B general model, full SDXL, Flux/Chroma-class image generation models |
| 16–24GB | 8–14B class dense models comfortably; 30B-class models only at aggressive quantization (Q4 and below); SDXL is fine, Flux/Chroma will be tight or need quantized variants |
| 12GB or less | Stick to 7–8B dense models at Q4/Q5 quantization; SDXL works at reduced batch size and resolution; skip Flux/Chroma-class models entirely unless heavily quantized |
A model that loads and runs at a reasonable speed beats a larger one that technically fits but pushes you to the edge of your VRAM budget — you'll hit out-of-memory errors the moment you also load an image-generation model or increase context length. Leave headroom.
The model roster used in this series
This series uses the following models, chosen deliberately rather than just grabbing the newest release of everything:
- General-purpose / reasoning: a ~35B mixture-of-experts model for everyday chat and reasoning tasks in the unified web interface
- Coding:
qwen3-coder:30b— a 30B coding-specialized model, used both as chat-box Q&A and as the backend for the IDE-integrated agent in Part 5 - Comparison models: a handful of smaller general models (12B–24B range) kept around for side-by-side comparison on specific tasks, since different model families have different strengths
Coding-specialized models are meaningfully better at code-specific tasks than general models of similar size, and vice versa for open-ended reasoning or conversation. Keeping a small, focused roster instead of one do-everything model gets better results per task without needing a much larger model to compensate.
Before you move on
- A GPU with enough VRAM for at least one mid-size model (8B+) at a reasonable quantization
- Windows 11 — this series uses WSL2 as the Linux layer (see Part 2). The same Docker-based approach works on native Linux too, you'd just skip the WSL2 step entirely
- A dedicated drive or partition for the stack if possible — model downloads get large fast and shouldn't compete with your OS drive
- Patience for a multi-session build — this is not a fifteen-minute setup, and Part 2 onward assumes you're building incrementally and verifying each stage before moving to the next