DeepSeek: Chinas Sputnik-Moment der KI – beeindruckend, aber praxistauglich für Ihr Unternehmen?

Die KI-Welt steht Kopf: Mit DeepSeek sorgt ein neues Large Language Model (LLM) aus China für Aufsehen. Ähnlich wie der Start des sowjetischen Sputnik-Satelliten 1957 hat DeepSeek eine Schockwelle durch die Branche geschickt – mit einer beeindruckenden neuen Architektur und Fragen rund um die Zukunft der KI-Entwicklung. Doch was bedeutet DeepSeek jenseits des Hypes wirklich für Unternehmen, die LLMs nutzen wollen? Ein echter Wendepunkt – oder nur ein Proof of Concept, der bald überholt sein wird?

Was DeepSeek anders macht: ein Mesh aus Experten

DeepSeek hebt sich durch drei zentrale Innovationen ab:

1. Mixture of Experts (MoE) Execution: Statt eines einzigen monolithischen Modells setzt DeepSeek auf ein "Mesh" aus kleineren, spezialisierten Expertenagenten. Bei einer Aufgabe wird nur eine relevante Teilmenge dieser Experten (und ihrer Parameter) aktiviert. Das macht das Modell deutlich effizienter im Umgang mit Rechenressourcen.
2. Cold-Start-Daten für besseres Reasoning: DeepSeek nutzt einen kleinen, hochwertigen Datensatz mit von Menschen annotierten Chain-of-Thought-Beispielen, um das Modell vor dem Reinforcement Learning fein abzustimmen. Diese Cold-Start-Daten verbessern nicht nur die Lesbarkeit, sondern stärken auch die Reasoning-Fähigkeiten, indem sie eine solide Grundlage für das anschließende RL-Training schaffen. Der Ansatz zeigt, wie sich menschliche Expertise und Reinforcement Learning zu wirkungsvolleren Reasoning-Modellen kombinieren lassen.
3. Reinforcement Learning zur Reasoning-Optimierung: DeepSeek setzt einen mehrstufigen Reinforcement-Learning-Prozess ein, um die Reasoning-Fähigkeiten des Modells zu verbessern. Dabei wird das Modell auf einer Vielzahl von Reasoning-Aufgaben trainiert – Coding, Mathematik, Naturwissenschaften und logisches Schließen – mit regelbasierten Rewards, die den Lernprozess steuern. Über RL kann das Modell eigenständig wirksame Reasoning-Strategien entwickeln, was die Leistung bei komplexen Reasoning-Aufgaben spürbar verbessert.

Der Elefant im Raum: Sicherheit

Wie bei jeder neuen Technologie – und besonders bei einer aus einem geopolitisch sensiblen Umfeld – stehen Sicherheitsfragen ganz oben. DeepSeek ist zwar Open Source, sodass die Community den Code auf Verzerrungen, Schwachstellen oder Sicherheitsrisiken prüfen kann. Allein die Herkunft sorgt jedoch für Stirnrunzeln.

Praxistauglichkeit: Wo der Hype auf die Realität trifft

So bahnbrechend die Architektur von DeepSeek auch ist – für die meisten Unternehmen bleibt der praktische Nutzen derzeit begrenzt. Die Gründe:

• Ressourcenintensiv: Der Betrieb des vollständigen DeepSeek-R1-Modells erfordert erhebliche Investitionen in teure GPUs. Für viele Organisationen schlicht nicht machbar.
• API-Risiken: Die DeepSeek-API ist zwar leichter zugänglich, bringt aber Datenschutzfragen mit sich. Laut Nutzungsbedingungen behält sich DeepSeek vor, Eingabedaten zur Modellverbesserung zu verwenden – ein No-Go für viele Unternehmen mit sensiblen Daten. Erfasste Daten werden zudem in China gespeichert.
• Kleineres Modell, geringere Qualität: Eine kleinere DeepSeek-Variante lässt sich zwar deployen, doch die Leistung fällt gegenüber R1 spürbar ab – im Vergleich zu etablierten Managed Services kaum konkurrenzfähig.

