Le clustering des jetons de raisonnement de GPT-5.5 Codex pourrait entraîner une baisse de performance

 (github.com/openai)
1 points par GN⁺ 4 시간 전 | 1 commentaires | Partager sur WhatsApp
  • L’issue OpenAI Codex #30364 signale que les reasoning_output_tokens des réponses gpt-5.5 se concentrent sur des valeurs fixes comme 516, 1034 et 1552, un phénomène qui pourrait être lié à une baisse de qualité sur les tâches Codex complexes
  • L’analyse porte sur les métadonnées Codex token_count du 1er février au 27 juin 2026 UTC ; 390 195 enregistrements de réponses et 865 sessions ont été examinés, avec 3 363 événements exacts à 516 identifiés
  • gpt-5.5 représentait 19,3 % de l’ensemble des réponses, mais 82,0 % des événements exact-516 ; parmi les reasoning_output_tokens >= 516, la part des exact 516 atteignait 44,0 %, bien au-dessus des 1,3 % des modèles non-GPT-5.5
  • Le taux mensuel d’exact-516 est passé de 0,11 % en février 2026 à 53,30 % en mai et 35,84 % en juin, tandis que le nombre moyen et le P90 de jetons de raisonnement baissaient sur la même période, ce qui n’indique pas une simple hausse de l’usage de jetons de raisonnement
  • Dans les commentaires, des cas similaires de clustering à 516 et certaines reproductions de mauvaises réponses ont été partagés sur Codex CLI, Codex Desktop et OpenCode ; une proxy local détectant le motif 518·n−2 pour poursuivre le raisonnement a aussi été proposé comme solution temporaire

Le cœur du problème soulevé

  • L’issue Codex #30364 rapporte un schéma de concentration excessive autour de reasoning_output_tokens = 516 dans les métadonnées token_count des réponses gpt-5.5
  • Des pics ressemblant à des bornes fixes apparaîtraient aussi autour de 1034 et 1552
  • La portée de l’allégation n’est pas de prouver une coupure de chaîne de pensée cachée
    • L’affirmation plus étroite est qu’une anomalie de clustering à jetons fixes spécifique à gpt-5.5 apparaît dans la télémétrie Codex
    • Le problème est présenté comme cohérent avec un comportement de budget de raisonnement fondé sur des seuils
  • L’issue liée #29353 portait sur la reproduction d’une unité de travail où une exécution gpt-5.5 se terminait exactement à 516 reasoning tokens et renvoyait une mauvaise réponse ; cette nouvelle issue ajoute des preuves agrégées sur une période plus longue

Environnement d’analyse et données

  • Le produit est Codex, et le modèle le plus concerné est gpt-5.5
  • La source de données est les métadonnées Codex token_count
  • La période d’analyse va du 1er février au 27 juin 2026 UTC
  • Chiffres agrégés :
    • Enregistrements de jetons au niveau réponse : 390 195
    • Sessions : 865
    • Événements exacts reasoning_output_tokens = 516 : 3 363
    • Part de gpt-5.5 dans l’ensemble des réponses : 19,3 %
    • Part de gpt-5.5 dans les événements exact-516 : 82,0 %
    • Ratio exact-516 / >=516 pour gpt-5.5 : 44,0 %
    • Ratio exact-516 / >=516 pour les non-GPT-5.5 : 1,3 %

Schémas par modèle et par mois

  • Le ratio exact 516 / >=516 par modèle est le plus marqué pour gpt-5.5
    • gpt-5.5 : 75 401 enregistrements, 44,0 %
    • gpt-5.4 : 25 214 enregistrements, 19,8 %
    • gpt-5.2 : 247 575 enregistrements, 0,34 %
    • gpt-5.3-codex : 13 333 enregistrements, 0,0 %
    • gpt-5.3-codex-spark : 26 179 enregistrements, 0,0 %
  • Le clustering mensuel exact-516 a fortement augmenté en mai 2026
    • Février : 0,11 %
    • Mars : 2,45 %
    • Avril : 4,25 %
    • Mai : 53,30 %
    • Juin : 35,84 %
  • Sur la même période, l’intensité globale des jetons de raisonnement a diminué
    • Moyenne des reasoning tokens : février 268,1 → mai 106,9 → juin 168,5
    • P90 des reasoning tokens : février 772 → mai 344 → juin 515
  • Cette combinaison soulève le problème qu’il est difficile d’expliquer la hausse des exact-516 par une simple augmentation de l’usage des jetons de raisonnement

