개발사조차 “사소한 변경”이라 지나친 곳.
Darwin은 모델의 부품 72,317개를 하나씩 열어봤다.
DeepSeek‑V4‑Flash를 가중치(모델이 학습으로 얻은 실제 숫자값) 한 겹까지 뜯었다. 공식 문서가 설명을 건너뛴 ‘전문가 배치’와 ‘층 연결’ 구조에서, 아직 누구도 공개하지 않은 두 가지 사실을 직접 측정해 꺼냈다.
해부 대상
DeepSeek‑V4‑Flash‑0731 (자유이용 라이선스 MIT). 개발사 설명을 인용한 게 아니라, 실제 파일의 부품 하나하나를 직접 읽어 다시 그린 골격이다. 낯선 용어는 옆에 풀어 두었다.
| 구성 | 측정값 | 쉽게 말하면 |
|---|---|---|
| 층(레이어) | 43개 · 전부 MoE | 모든 층이 ‘전문가 여럿 중 일부만 뽑아 쓰는’ 방식. 통짜로 다 쓰는 층이 하나도 없음 |
| 기억 처리(어텐션) | MLA · 헤드 64 / 기억채널 1 | 64개 시선이 참고하는 ‘기억(KV)’을 512칸짜리 요약본 하나로 압축 → 메모리 대폭 절약 |
| 전문가(FFN) | 256명 + 공용 1명 · 6명 선발 | 토큰(단어조각)마다 256명 중 6명 + 공용 1명만 일함 |
| 전문가 선발 방식 | sqrtsoftplus · noaux_tc | 점수 계산이 흔한 방식(softmax)이 아닌 신형. ‘벌점’ 없이도 일감이 골고루 가게 설계 |
| 층 연결 | MHC (하이퍼‑커넥션) | 층과 층을 잇는 표준 배선(잔차)을 대체한 신형 배선 |
| 정밀도(저장 형식) | fp8 + 블록 스케일 | 숫자를 8비트로 압축 저장 → 용량 절반, 속도 이득 |
| 속도 가속 | DSpark (40~42층) | 다음 단어들을 미리 넘겨짚어 빠르게 뱉는 장치를 모델에 아예 내장 |
덩치는 2,840억. 그런데 한 단어를 만들 때 실제로 일하는 건 4.5%뿐이다.
전체의 97.4%가 ‘전문가’에 들어 있다. 하지만 토큰마다 256명 중 6명 + 공용 1명 + 기억처리만 깨어난다 → 실제 계산량은 128억 규모.
덩치는 초대형인데 돌리는 비용은 소형급. 그래서 “집에서 돌아가는 프론티어 코딩 모델”이 성립한다.
1만 권 서재인데 질문 하나에 7권만 펴 읽는 셈. 라마 70B 같은 통짜 모델은 매번 700억 전부를 쓴다 — V4‑Flash는 덩치 4배인데 계산비는 1/5.
첫 3개 층은 전문가를 “고르지” 않는다 — 미리 짜둔 완벽 균형표를 그냥 펼친다.
0·1·2번 층에는 tid2eid [12만9280 × 6]이라는 배정표가 박혀 있다. 단어조각마다 담당 전문가 6명이 고정. 그 표를 열어보니 — 아무렇게나가 아니라 정교하게 균형 맞춘 표였다.
| 지표 | 값 |
|---|---|
| 일감 받은 전문가 | 256 / 256 |
| 전문가당 평균 배정 | 3,030 |
| 최소 ~ 최대 | 2,703 ~ 3,397 |
| 들쭉날쭉 정도(편차) | 5% |
| 한 단어의 6명 전원 다름 | 100% |
MoE 모델은 초기 층에서 일부 전문가에게만 일이 쏠려 나머지가 죽는 현상(라우터 붕괴)이 고질병이다. V4‑Flash는 첫 3층만 ‘완벽 균형 배정표’로 대체해 이 붕괴를 원천 차단하고, 그만큼 선발 계산도 아꼈다.
신입 3개월은 자유 배치 대신 인사팀이 미리 짜둔 완벽 균형표대로 일을 준다 — 특정 팀 과부하도, 노는 팀도 없게. 보통 MoE(Mixtral·이전 DeepSeek)는 첫 층부터 매번 계산해 뽑다가 초반에 쏠림이 생긴다.
배정 방식이 전문가의 “개성”을 만든다 — 표로 나누면 균질, 경쟁시키면 특화.
발견 1의 결과가 가중치에 남아 있었다. 전문가들이 서로 얼마나 다른지(크기의 들쭉날쭉함)를 층별로 재보니, 표로 배정한 층과 경쟁으로 뽑는 층이 9배 갈렸다.
“어떻게 배정하느냐가 전문가가 얼마나 특화되느냐를 결정한다”는 걸, 원인(배정표)과 결과(개성)를 같은 모델 안에서 둘 다 측정해 보인 첫 사례. MoE 설계자에게 ‘배정 방식 = 특화 조절 손잡이’라는 실증 교훈.
모두에게 일을 똑같이 나눠주면 다들 비슷한 제너럴리스트가 되고, 잘하는 사람에게 몰아주면 각자 전문분야가 갈린다. 표배정층 개성 0.4%(복사한 듯 균일) ↔ 경쟁선발층 3.4%(뚜렷) = 9배.
이 모델은 채팅이 아니라 “코드베이스를 헤집는 에이전트”를 위해 태어났다.
설계 하나하나가 코딩 에이전트(SWE‑bench 같은 자동 수정 작업)의 부하와 정확히 맞물린다. 예를 들어 SWE‑bench 과제 하나 = 레포 수만 줄 읽기 + 수십 번 고치고 테스트 돌리기다.
| 에이전트가 하는 일 | V4‑Flash 설계 | 왜 맞물리나 |
|---|---|---|
| 레포·로그·수십 턴을 다 읽음 | 105만 글자 맥락 + 기억 압축 | 채팅은 이만큼 안 읽는다 — 긴 맥락을 싸게 |
| 큰 수정·긴 도구호출을 길게 뱉음 | 출력 38만 글자 | 보통 모델 출력의 10배 이상 |
| 탐색→수정→테스트 수십 회 호출 | 활성 128억 + 속도장치 내장 | 호출 많은 작업을 싸고 빠르게 |
| 형식·도구를 일관되게 지킴 | 균형 배정 + 안정 선발 | 형식 붕괴 없는 일관 출력 |
우리도 두 번 틀릴 뻔했고, 두 번 잡았다
정밀함은 화려함이 아니라 스스로 의심하고 검증하는 데서 나온다.
압축 스케일의 유사도가 0.92 → “전문가끼리 92% 겹친다”처럼 보였다. 알고 보니 압축 보정이 균일하다는 뜻일 뿐, 실제 중복이 아니었다. 헤드라인으로 쓰지 않았다.
압축된 숫자를 원래대로 되돌리지(역양자화) 않고 재보니 전 전문가가 “똑같다”고 나왔다. 이는 측정 착오. 제대로 복원해야 함을 확인하고 그 결론을 버렸다.