DSpark: Beschleunigung der LLM-Inferenz mit Speculative Decoding [pdf]

 (github.com/deepseek-ai)
1 Punkte von GN⁺ 6 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • DSpark: ein Framework für Speculative Decoding, das semi-autoregressive Generierung und Confidence Scheduling kombiniert
  • Ein Parallel Drafter schlägt in einem einzigen Forward Pass lange Token-Blöcke vor, leidet jedoch wegen fehlender Abhängigkeiten zwischen Tokens an einem starken Acceptance Decay im hinteren Teil; DSpark adressiert dies gleichzeitig mit einer semi-autoregressiven Struktur und lastbewusster Verifikation
  • Kombiniert ein schwergewichtiges paralleles Backbone mit einem leichtgewichtigen sequenziellen Modul, um Abhängigkeiten innerhalb des Blocks einzubringen, die Draft-Geschwindigkeit zu erhalten und zugleich Suffix Decay abzuschwächen
  • Ein Confidence Head schätzt die Überlebenswahrscheinlichkeit des Präfixes je Position, und ein hardwarebewusster Scheduler passt die Verifikationslänge pro Anfrage dynamisch an die Durchsatzkurve der Engine an
  • In Offline-Benchmarks verbessert DSpark die Accepted Length gegenüber der autoregressiven Baseline (Eagle3) und der parallelen Baseline (DFlash) konsistent und begrenzt bei der Deployment-Nutzung von DeepSeek-V4 in realen Diensten verschwendete Verifikation
  • Gegenüber der bestehenden Production-Baseline MTP-1 beschleunigt DSpark bei gleichem Durchsatz die Generierung pro Nutzer um 60–85%, erschließt Leistungsbereiche, die unter strengen Interaktionsanforderungen zuvor nicht erreichbar waren, und erweitert die Pareto Frontier

Problemdefinition — zwei Engpässe paralleler Drafter

  • LLMs generieren Tokens autoregressiv; für jedes Token ist ein Forward Pass erforderlich, der auf alle vorherigen Tokens konditioniert ist. Dadurch wächst die Inferenzlatenz proportional zur Ausgabelänge, während geringe GPU-Auslastung und hohe Wartezeiten zu zentralen Engpässen im Production Serving werden
  • Speculative Decoding lässt ein leichtgewichtiges Draft-Modell Kandidatenblöcke vorschlagen und ein Target-Modell diese in einem einzigen Forward Pass verifizieren; per Rejection Sampling wird das längste Präfix akzeptiert, das der Target-Verteilung entspricht, wodurch Beschleunigung ohne Qualitätsverlust möglich ist

  • Grenzen autoregressiver Drafter

    • Sie konditionieren jede Position auf vorherige Tokens und besitzen damit starke Modellierungsfähigkeit, doch die Drafting-Kosten wachsen linear mit der Blockgröße (𝑇draft ∝ 𝛾), was sie auf kleine Blöcke und flache Architekturen beschränkt

  • Grenzen paralleler Drafter

    • Sie generieren alle Positionen auf einmal, sodass die Draft-Latenz nahezu unabhängig von der Blockgröße ist und große Blöcke (z. B. 𝛾=16) möglich sind
    • Da jede Position unabhängig vorhergesagt wird, können Abhängigkeiten zwischen Tokens nicht modelliert werden; dies verursacht Multi-Modal Collision und einen starken Einbruch der Akzeptanzrate im hinteren Teil
    • Wenn lange Blöcke unterschiedslos vollständig verifiziert werden, sinkt der Durchsatz; insbesondere in Umgebungen mit hoher Nebenläufigkeit belegen Tokens mit hohem Ablehnungsrisiko Batch-Kapazität
    • Die ideale Verifikationslänge schwankt entlang zweier Achsen: datenseitig (strukturierte Anfragen wie Code haben eine hohe Akzeptanzrate, offene Chats eine niedrige) und systemseitig (bei geringer Last ist zusätzliche Verifikation fast kostenlos, bei hoher Last verdrängt sie die Kapazität anderer aktiver Anfragen)

