DeepSeek: Wie Sie zwischen offizieller API, veröffentlichten Gewichten und externen Anbietern entscheiden, ohne Offenheit mit operativer Kontrolle zu verwechseln

Die Entscheidungseinheit ist nicht der Name DeepSeek

DeepSeek einzuführen bedeutet nicht, mit einer einzigen Wahl zugleich Familie, Variante und Ausführungskanal festzulegen. Eine Organisation kann einen von DeepSeek betriebenen Endpoint nutzen, veröffentlichte Gewichte herunterladen und auf eigener Infrastruktur ausführen oder einen Dritten beauftragen, der ein Modell unter diesem Namen bereitstellt. Diese Optionen können Teile einer technischen Abstammung teilen, verteilen Kontrolle, Risiko und operative Verantwortung jedoch unterschiedlich.

Die erste Disziplin besteht darin, einen Handelsnamen nicht an die Stelle des technischen Inventars treten zu lassen. „DeepSeek-R1“, „DeepSeek-V3“ oder eine spätere Bezeichnung können in Ankündigungen, Repositories, Chat-Oberflächen und API-Katalogen erscheinen. Keine dieser Erscheinungsformen belegt für sich, welche Revision eine Anfrage erhält, welche Gewichte sie erzeugen, welche Inferenzkonfiguration angewendet wird oder wer die Daten verarbeitet. Bevor Fähigkeiten verglichen werden, muss das Team das genaue Objekt identifizieren, das es freigeben möchte.

Das ist besonders relevant, wenn ein API-Alias einen stabilen Namen behält. Das Änderungsprotokoll der DeepSeek-API dokumentiert Veröffentlichungen, Ausmusterungen, Alias-Umleitungen und Kompatibilitätszeiträume. Ein aufrufbarer Bezeichner ist daher möglicherweise keine Garantie dafür, dass das zugrunde liegende Modell unverändert bleibt. Das ist nicht grundsätzlich ein Mangel: Es kann verwaltete Aktualisierungen erleichtern. Es zwingt jedoch zur Entscheidung, ob das Produkt eine vom Betreiber aktualisierte Fähigkeit oder eine festgelegte und reproduzierbare Version benötigt.

Die richtige operative Frage lautet: „Welches Modell oder welcher Dienst, betrieben von wem, unter welchen Bedingungen und mit welchen Nachweisen wird für diese konkrete Funktion verwendet?“ Das Organisationsverzeichnis kann helfen, das Profil von DeepSeek zu finden, und der Vergleichsbereich kann Alternativen einordnen. Die Entscheidung muss jedoch für jeden Zugriffskanal eigene Nachweise festhalten.

Inventar der Zugriffsmöglichkeiten und der Nachweise zu ihrer Identifikation

Die offizielle API ist ein Remote-Dienst. Das Team nutzt eine Schnittstelle, einen Modellbezeichner und Plattformbedingungen, während die Inferenzinfrastruktur unter der Kontrolle des Betreibers bleibt. Mögliche Vorteile sind ein geringerer eigener Betriebsaufwand und verwaltete Änderungen; dem stehen Abhängigkeiten von Verfügbarkeit, Limits, Dienstentwicklung und den an den Endpoint gesendeten Informationen gegenüber.

Veröffentlichte Gewichte sind ein Artefakt, das eine Organisation beziehen und auf von ihr kontrollierter Infrastruktur ausführen kann, sofern sie die einschlägige Lizenz einhält. Diese Kontrolle kann helfen, eine Revision festzuschreiben, Netzwerke einzuschränken, eine Region zu wählen und die Aufbewahrung von Logs festzulegen. Sie umfasst jedoch nicht automatisch einen Produktionsdienst: Inferenz, Authentifizierung, Observability, Skalierung, Evaluierung, Incident Response und das Management von Schwachstellen müssen aufgebaut oder eingekauft werden.

