MoE 서빙 (wide EP)

MoE 서빙은 파라미터 수보다 토큰 라우팅, 전문가 불균형과 집단 통신의 꼬리 비용을 설계하는 문제입니다.

넓은 expert parallel 구성에서 배치, 라우팅, all-to-all 통신과 장애 범위를 함께 최적화합니다.

§ 01

문제 정의

MoE 서빙 (wide EP)이 필요한 운영 조건

평균 부하가 균등해도 일부 전문가로 토큰이 몰리면 전체 단계가 가장 느린 랭크를 기다립니다.

GPU 수를 늘리면 메모리는 분산되지만 통신과 장애 도메인이 함께 커집니다.

  • 활성 파라미터 대비 전체 모델이 커 단일 노드 배치가 비효율적일 때
  • 실제 토큰 분포로 expert parallel 폭을 검증할 수 있을 때
  • 네트워크 토폴로지와 집단 통신을 통제할 수 없을 때
  • 소규모 트래픽에서 복잡성 비용이 메모리 이득보다 클 때
PLATE 01

MoE 서빙 (wide EP) 시스템 플레이트

CONTROL

시스템 1

프롬프트 유형별 전문가 선택과 토큰 불균형을 프로파일링합니다.

CONTROL

시스템 2

노드 내부·간 EP 배치와 TP 조합을 물리 네트워크에 맞춰 비교합니다.

EXECUTION

시스템 3

all-to-all 크기, 중첩 가능 계산과 straggler 영향을 구간별로 계측합니다.

EXECUTION

시스템 4

전문가·랭크·링크 장애 시 요청 범위와 복구 전략을 검증합니다.

  1. N1 N2context
  2. N2 N3decision
  3. N3 N4evidence
MoE 서빙 (wide EP)의 의사결정과 검증 구조입니다. 표기는 아키텍처를 설명하며 측정된 배포 성과를 의미하지 않습니다.
  1. 작업은 프롬프트 유형별 전문가 선택과 토큰 불균형을 프로파일링합니다.에서 시작합니다.
  2. 전문가 부하 분산을 통해 수용 여부를 결정합니다.

§ 03

설계 방법

구현보다 먼저 경계와 수용 기준을 고정합니다.

MoE 서빙은 파라미터 수보다 토큰 라우팅, 전문가 불균형과 집단 통신의 꼬리 비용을 설계하는 문제입니다.

  1. 01

    1단계

    프롬프트 유형별 전문가 선택과 토큰 불균형을 프로파일링합니다.

    검토 산출물 1
  2. 02

    2단계

    노드 내부·간 EP 배치와 TP 조합을 물리 네트워크에 맞춰 비교합니다.

    검토 산출물 2
  3. 03

    3단계

    all-to-all 크기, 중첩 가능 계산과 straggler 영향을 구간별로 계측합니다.

    검토 산출물 3
  4. 04

    4단계

    전문가·랭크·링크 장애 시 요청 범위와 복구 전략을 검증합니다.

    검토 산출물 4

§ 04

적용 시나리오

가상의 업무 조건으로 적용 범위를 확인합니다.

가상 적용 시나리오

활성 파라미터 대비 전체 모델이 커 단일 노드 배치가 비효율적일 때

평균 부하가 균등해도 일부 전문가로 토큰이 몰리면 전체 단계가 가장 느린 랭크를 기다립니다.

APPROACH
프롬프트 유형별 전문가 선택과 토큰 불균형을 프로파일링합니다.
BOUNDARY
하드웨어·모델·트래픽이 다른 처리량 수치를 전용하지 않습니다.
가상 적용 시나리오

실제 토큰 분포로 expert parallel 폭을 검증할 수 있을 때

GPU 수를 늘리면 메모리는 분산되지만 통신과 장애 도메인이 함께 커집니다.

APPROACH
노드 내부·간 EP 배치와 TP 조합을 물리 네트워크에 맞춰 비교합니다.
BOUNDARY
넓은 EP가 항상 TP 또는 작은 EP보다 우수하지 않습니다.

§ 05

설계 선택

이득과 비용을 같은 표에서 검토합니다.

