DeepSeek

1. DeepSeek ist Firma, Webdienst, API, Open-Weight-Modellfamilie und Agentenökosystem

„DeepSeek“ bezeichnet 2026 zugleich ein chinesisches AI-Unternehmen, den kostenlosen Web-/App-Chat, eine OpenAI-/Anthropic-kompatible API, mehrere offene Modellfamilien und mit DeepSeek Harness ein eigenes Agentenframework.

Eine belastbare Einordnung muss deshalb Produkt, Modell, Modellversion, Thinking-Stufe, API, lokale Gewichte und Agentenharness getrennt benennen.

2. DeepSeek wurde 2023 gegründet

DeepSeek beschreibt sich als 2023 gegründetes chinesisches Unternehmen mit langfristigem AGI-Forschungsziel.

Die Forschungslinie wurde früh ungewöhnlich stark über offene Papers, Gewichte und Code veröffentlicht.

3. Langfristiger Forschungsanspruch

DeepSeek verbindet die eigene Außendarstellung mit langfristiger Grundlagenforschung und möglichst effizienter Modellarchitektur.

Für ein Technikarchiv zählt dabei weniger Markenrhetorik als die konkrete Serie veröffentlichter Architekturen, Trainingsverfahren und Gewichte.

4. Offene Gewichte als zentrales Merkmal

Viele DeepSeek-Modelle wurden mit herunterladbaren Gewichten veröffentlicht.

Je nach Generation unterscheiden sich Lizenz, Modellkarte und kommerzielle Nutzbarkeit; „offen“ wird deshalb stichtagsbezogen geprüft.

5. MIT-Lizenz als späterer Standard

Spätestens R1 und die aktuelle V4-Linie werden von DeepSeek mit sehr permissiven MIT-Lizenzen veröffentlicht.

Ältere Spezialmodelle können zusätzlich eigene Modelllizenzen besitzen.

6. Forschung und gehosteter Dienst

Ein lokal geladenes DeepSeek-Modell ist nicht dasselbe wie chat.deepseek.com oder die offizielle API.

Der gehostete Dienst ergänzt Moderation, Suche, Konto, Logging, Produktregeln und Serverinfrastruktur.

7. Lokales Modell ≠ API

Bei Self-Hosting kontrolliert der Betreiber Inferenz, Logs und Tools selbst.

Bei der DeepSeek-API gelten DeepSeeks Open-Platform-Bedingungen, Preise, Limits und Datenpfade.

8. Modellfamilien

Die große DeepSeek-Linie umfasst DeepSeek Coder, DeepSeek LLM, DeepSeekMoE, DeepSeekMath, DeepSeek-VL/VL2, V2/V2.5, Coder-V2, V3, R1, V3.1/V3.2, Prover, OCR und V4.

Diese Familien teilen Forschung, sind aber nicht automatisch kompatible Nachfolger derselben Aufgabe.

9. Coding war von Anfang an zentral

DeepSeek Coder war eine der ersten öffentlich sichtbaren DeepSeek-Modellfamilien.

Die spätere Stärke bei Coding Agents lässt sich deshalb als kontinuierliche Entwicklung und nicht als plötzlicher R1-Nebeneffekt verstehen.

10. Mathematik als zweite Kernlinie

DeepSeekMath entwickelte Datensammlung und Reinforcement Learning für mathematisches Reasoning.

Das dort vorgestellte GRPO wurde später für R1 und weitere Post-Training-Systeme besonders wichtig.

11. Multimodalität als eigener Forschungszweig

DeepSeek-VL, VL2, Janus, JanusFlow, Janus-Pro und OCR/OCR2 bilden einen eigenen visuellen Zweig.

Die Haupt-Textmodelle waren lange textzentriert; erst V4-Flash-Vision-Exp bringt im August 2026 einen aktuellen multimodalen API-Pfad in die V4-Linie.

12. Agenten als dritter Kernzweig

Seit V3.1 und besonders V4 werden Tool Use, Code Agent und Search Agent ausdrücklich als Kernfähigkeiten trainiert.

2026 ergänzt DeepSeek mit Harness eine eigene Laufzeit für Agenten.

13. Effizienz als technischer Leitfaden

DeepSeek veröffentlicht wiederholt Architekturen, die Rechen- und Speicherbedarf relativ zur Modellkapazität senken sollen.

MoE, MLA, Sparse Attention, FP8/FP4, MTP und speculative decoding gehören zu dieser Linie.

14. Chinesischer Unternehmens- und Regulierungsrahmen

DeepSeek wird von Hangzhou DeepSeek Artificial Intelligence Co., Ltd. kontrolliert und betrieben.

Gehostete Dienste unterliegen daher neben internationalen Datenschutzpflichten auch dem chinesischen Rechts- und Inhaltsregulierungsrahmen.

15. Drei Hauptzugänge

Für Endnutzer existieren Web und mobile App; Entwickler nutzen die API; Forscher und lokale Nutzer können zahlreiche Gewichte herunterladen.

Funktionsumfang, Datenschutz und Sicherheitsgrenzen unterscheiden sich zwischen diesen drei Wegen.

16. DeepSeek Coder

DeepSeek Coder wurde als Code-Modellfamilie mit Größen von 1B bis 33B veröffentlicht und auf zwei Billionen Tokens trainiert.

Der Trainingsmix bestand laut Projektbeschreibung zu 87 Prozent aus Code und zu 13 Prozent aus natürlicher Sprache in Englisch und Chinesisch.

17. Zwei Billionen Tokens

DeepSeek Coder wurde von Grund auf auf einem großen projektnahen Codekorpus trainiert.

Die Datenmenge allein erklärt keine Qualität; wichtig waren zusätzlich Repositorystruktur, Infilling und Sprachabdeckung.

18. 1B bis 33B

Die Größenpalette erlaubte lokale Experimente ebenso wie stärkere Servermodelle.

Ein kleineres Modell ist leichter lokal betreibbar, aber nicht automatisch für komplexe Repositoryaufgaben geeignet.

19. 16K Kontext

Die erste Coder-Familie verwendete ein 16K-Kontextfenster.

Für 2023 war das bereits relevant für größere Dateien und Projektkontext.

20. Fill-in-the-Middle

DeepSeek Coder wurde mit einer zusätzlichen Fill-in-the-Blank-/Infilling-Aufgabe trainiert.

Infilling ist besonders für Editorergänzungen zwischen vorhandenem Präfix und Suffix wichtig.

21. Viele Programmiersprachen

DeepSeek Coder wurde über zahlreiche Programmiersprachen evaluiert.

Später erweitert Coder-V2 die Sprachabdeckung deutlich.

22. Base und Instruct/Chat

Wie bei vielen offenen Modellfamilien existieren Basismodelle und dialog-/instructionoptimierte Varianten.

Für Finetuning eignet sich Base; für direkte Nutzung meist die instructionoptimierte Variante.

23. DeepSeek LLM

DeepSeek LLM brachte eine allgemeine Sprachmodelllinie mit 7B und 67B Parametern.

Sie wurde auf zwei Billionen englischen und chinesischen Tokens trainiert.

24. DeepSeek LLM 7B

Die kleinere allgemeine Modellklasse diente Forschung und lokalerer Nutzung.

Sie ist historisch wichtig, obwohl sie später durch MoE- und V2/V3-Linien überholt wurde.

25. DeepSeek LLM 67B

67B war das große dense Basismodell der frühen allgemeinen DeepSeek-Linie.

Die spätere Entwicklung wechselte stark zu Mixture of Experts.

26. Englisch und Chinesisch

DeepSeek legte von Anfang an großen Wert auf bilinguale Fähigkeiten.

Spätere Modelle erweitern Sprachbreite, bleiben aber besonders stark in Englisch/Chinesisch und technischen Domänen.

27. DeepSeekMoE 16B

DeepSeekMoE untersuchte eine eigene Mixture-of-Experts-Architektur mit 16,4 Milliarden Gesamtparametern.

Das Modell sollte mit deutlich weniger aktivierter Rechenlast eine Leistung in der Nähe dichter 7B-Modelle erreichen.

28. Fine-Grained Expert Segmentation

DeepSeekMoE zerlegt Experten feiner, um Spezialisierung zu erhöhen.

Mehr Expertengranularität verlangt zugleich robustes Routing und Lastverteilung.

29. Shared Expert Isolation

Ein Teil der Experten wird als gemeinsam genutzter Wissenspfad isoliert.

Das soll redundantes Allgemeinwissen aus spezialisierten Experten heraushalten.

30. Mixture of Experts

Bei MoE wird pro Token nur ein Teil der Gesamtparameter aktiviert.

Gesamtparameter und aktive Parameter müssen deshalb getrennt angegeben werden.

31. Kapazität ≠ Rechenaufwand

Ein sehr großes MoE kann mehr gespeicherte Kapazität besitzen, ohne jeden Parameter bei jedem Token zu nutzen.

Speicherbedarf bleibt trotzdem von der gesamten Gewichtsmenge abhängig.

32. Router

Ein Router wählt für Token geeignete Experten.

Fehlerhafte oder unausgeglichene Routings können Trainingseffizienz und Modellqualität beeinträchtigen.

33. DeepSeekMoE als V2-Vorläufer

Die MoE-Forschung wurde direkt in DeepSeek-V2 und spätere V3/V4-Architekturen weiterentwickelt.

DeepSeekMoE ist deshalb mehr als eine Nebenserie.

34. Offene Forschungsartefakte

Code, Papers und Gewichte dieser frühen Modelle erlaubten unabhängige Reproduktion und Weiterentwicklung.

Ein offener Checkpoint macht aber nicht automatisch die ursprünglichen Trainingsdaten vollständig verfügbar.

35. DeepSeekMath 7B

DeepSeekMath wurde auf DeepSeek-Coder-v1.5 7B aufgebaut und mit zusätzlichen mathematischen Webdaten weitertrainiert.

Base-, Instruct- und RL-Varianten wurden veröffentlicht.

36. 120 Milliarden mathematische Tokens

Die Datensammlung nutzte OpenWebMath als Seed, FastText-Klassifikation und iterative Common-Crawl-Selektion.

DeepSeek dokumentierte damit ungewöhnlich konkret, wie ein Spezialkorpus aus dem offenen Web aufgebaut wurde.

37. 500B Continued Pretraining

DeepSeekMath erhielt 500 Milliarden zusätzliche Tokens aus Mathematik, natürlicher Sprache und Code.

Continued Pretraining ist von Instruction Tuning und RL zu unterscheiden.

38. Math Instruct

Die Instruct-Variante wurde für Schritt-für-Schritt-Mathematik optimiert.

Ein Instruction-Modell kann besser mit Aufgabenformaten umgehen als das Basismodell.

39. GRPO – Group Relative Policy Optimization

DeepSeekMath führte GRPO als Reinforcement-Learning-Verfahren ein.

GRPO vergleicht Gruppen von Antworten relativ zueinander und reduziert die Notwendigkeit eines separaten großen Value Models.

40. Warum GRPO wichtig wurde

GRPO wurde später ein zentraler Baustein von DeepSeeks Reasoning-Post-Training.

R1 machte die Methode weit über die ursprüngliche Math-Serie hinaus bekannt.

41. Mathematik mit Tools

DeepSeekMath wurde sowohl ohne als auch mit externen Tools evaluiert.

Toolnutzung und reine Modellreasoningfähigkeit sind getrennte Eigenschaften.

42. 11. März 2024: DeepSeek-VL

DeepSeek-VL brachte offene Vision-Language-Modelle mit 1,3B und 7B Parametern.

Die Modelle sollten Webseiten, Diagramme, wissenschaftliche Dokumente und natürliche Bilder verstehen.

43. VL 1.3B

Die kleinere Variante ermöglichte visuelle Experimente mit deutlich geringerem Hardwarebedarf.

Sie ist kein Bildgenerator, sondern primär ein Vision-Language-Verständnismodell.

44. VL 7B

Die 7B-Variante bot stärkere multimodale Analyse.

Base und Chat wurden separat veröffentlicht.

45. Webseiten verstehen

DeepSeek-VL wurde explizit auf Screenshots und webähnliche visuelle Strukturen ausgerichtet.

Das ist für spätere Computer-Use-Agenten ein relevanter Forschungsbaustein.

46. Diagramme und Formeln

Visuelle Mathematik und wissenschaftliche Abbildungen gehören zu den vorgesehenen Aufgaben.

Bildverständnis kann OCR-, Layout- und Reasoningfehler miteinander vermischen.

47. DeepSeek-Prover

DeepSeek entwickelte parallel Modelle für formale Mathematik und Beweisführung.

Diese Linie nutzt theorem-proving-spezifische Daten und Lean-nahe Aufgaben.

48. Formaler Beweis ≠ natürliche Erklärung

Ein formaler Proof Assistant verlangt syntaktisch und semantisch überprüfbare Beweisschritte.

Das unterscheidet sich deutlich von einem plausiblen natürlichsprachlichen Mathematiktext.

49. Prover als Reasoning-Labor

Formale Mathematik ist besonders nützlich, weil Lösungen automatisch geprüft werden können.

Solche verifizierbaren Rewards sind wertvoll für Reinforcement Learning.

50. DeepSeek-V2

DeepSeek-V2 markierte 2024 den großen Architekturwechsel zu einem sehr großen MoE-Modell mit 236B Gesamtparametern und 21B aktivierten Parametern.

Die Familie kombinierte DeepSeekMoE mit der neuen Multi-head Latent Attention.

51. 8,1 Billionen Pretraining-Tokens

DeepSeek-V2 wurde auf 8,1 Billionen vielfältigen Tokens vortrainiert.

Danach folgten Supervised Fine-Tuning und Reinforcement Learning.

52. MLA – Multi-head Latent Attention

MLA komprimiert Key-/Value-Repräsentationen in einen niedrigdimensionalen latenten Raum.

Das Ziel ist vor allem ein deutlich kleinerer KV-Cache während Inferenz.

53. KV-Cache als Inferenzengpass

Autoregressive Transformer müssen für frühere Tokens Attentionzustände speichern.

Bei langen Kontexten wird dieser Speicher schnell zum wesentlichen Hardwareproblem.

54. MLA und Speicherersparnis

DeepSeek berichtete für V2 gegenüber der vorherigen Architektur über sehr große KV-Cache-Einsparungen.

Herstellerangaben sind Architekturvergleiche und keine Garantie für jede Runtime.

55. Höherer Durchsatz

Die Kombination aus MoE und MLA sollte die Generation deutlich beschleunigen.

Servingsoftware und Batchgröße beeinflussen den realen Durchsatz zusätzlich.

56. DeepSeek-V2-Lite

Eine kleinere MoE-Variante mit 16B Gesamtparametern machte die V2-Architektur leichter zugänglich.

Lite ist nicht einfach eine Quantisierung des großen V2.

57. V2 Chat

Die Chatversion wurde für Dialog und Instruction Following post-trainiert.

Base und Chat bleiben unterschiedliche Checkpoints.

58. V2 in der API

DeepSeek führte V2 über den Modellalias `deepseek-chat` im gehosteten API-Dienst.

Aliasnamen können später auf neuere Generationen zeigen und sind deshalb keine reproduzierbaren Modellversionen.

59. V2-0517

Der Mai-2024-Stand verbesserte unter anderem Instruction Following und JSON-Ausgabe.

Datierte API-Versionen sind wichtig, weil sich das Verhalten hinter einem Alias ändern kann.

60. V2-0628

Ende Juni 2024 meldete DeepSeek weitere Verbesserungen bei Coding, Mathematik und Reasoning.

Ein API-Update verändert Produktverhalten ohne dass Clientcode geändert werden muss.

61. DeepSeek-Coder-V2

Coder-V2 wurde aus einem Zwischencheckpoint von DeepSeek-V2 mit sechs Billionen zusätzlichen Tokens weitertrainiert.

Es kombinierte allgemeine V2-Fähigkeiten mit deutlich stärkerem Coding.

62. Coder-V2 Lite 16B

Die Lite-Klasse besitzt 16B Gesamt- und ungefähr 2,4B aktive Parameter.

Sie war für deutlich günstigere lokale oder Serverinferenz gedacht.

