공동 연구

FP8로 바꾸면 모델의 답이 달라질까? 120개 중 하나가 뒤집혔다

함께: Anagha Langhe · NVIDIA L4 한 장으로 LLM을 직접 운영

30초 요약

Anagha Langhe는 NVIDIA L4 한 장으로 언어 모델을 직접 운영하고 있고, FP8로 바꾸면 정확도가 떨어지는지 알고 싶어 했습니다. 120개 질문에서 두 빌드의 점수는 72점과 71점이었습니다. 이것만으로는 말할 수 있는 게 별로 없어서, 우리는 뒤집힌 문제를 세어 보았습니다. 바뀐 것은 하나였고, 그마저 bf16 쪽이 맞힌 문제였습니다. 글자까지 똑같은 답이 49개였고, 두 빌드가 모두 틀렸을 때는 48번 중 42번이 같은 오답이었습니다. Anagha가 공개 비교 스크립트를 자신의 두 실행 결과에 돌려 보니 숫자가 정확히 같았고, 그녀는 스스로 결론을 내렸습니다. 실수는 양자화가 아니라 검색에서 나온다는 것입니다.

질문

모델을 bf16 대신 FP8로 돌리면 필요한 메모리가 대략 절반으로 줄어듭니다. GPU 한 장으로 돌릴 때 FP8을 쓰는 이유가 바로 이것입니다. 걱정은 단순합니다. 더 작은 형식이 슬그머니 답을 나쁘게 만드는 건 아닐까요?

Anagha는 이를 직접 측정했습니다. 두 빌드에 똑같은 120개 질문을 던졌고, 결과를 LinkedIn에 정리했습니다. bf16은 72개 정답, FP8은 71개 정답, 정확 McNemar 검정은 p = 1.0이었습니다. 같은 글에서 그녀는 자신의 환경에서 나온 다른 수치도 하나 공유했습니다. 프리픽스 캐시 적중률이 12%에서 26%로 올랐다는 것입니다.

72 대 71은 "차이 없음"처럼 보입니다. 하지만 질문이 120개뿐이라면 이런 검정은 큰 폭의 하락만 걸러낼 수 있습니다. 3~4점쯤 떨어져도 유의하게 나오지 않을 가능성이 높습니다. 그래서 흥미로운 것은 p값이 아니라, 문제 하나하나에 실제로 무슨 일이 일어났는지입니다.

누가 무엇을 했나

  • Anagha는 환경을 구성하고, 같은 120개 질문에 두 빌드를 돌리고, 답을 채점했으며, 나중에 자신의 파일로 비교까지 직접 돌렸습니다.
  • 우리(Vadym Chernets)는 양방향으로 각각 몇 문제가 뒤집혔는지 물었고, 모델 간 일치를 확인하려고 관리하던 공개 스크립트에 작은 compare 모드를 추가했으며, 그녀의 요약으로 구간과 계획용 수치를 계산했습니다.
  • Anagha가 전체 데이터로 그 스크립트를 돌려 보내온 결과는 우리 숫자와 같았고, 요약만으로는 볼 수 없던 값이 하나 더 있었습니다. 두 빌드가 얼마나 자주 똑같은 방식으로 틀렸는가 하는 것입니다.

숫자는 이렇게 생겼다

질문 120개 두 빌드에 동일 bf16 정답 72 FP8 정답 71 71둘 다정답 1bf16만정답 0FP8만정답 48둘 다오답 둘 다 틀린 48개 중 42개는 같은 오답 · 6개는 서로 다른 오답
120개 질문은 각각 네 칸 중 하나에 들어갑니다. 대각선에서 벗어난 칸은 단 하나뿐이고, 공유된 실수의 대부분은 글자까지 같은 답입니다.
120개 중 1개두 빌드 사이에서 뒤집힌 질문, bf16에 유리한 방향
49글자 그대로 똑같이 돌아온 답
48개 중 42개공유된 실수 가운데 같은 오답이었던 것
항목 값
정확도, bf16 72 / 120
정확도, FP8 71 / 120
뒤집힘: bf16만 정답 / FP8만 정답 1 / 0
정확 McNemar 검정 p = 1.0
차이 bf16 − FP8 +0.8점, 95% 구간 약 −2.3 ~ +4.6
글자 그대로 같은 답 120개 중 49개
둘 다 틀렸고 오답도 같음 48개 중 42개