Ein externer Anbieter fügt eine weitere Schicht hinzu. Er kann eine bestimmte Region, integrierte Abrechnung, Netzwerkkontrollen, Metriken oder kommerziellen Support anbieten. Er kann jedoch auch eine angepasste oder quantisierte Variante bereitstellen, über einen Alias routen oder diese im Laufe der Zeit ersetzen. Seine Aussage über API-Kompatibilität oder die Verfügbarkeit eines DeepSeek-Modells beweist weder Identität mit dem offiziellen Dienst noch mit einem veröffentlichten Checkpoint.

Das erste Inventar sollte für jeden Fall Kanal, Betreiber, den dem Nutzer angezeigten Namen, den in der Anfrage gesendeten Bezeichner, Beobachtungsdatum, Umgebung, Client-Version und Dokumentationsquelle erfassen. Bei Gewichten müssen außerdem Repository, überprüfbare Revision oder Hash, Format, Konvertierungsmethode und Inferenzkonfiguration aufgenommen werden. Ohne dieses Register lässt sich ein späterer Vorfall nicht belastbar einer Modell-, Infrastruktur- oder Anwendungsänderung zuordnen.

Lizenzen: Gewichte, Code und Dienst sind getrennte Ebenen

Die Lizenz des Codes darf nicht als Zusammenfassung der Rechte an den Gewichten verwendet werden. Im Repository von DeepSeek-V3 steht die Codelizenz unter MIT, während die Modelllizenz spezifische Bedingungen für das Modell enthält. Dieser dokumentarische Unterschied ist entscheidend: Eine weitreichende Erlaubnis für Code beseitigt nicht Pflichten, Hinweise, Einschränkungen oder Bedingungen, die das Modellartefakt betreffen können.

Die Lizenz des V3-Modells enthält Bedingungen zu Nutzung, Hosting oder Weiterverbreitung, zur Beibehaltung von Hinweisen und zu abgeleiteten Werken. Verantwortliche für Einkauf oder Compliance sollten diese Beschreibung nicht in eine vereinfachte rechtliche Schlussfolgerung verwandeln. Sie müssen die auf das herunterzuladende Artefakt anwendbare Fassung lesen, mit der Akte aufbewahren und klären, ob Vertriebsform, Endanwendung und Änderungen konkrete Pflichten auslösen.

Eine Lizenz darf ebenso wenig mit Support verwechselt werden. Eine Lizenz kann bestimmte Nutzungen eines Checkpoints erlauben, ohne Verfügbarkeit eines Endpoints, Sicherheitskorrekturen, ein Service-Level, Werkzeugkompatibilität, Incident Response oder die Fortführung einer Variante zuzusagen. Umgekehrt regelt ein API-Vertrag eine Plattformbeziehung und macht seine Nutzer nicht automatisch zu Vertreibern von Gewichten.

Die Nutzungsbedingungen der offenen Plattform beschreiben den Rahmen für die Entwicklerplattform und weisen Entwicklern Verantwortung für ihre Anwendungen und nachgelagerten Nutzer zu. Das verlangt eine gemeinsame Prüfung durch Engineering, Sicherheit, Datenschutz, Einkauf und Rechtsberatung. Dieser Artikel ersetzt diese Prüfung nicht: Die konkrete Anwendbarkeit hängt vom Artefakt, Land, der Architektur und der Vertragsbeziehung ab.

Offizielle API: Den Integrationsvertrag kontrollieren, nicht nur den Aufruf

Bei einer Integration über die offizielle API ist das Modell nur ein Teil der Abhängigkeit. Authentifizierung, Quoten, Rate Limits, Kontextfenster, Antwortformate, Werkzeugkompatibilität, Fehlerbehandlung und Verhalten bei Wiederholungen müssen überprüft werden. Der Test sollte mit dem Bezeichner erfolgen, der in Produktion verwendet wird, und mit repräsentativer Last, nicht nur mit einer erfolgreichen manuellen Unterhaltung.

Das Änderungsprotokoll ist eine zentrale operative Quelle, weil es Änderungen bei Veröffentlichung, Ausmusterung und Kompatibilität publiziert. Seine Prüfung sollte in den Change-Management-Prozess aufgenommen werden. Wenn die Anwendung von einem Alias abhängt, muss die Akte festhalten, dass das effektive Modell geändert werden kann. Wenn Reproduzierbarkeit erforderlich ist, sollte der Betreiber nach einem dokumentierten Mechanismus zum Festschreiben einer Version gefragt werden. Gibt es keinen solchen Mechanismus, sind das Produktversprechen einzugrenzen und Testergebnisse nach Datum aufzubewahren.

