Calcul en Temps de Sommeil – L’IA qui « Réfléchit » 24h/24 (Une Avancée Révolutionnaire)

Et si vous pouviez donner à l’IA la capacité de commencer à élaborer des réponses à vos questions avant même que vous ne les posiez ? Il s’avère que c’est tout à fait possible. Une équipe de chercheurs vient de publier un article scientifique montrant exactement comment y parvenir.

Les origines du concept : de MEM GPT à Leta

Il y a quelque temps, j’avais réalisé une vidéo analysant un article et un projet open-source appelé MEM GPT. C’était l’un des premiers projets à envisager de doter les agents d’IA d’une mémoire plus sophistiquée. L’équipe de MEM GPT s’est rassemblée pour créer une entreprise nommée Leta. Cette même équipe vient de publier ce nouvel article qui démontre que grâce au « sleep time compute » (calcul en temps de sommeil), permettant essentiellement à l’IA de réfléchir avant même que vous ne lui soumettiez une requête, il est possible de réduire considérablement les coûts de calcul et, dans certains cas, d’améliorer la qualité des réponses.

Comme l’indique leur recherche : « Nous introduisons le calcul en temps de sommeil qui permet aux modèles de réfléchir hors ligne sur le contexte avant que les requêtes ne soient présentées. »

Le problème du calcul au moment du test (test time compute)

Commençons par comprendre le concept de « test time scaling ». Cette approche est omniprésente et a été identifiée comme une nouvelle loi d’échelle. Fondamentalement, plus vous consacrez de ressources de calcul aux problèmes au moment du test, meilleure est la qualité des résultats produits par les modèles.

Si vous n’êtes pas familier avec le concept de « test time compute », il s’agit essentiellement des modèles de réflexion comme O1, O3, DeepSeek ou Gemini 2.5. Ces modèles raisonnent en produisant des « tokens de réflexion » et en élaborant leur raisonnement avant de vous donner la réponse finale.

Cependant, le calcul au moment du test présente deux problèmes majeurs :

La lenteur : Le temps de réflexion ralentit le processus. Pour des problèmes complexes, c’est acceptable, mais si votre cas d’utilisation est sensible à la latence, ce temps de réflexion peut être significatif – de quelques secondes à plusieurs minutes.
Le coût : Tout ce temps de réflexion nécessite des GPU en fonctionnement qui traitent ces tokens de réflexion, ce qui rend le processus très coûteux.

Comme le souligne l’introduction de l’article : « L’amélioration des performances grâce au calcul au moment du test s’accompagne d’une augmentation significative de la latence et des coûts, nécessitant potentiellement plusieurs minutes d’attente pour obtenir des réponses et coûtant jusqu’à des dizaines de dollars par requête. »

Pourquoi tout ce traitement est-il nécessaire au moment du test ?

Ces inconvénients sont en partie dus au fait que l’approche actuelle du calcul au moment du test suppose que les problèmes sont sans état (stateless). Essentiellement, les modèles doivent recommencer à zéro et comprendre le contexte à chaque fois qu’ils exécutent une inférence sur votre prompt.

Les requêtes (vos prompts) et le contexte (les informations d’arrière-plan telles que des documents ou des bases de code) nécessaires pour y répondre sont fournis au modèle ensemble au moment du test. En pratique, selon cet article, cela est particulièrement vrai si vous avez plusieurs requêtes qui interrogent essentiellement le même contexte.

Imaginez que vous chargiez une base de code et que vous souhaitiez poser des questions à son sujet. Même en utilisant la mise en cache des prompts, le modèle doit encore effectuer beaucoup de calculs redondants.

Mais comme l’indique l’article : « En réalité, de nombreuses applications LLM sont intrinsèquement avec état (stateful) et fonctionnent en conjonction avec un contexte persistant et réutilisé. »

Il existe des cas d’utilisation évidents : bases de code, traitement de documents et questions-réponses sur documents, traitement vidéo… Dans de nombreux cas, un LLM ne devrait pas avoir à recommencer à zéro à chaque fois.