Architektur — zwei komplementäre Komponenten

  • Die Latenz pro Token ist 𝐿 = (𝑇draft + 𝑇verify)/𝜏; Beschleunigung lässt sich auf drei Hebel zurückführen: 𝑇draft senken, 𝜏 erhöhen und die effektive 𝑇verify reduzieren

  • Decoding-Zyklus: Aus dem Prompt ABC erzeugt das Target-Modell das nächste Token D (als Anker) → paralleles Backbone und sequenzieller Head erzeugen den Draft EFGH sowie Confidence-Scores c1–c4 → der Scheduler behält das Präfix EFG und entfernt das Token H mit niedriger Confidence → das Target-Modell verifiziert parallel, akzeptiert E·F und erzeugt bei Ablehnung von G ein Korrekturtoken G*

  • Semi-autoregressive Generierung (Semi-Autoregressive Generation)

    • Ein paralleler Drafter erzeugt bei mehreren möglichen Fortsetzungen wie „of course“/„no problem“ inkonsistente Kombinationen wie „of problem“, weil jede Position über alle möglichen vorherigen Tokens marginalisiert, statt auf die tatsächlich gesampelten vorherigen Tokens konditioniert zu sein
    • Parallele Phase (Parallel stage): Das parallele Backbone (DFlash wird verwendet) führt einen einzigen Forward Pass über den gesamten Block aus, erzeugt Hidden States und Basis-Logits, behandelt den Anker selbst als erste Vorhersageposition, produziert aus 𝛾 Eingaben 𝛾 Logits und reduziert damit Draft-Rechenaufwand
    • Sequenzielle Phase (Sequential stage): Zu den Basis-Logits wird ein präfixabhängiger Übergangs-Bias 𝐵𝑘 addiert, sodass jede Position auf vorherige gesampelte Tokens im Block konditioniert ist; dies induziert über autoregressive Faktorisierung eine kausale Blockverteilung. Da die Verarbeitung sequenziell ist, muss sie deutlich leichtgewichtiger als die parallele Phase sein (𝑇sequential ≪ 𝑇parallel)
      • Markov Head: Vereinfacht auf eine Übergangsmodellierung erster Ordnung, die nur vom unmittelbar vorherigen Token abhängt; approximiert die vollständige 𝑉×𝑉-Matrix per Low-Rank-Faktorisierung 𝐵 = 𝑊1𝑊2 (Standard 𝑟=256), minimiert Speicher und Rechenaufwand pro Schritt und reduziert Cross-Mode-Kollisionen, indem nach Sampling von „of“ „course“ verstärkt und „problem“ unterdrückt wird
      • RNN Head: Akkumuliert über einen rekurrenten Zustand 𝑠𝑘 die gesamte Präfixhistorie innerhalb des Blocks und ermöglicht per Gate-Update Zugriff auf Informationen vor dem unmittelbar vorherigen Token, ist jedoch komplexer zu implementieren und hat ungünstigere Deployment-Eigenschaften

  • Verifikation mit Confidence Scheduling (Confidence-Scheduled Verification)

    • Die Draft-Akzeptanzrate variiert je nach Domäne (hoch bei Code, niedrig bei offenem Chat), und die Kosten zusätzlicher Token-Verifikation hängen von der Engine-Last ab; nötig ist daher ein integrierter Mechanismus, der Target-Rechenaufwand nur zu Tokens mit positivem Erwartungsnutzen routet
    • Confidence Head: Gibt für jede Position 𝑘 eine skalare Schätzung 𝑐𝑘 ∈ (0,1) aus und modelliert die bedingte Wahrscheinlichkeit, dass das Token an Position 𝑘 die Verifikation besteht, unter der Bedingung, dass alle vorherigen Tokens akzeptiert wurden; implementiert als leichtgewichtige lineare Projektion + Sigmoid
      • Überwachtes Training mit der analytischen schrittweisen Akzeptanzrate 𝑐*𝑘 = 1 − ½‖𝑝𝑑𝑘 − 𝑝𝑡𝑘‖1 (Total-Variation-Distanz zwischen Draft- und Target-Verteilung)
    • Nachträgliche Kalibrierung — Sequential Temperature Scaling (STS): Hardwarebewusstes Scheduling benötigt absolute Werte kumulativer Akzeptanzwahrscheinlichkeiten, doch neuronale Confidence ist tendenziell overconfident; da jedes 𝑐𝑖 eine bedingte Wahrscheinlichkeit ist, erfolgt die Faktorisierung über das kumulative Produkt des Präfixes. Auf einem Held-out-Validierungsset wird von links nach rechts eine 1D Grid Search zur Minimierung der ECE durchgeführt; als ordnungserhaltende Transformation bleiben Token-Rankings erhalten
    • Hardwarebewusster Präfix-Scheduler (Hardware-Aware Prefix Scheduler): Formuliert die Wahl der Verifikationslänge als Problem zur Maximierung des globalen Durchsatzes; für 𝑅 aktive Anfragen wird SPS(𝐵) genutzt (eine beim Engine-Start einmal profilierte Kostentabelle), maximiert wird 𝛩 = 𝜏·SPS(𝐵)
      • Da die Überlebenswahrscheinlichkeit 𝑎𝑟,𝑗 in 𝑗 monoton nicht zunimmt, wahrt globale Sortierung mit greedy Auswahl auf natürliche Weise die Präfixabhängigkeit innerhalb des Blocks; schrittweises Admit per 𝑂(1)-Kostentabellen-Lookup
      • Lossless Speculative Decoding verlangt die Eigenschaft non-anticipating; Markov-Features hängen von vorherigen gesampelten Tokens ab, sodass eine nachträgliche globale Suche Informationen über 𝑥𝑟,𝑘 leaken und Selektionsbias verursachen würde
      • Ein Early-Stopping-Mechanismus stoppt sofort, wenn der Durchsatz sinkt, und erzwingt Kausalität, indem Admit-Entscheidungen nur vom bis zu diesem Schritt verarbeiteten Präfix abhängen; ein globales Maximum ist nur garantiert, wenn das Ziel 𝛩 unimodal ist

