DeepSeek vend désormais la puissance de calcul à la seconde : votre modèle de coûts va changer

Ce qui vient d'être lancé

DeepSeek a ouvert un niveau public de calcul élastique, baptisé en interne DSec, qui facture les charges d'inférence à la seconde et ramène la capacité active à zéro lorsqu'aucune requête n'est en cours. Pour les opérateurs qui font tourner des modèles DeepSeek sur leur propre infrastructure, ou qui passent par l'API hébergée de DeepSeek, c'est une attaque frontale contre le plus gros coût caché de l'IA en production : le temps GPU que vous payez pendant que votre modèle attend.

L'annonce, parue à la mi-2026, a immédiatement retenu l'attention de la communauté de l'infrastructure, car elle reprend ce que les hyperscalers du cloud proposent depuis des années pour les fonctions serverless, mais appliqué à l'inférence des grands modèles de langage, où la latence de démarrage à froid a longtemps rendu le véritable passage à zéro impraticable.

Pourquoi c'était difficile jusqu'ici

Faire tourner un grand modèle de langage n'a rien à voir avec l'exploitation d'un serveur web. Charger en mémoire GPU un modèle de plusieurs milliards de paramètres prend du temps, souvent plusieurs secondes. Si vous descendez à zéro puis recevez une requête, votre utilisateur attend ce chargement avant de voir apparaître le moindre jeton. Cette pénalité de latence a conduit la plupart des opérateurs à garder au moins une instance chaude en permanence, en payant la capacité qu'elle soit utilisée ou non.

D'après ce que DeepSeek a divulgué, l'approche de DSec repose sur des fragments de modèle préchauffés, conservés dans un pool partagé plutôt que dans des instances dédiées à chaque client. Lorsque votre charge de travail a besoin de capacité, elle puise dans ce pool en quelques millisecondes plutôt que de tout charger depuis zéro. Vous ne payez que les secondes de calcul réellement consommées par vos requêtes. Le pool lui-même est un coût que DeepSeek supporte : votre temps d'inactivité devient son problème, pas le vôtre. C'est la même logique économique que celle des niveaux serverless des bases de données cloud, et elle fonctionne à grande échelle parce que la demande agrégée de milliers de clients est plus lisse que le trafic d'un seul.

Le compromis, c'est le contrôle. Vous partagez une infrastructure que vous ne pouvez pas inspecter, avec des garanties d'isolation que vous devez croire sur parole, administrée par une entreprise dont le siège est en Chine et qui est soumise aux règles de gouvernance des données qui en découlent.

Ce qui change pour les opérateurs

Pour les équipes qui exécutent des charges IA par à-coups ou imprévisibles (files de support client, chaînes de traitement de documents, outils internes à usage irrégulier), le calcul change de manière significative. Une charge qui tourne trois heures par jour était jusqu'ici ancrée à des coûts de réservation sur 24 heures. Avec une facturation à la seconde et un véritable passage à zéro, cette même charge pourrait coûter huit fois moins. Pour les startups ou les équipes produit qui engloutissent un budget GPU réservé dans des fonctionnalités à faible trafic, c'est de l'argent bien réel.

L'erreur serait de n'y voir qu'un gain de coût pur et de migrer les charges de production sans avoir d'abord traité les questions de confiance et de conformité. Élastique, bon marché et opaque : cette combinaison exige de la diligence raisonnable, pas de l'enthousiasme.

Les questions à poser

• Quelles sont les garanties de résidence des données, par écrit ? Les prompts et les réponses qui transitent par un pool partagé exigent des engagements contractuels explicites sur le lieu de stockage, la durée de conservation et les personnes qui peuvent y accéder, et pas seulement un paragraphe de politique de confidentialité.
• Que signifie concrètement l'isolation ici ? Les pools de modèles partagés réduisent les coûts en mutualisant les ressources entre clients. Demandez précisément si les données d'une requête peuvent être observées par un autre client, ou influencer les résultats que celui-ci reçoit.
• Comment la latence de démarrage à froid est-elle garantie, et que se passe-t-il en cas de saturation du pool ? Des démarrages à chaud en quelques millisecondes dépendent de la disponibilité du pool. Obtenez le SLA chiffré, et demandez à quoi ressemble votre latence p99 lorsque le pool est sous charge maximale.
• Votre posture de conformité autorise-t-elle ce fournisseur ? Selon votre secteur et votre clientèle, faire transiter des données par l'infrastructure de DeepSeek peut entrer en conflit avec vos obligations réglementaires existantes. C'est une question juridique, pas technique : obtenez la réponse avant l'envoi de la première requête de production.
• Quelle est la voie de sortie si vous devez partir ? Un calcul élastique à bas prix est un puissant mécanisme de dépendance. Avant d'optimiser votre pile autour des tarifs DSec, vérifiez que vous pouvez migrer vos charges sans réécrire entièrement votre chaîne d'inférence.

Ce qu'il faut surveiller ensuite

Le signal qui compte, c'est de savoir si les fournisseurs cloud occidentaux (AWS, Google, Azure) accélèrent leurs propres offres d'inférence LLM serverless en réponse. Si Azure AI Foundry ou Amazon Bedrock annoncent une facturation à la seconde avec passage à zéro au cours du prochain trimestre, la pression tarifaire de DSec aura porté ses fruits. S'ils ne bougent pas, cela signifie probablement qu'ils estiment que le risque de conformité éloigne les acheteurs d'entreprise quel que soit l'avantage de coût, et cela vous en dit long sur le sérieux avec lequel vous devriez considérer cette offre.