DeepInfer ist offen, doch der API-Dienst muss noch verbunden werden
Ein Server mit der Antwort „Hello world!“ kann ein funktionierendes Antwortformat zeigen, ohne dass ein Modell lief. Genau das macht DeepSeeks Veröffentlichung interessant: Der API-Beispielserver von deepseek-recipe verwendet ausdrücklich Mock-Inferenz. Die eigentliche Engine steckt in DeepInfer. Beide zu einem verlässlichen Dienst zu verbinden bleibt Entwicklungsarbeit.
DeepSeek stellte DeepInfer am 20. Oktober als Grundlage seines großen V4.1-Flash-Dienstes vor. Die öffentliche Version ist enger gefasst: Offline-Inferenz, mit einer Liste fehlender Dienstkomponenten. Die Protokollbibliotheken machen diese Grenze prüfbar, beseitigen sie aber nicht. Wir haben feste Codeversionen gelesen, keinen Beschleuniger-Stack gebaut, keine Gewichte ausgeführt und keine Leistung reproduziert. Für Entwickler geht es um zugängliche Implementierungsentscheidungen, nicht um bereits gemessene Einsparungen ihrer Anwendung.
Die Engine endet vor dem vollständigen Dienst
Unterstützt werden V4.1-Flash, NVIDIA SM100 und Huawei Ascend 950. Linux, Python 3.12 und passende CUDA- oder CANN-Versionen sind Voraussetzungen. Das ist kein allgemeiner Starter für beliebige vorhandene Hardware.
Es fehlen ein KV-Cache-System, die Trennung von Bildencoder, Prefill und Decode sowie Lastverteilung zwischen datenparallelen Replikaten. KV-Cache hält Attention-Zustand früherer Tokens; Prefill verarbeitet die Eingabe, Decode erzeugt weitere Ausgabe. Getrennte Stufen erlauben unterschiedliche Ressourcenzuteilung. Laut Projekt sind viele nötige Engine-Funktionen vorhanden, die vollständige Dienstanordnung aber nicht.
Ein hypothetisches Team mit externer API könnte durch einen erfolgreichen Offline-Lauf zeigen, dass ein Auftrag auf seiner Konfiguration funktioniert. Gleichzeitige Zugriffe, Abbruch, Cache-Platzierung und Ausfälle bleiben offen. Infrastrukturteams können den Code direkt untersuchen; Anwendungsteams ohne Cluster können Anbietern genauere Fragen stellen. Codezugang und Betriebsfähigkeit sind getrennte, beide wertvolle Meilensteine.
Durchsatz hängt von der Zählung der Entwurfstokens ab
Spekulatives Dekodieren schlägt Tokens vor und prüft, welche übernommen werden. Die Beispieldokumentation trennt Prefill-Durchsatz, Decode-Schritte pro Sekunde und Tokendurchsatz. Eine Zählweise unterstellt vollständige Annahme der Vorschläge. Mehrere vorgeschlagene Tokens sind noch keine gleich große tatsächliche Ausgabe.
Der Plotcode verwendet bei fester Entwurfslänge 1 + nextn × draft_acceptance. Ein vorgegebener Annahmewert wird in einen angenommenen Tokenbeitrag übersetzt. Der variable Modus wird ausgeschlossen, weil seine Schrittrate das Annahmeverhalten schon enthält. Nochmals anzupassen würde doppelt zählen.
Geschätzter Durchsatz, tatsächlich angenommene Tokens und Zeit bis zur brauchbaren Antwort unterscheiden sich. Eingabelänge, gecachter Präfix, Batch und Entwurfsmodus gehören zur Zahl. Die Hauptgrafiken nutzen vier SM100 für Prefill und 64 für Decode, jeweils in einer Scale-up-Domäne. Vier Geräte liefern deshalb nicht automatisch beide Kurven. Die Sweep-Skripte sind ein Reproduktionsweg, kein Ergebnis unseres Tests.
Eine Anwendung sollte zudem akzeptable abgeschlossene Antworten zählen. Schnelle Streams mit wiederholten Werkzeugformatfehlern können Nutzer länger warten lassen. Ressourcenverhalten und Produktergebnis müssen getrennt gemessen werden.
Wiederholbarkeit braucht mehr als einen Seed
Batch-invariante Inferenz auf NVIDIA soll Ergebnisse bei veränderten Nachbaranfragen erhalten. Deterministisches Sampling verlangt zusätzlich einen festen Sequenzseed und deaktiviertes variables MTP. Das ist eine Konfiguration, keine allgemeine Garantie durch einen einzelnen Seed.
Für Regressionen gehören Modell- und Engine-Version, tokenisierte Eingabe, Sampling und Ausführungsparameter ins Protokoll. Ändert eine fremde Batch-Anfrage das Ergebnis, reicht ein Vergleich des Prompttexts nicht.
Wiederholbare Fehler bleiben Fehler. Auch gültiges JSON kann falsche Fakten enthalten. Das Strukturbeispiel kombiniert Aufforderungen zu freien Geschichten mit Regex-, JSON- und Grammatikgrenzen. Es prüft Formtreue, keine zukünftige Geschäftsentscheidung. Backend-Verhalten, Client-Parsing und Nützlichkeit sollten getrennt geprüft werden, damit nicht jeder Fehler als Modellqualität endet.
Protokollkonvertierung führt weder Modell noch Werkzeug aus
Die recipe-Dokumentation beschreibt Rust-Bibliotheken und Python-Bindings, die Anfragen in eine gemeinsame Gesprächsform bringen, Prompts rendern und Ausgaben zurückkonvertieren. Inferenz, Werkzeugausführung und HTTP liefert der Aufrufer.
Recipe wählt auch Ausgabebeschränkungen, doch der Aufrufer entscheidet, ob das Backend diese durch eingeschränktes Dekodieren erzwingt. Ein JSON-Schema im Prompt ist nicht schon die Verbindung zur Engine-Beschränkung. Ähnliche Felder können fehlende Semantik verdecken.
Bei einem hypothetischen Terminassistenten reserviert eine geparste Buchungsanfrage noch keinen Termin. Die Anwendung prüft Argumente, ruft das Buchungssystem auf und führt dessen Ergebnis ins Gespräch zurück. Das ist eine Rollenbeschreibung, kein getestetes Integrationsprojekt. Prüfen Sie bei Migrationen auch Denkparameter, Endgründe und Schema-Durchsetzung; eine normale Textantwort beantwortet diese Fragen nicht.
Ein überzeugender Stream kann weiterhin simuliert sein
Der Streaming-Leitfaden wandelt Inferenzchunks in Protokollchunks um und verwendet simulierte Ereignisse. Python verarbeitet einzelne Chunks und schließt die Antwortverarbeitung ab. So lässt sich der Adapter ohne Cluster untersuchen.
Der Rust-Beispielserver bietet drei Formate, JSON und SSE, antwortet aber ohne Gewichte mit einem simulierten Gruß. Er hat keine Authentifizierung und filtert beim Bildabruf keine privaten Adressen; die Dokumentation begrenzt ihn auf Loopback. Das beschreibt das Beispiel, keinen Vorfall im gehosteten Dienst.
Ein Browserstream belegt nur den ausgeübten Pfad. Ereignisse, Tokenverbrauch und Abschluss müssen noch mit realer Inferenz verbunden werden. Nach Verbindungsabbruch das Rechnen zu stoppen ist etwas anderes, als die Anzeige zu stoppen. Auch nach einer verlorenen Buchungsantwort muss die Anwendung den externen Reservierungszustand kennen, bevor sie erneut handelt. Der Konverter kann diesen Ausgang nicht selbst feststellen.
Trennen Sie die ersten Untersuchungen
Der Evaluationsleitfaden trennt Erzeugung und Bewertung, bewahrt Rohantworten und erlaubt einen anderen Bewerter ohne Neugenerierung. Pass@1 setzt vollständige Abdeckung voraus. Modellbewerter können stochastisch sein, feste Extraktionsregeln nicht; HLE erlaubt nur den Modellbewerter. Wiederholbares Dekodieren macht dessen Urteil nicht deterministisch.
Mit geeigneter Hardware beginnt man mit einer Offline-Basis samt Einstellungen und prüft anschließend Protokollverhalten. Ein Team, das einen Anbieter bewertet, kann entsprechende Belege anfordern, ohne eigenen Clusterbetrieb vorzugeben.
| Untersuchung | Passender Beleg |
|---|---|
| Engine | Echte Ausgabe auf benannter Hardware, Gewichten und Revision |
| Durchsatz | Eingabe, Cache, Batch, Entwurfsmodus und Zählkonvention |
| Protokoll | Bedeutung, Beschränkung, Streamende und Verbrauch |
| Anwendung | Externer Zustand auch nach Abbruch oder Wiederholung |
NxCode-Entwickler sollten zuerst klären, welche dieser Fragen sie verantworten. Ein API-Nutzer muss nicht den ganzen Anbieter nachbauen. Ein Selbsthoster kann den Dienst nicht überspringen, weil Offline-Inferenz lief. DeepInfer und recipe öffnen verschiedene Grenzen. Ein tragfähiger Einsatz verbindet reale Engine-Ergebnisse mit realem Dienstverhalten, statt einen simulierten Gruß für beides zu nehmen.
