DeepSeek V4 Preise: 20-50x günstiger als OpenAI (Kostenaufschlüsselung)
Let me provide the German translation directly:
Vor kurzem suchte ich nach einem günstigeren Modell, etwas, das ich häufig aufrufen könnte, ohne ständig auf die Kosten zu achten. DeepSeek V4 wurde in Gesprächen mit anderen Entwicklern ständig erwähnt, normalerweise mit hochgezogener Augenbraue: “Es ist… wirklich billig.”
Dora ist da. Ich habe die zweite Hälfte des Januar 2026 damit verbracht, es in ein paar kleine Workflows zu integrieren: einen Recherche-Zusammenfasser, einen Produktnotiz-Umschreiber und einen wöchentlichen Backlog-Organizer. Nichts Besonderes. Mich interessierte, wie sich die Tokens in echte Dollar über eine normale Woche umrechnen. Hier ist, was ich über DeepSeek V4 API-Kosten, die Rabatte, die zählen, und eine einfache Möglichkeit gelernt habe, es vor dem Deployment zu budgetieren.

Aktuelle DeepSeek-Preise
Ich werde so tun, als wären die Zahlen stabil. Die Preise ändern sich, und sie unterscheiden sich je nachdem, wo du Zugriff kaufst (direkt vs. über einen Makler wie OpenRouter). Also zwei Ankerpunkte:
- Überprüfe die Quelle: die offizielle DeepSeek API-Dokumentation und Preisseite. Das sind die kanonischen Tarife, wenn du direkt verbindest.
- Wenn du über einen Marktplatz routest, öffne ihre Modellkarte. Zum Beispiel listen die DeepSeek-Modelle auf OpenRouter die Pro-Million-Token-Tarife und zeitbasierte Rabatte auf.

Was ich Ende Januar 2026 über verschiedene Anbieter hinweg sah, war konsistent in der Art: DeepSeek V4 liegt deutlich unter den Top-Modellen für sowohl Input- als auch Output-Tokens. Die genauen Cents variieren. Ich teile, wie ich mit den Preisen arbeite, anstatt sie festzulegen.
Standardtarife
Wenn du neu bei der verwendungsbasierten Modellabrechnung bist, sind zwei Zeilen wichtig:
- Input-Tokens (was du sendest): berechnet pro 1M Tokens.
- Output-Tokens (was du zurückbekommst): auch berechnet pro 1M Tokens, normalerweise höher als Input.
In meinen Durchläufen waren V4’s rohe Tarife niedrig genug, dass kleine tägliche Spitzen nicht wehtat. Das zeigt sich am meisten bei Batch-Jobs. Zum Beispiel sendet mein wöchentlicher Backlog-Organizer ~20 Prompts von ~3–5K Input-Tokens und erhält ~1–2K Output-Tokens. Selbst mit konservativen Beispieltarifen blieb der Gesamtpreis für den ganzen Durchlauf in der “Kaffeegeldzone”.
Zwei praktische Punkte:
- Output-Inflation schleicht sich ein. Wenn deine Prompts lange Gedanken fördern, kann die Output-Zeile deine Rechnung verdoppeln. Ich begrenzte max_tokens und machte den Stil straffer. Geld gespart, bessere Ergebnisse.
- Chunk-Größe ist wichtig. Wenn du lange Dokumente zusammenfasst, zahlst du für jeden überlappenden Token. Ich wechselte von 1.600-Token-Überlappung zu 400 und verlor keine Qualität.
Cache-Hit-Rabatte (90% Rabatt)
Das änderte meine Rechnung. Einige Plattformen und Modellhersteller unterstützen Prompt-Caching für wiederholte Präfixe. Wenn deine ersten N Tokens des Prompts sich nicht ändern (System-Nachricht, gemeinsame Anweisungen, Schema), können Cache-Hits mit einem steilen Rabatt berechnet werden. 90% Rabatt ist die Zahl, die ich in der Dokumentation einiger Anbieter für Caching-Implementierungen gesehen habe (Verfügbarkeit variiert: bestätigen auf der Preisseite deines Anbieters).
Wie das in der Praxis aussah:
- Mein Recherche-Zusammenfasser teilt einen langen, festen System-Prompt und ein stabiles Tool-Schema. Nur der Quelltext ändert sich.
- Nach dem ersten Aufruf treffen nachfolgende Aufrufe den Cache für diesen gemeinsamen Präfix.
- Auf Plattformen, die Cache-Abrechnung respektieren, fielen diese wiederverwendeten Tokens auf den reduzierten Tarif.
Zwei Vorsichtsmaßnahmen aus Tests:
- “Fast gleich” wird nicht gecacht. Ändere eine Zeile im gemeinsamen Präfix und du verfehlst den Hit.
- Große, feste Schemas zahlen sich selbst. Wenn du Anweisungen und Tools in einen stabilen Präfix konsolidieren kannst, tu es einmal und reite den Cache.
Wenn dein Anbieter Caching nicht offenlegt, kannst du immer noch einige Einsparungen simulieren, indem du wiederholte Anleitungen in einen kürzeren, konsistenten System-Prompt verschiebst und Redundanzen aus Benutzermeldungen entfernst.
Off-Peak-Rabatte (75% Rabatt)
Ein paar Marktplätze haben angefangen, zeitbasierte Rabatte anzubieten, um die Nachfrage zu glätten. Ich habe Off-Peak-Fenster mit steilen Kürzungen gesehen (Zahlen wie 50–75% Rabatt erscheinen, hängen aber vom Reseller und dem Modell ab). DeepSeek-Modelle neigen dazu, teilzunehmen, weil ihre Wirtschaft bereits effizient ist.
Zwei Wege, wie das mir geholfen hat:
- Ich habe meinen wöchentlichen Backlog-Job für das Off-Peak-Fenster geplant. Gleicher Workload, niedrigerer Posten.
- Ich habe Recherche-Zusammenfassungen über Nacht gebündelt. Die Latenz spielte keine Rolle, und der Rabatt tat es.
Das ist nicht universell. Wenn du dich direkt mit DeepSeek verbindest, überprüfe, ob sie zeitgestaffelte Preise veröffentlichen. Wenn du über einen Makler gehst, lies das Kleingedruckte der Modellkarte. Die Spanne kann groß genug sein, um zu ändern, wann du Dinge laufen lässt.
Warum DeepSeek so billig ist

