Skip to content

valorisa/Dual-Path-Deepseek

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

4 Commits
 
 
 
 

Repository files navigation

Dual Path (DeepSeek) – Analyse technique

License: MIT GitHub last commit GitHub repo size Made with Markdown

Analyse détaillée du concept Dual Path présenté par DeepSeek, permettant d’optimiser l’inférence des modèles de langage en contexte agentique sans ajout de GPU.


1. Fiche de lecture / Note technique

Titre : Dual Path – Optimisation du chargement de cache KV pour l’inférence agentique
Source : Vidéo de vulgarisation sur DeepSeek, basée sur le papier de recherche de DeepSeek (Pékin) et Tingro.
Date du contexte : 23 juin 2026.

Résumé exécutif

DeepSeek propose Dual Path, une architecture logicielle qui double le débit d’inférence et réduit de 56 % le délai d’arrivée du premier token, sans aucun GPU supplémentaire. L’astuce consiste à permettre aux machines de decode de charger directement le cache KV depuis le stockage, alors qu’auparavant seule la machine de prefill s’en chargeait, créant un goulot d’étranglement. Le trafic est géré dynamiquement pour ne jamais perturber les communications critiques du modèle. L’approche s’inscrit dans un mouvement plus large d’optimisation des flux de données autour des GPU, en particulier dans un contexte de restrictions matérielles imposées à la Chine.

1.1. Contexte et problématique

Sous-utilisation chronique des GPU

  • Les serveurs IA, équipés de GPU très coûteux (ex. H100), sont souvent utilisés à seulement 20-30 % de leur capacité.
  • La cause principale n’est pas un manque de puissance de calcul, mais l’attente des données : les GPU patientent que la mémoire leur fournisse les informations nécessaires.

Les deux phases de l’inférence d’un LLM

  1. Prefill : le modèle lit l’intégralité du prompt, traite tous les tokens en parallèle.
    • Très intensif en calcul (GPU à 90-95 %).
    • Il calcule et stocke les états dans le cache KV.
  2. Decode : génération de la réponse token par token.
    • Pour chaque nouveau token, le modèle doit relire l’intégralité du cache KV.
    • Très peu de calcul, mais énorme besoin de bande passante mémoire.
    • Les GPU chutent à 20-30 % d’utilisation, « tournent dans le vide ».
    • Cette phase représente 95 % du temps d’une requête (ex. 9 secondes de decode pour 20 ms de prefill sur 300 tokens).

Solution partielle : la désagrégation prefill/decode

  • On sépare les serveurs en deux groupes spécialisés : machines de prefill et machines de decode.
  • Gain de débit : 2 à 7 fois en production classique (chatbot simple).
  • Limite majeure : inefficace pour les charges agentiques.

L’effet amplificateur des agents IA

  • Une session agentique typique (analyse de traces DeepSeek) : 157 itérations, contexte cumulé de 32 000 tokens.
  • À chaque tour, seuls 409 nouveaux tokens sont ajoutés en moyenne → 98,7 % du contexte existe déjà dans les tours précédents.
  • Le cache KV est donc déjà sur le stockage. La phase de prefill ne calcule presque rien, elle passe son temps à recharger ce cache.
  • Goulot d’étranglement : dans l’architecture désagrégée classique, seule la machine de prefill est autorisée à aller chercher les données sur le stockage. Sa carte réseau est saturée, tandis que les cartes réseau de stockage des machines de decode (majoritaires) restent inactives. Le débit global s’effondre.

1.2. Architecture Dual Path

Idée centrale : permettre aussi aux machines de decode d’accéder directement au stockage pour charger le cache KV, en parallèle du chemin classique.

Chemin A (classique)

  1. La machine de prefill va chercher le cache KV sur le stockage.
  2. Elle traite les données couche par couche.
  3. Elle envoie le résultat à la machine de decode via le réseau inter-GPU.

Chemin B (le détournement)

  1. En parallèle, la machine de decode utilise ses propres cartes réseau de stockage (auparavant inactives) pour charger directement l’historique du cache KV.
  2. La machine de decode possède ainsi déjà l’essentiel du cache historique.

Fusion et optimisation

  • Une fois le prefill terminé, la machine de prefill n’a plus besoin d’envoyer des gigaoctets de cache complet. Elle envoie uniquement le cache incrémental correspondant aux nouveaux tokens (très léger).
  • La machine de decode fusionne ce petit supplément avec ce qu’elle a déjà chargé.
  • Conséquence : la bande passante de stockage est mutualisée sur tout le cluster, plus de congestion unique, les « tuyaux vides » sont utilisés.

