Getting an LLM application from prototype to production raises questions a notebook does not: which model to call for which request, whether to use an API or host the model yourself, how to make serving affordable, and how to evaluate and monitor quality once real users arrive. The three pages in this section each take one of those questions.
Running LLM systems: LLMOps, self-hosted serving and quantization, and choosing between frontier models.
Picking a model in 2026 is no longer a single decision — it is a routing decision. Most production systems use two or three models: a small fast one for…
LLMOps is the operational discipline of running LLM-backed systems the same way you run any other production software: versioned, tested, observable…
Self-hosting open-weights LLMs in 2026 is a different problem than it was in 2023. Llama 3.x and Qwen 2.x match or beat hosted GPT-3.5-class models on most…
Requests flow from the application through a gateway that chooses a model per request: a small, cheap model for simple tasks and a frontier model for hard ones, with fallbacks when a provider is down. Some traffic may go to self-hosted open-weight models served by vLLM, often quantized to fit on fewer GPUs. Across all of it, LLMOps practices record prompts, responses, latency and cost, and run evaluations so that prompt or model changes are tested before release.
| Question | Page | Key trade-off |
|---|---|---|
| Which model should handle this request? | Frontier Model Comparison | Quality versus cost and latency |
| How do we test, deploy and monitor? | LLMOps and Production | Release speed versus regression risk |
| Should we host models ourselves? | vLLM and Quantization | Control and data locality versus operational burden |
Hosted APIs are the default starting point because they need no infrastructure. Self-hosting becomes attractive with steady high volume, strict data residency, or a need for fine-tuned open models.