허깅페이스 MIC, PR 단계에서 버그 찾는다

허깅페이스(Hugging Face)⁠의 타렉 지아데(Tarek Ziadé)⁠가 11월 3일 블로그에 트랜스포머스(Transformers)⁠용 '모델 통합 계약(Model Integration Contract, MIC)' 표준안을 소개했습니다. 실제 체크포인트의 설정으로 줄여 만든 작은 모델에 대표적인 사용 경로를 돌려 보고, 사람이 검토해 둔 기준 결과와 같은지 CPU에서 확인하는 방식입니다.

UMT5 버그는 두 달 가까이 main에 남았습니다

글이 드는 사례는 2026년 7월 30일에 트랜스포머스가 T5에 파이토치(PyTorch)⁠의 SDPA(scaled dot-product attention)⁠를 켠 일입니다. 부작용으로 UMT5 디코더가 미래 토큰을 볼 수 있게 되어 학습 중에 맞혀야 할 답을 미리 엿볼 수 있었지만 오류는 나지 않았고, 버그는 거의 두 달 동안 main에 남았습니다. 트랜스포머스는 지원하는 모델 종류가 750개를 넘고 main에서 CPU 테스트 8만 8,000개 이상, 매일 GPU 테스트 20만 개 이상을 돌립니다. 글에 따르면 작은 UMT5 픽스처는 이 회귀 버그를 생긴 날인 7월 30일부터 수정이 들어간 9월 28일까지 계속 표시했습니다.

계약은 픽스처, 사용 경로, 기준 결과로 이뤄집니다

픽스처는 실제 체크포인트의 설정으로 줄여 만든 모델로 한 번 만들어 고정해 둡니다. 층 수와 폭은 줄여도 원래 모델에 있는 층 종류는 모두 남기고 토크나이저와 프로세서 파일도 그대로 씁니다. 사용 경로는 텍스트 생성이나 학습 한 단계처럼 사람들이 그 모델로 실제로 하는 일을 실행 가능한 마크다운 예제로 적은 것이고, 기준 결과는 그 예제를 돌려 기록한 출력을 사람이 검토한 값입니다. 픽스처에서 사용 경로를 돌렸을 때 기준 결과가 그대로 나오면 계약이 지켜진 것입니다. 계약 하나는 체크포인트 하나가 아니라 구조와 사용 경로에 걸리기 때문에 호환되는 체크포인트가 픽스처를 나눠 쓰고 기준 결과만 따로 가집니다.

SDPA는 기본 어텐션 경로인데 eager 어텐션 변형만 돌렸을 때는 UMT5 버그가 걸리지 않았습니다. 글은 픽스처가 실제 체크포인트와 같은 코드를 지나야 의미가 있다고 적고, 가중치 파일 형식도 원래대로 두어 사용자가 실제 체크포인트를 불러올 때 도는 변환 코드까지 시험하게 합니다.

1,086억 개 파라미터가 4,470만 개가 됩니다

라마 4 스카우트(Llama 4 Scout) 17B-⁠16E Instruct는 파라미터가 1,086억 개에서 4,470만 개로 줄고, 비전 쪽 34층은 2층, 언어 쪽 48층은 4층이 됩니다. UMT5 실험용 픽스처의 가중치는 66MB로 원본 체크포인트의 1,227MB보다 훨씬 작습니다. 수정을 되돌린 시험 가지에서 T5 계약을 돌리자 라벨 로그 확률이 검토한 기준값과 1.22, 학습 손실이 약 0.20 달랐고 실행 단계는 설정 시간을 빼고 CPU에서 13.4초가 걸렸습니다. 위스퍼(Whisper) 가중치 초기화 연구에서는 일부러 심은 결함 24개 중 무작위 가중치 픽스처가 18개, 한 번 과적합시킨 픽스처가 24개를 모두 잡았습니다(자체 발표 기준).

PR을 막지 않고 실패만 알립니다

11월 1일 기준으로 트랜스포머스 CI의 MIC 작업은 실패를 보고하되 PR을 막지는 않습니다. 막을지는 PR에서 실제 버그를 얼마나 잡는지, 헛경보로 얼마나 헤매게 하는지, 기준 결과 검토에 일이 얼마나 드는지처럼 아직 재지 못한 요소에 달려 있다고 글은 적습니다. 위스퍼에서는 두 픽스처 모두 실제 체크포인트로만 드러난 보조 디코딩 버그를 놓쳤고, 심은 결함이 합성이라 과적합판만 잡은 실제 회귀는 찾지 못했습니다. 기준 결과는 LLM이 초안을 쓰고 사람이 승인하며 픽스처가 전체 통합 테스트를 대신하지는 않습니다. 허브 모델 페이지와 MIC를 연결하는 일은 아직 계획으로만 적혀 있습니다.