Чи змінює FP8 відповіді моделі? Один переворот на 120

разом із Anagha Langhe · власна LLM на одній NVIDIA L4

За півхвилини

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

Питання

Запуск моделі у FP8 замість bf16 приблизно вдвічі зменшує потрібну їй пам'ять, і саме заради цього його роблять на одному GPU. Побоювання просте: чи не погіршує менший формат непомітно відповіді?

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

72 проти 71 виглядає як «різниці немає». Проте зі 120 питань такий тест може виключити лише велике падіння. Втрату в три-чотири пункти він, імовірно, все одно не показав би як значущу. Тож цікаве питання не p-значення, а те, що насправді сталося з кожним питанням.

Хто що робив

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, це «fits my read that the errors come from retrieval, not quantization»: коли знайдений контекст поганий, обидві збірки читають той самий поганий контекст і кажуть те саме.

Спробуйте на своїх прогонах

Якщо у вас є два прогони на тих самих питаннях у 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, McNemar p = 1,0. Ми коментуємо, що кількість переворотів каже більше за p-значення. Вона відповідає, а ми питаємо, скільки питань перевернулося в кожен бік.
11 листопада 2026Її відповідь: лише одне, bf16 вірно і FP8 хибно, жодного в інший бік, і 49 зі 120 відповідей слово в слово однакові. За ніч відкритий скрипт отримує режим compare, і ми надсилаємо їй інтервал та цифри для планування, пораховані за її підсумком.
12 листопада 2026Anagha запускає його на власних двох прогонах: цифри збігаються точно, а коли помилялися обидві збірки, вони давали ту саму хибну відповідь у 42 з 48. Вона погоджується на розібраний приклад.

← Усі співпраці · Запропонувати колаборацію