What happens if they double the price of tokens tomorrow?

To write this article, I had to look up how much a kilowatt-hour costs. I did not know it off the top of my head.

Token prices, on the other hand, I do know off the top of my head. Because those you have to keep watching.

That is the whole difference between the two cost models. The rest is just arithmetic.

Why now

Gábor Gonda, a deputy CEO of Magyar Telekom, gave an interview to Portfolio this week in which he put forward a firm view: the AI market and business model we see today is not sustainable in the long run. As he put it, the financial maths does not add up. Billions of dollars go into data-centre capacity, while the technology moves so far every two or three years that a significant part of earlier investments can become obsolete.

The interesting part for us, though, is not this but the conclusion. He argues that the biggest risk is token cost: we cannot know how it will evolve. The large enterprises that have already integrated AI in production keep one eye permanently on it, trying to work out what happens if the providers push through a 10, 20 or even 100 percent price increase. Does the efficiency gain survive, or does it evaporate?

I have to answer this too, because DocAI lives in the same market. So I looked at our own numbers.

What this article is not about

I have written twice already about why we run on-premise: once because of the data, once because of compliance.

This article is about neither. No GDPR here, no data sovereignty, no AI Act. We will move along a different axis: who sets the price, and when.

Two kinds of bill

There are two cost models, and the difference is not in the amount.

The variable cost — the token — scales with usage. Low entry barrier, no upfront payment, the risk of obsolescence sits with the provider. And you do not set the price. They tell you afterwards how much it cost, and next year they will tell you again.

The fixed cost — the box — does not scale with usage. High entry barrier, you pay upfront, and the risk of obsolescence is yours. In return you set the price once, and after that you know it.

It is important to see this clearly: there are true statements in both columns. Gonda's bakery analogy — that a bakery does not want to build a whole server room next to its oven just to have email and invoicing — is entirely correct. For thousands of SMEs their own server room really is not an option.

The question is not which model is better. It is which one when — and whether you have measured it.

First measured figure: the cheapest token saving is not in the price

Before anyone talks about token prices, it is worth looking at how many tokens you burn needlessly.

In May we systematically compared a 35-billion and a 122-billion parameter model on our own Hungarian business eval harness. The result was not what I expected:

• The larger model did not win on structured data extraction. Not by anything.
• And it was 2.6× slower.
• But on complex, multi-step analyses it gave a better answer in five out of six tasks — and with five times fewer data lookups.

Both are in production with us, for different purposes. That is the point.

And the lesson is general, and works in the cloud too: most of your token bill is not about price, but about using the wrong-sized model for the wrong task. This is the cheapest saving on the market, and you do not have to buy anything from anyone for it.

Second measured figure: on a Hungarian document, bigger does not win

In April we evaluated Gemma4 on our Hungarian invoice-KIE corpus. Qwen3.6's F1 was 0.975, Gemma4's was 0.890.

0.890 does not sound bad on paper. Let's look at what the errors were:

• Hungarian character-encoding problems
• hallucinated company names
• truncated invoice numbers

These are not small inaccuracies. The system invented a company name that does not exist, and cut off the end of the invoice number. In an accounting process this is not 11 percent of error — it is a line item someone has to find and fix by hand. The saving you did the whole thing for dies right there.

On top of that, Gemma4's single-stream decode was 30–80 percent slower.

You only know this if you measure it on your own documents, not on the vendor's demo. In the demo every model is good.

Third measured figure: how much work a box can take

In April we put a 122-billion parameter model on a single DGX Spark. The measured values:

• 30 tok/s on JSON-KIE, with 100 percent MTP acceptance
• 64 tok/s aggregate across four concurrent users

In another measurement MTP delivered +24 percent throughput and −56 percent TTFT on the 16-concurrent-user stress test — exactly where it should theoretically have been negative.

And now the point that makes this a business matter: Gree processes 30–70 documents a day. A desktop-sized machine handles that load. Not barely. With plenty to spare.

For the sake of honesty: there are places where it breaks. In the same measurement we wrote that the Spark falls over at 100,000-token concurrent contexts. It is not good for everything. Only for what we sized it for.

And now the electricity bill

Everything up to here comes from earlier articles. From here on comes what I measured for this one.

Two DGX Sparks, 30 days, Prometheus + DCGM. On the GPU rail:

The beta's gap comes from mode switches and reboots. I am writing it down because it is inconvenient, and because without it the number would not be interpretable.

On the GPU rail the two machines together draw ~15–17 kWh a month. At a corporate net electricity price, at roughly 65 HUF/kWh, that is around eleven hundred forint a month. The GPUs of both machines. That's it.

This is not the full picture, though, and I am not claiming it is. DCGM does not measure the Grace CPU, the always-powered 128 GB of LPDDR5X, the storage, the fan, or the power-supply loss. The Spark takes a 240-watt supply; with an idle-dominant profile the realistic average for the whole machine at the wall is 60–90 watts, that is 45–65 kWh/machine/month. Two machines: on the order of 100 kWh a month, realistically in the 90–130 kWh band.

At the same price: between 5,900 and 8,500 forint a month, roughly 6,500 forint.

I stress that this is an estimate and a ratio, not accounting. Electricity pricing in Hungary is put together in a surprisingly complicated way, and your bill will show something different. But that does not change the order of magnitude: the electricity cost of our entire DocAI infrastructure is roughly a mid-tier mobile subscription.

This is our entire variable cost. Not tokens. Not queries. Not a contract. Electricity.

And if they double the price of tokens tomorrow, this number does not change.

