Le caractère non déterministe de GPT-4 vient du Sparse MoE

 (152334H.github.io)
1 points par GN⁺ 2023-08-06 | 1 commentaires | Partager sur WhatsApp
  • Même avec temperature=0, GPT-4 et GPT-3.5-turbo produisent des sorties différentes à chaque exécution pour une même entrée, un comportement inhabituel qui n’apparaît pas sur les modèles décodeurs denses classiques
  • Jusqu’ici, l’origine de cette non-déterminisme était expliquée par l’instabilité des calculs en virgule flottante sur CUDA, mais cette explication reste insuffisante
  • Dans la structure de batched inference des architectures Sparse MoE, les tokens de séquences différentes au sein d’un même batch se disputent la place dans les buffers des experts, ce qui introduit de la non-déterminisme
  • Dans une expérience de 30 appels répétés, GPT-4 a généré de très loin le plus grand nombre de sorties uniques parmi les modèles testés, ce qui soutient empiriquement l’hypothèse
  • Le point clé est que le modèle n’est déterministe qu’au niveau du batch, pas de la séquence, ce qui constitue la cause centrale des problèmes de fiabilité de l’API GPT-4

Le problème — pourquoi la sortie change-t-elle à chaque fois avec temperature=0 ?

  • Le fait que GPT-4/GPT-3.5-turbo soient non déterministes même avec temperature=0.0 est déjà largement connu
    • Sur un modèle dense decoder-only, temp=0 signifie greedy sampling, ce qui devrait conduire à un comportement parfaitement déterministe
    • En effet, les logits du token suivant sont une fonction pure de la séquence d’entrée et des poids du modèle
  • Réponse de l’équipe technique lors d’une table ronde développeurs de l’OpenAI World Tour
    • En substance : « Honnêtement, nous sommes nous aussi perplexes. Cela pourrait être un bug système ou la non-déterminisme de calculs en virgule flottante optimisés »
  • Le fait que ce comportement soit signalé depuis 2 ans sans avoir été corrigé soulève des questions
    • Comme OpenAI met l’accent sur la fiabilité, il serait peu logique de conserver volontairement cette non-déterminisme ; au départ, la limite matérielle insoluble semblait donc l’explication la plus plausible

Nouvelle hypothèse — un indice trouvé dans l’article Soft MoE

  • La section 2.2 de l’article Soft MoE fournit un lien explicatif déterminant
    • Sous contrainte de capacité (capacity constraints), toutes les approches Sparse MoE routent les tokens par groupes de taille fixe et imposent ou encouragent l’équilibrage à l’intérieur du groupe
    • Lorsque ces groupes contiennent des tokens issus de séquences/entrées différentes, ces tokens entrent en concurrence pour les places disponibles dans les buffers des experts
    • Le résultat est que le modèle est non déterministe au niveau de la séquence, et déterministe seulement au niveau du batch, certains inputs influençant la prédiction finale d’autres inputs
  • Le fait que GPT-4 soit un modèle Mixture of Experts est déjà connu publiquement
    • GPT-4 a été entraîné avant le deuxième trimestre 2022, et le Sparse MoE existait déjà auparavant
  • Hypothèse centrale proposée
    • L’API GPT-4 est hébergée sur un backend qui effectue la batched inference
    • D’autres facteurs peuvent jouer un rôle, mais l’essentiel de la non-déterminisme de l’API viendrait de l’incapacité de l’architecture Sparse MoE à imposer un déterminisme séquence par séquence

Vérification — confirmation qu’il ne s’agit pas d’un problème matériel

  • Pour tester l’hypothèse, un script de test a été demandé directement à GPT-4
    • Le script appelle à répétition avec temperature=0 le même prompt sur des modèles chat (gpt-4, gpt-3.5-turbo) et des modèles completion (text-davinci-003/001, davinci-instruct-beta, davinci), puis compte le nombre de sorties uniques
  • Problèmes rencontrés pendant l’écriture du script
    • Les réponses de l’API OpenAI étaient très lentes, avec près de 10 secondes de latence même sur 3.5 turbo ; un logging par horodatage a été ajouté pour vérifier que cela ne venait pas du script
    • Certains modèles completion coupaient leur réponse trop tôt ; une correction a été appliquée via un logit bias sur le token EOS
    • Pour le token <|im_end|> (100265) des modèles chat, il n’était pas possible d’appliquer un biais équivalent, l’API renvoyant une erreur de clé au-delà de la valeur maximale 100257
      • Comme la plupart des completions atteignaient la longueur max de tokens et que les modèles chat étaient déjà bien plus non déterministes, cette contrainte a été jugée secondaire

