DeepSeek DeepInfer: Voraussetzungen für den Eigenbetrieb und Vergleich mit APIs

DeepInfer ist DeepSeeks Open-Source-Framework für Inferenz. Es führt ein Modell aus; es ist weder ein neues Modell noch eine sofort nutzbare gehostete API. Für Entwickler stellt sich deshalb zuerst die Frage, ob sie überhaupt ein Inferenz-Backend betreiben müssen. Wer eine Anwendung ausliefern möchte, sollte eine gehostete API mit dem vollständigen Dienst vergleichen, den das eigene Team aufbauen und warten müsste.

Dieser Leitfaden basiert auf der offiziellen Dokumentation, geprüft am 22. Oktober 2026. Wir haben DeepInfer nicht auf unterstützten Beschleunigern bereitgestellt und die veröffentlichten Leistungsdiagramme nicht reproduziert. Die Checklisten und die Kostenrechnung sind Entscheidungshilfen; sämtliche Zahlen im Rechenbeispiel sind ausdrücklich hypothetisch. Ofox bietet API-Zugang an und veröffentlicht diesen Artikel. Deshalb benennen wir die Bedingungen beider Wege, ohne vorauszusetzen, dass ein gehosteter Dienst für jeden Leser die richtige Wahl ist.

Welche Aufgaben DeepInfer, das Modell und deepseek-recipe übernehmen

Eine Modellbereitstellung umfasst mehrere Aufgaben. Wer die Komponenten gleichsetzt, erschwert sowohl die Kostenschätzung als auch die Fehlersuche.

Die DeepInfer-README nennt DeepSeek-V4.1-Flash als unterstütztes Modell und verwendet deepseek-ai/DeepSeek-V4.1-Flash-1017 als Standard-Checkpoint. Änderungen an der Modellversion behandelt unser Leitfaden zum 1017-Update (Englisch). Hier geht es um die Engine und die Entscheidung über ihren Betrieb.

Das separate Repository deepseek-recipe konvertiert die Formate Chat Completions, Responses und Messages. Die aufrufende Anwendung muss Modellinferenz, Werkzeugausführung und HTTP-Transport selbst bereitstellen. Die enthaltenen Python- und Rust-Beispielserver verwenden simulierte Inferenz. Eine JSON-Antwort aus einer solchen Demo beweist daher nicht, dass ein echtes Modell sie erzeugt hat.

Für die Fehlersuche ergeben sich drei getrennte Prüfungen: Kommt eine HTTP-Antwort zurück? Wird der Prompt korrekt aufbereitet? Erzeugt das echte Modell eine gültige Ausgabe? Ein Erfolg bei einer Prüfung belegt die beiden anderen nicht.

Vor der Installation die unterstützte Hardware prüfen

Die aktuelle README nennt NVIDIA-GPUs mit SM100 und Huawei-NPUs vom Typ Ascend 950. Als Basis sind Linux, GCC ab Version 13 und Python 3.12 angegeben. Für NVIDIA wird CUDA 13 verlangt, für Ascend CANN 9.2. Das sind die zum Prüfdatum dokumentierten Zielplattformen, keine Zusage für künftige Portierungen.

Eine RTX 4090 oder H100 gehört nicht zu diesen aufgeführten Zielen. Daraus folgt nicht, dass DeepSeek-Modelle grundsätzlich niemals auf diesen Karten laufen können: Die Ausführung über eine andere Engine ist eine eigene Kompatibilitätsfrage. Umgekehrt bestätigt ein Community-Pull-Request für eine Portierung noch keine Unterstützung in der aktuellen Veröffentlichung.

Halten Sie Gerätearchitektur, Treiber- und Werkzeugversionen, Checkpoint und Engine-Revision fest, bevor Sie den Implementierungsaufwand schätzen. Fehlt eine Voraussetzung, beginnen Sie mit einer Kompatibilitätsprüfung. Teure Hardware nur dafür zu mieten, herauszufinden, ob eine nicht unterstützte Konfiguration vielleicht kompiliert, ist kein sinnvoller erster Versuch.