I am not claiming it is cheaper. I am claiming it does not move. That was exactly Gonda's question.

What this number does not include

Two things have to be said out loud, or the comparison is not fair.

One: the token bill does not only pay for compute. It also pays for a service: someone else's uptime, the model updates, the support. That is real value, and it is not in the 100 kilowatt-hours.

The other: the two machines process the data of several companies, complementing each other. So I cannot give an exact per-company number, and I will not pretend I can. This figure is about the system, not about one client. The per-company measurement will be a separate article, on a dedicated machine, on a known corpus.

Idleness is almost free

There is something here that seems contradictory at first.

The cloud's classic argument goes: don't pay for idle capacity. That argument starts from the premise that idleness is expensive.

Our profile is strongly idle-dominant: the GPU ticks along at 11–12 watts on average, and only jumps to 90–97 during processing bursts. That is, the machines are idle for the vast majority of the time.

And idleness costs 11.56 watts. Eight kilowatt-hours a month. Roughly five hundred and forty forint.

That is what it costs to keep an AI on standby, ready to start at any moment. Five hundred and forty forint a month.

A small technical note that says a lot: the GPU is only about 15–20 percent of the machine's consumption. The idle floor is not set by the GPU, but by the always-powered 128 GB of memory.

The band

Here is where the point comes out. Let's add up the two endpoints:

• idle machine at the wall: ~60–90 W
• GPU at peak, full steam: on the order of ~150–180 W

So between doing nothing and full load the difference is two-to-threefold. That's it. It has a top.

In the token model the same band runs from zero to unlimited. The bill scales linearly with usage, with no upper bound.

Figure 1 — The box has a ceiling. The token bill does not.

From this follows something that sounds strange at first: the more you use the box, the cheaper it is per document. In the token model it is exactly the other way round.

The payback

The electricity bill on its own would be a half-truth, because the box has a price.

At Gree Hungary 30–70 documents a day go through the system, we automatically verify partners against four authoritative sources, and they save more than an hour a day on the transfers alone. A multi-day approval process became a same-day flow.

The payback was three to four months.

And that knocks a leg out from under the obsolescence argument. If a box pays for itself in three to four months, then the „but it becomes obsolete in two or three years” worry does not hold up mathematically. It earned its keep long before it would become obsolete.

The full cost picture looks like this, and this is honest:

• Capex: amortises, pays back in 3–4 months. Measured, at a client.
• Opex: ~100 kWh/month, for two machines. Measured, over 30 days.
• After payback, the marginal cost of one document: electricity.

„But it becomes obsolete”

This is the most serious counter-argument, and Gonda phrases it precisely: the technology advances so much every two or three years that a significant part of earlier investments can become obsolete.

True. For the model. Not for the box.

Look at this blog in chronological order. Three months, a single machine:

Four models, one box, three months, every switch measured.

The model becomes obsolete. The model is free. The box stays.

And now comes the part where I disagree with Gonda — on exactly one claim.

He says the swappable model, the technology-agnostic architecture, is a key direction, and in that he is entirely right. But he adds that this requires scale of the kind Magyar Telekom has, and that businesses would do well to move in this direction — instead of homebrew tinkering.

With respect: you do not need that kind of scale. We did it on a desktop-sized machine, and we published every measurement. Including the negatives: after two days and six hours of Triton tuning we ended up at a configuration 5–7 percent worse, and we wrote an article about that too.

That is the difference between tinkering and engineering. It is not that there is no failure. It is that you measured it, and wrote it down.

When NOT to do it this way

This section is not here out of politeness. If I left it out, this article would be an advert.

If your load is unpredictably peaky. You cannot size a fixed cost for the peak, except expensively. In that case the cloud is cheaper, and not by a little.

If there is no one to operate it. An un-updated, badly maintained on-premise infrastructure really is riskier than a cloud service. On this, minister Zoltán Tanács — who also spoke about this recently — is entirely right, and we take it seriously at DocAI too.

If the task is public and occasional. Drafting an email, summarising a public document — go ahead and use a public model for that. Not every task is confidential.

If you are just starting and do not know how much it will be. Start in the cloud. Measure for three months. Then decide.

Running on-premise is not a creed. It is a decision with a measurable precondition.

Five questions before you buy AI

1. How many documents go through you per day? If you do not know, that is the first task — not the AI.
2. How large is your token bill today, and what happens to it if it doubles? If that question is uncomfortable, that is already an answer.
3. Who sets the price next year? Is it in the contract, or are you just trusting it?
4. If you wanted to leave tomorrow: how long would it take, and what would you take with you?
5. Did you measure it on your own documents, or on the vendor's demo?

Closing

Gonda's question is a good question: what happens if they raise prices?

For us the answer is roughly 100 kilowatt-hours and six and a half thousand forint a month, and neither depends on what they decide in California. This is not a merit — it is the consequence of an architectural decision that has its own price and its own limit, both of which I described above.

But you can only answer the question if you know your own numbers.

That is the one thing that is up to you.

The measurements in this article were made on DocAI's own infrastructure: two NVIDIA DGX Sparks (GB10), Prometheus + DCGM Exporter, Grafana. The 30-day consumption data is raw, not smoothed. The whole-machine wall consumption is an estimate — we will publish the measured wall figure in a follow-up article. The electricity price is calculated at a net 65 HUF/kWh, as a ratio.

Gábor Gonda's quoted statements come from Portfolio's interview of 16 July 2026: „The maths doesn't add up: everything could change fundamentally if the AI companies' master plan works out” (in Hungarian). It is worth reading in full — there is more in it than I dealt with here.