63. Coder-V2 236B

Das große Coder-V2-Modell besitzt 236B Gesamt- und 21B aktive Parameter.

Es teilt damit die Grundgröße der V2-MoE-Familie.

64. 338 Programmiersprachen

DeepSeek erweiterte die dokumentierte Programmiersprachenabdeckung von 86 auf 338.

Breite Sprachabdeckung ist nicht mit gleicher Qualität in jeder Sprache gleichzusetzen.

65. 128K Kontext

Coder-V2 erweiterte den Kontext gegenüber Coder v1 deutlich auf 128K.

Für große Repositories bleibt gezieltes Retrieval dennoch oft effizienter.

66. Coding plus Mathematik

Coder-V2 wurde auch für mathematisches Reasoning weitertrainiert.

Die DeepSeek-Linien Coding und Math wachsen damit technisch zusammen.

67. Coder-V2 in der API

Der `deepseek-coder`-Alias wurde im Juni und Juli 2024 auf neue Coder-V2-Stände aktualisiert.

Auch hier ist der Alias historisch beweglich.

68. FIM Completion

Die API erhielt Fill-in-the-Middle-Completion als Beta.

FIM ist besonders für IDE- und Codeeditierungsaufgaben nützlich.

69. JSON Output

DeepSeek ergänzte einen strukturierten JSON-Modus.

Strukturierte Ausgabe sollte trotzdem gegen ein Schema validiert werden.

70. Function Calling

Die API erhielt Tool-/Function-Calling-Fähigkeiten.

Toolaufrufe müssen außerhalb des Modells autorisiert und validiert werden.

71. Chat Prefix Completion

Eine Beta-Funktion erlaubte, eine Assistant-Antwort mit vorgegebenem Präfix fortsetzen zu lassen.

Das ist nützlich für Formatkontrolle, kann aber die Natürlichkeit der Antwort beeinflussen.

72. 2. August 2024: Context Caching

DeepSeek führte Festplatten-basiertes Prompt-Caching ein, um wiederholte lange Präfixe günstiger zu bedienen.

Cache-Hit-Preise und Datenschutzfragen sind separate Themen.

73. Caching ist kein Memory

Context Caching speichert beziehungsweise erkennt wiederverwendbare Eingabeteile zur Kostenoptimierung.

Es ist nicht dasselbe wie persönliches Langzeitgedächtnis.

74. September 2024: DeepSeek-V2.5

DeepSeek verschmolz die allgemeine Chat- und Coding-Linie in V2.5.

Die API-Aliase `deepseek-chat` und `deepseek-coder` konnten beide auf denselben neuen Modellstand zeigen.

75. General + Coder

V2.5 kombinierte allgemeine Dialogqualität und Codefähigkeiten in einem Modell.

Das ist ein frühes Beispiel für DeepSeeks spätere Hybridisierung von Fähigkeiten.

76. V2.5-1210

Das Dezember-Update 2024 verbesserte Mathematik, Coding, Schreiben, Reasoning, Datei- und Webseitenzusammenfassung.

Diese Funktionen lagen unmittelbar vor dem V3-Wechsel.

77. 26. Dezember 2024: DeepSeek-V3

DeepSeek-V3 wurde als 671B-MoE mit 37B aktivierten Parametern veröffentlicht.

Die Generation verband DeepSeekMoE und MLA mit mehreren neuen Trainings- und Effizienztechniken.

78. 14,8 Billionen Tokens

V3 wurde auf 14,8 Billionen hochwertigen Tokens vortrainiert.

Danach folgten SFT und Reinforcement Learning.

79. 671B Gesamt / 37B aktiv

Nur ein kleiner Teil der Gesamtparameter ist pro Token aktiv.

Speicherbedarf und Rechenbedarf müssen deshalb getrennt betrachtet werden.

80. Auxiliary-Loss-Free Load Balancing

V3 führte eine Strategie zur MoE-Lastverteilung ohne klassischen zusätzlichen Balancing-Loss ein.

Ziel ist, Experten gleichmäßiger zu nutzen, ohne Modellqualität durch einen starken Nebenverlust zu beeinträchtigen.

81. Multi-Token Prediction

V3 trainiert zusätzlich darauf, mehrere zukünftige Tokens vorherzusagen.

Das kann Repräsentationen verbessern und später spekulative Dekodierung unterstützen.

82. FP8-Training

DeepSeek setzte umfangreich FP8-Training ein, um Rechen- und Speicherbedarf zu reduzieren.

Niedrigere Präzision verlangt sorgfältige numerische Stabilisierung.

83. H800-Training

DeepSeek bezifferte den vollständigen V3-Trainingsaufwand mit 2,788 Millionen H800-GPU-Stunden.

Diese Zahl wurde weltweit diskutiert, beschreibt aber nicht sämtliche Forschungs-, Daten- oder Vorentwicklungsaufwände.

84. Trainingskosten richtig einordnen

Aus GPU-Stunden lässt sich ein theoretischer Rechenpreis ableiten.

Eine reine Zahl für den finalen Lauf ist nicht identisch mit den gesamten Unternehmens- oder Forschungsentwicklungskosten.

85. DualPipe

DeepSeek entwickelte eine Pipeline-Parallelismusstrategie zur besseren Überlappung von Kommunikation und Berechnung.

Distributed Training ist ein wesentlicher Teil der Effizienzgeschichte.

86. Expert Parallelism

MoE-Experten werden über GPUs und Nodes verteilt.

Kommunikationsmuster und Netzwerkbandbreite entscheiden stark über reale Effizienz.

87. Stabiles Training

DeepSeek berichtete, dass der vollständige V3-Lauf ohne irrecoverable loss spikes und ohne Rollback verlief.

Stabile Milliardenparameter-Trainingsläufe sind selbst ein technischer Erfolg.

88. Offene V3-Gewichte

DeepSeek veröffentlichte V3-Gewichte und technischen Bericht.

Self-Hosting des vollständigen Modells bleibt wegen der Größe ein Datacenter-Problem.

89. V3 hinter `deepseek-chat`

Die API blieb kompatibel, während der Alias Ende Dezember auf V3 umgestellt wurde.

Clientcode kann damit dasselbe Modelllabel senden und dennoch eine völlig neue Generation erhalten.

90. Schnellere API

DeepSeek bewarb V3 mit deutlich höherer Ausgabegeschwindigkeit als V2.

Serverauslastung und Rate Limits beeinflussen reale Nutzerwerte.

91. 24. März 2025: V3-0324

Ein V3-Update verbesserte Reasoning, Coding, chinesisches Schreiben, Übersetzung und Function Calling.

Datierte API-Revisionen sollten bei Benchmarks mitnotiert werden.

92. Frontend-Code

DeepSeek hob bei V3-0324 besonders bessere Webseiten- und Spielefrontends hervor.

Ästhetische Ausgabe und funktionale Korrektheit werden getrennt geprüft.

93. Chinesische Search-Fähigkeit

Der gehostete Dienst optimierte auch Search-nahe Nutzung.

Search ist eine Produktschicht und nicht allein ein Modellgewicht.

94. V3 als Basis für R1

DeepSeek-R1 und R1-Zero wurden auf DeepSeek-V3-Base aufgebaut.

Die Reasoningrevolution von R1 nutzt damit die V3-Architektur als Foundation.

95. 20. Januar 2025: DeepSeek-R1

DeepSeek-R1 machte DeepSeek weltweit bekannt als offene Reasoning-Modellfamilie.

Das Modell zielte auf Mathematik, Code und allgemeines mehrstufiges Reasoning und wurde zusammen mit Technical Report und Gewichten veröffentlicht.

96. DeepSeek-R1-Zero

R1-Zero wurde mit großskaligem Reinforcement Learning ohne vorausgehendes klassisches SFT als eigentlicher Reasoning-Versuch trainiert.

Das Modell zeigte spontan lange Reasoningketten, Selbstprüfung und strategisches Verhalten.

97. Probleme von R1-Zero

DeepSeek dokumentierte Wiederholungsschleifen, schlechte Lesbarkeit und Sprachmischung.

Diese Probleme zeigen, dass hohe Reward-Performance nicht automatisch gute Endnutzerkommunikation ergibt.

98. Cold-Start-Daten

R1 ergänzt vor dem großen RL-Lauf eine kleine Menge kuratierter Reasoning-Beispiele.

Das verbessert Lesbarkeit, Format und Stabilität, ohne den RL-Schwerpunkt aufzugeben.

99. Großskaliges Reinforcement Learning

R1 wurde über mehrere RL-Phasen auf verifizierbare Reasoningaufgaben und allgemeineres Verhalten optimiert.

Automatisch prüfbare Rewards sind besonders für Mathematik und Code wertvoll.

100. GRPO in R1

Group Relative Policy Optimization aus DeepSeekMath wurde zum zentralen RL-Verfahren.

Antwortgruppen werden relativ bewertet, wodurch kein ebenso großes separates Value Model nötig ist.

101. Verifizierbare Rewards

Mathematik und Programmierung erlauben teilweise harte automatische Korrektheitsprüfungen.

Solche Rewards sind robuster als rein subjektive Stilbewertungen.

102. Emergente Reasoning-Verhaltensweisen

DeepSeek beobachtete längere Analyse, Selbstkorrektur und alternative Lösungswege im RL-Prozess.

„Emergent“ bedeutet dabei nicht magisch, sondern statistisch aus Training und Rewardstruktur entstanden.

103. Aha-Moment

Im Paper wurde ein qualitativer Moment hervorgehoben, in dem R1-Zero seine Strategie während der Lösung sichtbar neu bewertet.

Solche Beispiele sind illustrative Einzelfälle und keine Garantie für jedes Problem.

104. Thinking/Reasoning Content

R1 macht einen separaten Reasoningstrom vor der finalen Antwort sichtbar.

Spätere DeepSeek-Generationen unterscheiden weiterhin Thinking- und Non-Thinking-Modi.

105. 128K Kontext

R1 und R1-Zero wurden mit 128K Kontext veröffentlicht.

Großer Kontext ist getrennt von der Länge des erzeugten Reasonings.

106. 671B/37B

R1 übernimmt die V3-MoE-Grundarchitektur mit 671B Gesamt- und 37B aktivierten Parametern.

Das vollständige Modell bleibt für lokale Consumerhardware extrem groß.

107. MIT-Lizenz

DeepSeek stellte R1 und die Modellgewichte unter MIT-Lizenz.

Das erleichtert Forschung, Distillation und kommerzielle Nutzung erheblich.

108. `deepseek-reasoner`

Der gehostete API-Pfad für R1 hieß `deepseek-reasoner`.

Dieser Alias wurde später mehrfach auf neuere Reasoningmodelle umgestellt und 2026 zugunsten V4-Namen abgekündigt.

109. DeepThink im Web

Der Webdienst machte R1 über einen DeepThink-/Reasoningmodus für Endnutzer zugänglich.

Websuche und Reasoningmodus sind getrennte Produktfunktionen.

110. Niedrige API-Preise

R1 wurde zu deutlich niedrigeren Tokenpreisen als viele zeitgenössische Frontierreasoner angeboten.

Preisvergleiche sind stichtagsabhängig und sagen nichts über Hostingkosten bei Self-Hosting.

111. R1-Distill

DeepSeek veröffentlichte sechs kleinere dichte Modelle, die mit von R1 erzeugten Reasoningdaten feinabgestimmt wurden.

Distillation überträgt Reasoningmuster auf kleinere Basismodelle.

112. R1-Distill-Qwen-1.5B

Die kleinste Distill-Variante basiert auf Qwen2.5-Math 1.5B.

Sie ist für lokale Experimente sehr leichtgewichtig, aber keine Miniaturkopie aller R1-Fähigkeiten.

113. R1-Distill-Qwen-7B

Die 7B-Variante basiert auf Qwen2.5-Math 7B.

Sie eignet sich für lokale Reasoningexperimente mit moderater Hardware.

114. R1-Distill-Llama-8B

Diese Variante basiert auf Llama 3.1 8B.

DeepSeek-Reasoningdaten und Meta-Basismodell müssen lizenzseitig gemeinsam betrachtet werden.

115. R1-Distill-Qwen-14B

Die 14B-Klasse bietet mehr Kapazität bei weiterhin lokal realistischerem Betrieb.

Quantisierung kann den Hardwarebedarf stark senken.

116. R1-Distill-Qwen-32B

32B wurde als besonders starker dichte Reasoning-Checkpoint bekannt.

DeepSeek berichtete Benchmarkwerte auf beziehungsweise über damaligem o1-mini-Niveau.

117. R1-Distill-Llama-70B

Die größte Distill-Variante basiert auf Llama 3.3 70B Instruct.

Sie bleibt wesentlich kleiner als R1 671B, benötigt aber weiterhin starke Serverhardware.

118. Distill ≠ vollständiges R1

Die Distill-Modelle haben andere Architekturen, andere Parameterzahlen und nicht dieselben Gewichte wie R1.

Sie lernen aus R1-Ausgaben, sind aber eigenständige Modelle.

119. Warum Distillation wichtig ist

DeepSeek zeigte, dass hochwertige Reasoning-Trajektorien von großen Modellen kleineren Modellen stärker helfen können als RL nur auf kleinen Modellen.

Das prägte 2025 die offene Reasoningmodell-Landschaft.

120. Lokale R1-Nutzung

Das vollständige R1 erfordert sehr große Hardware, Distill-Varianten sind dagegen auf Workstations und teils Consumer-PCs realistisch.

„DeepSeek lokal“ meint deshalb in vielen Fällen ein Distill oder eine Quantisierung.

121. Quantisierung

Community und Inferenzanbieter veröffentlichten zahlreiche 4-/5-/8-Bit-Quantisierungen.

Quantisierung kann Reasoning und lange Kontexte stärker beeinflussen als einfache Kurzantworten.

122. Sampling-Empfehlungen

DeepSeek veröffentlichte für R1 konkrete Sampling- und Promptempfehlungen.

Reasoningmodelle können empfindlich auf Temperatur und Systemprompts reagieren.

123. Systemprompt-Empfehlung

DeepSeek empfahl für frühes R1 teilweise, Systeminstruktionen in die User-Nachricht zu integrieren.

Diese Empfehlung gilt nicht automatisch für spätere V3.1/V4-Chattemplates.

124. Sehr lange Outputs

R1 kann bei schwierigen Aufgaben deutlich mehr Tokens verbrauchen als klassische Chatmodelle.

Mehr Reasoningtokens bedeuten nicht automatisch bessere Antwort.

125. R1 halluziniert weiterhin

Reasoning und Selbstprüfung reduzieren manche Fehler, beseitigen Halluzinationen aber nicht.

Besonders bei Faktenwissen ohne Retrieval bleibt Quellenprüfung nötig.

126. Sprachmischung

R1-Zero zeigte starke Sprachmischung; R1 wurde dagegen gezielt lesbarer post-trainiert.

Lokale Finetunes können dieses Verhalten wieder verändern.

127. Safety von offenem R1

Bei offenen Gewichten kann ein Betreiber Moderation und Alignment verändern.

Lokaler Betrieb überträgt Safety-Verantwortung an den Betreiber.

128. Warum R1 wichtig war

R1 demonstrierte, dass starke Reasoningmodelle offen veröffentlicht und relativ günstig angeboten werden können.

Der Release löste weltweit Investitionen in RL, Distillation und offene Reasoningmodelle aus.

129. Ökosystemwirkung

R1-Distills wurden rasch in Ollama, llama.cpp, vLLM, SGLang, LM Studio und viele Cloudanbieter integriert.

Das Ökosystem ist breiter als DeepSeeks eigener Webdienst.

130. 28. Mai 2025: R1-0528

DeepSeek aktualisierte `deepseek-reasoner` auf R1-0528 mit deutlich stärkeren Reasoning-, Coding- und Frontendfähigkeiten.

DeepSeek meldete zugleich weniger Halluzinationen als beim ursprünglichen R1.

131. Function Calling

R1-0528 ergänzte verbesserte Function-Calling-Fähigkeiten.

Reasoningmodell und Toolausführung wachsen damit zusammen.

