LOCAL AI // guia de engenharia
Arquiteturas ↗
Um manual prático para executar IA no seu próprio hardware

O Guia de IA Local
Engenharia Guia

Execute IA de nível avançado em um hardware que pertence a você.

2026 edição Prioridade local 4 views 15 sections

Four ways through this: the Guide is the full reference, the Walkthrough tells the build story start to finish, Motores is how to choose an inference engine.

New, and the most plain-English of all: a companion page of architecture blueprints, with a system diagram and an everyday-language explanation for every setup, from a single laptop to a home cluster.

Comece aqui em 60 segundos

Big AI usually runs in someone else's cloud. That costs money, can change or go down without warning, and means your data leaves your hands. This guide is about running it on your own computer instead: cheaper, private, and yours. The trade is that you set it up and look after it.

A ideia inteira em três passos:

  1. Run a model on your own machine with a free program (llama.cpp), on the computer you already have.
  2. Point your AI tool at it by changing one setting, so it uses your model instead of the cloud.
  3. Add more only when it hurts: speed, more users, big-codebase tricks, or safety, one piece at a time.

Everything below is the detail behind those three moves. Brand new? See the the guide or the architecture blueprints first.

00

A pilha completa em uma visão geral

De cima a baixo: do propósito ao silício
Em linguagem simples

This is the map of all the pieces and how they stack up. You do not need every layer. Most people use just the bottom few (a machine, an engine, a model) and add the higher ones only when they hit a wall.

Local AI engineering is more than installing a chat app. There is a full stack underneath, and this guide covers it top to bottom.

WhySovereignty, privacy, fixed cost, no rate limits, survives vendor rug-pulls
AgentsClaude Code / opencode / Droid / Kimi-CLI pointed at a local endpoint
HarnessRouting (DSPy / GEPA), context compilers (RLM), memory (MemAgent / Honcho)
ServingvLLM / llama.cpp / SGLang / ktransformers, under AIBrix on Kubernetes
ModelsOpen weights: Qwen, GLM, DeepSeek, Kimi, MiniMax, Gemma, Nemotron
CompressQuant (GGUF / AWQ / FP8 / NVFP4 / BitNet) + KV-cache compression (TurboQuant)
HardwareGB10 / Ryzen AI 395 / 4x A6000 / Apple Silicon / 7-year-old edge boxes
SafetySandboxing (Hyperlight / Firecracker), zero-trust install gates (Aegis)
01

Por que usar IA local

Os argumentos, com evidências

The case is not "local is smarter than Claude." It is "some reasoning should never hit someone else's API," plus hard economics. The subsidy is a trap: cheap cloud coding was venture-subsidized, and the bill is coming due.

$133k
Per month, extrapolated from one agent burning $14.06 in under 5 minutes ($3/min)
40x
Copilot repricing impact. "Your $19/seat became a $1,550 problem. 40x, not 40%."
$15k
Top monthly per-engineer cloud-agent spend already seen at startups
$0
Local marginal cost per token after capex. No surprise invoices, no telemetry.
  • The cloud is non-deterministic and silently degraded. A $43 experiment found output quality is "a sinusoidal wave of genius and gibberish" tied to load and time of day: aggressive quantization down to 2-bit, GPU spin-down, swapped system prompts. Local is "deterministically dumb" but predictable, and yours.
  • Vendor risk is real and sudden. Outages, 5-year data-retention changes, weekly rate limits, export-control suspensions of entire models. "The outage is temporary. The weights are forever."
  • The honest counter-frame. Local is about resilience and privacy, not beating the frontier on raw IQ. Run what you can locally, route only the genuinely hard, high-value, compressible problems out. Hybrid is also the only real cure for Shadow AI.
02

Hardware

As máquinas usadas na prática

A representative fleet runs from "sock drawer" to "space heater," all real machines under load.

RigSiliconMemoryRole
NVIDIA GB10 / ZGX NanoGrace-Blackwell, CUDA cap 12.1128GB unifiedDaily-driver agentic box. Palm-sized, 33 to 74W, runs DeepSeek V4 at 1M context.
HP Z8 Fury G5Xeon + 4x RTX A6000 48GB~192GB VRAM / 477GB RAMThe "beast." Throughput records, training, giant MoE. ~1.8kW, A6000s at 84 to 90C.
HP Z2 Mini G1aAMD Ryzen AI MAX+ PRO 395128GB unifiedThe AMD / ROCm side. Backpack "exocortex."
MacBook Air / ProApple Silicon M3 / M4 / M524 to 32GBThin SSH client; small models on Metal / MLX; WebGPU in-browser inference.
2018 ThinkPad X280i5-8350U, CPU only16GBExtreme-edge proof: Qwen3-8B at ~3.27 tok/s, ~16W on battery.
k8s cluster "Z14 Mecha"1x Z8 + 3x Z2 (NVIDIA + AMD)564GiB VRAMMixed-vendor Kubernetes, "datacenter in a closet."
  • Old hardware plus good engineering wins. "It is not the car, it is the driver." 5-year-old A6000s out-throughput SaaS APIs.
  • Force more VRAM on Ryzen AI 395. Rated 96GB, but a BIOS "edge AI server" mode plus Linux GTT / TTM tweaks unlock the full 128GB pool: Qwen3-Coder-30B BF16 at 1M context, 115GB footprint, 24.4 tok/s.
  • Watch thermals on Strix Halo. It hit thermal shutdown because thermald did not recognize the new CPUID; the fix was thermald --ignore-cpuid-check.
  • The network is the compute. One A6000 can be shared over LAN to a ThinkPad via a virtual GPU driver, tunneling CUDA over QUIC / TLS / UDP. DGX Spark is a learning toy, not production.
03

Inferência e disponibilização

Dois motores fazem 90% do trabalho
Em linguagem simples

An inference engine is the program that actually runs the model: it loads the weights, takes your request, and streams back the answer. The model is the engine block; this is the whole car around it. vLLM is the heavy-duty one built for many users at once. llama.cpp is the go-anywhere one that runs on almost any machine.

vLLM

The production serving engine. OpenAI plus Anthropic and Ollama-compatible routes, continuous batching, chunked prefill, prefix caching. Built from source for day-zero models.

llama.cpp

The ease-of-use and edge engine. GGUF, llama-server, runs on CUDA / Metal / ROCm / Vulkan. Source edited directly for KV and quant work.

SGLang

EAGLE speculative decoding, GLM tool and reasoning parsers. A serving path for specific models.

ktransformers

Hybrid VRAM + RAM offload for huge models. Ran Kimi K2 at 1T params locally this way.

AIBrix

k8s-native control plane: LLM-aware autoscaling, distributed KV-cache routing, high-density LoRA. A capable "enterprise AI platform."

shim fake-ollama

A Rust / axum proxy that makes Copilot, Cline, and Roo think they talk to Ollama while traffic hits vLLM / llama.cpp.

The drop-in pattern that recurs constantly: point any cloud-shaped coding agent at a local endpoint.

# Repoint any Anthropic-shaped agent at local weights
export ANTHROPIC_BASE_URL=http://localhost:8080 # llama.cpp
export ANTHROPIC_BASE_URL=http://localhost:8000 # vLLM
# Claude Code now "just works" against your own model

When an agent speaks only one dialect, shim it. Claude Code Router (ccr) translates Claude Code into OpenAI-compatible backends; fake-ollama covers the Ollama dialect. Serious setups avoid Ollama, preferring vLLM and llama.cpp for control.

The split that decides everything is prefill versus decode. Prefill reads the prompt and is compute-bound. Decode generates one token at a time and is memory-bandwidth-bound. Short prompt with a long answer leans on bandwidth and batching; long prompt with a short answer leans on attention kernels and chunked prefill. Match the engine to that shape, your interconnect, and your quant format.

Sua situaçãoUse
Notebook, edge ou hardware incomumllama.cpp
Fluxos centrados no MacMLX / MLX-LM
Inferência local em uma única RTXExLlamaV2
De 2 a 4 ou mais GPUs NVIDIA/CUDAExLlamaV3
Inferência geral em produçãovLLM
Contexto longo / MoE / roteamentoSGLang
Máximo desempenho em NVIDIATensorRT-LLM
Orquestração de clusterNVIDIA Dynamo

That is the one-page version. The Engines tab has the full engine-by-engine breakdown, the real bottlenecks, hardware-strategy recipes, and how to benchmark them honestly.

