Wenn Teams in China über die DeepSeek API sprechen, reduziert sich die Frage oft auf „Kommt die Verbindung zustande?“. Für den Produktivbetrieb zählen jedoch vier Dinge: ein stabiles Netz, funktionierende Zahlung und Rechnungsstellung, akzeptable Drosselung zu Spitzenzeiten und ein Ausweichkanal bei Störungen. Fehlt auch nur einer dieser Punkte, ist „es verbindet“ ohne Belang.

Dieser Artikel vergleicht drei übliche Wege: die offizielle Direktverbindung, einen selbst betriebenen Proxy und ein inländisches AI-Gateway. Dazu kommen Timeouts, Wiederholungen, Degradation und ein Verfahren zur Validierung. Maßgeblich für Modelle, Preise und Zugangswege sind die Modellpreise und die Angaben auf der Plattform.

Hinweis: DeepSeek ist eine Marke ihres jeweiligen Inhabers. Der Beitrag beschreibt die übliche Situation im Oktober 2026. Netzwerkumgebung und Nutzungsbedingungen können sich ändern; maßgeblich sind die offizielle Dokumentation und die lokalen Vorschriften.

1. Drei Wege in einer Tabelle

Dimension Offizielle Direktverbindung Eigener Proxy Inländisches AI-Gateway
Einstieg Offizielle DeepSeek-Adresse Weiterleitung über eigenen Server Einheitlicher OpenAI-kompatibler Einstieg
Zahlung Über die offiziell unterstützten Kanäle Zuerst Server und Bandbreite bezahlen Aufladung auf der Plattform, Regeln laut Seite
Modellauswahl Nur DeepSeek Abhängig von der Proxy-Konfiguration Mehrere Anbieter, je nach Freischaltung
Verantwortung für Stabilität Anbieter und lokales Netz Vollständig beim Team Geteilt zwischen Dienstleister und Team
Betriebsaufwand Niedrig Hoch Mittel
Geeignet für Ein Modell, geringe Frequenz, stabiles Netz Teams mit Netzwerkbetrieb Mehrere Modelle, Rechnungen, einheitliche Abrechnung

Kein Weg passt für alle. Die sinnvolle Prüfreihenfolge lautet: Zuerst klären, ob Ausfälle im Geschäft tolerierbar sind, dann, ob mehrere Modelle und Rechnungen benötigt werden, und zuletzt, ob das Team Betriebspersonal für den Proxy hat.

2. Offizielle Direktverbindung: Wann sie ausreicht

Die Direktverbindung passt, wenn nur DeepSeek aufgerufen wird, das Aufrufvolumen stabil ist, das lokale Netz den Zugang zuverlässig erreicht, die offizielle Aufladung möglich ist und das Geschäft langsamere Antworten zu Spitzenzeiten akzeptiert. Die Anbindung ist nicht kompliziert:

  1. Im DeepSeek Open Platform einen API Key erstellen und nach Projekt benennen.
  2. Den Key in eine serverseitige Umgebungsvariable legen, nicht in Frontend oder Repository.
  3. Mit curl eine minimale Anfrage durchführen und Base URL sowie Modellnamen bestätigen.
  4. Im SDK Verbindungs-Timeout, Lese-Timeout und maximale Wiederholungen setzen.
  5. Bei jeder Anfrage Modell, Token, Laufzeit und Fehlertyp protokollieren.
export DEEPSEEK_API_KEY="sk-IHR_KEY"

curl "https://api.deepseek.com/chat/completions" \
  -H "Authorization: Bearer $DEEPSEEK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-chat",
    "messages": [{"role": "user", "content": "Antworte nur mit OK"}],
    "max_tokens": 16
  }'

Wenn dieser Befehl gelegentlich in einen Timeout läuft, über ein anderes Netz aber funktioniert, liegt die Ursache meist am lokalen Ausgang oder an DNS, nicht am Key. Zuerst Zeitpunkt und Fehlermeldung sichern, dann entscheiden, ob die Leitung gewechselt werden muss.

3. Eigener Proxy: löst den Netzausgang, nicht die Kapazität