132. JSON Output

Strukturierte Ausgabe wurde auch für den Reasoningpfad verbessert.

Schema-Validierung bleibt nötig.

133. 21. August 2025: DeepSeek-V3.1

V3.1 führte eine hybride Reasoningarchitektur ein: dasselbe Modell kann Thinking und Non-Thinking.

Die zuvor stärker getrennten Chat- und Reasoningpfade werden damit in einem Checkpoint zusammengeführt.

134. Hybrid Thinking

Ein Modell kann je nach Anfrage oder Modus mit oder ohne ausführlicheres Reasoning antworten.

Das reduziert die Notwendigkeit separater `chat`- und `reasoner`-Gewichte.

135. Effizienteres Thinking

DeepSeek beschrieb V3.1-Think als schneller als R1-0528 bei vergleichbarer Reasoningklasse.

Tokenbudget und Toolnutzung beeinflussen die reale Latenz.

136. Stärkere Agenten

V3.1 wurde besonders für Tool Use, Code Agent und Search Agent nachtrainiert.

Agentenfähigkeit wird damit zum expliziten Trainingsziel.

137. Tool Calls in Thinking

V3.1 kann Reasoning und Werkzeugaufrufe enger kombinieren.

Ein Tool darf nie allein aufgrund des Modellreasonings hohe Rechte erhalten.

138. 22. September 2025: V3.1-Terminus

Terminus korrigierte unter anderem Sprachmischung, ungewöhnliche Zeichen und Agentenprobleme.

Der Name bezeichnet einen stabilisierenden V3.1-Zwischenstand.

139. 29. September 2025: V3.2-Exp

V3.2-Exp experimentierte mit effizienterer Long-Context-Aufmerksamkeit.

Der Experimentalstand führte später zur stabilen V3.2-Version.

140. DeepSeek Sparse Attention

V3.2 führt DeepSeek Sparse Attention als effizientere Aufmerksamkeit für lange Kontexte ein.

Ziel ist, nicht für jedes Token vollständige quadratische Attention berechnen zu müssen.

141. 1. Dezember 2025: DeepSeek-V3.2

V3.2 harmonisierte effizientere Inferenz mit stärkerem Reasoning und Agentenleistung.

Die API-Aliase `deepseek-chat` und `deepseek-reasoner` zeigten auf Non-Thinking beziehungsweise Thinking desselben Modells.

142. Agentic AI

V3.2 wurde besonders auf komplexe Tool- und Agentenaufgaben optimiert.

Agentenharness und Modell müssen gemeinsam evaluiert werden.

143. V3.2-Speciale

DeepSeek bot kurzfristig eine High-Compute-Speciale-Variante für besonders anspruchsvolles Reasoning.

Der temporäre API-Endpunkt war nur bis Mitte Dezember 2025 vorgesehen.

144. Speciale ohne Tool Calls

Der temporäre High-Compute-Pfad verzichtete auf Tool Calls.

Reines Reasoning und Agentenfähigkeit sind damit klar getrennt.

145. DeepSeek-Math-V2

Ende 2025 veröffentlichte DeepSeek eine neue Mathematiklinie auf V3.2-Größe.

Sie setzt die Kombination aus großem Foundation-Modell und verifizierbarer Mathematik fort.

146. DeepSeek-Prover-V2

Prover-V2 wurde in 7B und 671B veröffentlicht; die große Variante baut auf V3-Base auf.

Formale Proof-Generierung bleibt ein eigener DeepSeek-Forschungszweig.

147. DeepSeek-ProverBench

DeepSeek veröffentlichte einen Benchmark mit 325 formalen Beweisaufgaben aus mehreren Mathematikgebieten.

Eigene Benchmarks sollten zusätzlich durch unabhängige Evaluation ergänzt werden.

148. DeepSeek-VL2

VL2 entwickelte die Vision-Language-Linie mit MoE-Architektur weiter.

Sie bleibt historisch getrennt von der späteren V4-Flash-Vision-API.

149. Janus

Janus untersuchte ein einheitliches Modell für multimodales Verständnis und Bildgenerierung.

DeepSeek trennte dabei interne Repräsentationspfade, um die widersprüchlichen Anforderungen von Understanding und Generation besser zu bedienen.

150. 13. November 2024: JanusFlow

JanusFlow kombinierte autoregressives Sprachmodell und Rectified Flow für Bildgenerierung.

Es ist ein Forschungs-/Open-Weight-Modell und keine Funktion des normalen DeepSeek-Chats.

151. 27. Januar 2025: Janus-Pro

Janus-Pro verbesserte multimodales Verständnis und Bildgenerierung.

Die bekannteste offene Variante besitzt 7B Parameter.

152. 20. Oktober 2025: DeepSeek-OCR

DeepSeek-OCR untersuchte visuelle Kompression von Dokumentkontext und OCR.

Dokumentseiten werden in kompakte Visiontokens transformiert, um lange Textkontexte effizienter abzubilden.

153. Contexts Optical Compression

Die Forschungsfrage lautet, wie viel Textinformation über Bilder komprimiert in ein Sprachmodell gelangen kann.

Das ist zugleich OCR- und Long-Context-Forschung.

154. Layout und Markdown

DeepSeek-OCR kann Dokumente mit Layoutbezug in Markdown umwandeln.

OCR-Fehler und Layoutrekonstruktionsfehler werden getrennt geprüft.

155. 27. Januar 2026: DeepSeek-OCR2

OCR2 setzt die optische Kompressionslinie fort.

Es ist ein spezialisiertes 3B-Klasse-Modell und kein Ersatz für V4-Pro.

156. 24. April 2026: DeepSeek-V4

DeepSeek veröffentlichte V4 als neue Modellgeneration mit zwei Hauptklassen: V4-Flash und V4-Pro.

Beide unterstützen Thinking und Non-Thinking und wurden für 1-Million-Token-Kontext ausgelegt.

157. V4-Flash Preview

Die ursprüngliche Flash-Klasse wurde als effizienteres Workhorse-Modell der V4-Familie positioniert.

Sie ist eigenständig trainiert und nicht nur eine Quantisierung von Pro.

158. V4-Pro Preview

Pro bildet die größere Wissens-, Reasoning- und Agentenklasse.

Der Previewstand wurde im August 2026 durch die GA-Version V4-Pro-0813 ersetzt.

159. V4-Flash: ursprüngliche V4-Architekturgröße

Der ursprüngliche technische V4-Report beschreibt Flash mit 284B Gesamt- und 13B aktiven Parametern.

Spätere veröffentlichte 0731-Artefakte werden von Hostingkatalogen teils mit leicht abweichender Gesamtgröße ausgewiesen; für Architekturangaben bleibt der Technical Report maßgeblich.

160. V4-Pro: ursprüngliche V4-Architekturgröße

Der technische V4-Report beschreibt Pro mit 1,6 Billionen Gesamt- und 49B aktiven Parametern.

Das aktuelle V4-Pro-0813-Hugging-Face-Artefakt wird als ungefähr 1,7T Modellgröße ausgewiesen; Releaseartefakt und ursprünglicher Report werden deshalb getrennt dokumentiert.

161. 1 Million Tokens

Die V4-Familie erweitert den Kontext massiv auf eine Million Tokens.

Maximaler Kontext verlangt enorme KV-/Attentioneffizienz und ist nicht gleichbedeutend mit perfekter Aufmerksamkeit.

162. Bis zu 384K Output

Die aktuelle API-Dokumentation nennt eine maximale Ausgabelänge bis 384K Tokens für V4.

Solche Extremwerte sind nur für Spezialfälle sinnvoll und können sehr hohe Kosten und Latenz verursachen.

163. Neue Attention-Effizienz

V4 baut die Long-Context-Linie von MLA und Sparse Attention weiter aus.

Der technische Schwerpunkt liegt auf stark komprimierten Attentionzuständen und effizientem Million-Token-Serving.

164. Hybridisierte Attention

V4 kombiniert stark komprimierte und sparse Attentionpfade.

Ziel ist, Wissen und Long Context mit deutlich geringerem KV- und FLOP-Aufwand als V3.2 zu bedienen.

165. Manifold-Constrained Hyper-Connections

V4 verwendet eine Hyper-Connection-Technik, die Informationspfade über Schichten erweitert und zugleich Stabilität kontrollieren soll.

Solche Architekturdetails sind Trainingsmechanismen, keine Endnutzeroption.

166. Muon Optimizer

DeepSeek verwendet in V4 den Muon-Optimizer für schnellere Konvergenz und Trainingsstabilität.

Optimierer beeinflussen Training, nicht direkt die API-Samplingparameter.

167. Über 32 Billionen Tokens

DeepSeek beschreibt für V4 mehr als 32 Billionen Pretraining-Tokens.

V4 verdoppelt damit grob die Datenmenge gegenüber V3.

168. Domänenspezifische Experten

Post-Training kultiviert zunächst spezialisierte Fähigkeiten über SFT und GRPO.

Anschließend werden die Fähigkeiten in einem gemeinsamen Modell konsolidiert.

169. On-Policy Distillation

DeepSeek vereinigt spezialisierte Expertisen über on-policy Distillation.

Das Modell lernt dabei von generierten Verhaltensspuren, die näher an seiner eigenen aktuellen Policy liegen.

170. FP4 + FP8

Die veröffentlichten Chatgewichte nutzen bei Teilen der MoE-Experten FP4 und bei anderen Komponenten FP8.

Gemischte Präzision reduziert Speicherbedarf, braucht aber spezialisierte Hardware- und Kernelunterstützung.

171. Base-Gewichte

V4-Base-Checkpoints werden mit FP8-gemischter Präzision bereitgestellt.

Base und Post-Trained/Chat sind unterschiedliche Gewichtsstände.

172. Thinking und Non-Thinking

V4 vereint beide Antwortpfade in derselben Modellfamilie.

Der Reasoningmodus kann explizit konfiguriert werden.

173. Reasoning Effort: low

`low` priorisiert geringe Latenz und kürzere Deliberation.

Für einfache Tool- oder Extraktionsaufgaben kann dies sinnvoller sein als maximale Denktiefe.

174. Reasoning Effort: high

`high` ist für typische komplexere Agenten- und Reasoningaufgaben gedacht.

Es erhöht typischerweise Tokenverbrauch und Latenz.

175. Reasoning Effort: max

`max` gibt dem Modell den größten Reasoning-Spielraum.

DeepSeek empfiehlt bei High/Max für lokale V4-Pro-Nutzung sehr große mögliche Outputbudgets.

176. Reasoning Effort ≠ eigenes Modell

Low, High und Max sind Inferenz-/Chattemplatekonfigurationen.

Sie dürfen nicht als drei unterschiedliche Checkpoints archiviert werden.

177. OpenAI-kompatible API

V4 kann über Chat Completions und Responses-nahe OpenAI-Formate angesprochen werden.

Syntaxkompatibilität bedeutet nicht vollständige Semantikgleichheit.

178. Anthropic-kompatible API

DeepSeek bietet zusätzlich einen Anthropic-kompatiblen API-Pfad.

Auch hier bleiben Modellverhalten, Toolsemantik und Tokenisierung DeepSeek-spezifisch.

179. JSON Output

V4 unterstützt strukturierten JSON-Output.

Produktion benötigt Schema-Validierung.

180. Tool Calls

V4 unterstützt Function-/Tool-Calling.

Agentenrechte müssen außerhalb des Modells kontrolliert werden.

181. Prefix Completion

Chat Prefix Completion bleibt als Beta-Funktion vorhanden.

Sie ist nützlich für erzwungene Ausgabeanfänge und bestimmte Codingflows.

182. FIM in Non-Thinking

Fill-in-the-Middle wird bei V4 nur im Non-Thinking-Pfad unterstützt.

Das passt besonders zu Codecompletion und Textinfilling.

183. `deepseek-chat` wird abgekündigt

Mit V4 kündigte DeepSeek an, den historischen Alias `deepseek-chat` zum 24. Juli 2026 einzustellen.

Vorher zeigte der Alias kompatibel auf V4-Flash Non-Thinking.

184. `deepseek-reasoner` wird abgekündigt

Auch der historische R1/V3-Reasoningalias sollte am 24. Juli 2026 enden.

Vorher zeigte er kompatibel auf V4-Flash Thinking.

185. Explizite V4-Modellnamen

Die aktuellen API-Namen sind `deepseek-v4-flash` und `deepseek-v4-pro`.

Explizite Namen verbessern Nachvollziehbarkeit gegenüber beweglichen historischen Aliasen.

186. Transparency Center

DeepSeek führt V4 und V3.2 in einem eigenen Transparency Center mit Release-Datum, Model Card und Technical Report.

Diese Primärseite ist für spätere Archivprüfungen besonders wertvoll.

187. 31. Juli 2026: DeepSeek-V4-Flash-0731

DeepSeek veröffentlichte den offiziellen Flash-Stand als Public Beta in der API.

Die Modellarchitektur blieb gegenüber dem Preview grundsätzlich gleich, das Post-Training wurde deutlich auf Agentenleistung verbessert.

188. Flash 0731 als Agentenmodell

DeepSeek meldete große Sprünge auf Terminal-, Repository-, Cyber-, Tool- und Automation-Benchmarks.

Herstellerbenchmarks werden als Herstellerangaben gekennzeichnet und nicht als unabhängiger Beweis übernommen.

189. DSpark in Flash 0731

Der offizielle Flash-Checkpoint enthält ein DSpark-Modul für speculative decoding.

Target- und Draft-Komponenten werden gemeinsam ausgeliefert.

190. Responses API

Flash 0731 unterstützt nativ das Responses-API-Format.

DeepSeek hat das Modell ausdrücklich für Codex-kompatible Agentenflüsse angepasst.

191. Codex-Integration

DeepSeek dokumentiert V4-Flash für OpenAI-Codex-nahe Toolchains.

Ein kompatibler Agentenclient macht das DeepSeek-Modell nicht zu einem OpenAI-Modell.

192. 13. August 2026: DeepSeek-V4-Pro-0813 GA

V4-Pro-0813 ist die offizielle GA-Pro-Version und ersetzt den Previewstand.

Sie ist am Stichtag die leistungsstärkere allgemeine DeepSeek-V4-Klasse für Wissen, Coding und komplexe Agenten.

193. V4-Pro im Web und in der App

DeepSeek stellte V4-Pro-0813 zugleich im Web und der mobilen App bereit.

Dort wird die leistungsfähigere Variante über einen Expert-Mode-Pfad zugänglich gemacht.

194. V4-Pro in der API

Der API-Modellname bleibt `deepseek-v4-pro` und zeigt auf den aktuellen GA-Stand.

Für reproduzierbare Forschung ist zusätzlich die konkrete 0813-Gewichtsrevision sinnvoll.

195. Responses API für Pro

Mit dem GA-Release unterstützt auch V4-Pro nativ Responses API.

Agentenclients können damit Reasoning-, Tool- und Responseobjekte strukturierter austauschen.

196. DSpark im Pro-Checkpoint

V4-Pro-0813 baut auf dem Preview-Modell auf und fügt DSpark speculative decoding hinzu.

Spekulative Dekodierung soll Ausgabe beschleunigen, ohne die Zielverteilung zu verändern.

197. Agenten-Benchmarks

DeepSeek meldet gegenüber dem Preview große Verbesserungen bei Terminal Bench, NL2Repo, DeepSWE, Toolathlon und AutomationBench.

Benchmarkbedingungen wie Harness, Reasoning Effort und Sampling gehören zur Ergebnisangabe.

198. DeepSeek Harness bei Evaluation

Für Code-Agent-Benchmarks evaluiert DeepSeek V4-Pro-0813 mit dem eigenen Harness im Minimalmodus und `max` Reasoning.

Modell und Agentenharness müssen deshalb gemeinsam betrachtet werden.

199. V4-Sampling

Für lokale V4-Nutzung empfiehlt DeepSeek typischerweise Temperatur 1.0; bei Agenten top_p 0.95, sonst 1.0.

Diese Herstellerempfehlung ist ein Ausgangspunkt und kein universelles Optimum.

200. V4-Pro lokal

