DeepSeek hat DeepInfer veröffentlicht: Code, um sein Modell V4.1 Flash in einem Offline-Inferenzlauf auszuführen. Der dokumentierte Weg ist ungewöhnlich konkret: Linux, aktuelle Compiler- und Python-Versionen sowie entweder NVIDIA-SM100-GPUs oder Huawei-Ascend-950-NPUs. Dieser Leitfaden hilft Fachleuten zu entscheiden, ob diese Voraussetzungen erfüllt sind, den Code zu bauen und die Ausgabe des Repository-Beispiels zu prüfen. BIG CHANGE hat die Dokumentation und Quelldateien beim Commit 774ce244 geprüft; wir haben DeepInfer weder gebaut noch ausgeführt.

Die große Veränderung

  • Was sich geändert hat: DeepSeek dokumentiert jetzt neben dem gehosteten Modell und den APIs einen Weg zur lokalen Inferenz mit V4.1 Flash. Teams mit unterstützten Beschleunigern können den veröffentlichten Engine-Code prüfen und ausführen, statt für dieses Modell ausschließlich auf entfernte Anfragen angewiesen zu sein.
  • Warum das wichtig ist: Infrastrukturteams erhalten damit einen konkreten Ansatz, um die Kontrolle über einen Modelllauf, seinen Checkpoint und seine Umgebung zu bewerten. Der veröffentlichte Build und das Beispiel sind ein Ausgangspunkt für die Evaluierung; DeepSeek nennt ausdrücklich weitere Komponenten, die für einen vollständigen Inferenzdienst nötig sind.
  • Worauf zu achten ist: Ob reale Workloads damit bedient werden sollen, hängt weiterhin von einem KV-Cache-System, der Trennung von visueller Kodierung, Prefill und Decode sowie dem Lastausgleich zwischen datenparallelen Replikaten ab. DeepInfers Offline-Beispiel klärt weder diese Integrationsentscheidungen noch die Betriebskosten eines Dienstes.

Zuerst Rechner und Modell prüfen

Dieser Leitfaden richtet sich an Fachleute mit Zugang zu einem unterstützten Beschleuniger-Cluster, der Befugnis, Quellcode und Abhängigkeiten zu installieren, und der Erlaubnis, den DeepSeek-V4.1-Flash-1017-Checkpoint zu beziehen. Das Repository führt ausschließlich die DeepSeek-V4.1-Flash-Familie als unterstützt auf. Genannt werden NVIDIA-SM100-GPUs und Huawei-Ascend-950-NPUs sowie Linux, GCC 13 oder neuer und Python 3.12. NVIDIA-Builds benötigen CUDA 13, Ascend-Builds CANN 9.2. Das sind die von DeepSeek angegebenen Voraussetzungen, keine Kompatibilitätsergebnisse aus unserem Labor.

Planen Sie die Beschleuniger-Hardware, genügend Kapazität für den Checkpoint und die Kosten seines Betriebs ein. Die README enthält weder eine allgemeine Angabe zum Speicherbedarf noch eine Kostenschätzung in Dollar für das Offline-Beispiel. Der Leistungsabschnitt verweist auf Diagramme und ein Skript für Parameterdurchläufe, liefert aber keine numerische Prefill-/Decode-Tabelle als Grundlage für eine Kaufkalkulation. Prüfen Sie Kapazität und Preise für Ihre eigene Umgebung, bevor Sie Hardware beschaffen oder Cloud-Ressourcen verbindlich buchen.

Beim ersten Lauf wird der Checkpoint standardmäßig in den Hugging-Face-Cache heruntergeladen. Stattdessen lässt sich ein vorbereitetes lokales Hugging-Face-Modellverzeichnis mit config.json und Safetensors-Dateien verwenden. Laut DeepSeek benötigt dieser Weg über ein lokales Verzeichnis keinen Netzwerkzugriff zum Abrufen des Modells. Daraus folgt nicht, dass auch der erste Build, die Installation der Abhängigkeiten oder die Vorbereitung des Checkpoints offline erfolgen.

Das veröffentlichte Beispiel bauen und ausführen

Die folgenden Befehle folgen DeepSeeks README für den Einstieg und dem Beispielleitfaden. Es handelt sich um Anweisungen auf Grundlage der Dokumentation, nicht um von BIG CHANGE getestete Schritte.

  1. Umgebung prüfen. Prüfen Sie unter Linux das Beschleunigermodell sowie die GCC- und Python-Version anhand der obigen Liste. Erstellen Sie eine neue, leere Python-3.12-Umgebung und aktivieren Sie sie, bevor Sie DeepInfer installieren. Prüfen Sie, ob bei NVIDIA CUDA 13 beziehungsweise bei Ascend CANN 9.2 vorhanden ist. Brechen Sie hier ab, wenn der Rechner nicht auf der dokumentierten Unterstützungsliste steht; das Repository belegt keinen Weg für andere Plattformen.
  2. Quellcode beschaffen und Beschleuniger auswählen. Arbeiten Sie mit einem vertrauenswürdigen Checkout von DeepInfer. Für den NVIDIA-Weg muss die Beschleunigerauswahl in der Shell, die sowohl für den Build als auch für die Ausführung verwendet wird, als exportierte Variable gesetzt bleiben:
Terminal
   export DEEPINFER_ACCELERATOR=nvidia
   ./build.sh