1.3. Gestion des interférences réseau

  • Risque : si Dual Path envoie trop de données depuis le stockage pendant la phase de decode, cela peut entrer en concurrence avec les communications inter-GPU nécessaires à la génération de la réponse.
  • Solution :
    • Priorité absolue au trafic du modèle (comme un couloir d’urgence sur une autoroute).
    • Dual Path utilise uniquement la bande passante restante, quand le modèle est moins occupé.
    • Routage dynamique : le système surveille la charge en temps réel. Si le chemin classique est bouché, il utilise l’autre, et inversement.

1.4. Résultats en production

Métrique Avant Dual Path Après Dual Path
Utilisation des machines ~40 % 80 %
Débit d’inférence 1x 2x
Temps d’arrivée du premier token baseline -56 %
Matériel supplémentaire - Aucun

1.5. Écosystème et tendances

Dual Path n’est pas une solution isolée. Il s’inscrit dans une optimisation globale des flux de données autour des GPU :

  • HiCache : organisation du cache KV sur plusieurs niveaux (mémoire GPU, RAM serveur, stockage persistant).
  • Mooncake (Best Paper à FAST 2025) : exploitation des ressources sous-utilisées d’un cluster pour construire un cache distribué efficace.
  • 3FS (DeepSeek) : système de fichiers distribué open source conçu pour les workloads d’entraînement et d’inférence IA.
  • Philosophie générale : « mieux faire circuler les données autour des GPU » plutôt que d’ajouter des GPU.

1.6. Contexte géopolitique

  • Depuis 2022, les États-Unis limitent l’accès de la Chine aux GPU avancés (A100, H100).
  • Les laboratoires chinois subissent une pression énorme pour obtenir plus de performance avec moins de hardware.
  • Dual Path est une réponse logicielle à une contrainte matérielle. Au lieu d’acheter plus de GPU, DeepSeek maximise l’existant.

1.7. Conclusion et implications

  • Le vrai problème n’était pas les GPU eux-mêmes, mais la manière dont on les alimentait en données.
  • Dual Path double les performances d’une infrastructure par simple réorganisation du trafic, démontrant que l’optimisation logicielle peut être aussi puissante que le renouvellement matériel.
  • Cette approche est une pièce maîtresse d’un mouvement qui redéfinit la conception des datacenters IA.

2. Schéma textuel / Mindmap

Dual Path (DeepSeek) – Optimisation de l'inférence agentique
│
├── Problème de départ
│   ├── GPU sous-utilisés (20-30 %) pendant la génération (decode)
│   └── Cause : attente de la mémoire, pas de manque de puissance
│
├── Fonctionnement d'un LLM
│   ├── Prefill
│   │   ├── Traitement parallèle de tout le prompt
│   │   ├── Calcul intensif (GPU à 90-95 %)
│   │   └── Stockage dans le cache KV
│   └── Decode
│       ├── Génération token par token
│       ├── Relecture complète du cache KV à chaque token
│       ├── Faible calcul, forte demande en bande passante mémoire
│       └── Représente 95 % du temps de réponse
│
├── Solution partielle : Désagrégation prefill/decode
│   ├── Machines spécialisées prefill / machines spécialisées decode
│   ├── Gains : débit x2 à x7 pour chatbots simples
│   └── Limite pour agents IA
│       ├── Contexte cumulé énorme (32k tokens, 157 itérations)
│       ├── 98,7 % du cache KV déjà existant sur disque
│       └── Saturation de la machine prefill qui recharge seule le cache,
│           pendant que les cartes réseau de stockage des machines decode
│           restent inactives
│
├── Dual Path : la solution
│   ├── Idée clé : laisser les machines decode charger le cache directement
│   │
│   ├── Chemin A (classique)
│   │   ├── Machine prefill : charge depuis stockage
│   │   ├── Traitement couche par couche
│   │   └── Envoi vers decode via réseau inter-GPU
│   │
│   ├── Chemin B (nouveau)
│   │   ├── Machine decode : utilise sa propre carte réseau stockage
│   │   └── Charge directement l'historique du cache KV
│   │
│   └── Fusion
│       ├── Decode possède déjà l'essentiel du cache
│       └── Prefill n'envoie que le cache incrémental (léger)
│
├── Gestion intelligente du réseau
│   ├── Priorité absolue au trafic modèle (données urgentes)
│   ├── Dual Path utilise la bande passante résiduelle
│   └── Routage dynamique selon la charge des machines
│
├── Résultats concrets
│   ├── Utilisation machines : 40 % → 80 %
│   ├── Débit d'inférence : x2
│   ├── Premier token : 56 % plus rapide
│   └── Aucun GPU supplémentaire
│
├── Écosystème plus large
│   ├── HiCache : cache KV multi-niveaux (GPU, RAM, SSD)
│   ├── Mooncake : cache distribué sur ressources inutilisées
│   └── 3FS : système de fichiers distribué pour IA (DeepSeek)
│
└── Contexte géopolitique
    ├── Restrictions US sur GPU avancés (A100, H100)
    ├── Pression sur les labos chinois
    └── Dual Path = réponse logicielle à une contrainte matérielle

