Qwen3.8-Max Kimi K3 DeepSeek V4 Kosten abgleichen

Stand: 08.08.2026. Zuletzt aktualisiert am 08.08.2026; geprüft anhand der offiziellen Dokumentation von Alibaba Cloud Model Studio, Kimi API und DeepSeek API.

DeepSeek V4 weist in der offiziellen Preisdokumentation drei getrennte Tokenklassen aus: Cache-Treffer, Cache-Fehltreffer und Ausgabetoken. Zusätzlich werden für DeepSeek V4-Flash und V4-Pro unterschiedliche Parallelitätsgrenzen genannt. Genau deshalb ist Qwen3.8-Max Kimi K3 DeepSeek V4 Kosten abgleichen keine einfache Preislistenaufgabe: Wir empfehlen, ab dieser Woche nicht mehr Paketpreise oder einzelne Tokenpreise zu vergleichen, sondern den Preis pro erfolgreich abgeschlossener Aufgabe. (offizielle DeepSeek-Preisdokumentation)

Diese Methode ist für drei Gruppen gedacht: unabhängige Entwickler, die Testabrechnungen in eine wiederverwendbare Kostenübersicht überführen möchten; technische Verantwortliche mit Budget- und Einkaufsverantwortung; sowie Teams, deren Programmier- oder Automatisierungs-Agenten durch Wiederholungen, lange Antworten und Werkzeugaufrufe höhere Kosten verursachen als erwartet.

Der gemeinsame Nenner ist die erfolgreiche Aufgabe

Ein Credits-Paket, eine monatliche Nutzungseinheit und ein Preis pro einer Million Token messen nicht dasselbe. Ein Paket beschreibt zunächst nur das gekaufte Kontingent. Credits zeigen, wie eine Plattform bestimmte Modell- oder Werkzeugnutzung intern belastet. Ein Tokenpreis beschreibt dagegen eine einzelne abrechenbare Einheit. Keiner dieser Werte beantwortet allein die Frage, wie viel eine funktionierende Lösung kostet.

Wir verwenden deshalb folgende Grundformel:

Effektive Kosten pro erfolgreicher Aufgabe = Gesamtkosten aller Versuche bis zur Abnahme ÷ Zahl der erfolgreich abgenommenen Aufgaben

Zu den Gesamtkosten gehören:

• Eingabetoken ohne Cache-Treffer,
• Eingabetoken mit Cache-Treffer,
• Ausgabetoken einschließlich längerer Denk- oder Begründungsanteile, sofern sie abgerechnet werden,
• Modellaufrufe nach Fehlern,
• automatische Wiederholungen,
• Zeitüberschreitungen und Fortsetzungen,
• Werkzeugaufrufe,
• externe Such-, Ausführungs- oder Datenbankdienste,
• gegebenenfalls Credits aus einem Abonnement,
• Kosten für die Entwicklungs- und Laufzeitumgebung.

Der entscheidende Punkt ist die Abnahme. Eine Antwort, die formal erzeugt wurde, aber keinen gültigen Patch, kein korrektes JSON oder keinen bestandenen Test liefert, ist für einen produktiven Agenten noch keine erfolgreiche Aufgabe.

Die offiziellen Dokumentationen liefern dafür die Rechenfaktoren, nicht aber Ihre tatsächliche Erfolgsquote. DeepSeek beschreibt die Abrechnung als Tokenmenge multipliziert mit dem jeweiligen Preis. Alibaba Cloud Model Studio dokumentiert ebenfalls eine Eingabe- und Ausgabeformel sowie gesonderte Rabatte für Kontext-Caching. Die reale Wirtschaftlichkeit entsteht aber erst durch Ihre Nutzungsprotokolle. (Dokumentation zur DeepSeek-Tokenabrechnung)

Warum die drei Abrechnungsmodelle nicht direkt vergleichbar sind

Bei Qwen3.8-Max müssen mindestens Vorschau- und reguläre Modellkennungen getrennt bleiben. Die offizielle Model-Studio-Dokumentation führt Qwen3.8-Max-Preview in einem Werkzeugkontext auf, während die aktuell sichtbare Preisübersicht andere Qwen-Max-Modellstände und regionale Bereitstellungsbereiche ausweist. Daraus darf keine Credits-zu-Token-Relation abgeleitet werden. Modell-ID, Tarif, Zeitraum und verwendete Werkzeuge gehören in getrennte Felder. (Alibaba-Dokumentation zu Credits und Werkzeugnutzung)

