Quick answer: Qwen3.8-Flash-Next arrived on 26 August 2026 as an open-weight preview of the Qwen4 architecture: roughly 6B active parameters, a 262,144-token native context, and no hosted pricing announced. That...

Pricing an open-weight model

Updated September 1, 2026 · first published September 1, 2026

Qwen3.8-Flash-Next arrived on 26 August 2026 as an open-weight preview of the Qwen4 architecture: roughly 6B active parameters, a 262,144-token native context, and no hosted pricing announced. That combination breaks the usual comparison. Every closed model gives you a number per million tokens; an open-weight release gives you a checkpoint and leaves the number to you.

The number is not hard to compute. It is just that most teams never compute it, and instead compare a $0 download against a $3.00/MTok API and conclude the download is cheaper. It might be. The arithmetic decides, and the arithmetic has exactly one term people forget.

The formula

Cost per million tokens is the hourly price of the instance divided by how many tokens that instance produces in an hour:

cost per MTok = hourly_price / (tokens_per_second * 3600) * 1,000,000

At $2.00 per hour and a measured 1,500 tokens per second, that is 2.00 / 5,400,000 * 1,000,000 = $0.37 per million tokens. Against a hosted model at $3.00/MTok output, self-hosting looks like an eight-fold saving. That figure is also wrong, because it assumes the GPU is busy every second you pay for.

The term everyone forgets: utilisation

You rent the hour; you use a fraction of it. Divide by that fraction:

UtilisationEffective cost per MTok
100%$0.37
60%$0.62
30%$1.23
10%$3.70

At 10% utilisation the self-hosted model costs more than the hosted API it was meant to replace. Most first deployments sit between 10% and 30%, because traffic is bursty and the instance is provisioned for the peak. The saving is real, but it is a saving on utilisation, not on weights.

What else belongs in the number

Storage and egress for the checkpoint. Idle time between the instance booting and the model being warm — on a large-context model, loading is minutes, and you pay for all of them. Redundancy, if the workload needs more than one instance to survive a node failure. And engineering time, which is not billed hourly but is the largest line in year one.

None of that argues against self-hosting. It argues against comparing a free download to a per-token rate without doing the division.

Measure before you commit

Run the model on the instance you would actually rent, with your own prompt shapes and your own context lengths, and record tokens per second under concurrency — not the single-stream number from the model card. Then take your real hourly traffic profile and compute utilisation. Two numbers, one division, and the decision makes itself.

The long context is where this bites hardest. A 262K-token context is a memory footprint before it is a feature: it dictates the instance class, and the instance class dictates the hourly price at the top of the formula. Price the context you actually send, not the context the model supports.

Related

Related


Want this applied to your own LLM spend? FinOps LLM runs a free audit of your AI costs and shows where the savings are. Book free audit →

Back to research