DeepSeek V4.1 Flash: So prüfen Sie, ob die komprimierte Cache den tatsächlichen Aufwand für einen Agenten senkt

Was DeepSeek behauptet – und was noch nachzuweisen ist

Für ein Team, das einen Agenten bewertet, ist nicht allein entscheidend, wie viel Speicher das Modell benötigt, um seinen Kontext vorzuhalten. Entscheidend ist, ob eine konkrete Aufgabe unter wiederholbaren Bedingungen mit geringeren Kosten, in kürzerer Zeit und mit akzeptabler Qualität abgeschlossen wird. DeepSeek stellt V4.1 Flash als Modell mit einer Architektur vor, die den Platzbedarf des Key-Value-Caches, kurz KV-Cache, reduziert. Laut technischem Datenblatt beträgt der persistente KV-Cache im Vergleich zu V4 Flash bei gleicher Sequenzlänge ungefähr ein Achtel. Außerdem nennt DeepSeek acht Milliarden aktive Parameter während des Prefill und sechzehn Milliarden während des Decode.

Diese Zahlen stammen vom Hersteller und beschreiben technische Eigenschaften des Modells. Für sich genommen belegen sie nicht, dass ein Agent eine Aufgabe kostengünstiger oder mit geringerer Latenz erledigt. Die Gesamtkosten hängen unter anderem davon ab, wie Ein- und Ausgaben abgerechnet werden, wie viel Kontext wiederverwendet wird, wie viele Tool-Aufrufe nötig sind und wie viele Versuche ein gültiges Ergebnis erfordern. Die Gesamtzeit umfasst zudem Vorgänge, die nicht zwangsläufig im selben Maß wie der Cache kleiner werden.

Diese Unterscheidung ist wichtig, damit ein Infrastrukturvorteil nicht vorschnell als Produktvorteil ausgegeben wird. Ein kleinerer Cache kann lange Kontexte leichter handhabbar machen oder in einer Implementierung den Bedarf an persistenten Ressourcen senken. Ob eine Anwendung davon profitiert, lässt sich nur durch Messung des gesamten Ablaufs feststellen: von der ersten Anfrage bis zum Bestehen einer zuvor festgelegten Validierung.

Asymmetrische Architektur und KV-Cache: Was die einzelnen Angaben messen

Der KV-Cache speichert Zustände, die aus vorherigen Tokens berechnet wurden. So kann das Modell eine Sequenz weiterverarbeiten, ohne alles bereits Gelesene von Grund auf neu zu berechnen. In einem Gespräch oder einem Agenten mit umfangreicher Historie kann dieser Zustand mit zusätzlichen Anweisungen, Tool-Ergebnissen und Dokumenten anwachsen. Ein geringerer Speicherbedarf kann für den persistenten Speicher und die Verwaltung langer Sequenzen relevant sein. Die Modellgewichte verschwinden dadurch jedoch nicht, und neue Eingaben müssen weiterhin verarbeitet werden.

DeepSeek beschreibt eine asymmetrische Architektur: Die Zahl der pro Token aktiven Parameter unterscheidet sich zwischen dem Prefill der Eingabe und der Generierungsphase. In den technischen Unterlagen nennt das Unternehmen acht Milliarden aktive Parameter beim Prefill und sechzehn Milliarden beim Decode. Das beschreibt, wie die Berechnung auf diese Phasen verteilt ist. Es ist weder eine direkte Messung eingesparter Sekunden noch eine Preisangabe. Um die Auswirkungen auf eine eigene Arbeitslast zu bestimmen, braucht es Ausführungsdaten aus genau dieser Arbeitslast.