Üblich ist ein Reverse Proxy auf einem Server, der die offizielle Schnittstelle erreicht und Anfragen an DeepSeek weiterleitet. Das löst einen Teil der Probleme mit instabilem lokalem Netz, bringt aber neue Arbeit mit sich:

  • Der Proxy ist ein einzelner Ausfallpunkt; fällt er aus, scheitern alle Anfragen gemeinsam.
  • TLS, Authentifizierung und Zugriffskontrolle müssen eingerichtet werden, damit der Proxy nicht missbraucht wird.
  • Logs, Rate Limiting und Monitoring sind nötig, sonst lässt sich bei Problemen nichts eingrenzen.
  • Eine zusätzliche Weiterleitung erhöht die Latenz; die Zeit bis zum ersten Token beim Streaming kann steigen.
  • Netz- und Compliance-Verantwortung bleiben beim Team.

Ohne Personal für die dauerhafte Pflege wird aus dem Proxy schnell eine „Übergangslösung“, die zur langfristigen Belastung wird. Als Zwischenschritt ist er brauchbar, als einziger Einstiegspunkt nicht empfehlenswert.

4. AI-Gateway: viele Modelle und Instabilität an einem Eingang bündeln

Der Nutzen eines inländischen AI-Gateways liegt nicht nur in der Weiterleitung, sondern darin, Key-Verwaltung, Aufladung, Abrechnung, Modellwechsel und Störungsbehandlung an einer Stelle zusammenzuführen. Für Teams mit mehreren Modellen ändert sich vor allem eines: Der Anwendungscode kennt nur einen OpenAI-kompatiblen Einstieg; beim Modellwechsel wird die Konfiguration geändert, nicht der Code.

export ZSQH_API_KEY="sk-IHR_KEY"

curl "https://ai.zhongshangqihang.com/v1/chat/completions" \
  -H "Authorization: Bearer $ZSQH_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-chat",
    "messages": [{"role": "user", "content": "Erkläre die Aufgabe eines Gateways in einem Satz"}],
    "max_tokens": 128
  }'

Bei der Auswahl eines Gateways sollten fünf Punkte geklärt werden: ob die benötigten Modelle unterstützt werden, ob klare Regeln für Abrechnung und Aufladung bestehen, ob Nutzungsdetails verfügbar sind, wie bei Störungen informiert wird und ob die Datenklauseln die eigenen Compliance-Anforderungen erfüllen. „Der Aufruf funktioniert“ allein genügt nicht.

5. Stabilität muss der Client selbst absichern: Timeout, Retry, Degradation

Unabhängig vom Weg braucht der Client Schutzmechanismen. Empfohlene Reihenfolge:

  1. Verbindungs- und Lese-Timeout getrennt setzen: Verbindungs-Timeout kurz, Lese-Timeout länger; lange Texte und Reasoning-Aufgaben separat konfigurieren.
  2. Wiederholungen mit Backoff: Nur bei 429, 5xx und Timeouts wiederholen, exponentielles Backoff mit Zufallsanteil und eine Obergrenze.
  3. Nebenläufigkeit begrenzen: Batch-Aufgaben über eine Queue glätten und nicht zur vollen Stunde gemeinsam starten.
  4. Ausweichmodell vorbereiten: Kernprozesse dürfen auf ein Ersatzmodell oder einen Ersatzkanal wechseln, müssen aber Abweichungen bei der Ausgabe akzeptieren.
  5. Circuit Breaker einbauen: Nach einer Fehlerschwelle Anfragen pausieren, um eine Wiederholungslawine zu vermeiden.
  6. Idempotenz sicherstellen: Bei Aufgaben mit Nebenwirkungen zuerst den Status prüfen, dann erneut senden.
import httpx
from openai import OpenAI

client = OpenAI(
    api_key="sk-IHR_KEY",
    base_url="https://ai.zhongshangqihang.com/v1",
    timeout=httpx.Timeout(connect=5.0, read=120.0, write=30.0, pool=10.0),
    max_retries=2,
)