Les auteurs soulignent que les questions-réponses sur documents constituent un exemple classique. Les agents de codage opèrent également sur un grand référentiel commun, et les assistants conversationnels doivent maintenir le dialogue passé.

La solution : le calcul en temps de sommeil

Et si, au lieu de fournir l’intégralité du contexte brut au modèle à chaque fois pour le traiter, nous effectuions un traitement préalable, avant même que vous n’interrogiez le modèle ?

Voici un exemple concret pour illustrer cette approche :

Prenons ce contexte brut : « Un jongleur peut jongler avec 800 balles. 1/4 des balles sont des balles de tennis, et la moitié des balles de tennis sont indigo, dont un dixième sont marquées. »

Avec l’approche standard de calcul au moment du test, nous transmettons l’intégralité du contexte brut plus nos questions, comme « Combien y a-t-il de balles de tennis indigo marquées ? » ou « Combien y a-t-il de balles de tennis au total ? ». Le modèle traite alors l’ensemble à chaque fois.

Cependant, avec la stratégie de calcul en temps de sommeil, nous prenons le contexte brut et nous créons un « contexte appris ». Il utilise essentiellement l’IA pour prétraiter le contexte et en déduire des informations, de manière très similaire au fonctionnement du cerveau humain.

À partir de ce contexte brut, voici ce que le LLM a déduit avant même d’être interrogé pour la première fois :
– Un jongleur peut jongler avec 800 balles (information directe).
– Un quart des balles sont des balles de tennis, ce qui signifie qu’il y a 200 balles de tennis.
– La moitié des balles de tennis sont indigo, ce qui donne 100 balles de tennis indigo.

Le modèle anticipe ainsi les questions les plus susceptibles d’être posées sur ce contexte et les prétraite.

Pourquoi le prétraitement est-il meilleur que le calcul au moment du test ?

Lorsque le calcul est effectué au moment du test, il peut être 10 fois plus coûteux en termes d’utilisation du GPU. Quand le modèle a une échéance stricte pour vous renvoyer une réponse, c’est le moment le plus coûteux pour ce GPU.

Pensez à la façon dont les GPU sont utilisés. Lorsque vous interrogez un modèle, le GPU fonctionne et traite les données. Mais une fois terminé, il s’arrête simplement et attend. Ce temps d’attente pourrait être utilisé de manière productive.

En raison de l’offre et de la demande, la demande de GPU au moment où vous interrogez le modèle est beaucoup plus élevée qu’elle ne le serait pendant les périodes où ces GPU sont essentiellement en sommeil.

Après avoir élaboré le contexte appris, lorsque nous posons les mêmes questions :
– « Combien y a-t-il de balles de tennis indigo marquées ? » – Au lieu de devoir refaire tout le raisonnement, le modèle répond simplement : « La réponse est 10. »
– « Combien y a-t-il de balles de tennis ? » – « La réponse est 200. »

Comme on peut le voir, la quantité totale de traitement peut être similaire, mais une grande partie est prétraitée pendant une période de traitement beaucoup moins coûteuse.

Pour citer l’article : « Nous pourrions faire des inférences utiles sur l’état actuel, le contexte, les informations que nous fournissons au modèle hors ligne, avant ou même pendant la prochaine entrée de l’utilisateur. Et nous appelons cela le calcul en temps de sommeil, où l’inférence est effectuée entre les interactions avec le modèle alors qu’il serait autrement inactif pendant le temps de sommeil. »

Comment fonctionne concrètement le calcul en temps de sommeil ?

Cela est réalisé en invitant le modèle à générer un nouveau contexte constitué d’inférences sur le contexte existant. En d’autres termes, on demande au modèle de prendre cet ensemble de données, ce document ou cette base de code, et d’établir des connexions, d’anticiper les questions potentielles qui pourraient être posées sur ces données.

Le contexte rereprésenté issu du temps de sommeil peut ensuite être fourni dans le prompt au moment du test. Ainsi, toutes ces déductions faites pendant que le GPU aurait été autrement en sommeil sont maintenant fournies comme contexte au modèle, lui évitant de devoir effectuer tout ce traitement supplémentaire au moment du test, permettant au modèle de répondre aux requêtes des utilisateurs avec la précision du calcul standard au moment du test, mais avec des latences bien inférieures.

