Wie draait Kimi K3 thuis met 2,8 biljoen parameters?

De modelmarkt beweegt zo snel dat een prijskaart of modelnaam al verouderd kan zijn voordat een proef is afgerond. Bij Kimi ligt vandaag een andere vraag voor: open gewichten scheiden van praktisch lokaal draaien bij een zeer groot MoE-model. Dat klinkt administratief, maar raakt direct aan de kosten en betrouwbaarheid van een werkproces.

Deze afweging is lastig omdat het model zelf vaak maar een deel van de rekening vormt. Een goedkoper tarief kan meer controles vragen, terwijl een duurdere route juist tijd, juridische uitzonderingen of herstelwerk voorkomt. Daarom worden de actuele feiten eerst uit elkaar gehaald en daarna in een omgekeerde rekensom gezet.

Direct naar een onderdeel van dit artikel

Wat er nu werkelijk is veranderd

De rekening ontstaat buiten de kale tokenprijs

De omgekeerde rekensom maakt de grens zichtbaar

Drie scenario’s voor 2027 tot en met 2029

Het sterkste tegenargument verdient een echte plaats

Wat deze cijfers niet bewijzen

Wat een bedrijf nu moet vastleggen

De conclusie volgt uit de gemeten uitkomst

In het kort

Bij Kimi draait de actuele afweging om open gewichten scheiden van praktisch lokaal draaien bij een zeer groot MoE-model. De prijs of licentie is maar één deel van de werkelijke rekening; kwaliteit, controle, snelheid en beheer bepalen wat een bruikbare uitkomst kost. De omgekeerde rekensom laat zien welke jaarlijkse besparing nodig is om de investering terug te verdienen. De redelijke keuze volgt daarom uit gemeten kosten per geaccepteerde taak en niet uit één opvallend tarief of benchmarkcijfer.

Wat er nu werkelijk is veranderd

Volgens de officiële documentatie geldt op de peildatum het volgende. Moonshot beschrijft Kimi K3 als een Mixture-of-Experts-model met 2,8 biljoen totale parameters, 896 experts en 16 actieve experts per token. De gewichten en technische informatie zijn geopend. Actieve parameters bepalen een deel van de rekentijd, maar niet hoeveel opslag en geheugen alle gewichten vragen. De datum van de bron en de datum waarop een productwijziging ingaat, zijn niet automatisch dezelfde. Waar een leverancier een vroegste datum, introductietarief of snelheidsclaim noemt, wordt dat hier dus ook zo behandeld.

Dat onderscheid voorkomt twee bekende fouten. Een aankondiging wordt niet gelijkgesteld aan algemene beschikbaarheid, en een open gewicht of gratis proef wordt niet beschreven als een kosteloze productiedienst. De technische toelichting laat bovendien zien dat context, cache, regio, licentie en servicelaag per variant kunnen verschillen.

De rekening ontstaat buiten de kale tokenprijs

Bij 16-bit precisie vertegenwoordigen 2,8 biljoen parameters theoretisch ongeveer 5,6 terabyte aan gewichten. Bij 4-bit blijft ruwweg 1,4 terabyte over, vóór metadata, cache, runtime en redundantie. Dat is geen consumentenwerkstation en ook geen bewijs dat een cluster het model efficiënt bedient. Inkoopteams zien het modeltarief, maar niet altijd de tijd die nodig is voor gegevensclassificatie, controle, monitoring en herstel. Die verborgen uren verdwijnen niet doordat een leverancier de prijs per miljoen tokens verlaagt.

De API maakt een andere afweging mogelijk. Tien miljoen niet-gecachete inputtokens en één miljoen outputtokens kosten volgens de actuele tabel $45. Bij volledige cachetreffers op de input daalt hetzelfde rekenvoorbeeld naar $18. Een eigen cluster moet niet alleen tokens vervangen, maar ook beschikbaarheid, updates en piekcapaciteit. Dit is bewust een rekenvoorbeeld en geen voorspelling van de uiteindelijke factuur. Het maakt zichtbaar welke variabele de uitkomst draagt. Toolkosten, valuta, belasting, cache en mislukte pogingen moeten alleen worden toegevoegd wanneer ze werkelijk in dezelfde route voorkomen.

De omgekeerde rekensom maakt de grens zichtbaar

Een project hoort niet te beginnen met de vraag hoeveel voordeel een model misschien oplevert, maar met de besparing die minimaal nodig is om de extra investering te rechtvaardigen. In het scenario hieronder bedraagt de startinvestering € 250.000 en komen daar € 90.000 jaarlijkse kosten bij. De gebruikte uurwaarde is €85.

De formule verdeelt de startinvestering eenvoudig over drie jaar en telt de jaarlijkse kosten op. Daarna wordt de som gedeeld door de waarde-eenheid. Zo ontstaat een drempel van 2.039,22 vermeden uren per jaar. Pas boven die grens is er in dit vereenvoudigde voorbeeld een positieve operationele kasbesparing.

Drie scenario’s voor 2027 tot en met 2029

Het lage scenario veronderstelt een voorzichtige ingebruikname, beperkte dekking en relatief veel menselijke controle. Het middenscenario gaat uit van herhaalbaar gebruik in enkele werkstromen. Het hoge scenario veronderstelt bredere inzet, maar telt dezelfde besparing niet nog eens als omzet of als vermeden externe kosten.