04

The open-weight model landscape

E como escolher
Em linguagem simples

These are the actual brains you can download and run, mostly free and open. The names change every few weeks, but the rule does not: pick the smallest one that does your job well, not the biggest one you can find.

Qwen3.x / 3.6

The hero family, 0.6B to 480B-A35B. Qwen3-Coder-Next (~80B / 3B active) is the default daily coder. "Qwen is the new Llama."

GLM-4.x / 5

Z.ai, MIT. "Opus at home." GLM-4.7-Flash is the "fast, good, and cheap" pick; topped tool-calling at a fraction of Opus cost.

DeepSeek V3.x / V4

"Soul of a Fortune-500 senior dev" for backends. V4-Flash: 284B / 13B active, 1M context, Sparse Attention ~9x cheaper.

Kimi K2.x

Moonshot, 1T / 32B active. Agent-swarm native, up to 300 parallel subagents.

MiniMax M2.x

~230B / 10B active. "Anthropic in a bottle," NVFP4-shrunk to fit a single GB10.

Gemma 4 / Nemotron

Google Apache-2.0 and NVIDIA Mamba-Transformer hybrids. Plus Ling / Ring, ERNIE, Hunyuan, LongCat.

  • Efficiency is the new scaling. Bigger is not better. A 27B dense or a 3B-active MoE on the Pareto frontier beats a 1T giant for most work.
  • Match the model to the language and job. DeepSeek for enterprise backends, not startup JS. Small and tiny models for narrow, repetitive agent tasks.
  • Public benchmarks rarely predict fit. Token efficiency, cost, and usability on your own tasks are better selection criteria.
  • MoE sparsity is the unlock. Huge total params, tiny active params per token, is what makes frontier behavior fit in consumer memory.

Judge it yourself: evals

The leaderboard is not your job
Em linguagem simples

A model topping a public leaderboard tells you almost nothing about whether it is good at your work. The fix is an eval: a small set of your own real tasks that you run every candidate model through, then keep whichever wins on those, not on the chart.

How to run a quick eval with no framework: collect 10 to 30 tasks you actually do (a real bug to fix, a function to write, a doc to summarize), each with the answer you would accept. Run every candidate model on all of them. Score pass or fail, or just A/B which output you would ship. Keep the winner on your set. That number beats every benchmark, because it is measured on the work you care about.

It cuts both ways, which is the whole point. Open models now sometimes beat the closed flagships on real-world evals (one open model recently passed a top closed model on a production web-framework eval), and sometimes they lose on yours. You only find out by testing on your own tasks. To score at scale you can use a strong model as the judge, but a human eye on 20 examples is usually enough to decide.

05

Compressão

Quantização e cache KV
Em linguagem simples

Models and their memory are huge, so you shrink them. Quantization stores the numbers with less precision, like saving a photo as a smaller JPEG: slightly less exact, but it fits and still looks fine. The KV cache is the model's short-term memory of the current conversation; compressing it is what lets a giant context fit on a small graphics card.

This is where local engineering gets hard and most of the wins live. Weight formats: GGUF (Q2_K to Q8_0), AWQ 4-bit, FP8, NVFP4 / MXFP4, and BitNet 1.58-bit ternary.

APEX

MoE-aware mixed precision on stock llama.cpp. Per-expert, per-layer bits beat Q8_0 and even F16 on perplexity at half the size.

BitNet distill

Convert FP LLMs to 1.58-bit ternary: ~10x memory savings, 2.65x faster CPU inference, near-FP16 accuracy.

Custom 2-bit

A custom DeepSeek-V4 GGUF (IQ2XXS-w2Q2K) is what makes a 284B model physically fit.

TurboQuant (Google's method, implemented in vLLM's Triton path) compresses KV cache to 2.5 to 3.5 bits per token via outlier handling, a Hadamard MSE transform, Lloyd clustering codebooks, and QJL 1-bit sign projection. This is what held 4.7M tokens of KV cache resident to hit 3,426 tok/s.

# vLLM with TurboQuant KV-cache compression
vllm serve /models/target \
  --tensor-parallel-size 4 --attention-backend TRITON_ATTN \
  --kv-cache-dtype turboquant35 --enable-turboquant \
  --turboquant-metadata-path /models/target/turboquant_kv.json
06

Engenharia de contexto

A habilidade mais importante
Em linguagem simples

Context is everything the model can see at once. Like a desk, it stops working when you pile too much on it. The trick is to quit dumping the whole codebase on the desk and instead let the model fetch only the few pages it needs, exactly when it needs them.

RLM

Recursive Language Models. Load a 32M-token codebase into a Python REPL variable; the root model writes code to walk it and spawns subagents that return distilled symbols, not text walls. 15% to 40% on long-horizon tasks, zero context rot.

MemAgent

Mega-context is a memory problem, not an attention problem. Chunk-wise RL over a fixed-token memory: 3.5M-token QA at under 5% loss, scaling linearly, on a base model with as little as 8K context.

Optical compression

The "JPEG moment." Render text as images for a VLM. DeepSeek-OCR: 97% decode at 10x compression. Glyph: 10k words to ~3k visual tokens.

Sparse attention

DeepSeek Sparse Attention drops 128K prefill from ~$0.70 to ~$0.10 per Mtok.

96.39%
Prefix-cache hit rate over a 6-hour local Claude Code session (46.3M prompt tokens, only ~1.3M actual prefill compute). Proof the cloud "unlimited" plan is a cache lottery, not physics.

An awk one-liner against vLLM /metrics proves it: prefix_cache_hits_total / prefix_cache_queries_total. The point: marginal cost is near zero, so the limits are pricing theater.

Beyond one session: local memory and retrieval

Context engineering handles a single conversation. For knowledge that should persist across sessions, build a private memory layer entirely on your own machine: local embeddings to index your notes and docs, plus a local re-ranker that re-sorts the top hits so the model sees the few best chunks, not the merely-similar ones. The re-ranker is the part most people skip, and it is what makes local retrieval feel sharp. None of it leaves your machine.

It is not just text

Local models do voice and vision too. Open multimodal models (Gemma-class) read images and run fully offline, and on-device speech models give you private dictation and transcription with no cloud. The same own-your-AI rules apply: pick a model that fits, serve it locally, keep the data on the machine.

07

Otimização de desempenho

Como tornar a inferência realmente rápida
Em linguagem simples

