왜 초대형 MoE는 "흩어서" 추론할 수 있는가
왜 초대형 MoE는 "흩어서" 추론할 수 있는가 분산 추론 기술 심층 분석 발행일: 2026년 7월 17일 — mmap과 NVMe, 200Gb/s WAN, 그리고 2조 파라미터 모델의 분산 추론 한 줄 요약: 4,280억 파라미터 모델이 121GB짜리 머신 한 대에서 돌아간다. 마법이....
왜 초대형 MoE는 "흩어서" 추론할 수 있는가
분산 추론 기술 심층 분석
발행일: 2026년 7월 17일
— mmap과 NVMe, 200Gb/s WAN, 그리고 2조 파라미터 모델의 분산 추론
한 줄 요약: 4,280억 파라미터 모델이 121GB짜리 머신 한 대에서 돌아간다. 마법이 아니라 세 가지 사실 — MoE의 희소성, 운영체제의 demand paging, 그리고 메모리 계층을 네트워크 너머로 늘리는 방법 — 이 맞물린 결과다. 이 글은 그 원리를 실측 수치와 함께 뜯어보고, 같은 원리가 2조 파라미터 프론티어 모델을 어떻게 감당할지까지 밀어붙인다.
0. 시작은 한 장면에서
통합 메모리 121GB 짜리 NVIDIA GB10(Grace Blackwell) 한 대. 여기에 MiniMax M3 — 4,280억 파라미터 MoE 를, 4비트 양자화(UD-IQ4_XS)로도 207GB 인 모델을 올렸다. 산술적으로 말이 안 된다. 207GB 모델이 121GB 메모리에 들어갈 리 없다.
그런데 돌아간다. 일관된 문장을 생성한다. 초당 약 1토큰.
프로세스 메모리 (M3 서버):
VmSize (가상): 241.7 GB ← 모델 전체를 mmap한 가상 주소공간
VmRSS (물리): 114.7 GB ← 실제 RAM 상주분은 이것뿐 (< 207GB!)
VmSwap: 0.4 GB
NVMe 로컬 읽기: 2.5 GB/s
물리 RAM에 상주하는 건 114.7GB — 모델보다 90GB 이상 작다 . 나머지는 어디에? 그리고 그건 무엇을 의미하나? 이 질문의 답이 곧, 왜 MoE 추론이 "한 대에 다 담기"에서 "여러 대에 흩뿌리기"로 넘어갈 수 있는지에 대한 답이다.
1. MoE라는 구조 — 희소성이 전부다
Dense 트랜스포머는 매 토큰마다 모델의 모든 파라미터를 통과시킨다. 70B 모델이면 토큰 하나에 700억 개 전부가 곱셈에 참여한다.
Mixture-of-Experts(MoE)는 다르다. MiniMax M3의 구조를 실측으로 보면:
속성
값
총 레이어
60 (앞 3층 dense, 뒤 57층 MoE)
레이어당 전문가 수
128
토큰당 활성 전문가
4 (top-4 라우팅)
n_embd
6144
전문가 FFN 차원
3072
핵심은 마지막 두 줄이 아니라 "128개 중 4개" 다. 각 MoE 레이어에는 128개의 전문가 FFN이 있지만, 토큰 하나는 그중 4개만 건드린다. 모델은 57개 레이어 × 128개 = 7,296개의 전문가 를 들고 있는데, 토큰 하나가 실제로 계산하는 건 57 × 4 = 228개뿐이다.
이 한 문장이 모든 것의 출발점이다: 파일 크기를 지배하는 200GB가 넘는 전문가 행렬은, 매 순전파에서 극히 일부를 빼면 놀고 있다. 활성 파라미터로 치면 428B 모델이 토큰당 ~23B만 계산한다. 희소성 비율이 20:1에 육박한다.
Dense 모델이었다면 이야기는 여기서 끝난다 — 전부 필요하니까 전부 빠른 메모리에 있어야 한다. MoE는 "전부"라는 전제를 깨뜨린다. 그리고 이 깨진 전제 위에서 나머지 모든 것이 가능해진다.
2. 메모리 벽 — 전체를 빠른 메모리에 담을 수 없다
전통적 추론의 암묵적 전제는 "모델 전체가 빠른 메모리(VRAM 또는 RAM)에 상주한다"이다. 이 전제는 모델이 커질수록 무너진다.
모델 규모 (4비트)
대략 크기
단일 GPU VRAM으로?
70B dense
~40GB
H100 80GB에 겨우
405B dense
~230GB
불가 (다중 GPU 필수)
428B MoE (M3)
207GB
단일 GPU 불가
2T MoE
~1TB
어떤 단일 노드도 불가
2조 파라미터급 프론티어 MoE는 4비트로도 1테라바이트다. 세상 어떤 단일 머신의 RAM/VRAM도 이걸 담지 못한다. 여기서 두 갈래 길이 갈린다:
포기하고 모델을 쪼개 여러 GPU에 텐서 병렬로 편다 (전통적 방식 — 비싸고, 모든 노드가 모델의 자기 몫을 빠른 메모리에 들어야 한다).
"전체를 빠른 메모리에"라는 전제 자체를 버린다.
MoE의 희소성은 2번을 실현 가능하게 만든다. 왜냐하면 필요한 건 전체가 아니라 "지금 이 토큰의 작업 세트"이기 때문이다.
3. 통찰 — 희소성은 "저장" 문제를 "캐시" 문제로 바꾼다
이게 이 글의 중심 명제다.
모델 전체를 빠른 메모리에 담을 필요가 없다. 지금 활성인 작업 세트 (백본 + 이번 토큰들이 라우팅한 전문가들)만 빠른 메모리에 있으면 된다. 차갑게 식은 나머지 전문가들 — 대부분의 무게 — 은 더 느리고, 더 멀고, 더 싼 곳에 두고 필요할 때 가져오면 된다.
즉 초대형 MoE 추론은 본질적으로 계층적 캐싱 문제 다. 뜨거운 것은 가까이, 차가운 것은 멀리. 그리고 캐싱 문제에는 두 개의 자유도가 있다:
어디에 차가운 것을 둘 것인가 (cold tier의 위치)
얼마나 빨리 가져올 수 있는가 (fetch 경로의 대역폭과 지연)
이 두 자유도를 어떻게 선택하느냐가 곧 아키텍처다. 그리고 놀랍게도, 단일 노드 서빙과 분산 스웜은 이 두 자유도의 서로 다른 선택일 뿐 같은 원리다.
4. 세로 방향 — mmap과 NVMe (단일 노드가 자기보다 큰 모델을 서빙하는 법)
cold tier를 로컬 NVMe SSD 에 두는 선택. 이게 서두의 GB10이 한 일이다.
세로 방향 아키텍처: 모델 파일은 NVMe에 있고, mmap을 통해 가상 메모리에 매핑됩니다. 필요한 전문가(활성 작업 세트)만 페이지 폴트를 통해 물리 RAM으로 로드됩니다.
커널이 로더다, 애플리케이션이 아니라
llama.cpp는 GGUF 파일을 통째로 읽어 RAM에 올리지 않는다. mmap() 으로 파일을 가상 주소공간에 매핑 한다. 그 순간 프로세스는 "207GB짜리 배열이 메모리에 있다"고 믿지만, 물리 RAM은 한 바이트도 채워지지 않았다. 페이지는 건드릴 때 비로소 올라온다.
토큰 하나를 디코드하는 과정을 따라가 보면:
라우터가 이 토큰의 top-4 전문가를 고른다.
llama.cpp가 그 전문가들의 가중치를 그냥 메모리 주소로 읽는다. read() 같은 시스템 콜은 없다.
그 페이지가 RAM에 없으면 → CPU의 MMU가 page fault (하드웨어 트랩)를 일으킨다.
커널의 page fault 핸들러 가 이를 받아 NVMe의 mmap 파일에서 해당 페이지를 RAM으로 읽고, 페이지 테이블을 갱신하고, 멈췄던 명령을 재개한다.
llama.cpp는 이 모든 걸 전혀 모른다. 포인터를 역참조했더니 데이터가 있었을 뿐. 디스크 I/O는 커널이 뒤에서 처리했다.
"나머지는 누가 로드하느냐"의 답은 운영체제의 가상메모리 서브시스템 이다. 애플리케이션이 아니라. 이걸 demand paging(요구 페이징) 또는 lazy loading이라 부른다.
실측 증거
M3 서버에 12토큰짜리 생성 하나를 던지고 page fault 카운터를 앞뒤로 쟀다:
major page fault: 1,871,360 → 1,929,921 = +58,561회 (≈229MB를 NVMe에서 끌어옴)
minor page fault: 5,144,417 → 5,296,372 = +151,955회 (이미 RAM 캐시에 있던 페이지)
major fault 는 디스크 I/O가 필요했던 접근 — 즉 커널이 NVMe에서 새로 끌어온 페이지. 12토큰에 58,561회, 토큰당 약 4,880페이지 × 4KB ≈ 19MB/토큰 을 NVMe에서 가져왔다. minor fault 는 이미 페이지 캐시(RAM)에 있어 디스크를 안 탄 것 — 뜨거운 백본과 자주 쓰는 전문가들이다.
왜 스왑을 안 쓰나 (VmSwap ≈ 0)
모델 가중치는 읽기 전용 + 파일 기반 이다. RAM이 꽉 차면 커널은 차가운 페이지를 그냥 버린다 (dirty가 아니라 write-back이 불필요). 나중에 필요하면 원본 GGUF에서 다시 읽으면 그만이다. 즉 NVMe의 GGUF 파일 자체가 이 페이지들의 백킹 스토어 다 — 별도 스왑 공간이 아니라. 읽기 전용 mmap은 evict 비용이 0인 "무한 용량 캐시"처럼 동작한다. mmap의 우아함이 여기 있다.
희소성이 없으면 무너진다
이게 오직 MoE이기 때문에 실용적이라는 걸 강조해야 한다. 만약 같은 207GB가 dense 모델 이었다면 매 토큰이 모델 전체를 읽어야 한다:
dense 207GB ÷ NVMe 2.5GB/s = 토큰당 ~83초 (사용 불가)
MoE (실측): 토큰당 ~1초 (쓸 만함)
약 100배 차이. mmap은 큰 모델을 담을 수 있게 하지만, 그걸 *쓸 만하게* 만드는 건 MoE 희소성이 "토큰당 디스크에서 끌어올 양"을 RAM 캐시가 감당할 크기(~19MB)로 묶어주기 때문이다.
세로 방향의 정리
단일 노드가 자기 메모리보다 큰 MoE를 서빙하는 것은 원래 가능한 일반 능력 이다. 필요한 3요소:
MoE 희소성 — 토큰당 극히 일부 전문가만 활성 (dense면 붕괴)
빠른 로컬 스토리지 — NVMe 2.5GB/s (HDD 150MB/s였다면 16배 느림)
충분한 RAM 캐시 — 114/207 ≈ 55%가 상주해 뜨거운 작업 세트를 덮음
5. 가로 방향 — 스웜 (cold tier를 다른 노드의 메모리에 두기)
이제 자유도 하나만 바꿔 보자. cold tier를 로컬 디스크가 아니라 다른 노드의 빠른 메모리 에 두면?
한 노드(백본)가 어텐션 · 라우터 · 임베딩만 든다 — MoE에서 이건 겨우 수 GB다.
200GB가 넘는 전문가 풀은 여러 노드의 RAM/VRAM에 흩어져 산다. 층 · 전문가 범위로 잘라, 들겠다고 자원한 누구든 든다 (데이터센터 GPU, 엣지 박스, 심지어 폰).
백본이 각 토큰에 필요한 전문가를 정하고, 네트워크로 그 계산을 해당 노드에 요청하고, 결과를 받아 꿰맨다.
가로 방향 아키텍처: 백본 노드는 고속 네트워크를 통해 여러 원격 워커 노드에 연결됩니다. 전문가 풀은 이 워커들의 RAM에 분산되어 있으며, 백본은 필요한 계산을 해당 전문가 노드에 요청합니다.
라우터는 한 머신에서 권위를 유지하므로 모델 동작은 정확히 원본과 같다 — 옮겨진 건 산술뿐이다. 이게 우리가 실제로 굴리는 expert-sharded swarm 이고, 그 위에 기여량 정산(전문가를 서빙한 만큼 보상)까지 얹혀 있지만, 그 경제 얘기는 이 글의 범위 밖이다.
여기서 결정적 관찰:
세로(mmap+NVMe)와 가로(스웜)는 같은 캐싱 원리의 두 구현이다. 뜨거운 작업 세트는 가까운 빠른 메모리에, 차가운 전문가 꼬리는 먼 저장소에. 유일한 차이는 "먼 저장소"가 로컬 NVMe냐, 원격 노드의 RAM이냐 다. 그리고 그 선택의 승패는 전적으로 fetch 경로의 성능 이 가른다.
6. 무엇이 승부를 가르나 — fetch 경로의 대역폭과 지연
세로냐 가로냐는 취향이 아니라 fetch 경로의 물리학 이 결정한다. 두 축이 있다:
대역폭 — 초당 몇 바이트를 끌어올 수 있나
지연(RTT) — 요청 한 번의 왕복이 몇 밀리초인가
그리고 추론의 두 국면이 이 축들에 다르게 반응한다:
Decode(자기회귀 생성) 는 RTT-bound 다. 토큰이 층을 순차적으로 통과하므로, 샤딩된 각 경계마다 왕복 지연을 토큰마다 지불한다. 페이로드는 작다(히든 스테이트 몇 KB). 여기선 지연이 왕 이다.
Prefill(긴 프롬프트 처리) 은 bandwidth-bound 다. 많은 토큰을 한꺼번에 밀어 넣으니 대역폭이 병목. 여기선 대역폭이 왕 이다.
지금 우리 토폴로지의 실측
두 노드 — 데이터센터의 MI250(8×64GB VRAM)과 사무실의 GB10 — 사이를 쟀다:
지표
측정값
함의
RTT (왕복 지연)
3.4 ms
낮다 — 메트로/동일지역 수준, 롱홀 아님
대역폭 · GB10→MI250 (사무실 업로드 )
6.1 MB/s (49 Mbps)
단일·8병렬 스트림 합산 동일 → 링크 실제 상한
대역폭 · MI250→GB10 (사무실 다운로드 )
11.2 MB/s (89 Mbps)
반대 방향은 ~1.8배 빠름 → 비대칭 확인
로컬 NVMe (비교군)
2,500 MB/s
fetch 경로로서 ~400배 빠름
여기서 세 가지가 분리되어 드러난다.
첫째, 거리가 아니라 파이프의 문제다. RTT 3.4ms는 낮다(가깝다). 만약 거리가 병목이었다면 지연이 컸을 것이다. 지연은 좋은데 대역폭이 나쁘다는 건, 물리적 거리가 아니라 회선의 굵기 가 좁다는 뜻이다.
둘째, 그 상한은 소프트웨어 아티팩트가 아니라 링크의 물리적 한계다. 처음엔 단일 TCP 스트림의 한계(작은 윈도우, SSH 암호화 CPU 바운드)를 의심했지만, 8개 병렬 스트림으로 다시 재도 합산이 여전히 6.1MB/s — 전혀 aggregate되지 않았다. 링크 자체가 ≈49 Mbps에 걸려 있다.
셋째 — 그리고 결정적으로 — 송신과 수신이 비대칭이다. 같은 두 지점, 같은 3.4ms 거리인데 방향에 따라 속도가 다르다: 사무실에서 나가는 (업로드) 6.1MB/s vs 들어오는 (다운로드) 11.2MB/s. 도로 길이는 짧은데 나가는 차선이 들어오는 차선보다 좁은 셈이다. 대부분의 사무실·가정 인터넷이 이렇게 비대칭이다 — 다운로드를 훨씬 많이 하니 ISP가 그쪽에 대역폭을 더 준다.
이 비대칭이 스웜에 하필 나쁜 이유: expert 워커는 백본이 보낸 히든 스테이트를 받아 계산하고 결과를 다시 올려보내야 한다. 즉 워커의 주된 작업은 업로드 다 — 그런데 그 업로드 방향이 하필 더 좁은 쪽(6.1MB/s)이다. 사무실의 업링크 상한이 정확히 원격 expert-worker의 목을 조른다.
중요한 건, 이건 거리(물리)의 한계가 아니라 회선 등급(계약·장비)의 한계이므로 고칠 수 있다는 점 이다: 대칭 광회선으로 업그레이드하거나, 두 노드가 물리적으로 가까우면(3.4ms니 그럴 만하다) 인터넷을 우회한 직결 광/DAC — 즉 §7의 200G — 로 파이프 자체를 갈아끼우면 된다.
현재 비교 (이 토폴로지에서)
단일 노드 GB10 (세로, NVMe): 실측 ~1 tok/s. cold tier가 2.5GB/s NVMe.
크로스사이트 스웜 (가로, 현재 링크): cold tier가 원격 RAM인데, 그 fetch 경로가 링크 상한 6.1MB/s. NVMe(2,500MB/s)보다 약 400배 느리다. 결과: 디코드마다 원격 전문가를 기다리며 로컬 NVMe 페이징보다 오히려 느려진다.
즉 지금 이 토폴로지에서는 단일 노드가 이긴다. cold tier로서 "느린 네트워크 너머의 빠른 메모리"보다 "빠른 로컬 디스크"가 낫기 때문이다. 스웜의 진가는 fetch 경로가 NVMe보다 빨라질 때 — 즉 노드 간 링크가 로컬 디스크를 능가할 때 비로소 터진다.
낮은 RTT(3.4ms)는 그 전환이 멀지 않았다는 신호다. 지연은 이미 충분히 낮다. 남은 건 대역폭이다.
7. 200Gb/s WAN — 원격 메모리가 로컬 디스크를 이기는 순간
전환점을 계산해 보자. 로컬 NVMe cold tier는 2.5 GB/s = 20 Gb/s 를 낸다. 스웜이 이기려면 노드 간 fetch가 이걸 넘어야 한다.
200GbE(25 GB/s)면 로컬 NVMe보다 10배 빠르다. 이 순간 부등호가 뒤집힌다 — 원격 노드의 RAM에서 전문가를 가져오는 게 로컬 SSD에서 페이징하는 것보다 빠르다. 그리고 이건 미래 기술이 아니다:
서두의 그 GB10에는 NVIDIA ConnectX-7과 200GbE QSFP 포트 2개가 기본 탑재 돼 있다. 두 대를 ~10만 원대 QSFP56 DAC 케이블 하나로 직결하면 스위치 없는 200G 클러스터다. (주의: GB10은 이 NIC을 PCIe Gen5 x4 ×2 multi-host로 물려서, 실측 최고속(~185Gb/s)은 RoCE/RDMA와 올바른 토폴로지 매핑을 요구한다. fat pipe는 케이블이 아니라 설정으로 산다.)
거리도 문제가 아니다. 200G는 모든 도달거리에 카탈로그 부품이 있다:
도달거리
부품
형태
랙 (0.5–3m)
QSFP56 DAC 구리
케이블 (~10만원)
실내 (~30m)
AOC 능동광
케이블
캠퍼스 (2–10km)
200G FR4/LR4 광모듈
QSFP56 모듈
메트로 (~40km)
200G ER4 광모듈
QSFP56 모듈
광역 (~120km)
400G ZR+ coherent를 200G 라인레이트로
QSFP-DD 모듈
장거리 (수백 km)
캐리어 200G 파장 / DWDM
회선 임대
WAN에서 케이블은 그저 표준 싱글모드 광섬유 — 이미 모든 도시를 잇고 있는 속도 중립적 유리다. 속도는 양끝의 플러거블 광모듈에 산다. OpenZR+가 "200G로 120km"를 통신사 프로젝트가 아니라 스위치에 꽂는 모듈 하나로 만들었다.
200G가 사주는 것, 못 사주는 것
fat pipe가 사주는 것: 모든 대역폭 항이 사라진다. 전문가 슬라이스가 밀리초에 배송되고, 긴 컨텍스트 prefill이 와이어 속도로 흐르고, 여러 사용자 스트림을 합산한 전문가-풀 트래픽 — 정확히 fat pipe가 흡수하는 대역폭-heavy · 지연-tolerant 부하 — 이 와이어 상한 없이 스케일한다. cold tier가 원격 RAM일 때, 200G는 그걸 로컬 디스크보다 빠른 tier로 승격시킨다.
못 사주는 것: 지연. 광섬유는 빛을 ~5µs/km로 나른다. 어떤 대역폭도 이걸 못 바꾼다. 13ms 왕복은 200Gb/s에서도 13ms다. 자기회귀 디코드는 그 왕복을 샤딩된 층마다, 토큰마다 지불한다. 그래서 가장 굵은 파이프로도 추측 디코딩(왕복당 k토큰)과 shared-expert 오버랩(dispatch가 나는 동안 로컬 계산)은 여전히 필수 다. 대역폭은 처리량을 사고, 지연은 오직 왕복 규율로만 산다.
결과 — 두 계층 구조
그래서 구조는 두 티어로 정착한다:
허브 티어 — 백본과 뜨거운 전문가들이 200G급 링크로 묶여, 용량이 사실상 무제한. 여러 대가 한 대처럼 느껴진다.
엣지 티어 — 폰과 소형 기기가 443 릴레이 위에서 scarcity 마켓이 배정한 전문가 롱테일을 든다.
fat pipe는 첫 계층을 한 대처럼 만들고, 릴레이는 둘째 계층을 누구에게나 연다. 서로를 대체하지 않는다 — 이 분리가 곧 설계다.
8. 2조 파라미터 MoE — 이 원리의 종착점
이제 원리를 끝까지 밀어붙이자. 프론티어는 이미 2조 파라미터급 MoE를 향하고 있다. 4비트로 ~1TB . M3의 5배다.
같은 두 자유도로 답이 나온다:
세로 (단일 노드 mmap): 1TB짜리 MoE를 서빙하려면 1TB NVMe면 된다 — 20만 원짜리 SSD 하나. 희소성이 충분하면(예: 256개 중 8개 활성) 토큰당 작업 세트는 여전히 유한하고, 커널이 demand paging으로 나머지를 NVMe에서 끌어온다. 한 대의 워크스테이션이 2T 모델을 "서빙"할 수 있다. 느리지만 — M3의 1 tok/s를 생각하면 2T는 더 느리겠지만 — 가능하다. 이것만으로도 접근성의 혁명이다: 2조 파라미터 모델이 데이터센터가 아니라 책상 위 SSD에 담긴다.
가로 (200G 스웜): 1TB의 전문가를 플릿의 메모리에 흩고, 25GB/s로 가져온다. 페이징이 사라진다. 빠르고, 스케일한다. 사용자가 늘수록 전문가-풀 트래픽은 배치로 합쳐져 fat pipe를 채우고, 각 전문가 가중치는 더 많은 스트림에 걸쳐 더 잘 상각된다. 2조 파라미터 모델이 데이터센터 자본 지출 항목이길 멈추고 공유 커버리지 마켓이 된다.
두 경로 모두 같은 이유로 성립한다: 2T dense였다면 어느 쪽도 불가능하다(토큰당 1TB를 읽어야 하니까). MoE 희소성이 "1TB 저장 문제"를 "수십 GB 작업 세트 캐시 문제"로 바꾸고, 그 다음은 캐시를 어느 tier에 두느냐 — NVMe냐 원격 RAM이냐 — 의 선택일 뿐이다.
희소성 비율이 관건이 된다
규모가 커질수록 희소성 비율 (총 파라미터 ÷ 활성 파라미터)이 결정적이다. M3는 ~20:1(428B/23B)이다. 2T 모델이 비슷한 비율을 유지하면 활성은 ~100B — 여전히 단일 노드가 감당할 계산량이고, cold tier에서 끌어올 작업 세트도 유한하다. 희소성이 규모의 저주를 푸는 열쇠다. MoE 설계자들이 전문가 수를 늘리면서 top-k를 낮게 유지하는 이유가 바로 이 캐시 국소성이다.
9. 통합 원리 — MoE 추론은 분산 메모리 계층이다
한 발 물러서서 보면, 지금까지의 모든 것은 하나의 그림이다: 메모리 계층(memory hierarchy)의 확장.
전통적 계층은 이렇게 생겼다:
레지스터
→ L1/L2/L3 캐시
→ RAM
→ NVMe
→ HDD
(빠르고 작고 비쌈) ────────────→ (느리고 크고 쌈)
MoE 추론의 계층은 이걸 네트워크 너머로 늘린다:
MoE 추론을 위한 확장된 메모리 계층: 로컬 VRAM/RAM/NVMe에서 시작하여 고속 네트워크 너머의 원격 RAM, 그리고 엣지 디바이스까지 확장됩니다.
GPU VRAM
→ 로컬 RAM
→ 로컬 NVMe
→ 200G 너머 원격 RAM
→ 443 릴레이 너머 폰
(뜨거운 백본·인기 전문가) ─────────────────────→ (차가운 전문가 롱테일)
각 tier는 위 tier보다 느리지만 크고 싸다. 그리고 MoE 희소성 덕분에 모델은 이 계층에 자연스럽게 얹히는 데이터셋 이다 — 뜨거운 소수는 위로, 차가운 다수는 아래로. 캐시 교체 정책(뜨거운 걸 유지, 차가운 걸 evict)이 전문가 접근 패턴에 그대로 대응한다.
"왜 MoE는 흩어서 추론할 수 있는가"의 최종 답: MoE 추론은 저장 문제가 아니라 계층적 캐싱 문제이고, 스웜화는 그 캐시 계층을 네트워크 너머로 확장하는 것이다. 희소성이 모델을 자연스러운 tier 구조로 만들고, demand paging(세로)이든 expert dispatch(가로)든 같은 원리 — 뜨거운 건 가까이, 차가운 건 필요할 때 — 의 서로 다른 반경(radius)일 뿐이다. 반경이 SSD면 단일 노드, 반경이 200G 링크면 데이터센터 클러스터, 반경이 443 릴레이면 전 지구다.
10. 마치며 — 접근성의 재정의
두 가지가 동시에 참이다:
한 대로도 된다. MoE 희소성 + mmap + 싼 NVMe면, 428B든 2T든 워크스테이션 한 대가 서빙한다. 느리지만 가능하고, 이건 프론티어 모델을 데이터센터 밖으로 꺼내는 접근성의 문이다.
여럿이면 빠르다. 200G급 인터커넥트가 원격 메모리를 로컬 디스크보다 빠른 tier로 만드는 순간, 같은 희소성이 이번엔 처리량과 스케일을 산다.
둘 다 같은 통찰의 활용이다 — 초대형 MoE는 "전부를 빠르게" 담을 필요가 없다는 것. 그리고 그 통찰이 참인 한, 모델이 아무리 커져도 추론은 흩어질 수 있다.
책상 위 SSD 한 개부터, 200G로 묶인 클러스터, 그리고 443 릴레이 위의 전 지구적 폰 스웜까지 — 같은 원리의 반경만 다를 뿐이다.
부록 — 이 글의 실측 수치 출처
모든 수치는 실제 하드웨어에서 측정했다.
M3 구조: GGUF 메타데이터 직접 파싱 ( minimax-m3.block_count=60 , expert_count=128 , expert_used_count=4 , embedding_length=6144 , expert_feed_forward_length=3072 , leading_dense_block_count=3 ).
모델 크기: unsloth/MiniMax-M3-GGUF UD-IQ4_XS 6샤드 = 207.6GB (HF 대조 바이트 정확 일치).
GB10 서빙: VmRSS 114.7GB / VmSize 241.7GB, ~1 tok/s, NVMe 2.5 GB/s ( dd iflag=direct ).
Page fault: 12토큰 생성 중 major +58,561 / minor +151,955 ( /proc/PID/stat ).
인터커넥트: MI250↔GB10 RTT 3.4ms ( ping ). 대역폭 방향별 — GB10→MI250(사무실 업로드) 6.1 MB/s(단일·8병렬 스트림 합산 동일 → 링크 실제 상한 ≈49 Mbps), MI250→GB10(사무실 다운로드) 11.2 MB/s(≈89 Mbps). 방향 비대칭 ~1.8배 → 사무실 비대칭 업링크 확인.
200GbE 하드웨어: GB10 온보드 ConnectX-7, OpenZR+/ZR 광학 카탈로그(랙~장거리 도달거리).