Ich wollte verstehen, ob der niedrige Preis eine Werbeaktion war oder ob die Architektur ihn tatsächlich unterstützt. Aus dem Öffentlichen stachen zwei Punkte heraus.
MoE-Architektur
DeepSeeks neuere große Modelle stützen sich auf Mixture-of-Experts (MoE). Einfach ausgedrückt: anstatt das ganze Gehirn für jeden Token aufzuwecken, wählt der Router ein paar Expert-Subnetzwerke aus, um ihn zu handhaben. Du bekommst immer noch ein fähiges Modell, aber nur ein Bruchteil der Parameter arbeitet pro Schritt, was Berechnung und Kosten senkt.
Warum das in der Praxis wichtig ist:
- Der Durchsatz skaliert besser. Auf meiner Seite blieb die p95-Latenz angemessen, selbst wenn ich parallele Jobs vorantrieb.
- Die Kosten steigen nicht linear mit der Komplexität. Lange Prompts bestraften nicht so hart wie bei dichten, ständig aktiven Modellen.
Ich habe andere MoE-Modelle verwendet, die sich bei Nischen-Tasks spröde anfühlten: V4 verarbeitete struktur-schwere Prompts (JSON-Ausgaben, Tool-Verwendung) ohne zu wackeln. Diese Stabilität ist auch Teil der Kostengeschichte: weniger Wiederholungen, weniger Neustarts.
Engram-Effizienz
DeepSeeks Docs erwähnen Arbeit an Kontextbehandlung und Speichereffizienz (sie heben Dinge wie verbesserte Attention-Routing und KV-Cache-Behandlung in einigen Versionen hervor). Ich kann die Interna nicht überprüfen, aber ich kann teilen, was ich beobachtet habe:
- Lange-Kontext-Prompts zerstörten den Durchsatz in meinen Tests im Januar 2026 nicht. Ich lief 32K-Token-Kontexte ohne das “alles wird zur Melasse”-Gefühl.
- Deterministische Formatierung hielt sich bei höherer Temperatur besser als ich erwartet hatte, was bedeutete, dass ich Ausgaben kürzer halten konnte, ohne die Qualität zusammenbrechen zu lassen.
Meine Lesart: Der Preis ist kein Marketing-Trick. Es ist das Ergebnis einer Architektur, die darauf ausgelegt ist, die Berechnung pro Token niedrig zu halten, plus eine Bereitschaft, das in den Aufkleberpreis zu übernehmen. Wenn du neugierig auf die technischen Notizen bist, beginne mit der offiziellen DeepSeek-Dokumentation und allen verknüpften Papieren von ihren Modellkarten.

