--- title: "When does a 16GB GPU break even against frontier LLM APIs" description: "A 700-euro 16GB GPU against Claude Opus, Sonnet and hosted Qwen at early October 2026 prices: about 584, 1,234, 7,360 hours of work, or never. The math." canonical: "https://www.mauriziofonte.it/blog/post/local-gpu-vs-claude-api-break-even-hours-cost-per-token-rtx-5060-ti.html" author: "Maurizio Fonte" date: "2026-10-30T08:55:39+01:00" modified: "2026-10-30T08:55:39+01:00" section: "LLM" tags: ["LLM", "Cloud"] license: "Riuso e citazione consentiti con attribuzione e link alla fonte" --- [LLM](https://www.mauriziofonte.it/blog/cat/llm.html) [Cloud](https://www.mauriziofonte.it/blog/cat/cloud-infrastructure.html) # [When does a 16GB GPU break even against frontier LLM APIs](https://www.mauriziofonte.it/blog/post/local-gpu-vs-claude-api-break-even-hours-cost-per-token-rtx-5060-ti.html) Venerdì 30 Ottobre 2026, alle 08:55 ![When does a 16GB GPU break even against frontier LLM APIs](https://www.mauriziofonte.it/image/006060200-local-gpu-vs-claude-api-break-even-hours-cost-per-token-rtx-5060-ti.jpg) Every discussion about local inference eventually reaches the money question: if I spend 700 euros on a 16GB card, when have I saved that money compared to paying an API? The answer is "it depends", and confident single numbers are everywhere, because the result swings by a factor of ten with assumptions that are rarely stated. Which API? Which model? How many tokens per hour does the card really produce? What does the electricity cost? Are input tokens counted? Is the work the same? I have the measured side of that equation from my own bench, a 16GB RTX 5060 Ti that ran a 45-hour campaign of 645 tasks across five models, and the public price side from the providers' list prices as I read them in early October 2026. This article puts the two together with every assumption written down, so that you can replace mine with yours and redo the arithmetic. The numbers below are a model, not a promise, and I say which parts are measured, which are estimated and which are assumed. Prices change: check the current list prices before you rely on any figure here, because they may have moved since I read them. > **Note:** The local side comes from my bench: RTX 5060 Ti 16GB (Blackwell, 180 W limit) on PCIe Gen3 x8, Ryzen 5 4500 with 6 cores, 32GB of DDR4 at 3,600 MT/s, Debian 13, NVIDIA driver 615.71.09 with CUDA 13.4, llama.cpp at commit `391fac1` with every flag pinned and one slot. All the numbers you see here come from the benchmark procedure described in detail in [how my harness accounts for energy and cost](https://www.mauriziofonte.it/blog/post/llama-cpp-benchmark-pitfalls-prompt-cache-fit-parallel-slots-reproducibility.html#energy-and-cost-accounting). ## Why do break-even estimates disagree so much? **Because a break-even divides the price of the card by a saving per hour, and every term of that saving is an assumption.** The saving per hour is the API cost of the work the card does in an hour, minus the electricity the card burns doing it. The API cost depends on the model you compare with, on how many tokens the work needs, and on the split between input and output tokens, which are priced very differently. Change any one of them and the result moves by a multiple. The most common mistake is comparing with the wrong API. A local 27B model is not a substitute for a frontier model on every task, and a frontier model is not the only alternative to a local one: the same open-weight model is often available hosted, at a fraction of the frontier price. The second most common mistake is assuming the card runs at full load all day. It does not, and every idle hour stretches the break-even. If you are weighing local inference against an API for a team and want the comparison done on your real usage, my [hub on AI infrastructure for companies](https://www.mauriziofonte.it/ai-aziende/ai-aziende-integrazione.html) describes how I build these cost models. ## The price side, as of early October 2026 I read the list prices directly from the providers' public pages in early October 2026: Anthropic's [pricing page](https://platform.claude.com/docs/en/about-claude/pricing) for Claude, and OpenRouter's public model list for the hosted Qwen models, the [Qwen3.8-27B](https://openrouter.ai/qwen/qwen3.8-27b) entry being the same base model as the 27B I run locally. Prices are per million tokens, in US dollars, for standard requests without batch or cache discounts. **Model comparison: API list prices per million tokens, as of early October 2026** *Prices in US dollars per million tokens* | Model | Input | Output | Context | | --- | --- | --- | --- | | Claude Opus 5.5, Anthropic, frontier | $4.00 | $20.00 | n/a | | Claude Sonnet 5.5, Anthropic, mid-tier | $2.00 | $10.00 | n/a | | Qwen3.8-27B, OpenRouter, same base model as the local 27B | $0.43 | $2.55 | 1 M token | | Qwen3.6-35B-A3B, OpenRouter, same class as the local 35B MoE | $0.15 | $1.00 | 262.14 K token | Source: Anthropic pricing page and OpenRouter public model list, early October 2026 Verified: Oct 2026 > **Warning:** These are list prices as of early October 2026. API prices change often and without notice: check the current prices on the providers' pages before using any number in this article for a decision. To compare with local work in euros, I convert at the European Central Bank reference rate of the same days, 1.1177 dollars per euro, and blend input and output prices with a declared ratio of one input token for every three output tokens. No assumption in this article moves the result more than the blend, and I return to it below. | Model | Input, USD per MTok | Output, USD per MTok | Blended, EUR per MTok | | --- | --- | --- | --- | | Claude Opus 5.5 | 4.00 | 20.00 | 14.32 | | Claude Sonnet 5.5 | 2.00 | 10.00 | 7.16 | | Qwen3.8-27B hosted | 0.425 | 2.55 | 1.81 | | Qwen3.6-35B-A3B hosted | 0.15 | 1.00 | 0.71 | ## The local side, measured and estimated **Throughput, measured.** Over the 45-hour campaign the card generated at least 3,974,359 tokens across five models, about 88,000 tokens per hour of saturated work. The count is a minimum: tasks cut at a time limit recorded no token counters, so the true figure is somewhat higher. **Electricity, estimated.** Above the idle baseline of the machine, the campaign used an estimated 8.86 kWh, with a 95% band from 8.31 to 9.41, which at my marginal price of 0.3266 euros per kWh is 2.89 euros, or about **0.064 euros per hour of saturated work**. The GPU part of that energy is measured by the driver; the rest of the machine is estimated, which is why I write "estimated" every time. **The card, assumed.** I use 700 euros for a 16GB card. Your price will differ, and the break-even scales linearly with it. ## The break-even, model by model The API cost of the same tokens is the blended price times the tokens. The saving per hour is that cost minus the local electricity. The break-even is the card price divided by the saving per hour. | Compared with | API cost of the campaign's tokens | API cost per hour of saturated work | Saving per hour after electricity | Break-even for a 700-euro card | | --- | --- | --- | --- | --- | | Claude Opus 5.5 | 56.89 euros | 1.263 euros | 1.199 euros | about 584 hours | | Claude Sonnet 5.5 | 28.45 euros | 0.632 euros | 0.568 euros | about 1,234 hours | | Qwen3.8-27B hosted | 7.18 euros | 0.159 euros | 0.095 euros | about 7,360 hours | | Qwen3.6-35B-A3B hosted | 2.80 euros | 0.062 euros | negative | never | The last row is not an error. A hosted 35B mixture of experts at 0.15 and 1.00 dollars per million tokens costs about 6 cents per hour for the same output, and the card burns about 6.4 cents of electricity per hour of saturated work. Against that API the card never pays for itself on electricity alone. ## What those hours mean in days Hours of saturated work are not calendar hours. A card that serves one developer is idle most of the day. If it worked at full load for eight hours every working day, 584 hours would be about 73 working days, a little over three months; 1,234 hours about 154 working days, seven months; 7,360 hours almost four years. At two hours of real load per day, multiply each of those by four. | Break-even | At 8 saturated hours per working day | At 2 saturated hours per working day | | --- | --- | --- | | Against Claude Opus 5.5 | about 73 working days | about 292 working days | | Against Claude Sonnet 5.5 | about 154 working days | about 617 working days | | Against Qwen3.8-27B hosted | about 920 working days | far beyond the card's useful life | > The card pays for itself quickly only against a frontier model, and only if you keep it busy. Against a hosted open-weight model you buy the card for other reasons than saving money. ## The assumptions that move the result **Same tokens for the same work.** The calculation assumes the API would generate the same number of output tokens for the same tasks. A frontier model would not: it typically solves some tasks with fewer tokens and others with more, and it would solve tasks the local model fails. This assumption is generous to the card when the frontier model is more efficient, and unfair to it when the local model thinks for ten thousand tokens on a question the API answers in two hundred. **Input tokens are not counted.** In an agentic loop, input tokens dominate: every turn resends the conversation and the tool outputs. My blend counts one input token for every three output tokens, which is far below the real ratio of an agent. Counting input properly would make the API more expensive and the break-even shorter. This assumption biases the result against the card, and it is the main reason the Opus and Sonnet figures above are conservative. **Caching and batch discounts are ignored.** Providers discount cached input and batch requests heavily. An API workload designed around those discounts costs less than the list price, which lengthens the break-even. **The value of keeping data in-house is zero in this table.** That value is real for many teams, sometimes decisive, and it cannot be expressed in euros per token. It is the subject of a separate article in this series. **Everything that is not electricity is excluded.** The rest of the machine, the time to install and maintain it, and the hours of a person waiting on a slower model. The break-even above is therefore a lower bound in favour of the card on cost, and an upper bound on how cheap local inference really is. ## How sensitive the result is to throughput The 88,000 tokens per hour are a campaign average: five models of very different speed, with time spent loading models, reading prompts, running tests in agent loops and waiting between tasks. A single fast model kept busy on generation alone produces more; a slow model on long prompts produces less. Because the saving per hour scales with the tokens the card produces, the break-even moves almost inversely with throughput, except where the API is so cheap that electricity eats the saving. | Compared with | At half the measured throughput, about 44,000 tokens per hour | At the measured 88,000 | At twice the measured throughput, about 176,000 | | --- | --- | --- | --- | | Claude Opus 5.5 | about 1,234 hours | about 584 hours | about 284 hours | | Claude Sonnet 5.5 | about 2,782 hours | about 1,234 hours | about 584 hours | | Qwen3.8-27B hosted | about 45,000 hours | about 7,360 hours | about 2,750 hours | | Qwen3.6-35B-A3B hosted | never | never | about 11,630 hours | If money is part of the decision, the table argues for keeping a local card busy: halving the idle time does more for the break-even than any price difference between two cards of the same class. It also shows how fragile the comparison with hosted open-weight models is: at half the measured throughput, the card needs about 45,000 hours to beat even the hosted 27B, far longer than any card stays in service. ## Redo the arithmetic with your numbers The calculation is small enough to keep in a script and rerun with your own assumptions. This is the version I use: ```python # All amounts in euros; API prices in USD per million tokens. USD_PER_EUR = 1.1177 # ECB reference rate, early October 2026 INPUT_SHARE = 0.25 # 1 input token every 3 output tokens: a declared assumption TOKENS_PER_HOUR = 3_974_359 / 45.04 # measured on the card: about 88,000 per saturated hour ENERGY_EUR_PER_HOUR = 2.89 / 45.04 # estimated, marginal above idle: about 0.064 euros per hour CARD_EUR = 700 # card price: replace with yours def blended_eur_per_mtok(usd_in: float, usd_out: float) -> float: return (INPUT_SHARE * usd_in + (1 - INPUT_SHARE) * usd_out) / USD_PER_EUR def break_even_hours(usd_in: float, usd_out: float) -> float | None: api_per_hour = blended_eur_per_mtok(usd_in, usd_out) * TOKENS_PER_HOUR / 1_000_000 saving = api_per_hour - ENERGY_EUR_PER_HOUR return CARD_EUR / saving if saving > 0 else None for name, usd_in, usd_out in [("Opus 5.5", 4, 20), ("Sonnet 5.5", 2, 10), ("Qwen3.8-27B hosted", 0.425, 2.55), ("Qwen3.6-35B-A3B hosted", 0.15, 1.0)]: print(name, break_even_hours(usd_in, usd_out)) ``` The blend treats the measured tokens as a mix of input and output, which understates an agent loop: there, the input tokens resent at every turn come on top of the generated ones, often several times their number. To model that, add your real input volume per hour priced at the input rate to `api_per_hour`; the API cost rises and the break-even shortens. Change `CARD_EUR` to your price and every result scales with it. To convert the dollar prices at today's rate rather than mine, the [currency converter](https://www.mauriziofonte.it/tools/currency-converter) on this site uses the same ECB reference rates. ## The decision in yes-or-no form **Comparison matrix: Does a 700-euro 16GB card pay for itself, as of early October 2026** | Compared with | Pays back in under 1,000 saturated hours | Pays back at all on electricity | Same base model as a local option | | --- | --- | --- | --- | | Claude Opus 5.5 | Yes, about 584 | Yes | No | | Claude Sonnet 5.5 | No, about 1,234 | Yes | No | | Qwen3.8-27B hosted | No, about 7,360 | Yes | Yes | | Qwen3.6-35B-A3B hosted | No | No | Partial, same class | Source: author's measurements and list prices as of early October 2026 ## What I conclude for my own setup For me, the money was never the deciding argument, and the arithmetic confirms why. Against a frontier API, a busy card pays for itself within months. Against the same open-weight model hosted by someone else, it does not pay for itself in any reasonable time. What the card buys is something the table does not price: data that never leaves the machine, a model that cannot be withdrawn or changed by a third party, and a setup I can measure and reproduce to the last flag. Those are good reasons, and they are not savings. The local side of this calculation comes from the same campaign as [the real cost of keeping a 16GB card dedicated](https://www.mauriziofonte.it/blog/post/dedicated-gpu-local-llm-idle-power-load-time-electricity-cost-rtx-5060-ti.html), and the models whose throughput feeds it are compared in [Qwen3.8-27B vs Ornith-1.5-35B-A3B](https://www.mauriziofonte.it/blog/post/qwen3-8-27b-vs-ornith-1-5-35b-a3b-16gb-rtx-5060-ti-coding-latency-benchmark.html). A broader view of when self-hosting makes sense for a small company, beyond the GPU, is in my earlier article on [self-hosted LLM costs after the 2026 VPS repricing](https://www.mauriziofonte.it/blog/post/hetzner-prezzi-2026-llm-self-hosted-vps-costi-pmi.html). A break-even is only as good as its assumptions, so I publish the assumptions next to it. With mine, the card beats a frontier API in a few months of real work and never beats a cheap hosted open-weight model. With yours, the numbers will move; the structure of the decision will not. If you are deciding between local inference and an API for a team and want the cost model built on your actual traffic, you can describe the case in the [free quote form](https://www.mauriziofonte.it/pages/preventivo-gratuito.html#consulenza-ai): two minutes, and I tell you upfront whether it is something I can help with. Dall'articolo al lavoro vero Se questo server lo devi tenere in piedi tu Major upgrade senza fermo, hardening, monitoraggio, backup di cui viene provato il ripristino. [Vedi come lavoro sui server](https://www.mauriziofonte.it/servizi/consulenza-it-devops.html) Ultima modifica: Venerdì 30 Ottobre 2026, alle 08:55 [« Articolo precedenteRiparare apt e dpkg interrotti a metà upgrade senza reinstallare29 Ottobre 2026](https://www.mauriziofonte.it/blog/post/dpkg-was-interrupted-riparare-apt-debian-senza-reinstallare.html) --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about --- ## Come citare > Maurizio Fonte, "When does a 16GB GPU break even against frontier LLM APIs", mauriziofonte.it, 2026. https://www.mauriziofonte.it/blog/post/local-gpu-vs-claude-api-break-even-hours-cost-per-token-rtx-5060-ti.html Pubblicato: 2026-10-30 · Aggiornato: 2026-10-30. **Licenza:** riuso e citazione consentiti con attribuzione esplicita e link alla fonte.