知識がなくても始められる、AIと共にある豊かな毎日。
AI News & Trends

Reading Your Cloud AI Bill Before You Buy a GPU — What Local AI Really Saves

swiftwand

Two things tend to push people toward running AI on their own hardware. The first is the monthly invoice. The second is the moment you realise a particular file should not leave the building. Local AI gets offered as the answer to both, usually in the same breath, and usually without numbers attached.

This article puts the numbers next to each other: the cloud API rates in force as of August 2026, the memory figures published in official model cards, and measurements taken on hardware sitting on my own desk. The goal is to draw a line between the work worth moving and the work that is not.

忍者AdMax

Look at the invoice first — actual rates in August 2026

Judgement starts with unit prices. The table below is taken from each vendor official pricing page as of 19 August 2026. Every figure is per million tokens, input on the left and output on the right.

ProviderModelInputOutput
AnthropicClaude Fable 5$10$50
AnthropicClaude Opus 5$5$25
AnthropicClaude Sonnet 5$2$10
AnthropicClaude Haiku 4.5$1$5
OpenAIGPT-5.6 Sol$5$30
OpenAIGPT-5.6 Terra$2$12
OpenAIGPT-5.6 Luna$0.20$1.20
GoogleGemini 3.7 Flash$0.75$3.75
GoogleGemini 3.5 Flash-Lite$0.30$2.50

The first thing to notice is that there is a spread of more than fifty times inside the category we casually call cloud AI. Between Fable 5 at the top and Luna at the bottom, output tokens differ by more than forty times.

Two footnotes matter. The $2 / $10 on Claude Sonnet 5 was announced as introductory pricing through 31 August 2026, but the official page now states plainly that the increase to $3 / $15 scheduled for 1 September will not happen and that this is the standard price. Gemini 3.7 Flash runs the other way: $0.75 / $3.75 holds through 31 December 2026, then doubles to $1.50 / $7.50 on 1 January 2027.

Discounts sit on top of all of this. Claude charges 0.1x base input on a prompt cache hit and halves both directions through the Batch API. The GPT-5.6 tier prices cached input at a tenth as well. Before moving anything to your own machine, it is worth asking whether the bill survives contact with the discounts already on offer.

The thing local AI is best at is not cost

Cost is the reason people start looking. It is rarely the reason they stay. Three properties do more work:

  • Data never leaves the machine. For a client drawing, an unreleased design or a measurement log, this is not a saving, it is a requirement.
  • Throughput is bounded by hardware, not by a bill. Generating ten images to keep one costs the same as generating one.
  • Availability does not depend on someone else uptime. A local stack keeps working when an API has a bad afternoon. I wrote about what that dependency feels like in the day AI dependency became a real problem.

Read those three together and the shape of the answer changes. Local AI is not a cheaper replacement for the cloud. It is a tier you place below the cheapest cloud tier, for work whose volume or sensitivity makes metered billing the wrong shape.

What actually runs on the VRAM you have

The constraint is memory, and the honest version of the question is not which model is best but which model fits. Two official statements are useful because they name a number rather than a vibe.

Memory on handModel with a published figureOfficial wording
16 GBopenai/gpt-oss-20b (21B total, 3.6B active)runs within 16GB of memory
80 GBopenai/gpt-oss-120b (117B total, 5.1B active)fits into a single 80GB GPU

Most model cards do not say this, which means you have to estimate. The arithmetic is one multiplication and is covered in estimating what fits in your VRAM. What matters here is the order of operations: check that it fits before you argue about which is smarter.

One formula for the break-even point

Strip the argument down and it is a division.

  1. Monthly cloud spend for the job you actually want to move.
  2. Monthly cost of running the same job locally, which is mostly electricity.
  3. Initial hardware outlay, divided by the difference.

Take a concrete workload: thirty calls a day, 8,000 input and 2,000 output tokens each. Over thirty days that is 7.2M input and 1.8M output tokens. At 150 yen to the dollar:

ModelCalculationMonthly
Claude Opus 57.2 x $5 + 1.8 x $25$81.00 (12,150 yen)
Claude Sonnet 57.2 x $2 + 1.8 x $10$32.40 (4,860 yen)
Gemini 3.7 Flash7.2 x $0.75 + 1.8 x $3.75$12.15 (1,823 yen)
GPT-5.6 Luna7.2 x $0.20 + 1.8 x $1.20$3.60 (540 yen)