Der Bericht beschreibt außerdem SWA Bounded Replay. Dabei rekonstruiert das System bestimmte SWA-Cache-Zustände, indem es die jüngsten Tokens erneut verarbeitet, statt sämtliche Zustände dauerhaft auf einer SSD zu speichern. Damit wird ein Kompromiss zwischen persistentem Speicher und zusätzlichem Rekonstruktionsaufwand eingegangen. Selbst wenn der gespeicherte Umfang sinkt, reicht es deshalb nicht, nur Bytes zu zählen. Zu beobachten ist auch, ob die Rekonstruktion die Laufzeit, den Arbeitsspeicher während der Ausführung oder die Fähigkeit zur gleichzeitigen Bearbeitung von Anfragen beeinflusst. Die vorliegenden Quellen beschreiben den Mechanismus, garantieren aber keine identische Verbesserung in jeder Bereitstellung.

Die verfügbare Dokumentation rechtfertigt es nicht, die Cache-Reduktion als universellen Einsparungsfaktor zu behandeln. Die Angabe vergleicht den persistenten Cache mit der Vorgängergeneration bei vergleichbarer Sequenzlänge. Sie legt weder fest, welchen Anteil der Cache an den Gesamtkosten einer konkreten Anwendung hat, noch weist sie Kosten pro Aufgabe für sämtliche Kombinationen aus Kontext, Tools und visuellen Eingaben aus.

Die Aufgabe mit akzeptiertem Ergebnis ist die richtige Analyseeinheit

Der Vergleich der Kosten eines einzelnen Aufrufs kann irreführend sein, wenn das System als Agent arbeitet. Für eine Aufgabe können mehrere Modellanfragen, Tool-Ausführungen, eine Korrektur der Antwort und weitere Versuche nötig sein. Liefert eine Konfiguration zwar schneller Antworten, benötigt aber mehr Wiederholungen, können Latenz und Aufwand pro brauchbarem Ergebnis steigen. Umgekehrt kann ein einzelner, etwas teurerer Aufruf nachfolgende Schritte vermeiden. Die zentrale Kennzahl sollte daher die gesamte Arbeit bis zu einem akzeptablen Ergebnis umfassen.

Vor dem Test muss das Team festlegen, was bei jeder Aufgabe als „akzeptabel“ gilt. Das kann beispielsweise bedeuten, dass eine vorgeschlagene Änderung die Tests besteht, eine Extraktion alle Pflichtfelder enthält oder eine Antwort die richtige Evidenz nennt. Die Validierung muss für alle verglichenen Bedingungen gleich bleiben und sollte möglichst nicht von der subjektiven Einschätzung einer Person abhängen, die weiß, welche Variante gerade getestet wird.

Die Kosten sind anhand der verfügbaren Nutzungsdaten und des zum Testzeitpunkt für den jeweiligen Zugang geltenden Tarifs zu erfassen. Für die Latenz bis zum ersten Token und die Aufgabendauer sind externe Zeitstempel erforderlich, denn die Nutzungsdaten einer Antwort ersetzen nicht unbedingt eine Stoppuhr für den gesamten Ablauf. Fehler, Wiederholungen, vom Validator abgelehnte Antworten und zusätzliche Tool-Arbeit müssen ebenfalls berücksichtigt werden.

Testbedingungen festlegen: Kontext, Präfixe, Tools und Bilder

Es empfiehlt sich nicht, alle Variablen gleichzeitig zu ändern. Um die Kontextlänge zu untersuchen, lassen sich Aufgabengruppen mit kurzen, mittleren und langen Verläufen vorbereiten. Dabei sollten die Aufgaben möglichst vergleichbar bleiben. Wenn der Kontext länger wird, sind sowohl die Eingabetokens als auch die Zahl der nachfolgenden Schritte zu protokollieren. So lässt sich zwischen den anfänglichen Kosten für das Einlesen des Kontexts und den kumulierten Kosten für dessen Vorhaltung und Wiederverwendung unterscheiden.