3. Questions / Réponses approfondies

Q1. Pourquoi les GPU sont-ils si peu utilisés (20-30 %) pendant la génération de texte ?

La phase de decode génère la réponse token par token. Pour chaque token, le modèle doit relire l’intégralité du cache KV en mémoire. Cette opération demande énormément de bande passante mémoire, mais très peu de calcul. Les GPU passent donc l’essentiel de leur temps à attendre que les données arrivent, d’où un taux d’utilisation très bas. Or, le decode représente environ 95 % du temps total d’une requête.

Q2. Qu’est-ce que la désagrégation prefill/decode et pourquoi n’est-elle pas suffisante ?

La désagrégation consiste à séparer les serveurs en deux groupes : des machines dédiées au prefill (calcul lourd) et d’autres au decode (génération). Cela évite que les deux phases se gênent et améliore le débit (x2 à x7).

Cependant, pour des agents IA qui accumulent un énorme contexte récurrent (32 000 tokens, 157 tours), la phase de prefill n’a presque plus rien à calculer : elle doit seulement recharger le cache KV depuis le stockage. Avec l’architecture classique, seule la machine de prefill est autorisée à faire ce chargement, ce qui sature sa carte réseau alors que les machines de decode (majoritaires en nombre) gardent leurs connexions de stockage inactives.

Q3. En quoi les agents IA aggravent-ils le problème ?

Contrairement à un chatbot question-réponse, un agent autonome fonctionne en boucle : il exécute du code, appelle des outils, raisonne sur des dizaines voire des centaines d’itérations. À chaque tour, le contexte s’allonge, mais la grande majorité (98,7 %) provient des tours précédents et se trouve déjà dans le cache KV sur le disque. Le prefill devient donc un goulot d’étranglement non pas par manque de calcul, mais par saturation de la bande passante de stockage sur une seule machine.

Q4. Quel est le concept fondamental de Dual Path ?

Au lieu de réserver le chargement du cache KV à la machine de prefill, Dual Path autorise deux chemins simultanés :

  • Chemin A : la machine de prefill charge le cache depuis le stockage et l’envoie à la machine de decode.
  • Chemin B : la machine de decode charge elle-même l’historique du cache directement depuis le stockage, via ses propres cartes réseau jusqu’ici inactives.

Une fois le chargement parallèle effectué, la machine de prefill n’a plus qu’à transmettre le cache incrémental (très léger). La bande passante de stockage est ainsi mutualisée et le goulot d’étranglement disparaît.

Q5. Comment Dual Path évite-t-il de perturber les communications critiques du modèle ?

Pendant le decode, les GPU communiquent déjà entre eux en permanence. Si Dual Path envoyait des données massives au même moment, cela créerait des bouchons. Pour l’éviter :

  • Le trafic du modèle est toujours prioritaire (comme un couloir d’urgence).
  • Dual Path utilise uniquement la bande passante résiduelle, lorsque le modèle est moins actif.
  • Un système de routage dynamique surveille la charge en temps réel et bascule d’un chemin à l’autre si l’un est saturé.

Q6. Quels sont les gains concrets en production ?

  • L’utilisation des machines passe de 40 % à 80 %.
  • Le débit d’inférence double.
  • Le temps d’arrivée du premier token est réduit de 56 %.
  • Tout cela sans acquérir un seul GPU supplémentaire.

Q7. En quoi ce papier s’inscrit-il dans une tendance plus large ?

Dual Path fait partie d’un mouvement qui ne considère plus les GPU comme le seul maillon critique, mais cherche à optimiser tout l’environnement : mémoire, SSD, réseau, système de fichiers, caches. On voit émerger des systèmes comme HiCache (cache multi-niveaux), Mooncake (cache distribué sur ressources sous-utilisées) ou encore 3FS, le système de fichiers distribué de DeepSeek. L’objectif est toujours le même : mieux faire circuler les données autour des GPU.

Q8. Quel est le lien avec les sanctions américaines sur les GPU ?

Depuis 2022, les États-Unis restreignent fortement l’exportation vers la Chine des GPU les plus avancés (A100, H100). Les laboratoires chinois doivent donc obtenir plus de performance avec moins de matériel. Dual Path est une réponse directe à cette contrainte : plutôt que d’acheter plus de GPU, DeepSeek a optimisé le logiciel pour doubler les performances de l’infrastructure existante. C’est ce qui rend ce papier si marquant : il démontre que le code peut compenser les limitations matérielles.

About

Analyse approfondie de Dual Path (DeepSeek) : architecture double chemin pour charger le cache KV depuis le stockage, mutualisation de la bande passante, +100% de débit d'inférence et -56% sur le premier token sans GPU supplémentaire. Fiche de lecture, mindmap textuelle et Q/R détaillées sur l'optimisation agentique.

Topics

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

 
 
 

Contributors