Open Source LLMs: Complete Guide to Local AI Models
In This Guide
Why Open Source LLMs Matter Now
Three years ago, the conversation around open source language models was mostly theoretical. GPT-4 had a massive quality lead, open alternatives felt like science projects, and nobody was deploying Llama in production with a straight face. That picture has reversed in 2026. Qwen 3 235B-A22B leads the broadest range of public benchmarks under an Apache 2.0 license. DeepSeek R1 matches or beats proprietary reasoning models on AIME math problems at 79.8% accuracy. GLM-5.1 rivals Claude Opus on coding tasks. The quality argument for keeping everything behind an API is gone for the majority of production workloads.
The shift is not just about benchmarks. Open source models solve three problems that API-only approaches cannot. First, data stays on your infrastructure. Healthcare companies processing patient records, law firms handling privileged communications, and financial institutions with regulatory constraints can run inference without sending a single byte to a third party. Second, costs become predictable. API pricing scales linearly with token volume, and a chatbot handling 10 million messages per month on Claude or GPT-4o can cost $50,000 or more in raw API fees. The same workload on a self-hosted Qwen 3 72B model running on two A100 GPUs costs roughly $3,000 per month in compute. Third, you control the model version. No surprise deprecations, no behavior changes after a provider updates their weights, no rate limits during traffic spikes.
The developer tooling has matured alongside the models. Ollama gives you a one-line install and Docker-like model management on Mac, Linux, and Windows. vLLM handles production serving with PagedAttention and continuous batching. llama.cpp runs quantized models on consumer hardware with CPU and GPU hybrid inference. SGLang optimizes structured generation for agent workflows. The stack is real, tested, and running at companies from startups to Fortune 500 enterprises.
The 2026 Model Landscape
The open source model ecosystem in 2026 is dominated by five major families, each with distinct strengths. Understanding their differences saves weeks of experimentation.
Qwen (Alibaba Cloud)
Qwen 3 is the current overall leader in open source LLMs. The flagship 235B-A22B model uses a mixture-of-experts architecture that activates only 22 billion parameters per forward pass, keeping inference costs manageable despite its massive parameter count. It leads benchmarks in reasoning, coding, multilingual tasks, and general instruction following. The smaller Qwen 3.7 model punches well above its weight for coding specifically. All Qwen 3 models ship under Apache 2.0, the cleanest commercial license available. Qwen also provides strong embedding and vision models in the same ecosystem.
DeepSeek
DeepSeek built its reputation on reasoning. DeepSeek R1 uses chain-of-thought reasoning with verification steps to achieve 79.8% on AIME, a math competition benchmark that most proprietary models struggle with. DeepSeek V4 Pro offers a strong general-purpose model under MIT license. The DeepSeek Coder series remains competitive for code generation tasks. DeepSeek models tend to be more resource-intensive to serve due to their architecture, but the reasoning quality justifies the cost for applications that demand accuracy.
Llama (Meta)
Meta's Llama family remains the most widely deployed open source model line. Llama 4 Scout specializes in long-context workloads with a 256K token context window, making it the go-to choice for document processing and retrieval-augmented generation. The Llama 4 Maverick model targets general-purpose tasks with strong multilingual performance. Llama's community license is permissive for most commercial uses, though it includes a revenue threshold that very large companies need to review. The Llama ecosystem has the largest community, the most fine-tuned variants, and the broadest tool support.
GLM (Zhipu AI)
GLM-5.1 and GLM-5.2 surprised the industry in 2026 by matching Claude Opus on coding benchmarks. GLM-5.2 ships under MIT license, making it one of the most commercially permissive high-quality models available. GLM models support function calling natively and integrate well with agent frameworks. The relatively smaller community compared to Llama means fewer fine-tuned variants, but the base model quality compensates for this.
Mistral
Mistral continues to offer strong models for multilingual work and coding. Mistral Large 2 handles European languages particularly well and offers solid reasoning capabilities. The Mixtral mixture-of-experts architecture pioneered efficient inference at scale before Qwen adopted a similar approach. Mistral models are typically smaller and faster to serve than equivalently capable models from other families, making them a good fit for latency-sensitive applications.
Other Notable Models
Google's Gemma 3 provides compact models optimized for on-device deployment. Microsoft's Phi-4 demonstrates that carefully curated training data can produce surprisingly capable models at 3B to 14B parameter counts. Cohere's Command R series targets enterprise RAG use cases with built-in citation generation. Each of these fills specific niches where the larger model families may be overkill or a poor architectural fit.
Choosing the Right Model
Model selection depends on four factors: your primary use case, available hardware, latency requirements, and licensing needs.
For general-purpose chatbots and assistants, Qwen 3 72B or Llama 4 Maverick at 70B offer the best quality per compute dollar. Both run comfortably on a single A100 80GB GPU or two consumer RTX 4090 GPUs with quantization. If your application is primarily English, Llama has a slight edge in natural conversational tone. For applications serving Asian or European languages, Qwen and Mistral respectively perform better.
For coding assistants, GLM-5.2 and Qwen 3.7 lead the benchmarks. DeepSeek Coder V3 is strong for Python and JavaScript specifically. The key metric for coding models is not just code generation quality, but how well the model handles multi-file context, follows existing code patterns, and generates tests alongside implementations.
For reasoning-heavy applications like math tutoring, scientific analysis, or complex planning, DeepSeek R1 is the clear leader. Its chain-of-thought approach produces verifiable reasoning steps, which matters enormously for applications where you need to audit the model's logic.
For RAG and document processing, Llama 4 Scout's 256K context window handles long documents without chunking compromises. Pair it with a good embedding model like Qwen's text-embedding-v3 or a fine-tuned BGE variant for the retrieval stage.
For edge and mobile deployment, Phi-4 at 3.8B parameters and Gemma 3 at 2B deliver usable quality on phones and embedded devices. These models run acceptably on devices with 4GB of RAM using aggressive quantization.
Start with Qwen 3 72B for general-purpose work, DeepSeek R1 for reasoning, Llama 4 Scout for long-context RAG, and GLM-5.2 for coding. Drop to Phi-4 or Gemma 3 only when hardware constraints demand it.
Running Models Locally
Local inference means running the model on hardware you control, whether that is a developer laptop, a workstation with a dedicated GPU, or a cloud GPU instance you rent by the hour. The tooling has converged around two primary stacks.
Ollama is the starting point for most developers. It provides a single binary installation on Mac, Linux, and Windows, with a CLI that works like Docker for models. Running ollama pull qwen3:72b downloads the model, and ollama run qwen3:72b starts an interactive chat session. Ollama wraps llama.cpp internally and handles GGUF quantization transparently. On Apple Silicon Macs running Ollama 0.19 or later, it automatically uses the MLX backend for optimal Metal GPU utilization. Ollama binds to localhost:11434 by default and exposes an OpenAI-compatible API, so existing code that calls the OpenAI SDK can point at Ollama with a one-line URL change.
llama.cpp is the low-level engine that powers Ollama and several other tools. Using it directly gives you finer control over model loading, context size, GPU layer allocation, and batch processing. It supports GGUF quantization natively and can split model layers between GPU VRAM and system RAM, allowing you to run models larger than your GPU can hold entirely in memory. The trade-off is a steeper learning curve and manual model management.
For hardware, the minimum viable setup for useful local inference is 16GB of unified memory (Apple Silicon) or 8GB VRAM (NVIDIA GPU) running a 7B to 8B parameter model at Q4 quantization. For a 70B model, you need 48GB or more of VRAM, which means a workstation GPU like the RTX 5090 (32GB), an A6000 (48GB), or an A100 (80GB). Cloud GPU rental through providers like Vast.ai lets you rent these machines by the hour at marketplace prices starting around $0.50 per hour for an A100.
Memory bandwidth matters more than raw compute for inference. Apple Silicon Macs with their unified memory architecture achieve surprisingly competitive tokens-per-second rates on large models because their memory bandwidth is high relative to the compute available. An M4 Max with 128GB unified memory can run a 70B Q4 model at roughly 15 to 20 tokens per second, which is usable for interactive applications.
Quantization and Compression
Quantization reduces model precision from the standard 16-bit floating point (BF16/FP16) to lower bit widths like 8-bit, 4-bit, or even 2-bit representations. This shrinks model file sizes, reduces memory requirements, and speeds up inference, all at the cost of some quality loss. The practical question is always how much quality you lose and whether it matters for your use case.
Three quantization formats dominate in 2026. GGUF is the native format for llama.cpp and Ollama. It supports CPU+GPU hybrid inference and offers fine-grained quantization levels from Q2_K through Q8_0. The sweet spot is Q4_K_M, which delivers roughly 95% of full-precision quality at 25% of the memory footprint. GPTQ is a GPU-only format that uses calibration data to minimize quantization error. It works well with vLLM and other GPU serving frameworks. AWQ (Activation-aware Weight Quantization) achieves similar quality to GPTQ but with faster inference on modern NVIDIA hardware. On Hopper and newer GPUs (H100, H200), FP8 quantization has emerged as the production standard because it halves memory usage with virtually zero quality loss on these architectures.
A critical principle: a larger model at lower precision almost always beats a smaller model at higher precision. A 70B model quantized to Q4 outperforms a 7B model at full FP16 by a wide margin, despite occupying a similar amount of memory. The strategy is to pick the largest model your hardware can fit, then apply the highest quality quantization that fits in your available VRAM. Going below Q3 quantization rarely makes sense because quality degradation accelerates while VRAM savings become marginal in absolute terms.
Production Serving
Serving open source models in production requires different tooling than local development. The key challenge is handling concurrent users efficiently. A naive single-request server wastes GPU cycles during the autoregressive decoding phase, where each token depends on the previous one. Production serving frameworks solve this through continuous batching, where multiple requests share the GPU simultaneously.
vLLM is the industry standard for production LLM serving. Its PagedAttention mechanism manages KV cache memory like an operating system manages virtual memory, eliminating waste from pre-allocated fixed-size buffers. In 2026 benchmarks, vLLM delivers 16x higher throughput than Ollama under concurrent load. It supports tensor parallelism across multiple GPUs, automatic model sharding, and all major quantization formats. vLLM requires NVIDIA CUDA GPUs with at least 16GB VRAM for FP16 inference or 8GB for quantized models.
SGLang has gained traction for applications that need structured generation, such as JSON output, function calling, or constrained decoding. It optimizes the generation process for these patterns specifically, reducing latency for agent-style workloads where the model output must conform to a schema.
For scaling, the standard architecture is a load balancer in front of multiple vLLM instances, each running on a dedicated GPU or GPU cluster. Autoscaling based on request queue depth handles traffic spikes. Adding a response cache (Redis or a dedicated LLM caching layer) in front of the serving layer can reduce GPU load by 30% to 60% for applications with repetitive queries.
Memory and Context Management
Open source models face the same fundamental challenge as proprietary ones: they are stateless by default. Every request starts with zero knowledge of previous interactions. For applications that need continuity across conversations, user personalization, or accumulated knowledge, you need an external memory layer.
The advantage of self-hosted models is that your memory system operates entirely within your infrastructure. Conversation histories, user preferences, and extracted knowledge never leave your network. This simplifies compliance with data residency requirements and privacy regulations like GDPR, where the right to be forgotten applies to AI-stored data as much as traditional databases.
Context window size varies dramatically across open source models. Llama 4 Scout supports 256K tokens natively, while many models cap at 8K or 32K. For models with smaller context windows, a multi-layer memory architecture becomes essential: short-term conversation buffer, medium-term session summaries, and long-term knowledge stored in a vector database or knowledge graph with retrieval on each turn. Context engineering determines what information to inject into each prompt to maximize the model's effective knowledge without exceeding its context limit.
When running open source models in a RAG pipeline, you control both the retrieval and generation stages. This means you can optimize the embedding model and the generation model together, use the same GPU for both, and tune parameters like chunk size and retrieval depth without worrying about API rate limits or per-token costs on the generation side.
Cost Analysis
The cost equation for open source models depends on your scale. At low volume, under 100,000 tokens per day, API services are cheaper because you avoid fixed infrastructure costs. At moderate volume, 1 million to 10 million tokens per day, a single rented GPU running an open source model typically breaks even with API costs within 2 to 4 weeks. At high volume, above 10 million tokens per day, self-hosted open source models cost 4x to 10x less than equivalent API calls.
Concrete numbers: an A100 80GB GPU on Vast.ai costs roughly $0.80 to $1.50 per hour depending on availability. Running Qwen 3 72B quantized to Q4 on this machine serves approximately 50 tokens per second per concurrent request. For a customer support chatbot generating 500-token responses, that is 360 responses per hour, or roughly 8,600 per day. The daily compute cost is about $20 to $36. The same volume through a proprietary API at $3 per million input tokens and $15 per million output tokens would cost approximately $130 per day. The savings compound as you scale to multiple models, multiple use cases, or higher volumes.
Hidden costs to account for include: infrastructure management time (monitoring, updates, failover), the learning curve for your team, and the opportunity cost of building serving infrastructure instead of application features. For teams without dedicated ML infrastructure engineers, managed open source model hosting services offer a middle ground, providing API access to open source models at prices between self-hosted and proprietary API costs.
For a deeper breakdown of AI spending patterns and optimization strategies, see our AI cost optimization guide.