Für Timeout-Werte gibt es keinen einheitlichen Standard; sie richten sich nach der Toleranz des Geschäfts und der Aufgabenlänge. Entscheidend ist, Anfragen nicht unbegrenzt warten zu lassen und nach einem Fehler nicht sofort parallel erneut zu senden.

6. Eine Woche zur Validierung eines Zugangswegs

Kennzahl Erfassung Worauf achten
Erfolgsquote Anteil der Antworten ungleich 200 Konzentriert sich das Problem auf Spitzenzeiten?
Latenz p50, p95 und Zeit bis zum ersten Token Beeinflusst die Tail-Latenz die Erfahrung?
Drosselung Anzahl und Zeitpunkte von 429 Kontingentproblem oder Verkehrsspitze?
Netzfehler DNS, TLS, Verbindungs-Timeouts Lokaler Ausgang als Ursache?
Qualität Manuelle Stichprobe eines festen Aufgabensatzes Bleibt die Ausgabe nach dem Wechsel gleich?

Die Validierung sollte mindestens eine Spitze an einem Werktag und eine ruhige Nachtphase abdecken. Täglich zur gleichen Zeit dieselben Anfragen über sieben Tage sind aussagekräftiger als ein einzelner Lasttest.

7. Zahlung, Rechnung und Compliance

  • Teams, die Zahlung auf Firmenrechnung benötigen, klären vorab Rechnungsregeln und Gutschriftzeitpunkt des Dienstleisters.
  • Bei Kundendaten zuerst die Datenklauseln lesen und prüfen, ob Eingaben gespeichert oder zur Serviceverbesserung verwendet werden.
  • Keys nach Umgebung trennen; Produktions-Keys gehören weder ins Frontend noch in öffentliche Repositories.
  • Aufrufprotokolle und Abrechnungen aufbewahren, um Buchhaltung und Sicherheitsaudit zu erleichtern.
  • Grenzüberschreitende Übertragung und branchenspezifische Vorgaben nach lokalem Recht und internen Compliance-Prozessen prüfen.

Häufige Fragen

Ist die DeepSeek-Direktverbindung in China stabil?

Das hängt vom lokalen Netz, der Tageszeit und der Auslastung des Anbieters ab; eine pauschale Antwort gibt es nicht. Produktionssysteme sollten sich nicht auf eine einzige Leitung verlassen und mindestens Timeouts, Wiederholungen und einen Ausweichkanal vorsehen.

Ist ein Gateway langsamer?

Eine zusätzliche Weiterleitung kann etwas Latenz kosten, ein Gateway bietet aber häufig einen stabileren Einstieg und Failover. Messen Sie dieselben Anfragen über Direktverbindung und Gateway und vergleichen Sie p95 und Erfolgsquote statt einer einzelnen Anfrage.

Ist ein eigener Proxy für jedes Team geeignet?

Nein. Er erfordert laufenden Netzwerkbetrieb, Sicherheitskonfiguration und Monitoring. Ohne dediziertes Personal wird der Proxy selbst zum neuen Ausfallpunkt.

Kann ein Key mehrere Modelle aufrufen?

Im Gateway-Modell ist das meist möglich; das Modell wird in der Anfrage angegeben, der genaue Umfang steht auf der Preisseite und im Kundenportal. Ein Key der offiziellen Direktverbindung erreicht nur die dort freigegebenen Modelle.

Wie erkennt man, ob das Problem lokal oder upstream liegt?

Zuerst eine minimale Anfrage senden, dann nacheinander Netz, Key und Einstiegspunkt wechseln. Zeitpunkt und Fehlermeldung festhalten; so lassen sich DNS, TLS, Authentifizierung, Drosselung und Upstream-Störung schnell unterscheiden.

Nächster Schritt

Erstellen Sie zuerst im ZSQH AI Gateway einen Test-Key und vergleichen Sie mit denselben Anfragen Erfolgsquote und Latenz von Direktverbindung und Gateway, bevor Sie über die Produktionsleitung entscheiden. Modelle und Preise stehen in den Modellpreisen.

Weiterlesen: