초대형 MoE 자체 서빙을 위한 GPU 용량과 양자화 설계

2.8T 가중치를 어디에 둘 것인가

2.8조 파라미터급 가중치가 공개 배포되면서, 전체 적재 용량과 실제 연산량이 크게 다른 모델을 자체 인프라에서 어떻게 운용할지가 현실적인 설계 과제가 됐다. 활성 파라미터가 104.2B에 불과하더라도 전문가 가중치 전체는 저장 위치를 확보해야 한다. 초희소 MoE의 자체 서빙은 연산 문제보다 메모리 배치 문제에 가깝다.

활성 파라미터 104.2B는 토큰당 FLOPs를 좌우하지만, 적재 대상은 2.8T 전체 가중치다. 정밀도별 개략 산정은 BF16에서 파라미터당 2바이트, FP8에서 1바이트, INT4·MXFP4에서 0.5바이트다. 2.8T를 4비트로 적재하더라도 필요한 메모리는 테라바이트 단위다.

MXFP4 양자화 배포판이 공식 제공되고 vLLM이 공개 시점부터 지원하는 조건에서는, 저비트 적재가 자체 서빙의 출발점이 된다. 여기서 판단할 변수는 양자화 수준, GPU·CPU·NVMe 사이의 오프로딩 계층, 전문가 병렬과 텐서 병렬을 포함한 분산 방식이다.

양자화를 강하게 적용하면 필요한 노드 수는 줄어드는 대신 품질 변동 가능성이 생긴다. 오프로딩을 확대하면 GPU 투자비는 낮아지지만 지연이 늘어난다. 분산 범위를 넓히면 노드별 적재 부담은 줄지만 통신 비용이 커진다. 결국 중요한 질문은 모델이 실행되는지가 아니라, 목표 지연과 처리량에서 몇 대의 GPU가 필요하며 그 원가가 얼마인지다.

가중치와 연산을 나누어 배치하는 구조

MoE에서 전문가 가중치는 전체 파라미터 대부분을 차지하므로 양자화에 따른 절감 효과도 이곳에 집중된다. 반대로 라우터, 어텐션, 임베딩은 비중은 작지만 민감도가 높다. 전문가는 4비트로 두고 라우터·어텐션은 8비트 이상으로 유지하는 혼합 정밀도 구성이 용량 절감과 품질 저하 억제를 함께 노릴 수 있다.

전문가 병렬(EP)은 전문가를 여러 노드에 나눠 배치하고, 각 토큰을 해당 전문가가 있는 노드로 보낸다. 노드를 늘리면 노드별 적재량은 감소하지만 all-to-all 통신량이 증가한다. 통신량은 배치 크기와 활성 전문가 수에 비례하며, 대역폭이 부족하면 GPU는 통신을 기다리느라 유휴 상태가 된다.

텐서 병렬(TP)은 한 레이어의 연산을 여러 GPU에 나누는 방식이다. 노드 내부의 NVLink류 고대역 연결에서는 효율적이지만 노드 경계를 넘으면 성능이 급격히 나빠진다. 따라서 실무에서는 노드 내부에 TP를 적용하고 노드 간에는 EP를 구성하는 조합이 일반적이다.

저빈도 전문가는 CPU 메모리나 NVMe에 두고 호출 시 적재할 수 있다. 이 방식은 GPU 상주량을 낮추는 대신 적재 지연을 수반한다. 효과는 전문가 호출 분포가 얼마나 편향돼 있는지에 달려 있다. 호출이 균등하다면 오프로딩한 전문가가 매 토큰마다 호출돼 이점이 사라진다.

초희소 MoE 서빙에서 인터커넥트는 부가 선택지가 아니라 독립적인 용량 항목이다. 대역이 부족한 환경에서는 GPU를 더 추가해도 처리량이 늘지 않을 수 있다. 배치 크기를 키우면 GPU 효율은 높아지지만 통신량 역시 증가하므로, 대역 한계가 최적 배치 크기를 제한한다.

연속 배치는 요청 슬롯을 즉시 채워 GPU 유휴를 줄인다. 다만 오프로딩 구성에서는 배치 안의 전문가 다양성이 커질수록 적재 트래픽도 늘어난다. 콜드스타트에서는 테라바이트급 가중치를 적재하는 데 수 분이 걸리므로, 배포 전략에 워밍업 단계와 준비 상태 프로브를 포함해야 한다.

⤢✕

목표 SLO에서 역산하는 배포 판단

GPU 수를 계산하려면 업무별 목표부터 정해야 한다. 첫 토큰 지연(TTFT), 토큰 간 지연(ITL), 목표 동시성이 정해지지 않으면 필요한 GPU 대수도 산정할 수 없다. 대화형 서비스와 배치 처리는 목표가 다르다. 배치 워크로드는 지연 조건을 완화하고 처리량 중심으로 설계해 노드 수를 줄일 수 있다.

양자화 전후 품질은 자체 평가셋으로 확인해야 한다. 벤더 벤치마크 수치는 조직의 실제 워크로드와 상관이 낮을 수 있다. 정답률, 구조화 출력의 형식 준수율, 장문 일관성, 도구 호출 정확도를 검증 항목으로 두고 비교한다. 저비트 양자화에서는 형식 준수율이 먼저 무너지는 경향이 있다.