Vérifications internes demandées

  • Il est demandé à l’équipe Codex d’examiner si le budget de raisonnement, le routage, la coupure, le fallback ou le comportement du scheduler de gpt-5.5 peuvent provoquer des terminaisons autour de 516/1034/1552
  • Si ce comportement est intentionnel, la demande inclut de préciser si exact 516 correspond à un point de terminaison normal, à une limite de budget, à un tier dégradé ou à un autre seuil interne
  • Procédure de vérification proposée :
    • Consulter les événements token_count incluant reasoning_output_tokens par modèle
    • Comparer les comptages de valeurs exactes 0, 516, 1034, 1552
    • Calculer par modèle et par date count(reasoning_output_tokens = 516) / count(reasoning_output_tokens >= 516)
    • Comparer gpt-5.5 avec gpt-5.2, gpt-5.4 et les variantes dédiées à Codex
    • Relancer des tâches complexes sur GPT-5.2 et GPT-5.5, puis séparer les réponses exact-516 des réponses avec un raisonnement plus long pour en évaluer la qualité

Reproductions supplémentaires et données croisées dans les commentaires

  • GitHub Actions signale #29353 comme doublon potentiel lié
  • Plusieurs utilisateurs ont commenté avoir rencontré le même problème, et l’un d’eux estime que cette issue constitue un rapport plus fondé sur les données que la précédente
  • sinnet3000 a présenté des données inter-clients issues des stockages de sessions locaux de Codex CLI et OpenCode
    • Dans environ 22,7k événements token_count de Codex ~/.codex/sessions et archived_sessions, gpt-5.5 affiche 4 300 records, 156 >=516, 88 exact 516, soit un ratio de 56,4 %
    • Dans environ 32,1k assistant messages de l’opencode.db d’OpenCode, gpt-5.5 affiche 6 977 records, 126 >=516, 90 exact 516, soit un ratio de 71,4 %
    • Sur environ 24k records agrégés de modèles non-OpenAI avec du volume, comme Kimi, DeepSeek, MiMo, MiniMax, Gemini, Qwen et GLM, aucun exact 516 n’a été observé
    • Cette donnée est accompagnée d’une réserve : elle n’évalue pas si les réponses sont justes ou fausses, seulement l’existence du clustering exact 516
  • kyleboddy a signalé des différences de comportement liées sur Codex Desktop sous Windows 11
    • Le même candy prompt a été exécuté dans 5 threads Codex Desktop frais, sans projet
    • Les exécutions rapides direct-final_answer ont renvoyé 29, une mauvaise réponse
    • Les exécutions plus lentes où commentary apparaissait d’abord ont renvoyé 21, la bonne réponse
    • Il précise que les exact reasoning_output_tokens n’ont pas pu être extraits des threads Desktop frais sous Windows, donc il n’est pas possible d’affirmer que l’exécution erronée était exactement à 516
  • Le même utilisateur a aussi agrégé le clustering de valeurs fixes de gpt-5.5 / xhigh dans les métadonnées de sessions locales
    • records 16 141, sessions 51, reasoning moyen 149,7, P90 429
    • =516 438 cas, >=516 1 298 cas, ratio 33,74 %
    • =1034 52 cas, =1552 14 cas, =2070 16 cas, =2588 12 cas, =3106 5 cas

Résultats de reproduction sur Codex Linux CLI

  • kyleboddy indique avoir reproduit le problème sur Codex Linux CLI avec le même candy prompt
  • Environnement :
    • Produit : Codex CLI
    • Version : codex-cli 0.142.5
    • Plateforme : Ubuntu Linux 6.8.0-111-generic, x86_64
    • Node : v24.14.0
    • Mode d’authentification : ChatGPT
    • Modèle testé : gpt-5.5
    • reasoning efforts : xhigh, high
    • Modèle témoin : gpt-5.4 xhigh
  • Le prompt demande, sans utiliser d’outils externes, le nombre minimal de tirages pour un problème de sac de bonbons où la forme est distinguable au toucher
  • La réponse attendue a été confirmée indépendamment par énumération brute-force comme étant 21
    • L’explication inclut le fait que, puisque la forme est distinguable au toucher, on peut planifier 9 bonbons ronds + 12 bonbons en étoile
  • Résultats :
    • Les 4 exécutions terminées de gpt-5.5 xhigh avaient toutes reasoning_output_tokens = 516, avec les réponses finales 23, 26, 28, 15, toutes incorrectes
    • Les 3 exécutions de gpt-5.5 high étaient également toutes à 516, avec les réponses 22, 21, 27, une seule étant correcte
    • Les 3 exécutions de gpt-5.4 xhigh ont utilisé 6211, 12274 et 10876 reasoning tokens et ont toutes répondu 21, correctement
  • Ces résultats renforcent l’affirmation étroite selon laquelle gpt-5.5 peut entrer dans un chemin fixe à 516 tokens dans Codex, et que ce chemin peut être corrélé à une baisse de qualité des tâches

