Qwen2.5 72B (local via Ollama) runs the 72B Qwen2.5 flagship entirely on your own hardware, and inside Atlas it is the configuration you choose when nothing may leave the machine. Pricing is Free (self-hosted): once the hardware exists, a long Atlas agent loop with dozens of tool calls costs nothing per token. The weights land at about 47 GB at Q4_K_M, which a 64 GB Mac Studio or a pair of 24 GB cards can hold. The native window is 128K tokens (131,072), commonly capped at 32,768 locally for KV cache reasons, and token throughput on consumer hardware will be a few tokens per second.
What is Qwen2.5 72B (local via Ollama) best at inside Atlas?
Qwen2.5 72B (local via Ollama) is best at fully air-gapped Atlas work in 2026. Nothing leaves the machine: Atlas can also embed the codebase index with OllamaEmbedder, so source and vectors both stay local, and the largest dense Qwen2.5 does the generating.
Atlas can build its code index with local Ollama embeddings, keeping code off third-party servers, and Qwen2.5 72B (local via Ollama) closes the other half of that loop. With the OllamaEmbedder handling vectors and the 72B checkpoint handling generation, no part of an Atlas session touches an external API: not the code, not the embeddings, not the prompts. That is the whole reason to accept the tradeoffs below. For a client repo under an NDA that forbids third-party processing, or a codebase on a network with no egress, this is the only Atlas configuration that qualifies. Atlas still does everything else it normally does, indexing code by AST declarations using tree-sitter rather than blind line windows, and computing a unified diff for every file edit before writing.
What does Qwen2.5 72B (local via Ollama) cost to run?
Qwen2.5 72B (local via Ollama) is Free (self-hosted). There is zero per-token cost, so long Atlas agent loops with dozens of tool calls are effectively free after hardware. The real bill is the machine: about 47 GB at Q4_K_M has to fit in memory before the first token is generated.
Zero per-token cost changes what kinds of Atlas sessions are rational. On a metered API, a fifty-turn agent loop that reads a lot of code and retries a few edits is a cost decision. With Qwen2.5 72B (local via Ollama), it is a time decision only. You can let Atlas fan out to subagents, replay large retrieved contexts, and iterate on a failing test without watching a meter. The counterweight is capital, not usage: about 47 GB at Q4_K_M means a 64 GB Mac Studio or a pair of 24 GB cards, and that hardware is the entire cost of the configuration. Run `atlas device` to confirm Atlas sees Ollama and a GPU before you assume the machine can carry it.
What hardware do I need for Qwen2.5 72B on Ollama?
Qwen2.5 72B (local via Ollama) needs about 47 GB at Q4_K_M, which means a 64 GB Mac Studio or a pair of 24 GB cards can run the largest dense Qwen2.5. Run `ollama pull qwen2.5:72b` (roughly 47 GB) and confirm it loads with `ollama run qwen2.5:72b`.
The memory floor is the gate. About 47 GB at Q4_K_M is not a laptop number, so the realistic targets are a 64 GB Mac Studio with unified memory, or a pair of 24 GB cards where the weights are split across both. Pull with `ollama pull qwen2.5:72b` and confirm the load with `ollama run qwen2.5:72b` before you touch atlas.json, because a model that will not load in Ollama will not load through Atlas either. Then run `atlas device` so Atlas reports whether it detected Ollama and a GPU. That command is the fastest way to catch the failure mode where the weights technically load but are running on CPU, which turns a slow configuration into an unusable one.
Why cap the context at 32,768 instead of 131,072?
Qwen2.5 72B (local via Ollama) has a native window of 128K tokens (131,072), commonly capped at 32,768 locally for KV cache reasons. You give up the 131,072 token window in practice, since a full KV cache at that length will not fit alongside the weights.
Weights and KV cache compete for the same memory. Once about 47 GB of Qwen2.5 72B weights are resident, the room left for a key-value cache is what determines your usable context, and a full 131,072 token cache does not fit alongside them on a 64 GB machine. That is why the documented Atlas configuration registers the model as `"qwen2.5:72b"` with `"limit": { "context": 32768, "output": 8192 }`. The 32,768 setting is not Ollama being conservative, it is arithmetic. Atlas compensates on the retrieval side: Atlas searches code with hybrid semantic and keyword retrieval fused by reciprocal rank fusion, so a smaller window filled with the right AST-chunked declarations beats a larger window filled with noise.
What are the tradeoffs of running Qwen2.5 72B locally?
Token throughput on consumer hardware will be a few tokens per second, which makes long agentic runs slow. Qwen2.5 72B (local via Ollama) trades speed for privacy and for a Free (self-hosted) price, and a developer who cannot tolerate that latency should not choose this configuration.
A few tokens per second is the number that decides whether Qwen2.5 72B (local via Ollama) fits your workflow. An Atlas build loop that would take two minutes against a hosted endpoint can take a long stretch of that same afternoon locally, because every tool result feeds back into another slow generation. The way to live with it is to change how you use the agent: lean on Atlas's plan agent, which drafts a plan in read-only mode and asks before switching to a build agent, so the slow tokens are spent on a plan you actually want rather than on a build you will throw away. The second tradeoff is the context cap of 32,768, and the third is that you own the hardware and the ops. In exchange, nothing leaves the machine and there is no per-token bill.
When should I pick a hosted model instead?
Pick a hosted model when throughput matters more than air-gapping. Qwen2.5 72B (local via Ollama) generates at a few tokens per second on consumer hardware and caps at 32,768 tokens of context in practice, so an Atlas session that needs speed or the full 131,072 window belongs on a hosted tier.
Atlas lets you switch the active model and provider on the fly with favorites and recents, which means the choice is not permanent. A sensible pattern is to keep Qwen2.5 72B (local via Ollama) registered as the offline fallback and switch to it only when the work is sensitive or the network is gone. When you are back on a normal repo with egress, the hosted tiers give you real throughput and the full context window without the memory arithmetic. The decision rule is simple: if the reason to run locally is compliance or an air gap, Qwen2.5 72B (local via Ollama) is correct despite the speed. If the reason is only saving money, weigh the few-tokens-per-second reality against the hours it costs you.
Setup
- 01Run `ollama pull qwen2.5:72b` (roughly 47 GB) and confirm it loads with `ollama run qwen2.5:72b`.
- 02Add an `ollama` custom provider block to atlas.json with `"npm": "@ai-sdk/openai-compatible"` and `"baseURL": "http://localhost:11434/v1"`.
- 03Register the model as `"qwen2.5:72b"` with `"limit": { "context": 32768, "output": 8192 }`.
- 04Set `"model": "ollama/qwen2.5:72b"` and run `atlas device` to confirm Atlas sees Ollama and a GPU.
- 05Verify the provider is live with `atlas models ollama`.
- 06Pair the setup with Atlas's OllamaEmbedder so the semantic index never leaves the machine.
Frequently asked questions
- how much vram do i need to run qwen2.5 72b locally
- Qwen2.5 72B is about 47 GB at Q4_K_M, so a 64 GB Mac Studio or a pair of 24 GB cards can hold it. Run `atlas device` to confirm Atlas sees Ollama and a GPU before starting a session.
- how do i run qwen2.5 72b with ollama and atlas
- Run `ollama pull qwen2.5:72b` (roughly 47 GB), add an `ollama` provider block to atlas.json with `"baseURL": "http://localhost:11434/v1"`, register `"qwen2.5:72b"`, then set `"model": "ollama/qwen2.5:72b"` and verify with `atlas models ollama`.
- how much does it cost to run qwen2.5 72b locally
- Qwen2.5 72B (local via Ollama) is Free (self-hosted). There is zero per-token cost after hardware, so a long Atlas agent loop with dozens of tool calls costs nothing to run.
- why is my local qwen2.5 72b context limited to 32768
- A full KV cache at 131,072 tokens will not fit alongside about 47 GB of Qwen2.5 72B weights, so the native 128K token (131,072) window is commonly capped at 32,768 locally. Register `"limit": { "context": 32768, "output": 8192 }` in atlas.json.
- is qwen2.5 72b on ollama fast enough for coding agents
- Token throughput on consumer hardware will be a few tokens per second, which makes long agentic runs slow. Qwen2.5 72B (local via Ollama) trades speed for a Free (self-hosted) price and full air-gapping.
- can atlas keep my code fully offline with a local model
- Yes. Atlas can build its code index with local Ollama embeddings, so pairing Qwen2.5 72B (local via Ollama) with the OllamaEmbedder means source and vectors both stay on the machine.
- what ollama command pulls qwen2.5 72b
- `ollama pull qwen2.5:72b` pulls roughly 47 GB. Confirm it loads with `ollama run qwen2.5:72b` before wiring it into atlas.json.
Try Atlas in your terminal
The terminal-native AI coding agent. Free core, single binary.
Install AtlasRelated guides
Self-Review Your Working Diff Before Committing with Atlas (2026 Workflow)
How to self-review your working diff before committing with Atlas in 2026: bash produces the diff, read checks each file, grep finds leftovers, session revert undoes bad edits.
Atlas for Dart in 2026
Adopt Atlas, the terminal-native AI coding agent, for Dart development in 2026. Enhance productivity with intelligent code search, refactoring, and robust safety features across your Dart projects.
Atlas for React in 2026
Adopt Atlas, the terminal-native AI coding agent, for React development in 2026. Enhance your workflow with intelligent code search, refactoring, and testing for React components and hooks.
Atlas vs Tabby: Terminal AI Coding Agents in 2026
Atlas and Tabby comparison for 2026. Atlas offers terminal-native TUI with permission-gated tools and diff review. Tabby provides self-hosted GPU completion and a cloud agent.
Atlas for Symfony in 2026
Atlas is a terminal-native AI coding agent for Symfony in 2026. It reads autowired services and Doctrine mappings, and shows migration SQL before anything runs.
Atlas for TypeScript in 2026
In 2026, TypeScript developers leverage Atlas, the terminal-native AI coding agent, to enhance productivity. Atlas understands your types, ensures code quality, and offers robust safety features.
Atlas vs Blackbox AI: Choosing Your AI Coding Agent in 2026
Comparing Atlas, the terminal-native AI coding agent, with Blackbox AI, a VS Code agent with 4.7 million installs, for developers in 2026. Evaluate features, pricing, and workflow.
Atlas for Angular in 2026
Adopt Atlas, the terminal-native AI coding agent, for your Angular projects in 2026. Enhance development with intelligent code search, secure local embeddings, and granular control over AI actions.