Par exemple, un assistant de codage en temps de sommeil peut identifier des modèles architecturaux, anticiper des stratégies de débogage potentielles ou déduire des optimisations avant l’entrée de l’utilisateur. Cela est particulièrement utile lorsqu’un utilisateur va poser plusieurs questions sur le même contexte.

Les chercheurs vont plus loin et affirment qu’on peut amortir le coût du calcul en temps de sommeil et réduire le coût total moyen par requête. Concrètement, ils ont découvert que dans la plupart des cas, le calcul en temps de sommeil pouvait égaler ou surpasser la qualité du calcul au moment du test en utilisant cinq fois moins de ressources.

Ils ont également constaté qu’ils pouvaient faire évoluer le calcul en temps de sommeil – plus ils effectuaient de calculs pendant le temps de sommeil, meilleurs étaient les résultats. Ils ont pu améliorer leurs résultats de 13% et 18% sur leurs deux différentes références de test.

En amortissant le calcul en temps de sommeil sur plusieurs requêtes (en effectuant ce prétraitement une fois puis en permettant à plusieurs requêtes d’utiliser ce contexte prétraité), ils ont pu réduire le coût moyen par question de 2,5 fois.

Ce n’est pas parfait pour autant. Dans certains cas, le calcul au moment du test reste meilleur, comme nous le verrons plus loin.

Benchmarks et évaluation

Les chercheurs ont utilisé deux benchmarks différents. Ils ont converti un benchmark sans état (stateless), qui est la norme actuelle, en un benchmark avec état (stateful). Voici ce que cela signifie :

Benchmark sans état : L’utilisateur fournit une requête au LLM, comme l’exemple du jongleur, incluant la question « Combien y a-t-il de balles de tennis indigo marquées ? »
Benchmark avec état : Cette même requête peut être divisée en contexte (les informations sur le jongleur) et la requête proprement dite (« Combien y a-t-il de balles de tennis indigo marquées ? »). Ainsi, nous pouvons commencer à traiter le contexte avant de soumettre la requête à l’IA.

Les modèles testés comprennent à la fois des modèles de raisonnement (qui utilisent le calcul au moment du test) et des modèles sans raisonnement :
– Modèles de raisonnement : O1, O3 Mini, Claude 3.7 Sonnet Extended Thinking, DeepSeek R1
– Modèles sans raisonnement : GPT-4o Mini et GPT-4o

Résultats clés

Les résultats ont été présentés sur deux graphiques, P1 et P2 : P1 pour les questions plus faciles et P2 pour les questions plus difficiles (nécessitant plus de calcul).

Pour GPT-4o Mini et GPT-4o, voici ce qu’ils ont observé :

La ligne de base (sans calcul en temps de sommeil) montre que plus le modèle réfléchit, meilleurs sont les résultats, ce qui confirme l’efficacité du calcul au moment du test.
Avec l’ajout du calcul en temps de sommeil, on observe une augmentation substantielle de la précision lorsque la question nécessite moins de tokens pour la réponse. Cependant, à mesure que plus de tokens sont utilisés pour la réponse, le calcul au moment du test commence à mieux performer.

Mais comment tester cela sur un modèle sans raisonnement, un modèle où l’on ne peut pas contrôler directement la quantité de calcul utilisée pendant sa période de réflexion ? Pour les modèles sans raisonnement comme GPT-4o et GPT-4o Mini, les chercheurs ont construit des prompts qui instruisent le modèle d’utiliser différents niveaux de verbosité au moment du test. Par exemple, « répondez directement en une seule phrase » versus « vérifiez votre raisonnement avant de donner la réponse finale ».

Rappelons que la chaîne de pensée (chain of thought) n’était qu’une stratégie de prompt avant d’être intégrée directement dans les modèles de raisonnement.

Comme mentionné précédemment, avec des budgets de calcul au moment du test plus faibles, les performances du calcul en temps de sommeil sont significativement meilleures que la ligne de base, atteignant des performances comparables à celles de la ligne de base avec cinq fois moins de tokens de calcul.