Die Bedingungen der offenen Plattform sind wichtig, um Verantwortlichkeiten des Entwicklers abzugrenzen. Die Datenschutzrichtlinie von DeepSeek beschreibt verarbeitete Datenkategorien, einschließlich Nutzereingaben und Daten im Zusammenhang mit Zahlungen auf der offenen Plattform, sowie Speicherung und Verarbeitung. Diese Dokumentation ist nützlich, um eine Prüfung zu eröffnen. Sie reicht jedoch nicht aus, um exklusives Isolieren, einen konkreten Speicherort, für jeden Kontotyp geltende Aufbewahrungsfristen, eine Nutzung zum Training oder nicht ausdrücklich dokumentierte vertragliche Garantien abzuleiten.

Ein Team, das interne Informationen, Kundendaten oder regulierte Daten senden will, muss deshalb Veröffentlichtes von Garantiertem trennen. Über den passenden kommerziellen oder rechtlichen Weg sollte es schriftliche Antworten zur Verarbeitung, zu Standorten, Aufbewahrung, Unterauftragsverarbeitern, Vorfallbenachrichtigung, Löschung, Zugriffskontrollen und anwendbaren Anhängen einholen. Bis dahin müssen Datenklassifikation und ein auf Datenminimierung ausgerichtetes Design von Unsicherheit ausgehen.

Eigene Gewichte: mehr technische Kontrolle, größerer Verantwortungsbereich

Der Betrieb eigener Gewichte kann einen direkteren Weg bieten, eine Revision einzufrieren und den Ausführungsort festzulegen. Diese Aussage gilt jedoch nur, wenn das genaue Artefakt aufbewahrt, seine Kennungen überprüft und die gesamte Deployment-Kette kontrolliert wird. Ein Repository anhand seines Namens herunterzuladen, ein bewegliches Tag zu verwenden oder ein Container-Image ohne dokumentierte Herkunft zu akzeptieren, ist keine Reproduzierbarkeit.

Das Team übernimmt Aufgaben, die bei einer API der Betreiber verwaltet: Auswahl und Pflege der Inferenz-Engine, Hardware-Kompatibilität, Quantisierung, Parallelisierung, Gleichzeitigkeit, Schutz von Geheimnissen, Eingabefilterung, Ereignisprotokollierung, Backups, Aktualisierung von Abhängigkeiten, Observability und Incident Response. Zudem muss es Änderungen bewerten, die durch Chat-Vorlagen, Decodierungsparameter, angebundene Werkzeuge und eigene Sicherheitsschichten entstehen. Zwei Installationen mit denselben Gewichten können unterschiedlich antworten.

Die Offenheit eines Artefakts belegt für sich auch nicht dessen Sicherheit für einen Anwendungsfall. Die für diese Analyse verfügbaren Quellen enthalten weder eine vertragliche Sicherheitsgarantie noch eine System Card, aus der sich eine vollständige Bewertung je Familie ableiten ließe. Das Fehlen solcher öffentlichen Nachweise beweist nicht, dass das Modell unsicher ist. Es bedeutet, dass nicht behauptet werden darf, es erfülle ein bestimmtes Niveau, ohne unabhängige Tests und vom Übernehmer definierte Kriterien.

Die Evaluierung muss den tatsächlichen Anwendungsfluss einbeziehen. Es genügt nicht, eine Referenzaufgabe oder eine globale Trefferquote zu messen. Erforderlich sind Tests zu Instruktionslecks, unerwünschten Inhalten, Datenextraktion, Werkzeugmissbrauch, Degradation unter Last, Wiederherstellung nach Neustart und Regressionen zwischen Revisionen. Produktionsentscheidungen sollten von dokumentierten Schwellenwerten und einer verantwortlichen Person abhängen, die das Restrisiko akzeptiert.

Externe Anbieter: Die zusätzliche Ebene bewerten, ohne Identität anzunehmen

