Utiliser l’API DeepSeek hors de Chine : configuration et contrôles

Pour utiliser l’API DeepSeek hors de Chine, commencez par choisir un service compatible avec votre compte et votre lieu de déploiement. Vous pouvez évaluer la plateforme directe de DeepSeek ou une passerelle telle que Tokenhot. Dans les deux cas, il vous faut l’endpoint, une clé API émise par ce service et un identifiant de modèle réellement pris en charge par la route choisie.

Aucune valeur de latence ni règle d’inscription unique ne s’applique à tous les pays, comptes et fournisseurs. Vérifiez les options actuelles d’inscription et de paiement pour votre région avant de bâtir votre système autour d’elles. Une passerelle est une option d’accès ; elle ne permet pas d’ignorer les règles de disponibilité d’un service.

Mise à jour le 14 septembre 2026. Les exemples de code sont des points de départ fondés sur la documentation, pas des mesures de performances en direct.

Accès direct à DeepSeek ou passerelle ?

Critère	DeepSeek direct	Passerelle Tokenhot
Endpoint	https://api.deepseek.com	https://api.tokenhot.ai/v1
Identifiant	Clé de la plateforme DeepSeek	Clé de la console Tokenhot
Choix du modèle	Identifiants actuels dans la documentation API DeepSeek	Identifiant exact de la route dans le catalogue Tokenhot
Facturation	Compte DeepSeek et tarifs directs actuels	Compte Tokenhot et tarifs de passerelle affichés
Raison principale d’évaluer	Relation directe avec le fournisseur du modèle	Accès à plusieurs familles de modèles via un service

L’endpoint et la configuration du SDK sont documentés dans le guide de démarrage DeepSeek et le guide de démarrage Tokenhot. Les clés sont propres à chaque service : n’envoyez pas une clé DeepSeek à Tokenhot, ni une clé Tokenhot à DeepSeek.

Si votre compte DeepSeek existant prend déjà en charge la charge de travail, testez d’abord cette route. Si vous avez besoin d’un catalogue plus large ou d’autres modalités de compte, comparez les passerelles. Notre guide des alternatives à OpenRouter traite des questions de compatibilité et de choix du fournisseur au-delà du premier appel API.

Vérifier le nom du modèle avant de copier un ancien exemple

Le guide de démarrage actuel de DeepSeek recommande deepseek-flash. Il précise que les anciens noms deepseek-v4-flash et deepseek-v4-flash-vision-exp restent acceptés sur le service direct, mais que les requêtes utilisent désormais DeepSeek V4.1 Flash, car les anciens modèles correspondants ont été retirés. La même page indique que le service API V4 Pro continue après le 14 septembre 2026. Identifiants API DeepSeek actuels.

Un alias fonctionnel ne prouve donc pas que vous appelez un modèle inchangé. Consignez dans votre configuration de déploiement l’endpoint, le modèle demandé, les métadonnées du modèle renvoyées si elles sont disponibles et la date de vérification.

Ne supposez pas qu’une passerelle suit les mêmes alias ou le même calendrier de retrait. Sélectionnez explicitement l’identifiant qu’elle publie. Pour la version historique V4 Pro, ses benchmarks et les exigences relatives aux poids, consultez notre guide DeepSeek V4 Pro.

Effectuer un petit premier appel avec Python

Installez le SDK Python OpenAI officiel, qui prend en charge les URL de base configurables et les clients Chat Completions :

pip install openai

Pour l’accès direct, créez une clé sur la plateforme DeepSeek et définissez DEEPSEEK_API_KEY dans votre environnement. Commencez par un prompt court afin de vérifier l’authentification et le choix du modèle sans charge importante.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com",
    timeout=120.0,
    max_retries=0,
)

response = client.chat.completions.create(
    model="deepseek-flash",
    messages=[{"role": "user", "content": "Explain an API gateway in two sentences."}],
    stream=False,
)
print(response.choices[0].message.content or "")
print(response.usage)

Le délai explicite et la désactivation des nouvelles tentatives automatiques facilitent l’interprétation du premier diagnostic. Ce sont des valeurs d’exemple, pas des limites recommandées pour chaque charge. Configurez une politique de tentatives bornée après avoir compris les erreurs du service et le budget temps de votre application.

Pour Tokenhot, obtenez une clé dans la console des clés API, choisissez une route DeepSeek dans le catalogue de modèles, puis définissez TOKENHOT_API_KEY et TOKENHOT_MODEL dans l’environnement serveur. Remplacez la configuration du client et du modèle par :

client = OpenAI(
    api_key=os.environ["TOKENHOT_API_KEY"],
    base_url="https://api.tokenhot.ai/v1",
    timeout=120.0,
    max_retries=0,
)
model = os.environ["TOKENHOT_MODEL"]

Passez model=model au même appel Chat Completions de base. Choisir le modèle par configuration évite d’inscrire dans le tutoriel un alias de passerelle non vérifié. Conservez les identifiants côté serveur, hors des bundles navigateur, dépôts publics et captures de diagnostic.

Ajouter séparément le streaming et les options de raisonnement

Une fois la requête de base fonctionnelle, testez le streaming sur la route choisie. Pour un flux Chat Completions, vérifiez qu’un fragment contient un choix avant d’accéder à son contenu :

