StartseiteArtikel

DeepSeek + Pi – Das ultimative Power-Duo schlägt Claude Code? Der Gründer von Pi: Ich habe schon lange auf diese Kombination gesetzt und damit richtig gelegen.

极客邦科技InfoQ2026-08-12 18:37
Wie wird eine Cache-Trefferquote von 99,9 % erreicht?

Am 11. August hat Mario Zechner, Gründer von Pi Harness, eine Gruppe von Daten weiterverbreitet:

Der Entwickler 0xEvan hat DeepSeek V4 Flash über Pi aufgerufen, fast 1 Milliarde Eingabe-Token verarbeitet, eine Cache-Trefferquote von 99,93 % erreicht und am Ende nur 2,65 US-Dollar ausgegeben. Ohne Cache würde der gleiche Verbrauch voraussichtlich 132 US-Dollar kosten.

Am selben Tag erklärte ein anderer Entwickler, Shantanu Goel, dass die Cache-Trefferquote von DeepSeek V4 Flash in anderen Harness normalerweise zwischen 94 % und 97 % liegt, in Pi aber dauerhaft über 99 % erreicht. Mario kommentierte dies: „Das ist besonders nützlich, wenn man lokale Modelle verwendet.“

Es gibt viele weitere solche Fälle in der Community.

Das erinnert auch an Marios Bewertung der Kombination aus Pi und DeepSeek V4 im Mai dieses Jahres: „pi + ds4 == sovereign AI enterprise ready clearly.“ In passenderer Ausdrucksweise heißt das ungefähr: „Pi + DeepSeek 4 – die KI für Unternehmen ist damit doch einfach realisiert.“

Damals war das nur ein Scherz von ihm, nachdem er gesehen hatte, dass Entwickler mit Pi und DeepSeek V4 ein Terminal-Tetris zum Laufen gebracht hatten. Drei Monate später hat ein öffentlicher vergleichender Test diese Aussage unerwartet mit Daten untermauert.

Pi in Kombination mit DeepSeek – hat es Claude Code übertroffen?

Composio ist ein Unternehmen, das Tools für KI-Agenten entwickelt und kürzlich einen öffentlichen Vergleichstest durchgeführt hat. Sie haben dasselbe Modell DeepSeek V4 Flash ausgewählt und es in 8 verschiedenen Agenten-Harness ausführen lassen, um 30 hochschwierige Agentenaufgaben zu erledigen. Diese Aufgaben verlangen von den Agenten, Maßnahmen zu ergreifen, Tools aufzurufen und den gesamten Arbeitsablauf selbstständig abzuschließen.

Den ersten Platz belegte Pi Agent: 20 von 30 Aufgaben wurden bestanden, was eine Erfolgsquote von 66,7 % ergibt; Oh My Pi belegte mit 17 bestandenen Aufgaben den zweiten Platz; Claude Code, Codex und Deep Agents bestanden jeweils 16 Aufgaben; Prime Agent schaffte 15 Aufgaben, weitere 6 Läufe wurden nicht gewertet – davon 2 wegen Zeitüberschreitung bei der Verarbeitung durch den Bewerter und 4 ohne aufgezeichnete Ergebnisse; Hermes Agent bestand ebenfalls 15 Aufgaben; OpenCode belegte mit 14 bestandenen Aufgaben den letzten Platz.

Bei demselben Modell stieg die Erfolgsquote von 46,7 % auf 66,7 %, wenn nur das äußere Harness ausgetauscht wurde – ein Unterschied von ganzen 20 Prozentpunkten.

Der Kostenunterschied fällt noch deutlicher aus: Für eine erfolgreich abgeschlossene Aufgabe gibt Pi durchschnittlich nur 0,028 US-Dollar aus, während Claude Code 0,195 US-Dollar benötigt, fast das Siebenfache des Werts von Pi.

Die mediane Zeit für die Aufgabenerledigung von Pi beträgt 132,2 Sekunden, was zwar etwas langsamer ist als die 122,7 Sekunden von Claude Code und die 129,7 Sekunden von OpenCode, aber in der Gesamtbetrachtung von Erfolgsquote, Geschwindigkeit und Kosten lieferte es das herausragendste Ergebnis in dieser Testrunde.

Dieser Test zeigt den sogenannten „Harness-Multiplikatoreffekt“: Tools, die um KI herum aufgebaut sind, können die tatsächliche Leistung des Modells verstärken oder schwächen. Mit dem richtigen Harness kann dasselbe Modell gleichzeitig zuverlässiger und effizienter werden; mit dem falschen Harness können Aufgabenerfolgsquote und Laufzeiteffizienz deutlich sinken, selbst wenn das Intelligenzniveau des zugrundeliegenden Modells völlig identisch ist.

Composio betont daher, dass Modelle nicht isoliert bewertet werden sollten: Wenn eine Agenten-Rangliste nur den Modellnamen angibt, aber nicht mitteilt, welches Harness verwendet wurde, ist diese Bewertung unvollständig.

Warum gewinnt das minimalistische Pi am Ende?

