Le FP8 change-t-il les réponses d'un modèle ? Un basculement sur 120

La question

Faire tourner un modèle en FP8 plutôt qu'en bf16 divise à peu près par deux la mémoire dont il a besoin, ce qui est tout l'intérêt sur un seul GPU. L'inquiétude est simple : le format plus petit dégrade-t-il discrètement les réponses ?

Anagha l'a mesuré directement. Elle a posé les mêmes 120 questions aux deux versions et l'a raconté sur LinkedIn : 72 bonnes réponses en bf16, 71 en FP8, un test de McNemar exact avec p = 1,0. Dans le même post, elle partageait un autre chiffre de son installation : le taux de succès du cache de préfixes passé de 12 % à 26 %.

72 contre 71, cela ressemble à « aucune différence ». Avec 120 questions, pourtant, un test de ce genre ne peut écarter qu'une forte baisse. Une perte de trois ou quatre points ne ressortirait probablement toujours pas comme significative. La question intéressante n'est donc pas la valeur p, mais ce qui s'est réellement passé pour chaque question.

Qui a fait quoi

• Anagha a monté l'installation, fait tourner les deux versions sur les mêmes 120 questions, noté les réponses, puis exécuté la comparaison sur ses propres fichiers.
• Nous (Vadym Chernets) lui avons demandé combien de questions avaient basculé dans chaque sens, puis ajouté un petit mode compare à un script ouvert que nous entretenons pour vérifier l'accord entre modèles, et calculé l'intervalle et les chiffres de planification à partir de son résumé.
• L'exécution de ce script par Anagha sur l'ensemble de ses données a donné les mêmes chiffres, plus un que nous ne pouvions pas voir dans le résumé : la fréquence à laquelle les deux versions se trompaient de la même façon.

À quoi ressemblent les chiffres

Comment lire cela. Un seul basculement est tout à fait compatible avec un FP8 qui ne coûte rien. Ce n'est pas la preuve qu'il ne coûte rien : une baisse de quelques points tient encore dans l'intervalle. Avec moins de six basculements, un test de McNemar exact ne peut pas atteindre p < 0,05, quelle que soit leur direction ; ici, les chiffres utiles sont donc les basculements eux-mêmes et l'intervalle. Pour voir une baisse d'un point, il faudrait environ 800 questions, même si tous les basculements allaient dans le même sens.

Les 42 sur 48, c'est ce qui nous a surpris. Si la version FP8 était simplement plus bruitée, ses erreurs seraient dispersées. Or les deux versions butent sur les mêmes questions et tombent sur la même mauvaise réponse. Selon les mots d'Anagha, cela « colle avec ma lecture : les erreurs viennent de la récupération, pas de la quantification » : quand le contexte récupéré est mauvais, les deux versions lisent le même mauvais contexte et disent la même chose.

À essayer sur vos propres exécutions

Si vous avez deux exécutions sur les mêmes questions au format JSONL (un identifiant de question, la réponse, et soit un champ correct, soit un fichier de référence), la comparaison tient en une commande. Elle fait partie du dépôt ouvert memory-agreement-check, licence MIT, sans dépendances :

git clone https://github.com/vadimchernets/memory-agreement-check
cd memory-agreement-check
python -m memcheck compare bf16.jsonl fp8.jsonl --label-a bf16 --label-b FP8

Une ligne par question ressemble à ceci :

{"qid": "q001", "answer": "Paris", "correct": true, "category": "factual"}

Il affiche le tableau 2×2, le test de McNemar exact, l'intervalle de la différence d'exactitude, le nombre de réponses identiques, la fréquence à laquelle les deux exécutions s'accordent tout en étant fausses, et une ventilation par catégorie si vos questions en ont une. --md report.md enregistre le rapport.

Ce que cela montre, et ce que cela ne montre pas

• 120 questions suffisent pour voir que le FP8 n'a pas saccagé ce modèle. Elles ne suffisent pas pour garantir l'absence d'une baisse d'un ou deux points.
• Le test traite les questions comme indépendantes. Si beaucoup viennent d'un même document ou d'un même gabarit, l'échantillon réel est plus petit que 120.
• « Les erreurs viennent de la récupération » est la lecture qu'Anagha fait de son propre système. Les 42 sur 48 la soutiennent ; la vérifier directement reviendrait à répondre aux mêmes questions une fois avec un bon contexte et une fois avec un mauvais.

La suite

Anagha a accepté que son contrôle FP8 contre bf16 entre dans le dépôt comme exemple concret, à son nom, afin que la prochaine personne qui compare deux versions ait un vrai cas pour démarrer, et pas seulement un cas synthétique.

Chronologie

1. 11 novembre 2026Anagha publie son contrôle FP8 sur LinkedIn : 71 contre 72 sur 120, McNemar p = 1,0. Nous commentons que le nombre de basculements en dit plus que la valeur p. Elle répond, et nous lui demandons combien de questions ont basculé dans chaque sens.
2. 11 novembre 2026Sa réponse : une seule, juste en bf16 et fausse en FP8, aucune dans l'autre sens, et 49 des 120 réponses identiques mot pour mot. Dans la nuit, le script ouvert reçoit son mode compare, et nous lui envoyons l'intervalle et les chiffres de planification calculés à partir de son résumé.
3. 12 novembre 2026Anagha l'exécute sur ses deux exécutions : les chiffres concordent exactement, et quand les deux versions se trompaient, elles donnaient la même mauvaise réponse dans 42 cas sur 48. Elle accepte l'exemple concret.