Die Wiederverwendung von Präfixen sollte separat getestet werden. DeepSeeks Anleitung zum Kontext-Caching beschreibt Präfix-Matching und bezeichnet die Persistenz als „best effort“: Ein wiederholtes Präfix garantiert keinen Cache-Treffer. Für aussagekräftige Ergebnisse muss der voraussichtlich wiederverwendete Abschnitt identisch bleiben, während der am Ende hinzugefügte Inhalt kontrolliert variiert wird. Werden die gemeldeten Cache-Treffer und -Fehlschläge erfasst, lässt sich überprüfen, was bei jedem Aufruf tatsächlich geschah, statt eine Wiederverwendung des Kontexts einfach anzunehmen.

Bei Agenten mit Tools müssen die verfügbaren Tools, ihre Beschreibungen und Parameter sowie ihre Ausführungsbedingungen festgelegt werden. Die API kann Tool-Aufrufe im Austausch und die damit verbundene Nutzung ausweisen. Die Laufzeit des Tools und die des Agenten sollten jedoch so gemessen werden, dass sie sich getrennt betrachten lassen. Eine externe Suche oder eine Codeausführung kann die Gesamtzeit dominieren, auch wenn das Modell selbst weniger Rechenaufwand hat.

Visuelle Eingaben sind als eigene Bedingung zu behandeln, nicht als unkontrolliert hinzugefügtes Detail. Gehören sie zur erwarteten Arbeitslast, sollten vergleichbare Aufgaben mit repräsentativen Bildern getestet werden. Zu erfassen sind ihre Auswirkungen auf Kosten, Zeit und Aufgabenerfolg. Die vorliegenden Quellen belegen nicht, dass die Cache-Reduktion bei visuellen Arbeitslasten eine bestimmte Verbesserung bewirkt. Dieser Zusammenhang muss gemessen und darf nicht vorausgesetzt werden.

Was die API ausweist – und was außerhalb der API gemessen werden muss

Die Chat-Antwort von DeepSeek enthält Nutzungsfelder, darunter Ein- und Ausgabetokens sowie Angaben zu Eingabetokens, die Cache-Treffern und -Fehlschlägen zugeordnet sind. Die Spezifikation berücksichtigt außerdem die Nutzung im Zusammenhang mit Tool-Aufrufen. Mit diesen Daten lässt sich beschreiben, was die API für jede Anfrage erfasst hat. Sie sind eine nützliche Grundlage, um den Verbrauch abzugleichen. Für sich genommen belegen sie weder die Dauer des Agentenablaufs von Anfang bis Ende noch, ob das Ergebnis das Ziel erfüllt hat.

Für die Latenz bis zum ersten Token muss die Zeitmessung an einem klar definierten Punkt beginnen, etwa beim Absenden der Anfrage, und mit dem Empfang des ersten Antworttokens enden. Für die Aufgabendauer braucht es ein zweites Intervall: vom Start der Arbeit bis zu dem Zeitpunkt, an dem der Validator das Ergebnis als akzeptabel einstuft oder die Ausführung als fehlgeschlagen gilt. Wenn Wartezeit, Tools oder Validierung einbezogen werden, muss angegeben werden, wie diese gemessen werden. Andernfalls sind die Ergebnisse zweier Tests womöglich nicht vergleichbar.

Das Team sollte Verteilungen und nicht nur einen Durchschnitt angeben. Medianwerte und Spannweiten oder Perzentile zeigen, ob einige wenige langsame Ausführungen die Nutzererfahrung verzerren. Außerdem sollten Erfolgsquote und Zahl der Wiederholungen erfasst werden. Ein niedrigerer durchschnittlicher Aufwand, der mit mehr Fehlschlägen einhergeht, belegt keine nützliche Effizienz, wenn der operative Zweck darin besteht, Aufgaben abzuschließen.

Stellt die API eine bestimmte Messgröße nicht bereit – etwa eine nach Phasen aufgeschlüsselte Zeit für die gesamte Ausführung –, darf sie nicht so rekonstruiert werden, als handele es sich um einen beobachteten API-Wert. Sie kann extern gemessen und als Messung des Teams gekennzeichnet werden. Diese Trennung zwischen Anbieterangaben und eigenen Messungen macht die Ergebnisse überprüfbar und verhindert, dass dem Modell zugeschrieben wird, was vom Dienst, dem Netzwerk oder den Tools abhängt.

