![llama.cpp vs Ollama: v1.0, $0 vs $20 Cloud Tier [2026]](https://shattered.io/wp-content/uploads/2026/11/llama-cpp-vs-ollama-v1-0-free-vs-20-cloud-tier-2026-img13.webp)
Don't miss new tech stories on Google
Add Shattered once in the Google app and our stories show up in your news suggestions.
llama.cpp vs Ollama in November 2026: What Changed in One Week #
The llama.cpp project tagged v1.0.0 on November 13, 2026, its first stable release and the point where the public API moved to semantic versioning. Georgi Gerganov merged the version bump, and nightly builds b12381 and b12383 landed on November 14, which shows the project did not slow down after the milestone. That single release reshapes the llama.cpp vs Ollama question, because Ollama leans on llama.cpp for GGUF model compatibility and now sits on top of a stable upstream.
Ollama had its own news. Reports on November 11 said Ollama dropped the free plan from its hosted cloud, leaving Pro at $20 a month, Max at $100 and Team at $500. Local use stays free, but the product is no longer only a local runner. For the wider field that includes vLLM and LM Studio, the four-way runtime comparison covers all four. This piece stays on the two tools most people actually weigh against each other.
Here is the short version before the detail:
- Pick Ollama if you want one install, one command per model and an optional cloud path for models too big for your machine.
- Pick llama.cpp if you ship software that embeds an inference library, need fine control over memory and cache settings, or want the newest architecture support the day it lands.
- Pick neither as your main engine if you serve many simultaneous users from a GPU server. That job belongs to vLLM.
- Cost: both run locally for $0. Only Ollama sells paid cloud plans, at $20, $100 and $500 a month.
The sections below set the two side by side on specs, pricing, performance claims, hardware, developer experience and migration. Every figure comes from official pages or dated reports fetched on November 15, 2026. Where a number is vendor-published and not independently measured, the text says so. Where only one source reported a detail, the text hedges it.
Specs Table: llama.cpp 1.0 vs Ollama Side by Side #
The two projects overlap far more than their reputations suggest. Ollama packages a model manager, a local API and a command line around an inference engine. llama.cpp is that kind of engine, plus a server and a set of command line tools. The table below lists only facts confirmed on official pages or in multiple dated sources.
| Spec | llama.cpp | Ollama |
|---|---|---|
| Project type | Open-source C/C++ inference runtime under the ggml-org organization | Local app, CLI and API, plus optional hosted cloud models |
| Latest stable release | v1.0.0, November 13, 2026 | 0.x line (0.30 and 0.31 are named on its official blog) |
| Versioning policy | Semantic versioning for the public API since 1.0.0 | Pre-1.0 numbering |
| Nightly or pre-release builds | Yes, b12381 and b12383 on November 14, 2026 | Tagged point releases |
| Cost to run locally | $0 | $0 |
| Paid plans | None confirmed, no hosted product | Pro $20, Max $100, Team $500 per month (cloud usage) |
| Hosted cloud models | No | Yes, for example gemma4:cloud and clef:cloud |
| Default API address | You choose it through server flags | 127.0.0.1 port 11434, changed with OLLAMA_HOST |
| Default context window | Set by you on each run | 4096 tokens |
| Model format | GGUF at the center | GGUF through llama.cpp compatibility (Ollama 0.30), plus an MLX engine on Apple silicon |
| Used inside other tools | Yes, LM Studio ships llama.cpp runtime packs | Uses llama.cpp for GGUF model compatibility |
| Backing | Community project, Georgi Gerganov merged the 1.0.0 bump | Company that reports 8.9 million developers and $88M raised |
| Linux install | Release binaries or source build | One curl install script |
Two rows deserve emphasis. First, the shared lineage: LM Studio’s official changelog lists llama.cpp runtime updates such as runtime 2.50.0 built on upstream b11337, and Ollama’s own blog says its 0.30 release improved GGUF compatibility through llama.cpp. When a new model architecture lands upstream, several tools inherit it. Second, the default context window. Ollama starts at 4096 tokens, which surprises people who load a long document and watch the model forget the first half. You can raise it, but you have to know to.
What llama.cpp 1.0 Actually Changes #
A 1.0 label matters less for features than for promises. Before November 13, anyone embedding llama.cpp in an application pinned a build number and hoped the next one did not rename a function. Under semantic versioning, breaking changes to the public API now require a major version bump. Local AI’s coverage of the tag frames it as the project’s move from a fast-moving v0.x line to a foundation that downstream apps can build against.
Release coverage also reports the contents. Per those reports, v1.0.0 removed deprecated public APIs, promoted the NextN speculative-decoding API into the llama.h header, added OCP FP8 key-value caches, added a host-memory cache for mixture-of-experts experts with configurable CPU allocation, and added of external PLE shards. Treat that list as reported rather than verified line by line, because it rests on release notes and secondary write-ups. The direction is clear anyway: speculative decoding becomes a first-class part of the library, and large MoE models get a path to run with experts spilling into system memory.
The release before it, reportedly v0.9.0 on November 5, added OCP FP8 E4M3 quantization, a flash attention operation for efficient unified KV-cache use with several sequences, a batched tensor-copy API and four new model architectures. One source also credits it with wider audio generation and transcription support and Gemma 4 prefill optimizations. Hedge that one too, since a single report carries it. If it holds, the gap between v0.9.0 and v1.0.0 is under two weeks of work, which fits the project’s pace.
What 1.0 means if you only run models
If you launch a server and point a chat front end at it, 1.0 changes little on day one. Your existing command lines keep working, and the new cache options are opt-in. The practical gain is confidence when you update. A guide on running llama.cpp with Open WebUI will age better against a stable API than it would have against a moving one. Pin the version in your scripts anyway, because a stable API does not make every flag behave the same forever.
What 1.0 means if you embed the library
For application developers the change is larger. A desktop app, a game tool or a plugin that links against llama.h can now state a supported version range and trust it. The removal of deprecated functions means some code needs one more pass before it compiles against 1.0. That is a one-time cost, and it buys a predictable upgrade path afterward. Ollama builds a product on top of this layer, so the same stability helps Ollama’s own maintainers.
How Ollama Evolved Beyond a Local Wrapper #
The old shorthand, Ollama is a friendly wrapper around llama.cpp, no longer describes the product. Its own blog tracks a steady widening. Ollama 0.30 brought improved performance and GGUF compatibility through llama.cpp and added to its MLX engine on Apple silicon. Ollama 0.31 made Gemma 4 faster on Apple silicon through multi-token prediction powered by MLX, with the company reporting gains of up to 90 percent when used with coding agents, measured on the Aider polyglot benchmark. Mind the qualifier: that is the vendor’s own figure on one benchmark and one hardware family.
Speech support arrived recently. The announcement says the Phonon model reads text aloud in five languages with dozens of voices, with streaming claimed at more than 100 times real time on Apple silicon. Cloud models came earlier and keep growing. Cloudflare’s Clef, a 27B multimodal decision model, became available through Ollama Cloud and also runs locally, according to Agentic Weekly’s Ollama profile. Model tags such as gemma4:cloud and clef:cloud run on hosted hardware instead of down to your disk.
Ollama also positions itself as a hub for coding agents. Tools such as Aider with a local Ollama model treat its local API as a drop-in endpoint, which is part of why the company can report 8.9 million developers and $88M raised from Benchmark, Theory Ventures, 8VC, Y Combinator and angel investors. That scale funds a product team and a hosted service, and it also explains the pricing change covered below.
What has not changed is the local path. The quickstart still shows a local workflow that needs no API key, and the server binds to 127.0.0.1 on port 11434 by default. You can expose it on a network by setting OLLAMA_HOST, for example to 0.0.0.0:11434, but the default keeps it private to your machine. That conservative default is a point in Ollama’s favor against a bare llama.cpp server, where the bind address is whatever you typed.
Version numbers deserve a hedge. Reports for early November describe Ollama point releases in the 0.40 series, including 0.40.16 on November 9 and 0.40.17 on November 10, described as routine software updates rather than product launches. Only single sources carried those numbers, so check the releases page before you quote a version in your own documentation.
Pricing: $0 Engine vs $20, $100 and $500 Cloud Plans #
On the local side, price is a tie. Both tools cost $0 to download and run on your own hardware. The real cost is the machine, the electricity and the time you spend tuning. The split appears the moment you want hosted models. Ollama’s pricing page lists three paid plans, and the November 11 reports said the earlier free cloud tier was gone. Anything written about Ollama’s free cloud access before that date describes a plan that no longer exists.
| Runtime | Plan | Price | What it includes |
|---|---|---|---|
| llama.cpp | Open source | $0 | The engine and tools, on your own hardware |
| Ollama | Local | $0 | Local app, CLI and local API, no API key needed |
| Ollama | Pro | $20 per month or $200 per year ($16.67 per month billed annually) | $60 of usage credits per month |
| Ollama | Max | $100 per month | $300 of usage credits per month |
| Ollama | Team | $500 per month | Unlimited users, $1,000 of credits shared across the team |
| LM Studio | Free | $0 | Local models, the Bionic agent, offline voice transcription, LM Link for up to five devices |
| LM Studio | Bionic+ | $20 per month | Paid tier, full feature list not confirmed |
| LM Studio | Pro | $100 per month | Five times the Bionic+ usage limits, zero data retention, bulk discounts, early features |
| vLLM | Open source | $0 | Serving engine, you supply the GPUs |
Read the Ollama credit math carefully. Pro at $20 includes $60 of usage credits, so the credits exceed the sticker price. Max at $100 includes $300. Team at $500 includes $1,000 shared across an unlimited number of seats. On paid plans Ollama emails a reminder at 90 percent of included monthly usage, and you can turn that off in settings. Cloud models draw down those credits per token, so heavy agent loops can burn through an allowance faster than a casual chat user would expect.
Ollama’s August 31, 2026 pricing announcement is where the Pro, Max and Team names were confirmed. The free plan’s removal followed in November. For a hobbyist the practical effect is small, since local models stay free. For a team that built a workflow on free hosted inference, it is a budget line that appeared overnight. The cleanest hedge is to keep a local fallback. A llama.cpp server running a GGUF copy of the same model family costs nothing per token and does not change terms.
One caution on the LM Studio rows: its paid tiers sit under the Bionic product name, and the secondary reports on Bionic+ and Pro come with an incomplete feature list. Verify on the official pricing page before you commit budget. For the llama.cpp vs Ollama decision, LM Studio’s free tier matters mainly as a third option for people who want a graphical app on top of llama.cpp runtimes.
Performance: What the Published Numbers Say and Do Not Say #
No source checked for this comparison publishes a controlled, same-hardware, same-model test of llama.cpp against Ollama after November 13. That is the honest starting point, because any article that hands you a clean tokens-per-second winner is borrowing a number from a different setup. What does exist are vendor-published figures from the projects themselves. They answer different questions, so the table below keeps them apart.
| Source | Claim | Setup | What it tells you |
|---|---|---|---|
| vLLM blog | 1.7M tokens/s per GPU at P90 of 387 tokens/s per user, 58x GB300 NVL72 | DeepSeek-V4.1-Flash on one NVIDIA Vera Rubin NVL72 rack | Data-center ceiling for a serving engine |
| vLLM blog | 954K tokens/s per GPU at P90 of 196 tokens/s per user, 7.9x the aggregated single-node result | P/D disaggregation and Wide-EP on a GB300 NVL72 rack | What disaggregated serving adds |
| vLLM blog | About 500 tokens/s decoding a single request | Flint checkpoints (40B total, 2.5B active), one GPU | Small-active-parameter MoE on one card |
| vLLM blog | 2.8x throughput | Kimi K3 optimizations in vLLM | Engine-level gains on a very large model |
| vLLM blog | 1.7 to 3.2x per-user speed versus data-parallel P/D, 1M-token contexts | GLM-5.3 on 16 H200s | Long-context serving on a GPU cluster |
| Ollama blog | Up to 90% faster with coding agents | Gemma 4 in Ollama 0.31 on Apple silicon, Aider polyglot benchmark | Software gain on a Mac, not a cross-engine race |
| Ollama blog | Streaming above 100x real time | Phonon speech on Apple silicon | Text-to-speech speed, not LLM decoding |
Three things stand out. The vLLM figures come from NVIDIA racks and H200 clusters, not a desktop, so they describe where vLLM goes when you outgrow a single machine. The Ollama figures describe improvements to Ollama itself on Apple silicon, measured against its earlier behavior, not against llama.cpp. And llama.cpp’s official release material in this window lists features and a version milestone but no throughput table. Nobody has published the number you actually want.
That gap is useful to understand. Since Ollama uses llama.cpp for GGUF compatibility, a large share of single-user speed on a given GGUF model comes down to the same underlying kernels, the same quantization and the same hardware. Differences then come from defaults: context size, batch settings, how many layers go to the GPU, whether flash attention is on, and how long a model stays loaded between requests. A tuned llama.cpp command line can beat an untuned Ollama default, and a default Ollama install can beat a careless llama.cpp one. The way to know is to measure, which the migration section below walks through.
Speculative decoding is the feature most likely to move single-user numbers next. The method drafts several tokens cheaply and verifies them in one pass, so a model can emit more than one token per expensive step. Reports say llama.cpp 1.0 promotes the NextN speculative-decoding API into llama.h, which turns it from an experiment into something application code can call. vLLM’s blog describes DFlash2 speculative decoding with adaptive verification in its Beam-1.0 results, where agent-driven optimization cut decode latency 2.71 times. Those are different engines on different models, so treat them as direction, not a scoreboard.
Concurrency is the other axis where claims tend to mislead. Both tools run well for one person. Both can degrade when several people hit the same box at once, which is why the vLLM numbers above exist. If your workload is one developer and one coding agent, ignore the data-center figures. If it is a team of twenty sharing a GPU, the right comparison is no longer llama.cpp vs Ollama at all.
Hardware and Model Support: Apple Silicon, CUDA and GGUF Sizes #
Hardware coverage is broad on both sides, and the newest silicon tends to reach llama.cpp first, then flow into Ollama and LM Studio through updated runtimes. Check each project’s own documentation for the exact backends it supports, and confirm the build you need. On Apple silicon, Ollama now runs its own MLX engine alongside the llama.cpp path, which is where its Gemma 4 gains came from.
Model sizing is where hardware decisions get real. One community upload on Ollama shows how quantization changes disk and memory needs for a single model. It is a 9B distillation from DeepSeek-V4-Pro published by a user, not an official Ollama release, and it is listed in four sizes.
| Quantization | File size | Relative to full precision |
|---|---|---|
| q4km | Not listed | Not listed |
| q6k | Not listed | Not listed |
| q8_0 | Not listed | Not listed |
| f16 | Not listed | Baseline |
The relative column is simple arithmetic on the listed sizes. The ladder shows the trade: moving from f16 to q4km cuts the file by roughly two thirds, which decides whether a 9B model fits on an 8 GB or 12 GB card with room for context. Both Ollama and llama.cpp read GGUF, so the same file works in either tool. Only the way you launch it differs.
Bigger models change the picture. A catalog entry for Qwen3.8 27B lists a 19 GB download in a Hugging Face cache, a size that fits a 24 GB card with little spare room for context. The walkthrough on running Qwen3.8-27B locally with llama.cpp shows how those limits play out on real hardware. For models beyond a single card, Ollama’s cloud tags offload the work, while llama.cpp 1.0’s reported host-memory cache for MoE experts offers a local compromise by letting expert weights spill into system RAM at a speed cost.
New model support is the other practical question. llama.cpp supports a new architecture when a contributor lands it, and that can happen within days of a release. Ollama then needs a release that bundles the update, plus a packaged model in its library. LM Studio’s changelog shows the same lag, with runtime packs such as 2.66.0 and 2.67.0 following upstream builds. If you need a brand-new architecture the week it ships, llama.cpp is where support appears first. If you can wait a few days, Ollama’s packaged tags save the conversion step.
Ease of Use and Developer Experience #
Ollama wins the first ten minutes. On Linux you run one curl command to install, pull a model by name and talk to it. Memory and layer placement happen automatically. Running ollama ps afterward shows what loaded and where, with a processor column that reads 100% GPU when the whole model sits in video memory, 100% CPU when it sits in system memory, and a split such as 48%/52% CPU/GPU when it straddles both. That one table answers most of the why-is-it-slow questions.
llama.cpp asks for more up front. You choose a GGUF file, decide how many layers go to the GPU, set the context length, pick a cache type and start a server. In return you see every knob. For people who like to understand why a run is slow or why memory ran out, that visibility is the product. For people who just want an answer from a model, it is friction. The 1.0 release does not change that trade, but it does make the knobs safer to rely on.
Version control feels different too. Ollama’s Linux documentation describes pinning a version through an environment variable on the install script, which is handy for reproducible machines. llama.cpp users typically pin a release or a nightly build number. With 1.0 they can reason about compatibility using semantic versioning, which Ollama’s 0.x numbering does not promise.
Here is the typical first-run gap in practice. With Ollama, you install, run a model by name and start typing. With llama.cpp, you download a GGUF file, then start a server and open its local address in a browser or connect a client. The Ollama path is shorter by a few steps, and the llama.cpp path leaves you with explicit settings you can write into a script and reuse unchanged.
curl -fsSL https://ollama.com/install.sh | sh
ollama run <model>
ollama ps
llama-server -m ./model.gguf --port 8080 -c 8192
Both expose an HTTP API that most clients can talk to, so front ends such as Open WebUI work with either. The difference shows up in defaults. Ollama’s API stays on localhost unless you change it, and its context starts at 4096 tokens. The llama.cpp server does what the flags say, which is exactly right when you wrote the flags and a surprise when a colleague did.
Network exposure is where defaults matter most. If you want a second machine to reach Ollama, you set OLLAMA_HOST, using launchctl setenv on macOS or an Environment line in a systemd unit on Linux. Either way you are opening a service with no authentication of its own, so put a reverse proxy or a firewall rule in front of it. The same advice applies to a llama.cpp server bound to a public address. Nothing in either project makes an open port safe.
Real-World Examples: Who Runs What #
Nine concrete cases from the past few weeks show how the two tools get used. Each draws on official pages or dated reports.
- LM Studio shipping llama.cpp. LM Studio’s changelog lists runtime updates such as llama.cpp 2.50.0 (upstream b11337) and extension packs 2.66.0 and 2.67.0. A graphical app with its own business ships llama.cpp as the engine under the hood, which is the strongest evidence the project works as a component.
- Ollama borrowing llama.cpp for GGUF. Ollama 0.30 improved performance and GGUF compatibility through llama.cpp, bringing support to more models on a wider range of hardware. The two tools share a lineage on purpose.
- Agents on your own hardware. NVIDIA Nemotron 3.5 Lightning, a 30 billion parameter model with 3 billion active, is now available on Ollama and built for agents that stay running, gather context and call tools. The small active count suits a single workstation.
- Cloudflare’s Clef. The 27B multimodal decision model reached Ollama Cloud on October 19 and also runs locally. It shows the hybrid pattern: one model name, two places to run it.
- Gemma 4 on a Mac. Ollama 0.31 reported gains of up to 90 percent with coding agents on Apple silicon, measured on the Aider polyglot benchmark. AGoose coding assistant setup with local Ollama is the sort of workflow that benefits.
- Community quantizations. Community-published quantizations of DeepSeek-V4-Pro distillations give hobbyists a ladder of file sizes to pick from. Both tools can load the same GGUF.
- Teams hit by the free-plan change. Anyone who built on Ollama’s free cloud tier faced a decision after the November 11 reports. Teams with a llama.cpp fallback could keep running at $0 per token.
- Library embedders after 1.0. Developers linking llama.h now have a stable public API to target, and a short list of removed deprecated functions to clean up.
- Day-zero serving on vLLM. vLLM announced day-0 support for Qwen3.8-2.4T-A95B, a 2.4 trillion parameter hybrid MoE, and for both Flint checkpoints. Models at that scale sit outside both desktop tools’ comfort zone.
The pattern across these cases is consistent. Small and mid-size models on one machine suit Ollama or llama.cpp. Embedded use favors llama.cpp. Hybrid local and cloud favors Ollama. Anything near trillion-parameter scale or heavy concurrency moves to vLLM or a hosted service.
Use-Case Recommendations: Pick by Job #
The right runtime depends on the job, not on a general ranking. The table maps seven common situations to a pick and the reason.
| Situation | Pick | Why |
|---|---|---|
| First time running a model on a laptop | Ollama | One install, one command, automatic GPU and CPU placement |
| Shipping an app that embeds inference | llama.cpp | Stable public API since 1.0.0 and direct library access |
| Mac user running coding agents | Ollama | MLX engine and multi-token prediction gains on Apple silicon |
| Needing a new architecture on release week | llama.cpp | Upstream support lands first, wrappers follow |
| Model too large for your GPU | Ollama cloud tags or llama.cpp MoE expert cache | Hosted offload, or reported host-memory expert caching |
| Strict offline or no-recurring-fee setup | llama.cpp | No paid tier and no hosted product to depend on |
| Twenty people sharing one GPU server | vLLM | Built for high-throughput multi-user serving |
Coding agents deserve a closer look because they are the most common reason people install a local runtime. Agent frameworks such as OpenHands with a local Ollama endpoint expect an HTTP API, and both tools provide one. Ollama’s advantage is that its model naming makes switching quick. llama.cpp’s advantage is that you can tune the server for the long prompts agents generate, including the context length that Ollama’s 4096 default would otherwise cut off.
Editor integrations follow the same split. A guide to Kilo Code with Ollama in VS Code shows the point-and-click path. If your team prefers explicit configuration in version control, a llama.cpp server launched from a script fits that habit better, because every setting is a visible flag rather than a stored preference.
Privacy needs split the field too. Running locally keeps prompts on your machine with either tool. The caveat is Ollama’s cloud tags. A model name ending in cloud runs on hosted hardware, so a prompt sent to it leaves your machine. If your policy forbids that, enforce it by listing allowed model names or by running llama.cpp, which has no hosted path to misuse. The first is a policy, the second is a property of the software.
Migration Guide: Moving Between Ollama and llama.cpp #
Because both read GGUF, moving between them is mostly about locating the file and recreating your settings. None of the steps below deletes anything, so you can run both side by side while you test.
Ollama to llama.cpp
Start by finding the weights. Ollama stores models as content-addressed blobs, and its modelfile output points at the file. Then serve that file with llama-server and point your client at the new address. Choose your own context length, since you are leaving the 4096 default behind.
ollama show --modelfile <model>
llama-server -m /path/from/the/FROM/line --port 8080 -c 8192
Check three things after the switch. Confirm the chat template matches, since a wrong template makes a good model sound broken. Confirm GPU offload by watching memory use while you send a prompt. And pin the llama.cpp version in your deployment notes, using the 1.0.0 tag or a named nightly build.
llama.cpp to Ollama
The reverse is shorter. Write a Modelfile that points at your GGUF, create a named model, and run it. Set the context length in the Modelfile so you do not inherit the 4096 default by accident.
FROM ./model.gguf
PARAMETER num_ctx 8192
ollama create my-model -f Modelfile
ollama run my-model
How to benchmark both on your own machine
Since no published head-to-head exists, run your own. Use one GGUF file, one prompt set and one machine. With llama.cpp, the bundled llama-bench tool reports prompt processing and generation speed. With Ollama, the verbose flag prints evaluation rates after each reply. Record both, then repeat with your real context length and your real number of simultaneous requests.
llama-bench -m ./model.gguf -p 512 -n 128
ollama run my-model --verbose
Run each test three times and discard the first, since the first run pays the model-load cost. Keep the machine otherwise idle, because a browser tab can steal GPU memory. Write down the settings alongside the results so you can reproduce the run later. A benchmark you cannot repeat is a story, not a measurement.
Pros and Cons #
The two lists below stay within what the sources support. They describe trade-offs, not scores.
llama.cpp
- Pro: first stable release (v1.0.0, November 13, 2026) with semantic versioning for the public API.
- Pro: new architectures and features appear upstream first, and other tools inherit them.
- Pro: no paid tier, no hosted product, nothing to lose if terms change.
- Pro: fine control over context, cache and offload settings.
- Con: more setup and more decisions before the first reply.
- Con: no built-in model catalog or one-command pulls.
- Con: no hosted fallback when a model exceeds your hardware.
Ollama
- Pro: fastest path from install to first reply, with automatic placement across GPU and CPU.
- Pro: packaged model library plus cloud tags for models too large to run locally.
- Pro: MLX engine and multi-token prediction gains on Apple silicon.
- Pro: localhost-only default binding.
- Con: 4096-token default context catches new users out.
- Con: free cloud plan removed, with paid plans at $20, $100 and $500 per month.
- Con: pre-1.0 numbering offers no compatibility promise, and new architectures can arrive days after upstream.
Where vLLM and LM Studio Fit Beside Them #
Two other names come up in every thread on this topic, and each solves a different problem. vLLM is an open-source serving engine, not a desktop app. Its official page announces v0.33.0 with 927 commits from 389 contributors, PyTorch 2.14 and CUDA 12.9 dropped. The release is compatible with CUDA 13.x and needs Python 3.10 or newer, with 3.12 or newer recommended. A vLLM engineering post describes making the CUDA wheel LibTorch ABI stable after the DeepGEMM migration, so one wheel can work across compatible PyTorch releases.
The vLLM project also expanded beyond NVIDIA. Its roadmap describes a public TorchTPU launch in October 2026, and Ascend, Metal and Omni appear as related project areas. None of that matters for a laptop. All of it matters if you outgrow one box. The step from Ollama to vLLM is the step from a tool for one person to infrastructure for a team, with the learning curve that implies.
LM Studio is the graphical option. Its changelog reportedly puts the latest build at 0.4.28 Build 2 from October 31, and a Bionic agent product now sits beside it. It runs llama.cpp runtime packs, so the llama.cpp vs Ollama question partly resolves inside it. If you want a window with a model browser instead of a terminal, LM Studio is the third option, and its free tier costs $0.
For broader context on how open-weight models and their runtimes are evolving, the AI and machine learning coverage tracks the models these runtimes load. The practical advice stays simple: start with Ollama or LM Studio for the first week, learn what your workload needs, then move to llama.cpp for control or vLLM for scale.
Verdict: Which Runtime Wins by the Data #
There is no single winner, and the data explains why. Both tools run locally for $0. Both load the same GGUF files. Both share engine lineage through llama.cpp. The differences are packaging, defaults and what each project is trying to become.
Ollama wins for most individuals. It cuts the first-run steps, handles placement for you, adds a hosted escape hatch and has a clear Mac advantage through its MLX engine. If you are a developer wiring a model into a coding agent, it is the faster path. Its costs are a 4096-token default context to override, pre-1.0 versioning and a paid cloud tier with no free plan since November 11.
llama.cpp wins for builders and tinkerers. The v1.0.0 release on November 13 gives it the one thing it lacked: a stable public API. If you embed inference in an application, need new architectures first, want every setting explicit or refuse to depend on a vendor’s pricing page, it is the better foundation. It costs you setup time.
Neither wins for team serving. Past a handful of simultaneous users, the right comparison moves to vLLM and its data-center numbers, such as 1.7M tokens per second per GPU on one Vera Rubin NVL72 rack in the project’s own test.
Five questions settle the choice for most readers, and you can answer them in a minute:
- Do you ship code that links an inference library? Choose llama.cpp, and target the 1.0.0 API.
- Do you work on a Mac with coding agents? Start with Ollama, since its MLX engine and multi-token prediction work target that setup.
- Does your policy forbid prompts leaving the machine? Use llama.cpp, or lock Ollama down to local model names only.
- Do you need a model larger than your GPU holds? Compare Ollama’s cloud credits against a bigger machine, and price the Pro, Max and Team tiers honestly.
- Do many people share the box? Skip both and evaluate vLLM.
The takeaway: install Ollama to learn, keep llama.cpp 1.0 for anything you will ship or automate, and treat your own benchmark as the tiebreaker. A twenty-minute test on your hardware, your model and your context length beats any published chart. Watch two things over the coming weeks. One is whether Ollama’s next releases pick up the 1.0 changes quickly. The other is whether anyone publishes a controlled head-to-head, because those numbers still do not exist.
FAQ: llama.cpp vs Ollama #
Is llama.cpp faster than Ollama?
No controlled test published after llama.cpp 1.0 settles it. Ollama uses llama.cpp for GGUF compatibility, so raw speed on one model often comes down to settings such as context size, GPU offload and flash attention. A tuned llama.cpp command can edge out an untuned Ollama default. Measure both with llama-bench and the verbose flag on your own hardware.
Is Ollama still free?
Running models locally is free. Ollama’s hosted cloud is not. Reports from November 11, 2026 said the free cloud plan was removed, leaving Pro at $20 a month or $200 a year, Max at $100 a month and Team at $500 a month.
What did llama.cpp 1.0 change?
It released on November 13, 2026 as the project’s first stable version, with semantic versioning for the public API. Release coverage also reports removed deprecated APIs, speculative-decoding support in llama.h, OCP FP8 KV caches and a host-memory cache for mixture-of-experts experts.
Does Ollama use llama.cpp?
Partly. Ollama 0.30 improved GGUF compatibility through llama.cpp. On Apple silicon it also runs its own MLX engine, which is behind the Gemma 4 speedups announced with Ollama 0.31.
Can I use the same model file in both?
Yes, for GGUF files. Serve the file with llama-server, or write a Modelfile with a FROM line and run ollama create. Set the context length explicitly in both, because Ollama defaults to 4096 tokens.
Should a team use Ollama or llama.cpp for many users?
Neither is the usual choice once many people share one GPU. vLLM is built for high-throughput multi-user serving, and its own published results come from data-center racks and GPU clusters. Use Ollama or llama.cpp for one person or a very small group.
Which one should a beginner install first?
Ollama, or LM Studio if you prefer a window to a terminal. Both are quick to start, and both can later hand off to llama.cpp when you need control, since they all read the same GGUF files.