Throughput is how many words per second you get out. The surprise is that the limit is usually how fast the machine can move data around in memory, not how fast it can do math. So the real wins come from smarter shuffling and scheduling, not from a bigger graphics card.

  • Speculative decoding stacks. DFlash (block-diffusion drafting, ~6x speedup) plus DDTree (single-pass draft tree, tree-attention verification, lossless). Watch mean acceptance length in the logs.
  • MoE expert placement is HBM-bound (limited by how fast the card's memory moves data, not by its math). For 370 TPS from 4x A6000: pin the router thread to the nearest memory, re-tile the KV cache so live experts land on the fastest memory banks, and set queue depth to ~64 to hide latency.
  • Day / night daemon split. Interactive low-latency by day, async long-context bulk work by night, same hardware.
SetupResult
Qwen3.5-35B AWQ, 4x A6000, TurboQuant 3.53,426 tok/s at 1M context, 4.7M-token KV cache resident
MiniMax M2 BF16/FP8, 4x A6000, vLLM + AIBrix620 tok/s, 6,000 concurrent sessions at 100% success, ~1.8kW
GLM-4.7-Flash on a single GB10~1,470 tok/s peak gen, 195 concurrent, zero queue
Gemma-4 31B AWQ on ONE A6000129 concurrent subagents, 100% success
DeepSeek V4-Flash, 1M context, single GB1080 to 91 tok/s per agent
Gemma4 2.3B in a browser tab (WebGPU, MacBook Air)80 tok/s, 2GB RAM per tab, fully offline
Qwen3-8B on a 2018 i5 CPU3.27 tok/s at ~16W
08

Coding agents on local models

O ganho no uso diário

The pattern is always the same: take a cloud-shaped agent and repoint it at local weights.

Claude Code headless, no account opencode (32 concurrent) Factory Droid Kimi-CLI Cursor Cline Kilo Roo Mistral Vibe "16 systems on one GPU box"
Harness > model
In agentic coding, the harness and context engineering often matter more than the base model. Well-configured local swarms can be competitive with frontier models on legacy codebases.

Once the endpoint is yours, the interface is portable: any device that can hold a connection can act as a client, and a laptop can run the whole loop fully offline with a small local model.

09

Enxames e orquestração

Em escala, o trabalho passa a ser coordenar
Em linguagem simples

A swarm is just many copies of the agent working at the same time, turning one worker into a whole crew. The hard part is no longer the work itself, it is handing out jobs and keeping the workers from stepping on each other.

At 10,000+ agents and a 35:1 AI-to-human ratio, there is no human UI; the backlog is the HUD.

  • Swarms. Spawn, execute, report, die. Self-orchestrating swarms cut an OpenClaw deep-sweep from 3.5 hours and 19M tokens to ~10 minutes with 90% identical results.
  • Isolation. Git-worktree per agent, or AgentFS (a SQLite .db holding files plus state plus tool_calls, so cp agent.db snapshot.db is time travel and you can SQL-query agent behavior).
  • Legacy code is a graph, not a document corpus. A tool like dede exposes a Roslyn dependency graph as a skill so agents query blast radius instead of RAG-chunking across 40 repos.
  • Headless loop. systemd timers plus flock plus Radicle issue labels as a state machine. Offline-first, human-merge-at-the-end.
10

Segurança e confiança zero

O modelo escreve, o sistema restringe e o sandbox contém
Em linguagem simples

Once an agent can run commands, treat it like a new intern: helpful, but you would not hand it every key on day one. The setup here lets it suggest actions while a checker approves them and a sealed room contains any mistakes.

Hyperlight

CNCF, Rust. Hardware-isolated micro VMs that spawn in ~1ms with microsecond guest calls and snapshot / restore, so a hallucinated rm -rf rewinds in microseconds.

Firecracker + AgentFS

microVM isolation for agents, formally verified with Quint.

Aegis

A zero-trust install gate. Ed25519-signed execution plans, SHA-256 hash-chained audit logs, AI architecturally incapable of escalation: never gets root, never generates argv, enforced via std::process::Command with no shell.

Supply-chain hygiene

Pin every artifact to a SHA-256, disable npm lifecycle scripts, generate an SBOM, sign with cosign, gate with Trivy and semgrep. "Can your stack survive pip install?"

11

Self-improvement & local training

Treine na mesma máquina
Em linguagem simples

You can also make a model better on your own machine, not just use it. The cheapest trick is to let it learn from its own best answers. You do not need a data center to get a real improvement.

Self-distillation

Apple SSD: SFT on the model's own unverified outputs, no RL, verifier, teacher, or execution. Qwen3-30B went 42.4% to 55.3% pass@1 on LiveCodeBench, +30% relative.

GEPA + DSPy

Genetic-Pareto prompt and skill optimization converges in ~50 iterations vs 5,000 brute-force, auto-harvesting high-success sessions.

Tiny recursive models

TRM (7M params, recursive self-calls) hits 45% ARC-AGI-1, beating models thousands of times larger. RSA lifts Qwen3-4B +29.9 on AIME with no verifiers.

From-scratch training

nanochat end to end on 4x A6000. Rust borrow-checker RL loops (prompt, cargo check, reward) hit 71.8% compile rate in a non-root sandbox.

Close the loop

The cheapest self-improvement: give the agent a way to verify its own output (tests, a compiler, a checker), then loop. It drafts, checks, and fixes until it passes. This is how teams run swarms of self-improving agents, no training required.

Open post-training

The RL stacks behind the big open models are themselves open. One of them post-trained a frontier-class model in about two days. You can use the same tools to post-train your own model on your own data.

12

Casos de uso relacionados

Que comprovam a ideia
  • Reverse engineering, fully local. Ghidra plus a local agent at 80 tok/s decompiled a 6.9MB binary in 110 seconds (9,426 functions, 250+ Windows APIs, 7 auto-generated docs). "Three weeks of RE engineers becomes a Sunday morning."
  • Private OCR. GLM-OCR (0.9B) beats Gemini and GPT on doc parsing while running on vLLM.
  • Privacy as capability. Local Qwen3.5-35B did text deanonymization at ~90% precision, the point being your writing style is a biometric, so it should never leave your machine. The same approach reverse-engineered an air fryer's API with a local model and mitmproxy.
  • Real-time / OT edge AI. CASA: 100Hz perception, 10Hz decision, sub-10ms action, with Decision Contracts (TTL, multi-model consensus, a classical Z-score sanity check, SHA-256 audit ledger). "An agent should be a PID controller, not a philosophy major writing a dissertation."
The killer use case: always-on, ambient agents

This is the thing only local can do. Because a local model is unlimited and has no per-call bill or rate limit, you can leave agents running around the clock. People run continuous security scans over their own codebase, watch a database for anomalies, and scrape the web every twenty minutes for opportunities, all 24/7. On cloud APIs that would cost more than the hardware; on local it is just electricity. A fleet of tireless workers that never sleeps, only possible when the model is yours.

Use it from anywhere, privately (the mesh trick)

Put a private mesh (Tailscale) across all your machines and your phone, and any device can use a model running on your home box from anywhere in the world, encrypted, never touching the public internet. Pair it with an orchestrator agent (Hermes or OpenClaw) that loads models and routes work across your machines for you, like an IT person you talk to in plain English. That is how a pile of computers becomes one personal AI cloud you own.

13

Produção em escala

Hiperescala em casa

k8s + AIBrix

The control plane. LLM-aware autoscaling on gpu_cache_usage_perc, distributed KV cache, KubeRay, high-density LoRA.

HA for a team

2x Ubuntu + MicroK8s, etcd on DRBD, Pacemaker VIP, LINSTOR, MetalLB, ArgoCD canary. Failover under 60s, serving Qwen3-Coder-30B at ~90 tok/s.

AI Coding Factory

Definition of Done as build gates: block merges below 85% coverage, security agent rejects vulnerable PRs. "Treat AI like an engineering org."

14 / The economics

O custo é dominado pelo cache, not compute

Which is why flat plans get rate-limited (at-scale swarms melt vendor infra) and why "unlimited" is psychological anchoring. The marginal cost of a local token is effectively zero after the capex.

88.7%
Of single-turn queries are answerable locally (Stanford intelligence-per-watt study)
80.4%
Energy cut from hybrid local-plus-cloud routing; 73.8% compute-cost cut
45%
Cost cut even from a merely 60%-accurate local router
15

The starting playbook

Do zero à IA local em oito passos
Pick a box you already own. A MacBook Air, a gaming GPU, even an old ThinkPad. "There is no perfect guide. You just start."
Install llama.cpp, pull a GGUF (start with Qwen3-Coder-30B or GLM-4.7-Flash), run llama-server.
Point your existing agent at it. Set ANTHROPIC_BASE_URL to localhost and run Claude Code, or use Claude Code Router / fake-ollama for other tools.
Graduate to vLLM when you need throughput and concurrency; add prefix caching and a KV-cache quant.
Add context engineering (RLM for big repos, a dependency graph as a skill) before reaching for a bigger model.
Sandbox the agent (Firecracker / Hyperlight) and gate installs (the Aegis pattern) the moment it can write to disk.
Scale out with AIBrix on k8s only when one box is genuinely the bottleneck.
Keep it hybrid. Run 90% local, route the rare hard problem out, and keep a contingency for the day a vendor returns budget_exceeded.

Go deeper: build it from first principles

Para quando você quiser entender, não apenas usar
Em linguagem simples

The rest of this guide is about using local AI well. This part is for the curious: actually building the thing, so the rules stop being magic. The goal is to build, fine-tune, and ship a tiny model, not to study theory forever.

A no-fluff path from "what is a token" to "I trained a mini-GPT," in five phases. Skip what you know, rewatch what loses you.

Phase 0, foundations. Just enough matrix math and Python to not be scared of it. No five-year detour.
Phase 1, an autograd engine from scratch. Build the tiny thing that does backpropagation, so training stops being a black box.
Phase 2, a mini-GPT from scratch. Tokenizer, embeddings, attention, a transformer block, sampling. Hand-wire it once.
Phase 3, fine-tune for real. Implement LoRA and fine-tune a small model on real data you care about.
Phase 4, make it efficient and ship it. KV cache, FlashAttention, quantization, a simple serving loop. Now it is usable.

Two free companions: a 214-page training playbook that walks the whole pipeline (pre-training, mid-training, post-training, tokenization, data, infra, and the real-world gotchas), and a single ~8000-line open-source project (nanochat) that goes end to end: train the tokenizer, pretrain, mid-train on conversations, supervised fine-tune, optionally reinforcement-learn, then serve it with a KV cache and chat with it. Read the playbook, build the project.

16

Glossário em linguagem simples

Cada termo técnico explicado em uma linha
Token
A chunk of text, roughly a word or piece of one. Models read and write in tokens, and you pay by the token.
Inferência
The model actually running to turn your request into an answer. "Serving" inference means doing this for many requests at once.
Prefill e geração
Two phases of a request. Prefill is the model reading your prompt; decode is it writing the reply one word at a time.
Janela de contexto
How much text the model can see at once. Like a desk, it stops working well when you pile too much onto it.
Cache KV
The model's short-term memory of the current conversation. It grows with the context and eats graphics-card memory fast.
Cache de prefixo
Reusing the work already done on text the model has seen before, so repeated context is almost free. This is where most cloud cost hides.
Quantização
Storing the model's numbers with less precision to shrink it, like saving a photo as a smaller JPEG. Slightly less exact, but it fits.
GGUF, AWQ, FP8, NVFP4
File formats for those shrunk models. You just need one your engine has been tuned for; they are not interchangeable.
Mistura de especialistas (MoE)
A huge model that only switches on a small, relevant slice of itself for each word, so it runs fast despite its size.
Parâmetros ativos versus totais
The model is enormous on paper (total), but only a small part fires per word (active). Active is what decides speed and memory.
Decodificação especulativa
Guess several words cheaply, then check them all in one pass. When the guesses are right, you get a big speed-up for free.
RAG
The older approach: search for relevant snippets and paste them into the prompt. Good for documents, clumsy for whole codebases.
RLM (recursive language model)
Instead of reading everything, the model writes a little program to look things up and gets back just the answer. No clogged window.
vLLM and llama.cpp
The two main programs that run and serve a model. vLLM is heavy-duty for many users; llama.cpp runs almost anywhere.
Vazão e latência
Throughput is words per second across everyone. Latency is how long before the first word shows up. You tune for one or the other.
Interconexão
The wiring between graphics cards (NVLink, PCIe, the network). When it is slow, it, not the chips, becomes the real bottleneck.
Sandbox
A sealed, throwaway room where an agent can act without touching your real machine. A bad command rewinds instead of doing harm.
Local primeiro / híbrido
Run almost everything on your own hardware and send only the rare hard problem to the cloud. Most of the savings, with a safety valve.
QAT (quantization-aware training)
A model trained to be shrunk, instead of shrunk after the fact. It keeps more quality at small sizes, so QAT versions (like Gemma's) run great on tiny memory. Prefer a QAT build when you see one.
Harness vs model vs serving
Three different things people mix up. The harness is the app that calls the model (Claude Code, Cowork). Serving is the engine that runs it (vLLM, MLX). The model is just the weights. Most "it's broken" problems are actually the harness.
Avaliação
A small set of your own real tasks, with the answers you would accept, that you run each model through to pick a winner. The only score that reflects your work, unlike a public leaderboard.
Offload (run bigger than your VRAM)
Keep most of the model in ordinary system RAM and only the active part on the GPU. It lets a small box touch much bigger models. The catch: system RAM is slower, so it becomes the bottleneck. Works especially well for mixture-of-experts (offload the idle experts). Tools: llama.cpp partial offload, KTransformers.
Private mesh (Tailscale)
A private, encrypted network across all your devices and your phone, so any of them can reach a model running on your home machine from anywhere, without going over the public internet. Turns a pile of computers into one personal AI cloud you own.
Agentes ambientes
Agents left running 24/7 because local has no per-call bill or rate limit: continuous security scans, anomaly watching, opportunity scraping. The use case cloud cannot match on cost.
17

Perguntas frequentes

O que as pessoas realmente perguntam
Preciso de uma GPU cara?
No. Start on the computer you already have. A model runs on a normal laptop, just slower. You only buy hardware once you have outgrown what you own.
Um modelo local é tão bom quanto ChatGPT ou Claude?
For most everyday coding and writing, the good open models are close enough. For the very hardest problems the big clouds still lead, which is why "mostly local, cloud for the rare hard one" is the sweet spot.
É difícil configurar?
The first model runs in a few minutes with one free program. The advanced parts (serving, scaling, sandboxing) are optional and you add them only when you actually need them.
É gratuito?
The software and the models are free. You pay in electricity and your own time, plus hardware if you scale up. There is no per-use bill and no surprise invoice.
É privado e seguro?
Yes, that is the whole point: nothing leaves your machine. If you let an agent run commands, put it in a sandbox first, a sealed room where any mistake can be undone.
Minha configuração ficará desatualizada?
Model names change constantly, but the method does not. Swapping in a newer model is usually a one-line change, so you keep up without rebuilding anything.
Quando devo ir além do notebook?
When more than one person or tool needs the model, or it feels too slow. Then add a dedicated box, and only later a cluster. Grow one step at a time.
E se eu ainda precisar de um modelo de fronteira às vezes?
Keep a cloud key as a backup and route only the rare hard problem to it. You get local cost and privacy by default, with full power on call.
Interativo

Eu consigo executar?

Escolha seu hardware e um modelo. A calculadora informa se ele cabe na memória, qual será a velocidade aproximada e quanto espaço restará. A capacidade determina o que cabe; a largura de banda determina a velocidade.

Sua configuração

O modelo

Defina os valores
0 GB
pesos do modelo
0 GB
cache KV neste contexto (estimativa)
0 GB
memória total necessária
0
palavras estimadas por segundo
memória utilizada0 / 64 GB

These are deliberately simple estimates to set expectations, not a benchmark. Weights are exact; KV cache and speed are rough (real numbers depend on the exact model, attention design, KV quantization, prompt length, and whether you run MLX, llama.cpp, vLLM, or SGLang). Decode speed assumes you are memory-bandwidth bound, which is true for almost all local single-stream use.

A construção completa, em ordem

O Passo a Passo

How you actually go from a cloud subscription to a sovereign AI operation on hardware you own. Read top to bottom. Weighted toward the most recent learnings, because this field reinvents itself every few weeks.

00

The reckoning: why you start at all

Recent framing, 2026

Before any hardware, the decision is economic and political. Through 2026 the story sharpened. The cheap era of cloud coding was venture money buying market share, and the repricing has arrived: usage-based billing, model multipliers, weekly caps that let you "code 30 minutes then wait 4.5 hours." One metered agent burned roughly $14 in under five minutes, which annualizes past $130,000. Put bluntly: your $19 seat became a $1,550 problem, 40x not 40 percent.

The second realization is quieter and more damning. Cloud output is not stable. A controlled experiment found quality moving in "a sinusoidal wave of genius and gibberish" tied to load and time of day, consistent with silent quantization, GPU spin-down, and swapped system prompts behind the curtain. Locally you get a model that is "deterministically dumb" but never changes underneath you.

Then came the events that turned a preference into a thesis. Multi-hour outages. Five-year data-retention changes. Whole frontier models suspended overnight by export directives. Each one made the same point. If your workflow depends on one vendor's API, you can be wrecked by a decision you did not make and cannot appeal.

One honest caveat worth repeating: this is not a claim that local beats Claude on raw intelligence. It is resilience and privacy engineering. The endgame is hybrid. Run almost everything locally, route only the rare, hard, compressible problem out. That posture also happens to be the only real cure for Shadow AI, because the way to stop people pasting secrets into a chat box is to give them something local that is faster and better.

01

Escolhendo o hardware

Recent: GB10 era

You do not need a datacenter. The most-used machine in 2026 is the NVIDIA GB10, a Grace-Blackwell box with 128GB of unified memory that fits in a sock drawer and sips 33 to 74 watts, yet runs DeepSeek V4 at a million tokens of context. The lesson it keeps proving is that unified memory plus a modern interconnect beats raw VRAM bragging rights for agentic work.

If you want throughput, the other end of the fleet is an HP Z8 Fury with four RTX A6000 cards, around 192GB of VRAM. Critically, those A6000s are five years old. "It is not the car, it is the driver." Good engineering on vintage Ampere out-throughputs SaaS APIs, and it is worth real effort backporting new models onto unsupported old silicon rather than buying the latest card.

The value pick is AMD. The Ryzen AI MAX+ PRO 395 (Strix Halo) ships with 128GB of unified memory. A recent and very actionable hack: it is rated for 96GB of GPU memory, but a BIOS "edge AI server" mode plus Linux GTT and TTM tweaks unlock the full 128GB, enough to hold Qwen3-Coder-30B in BF16 at a million-token context with a 115GB footprint. Watch the thermals, the chip is new enough that the thermal daemon did not recognize its CPUID and triggered a shutdown until you pass thermald --ignore-cpuid-check.

Two ideas worth internalizing early. First, the network can be the compute: a single A6000 can be shared across the LAN to a thin laptop by tunneling CUDA over QUIC. Second, the floor is absurdly low. A coding agent runs on a 2018 ThinkPad i5 at three tokens a second on battery. You can start with what is on your desk today.

02

First light: one model, one command

The 10-minute on-ramp

The fastest path to a working local model is llama.cpp. Install it, pull a GGUF (a good first pick is Qwen3-Coder-30B or GLM-4.7-Flash), and start llama-server. You now have an OpenAI-shaped endpoint on localhost.

The move that makes it click is the drop-in. Almost every coding agent reads a base-URL environment variable, so you point the cloud tool at your own server and it simply works.

export ANTHROPIC_BASE_URL=http://localhost:8080 # llama.cpp
# launch Claude Code. It is now talking to your model, no account.

When a tool only speaks one dialect, you shim it. There is fake-ollama, a tiny Rust proxy that answers the Ollama API so VS Code Copilot, Cline, and Roo think they are talking to Ollama while the traffic actually hits your real engine. Claude Code Router does the same translation for Claude Code into OpenAI-style backends. The pattern generalizes: the agent is just a client, and you own the server it points at.

Serious setups deliberately avoid Ollama and prefer llama.cpp and vLLM, because the whole point is control over batching, caching, and quantization, not a friendly wrapper that hides them.

03

Picking your models in 2026

Recent: the open-weight flood

The biggest shift of the year is that open weights, mostly from Chinese labs, caught the frontier. The framing: the era of the cloud-only frontier is over, the frontier is on your desk. The families worth running are Qwen (the hero, from 0.6B to 480B, with Qwen3-Coder-Next as the daily driver), GLM from Z.ai (the "Opus at home" line, with GLM-4.7-Flash as the fast-good-cheap pick), DeepSeek (the backend specialist, "the soul of a Fortune-500 senior dev"), Kimi K2 (swarm-native at a trillion params), MiniMax M2 (the "Anthropic in a bottle" coder), and Gemma plus Nemotron for the smaller and hybrid-architecture end.

The selection rules are consistent and contrarian. Efficiency is the new scaling, bigger is not better. A 27B dense model or a 3B-active mixture-of-experts on the Pareto frontier beats a trillion-param giant for almost all work, and the receipts back it: local coder swarms have been reported outperforming frontier models on some legacy codebases. Public benchmarks rarely predict fit; token efficiency, cost, and usability on your own tasks are better selection criteria. And match the model to the job: DeepSeek for enterprise Java and C#, small models for narrow repetitive agent tasks, not one model for everything.

The architectural through-line is sparsity. Mixture-of-experts with huge total params but tiny active params per token is exactly what makes frontier behavior fit in consumer memory. When you read a spec, the number that matters is active parameters, not total.

04

Uso avançado do vLLM

When one user becomes many

llama.cpp gets you running. vLLM gets you fast and concurrent. It is the production serving engine, exposing OpenAI, Anthropic, and Ollama-compatible routes at once, with continuous batching, chunked prefill, and prefix caching. For new models you build it from source against nightly PyTorch to get day-zero support, and there are patches to run frontier models on unsupported older GPUs.

The single most important thing vLLM reveals is where the cost actually lives. Over a six-hour local coding session, a 96 percent prefix-cache hit rate was measured: of 46 million prompt tokens, only about 1.3 million were real prefill compute. Everything else was served from cache. The implication is that agentic coding cost is dominated by prefix cache (reused work on text the model has already seen), not generation, which is exactly why cloud flat plans get rate-limited and why "unlimited" is pricing theater rather than physics.

Practical defaults that recur in real configs: enable prefix caching, set a generous batched-token budget, tune max sequences to your concurrency, and pick an attention backend that supports your KV-cache quant. Then watch the metrics endpoint, the hit-rate and KV-utilization numbers tell you whether you are bottlenecked on cache, memory, or compute long before you guess.

05

A técnica da compressão

Recent: the KV cache

This is where local engineering gets hard and where most of the wins are. Two layers compress: the weights and the KV cache. For weights the formats are GGUF, AWQ, FP8, NVFP4, and at the extreme BitNet 1.58-bit ternary, which gives roughly 10x memory savings and near-FP16 accuracy after a distillation warm-up. APEX is a recent favorite: mixture-of-experts-aware mixed precision on stock llama.cpp that beats Q8 and even F16 on perplexity at half the size by spending bits per expert and per layer.

But the recent obsession, and the bigger lever, is the KV cache. The battle is memory bandwidth, not FLOPs. Google's TurboQuant, implemented inside vLLM's Triton path, compresses the cache to two-and-a-half or three-and-a-half bits per token, using outlier handling, a Hadamard transform, clustering codebooks, and a one-bit sign projection. That is what lets a rig hold 4.7 million tokens of KV cache resident in GPU memory and hit 3,426 tokens per second on those vintage A6000s.

vllm serve /models/target \
  --attention-backend TRITON_ATTN \
  --kv-cache-dtype turboquant35 --enable-turboquant

For the truly large models, pushing the compressed cache to disk is how a 284B DeepSeek V4 runs at a million-token context on a single palm-sized box. The mental model to adopt: context tokens are now compute and storage you manage, not a free buffer you fill.

06

O desafio do contexto

Recent: the big idea

Everything above is plumbing. This is the skill that separates a toy from a system. The core insight, repeated all year and the most shared: stop stuffing the context window, give the model an environment instead. Dense-task performance falls off a cliff after roughly sixteen thousand tokens, so a million-token window is not the answer, it is the trap.

The primary weapon is the Recursive Language Model. Load a 32-million-token codebase into a Python REPL variable. The root model never sees the flood. It writes code to grep, slice, and walk the repo, and spawns sub-agents that return distilled symbols and variables, not walls of text. The result is no context rot and a jump from 15 to 40 percent on long-horizon tasks. The framing: RAG asked what is in the document, RLM asks what you can make the document do.

Two complements matter. MemAgent treats huge context as a memory-management problem, not an attention problem: chunk-wise reinforcement learning over a fixed-token memory delivers 3.5 million-token recall at under five percent loss, scaling linearly, even on a base model with an 8K window. And the "JPEG moment," rendering text as images for a vision model: DeepSeek-OCR decodes at 97 percent accuracy with tenfold compression, and Glyph turns ten thousand words into about three thousand visual tokens.

For codebases specifically, the recent reframe is that code is a graph, not a document corpus. A tool like dede exposes a real dependency graph as a skill so the agent queries blast radius ("what breaks if I change this endpoint") instead of RAG-chunking blindly across forty repos. Navigation beats retrieval.

07

Wiring your coding agents

The daily payoff

With a fast local endpoint and real context engineering, the everyday loop is simple: take whatever agent you already like and repoint it. It is normal to run sixteen different AI dev systems against one GPU workstation. Claude Code headless with no account is the main harness, opencode when you want higher concurrency (32 parallel versus Claude Code's three on the same GPU), plus Droid, Kimi-CLI, Cursor, Cline, Kilo, Roo, and Mistral Vibe, all pointed at localhost.

Token cost is worth comparing here. The GitHub MCP server costs roughly 54,000 tokens just to load its spec before any call. The equivalent CLI help is 562 tokens and already sits in the model's training data. Skills cost 30 to 50 tokens until triggered. For agents, command-line tools plus progressively-disclosed skills are often cheaper, faster, and easier to debug than MCP servers.

The other recent theme is "everything everywhere": once the endpoint is yours, the client is portable. Any device that can open a connection can become a client, including fully offline laptops. The point is that owning the server frees the interface.

08

Adotando múltiplos agentes

Recent: shepherding, not coding

The jump from one agent to a swarm changes your job from writing code to shepherding processes. At ten thousand agents and a 35-to-1 AI-to-human ratio, the recurring lesson is that beyond a point there is no human UI at all, the backlog becomes the interface.

The pattern is spawn, execute, report, die. Self-orchestrating swarms that decide their own termination cut a deep codebase sweep from three and a half hours and nineteen million tokens to about ten minutes with ninety percent identical results. For isolation, the move is from git worktrees to AgentFS, where an entire agent runtime, files plus state plus tool calls, lives in a single SQLite file. That means cp agent.db snapshot.db is time travel and you can run SQL queries over what your agents actually did.

At the top sits the orchestration loop, and the recent production shape is deliberately boring and offline-first: headless agents driven by systemd timers and file locks, with a decentralized issue queue (Radicle) acting as the state machine. A ticket labeled approved and queued gets locked, worked, patched, and marked done, and a human merges at the end. The queue is the HUD, coordination is the bottleneck, generation is not.

09

Protegendo o sistema

Recent: model writes, harness restricts

An agent that can write to disk is, put plainly, a junior developer with API keys and ambition. The division of labor is strict: the probabilistic model only suggests, deterministic code decides and enforces. The moment your agent can act, you sandbox and gate it.

For isolation, reach for Hyperlight, a Rust micro-VM that spawns hardware isolation in about a millisecond with microsecond guest calls and snapshot-restore, so a hallucinated destructive command rewinds in microseconds. Firecracker with AgentFS is the heavier option, formally verified. For installs and shell actions, Aegis is a zero-trust gate where every execution plan is Ed25519-signed and logged into a hash-chained, tamper-evident ledger, and the AI is architecturally incapable of escalation: it never gets root, never generates the argument vector, and is enforced through a no-shell process API. By default sudo, curl-pipe-bash, and unplanned package installs are forbidden.

The recent supply-chain thread, sharpened after a real poisoning incident, extends this to dependencies: pin every artifact to a hash, disable package lifecycle scripts, generate a software bill of materials, sign images, and gate with scanners. A practical test: whether your stack can survive a compromised pip install. Some setups go further and decentralize the control plane itself, using tools like Radicle and IPFS over a private mesh.

10

Aumentando a velocidade

Recent: HBM, not FLOPs

Once it works and is safe, you tune. The recurring discovery is that local serving speed is bound by memory bandwidth and expert routing, not raw compute. To pull 370 tokens per second from four A6000s, pin the router thread to a NUMA node (the memory bank physically closest to that processor), re-tile the KV cache so the live experts land on the fastest memory banks, set queue depth around 64 to hide latency, and trim per-client rope scaling (the math that lets a model stretch to longer text). None of that is "buy a bigger GPU."

On the algorithm side, stack speculative decoding (guess several words cheaply, then verify them all in one pass): DFlash drafts a whole block with one diffusion pass for roughly a sixfold speedup, and DDTree verifies a draft tree with tree attention while staying lossless. A recent fifty-line trick worth knowing is DeepConf, which prunes reasoning rollouts by the model's own token confidence and early-stops weak chains, hitting near-perfect AIME accuracy with up to 85 percent fewer tokens and no training at all.

The numbers that result are the proof of the whole discipline: 3,426 tokens per second at a million-token context on vintage cards, 620 tokens per second with six thousand concurrent sessions on one box, a million-token DeepSeek model at 80 to 91 tokens per second on a palm-sized machine, and a 2.3B model running in a browser tab at 80 tokens per second, fully offline.

11

Teaching it to improve itself

Recent: training on the same desk

The last layer is that you can train and improve models on the same hardware you serve from, and the recent methods make it cheap. Self-distillation is the standout: a model fine-tuned on its own unverified outputs, with no reinforcement learning, verifier, or teacher, moved a 30B model from 42 to 55 percent pass-rate on a coding benchmark, a thirty percent relative gain for almost nothing.

For prompts and skills, use DSPy with GEPA, a genetic-Pareto optimizer that converges in about fifty iterations versus thousands of brute-force trials and auto-harvests your high-success sessions as training signal. The recurring surprise from recent research is that tiny recursive models punch absurdly high: a seven-million-parameter recursive network beats models thousands of times larger on abstract reasoning, and recursive self-aggregation lifts a 4B model by thirty points on hard math with no verifier.

You can even train from scratch on the desk (nanochat on four A6000s) and run reinforcement loops where a model writes Rust and the compiler is the reward function, hitting a 72 percent compile rate inside a non-root sandbox. The point is not that you should pretrain a frontier model at home. It is that post-training, distillation, and merging are now things you own, which closes the loop on sovereignty.

12

Escalando além de uma máquina

Hiperescala em casa

When a single machine is genuinely the bottleneck, you reach for Kubernetes and AIBrix, the preferred control plane, which adds LLM-aware autoscaling on cache utilization, distributed KV-cache routing, and high-density adapter management on top of vLLM. A mixed-vendor home cluster runs NVIDIA and AMD nodes side by side, scheduled together.

For a small team there is a full high-availability recipe: two nodes with MicroK8s, replicated etcd, a floating virtual IP managed by Pacemaker, mirrored storage, and canary deploys, with failover under a minute, serving a coding model at around ninety tokens per second. And the governance layer is treated as code: the definition of done becomes build gates, where a coverage threshold blocks merges and a security agent rejects vulnerable pull requests. The recurring guidance: treat the swarm like an engineering organization with policy, determinism, and audit, not an assistant.

13

Para onde isso está indo

Recent: the frontier of the frontier

The most recent thinking points past the application layer entirely. The provocation is AI as operating-system plumbing rather than an app: a tiny neural net running in kernel space, intercepting events through eBPF and answering in under a hundred microseconds, escalating to a CPU model and then a GPU cluster only when needed, so most work never leaves ring zero and GPU calls drop by three quarters.

Around that sit the other threads worth pulling: the network as the compute, with inference tunneled between machines and decentralized peer-to-peer model meshes; self-improving agents where recursive improvement is "a YAML config" and cron jobs head into latent space; and a relentless push to decentralize code, weights, and compute so no single platform is a chokepoint.

The recurring practices across all of it: run the weights locally, invest in the system around the model, compress aggressively, give the model an environment rather than an ever-larger context window, sandbox anything that can act, and design so cloud services stay optional.

A camada de software que transforma hardware em inferência

Os Motores

A 2026 field guide to LLM inference engines. The one rule above all the rest: you do not choose the engine first, you choose a hardware strategy, a workload shape, and a serving model. The engine follows.

Section three of the Guide named the core engines, vLLM, llama.cpp, SGLang. This is the decision layer beneath them: every major inference engine in 2026, the hardware and workload each one fits, and how to choose without guessing.

00

O princípio central

Em linguagem simples

The model is the thing that knows stuff. The engine is everything that makes it usable: it lines up requests, manages memory, and hands back the words. The whole point of this tab is that you choose the engine last, after you know your hardware and how you will use it.

An inference engine is not the model. It is the traffic cop, the memory manager, the kernel dispatcher, the scheduler, the cache accountant, the parallelism planner, the API surface, and sometimes the deployment framework. The best engine matches your memory hierarchy, interconnect, quantization format, latency and throughput targets, model architecture, and operational maturity. Pick the strategy, and the engine reveals itself.

The workload has two phases, and the split explains almost everything. Prefill reads the prompt and builds the initial cache; it is compute-intensive. Decode generates one token at a time, repeatedly reading weights and cache; it is memory-bandwidth-bound. Decode speed tracks memory bandwidth more than peak compute.

  • Short prompt, long answer: decode dominates, so memory bandwidth and batching matter.
  • Long prompt, short answer: prefill dominates, so attention kernels and chunked prefill matter.
  • Many users: scheduler quality matters, so continuous batching, cache paging, and fairness matter.
  • Long context: the KV cache dominates, so paged attention, KV quantization, and offload matter.
  • MoE: expert routing dominates, so expert parallelism and interconnect matter.
  • Multi-node: interconnect dominates, so NVLink, RDMA, pipeline parallelism, and disaggregation matter.
01

The one-page decision guide

Comece aqui
Sua situaçãoUseFamília
Notebook, edge ou hardware incomumllama.cppportátil
Fluxos centrados no MacMLX / MLX-LMApple
Inferência local em uma única RTXExLlamaV2CUDA doméstico
De 2 a 4 ou mais GPUs NVIDIA/CUDAExLlamaV3CUDA doméstico
Inferência geral em produçãovLLMprodução
Contexto longo / MoE / roteamentoSGLangprodução
Máximo desempenho em NVIDIATensorRT-LLMprodução
Orquestração de clusterNVIDIA Dynamoorquestração

Everything below explains why. The short version: the engine is downstream of your iron, your traffic, and your tolerance for operational complexity.

02

What an engine actually does

At minimum, an engine loads weights, tokenizes input, runs the forward pass, samples tokens, maintains the KV cache, and streams results. Serious engines add batching, scheduling, prefix caching, quantization, parallel execution, API serving, metrics, and distributed execution. The recurring theme across every advance is the same: inference performance is memory movement plus scheduling.

The landmark techniques all attack that theme. PagedAttention tackled KV-cache fragmentation by partitioning it into blocks, raising utilization and enabling larger batches. FlashAttention used IO-aware tiling to cut high-bandwidth-memory traffic. Decodificação especulativa drafts cheap tokens and verifies them in parallel. None of these make the GPU compute faster. They move less memory and schedule it better.

03

Os verdadeiros gargalos

819 GB/s
Apple M3 Ultra unified-memory bandwidth. Lets you fit models that would not fit in consumer VRAM.
3.35 TB/s
NVIDIA H100 SXM memory bandwidth. Serves them faster once the model fits. Fit is not speed.
  • Memory bandwidth, not just VRAM size. VRAM determines fit. Bandwidth determines decode speed. Capacity is not bandwidth.
  • KV cache growth. It grows with batch size and context length, so long-context workloads run out of memory even when weights fit. PagedAttention is the answer.
  • Interconnect. The moment a model crosses GPU boundaries you pay communication cost: tensor parallelism needs frequent all-reduce, expert parallelism needs all-to-all. Without NVLink, pipeline parallelism can beat tensor parallelism.
  • Scheduler quality. Supporting batching is not the same as a production-ready scheduler that decides which requests batch, how prefill and decode share the accelerator, and how to avoid starvation.
  • Runtime overhead. CUDA graphs, kernel fusion, sampling, tokenizer, HTTP, LoRA switching, and structured decoding. At scale the annoying two-percent overheads form a union and demand attention.
04

As quatro famílias

portátil Local runtimes

llama.cpp, MLC LLM, ONNX Runtime GenAI, OpenVINO. They care about one thing: make it run here, on whatever hardware you have.

Apple Unified-memory

MLX and MLX-LM. Built to use Apple's big shared memory pool and its stack well, on Mac first.

CUDA doméstico Quant engines

ExLlamaV2 and ExLlamaV3. Make a 3090 / 4090 / 5090 box scream with low-bit weights.

produção Serving engines

vLLM, SGLang, TensorRT-LLM, TGI, LMDeploy. Concurrent users, KV cache, batching, parallelism, observability, cost per token.

Above all of these sits an orchestration layer like NVIDIA Dynamo, which coordinates fleets, disaggregated prefill and decode, routing, and autoscaling across multiple engines.

05

Motor por motor

portátil

llama.cpp

The portability king. Apple Silicon via Metal, x86 via AVX and AMX, plus RISC-V, CUDA, AMD HIP, Vulkan, SYCL, and CPU-plus-GPU hybrid offload. Its HTTP server is far more than a toy: OpenAI and Anthropic routes, reranking, continuous batching, multimodal, JSON-schema constraints, function calling, and speculative decoding.

VerdictUse when portability, offline operation, GGUF, or hybrid offload matter more than fleet-scale serving. Do not use it for multi-GPU or serious multi-node production; its RPC backend is documented as fragile and insecure.
Apple

MLX / MLX-LM

Apple's array framework and its LLM package. The key fact is unified memory: CPU and GPU share one pool, so the question shifts from "does it fit in VRAM" to "does it fit in memory, and can the memory feed the GPU fast enough." Large quantized models fit where a 24GB card would fail. It is also slower than HBM.

VerdictUse for Mac-first ML and LLM work. For high-concurrency public serving, start with a real serving stack; the MLX-LM server itself warns it is not for production.
CUDA doméstico

ExLlamaV2

The enthusiast's local CUDA engine. Paged attention, dynamic batching, prompt caching, KV-cache deduplication, streaming, and speculative decoding. The word to remember is local: it makes EXL2 quantized models fast on consumer cards.

VerdictThe pick for a single 3090 / 4090 / 5090 box running a local coding assistant or chat.
CUDA doméstico

ExLlamaV3

Extends the philosophy to multi-GPU and local MoE. Adds the EXL3 format based on QTIP, flexible tensor and expert parallelism for consumer hardware, an OpenAI-compatible server via TabbyAPI, and multimodal support.

VerdictThe frontier for 2 to 4+ consumer NVIDIA GPUs or local MoE. Expect rougher edges for better capability; some models do not support its parallelism.
produção

vLLM

The default open-source production server, and the first engine most teams should evaluate. PagedAttention, continuous batching, chunked prefill, prefix caching, wide quantization (FP8, MXFP4, NVFP4, INT8/4, GPTQ, AWQ, GGUF), speculative decoding, and disaggregated prefill/decode. Tensor, pipeline, data, expert, and context parallelism, OpenAI and Anthropic APIs, multi-LoRA, across NVIDIA, AMD, and more.

VerdictIf someone says "we need to serve open models in production," this is the default starting point. It does not remove the need for systems thinking; you still tune batching, parallelism layout, and routing.
produção

SGLang

vLLM's systems-brained cousin, for when the workload is ugly: structured outputs, long context, MoE, routing. RadixAttention prefix caching, and the differentiator, prefill-decode disaggregation that splits compute-heavy prefill from memory-heavy decode into specialized instances so long prefills do not spike decode latency.

VerdictFor teams whose bottleneck is no longer "can we run it" but "can we run it under hostile traffic without torching latency, memory, and cost."
produção

TensorRT-LLM

The NVIDIA-max-performance stack. Builds optimized TensorRT engines with custom attention, GEMM, and MoE kernels, prefill-decode disaggregation, wide expert parallelism, and speculative decoding. B200 loads FP4 with optimized kernels; H100 and later run FP8 that can double performance and halve memory versus 16-bit.

VerdictIf you are committed to NVIDIA and care about absolute performance, it belongs in the bake-off. You trade portability for performance: awkward on AMD, Apple, or fast-changing experimental models.
orquestração

NVIDIA Dynamo

A distributed orchestration layer above engines like vLLM, SGLang, and TensorRT-LLM. Disaggregation, intelligent KV-aware routing, multi-tier KV caching, and autoscaling.

VerdictReach for it when single-engine serving is no longer enough and you are coordinating a fleet.

The rest of the field. TGI is Hugging Face's production server, good when HF integration and simplicity matter. MLC LLM is the compiler-first universal engine for shipping to browser, mobile, and native apps. ONNX Runtime GenAI powers Foundry Local and Windows ML across CPU, CUDA, DirectML, WebGPU, and more, best for app deployment. OpenVINO GenAI is the Intel story for Xeon, Arc, and NPUs. LMDeploy is a CUDA toolkit with TurboMind, an alternative to vLLM and SGLang.

One hard exclusion. Do not use Ollama for anything serious. It is pleasant, but for real work reach for llama.cpp (control and portability) or a proper serving stack (concurrency, security, observability). Convenience wrappers hide exactly the batching, caching, and quant levers you need.
06

Hardware strategy recipes

HardwareRecipe
CPU-only serverllama.cpp first. OpenVINO for Intel Xeon. ONNX Runtime GenAI for app / ONNX deployment.
MacBook / Mac StudioMLX / MLX-LM for Mac-native work. llama.cpp for GGUF portability.
Single RTX 3090 / 4090 / 5090ExLlamaV2 for EXL2. llama.cpp for GGUF. vLLM if serving multiple users.
Dual or quad consumer RTXExLlamaV3 for multi-GPU quant or MoE. vLLM if serving behavior matters. SGLang for routing / long context.
8x H100 / H200 nodeStart with vLLM or SGLang. Benchmark TensorRT-LLM if NVIDIA-only and performance justifies it. Dynamo when multi-node.
B200 / GB200 / GB300 classBenchmark TensorRT-LLM, SGLang, and vLLM. Add Dynamo for fleet routing and autoscaling.
AMD MI300 / MI325 / MI355vLLM or SGLang on ROCm. Do not assume NVIDIA benchmarks transfer cleanly.
Intel Xeon / Core Ultra / ArcOpenVINO GenAI or OpenVINO Model Server. ONNX Runtime GenAI for app embedding.
Browser, mobile, app-nativeMLC LLM / WebLLM, or ONNX Runtime GenAI.
07

Benchmarking: what to measure

Bad benchmark: "I got 180 tokens per second." It says almost nothing without the model, the weights, the workload shape, and the concurrency behind it.

Model

Exact model, architecture, parameter count, active MoE params.

Weights

Dtype, quant format, group size, calibration.

Engine

Version, commit, backend, flags.

Hardware

GPU SKU, memory capacity and bandwidth, interconnect, CPU, RAM.

Workload

Input/output length distributions, concurrency, streaming, shared prefixes, structured output.

Metrics

TTFT, TPOT, end-to-end latency, p50/p95/p99, tokens and requests per second, KV-cache hit rate, prefill vs decode throughput, cost per million tokens.

  • Never compare engines using only single-user tokens per second.
  • Test your actual prompt and output distribution, at realistic concurrency.
  • Separate prefill from decode. Track p95 and p99, not just averages.
  • Measure memory headroom at your target context length, and cache reuse if you have repeated prefixes.
  • Benchmark structured output, LoRA, and multi-LoRA separately; grammar and adapters add overhead.
  • Re-test after every driver, CUDA, ROCm, model, or engine upgrade.
08

Erros comuns

  • Choosing by VRAM capacity alone. VRAM determines fit; bandwidth and scheduler determine speed. A big unified-memory machine fits huge models, but an H100 decodes faster when the model fits.
  • Tensor parallelism on weak interconnect. Without NVLink or NVSwitch, test pipeline parallelism instead.
  • Ignoring the KV cache. At long context and high concurrency it becomes the limiting factor. Paged attention, prefix caching, KV quantization, and disaggregation are not optional at scale.
  • Treating local engines as production servers. Production means security, observability, backpressure, routing, autoscaling, and SLA behavior. The llama.cpp and MLX-LM servers are capable and convenient, but the latter warns it is not for production.
  • Assuming quant formats are portable. GGUF, EXL2, EXL3, AWQ, GPTQ, FP8, FP4, MLX, and ONNX are not interchangeable. The right format is the one your engine has optimized kernels for.
  • Ignoring model architecture. Dense, MoE, hybrid-attention, multimodal, and long-context variants stress different parts of an engine. Broad support does not mean every optimization works equally.
  • Trusting benchmark charts without workload shape. A chart for an 8B model at 1K-in / 128-out says little about a coding agent at 80K context, or a RAG service with 500 concurrent users.
09

The opinionated final map

Local AI user

llama.cpp for control. MLX on Mac. ExLlamaV2 or V3 for CUDA local performance.

Building a local agent

llama.cpp for portability. MLX on Apple Silicon. vLLM to simulate production locally.

Serving an internal team

Start with vLLM. Move to SGLang for structured outputs, long context, multi-LoRA, MoE, or routing.

Serving customers at scale

Benchmark vLLM, SGLang, and TensorRT-LLM. If routing and disaggregation matter, SGLang and Dynamo earn attention.

NVIDIA datacenter

TensorRT-LLM for max performance, vLLM for flexibility, SGLang for complex serving, Dynamo for fleet orchestration.

Edge, app, browser, Windows

llama.cpp, MLC LLM, ONNX Runtime GenAI, or OpenVINO, depending on the stack.

The final principle. Inference engines have consequences. Pick the engine only after you can answer these:

  • What hardware do I actually have, and does the model fit in fast memory or only in system / unified memory?
  • Is decode or prefill my bottleneck? What context length and concurrency matter?
  • Are prompts shared enough for prefix caching? Is the model dense, MoE, multimodal, or hybrid?
  • Do I need local convenience, production serving, or fleet orchestration?
  • What quant format has optimized kernels on my target engine?
  • Is my interconnect PCIe, NVLink, NVSwitch, Ethernet, RDMA, or Thunderbolt?
  • Am I optimizing latency, throughput, cost, privacy, portability, or developer speed?
10

Field notes: kernels and bandwidth

Fresh from the field, 2026
Em linguagem simples

Two ideas that explain why the same model can feel fast on one setup and painful on another. First, the model is just a blueprint; the real work happens in tiny programs called kernels, and good ones are far faster. Second, your machine's ceiling is three things multiplied together, not one big number.

A kernel is the small, hardware-specific routine that does one job: a matrix multiply, an attention step, a normalization, a sampling step. A good engine fuses these so the GPU does not write half-results back to memory over and over. Bad kernels make people say "this model is slow." Good kernels make the same model fly. This is why the engine choice from the decision guide matters so much.

The hardware formula: what your box can do equals capacity × bandwidth × software stack. Capacity (memory) tells you what fits. Bandwidth tells you how hard the box can breathe. The software stack (engine plus kernels) tells you how much of that spec sheet you actually cash out. Most people buy capacity, forget bandwidth, and ignore the stack, then blame the model.

14.5 → 64
tok/s on 2x RTX 3090 just by moving to vLLM with tensor-parallel across both cards. Same hardware, ~4x faster.
32 → 110
tok/s on an RTX PRO 6000 by moving to SGLang. Same card, ~3x faster, all from the software stack.

Hardware by memory bandwidth (the number that sets decode speed), newest reference:

HardwareMemoryBandwidth
RTX PRO 6000 Blackwell96 GB1792 GB/s
RTX 509032 GB1792 GB/s
RTX 409024 GB1008 GB/s
Radeon PRO W790048 GB864 GB/s
Mac Studio M3 Ultraup to 512 GB819 GB/s
MacBook Pro M5 Max128 GB460 to 614 GB/s
MacBook Pro M5 Pro64 GB307 GB/s

Notice the pattern: a small desktop GPU can have far more bandwidth than a big laptop, which is why a 24 GB RTX 4090 decodes faster than a 64 GB Mac on a model that fits both. Capacity lets you load it; bandwidth lets you run it. The starter rig many people land on: two used RTX 3090s, a 27B to 31B open model, your favorite agent, and a self-hosted search tool, which gets you frontier-class coding at home for a few hundred dollars.

The 24 GB sweet spot

A widely repeated rule from the field: there is no great model that needs more than 24 GB but less than ~256 GB. So a single 24 GB card (a used RTX 3090, around $700) runs the best model anyone can run unless they own ten times your memory. That is why the budget build punches so far above its price.

Local AI on a budget, what to buy and run:

BudgetHardwareWhat you run
$0a laptop or any 8 GB GPU you owna small QAT model (Gemma-class) for chat and subagents; with dynamic quants and offload, even a 26B mixture-of-experts at long context
~$700one used RTX 3090, 24 GB (the sweet spot)a 27B to 32B coder (Qwen3-class, GLM-4.7-Flash) at frontier-class quality, the best value in local AI
~$2,000two used 3090s (48 GB) or an AMD Strix Halo (128 GB unified)bigger mixture-of-experts and much longer context, served with vLLM or SGLang
~$5,000+MacBook Pro M5 Max (128 GB) or an NVIDIA DGX Sparkthe big MoE models (MiniMax, DeepSeek V4 Flash class)

The software stack still decides how much you cash out: two used 3090s with vLLM and tensor-parallel beat the same cards on a basic runner by several times. Buy the memory, then earn the speed with the right engine.

Run bigger than your VRAM

If a model does not fit, you do not always need a bigger GPU. With offload, most of the model lives in ordinary system RAM and only the active part runs on the GPU. People run a 753B mixture-of-experts on a single desktop this way (4-bit, decode around 13 to 15 words/sec), and a 26B MoE on an 8 GB iGPU at ~20 words/sec by reading the shared RAM pool directly. The trade is speed: system RAM is slower, so it becomes the bottleneck. It shines for MoE, where you offload the idle experts and keep the active slice on the GPU. Tools: llama.cpp partial offload, or KTransformers for big MoE.

Or pool several cheap machines

The other way past one box's limit is to combine machines. Tools like exo (open-source, free) link several ordinary computers into a single memory pool, so four Mac minis can run a 235B model that none of them could load alone. It is the budget route to a big model: stack cheap boxes instead of buying one expensive one. The catch is the same as offload, the link between machines is slower than memory inside one, so it favors throughput over snappy latency.