Was ist der Schlüssel nach Millionen von Kontexten?
In den letzten Tagen hat DeepSeek die volle Aufmerksamkeit der Tech-Szene erobert.
Der Bildschirm ist voller Gerüchte über die geschätzte Überbewertung oder Pressemitteilungen über die Kompatibilität mit verschiedenen chinesischen Rechenleistungschips. Die aufgebrachte Stimmung auf dem Markt lässt es leicht zu, sich im Labyrinth großer Zahlen zu verlieren. Die Öffentlichkeit richtet ihren Fokus entweder auf das ansehnliche Label "Millionen-Kontext" oder auf die arithmetischen Probleme wie "wer hat wen um ein paar Zehntel Punkte geschlagen" in den Benchmark-Ranglisten.
Die Ergebnisse von DeepSeek V4-Pro sind wirklich beeindruckend. Laut dem technischen Bericht hat es in den SimpleQA-Verified-Tests alle Open-Source-Konkurrenten um 20 absolute Prozentpunkte hinter sich gelassen. Im Codeforces-Codewettbewerb hat es die erwartete Punktzahl von GPT-5.4 erreicht. Natürlich ist es in Bezug auf die Breite des Weltwissens immer noch etwas hinter Gemini-3.1-Pro zurück, und bei äußerst schwierigen komplexen Aufgaben gibt es immer noch eine kleine Lücke zu Claude Opus 4.6.
Aber das spielt keine Rolle.
Wenn Sie sich nur auf die Platzierung in der Rangliste konzentrieren, verpassen Sie die echte Ambition dieser Institution völlig.
DeepSeek gibt nicht einfach ein Modellparameterpaket heraus, um in der Rangliste zu bestehen. Es bricht tatsächlich Stück für Stück die Grundlage der "Millionen-Kontext"-Funktion auf.
Der Kampf um die großen Modelle hat die Ebene der Modelle verlassen und hat die Systemebene vollständig in Besitz genommen.
In den letzten Jahren hat die Branche um die Gehirnkapazität gekämpft. Man hat verglichen, wer mehr Parameter hat und wer höhere Benchmark-Ergebnisse erzielt. Aber diese Spielweise ist am Ende. Die Entstehung von V4 definiert eine neue Regel: Das Modell selbst ist nur ein natürliches Nebenprodukt eines effizienten Engineeringsystems.
Wenn 1M Kontext zum Standardwert aller offiziellen Dienste wird, zeigt sich aus seiner Open-Source-Implementierung deutlich: Dies ist definitiv nicht durch reine Rechenleistung erreicht worden. Im zweiten Halbbogen der Ära des langen Textes geht es nie um Intelligenz.
Sondern um die Fähigkeit der Rechenzentrumsplanung.
13M aktive Parameter besiegen 37M
Woher kann man die Planungsfähigkeit erkennen? Betrachten Sie zunächst ein am wenigsten intuitives Design von V4: die symbiotische Beziehung zwischen Pro und Flash.
Wenn die Branche "Pro" und "Flash" sieht, denkt man sofort an präzise Strategien: Pro wird für die Spitzenleistung eingesetzt, und Flash wird für den Massenmarkt verwendet, um kleine und mittlere Unternehmen zu erobern.
Diese typische kommerzielle Verpackungslogik trifft bei V4 weit daneben. Es handelt sich nicht um eine Beziehung der Rechenleistungseinbuße, sondern um eine Kontrollgruppe, die die gleiche zugrunde liegende Logik verifiziert.
Die bisherige Fähigkeit großer Modelle für lange Texte war im Wesentlichen eine künstliche Fähigkeit, die durch das Aufstocken des Grafikspeichers erreicht wurde. Solange man genug GPU und genügend Grafikspeicher zur Verfügung hat, kann man beliebig lange Texte verarbeiten. Aber der Preis dafür ist so hoch, dass es in der realen Geschäftsumgebung nicht umsetzbar ist.
V4-Pro hat mit 1,6T Gesamtparametern und 49M aktiven Parametern die Kapazität auf das Maximum gebracht. Aber der wirkliche Trumpf ist V4-Flash mit nur 284M Gesamtparametern und 13M aktiven Parametern.
Eine Zahl in der Dokumentation durchbricht direkt die Branchenillusion: In vielen herausfordernden Tests hat Flash-Base mit nur 13M aktiven Parametern die vorherige Generation V3.2-Base mit 37M aktiven Parametern direkt übertroffen.
Die minimale Aktivierungskosten von 13M bedeuten keine Leistungseinbuße, sondern eine umfassende Effizienzoptimierung auf der untersten Ebene. Die Bedeutung von Flash liegt nicht darin, zu zeigen, wie viel Geld man sparen kann, sondern darin, zu beweisen, dass die "Rechenleistungsherrschaft" durch die Architekturumgestaltung gebrochen werden kann.
Die Parametergröße hat vollständig ihre entscheidende Bedeutung verloren.
Die Planungsfähigkeit ersetzt die Parameter und wird zur neuen Hauptschlachtfeld. Dadurch wird der Millionen-Kontext nicht mehr das exklusive Spielzeug von hochwertigen NVIDIA-Clustern, und chinesische Chips können die Kontrolle übernehmen. Der Markstein für zukünftige Open-Source-Modelle liegt nicht darin, wer die größere Basis hat, sondern darin, wer mit einem Zehntel des Aufwands die gleiche Arbeit leisten kann.
Experten vermischen die Dinge nicht, sondern jeder hat seine Aufgabe
Die Hardwareeffizienz ist eine Seite, die Softwareeffizienz ist die andere. V4 hat auch bei der "Nach-Training"-Phase einen anderen Weg gewählt.
Die "Nach-Training"-Phase großer Modelle war in den letzten Jahren in einer Sackgasse.
Die übliche gemischte Verstärkungslearning (Mixed RL) in der Branche, um es direkt zu sagen, ist wie das Vermischen von Dingen. Wenn Sie möchten, dass das Modell sowohl Kalkül versteht, als auch C++ schreiben kann und auch tägliche Pläne erstellen kann, wird traditionell versucht, alle Parameter zusammenzudrücken. Das Ergebnis ist die "Regression zur Mitte".
Wenn man die Parameter zwangsweise zusammenbringt, werden alle spezialisierten Fähigkeiten abgeschliffen, und am Ende wird es zu einem durchschnittlichen Allrounder.
V4 hat einen anderen Weg gewählt. Es ist keine Verbesserung, sondern eine völlige Umstellung. Der technische Bericht gibt die neue Lösung an: Zunächst werden spezialisierte Experten isoliert trainiert. Mathematikexperten kümmern sich nur um Rechnen, und Codeexperten kümmern sich nur um Programmieren. Die Fähigkeiten in einer einzigen Dimension werden auf das Maximum gebracht.
Der Schlüssel liegt in der endgültigen Kombination. V4 verwendet nicht die in der Branche weit verbreitete Parameter-Mittelungsmethode, sondern die One Policy Distillation (OPD).
Die traditionelle Gewichtskombination ist ein statischer Kompromiss, während OPD eine dynamische Übernahme ist.
Wenn das einheitliche Modell seine eigene Generierungsspur erzeugt und auf eine Mathematikaufgabe stößt, führt das System gezielt den Gradienten des Mathematikexperten ein, um den Weg zu weisen; wenn es um das Schreiben von Code geht, wird es nahtlos an den Codeexperten weitergeleitet. Jeder hat seine Aufgabe und es gibt keine Konflikte auf der Parameterebene.
Betrachtet man diesen Gedanken weiter, so ist das beliebte "Drei-Inferenz-Modi" (keine Überlegung, intensive Überlegung, extreme Überlegung) auf der Anwendungsseite von V4 nicht einfach nur das Hinzufügen eines UI-Buttons. Es ist die direkte Umsetzung des OPD-Mechanismus auf der Produktseite.
Im Modus der extremen Überlegung zwingt das unterliegende Prompt das Modell, das Problem zu zerlegen und alle Randfälle auszureizen. Diese äußerst hartnäckige Verhaltensweise ist genau die Instinkt, die in der OPD-Phase durch die intensive Arbeit der "Mathematikexperten" und "Programmierer" festgelegt wurde.
OPD macht keine Mittelung. Bei Mathematikaufgaben wählt man den Mathematikexperten, bei Codeaufgaben wählt man den Codeexperten. Jeder hat seine Aufgabe, und es gibt keine Konflikte auf der Parameterebene.
Der Agent darf nach drei Stunden nicht vergessen
Nach der Umstellung der Trainingsmethode betrachten wir die Anwendungsfälle. Was kann der lange Kontext tatsächlich leisten?
Wenn es nur darum geht, einen Satz in einem zehntausendseitigen Forschungsbericht zu finden, dann handelt es sich nicht um einen langen Kontext, sondern um eine fortgeschrittene Suche. In der realen Geschäftsumgebung muss der Agent Code neu strukturieren, Daten über Systemgrenzen hinweg verifizieren und sogar einen ganzen Abend lang Prozesse ausführen.
Das tödlichste Problem in diesem Prozess ist das "Vergessen".
Bei V3.2 gibt es ein Problem, das die Ingenieure sehr ärgert: Sobald eine neue Nachricht eintrifft, werden alle vorherigen Denkspuren des Modells gelöscht. Bei normalen Chatgesprächen ist das in Ordnung, da es Ressourcen spart. Aber wenn es sich um einen dreistündigen Agentenauftrag handelt und plötzlich eine Nachricht dazwischen kommt, wird das Modell leer, und der gesamte Zustand geht verloren, und man muss von vorne anfangen.
Diese Kettenschlüsse können in der realen Geschäftspraxis nicht aufgefangen werden.
V4 bietet die Lösung "interleaved thinking". Die Logik ist sehr rational und berücksichtigt die verschiedenen Szenarien.
In allen Szenarien mit Werkzeugaufrufen über Nachrichtengrenzen hinweg wird die Inferenzkette vollständig beibehalten. Bei einfachen Gesprächen wird weiterhin gelöscht, um keine Rechenleistung zu verschwenden. Das Modell lernt endlich, "in welchem Anlass was zu merken ist".
Noch besser ist seine schnelle Anweisung (Quick Instruction).
In der Branche war es üblich, bei der Intentionenerkennung ein kleines Modell anzuhängen. Das bedeutet, dass jedes Mal, wenn eine neue Anfrage eintrifft, unabhängig von ihrer Länge, das System die Benutzeranweisung erneut verarbeiten muss. Dies ist im Wesentlichen eine Verschwendung der Vorbelegungskalkulation.
V4 macht es nicht so. Aus seinem Open-Source-Code geht hervor: Es werden einfach einige implizite Anweisungen am Ende der Eingabesequenz eingefügt. Die von dem Hauptmodell zuvor berechneten massiven Merkmale (KV Cache) können direkt wiederverwendet werden.
Das Kernproblem des langen Kontexts liegt nie darin, "viel zu merken", sondern darin, "es zu leisten".
Dies bedeutet einfach, dass eine redundante Vorbelegungskalkulation weggelassen wird. Die Branche geht davon aus, dass jede Funktion ein kleines Modell benötigt, aber V4 beweist mit seiner Tat, dass das nicht nötig ist. Wenn der KV Cache vollständig wiederverwendet wird, kann der langfristige Agent funktionieren.
Vollständiger Cache, regelmäßiges Speichern, kein Speichern - alles schmerzt
Das Funktionieren eines Modells bedeutet nicht, dass es verkauft werden kann.
Es gibt ein Detail auf Seite 17: Der automatisch generierte Kernel wird bitweise mit dem handgeschriebenen CUDA verglichen. Es ist nicht nur ähnlich, sondern jeder Bit ist gleich. Eine solche Ingenieurskunst ist in der Geschäftspraxis selten. Erst mit dieser Grundhaltung kann man die Implementierungskosten berechnen.
Bei der hohen Parallelität des Millionen-Kontexts geht es nicht darum, ob das große Modell den Menschen versteht, sondern darum, ob man die physikalischen Grenzen der Hardware kennt.
Die Dokumentation listet alle drei Planungsstrategien auf, ohne etwas zu verbergen. Es geht um Abwägungen.
Möchten Sie die Rechenleistung ohne Redundanz nutzen? Wählen Sie "vollständigen Cache". Aber der Preis dafür ist, dass der I/O-Kanal der Festplatte in wenigen Sekunden durch die häufige Schreibaktion überlastet werden kann.
Möchten Sie die Festplatte schützen? Wählen Sie "regelmäßige Checkpoints". Speichern Sie in regelmäßigen Abständen. Die Festplatte wird geschützt, aber die GPU muss von Zeit zu Zeit Rechenleistung aufwenden, um die fehlenden Enddaten zu reparieren.
Wenn Sie auf den physischen Festplatten-Cache verzichten möchten? Wählen Sie "Null-Cache". Sparen Sie die gesamte Speicherbandbreite und verlassen Sie sich auf die langfristigen Merkmale als Ankerpunkte. Bei Problemen muss die GPU vor Ort rechnen.
Keiner dieser drei Wege ist perfekt. Dies ist im Wesentlichen eine Grenzberechnung zwischen der Lebensdauer der Hardware, dem Spitzenwert der Parallelität und der Verzögerungstoleranz der Benutzer. Es stellt die kalte Realität vor alle: Die KI ist längst keine reine Rechenleistungsintensive Branche mehr, sondern wird immer mehr zu einer Planungsintensiven Branche.
Abschluss
Wenn man DeepSeek V4 nur anhand der Benchmark-Rangliste beurteilt, hat man überhaupt nicht die Schwelle erreicht.
Die dynamische Übernahme der Fähigkeiten durch OPD, die Beibehaltung des Gedächtnisses durch das interleaved thinking, die schnelle Anweisung, die die Vorbelegungskalkulation weglässt, und die Speicherstrategien, die die Festplatte und den Grafikspeicher bis ins letzte Detail berücksichtigen.
Diese trockenen Details hängen alle zusammen.
Die großen Modelle ändern sich.