Меняет ли FP8 ответы модели? Один сдвиг на 120

вместе с Anagha Langhe · собственная LLM на одной NVIDIA L4

За полминуты

Anagha Langhe сама запускает языковую модель на одной карте NVIDIA L4 и хотела понять, не теряется ли точность при переходе на FP8. На 120 вопросах две сборки набрали 72 и 71. Само по себе это мало что говорит, поэтому мы посчитали, сколько ответов перевернулось: один, причём в пользу bf16. 49 ответов совпали слово в слово, а когда ошибались обе сборки, они давали один и тот же неверный ответ 42 раза из 48. Anagha запустила открытый скрипт сравнения на своих двух прогонах, получила в точности те же цифры и сама сделала вывод: ошибки идут от поиска по контексту, а не от квантизации.

Вопрос

Запуск модели в FP8 вместо bf16 примерно вдвое снижает нужную память, ради этого на одной видеокарте всё и затевается. Опасение простое: не делает ли более компактный формат ответы тихо хуже?

Anagha измерила это напрямую. Она задала одни и те же 120 вопросов обеим сборкам и описала результат в LinkedIn: 72 верных в bf16, 71 в FP8, точный критерий Макнемара, p = 1,0. В том же посте она привела ещё одну цифру из своей установки: доля попаданий в префиксный кэш выросла с 12% до 26%.

72 против 71 выглядит как «разницы нет». Но на 120 вопросах такой критерий способен исключить лишь большое падение. Потерю в три-четыре пункта он, скорее всего, всё равно не признал бы значимой. Поэтому интересен не p-value, а то, что на самом деле произошло с каждым вопросом.

Кто что делал

Anagha собрала установку, прогнала обе сборки на одних и тех же 120 вопросах, проверила ответы, а позже запустила сравнение на собственных файлах.
Мы (Vadym Chernets) спросили, сколько вопросов перевернулось в каждую сторону, затем добавили небольшой режим compare в открытый скрипт, который держим для проверки согласия моделей, и по её сводке посчитали интервал и цифры для планирования.
Запуск этого скрипта на её полных данных дал те же числа и ещё одно, которое по сводке мы увидеть не могли: как часто две сборки ошибались одинаково.

Как выглядят цифры

Каждый из 120 вопросов попадает в одну из четырёх клеток. Лишь одна лежит вне диагонали. Большинство общих ошибок — один и тот же ответ.

1 из 120вопросов перевернулся между сборками, в пользу bf16

49ответов совпали слово в слово

42 из 48общих ошибок были одним и тем же неверным ответом

Показатель	Значение
Точность, bf16	72 / 120
Точность, FP8	71 / 120
Сдвиги: верно только bf16 / верно только FP8	1 / 0
Точный критерий Макнемара	p = 1,0
Разница bf16 − FP8	+0,8 пункта, 95-процентный интервал примерно от −2,3 до +4,6
Одинаковые ответы, слово в слово	49 из 120
Обе неверны, ответ один и тот же	42 из 48

Как это читать. Один сдвиг полностью согласуется с тем, что FP8 ничего не стоит. Но это не доказательство: падение на пару пунктов в интервал всё ещё укладывается. Если сдвигов меньше шести, точный критерий Макнемара не может дать p < 0,05, в какую бы сторону они ни шли, так что полезны здесь сами сдвиги и интервал. Чтобы заметить падение на один пункт, понадобилось бы примерно 800 вопросов, и то если бы все сдвиги шли в одну сторону.

Больше всего нас удивили эти 42 из 48. Будь FP8-сборка просто шумнее, её ошибки разлетались бы кто куда. А вместо этого обе сборки спотыкаются на одних и тех же вопросах и приходят к одному и тому же неверному ответу. По словам Anagha, это «совпадает с моим прочтением, что ошибки идут от поиска, а не от квантизации»: когда найденный контекст плох, обе сборки читают один и тот же плохой контекст и говорят одно и то же.

Попробуйте на своих прогонах

Если у вас есть два прогона на одних и тех же вопросах в формате JSONL (идентификатор вопроса, ответ и либо поле correct, либо файл с эталоном), сравнение делается одной командой. Оно входит в открытый репозиторий memory-agreement-check, лицензия MIT, без зависимостей:

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

Одна строка на вопрос выглядит так:

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

Скрипт выводит таблицу 2×2, точный критерий Макнемара, интервал для разницы точности, число одинаковых ответов, как часто два прогона сходятся и оба неправы, а если у вопросов есть категории, то и разбивку по ним. Флаг --md report.md сохраняет отчёт.

Что это показывает, а что нет

120 вопросов хватает, чтобы увидеть: FP8 не испортил эту модель. Но не хватает, чтобы ручаться, что нет падения на пункт-два.
Критерий считает вопросы независимыми. Если многие из них взяты из одного документа или одного шаблона, реальная выборка меньше 120.
«Ошибки идут от поиска» — это прочтение Anagha её собственной системы. 42 из 48 его подкрепляют; проверить напрямую значило бы ответить на те же вопросы один раз с хорошим контекстом и один раз с плохим.

Что дальше

Anagha согласилась, чтобы её проверку FP8 и bf16 добавили в репозиторий как разобранный пример с указанием её авторства, чтобы у следующего, кто сравнивает две сборки, был настоящий случай для старта, а не только синтетический.

Хронология

11 ноября 2026Anagha публикует в LinkedIn свою проверку FP8: 71 против 72 из 120, критерий Макнемара p = 1,0. Мы комментируем, что число сдвигов говорит больше, чем p-value. Она отвечает, и мы спрашиваем, сколько вопросов перевернулось в каждую сторону.
11 ноября 2026Её ответ: всего один, bf16 верно, а FP8 неверно, в обратную сторону ни одного, и 49 из 120 ответов совпали слово в слово. За ночь в открытом скрипте появляется режим compare, и мы отправляем ей интервал и цифры для планирования, посчитанные по её сводке.
12 ноября 2026Anagha запускает его на своих двух прогонах: цифры сходятся точно, а когда ошибались обе сборки, неверный ответ у них совпал в 42 случаях из 48. Она соглашается на разобранный пример.

← Все совместные работы · Предложить коллаборацию