WAN Dispatch를 싸게 만들기: 근거 있는 로드맵
원격 전문가 dispatch는 작동하고 바이트-동일하다 — 하지만 WAN 디코드는 왕복 바운드다. 비용을 줄이는 계획을, DeepSeek·Petals 등의 프로덕션 수치에 근거해 소개한다(로드맵, 배포된 것 아님).
프레이밍: *우리가 측정한* 수치는 측정값으로 명시하고, 계획으로 서술된 모든 것은 배포된 결과가 아니라 로드맵이다. 목표는 원격 전문가 dispatch — 이미 정확하고 지불되는(짝 글 참조) — 를 가져와, 멀리 있는 GPU나 폰이 느린 구성원이 아니라 일급 스웜 구성원이 될 만큼 WAN 왕복을 싸게 만드는 것이다.
우리 자신의 실측, 담백하게 공개한다: dispatch는 레이어당 토큰당 약 110 KB 든다 — 나가는 12.3 KB(dispatch) + 돌아오는 98.3 KB(combine). 8× 비대칭은 선택된 각 전문가가 가중합 *이전에* 자기 전체 출력을 돌려주기 때문이다. 직접 링크로는 처리량 오버헤드 1.2%, CDN 릴레이를 통하면 ~28%다. 이것이 사실이다. 이 글의 나머지는 우리가 그 격차를 어떻게 좁힐 것인가 — 그리고 왜 바이트가 쉬운 쪽인가다.
WAN 디코드는 왕복 바운드다
여기서 가장 중요한 공개 결과는 우리 것이 아니라 Petals의 것이다: RTT가 <5 ms에서 100 ms로 가면 디코드가 1.24에서 0.57 steps/s로 떨어지는 반면, 대역폭을 10× 줄여도 변화는 ~0이다. 지연이 지배하고, 대역폭은 여유다. 이것이 문제 전체를 재구성한다: 바이트를 깎는 것은 여유분이지만, 왕복을 줄이는 것이 본질이다. 아래 모든 항목은 왕복 비용을 얼마나 없애는가로 순위 매긴다.
정확성 우선의 바이트 감축
- 원시 전문가 출력이 아니라 가중 부분합을 돌려준다. 선형성 덕에 백본의 combine은 어느 쪽이든 정확하지만, 워커가 8개 대신 하나의 합산 벡터를 돌려준다 — 그것이 ~8× combine 감축이며, DeepSeek-V3 / DeepEP가 프로덕션에서 하는 바로 그것이다.
- 다중 워커에 걸쳐 직렬 체인이 아니라 병렬 스타: ΣRTT가 max RTT로 붕괴한다.
- 회선에 F16 — 우리는 이미 교차 백엔드 cosine ~0.998을 받아들이므로 F16 전송은 기존 허용오차 안이다; 블록 단위 INT8/FP8은 나중에, 우리 자신의 argmax/cosine 게이트가 Q4_K_M 가중치 대비 통과시킨 뒤에(Petals는 실제 인터넷에서 품질 손실 없는 INT8을 보였다).
- 이들을 합쳐 ~110 KB → 토큰당 9–12 KB (~12×)를 겨냥한다 — 실질적이지만, 병목이 아니라 *여유분*임을 기억하라.
본질: 왕복을 줄이고, 왕복을 숨기고
- Speculative decoding은 여러 토큰을 하나의 왕복으로 바꾼다. 측정된 80 ms WAN에서 손익분기는 겨우 ~1.15–1.2 accepted tokens/step이라 — 약한 n-gram 추측조차 이긴다(순정 Jacobi는 역효과를 낼 수 있어 기법 선택이 중요하다). 우리 dispatch 프로토콜은 이미
n_tokens > 1을 실어 나르므로 회선 변경이 필요 없다. - 게이트웨이에서의 continuous batching은 동시 요청을 하나의 왕복으로 접고, slot-affinity prefix caching은 세션을 같은 복제본에 붙여 둔다.
- 지연 은닉: shared expert는 독립적인 덧셈 항이라, 백본이 원격 왕복 동안 그것을 *로컬로* 계산한다(ScMoE는 PCIe에서 재학습 없이 1.82×를 보고). hot 전문가는 로컬로 두고 cold만 원격으로 보낸다(EPLB는 가장 뜨거운 ~32개를 복제해 프로덕션에서 2.54× 디코드 가속).
피어별 라우팅, 그리고 200 Gb/s가 바꾸는 것
경로 정책: 공개 라우팅 가능한 피어는 직접 경로(1.2% 경로)를 타고, 릴레이는 NAT에 묶인 기기 전용이다. 그리고 넓은 200 Gb/s 링크가 오면 110 KB는 ~4.4 µs에 직렬화된다 — 위의 감축 이전에도 대역폭 항이 사라지고, 794 MB 슬라이스가 ~32 ms에 전송된다. 하지만 RTT는 물리이고, 줄어들지 않는다 — 그래서 200 G에서도 speculative decoding과 overlap이 진짜 지렛대로 남는다. 굵은 파이프가 진정 중요해지는 곳은 다중 백본 페더레이션(여러 백본이 하나의 전문가 풀을 공유)과 대역폭 바운드 작업이다: 긴 프롬프트 prefill과 대규모 배치 처리량.
정직하게 밝히는 한 가지 단서: 전송 계층 자체(WebSocket vs QUIC, 마스킹 오버헤드, NAT hole-punching)는 인용할 외부 결과가 없다 — 무엇이든 주장하기 전에 우리가 직접 측정할 엔지니어링이다. 위의 모든 것은 공개된 프로덕션 수치(DeepEP / DeepSeek-V3, Petals, DeepSpeed-MoE, ScMoE, SGLang/EPLB)와 우리 자신의 실측에 기댄다; 로드맵 항목이 배포되면 그 수치와 시제가 여기서 갱신된다.
온보딩 대상
우리의 dispatch 훅은 build_moe_ffn 위에 앉는다 — 추론엔진에서 43개 MoE 아키텍처가 공유하는 단일 함수다. 세 불변식은 모델과 무관하다: MoE 수학(routed = Σ wᵢ·Eᵢ(x), 선형), 공유 코드 경로, 그리고 GGUF의 표준 적층 전문가 텐서(최외곽 ne[2] → 블록 정렬 슬라이싱). 그래서 새 모델 온보딩은 재설계가 아니라 — 모델별 argmax/cosine 검증 게이트를 한 번 통과하는 것이다.
| 모델 | 전문가 · 라우팅 | 전문가당 (Q4≈) | shared expert | 상태 |
|---|---|---|---|---|
| Step-3.7-Flash 198B (현재 서빙 중) | 288 · top-8 | 플릿에서 실측 | 있음 | 서빙 중 — 16 스테이지, 머신 2대 |
| Qwen3.5-122B | 256 · top-8 | 5.3 MB (실측) | 있음 | 머신 3대에 걸쳐 엔드투엔드 서빙함 |
| GLM-5.2 744B | — | — | 있음 | linkcpp에서 검증 — 리포트 미공개 |
| GLM-4.5 / 4.6 355B | 160 · top-8 | ~13 MB | 있음 | 계획됨 (훅 검증) |
| MiniMax-M2 230B | 256 · top-8 | ~8 MB | 없음 | 계획됨 (훅 검증) |
| DeepSeek-V3 / R1 671B | 256 · top-8 | ~25 MB | 있음 | 계획됨 (deepseek2 그래프) |
| Kimi K3 2.8T | — | — | 있음 | 다음 게이트 — p4에서 검증 |
| Qwen3-235B | 128 · top-8 | ~11 MB | 없음 | 준비됨 |
| gpt-oss-120b | 128 · top-4 | ~14 MB | 없음 | 준비됨 |
| Llama 4 Maverick 400B | 128 · top-1 | ~70 MB | 있음 | 계획됨 (한 레이어 건너 MoE) |
| MiniMax M3 428B | 128 · top-4 | 미정 (GGUF) | 있음 | 업스트림 엔진 대기 |
| Mixtral 8×22B | 8 · top-2 | ~170 MB | 없음 | 작동 — GPU 워커만 |
업계는 세밀한(fine-grained) MoE로 수렴하고 있다 — 더 작은 전문가, 더 많은 수, 더 높은 희소성(DeepSeek, Qwen, Kimi, GLM, gpt-oss 모두 이 길로 갔다). 그 방향의 모든 걸음이 스웜의 참여 단위를 더 작게, 희소성 마켓의 알갱이를 더 잘게 만든다. 위의 모델들은 희망 목록이 아니다; 각각은 이미 우리가 테스트 플릿에서 돌리는 같은 dispatch 훅을 지난다 — 온보딩은 엔지니어링 프로젝트가 아니라 검증 게이트다.