Training

  • Aus Target-Sequenzen werden zufällig mehrere Ankerpositionen gesampelt, um 𝛾-Token-Blöcke als Trainingsdaten zu bilden
  • Das Target-Modell bleibt während des gesamten Prozesses frozen; das Draft-Modell teilt Embedding-Schicht und LM Head und hält diese ebenfalls fest, aktualisiert werden nur Backbone-Drafter, sequenzieller Block und Confidence Head
  • Das Trainingsziel ist eine gewichtete Summe aus drei Termen: Cross-Entropy-Loss Lce, Distribution-Matching-Loss Ltv und Confidence-Loss Lconf
    • Alle Terme werden mit Positionsgewichten 𝑤𝑘 = exp(−(𝑘−1)/𝛾) gewichtet, um frühe Positionen zu betonen, die bei präfixbasierter Verifikation stärker zur erwarteten Accepted Length beitragen
    • Ltv bestraft die Total-Variation-Distanz; da die schrittweise Akzeptanzwahrscheinlichkeit 1 − ½‖𝑝𝑑 − 𝑝𝑡‖1 entspricht, maximiert die Minimierung von Ltv direkt die erwartete Akzeptanzrate
    • Standardgewichte: 𝛼ce = 0.1, 𝛼tv = 0.9, 𝛼conf = 1.0

Experimente — Offline-Benchmarks

  • Setup

    • Target-Modelle: Qwen3-{4B, 8B, 14B}, Gemma4-12B / Vergleichs-Drafter: SOTA-Parallel-Drafter DFlash, autoregressiver Drafter Eagle3
    • Vollständiges Retraining mit identischem Framework und identischen Daten; der TTT-Horizon (7) von Eagle3 wird auf die Blockgröße (7) von DFlash und DSpark ausgerichtet, Anzahl der Draft-Schichten: Eagle3 1, DSpark und DFlash 5
    • Trainingsdaten: Open-PerfectBlend mit 1,3 Mio. Samples (Chat 17,6%, Math 39,4%, Code 38,9%, Instruction-Following 4,1%); nur Prompts werden verwendet, Antworten werden von jedem Target-Modell neu generiert; Training über 10 Epochs
    • Evaluationsdomänen: Mathematik (GSM8K, MATH500, AIME25), Code (MBPP, HumanEval, LiveCodeBench), Alltags-Chat (MT-Bench, Alpaca, Arena-Hard), Sampling-Temperatur 1.0; berichtet wird die Accepted Length 𝜏 pro Runde

  • Zentrale Ergebnisse

    • In der Offline-Evaluation wird der Confidence Scheduler deaktiviert, um bei festen Blöcken ausschließlich die reine Draft-Qualität zu isolieren
    • Bei Qwen3-4B, 8B und 14B verbessert DSpark die makro-gemittelte Accepted Length gegenüber Eagle3 um 30,9%·26,7%·30,0% und gegenüber DFlash um 16,3%·18,4%·18,3%; auch bei Gemma4-12B zeigt sich ein konsistenter Gewinn und damit Generalisierung über Modellfamilien hinweg
    • Strukturierte Aufgaben haben höhere Accepted Lengths als offene Chats (bei Qwen3-4B: Mathematik 5,57, Code 5,12 vs. Chat 3,49); die Varianz in der Datenvorhersagbarkeit führt bei statischen Verifikationslängen zu Verschwendung und motiviert Confidence Scheduling