Ein externer Anbieter kann sinnvoll sein, wenn er eine vom Team benötigte Bedingung bietet, etwa zentralisierte Abrechnung, eine Bereitstellungszone, private Konnektivität, Observability oder Support. Diese Fähigkeiten müssen als Eigenschaften dieses Anbieters validiert werden, nicht als inhärente Eigenschaften von DeepSeek. Ebenso überträgt sich eine Zusage des Dritten nicht automatisch auf die offizielle API, veröffentlichte Gewichte oder einen anderen Wiederverkäufer.

Die Mindestprüfung beginnt mit der Identifikation der Stelle, die die Anfrage empfängt, verarbeitet und den Dienst abrechnet. Danach sollten deklarierte Variante, Versionierungsmechanismus, Ersetzungsregeln, anwendbare Infrastruktur oder Region, Log-Richtlinie, Datenverarbeitung, Unteranbieter, Support und der Prozess für Änderungsbenachrichtigungen erfragt werden. Wenn die Antwort sich auf ein kommerzielles Label beschränkt, muss die Version als nicht verifiziert eingestuft werden.

Protokollkompatibilität beschreibt nur eine Schnittstelle. Ein kompatibler Endpoint kann eine ähnliche Anfragestruktur annehmen und dennoch eine andere Version, Quantisierung oder Vorlage anwenden, andere Limits besitzen oder auf mehr als ein Backend routen. Ohne Test und Erklärung des Betreibers darf auch nicht angenommen werden, dass er denselben Checkpoint und dieselbe Konfiguration wie ein anderer Endpoint bereitstellt.

Bei der Beschaffung sollten Dokumentenprüfung und Messung kombiniert werden. Führen Sie Regressionstests aus, bewerten Sie Limits und Antwortzeiten, prüfen Sie den zulässigen Export von Logs und simulieren Sie eine Ausmusterung oder Modelländerung. Wenn die Anwendung Funktionen, Werkzeuge oder strukturierte Ausgabe nutzt, testen Sie diese mit adversarialen Eingaben und partiellen Fehlern. Ziel ist nicht, eine abstrakte Gleichwertigkeit zu beweisen, sondern festzustellen, ob der eingekaufte Dienst die deklarierten Anforderungen erfüllt.

Nutzungsklassifikation und Änderungsregister

Die Freigabe sollte nicht binär sein. Ein Kanal kann für Exploration ausreichen und für Produktion ungeeignet sein. Für ein Experiment können ein kontrolliertes Konto, synthetische Daten, ein Funktionstest und eine Notiz der Unsicherheiten genügen. Für eine begrenzte interne Nutzung kommen Datenklassifikation, Zugriffskontrollen, Risikobewertung und Änderungsüberwachung hinzu. Bei kundenorientierter Produktion steigen die Anforderungen: Kontinuitätsarchitektur, operative Eigentümerschaft, gegebenenfalls vertragliche Nachweise, Sicherheitstests und ein Rückfallmechanismus.

Das Änderungsregister muss ein lebendes Artefakt sein, keine Notiz in einer Präsentation. Bewahren Sie für jedes Deployment Zugriffskanal, Betreiber, aufgerufenen Bezeichner, deklarierte Familie und Variante, Revision oder Hash, sofern vorhanden, Datum, relevante Konfiguration, Client-Version, bekannte Region, beobachtete Limits, Evaluierungssuite und Ergebnisse auf. Ergänzen Sie eine explizite Entscheidung über akzeptierte Unsicherheiten.

Diese Disziplin ermöglicht es, spätere Fragen präzise zu beantworten: ob sich eine Ausgabe verändert hat, der Endpoint geändert wurde, die Anwendung ihre Vorlage änderte, ein Gewicht aktualisiert wurde oder eine Abhängigkeit ausgefallen ist. Sie verhindert außerdem, dass die Organisation DeepSeek eine Eigenschaft zuschreibt, die zum externen Anbieter oder zur eigenen Umgebung gehört. Offenheit kann Bereitstellungsoptionen erweitern, ersetzt jedoch weder Konfigurationsmanagement und Evaluierung noch die Verantwortung derjenigen, die das Endprodukt liefern.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.