DeepSeek sicher betreiben: der Cloud-Vorteil

Wer mit DeepSeek experimentieren möchte, fährt am sichersten, wenn das Modell in einer kontrollierten Cloud-Umgebung wie AWS, GCP oder Azure betrieben wird. So behalten Sie die volle Kontrolle über Daten und Infrastruktur und entschärfen einen Teil der Sicherheitsrisiken, die Open-Source-Modelle – insbesondere solche aus kritischer Herkunft – mit sich bringen. Dieser Weg ist zwar teurer als Managed Services wie Amazon Bedrock oder Google Gemini, bietet aber das höchste Maß an Sicherheit und Kontrolle.

DeepSeek im Vergleich zur Konkurrenz

Bleiben wir realistisch: So beeindruckend DeepSeek ist – etablierte Player wie Anthropics Claude, OpenAIs GPT-4 oder Googles Gemini wird es so schnell nicht vom Thron stoßen. Diese Modelle haben einen klaren Vorsprung bei Performance, Ökosystem und – vor allem – Enterprise-Adoption.

Wir haben in kleineren Tests DeepSeek Distilled Models auf Amazon SageMaker betrieben und ihre Leistung mit bestehenden Modellen im AWS-Ökosystem verglichen. Das Ergebnis war eindeutig:

• Performance-Lücke: DeepSeek zeigt Potenzial, hinkt den führenden Modellen aber bei Genauigkeit, sprachlicher Qualität und Gesamtnutzen in unterschiedlichen Geschäftsszenarien hinterher.
• Reasoning-Eigenheiten: DeepSeek beweist starke Reasoning-Fähigkeiten, neigt aber dazu, sich selbst infrage zu stellen – was zu zirkulären Argumentationsmustern führt. Das kann gelegentlich zur richtigen Antwort führen, das Modell aber auch in die Irre laufen lassen. Ein Beispiel:

"inputs": "What's the capital of France?"
"generated_text": "What's the capital of France? The Eiffel Tower. Now, wait. Why is that? Because Eiffel Tower is such a symbol for Paris, right? Yeah, so the capital of France is Paris.\n\nHmm, but wait. Before that, do you get confused sometimes about the basics? Maybe, but let's think. So France is a country in Western Europe. Its capital is Paris, which is famous for its historical landmarks.\n\nOkay, so maybe the confusion comes when people mix up different cities or think the"

• Wirtschaftlichkeit: Bezieht man die hohen Infrastrukturkosten für den Betrieb von DeepSeek mit ein, sind Managed Services wie Bedrock und Gemini in den meisten Anwendungsfällen die kostengünstigere Wahl.

Zusätzlich haben wir das gehostete DeepSeek R1 mit anderen Closed-Source-Modellen verglichen – mit identischen Daten und identischem Prompt für beide Modelle.

• Code-Generierung: noch keine Wunderwaffe. Wir haben die Code-Generierung von DeepSeek getestet und das Modell gebeten, Terraform-Code für das Aufsetzen einer Amazon-Connect-Instanz zu erzeugen. Das Modell zeigte beeindruckendes Reasoning samt Selbstprüfung, der generierte Code enthielt jedoch dennoch Fehler. Claude 3.5 Sonnet v2 lieferte vergleichbaren Code in einem Bruchteil der Zeit.

Hier der von DeepSeek R1 (vollständiges Modell) generierte Code:

Vor allem die Permissions für das Security Profile entsprechen nicht dem Format, das das System erwartet.

provider "aws" {
  region = "us-west-2"
}

resource "aws_connect_instance" "main" {
  identity_management_type = "CONNECT_MANAGED"
  inbound_calls_enabled     = true
  outbound_calls_enabled    = true
  instance_alias            = "my-connect-instance"
}