Experimentanalyse

  • Warum parallele Generierung Autoregression übertrifft

    • Die kontraintuitive Beobachtung, dass parallele und semi-autoregressive Drafter längere Accepted Lengths erzielen als das vollständig autoregressive Eagle3, wird über bedingte positionsweise Akzeptanzraten analysiert (der Nenner umfasst nur Fälle, in denen alle vorherigen Positionen akzeptiert wurden)
    • Kapazitätsvorteil an Position 1: Die erste Position hängt nur vom Target-Kontext ab; Eagle3 ist wegen 𝑂(𝛾)-Latenz auf ein flaches Netz beschränkt, während ein 𝑂(1)-Parallel-Drafter ein tiefes Netz verwenden kann. DFlash startet höher als Eagle3 (Mathematik 0,88 vs. 0,81, Chat 0,72 vs. 0,53); da eine Ablehnung des ersten Tokens den gesamten Block ungültig macht, wirkt sich der frühe Vorteil stark auf die finale Accepted Length aus
    • Unabhängigkeitsgrenzen an späteren Positionen: An den Positionen 2–7 nutzt Eagle3 bedingte Sicherheit und hält bzw. steigert die Werte (Chat 0,53→0,74), während DFlash stark abfällt (Code 0,87→0,78, Chat 0,72→0,63) und durch Multi-Modal Collision inkonsistente Suffixe erzeugt
    • Semi-autoregressive Abschwächung des Suffix Collapse: DSpark übernimmt die hohe anfängliche Akzeptanz des tiefen parallelen Backbones (Start Mathematik 0,93), unterdrückt aber mit einem leichtgewichtigen sequenziellen Head den späteren Kollaps und hält über den gesamten Block hohe, stabile bedingte Akzeptanzraten

  • Schon wenig Autoregression bringt große Wirkung

    • Drafter-Tiefe: Bei fester Blockgröße 7 steigt die Leistung monoton, wenn die DSpark-Schichtzahl von 1 auf 5 erhöht wird; der Grenznutzen ist beim Schritt von 1 auf 2 Schichten am größten. Ein 2-Schichten-DSpark übertrifft 5-Schichten-DFlash in allen Domänen, was die Parametereffizienz des sequenziellen Heads belegt
    • Vorschlagslänge: Bei fester Tiefe 5 und Draft-Längen {4,8,12,16} übertrifft DSpark DFlash bei jeder Länge; mit wachsendem 𝛾 vergrößert sich der Abstand (bei 𝛾=7: Mathematik 16%, Code 15%, Chat 18%; bei 𝛾=15: 30%, 26%, 22%). Der RNN Head liefert bei langen Längen nur geringe Zusatzgewinne, daher wird der Markov Head als Standard gewählt
    • Latenz-Overhead: Gemittelt über Batch 128 und Kontextlängen {512,1024,2048,4096} ist die Latenz des sequenziellen Blocks vernachlässigbar; die Erweiterung der Draft-Länge von 4 auf 16 erhöht die gesamte Rundenlatenz nur um 0,2–1,3%, verbessert aber die Accepted Length um bis zu 30%

  • Rolle des Confidence Head — nicht länger, sondern smarter verifizieren

    • Diagnose per statischem Threshold Sweep mit Qwen3-4B: Mit steigendem Threshold steigt durch Herausfiltern abgelehnter Tokens die Akzeptanzrate, am stärksten im Chat (45,7%→95,7%); Mathematik (76,9%→92,5%) und Code (67,6%→92,0%) steigen moderater
    • Statische Thresholds ignorieren die Systemlast und sind im dynamischen Serving suboptimal; das Confidence-Modell besitzt starke Trennschärfe (ROC-AUC 0,81–0,90), ist aber overconfident (ECE 3–8%). Nach Anwendung von STS sinkt die durchschnittliche ECE auf etwa 1%, wodurch verlässliche Survival-Schätzungen verfügbar werden