Das vollständige V4-Pro-0813 ist extrem groß und erfordert Datacenterklasse-Hardware.

Die Existenz offener Gewichte bedeutet nicht Consumer-PC-Tauglichkeit.

201. V4-Flash lokal

V4-Flash ist erheblich kleiner als Pro, bleibt aber ein großes MoE-Modell.

Quantisierte oder spezialisierte Servingpfade sind für lokale/On-Prem-Nutzung praktisch entscheidend.

202. 21. August 2026: V4-Flash-Vision-Exp

DeepSeek veröffentlichte einen experimentellen multimodalen Vision-API-Pfad.

Er kombiniert Text- und Bildinput mit V4-Flash-naher Text-, Reasoning- und Agentenleistung.

203. Textfähigkeiten von Vision-Exp

DeepSeek beschreibt die reinen Textfähigkeiten als auf dem Niveau des offiziellen V4-Flash.

Multimodalität wird also als Erweiterung des Flash-Agentenpfads angeboten.

204. Bildinput

Vision-Exp kann Bilder beschreiben, Screenshots lesen und Diagramme analysieren.

Bildverständnis ist nicht dasselbe wie Bildgenerierung.

205. JPEG, PNG, GIF, WebP

Die aktuelle API akzeptiert mehrere verbreitete Bildformate.

Dateiendungen allein bestimmen das Format nicht; DeepSeek prüft den tatsächlichen Dateiinhalt.

206. Files API

Mit Vision-Exp führte DeepSeek eine Files API ein, um Bilder einmal hochzuladen und per File-ID wiederzuverwenden.

Persistenz- und Datenschutzbedingungen von Uploads sollten separat geprüft werden.

207. Chat Completions und Responses

Visionbilder können über OpenAI-kompatible Content Blocks oder Responses-Input-Items gesendet werden.

Nur der Vision-Endpunkt verarbeitet diese Bildteile tatsächlich.

208. Nur Vision-Modell verarbeitet Bilder

Normale V4-Pro/Flash-Textmodelle akzeptieren kein echtes Bildverständnis im gleichen API-Pfad.

Ein Bildplatzhalter oder Clientfeature darf nicht als Modellvision missverstanden werden.

209. Multimodale Agenten

Vision-Exp kann Screenshots aus Tools verarbeiten und darauf weitere Aktionen ableiten.

Dies ist ein wichtiger Baustein für Computer-Use-Agenten.

210. Screenshot-Sicherheit

Screenshots können Passwörter, personenbezogene Daten und Prompt-Injection-Inhalte enthalten.

Vision-Agenten benötigen deshalb dieselben Least-Privilege-Regeln wie Browseragenten.

211. Experimental

Der Name `deepseek-v4-flash-vision-exp` kennzeichnet ausdrücklich einen experimentellen Modellstand.

Produktive Integrationen sollten mit Änderungen und möglichen Inkompatibilitäten rechnen.

212. Aktuelle DeepSeek-API-Modelle am 1. September 2026

Die aktuelle Preisseite führt V4-Flash-0731, V4-Pro-0813 und V4-Flash-Vision-Exp.

Diese Liste ist stichtagsbezogen und kann kurzfristig aktualisiert werden.

213. Peak-/Off-Peak-Preise

DeepSeek führte im August 2026 zeitabhängige API-Preise ein.

Kostenkalkulation muss deshalb Uhrzeit, Modell, Cache-Hit und Tokenrichtung berücksichtigen.

214. Cache-Hits

Wiederverwendete Eingabetokens sind deutlich günstiger als Cache-Misses.

Das begünstigt lange stabile System-/Repositorypräfixe.

215. Concurrency

Flash und Vision besitzen höhere dokumentierte Parallelitätsgrenzen als Pro.

Durchsatzplanung muss Modellklasse und Rate Limit gemeinsam berücksichtigen.

216. DeepSpec

DeepSpec ist DeepSeeks offenes Forschungs- und Trainingsframework für speculative decoding.

Es bündelt unter anderem DSpark, DFlash und Eagle3 als Draft-/Speculation-Ansätze.

217. Speculative Decoding

Ein kleinerer oder zusätzlicher Draft-Pfad schlägt mehrere Tokens voraus, die das große Zielmodell anschließend akzeptiert oder verwirft.

Ziel ist mehr Ausgabetokens pro Sekunde ohne Änderung der Zielmodellverteilung.

218. DSpark

DSpark ist DeepSeeks Confidence-Scheduled Speculative-Decoding-Ansatz mit semi-autoregressiver Generierung.

Er wird 2026 direkt in V4-Flash-0731 und V4-Pro-0813 integriert.

219. Confidence Scheduling

DSpark nutzt eine Konfidenzschätzung, um zu entscheiden, wie aggressiv mehrere Tokens spekulativ vorgeschlagen werden.

Zu aggressive Drafts erhöhen Verwerfungen und sparen dann weniger Zeit.

220. Mehrere speculative Tokens

V4-Rezepte zeigen DSpark-Konfigurationen mit mehreren Drafttokens pro Schritt.

Die optimale Zahl hängt von Hardware, Modell und Acceptance Rate ab.

221. DFlash

DFlash ist ein weiterer Draft-Modellpfad im DeepSpec-Framework.

Die Forschung vergleicht verschiedene Kompromisse zwischen Draftkosten und Akzeptanz.

222. Eagle3

DeepSpec unterstützt zusätzlich Eagle3 als Vergleichs-/Draftalgorithmus.

Nicht jeder von DeepSpec unterstützte Algorithmus stammt ursprünglich von DeepSeek.

223. DeepSpec ist MIT-lizenziert

Das Framework kann für Forschung und eigene Zielmodelle verwendet werden.

Abhängigkeiten behalten ihre jeweiligen Drittanbieter-Lizenzen.

224. Speculative Decoding ≠ Quantisierung

Speculative Decoding beschleunigt Generierung durch Vorhersage und Verifikation.

Quantisierung reduziert numerische Präzision und Speicherbedarf; beide Techniken können kombiniert werden.

225. Speculative Decoding ≠ MoE

MoE reduziert aktive Modellteile pro Token; speculative decoding reduziert Zahl teurer autoregressiver Zielmodellschritte.

Die Optimierungen wirken an unterschiedlichen Stellen.

226. Agenten profitieren von schneller Dekodierung

Agenten erzeugen viele kurze Toolentscheidungen und lange Codingtraces.

Mehr Tokens pro Sekunde kann deshalb den gesamten Agentendurchsatz stark verbessern.

227. Speculative Evaluation

Leistungsvergleiche müssen Acceptance Rate, Draftkosten, Batchgröße und Hardware angeben.

Eine reine Tokens-pro-Sekunde-Zahl ohne Kontext ist kaum übertragbar.

228. DeepSeek Harness

DeepSeek Harness (`dsh`) ist 2026 DeepSeeks eigenes offenes Agentenharness.

Es ist ausdrücklich Developer Preview und kann inkompatible Änderungen erhalten.

229. Everything is a Plugin

Das Harness baut Tools, Agentenloop, UI, Speicher, Skills und Erweiterungen als Plugins.

Die Architektur priorisiert Komponierbarkeit und schnelle Experimente.

230. Cordis

DeepSeek Harness basiert auf Cordis als Plugin-/Runtime-Grundlage.

Das Framework organisiert Services, Events, Lebenszyklen und dynamische Erweiterungen.

231. Lokale Weboberfläche

Das Harness kann lokal eine Web-UI starten.

Die Oberfläche ist ein Client für den Agentenruntime und nicht der DeepSeek-Webchat.

232. Mehrere Modellprovider

Ein Agentenharness kann unterschiedliche LLM-Provider anbinden.

DeepSeek Harness ist deshalb nicht zwingend auf DeepSeek-Modelle beschränkt.

233. Tools

Plugins können Shell, Browser, Dateien, Search, MCP und andere Werkzeuge bereitstellen.

Jedes Tool besitzt eigene Sicherheitsgrenzen.

234. Agent Loop

Der Kernloop organisiert Modellaufruf, Toolausführung, Beobachtung und nächsten Schritt.

Loopdesign beeinflusst Agentenleistung erheblich.

235. Eventbasierte Erweiterbarkeit

DeepSeek dokumentiert Events für Pre-Step, Request, Tool-Execution, Streaming und Stopentscheidungen.

Plugins können dadurch Verhalten transformieren oder überwachen.

236. Skills

Wiederverwendbare Agentenfähigkeiten können als Skills/Plugins gebündelt werden.

Ein Skill ist Instruktion plus Tool-/Runtimewissen, kein Foundation-Modell.

237. MCP

Der Harness kann Model Context Protocol als Werkzeug- und Datenzugriffsschicht verwenden.

MCP-Kompatibilität garantiert keine sichere Toolkonfiguration.

238. Memory

Plugins können Erfahrungen, Zustände und Arbeitskontext speichern.

Persistenz braucht explizite Lösch- und Berechtigungsregeln.

239. Context Compaction

Lange Agentensitzungen können komprimiert werden, damit zentrale Informationen im Kontext bleiben.

Komprimierung kann Details verlieren.

240. Sandbox

Code- und Shellwerkzeuge sollten isoliert ausgeführt werden.

Eine Sandbox ist nur so stark wie die tatsächlich exponierten Rechte.

241. Self-Referential Cordis Toolset

Ein experimenteller Harness-Pfad erlaubt Agenten, ihre eigene Plugin-Runtime zu inspizieren und temporär zu erweitern.

DeepSeek weist ausdrücklich darauf hin, dass dies kein Security Boundary ist und bash-ähnliches Vertrauen verlangt.

242. Dynamische Plugins

Ein Agent kann temporäre Werkzeuge oder UI-Komponenten zur Laufzeit definieren.

Solche Erweiterungen müssen validierbar und vollständig wieder entfernbar sein.

243. Disposable Runtime Extensions

Temporäre Erweiterungen sollen nach der Aufgabe verschwinden können.

Das reduziert langlebigen Zustand und unbeabsichtigte Nebeneffekte.

244. Developer Preview

DeepSeek warnt vor Breaking Changes und fehlender Kompatibilitätsgarantie.

Produktionssysteme sollten Versionen pinnen und Upgrades testen.

245. MIT-Lizenz

DeepSeek Harness wird unter MIT veröffentlicht.

Third-Party-Komponenten werden separat attribuiert.

246. Code Agent

V4 wurde auf Coding-Agent-Benchmarks mit Harness evaluiert.

Die gemessene Agentenleistung gehört daher zum Modell-plus-Harness-System.

247. Search Agent

V3.1/V3.2/V4 betonen zusätzlich Search-Agent-Fähigkeiten.

Search braucht einen Retrievalprovider und Quellenprüfung außerhalb des Modells.

248. Browseragenten

Mit Vision-Exp können Screenshots in den Agentenloop eingespeist werden.

Visuelle Browsersteuerung erhöht Prompt-Injection- und Fehlklickrisiko.

249. Repositoryarbeit

Agenten können große Codebasen durchsuchen, ändern und testen.

Branches, Diffs, CI und Secret Scanning bleiben Pflicht.

250. Tool Schemas

Strukturierte Schemas definieren Parameter für Modellaufrufe.

Providerunterschiede bei JSON Schema können zu Laufzeitfehlern führen.

251. Providerkompatibilität

Das Harness muss Unterschiede in Rollen, Toolcalls, Reasoningfeldern und Streaming zwischen APIs abstrahieren.

OpenAI-kompatibel heißt nicht identisch.

252. Observability

Agenten benötigen Logs zu Modellcalls, Tools, Fehlern und Kosten.

Logs selbst können vertrauliche Inhalte enthalten.

253. Permissions

Tools sollten standardmäßig minimale Rechte besitzen.

Ein Agent darf sich Rechte nicht aus Web- oder Dokumentinhalt selbst erweitern.

254. Human Approval

Irreversible Aktionen brauchen Bestätigung.

Agentenautonomie wird gezielt an Risikoklassen gekoppelt.

255. DeepSeek Web

chat.deepseek.com bietet den gehosteten Endnutzerzugang.

Webmodell, Search, Account und Moderation bilden einen anderen Stack als lokale Gewichte.

256. DeepSeek App

Die mobile App stellt denselben Dienst auf Smartphoneplattformen bereit.

App-Store-Verfügbarkeit kann je nach Land regulatorisch eingeschränkt sein.

257. Kostenloser Chat

DeepSeek bewirbt den Webdienst weiterhin als kostenlosen Zugang zur aktuellen Modellintelligenz.

Kostenloser Consumerzugang ist getrennt von API-Billing.

258. Expert Mode

V4-Pro-0813 ist in Web und App über einen leistungsfähigeren Expert-Mode-Pfad verfügbar.

Produktbezeichnung und API-Modellname sind getrennte Ebenen.

259. DeepThink

Historisch bezeichnet DeepThink den Reasoningmodus im Consumerdienst.

Seit V3.1/V4 können Thinking und Non-Thinking aus derselben Modellfamilie kommen.

260. Web Search

Der DeepSeek-Dienst kann Websuche als aktuelles Grounding ergänzen.

Webquelle und Modellwissen sollten in kritischen Antworten getrennt erkennbar bleiben.

261. Dateiupload

Der Consumerdienst unterstützt Datei- und Dokumentarbeit.

Dateien können personenbezogene und vertrauliche Daten enthalten.

262. DeepSeek API

Die API verwendet die Basisadresse `https://api.deepseek.com` und unterstützt OpenAI-kompatible Aufrufe.

Open-Platform-Nutzung unterliegt eigenen Entwicklerbedingungen.

263. Anthropic-kompatibler API-Pfad

V4 kann zusätzlich über einen Anthropic-kompatiblen Base-URL-Pfad aufgerufen werden.

Das erleichtert Migration von Claude-Clients, ersetzt aber Tests nicht.

264. Responses API

Die aktuelle V4-API unterstützt das Responses-Format für Agenten und Tools.

Responsesobjekte können Reasoning, Function Calls und Tooloutputs strukturierter abbilden.

265. Chat Completions

Der klassische OpenAI-kompatible `/chat/completions`-Pfad bleibt verfügbar.

Ältere Clients können dadurch weiterarbeiten.

266. Thinking Mode API

V4 unterstützt Thinking innerhalb der gleichen Modellnamen.

Reasoningfelder und Chattemplate müssen vom Client korrekt verarbeitet werden.

267. Reasoning Content

APIs können getrennte Reasoninginhalte und finale Antwort transportieren.

Anwendungen sollten Reasoninginhalte nicht automatisch öffentlich protokollieren.

268. Multi-Round Conversation

Die API unterstützt mehrturnige Gespräche durch erneutes Senden des Verlaufs.

Die API ist nicht automatisch ein persönliches Memorysystem.

269. Stateless Responses

Die aktuelle Responses-API beschreibt sich als zustandslos; der Client sendet den benötigten Verlauf erneut.

Serverseitige Abrechnung/Logging und Conversation State sind getrennte Begriffe.

270. JSON Output aktuell

V4 kann strukturierte JSON-Antworten erzeugen.

Schema-Validierung und Retrylogik bleiben im Client.

271. Tool Calls aktuell

V4 unterstützt native Toolcalls.

Tools mit Seiteneffekten brauchen zusätzliche Freigaben.

272. Prefix Completion aktuell

Prefix Completion bleibt Beta.

Beta-Funktionen können sich ohne lange Stabilitätsgarantie ändern.

273. FIM Completion aktuell

FIM bleibt für Non-Thinking-Pfade verfügbar.

Es ist besonders für Code-Editoren relevant.

274. Context Caching aktuell

DeepSeek berechnet Cache-Hits deutlich günstiger.

Lange wiederkehrende Präfixe profitieren besonders.

275. Rate Limit & Isolation

DeepSeek dokumentiert Modellabhängige Concurrency-Grenzen und Isolation.

Hohe Parallelität kann Throttling auslösen.

276. Zeitabhängige Preise

Seit August 2026 unterscheidet DeepSeek Peak- und Off-Peak-Zeiten.

Batchjobs können gezielt in günstigere Zeitfenster verschoben werden.

277. Files API

Der Visionpfad kann Bilder per File-ID referenzieren.