Eine falsche Vergleichsbasis durch Aliase und Versionen vermeiden

Für einen historischen Vergleich muss geprüft werden, welches Modell die jeweilige Anfrage tatsächlich bearbeitet hat. DeepSeek dokumentiert `deepseek-flash` als aktuelle Zugangskennung für V4.1 Flash und weist darauf hin, dass ältere Kennungen für V4 Flash an das neue Modell weitergeleitet werden können. Wird heute mit einem alten Alias getestet und das Ergebnis als Messung des früheren Modells dargestellt, kann der Vergleich irreführend sein: Der übermittelte Name garantiert nicht, dass bei der Ausführung tatsächlich eine historische Version verwendet wurde.

Vor Beginn des Tests sollten das Änderungsprotokoll und die API-Dokumentation geprüft und die verwendete Kennung sowie das Abrufdatum festgehalten werden. Ist ein Alias weitergeleitet, muss die Ausführung als das dokumentierte Zielmodell gekennzeichnet werden und darf nicht als Wiederholung mit dem alten Modell gelten. Für einen historischen Vergleich braucht es entweder Daten, die erhoben wurden, als die frühere Version verfügbar war, oder einen Zugang, der beide Versionen eindeutig identifiziert.

Der Status von Namen und Weiterleitungen kann sich ändern. Deshalb gehört die Modellkennung zur Versuchskonfiguration und ist kein nebensächlicher Eintrag. Lässt sich eine Unsicherheit über Aliase oder Änderungen am Dienst nicht klären, muss sie im Bericht offengelegt werden.

Ergebnisse interpretieren, ohne zu weitreichende Schlüsse zu ziehen

Ein Test kann eine begrenzte Schlussfolgerung stützen: etwa, dass eine bestimmte Bedingung bei einem festgelegten Aufgabensatz, Präfixmuster, einer konkreten Tool-Konfiguration und einem bestimmten Tarif niedrigere oder höhere Kosten und eine andere Dauer pro akzeptiertem Ergebnis aufwies. Er beweist nicht, dass alle Agenten gleichermaßen profitieren, dass eine Cache-Reduktion jede beobachtete Abweichung verursacht hat oder dass das Ergebnis bei einem anderen Zugang unverändert bleibt.

Für eine stärkere Aussage zur Ursache sollte jeweils nur eine Bedingung verändert und der Test wiederholt werden. Werden Kontextlänge, Prompt und Tools gleichzeitig geändert, lässt sich nicht isolieren, welcher Unterschied die Veränderung erklärt. Ebenso beweist eine Zunahme der Cache-Treffer bei Tokens keine bessere Qualität: Der Erfolg muss anhand des zuvor festgelegten Aufgabenkriteriums gemessen werden.

Die verfügbare Dokumentation reicht aus, um technische Hypothesen über die Architektur, die Nutzungsfelder und das Verhalten des Kontext-Caches aufzustellen. Sie reicht nicht aus, um universelle Einsparungen pro Aufgabe, garantierte Latenzwerte oder einen unabhängigen Vorteil für sämtliche Arbeitslasten abzuleiten. Primärquellen beschreiben die von DeepSeek veröffentlichten Angaben und Mechanismen. Ergebnisse für eine konkrete Anwendung sollte das Team als eigene Messungen unter den jeweiligen Bedingungen ausweisen.

Eine belastbare operative Schlussfolgerung trennt vier Ebenen: was der Hersteller angibt, was die API ausweist, was das Team misst und was weiterhin unbekannt ist. Die Cache-Komprimierung ist eine relevante Eigenschaft für die Bewertung der Infrastruktur. Die Entscheidung über einen breiteren Einsatz sollte sich hingegen auf Kosten und Zeit pro akzeptierter Aufgabe stützen – zusammen mit Qualität, Schwankungen, Wiederholungen und Grenzen der Beobachtbarkeit.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.