Résultats empiriques

  • Sur 3 essais, avec N=30 et max_tokens=128, sorties uniques (moyenne/30)
    • gpt-4 : 12, 11, 12 — moyenne 11,67
    • gpt-3.5-turbo : 4, 4, 3 — moyenne 3,67
    • text-davinci-003 : 3, 2, 4 — moyenne 3,00
    • text-davinci-001 : 2, 2, 2 — moyenne 2,00
    • davinci-instruct-beta : 1, 1, 1 — déterministe, sortie qui s’effondre en boucle répétitive
    • davinci : 1, 1, 1 — déterministe, sortie qui s’effondre en boucle répétitive
  • Résultats avec max_tokens=256 avant la découverte du problème de logit_bias
    • gpt-4 : 30, gpt-3.5-turbo : 9, text-davinci-003 : 5, text-davinci-001 : 2

Interprétation des résultats

  • Le nombre de sorties uniques de GPT-4 est anormalement élevé ; sur des sorties longues, il est en pratique presque toujours non déterministe
  • Les autres modèles qui ne s’effondrent pas en boucle répétitive présentent aussi un certain niveau de non-déterminisme, ce qui correspond à l’affirmation publique selon laquelle l’instabilité des calculs GPU serait à l’origine d’une partie de l’aléa
  • Questions restantes
    • Il n’existe pas d’explication claire au fait que l’aléa augmente progressivement de text-davinci-001 à gpt-3.5-turbo
    • On ne peut pas exclure totalement que la forte non-déterminisme de GPT-4 vienne simplement du nombre de paramètres et non du MoE ; toutefois, le fait que Turbo, plus rapide, soit plus non déterministe que davinci contredit cette explication

Implications

Nous sommes très en retard

  • Si la non-déterminisme est une propriété inhérente à la batched inference des Sparse MoE, cela devrait paraître évident aux personnes travaillant dans ce domaine
  • Le fait que la majorité des utilisateurs de GPT-4 ignorent l’origine de l’instabilité de l’API suggère soit que l’hypothèse est fausse, soit que trop peu de gens comprennent les modèles MoE pour que cette explication soit réellement débattue publiquement
  • Google Deepmind le savait, et le traite comme un détail suffisamment mineur pour l’évoquer en une phrase au passage dans un article, ce qui donne davantage de raisons d’être optimiste sur Deepmind que sur d’autres organisations focalisées uniquement sur les modèles denses

GPT-3.5-Turbo est peut-être aussi un MoE

  • Une rumeur affirme que 3.5-turbo partage la même architecture que GPT-4, avec simplement beaucoup moins de paramètres
  • Dans le contexte actuel, atteindre les performances de Turbo nécessiterait 70B de paramètres, ce qu’il est difficile d’expliquer par un unique modèle dense compte tenu du volume de trafic et des contraintes de vitesse chez OpenAI
  • Turbo est le seul autre modèle de l’API pour lequel les logprobs sont limités de manière non publique
    • L’explication habituelle était d’éviter d’améliorer la précision de la distillation, mais des exemples comme Orca rendent cette justification moins convaincante
    • Le fait qu’OpenAI ait annoncé publiquement travailler à l’intégration des logprobs dans ChatCompletions renforce l’idée que le vrai problème n’est pas tant la « protection contre la distillation » que le fait d’être intrinsèquement trop aléatoire pour permettre une ingénierie stable

Conclusion

  • Tout le monde sait que les modèles GPT d’OpenAI sont non déterministes à temperature=0
  • La cause généralement invoquée est l’imprécision des calculs en virgule flottante optimisés sur CUDA
  • L’autre hypothèse proposée ici est que la batched inference des modèles Sparse MoE constitue la cause fondamentale de la non-déterminisme de l’API GPT-4, une hypothèse plus élégante que l’explication classique
  • Il est montré empiriquement que les appels API à GPT-4 (et à certains modèles 3.5) sont bien plus non déterministes que ceux des autres modèles OpenAI
  • La vitesse, la non-déterminisme et la suppression des logprobs conduisent à estimer que GPT-3.5-turbo pourrait lui aussi être un MoE

À lire aussi