Put electricity into the formula

The local side is not free. Assume a 300 W card running two hours a day: 0.6 kWh daily, 18 kWh a month. At 31 yen per kWh, the reference figure published by the Japanese fair trade council for home appliances, that is 558 yen a month. Assume 150,000 yen spent on the GPU.

Compared againstCloud per monthSaved per monthMonths to recover
Claude Opus 512,150 yen11,592 yenabout 13
Claude Sonnet 54,860 yen4,302 yenabout 35
Gemini 3.7 Flash1,823 yen1,265 yenabout 119
GPT-5.6 Luna540 yennegativenever

The last row is the one worth sitting with. Against the cheapest tier, running the job at home is more expensive — 558 yen of electricity against 540 yen of API. If you are already on Luna or Flash-Lite, a GPU purchase justified by cost alone will not pay for itself. It has to be justified by privacy, by volume, or by not wanting to be metered.

Image generation is the first thing that moves

Text is where people start, but images are where the economics tip first. A single article might need a dozen illustrations, and the working method is to generate ten and keep one. On metered billing you pay for the nine you throw away. Locally you pay for electricity and time.

The catch is licensing rather than hardware, and it is easy to get wrong: FLUX.1 [dev] and FLUX.1 [schnell] are not interchangeable. That, and the batch design that makes a twelve-image job survivable, is the subject of covering your article images locally.

Speech synthesis runs, but it is not cheap in time

Text-to-speech is the other workload with an awkward relationship to metered pricing, because the unit of work is a whole article rather than a sentence. It runs locally without much trouble. What it costs is wall-clock time, and the number of chunks is usually three times what you guessed. The measurements are in turning long articles into audio with local TTS.

How to recognise work that should stay in the cloud

Three signals, in rough order of how often they decide it:

  • The input is large. Reading a long document end to end wants a context window that a consumer card cannot hold comfortably, while cloud tiers offer million-token contexts at standard rates.
  • Quality sets the outcome. An article, a proposal, a piece of code that carries a design decision — here the ceiling matters more than the unit price.
  • The volume is low. Anything you run a handful of times a month will never repay hardware, whatever the per-call price.

Get the order of the first moves right

  1. Ask whether the job has a data-egress constraint. If it does, local is the only answer and cost never enters the argument.
  2. If it does not, try dropping a tier inside the cloud first. The number of jobs that Luna or Flash-Lite handle fine is surprising.
  3. If the volume is genuinely piling up, then make it a candidate for moving.
  4. Before moving it, verify on one small job that a local model meets your quality bar.

Most people skip step two and jump to step four. The table above shows why that is expensive thinking: dropping a tier within the cloud already cuts the bill by more than twenty times. Run the same input through a top tier and a cheap tier, compare the two outputs on work you are actually paying for, and decide from that rather than from a feeling.

Assume you will run both

The useful framing is not local versus cloud but three layers: local, cheap cloud, top cloud. Work flows downward until quality stops holding, and stays where it stops. Nothing about that requires picking a side.

Making both reachable from the same code is easier than it sounds, because every serious local runtime exposes an OpenAI-compatible endpoint. Point the base URL somewhere else and the same client works. The details, plus tool calling and MCP, are in wiring a local LLM into real work. For choosing which model sits in each layer, the reverse guide to the summer 2026 model lineup covers the cloud side.

What changes at a 3D printing bench

The pattern is easy to see in workshop work. Rewriting a parameter set, naming a batch of files, drafting a product description — high volume, low stakes, no need for a frontier model. A camera watching the first layer is the clearer case: streaming frames to an API all day is not sensible on bandwidth alone, and a small local model is the only shape that works.

Generating geometry is the opposite. If you want to see how far open models have come there, the open-source 3D generation piece has the comparisons.

Summary — keep a map of your own side

  • Cloud AI already spans more than fifty times in price. Try dropping a tier before buying hardware.
  • Break-even is initial outlay divided by monthly saving. Against a top model, roughly a year; against the cheapest tier, never.
  • Electricity is real: 300 W for two hours a day is about 558 yen a month at 31 yen per kWh.
  • Whether a model fits is a memory question, and most model cards leave you to estimate it yourself.
  • Images move local first. Speech runs locally but costs time rather than money.
  • Local AI is not a replacement for the cloud. It is the tier below the cheapest one.

Sources

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】
ABOUT ME
swiftwand
swiftwand
AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.
記事URLをコピーしました