Upload und Wiederverwendung sparen Bandbreite, schaffen aber persistente Datenobjekte.

278. Vision API

Nur `deepseek-v4-flash-vision-exp` verarbeitet echte Bildinputs.

Normale V4-Textmodelle dürfen nicht als Visionmodelle behandelt werden.

279. Service Status

DeepSeek betreibt eine Statusseite für API- und Dienststörungen.

Fehlerdiagnose sollte Serviceausfall von Clientfehlern trennen.

280. Account

Web/App-Nutzung kann Chatverlauf, Geräte- und Kontoinformationen mit dem Dienst verknüpfen.

Lokales Self-Hosting besitzt diesen Accountpfad nicht.

281. Search-Provider

DeepSeeks Privacy Policy nennt die Integration externer Such-APIs wie Bing als möglichen Datenpfad.

Searchanfragen können deshalb an Drittanbieter weitergegeben werden.

282. Produktfunktion ≠ Modellfähigkeit

File Upload, Search, Account, History und App-UI sind Produktschichten.

Ein heruntergeladenes V4-Modell enthält diese Funktionen nicht automatisch.

283. Self-Hosting

Offene DeepSeek-Gewichte können auf eigener Infrastruktur betrieben werden.

Der Betreiber übernimmt Hardware, Serving, Security, Moderation, Logging und Updates.

284. Hugging Face

DeepSeek veröffentlicht viele aktuelle Gewichte im verifizierten Hugging-Face-Account.

Für Archivierung sind exakte Repositorynamen und Revisionen wichtiger als nur der Marketingname.

285. ModelScope

Viele DeepSeek-Modelle werden zusätzlich über ModelScope bereitgestellt.

Mehrere Mirrors erleichtern Verfügbarkeit, erfordern aber Hash- und Versionsvergleich.

286. vLLM

vLLM gehört zu den wichtigsten Servingpfaden für V2/V3/R1/V4.

V4 nutzt spezielle Reasoning-, Tool- und speculative-decoding-Parser.

287. SGLang

SGLang unterstützt DeepSeek-Modelle inklusive großer MoE- und DSpark-Konfigurationen.

Servingparameter beeinflussen Performance, nicht das Training der Gewichte.

288. Transformers

Hugging Face Transformers kann viele DeepSeek-Modelle direkt laden.

Bei neuen Architekturen muss eine ausreichend aktuelle Library-Version verwendet werden.

289. `trust_remote_code`

Einige DeepSeek-Modelle benötigen herstellerspezifischen Modellcode.

Remote Code sollte nur aus vertrauenswürdigen Repositories ausgeführt werden.

290. Safetensors

Aktuelle Gewichte werden in sicheren Tensorformaten angeboten.

Ein sicheres Dateiformat verhindert nicht falsche oder manipulierte Modellinhalte.

291. Quantisierung

FP8, FP4, INT8, 4-Bit-Communityquants und andere Formate senken Speicherbedarf.

Je aggressiver die Quantisierung, desto stärker müssen Reasoning und Tool Calls neu evaluiert werden.

292. GGUF

Community-Konvertierungen machen R1-Distills und andere DeepSeek-Modelle in llama.cpp-Ökosystemen nutzbar.

GGUF-Dateien stammen nicht automatisch von DeepSeek selbst.

293. llama.cpp

llama.cpp ist besonders für kleinere DeepSeek-/R1-Distill-Modelle auf PCs und Macs relevant.

Vollständige V4-Pro-Inferenz liegt weit außerhalb typischer Consumerhardware.

294. Ollama

Ollama vereinfacht lokale Installation und API-Nutzung quantisierter DeepSeek-Modelle.

Tags können Communityquantisierungen und eigene Chattemplates enthalten.

295. LM Studio

LM Studio bietet eine grafische lokale Nutzung vieler DeepSeek-Derivate.

Das GUI-Produkt ist nicht Teil von DeepSeek.

296. Apple Silicon

Unified Memory macht Qwen-/Llama-basierte R1-Distills auf Macs praktisch interessant.

Speicherbandbreite und Modellgröße bestimmen die Geschwindigkeit.

297. NVIDIA GPUs

Datacenter-GPUs sind der Hauptpfad für vollständige V3/V4-Modelle.

MoE, FP8/FP4 und speculative decoding benötigen spezielle Kernel für maximale Effizienz.

298. AMD GPUs

vLLM/SGLang-Rezepte unterstützen Teile der V4-Familie auch auf aktuellen AMD-Accelerators.

Feature- und Performanceparität zu NVIDIA muss pro Release geprüft werden.

299. CPU-Inferenz

Kleine Distillmodelle können rein auf CPU laufen.

Große Modelle werden ohne GPU/NPU typischerweise sehr langsam.

300. RAM

Gewichtsgröße ist nur ein Teil des Speicherbedarfs.

KV-Cache, Runtime, Quantisierung, Batch und Kontextfenster kommen hinzu.

301. VRAM

GPU-Speicher entscheidet über vollständig lokale Inferenz oder Offloading.

Ein Modell kann mit kurzen Kontexten passen und bei langen Kontexten dennoch aus dem Speicher laufen.

302. KV-Cache lokal

Gerade 128K oder 1M Kontext kann trotz quantisierter Gewichte sehr großen zusätzlichen Speicher verlangen.

MLA und V4-Kompression reduzieren diesen Engpass, beseitigen ihn nicht.

303. Tensor Parallel

Große Modelle werden über mehrere GPUs verteilt.

Kommunikation zwischen GPUs kann zum Flaschenhals werden.

304. Expert Parallel

MoE-Experten können über Geräte verteilt werden.

DeepSeek-V4-Rezepte kombinieren Data und Expert Parallelism.

305. Pipeline Parallel

Schichten können auf mehrere Devices beziehungsweise Nodes verteilt werden.

Pipelinebubbles und Kommunikation beeinflussen Durchsatz.

306. FP8 KV Cache

Servingframeworks können den KV-Cache in niedrigerer Präzision speichern.

Speichergewinn muss gegen mögliche Qualitätsänderungen geprüft werden.

307. MTP/Speculative Serving

V3/V4-nahe Multi-Token-Techniken und DSpark beschleunigen Decoding.

Servingsoftware muss die jeweilige Modellgeneration korrekt unterstützen.

308. DeepGEMM

DeepSeek veröffentlichte optimierte Matrixmultiplikations-Kernels für FP8/MoE-Workloads.

Kerneloptimierung ist Hardware- und Runtimeabhängig.

309. DeepEP

DeepEP adressiert effiziente Kommunikation für Expert Parallelism.

Bei MoE kann Netzwerkkommunikation ebenso wichtig wie Rechenleistung sein.

310. FlashMLA

DeepSeek veröffentlichte optimierte Attention-Kernels für MLA.

Die Forschungssoftware zeigt, wie Modellarchitektur und Servingstack gemeinsam entwickelt werden.

311. Full-Stack-Optimierung

DeepSeek optimiert Modell, Präzision, Kernel, Kommunikation und speculative decoding gemeinsam.

Dieser Full-Stack-Ansatz erklärt einen Teil der hohen Effizienz.

312. R1 Distill 1.5B/7B/8B

Die kleinen Distillmodelle sind die leichtesten Wege zu DeepSeek-Reasoning auf Consumerhardware.

Sie besitzen nicht das Wissen oder die Agentenleistung von V4-Pro.

313. R1 Distill 14B/32B

Mittlere Distills bieten deutlich stärkere Reasoningqualität bei noch realistischer Workstationnutzung.

32B in hoher Präzision benötigt bereits erheblichen Speicher.

314. R1 Distill 70B

70B ist lokal auf großen Workstations oder mehreren GPUs möglich.

Es bleibt deutlich einfacher zu hosten als das 671B-R1.

315. V2-Lite lokal

V2-Lite demonstriert MLA/MoE in einer kleineren Klasse.

Historisch ist es besonders für Architekturtests interessant.

316. Coder-V2-Lite

Coder-V2-Lite 16B ist für lokale Codeexperimente deutlich handlicher als die 236B-Klasse.

Repositoryaufgaben profitieren dennoch von RAG und Tooling.

317. Janus lokal

Janus/Janus-Pro lassen sich als offene multimodale Forschungsmodelle lokal betreiben.

Sie sind nicht derselbe Modellpfad wie V4-Flash-Vision-Exp.

318. OCR/OCR2 lokal

DeepSeek-OCR-Modelle können Dokumente lokal analysieren.

Das ist für sensible PDFs oft datenschutzfreundlicher als ein gehosteter Chat.

319. Prover lokal

DeepSeek-Prover-V2 7B ist für formale Mathematik erheblich leichter zu hosten als die 671B-Variante.

Der Proof-Assistant-Stack muss zusätzlich installiert werden.

320. Lokale OpenAI-kompatible API

vLLM, SGLang und Ollama können lokale Endpunkte mit verbreiteten API-Schemata anbieten.

Ein lokaler Endpoint ist nicht die offizielle DeepSeek API.

321. Lokale Datenkontrolle

Bei vollständig lokalem Betrieb verlassen Prompts und Dateien den Rechner nicht über DeepSeek.

Websuche, Telemetrie, externe Tools oder Cloud-Embeddings können diesen Vorteil wieder aufheben.

322. Lokales Verhalten

Ein offener Checkpoint kann andere Moderation und politische Antwortmuster zeigen als der gehostete Dienst.

Modellgewichte, Systemprompt, Finetune und Hostpolicy müssen getrennt untersucht werden.

323. Lokale Safety

Self-Hosting ermöglicht mehr Kontrolle, entfernt aber serverseitige Schutzmechanismen.

Der Betreiber braucht eigene Content-, Tool- und Securityregeln.

324. Hashes

Für Archivierung werden Hashes der heruntergeladenen Gewichte und Konfigurationsdateien gespeichert.

So lässt sich später prüfen, ob ein Modell wirklich identisch ist.

325. Repository-Revision

Eine Hugging-Face-Revision oder Commit-ID gehört zum reproduzierbaren Stand.

Ein unveränderter Modellname kann aktualisierte Dateien erhalten.

326. Chattemplate

DeepSeek-Generationen besitzen unterschiedliche Chattemplates und Reasoningformate.

Ein falsches Template kann Qualität, Toolcalls und Thinking massiv verschlechtern.

327. V4-Encoding

V4-Pro-0813 liefert eigene Encoding-/Parsing-Skripte statt nur eines Jinja-Chattemplates.

Clients sollten diese Spezifikation beachten.

328. Sampling dokumentieren

Temperature, top_p, max tokens und Reasoning Effort gehören zum reproduzierbaren Teststand.

„Gleiches Modell“ ohne Samplingangaben ist kein sauberer Vergleich.

329. Seed und Nichtdeterminismus

Auch bei gesetztem Seed können GPU-Kernels, Parallelismus und Sampling Unterschiede erzeugen.

Reproduzierbarkeit ist probabilistisch, nicht absolut.

330. Eigene Evaluation

Lokale Quantisierung und Runtime sollten auf realen Aufgaben getestet werden.

Offizielle Herstellerbenchmarks bilden nicht jede Hardware- und Toolkombination ab.

331. DeepSeek Privacy Policy

Die aktuelle englische Privacy Policy wurde am 10. Februar 2026 aktualisiert.

Sie gilt für DeepSeek-Apps, Webseiten, Software und verbundene Services, soweit keine speziellere Regel greift.

332. Data Controller

Als Verantwortlicher wird Hangzhou DeepSeek Artificial Intelligence Co., Ltd. in China genannt.

Der Standort des Unternehmens ist für internationale Datenschutzbewertungen relevant.

333. Prompts und Uploads

DeepSeek kann Texteingaben, Prompts, hochgeladene Dateien, Feedback und Chatverlauf verarbeiten.

Vertrauliche Inhalte sollten deshalb im Consumerdienst nur bewusst eingegeben werden.

334. Kontodaten

Bei Kontoerstellung können unter anderem E-Mail, Telefonnummer, Benutzername und Passwortdaten anfallen.

Lokale Modellnutzung benötigt kein DeepSeek-Konto.

335. Geräte- und Netzwerkdaten

Die Policy nennt unter anderem IP-Adresse, Geräteinformationen, Betriebssystem, Sprache und technische Logs.

Solche Metadaten können selbst personenbezogen sein.

336. Ungefährer Standort

DeepSeek kann anhand der IP-Adresse einen ungefähren Standort ableiten.

Dies dient unter anderem Sicherheits- und Missbrauchserkennung.

337. Cookies

Der Webdienst verwendet Cookies und ähnliche Technologien für Betrieb, Präferenzen und Sicherheit.

Browser- und App-Datenpfade unterscheiden sich.

338. Zahlungsdaten

Für bezahlte API-/Open-Platform-Dienste entstehen Bestell- und Transaktionsdaten.

Diese Daten sind vom kostenlosen Consumerchat getrennt.

339. Öffentliche Trainingsdaten

DeepSeek erklärt, öffentlich verfügbare Informationen aus dem Internet für Training und Bereitstellung von Diensten nutzen zu können.

Öffentlich zugänglich bedeutet nicht automatisch urheberrechtsfrei oder unproblematisch.

340. Serviceverbesserung

Die Privacy Policy nennt Entwicklung und Verbesserung von Modellen und Algorithmen als Verwendungszweck.

Wer sensible Informationen vermeiden will, sollte lokale oder speziell vertraglich geregelte Pfade bevorzugen.

341. Search an Drittanbieter

Die Policy nennt externe APIs wie Bing für Suchfunktionen und die Weitergabe des Inputs, soweit dies für Search notwendig ist.

Websuche kann damit zusätzliche Datenempfänger einführen.

342. Dienstleister

DeepSeek nutzt Dienstleister für Kommunikation, Analytics, Support und Sicherheit.

Diese Parteien können Daten im Auftrag von DeepSeek verarbeiten.

343. Speicherung in China

DeepSeek erklärt, gesammelte personenbezogene Daten auf sicheren Servern in der Volksrepublik China zu speichern.

Für Nutzer in Europa ist dies ein internationaler Datentransfer und ein wesentlicher Compliancepunkt.

344. Internationale Datenübermittlung

Die Policy verspricht erforderliche Schutzmaßnahmen nach anwendbarem Datenschutzrecht.

Ob die konkrete Übertragung für einen bestimmten europäischen Einsatz zulässig ist, muss separat bewertet werden.

345. Aufbewahrung

Daten werden laut Policy so lange aufbewahrt, wie sie für Dienst, Rechtspflichten, legitime Interessen oder Rechtsansprüche benötigt werden.

Es gibt keine pauschale Einheitsfrist für alle Datentypen.

346. Chatverlauf löschen

Nutzer können den Chatverlauf über Einstellungen verwalten und löschen.

Das Löschen des Verlaufs ist nicht automatisch identisch mit sofortiger Entfernung aus allen Backups oder rechtlich erforderlichen Speichern.

347. Account löschen

Die Policy sieht Accountlöschung vor; danach kann der Account nicht einfach reaktiviert werden.

Vor Löschung sollten benötigte Inhalte exportiert oder gesichert werden.

348. DeepSeek warnt selbst vor Ungenauigkeit

Die Privacy Policy weist ausdrücklich darauf hin, dass generierte Antworten faktisch falsch sein können.

Das ist eine wichtige Herstellerquelle gegen die Annahme, ein Reasoningmodell sei automatisch zuverlässig.

349. Kinder unter 14

DeepSeek erklärt den Dienst nicht für Kinder unter 14 Jahren bestimmt.

Für 14- bis unter 18-Jährige wird Zustimmung beziehungsweise gemeinsames Lesen mit Erziehungsberechtigten verlangt.

350. EEA-/UK-/Schweiz-Zusatzregeln

Die Policy enthält gesonderte Bestimmungen für europäische Regionen.

Diese sollen Rechte und Rechtsgrundlagen nach lokalem Datenschutzrecht abbilden.

351. Developer-/Open-Platform-Daten

Die Consumer-Privacy-Policy weist darauf hin, dass Endnutzerdaten in Anwendungen von API-Entwicklern nicht automatisch unter dieselben Regeln fallen.