Solution de contournement temporaire proposée

  • dzshzx propose codexcomp, un proxy Responses local placé devant Codex en attendant un correctif upstream
  • Son fonctionnement consiste à considérer le motif 518·n−2 comme une coupure et à poursuivre le raisonnement
    • Les rounds se terminant avec reasoning_tokens == 518·n − 2, c’est-à-dire 516, 1034, 1552, etc., sont traités comme truncated
    • La sortie tentative est écartée, et les reasoning items du round ainsi que encrypted_content sont rejoués dans l’entrée suivante
    • Un message phase:"commentary" et "Continue thinking..." sont ajoutés
    • Tous les rounds sont repliés en une seule downstream response afin que Codex voie le tout comme une réponse terminée
  • La configuration utilise la clé officielle top-level openai_base_url
    • Exemple : openai_base_url = "http://127.0.0.1:8787/v1";
    • Le provider built-in openai est conservé, ce qui permettrait de maintenir le session grouping, la remote compaction et le remote-control
  • Un exemple de logs réels présente un cas où, après deux 516 consécutifs, le troisième round se termine proprement et donne la bonne réponse finale
    • round 1 : reason=516 → continue
    • round 2 : reason=516 → continue
    • round 3 : reason=291 → clean
  • Réserves :
    • C’est une solution de contournement non officielle qui dépend de comportements upstream non contractuels
    • Les rounds de continuation consomment de vrais jetons supplémentaires
    • Elle est limitée par une fenêtre n et un plafond de 3 continuations
    • Elle fonctionne uniquement en loopback, transmet l’authentification et affirme ne pas lire ni stocker les credentials

À lire aussi

