Anmerkung des Autors: Seit die DeepSeek API Peak-/Off-Peak-Preise und Gebühren für Tool-Aufrufe eingeführt hat, ist die alte Schätzung „Einzelpreis × Token“ hinfällig. Dieser Artikel zeigt in fünf Schritten, wie sich die tatsächlichen Kosten einer Anwendung entlang von vier Dimensionen neu berechnen lassen: Zeitfenster, Token-Typ, Caching und Tool-Aufrufe.
Viele Kostentabellen von Entwicklern bleiben auf der Ebene „Eingabepreis × Input-Token + Ausgabepreis × Output-Token“ stehen. Seit die DeepSeek API Peak-/Off-Peak-Preise und Gebühren für Tool-Aufrufe eingeführt hat, fehlen dieser Formel zwei Variablen: zu welchem Zeitfenster die Anfrage läuft und wie oft Tools aufgerufen werden. Bei derselben Anwendung und identischem Token-Verbrauch kann die Rechnung deutlich anders aussehen, wenn man sie zu einer anderen Tageszeit laufen lässt.
Dies ist kein Artikel, der nur Preise abschreibt. Hier werden keine ungeprüften Einzelpreise genannt – für alle Preise, Zeitfenster-Rabatte und Cache-Regeln gelten die Echtzeitdaten auf der Preisseite von APIYI unter docs.apiyi.com/models sowie die offiziellen Ankündigungen von DeepSeek. Worum es hier geht, ist die Methode: Wie setzt man eine Preistabelle korrekt auf die eigenen Betriebslogs an, sobald man sie in der Hand hat?
Der Kernnutzen: Nach der Lektüre hast du ein wiederverwendbares Framework zur Kostenkalkulation der DeepSeek API in der Hand. Du kannst einschätzen, welche Anfragen sich in die Off-Peak-Zeit verschieben lohnen und bei welchen Tool-Aufrufen sich straffen lässt – und du weißt, wo du belastbare Preisdaten herbekommst.
Kostenschwerpunkte nach der Peak-/Off-Peak-Preisgestaltung der DeepSeek API
In letzter Zeit wird die kommerzielle Ausrichtung von DeepSeek in den Medien deutlich häufiger diskutiert (zum Beispiel im Bericht von 36Kr „Liang Wenfeng steigt vom Berg herab – wonach sucht DeepSeek?“). Auch die Veränderungen der Preisstruktur sind für Entwickler ein zentrales Thema. Unabhängig von der Geschäftslogik dahinter ist der unmittelbarste Effekt für Aufrufer: Das Kostenmodell ist von „eindimensional“ zu „mehrdimensional“ geworden. Die folgende Tabelle schlüsselt die neue Kostenstruktur zunächst auf.
| Kostendimension | Erläuterung | Auswirkung auf die Kalkulation |
|---|---|---|
| Zeitfenster-Koeffizient | Für Peak- und Off-Peak-Zeiten gelten unterschiedliche Abrechnungssätze | Requests müssen nach Anfragezeit in Buckets getrennt erfasst werden; Tagesdurchschnittswerte sind ungeeignet |
| Input-Token (Cache-Treffer) | Der Teil der Eingabe, der den Kontext-Cache trifft | Der Stückpreis unterscheidet sich vom Cache-Miss-Teil und muss separat erfasst werden |
| Input-Token (Cache-Miss) | Eingaben, die zum ersten Mal auftreten oder deren Cache ungültig ist | Bei Anwendungen mit langem System-Prompt ist dieser Anteil am größten |
| Output-Token | Enthält die Denkprozess-Token von Reasoning-Modellen | Die Ausgabemenge von Reasoning-Modellen wird oft unterschätzt |
| Tool-Aufrufgebühr | Nutzung von Tools, abgerechnet z. B. nach Anzahl der Aufrufe | Neuer separater Kostenposten, der zusätzlich Token verursacht |
Die konkreten Preisangaben fehlen in der Tabelle bewusst. DeepSeeks Preise wurden in der Vergangenheit mehrfach angepasst; zwischenzeitlich gab es nächtliche Off-Peak-Rabatte, später wurde die Strategie wieder geändert. Wer die an einem Tag gesehenen Zahlen fest in das Kostenmodell eincodiert, hat nach einigen Monaten falsche Daten im Modell. Richtig ist, den Stückpreis als „Eingabeparameter“ des Modells zu behandeln und ihn in Echtzeit von der Preisseite zu laden.
Wichtige Details zur zeitabhängigen Abrechnung der DeepSeek API
Im Kern geht es bei der Peak-/Off-Peak-Preisgestaltung darum, Zeiten ungenutzter Rechenkapazität vergünstigt an Aufgaben weiterzugeben, die sich verzögert ausführen lassen. Für die Kalkulation sind drei Details am fehleranfälligsten. Erstens die Zeitzone: Offizielle Zeitfenster sind üblicherweise in Peking-Zeit (UTC+8) definiert, während viele Server-Logs standardmäßig UTC aufzeichnen. Ohne Umrechnung landen ganze Request-Batches im falschen Bucket. Zweitens Requests, die Zeitfenster überschreiten: Ein langer Streaming-Request kann in der Peak-Zeit beginnen und in der Off-Peak-Zeit enden. Ob nach Start- oder Endzeit abgerechnet wird, muss man den offiziellen Regeln entnehmen. Drittens Wiederholungen: Ein fehlgeschlagener und erneut gesendeter Request kann in ein anderes Zeitfenster fallen; gerechnet werden sollte mit der Zeit des tatsächlich erfolgreichen Requests.
Wichtige Details zur Tool-Abrechnung der DeepSeek API
Die Falle bei der Tool-Abrechnung ist die „Doppelabrechnung“. Bei Tools wie der Websuche kann ein Aufruf nicht nur eine nutzungsabhängige Tool-Gebühr auslösen; die vom Tool zurückgegebenen Ergebnisse werden außerdem in den Kontext eingefügt und in der nächsten Runde als Input-Token ein weiteres Mal abgerechnet. Ruft das Modell in einem Gesprächsverlauf hintereinander drei- oder viermal ein Tool auf, wächst der Token-Aufwand mit dem akkumulierten Kontext kontinuierlich an. Bei der Kalkulation von Tool-Kosten müssen daher sowohl die „Anzahl der Aufrufe“ als auch die „zusätzlichen Input-Token durch Tool-Ergebnisse“ erfasst werden. Beides ist unverzichtbar.
DeepSeek-API-Aufrufkosten: Schnelleinstieg mit 5 Schritten zur Neuberechnung
Der folgende Ablauf erfordert keinen Code – ein Log-Export plus Tabellenkalkulation reicht aus. Wenn Sie bereits eine Datenplattform betreiben, übertragen Sie diese Schritte einfach in SQL oder Berichte.
Schritt 1: Preistabelle vorbereiten
Erstellen Sie zunächst eine „Preisparameter-Tabelle“, in der jede Zeile eine Abrechnungsvariable repräsentiert. Alle Stückpreise werden von der Preisseite übernommen und mit dem Abrufdatum dokumentiert. Dieser Schritt entscheidet über die Genauigkeit aller nachfolgenden Berechnungen.
| Variablenname | Bedeutung | Datenquelle |
|---|---|---|
| Eingabepreis bei Cache-Treffer während der Peak-Zeit | Eingabepreis bei einem Cache-Treffer während der Peak-Zeit | APIYI-Preisseite docs.apiyi.com/models |
| Eingabepreis bei Cache-Miss während der Peak-Zeit | Eingabepreis bei einem Cache-Miss während der Peak-Zeit | APIYI-Preisseite docs.apiyi.com/models |
| Ausgabepreis während der Peak-Zeit | Preis für Ausgabe-Token während der Peak-Zeit | APIYI-Preisseite docs.apiyi.com/models |
| Entsprechende drei Preise während der Off-Peak-Zeit | Preise für Eingabe, Cache und Ausgabe während der Off-Peak-Zeit | APIYI-Preisseite und offizielle Ankündigungen |
| Preis pro Tool-Aufruf | Abrechnungslogik und Preis pro Tool-Typ | APIYI-Preisseite und offizielle Ankündigungen |
| Zeitfenstergrenzen | Beginn und Ende von Peak- und Off-Peak-Zeit inklusive Zeitzone | Offizielle Ankündigungen von DeepSeek |
💡 Empfehlung zur Datenquelle: Gleichen Sie die Preisparameter-Tabelle regelmäßig mit der APIYI-Preisseite docs.apiyi.com/models ab und vermerken Sie in der Tabelle das „Abrufdatum“. Sobald die offiziellen Preise angepasst werden, müssen Sie nur diese Tabelle ändern – das gesamte Kostenmodell greift automatisch.
Schritt 2: Nutzungsprotokolle mit Zeitstempel exportieren
Jeder Anforderungs-Log sollte mindestens diese Felder enthalten: Startzeit der Anfrage, Modellname, Anzahl der Eingabe-Token, davon die Anzahl der per Cache-Treffer gesparten Token, Anzahl der Ausgabe-Token, Anzahl der Tool-Aufrufe sowie den Tool-Typ. Im usage-Feld der DeepSeek-Antwort werden Statistiken zu Cache-Treffern und -Fehlschlägen zurückgegeben; bei Reasoning-Modellen zählen die Denk-Token ebenfalls zu den Ausgabe-Token. Wenn Ihr Log nur die Gesamtzahl der Token erfasst, sollten Sie die Instrumentierung zuerst vervollständigen – andernfalls bleiben alle späteren Berechnungen grobe Schätzungen.
Schritt 3: Nach Zeitfenstern gruppieren
Rechnen Sie alle Zeitstempel einheitlich in Pekinger Zeit um und versehen Sie dann jede Anfrage anhand der Tarifgrenzen mit dem Label „Peak“ oder „Off-Peak“. Empfehlenswert ist zusätzlich eine feinere Unterteilung pro Stunde: So erkennen Sie die Wellenform Ihres Geschäftsverkehrs und gewinnen eine Grundlage für die spätere Steuerung. Viele Teams stellen erst nach diesem Schritt fest, dass ein beträchtlicher Anteil ihrer Anfragen actually aus geplanten Jobs stammt und problemlos in die Off-Peak-Zeit verschoben werden könnte.
Schritt 4: Token-Kosten und Tool-Kosten getrennt berechnen
Für jeden Zeitfenster-Bucket separat berechnen: Token-Kosten = Eingabe mit Cache-Treffer × jeweiliger Stückpreis + Eingabe mit Cache-Miss × jeweiliger Stückpreis + Ausgabe × jeweiliger Stückpreis; Tool-Kosten = Anzahl der Aufrufe je Tool-Typ × jeweiliger Tool-Stückpreis. Anschließend werden die beiden Buckets Peak und Off-Peak addiert – das ergibt die Gesamtkosten nach der neuen Berechnungsmethode.
Ein Beispiel nur mit Mengen, ohne Preise: Angenommen, eine Kundenservice-Anwendung verzeichnet durchschnittlich 10.000 Anfragen pro Tag, jede Eingabe umfasst im Schnitt 3.000 Token, davon etwa 60 % Cache-Treffer, die Ausgabe beträgt 500 Token, und durchschnittlich löst jede fünfte Anfrage ein Suchtool aus. Dann entstehen pro Tag etwa 12 Millionen Eingabe-Token mit Cache-Treffer, etwa 18 Millionen Eingabe-Token mit Cache-Miss, etwa 5 Millionen Ausgabe-Token und rund 2.000 Tool-Aufrufe – hinzu kommen zusätzliche Eingabe-Token, die durch die Rückgabe der Tool-Ergebnisse entstehen. Teilt man diese Mengen im Peak-/Off-Peak-Verhältnis auf und multipliziert sie mit den Stückpreisen aus der Preistabelle, erhält man die tatsächlichen Tageskosten.
Schritt 5: Mit der alten Berechnungsmethode vergleichen und Optimierungspotenzial finden
Stellen Sie das Ergebnis der neuen Methode dem alten „einheitlichen Durchschnittspreis“-Ansatz nebeneinander gegenüber – der Teil mit der größten Differenz ist der Schwerpunkt für Optimierungen. Typische Erkenntnisse lassen sich in drei Kategorien einteilen: zu hoher Anteil in Peak-Zeiten, zu häufige Tool-Aufrufe und eine zu niedrige Cache-Trefferquote. Im nächsten Abschnitt werden für diese drei Kategorien konkrete Vorgehensweisen vorgestellt.
🚀 Schnellstart: Wenn Sie die Kostenunterschiede zwischen DeepSeek und anderen Modellen unter derselben API testen möchten, können Sie sie über APIYI unter apiyi.com aufrufen. APIYI stellt die in diesem Artikel behandelten DeepSeek-Modell-APIs bereit und ist gleichzeitig mit den API-Formaten von OpenAI und Anthropic kompatibel. Bei bestehendem Code müssen in der Regel nur base_url und API-Schlüssel geändert werden, um die Integration durchzuführen. Die konkreten Adressen und Parameter finden Sie im Dokumentationszentrum docs.apiyi.com.
Anwendungsszenarien und Kostenstrategien für das Peak-/Off-Peak-Preismodell der DeepSeek API
Verschiedene Anwendungstypen reagieren sehr unterschiedlich empfindlich auf Peak-/Off-Peak-Preise und Tool-Gebühren. Zuerst sollte man bestimmen, zu welcher Kategorie man gehört, und dann die Optimierungsrichtung festlegen – das ist effektiver, als pauschal „alles nachts laufen zu lassen“.
| Anwendungstyp | Zeitliche Flexibilität | Tool-Abhängigkeit | Empfohlene Strategie | Verfügbare Plattformen |
|---|---|---|---|---|
| Online-Kundenservice / Chatbots | Niedrig, muss in Echtzeit antworten | Mittel | Cache-Trefferquote erhöhen, Tool-Aufrufe straffen | APIYI apiyi.com, DeepSeek offiziell |
| Batch-Dokumentenverarbeitung / Datenannotation | Hoch, verzögert ausführbar | Niedrig | Vollständig in Off-Peak-Zeiten einplanen | APIYI apiyi.com, DeepSeek offiziell |
| KI-Suche / Recherche-Assistent | Mittel | Hoch | Tool-Aufrufrunden begrenzen, eingefügte Kontextinhalte komprimieren | APIYI apiyi.com, DeepSeek offiziell |
| Code-Agent | Mittel | Hoch | Tool-Aufrufe zusammenfassen, Kontext verkürzen | APIYI apiyi.com, DeepSeek offiziell |
| Zeitgesteuerte Content-Erzeugung | Hoch | Mittel | In Off-Peak-Zeiten in Batches generieren, in Peak-Zeiten nur prüfen | APIYI apiyi.com, DeepSeek offiziell |
Kostenoptimierung für Echtzeit-Anwendungen mit der DeepSeek API
Echtzeit-Anwendungen können Peak-Zeiten nicht umgehen; der Schwerpunkt sollte daher auf Caching und Tools liegen. Wenn unveränderliche System-Prompts, Wissensdatenbank-Zusammenfassungen und Few-Shot-Beispiele am Anfang der Nachricht stehen und bytegenau unverändert bleiben, lässt sich die Cache-Trefferquote deutlich erhöhen. Bei den Tools kann eine einmalige, leichtgewichtige Prüfung entscheiden, ob eine Suche wirklich nötig ist; so vermeidet man wiederholte Tool-Aufrufe des Modells in unnötigen Fällen.
Off-Peak-Scheduling für Offline-Anwendungen mit der DeepSeek API
Offline-Aufgaben profitieren am stärksten vom Peak-/Off-Peak-Preismodell. Der Ansatz besteht darin, zwischen Geschäftssystem und Modellaufruf eine Aufgabenwarteschlange einzuziehen: In Peak-Zeiten wird nur eingereiht, in Off-Peak-Zeiten verarbeitet ein Consumer die Aufgaben gebündelt. Zwei Punkte sind zu beachten: Erstens ist die Parallelität in Off-Peak-Zeiten gebündelt; Rate Limits sollten vorab bewertet und bei Bedarf in Batches gedrosselt werden. Zweitens sollten Aufgaben eine Timeout-Absicherung erhalten, damit Aufgaben, die in Off-Peak-Zeiten nicht fertig werden, nicht in die nächste Peak-Zeit rutschen und dann zu Hochpreisen abgerechnet werden.
Vergleich von Optimierungsansätzen für die Tool-Kosten bei der DeepSeek API
Die Tool-Abrechnung ist ein neuer Posten – und zugleich derjenige, der am leichtesten außer Kontrolle gerät, weil das Modell selbst über den Verbrauch entscheidet. Die folgende Tabelle stellt gängige Steuerungsmechanismen gegenüber.
| Optimierungsansatz | Einsparquelle | Geeignete Szenarien | Hinweise |
|---|---|---|---|
| Vorgeschaltete Intent-Erkennung | Reduziert unnötige Tool-Aufrufe | Such-Assistenten, Kundenservice | Die Erkennung selbst verbraucht ebenfalls Token, daher eine schlanke Eingabeaufforderung verwenden |
| Maximale Aufrufrunden begrenzen | Deckelt die Tool-Kosten einer einzelnen Anfrage | Agent-Anwendungen | Zu wenige Runden können die Antwortqualität beeinträchtigen |
| Tool-Rückgaben komprimieren | Senkt die Eingabe-Token, die durch das Zurückspielen entstehen | Such- und Retrieval-Tools | Nur Zusammenfassung und Schlüsselfelder behalten |
| Ergebnis-Cache wiederverwenden | Identische Abfragen werden nicht erneut ausgeführt | Szenarien mit vielen wiederkehrenden Fragen | Sinnvolle Ablaufzeit setzen, damit Informationen nicht veralten |
| Eigene Suche als Ersatz | Bezahlte Tools durch eigene Wissensdatenbank ersetzen | Geschäftsbereiche mit stabilem Fachwissen | Eigenbau- und Wartungskosten müssen bewertet werden |
Einordnung des Vergleichs
Die vorgeschaltete Intent-Erkennung wirkt am direktesten auf die Aufrufhäufigkeit und passt zu den meisten Dialogszenarien. Sie verursacht jedoch pro Anfrage einen kleinen zusätzlichen Aufwand für die Erkennung – bei kurzen Dialogen kann sich das unterm Strich nicht lohnen. Dagegen hat das Komprimieren der Tool-Rückgaben praktisch keine Nebenwirkungen und sollte in jeder Anwendung mit Tools standardmäßig aktiviert sein. Das Begrenzen der maximalen Aufrufrunden ist eher eine Sicherung: Sie verhindert, dass einzelne Anfragen durch wiederholte Tool-Aufrufe des Modells eine ungewöhnlich hohe Rechnung erzeugen.
💡 Empfehlung zur Auswahl: Wie stark sich Tool-Kosten optimieren lassen, hängt sehr vom jeweiligen Geschäft ab. Testen Sie die Varianten daher zunächst mit wenig Traffic in einem A/B-Vergleich. Über APIYI apiyi.com können Sie verschiedene Modelle im selben Schnittstellenformat umschalten und gegeneinander testen; zusammen mit den tagesaktuellen Preisen auf der Preisseite docs.apiyi.com/models lässt sich der tatsächliche Nutzen jedes Ansatzes schneller ausrechnen.
Häufig gestellte Fragen (FAQ)
F1: Was ist die Peak-/Off-Peak-Preisgestaltung der DeepSeek API?
Bei der Peak-/Off-Peak-Preisgestaltung gelten für dasselbe Modell je nach Zeitfenster unterschiedliche Abrechnungsmaßstäbe. In der Regel ist der Preis in der Nebenzeiten (Off-Peak) niedriger, um aufschiebbare Aufgaben zur Nutzung von Rechenkapazität außerhalb der Spitzenzeiten zu lenken. Die genauen Zeitfenstergrenzen und Rabattstufen richten sich nach den offiziellen Ankündigungen von DeepSeek sowie der Preisseite von APIYI.
F2: Worin unterscheidet sich die Berechnungsmethode der Peak-/Off-Peak-Preisgestaltung von der früheren einheitlichen Preisgestaltung?
Bei einheitlicher Preisgestaltung genügt „Gesamt-Token × Stückpreis“; bei der Peak-/Off-Peak-Preisgestaltung muss zunächst nach Anfragezeit in Buckets unterteilt, auf jeden Bucket separat der Preis angewendet und anschließend die Tool-Aufrufgebühr addiert werden. Eine Schätzung mit dem Tagesdurchschnittspreis verdeckt die Verzerrung durch den Spitzenzeitenanteil – besonders bei Geschäftsbetrieben, deren Traffic sich auf den Tag konzentriert.
F3: Nach welcher Zeit wird abgerechnet, wenn eine Anfrage die Peak- und Off-Peak-Zeitfenster überschreitet?
Das hängt von den offiziellen Abrechnungsregeln ab. Üblicherweise wird nach der Startzeit der Anfrage gerechnet, aber das sollte man nicht einfach annehmen. Es empfiehlt sich, den „Abrechnungszeitpunkt“ im Berechnungsmodell als konfigurierbaren Parameter anzulegen, ihn nach Bestätigung der offiziellen Regel zu befüllen und lange Streaming-Anfragen separat zu kennzeichnen und stichprobenartig zu prüfen.
F4: Warum lassen Tool-Gebühren die Kosten „explodieren“?
Weil Tool-Aufrufe oft zwei Kostenposten erzeugen: die Aufrufgebühr des Tools selbst und die erneute Abrechnung des Tool-Ergebnisses als Eingabe-Token, nachdem es zurück in den Kontext gefüllt wurde. Bei mehrrundigen Tool-Aufrufen wächst der Kontext stetig, und jede spätere Runde muss für die Ergebnisse der vorherigen mitbezahlen. Deshalb müssen sowohl die Anzahl der Aufrufe als auch die Länge der zurückgefüllten Inhalte kontrolliert werden.
F5: Wie ruft man DeepSeek schnell über die API auf und prüft die Kosten?
Gehen Sie wie folgt vor:
1. Besuchen Sie APIYI apiyi.com, registrieren Sie ein Konto und holen Sie sich den API-Schlüssel
2. Sehen Sie im Dokumentationszentrum docs.apiyi.com die Zugriffsadresse ein und wählen Sie das OpenAI- oder das Anthropic-kompatible Format
3. Suchen Sie auf der Preisseite docs.apiyi.com/models die Stückpreise für Ein-, Ausgabe und Caching der DeepSeek-Modelle
4. Führen Sie mit einer kleinen Traffic-Menge die 5-Schritte-Kalkulation aus diesem Artikel durch und kalibrieren Sie sie gegen Ihre Kontrollabrechnung
APIYI stellt die in diesem Artikel behandelten DeepSeek-Modellaufrufe bereit. Das Schnittstellenformat ist mit gängigen SDKs kompatibel, sodass es sich in bestehenden Projekten direkt zum Testen austauschen lässt.
F6: Sind bei Aufrufen über Drittplattformen die Peak-/Off-Peak- und Tool-Abrechnungsmaßstäbe identisch?
Die Abrechnungsmaßstäbe verschiedener Plattformen können von den offiziellen abweichen, etwa ob Zeitfenster unterschieden werden oder wie Tool-Gebühren umgerechnet werden. Bei Aufrufen über APIYI richten Sie sich bitte nach den tatsächlichen, auf der Preisseite docs.apiyi.com/models von APIYI ausgewiesenen Daten und übernehmen Sie nicht einfach die offizielle Preistabelle. Klärt man dies vor der Berechnung, lassen sich die meisten Abrechnungsfehler vermeiden.
F7: Welche bekannten Einschränkungen gibt es bei der Kostenkalkulation der DeepSeek API?
Es gibt im Wesentlichen drei Punkte. Erstens ändern sich die Preise, das Modell muss also parameterisierte Aktualisierungen unterstützen. Zweitens schwankt die Länge der Denk-Token bei Reasoning-Modellen stark, eine Schätzung nach dem Mittelwert ist mit hoher Abweichung verbunden – hier empfiehlt sich die Verwendung von Quantilen. Drittens entscheidet das Modell selbst über die Anzahl der Tool-Aufrufe; derselbe Prompt unterscheidet sich bei verschiedenen Eingaben deutlich. Daher ist kontinuierliches Monitoring statt einer einmaligen Schätzung nötig.
DeepSeek API: Kernpunkte zur Kostenkalkulation bei Peak-/Off-Peak-Preisen (Key Takeaways)
- Kosten werden mehrdimensional: Zeitfenster, Cache, Ausgabe und Tools bestimmen gemeinsam die Rechnung
- Einzelpreise müssen parametrisiert sein: Maßgeblich sind die tagesaktuellen Werte auf der Preisseite von APIYI – nicht fest im Code hinterlegen
- Zuerst die Zeitzone angleichen: Logs einheitlich in Pekinger Zeit umrechnen und dann den Peak-/Off-Peak-Buckets zuordnen, sonst wird ein ganzer Batch falsch einsortiert
- Tools werden doppelt berechnet: Aufrufgebühr plus zurückgeschriebene Token – beides muss erfasst werden
- Offline-Aufgaben in die Nebenzeiten verschieben: Eine Task-Queue zum Glätten von Lastspitzen ist die Optimierung mit dem direktesten Effekt
- Echtzeit-Aufgaben profitieren vom Cache: Fester Prefix bleibt unverändert und erhöht die Cache-Trefferquote
- Die Kalkulation lässt sich schnell prüfen: Über die kompatible Schnittstelle von APIYI mit wenig Traffic testen und das Modell anhand der Abrechnung kalibrieren
Zusammenfassung
Seit DeepSeek in der API Spitzen- und Nebenzeiten-Tarife sowie eine separate Werkzeuggebühr eingeführt hat, lassen sich die zentralen Änderungen bei der Kostenkalkulation in drei Punkten zusammenfassen:
- Von der Gesamtmenge zur Aufteilung nach Zeitfenstern: Anfragen müssen nach Zeitfenstern aufgeteilt und Spitzen- bzw. Nebenzeiten getrennt berechnet werden, erst dann wird die tatsächliche Kostenstruktur sichtbar
- Von Tokens zu Tokens plus Werkzeugen: Die Werkzeuggebühr ist ein eigener Kostenposten und treibt zusätzlich auch die Input-Tokens nach oben
- Von der statischen Schätzung zur laufenden Überwachung: Preise ändern sich, die Nutzung ändert sich – das Kalkulationsmodell muss parametrisierbar sein und regelmäßig kalibriert werden
Empfehlung: Lassen Sie zuerst den 5-Schritte-Ablauf aus diesem Artikel über die Logs der letzten Woche laufen, um die drei Kernkennzahlen Anteil der Spitzenzeit, Häufigkeit der Werkzeugaufrufe und Cache-Trefferquote zu ermitteln – und optimieren Sie dann gezielt. Wenn Sie DeepSeek und andere Modelle über eine einheitliche Schnittstelle testen möchten, können Sie den Zugang über APIYI apiyi.com einrichten; die Details zur Anbindung finden Sie im Dokumentationszentrum docs.apiyi.com. Alle Stückpreise entnehmen Sie bitte den aktuellen Werten auf der Preisseite docs.apiyi.com/models.
📚 Referenzen
- Bericht von 36Kr: „Liang Wenfeng steigt vom Berg herab – wonach sucht DeepSeek?“
- Link:
36kr.com/p/4055279154779015 -
Anmerkung: Branchenbericht über die jüngsten Kommerzialisierungsaktivitäten von DeepSeek, hilfreich als Hintergrund zum Verständnis der Preisänderungen
-
Preisseite von APIYI: Stückpreise für Input, Output und Cache von DeepSeek und anderen Modellen
- Link:
docs.apiyi.com/models -
Anmerkung: Quelle aller preisbezogenen Parameter in diesem Artikel – bitte vor der Kalkulation abgleichen
-
Dokumentationszentrum von APIYI: Erläuterungen zur Anbindung und zum Schnittstellenformat
- Link:
docs.apiyi.com -
Anmerkung: Enthält Anbindungshinweise für die zu OpenAI und Anthropic kompatiblen Formate
-
Offizielle API-Dokumentation von DeepSeek: Abrechnungsregeln und Erläuterung des Feldes
usage - Link:
api-docs.deepseek.com - Anmerkung: Grenzen der Spitzen- und Nebenzeiten, Cache-Mechanismus und Bemessungsgrundlage der Werkzeugabrechnung richten sich nach der offiziellen Dokumentation
Autor: Technikteam von APIYI
Technischer Austausch: Bei Fragen zur Kostenkalkulation oder zur Anbindung erreichen Sie uns gerne über die offizielle Website apiyi.com; weitere Anbindungsunterlagen finden Sie im Dokumentationszentrum docs.apiyi.com