Der Entwickler der Anwendung ist für seine eigene Datenschutzerklärung und Rechtsgrundlage verantwortlich.

352. Open Platform Terms 2026

Für API- und Entwicklerdienste gelten seit April 2026 zusätzliche Open-Platform-Bedingungen.

Enterprise-/Entwicklerbewertung darf nicht nur die Consumerterms lesen.

353. Lokales Modell und DeepSeek-Privacy-Policy

Wer offene Gewichte vollständig lokal betreibt, sendet die Inferenz nicht automatisch an DeepSeek.

Die Cloud-Policy ist dann nicht der Inferenzdatenpfad; verwendete Drittsoftware kann aber eigene Telemetrie besitzen.

354. Italien 2025

Die italienische Datenschutzaufsicht ordnete Ende Januar 2025 eine sofortige Einschränkung der Verarbeitung italienischer Nutzerdaten durch DeepSeek an.

Der Fall ist ein regulatorisches Ereignis des gehosteten Dienstes, nicht ein Verbot offener Modellgewichte.

355. App-Store-Situation in Italien

Im Zuge des Verfahrens verschwand die App aus den italienischen App-Stores.

Webzugang und lokale Open-Weight-Nutzung sind davon technisch getrennt.

356. Südkorea 2025

DeepSeek setzte den App-Service in Korea im Februar 2025 vorübergehend aus, um Datenschutzanforderungen nachzubessern.

Die koreanische PIPC untersuchte unter anderem Transparenz und internationale Datenübermittlung.

357. Koreanische Transparenzprobleme

Die PIPC kritisierte unter anderem unzureichende Angaben zu Löschung, Schutzmaßnahmen und Datenschutzverantwortlichen.

Der Fall zeigt, dass eine allgemeine globale Privacy Policy lokale Anforderungen nicht automatisch erfüllt.

358. Deutschland 2025

Die Berliner Datenschutzbeauftragte beantragte die Sperrung der DeepSeek-App in deutschen App-Stores wegen als rechtswidrig bewerteter Übermittlungen personenbezogener Daten nach China.

Das Verfahren betrifft den gehosteten Consumerdienst und die App, nicht selbstgehostete Checkpoints.

359. DSGVO-Bezug

Die Berliner Behörde argumentierte, dass die App deutschen Nutzern gezielt angeboten wurde und daher die DSGVO anwendbar ist.

Unternehmensstandort außerhalb der EU schließt EU-Datenschutzrecht nicht automatisch aus.

360. Australische Regierungsgeräte

Australien verbot DeepSeek-Produkte, -Apps und Webdienste 2025 auf Systemen und Geräten der Bundesregierung aus Schutzsicherheitsgründen.

Das ist eine Government-Security-Policy und kein allgemeines Verbraucherverbot.

361. Behördenverbot ≠ allgemeines Verbot

Regierungen können für dienstliche Systeme strengere Regeln als für private Verbraucher festlegen.

Solche Maßnahmen werden nicht als generelle Illegalität des Modells dargestellt.

362. Exponierte Datenbank 2025

Wiz Research fand im Januar 2025 eine öffentlich erreichbare DeepSeek-ClickHouse-Datenbank mit sensiblen Log- und Backenddaten.

Der Fund betraf Cloud-/Serviceinfrastruktur und nicht die kryptografische Sicherheit der Modellgewichte.

363. Chat- und Logdaten

Der öffentlich dokumentierte Vorfall umfasste laut Wiz unter anderem Chatverläufe, API-nahe Informationen und interne Logs.

Er ist ein wichtiges historisches Beispiel für Infrastruktur- statt Modellrisiko.

364. Service-Security

Ein starker Foundation-Modellalgorithmus schützt nicht automatisch vor Fehlkonfigurationen von Datenbanken, APIs oder Cloudsystemen.

AI-Security und klassische IT-Security müssen gemeinsam betrachtet werden.

365. Chinesische Inhaltsregulierung

Der gehostete DeepSeek-Dienst muss chinesische Inhalts- und Plattformregeln beachten.

Bei politisch sensiblen Themen können Antworten deshalb stärker eingeschränkt oder gerahmt sein.

366. Politische Antwortmuster

Unabhängige Tests berichteten bei sensiblen China-Themen über Ablehnungen oder regierungsnahe Formulierungen im gehosteten Dienst.

Einzeltests werden nicht als vollständige Beschreibung jedes Modells verallgemeinert.

367. Hosted Policy vs. Open Weights

Ein lokal betriebenes offenes Modell kann andere Antworten geben als chat.deepseek.com.

Systemprompt, Finetune, Moderation und Providerpolicy beeinflussen politische Inhalte zusätzlich.

368. „Zensur“ ist kein einzelner Modellparameter

Antwortbeschränkungen können aus Trainingsdaten, Alignment, Systemprompt, API-Gateway oder Produktmoderation stammen.

Für Tests muss die Schicht identifiziert werden.

369. Politische Benchmarks

Geopolitische Fragen eignen sich schlecht für simple Ja/Nein-Benchmarks.

Quellenvielfalt, Framing und Ablehnungsquote sollten getrennt bewertet werden.

370. Datenschutz und Inhaltsmoderation sind getrennt

China-Datenspeicherung ist eine Privacy-/Compliancefrage; politische Antwortgrenzen sind eine Content-/Governancefrage.

Beide dürfen nicht vermischt werden.

371. Prompt Injection

Search-, Browser- oder Agentensysteme können manipulierte externe Inhalte übernehmen.

V4/Harness-Agenten müssen fremde Daten von vertrauenswürdigen Systeminstruktionen trennen.

372. Tool Calls

Ein DeepSeek-Agent kann Dateien, Shell, Browser oder APIs bedienen.

Modellintelligenz ersetzt keine Zugriffssteuerung.

373. Shellzugriff

Harness-Plugins können je nach Konfiguration echte Shellrechte besitzen.

DeepSeek selbst weist bei dynamischen Cordis-Tools darauf hin, dass dies bash-ähnliches Vertrauen verlangt.

374. Repositoryzugriff

Code-Agenten können großflächige Änderungen vornehmen.

Git-Branching, Tests, Diff-Review und Secret Scanning bleiben Pflicht.

375. MCP-Risiko

Remote-MCP-Server können externe Daten und Aktionen bereitstellen.

Standardisiertes Protokoll ist kein Sicherheitsnachweis.

376. Visuelle Prompt Injection

V4-Flash-Vision-Exp kann Screenshots und Bilder lesen.

Auch Text in einem Bild kann manipulative Agentenanweisungen enthalten.

377. Dateiupload

PDFs, Bilder und Codearchive können sensible Daten oder bösartige Inhalte enthalten.

Upload und spätere Toolausführung werden getrennt behandelt.

378. API-Schlüssel

DeepSeek-API-Keys gehören in Secret Stores.

Sie dürfen weder in Frontendcode noch in normale Prompts oder öffentliche Repositories gelangen.

379. Logs

Reasoning, Toolcalls und Inputs können sensible Details enthalten.

Produktionslogs brauchen Redaction, Retention und Zugriffskontrolle.

380. Reasoning-Inhalte

Explizite Reasoningfelder können interne Arbeitsdetails oder aus Prompts abgeleitete sensible Informationen enthalten.

Sie sollten nicht automatisch an Endnutzer, Telemetrie oder öffentliche Logs weitergereicht werden.

381. Medizin

DeepSeek kann medizinische Information erklären, ist aber keine Diagnoseinstanz.

Besonders bei gehosteter Nutzung kommen Datenschutzrisiken sensibler Gesundheitsdaten hinzu.

382. Recht

DeepSeek kann Rechtsquellen und Texte zusammenfassen.

Jurisdiktion, Aktualität und professionelle Beratung werden separat geprüft.

383. Finanzen

Reasoningmodelle können Berechnungen und Analysen unterstützen.

Investitions- oder Kreditentscheidungen benötigen unabhängige Quellen und Fachprüfung.

384. Cybersecurity

DeepSeek-Modelle und Agenten zeigen starke Coding- und Cyberfähigkeiten.

Defensive Securitynutzung braucht enge Laborgrenzen und Berechtigungen.

385. Supply Chain

Modelle, Quantisierungen, vLLM/SGLang-Images, npm-Harnesspakete, Plugins und MCP bilden eine Lieferkette.

Jede Komponente braucht Herkunfts- und Versionsprüfung.

386. Remote Model Code

`trust_remote_code` kann Python-Code aus einem Modellrepository ausführen.

Diese Option sollte nur für verifizierte Quellen eingesetzt werden.

387. Community-Quantisierungen

Ein fremder Quant-Upload kann manipuliert oder falsch bezeichnet sein.

Hash, Uploader, Basisrevision und Dateiformat werden kontrolliert.

388. Least Privilege

Agenten erhalten nur die Tools und Ordner, die für die Aufgabe erforderlich sind.

Modelle dürfen Rechte nicht selbst dauerhaft erweitern.

389. Human Approval

Versand, Veröffentlichung, Zahlung, Löschung und Deployment brauchen explizite Freigabe.

Autonomie wird an Risikoklassen gekoppelt.

390. Sandbox

Codeausführung wird möglichst isoliert.

Eine Sandbox verhindert keine externen API- oder Dateischäden, wenn entsprechende Rechte freigegeben sind.

391. Rollback

Agentenänderungen werden versioniert und rückgängig machbar gehalten.

Backups und Git sind Teil der AI-Sicherheitsarchitektur.

392. Fail-safe

Bei Unsicherheit stoppt der Agent und fordert Bestätigung an.

Ein plausibel klingender Guess ist bei irreversiblen Aktionen kein akzeptabler Fallback.

393. Einfach ausprobieren

Der DeepSeek-Webdienst ist der einfachste Weg zu aktuellen gehosteten Modellen.

Keine vertraulichen Daten eingeben, wenn China-Speicherung oder Service-Training problematisch ist.

394. Schwierige Agenten-/Codingaufgabe

V4-Pro-0813 ist die aktuelle stärkere gehostete Klasse.

Für einfache Aufgaben ist Flash schneller und günstiger.

395. Allgemeine API- und Agentenaufgaben

V4-Flash-0731 ist das effizientere aktuelle Workhorse.

Es bietet 1M Kontext, Thinking und Tool Calls bei deutlich geringerer Rechenklasse als Pro.

396. Screenshot oder Bild verstehen

V4-Flash-Vision-Exp ist der aktuelle multimodale API-Pfad.

Der Experimentalstatus muss für Produktion akzeptiert werden.

397. Historische Reasoningforschung

R1 ist weiterhin besonders relevant für Forschung zu RL, GRPO und offenen Reasoningmodellen.

Für aktuelle Produktleistung ist V4 die neuere Generation.

398. Lokales Reasoning mit wenig Hardware

R1-Distill-Qwen 7B/14B oder Llama 8B sind praktische Einstiegspunkte.

Sie sind nicht gleichwertig mit vollständigem R1 oder V4.

399. Starkes lokales Reasoning

R1-Distill-Qwen-32B bietet einen guten Kompromiss aus Modellgröße und Reasoningstärke.

Quantisierung sollte auf den eigenen Aufgaben evaluiert werden.

400. Historische Codeforschung

DeepSeek Coder/Coder-V2 sind für Entwicklungsgeschichte und spezialisierte Infillingtests interessant.

Für aktuelle agentische Codingaufgaben ist V4 plus Harness stärker.

401. MoE/MLA-Forschung mit kleinerem Modell

V2-Lite ist geeignet, um DeepSeekMoE und MLA in handlicherer Form zu untersuchen.

Es ist kein aktuelles Frontiermodell.

402. Offenes visuelles Forschungsmodell

DeepSeek-VL/VL2 oder Janus sind sinnvoll für lokale multimodale Forschung.

Für aktuelle V4-Agentenvision ist Vision-Exp der passendere Cloudpfad.

403. Dokument-OCR lokal

DeepSeek-OCR/OCR2 eignet sich für visuelle Dokumentextraktion.

Bei Tabellen und komplexem Layout muss das Ergebnis kontrolliert werden.

404. Formale Mathematik

DeepSeek-Prover-V2 ist die spezialisierte Linie für Lean-/Proof-Aufgaben.

Allgemeiner Chat ist dafür methodisch schwächer.

405. Eigene Anwendung

Die offizielle DeepSeek API eignet sich für aktuelle V4-Modelle ohne eigene Hostinginfrastruktur.

Datenpfad und Open-Platform-Bedingungen werden bewusst akzeptiert.

406. Maximale Datenkontrolle

Self-Hosting ist sinnvoll, wenn Prompts und Dateien nicht an DeepSeek gesendet werden sollen.

Der Betreiber übernimmt dafür Hardware, Security und Updates.

407. Agentenexperimente

DeepSeek Harness eignet sich für Plugin-, Tool- und Agentenforschung.

Developer-Preview-Status und Breaking Changes machen es noch nicht zur ruhigen Langzeitplattform.

408. Hochleistungs-Serving

vLLM ist ein starker Standardpfad für offene DeepSeek-Modelle.

Für V4 müssen die korrekten Parser, Kernel und DSparkoptionen verwendet werden.

409. Agenten-/V4-Serving

SGLang bietet ebenfalls aktuelle V4- und DSpark-Unterstützung.

Performance wird auf der tatsächlichen Hardware gemessen.

410. Einfach lokal

Ollama ist bequem für kleine und mittlere R1-Distills.

Modelltag und Quantisierung werden genau geprüft.

411. CPU/Mac

GGUF/llama.cpp ist für kleinere DeepSeek-Derivate praktisch.

Communitykonvertierungen brauchen Herkunftsprüfung.

412. Sensible personenbezogene Daten

Vollständig lokales Self-Hosting ist meist die klarste DeepSeek-Option, wenn Cloudtransfer nach China vermieden werden soll.

Auch lokale Tools und Betriebssystemtelemetrie werden geprüft.

413. Unternehmensdaten

Vor offizieller DeepSeek-API-Nutzung werden Datenschutz, DPA/Vertrag, Exportkontrolle und interne Security bewertet.

Ein billiger Tokenpreis ersetzt keine Complianceprüfung.

414. Nutzung in Deutschland

Die regulatorische Kritik am Consumerdienst sollte bei personenbezogenen oder geschäftlichen Daten berücksichtigt werden.

Lokale Open-Weight-Nutzung ist technisch eine andere Kategorie.

415. Modellforschung

Technical Reports, GitHub und Hugging-Face-Checkpoints sind die besten Primärquellen.

Consumerchat-Screenshots allein reichen für Architekturgeschichte nicht.

416. Benchmarking

Exakte Revision, Reasoning Effort, Harness, Tools, Sampling und Hardware werden dokumentiert.

Nur der Modellname ist für reproduzierbare Benchmarks zu wenig.

417. Problemhilfe: API meldet Modell nicht gefunden

Mögliche Ursache: alter Alias oder falscher V4-Name.

Sinnvolle Prüfung: aktuelle Modell-/Preisseite prüfen.

418. Problemhilfe: `deepseek-chat` funktioniert nicht mehr

Mögliche Ursache: historischer Alias wurde 2026 abgekündigt.

Sinnvolle Prüfung: `deepseek-v4-flash` oder aktuellen Modellnamen verwenden.

419. Problemhilfe: `deepseek-reasoner` funktioniert nicht mehr

Mögliche Ursache: Reasoningalias wurde mit V4 abgekündigt.

Sinnvolle Prüfung: V4-Modell plus Thinking Mode konfigurieren.

420. Problemhilfe: V4-Pro verhält sich anders als im Frühjahr

Mögliche Ursache: Preview wurde durch V4-Pro-0813 GA ersetzt.

Sinnvolle Prüfung: konkrete Revision dokumentieren.

421. Problemhilfe: Flash verhält sich anders

Mögliche Ursache: 0731 wurde neu post-trainiert.

Sinnvolle Prüfung: Version 0731 festhalten.

422. Problemhilfe: V4-Pro versteht Bild nicht

Mögliche Ursache: nur Vision-Exp verarbeitet echten Bildinput.

Sinnvolle Prüfung: `deepseek-v4-flash-vision-exp` wählen.