Deze scenario’s zeggen niets over een toekomstige modelbenchmark. Ze laten alleen zien hoeveel aantoonbare benutting nodig is. Wanneer de kwaliteit achterblijft, stijgt het aantal herstelpogingen en valt het netto voordeel lager uit. Wanneer een betere route werk in één keer accepteerbaar maakt, mag dat effect juist worden meegenomen.

Het sterkste tegenargument verdient een echte plaats

Open gewichten geven controle over gegevens, aanpassingen en leveranciersafhankelijkheid. Voor organisaties met hoog, voorspelbaar volume kan dat zwaar wegen. De tegenwerping blijft dat de grootste Kimi-variant infrastructuur en deskundigheid vraagt die een laag API-tarief vaak moeilijk verslaat. Een goede vergelijking zet die kans niet weg als marketing. Zij vraagt alleen om dezelfde taak, dezelfde kwaliteitsgrens en dezelfde meetperiode. Anders worden snelheid, privacy of openheid wel genoemd, maar niet economisch bewezen.

Een benchmark kan daarbij helpen om kandidaten te selecteren, maar bewijst geen betrouwbaarheid in Nederlandse documenten, eigen code of een gereguleerd proces. Alleen een vaste evaluatieset met geslaagde en mislukte gevallen laat zien of de nieuwe route werkelijk minder werk vraagt.

Wat deze cijfers niet bewijzen

De bedragen hierboven zijn geen gemeten rendement van Kimi bij één specifieke onderneming. De officiële prijzen en productvoorwaarden zijn feiten op de peildatum; volume, uurwaarde, implementatiekosten en gebruik in 2027 tot en met 2029 zijn expliciete aannames. Een positief scenario bewijst dus alleen dat de rekensom kán sluiten wanneer de veronderstelde benutting werkelijk wordt gehaald.

Ook de omgekeerde conclusie vraagt voorzichtigheid. Een project onder de financiële drempel kan toch rationeel zijn wanneer het een harde privacy-eis, continuïteitsrisico of strategische afhankelijkheid vermindert. Dan moet die waarde apart worden benoemd en onderbouwd. Zij mag niet stilletjes boven op volledige tijdwinst worden gezet, want daarmee zou dezelfde verbetering twee keer in de businesscase terechtkomen.

Voor de vergelijking is daarom een nulmeting nodig. Noteer vóór de overstap hoeveel tijd de bestaande route vraagt, welk deel van de uitkomsten direct wordt geaccepteerd en hoeveel dossiers terugkomen voor correctie. Meet na de overstap exact dezelfde grootheden. Houd daarbij taakmix en kwaliteitsgrens gelijk, zodat een eenvoudiger maand niet per ongeluk als modelverbetering wordt geboekt. Zonder die basis wordt een dalende modelrekening gemakkelijk aangezien voor productiviteitswinst, terwijl medewerkers mogelijk meer tijd besteden aan controleren, wachten of het opnieuw formuleren van opdrachten.

Wat een bedrijf nu moet vastleggen

Begin met een werkbelastingprofiel: tokens, pieken, context, vertrouwelijkheid en vereiste beschikbaarheid. Bereken daarna hardware over drie jaar inclusief stroom, beheer en uitval. Pas als die som lager is dan de geteste API-route en controle werkelijk waarde heeft, wordt zelf hosten rationeel. De aanvullende productinformatie moet samen met de contractvoorwaarden worden bewaard op de datum waarop het besluit wordt genomen. Zo is later terug te vinden welke prijs, toegang en beperking bij de businesscase hoorden.

Praktisch betekent dit dat iedere productieflow een modelversie, regio, eigenaar, evaluatieset en terugvalroute krijgt. Meet per maand volume, cachetreffers, toolgebruik, wachttijd, correcties en acceptatie. Noteer ook wijzigingen in prompts en gekoppelde gegevens, omdat zij de uitkomst even sterk kunnen beïnvloeden als een nieuw model. Daarmee wordt een prijswijziging of modelwissel een herberekening in plaats van een verrassing.

Begin bovendien met een kleine groep taken die vaak genoeg voorkomt om te meten en begrensd genoeg is om fouten te onderzoeken. Bewaar afgewezen uitkomsten naast geslaagde voorbeelden. Juist die mislukkingen laten zien of een lagere prijs, hogere snelheid of ruimere context echt tot minder werk leidt, of alleen de kosten naar controle en herstel verschuift.

De conclusie volgt uit de gemeten uitkomst

De huidige stand maakt Kimi niet vanzelf goedkoop of duur. De gekozen invalshoek laat vooral zien waar een ogenschijnlijk kleine productvoorwaarde de hele rekening kan veranderen. Wie alleen het laagste tarief kiest, kan later betalen voor vertraging, migratie of controle. Wie zonder meting voor de duurste route kiest, koopt mogelijk capaciteit die niet wordt benut.

De redelijke conclusie is daarom om klein te beginnen, de volledige keten te meten en alleen op te schalen wanneer de omgekeerde drempel wordt gehaald. De uitkomst moet daarna minstens ieder kwartaal opnieuw worden getoetst. Opnieuw kijken wanneer Moonshot kleinere K3-varianten uitbrengt, officiële quantisaties met gemeten hardware-eisen publiceert of API-prijzen wijzigen. Tot dat bewijs er ligt, blijft het scenario een plan en geen gerealiseerde besparing.