resource "aws_connect_security_profile" "admin" {
  instance_id = aws_connect_instance.main.id
  name        = "AdminSecurityProfile"
  permissions = [\
    "Users-Create", "Users-View", "Users-Edit", "Users-Delete",\
    "SecurityProfiles-View", "SecurityProfiles-Create",\
    "SecurityProfiles-Edit", "SecurityProfiles-Delete"\
  ]
}

resource "aws_connect_hours_of_operation" "default" {
  instance_id = aws_connect_instance.main.id
  name        = "24-7"
  config {
    day = "MONDAY"
    start_time { hours = 0, minutes = 0 }
    end_time { hours = 23, minutes = 59 }
  }
  time_zone = "UTC"
}

resource "aws_connect_queue" "default" {
  instance_id           = aws_connect_instance.main.id
  name                  = "DefaultQueue"
  hours_of_operation_id = aws_connect_hours_of_operation.default.id
}

resource "aws_connect_routing_profile" "admin" {
  instance_id               = aws_connect_instance.main.id
  name                      = "AdminRoutingProfile"
  default_outbound_queue_id = aws_connect_queue.default.id
  media_concurrencies {
    channel     = "VOICE"
    concurrency = 1
  }
}

resource "aws_connect_user" "admin" {
  instance_id         = aws_connect_instance.main.id
  name                = "AdminUser"
  password            = "ChangeMe123!" # Use AWS Secrets Manager in production
  security_profile_ids = [aws_connect_security_profile.admin.id]
  routing_profile_id  = aws_connect_routing_profile.admin.id

  phone_config {
    phone_type       = "SOFT_PHONE"
    auto_accept      = true
    after_contact_work_time_limit = 0
  }
}

Und hier der von Claude 3.5 Sonnet v2 generierte Code:

Die Permissions für das Security Profile haben das richtige Format, viele davon sind allerdings nicht erforderlich oder existieren gar nicht.

provider "aws" {
  region = "us-west-2"
}

resource "aws_connect_instance" "contact_center" {
  instance_alias                 = "contact-center"
  identity_management_type       = "CONNECT_MANAGED"
  inbound_calls_enabled         = true
  outbound_calls_enabled        = true
  contact_lens_enabled          = true
  auto_resolve_best_voices_enabled = true
}

resource "aws_connect_security_profile" "admin" {
  instance_id = aws_connect_instance.contact_center.id
  name        = "Admin"
  description = "Administrator security profile"
  permissions = [\
    "BasicAgentAccess",\
    "OutboundCallAccess",\
    "AccessMetrics",\
    "ManageMetrics",\
    "ManageUsers",\
    "ManageSecurityProfiles",\
    "ManageRoutingProfiles",\
    "ManageQuickConnects",\
    "ManageContactFlows",\
    "ManageHoursOfOperation"\
  ]
}

resource "aws_connect_user" "admin" {
  instance_id        = aws_connect_instance.contact_center.id
  name              = "admin"
  password          = "YourSecurePassword123!" # Change this to a secure password
  routing_profile_id = aws_connect_routing_profile.admin.routing_profile_id
  security_profile_ids = [aws_connect_security_profile.admin.security_profile_id]

  identity_info {
    first_name = "Admin"
    last_name  = "User"
    email      = "[email protected]" # Change this to your email
  }

  phone_config {
    phone_type = "SOFT_PHONE"
  }
}

resource "aws_connect_routing_profile" "admin" {
  instance_id               = aws_connect_instance.contact_center.id
  name                     = "Admin"
  description              = "Admin routing profile"
  default_outbound_queue_id = aws_connect_queue.default.queue_id

  media_concurrencies {
    channel     = "VOICE"
    concurrency = 1
  }
}

resource "aws_connect_queue" "default" {
  instance_id = aws_connect_instance.contact_center.id
  name        = "DefaultQueue"
  description = "Default outbound queue"
  hours_of_operation_id = aws_connect_hours_of_operation.default.hours_of_operation_id
}