Drei Fragen müssen getrennt bleiben:

1. Unterstützt: Führt die Dokumentation dieser Engine-Version die Plattform auf?
2. Ausführbar: Passt das Modell in die gewählte Konfiguration, und führt sie die Inferenz korrekt aus?
3. Effizient: Erreicht sie bei der erwarteten Last die Ziele für Durchsatz und Latenz?

Die offiziellen Fragen und Antworten zur Bereitstellung beschreiben für das empfohlene Produktionsdesign eine kleinste effiziente Einheit aus 64 Prefill-GPUs und 64 Decode-GPUs. Das ist keine absolute Mindestzahl für jeden Offline-Test. Auch die Benchmark-Konfigurationen in der README unterscheiden sich zwischen Prefill und Decode. Keine dieser Zahlen sollte ungeprüft zur allgemeinen Einkaufsliste für „Mindesthardware“ werden.

Was zwischen Offline-Inferenz und einer Online-API noch fehlt

Die öffentliche README nennt drei noch benötigte Bestandteile eines vollständigen Dienstes: ein KV-Cache-System, die Aufteilung von VE, Prefill und Decode sowie Lastverteilung zwischen datenparallelen Replikaten. VE steht für den visuellen Encoder. Prefill verarbeitet die Eingabe-Tokens im Modell; Decode erzeugt anschließend die Ausgabe-Tokens schrittweise. Zugleich weist die README darauf hin, dass ein großer Teil der dafür nötigen Engine-Funktionen bereits implementiert ist. Vorhandene Grundfunktionen sind aber noch kein zusammengesetzter, betriebener Dienst.

Benennen Sie für jede Aufgabe eine verantwortliche Person und eine Abnahmeprüfung:

Diese Tabelle ist eine vorgeschlagene Betriebsabnahme, keine Behauptung, DeepInfer liefere sämtliche Funktionen der linken Spalte mit. Insbesondere löst eigene Hardware Datenschutzfragen nicht automatisch: Zugriffe auf Rechner, Protokolle, Backups und zwischengespeicherte Prompts müssen weiterhin geregelt werden.

Stellen Sie einem API-Anbieter vergleichbare Fragen. Ein kompatibler Endpunktname allein garantiert weder identisches Tool-Verhalten noch dieselbe Cache-Abrechnung oder Datenaufbewahrung. Wer lediglich einen Coding-Client verbinden möchte, kann mit der Codex-Anleitung (Englisch) oder der Claude-Code-Anleitung (Englisch) beginnen und zunächst die aktuelle Unterstützung der gewählten Route prüfen.

Kosten bei gleicher Last und gleichem Leistungsziel vergleichen

Ein Diagramm mit Spitzenwerten für Tokens pro Sekunde sagt nichts über die monatlichen Gesamtkosten aus. Beginnen Sie mit einer repräsentativen Last: Verteilung der Eingabelängen, Ausgabelängen, wiederkehrende Präfixe, gegebenenfalls Bilder, parallele Anfragen und Tagesspitzen. Definieren Sie Ziele für abgeschlossene Anfragen, Qualität, Zeit bis zum ersten Token und Streaming-Geschwindigkeit. Ein billiger Dienst, der diese Ziele verfehlt, ist keine gleichwertige Alternative.

Rechnen Sie bei APIs mit getrennten Preisen für nicht gecachte Eingaben, Cache-Treffer und Ausgaben. Gebühren für Cache-Schreibvorgänge, Speicher, Plattform oder weitere Leistungen gehören nur hinein, wenn der gewählte Anbieter sie tatsächlich erhebt. Unbekannte Gebühren bleiben offene Punkte und werden nicht zu null. Tokenmengen müssen den Abrechnungsregeln entsprechen, einschließlich gegebenenfalls berechneter Reasoning-Tokens. Unser DeepSeek-API-Preisleitfaden (Englisch) erläutert das Thema; holen Sie vor einer Kaufentscheidung ein aktuelles Angebot für die konkrete Route ein.