Der Test von Composio weist noch ein weiteres bemerkenswertes Detail auf: Pi hat fast keine zusätzlichen Konfigurationen hinzugefügt, es wurde eine neue, unveränderte Standardinstallation verwendet, bei der nur die für den Test erforderlichen MCP-Server-Plug-ins eingebunden wurden. Darüber hinaus wurden bei Pi keine benutzerdefinierten Einstellungen, Optimierungen oder speziellen Konfigurationen vorgenommen. Genau ein solches fast direkt einsatzbereites System hat am Ende die meisten Aufgaben bestanden.

Schauen wir uns nun Prime Agent an: Es erzeugte das umfangreichste Sitzungsaufkommen unter den acht Harness, einige Sitzungen verbrachten bis zu 3,5 Millionen Token und führten 33 Tool-Aufrufe durch. Man kann es sich so vorstellen, dass der Agent, bevor er überhaupt richtig mit der Arbeit beginnt, sich zuerst eine Aufgabenliste anlegt, die so lang ist wie ein Telefonbuch.

Diese Sitzungen waren so umfangreich, dass der Bewerter bei ihrer Verarbeitung eine Zeitüberschreitung erlitt. Zwei Läufe konnten nicht bewertet werden, weitere vier blieben ohne Aufzeichnung, sodass insgesamt sechs Läufe nicht in die Wertung eingingen. Selbst wenn man nur die gültigen Läufe betrachtet, entspricht die Anzahl der von Prime bestandenen Aufgaben nur der von Hermes, während die benötigte Zeit fast das Doppelte von Pi beträgt.

Diese Daten zeigen einen deutlichen Kontrast: Prime mit seinen zahlreichen Funktionen und umfangreichen Sitzungen wurde am Ende durch seine eigene Betriebslast ausgebremst, während das leichgewichtige Pi mit geringerem Overhead die meisten Aufgaben bestand. Zumindest in diesem Test hat das Hinzufügen weiterer Ebenen kein besseres Ergebnis gebracht.

Das stellt auch die bisherige Annahme infrage, dass „je mehr Konfigurationen, desto besser das Ergebnis“. Normalerweise wählt man das größte Modell, fügt jedes Plug-in, jede Erweiterung und verschiedene komplexe Funktionsebenen hinzu und geht standardmäßig davon aus, dass mehr Funktionen den Agenten stärker machen. Dieser Test liefert einen anderen Denkansatz: Wähle ein Modell mit hoher Geschwindigkeit und niedrigen Kosten, setze es in ein sauberes, leichtgewichtiges Harness ein und prüfe die Kombination beider anhand echter Aufgaben.

DeepSeek V4 Flash ist seinem Namen nach ein Flash-Modell, das sich stärker auf Geschwindigkeit und Laufzeiteffizienz konzentriert und nicht darauf abzielt, Intelligenzwettbewerbe für Modelle zu gewinnen. Der Grund für den Vorteil des leichtgewichtigen Pi in diesem Test ist eigentlich einfach: Mit jeder zusätzlichen Ebene bekommt der Agent eine weitere Stelle, an der er sich verlaufen kann; mit jedem zusätzlichen Tool bekommt er eine weitere Entscheidung zu treffen; mit jeder umfangreichen Anweisungsdatei muss er mehr Störinformationen lesen, bevor er handeln kann.

Daher bietet ein sauberes Harness dem Modell einen kurzen Pfad vom Erhalten der Aufgabe bis zu deren Abschluss, während ein überladenes Harness es dazu bringt, Umwege zu machen. Das ist der Grund, warum eine Standardinstallation eine schwergewichtige Konfiguration besiegen kann: Der Pfad ist kürzer, und die Wahrscheinlichkeit, in die falsche Richtung zu laufen, ist geringer.

Wie wird eine Cache-Trefferquote von 99,9 % erreicht?

Pi selbst ist kein Harness, das speziell für DeepSeek entwickelt wurde. Es stellt eher eine für Entwickler offene Agenten-Basis dar: Pi erlaubt es Entwicklern, Systemprompts durch Erweiterungen zu modifizieren, den Gesprächsverlauf zu filtern, die Kontextkompression individuell anzupassen und Tools dynamisch hinzuzufügen, zu löschen oder zu starten und zu stoppen. Bevor die Anfrage an das Modell gesendet wird, können Entwickler sogar die endgültige Nutzlast direkt prüfen und umschreiben. Diese Programmierbarkeit lässt viel Raum für die Cache-Optimierung von DeepSeek.

Die DeepSeek-API speichert das Präfix der Prompts in der Anfrage im Cache. Wenn die Token-Sequenz am Anfang der nächsten Anfrage mit der vorherigen vollständig übereinstimmt, liest der Server diese Token direkt aus dem Cache und berechnet sie zu einem Preis, der weit unter dem normalen Preis für Eingabe-Token liegt. Der Preis für Cache-Treffer ist viel niedriger als der für Cache-Fehltreffer.

