초대형 MoE 오픈웨이트를 자체 서빙하기 위한 자원 배분 설계

가중치를 확보해도 서빙 설계는 별도로 필요하다

알리바바가 Max 계열 최초로 Qwen3.8-Max를 오픈웨이트로 공개하면서, 2.4조 파라미터 MoE(Mixture of Experts) 모델을 자체 인프라에서 운용할 선택지가 생겼다. 최상위 성능 모델을 API 호출에만 의존하지 않을 수 있다는 뜻이다.

하지만 가중치를 내려받는 일과 해당 모델을 안정적으로 서비스하는 일은 다르다. MoE는 추론할 때 일부 전문가만 활성화하므로 연산량은 줄일 수 있지만, 전체 가중치는 계속 메모리에 올려 두어야 한다. 계산 비용의 절감이 메모리 상주 요구량의 절감으로 이어지지 않는 이 비대칭이 초대형 MoE 자체 서빙의 진입 장벽이다.

Qwen3.8-Max는 총 2.4조 파라미터 MoE 구조이고, 추론 시 활성 파라미터는 약 950억 수준이다. 연산량은 활성 파라미터에 비례하지만 메모리 요구량은 총 파라미터를 기준으로 잡아야 한다. Alibaba Cloud Model Studio를 통한 오픈웨이트 배포와 OpenAI·DashScope 호환 API가 병존하므로, 통합 자체는 base URL과 모델 ID 변경 수준에서 처리할 수 있다. 다만 실제 성능은 가속기 확보, 전문가 배치, 라우팅 지연, 네트워크 대역에 좌우된다.

전문가를 어디에 두고 어떻게 연결할지 결정한다

단일 노드에 전체 파라미터를 담기 어려운 규모에서는 전문가 병렬(Expert Parallelism)이 기본 축이 된다. 전문가 단위로 여러 노드에 가중치를 나눠 상주시켜야 하며, 텐서 병렬·파이프라인 병렬·전문가 병렬을 어떤 조합으로 사용할지에 따라 통신 패턴도 달라진다.

샤딩 경계는 운영 중 쉽게 바꾸기 어렵다. 현재 가속기 구성만 보지 말고, 향후 증설 계획도 함께 반영해야 한다. 특정 전문가가 반복적으로 선택되면 노드별 부하가 한쪽으로 쏠릴 수 있으므로, 활성 빈도를 계측하고 전문가 배치를 재조정하는 절차가 필요하다.

토큰마다 라우터는 활성 전문가를 선택한다. 선택된 전문가가 다른 노드에 있으면 네트워크 왕복이 발생하고, 노드 경계를 넘는 라우팅이 빈번해질수록 MoE의 연산 절감분은 통신 지연으로 상쇄된다. 라우팅 지역성은 구현 세부사항이 아니라 실질적인 성능 변수다.

전문가 병렬은 all-to-all 통신을 유발한다. 노드 간 대역폭은 처리량의 상한이 되며, 고속 인터커넥트가 부족하면 규모 확장은 성립하기 어렵다. 대역 부족은 평균 지연보다 지연 분포의 꼬리에서 먼저 드러나므로, 평균값만이 아니라 상위 백분위 지연을 감시해야 한다.

⤢✕

양자화와 배치 정책은 분리해서 운영한다

전문가 가중치, 어텐션 가중치, KV 캐시에는 서로 다른 정밀도를 적용할 수 있다. 일괄 양자화는 어느 구간에서 품질이 떨어졌는지 예측하기 어렵게 만든다. 특히 라우터 가중치는 양자화 민감도가 높다. 라우팅이 흔들리면 출력 품질이 비선형으로 무너질 수 있으므로, 라우터와 임베딩 계층은 별도 기준으로 다루는 편이 낫다.

업무별 허용 손실을 수치로 정한 뒤, 그 범위 안에서 가장 공격적인 양자화를 선택한다. 기준 없이 시도하면 되돌릴 근거도 없다. 전량 정밀도 유지는 공개된 품질 지표를 그대로 재현하고 품질 저하 분석에서 양자화 변수를 제외할 수 있지만, 메모리 요구량이 최대가 되어 필요한 가속기 대수와 상시 비용이 증가한다. 양자화는 메모리와 대역 요구량을 낮춰 같은 하드웨어에서 더 큰 배치를 처리할 수 있게 하지만, 특정 작업에서만 급격한 품질 저하가 나타날 수 있다.

배치 크기도 단일 정책으로 고정하기 어렵다. 배치를 키우면 전문가 활성 패턴이 다양해져 노드별 부하가 평준화되는 반면, 개별 요청의 지연은 늘어난다. 온라인 경로와 배치 경로를 분리하고 각 경로에 다른 배치 정책을 적용하는 구성이 현실적이다.

