Technischer Kontext
Ich habe mir diese Berechnungen zu Kimi K3 angesehen und bin sofort auf die Kernfrage gestoßen: Reden wir über einen Labortest oder eine richtige KI-Integration für die Produktion? Das sind zwei völlig unterschiedliche Budgets, die man nicht verwechseln darf.
Für ein Modell der 2,5–2,8T-Klasse mit BF16 erscheint die Schätzung von 32 B300-GPUs nicht abwegig. Man kommt wirklich auf Terabytes an HBM, einen riesigen KV-Cache, Puffer, dazu Stromversorgung und Kühlung, die bereits ein eigenes Engineering-Projekt darstellen – kein „mal eben Hardware kaufen“.
Doch dann wird es spannender. Bei Kimi K3 geht es nicht nur um die Gesamtgröße des Modells, sondern um das Gewichtsformat und die tatsächliche Serving-Architektur. Wenn die native Inferenz in MXFP4 oder MXFP8 läuft, ändert sich das Bild drastisch: Man kann 1–2 DGX B300 nicht mehr als Witz betrachten, sondern als praktikablen Kompromiss für ein Low-Concurrency-Szenario.
Allerdings würde ich die Idee „ein DGX und alles fliegt“ nicht zu forsch verkaufen. Auf dem Papier scheinen 2,3 TB HBM in einer DGX B300 zu reichen, aber in der Praxis wird der Speicher nicht nur von den Gewichten verbraucht. Es braucht Platz für Cache, Service-Puffer, Experten-Routing und einen Sicherheitspuffer, sonst lebt das System am Limit.
Genau deshalb klingen Schätzungen von 600–700k $ für eine einzelne DGX B300 im privaten Gebrauch nur als Forschungsszenario plausibel. Hingegen sehen 2× DGX B300 für 1,25–1,45 Mio. $ eher nach der Untergrenze für ein vernünftiges On-Prem-Setup mit Batching, parallelen Anfragen und ohne ständigen Kampf um jedes Gigabyte aus.
Die gesonderte Debatte BF16 gegen Quantisierung verstehe ich sehr gut. Wenn man „kompromisslose Spitzenleistung“ braucht, ist BF16 logisch. Aber dann schnellt das Budget in einen Bereich, in dem viele plötzlich merken: Die API war gar nicht so teuer.
Auswirkungen auf Geschäft und Automatisierung
Für Unternehmen gibt es drei Erkenntnisse. Erstens: Ein riesiges offenes Modell bedeutet noch keine günstige KI-Automatisierung. Hardware, Interconnect und Betrieb können schnell teurer werden als die Idee selbst.
Zweitens: Wenn Sie ein enges privates Szenario, F&E oder ein internes Wissenssystem haben, können 1–2 Knoten gerechtfertigt sein. Wenn Sie stabile SLAs, lange Kontexte und viele gleichzeitige Benutzer brauchen, rächt sich die Sparsamkeit beim Cluster später in Latenzproblemen.
Drittens: Viele Teams überschätzen den Wert von „alles on-prem behalten“ und unterschätzen hybride KI-Architekturen. Wir bei Nahornyi AI Lab lösen genau diese Abwägungen für Kunden: wo die API günstiger ist, wo eine eigene Instanz nötig ist und wann es klüger ist, die KI-Automatisierung auf einem kleineren Modell aufzubauen, ohne diese Millionenrechnung.
Wenn Sie gerade vor einem ähnlichen Dilemma zwischen On-Prem, API und benutzerdefinierter Architektur stehen, lassen Sie es uns mit Zahlen klären, nicht mit Foreneindrücken. Bei Nahornyi AI Lab rechne ich normalerweise schnell aus, wo sich die Implementierung künstlicher Intelligenz wirklich lohnt und wo man sich besser keine teure Kontrollillusion kauft.