Bei Kimi K3 liegt der Schwerpunkt auf der Frage, welche Einheiten die API tatsächlich zurückmeldet und ob Eingaben als Cache-Treffer oder Cache-Fehltreffer klassifiziert werden. Die offizielle Kimi-API-Übersicht nennt kimi-k3 als verfügbares Spitzenmodell für langfristige Programmier- und Wissensaufgaben. Für die Kostenberechnung sollten Sie die offizielle K3-Preisseite und den tatsächlichen usage-Block der API verwenden, nicht Drittanbieterpreise oder pauschale Angaben aus Community-Beiträgen. (offizielle Kimi-API-Übersicht)

Bei DeepSeek V4 ist die Trennung in Cache-Treffer, Cache-Fehltreffer und Ausgabe in der offiziellen Preisdokumentation ausdrücklich sichtbar. DeepSeek V4-Flash und V4-Pro werden dort jeweils mit einem Kontextfenster von 1 Million Token, einer maximalen Ausgabe von 384.000 Token sowie unterschiedlichen Parallelitätsgrenzen beschrieben. Diese Werte sind keine Empfehlung für ein bestimmtes Modell, sondern zeigen, warum lange Aufgaben und gleichzeitige Agentenläufe getrennt budgetiert werden müssen. (offizielle DeepSeek-V4-Preisübersicht)

Ein Preisvergleich ohne diese Trennung erzeugt drei typische Verzerrungen:

1. Ein günstiger Einzelaufruf wirkt vorteilhaft, obwohl der Agent häufiger scheitert.
2. Ein hoher Ausgabeanteil wird übersehen, weil nur die Eingabekosten betrachtet werden.
3. Ein theoretischer Cache-Rabatt wird eingerechnet, obwohl die Anwendung den Kontext bei jeder Anfrage verändert.

Erste Auswertung: Vier Felder bestimmen Ihre Rechnung

Für jeden Anbieter und jeden Testfall sollten wir mindestens die folgenden Felder erfassen:

• Modell und Modell-ID: einschließlich Vorschau-, Datums- oder Regionalvariante;
• Eingabe: Token ohne Cache-Treffer und Token mit Cache-Treffer;
• Ausgabe: gesamte abrechenbare Ausgabe, nicht nur der sichtbare Endtext;
• Aufgabenstatus: erfolgreich, abgebrochen, fehlgeschlagen oder wiederholt.

Für Agenten kommen drei weitere Felder hinzu:

• Anzahl der Werkzeugaufrufe,
• Ursache jeder Wiederholung,
• Kosten externer Dienste und der Laufzeitumgebung.

Bei Qwen3.8-Max beziehungsweise einer Vorschauvariante sollten Sie zusätzlich festhalten, ob die Nutzung über ein Credits-Paket, eine direkte Tokenabrechnung oder ein eingebautes Werkzeug erfolgte. In der offiziellen Alibaba-Dokumentation werden Werkzeugaufrufe in bestimmten Angeboten pro erfolgreicher Ausführung aus Credits belastet. Dieser Verbrauch darf nicht stillschweigend mit einer normalen Modellanfrage vermischt werden. (Alibaba-Dokumentation zur Credits-Nutzung)

Für DeepSeek V4 sollte der Nutzungsblock der API direkt gespeichert werden. Die offizielle Dokumentation nennt unter anderem Cache-Treffer- und Cache-Fehltreffer als eigene Abrechnungsgrößen. Wenn Ihr Gateway diese Felder entfernt, ist die Abrechnung nicht mehr ausreichend transparent für einen fairen Vergleich. (DeepSeek-Hinweise zu Abrechnung und Nutzung)

Bei Kimi K3 gilt dasselbe Prinzip: Nicht der Wert aus einer Werbe- oder Drittanbieterübersicht, sondern die Kombination aus offizieller Preisregel, Modell-ID und API-Nutzungsantwort gehört in die Kostenrechnung.

Lange Dokumente brauchen drei getrennte Testläufe

