DeepSeek erhöht die API-Preise um bis zu 1.100 Prozent – und kippt damit jede Make-or-Buy-Rechnung
Am 13. August 2026 hat DeepSeek mit DeepSeek-V4-Pro-0813 zugleich eine Preisreform angekündigt, die seit dem 16. August gilt: Peak- und Off-Peak-Tarife mit Aufschlägen von 50 bis rund 1.100 Prozent. Damit bricht der wichtigste Preisanker des LLM-Marktes weg – ausgerechnet in der Budgetplanung für 2027.
DeepSeek hat seine API-Preise am 16.08.2026 um 16:00 UTC auf Peak- und Off-Peak-Tarife umgestellt. Der Spitzenwert von rund 1.100 Prozent betrifft nur eine einzige Zeile: Cache-Hit-Input bei V4-Pro, der von 0,003625 auf 0,044 USD je Mio. Tokens steigt.
Realistisch verteuert sich ein typischer Workload im Peak um Faktor 3 bis 4,5, off-peak um Faktor 1,5 bis 2,3. Entscheidend ist nicht die Höhe, sondern die Vorlaufzeit: drei Tage zwischen Ankündigung und Wirksamkeit, ohne Bestandsschutz.
Der günstigste ernstzunehmende Frontier-Anbieter war über zwei Jahre hinweg der stille Referenzpunkt jeder Wirtschaftlichkeitsrechnung im deutschen Mittelstand. Wer eine Make-or-Buy-Entscheidung gegen eigene Hardware gerechnet hat, hat sie fast immer gegen DeepSeek-Preise gerechnet – weil das die Untergrenze war. Seit dem 16. August 2026 existiert dieser Anker nicht mehr in der Form.
Was DeepSeek angekündigt hat, ist keine Preisanpassung im üblichen Sinn. Es ist ein Wechsel des Preismodells: von einem flachen Tarif je Million Tokens zu einer zeitabhängigen Staffelung mit Peak- und Off-Peak-Fenstern. Dieser Beitrag rechnet nach, was das konkret kostet, wo die Schlagzeile in die Irre führt und ab welchem Volumen der eigene Server tatsächlich die günstigere Option ist.
Was sich zum 16. August 2026 konkret geändert hat
Vorgewarnt hatte DeepSeek bereits am 6. August 2026 – damals ohne Zahlen und ohne Datum. Die konkrete Tabelle kam am 13. August, gemeinsam mit dem Release von DeepSeek-V4-Pro-0813. Wirksam wurde sie am 16. August 2026 um 16:00 UTC, was 18:00 Uhr MESZ entspricht und in Peking bereits dem 17. August um Mitternacht Ortszeit. Genau deshalb datieren einige Meldungen die Umstellung auf den 17. August: Es ist derselbe Moment, nur eine andere Zeitzone.
Bis dahin galt seit dem Launch von V4-Flash und V4-Pro am 24. April 2026 ein einziger, flacher Satz je Modell und Preisbestandteil. Seither gibt es für jede Zeile zwei Preise. Die vollständige Gegenüberstellung in USD je Million Tokens:
| Position | alt (flat) | neu Off-Peak | neu Peak | Peak vs. alt |
|---|---|---|---|---|
| V4-Flash · Cache-Hit-Input | 0,0028 | 0,007 | 0,014 | +400 % |
| V4-Flash · Cache-Miss-Input | 0,14 | 0,22 | 0,44 | +214 % |
| V4-Flash · Output | 0,28 | 0,66 | 1,32 | +371 % |
| V4-Pro · Cache-Hit-Input | 0,003625 | 0,022 | 0,044 | +1.114 % |
| V4-Pro · Cache-Miss-Input | 0,435 | 0,66 | 1,32 | +203 % |
| V4-Pro · Output | 0,87 | 1,98 | 3,96 | +355 % |
Drei Beobachtungen aus dieser Tabelle sind für die Budgetplanung relevanter als jede Schlagzeile:
- Off-Peak ist exakt die Hälfte von Peak. DeepSeek formuliert das wörtlich so – es gibt keine Zwischenstufen, keine Volumenrabatte, keine Staffel nach Kontingent.
- Die Untergrenze der Erhöhung liegt bei rund 52 Prozent. Das ist der V4-Pro-Cache-Miss-Input off-peak: von 0,435 auf 0,66 USD. Selbst im günstigsten Fenster zahlen Sie also anderthalbmal so viel wie vorher.
- Der Spitzenwert ist eine Randposition. Die +1.114 Prozent betreffen ausschließlich Cache-Hit-Input bei V4-Pro. Diese Zeile kostet auch nach der Erhöhung nur 0,044 USD je Million Tokens – absolut die billigste Position der gesamten Preisliste.
Die Schlagzeile richtig lesen: „+1.100 Prozent" klingt nach einer Verzwölffachung der Rechnung. Real steigt ein typischer Workload im Peak um Faktor 3 bis 4,5, off-peak um Faktor 1,5 bis 2,3. Wer mit dem Maximalwert plant, überschätzt sein Budget massiv – wer die Erhöhung deshalb kleinredet, unterschätzt sie ebenso. Rechnen Sie mit Ihrem eigenen Token-Mix, nicht mit der Extremzeile.
Warum die deutsche Vormittagsspitze voll in den Peak-Tarif fällt
Die Peak-Fenster liegen bei 01:00–04:00 und 06:00–10:00 UTC – laut offizieller DeepSeek-Dokumentation ausdrücklich nur von Montag bis Freitag. Das sind sieben Stunden an fünf Tagen, also 35 von 168 Wochenstunden oder rund 21 Prozent der Woche. Wochenenden sind durchgehend off-peak, ebenso jede Stunde außerhalb der beiden Fenster.
Umgerechnet auf deutsche Zeit ergibt sich ein klares Bild:
- Sommerzeit (MESZ, UTC+2): Peak von 03:00–06:00 und 08:00–12:00 Uhr.
- Winterzeit (MEZ, UTC+1): Peak von 02:00–05:00 und 07:00–11:00 Uhr.
Vom deutschen Arbeitstag fällt damit nur der Vormittag in den teuren Tarif – der Nachmittag ab 12:00 Uhr MESZ, der Abend, die Nacht und das gesamte Wochenende sind off-peak. Wer behauptet, deutsche Nutzer zahlten grundsätzlich den Höchstpreis, überzeichnet. Wer die Fenster ignoriert, zahlt trotzdem drauf, denn genau in diesen vier Vormittagsstunden liegt der Lastschwerpunkt der meisten Unternehmen: Daily-Standups mit Protokollzusammenfassung, die morgendliche Ticket-Triage im Support, der Nightly-Batch, der um 07:30 Uhr fertig sein soll, und die erste Welle interaktiver Assistenzanfragen nach Arbeitsbeginn.
Die praktische Konsequenz ist eine Zweiteilung Ihrer Last:
- Verschiebbar: Nächtliche Dokumentenverarbeitung, Embedding-Läufe, Klassifikation großer Backlogs, Report-Generierung. Diese Jobs können ohne Qualitätsverlust nach 12:00 Uhr MESZ oder aufs Wochenende wandern und halbieren dort ihren Preis.
- Nicht verschiebbar: Interaktive Assistenz, Agenten in Geschäftsprozessen, Chat-Frontends, alles mit Nutzer am anderen Ende. Diese Last liegt dort, wo Menschen arbeiten – und der deutsche Vormittag ist Peak.
Es entsteht damit eine Zeitzonen-Arbitrage als versteckter Kostentreiber: Ein Unternehmen mit reinen Batch-Lasten kann seine Rechnung nahezu halbieren, ein Unternehmen mit interaktivem LLM-Frontend nicht. Zwei Firmen mit identischem Token-Volumen zahlen künftig unterschiedlich viel – abhängig allein davon, wann ihre Nutzer auf Enter drücken.
Die neue Kostenformel: mit dem Peak-Tarif als Worst Case rechnen
Eine belastbare Jahreskalkulation braucht jetzt eine Dimension mehr. Die Grundformel lautet:
Jahreskosten = (Tokens/Tag × Peak-Anteil × Peak-Tarif + Tokens/Tag × (1 − Peak-Anteil) × Off-Peak-Tarif) × Arbeitstage
getrennt gerechnet für Cache-Hit-Input, Cache-Miss-Input und Output – die drei Positionen haben unterschiedliche Steigerungsraten und lassen sich nicht sinnvoll mitteln.
Der Peak-Anteil ist der Parameter, den fast alle Planungen falsch ansetzen. Ihn aus der Kalenderverteilung abzuleiten (21 Prozent der Woche) ist irreführend, weil Ihre Last nicht gleichverteilt ist. Ziehen Sie stattdessen die tatsächlichen Zeitstempel aus Ihren API-Logs der letzten 30 Tage und bilden Sie den Anteil der Tokens, die in den Peak-Fenstern angefallen sind. In der Praxis liegt dieser Wert bei interaktiven Anwendungen häufig zwischen 30 und 45 Prozent, bei reinen Batch-Systemen unter 10 Prozent.
Solange diese Messung fehlt, ist es vertretbar, konservativ mit dem reinen Peak-Tarif zu rechnen – aber deklarieren Sie das als bewussten Worst Case, nicht als Durchschnittspreis. Sonst überschätzen Sie die realen Kosten um bis zu Faktor 2 und treffen die Make-or-Buy-Entscheidung auf falscher Grundlage.
Prompt-Caching verliert einen Teil seines Hebels
Prompt-Caching war bisher das wirksamste Kostenwerkzeug bei DeepSeek: Ein Cache-Hit kostete bei V4-Pro nur ein 120stel eines Cache-Miss (0,003625 gegenüber 0,435 USD). Nach der Reform liegt dieses Verhältnis bei 1 zu 30 (0,044 gegenüber 1,32 USD im Peak). Der Hebel wirkt weiter, aber schwächer – und vor allem: Er wirkt nun auf einer absolut höheren Basis. Ein Agent mit 60.000 Tokens Systemprompt und Werkzeugbeschreibungen, der 500-mal am Tag im Peak feuert, verursacht allein aus Cache-Hits rund 1,32 USD täglich statt zuvor 0,11 USD.
Reasoning-Tokens vervielfachen die Outputseite
Die schmerzhafteste Position ist Output: 3,96 USD je Million Tokens bei V4-Pro im Peak. Bei Modellen mit ausgedehnten Denkschritten ist der sichtbare Antworttext nur ein Bruchteil der abgerechneten Output-Tokens. Wenn ein Modell für eine 300-Token-Antwort 4.000 Reasoning-Tokens verbraucht, zahlen Sie das Vierzehnfache dessen, was die Antwortlänge suggeriert. Bei einem Modell mit Mixture-of-Experts-Architektur ändert das nichts an der Abrechnungslogik – abgerechnet wird pro erzeugtem Token, nicht pro aktiviertem Parameter.
Rechenbeispiel: Support-Assistent mit 1.200 Anfragen pro Arbeitstag
Ein mittelständischer Maschinenbauer betreibt einen internen Support-Assistenten auf V4-Flash. Profil je Anfrage: 12.000 Tokens Cache-Hit-Input (fester Systemprompt und Produktkatalog), 3.000 Tokens Cache-Miss-Input (Ticketverlauf), 900 Tokens Output. Gemessener Peak-Anteil: 38 Prozent.
Alt (flat): 12.000 × 0,0028 + 3.000 × 0,14 + 900 × 0,28 = 0,000034 + 0,00042 + 0,000252 ≈ 0,00070 USD je Anfrage → rund 0,84 USD/Tag → ca. 220 USD/Jahr.
Neu: Off-Peak 0,00126 USD, Peak 0,00252 USD je Anfrage. Gewichtet mit 38 Prozent Peak: 0,00174 USD → rund 2,09 USD/Tag → ca. 545 USD/Jahr.
Faktor 2,5 auf die Jahresrechnung – nicht Faktor 12. Absolut bleibt der Betrag klein. Genau das ist der Punkt: Bei diesem Volumen ist die Erhöhung ärgerlich, aber irrelevant. Kritisch wird sie erst dort, wo Token-Volumen in Milliardenhöhe anfällt – und dort kippt sie die Rechnung sofort.
Der eigentliche Punkt: Preisrisiko ist kein Preis, sondern ein Risiko
Die Zahlen sind die eine Hälfte der Geschichte. Die andere ist die Vorlaufzeit. Zwischen der detaillierten Ankündigung am 13. August und der Wirksamkeit am 16. August lagen drei Tage – ein Wochenende inklusive. Kein Unternehmen migriert in drei Tagen eine produktive KI-Integration auf einen anderen Anbieter, und keine Budgetfreigabe läuft in dieser Geschwindigkeit durch ein Controlling.
Was in dieser Konstellation fehlt, ist juristisch bemerkenswert unspektakulär und praktisch entscheidend:
- Keine Preisgarantie. Die veröffentlichten Sätze sind Listenpreise ohne Bindungsfrist. Was heute gilt, kann in vier Wochen anders sein.
- Kein Bestandsschutz. Die neuen Tarife gelten für alle API-Nutzer, unabhängig davon, seit wann sie Kunde sind oder welches Volumen sie fahren.
- Keine SLA-Kompensation. Es gibt keinen Mechanismus, der eine Preiserhöhung mit einer Leistungszusage koppelt oder einen Ausstieg ohne Nachteil ermöglicht.
- Keine Modellstabilität. Ein API-Modellname kann jederzeit auf eine neue Gewichtsversion zeigen. Ihre evaluierten Prompts gelten dann für ein Modell, das es so nicht mehr gibt.
DeepSeek begründet die Umstellung damit, Ressourcen „sinnvoller zu verteilen": Die Zeitstaffelung soll Entwickler-Workloads in weniger ausgelastete Fenster verschieben. Das ist betriebswirtschaftlich nachvollziehbar und aus Anbietersicht sogar elegant. Für den Einkauf bedeutet es allerdings, dass der Preis eines Vorleistungsguts künftig von der Auslastungssituation eines Rechenzentrums in einer anderen Zeitzone abhängt – einer Größe, die Sie weder beobachten noch beeinflussen können.
Das Muster ist nicht neu. Es wiederholt, was bei früheren Preiserhöhungen am Frontier-Markt zu beobachten war: Erst wird über Kampfpreise Marktanteil aufgebaut, dann wird auf einer installierten Basis nachgezogen, die technisch gebunden ist. Wer seine Prozesse an einer API festmacht, kauft nicht nur Rechenleistung ein, sondern akzeptiert ein offenes Preisrisiko in der eigenen Kostenstruktur.
Gegenrechnung: V4 ist open-weight – aber nicht in jeder Größe realistisch
Der bemerkenswerte Teil der Geschichte: Die Preiserhöhung betrifft ausschließlich den API-Zugang. DeepSeek-V4-Pro-0813 steht unverändert unter MIT-Lizenz als Open-Weight-Modell auf Hugging Face bereit. Es sind dieselben Gewichte, die hinter dem teurer gewordenen Endpunkt rechnen – und sie dürfen ohne Lizenzgebühr, ohne Nutzungsbeschränkung und ohne Tarifzeiten im eigenen Rack betrieben werden.
Die technischen Eckdaten von V4-Pro-0813: 1 Million Tokens Kontextfenster, maximal 384K Output-Tokens, ergänzt um ein DSpark-Modul für Speculative Decoding. Die empfohlenen Sampling-Parameter der Modellkarte liegen für agentische Szenarien bei temperature = 1.0 und top_p = 0.95. Die Benchmark-Werte des August-Release zeigen den Sprung gegenüber der April-Preview deutlich: Terminal-Bench 2.1 von 72,1 auf 87,9, DeepSWE von 12,8 auf 62,7, dazu NL2Repo 61,5, CyberGym 83,3, Toolathlon-Verified 74,1 und 42,7 Prozent auf Humanity's Last Exam (60,0 Prozent mit Werkzeugzugriff). Der Artificial Analysis Intelligence Index weist 53 Punkte aus.
Die harte Einschränkung: V4-Pro-0813 hat 1,7 Billionen Parameter. Das ist auf einem einzelnen Mittelstands-Server nicht lauffähig – dafür braucht es Multi-Node-Cluster im hohen sechs- bis siebenstelligen Bereich. Die MIT-Lizenz erlaubt Self-Hosting rechtlich, macht es für diese Zielgruppe aber wirtschaftlich nicht darstellbar. Der ehrliche On-Premise-Pfad führt über kleinere Open-Weight-Modelle, nicht über V4-Pro.
Das ist keine Absage an Self-Hosting, sondern eine Präzisierung der Frage. Sie lautet nicht „Kann ich V4-Pro selbst betreiben?", sondern „Erreicht ein Modell, das ich selbst betreiben kann, die Qualität, die mein Anwendungsfall tatsächlich braucht?" Für Ticket-Klassifikation, Dokumentenextraktion, RAG-Antworten auf eigener Wissensbasis und strukturierte Zusammenfassungen lautet die Antwort seit etwa einem Jahr durchgängig ja – dafür genügen Modelle in der Klasse von 30 bis 120 Milliarden Parametern, die auf zwei bis vier professionellen GPUs laufen. Für autonome Software-Agenten mit langen Werkzeugketten lautet sie weiterhin nein.
Zwei Vorteile des Eigenbetriebs bleiben unabhängig von der Modellgröße bestehen: Die Grenzkosten je Anfrage sind Strom und Abschreibung, nicht ein Listenpreis. Und die Modellversion bleibt eingefroren, bis Sie sie ändern – es gibt keine Deprecation von außen, die Ihre evaluierten Prompts über Nacht ungültig macht.
Break-even: ab welchem Volumen sich der eigene Server trägt
Damit die Rechnung ehrlich bleibt, wird hier nicht V4-Pro-API gegen einen Mittelstands-Server gerechnet – das wären ungleiche Dinge. Verglichen wird der Betrieb eines selbst hostbaren Open-Weight-Modells der Flash-Klasse gegen den V4-Flash-API-Tarif.
Die Kostenseite des Eigenbetriebs
| Position | Annahme | pro Monat |
|---|---|---|
| Hardware-Abschreibung | Inferenz-Node mit 4 GPUs, 45.000 €, 36 Monate | 1.250 € |
| Strom | 2,2 kW × 24 h × 30 d × 0,22 €/kWh | 350 € |
| Betrieb & Wartung | Monitoring, Updates, Rack, Backup | 400 € |
| Summe | Vollkosten, unabhängig von der Auslastung | 2.000 € |
Die Vergleichsseite: was dieselbe Last per API kostet
Zugrunde gelegt wird dasselbe Anfrageprofil wie im Rechenbeispiel oben, vereinfacht auf 8.000 Tokens Cache-Miss-Input und 800 Tokens Output je Anfrage. Zum V4-Flash-Peak-Tarif: 8.000 × 0,44 / 1.000.000 = 0,00352 USD plus 800 × 1,32 / 1.000.000 = 0,001056 USD, zusammen rund 0,0046 USD oder etwa 0,0042 € je Anfrage.
Damit ergibt sich der Break-even:
- gegen den Peak-Tarif: 2.000 € ÷ 0,0042 € ≈ 476.000 Anfragen pro Monat, also rund 21.600 pro Arbeitstag.
- gegen den Off-Peak-Tarif: rund 950.000 Anfragen pro Monat, also etwa 43.000 pro Arbeitstag.
- gegen den alten Flat-Tarif: es waren rund 1,4 Millionen Anfragen pro Monat nötig – die Preisreform hat die Schwelle also etwa gedrittelt.
Das ist die ernüchternde und zugleich nützliche Erkenntnis: Rein über den Tokenpreis rechnet sich ein eigener Server erst bei erheblichem Volumen. Der dominierende Faktor ist dabei nicht der Anschaffungspreis, sondern die Auslastung. Ein Node, der zu 8 Prozent ausgelastet läuft, kostet dieselben 2.000 € wie einer bei 70 Prozent – nur verteilen sich diese Kosten auf ein Neuntel der Anfragen. Wer 40 statt 8 Prozent Auslastung erreicht, senkt seine Kosten je Anfrage um denselben Faktor, ohne einen Euro zusätzlich zu investieren. Deshalb ist das Bündeln mehrerer Anwendungsfälle auf einer Inference-Instanz wirtschaftlich wirksamer als jede Hardware-Optimierung.
Zwei Ergänzungen, die die reine Tokenrechnung nicht abbildet: Erstens rechtfertigen Datenschutz, Geschäftsgeheimnisse und Auftragsverarbeitungspflichten den Eigenbetrieb oft schon weit unterhalb des Break-even – dann ist der Server keine Kostenoptimierung, sondern eine Compliance-Entscheidung. Zweitens ist das Hybrid-Modell in den meisten Fällen die rationalste Antwort: Grundlast und alles mit personenbezogenen oder vertraulichen Daten läuft lokal auf eigenem Modell, Spitzen und Aufgaben, die echte Frontier-Qualität brauchen, gehen über die API – bewusst und mit gedeckeltem Budget. Welche Last in welchen Topf gehört, lässt sich im Vergleich Cloud gegen On-Premise und mit dem TCO-Rechner für die eigenen Zahlen durchspielen.
Praxisbeispiel: Dokumentenverarbeitung bei einem Versicherungsmakler
Ein Makler mit 40 Innendienst-Mitarbeitern verarbeitet monatlich rund 900.000 API-Anfragen zur Extraktion von Vertragsdaten aus eingescannten Policen – überwiegend nachts als Batch, also off-peak. Bei 0,0042 € je Anfrage im Peak beziehungsweise 0,0021 € off-peak lag die Rechnung vor der Reform bei rund 700 €, danach bei rund 1.900 € monatlich. Der Break-even gegen einen eigenen Node liegt hier knapp erreicht – ausschlaggebend für die Entscheidung war am Ende jedoch nicht der Preis, sondern dass die Policen personenbezogene Gesundheitsdaten enthalten und die Verarbeitung ohnehin im Haus bleiben musste. Die Preisreform hat lediglich das Argument geliefert, das Projekt zwei Quartale vorzuziehen.
Was jetzt konkret zu tun ist
- Peak-Anteil messen. Zeitstempel der letzten 30 Tage auswerten und den tatsächlichen Anteil der Tokens in den Fenstern 01–04 und 06–10 UTC (Mo–Fr) bestimmen.
- Last sortieren. Jede Integration danach klassifizieren, ob sie verschiebbar ist. Alles Verschiebbare aus dem Vormittagsfenster herausnehmen – das halbiert dort den Preis sofort.
- Budget mit Bandbreite planen. Nicht mit einem Preis, sondern mit einem Korridor aus Off-Peak- und Peak-Szenario rechnen und den Puffer explizit ausweisen.
- Exit-Fähigkeit herstellen. Anwendungen gegen eine OpenAI-kompatible Schnittstelle bauen, damit ein Anbieterwechsel oder der Wechsel auf ein lokales Modell eine Konfigurations- und keine Projektentscheidung ist.
- Break-even nachrechnen. Mit den eigenen Volumina prüfen, ob die Schwelle für eine lokale Grundlast bereits überschritten ist – die Reform hat sie um rund zwei Drittel gesenkt.
Quellen & Primärbelege
Alle Zahlen, Fristen und Produktangaben in diesem Beitrag wurden vor der Veröffentlichung gegen die folgenden Primärquellen geprüft.
- DeepSeek API Docs – Pricing Offizielle Preistabelle, Peak-Fenster 01–04 und 06–10 UTC, Mo–Fr, Off-Peak = halber Peak-Tarif
- Hugging Face – DeepSeek-V4-Pro-0813 Modellkarte: MIT-Lizenz, 1 Mio. Kontext, 384K Output, 1,7 Bio. Parameter, Sampling-Parameter
- DataNorth – DeepSeek releases V4-Pro-0813 Release am 13.08.2026, Verfügbarkeit in App, Web (Expert Mode) und API
- AI Pricing Guru – Peak/Off-Peak Update Gegenüberstellung alter und neuer Sätze je Preisbestandteil
- BenchLM – DeepSeek API Pricing Historische Preisreihe seit dem V4-Launch am 24.04.2026
- Quartz – DeepSeek API price increase Einordnung der Spanne von rund 50 bis 1.100 Prozent
- Investing.com – DeepSeek raises API pricing Stichtag 16.08.2026, 16:00 UTC und Begründung des Anbieters
- Dataconomy – Vorankündigung vom 06.08.2026 Erste Ankündigung ohne Zahlen und ohne Datum
- Mercatus AI – Peak/Off-Peak Hours Umrechnung der Peak-Fenster in europäische Zeitzonen
Häufig gestellte Fragen zur DeepSeek-Preisreform
Gilt die Preiserhöhung auch für Bestandskunden?
Ja. Die neuen Peak- und Off-Peak-Tarife gelten seit dem 16. August 2026 für alle API-Nutzer, es gibt keinen Bestandsschutz und keine Übergangsfrist.
Kann ich die Kosten durch Verschieben auf Off-Peak halbieren?
Nur für Batch-Lasten. Off-Peak kostet die Hälfte des Peak-Tarifs, aber interaktive Assistenz und Agenten laufen zwingend in der Kernarbeitszeit, die in den Peak-Fenstern liegt.
Ist DeepSeek V4 wirklich selbst hostbar?
Ja, DeepSeek-V4-Pro-0813 ist unter MIT-Lizenz open-weight. Die Hardware-Anforderungen sind allerdings erheblich – die Flash-Variante ist für den Mittelstand die realistischere Größe.
Ab wann lohnt sich ein eigener GPU-Server gegenüber der API?
Entscheidend ist die Auslastung, nicht das Nutzungsvolumen allein. Bei konstanter Grundlast mit hoher GPU-Auslastung amortisiert sich eigene Hardware typischerweise binnen weniger Quartale.
Wie hoch ist Ihr Preisrisiko wirklich?
Wir rechnen Ihren tatsächlichen Token-Mix gegen Peak-, Off-Peak- und Eigenbetriebs-Szenarien durch – und sagen Ihnen ehrlich, ab wann sich ein eigener Server trägt und ab wann nicht.