Ga naar inhoud

Een open-weight model prijzen

Bijgewerkt September 1, 2026 · eerst gepubliceerd September 1, 2026

Kort antwoord: Qwen3.8-Flash-Next verscheen op 26 augustus 2026 als open-weight preview van de Qwen4-architectuur: ongeveer 6B actieve parameters, een native context van 262.144 tokens en geen aangekondigde hosted...

Qwen3.8-Flash-Next verscheen op 26 augustus 2026 als open-weight preview van de Qwen4-architectuur: ongeveer 6B actieve parameters, een native context van 262.144 tokens en geen aangekondigde hosted prijs. Die combinatie breekt de gebruikelijke vergelijking. Elk gesloten model geeft je een getal per miljoen tokens; een open-weight release geeft je een checkpoint en laat het getal aan jou over.

Het getal is niet moeilijk te berekenen. De meeste teams doen het alleen nooit en vergelijken een download van $0 met een API van $3.00/MTok, om te concluderen dat de download goedkoper is. Dat kan. De rekensom beslist, en die rekensom heeft precies één term die mensen vergeten.

De formule

Kosten per miljoen tokens zijn de uurprijs van de instance gedeeld door het aantal tokens dat die instance per uur produceert:

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

Bij $2.00 per uur en een gemeten 1.500 tokens per seconde is dat 2.00 / 5.400.000 * 1.000.000 = $0.37 per miljoen tokens. Naast een gehost model van $3.00/MTok output lijkt zelf hosten een achtvoudige besparing. Dat cijfer is ook onjuist, omdat het aanneemt dat de GPU elke seconde bezig is waarvoor je betaalt.

De term die iedereen vergeet: benutting

Je huurt het uur; je gebruikt er een fractie van. Deel door die fractie:

BenuttingEffectieve kosten per MTok
100%$0.37
60%$0.62
30%$1.23
10%$3.70

Bij 10% benutting kost het zelfgehoste model meer dan de gehoste API die het moest vervangen. De meeste eerste deployments zitten tussen 10% en 30%, omdat verkeer piekerig is en de instance voor de piek is ingericht. De besparing is echt, maar het is een besparing op benutting, niet op gewichten.

Wat nog meer in het getal hoort

Opslag en egress voor het checkpoint. Leegloop tussen het opstarten van de instance en het moment dat het model warm is — bij een model met grote context duurt laden minuten, en je betaalt voor elke minuut. Redundantie, als de workload meer dan één instance nodig heeft om een nodestoring te overleven. En engineeringtijd, die niet per uur wordt gefactureerd maar in jaar één de grootste regel is.

Niets hiervan pleit tegen zelf hosten. Het pleit tegen het vergelijken van een gratis download met een tarief per token zonder de deling uit te voeren.

Meet voordat je je vastlegt

Draai het model op de instance die je daadwerkelijk zou huren, met je eigen promptvormen en contextlengtes, en leg de tokens per seconde onder gelijktijdigheid vast — niet het single-stream-getal uit de modelkaart. Neem dan je echte uurprofiel van het verkeer en bereken de benutting. Twee getallen, één deling, en de beslissing volgt vanzelf.

Bij lange context bijt dit het hardst. Een context van 262K tokens is eerst een geheugenvoetafdruk en pas daarna een feature: ze bepaalt de instanceklasse, en de instanceklasse bepaalt de uurprijs bovenaan de formule. Prijs de context die je echt verstuurt, niet de context die het model ondersteunt.

Gerelateerd

Gerelateerd


Wilt u dit toepassen op uw stack? Neem leveranciersfacturen, gatewaylogs en de belangrijkste workflows mee; we brengen kostenfactoren en besparingskansen in kaart. Plan een gratis audit →

Terug naar finopsllm.com