[기획: AI 트렌드] 답은 맞았고 GPU마다 전문가가 전부 실려 있었다, transformers에 그것을 확인하는 테스트가 추가됐다
10월 16일 머지된 PR 하나
10월 16일, transformers에 PR 하나가 머지됐습니다. transformers는 Hugging Face가 GitHub에 공개한 파이썬 라이브러리입니다. 공개된 AI 모델을 내려받아 돌리는 데 쓰입니다.
PR은 코드를 이렇게 바꾸자는 요청입니다. 그 요청을 받아들여 본 코드에 합치는 일을 머지라고 합니다.
이 PR은 MoE(전문가 혼합) 모델에 관한 것입니다. MoE에서는 층 안의 한 부분을 '전문가'라는 작은 계산 단위 여럿으로 바꿔 둡니다. 그리고 토큰(모델이 글을 잘게 자른 단위)마다 그중 몇 개만 골라 씁니다. 큰 병원에 여러 과 전문의가 있어도, 환자 한 명은 그중 몇 명에게만 진료를 받는 것과 비슷합니다.
가중치는 모델이 학습으로 익힌 숫자들입니다. 전문가가 이 가중치에서 차지하는 비중은 다른 저장소 문서에 적힌 모델의 예로 가늠할 수 있습니다. 이번 PR의 수정 목록에 이름이 오르지 않은 NVIDIA의 Nemotron 3.5 Super VL입니다. 가중치 약 1,210억 개 가운데 약 1,130억 개가 전문가에 있고, 토큰 하나에 쓰이는 것은 약 130억 개입니다. 우리가 다시 대조하지는 못한 수치입니다. MoE는 계산을 아끼는 대신, 쓰지 않는 전문가까지 전부 들고 있어야 하는 설계입니다.
이번 PR로 고친 것은 MoE의 전문가 가중치를 GPU(AI 계산을 맡는 칩) 여러 장에 나눠 싣는 계획입니다. PR 제목 앞의 🚨는 깨지는 변경, 즉 기존 코드를 고쳐야 할 수도 있는 변경이라는 표시입니다.
GPU 여러 장에 나누는 계획
PR 제목은 「MoE: 모든 TP/EP 계획에서 전문가를 나누고, 그것을 테스트한다」입니다.
모델이 GPU 한 장의 메모리에 다 들어가지 않으면 여러 장에 나눠 싣습니다. 이렇게 나누는 일을 샤딩이라고 하고, 이 글에서는 나누기라고 부릅니다. 나눠 맡은 실행 단위 하나하나는 랭크라고 합니다(보통 GPU 한 장이 랭크 하나).
이 PR에서 다루는 나누기 방식은 두 가지입니다. TP(텐서 병렬)는 큰 가중치 덩어리 하나를 잘라 GPU마다 조각을 싣는 방식입니다. EP(전문가 병렬)는 전문가를 통째로 GPU마다 몇 개씩 나눠 싣는 방식입니다.
transformers에서는 어느 가중치를 어떤 방식으로 나눌지 모델마다 계획으로 적어 둡니다. 계획에서 전문가가 빠지면 전문가 가중치는 나뉘지 않고 GPU마다 통째로 남습니다.
답은 맞았다
PR 설명에 적힌 문제는 출력이 틀리는 것이 아니었습니다. 「전문가를 빠뜨린 MoE 병렬 계획으로도 출력은 여전히 맞게 나온다. 하지만 랭크마다 전문가가 전부 남는다.」
새 테스트의 설명문에는 이 결함이 드러나지 않은 이유가 적혀 있습니다. 「전문가를 빠뜨린 계획은 어떤 출력도 바꾸지 않은 채 랭크마다 전문가를 전부 남긴다. 그래서 수치를 확인하는 어떤 테스트로도 이 문제는 보이지 않는다.」
복제는 결과를 바꾸지 않는 안전한 기본값입니다. 그래서 계획에서 빠뜨린 실수가 오답이 아니라 낭비로 떨어집니다. 답을 보는 테스트가 이 실수를 못 본 것은 우연이 아니라 구조 때문이었습니다(우리 판단).
출력이 맞으니 메모리가 조금 더 드는 것뿐이라는 반론도 가능합니다. 정확성의 문제가 아니라는 점은 맞습니다. 그러나 앞의 NVIDIA 예의 수치로 셈하면 가중치의 약 93%가 전문가입니다(우리 계산). 다른 층을 다 나눠도, 전문가가 GPU마다 남으면 GPU 한 장의 가중치는 나누기 전의 9할 넘게 그대로입니다(우리 계산). 거꾸로 이번에 새로 생긴 TP 계획 10종은 어텐션은 복제한 채 전문가만 나눕니다. 전문가가 무게의 대부분이라 그것만 나눠도 몫이 크다는 뜻입니다.
계획을 고치고, 테스트를 하나 더했다
이 PR에서 기존 TP 계획을 보강한 모델은 EXAONE-MoE·Aria 등 6종이고, 항목 하나가 빠져 있던 Qwen3-Omni-MoE도 채웠습니다. TP 계획이 새로 생긴 모델은 Jamba·PhiMoE 등 10종이고, EP 계획이 새로 생긴 모델은 7종입니다.
고친 것은 계획만이 아닙니다. 새 테스트(test_moe_parallel_plans_shard_experts)에서는 TP와 EP 계획 모두가 전문가 가중치를 빠짐없이 덮는지를 확인합니다. 메모리를 재는 테스트가 아니라 계획의 구조를 확인하는 테스트입니다. 계획에서 전문가가 빠지면, 출력이 맞아도 이 테스트를 통과하지 못합니다.
작성자가 적은 확인 결과도 있습니다. GPU 2장에서 나눈 모델과 나누지 않은 모델의 출력 차이가 2e-6(0.000002) 이내였다고 합니다. 계산은 fp32(실수 하나를 32비트로 적는 부동소수점 형식)로 했습니다. 이 확인에서 비교한 것도 출력입니다. 고친 뒤에도 답이 그대로라는 뜻이고, 전문가가 계획에 덮였는지는 새 테스트가 확인합니다.
대가도 있습니다. 여러 GPU 나누기를 켜며 자동 계획(tp_plan="auto", 모델에 미리 적힌 계획을 쓰라는 설정)을 쓰면, 목록의 모델에서는 이제 전문가도 나뉩니다. PR 설명에 따르면 GPU 한 장당 메모리는 줄고 출력은 그대로입니다. 줄어드는 폭은 숫자로 적혀 있지 않습니다. 다만 GPU마다 전문가 가중치 전체를 읽던 코드는 이제 자기 조각만 보게 됩니다. 전문가 안쪽 크기도 TP로 묶은 GPU 수로 나눠떨어져야 합니다.
라우터(토큰을 어느 전문가에게 보낼지 고르는 부분)도 바뀌었습니다. GraniteMoe 계열과 Aria는 라우터 결과를 돌려주는 순서가 바뀌었습니다. Jamba는 라우터가 단순 선형층에서 전용 라우터 모듈로 바뀌고 함수 하나가 제거됐습니다. 모델 출력에 담기는 라우터 값은 그대로라서, 라우터를 직접 불러 쓰던 코드만 고치면 됩니다.
9월 30일 첫 코멘트부터 머지까지 리뷰가 이어졌고, 리뷰어 한 명이 두 차례 승인했습니다.
같은 주 릴리스, 그리고 남은 것
이 PR이 머지되기 하루 전, transformers의 새 릴리스 v5.20.0이 나왔습니다. 릴리스는 사용자가 내려받아 설치하는 정식 판입니다.
릴리스 노트에는 EP를 쓴 추론에서 속도 회귀가 있다는 공지가 실렸습니다. 추론은 학습을 마친 모델을 실제로 돌리는 일이고, 속도 회귀는 전보다 느려지는 것입니다. 최대한 빨리 고치는 중이라는 말도 함께 적혀 있습니다. 이 PR은 그 노트에 없고, PR 본문에도 이 회귀 이야기는 없습니다. 두 일의 관계는 우리가 연 문서 어디에도 적혀 있지 않습니다.
같은 릴리스에 새로 추가된 모델 일곱 종의 첫 항목은 Meta의 대형 MoE인 Muse Spark Open입니다. 자료 수집 단계에서 본 모델 추가 PR 기준으로 가중치는 모두 8,160억 개이고, 토큰마다 쓰이는 것은 420억 개입니다. 우리가 다시 대조하지 못한 수치이고, 이 모델은 이번 PR의 계획 목록에 없습니다. 규모의 예일 뿐이지만, 전문가 몫이 큰 모델일수록 계획이 전문가를 빠뜨렸을 때 GPU마다 남는 양도 커집니다(우리 판단).
이번 PR로 모든 MoE가 제대로 나뉘게 된 것은 아닙니다. GPT-OSS와 OpenAI Privacy Filter는 이번 범위에서 빠졌습니다. 전문가 가중치가 행과 열이 뒤바뀐 배열(전치)이고, 편향(bias) 항이 붙어 있기 때문입니다. 다른 PR로 넘긴 모델도 있습니다. 이 수정이 실릴 릴리스 번호는 아직 확인하지 못했습니다. 앞으로 볼 것은 이 번호와, 빠진 모델의 계획이 따로 고쳐지는지입니다.
앞선 글에서 우리는 MoE를 능력보다 효율을 얻는 설계로 봤습니다트랜스포머 다음은 무엇인가 — 틀린 질문에 답이 있다. 계산을 아끼는 그 효율은 그대로지만, 그 대가인 메모리를 GPU 여러 장이 나눠 지는 장치가 계획이고, 계획이 전문가를 빠뜨리면 그 장치가 조용히 꺼집니다.
우리는 이번 PR의 핵심을 계획 보강보다 새 테스트에서 봅니다. 복제처럼 결과를 바꾸지 않는 기본값 위에서는 실수가 오답이 아니라 낭비로 남고, 답을 채점하는 테스트로는 그 낭비가 보이지 않습니다. 이번 테스트도 메모리를 재지는 않고, 계획이 전문가를 빠짐없이 덮는지를 묻습니다. 효율의 결함은 그것을 따로 묻는 질문을 만들어야 보입니다.
유의
루틴 11회차 · 캐스케이드 ①(GitHub 1차 직접 열람 · 메인 PR·변경 파일·릴리스 3페이지 재열람 + DE 지적 인용 5건 재열람) · 직접 열람 도메인 = github.com뿐(HF·arXiv·openai.com·nvidia ENOTFOUND · WebFetch 요약 모델 경유) · 머지 시각·테스트 함수 본문 미확보(페이지 절단) · f13 규모·f14는 miner 단독 열람(본문 미재대조 표기) · 원장 f8 「기본값」은 메인 원장 저작 오류였고 R1 DE B1로 정정 · 델타 R2 should-fix 4 미반영(31행 f# 부재 · 33행 끝 f14→f5 이전 추론 · 39·61행 테스트 본문 미확보 상태의 「메모리를 재지 않는다」 · 11행 틀 문장 바인딩) · nit 5 미반영 · 렌더 약 10.6KB(출처 절 포함 · 목표 6~10KB 상단 소폭 초과) · 10-15·10-16 루틴 글이 main 미병합 상태에서 발행(허브 줄 위치 충돌 가능 · 메인 병합 몫) · planner·reviser 메인 수행(스폰 상한 8) · pm 추가: 닫는 통찰 단락(31·61행)이 테스트 본문 미확보 상태의 추론 · pipeline lens-return 행 sha는 기록 시점 바이트출처
- 기준일 = 2026년 10월 17일 오전(한국 시간).
- 우리가 직접 연 원문은 GitHub 페이지뿐이고, 요약 모델을 거쳐 내용을 돌려주는 웹 열람 도구(WebFetch)로 읽어 핵심 문장만 인용으로 대조했습니다. 머지 시각과 새 테스트의 코드 본문은 페이지가 잘려 확보하지 못했고, 페이지 시각은 시간대 표기가 없어 날짜만 적었습니다.
- Nemotron 3.5 Super VL과 Muse Spark Open의 규모 수치는 자료 수집 단계에서 한 번 열어 본 결과이고, 우리가 다시 대조하지 못했습니다.
- 이해관계: Refract는 글을 분석하고 쓰는 데 Anthropic의 Claude를 씁니다. 이 글이 다룬 사건에 Anthropic은 당사자로 관여하지 않았습니다.
- MoE 병렬 계획 PR 머지(2026-10-16)·문제 설명과 새 테스트 설명문·계획을 보강하거나 새로 만든 모델과 빠진 모델·작성자 확인 결과·깨지는 변경·리뷰 경과 — 직접 열람 huggingface/transformers PR #49206
- 같은 PR의 변경 파일 — 직접 열람 PR #49206 변경 파일
- v5.20.0 릴리스(2026-10-15)·EP 추론 속도 회귀 공지·새 모델 목록 — 직접 열람 transformers v5.20.0 릴리스 노트
- Muse Spark Open의 규모(모델 추가 PR) — 자료 수집 단계 열람, 재대조 못 함 huggingface/transformers PR #49644
- Nemotron 3.5 Super VL의 가중치 구성(이번 PR 수정 목록에 없는 모델 · 2026-09-09 머지) — 자료 수집 단계 열람, 재대조 못 함 NVIDIA-NeMo/Automodel PR #3801