423. Problemhilfe: Vision-Exp ist instabil

Mögliche Ursache: experimenteller Modellstatus.

Sinnvolle Prüfung: Produktionsfallback definieren.

424. Problemhilfe: File-ID wird abgelehnt

Mögliche Ursache: Datei nicht korrekt hochgeladen oder falsches Modell.

Sinnvolle Prüfung: Files API und Visionmodell prüfen.

425. Problemhilfe: Bild wird abgelehnt

Mögliche Ursache: Format oder Größenlimit verletzt.

Sinnvolle Prüfung: JPEG/PNG/GIF/WebP und Limit prüfen.

426. Problemhilfe: Responses API funktioniert nicht

Mögliche Ursache: Clientparameter oder Modellkompatibilität falsch.

Sinnvolle Prüfung: aktuelle Responses-Doku prüfen.

427. Problemhilfe: Anthropic-SDK-Aufruf scheitert

Mögliche Ursache: Base URL oder Parameter unterscheiden sich.

Sinnvolle Prüfung: DeepSeek-Anthropic-Beispiele verwenden.

428. Problemhilfe: Thinking lässt sich nicht abschalten

Mögliche Ursache: Client setzt Default oder Chattemplate falsch.

Sinnvolle Prüfung: Thinking-Parameter kontrollieren.

429. Problemhilfe: Thinking verbraucht sehr viele Tokens

Mögliche Ursache: Effort high/max oder schwierige Aufgabe.

Sinnvolle Prüfung: Effort senken und Outputlimit setzen.

430. Problemhilfe: Thinking ist zu kurz

Mögliche Ursache: Effort low oder kleines Budget.

Sinnvolle Prüfung: high/max für komplexe Aufgabe testen.

431. Problemhilfe: Reasoning und Antwort werden vermischt

Mögliche Ursache: Client kennt V4-Ausgabeformat nicht.

Sinnvolle Prüfung: aktuellen Parser/Encoding verwenden.

432. Problemhilfe: Toolargumente sind falsch

Mögliche Ursache: Schema oder Modellinterpretation fehlerhaft.

Sinnvolle Prüfung: Argumente validieren.

433. Problemhilfe: Agent ruft Tool in Schleife auf

Mögliche Ursache: Ziel unklar oder Toolfehler nicht verarbeitet.

Sinnvolle Prüfung: Stopregeln und Fehlersignal setzen.

434. Problemhilfe: JSON ist ungültig

Mögliche Ursache: Modell oder Streaming hat Format verletzt.

Sinnvolle Prüfung: Schema validieren und Retry nutzen.

435. Problemhilfe: FIM funktioniert im Thinking Mode nicht

Mögliche Ursache: V4 unterstützt FIM nur Non-Thinking.

Sinnvolle Prüfung: Thinking abschalten.

436. Problemhilfe: Prefix Completion verhält sich unerwartet

Mögliche Ursache: Beta-Funktion oder Präfix kollidiert mit Template.

Sinnvolle Prüfung: minimal reproduzieren.

437. Problemhilfe: Cache-Hit bleibt aus

Mögliche Ursache: Präfix hat sich verändert.

Sinnvolle Prüfung: identischen Tokenpräfix prüfen.

438. Problemhilfe: Cache wird mit Memory verwechselt

Mögliche Ursache: Caching ist Kosten-/Inferenztechnik.

Sinnvolle Prüfung: Datenschutz und Cache separat prüfen.

439. Problemhilfe: 429 / Rate Limit

Mögliche Ursache: Concurrency oder Kontingent überschritten.

Sinnvolle Prüfung: Backoff und Limits prüfen.

440. Problemhilfe: API teurer als erwartet

Mögliche Ursache: Peak-Zeit, Cache-Miss oder Pro gewählt.

Sinnvolle Prüfung: Abrechnungsdetail prüfen.

441. Problemhilfe: Peak/Off-Peak stimmt nicht

Mögliche Ursache: UTC-Zeitfenster falsch umgerechnet.

Sinnvolle Prüfung: aktuelle Pricing-Seite und UTC prüfen.

442. Problemhilfe: Antwort bricht ab

Mögliche Ursache: max output oder Clientlimit erreicht.

Sinnvolle Prüfung: Tokenlimit und Finish Reason prüfen.

443. Problemhilfe: 1M-Kontext scheitert

Mögliche Ursache: Requestgröße, KV-/Serverlimit oder Clientbeschränkung.

Sinnvolle Prüfung: reale Tokenzahl messen.

444. Problemhilfe: Detail im 1M-Kontext fehlt

Mögliche Ursache: Attention/Retrieval ist nicht perfekt.

Sinnvolle Prüfung: kritische Passage gezielt referenzieren.

445. Problemhilfe: Lokales Modell läuft aus Speicher

Mögliche Ursache: Gewichte + KV-Cache + Runtime zu groß.

Sinnvolle Prüfung: Quantisierung/Kontext/Offload anpassen.

446. Problemhilfe: Lokales Modell ist extrem langsam

Mögliche Ursache: CPU/Offload oder ungeeignete Quantisierung.

Sinnvolle Prüfung: GPU-Offload und Runtime prüfen.

447. Problemhilfe: Quantisiertes Modell denkt schlechter

Mögliche Ursache: zu aggressive Quantisierung.

Sinnvolle Prüfung: höhere Präzision gegenprüfen.

448. Problemhilfe: GGUF ist verdächtig

Mögliche Ursache: Communitydatei unbekannter Herkunft.

Sinnvolle Prüfung: Uploader/Hash/Basisrevision prüfen.

449. Problemhilfe: Modell folgt Instruktionen schlecht

Mögliche Ursache: falsches Chattemplate.

Sinnvolle Prüfung: offizielles Modelltemplate nutzen.

450. Problemhilfe: V4-Pro-0813 parst falsch

Mögliche Ursache: eigene Encoding-Spezifikation nicht berücksichtigt.

Sinnvolle Prüfung: offiziellen Encoding-Ordner nutzen.

451. Problemhilfe: Transformers fordert Remote Code

Mögliche Ursache: Architektur braucht Repositorycode.

Sinnvolle Prüfung: Quelle verifizieren und Umgebung isolieren.

452. Problemhilfe: vLLM startet V4 nicht

Mögliche Ursache: Version/Kernels/Parser zu alt.

Sinnvolle Prüfung: aktuelle V4-Rezepte prüfen.

453. Problemhilfe: SGLang startet V4 nicht

Mögliche Ursache: Backend oder DSpark-Konfiguration passt nicht.

Sinnvolle Prüfung: offiziellen Cookbookpfad prüfen.

454. Problemhilfe: DSpark bringt keinen Speedup

Mögliche Ursache: Acceptance Rate/Hardware/Batch ungünstig.

Sinnvolle Prüfung: Baseline und Speculation messen.

455. Problemhilfe: DSpark startet nicht

Mögliche Ursache: Runtime unterstützt Checkpointmodul nicht.

Sinnvolle Prüfung: vLLM/SGLang-Version prüfen.

456. Problemhilfe: DeepSeek Harness startet nicht

Mögliche Ursache: Node/pnpm oder Previewänderung.

Sinnvolle Prüfung: README und gepinnte Version prüfen.

457. Problemhilfe: Harness-Update bricht Plugin

Mögliche Ursache: Developer Preview ohne Kompatibilitätsgarantie.

Sinnvolle Prüfung: Version pinnen und Migration lesen.

458. Problemhilfe: Harness-Plugin validiert nicht

Mögliche Ursache: Schema/Provider inkompatibel.

Sinnvolle Prüfung: Toolschema minimalisieren und testen.

459. Problemhilfe: Harness verändert falsche Datei

Mögliche Ursache: Shell-/Filesystemrechte zu breit.

Sinnvolle Prüfung: Workspace begrenzen und Git nutzen.

460. Problemhilfe: Dynamisches Cordis-Tool ist riskant

Mögliche Ursache: Self-Referential Plugin hat echte Hostrechte.

Sinnvolle Prüfung: nur isoliert und bewusst aktivieren.

461. Problemhilfe: Eigene Agentenwerte sind viel schlechter

Mögliche Ursache: anderer Harness, Effort, Sampling oder Tools.

Sinnvolle Prüfung: Benchmarksetup reproduzieren.

462. Problemhilfe: Code-Agent erzeugt kaputten Patch

Mögliche Ursache: Repoverständnis oder Testabdeckung unzureichend.

Sinnvolle Prüfung: Diff/Tests/Review.

463. Problemhilfe: Agent liest API-Key

Mögliche Ursache: Secret liegt im Workspace.

Sinnvolle Prüfung: Key rotieren und Secretzugriff entfernen.

464. Problemhilfe: Web Search liefert falschen Fakt

Mögliche Ursache: Searchquelle veraltet oder schlecht.

Sinnvolle Prüfung: Primärquelle prüfen.

465. Problemhilfe: Search sendet sensible Anfrage weiter

Mögliche Ursache: externe Search-API wird verwendet.

Sinnvolle Prüfung: sensible Daten entfernen.

466. Problemhilfe: Lokales Modell antwortet anders als Website

Mögliche Ursache: Systemprompt/Moderation/Search fehlen.

Sinnvolle Prüfung: Umgebung dokumentieren.

467. Problemhilfe: Politische Antwort wird abgelehnt

Mögliche Ursache: Hosted Policy/Regulierung oder Alignment.

Sinnvolle Prüfung: lokal vs hosted vergleichen und Quellen nutzen.

468. Problemhilfe: Chinesisch/Englisch mischt sich

Mögliche Ursache: Modellrevision/Reasoning/Prompt.

Sinnvolle Prüfung: Sprache explizit setzen und Version prüfen.

469. Problemhilfe: R1 wiederholt sich

Mögliche Ursache: frühes Reasoningverhalten oder Sampling.

Sinnvolle Prüfung: Sampling/Distill/neuere Revision testen.

470. Problemhilfe: R1 671B passt nicht lokal

Mögliche Ursache: vollständiges Modell ist riesig.

Sinnvolle Prüfung: Distill oder Hosting verwenden.

471. Problemhilfe: R1-Distill wird als R1 erkannt

Mögliche Ursache: Frontend kürzt Namen.

Sinnvolle Prüfung: Basis/Parameterzahl prüfen.

472. Problemhilfe: Codecompletion ist schlecht

Mögliche Ursache: falsche Base/Instruct/FIM-Konfiguration.

Sinnvolle Prüfung: Coder-/Non-Thinking-FIMpfad prüfen.

473. Problemhilfe: OCR-Text ist falsch

Mögliche Ursache: Bildqualität/Layout/Kompression.

Sinnvolle Prüfung: Originalseite vergleichen.

474. Problemhilfe: Tabelle wird falsch rekonstruiert

Mögliche Ursache: Layoutmodell interpretiert Zellen falsch.

Sinnvolle Prüfung: Zellen gegen Bild prüfen.

475. Problemhilfe: Formal Proof kompiliert nicht

Mögliche Ursache: Lean-Version oder Beweisschritt fehlerhaft.

Sinnvolle Prüfung: Proof Assistant ausführen.

476. Problemhilfe: Cloudtransfer nach China ist problematisch

Mögliche Ursache: Consumerdienst speichert Daten in China.

Sinnvolle Prüfung: lokal hosten oder Compliancepfad prüfen.

477. Problemhilfe: Gelöschter Chat scheint noch relevant

Mögliche Ursache: andere Logs/Retention/Systeme.

Sinnvolle Prüfung: Policy und Accountdaten getrennt prüfen.

478. Problemhilfe: App ist regional nicht verfügbar

Mögliche Ursache: Datenschutz-/Store-/Regulierungsmaßnahme.

Sinnvolle Prüfung: lokale Rechtslage prüfen.

479. Problemhilfe: Italien-Zugang eingeschränkt

Mögliche Ursache: Garante-Maßnahme.

Sinnvolle Prüfung: offizielle regulatorische Hinweise prüfen.

480. Problemhilfe: Koreanische App fehlt

Mögliche Ursache: historische/aktuelle PIPC-Compliancephase.

Sinnvolle Prüfung: aktuellen Storestatus prüfen.

481. Problemhilfe: Deutsche App-Verfügbarkeit ändert sich

Mögliche Ursache: DSA-/Datenschutzverfahren und Storeentscheidung.

Sinnvolle Prüfung: aktuelle Store-/Behördenlage prüfen.

482. Problemhilfe: Sicherheitsvorfall wird mit Modellfehler verwechselt

Mögliche Ursache: Cloud-Datenbank war exponiert.

Sinnvolle Prüfung: Infrastruktur und Modell getrennt bewerten.

483. Problemhilfe: DeepSeek erfindet Fakt

Mögliche Ursache: Modellwissen/Reasoning ohne verlässliche Quelle.

Sinnvolle Prüfung: Primärquelle oder Search prüfen.

484. Problemhilfe: Benchmarkwert nicht reproduzierbar

Mögliche Ursache: Prompt, Effort, Harness, Tools oder Revision abweichend.

Sinnvolle Prüfung: vollständiges Setup erfassen.

485. Problemhilfe: MIT-Lizenz wird falsch übertragen

Mögliche Ursache: nicht jede ältere Spezialserie nutzt identische Lizenz.

Sinnvolle Prüfung: LICENSE pro Repo lesen.

486. Problemhilfe: Kommerzielle Nutzung unklar

Mögliche Ursache: Modell-/Code-Lizenz differiert.

Sinnvolle Prüfung: konkrete Lizenzdatei prüfen.

487. Problemhilfe: Medizinische Antwort wirkt sicher

Mögliche Ursache: Reasoning erzeugt plausible Erklärung.

Sinnvolle Prüfung: Leitlinie/Fachperson prüfen.

488. Problemhilfe: Rechtsantwort klingt eindeutig

Mögliche Ursache: Jurisdiktion/Stand fehlt.

Sinnvolle Prüfung: Primärrecht und Fachberatung.

489. Problemhilfe: Finanzanalyse wirkt präzise

Mögliche Ursache: Zahlen können veraltet/erfunden sein.

Sinnvolle Prüfung: Marktdatenquelle prüfen.

490. Problemhilfe: Screenshot bringt Agenten vom Ziel ab

Mögliche Ursache: Text im Bild enthält Prompt Injection.

Sinnvolle Prüfung: Bildinhalt als untrusted behandeln.

491. Problemhilfe: MCP-Tool verhält sich unerwartet

Mögliche Ursache: Server bösartig/fehlerhaft.

Sinnvolle Prüfung: Scope reduzieren und Server auditieren.

492. Problemhilfe: Logs enthalten Reasoning/Secrets

Mögliche Ursache: zu breite Observability.

Sinnvolle Prüfung: Redaction und Retention.

493. Mythos: DeepSeek ist nur R1

R1 war der internationale Durchbruch, aber die technische Linie beginnt früher mit Coder, LLM, MoE, Math und V2.

2026 ist V4 die aktuelle Hauptgeneration.

494. Mythos: R1 ist noch das neueste DeepSeek-Modell

R1 stammt vom Januar 2025.

Seitdem folgten R1-0528, V3.1, V3.2 und 2026 V4-Pro/Flash.

495. Mythos: DeepSeek-V4 ist ein einzelner Checkpoint

V4 umfasst Flash, Pro und inzwischen einen experimentellen Visionpfad.

Zusätzlich existieren datierte Revisionen wie 0731 und 0813.

496. Mythos: V4-Flash ist nur quantisiertes Pro

Flash ist eine eigenständig trainierte kleinere V4-Klasse.

Beide teilen Architekturideen, unterscheiden sich aber in Modellkapazität und Post-Training.

497. Mythos: Gesamtparameter sind gleich Rechenaufwand pro Token

MoE aktiviert nur einen Teil der Experten.

Gesamtparameter bestimmen vor allem Kapazität und Speicher, aktive Parameter näherungsweise die FFN-Rechenlast.

498. Mythos: 1M Kontext ist dauerhaftes Gedächtnis

Das Kontextfenster ist temporärer Arbeitsbereich einer Inferenz.

Persönliches Memory oder Datenbankpersistenz sind andere Systeme.

499. Mythos: Ein Modell mit 1M Kontext findet jedes Detail perfekt