Der entscheidende Punkt ist, dass es sich um einen Präfix-Cache handelt, bei dem die Übereinstimmung ab dem ersten Token beginnen muss. Wenn sich der vordere Teil des Kontexts ändert, können viele nachfolgende Token nicht mehr den ursprünglichen Cache treffen. Je früher sich das Präfix ändert, desto mehr Token sind davon betroffen.

Eine typische Agenten-Anfrage enthält normalerweise Systemprompts, Tool-Definitionen, Gesprächsverlauf und den neu hinzugefügten Inhalt der aktuellen Runde. Bei jedem Schritt, den der Agent ausführt, muss er erneut viele bereits zuvor aufgetretene Kontextinhalte mitführen. Je länger die Sitzung ist, desto mehr Wiederholungsinhalte gibt es – theoretisch eignet sich das sehr gut für die Nutzung des Caches. Aber wenn das Harness diese Inhalte in jeder Runde neu ordnet, neue Zeitstempel hinzufügt, die Reihenfolge der Tools ändert oder die Zusammenfassung des Verlaufs neu schreibt, lässt sich selbst ein sehr langer Kontext kaum stabil wiederverwenden.

Das hat auch eine Reihe von Harness-Projekten hervorgebracht, die speziell für die Optimierung des DeepSeek-Caches entwickelt wurden. Das quelloffene Reasonix ist ein Terminal-Programmieragent, der um den DeepSeek-Präfix-Cache herum entworfen wurde, und seine Cache-Leistung wird von vielen Entwicklern beachtet. Ein Entwickler, der Pi bevorzugt, hat sogar speziell DeepPi erstellt, um die Cache-Optimierungsmethoden von Reasonix auf Pi zu übertragen. Er gibt an, dass DeepPi bei Aufrufen der DeepSeek-API eine stabile Cache-Trefferquote von 99,7 % bis 99,9 % erreicht.

Ich habe versucht, einige Leistungsvorteile von Reasonix in das für Pi optimierte Deepseek-Paket zu übertragen. Es wird nur aktiviert, wenn die Deepseek-API verwendet wird, aber nach der Aktivierung liegt meine Cache-Trefferquote stabil zwischen 99,7 % und 99,9 %.

Das zentrale Gestaltungsprinzip von Reasonix lautet: Halte den vorderen Teil des Kontexts stabil, verwende das Anhängen statt das Modifizieren und minimiere die Änderungskosten auf ein Minimum.

In der konkreten Umsetzung injiziert Reasonix beim Start eine kompakte, stabile Umweltzusammenfassung, anstatt sie in jeder Gesprächsrunde neu zu generieren. Veraltete Tool-Ausgaben werden abgeschnitten und bereinigt, bevor die Zusammenfassungskompression ausgelöst wird – sodass die umfangreichen Ergebnisse eines cat-Befehls, der vor zwanzig Runden ausgeführt wurde, nicht dauerhaft im Präfix des Prompts verbleiben. Reasonix hat außerdem das Schema-Vertrag der integrierten Tools dokumentiert und führt bei Änderungen Regressionsprüfungen durch: Denn sobald die Tool-Definition ohne Hinweis neu angepasst wird, führt das zu einem Cache-Fehltreffer, ohne dass oberflächlich irgendwelche Anomalien sichtbar sind.

Im Zweimodell-Betrieb laufen das Ausführungsmodell und das Planungsmodell jeweils in eigenen, unabhängigen und cache-stabilen Sitzungen, anstatt in denselben Kontext vermischt zu werden. Das ist das raffinierteste Design in diesem Projekt. Der einfachste Weg, das Planungsmodell einzuführen, besteht darin, die Planungsrunden direkt in dasselbe Gespräch einzufügen – aber das zerstört die Cache-Stabilität beider Rollen. Wenn man sie in getrennten Sitzungen unterbringt, können die jeweiligen Prompt-Präfixe unverändert bleiben.

In der Pi-Ökosystem sind auch viele ähnliche Erweiterungen von Drittanbietern entstanden. Nehmen wir pi-deepseek-cache als Beispiel: Es hat ebenfalls die DeepSeek-Cache-Optimierung als zentrales Ziel, und seine Designidee weist viele Gemeinsamkeiten mit Reasonix auf.

Reasonix betont, dass „eine stabile Umweltzusammenfassung beim Start injiziert wird“ – genau das macht die P0-Ebene von pi-deepseek-cache: Beim Start des Agenten werden Datum und aktuelles Arbeitsverzeichnis eingefroren, was die durch dynamische Inhalte wie „Current date: YYYY-MM-DD“ und „Current working directory: “ im Standard-Systemprompt von Pi verursachten Cache-Fehltreffer von Grund auf verhindert.

Reasonix betont, dass „veraltete Tool-Ausgaben vor der Kompression beschnitten und bereinigt werden“ – die P3-Ebene von pi-deepseek-cache realisiert dies durch cache-freundliche Kompression: Wenn der Gesprächsverlauf zu lang ist und zusammengefasst werden muss, wird deepseek-v4-flash unter der Bedingung von