GPU를 자산으로 취득하면 감가와 기술 진부화 위험을 감수해야 한다. 리스와 클라우드는 단가가 높지만 규모 조정이 가능하다. 수요 예측의 신뢰도가 판단 기준이며, 트래픽 예측이 불확실하다면 초기에는 클라우드로 시작한 뒤 정상 트래픽이 안정된 시점에 자산 전환을 검토하는 편이 위험이 낮다.

오프로딩 비율의 상한은 지연 SLO에서 역산한다. 예를 들어 목표가 P95 TTFT 2초 이내라면, 적재 지연을 감내할 수 있는 전문가 비율도 그 조건 안에서 정해진다. 전문가 호출 분포는 실제 트래픽으로 측정한 뒤 오프로딩 대상을 골라야 한다. 추정만으로 정하면 기대한 효과가 나오지 않는다.

노드 일부가 이탈하면 해당 노드에 있던 전문가가 사라진다. 전문가 복제(replica) 여부와 축소 운전 시 허용할 품질 저하 범위를 사전에 정해 둘 필요가 있다. 전량 복제는 메모리 비용을 배로 만들기 때문에, 고빈도 전문가만 복제하는 비대칭 구성이 실무적이다.

양자화 설정, 오프로딩 비율, 병렬 구성은 형상관리 항목으로 등록하고 변경 때마다 품질 회귀 결과를 증적으로 남긴다. 관리 지표 역시 GPU 사용률이 아니라 토큰당 원가로 잡아야 한다. 사용률이 높더라도 유휴 대기 토큰이 많으면 원가는 개선되지 않는다.

자체 클러스터와 관리형 추론 서비스의 선택

구분	자체 GPU 클러스터	관리형 추론 서비스
초기 투자	큼 (고정비)	없음
토큰당 한계비용	낮음	높음
통제력	완전 (양자화·디코딩)	제한적
운영 부담	조직 부담	벤더 부담
확장 유연성	조달 기간 종속	즉시
적합 상황	고트래픽·주권 요구	변동 트래픽·초기 도입

자체 GPU 클러스터는 양자화 수준, 디코딩 개입, 데이터 경계를 모두 통제할 수 있으며 트래픽이 클수록 단가 측면에서 유리하다. 반면 관리형 추론 서비스는 조달, 운영, 장애 대응 부담을 벤더가 맡고 수요 변화에 즉시 대응한다. 두 방식의 교차점은 일 처리 토큰 수와 GPU 유휴율이 결정한다. 유휴율이 50%를 넘는 자체 클러스터는 대부분 관리형보다 비싸다.

BF16 적재는 품질 손실과 검증 부담이 없지만 노드 수와 투자비가 크게 증가한다. 4비트 양자화는 적재량을 4분의 1로 낮추는 대신 품질 검증 절차와 회귀 위험을 수반한다. 전문가 가중치에만 저비트를 적용하는 혼합 정밀도는 이 절감과 품질 사이에서 가장 실무적인 균형점이다.

전문가 오프로딩은 GPU 투자비를 크게 낮추지만, 저빈도 전문가가 호출될 때 지연이 튄다. 평균 지연은 유지되더라도 P99가 무너질 수 있어 평균 기준 SLO만으로는 문제를 잡기 어렵다. 대화형 서비스에는 전량 GPU 상주가 맞고, 배치·비동기 워크로드에는 오프로딩이 적합하다.

용량계획과 비용 거버넌스에 남는 과제

GPU 조달은 리드타임이 긴 자산 취득이다. 모델 세대 교체 주기가 조달 주기보다 짧으면, 자산이 도착했을 때 이미 최적 구성에서 벗어날 수 있다. 조달 결정에는 모델 교체 뒤 재활용 가능성도 평가 항목으로 포함해야 하며, 특정 모델 전용 구성은 위험 자산이 된다.

초희소 MoE는 연산 용량과 메모리 용량을 분리해 산정해야 하는 사례군이다. 단일 지표에 의존하는 기존 용량계획서만으로는 이 구조를 표현하기 어렵다. 인터커넥트 대역도 별도 용량 항목으로 계상해야 한다. 이를 빠뜨리면 GPU를 늘려도 처리량이 증가하지 않는 상황을 설명할 수 없다.

자체 서빙 전환은 변동비를 고정비로 옮기는 재무 결정이기도 하다. 수요가 줄어도 비용이 함께 내려가지 않는 구조를 경영진이 이해해야 한다. 원가 보고 단위를 토큰당 원가로 통일하면 자체 서빙과 API 호출을 같은 기준에서 비교할 수 있다.

2026년에 예상되는 변화

저비트 양자화 배포판을 모델 공개와 동시에 제공하는 관행이 표준화되면서, 자체 서빙의 진입 장벽은 정밀도 문제에서 메모리 조달 문제로 옮겨갈 전망이다. 추론 엔진이 전문가 오프로딩을 기본 기능으로 제공하면 GPU 상주 비율은 운영 튜닝 항목으로 드러난다.

인터커넥트 대역은 GPU 개수만큼 중요한 조달 항목으로 인식될 것이며, 노드 구성 설계도 모델 선택과 함께 결정되는 흐름이 강해질 수 있다. 초대형 오픈웨이트의 실사용은 데이터 주권 요구가 명확한 부문에 집중되고, 일반 기업은 오픈웨이트를 관리형 서비스로 호출하는 형태가 다수를 차지할 전망이다.