읽는 법. 뒤집힌 문제가 하나라는 것은 FP8의 비용이 0이라는 가설과 완전히 들어맞습니다. 하지만 비용이 0이라는 증거는 아닙니다. 2점 안팎의 하락은 구간 안에 여전히 들어가기 때문입니다. 뒤집힌 문제가 6개 미만이면 어느 방향이든 정확 McNemar 검정은 p < 0.05에 도달할 수 없습니다. 그래서 여기서 쓸모 있는 숫자는 뒤집힌 개수 자체와 구간입니다. 1점 차이를 보려면, 뒤집힌 것이 전부 같은 방향이라 해도 대략 800개의 질문이 필요합니다.

우리를 놀라게 한 것은 48개 중 42개입니다. FP8 빌드가 단순히 더 불안정한 것이라면 실수는 흩어져야 합니다. 그런데 두 빌드는 같은 질문에서 넘어지고 같은 오답에 도착합니다. Anagha의 표현대로라면 "실수는 양자화가 아니라 검색에서 나온다는 제 판단과 맞아떨어집니다." 가져온 문맥이 나쁘면 두 빌드가 같은 나쁜 문맥을 읽고 같은 말을 한다는 뜻입니다.

직접 돌려 보세요

같은 질문에 대한 두 번의 실행 결과가 JSONL(질문 id, 답, 그리고 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 표, 정확 McNemar 검정, 정확도 차이의 구간, 똑같은 답의 개수, 두 실행이 일치하면서 함께 틀린 비율, 그리고 질문에 카테고리가 있다면 카테고리별 분해가 나옵니다. --md report.md를 붙이면 보고서가 저장됩니다.

이 결과가 보여 주는 것과 보여 주지 못하는 것

  • 120개 질문이면 FP8이 이 모델을 망가뜨리지 않았다는 것은 확인할 수 있습니다. 하지만 1~2점의 하락이 없다고 장담하기에는 부족합니다.
  • 이 검정은 질문들을 서로 독립으로 가정합니다. 많은 질문이 하나의 문서나 하나의 템플릿에서 나왔다면 실제 표본은 120보다 작습니다.
  • "실수는 검색에서 나온다"는 Anagha가 자신의 시스템을 두고 내린 해석입니다. 48개 중 42개는 그 해석을 뒷받침합니다. 직접 확인하려면 같은 질문에 좋은 문맥과 나쁜 문맥을 한 번씩 주고 답하게 해야 합니다.

다음 단계

Anagha는 자신의 FP8 대 bf16 검사를 실제 사례로 저장소에 넣는 데 동의했고, 그녀의 이름이 함께 올라갑니다. 앞으로 두 빌드를 비교하려는 사람이 인위적인 예제 말고 진짜 사례에서 출발할 수 있게 하려는 것입니다.

타임라인

  1. Anagha가 LinkedIn에 FP8 검사를 올립니다. 120개 중 71 대 72, McNemar p = 1.0. 우리는 p값보다 뒤집힌 개수가 더 많은 것을 말해 준다는 댓글을 남깁니다. 그녀가 답글을 달았고, 우리는 양방향으로 각각 몇 문제가 뒤집혔는지 묻습니다.
  2. 그녀의 답은 이렇습니다. 딱 하나, bf16은 맞고 FP8은 틀린 문제뿐이고 반대 방향은 없으며, 120개 답 중 49개는 글자 그대로 같았습니다. 밤사이 공개 스크립트에 compare 모드가 생겼고, 우리는 그녀의 요약으로 계산한 구간과 계획용 수치를 보냅니다.
  3. Anagha가 자신의 두 실행 결과에 스크립트를 돌립니다. 숫자는 정확히 일치했고, 두 빌드가 모두 틀렸을 때는 48개 중 42개가 같은 오답이었습니다. 그녀는 실제 사례로 싣는 데 동의합니다.

← 모든 공동 연구 · 공동 연구 제안하기