Quick Answer
The best local AI runtime as of September 2026 is llama.cpp (Georgi Gerganov and contributors), the strongest general-purpose single-user inference engine across broad hardware backends [5][8]. The ranking is llama.cpp (Georgi Gerganov and contributors), vLLM (vLLM project / community), Ollama (Ollama, Inc.), SGLang (LMSYS / SGLang project), NVIDIA TensorRT-LLM (NVIDIA), MLX (Apple), LM Studio (LM Studio), and llamafile (Mozilla) [1][5][8][13][14].
Key Takeaways
- llama.cpp (Georgi Gerganov and contributors) recorded about 65 tok/s for Llama 3.1 8B on an NVIDIA RTX 4090 in a July 2026 single-stream test [5].
- vLLM (vLLM project / community) recorded about 920 tok/s aggregate at 50 concurrent requests for Llama 3.1 8B on an NVIDIA RTX 4090 in a July 2026 comparison [5].
- Ollama (Ollama, Inc.) posted about 62 tok/s single-stream and about 155 tok/s aggregate at 50 concurrent requests on an NVIDIA RTX 4090 in a July 2026 test [5].
- NVIDIA TensorRT-LLM (NVIDIA) reached the highest aggregate throughput in a June 2026 comparison, about 2,780 tok/s at 100 concurrent requests, with SGLang (LMSYS / SGLang project) at about 2,460 tok/s [14].
- A practical starting point for 7B–8B local models is 16 GB system RAM with a 6–8 GB GPU at 4-bit quantization [40].
- llamafile (Mozilla) placed near the top with llama.cpp in Mozilla’s September 17, 2026 Steam Deck benchmark [1].
How do llama.cpp, vLLM and Ollama compare on dated throughput benchmarks?
| Runtime | Organization | Model formats / hardware | Dated benchmark figure | Multi-GPU support | OpenAI-compatible API | License | Setup complexity |
|---|---|---|---|---|---|---|---|
| llama.cpp | Georgi Gerganov and contributors [30] | GGUF; CPU, CUDA, Metal, HIP, Vulkan, SYCL backends [5][30] | 65 tok/s on an RTX 4090 with Llama 3.1 8B (July 9, 2026) [5] | GPU layer offloading and multi-GPU support [30] | Yes; llama-server provides an OpenAI-style HTTP interface [8] | MIT [7] | Moderate; users select builds, quantizations, backends, runtime parameters [8] |
| vLLM | vLLM project / community [21] | Hugging Face Transformers formats, safetensors, supported quantized formats; NVIDIA and supported AMD accelerators [17] | 71 tok/s for one request; 920 aggregate tok/s at 50 concurrent requests (July 9, 2026) [5] | Tensor parallelism, pipeline parallelism, distributed serving [21] | Yes; native OpenAI-compatible server [27] | Apache-2.0 [16] | Moderate to difficult for production serving [5] |
| Ollama | Ollama, Inc.; Ollama project [8] | GGUF through a packaged llama.cpp-based stack; CPU, CUDA, ROCm, Apple Metal paths [5][10] | 62 tok/s on an RTX 4090 with Llama 3.1 8B; about 155 aggregate tok/s at 50 concurrent requests (July 9, 2026) [5] | Limited multi-GPU controls compared with server runtimes [8][10] | Yes; REST API with OpenAI-compatible endpoints [8] | MIT [8] | Easiest among the major server runtimes in cited comparisons [8][10] |
| SGLang | LMSYS / SGLang project [14] | Hugging Face Transformers and safetensors; quantized models; accelerator-specific kernels; primarily NVIDIA-oriented [14] | About 125 tok/s at one concurrent request; about 2,460 tok/s at 100 concurrent requests (June 1, 2026); configuration-specific [14] | Tensor and data-parallel serving for multi-GPU and distributed workloads [14] | Yes; OpenAI-compatible serving endpoints [14] | Apache 2.0 [14] | Moderate to difficult; optimized for inference servers rather than casual desktop users [14] |
| NVIDIA TensorRT-LLM | NVIDIA [14] | Hugging Face checkpoints, safetensors, TensorRT engine representations; optimized for NVIDIA GPUs [14] | About 130 tok/s at one concurrent request; about 2,780 tok/s at 100 concurrent requests (June 1, 2026) [14] | Tensor, pipeline, and in some deployments expert/data parallel strategies across NVIDIA GPUs [14] | Yes through Triton or TensorRT-LLM serving stack; compatibility depends on the selected wrapper [14] | Apache 2.0 [14] | Difficult; engine building, CUDA compatibility, and NVIDIA deployment knowledge often required [14] |
| MLX | Apple [13] | MLX-native weights and supported Hugging Face model formats; optimized for Apple Silicon unified memory and Metal [13] | not published | Apple Silicon unified-memory execution [13] | HTTP and Python serving options exist; OpenAI compatibility depends on the selected wrapper [13] | MIT [13] | Moderate for Apple developers [13] |
| LM Studio | LM Studio [1] | Primarily GGUF through a llama.cpp path; desktop support for macOS, Windows, Linux with platform-specific acceleration [1] | not published | Limited desktop-oriented multi-GPU controls [1] | Yes; local server with OpenAI-compatible API support [1] | Check runtime and model licenses separately [1] | Very easy; graphical model discovery, downloading, configuration, server startup [1] |
| llamafile | Mozilla [1] | Packaged executable built around llama.cpp; quantized GGUF models inside a single runnable file [1] | not published | Inherits llama.cpp hardware controls; not a distributed-serving control layer [1] | Yes through its local HTTP server and OpenAI-style endpoints in supported configurations [1] | Apache 2.0 for the project; embedded models retain their own licenses [1] | Extremely easy; download one executable and run it with little environment configuration [1] |
Which local AI runtime should you choose for single-user inference?
1. llama.cpp
llama.cpp by Georgi Gerganov and contributors is the best overall single-user local inference runtime in this comparison [5][8][10], because it directly serves GGUF models across CPU, CUDA, Metal, HIP, Vulkan, and SYCL backends [5]. The project is reported as MIT-licensed, and a representative July 9, 2026 test measured about 65 tok/s for Llama 3.1 8B on an RTX 4090 in single-stream inference [7][5].
A practical setup starts at 16 GB system RAM with a GPU containing 6-8 GB VRAM, or an Apple Silicon unified-memory machine, for 7B to 8B models at 4-bit quantization [31][40][42]. Thirteen-billion-parameter models are more comfortable around 16 GB VRAM, while seventy-billion-parameter models usually require 48 GB+ VRAM, multi-GPU memory, or a large unified-memory system [31][40][42].
The runtime is the right choice when an engineer needs direct control over CPU/GPU layer placement and quantization without a heavier serving stack [9]. The tradeoff is that users must select builds, quantizations, backends, and context parameters themselves, which makes setup less turnkey than Ollama or LM Studio [7].
2. vLLM
vLLM, developed by the vLLM project / community, ranks here for high-concurrency serving because its throughput mode favors aggregate token rate over single-request latency [20][5]. The engine loads Hugging Face Transformers model formats, with documentation listing 200+ supported model architectures [17]. In a July 9, 2026 comparison on an NVIDIA RTX 4090 running Llama 3.1 8B, vLLM produced about 71 tokens/s for one request and about 920 aggregate tokens/s at 50 concurrent requests [5].
vLLM is best suited to multi-user or batch-style local servers, where many clients share one accelerator and the goal is total throughput rather than low per-request latency [20][34]. Hardware requirements are model-dependent; documentation says tensor/data parallelism determines how much memory remains for the KV cache [18]. For smaller models, common 2026 hardware guidance treats 8 GB VRAM or about 16 GB RAM as a practical starting point for quantized 7B–8B workloads [31][40][42].
The main caveat is that vLLM is more demanding to operate than a simple desktop runtime [34]. A July 16, 2026 production-quality post describes benchmarking across data-center accelerators such as NVIDIA H200 and B200, and AMD MI300X and MI355X [16][21]. Users should expect to configure model format, GPU memory, parallelism, context length, and batch policy before comparing results with llama.cpp or Ollama [5][18].
3. Ollama
Ollama by Ollama, Inc., is a practical entry point for local inference because it packages GGUF models through a llama.cpp-based stack and exposes an OpenAI-compatible REST API [5][8]. The runtime supports CPU, CUDA, ROCm, and Apple Metal paths [5][8], and the September 2026 comparison listed version 0.33.2 as MIT-licensed [8]. In a representative single-stream test on an RTX 4090 with Llama 3.1 8B, it produced about 62 tok/s [5].
Hardware guidance for local deployment commonly starts at 16 GB system RAM plus a GPU with 6–8 GB VRAM, or Apple Silicon unified memory [40][42][31]. Seven- to eight-billion-parameter models often run there at 4-bit quantization, while 13B-class models are more comfortable with 16 GB VRAM and 70B-class models usually need 48 GB+ VRAM or large offload setups [40][42][31]. This makes Ollama suitable for developer laptops, workstations, and single-user servers.
A practical fit is simple local model discovery, pull, and API access for one developer or a small internal tool; the runtime is easy to install and run as a local daemon [5][8]. A caveat is that its management layer adds overhead compared with direct llama.cpp, which was reported 2–8% faster in community comparisons [10], and high-concurrency serving is weaker than vLLM: at 50 concurrent requests it reached about 155 tok/s aggregate, versus roughly 920 tok/s for vLLM in the same July 2026 comparison [5].
4. SGLang
SGLang by LMSYS / SGLang project belongs in this list because it targets high-concurrency serving on primarily NVIDIA hardware, with OpenAI-compatible endpoints for production-style workloads [6][14]. In that test setup, SGLang reached approximately 125 tok/s at one concurrent request and 2,460 tok/s at 100 concurrent requests [14].
Hardware planning starts with an NVIDIA GPU that has enough VRAM for the chosen model, quantization metadata, runtime buffers, and KV cache [6][14]. For 7B–8B quantized models, common local-AI guidance begins around a GPU with 6–8 GB VRAM plus 16 GB system RAM; larger 13B models commonly need 16 GB VRAM or more [31][40][42].
A primary use is a multi-user inference server that needs aggregate throughput across many requests, especially on NVIDIA accelerators [14]. Setup is more serving-oriented than casual desktop use, aimed at developers operating local endpoints [6][14]. The caveat is that 2,460 tok/s came from one test configuration; GPU model, quantization, context length, and batching policy can change results materially [14].
5. NVIDIA TensorRT-LLM
NVIDIA TensorRT-LLM by NVIDIA ranks here in this shortlist because it is an Apache-2.0 inference stack built for optimized serving on NVIDIA GPUs, using Hugging Face checkpoints, safetensors and TensorRT engine representations [14]. In a June 1, 2026 comparative analysis, it reached about 130 tok/s at one concurrent request and about 2,780 tok/s at 100 concurrent requests, the highest of the three engines tested in that setup [14].
Hardware-wise, expect an NVIDIA GPU system with CUDA-compatible software, and use multi-GPU tensor or pipeline parallelism for larger serving workloads [14]. The stack commonly exposes OpenAI-style endpoints through a Triton or TensorRT-LLM server wrapper, so API compatibility depends on the chosen deployment [14].
Best use is high-concurrency production inference where aggregate token throughput is the priority for teams running many concurrent requests across services [14]. The main caveat is that setup is among the most demanding in this group, because engine building, CUDA compatibility and NVIDIA-specific deployment knowledge are often required [14].
6. MLX
MLX and mlx-lm by Apple are among the fastest local-inference options on Apple Silicon Macs because they target Metal and unified memory rather than conventional NVIDIA CUDA serving [13]. The framework uses MLX-native weights and supported Hugging Face model formats, provides Python and HTTP serving paths, and carries an MIT license for the runtime while individual models keep their own terms [13].
The required hardware is an Apple Silicon Mac with enough unified memory for the selected quantized weights, KV cache, and OS overhead; MLX is tied to the Apple Silicon memory architecture and does not offer conventional multi-discrete-GPU scaling [13]. That makes it a practical fit for Apple-native developers who want a low-level local server without an external GPU stack, while remaining less portable across hardware ecosystems [13].
The main caveat is that a dated MLX tok/s result is unavailable, so performance must be measured on your own Mac, model configuration, and workload before selecting a local stack [13].
7. LM Studio
LM Studio from LM Studio ranks here as a graphical desktop runtime for users who want model discovery, download, configuration, and server startup without command-line setup [12][34]. The application runs on macOS, Windows, and Linux, and it supports GGUF model files [12]. Its local server exposes OpenAI-compatible API endpoints, so existing scripts can point at a local endpoint instead of a cloud service [12].
For a small-to-mid local model, a practical starting point is 16 GB of system RAM plus either a GPU with 6 to 8 GB of VRAM or an Apple Silicon machine from Apple [40][42]. Seven- to eight-billion-parameter models commonly fit at 4-bit quantization in that class; 13B models are more comfortable with 16 GB of VRAM, and 70B models usually require 48 GB+ of VRAM, multiple GPUs, or high-memory unified memory [31][40][42].
The main desktop use is a single-developer or small-team local endpoint that needs quick model switching and an OpenAI-compatible API, with less emphasis on multi-GPU serving controls [12][34]. A caveat is performance: Mozilla's September 17, 2026 Steam Deck benchmark found LM Studio behind llama.cpp from ggml-org and llamafile from Mozilla, particularly for 9B generation [1].
8. llamafile
llamafile, developed by Mozilla, ranks here because Mozilla’s September 17, 2026 Steam Deck benchmark placed it with llama.cpp at the top of the tested runtimes for prompt processing and generation [1]. It is a portable deployment format built around llama.cpp, commonly running quantized GGUF models from a single executable file [1]. This makes it useful when the goal is low-configuration local inference on a single machine.
Hardware requirements are similar to other GGUF-based local runtimes: for 7B–8B 4-bit models [40][42][31], practical guidance points to about 16 GB system RAM [40][42][31] and either a GPU with 6–8 GB VRAM [40][42][31] or Apple Silicon [40][42][31]. Larger model sizes need more memory, so llamafile should be matched to the selected quantization and context length before deployment.
A practical use case is distributing a ready-to-run local model to engineers who want low-configuration inference without managing a separate serving stack [1]. A caveat is that llamafile inherits llama.cpp’s hardware constraints, so performance depends on the embedded model, accelerator, and configuration [1].
What hardware is needed to run small and mid-size local models?
Small 7–8B local models can start with 16 GB system RAM plus a GPU with 6–8 GB VRAM or Apple's Apple Silicon unified memory, while mid-size 13B models usually need 16 GB VRAM and 32 GB RAM for comfortable interactive use [13][31][40][42]. 7B and 8B models commonly fit at 4-bit quantization in that hardware class, with CPU offload available when GPU memory is smaller [31][40][42].
The vLLM project's documentation notes that parallelism choices determine memory left for the KV cache, which affects usable context [18]. The same documentation distinguishes throughput-oriented operation from interactive-oriented operation, so memory headroom matters for long contexts and concurrent requests [20].
llama.cpp (ggml-org) supports CPU, CUDA, Metal, HIP, Vulkan, and SYCL backends, which makes manual layer placement practical on mixed systems [5][30]. vLLM favors high-throughput serving, with its benchmark documentation showing an example of 382.89 output tokens/s in a stated test setup [5][19]. Ollama (Ollama, Inc.) provides a local daemon and OpenAI-compatible endpoints for simple model pulling and API access [5][8].
Hardware therefore depends on the runtime role: desktop single-user inference can start near 8 GB VRAM, while concurrent serving usually requires larger GPU memory or multi-GPU tensor parallelism [18][31][40].
How does Ollama compare with llama.cpp for setup and performance?
Ollama from the Ollama project and Ollama, Inc. is generally easier to set up than llama.cpp from Georgi Gerganov and contributors, while direct llama.cpp usually runs slightly faster in single-stream tests [34][46][5][8].
Ollama gives a developer-friendly CLI runtime with an API and model management for local workflows [34][46]. llama.cpp remains the lower-level baseline: users choose GGUF models, quantizations, CPU/GPU backends, context settings, and server flags before running llama-server [5][8].
Performance differences are modest for a single request [5]. A July 9, 2026 comparison reported about 65 tokens/s for llama.cpp and about 62 tokens/s on an NVIDIA RTX 4090 with Llama 3.1 8B Instruct in a single-stream setup [5]. September 2026 comparisons found direct llama.cpp typically 5–15% faster than Ollama, likely because Ollama adds a management layer over the underlying execution stack [5][8][10].
Choose Ollama when quick local access and simple model handling matter. Choose llama.cpp when you need finer control of quantization, offloading, ports, and server behavior. For repeated model pulls, Ollama's registry workflow is simpler; llama.cpp gives more deployment knobs [34][46].
Frequently Asked Questions
Which local AI runtime should a single user choose in 2026?
llama.cpp, from Georgi Gerganov and contributors, is a strong single-user baseline because it supports GGUF, CPU/GPU backends, and an OpenAI-style server. Direct llama.cpp was typically 5-15% faster than Ollama in September 2026 comparisons.[5][8] A July 9, 2026 representative single-stream benchmark measured about 65 tokens per second for llama.cpp from Georgi Gerganov and contributors on an RTX 4090 with Meta Llama 3.1 8B [5] Use it when controlling quantization and placement matters. [5][8][30]
Which runtime handles many concurrent users better?
vLLM, from the vLLM project, is a high-concurrency serving runtime because it supports tensor parallelism and distributed serving. In a July 9, 2026 comparison, vLLM produced about 71 tok/s for one request on that NVIDIA GeForce RTX 4090 with Meta Llama 3.1 8B and about 920 tok/s aggregate at 50 concurrent requests [5]. Ollama measured about 155 aggregate tok/s at 50 concurrent requests in the July 9, 2026 comparison.[5] Use vLLM when serving many clients. [5][21]
Which local AI runtime is easy to install for a first project?
Ollama, from the Ollama project, is a simple major server runtime for one-command installation, model pulling, and a local daemon. It uses GGUF models through a packaged llama.cpp-based stack and exposes OpenAI-compatible endpoints. Direct llama.cpp was generally reported 2-8% faster than Ollama in September 2026 comparisons, so Ollama trades some raw speed for setup convenience on CPU, CUDA, ROCm, or Metal paths. [5][10]
What hardware do I need to run 7B-8B and 13B models locally?
For 7B-8B models, a practical minimum is 16 GB system RAM plus either a GPU with 6-8 GB VRAM or Apple Silicon; many guides treat 8 GB VRAM as comfortable at 4-bit quantization. Thirteen-billion-parameter models are more comfortable at 16 GB VRAM, while 70B models usually need 48 GB+ VRAM or large unified memory.[31][32][39][40][42] Match model size to available VRAM before choosing a runtime. [31][40][42]
Do I need vLLM for local AI, or is Ollama enough?
Ollama is enough for one-user desktop workflows because it simplifies model downloads and serves a local API. Choose vLLM when the workload needs higher aggregate serving throughput; its July 2026 RTX 4090 test showed about 920 tok/s at 50 concurrent requests, versus about 155 tok/s for Ollama in that setup. vLLM requires more server-style configuration than Ollama's one-command flow. [5]
Which runtime should I use on Apple Silicon?
MLX and mlx-lm, from Apple, are natural Apple Silicon candidates because they target unified memory and Metal acceleration. Ollama and llama.cpp also run on Apple Metal, but the available September 2026 material does not give a directly comparable dated tok/s number for MLX against other runtimes. Use MLX when staying native to Apple hardware matters; use Ollama or llama.cpp for broader GGUF workflows. [5][13]
Sources
- Benchmarking llama.cpp vs llamafile vs LM Studio vs Ollama — 2026-09-17
- Run Local LLMs in 2026: Ollama vs LM Studio vs vLLM — 2026-06-28
- Best local LLM runtimes in 2026: speed vs setup tradeoff — 2026-06-06
- Ollama vs LM Studio vs vLLM vs llama.cpp vs MLX 2026 — 2026-05-26
- 2026 Comparison of Local AI Inference Engines - Sesame Disk — 2026-07-09
- 2026 Local Inference Engines: Key Decision - Sesame Disk — 2026-06-19
- vLLM, Ollama, LM Studio, llama.cpp: Choosing the best LLM ... — 2026-05-19
- Throughput Vs Latency: The... — 2026-09-13
- llama.cpp vs. vLLM: Choosing the right local LLM inference engine — 2026-06-15
- Ollama vs llama.cpp 2026: Which Local LLM Tool Actually Wins? — 2026-08-16
- The Complete Guide to Local LLM Inference Tools in July 2026 ... — 2026-07-19
- Ollama Alternatives: 8 Local LLM Runtimes Compared - Autonoma AI — 2026-08-04
- Run LLMs Locally: Ollama, LM Studio, llama.cpp, vLLM — 2024-08-15
- Open Source LLM Inference Projects: A Comprehensive ... — 2026-06-01
- Running LLMs Locally in 2026: Ollama, llama.cpp, and Self-Hosted ... — accessed 2026-09-25
- Keeping vLLM Production Quality: A Look Inside CI, Benchmarking ... — 2026-07-16
- Supported Models - vLLM Documentation — 2026-09-24
- throughput - vLLM — 2026-09-11
- vllm bench throughput — 2026-09-21
- Benchmark CLI - vLLM Documentation — 2026-09-17
- Welcome to vLLM¶ — 2026-04-09
- vLLM Blog — 2023-06-20
- vLLM — accessed 2026-09-25
- Welcome to vLLM! — accessed 2026-09-25
- Performance Dashboard - vLLM — accessed 2026-09-25
- v0.29.0 - vLLM Documentation — 2026-04-09
- vLLM Serve - vLLM Documentation — 2026-09-09
- List of Supported Models — accessed 2026-09-25
- vLLM bench serve — 2026-09-21
- ggml-org/llama.cpp: LLM inference in C/C++ - GitHub — 2026-09-14
- Best PCs for Local AI in 2026: How Much Power Do You Really Need? — 2026-08-25
- 7. Gemma 4 26b-A4b — 2026-06-19
- Local AI Hardware Guide 2026: What Models Run at Every Budget — 2026-08-14
- Best Local AI Tools in 2026: 10 Free & Enterprise Picks — 2026-07-12
- Running Local AI in 2026 - DWU Consulting — 2026-08-25
- Local LLMs on Consumer Hardware in 2026: What You Can ... — 2026-07-29
- Best PC for Local AI & LLMs 2026: 17 Tested Builds - Houtini — 2026-02-19
- Best Laptops for Local AI in 2026: Lab-Tested Leaderboard — 2026-09-15
- Local AI vs Cloud AI in 2026: When to Run Models on Your ... — 2026-05-27
- Local LLM: What It Is, Best Models & Hardware (2026) — 2026-06-14
- Guide to Local LLMs in 2026: Privacy, Tools & Hardware - SitePoint — 2026-02-15
- Local LLM Hardware Requirements in 2026 | AI Hub - Overchat AI — accessed 2026-09-25
- Running AI Locally, Part 2: From VMware Context to Hands-On Tools -- Virtualization Review — 2026-06-30
- Local AI Hardware Requirements (2026): Complete Guide — 2025-10-25
- Best Desktops for Local AI in 2026: Lab-Tested Leaderboard — 2026-09-23
- msb-msb/awesome-local-ai: A curated list of ... — 2026-02-03
- Local AI Blog — Qwen, Llama, GPU Picks & VRAM Guides (2026) — 2025-03-25
- Top 5 Local LLM Tools and Models in 2026 — 2026-08-02