DecisionGainCostWatch
활성 파라미터 대비 전체 모델이 커 단일 노드 배치가 비효율적일 때프롬프트 유형별 전문가 선택과 토큰 불균형을 프로파일링합니다.하드웨어·모델·트래픽이 다른 처리량 수치를 전용하지 않습니다.전문가 부하 분산
실제 토큰 분포로 expert parallel 폭을 검증할 수 있을 때노드 내부·간 EP 배치와 TP 조합을 물리 네트워크에 맞춰 비교합니다.넓은 EP가 항상 TP 또는 작은 EP보다 우수하지 않습니다.집단 통신 비중과 꼬리 시간
PLATE 02

MoE 서빙 (wide EP) 시스템 플레이트

Item방법증거경계
계층 1프롬프트 유형별 전문가 선택과 토큰 불균형을 프로파일링합니다.전문가 부하 분산하드웨어·모델·트래픽이 다른 처리량 수치를 전용하지 않습니다.
계층 2노드 내부·간 EP 배치와 TP 조합을 물리 네트워크에 맞춰 비교합니다.집단 통신 비중과 꼬리 시간넓은 EP가 항상 TP 또는 작은 EP보다 우수하지 않습니다.
계층 3all-to-all 크기, 중첩 가능 계산과 straggler 영향을 구간별로 계측합니다.토큰 goodput과 복구 범위하드웨어·모델·트래픽이 다른 처리량 수치를 전용하지 않습니다.
MoE 서빙 (wide EP)의 의사결정과 검증 구조입니다. 표기는 아키텍처를 설명하며 측정된 배포 성과를 의미하지 않습니다.
  1. 작업은 프롬프트 유형별 전문가 선택과 토큰 불균형을 프로파일링합니다.에서 시작합니다.
  2. 전문가 부하 분산을 통해 수용 여부를 결정합니다.

§ 07

검증 계획

성과 수치보다 먼저 측정 조건을 합의합니다.

MeasureMethodPass conditionCaveat
전문가 부하 분산프롬프트 유형별 전문가 선택과 토큰 불균형을 프로파일링합니다.도입 검토에서 합의한 기준을 반복 측정으로 충족하드웨어·모델·트래픽이 다른 처리량 수치를 전용하지 않습니다.
집단 통신 비중과 꼬리 시간노드 내부·간 EP 배치와 TP 조합을 물리 네트워크에 맞춰 비교합니다.도입 검토에서 합의한 기준을 반복 측정으로 충족
토큰 goodput과 복구 범위all-to-all 크기, 중첩 가능 계산과 straggler 영향을 구간별로 계측합니다.도입 검토에서 합의한 기준을 반복 측정으로 충족

§ 08

한계와 실패 조건

적용하지 말아야 할 조건도 설계의 일부입니다.

네트워크 토폴로지와 집단 통신을 통제할 수 없을 때

하드웨어·모델·트래픽이 다른 처리량 수치를 전용하지 않습니다.

소규모 트래픽에서 복잡성 비용이 메모리 이득보다 클 때

넓은 EP가 항상 TP 또는 작은 EP보다 우수하지 않습니다.

§ 10

남는 산출물

프로젝트가 끝나도 운영 조직에 남아야 합니다.

MoE 서빙 (wide EP) 의사결정 기록
MoE 서빙은 파라미터 수보다 토큰 라우팅, 전문가 불균형과 집단 통신의 꼬리 비용을 설계하는 문제입니다.고객 소유 · Patty 검토
검증 하네스와 수용 기준
전문가 부하 분산 · 집단 통신 비중과 꼬리 시간 · 토큰 goodput과 복구 범위공동 관리
운영·복구 런북
하드웨어·모델·트래픽이 다른 처리량 수치를 전용하지 않습니다. · 넓은 EP가 항상 TP 또는 작은 EP보다 우수하지 않습니다.운영 조직 소유

§ 11

용어

같은 단어를 같은 운영 의미로 사용합니다.

MoE 서빙 (wide EP)
넓은 expert parallel 구성에서 배치, 라우팅, all-to-all 통신과 장애 범위를 함께 최적화합니다.
수용 기준
전문가 부하 분산
운영 경계
하드웨어·모델·트래픽이 다른 처리량 수치를 전용하지 않습니다.

REFERENCES

참고 문헌과 1차 자료

  1. DeepEP

    방법과 용어를 확인하기 위한 1차 자료입니다.

  2. vLLM Expert Parallel Deployment

    방법과 용어를 확인하기 위한 1차 자료입니다.

MoE 서빙 (wide EP)이 필요한 조건부터 함께 검토하겠습니다.

대표 업무, 데이터와 인프라 경계, 실패 조건을 기준으로 적용 범위와 검증 계획을 구체화합니다.

기술 검토 요청