Qu’en est-il des modèles de raisonnement ? Il s’avère que c’est à peu près la même chose. Lorsque les modèles utilisent moins de réflexion, le calcul en temps de sommeil est bien meilleur. Pour les questions plus faciles, le calcul en temps de sommeil est bien meilleur et moins cher. Mais après un certain temps, permettre au modèle de réfléchir davantage améliore les performances globales, mais à un coût substantiel – un coût littéral. Ces GPU fonctionnent et cela coûte de l’argent, et ils fonctionnent au moment où leur utilisation est la plus coûteuse, le moment du test.

Voici ce qu’ils ont observé avec différents modèles :

O3 Mini : une augmentation substantielle de la précision jusqu’à environ 6 000 tokens de temps de réflexion.
Claude 3.7 Sonnet : une amélioration substantielle de la précision, jusqu’à environ 20 000+ tokens de temps de réflexion.
DeepSeek R1 et O1 ont montré des tendances similaires.

En fin de compte, si vous cherchez à obtenir les meilleures performances indépendamment du coût, le calcul au moment du test et l’augmentation de la quantité de calcul est la meilleure approche. Mais si le coût devient un facteur ou si vous ne résolvez pas des problèmes de mathématiques ou de codage extrêmement difficiles, le calcul en temps de sommeil est vraiment très efficace.

Comparaison avec l’échantillonnage parallèle

Nous parlons beaucoup du calcul au moment du test, le temps de raisonnement d’un modèle avant qu’il ne vous donne sa réponse. Mais il existe une autre approche moins discutée : l’échantillonnage parallèle (parallel sampling).

Cela consiste essentiellement à demander au modèle plusieurs réponses, plusieurs réponses potentielles à votre question, puis à choisir la meilleure. Mais il y a un problème majeur avec l’échantillonnage parallèle : comment savoir quelle est la meilleure réponse ? Il y a une hypothèse énorme, et c’est pourquoi cette approche n’est pas aussi populaire que le calcul au moment du test : vous êtes censé savoir comment choisir laquelle des multiples réponses est la meilleure, ce qui n’est pas toujours le cas, et même fréquemment pas le cas.

En gardant cela à l’esprit, les chercheurs ont constaté que « sur toutes les tâches et tous les modèles, le calcul en temps de sommeil surpasse systématiquement l’échantillonnage parallèle (pass at K) avec le même budget de tokens au moment du test, démontrant que le calcul en temps de sommeil peut être un moyen plus efficace de faire évoluer le calcul au moment de l’inférence que l’échelle standard de test parallèle. »

Mise à l’échelle du calcul en temps de sommeil

Dans quelle mesure ce prétraitement en temps de sommeil, permettant essentiellement aux modèles de faire des déductions lorsque vous ne leur posez même pas de questions, peut-il être mis à l’échelle ?

Les chercheurs ont testé cela en augmentant le budget de prétraitement pendant ce calcul en temps de sommeil. « Sur les modèles de raisonnement, nous augmentons la quantité de calcul en temps de sommeil en variant l’effort de raisonnement pour O1 et O3 Mini lors de l’application du prompt de calcul en temps de sommeil. La mise à l’échelle du calcul en temps de sommeil sur ce benchmark déplace les performances vers l’extérieur, les améliorant de 13% avec un budget de temps de test similaire. »

En d’autres termes, avec la même quantité de réflexion lors de l’interrogation réelle du modèle, mais plus de prétraitement, il peut fonctionner beaucoup mieux. Pour les tâches avec un contexte plus complexe, un calcul supplémentaire en temps de sommeil peut être bénéfique.

Voici à quoi cela ressemble concrètement :
– Calcul en temps de sommeil à faible effort
– Calcul en temps de sommeil à effort moyen
– Calcul en temps de sommeil à effort élevé

La précision augmente à mesure que vous accordez plus de temps au prétraitement pendant le temps de sommeil.

Amortissement du calcul en temps de sommeil

Nous avons évoqué l’amortissement du calcul en temps de sommeil sur plusieurs requêtes. En termes simples, vous effectuez ce prétraitement une fois et vous pouvez interroger ce contexte prétraité plusieurs fois sans avoir à le prétraiter à nouveau, contrairement au calcul au moment du test qui devrait le faire à chaque fois.