Verwenden Sie ascend anstelle von nvidia auf unterstützter Ascend-Hardware. Das Build-Skript installiert die beschleunigerspezifischen Python-Abhängigkeiten, baut die mitgelieferten Abhängigkeiten und anschließend DeepInfer. Der NVIDIA-Weg installiert außerdem die im Skript angegebene NCCL-Paketversion erneut. Prüfen Sie das Skript und seine Abhängigkeitslisten vor der Ausführung anhand Ihrer eigenen Software-Richtlinien.

  1. Quelle des Checkpoints auswählen. Ohne abweichende Einstellung lädt das Beispiel beim ersten Einsatz deepseek-ai/DeepSeek-V4.1-Flash-1017 in den Hugging-Face-Cache. Für eine vorbereitete lokale Kopie setzen Sie DEEPINFER_HF_MODEL_DIR auf dieses Verzeichnis. Der Beispielleitfaden erklärt, dass eine explizite Angabe von --model_name Vorrang vor dieser Umgebungsvariablen hat; akzeptiert werden sowohl eine Modell-ID als auch ein lokales Hugging-Face-Checkpoint-Verzeichnis. Prüfen Sie vor dem Start das Verzeichnis und die Zugriffsrechte auf den Checkpoint.
  2. Beispiel vom Stammverzeichnis des Repositorys ausführen. DeepSeeks zentrale README verwendet:
Terminal
   python examples/offline_inference.py

Der Quellcode des Beispiels verwendet standardmäßig --ep 8 und bietet die Optionen --ep, --dp und --cp für die parallele Aufteilung. Der Beispielleitfaden zeigt beispielhafte Aufteilungen und verweist auf --help. Stimmen Sie diese Einstellungen auf die tatsächlich zugewiesenen Geräte ab; gehen Sie nicht davon aus, dass die Standardeinstellung für einen kleineren Rechner geeignet ist.

  1. Ausgabe des Beispiels prüfen. Das Skript prüft per Assertion, dass jedes Beispiel generierte Tokens mit endlichen logarithmischen Wahrscheinlichkeiten zurückgibt. Es gibt für jeden datenparallelen Rang die Eingabebeschreibung, die dekodierte Ausgabe, die Zahl der Ausgabetokens, die Annahmerate der Entwurfstokens und decode_ppl aus. Ein erfolgreicher Programmabschluss mit diesen Angaben bestätigt, dass dieses konkrete Beispiel in Ihrer Umgebung lief. Prüfen Sie den Inhalt gesondert, bevor Sie ihn als Entscheidungsgrundlage verwenden: Die Prüfungen des Skripts bescheinigen weder die Richtigkeit von Antworten noch die Zuverlässigkeit des Dienstes oder eine bestimmte Benchmark-Leistung. Die optionale Einstellung --check_structured_output führt nach den Beispielausgaben die Prüfungen des Repositorys für reguläre Ausdrücke, JSON und EBNF aus.

Nach einem fehlgeschlagenen Lauf vorgehen

Wenn der Build fehlschlägt, vergleichen Sie zuerst Plattform, Compiler, Python-Version und CUDA- beziehungsweise CANN-Version mit den Voraussetzungen des Repositorys. Prüfen Sie, ob die Python-Umgebung vor der Installation leer war und ob DEEPINFER_ACCELERATOR in der Shell gesetzt blieb. Das Build-Skript verwendet getrennte Abhängigkeitspfade für NVIDIA und Ascend; ein Build für den falschen Beschleuniger belegt keine Inkompatibilität des Modells.

Wenn beim Start Gewichte nicht gefunden oder unerwartet heruntergeladen werden, prüfen Sie, ob --model_name auf eine Modell-ID oder ein lokales Verzeichnis verweist und ob DEEPINFER_HF_MODEL_DIR auf einen vollständigen lokalen Checkpoint zeigt. Der Beispielleitfaden verlangt config.json und Safetensors im lokalen Verzeichnis. Wenn das Beispiel startet, aber eine Assertion fehlschlägt, sichern Sie den Befehl, die Umgebungsversionen und den Fehlertext zur Untersuchung. Werten Sie eine Teilausgabe nicht als erfolgreichen Inferenzlauf.

Verwenden Sie für die Evaluierung keine sensiblen Beispieleingaben. Halten Sie Checkpoints, Prompts, Ausgaben und Protokolle innerhalb der von Ihrer Organisation zugelassenen Zugriffsgrenzen und prüfen Sie heruntergeladene Abhängigkeiten und Modelldateien vor der Ausführung. Ein lokaler Modellpfad begrenzt den Modellabruf des Beispiels; er prüft für sich genommen weder den Netzwerkzugriff noch schützt er Eingaben oder macht aus dem Code einen privaten Produktionsdienst.

Was Betreibende über das Beispiel hinaus leisten müssen

DeepSeek beschreibt DeepInfer als Framework hinter seinem eigenen Dienst im großen Maßstab, bezeichnet die öffentliche Veröffentlichung aber als Offline-Inferenz. Die README erklärt ausdrücklich, dass für einen vollständigen Dienst weiterhin ein KV-Cache-System, die Entkopplung von Visual Encoder, Prefill und Decode sowie ein Lastausgleich zwischen datenparallelen Replikaten für Prefill und Decode nötig sind. Teile dieser Funktionen können in der Engine vorhanden sein; das Repository stellt jedoch keinen schlüsselfertigen gehosteten Endpunkt bereit. Die Beispielausgabe eignet sich zur Prüfung von Build und Inferenz, belegt aber weder Durchsatz noch Verfügbarkeit im Maßstab von DeepSeeks Dienst.

Dieser Leitfaden ergänzt unseren Bericht zum Update von V4.1 Flash und den Search- und Fetch-APIs. Diese APIs beantworten eine andere Frage des Zugangs. DeepInfer bietet technisch entsprechend ausgestatteten Betreibenden einen dokumentierten Weg, die Offline-Ausführung des Modells zu evaluieren. Die Wahl zwischen diesen Möglichkeiten erfordert eine eigene Bewertung von Hardware, Integration, Datenschutz und Kosten.

Quellen und weiterführende Informationen