-- Eine Diskussion über die tiefere Logik der großen Modell-API-Preiskämpfe, die Optimierung der Nutzererfahrung und die Einbeziehung von Technologien
Bildnachweis: Offizielle DeepSeek-Dokumentation
In einer Zeit, in der der Wettbewerb im Bereich der großen KI-Modelle immer härter wird, hat DeepSeek vor kurzem angekündigt, dass sein API-Dienst auf innovative Weise dieFestplatten-Cache-TechnologieDie Preisanpassung von DeepSeek ist schockierend - der Preis des Cache-Hit-Teils wird direkt auf ein Zehntel des vorherigen Preises gesenkt, was die Preise in der Branche unterm Strich noch einmal auffrischt. Als unabhängiger Gutachter, der sich seit langem mit der Big-Model-Technologie und den Branchentrends befasst, bin ich der Meinung, dass der Schritt von DeepSeek nicht nur eine Kostenrevolution ist, die durch technologische Innovation angetrieben wird, sondern auch eine tiefgreifende Optimierung der Big-Model-API-Nutzererfahrung und ein wichtiger Schritt zur Beschleunigung der Verallgemeinerung der Big-Model-Technologie.
Technologische Innovation: Feinheiten des Festplatten-Cache und Leistungssprünge
DeepSeek ist sich der hohen Kosten und Latenzprobleme bewusst, die die weit verbreitete Nutzung von Big Model APIs lange Zeit behindert haben, und die allgegenwärtige kontextbezogene Duplizierung von Benutzeranfragen ist ein Hauptgrund für diese Probleme. Bei Dialogen, die über mehrere Runden laufen, muss beispielsweise in jeder Runde der vorherige Dialogverlauf erneut eingegeben werden; bei langen Textverarbeitungsaufgaben enthält Prompt oft wiederholte Verweise. Wiederholtes Rechnen Token Dies verschwendet Rechenzeit und erhöht die Latenzzeit.
Um dieses Problem zu lösen, führt DeepSeek die kontextbezogene Festplatten-Caching-Technologie ein. Das Kernprinzip ist die intelligente Zwischenspeicherung kontextbezogener Inhalte, die voraussichtlich in Zukunft wiederverwendet werden, wie z. B. Dialogverlauf, Systemvoreinstellungen, Few-Shot-Beispiele usw., in einem verteilten Festplatten-Array. Wenn ein Benutzer eine neue API-Anfrage stellt, erkennt das System automatisch, ob der Präfix-Teil der Eingabe mit dem zwischengespeicherten Inhalt übereinstimmt (Hinweis: der Präfix muss identisch sein, um den Cache zu treffen). Ist dies der Fall, liest das System das Duplikat direkt aus dem Hochgeschwindigkeits-Festplattencache, ohne eine Neuberechnung vorzunehmen, wodurch sowohl die Latenzzeit als auch die Kosten optimiert werden.
Um ein besseres Verständnis für die Funktionsweise des Caching zu bekommen, sehen wir uns einige Beispiele an DeepSeek Offizielles Beispiel geliefert:
Beispiel 1: Dialogszenario mit mehreren Runden
Hauptmerkmal: Nachfolgende Dialogrunden greifen automatisch auf den Kontext-Cache der vorangegangenen Runde zu.
In Dialogen mit mehreren Gesprächsrunden, in denen Benutzer typischerweise aufeinanderfolgende Fragen zu einem einzigen Thema stellen, kann das Festplatten-Caching von DeepSeek den Dialogkontext effizient wiederverwenden. Zum Beispiel im folgenden Dialogszenario:
Erste Anfrage:
Nachrichten: [
{"role": "system", "content": "Sie sind ein hilfreicher Assistent"}, {"role": "user", "content": "Wo ist die Hauptstadt von China?
{"role": "user", "content": "Was ist die Hauptstadt von China?"}
]
Zweiter Antrag:
Nachrichten: [
{"role": "system", "content": "Sie sind ein hilfreicher Assistent"}, {"role": "user", "content": "Wo ist die Hauptstadt von China?
{"role": "user", "content": "Was ist die Hauptstadt von China?"} ,
{"role": "assistant", "content": "Die Hauptstadt von China ist Peking."} ,
{"role": "user", "content": "Welches ist die Hauptstadt der Vereinigten Staaten?"}
]
Bildnachweis: Offizielle DeepSeek-Dokumentation
Beispiel für einen Cache-Treffer in einem Mehrrunden-Dialogszenario: Nachfolgende Dialogrunden treffen automatisch auf den Kontext-Cache der vorherigen Runde.
Da bei der zweiten Anfrage der Präfix-Teil (Systemnachricht + erste Nutzernachricht) genau derselbe ist wie bei der ersten Anfrage, wird dieser Teil vom Cache erfasst, ohne dass die Berechnung wiederholt werden muss, wodurch sich die Latenzzeit und die Kosten verringern.
Laut den offiziellen Daten von DeepSeek sank die gemessene Latenzzeit des ersten Tokens in extremen Szenarien mit 128K Eingaben und den meisten Wiederholungen von 13 Sekunden auf 500 Millisekunden, was eine erstaunliche Leistungsverbesserung darstellt. Selbst in nicht extremen Szenarien kann die Latenzzeit effektiv reduziert und die Benutzerfreundlichkeit verbessert werden.
Darüber hinaus ist der Festplatten-Caching-Service von DeepSeek vollständig automatisiert und benutzerunabhängig. Sie können die Leistungs- und Preisvorteile des Cachings nutzen, ohne Code oder API-Schnittstelle ändern zu müssen. Die neue Abfrage prompt_cache_hit_tokens (Cache-Treffer) im Nutzungsfeld, das von der API zurückgegeben wird, ermöglicht es den Nutzern, die Anzahl der Cache-Treffer zu sehen, die sie erhalten haben. Token (Anzahl der Token) und prompt_cache_miss_tokens (Anzahl der verpassten Token), um die Cache-Treffer in Echtzeit zu überwachen und die Cache-Leistung besser zu bewerten und zu optimieren.
DeepSeek ist in der Lage, die Führung bei der Anwendung der Festplatten-Caching-Technologie in großem Maßstab zu übernehmen, was untrennbar mit seiner fortschrittlichen Modellarchitektur verbunden ist. Die von DeepSeek V2 vorgeschlagene MLA-Struktur (Multi-head Latent Attention) komprimiert die Größe des Kontext-KV-Cache erheblich und garantiert gleichzeitig die Leistung des Modells, wodurch es möglich wird, den KV-Cache auf einer kostengünstigen Festplatte zu speichern, was den Grundstein für die Implementierung der Festplatten-Caching-Technologie legt. Dadurch wird es möglich, den KV-Cache auf einer kostengünstigen Festplatte zu speichern, wodurch die Grundlage für die Festplatten-Caching-Technologie geschaffen wird.
Verständnisse DeepSeek-R1 API Cache Hit vs. Preis:Häufig gestellte Fragen zur Verwendung der DeepSeek-R1-API
Anwendungsszenarien: von langen Text-Fragen bis hin zur Code-Analyse, die Grenzen sind unendlich erweiterbar!
Es gibt eine Vielzahl von Szenarien, in denen die Festplatten-Caching-Technologie eingesetzt werden kann, und fast jede Anwendung mit großen Modellen, die kontextbezogene Eingaben beinhaltet, kann davon profitieren. Der ursprüngliche Artikel listet die folgenden typischen Szenarien auf und enthält weitere spezifische Beispiele:
- Ein Quiz-Assistent mit langen voreingestellten Aufforderungswörtern:
- Hauptmerkmal: Feste Systemprompts können zwischengespeichert werden, was die Kosten pro Anfrage reduziert.
- Beispiel:
Beispiel 2: Langer Text Q&A-Szenario
Hauptmerkmal: Mehrere Analysen desselben Dokuments können im Cache gespeichert werden.
Die Nutzer müssen denselben Ergebnisbericht analysieren und unterschiedliche Fragen stellen:
Erste Anfrage:
Nachrichten: [
{"role": "system", "content": "Sie sind ein Senior Earnings Analyst..."} ,
{"role": "user", "content": "\n\nBitte fassen Sie die wichtigsten Aussagen dieses Gewinnberichts zusammen."}
]
Zweiter Antrag:
Nachrichten: [
{"role": "system", "content": "Sie sind ein Senior Earnings Analyst..."} ,
{"role": "user", "content": "\n\nBitte analysieren Sie die Rentabilität dieses Gewinnberichts."}
]
Da bei der zweiten Anfrage der Teil der Systemnachricht und der Benutzernachricht das gleiche Präfix wie bei der ersten Anfrage hat, kann dieser Teil vom Cache erfasst werden, um Rechenressourcen zu sparen.
- Rollenspiel-Apps mit mehreren Dialogrunden:
- Hauptmerkmale: hohe Wiederverwendung des Dialogverlaufs und umfangreiche Zwischenspeicherung.
- (Beispiel 1 wurde im Detail dargestellt)
- Datenanalyse für feste Textsammlungen:
- Hauptmerkmale: mehrere Analysen und Quizfragen zum selben Dokument mit hoher Wiederholung des Präfixes.
- Zum Beispiel mehrere Analysen und Fragerunden zu ein und demselben Finanzbericht oder Rechtsdokument. (Beispiel 2 wurde im Detail dargestellt)
- Werkzeuge zur Codeanalyse und Fehlerbehebung auf der Ebene des Code-Repository:
- Hauptmerkmal: Code-Analyseaufgaben erfordern oft eine große Menge an Kontext, und das Zwischenspeichern kann zur Kostensenkung beitragen.
- Lernen mit wenigen Schüssen:
- Hauptmerkmal: Few-Shot-Beispiele mit dem Präfix Prompt können zwischengespeichert werden, wodurch die Kosten für mehrere Few-Shot-Aufrufe reduziert werden.
- Beispiel:
Beispiel 3: Lernszenario mit wenigen Schüssen
Hauptmerkmal: dasselbe Few-shot-Beispiel kann als Präfix zwischengespeichert werden.
Die Benutzer verwenden Few-Shot-Learning, um die Effektivität des Modells bei der Abfrage von historischem Wissen zu verbessern:
Erste Anfrage:
Nachrichten: [
{"role": "system", "content": "Sie sind Geschichtsexperte, der Benutzer stellt eine Reihe von Fragen, Ihre Antworten sollten kurz und bündig sein und mit `Answer:` beginnen"}, {"role": "user", "content": "Sie sind Geschichtsexperte, der Benutzer stellt eine Reihe von Fragen, Ihre Antworten sollten kurz und bündig sein und mit `Answer:` beginnen"}, {"role": "user", "content": "Darf ich wissen, in welchem Jahr Qin Shi Huang die sechs Reiche vereinigte?
{"role": "user", "content": "In welchem Jahr hat Qin Shi Huang die sechs Reiche vereinigt?"} ,
{"role": "user", "content": "Wer war der Gründer der Han-Dynastie?"} ,
{"role": "assistant", "content": "Antwort:Liu Bang"}, {"role": "assistant", "content": "Antwort:Liu Bang"}, {"role": "user", "content": "Wer war der Gründer der Han-Dynastie?
{"role": "user", "content": "Wer war der letzte Kaiser der Tang-Dynastie?"}, {"role": "assistant", "content": "Antwort:Liu Bang"}, {"role": "user", "content": "Antwort:Liu Bang"}, {"role": "assistant", "content": "Antwort:Liu Bang"}
{"role": "assistant", "content": "Antwort:Li bax"}, {"role": "assistant", "content": "Antwort:Li bax"}, {"role": "assistant", "content": "Antwort:Li bax"}, {"role": "user", "content": "Wer war der letzte Kaiser der Tang Dynastie?
{"role": "user", "content": "Wer war der Gründerkaiser der Ming-Dynastie?"}, {"role": "user", "content": "Wer war der Gründerkaiser der Ming-Dynastie? ,
{"role": "assistant", "content": "Antwort:Zhu Yuanzhang"}, {"role": "user", "content": "Wer war der Gründerkaiser der Ming-Dynastie?
{"role": "user", "content": "Wer war der Gründerkaiser der Qing-Dynastie?"}, {"role": "user", "content": "Who was the founding emperor of the Qing Dynasty?
]
Zweiter Antrag:
Nachrichten: [
{"role": "system", "content": "Sie sind Geschichtsexperte, der Benutzer stellt eine Reihe von Fragen, Ihre Antworten sollten kurz und bündig sein und mit `Answer:` beginnen"}, {"role": "user", "content": "Sie sind Geschichtsexperte, der Benutzer stellt eine Reihe von Fragen, Ihre Antworten sollten kurz und bündig sein und mit `Answer:` beginnen"}, {"role": "user", "content": "Darf ich wissen, in welchem Jahr Qin Shi Huang die sechs Reiche vereinigte?
{"role": "user", "content": "In welchem Jahr hat Qin Shi Huang die sechs Reiche vereinigt?"} ,
{"role": "user", "content": "Wer war der Gründer der Han-Dynastie?"} ,
{"role": "assistant", "content": "Antwort:Liu Bang"}, {"role": "assistant", "content": "Antwort:Liu Bang"}, {"role": "user", "content": "Wer war der Gründer der Han-Dynastie?
{"role": "user", "content": "Wer war der letzte Kaiser der Tang-Dynastie?"}, {"role": "assistant", "content": "Antwort:Liu Bang"}, {"role": "user", "content": "Antwort:Liu Bang"}, {"role": "assistant", "content": "Antwort:Liu Bang"}
{"role": "assistant", "content": "Antwort:Li bax"}, {"role": "assistant", "content": "Antwort:Li bax"}, {"role": "assistant", "content": "Antwort:Li bax"}, {"role": "user", "content": "Wer war der letzte Kaiser der Tang Dynastie?
{"role": "user", "content": "Wer war der Gründerkaiser der Ming-Dynastie?"}, {"role": "user", "content": "Wer war der Gründerkaiser der Ming-Dynastie? ,
{"role": "assistant", "content": "Antwort:Zhu Yuanzhang"}, {"role": "user", "content": "Wer war der Gründerkaiser der Ming-Dynastie?
{"role": "user", "content": "Darf ich wissen, wann die Shang-Dynastie fiel?"}, {"role": "user", "content": "Antwort:Zhu Yuanzhang" }, {"role": "user", "content": "Antwort:
]
Da bei der zweiten Anfrage dasselbe 4-Schuss-Beispiel als Präfix verwendet wird, kann dieser Teil aus dem Cache abgerufen werden, und es muss nur die letzte Frage neu berechnet werden, wodurch die Kosten für das Few-Shot-Lernen erheblich gesenkt werden.
Bildnachweis: Offizielle DeepSeek-Dokumentation
Beispiel für einen Cache-Treffer in einem Datenanalyse-Szenario: Anfragen mit demselben Präfix können den Cache treffen (Hinweis: Das Bild hier folgt dem ursprünglichen Datenanalyse-Beispiel, das sich mehr auf das Konzept der Präfix-Duplikation konzentriert, und das Few-shot-Beispielszenario kann auf dieselbe Weise interpretiert werden).
Diese Szenarien sind nur die Spitze des Eisbergs. Die Anwendung der Festplatten-Caching-Technologie eröffnet wirklich neue Möglichkeiten für die Anwendung von APIs für große Modelle mit langem Kontext. So können wir beispielsweise leistungsfähigere Tools für die Erstellung von Langtexten entwickeln, komplexere wissensintensive Aufgaben bewältigen und tiefgründigere und einprägsamere KI-Anwendungen für Konversationen entwickeln.
Referenz: Inspiriert von Claude
Kostenvorteil: Die Preise sinken um Größenordnungen und kommen der großen Modellökologie zugute
Die Preisanpassung für die DeepSeek-API ist "episch", wobei der Cache-Treffer-Teil der API mit 0,10 $/Millionen Token und der Treffer-Teil mit 1 $/Million Token bepreist wird. Der Preis für einen Cache-Treffer beträgt nur 0,1 $ pro Million Token, und der Preis für einen Miss beträgt nur 1 $ pro Million Token, was eine Größenordnung niedriger ist als der vorherige Preis für einen Cache-Treffer.
Nach den offiziellen Angaben von DeepSeek können damit bis zu 90% eingespart werden, und selbst ohne jegliche Optimierung können die Nutzer insgesamt mehr als 50% einsparen. Dieser Kostenvorteil ist von großer Bedeutung, um die Schwelle für die Anwendung großer Modelle zu senken und die Popularität großer Modelle zu steigern.
Noch interessanter ist die Preisstrategie von DeepSeek. Die Preise für Cache-Hits und -Misses sind gestaffelt, um die Benutzer zu ermutigen, den Cache so weit wie möglich zu nutzen, das Prompt-Design zu optimieren und die Cache-Trefferquote zu erhöhen, wodurch die Kosten weiter gesenkt werden. Gleichzeitig fallen weder für den Cache-Dienst selbst noch für den Cache-Speicherplatz zusätzliche Gebühren an, was wirklich benutzerfreundlich ist.
Bildnachweis: Offizielle DeepSeek-Dokumentation
Der Preis für die DeepSeek-API wurde erheblich gesenkt, so dass Cache-Treffer nur noch 0,1 $/Million Token kosten.
Die deutliche Preissenkung von DeepSeek API wird zweifellos die Entwicklung des Preiskampfes bei den großen Modellen beschleunigen. Im Gegensatz zum früheren einfachen Preiswettbewerb ist die Preissenkung von DeepSeek jedoch eine rationale Preissenkung auf der Grundlage von technologischer Innovation und Kostenoptimierung, die nachhaltiger und branchenorientierter ist. Dieser gesunde Preiswettbewerb wird letztlich dem gesamten Big-Model-Ökosystem zugute kommen, so dass mehr Entwickler und Unternehmen in den Genuss fortschrittlicher Big-Model-Technologie zu niedrigeren Kosten kommen.
Unbegrenztes Streaming und Gleichzeitigkeit, sichere und zuverlässige Caching-Dienste
Neben den Leistungs- und Preisvorteilen sind auch die Stabilität und Sicherheit der DeepSeek API vertrauenswürdig. Der DeepSeek API-Dienst ist auf eine Kapazität von 1 Billion Token pro Tag ausgelegt, mit unbegrenztem Streaming und Gleichzeitigkeit für alle Nutzer, was die Qualität des Dienstes unter hohen Lastbedingungen gewährleistet.
DeepSeek hat auch der Datensicherheit volle Aufmerksamkeit geschenkt. Der Cache jedes Nutzers ist getrennt und logisch voneinander isoliert, um die Sicherheit und den Schutz der Nutzerdaten zu gewährleisten. Caches, die über einen längeren Zeitraum nicht genutzt wurden, werden automatisch geleert (in der Regel nach ein paar Stunden bis ein paar Tagen) und nicht lange aufbewahrt oder für andere Zwecke verwendet, was mögliche Sicherheitsrisiken weiter reduziert.
Es ist zu beachten, dass das Cache-System 64 Token als Speichereinheit verwendet und dass alles, was weniger als 64 Token enthält, nicht in den Cache aufgenommen wird. Außerdem ist das Cache-System "best effort" und garantiert keine 100% Cache-Treffer. Darüber hinaus dauert der Aufbau des Caches einige Sekunden, was aber für lange Kontext-Szenarien durchaus akzeptabel ist.
Modellaktualisierung und Zukunftsaussichten
Es ist erwähnenswert, dass DeepSeek zusammen mit der Einführung der Festplatten-Caching-Technologie auch bekannt gab, dass das DeepSeek-Chat-Modell zu DeepSeek-V3 aufgerüstet wurde und das DeepSeek-Rasoner-Modell das neue Modell DeepSeek-R1 ist. Die neuen Modelle bieten verbesserte Leistung und Fähigkeiten zu einem deutlich niedrigeren Preis, was die die Wettbewerbsfähigkeit der DeepSeek API.
Laut der offiziellen Preisinformation genießt DeepSeek-V3 API (deepseek-chat) bis zum 8. Februar 2025 um 24:00 Uhr einen ermäßigten Preis, mit einem Preis von nur $0,1/Millionen Token für zwischengespeicherte Treffer, $1/Million Token für verpasste Eingaben und $2/Millionen Token für Ausgaben. DeepSeek-R1 API (deepseek-reasoner) wird als Inferenzmodell mit einer 32K Gedankenkettenlänge und 8K maximaler Ausgabelänge positioniert, mit einem Eingabepreis (zwischengespeicherte Treffer) von $1/Million Token. DeepSeek-R1 API (deepseek-reasoner) wird als Inferenzmodell mit 32K Gedankenkettenlängen und 8K maximalen Ausgabelängen positioniert, mit einem Eingabepreis von $1/Million Token für zwischengespeicherte Treffer, $4/Million Token für verpasste Eingaben und $16/Million Token für Ausgaben (alle Token für die Gedankenkette und die endgültige Antwort). und alle Token der endgültigen Antwort).
Die Reihe innovativer Initiativen von DeepSeek zeigt, dass das Unternehmen kontinuierlich in Technologie investiert und die Nutzer in den Mittelpunkt stellt. Wir haben allen Grund zu glauben, dass mit DeepSeek und weiteren innovativen Kräften die Big-Model-Technologie ihre Reife beschleunigen und umfassender werden wird, was weitreichendere Veränderungen in verschiedenen Branchen mit sich bringen wird.
Schlussbemerkungen
Die innovative Nutzung der Festplatten-Caching-Technologie und die erhebliche Preissenkung der DeepSeek-API sind ein bahnbrechender Durchbruch. Sie löst nicht nur die langjährigen Kosten- und Latenzprobleme von Big-Model-APIs, sondern bringt den Nutzern auch bessere Qualität und umfassendere Big-Model-Dienste durch technologische Innovation. Der Schritt von DeepSeek kann das Wettbewerbsmuster von Big-Model-APIs neu definieren, die Popularität und Anwendung von KI-Technologie beschleunigen und letztendlich ein wohlhabenderes, offenes und inklusives Big-Model-Ökosystem aufbauen.
Deutsch (Sie) 
简体中文 
English 
日本語 
Português do Brasil