DeepSeek prépare visiblement un nouveau jalon côté modèles. À la date anniversaire de DeepSeek-R1, des commits GitHub ont introduit dans FlashMLA une série de références à un identifiant « MODEL1 » disséminé dans 28 sections sur 114 fichiers, apparaissant tantôt aux côtés, tantôt en distinction du « V32 » (DeepSeek-V3.2). L’actualité recoupe un bruit de couloir de début janvier selon lequel un « DeepSeek V4 » serait attendu autour du Nouvel An lunaire, avec un net accent sur les capacités de génération de code.
Des indices d’architecture distincte
Les extraits techniques pointent des écarts notables entre « MODEL1 » et « V32 » sur la gestion des caches KV, le traitement de la sparsité et la prise en charge du format FP8 côté décodage. Ce triptyque suggère un chantier ciblé sur l’empreinte mémoire et le débit effectif, avec un pipeline d’inférence potentiellement optimisé pour des séquences longues et des charges interactives intensives.
Ces choix s’alignent avec l’intégration de kernels FlashMLA de nouvelle génération, où le layout KV et la granularité de sparsité conditionnent fortement l’utilisation du cache et le taux d’occupation des unités de calcul. Le support FP8 en décodage laisse supposer une calibration fine entre précision et débit, un levier crucial pour soutenir des fenêtres contextuelles étendues et des graphes d’attention parcimonieux.
Ponts avec les travaux récents de l’équipe
Deux publications récentes signées par le groupe de recherche DeepSeek détaillent une méthode d’entraînement baptisée « mHC » autour de l’optimisation des connexions résiduelles, et un module mémoire inspiré du biologique, « Engram ». Sans confirmation officielle, l’hypothèse d’une convergence de ces pistes dans « MODEL1 » reste crédible au vu des cibles affichées: stabilité d’apprentissage, capacités de rappel et efficacité d’inférence.
L’ensemble dessine un modèle distinct de V3.2, moins comme une simple révision qu’une refonte de certains blocs critiques. Si le calendrier évoqué pour « V4 » autour de février se confirme, DeepSeek chercherait à capitaliser sur un couple entraînement-inférence resserré, où les gains de sparsité et de quantification allégée seraient immédiatement convertibles en débit et en coût par token.
Dans un marché où l’avantage bascule désormais sur le coût d’exploitation plus que sur les seuls scores synthétiques, la combinaison d’un KV cache repensé et d’un décodage FP8 peut déplacer la pression du côté des fournisseurs d’infrastructure. Si DeepSeek parvient à stabiliser ces optimisations à large échelle, l’impact pourrait être tangible pour les intégrateurs qui cherchent à pousser des assistants de code à forte contrainte de latence et de fenêtre contextuelle, en particulier sur des grappes hétérogènes.
Source : ITHome