Ein allgemeines Schema mit Mengen in Millionen abgerechneter Tokens:

Monatliche API-Kosten =
  Millionen nicht gecachter Eingabe-Tokens × zugehöriger Preis
  + Millionen gecachter Eingabe-Tokens × zugehöriger Preis
  + Millionen abgerechneter Ausgabe-Tokens × Ausgabepreis
  + weitere tatsächlich anfallende Monatsgebühren

Monatliche Kosten des Eigenbetriebs =
  Beschleunigermiete ODER anteilige Hardwareabschreibung
  + Kosten für Host, Netzwerk und Speicher
  + Strom, soweit nicht bereits in der Miete enthalten
  + Arbeitszeit für Betrieb und Support
  + Redundanz und Wiederherstellungskapazität
  + lastabhängige Kosten

Berechnen Sie einen Beschleuniger nicht zugleich als Miete und Abschreibung. Strom darf ebenfalls nicht doppelt angesetzt werden, wenn die Miete ihn bereits enthält. Ordnen Sie gemeinsam genutzte Arbeitszeit ausdrücklich zu. Beschaffen Sie für Unbekanntes ein Angebot oder einen Messwert und zeigen Sie eine Spanne, statt Unsicherheit in einer scheinbar genauen Summe zu verstecken.

Nachrechenbares Beispiel statt DeepInfer-Preisangebot

Angenommen, eine Lasteinheit umfasst 100 Millionen Eingabe-Tokens und 20 Millionen abgerechnete Ausgabe-Tokens, bei 60 % Cache-Treffern auf der Eingabeseite. Rein zur Veranschaulichung setzen wir 0,80 US-Dollar je Million nicht gecachter Eingabe-Tokens, 0,20 US-Dollar je Million gecachter Eingabe-Tokens und 2,00 US-Dollar je Million Ausgabe-Tokens an. Das sind erfundene Rechenwerte, keine aktuellen DeepSeek- oder Ofox-Preise.

Die variablen API-Kosten je Einheit betragen 40 × 0,80 + 60 × 0,20 + 20 × 2,00 = 84 US-Dollar. Hinzu kommen angenommene 16 US-Dollar Plattformgebühr pro Monat. Für den Eigenbetrieb nehmen wir 50.000 US-Dollar monatliche Fixkosten und zusätzlich 20 US-Dollar variable Kosten je Einheit an. Auch diese Annahmen sind kein reales Hardwareangebot für DeepInfer.

Unter diesen Annahmen lautet die Gleichung 84x + 16 = 50.000 + 20x, also x = 781 Einheiten pro Monat. Die Rechnung ist keine Betriebsempfehlung. Die feste Konfiguration muss diese Last bei den geforderten Latenz- und Zuverlässigkeitswerten tatsächlich bewältigen. Ist für 781 Einheiten ein weiterer Cluster nötig, müssen die Fixkosten neu berechnet werden; der scheinbare Kostenvorteil kann verschwinden.

Sinkt die Cache-Trefferrate im Beispiel von 60 % auf 20 %, steigen die variablen API-Kosten von 84 auf 108 US-Dollar je Einheit. Weniger Wiederverwendung kann auch Kosten und Kapazität des Eigenbetriebs verändern. Halten Sie nicht eine Seite künstlich konstant, um eine präzise Ersparnis zu behaupten. Rechnen Sie Monate mit geringer, erwarteter und hoher Last getrennt.

Ein Pilot muss beide Optionen ausschließen können

Ein Team, das Eigenbetrieb erwägt, sollte vor einer Produktionszusage diese Schritte durchlaufen:

1. Last und Erfolgskriterien definieren. Bewahren Sie eine repräsentative, angemessen anonymisierte Stichprobe auf. Legen Sie Qualität, Latenz, Fehlerrate und Datenanforderungen vor der Auswahl fest.
2. Plattformkompatibilität klären. Dokumentieren Sie Beschleuniger, Softwareumgebung, Checkpoint und Code-Revision. Nutzen Sie aktuelle Repository-Beispiele statt eines Installationsbefehls ohne Versionsbezug aus einem Blog.
3. Offline-Korrektheit prüfen. Führen Sie passende offizielle Beispiele und Auswertungen in dieser Umgebung aus. Halten Sie Erfolge und Fehler fest. Ein erfolgreicher Build belegt weder Ausgabequalität noch Protokollkompatibilität.
4. Den echten Dienstpfad testen. Ersetzen Sie simulierte Backends und prüfen Sie eine vollständige sowie eine gestreamte Anfrage. Bei Werkzeugen sind erzeugte Argumente und deren Ausführung in der Anwendung getrennt zu prüfen. Testen Sie ungültige Eingaben, Zeitüberschreitung, Client-Abbruch und Überlast.
5. Realistische Last messen. Berücksichtigen Sie kurze und lange Prompts, warme und kalte Caches, ruhige Phasen und Parallelitätsspitzen. Erfassen Sie erledigte Arbeit, Latenzverteilung, Fehler und alle abrechenbaren Ressourcen.
6. Mit einer gehosteten Route vergleichen. Halten Sie Modellversion und Anfrageverhalten möglichst vergleichbar. Dokumentieren Sie Unterschiede bei Quantisierung, Reasoning-Einstellungen und Funktionen, die einen fairen Vergleich begrenzen.
7. Kosten neu berechnen und entscheiden. Halten Sie einen Rückfallweg bereit und benennen Sie einen Betreiber. Verletzt eine Option eine zwingende Anforderung, kann ein günstiger Durchschnittspreis das nicht ausgleichen.

Scheitert der Pilot, ordnen Sie den Fehler ein, bevor Sie mehr ausgeben: Compilerfehler betreffen die Build-Umgebung; Speichermangel erfordert eine Analyse von Modell und Laufzeitkapazität; eine gültige simulierte Antwort ist nur ein Ergebnis des Testgerüsts; fehlerhafte Tool-Argumente verlangen eine Prüfung von Protokoll und Modellpfad. Keiner dieser Befunde beweist, dass ein anderer API-Key oder eine größere Maschine alles behebt.

Einen Weg wählen, den das Team betreiben kann

Eine gehostete API ist ein sinnvoller erster Kandidat, wenn die Nachfrage unklar ist, die Nutzung schwankt, das Team schnell liefern muss oder niemand den Beschleunigerbetrieb verantwortet. Prüfen Sie Grenzen und Bedingungen des Anbieters, statt alle gehosteten Routen als austauschbar anzusehen.

Eigenbetrieb verdient einen Pilotversuch, wenn kompatible Infrastruktur, ein Team für den vollständigen Dienst, anhaltende Last oder eine konkrete, von verfügbaren APIs nicht erfüllbare Anforderung vorhanden sind. Bestehende Hardware macht das Projekt nicht kostenlos: Ihre alternative Verwendung und die benötigten Arbeitsstunden haben ebenfalls einen Wert.

Füllen Sie vor der Entscheidung diese kurze Vorlage aus:

Aufgabe und genaue Modellversion:
Verbindliche Anforderungen an Qualität, Latenz und Daten:
Erwartete / geringe / maximale monatliche Last:
Gemessenes Cache-Verhalten und abgerechnete Tokenkategorien:
Plattform und Verantwortlicher für den Eigenbetrieb:
Gehostete Route und offene Vertrags- oder Funktionsfragen:
Spanne der monatlichen Gesamtkosten je Option:
Kapazitätsnachweise für die Schätzung:
Pilotergebnis, Rückfallweg und Entscheidungsdatum:

DeepInfer macht umfangreiche Inferenztechnik zugänglich. Eine Entscheidung für seinen Einsatz muss trotzdem zu einem betreibbaren Dienst und einer zur eigenen Last passenden Kalkulation führen. Die Open-Source-Verfügbarkeit allein belegt weder niedrigere API-Rechnungen noch die Notwendigkeit, eine funktionierende Anwendung auf ein neues Backend umzustellen.