1 commentaires

 
GN⁺ 2023-08-06
Avis Hacker News

  • Les erreurs en virgule flottante sont généralement déterministes : si l’on exécute deux fois le même calcul, on devrait obtenir un résultat identique jusqu’au bit près.
    Les résultats ne divergent que s’il existe un autre état ou une source d’entropie, par exemple si un tampon n’est pas correctement initialisé à zéro, s’il y a une condition de concurrence, ou si les indicateurs de mode d’arrondi ne sont pas définis de façon cohérente.
    Vu la qualité du code bricolé à la hâte dans l’écosystème IA/ML, il est probable que ces trois cas se produisent, voire davantage.

    • Ce n’est pas le cas sur GPU : https://www.twosigma.com/articles/a-workaround-for-non-deter...
      Dans ce cas, le parallélisme du GPU rend non déterministe l’ordre dans lequel les nombres sont additionnés, et le résultat peut donc varier légèrement.
      Mieux vaut éviter de dénigrer le code des autres quand il s’agit de code écrit au-dessus de systèmes que l’on connaît mal.
      La même chose peut arriver sur CPU à cause du traitement parallèle, mais la plupart des instructions CPU individuelles sont déterministes, alors que CUDA fournit des opérations primitives non déterministes.
      C’est un choix de conception volontaire, car elles sont plus rapides que leurs équivalents déterministes ; le problème est de présenter cela comme un bug dû à du mauvais code.
    • Dès qu’il y a du parallélisme, cette affirmation peut ne plus tenir.
      Par exemple, certaines opérations en virgule flottante, comme l’addition ou la multiplication, ne sont pas associatives ; le résultat dépend donc de l’ordre d’exécution dans lequel une réduction (reduction) se termine.
      En contexte parallèle, certaines implémentations rendent l’ordre de réduction non déterministe pour des raisons de performance, ce qui rend aussi le résultat final non déterministe.
    • Mathématiquement, le calcul est déterministe, mais le dispositif physique qui l’exécute peut rendre le résultat logiciel dépendant du temps de plusieurs manières.
      Un simple appel à GetTimeOfDay() peut suffire, tout comme la dérive des fréquences d’horloge entre plusieurs processeurs.
    • Je me demande si, en simulant le problème du billard circulaire d’Alhazen sur n étapes, on obtiendrait le même résultat à chaque exécution.
      https://forumgeom.fau.edu/FG2012volume12/FG201216.pdf
    • À grande échelle, la simple absence d’une bonne mémoire ECC suffit à introduire de l’entropie.

  • Je ne suis pas sûr d’avoir bien compris l’extrait de l’article cité.
    Est-ce que cela signifie qu’une partie de l’inférence plus efficace repose sur le mélange de tokens issus d’entrées totalement distinctes, par exemple celles d’autres utilisateurs ? Et que, selon les autres entrées qui se retrouvent par hasard dans le même lot, le taux d’affectation aux « experts » change, ce qui modifie aussi la complétion finale ?
    Si c’est le cas, cela n’introduit pas seulement du non-déterminisme : la qualité de la réponse pourrait aussi dépendre du nombre de requêtes simultanées en concurrence pour la même affectation d’experts.
    Par exemple, la partie du système qui est bonne en traduction/interprétation de l’hindi pourrait produire de moins bons résultats aux heures de pointe en Inde, parce que davantage d’entrées se disputent simultanément la même capacité.
    Cela pourrait aussi expliquer autrement l’impression d’une baisse de qualité au fil du temps. Auparavant, un test donné réussissait de manière fiable parce que l’expert concerné était peu encombré ; désormais, avec l’augmentation de l’usage simultané, ce même test n’obtient peut-être plus suffisamment d’effort de la part de cet expert.
    Si un sous-expert impressionne d’abord dans un domaine donné, l’usage dans ce domaine peut affluer, puis la nouvelle congestion fait que les utilisations imitatives n’obtiennent plus la même affectation d’expert, ce qui fait retomber les performances initialement impressionnantes.
    Si l’effet est fort et qu’OpenAI le sait sans le divulguer, on pourrait y voir une sorte de produit d’appel : attirer les utilisateurs avec l’excellence non représentative d’un système Mixture-of-Experts initialement peu congestionné, puis leur servir les résultats de moindre qualité d’un système plus encombré.

    • Le résultat semble essentiellement donner 12 réponses uniques sur 30 essais, ce qui n’est pas ce à quoi on s’attendrait si les tokens étaient mélangés.
      Ils regroupent probablement les lots différemment. Par exemple, si l’on divise 10 lots en 2 groupes de 5, la réponse change selon que mon prompt se trouve dans le premier ou le second groupe ; s’il occupe la même position dans le lot, on obtient la même réponse.
      Pour un même lot, c’est-à-dire avec les mêmes séquences et le même ordre, l’ensemble du lot est déterministe, mais si l’on mélange les lots, on perd ce déterminisme.
    • C’est un résultat plausible et, s’il est vrai, les modèles d’OpenAI pourraient en pâtir fortement face aux modèles concurrents ou open source.
      Aujourd’hui encore, la fiabilité est l’un des principaux obstacles à l’adoption large des LLM dans de nombreux flux de travail critiques.
      Si les rumeurs selon lesquelles GPT-4 serait intrinsèquement non déterministe et instable sont vraies, la plupart des entreprises auraient intérêt à fine-tuner un LLM open source aux performances similaires pour leur domaine précis.
      Les modèles spécialisés par domaine surpassent toujours les modèles généralistes ; c’est donc aussi l’option qui offre le meilleur gain de performance.

  • Si GPT-3.5 est un modèle MoE, n’est-ce pas un signal plutôt encourageant pour le monde open source ?
    Si un bon modèle MoE open source apparaît, même sous une forme proche d’une variante des modèles décodeurs existants, cela voudrait dire qu’on peut faire beaucoup plus avec beaucoup moins de ressources.
    Je ne sais pas s’il faut entraîner les modèles MoE à partir de zéro.

    • Je suis d’accord, et j’espère vraiment que Meta travaille sur quelque chose dans cette direction.
      Une approche qui réduit le ratio FLOPs/mémoire, comme Soft MoE, pourrait aussi rendre l’inférence sur CPU, ou au moins sur Apple Silicon, plus pertinente.
    • Cela pourrait être défavorable aux environnements d’inférence qui tournent sur un seul GPU grand public.

  • Si les séquences d’un lot peuvent influencer mutuellement leur routage, j’ai l’impression que cela ouvre la porte à des attaques par canal auxiliaire étranges et difficiles à mettre en œuvre.

    • Je pense que oui. Cela dit, ce serait sans doute très difficile à exploiter en pratique.

  • C’est vraiment un excellent travail. Je suis fortement opposé aux MoE pour plusieurs raisons, mais c’est la première fois que je vois des preuves convaincantes, plutôt que des billets Substack ou des rumeurs répétées
    Je ne savais absolument pas que GPT-4 était non déterministe, alors que je l’utilise environ 2 heures par jour
    Je comprends pourquoi il est difficile de s’en rendre compte en y jetant simplement un coup d’œil. Dans mes souvenirs, le « ressenti » est similaire et il utilise beaucoup de vocabulaire semblable, mais la forme est complètement différente, avec quelques mots clés identiques remplacés comme par des expressions synonymes

    • Je ne suis pas spécialiste de la recherche sur les MoE, mais ce que j’ai lu dans l’article sur Soft MoE m’a donné envie de vérifier
      À voir les exemples du gist lié, les sorties non déterministes sont vraiment similaires : https://gist.github.com/152334H/047827ad3740627f4d37826c867a...
      Comme le caractère aléatoire devrait être limité, cette partie n’est au moins pas surprenante
      Je pense qu’OpenAI finira un jour par trouver un moyen de réduire cet aléa. C’est d’autant plus plausible qu’ils se sont publiquement engagés à rajouter les logprobs à ChatCompletions
    • Si tu utilises le chat web de GPT-4 deux heures par jour, c’est possible
      Mais si tu développes un programme en appelant l’API à répétition avec la même entrée, il est difficile de passer à côté de la non-déterminisme
    • Je suis curieux de savoir pourquoi tu étais fortement opposé aux MoE
    • Je me demande à quoi tu l’utilises. Je me demande aussi si tu utilises beaucoup les plugins
      Ça m’intéresserait de savoir quelles intuitions une personne qui l’utilise autant a pu tirer, y compris avec l’ensemble de fonctionnalités sorti cette semaine

  • MoE signifie Mixture of Experts, c’est-à-dire mélange d’experts

    • Merci. Je pensais que ça voulait dire Margin of Error
      L’acronyme n’est développé presque par hasard qu’à peu près au milieu de l’article ; le lectorat visé semble être familier avec le mélange d’experts, et je n’en faisais pas partie

  • Les modèles davinci-instruct-beta de GPT-3.0 renvoyaient déjà des logprobs non déterministes depuis début 2021
    Ce n’est qu’une supposition, et CUDA lui-même a souvent des bugs de non-déterminisme
    text-davinci-001 et text-davinci-002 ont été entraînés avec FeedMe et SFT, et text-davinci-003 avec RLHF
    Le modèle lui-même a aussi une variance plus grande à haute température

    • Et les modèles de base, c’est-à-dire davinci et code-davinci-002 ?

  • Si « ces tokens se disputent souvent les places disponibles dans le tampon des experts », est-ce aussi pour cette raison que ChatGPT met souvent de simples placeholders à la place des fonctions quand je lui demande du code long ?

  • « Ces tokens se disputent souvent les places disponibles dans le tampon des experts » : cela veut-il dire que les résultats changent quand la charge est élevée ?
    Est-ce que l’impression que la qualité des sorties varie parfois peut aussi s’expliquer par une forte charge ?

  • MoE signifie Mixture of Experts