12 Punkte von xguru 2025-03-02 | 1 Kommentare | Auf WhatsApp teilen
  • Zum Abschluss der Open-Source-Veröffentlichungswoche wurden als one more thing überraschend eine Gesamtübersicht des Systems und sogar die Betriebskosten offengelegt

Überblick über das Inferenzsystem von DeepSeek-V3/R1

Prinzipien des Systemdesigns

  • Das Optimierungsziel des Inferenzsystems von DeepSeek-V3/R1 sind höherer Durchsatz und geringere Latenz
  • Dafür wurde zur Optimierung Cross-Node Expert Parallelism (EP) eingesetzt.
    • Mehr Durchsatz: EP skaliert die Batch-Größe, erhöht so die Effizienz der GPU-Matrixoperationen und steigert den Durchsatz.
    • Weniger Latenz: Durch die Verteilung der Experten (Experts) auf mehrere GPUs wird der Speicherzugriff pro einzelner GPU reduziert, was die Latenz senkt.
  • Allerdings erhöht EP die Systemkomplexität:
    • Cross-Node-Kommunikation erforderlich: Kommunikation und Berechnung müssen überlappend ausgeführt werden, um Engpässe zu vermeiden.
    • Nutzung mehrerer Nodes: Data Parallelism (DP) muss angewendet werden, und zwischen den DP-Instanzen ist Load Balancing nötig.

Großskaliger Cross-Node Expert Parallelism (EP)

  • Im DeepSeek-V3/R1-Modell werden pro Layer von 256 Experten nur 8 aktiviert, daher ist eine Skalierung der Batch-Größe zwingend erforderlich
  • Unterschiede der Parallelität zwischen Prefill- und Decode-Phase:
    • Prefill-Phase: EP32, DP32 (4 Nodes, jede GPU verarbeitet 9 Experten)
    • Decode-Phase: EP144, DP144 (18 Nodes, jede GPU verarbeitet 2 Experten)

Overlap von Berechnung und Kommunikation (Computation-Communication Overlapping)

  • Da EP die Kosten der Cross-Node-Kommunikation erhöht, wird eine Double-Batch-Overlap-Strategie eingesetzt, um diese zu reduzieren.
    • Prefill-Phase: Zwei Mikrobatches werden abwechselnd ausgeführt, sodass die Kommunikation eines Batches hinter der Berechnung des anderen verborgen wird.
    • Decode-Phase: Die Attention-Layer werden in zwei Phasen aufgeteilt, und mit einer 5-stufigen Pipeline wird der Overlap von Berechnung und Kommunikation maximiert.

Umsetzung optimalen Load Balancings

  • Um Ungleichgewichte zwischen GPUs zu verhindern und die Ressourcennutzung zu maximieren, werden drei Load-Balancing-Methoden eingesetzt.
    1. Prefill-Load-Balancer
    • Problem: Unterschiede bei Anzahl der Requests und Sequenzlängen führen zu ungleichmäßiger Last bei Core-Attention-Berechnungen und Datenübertragung.
    • Ziel:
      • Gleichgewicht der Core-Attention-Rechenlast zwischen den GPUs.
      • Gleichmäßige Verteilung der Anzahl der Input-Tokens pro GPU.
    1. Decode-Load-Balancer
    • Problem: Unterschiede bei der KVCache-Nutzung führen zu unterschiedlicher Rechenlast zwischen den GPUs.
    • Ziel:
      • Gleichgewicht der KVCache-Nutzung zwischen den GPUs.
      • Gleichmäßige Verteilung der Anzahl der Requests pro GPU.
    1. Expert-Parallel-Load-Balancer
    • Problem: Eine hohe Last auf bestimmten Experten (Experts) verursacht Rechenungleichgewichte zwischen den GPUs.
    • Ziel:
      • Gleichgewicht der Experten-Rechenlast auf jeder GPU.

Statistiken des Online-Inferenzsystems von DeepSeek

  • Der Inferenzdienst von DeepSeek-V3/R1 läuft auf H800 GPUs und behält die gleiche Rechengenauigkeit wie beim Training bei
    • FP8: Matrixoperationen und Datenübertragung
    • BF16: zentrale MLA-Berechnungen und kombinierte Übertragung
  • Betriebsstrategie für Spitzenzeiten und Nachtbetrieb
    • Tagsüber ist die Service-Last hoch, nachts sinkt sie
    • Spitzenzeiten: Alle Nodes werden für den Inferenzdienst genutzt
    • Nächtliche Niedriglastzeiten: Ein Teil der Nodes wird für Forschung und Training umgewidmet, um Ressourcen effizient zu nutzen
  • 24-Stunden-Betriebsstatistik (UTC+8, 2025-02-27 12:00 PM ~ 2025-02-28 12:00 PM)
    • Gesamte Input-Tokens: 608B (davon waren 342B, also 56,3 %, KV-Cache-Treffer)
    • Gesamte Output-Tokens: 168B (durchschnittliche Ausgabegeschwindigkeit 20~22 Tokens/s)
    • Durchschnittliche KVCache-Länge: 4.989 Tokens pro Output-Token
    • Verarbeitungsgeschwindigkeit pro H800-Node:
      • Prefill-Phase: 73.7k Tokens/s (inklusive Cache-Treffern)
      • Decode-Phase: 14.8k Tokens/s

Analyse von Betriebskosten und Einnahmen: V3 & R1 auf Basis eines Tages von UTC+8 02/27/2025 12:00 PM bis 02/28/2025 12:00 PM

  • GPU-Nutzung: 278 Nodes zu Spitzenzeiten, durchschnittlich 226,75 Nodes (jede Node enthält 8 H800 GPUs)
  • GPU-Mietkosten: $2/Stunde pro H800 GPU → gesamte tägliche Betriebskosten: $87,072
  • Wenn alle Tokens abrechnungsfähig wären, theoretischer Tagesumsatz: $562,027 → Marge 545 %
    • (Preise für Input-/Output-Tokens von R1: $0.14M (Cache-Treffer), $0.55M (kein Cache-Treffer), $2.19M)
  • Die tatsächlichen Einnahmen liegen jedoch niedriger:
    • Die Preise von DeepSeek-V3 sind deutlich niedriger als die von R1
    • Nur ein Teil des Dienstes wird monetarisiert (Web- und App-Nutzung sind kostenlos)
    • Nachts werden automatische Rabatte angewendet

Die 5 Open-Source-Projekte, die als DeepSeek Open Infra veröffentlicht werden wurden hier mit dem letzten one more thing ergänzt

1 Kommentare

 
sppappi 2025-03-03

Wenn man drei Fragen stellt, hängt es sich einfach auf..