stream = client.chat.completions.create(
    model=model,
    messages=[{"role": "user", "content": "Give three checks before deploying an API client."}],
    stream=True,
)
try:
    for chunk in stream:
        if chunk.choices:
            text = chunk.choices[0].delta.content
            if text:
                print(text, end="", flush=True)
finally:
    stream.close()

Ici, client et model désignent la configuration choisie plus haut ; pour l’exemple direct, définissez model="deepseek-flash". Ce code affiche le contenu de la réponse. Ne supposez pas que chaque modèle de raisonnement place sa sortie intermédiaire dans des balises littérales <think>. N’analysez que les champs documentés pour la route et séparez les données de raisonnement auxiliaires de la réponse finale.

L’exemple direct actuel de DeepSeek emploie reasoning_effort avec un objet thinking. Cela ne prouve pas qu’une passerelle quelconque accepte la même extension ou les mêmes valeurs. N’ajoutez ces contrôles qu’après avoir consulté sa documentation. Testez aussi séparément les outils, la sortie structurée, les images et le contexte long : une interface client commune ne rend pas toutes les fonctions interchangeables.

Diagnostiquer les erreurs d’accès avant de changer de fournisseur

Une requête infructueuse ne prouve pas à elle seule un blocage réseau régional. Examinez d’abord le statut HTTP, le message du service, l’endpoint et le modèle choisi.

Symptôme	Premier contrôle
Erreur d’authentification	La clé a-t-elle été créée par le service qui reçoit la requête et est-elle encore valide ?
Solde insuffisant	Le compte API dispose-t-il de crédit utilisable pour cette route ?
Paramètre ou modèle invalide	Le modèle actuel accepte-t-il l’identifiant, le champ et la valeur envoyés ?
Limite de débit	La simultanéité ou le volume de tokens dépasse-t-il la limite du compte ?
Délai ou surcharge serveur	Une petite requête aboutit-elle, et le service signale-t-il un incident ?
Flux interrompu	La connexion s’est-elle fermée tôt, et l’application a-t-elle pris un texte partiel pour une réponse complète ?

DeepSeek documente 401 pour l’échec d’authentification, 402 pour un solde insuffisant, 422 pour des paramètres invalides, 429 pour la limitation et 500/503 pour des problèmes serveur. Les codes d’une passerelle peuvent différer. Consultez la référence d’erreurs du service concerné au lieu d’appliquer la politique de tentatives d’un fournisseur à toutes les routes. Codes d’erreur DeepSeek.

Conservez les ID de requête et des métadonnées d’erreur expurgées pour l’assistance. Ne publiez ni clé API ni prompt privé dans un ticket public. En cas d’échecs répétés, changez une seule variable à la fois : clé, modèle, corps de requête ou emplacement réseau.

Mesurer la latence depuis votre région de déploiement

Comparez les routes depuis la région serveur de l’application. Une entrée de passerelle proche peut réduire le temps de connexion, mais la génération dépend aussi de la file d’attente, de la longueur d’entrée, du calcul du modèle, du mode de raisonnement et de la longueur de sortie.

Utilisez les mêmes prompts, concurrence, réglages de sortie et plage horaire. Mesurez le temps jusqu’au premier token, le temps total, le taux de réussite et l’usage facturé. Notez si la mesure inclut l’établissement de connexion et si le raisonnement auxiliaire précède la réponse. Avec assez d’observations, publiez séparément la médiane et la latence de queue.

Pour les tâches à long contexte, utilisez des documents de taille réaliste. Une courte salutation ne mesure pas une route sur une grande base de code. Pour le streaming, testez l’interruption et l’annulation en plus d’une réponse réussie. Cet article ne promet pas universellement moins de 200 ms, car il ne contient aucun benchmark régional contrôlé.

Comparer la facture et les conditions de données de la route réelle

Utilisez le tarif actuel de l’endpoint que vous paierez. Les prix directs DeepSeek et les tarifs de passerelle Tokenhot sont des offres distinctes. Entrée en cache, entrée ordinaire, sortie de raisonnement et tarification horaire peuvent modifier le coût effectif ; notre comparaison des prix LLM API fournit un cadre de calcul reproductible.

Vérifiez les moyens de paiement et le montant minimal affichés pour votre compte avant d’ajouter des fonds. Ne supposez pas que chaque pays accepte les mêmes cartes ou portefeuilles.

Pour les charges sensibles, examinez les conditions de données de la passerelle et du fournisseur amont. Demandez quelle route traite la requête, quels journaux sont conservés et quels réglages contractuels s’appliquent. Le chiffrement du transport, une déclaration marketing sur la conservation et une évaluation de conformité répondent à des questions différentes.

Avant la mise en production

Confirmez la prise en charge du compte, le fonctionnement du modèle exact, l’achèvement d’une requête représentative et l’affichage attendu de l’usage. Testez ensuite le streaming, les erreurs, les limites et les fonctions propres au modèle. Conservez une configuration datée pour rendre visibles les changements futurs d’alias ou de prix.

Commencez par le guide Tokenhot pour la passerelle ou le guide DeepSeek pour l’accès direct, puis évaluez la route avec votre charge avant d’augmenter le trafic.