Lange Kontexte verändern die Rangfolge der Anbieter, weil nicht jede Anfrage denselben Anteil wiederverwendbarer Eingaben enthält. Ein unveränderter Systemprompt, ein festes Repository-Handbuch oder eine gleichbleibende API-Spezifikation kann cachefähig sein. Ein laufend veränderter Diff, ein neuer Fehlerlog oder eine wechselnde Aufgabenbeschreibung kann dagegen einen großen Teil des Kontextes aus dem Cache herausfallen lassen.

Wir empfehlen drei Testläufe:

1. Kaltstart: Der vollständige Kontext wird erstmals übertragen.
2. Kontinuität: Derselbe Kontext wird in einer Folgesitzung wiederverwendet.
3. Kontextänderung: Ein wesentlicher Abschnitt wird ersetzt oder ergänzt.

Für jeden Lauf speichern Sie Eingabelänge, Cache-Status, Ausgabelänge, Bearbeitungsstatus und Gesamtverbrauch. Erst anschließend lässt sich beurteilen, ob der konkrete Arbeitsablauf von Cache-Wiederverwendung profitiert.

DeepSeek dokumentiert für V4 ein Kontextfenster von 1 Million Token und separate Preise für Cache-Treffer und Cache-Fehltreffer. Alibaba Cloud beschreibt bei seinen Qwen-Modellen ebenfalls Kontext-Caching und weist darauf hin, dass Rabatte nur auf bestimmte Eingabetoken angewendet werden. Daraus folgt keine allgemeine Rangliste: Ein Cache-Vorteil ist nur so groß wie der wiederverwendbare Anteil Ihres tatsächlichen Prompts. (Dokumentation zum Kontext-Caching bei Alibaba Cloud)

Achtung: Ein längerer Kontext ist nicht automatisch ein günstiger Kontext. Wenn ein Agent vor jedem Schritt den gesamten Verlauf neu strukturiert, zusammenfasst oder mit wechselnden Anweisungen versieht, kann die erwartete Cache-Ersparnis deutlich kleiner ausfallen als in einer statischen Preisrechnung.

Für Datenschutz und DSGVO-Bewertung sollte außerdem dokumentiert werden, welche Inhalte in einem persistenten Kontext oder serverseitigen Cache verbleiben. Die Kostenseite und die Datenkontrolle gehören in dieselbe Beschaffungsprüfung. Ein nominell günstiger Cache ist kein Vorteil, wenn sensible Quelltexte oder Kundendaten deshalb nicht verwendet werden dürfen.

Programmier-Agenten rechnen pro Lösungsweg, nicht pro Anfrage

Ein Programmier-Agent führt selten nur einen Modellaufruf aus. Ein typischer Ablauf kann aus Aufgabenanalyse, Dateisuche, Änderungsvorschlag, Werkzeugausführung, Fehlermeldung, Korrektur und Testprüfung bestehen. Wenn der Test scheitert, entstehen weitere Modell- und Werkzeugkosten. Die letzte erfolgreiche Antwort ist deshalb nur ein Teil der Rechnung.

Für jeden Agentenlauf sollten wir eine Ablaufkette speichern:

1. Nutzerauftrag mit eindeutiger Aufgaben-ID anlegen.
2. Jede Modellanfrage mit Zeitstempel und Modell-ID protokollieren.
3. Eingabe-, Cache- und Ausgabetoken aus der API-Antwort übernehmen.
4. Jeden Werkzeugaufruf mit Status und externer Kostenquelle erfassen.
5. Wiederholungen nach Ursache klassifizieren: Modellfehler, Werkzeugfehler, Timeout oder ungültiges Ergebnis.
6. Die technische Abnahme anhand eines Tests, eines Schemas oder einer manuellen Freigabe durchführen.
7. Alle Kosten bis zur Abnahme addieren.

Eine Anfrage, die wegen eines fehlerhaften Werkzeugaufrufs erneut gesendet wird, ist kein kostenloser Nebenschritt. Ebenso darf eine Zeitüberschreitung nicht aus der Statistik entfernt werden, wenn bereits Token verbraucht wurden. Für die Beschaffung ist der Gesamtverbrauch pro erfolgreicher Lösung wichtiger als der Preis einer idealisierten Einzelantwort.

Bei hoher Parallelität müssen Sie zusätzlich die Kontingente des jeweiligen Dienstes berücksichtigen. DeepSeek nennt für V4-Flash eine höhere und für V4-Pro eine niedrigere Kontingentgrenze auf Kontoebene. Wird diese Grenze überschritten, können HTTP-429-Fehler entstehen. Die daraus folgenden Wartezeiten, Wiederholungen und Warteschlangen gehören in einen Belastungstest, auch wenn keine separate Gebühr anfällt. (offizielle DeepSeek-Dokumentation zu Ratenlimits)

FAQ: Die vier häufigsten Abrechnungsfehler

Die folgenden Antworten beziehen sich auf die häufigsten Fehlinterpretationen bei gemischten API-Abrechnungen. Entscheidend bleiben die zum Testzeitpunkt geltenden offiziellen Preis- und Nutzungsseiten.

Qwen3.8-Max Credits sind kein versteckter Tokenpreis

Credits können nur dann in Tokenkosten umgerechnet werden, wenn der Anbieter eine stabile, offiziell dokumentierte Relation veröffentlicht und diese Relation für denselben Tarif, dieselbe Modell-ID und denselben Zeitraum gilt. Bei Vorschauangeboten, Werkzeugen und Paketlimits ist das häufig nicht gegeben.

Die belastbare Alternative lautet:

Credits pro erfolgreicher Aufgabe = verwendete Credits ÷ erfolgreich abgenommene Aufgaben

Wenn die Plattform zusätzlich Tokenwerte liefert, können Sie beide Angaben parallel speichern. Die Tokenwerte ersetzen aber nicht automatisch die Credits-Rechnung.

Kimi K3 und DeepSeek V4 müssen Cache-Zustände getrennt ausweisen

Ein Cache-Treffer und ein Cache-Fehltreffer sind nicht dieselbe Eingabeart. Verwenden Sie deshalb zwei separate Spalten und berechnen Sie:

Eingabekosten = Cache-Fehltreffer × Preis für Fehltreffer + Cache-Treffer × Preis für Treffer

Dazu kommen die Ausgabekosten. Bei wechselnden Sitzungen sollten Sie nicht mit einer pauschalen Cache-Quote arbeiten, sondern die tatsächlichen API-Nutzungsdaten aus mehreren Testläufen übernehmen. Die offiziellen Kimi- und DeepSeek-Dokumentationen sind dafür die maßgeblichen Quellen. (Kimi-API-Dokumentation zur Nutzung)

Die Agentenkosten steigen durch erfolglose Zwischenstände

Eine Agentenaufgabe besteht aus dem gesamten Lösungsweg. Wenn ein Agent fünf Anfragen benötigt und nur die fünfte Antwort akzeptiert wird, werden die ersten vier nicht aus der Kostenrechnung entfernt. Das gilt auch dann, wenn sie für den Menschen unsichtbar waren.

Besonders teuer werden:

• lange Ausgaben mit umfangreichen Zwischenschritten,
• wiederholte Werkzeugaufrufe,
• erneutes Übertragen großer Repository-Ausschnitte,
• fehlende Abbruchbedingungen,
• automatische Fortsetzung nach Timeouts.

Die wichtigste Kennzahl lautet deshalb nicht „Kosten pro Anfrage“, sondern „Kosten pro akzeptierter Lösung“.

Bei zu wenig Daten ist eine Rangliste unseriös

Wenn nur wenige Aufgaben vorliegen oder die Testfälle stark voneinander abweichen, sollten Sie keine Gesamtwertung veröffentlichen. Führen Sie stattdessen parallele Testläufe mit identischen Eingaben, gleichen Abnahmekriterien und getrennten Cache-Zuständen durch.

Erst wenn die Kostenverteilung stabil genug ist, können Sie eine Entscheidung für ein bestimmtes Einsatzgebiet treffen. Andernfalls bleibt eine bedingte Empfehlung sinnvoller als ein künstlicher Gesamtsieger.

Entscheidungswerkzeug: Ankreuzbare Entscheidungsbedingungen

Die folgende Entscheidungsbedingungen-Liste ist ein direkt nutzbares Auswahlwerkzeug. Setzen Sie bei jeder zutreffenden Aussage ein Kreuz. Folgen Sie anschließend ausschließlich dem angegebenen Ergebnis. Wenn mehrere Bedingungen gleichzeitig zutreffen, hat die speziellere Bedingung für Agenten, Datenschutz oder Selbsthosting Vorrang vor einem allgemeinen Tokenpreisvergleich.

• [ ] Credits-Abrechnung: Wird Qwen3.8-Max über ein Credits-Modell getestet und ist keine offiziell dokumentierte Credits-zu-Token-Relation verfügbar?
  Wenn ja: Wählen Sie „Credits pro erfolgreicher Aufgabe“ als Hauptkennzahl.
  Wenn nein: Führen Sie Credits und Token getrennt als Kontrollwerte und vermischen Sie die Einheiten nicht.

• [ ] Cache-Nutzung: Werden Kimi K3 oder DeepSeek V4 in langen, wiederholten Sitzungen mit wiederverwendbarem Kontext eingesetzt?
  Wenn ja: Wählen Sie den Anbieter mit den niedrigeren gemessenen Kosten bei gleicher Erfolgsquote und getrennten Cache-Zuständen.
  Wenn nein: Gewichten Sie Cache-Rabatte nicht künstlich und vergleichen Sie zunächst Eingabe, Ausgabe und Erfolgsquote.

• [ ] Kurze Einzelanfragen: Besteht der Arbeitsablauf überwiegend aus kurzen, voneinander unabhängigen Anfragen?
  Wenn ja: Bewerten Sie Eingabe-, Ausgabe- und Fehlerkosten pro erfolgreicher Aufgabe.
  Wenn nein: Ergänzen Sie Kaltstart, Kontinuität und Kontextänderung als eigene Testgruppen.

• [ ] Programmier-Agent: Nutzt der Agent Werkzeuge, korrigiert er Fehler oder setzt er nach Zeitüberschreitungen automatisch fort?
  Wenn ja: Wählen Sie ausschließlich nach den End-to-End-Kosten pro akzeptierter Lösung; Einzelaufrufpreise sind nur Nebenkennzahlen.
  Wenn nein: Die Kosten pro erfolgreicher Modellantwort können zusätzlich zur Aufgabenkennzahl verwendet werden.

• [ ] Externe Dienste: Werden Suche, Codeausführung, Datenbanken oder andere Werkzeuge separat berechnet?
  Wenn ja: Führen Sie diese Beträge in einer eigenen Kostenzeile und rechnen Sie sie bis zur Abnahme mit.
  Wenn nein: Protokollieren Sie trotzdem Werkzeugstatus und Wiederholungen, weil auch kostenfreie Fehler zusätzliche Modellaufrufe erzeugen können.

• [ ] Datenschutz und Betriebsstabilität: Überschreiten Datenkontrolle, Standortanforderungen oder Dienstunterbrechungen die intern zulässige Toleranz?
  Wenn ja: Prüfen Sie offene Gewichte und Selbsthosting als Alternativen.
  Wenn nein: Bleibt die Last schwankend und der Testzeitraum begrenzt, ist die API meist der einfachere Betriebsweg.

• [ ] Ausreichende Datenbasis: Sind Aufgaben, Abnahmekriterien, Modell-IDs und Nutzungsfelder vergleichbar dokumentiert?
  Wenn nein: Geben Sie noch keine Gesamtempfehlung ab, sondern führen Sie parallele Testläufe fort.
  Wenn ja: Formulieren Sie eine Empfehlung je Einsatzfall statt einer allgemeinen Rangliste.

Dieses Entscheidungswerkzeug liefert bewusst keine pauschale Reihenfolge „Qwen3.8-Max vor Kimi K3 vor DeepSeek V4“. Es ordnet zuerst die richtige Kennzahl zu und verhindert dadurch, dass ein einzelnes günstiges Preisfeld den gesamten Beschaffungsentscheid bestimmt.

Vom Testprotokoll zur Einkaufsentscheidung

Vor dem nächsten Budgetgespräch sollten Sie eine Woche lang dieselben Felder erfassen:

1. Aufgaben-ID und Aufgabentyp festlegen.
2. Modell-ID und Tarifvariante speichern.
3. Eingabe-, Cache- und Ausgabetoken exportieren.
4. Credits-Verbrauch separat protokollieren.
5. Werkzeugaufrufe und externe Kosten hinzufügen.
6. Wiederholungsgrund und Zeitüberschreitung markieren.
7. Erfolgsprüfung dokumentieren.
8. Kosten pro erfolgreicher Aufgabe berechnen.
9. Ergebnisse nach Kaltstart, Folgegespräch und Kontextänderung gruppieren.
10. Nur Aufgaben mit identischen Abnahmekriterien vergleichen.

Für die technische Umsetzung genügt zunächst eine strukturierte CSV- oder JSON-Datei. Wichtig ist nicht das verwendete Auswertungssystem, sondern dass die Rohdaten unverändert erhalten bleiben. Preisänderungen sollten mit Datum, Modell-ID und Quelle versioniert werden. Alibaba Cloud weist auf regionale Bereitstellungsbereiche und zeitlich begrenzte Preisaktionen hin; deshalb dürfen Vorschaupreise, Nacht- oder Aktionsrabatte und reguläre Preise nicht in einer einzigen historischen Spalte landen.

Wenn Sie bereits mit Mac-basierter Automatisierung arbeiten, kann ein stabiler Testknoten die Vergleichbarkeit verbessern: gleiche Projektdateien, gleiche Umgebungsvariablen, gleiche Werkzeuge und reproduzierbare Zeitüberschreitungen. Informationen zu einer solchen Cloud-Mac-Umgebung für Agententests sollten jedoch getrennt von den reinen API-Kosten ausgewiesen werden. Die Umgebung ist ein zusätzlicher Kostenblock, nicht Teil des Tokenpreises.

Eine Qwen3.8-Max-Konfiguration im lokalen Laufzeitkontext kann für bestimmte offene oder lokale Modelle relevant sein, beantwortet aber nicht automatisch die Kostenfrage der drei hier verglichenen APIs. Ebenso sollte ein aktueller Qwen-Kostenhinweis nicht als Ersatz für die jeweils offizielle Preis- und Nutzungsdokumentation dienen.

API oder eigener Mac: der nächste Prüfpunkt

Die API bleibt meist die einfachere Lösung, wenn der Bedarf schwankt, mehrere Modelle kurzfristig getestet werden sollen oder keine eigene Betriebsverantwortung gewünscht ist. Sie zahlen dann verbrauchsabhängig und vermeiden die Anschaffung eines dauerhaft ausgelasteten Systems.

Ein reines API-Modell hat aber reale Nachteile: Preise und Modell-IDs können sich ändern, Cache-Regeln sind nicht immer über Anbieter hinweg vergleichbar, sensible Inhalte verlassen die eigene Umgebung, und Dienstunterbrechungen oder Kontingentgrenzen können Agentenläufe verzögern. Bei stabiler Dauerlast, strengen Datenschutzanforderungen oder notwendiger Offline-Verfügbarkeit kann ein eigener Mac deshalb wirtschaftlich und organisatorisch sinnvoller sein. Auch dort müssen Strom, Wartung, Arbeitsspeicher, Modellkompatibilität und Betriebszeit eingerechnet werden.

Wenn die einwöchige Auswertung zeigt, dass Wiederholungen, Umgebungsstabilität oder die Prüfung eines selbst betriebenen Modells den größten Kostenanteil verursachen, sollten Sie nicht länger nur Tokenpreise vergleichen. Für zeitlich begrenzte PoCs, reproduzierbare Agententests und wechselnde Modellversuche kann das Mieten einer Mac-Umgebung über JexMac die praktischere Zwischenstufe sein: Sie behalten die API flexibel, erhalten aber einen kontrollierbaren Rechner für Tests, Deployment und Abnahme. Einen passenden Einstieg finden Sie über die JexMac-Angebotsübersicht.

Beginnen Sie vor einer Kauf- oder Bereitstellungsentscheidung mit dem Export einer Woche API-Nutzung und erfolgreicher Aufgaben. Erst wenn Credits, Token, Cache, Wiederholungen und Werkzeugkosten in derselben Rechnung stehen, ist sichtbar, ob Qwen3.8-Max, Kimi K3 oder DeepSeek V4 für Ihren konkreten Arbeitsablauf tatsächlich günstiger ist.

FAQ