1 commentaires

 
GN⁺ 4 시간 전
Commentaires sur Hacker News

  • Ça a l’air assez sérieux, et c’est facile à reproduire même avec codex cli
    Si on lui donne un prompt de puzzle qui demande du raisonnement, il arrive qu’il se coupe soudainement et n’utilise exactement que 516 jetons de réflexion, puis donne une mauvaise réponse
    Quand il utilise 6 000 à 8 000 jetons de réflexion, il donne la bonne réponse
    Ça peut être un problème du côté de la réflexion adaptative (adaptive thinking), et c’est encore un point en faveur des modèles locaux, puisqu’il n’y a pas à s’inquiéter de changements côté serveur passés sous silence
    J’ai lancé le même prompt 10 fois, et 4 fois il y a eu ce problème des 516 jetons, avec une mauvaise réponse dans les 4 cas. L’échantillon est petit, mais on dirait bien qu’avec 5.5 xhigh, il y a presque une chance sur deux d’être écourté avec une baisse de performance

    • Je pense aussi qu’il y a un problème philosophique avec la réflexion adaptative. C’est une approche où l’on devine combien de budget de réflexion allouer avant de commencer à réfléchir, mais dans le contexte des LLM, il semble presque impossible de savoir à l’avance quelle quantité de réflexion est nécessaire, autrement dit combien de jetons il faudra générer
      L’espace des problèmes est infiniment vaste, et il est difficile de juger combien réfléchir simplement à partir de la similarité entre prompts. Le modèle arrête déjà de réfléchir avant même d’avoir atteint son budget de réflexion
      Je ne comprends pas pourquoi autant d’efforts sont consacrés à implémenter la réflexion adaptative, alors qu’il vaudrait peut-être mieux entraîner le modèle à mieux produire un jeton de fin de réflexion
      Ça ressemble à un bricolage. Le modèle devrait être entraîné à faire une quantité de raisonnement appropriée : raisonnement → estimation de l’incertitude restante → décision de continuer ou non → nouveau raisonnement → répétition
    • Même avec un modèle local, il faut se méfier des erreurs de configuration. Même les experts se trompent, donc les performances des modèles locaux varient selon les fournisseurs
    • Je me demande si des tests selon l’heure de la journée ou le jour de la semaine révèleraient un motif. Par exemple, on pourrait voir si ces interruptions arrivent plus souvent pendant les pics d’activité
    • Si c’est aussi l’utilisateur qui paie le coût de ces jetons gaspillés, ça peut valoir le coup de demander un remboursement

  • J’ai constaté presque tous les jours une dégradation de la qualité par paliers, en utilisant généralement xhigh
    L’expérience sur laquelle je comptais en début d’année, avec le codage remarquablement méticuleux de Codex, a disparu, et comme il sort de temps en temps des implémentations absurdement stupides, je suis passé à Claude jusqu’à ce qu’OpenAI traite ce problème sérieusement
    Personnellement, je le constate depuis des mois, sans avoir l’impression qu’OpenAI le prenne vraiment au sérieux

    • Il y a 3 mois, Claude était devenu tellement idiot que je suis passé à Codex, et il y a 6 mois c’était l’inverse. Que ce soit Codex ou Claude, les deux finissent par poser problème un jour ou l’autre. Cela dit, Codex est probablement un peu moins pire
    • Depuis début juin, j’ai l’impression que la fiabilité de 5.5 est tombée à mon niveau d’expérience au niveau de Claude
      Du coup, je suis passé de 5.5 high → 5.5 xhigh → 5.4 high
      5.4 high a été totalement stable ces 3 dernières semaines, et pour l’instant ça me convient
      Je lance parfois un job sur 5.5 xhigh pour vérifier si c’est revenu à 100 % de stabilité, mais j’ai l’impression qu’en ce moment ils attendent plutôt la sortie de 5.6 que de corriger ce problème de fiabilité
    • Je ne crois pas que ce soit un problème technique. Le corriger coûterait cher, et comme les utilisateurs ne paient pas assez, j’y vois une décision commerciale consistant à dégrader les performances

  • Ça donne une impression de déjà-vu. Ça ressemble exactement à la régression de performance de Claude Code en avril. À l’époque, j’avais annulé mon abonnement Claude et migré vers Codex
    Maintenant, j’envisage d’utiliser les deux avec une facturation au jeton, d’employer Fireworks GLM 5.2 pour la plupart des tâches, et de ne payer pour les gros modèles que lorsque c’est nécessaire. En revanche, je ne suis pas sûr que l’équilibre économique soit réellement favorable

    • J’avais la même réaction à propos de la facturation au jeton, mais à cause du fait qu’il est économiquement avantageux pour les deux laboratoires de faire basculer leurs clients vers une consommation au jeton, j’ai envie de l’éviter par principe
      Même si ce n’est pas intentionnel, je ne veux pas accepter ni rendre possible une structure où l’on tire profit d’un produit dont la qualité se dégrade
      Plus que jamais depuis la sortie de ChatGPT, les modèles open source et les environnements d’exécution ouverts, comme Pi par exemple, me paraissent bien plus attrayants
    • Exact. Moi aussi, c’est à cause de ça que j’ai arrêté Claude Code et basculé sur Codex
      Maintenant, je réfléchis surtout à la façon de gagner 65 000 dollars de plus si je veux arrêter de me soucier à nouveau de ce genre d’absurdités. Je comprends l’intérêt économique de choses comme OpenRouter
      Ça me rappelle l’époque, vers 2008, où le « cloud » s’imposait comme terme marketing. Ça ressemblait à un emballage destiné à augmenter les marges des entreprises, en abaissant les attentes autour des clients riches et en rognant la propriété locale au profit d’un modèle par abonnement
      Ensuite, j’en ai eu assez de l’enthousiasme et de l’absolutisme autour des « vrais logiciels libres/open source », et j’ai laissé tomber en me disant que j’étais jeune
      En réalité, je peux comprendre ou tolérer beaucoup de modèles par abonnement dans une certaine mesure. Développer du logiciel coûte cher, et considérer en 2026 qu’une mise à niveau annuelle de Photoshop vaut 200 dollars n’est peut-être pas juste. En revanche, modifier arbitrairement une interface qui fonctionnait bien depuis 20 ans, ou supprimer totalement des choses comme les nuanciers de couleurs classiques, c’est idiot
      Ensuite, bien sûr, on peut utiliser Codex, outil de travail indispensable à 200 dollars par mois, pour créer un plugin de nuanciers classiques
      Est-ce que 200 dollars par mois est un prix juste pour mon volume d’utilisation de jetons ? Certains mois où j’ai vraiment beaucoup utilisé le service, j’ai peut-être consommé autour d’un milliard de jetons
      Mais c’est justement le problème. Ils vont continuer à actionner les leviers à l’infini sans savoir précisément quel modèle de rentabilité fonctionne, et si on lit les signes comme les échéances de dette, on dirait qu’ils continueront au moins jusqu’en 2030 ou 2032
      Je n’ai aucune envie de penser à ça. Je ne veux pas devoir réévaluer sans cesse mes préférences de modèles et la dégradation de leurs performances, ni mettre à jour en permanence les nuances de ma manière de parler à l’IA en fonction de mystérieuses expérimentations backend qui affectent les sorties que j’utilise dans des livrables réels, ceux que je produis et maintiens contre rémunération
      L’IA se situe quelque part entre un outil et un collaborateur, et ces changements de « personnalité » capricieux liés à des boutons et leviers mal compris au stade du raisonnement me rendent fou. Alors je montre la boîte dans un coin et je veux connaître exactement la qualité de sortie qu’elle produit, qualité que personne d’autre que moi ne modifie
    • Fireworks ?
    • Oui, cette idée d’une régression de performance de Claude Code « au ressenti », c’est bien ça. Dans un système non déterministe, il ne faut pas s’attendre à des performances constantes. Il n’existe absolument aucune donnée empirique à l’appui d’une dégradation des performances
      Récemment, ce qui a changé par paliers, ce n’est pas la performance du modèle, mais la quantité de geignements et de plaintes des développeurs

  • Le fait que Codex soit open source est appréciable, car ce genre de problème peut être exposé et traité publiquement.

    • Mais il s’agit du comportement du modèle, et le fait qu’il y ait un suivi public des problèmes ne le rend-il pas au fond similaire à Claude Code, à ceci près que le code n’est pas là ? Dans ce type de problème, je ne vois pas bien ce qui le distingue de https://github.com/anthropics/claude-code
      Je suis globalement reconnaissant que Codex soit open source, mais pour cette catégorie de problèmes cela ne semble pas avoir beaucoup d’importance, puisque le modèle reste fermé.
    • J’ai le sentiment qu’OpenAI est, dans l’ensemble, bien plus ouvert qu’Anthropic et se comporte davantage comme une vraie entreprise. Anthropic, c’est juste une boîte noire.

  • C’est peut-être ma mémoire qui me joue des tours, mais en termes de consommation de tokens et de qualité du code, 5.3 était peut-être le meilleur. 5.5 fonctionne mieux, mais il dévore complètement les tokens.

    • Je ne suis pas le seul à le penser. 5.3-codex était selon moi un excellent modèle en matière d’équilibre entre qualité de sortie et coût.
      Contrairement à 5.5 ou Opus, il était assez bon tout en restant suffisamment bon marché et efficace pour être utilisé sur presque toutes les tâches, et je le préférais à Sonnet.
    • Il y a quelques semaines, 5.3 est devenu inutilisable selon mes critères. Il s’arrêtait simplement ou produisait des réponses médiocres.

  • Il me semble que quelqu’un disait ici, il y a quelques jours, qu’OpenAI avait réduit de moitié le coût de calcul grâce à une optimisation révolutionnaire ; c’était ça ?

    • C’était un article de The Information, mais il ne m’a pas semblé particulièrement bien écrit. Je n’ai pas eu l’impression que l’auteur était un expert technique connaissant suffisamment le fonctionnement des LLM pour évaluer de manière fiable des rumeurs internes : https://www.theinformation.com/newsletters/ai-agenda/openai-...
      Il y était dit, selon une personne au courant de ces discussions, que « des ingénieurs d’OpenAI ont expliqué à certains collègues plus tôt ce mois-ci qu’ils avaient découvert, grâce à une nouvelle optimisation, un moyen de réduire de plus de moitié le coût d’exécution des modèles existants, c’est-à-dire le coût d’inférence ».
    • J’avais compris cette rumeur comme disant que ce n’était pas OpenAI lui-même, mais plutôt l’un des groupes issus de la scission d’après-crise d’OpenAI, probablement Thinking Machines, qui avait trouvé une percée et la proposait à OpenAI. À mon avis, OpenAI ne l’a pas encore réellement mise en œuvre.

  • Dans mon cas, cet effet apparaît si l’on regarde le contenu de raisonnement chiffré via la longueur de la chaîne base64. En revanche, il n’apparaît pas dans les tokens de raisonnement rapportés par le serveur.
    J’ai donc pensé qu’il s’agissait simplement d’un aspect du chiffrement ou de l’obfuscation, et que ce n’était pas un vrai problème.
    Le plus gros défaut de GPT est que son processus de pensée est chiffré, ce qui en fait une boîte noire encore plus opaque que Kimi, GLM ou DeepSeek. Cela dit, on peut quand même obtenir un résumé du raisonnement, donc même si c’est étrange, cela reste utilisable.

  • Serait-ce l’un des rares cas où dire qu’« ils ont rendu le modèle plus bête » n’est pas le fantasme habituel des utilisateurs, mais un cas où ils ont réellement rendu le modèle plus bête ?

    • Cela ressemble plutôt à un défaut du moteur de raisonnement ou de l’environnement d’exécution de l’agent, voire à une erreur de configuration.
      Les détails de l’incident ne constituent pas une preuve d’un affaiblissement volontaire et furtif ; on serait même plutôt dans le cas inverse. La cause profonde paraît grossière, et ce n’est pas quelque chose de particulièrement discret si un utilisateur ordinaire peut le signaler avec des détails précis vérifiables indépendamment.
      L’expression « fantasme habituel des utilisateurs » n’est ni juste ni à mon goût. Quand on n’a qu’un endpoint d’API façon évier magique qui engloutit une fenêtre de contexte et recrache la suite, il ne reste au fond que des jugements subjectifs, des suppositions et des soupçons.
      Même avec une suite de tests standardisée pour les modèles, prétendre à un affaiblissement furtif revient finalement à prêter des intentions aux gens de l’entreprise. La qualité d’un modèle peut baisser même sans intention explicite ni dégradation de l’infrastructure sous-jacente.
      Examiner des théories du complot lancées à moitié pour rire ou la possibilité d’un véritable affaiblissement n’a rien de pathologique. Je n’aime pas cette tendance à détourner ainsi des termes de diagnostic psychologique.
      Bien sûr, il y a probablement des gens trop sûrs d’eux dans ce type de jugement, et cela peut s’appliquer à eux, mais ils restent minoritaires. Au final, c’est juste exagéré, et cela n’aide personne.

  • C’est drôle de vendre des abonnements à des modèles frontier puis de les nerfer rapidement avec le temps sans que personne n’en parle.
    Si, côté serveur, on réduit discrètement l’intensité du raisonnement, il faudrait au moins accorder une remise.
    Cela dit, j’utilise 5.5-high tous les jours dans un flux de travail parallèle multi-tâches, et j’arrive tout juste à consommer ma limite hebdomadaire. Je ne suis tout simplement pas assez rapide en mode Human-as-a-Service pour suivre et lire toute la planification et toute l’implémentation. Il y a aussi cet aspect-là.

  • Il semble clair que, pour optimiser le débit, ils traitent par lots le raisonnement d’inférence par multiples de 512 tokens.

    • Ma première pensée, en prenant llama.cpp comme référence, a été qu’un ajustement du paramètre de budget de raisonnement pourrait produire ce résultat. Mais sans annonce d’OpenAI, impossible de le savoir avec certitude.
      Cela pourrait aussi être une manière très malhonnête d’adapter le système à la demande des heures de pointe. Je sais déjà que, sur ce sujet, certains se moquent de la subjectivité du ressenti de performance des modèles, mais au moins dans mes tests sur tout le mois de mai, le modèle semblait moins intelligent aux heures où les États-Unis se connectaient.
      Il y a quelques semaines, dans un billet du blog de l’entreprise aussi, cela m’a paru se produire selon un schéma plus cohérent à ces horaires qui se chevauchent, au point que j’ai estimé qu’il fallait le signaler. J’aurais dû conserver les journaux de session pour une analyse supplémentaire https://webesque.agency/blog/2026-06-19-llms.html
    • Le standard, ce n’est pas le continuous batching ? Si on utilise le continuous batching, je me demande pourquoi la longueur des tokens générés aurait de l’importance, et pourquoi on les regrouperait par longueur. Et si ce n’est pas le cas, je me demande pourquoi, ainsi que quels en sont les compromis.