Deployment in realen Diensten

  • Skalierbares Training

    • Gemeinsames Deployment mit DeepSeek-V4-Flash und Pro preview; das parallele Backbone besteht aus drei MoE-Schichten mit mHC sowie Sliding Window Attention 128, maximale Blockgröße 𝛾=5, Markov Head wird genutzt, der Confidence Head wird end-to-end trainiert und anschließend per STS kalibriert
    • Hidden State Communication: Statt vollständige Vocabulary-Logits (𝑉≈10⁵) zu übertragen, wird nur der Hidden State direkt vor dem LM Head kommuniziert, und der LM Head wird nur für Sample-Positionen lokal auf dem Draft-Worker ausgeführt; dadurch sinkt die Kommunikationskomplexität pro Token auf 𝑂(𝑑)
    • Anchor-bounded Sequence Packing: Eine feste Zahl von Draft-Ankern wird gesampelt, isolierte Vorhersageblöcke werden zu dichten Batches gepackt; kausales Masking zwischen mehreren unabhängigen Sequenzen wird über Token-Level-Attention-Indizes erhalten, während Padding-Overhead vermieden wird

  • Praktischer Einsatz des Schedulers

    • Zwei Konflikte: Der Algorithmus nimmt glatte unimodale Kapazitätskurven an, während reales SPS(𝐵) diskret ist und stufenförmig abfällt; dynamisches Token-Scheduling pro Schritt kollidiert mit kontinuierlichem CUDA Graph Replay und Zero-Overhead Scheduling (ZOS)
    • Anpassung durch asynchrones Scheduling: Da ZOS die nächste Batchgröße vor Abschluss des aktuellen Schritts benötigt, wird die Verifikationskapazität anhand der Confidence-Ausgaben von vor zwei Schritten angenähert; aktuelle Kandidaten werden nach aktueller kumulativer Confidence sortiert, vergangene Vorhersagen werden nur zur Bestimmung der dynamischen Cut-Länge (𝐾) verwendet, und dies wird als dynamische Top-𝐾-Auswahl formuliert
    • Early Stopping wird entfernt, um uneingeschränkte globale Suche zu aktivieren; da nur die Historie von vor zwei Schritten ausgewertet wird, bleibt sie von der Realisierung des aktuellen Tokens 𝑥𝑟,𝑘 isoliert und bildet eine kausale Barriere. So werden die Maximierung des physischen Durchsatzes über Hardware-Cliffs hinweg und die exakte Erhaltung der Target-Verteilung vereinbar

  • Inferenz mit hohem Durchsatz und niedriger Latenz

    • Production Serving optimiert gleichzeitig Latenz pro Anfrage und Gesamtdurchsatz; in diesem Deployment bleiben die effektiven Batchgrößen wegen KV-Cache-Kapazität und Nutzertraffic unterhalb der GPU-Sättigungsschwelle, sodass die beiden Ziele nicht konkurrieren, sondern stark korrelieren
    • Eine Herausforderung ist die Unterstützung variabel langer Queries: Bei naiver Verarbeitung in Decode-Kernels fester Länge führen Padding und ungleichmäßige Last zu geringer GPU-Auslastung. Alle Anfrage-Tokens werden daher zu unabhängigen Elementen flachgelegt, und Abhängigkeiten innerhalb der Sequenz werden über Marker Tensoren der Sparse Attention übergeben; in DeepSeek-V4 werden nur die index-attention- und compress-Kernels angepasst, um Routing mit variabler Länge zu unterstützen

  • Performance auf realem Nutzertraffic

    • DSpark-5 (𝛾=5) wird auf den Production-Engines V4-Flash und Pro mit der MTP-1-Baseline verglichen; MTP-1 war eine beibehaltene Single-Token-Konfiguration, weil statische Multi-Token-Drafter (MTP-3/5) bei hoher Nebenläufigkeit den Durchsatz senken, und wurde zwei Wochen nach Launch von DeepSeek-V4-preview durch DSpark ersetzt
    • V4-Flash: Bei einer SLA von 80 tok/s/user steigt der Durchsatz um 51%; bei 120 tok/s/user nähert sich MTP-1 der Betriebsgrenze, sodass nominal ein Vorteil von 661% entsteht (zu interpretieren als Beleg für die Erweiterung der Interaktions-Frontier, nicht als absoluter Multiplikator). Bei gleichem Durchsatz beschleunigt sich die Generierung pro Nutzer um 60–85%
    • V4-Pro: Bei 35 tok/s/user steigt der Durchsatz um 52%; bei 50 tok/s/user ergibt sich nominal ein Vorteil von 406%. Bei gleicher Kapazität beträgt die Beschleunigung 57–78%, insgesamt verschiebt sich die Throughput–Interactivity Frontier nach außen
    • Lastadaptives Verhalten: Bei mittlerer Nebenläufigkeit (V4-Flash unter 200, V4-Pro unter 150 Anfragen) erweitert der Scheduler die statischen 2 Tokens pro Anfrage von MTP-1 auf etwa 4–6 Tokens und erhöht dadurch die akzeptierten Tokens pro Forward Pass; bei Sättigung der Nebenläufigkeit verkürzt er die Verifikationslänge sanft und schneidet Low-Confidence-Tokens ab, bevor sie Batch-Kapazität verdrängen

  • Grenzen

    • Der Präfix-Scheduler minimiert zwar verschwendete Target-Verifikation, doch es bleibt ein fixer Draft-Aufwand für die initiale Generierung des 𝛾-Token-Blocks durch das parallele Backbone; bei komplexen Queries mit inhärent niedriger Akzeptanzrate lässt sich diese Vorabrechnung nicht amortisieren
    • Künftig könnte Difficulty-aware Early Exiting im Draft-Modell verbessern, dass solche Anfragen die vollständige Blockgenerierung umgehen