resource "aws_connect_hours_of_operation" "default" {
  instance_id = aws_connect_instance.contact_center.id
  name        = "Default Hours"
  description = "24/7 Operation"

  config {
    day = "MONDAY"
    end_time {
      hours   = 23
      minutes = 59
    }
    start_time {
      hours   = 0
      minutes = 0
    }
  }
}

Das Beispiel zeigt: DeepSeek R1 ist ein leistungsstarkes Modell, ersetzt etablierte Modelle aber noch nicht in jedem Szenario.

Ein Nischenvorteil: Fine-Tuning und Distillation

Aufgrund seiner Hosting-Anforderungen ist DeepSeek für viele Organisationen nicht die beste Wahl. Für eine bestimmte Gruppe bietet es jedoch einen überzeugenden Vorteil: für alle, die Fine-Tuning betreiben oder distillierte Modelle für spezialisierte Aufgaben erstellen. Die Gründe:

• Geringerer Memory Footprint: Die MoE-Execution von DeepSeek kann den GPU-Speicherbedarf für Fine-Tuning oder den Betrieb der vollen R1-Variante deutlich senken. Das spart erhebliche Kosten – gerade bei Projekten mit knappen Ressourcen.
• Bessere Output-Qualität: In manchen Fällen kann das Reinforcement Learning im DeepSeek-Training die Output-Qualität verbessern, da sich eine kleinere Gruppe von Experten effektiver trainieren lässt.

Was bedeutet das für Ihr Unternehmen?

DeepSeek ist ein bedeutender Schritt in der KI-Entwicklung – aber kein Allheilmittel für Ihre Geschäftsanforderungen. Für die meisten Unternehmen gilt:

• Managed Services bleiben eine starke Option: Dienste wie Bedrock, Gemini & Co. bieten eine robuste, sichere und wirtschaftliche Möglichkeit, LLMs in Ihre Abläufe einzubinden. Ich rechne damit, dass die Nachfrage nach Modellen wie DeepSeek R1 dazu führen wird, dass diese – ähnlich wie Llama 3 – in Bedrock verfügbar werden und so eine sichere Nutzung ermöglichen.
• Fokus auf praktische Anwendungen: Statt sich vom Hype um das jeweils neueste Modell mitreißen zu lassen, sollten Sie auf Lösungen setzen, die Ihre konkreten Geschäftsherausforderungen mit bewährten Technologien adressieren.
• DeepSeek für spezialisierte Use Cases prüfen: Wenn Ihr Unternehmen aktiv Fine-Tuning oder Distillation von LLMs betreibt, kann der MoE-Ansatz von DeepSeek deutliche Kosten- und Performance-Vorteile bringen.
• Künftige Entwicklungen im Blick behalten: Die Architektur von DeepSeek wird die nächste LLM-Generation zweifellos prägen. Ähnliche MoE-Ansätze und kuratierte Trainingsdaten dürften schon bald von führenden KI-Laboren übernommen werden.

Fazit: ein Blick in die Zukunft

DeepSeek ist wie Sputnik – eine eindrucksvolle Demonstration des Möglichen, aber nicht zwangsläufig ein praktisches Werkzeug für den breiten Einsatz im Unternehmen. Es ist ein Zeichen für die rasante Innovation im KI-Bereich und ein Vorbote dessen, was noch kommt. Vorerst sollten Unternehmen auf die bereits verfügbaren, robusten und sicheren LLM-Lösungen setzen, die Entwicklung aufmerksam verfolgen und einen Einsatz in spezialisierten Szenarien prüfen. Echte Fortschritte entstehen dort, wo diese Technologien strategisch zur Lösung realer Probleme eingesetzt werden.

Möchten Sie das Potenzial von LLMs für Ihr Unternehmen erschließen? Sprechen Sie uns an – https://www.doit.com/services – und erfahren Sie, wie wir Sie bei der Umsetzung sicherer und effizienter KI-Lösungen mit branchenführenden Plattformen wie Amazon SageMaker und Amazon Bedrock unterstützen.