Voici le point clé, voici pourquoi le calcul en temps de sommeil est une avancée potentiellement importante : « L’inférence optimisée pour la latence peut être environ 10 fois plus coûteuse. » Cela signifie que lorsque vous interrogez réellement le modèle, et que tout le monde essaie de l’interroger en même temps, ce coût d’inférence, ce GPU fonctionnant dans ce serveur est le plus cher qu’il ne sera jamais à ce moment-là. C’est la demande la plus élevée et l’offre la plus faible.

Les chercheurs ont donc essayé de déterminer quel serait ce compromis entre le calcul en temps de sommeil et le calcul au moment du test en dollars réels, et ils ont augmenté le coût des tokens au moment du test car ces tokens sont plus chers.

L’impact de la prévisibilité des questions

Une autre découverte intéressante : plus les questions sont prévisibles en fonction du contexte que vous fournissez au modèle, mieux fonctionne le calcul en temps de sommeil. Cela est dû à une hypothèse importante du calcul en temps de sommeil : le contexte va informer les questions posées sur ce contexte.

Reprenons l’exemple du jongleur. Si le contexte parle du nombre de balles, du nombre de balles de tennis, du nombre de balles indigo et du nombre de balles marquées, vous allez probablement poser des questions sur ces balles. Mais si vous posiez une question aléatoire sur l’océan, tout ce prétraitement n’aurait pas du tout aidé à répondre à cette question.

Les chercheurs ont émis l’hypothèse que « le calcul en temps de sommeil peut être plus efficace dans les contextes où la requête est plus prévisible à partir du contexte », et ils ont voulu vérifier si c’était vrai.

Voici ce qu’ils ont découvert : en se déplaçant sur l’axe des x, on observe une plus grande prévisibilité des questions basées sur le contexte. Sur l’axe des y, on observe la précision. Plus les questions sont prévisibles, plus la précision est élevée en utilisant le calcul en temps de sommeil.

Cependant, pour P2, qui concerne des questions plus difficiles, l’amélioration des performances devient moins claire pour le calcul en temps de sommeil.

Conclusions globales

En résumé, le calcul en temps de sommeil fonctionne très bien dans certains cas, mais présente des limites :

Dans les contextes où les requêtes sont difficiles à prédire ou sans rapport avec le contexte, le calcul en temps de sommeil sera moins efficace. Cela est logique : si vous effectuez tout ce prétraitement avant même de connaître la question, et que la question est sans rapport avec tout ce que vous venez de prétraiter, aucun des travaux que vous venez d’effectuer n’a d’importance.
Les chercheurs suggèrent qu’ »une direction intéressante pour les travaux futurs consiste à identifier quels contextes peuvent avoir des questions prévisibles et, en fin de compte, à répartir le calcul d’inférence entre le temps de sommeil et le temps de test à travers différents contextes et requêtes. »

Il y a beaucoup d’autres découvertes intéressantes que je n’ai pas abordées directement dans cet article. Je vous encourage à consulter le papier de recherche complet pour en savoir plus sur cette avancée prometteuse dans le domaine de l’IA.

Conclusion

Le calcul en temps de sommeil représente une approche novatrice pour optimiser l’utilisation des ressources de calcul dans les systèmes d’IA. En permettant aux modèles de « réfléchir » pendant les périodes d’inactivité, cette technique peut réduire considérablement les coûts tout en maintenant ou même en améliorant la qualité des réponses pour certains types de requêtes.

Bien que cette approche ne soit pas universellement supérieure au calcul traditionnel au moment du test, particulièrement pour les problèmes complexes ou imprévisibles, elle offre un compromis attrayant entre coût et performance dans de nombreux scénarios d’utilisation courants.

À mesure que la recherche dans ce domaine progresse, nous pourrions voir émerger des systèmes hybrides intelligents qui allouent dynamiquement les ressources de calcul entre le temps de sommeil et le temps de test en fonction de la nature du contexte et des requêtes anticipées.