2.4조 파라미터를 적재하려면 수 분 단위의 초기화 시간이 필요하다. 무중단 배포 전략이 없으면 모델 갱신 자체가 장애가 된다. 가중치를 사전 적재한 인스턴스를 대기시키는 방식과 요청 시 적재하는 방식의 비용 차이는 실측해야 한다.

자체 서빙은 가동률과 업무 특성으로 판단한다

호출량이 크고 프롬프트 구조가 일정한 업무는 자체 서빙 후보가 된다. 반대로 산발적이고 저빈도인 호출은 API가 유리하다. 데이터 외부 반출이 제한되는 업무라면 호출량과 관계없이 자체 서빙을 검토할 수 있다.

용량은 총 파라미터 기준 메모리 요구량, 동시 요청 기준 KV 캐시 요구량, 여유율을 각각 산정해야 한다. 이 세 요소를 함께 보지 않으면 부족해진다. 자체 서빙의 가속기는 트래픽이 없어도 점유 비용이 계속 발생하므로, 손익분기는 가동률에 달려 있다.

피크를 모두 자체 인프라로 받아내기 위해 상시 용량을 키우면 가동률이 무너질 수 있다. 자체 서빙 용량을 넘는 요청은 API로 보내는 하이브리드 구성을 기본으로 두는 이유다. 양자화 수준이 다르면 출력도 달라질 수 있으므로, 두 경로의 출력 차이는 허용 범위 안에서 관리해야 한다.

성능 평가는 공개 벤치마크가 아니라 사내 대표 작업으로 수행한다. Terminal-Bench 2.1 같은 지표는 후보를 선별하는 용도이지 도입 근거가 아니다. 처리량, 지연 백분위, 품질을 동시에 기록해 단일 지표만 최적화하는 상황을 피한다.

오픈웨이트는 오픈소스와 같은 뜻이 아니다. 사용 범위, 재배포, 파생 모델 조건은 라이선스마다 다르므로 배포 전 법무 검토를 절차에 포함해야 한다. 상업적 사용 제한과 출력물 귀속 조항도 별도로 확인한다.

운영 상태를 재현 가능하게 묶어 둔다

모델 파일 해시, 양자화 설정, 샤딩 구성, 런타임 버전은 하나의 형상으로 고정해야 한다. 이들 중 하나만 달라져도 재현성이 깨질 수 있다. 가중치 해시와 라이선스 버전은 감사 추적을 위해 형상 항목으로 등록하고, 버전별 품질 기준선을 보관해 교체 시 회귀를 비교한다.

거버넌스에는 가중치 접근 권한, 배포 승인, 버전 롤백 경로가 포함돼야 한다. 자체 서빙 인프라의 증설 판단 기준과 예산 상한도 운영 전에 정해 둘 항목이다.

구분	오픈웨이트 자체 서빙	상용 API 호출
초기 투자	가속기 확보 필요	없음
단가 구조	상시 점유 비용	토큰당 종량
데이터 통제	내부 유지	외부 전송
버전 고정	완전 통제	제공자 정책
운영 부담	높음	낮음
피크 대응	용량 상한 존재	탄력적

자체 서빙은 데이터가 외부로 나가지 않고 원하는 시점까지 모델 버전을 고정할 수 있다. 호출량이 많아질수록 실효 단가가 내려갈 수 있지만, 가속기 확보와 상시 점유 비용은 트래픽과 무관하게 발생하며 샤딩·라우팅·양자화 운영 역량도 요구된다. API는 초기 투자 없이 최신 모델을 사용할 수 있고 피크 트래픽을 탄력적으로 흡수하지만, 데이터 외부 전송과 제공자의 모델 교체·가격 정책 변경에 종속된다.

MoE는 활성 파라미터만 계산하므로 같은 총 파라미터의 밀집 모델보다 추론 연산량이 낮고, 같은 계산 예산에서 더 큰 표현력을 확보할 수 있다. 반면 전체 가중치의 메모리 상주와 전문가 간 all-to-all 통신을 요구한다. 가속기 메모리는 충분하지만 노드 간 대역이 빈약한 환경에서는 이 연산 이점이 통신 지연으로 상쇄될 수 있다. 구조 선택에 앞서 인프라 특성을 확인해야 하는 이유다.

조 단위 파라미터 오픈웨이트가 반기 단위로 등장하면서 자체 서빙 가능 여부는 인프라 역량의 척도가 되는 흐름이다. 전문가 병렬 최적화는 서빙 프레임워크의 기본 기능으로 편입되어 구현 부담이 낮아지는 방향이며, 계층별 차등 양자화 설정도 모델 배포 시 표준 메타데이터로 함께 제공되는 흐름이다. 라이선스 조건은 더 다양해지고 있어 법무 검토는 도입 절차의 필수 단계로 정착되는 방향이다.