Fazit

  • Strukturell reduziert das semi-autoregressive Paradigma, das ein schweres paralleles Backbone mit einem leichtgewichtigen sequenziellen Head kombiniert, den abrupten Suffix Collapse unabhängiger paralleler Drafter
  • Systemseitig wird die Wahl der Verifikationslänge als Problem zur Maximierung des globalen Durchsatzes formuliert; ein hardwarebewusster Präfix-Scheduler auf Basis kalibrierter Survival-Wahrscheinlichkeiten und Echtzeit-Engine-Last passt das Verifikationsbudget dynamisch an
  • Umfangreiche Offline-Evaluationen übertreffen SOTA-autoregressive und parallele Baselines; das reale Deployment von DeepSeek-V4 belegt praktischen Nutzen durch stabile Nebenläufigkeit unter hoher Last, beschleunigte Generierung pro Nutzer und Erweiterung der Pareto Frontier im LLM Serving

Verwandte Beiträge

1 Kommentare

 
GN⁺ 6 시간 전
Meinungen auf Hacker News

  • DeepSeek verschiebt nicht nur die Grenzen, sondern veröffentlicht auch noch hervorragende Paper, die erklären, wie die Leistungssteigerungen erreicht wurden.
    Leider machen US-Labore solche Offenlegungen kaum noch, und es wirkt so, als käme die spannendste Arbeit in der KI derzeit aus chinesischen Forschungslaboren.

    • Google veröffentlicht weiterhin viel Forschung zu LLM-Architekturen.
      2022 haben sie Speculative Decoding für LLMs vorgestellt[1], und dieses Jahr haben sie auch Code veröffentlicht, der Speculative Decoding mit den Gemma-4-Modellen durchführt[2].

      [1] https://arxiv.org/abs/2211.17192

      [2] https://github.com/google-gemma/cookbook/blob/main/docs/mtp/...

    • US-KI-Unternehmen müssen riesige Investitionen rechtfertigen und scheinen daher nach einem magischen Burggraben zu suchen, der ihre Bewertungen stützt.
      Würden sie solche Optimierungen veröffentlichen, würde ihr Wettbewerbsvorteil deutlich schrumpfen.

    • Vielleicht ist die Offenlegung auch aus der Not geboren.
      Da US-Labore an der vordersten Front den Weg bahnen, ist die Vermutung, dass DeepSeek das, was es hat, als Open Source veröffentlicht, um das Spielfeld zu ebnen.

    • DeepSeek macht die Leistungsgewinne zur Commodity, auf die US-Labore angewiesen sind, um ihren Investoren Geld einzubringen.

    • Es ist an der Zeit, dass der Westen die Vorstellung aufgibt, Chinesen seien nur „sehr schlechte Menschen unter einer Diktatur“.

  • Die Hugging-Face-Modelle sind bereits online und sehen ziemlich cool aus: Es wirkt so, als sei ein Speculative-Decoding-Modul direkt in das ursprüngliche Modell eingebaut.

    Flash: https://huggingface.co/deepseek-ai/DeepSeek-V4-Flash-DSpark

    Pro: https://huggingface.co/deepseek-ai/DeepSeek-V4-Pro-DSpark

    Bin gespannt, ob es auch in DwarfStar für lokale Inferenz landet.
    Seit antirez die 2-Bit-Quantisierung veröffentlicht hat, habe ich das Flash-Modell viel genutzt.

    • Besteht die Möglichkeit, dass das auch auf Qwen 27B angewendet wird?

  • Im Moment fühlt es sich so an, als sei DeepSeek fast das einzige KI-Unternehmen, das tatsächlich innovieren will, statt einfach nur Platz 1 in Benchmarks anzustreben.
    Unternehmen wie OpenAI, Anthropic und Google scheinen stärker damit beschäftigt zu sein, miteinander zu konkurrieren, als weiter zu innovieren.

    • Ich finde, man sollte auch andere chinesische Forschungslabore wie Moonshot, den Entwickler von Kimi, und Z.ai, den Entwickler von GLM, dazuzählen.
      Auch sie innovieren und teilen ihre Forschung weiterhin offen.
      Soweit ich weiß, hat der Gründer von Moonshot sogar ein 40-minütiges Video auf Twitter gepostet, in dem er die Techniken erklärt, auf denen Kimi basiert.

    • Viele US-Unternehmen verfolgen schon lange die Strategie, Nutzer festzuhalten, mit welchen Mitteln auch immer.
      Qualität und Innovation sind zweitrangig; sie wollen den Markt beherrschen, Nutzer einsperren und dann über Regulierung und Lobbying Einfluss nehmen, um ihre Macht zu erhalten.

    • Diese Unternehmen konkurrieren ebenfalls durch Innovation miteinander.
      Innovation bringt Kunden größeren Nutzen, nur wird die Technologie eben nicht veröffentlicht.
      Geschäftsgeheimnisse sind aus gutem Grund geheim.

      DeepSeek wirkt möglicherweise deshalb „am innovativsten“, weil genau das von außen beobachtbar ist.
      Das ist ein ähnlicher Trugschluss wie der Schluss, veröffentlichte Models seien die hübschesten in der gesamten Bevölkerung, nur weil nicht jeder Fotos von sich öffentlich macht.

    • Die großen Forschungslabore machen so etwas schon seit mindestens einem Jahr.

    • Qwen ebenso.

  • Ich nutze DeepSeek v4 pro seit einem Monat in Kilo Code, und es ist hervorragend.
    Schnell, zuverlässig, großes Kontextfenster und wirklich günstig.
    Diesen Monat habe ich 1,5 Milliarden Tokens verbraucht, was 40 Dollar gekostet hat; vieles davon war zwar gecacht, aber es ist trotzdem billig.

    • Ich nutze DeepSeek in omp als task- und quicktask-Agenten und Sonnet für den Rest.
      Meine KI-Ausgaben sind deutlich gesunken, von 40 Dollar pro Tag auf 10 Dollar pro Tag.
    • Mich würde interessieren, welchen Anbieter du genutzt hast.
      Bei OpenRouter waren 40 Dollar schnell weg.
      Es gab nicht viele Hin-und-her-Dialoge, der Kontext lag bei etwa 300.000, die Ausgabe bei rund 15.000 Zeilen.
      Ich habe opencode verwendet, weiß aber nicht genau, ob man die gesamte Tokenzahl anzeigen lassen kann.
    • Mich würde interessieren, ob du Kilo mit Pi oder OpenCode verglichen hast.
      Mit beiden bin ich vertraut, suche aber immer nach Alternativen.
    • Gibt es eine Möglichkeit zu sehen, wie viele Tokens man in Claude Code Pro verbraucht hat?

  • Ist das neuer oder besser als Speculative Decoding von 2022? https://arxiv.org/abs/2211.17192

    • Dieses Paper wird in den Abschnitten „introduction“ und „background“ des vorliegenden Papers zitiert.
      In diesem Paper geht es darum, einige Engpässe zu beseitigen und es dadurch zu verbessern.
    • Es scheint den Fokus darauf zu legen, das Draft-Modell und die Verifikationsstrategie zu verbessern, sodass Spekulation auf DeepSeek-Skala nicht in verschwendete Verifikationsarbeit mündet, sondern in reine Beschleunigung.

  • Der Zeitpunkt wirkt nicht zufällig.
    Es scheint Offenheit einem starken Regulierungsansatz gegenüberzustellen.

    • China = offen, USA = starke Regulierung ist schon eine seltsame Zeitlinie.
      Allerdings ist das möglich, weil es mit Xis Zielen übereinstimmt.
    • Niemand hat Anthropic gezwungen, eine Medienoffensive zu starten, in der die Gefahren neuer KI-Modelle groß aufgeblasen werden.
      Ehrlich gesagt: selbst schuld.

  • Der Titel ist nicht gut.
    Er ist nicht der Titel des Papers, sondern die erste Zeile des Abstracts.
    Speculative Decoding für LLM-Inferenz wurde bereits 2022 veröffentlicht: https://arxiv.org/abs/2211.17192

    Dieses Paper scheint eine Verbesserung von Speculative Decoding zu sein, aber ich habe es noch nicht gelesen.

  • Wegen des Namens dachte ich zuerst, es habe etwas mit DGX Spark zu tun.
    Zufällig gab es in letzter Zeit viel Arbeit daran, die Inferenzleistung von DGX Spark zu verbessern, und MTP brachte 50–100 % mehr Geschwindigkeit; DSpark dürfte für diesen Zweck also ebenfalls ziemlich hilfreich sein.

  • Vermutlich lief das schon eine Weile in Produktion und war einer der Gründe, warum sie vor einem Monat die Preise stark senken konnten.

    • Genau.
      Kapitel 5 behandelt den realen Einsatz.
      In 5.1 steht: „DSpark draft models are co-deployed with the preview versions of DeepSeek-V4-Flash and DeepSeek-V4-Pro“, und in 5.4 steht: „MTP-1 represents the former production setup, having been superseded by DSpark two weeks following the DeepSeek-V4-preview release“.
    • Lookahead Sparse Attention dürfte ebenfalls eine große Rolle gespielt haben.
      Denn es reduziert den Speicherverbrauch deutlich.
    • Gut erkannt.
      Sie haben die Preise um 75 % gesenkt, und das scheint ziemlich genau zu den Gewinnen bei Geschwindigkeit und Inferenzoptimierung zu passen.

  • Ich glaube, bald wird es für jeden Use Case, jedes Unternehmen und sogar jede Einzelperson sehr viele eigene kleine Modelle für Speculative Decoding geben.

    • Das wäre schön, und hoffentlich wird Hardware dann nicht unmöglich zu bekommen.

    • Ja.
      Das wird stark durch ausgefeilte Guardrails eingeschränkt sein.

      Es geht eindeutig in diese Richtung.
      Die riesigen Modelle, die die ganze Welt verschlingen wollen, haben im Vergleich dazu extrem stark sinkende Erträge.

    • Du hast die neueren Paper zu Speculative Decoding offenbar nicht gelesen.
      Schon seit einiger Zeit kann im Grunde jedes Modell für ein anderes Modell zur Spekulation verwendet werden.
      Die früher blockierenden Tokenisierungsprobleme wurden gelöst.