Langer Kontext erhöht Kapazität, aber nicht garantiert perfekte Aufmerksamkeit.

Strukturierung und Retrieval bleiben wichtig.

500. Mythos: Sichtbares Reasoning macht die Antwort wahr

Reasoning kann Fehler schrittweise rationalisieren.

Ergebnis und Quellen müssen unabhängig geprüft werden.

501. Mythos: Max Thinking ist immer besser

Mehr Reasoning erhöht Kosten und Latenz und kann überdenken.

Effort wird passend zur Aufgabe gewählt.

502. Mythos: R1-Zero ist grundsätzlich besser, weil es „reines RL“ ist

R1-Zero zeigte interessante emergente Strategien, hatte aber Wiederholung, Sprachmischung und Lesbarkeitsprobleme.

R1 ergänzte bewusst Cold-Start-Daten.

503. Mythos: R1-Distill-32B ist einfach komprimiertes R1

Distillmodelle basieren auf Qwen- oder Llama-Architekturen und wurden mit R1-Ausgaben feinabgestimmt.

Sie sind eigenständige Checkpoints.

504. Mythos: Jede DeepSeek-Datei hat dieselbe offene Lizenz

Viele aktuelle Modelle sind MIT-lizenziert, ältere Spezialfamilien können Modelllizenzen besitzen.

LICENSE und Model Card der konkreten Version sind maßgeblich.

505. Mythos: Lokales DeepSeek sendet automatisch Daten nach China

Ein vollständig lokal betriebener Open-Weight-Checkpoint sendet Inferenz nicht automatisch an DeepSeek.

Die verwendete Runtime oder externe Tools können aber eigene Netzwerkpfade besitzen.

506. Mythos: Der DeepSeek-Webchat ist datenschutzrechtlich dasselbe wie ein lokales Modell

Der Consumerdienst verarbeitet Account-, Prompt-, Geräte- und Serviceinformationen in DeepSeeks Infrastruktur.

Self-Hosting ist eine andere Datenarchitektur.

507. Mythos: Jede lokale DeepSeek-Quantisierung antwortet politisch exakt wie die Website

Hosted Moderation, Systemprompt und Modellcheckpoint können sich unterscheiden.

Politische Antwortmuster müssen pro Deployment untersucht werden.

508. Mythos: DeepSeek ist weltweit verboten

Einige Behörden und Länder ergriffen spezifische App-, Regierungsgeräte- oder Datenschutzmaßnahmen.

Das ist kein einheitliches globales Verbot aller DeepSeek-Modelle.

509. Mythos: Italien verbot DeepSeek-Gewichte

Die italienische Maßnahme richtete sich gegen Verarbeitung personenbezogener Daten im Dienst.

Open-Weight-Modelle als Dateien sind technisch eine andere Kategorie.

510. Mythos: Der Wiz-Vorfall beweist eine Sicherheitslücke im Transformer

Der Vorfall betraf eine offen erreichbare Datenbank und Cloudkonfiguration.

Modellarchitektur und Serviceinfrastruktur sind getrennte Sicherheitsebenen.

511. Mythos: MIT-Lizenz bedeutet sicher oder vertrauenswürdig

Eine Lizenz regelt Nutzungsrechte.

Sie sagt nichts über Modellbias, Security oder Herkunft eines Communityquants.

512. Mythos: OpenAI-kompatible API bedeutet identisches Verhalten

Requestformen können ähnlich sein.

Reasoningfelder, Tool Calls, Rollen, Tokenisierung und Limits unterscheiden sich.

513. Mythos: Anthropic-kompatibler Endpoint macht DeepSeek zu Claude

Die Kompatibilität betrifft Client-/Requestformate.

Das Modell bleibt DeepSeek.

514. Mythos: DeepSeek Harness ist ein neues LLM

Harness ist eine Agentenruntime.

Es orchestriert Modelle, Plugins und Tools.

515. Mythos: Harness-Plugins sind automatisch sandboxed

Einige Plugins können echte Shell- oder Dateirechte erhalten.

DeepSeek dokumentiert dynamische Cordis-Tools ausdrücklich nicht als Security Boundary.

516. Mythos: DSpark ist ein zweites Chatmodell

DSpark ist ein speculative-decoding-Modul beziehungsweise Draftsystem.

Es soll Decoding beschleunigen.

517. Mythos: Speculative decoding verbessert automatisch die Antwortqualität

Die Technik zielt auf Geschwindigkeit bei gleicher Zielverteilung.

Qualitätsänderungen deuten eher auf Implementierungs-/Numerikprobleme hin.

518. Mythos: Ein 4-Bit-Quant ist kostenlos leistungsfähig

Quantisierung spart Speicher, kann aber Qualität und Toolzuverlässigkeit verändern.

Außerdem bleiben Hardware-, Strom- und Betriebsaufwand.

519. Mythos: Weil V4 FP4 nutzt, passt Pro auf einen normalen PC

V4-Pro besitzt trotzdem enorme Gesamtgewichte.

Niedrige Präzision reduziert, aber beseitigt den Datacenter-Hardwarebedarf nicht.

520. Mythos: Seit August 2026 können alle V4-Modelle Bilder sehen

Der aktuelle multimodale API-Pfad ist V4-Flash-Vision-Exp.

V4-Pro und normales Flash bleiben in der dokumentierten API textzentriert.

521. Mythos: Vision-Exp ist ein Bildgenerator

Der August-2026-Pfad ist für Bildverständnis und multimodale Agenten.

Bildgenerierung gehört zu Janus-/anderen multimodalen Forschungszweigen.

522. Mythos: DeepSeek-OCR ist einfach V4 mit OCR-Prompt

OCR/OCR2 sind spezialisierte visuelle Modelle.

Sie besitzen andere Architektur, Größe und Zielsetzung.

523. Mythos: Prover ist nur DeepSeek-Chat mit Mathematikprompt

Prover ist auf formale Theorem-Proving-Aufgaben spezialisiert.

Formale Verifikation unterscheidet sich fundamental von natürlicher Sprache.

524. Mythos: GRPO wurde erst für R1 erfunden

GRPO wurde bereits in DeepSeekMath vorgestellt.

R1 machte die Methode anschließend weltbekannt.

525. Mythos: Die oft zitierte V3-Trainingskostenzahl sind alle Kosten von DeepSeek

Die veröffentlichte GPU-Stundenangabe bezieht sich auf den finalen Trainingslauf.

Forschung, Personal, Daten, Fehlversuche und Infrastruktur sind damit nicht vollständig erfasst.

526. Mythos: Ein Benchmark beweist allgemeine Überlegenheit

Scores hängen von Prompt, Harness, Tools, Revision und Bewertung ab.

Produktive Modellwahl braucht eigene Tasks.

527. Mythos: Kostenloser Webchat bedeutet kostenlose API

Consumerchat und API-Billing sind getrennt.

API nutzt tokenbasierte Preise und seit 2026 Peak/Off-Peak-Stufen.

528. Mythos: Context Cache ist persönliches Memory

Caching reduziert Rechen-/Abrechnungskosten bei identischen Präfixen.

Es erzeugt kein Nutzerprofil.

529. DeepSeek Coder archivieren

Coder v1 dokumentiert die codingzentrierte Ausgangslinie mit 2T Trainingsdaten, 16K Kontext und Infilling.

Base/Instruct, Modellgröße und Lizenz werden mitgesichert.

530. DeepSeek LLM

7B/67B zeigen die frühe dense Allgemeinmodellphase.

Diese Generation darf nicht rückwirkend als MoE beschrieben werden.

531. DeepSeekMoE

Fine-Grained Expert Segmentation und Shared Experts sind Grundlagen der späteren Architektur.

Paper, 16B-Checkpoint und Config sind wertvolle Primärquellen.

532. DeepSeekMath

GRPO und die dokumentierte mathematische Webdatensammlung machen DeepSeekMath historisch besonders wichtig.

Der RL-Checkpoint wird zusammen mit Paper und Trainingsdetails archiviert.

533. DeepSeek-VL

Die 2024er 1.3B-/7B-Visionfamilie dokumentiert DeepSeeks frühen multimodalen Pfad.

Sie wird nicht mit Janus oder V4 Vision zusammengelegt.

534. DeepSeek-V2

V2 ist der MLA- und große-MoE-Wendepunkt.

236B/21B, 8.1T Tokens und KV-Cache-Architektur gehören zum Kernbestand.

535. Coder-V2

6T Continued Pretraining, 338 Sprachen und 128K Kontext markieren die zweite Codinggeneration.

Lite und Full werden separat gesichert.

536. V2.5

Die Verschmelzung von Chat und Coder ist historisch wichtig.

API-Aliaszustände gehören zum Zeitstempel.

537. DeepSeek-V3

671B/37B, 14.8T Tokens, FP8, auxiliary-loss-free load balancing und MTP sind zentrale Primärmerkmale.

Technical Report und Gewichte werden gemeinsam archiviert.

538. R1-Zero

R1-Zero sollte als eigenständiger RL-Versuch erhalten bleiben und nicht durch R1 überschrieben werden.

Wiederholung und Sprachmischung sind gerade historisch relevant.

539. R1

R1 markiert den offenen Reasoningdurchbruch vom Januar 2025.

MIT-Lizenz, Reasoningformat und 128K-Kontext gehören zum Stand.

540. R1-Distills

Alle sechs Distillgrößen werden mit Basismodellbezug dokumentiert.

Qwen-/Llama-Basis ist Teil der Modellidentität.

541. R1-0528

Das Mai-Update zeigt die schnelle Verbesserung vor V3.1.

API-Alias und reale Modellrevision werden getrennt notiert.

542. V3.1

Hybrid Thinking und Agentenfokus markieren den Übergang vom spezialisierten Reasoner zum einheitlichen Agentenmodell.

Terminus bleibt eigener Stabilitätsstand.

543. V3.2

DeepSeek Sparse Attention und Agentic AI führen direkt zu V4.

Speciale wird als temporärer High-Compute-Endpunkt separat archiviert.

544. Prover

Formale Mathematik bleibt ein Spezialzweig und sollte nicht in der allgemeinen Chatlinie verschwinden.

Benchmarks und Lean-Versionen gehören zum Reproduktionsstand.

545. Janus/JanusFlow/Janus-Pro

Diese Reihe dokumentiert multimodales Verständnis plus Bildgenerierung.

Sie ist architektonisch und produktseitig getrennt von der Haupt-Chat-API.

546. OCR/OCR2

Optische Kontextkompression ist eine eigenständige DeepSeek-Forschungsrichtung.

Beispieldokumente und erzeugtes Markdown sollten zusammen archiviert werden.

547. V4 vom 24. April 2026

Der ursprüngliche V4-Report dokumentiert Flash/Pro, 1M Kontext, FP4/FP8, mHC, Muon und neue Attentioneffizienz.

Preview und spätere GA-Revisionen werden nicht vermischt.

548. V4-Flash-0731

Der 31. Juli ist der offizielle agentisch nachtrainierte Flash-Stand.

DSpark, Responses API und Benchmarksetup gehören dazu.

549. V4-Pro-0813

Der 13. August ist am Stichtag die GA-Pro-Referenz.

Konkretes Hugging-Face-Repository, API-Modellname und Expert-Mode-Produktoberfläche werden getrennt dokumentiert.

550. V4-Flash-Vision-Exp

Der 21. August 2026 ist der aktuelle Multimodalitätsendpunkt.

Experimentalstatus und Files-API-Support sind Teil des Archivstands.

551. DeepSeek Harness

Die Developer-Preview-Runtime wird mit Commit/Version dokumentiert, weil Breaking Changes ausdrücklich erwartet werden.

Plugins und Cordis-Versionen gehören zum Reproduktionsstand.

552. DeepSpec/DSpark

Speculative-Decoding-Forschung erklärt einen Teil des aktuellen V4-Servingstacks.

Draftmodelle, Zielmodelle und Acceptance-Metriken werden getrennt gesichert.

553. API-Changelog

DeepSeeks Changelog ist eine außergewöhnlich wertvolle Quelle für bewegliche Aliasnamen und Modellwechsel.

Snapshots verhindern, dass später ein alter `deepseek-chat`-Name falsch interpretiert wird.

554. Preise

API-Preise sind historisch interessant, aber besonders volatil.

Peak/Off-Peak, Cache-Hit/Miss und Datum werden gemeinsam angegeben.

555. Privacy Policy

Die Privacy Policy vom 10. Februar 2026 dokumentiert Datenarten, China-Speicherung und europäische Zusatzregeln.

Spätere Fassungen werden als neue Dokumentversion archiviert.

556. Regulatorische Ereignisse

Italien, Korea, Deutschland und australische Behördenmaßnahmen werden mit Datum und Behördentyp dokumentiert.

Sie werden nicht als pauschales Modellverbot verallgemeinert.

557. Wiz-Datenbankvorfall

Der Januar-2025-Vorfall wird als Service-/Cloud-Securityereignis archiviert.

Er darf nicht mit Gewichts- oder Transformer-Sicherheit verwechselt werden.

558. Vergleich mit ChatGPT

Die ChatGPT-Chronik zeigt einen stärker zentralisierten Produkt-/Agentenpfad.

DeepSeek unterscheidet sich besonders durch offene Gewichte, aggressive Architektureffizienz und niedrigpreisige API.

559. Vergleich mit Claude

Die Claude-Chronik betont Constitutional AI, MCP und professionelle Agentenprodukte.

DeepSeek veröffentlicht deutlich mehr Frontiergewichte offen und entwickelt zugleich ein eigenes Harness.

560. Vergleich mit Gemini

Die Gemini-Chronik dokumentiert Googles breit integriertes Consumer-/Cloudökosystem.

DeepSeek ist produktseitig schmaler, architektur- und Open-Weight-seitig dagegen außergewöhnlich offen.

561. Vergleich mit Meta/Llama

Die Meta-AI-/Llama-/Muse-Chronik ist die stärkste parallele Open-Weight-Linie.

DeepSeek setzt stärker auf MoE-/Attentioneffizienz und offene Reasoning-/Codingforschung.

562. Vergleich mit Perplexity

Die Perplexity-Chronik ist Search- und Orchestrierungszentriert und kann DeepSeek als Modellprovider einsetzen.

DeepSeek selbst entwickelt primär Modelle, API und Agentenharness.

563. Vergleich mit Grok

Die Grok-Chronik verbindet eigene Modelle eng mit X und Echtzeitprodukten.

DeepSeek besitzt kein vergleichbares Social-Netzwerk und fokussiert Forschung, API und offene Gewichte.

564. Vergleich mit Copilot

Die Microsoft-Copilot-Chronik zeigt Integration in Windows und Microsoft 365.

DeepSeek ist eher Modell-/Infrastrukturprovider als Arbeitsplatzsuite.

565. Zur KI-Werkzeugübersicht

Die Seite KI-Werkzeuge bleibt die übergreifende Methoden- und Sicherheitsseite.

Diese Chronik vertieft ausschließlich DeepSeek.

566. Wohin DeepSeek 2026 zeigt

V4, Vision-Exp, DSpark und Harness zeigen eine klare Richtung: lange Kontexte, multimodale Wahrnehmung, effiziente Inferenz und agentische Toolnutzung.

Offene Gewichte bleiben parallel ein strategischer Bestandteil.

567. Fazit: DeepSeek ist vor allem eine Architektur- und Open-Reasoning-Geschichte

Von Coder und DeepSeekMoE über MLA/V2, GRPO/Math, V3 und R1 bis V4 zieht sich eine erstaunlich konsistente Linie effizienter offener Forschung.

Der gehostete Dienst ist nur eine Ebene davon; für die Technikgeschichte sind Papers, Gewichte, API-Changelog und Agentenruntime mindestens ebenso wichtig.

Weiterführende interne Themen

Die übergreifende Methoden- und Sicherheitsseite bleibt KI-Werkzeuge. Die parallelen großen Chroniken dokumentieren OpenAI ChatGPT, Anthropic Claude, Google Gemini, xAI / SpaceXAI Grok, Meta AI / Llama / Muse, Perplexity AI und Microsoft Copilot.