Kostenrechner-Template
Ich sperre Budgets nicht mehr auf genaue Cents. Ich plane Bereiche, dann passe ich an, sobald die reale Nutzung sich beruhigt. Hier ist das Template, das ich für DeepSeek V4 verwendet habe. Es ist einfach genug, um in einer Tabelle nachzubilden.
Eingaben, die du pro Workload ausfüllst:
- Aufrufe pro Tag (oder pro Batch)
- Durchschn. Input-Tokens pro Aufruf
- Durchschn. Output-Tokens pro Aufruf
- Input-Tarif pro 1M Tokens (von deinem Anbieter)
- Output-Tarif pro 1M Tokens (von deinem Anbieter)
- Cacheable-Präfix-Tokens pro Aufruf (0, wenn keine)
- Cache-Hit-Rabatt (z.B. 0,90 für 90% Rabatt)
- Off-Peak-Multiplikator (z.B. 0,25, wenn 75% Rabatt, sonst 1)
Schritte:
-
Trenne cacheable und nicht-cacheable Input-Tokens.
- cacheable_input = cacheable_prefix_tokens
- variable_input = max(avg_input_tokens - cacheable_prefix_tokens, 0)
-
Berechne den cacheablen Teil zum rabattierten Tarif.
- cacheable_cost = (cacheable_input / 1.000.000) × input_rate × (1 − cache_hit_discount)
-
Berechne den variablen Input zum vollen Input-Tarif.
- variable_input_cost = (variable_input / 1.000.000) × input_rate
-
Berechne die Ausgabe zum Ausgabe-Tarif.
- output_cost = (avg_output_tokens / 1.000.000) × output_rate
-
Addiere sie pro Aufruf, dann wende jeden Off-Peak-Multiplikator an.
- raw_cost_per_call = cacheable_cost + variable_input_cost + output_cost
- cost_per_call = raw_cost_per_call × off_peak_multiplier
-
Skaliere nach Volumen.
- daily_cost = cost_per_call × calls_per_day
- monthly_cost ≈ daily_cost × 30
Ein kleines, echtes Beispiel aus meiner Testwoche (23.–30. Januar 2026):
- 120 Aufrufe/Tag
- 3.200 Input-Tokens/Aufruf, davon 1.800 ein fester, cacheabler Präfix
- 1.100 Output-Tokens/Aufruf
- Beispieltarife: $0,40 pro 1M Input, $1,60 pro 1M Output (ersetze mit deinen Aktuellen)
- Cache-Hit-Rabatt: 90%
- Off-Peak-Multiplikator: 0,5 (50% Rabatt-Fenster über einen Reseller verwendet)
Mathematik (gerundet):
- Cacheable-Kosten pro Aufruf = (1.800/1.000.000) × $0,40 × (1 − 0,90) ≈ $0,0000072
- Variable Input-Kosten pro Aufruf = (1.400/1.000.000) × $0,40 ≈ $0,00056
- Output-Kosten pro Aufruf = (1.100/1.000.000) × $1,60 ≈ $0,00176
- Rohe Kosten pro Aufruf ≈ $0,0023272
- Off-Peak-angepasst ≈ $0,0011636
- Täglich ≈ $0,14
- Monatlich ≈ $4,20
Das ist kein Tippfehler. Die niedrigen Pro-Million-Tarife plus Caching und Off-Peak verwandelten einen “Meter-Anschauen”-Service in etwas, das ich vergessen kann. Es sparte anfangs keine Zeit, ich verbrauchte eine Stunde, um den cacheablen Präfix wirklich fest zu machen, aber jeden Aufruf danach wurde billiger.
Ein paar Leitplanken, die ich im Sheet halte:
- Setze harte Grenzen für max_tokens. Output-Aufblähung ist der stille Budget-Killer.
- Verfolgue Wiederholungen separat. Wiederholungen sind echte Ausgaben.
- Protokolliere durchschnittliche Tokens wöchentlich. Token-Drift passiert, wenn sich Prompts entwickeln.
Wer das passt:
- Teams, die viele kleine, ähnliche Aufrufe ausführen (ETL, Zusammenfassung, QA).
- Maker mit Batch-Jobs, die zu Off-Peak verschoben werden können.
Wer es möglicherweise nicht mag:
- Apps, die den ganzen Tag über lange, Streaming-Ausgaben brauchen, zum Peak-Zeitpunkt. Die Einsparungen verengen sich.
- Setups ohne Caching-Unterstützung. Du zahlst immer noch niedrige Tarife, aber nicht die absurd niedrigen.
Wenn du einen Startpunkt möchtest, baue das obige Template in dein Werkzeug deiner Wahl um. Das sind 10 Minuten Setup und spart später Stunden des Ratens.
Eine letzte Anmerkung: Wenn du Anbieter mischt, normalisiere alles auch auf “Kosten pro 1K Tokens” in deinem Sheet. Es macht schnelle Seite-an-Seite-Vergleiche einfacher, wenn du entscheidest, ob du V4 in der Schleife hältst oder eine Task aus Qualitätsgründen zu einem Top-Modell wechselst.
Ich beobachte immer noch, wie sich die Off-Peak-Fenster verschieben. Neuerdings haben sie sich früher am Abend verschoben. Kein Problem für Batch-Jobs, nur etwas, das ich im Auge behalte.





