MoE 모형 직접 구축과 API, 2026년 손익분기점
모형을 띄우는 데 성공했지만 동시 요청이 늘자 캐시가 부족해지고, 피크 시간마다 지연 시간이 급격히 흔들리는 상황이 반복됩니다.
가장 빠른 해법은 API를 유지하거나 단기 GPU 임대로 먼저 검증하는 것입니다. 부하가 낮거나 모델 버전이 계속 바뀌면 장기 자체 구축을 미루고, 안정적인 부하와 분산 추론 운영 능력이 확인된 경우에만 직접 구축을 검토해야 합니다.
이 글은 AI 창업팀과 에이전트 제품팀, MLOps 엔지니어, 인프라 예산 담당자를 위한 판단 기준을 다룹니다. 모델 교체 가능성을 유지해야 하는 팀, 대형 MoE 모형의 메모리와 비용을 계산해야 하는 팀에 적합합니다.
활성 매개변수와 실제 상주 용량
MoE 모형은 일부 전문가만 토큰 계산에 참여합니다. 그러나 활성 매개변수가 곧 필요한 그래픽 메모리라는 뜻은 아닙니다. 라우팅되지 않은 전문가의 가중치도 실행 방식에 따라 장치 메모리나 호스트 메모리에 남아야 합니다.
실제 용량은 다음처럼 나눠 계산해야 합니다.
필요한 전체 메모리
= 가중치와 양자화 정보
+ 실행 중간값과 통신 버퍼
+ 키·값 캐시
+ 안전 여유 공간
여기서 반드시 구분해야 하는 상태는 세 가지입니다.
- 적재 가능: 파일을 읽고 모델 객체를 만드는 단계입니다.
- 생성 가능: 단일 또는 소수 요청을 실제로 처리하는 단계입니다.
- 업무 부하 수용 가능: 목표 동시성, 출력 길이, 지연 시간, 장애 재시도를 견디는 단계입니다.
예를 들어 공개 커뮤니티 자료는 Kimi K3를 전체 매개변수 2.8조 개, 토큰당 활성 전문가 16개와 전체 전문가 896개, 문맥 길이 100만 토큰으로 소개합니다. 다만 해당 자료는 공식 모델 카드가 아니라 커뮤니티 글이므로, 수치는 배포 구매 결론이 아니라 검증 대상 변수로만 사용해야 합니다. Kimi K3 공개 자료
주의: 활성 매개변수, 이론상 비트 수, 저장소 파일 크기 중 하나만으로 생산 환경의 그래픽 메모리를 확정하면 안 됩니다. 캐시 길이와 동시 요청이 바뀌면 같은 가중치도 필요한 용량이 달라집니다.
실행 도구와 장치 연결성
파일을 내려받을 수 있다는 사실은 현재 실행 도구가 그 파일을 올바르게 읽는다는 뜻이 아닙니다. 양자화 형식, 커널, 드라이버, 통신 라이브러리와 모델 구조가 모두 맞아야 합니다.
검토 순서는 다음과 같습니다.
- 공식 모델 카드에서 가중치 형식과 권장 실행 도구를 확인합니다.
- 가중치 색인에서 파일 수와 각 파일의 형식을 확인합니다.
- 사용하는 실행 도구의 해당 구조와 양자화 지원 여부를 확인합니다.
- 단일 장치 로딩 로그에서 실제 메모리 배치를 확인합니다.
- 다중 장치 실행 시 텐서 병렬화, 파이프라인 병렬화, 전문가 병렬화를 분리해 시험합니다.
- 장치 간 통신 지연과 장애 시 재시작 시간을 기록합니다.
vLLM 문서는 MoE 모형에서 전문가 병렬화를 사용할 수 있고, 텐서 병렬화와 데이터 병렬화를 조합할 수 있다고 설명합니다. 텐서 병렬화는 가중치를 나누지만 동기화 비용을 키울 수 있고, 파이프라인 병렬화는 장치 간 층 분배로 메모리를 줄이는 대신 지연 시간이 늘어날 수 있습니다. vLLM 병렬화 문서
전문가 부하가 고르지 않으면 특정 장치에 요청이 몰립니다. vLLM의 전문가 부하 균형 기능은 재배치용 중복 전문가를 사용하며, DeepSeek V3 예시에서는 전문가 순위당 중복 전문가 하나의 추가 메모리 부담이 약 2.4 GB로 설명됩니다. 이 수치는 Kimi K3나 DeepSeek V4의 실제 요구량이 아니라, 부하 균형 기능 자체가 추가 용량을 요구할 수 있다는 참고값입니다. 전문가 병렬화와 추가 메모리 공식
모델별 확인 수준
세 모델을 같은 공식으로 비교하되, 입력 데이터의 확정 수준은 분리해야 합니다.
| 대상 | 현재 비용 계산에 넣을 정보 | 계산에서 보류할 정보 |
|---|---|---|
| Kimi K3 | 공개된 구조 설명, 양자화 형식, 공식 자료 존재 여부 | 커뮤니티가 제시한 실제 장치 수와 생산 처리량 |
| DeepSeek V4 | 공식 모델 목록, 모델 카드, 기술 보고서, 공식 실행 안내 | 비공식 장치 조합과 커뮤니티 추정 비용 |
| Qwen3.8 Max | 공식 저장소와 파일 목록이 확인된 뒤 입력 | 출시 예측, 게시판의 가중치 크기, 미확인 메모리 요구량 |
DeepSeek는 공식 투명성 페이지에서 V4.0의 모델 카드와 기술 보고서를 별도로 연결하고 있습니다. 따라서 DeepSeek V4는 해당 문서에서 확인한 구조와 실행 조건만 비용 공식에 넣어야 합니다. DeepSeek 공식 모델 목록
Qwen3.8 Max는 공식 모델 저장소, 모델 카드, 파일 목록이 확인되기 전까지 대기 행으로 남겨야 합니다. 커뮤니티 게시물이나 출시 예측은 검색 열기를 설명하는 자료일 뿐입니다. 구매 수량이나 장기 임대 기간을 결정하는 근거로 사용할 수 없습니다. Qwen 관련 커뮤니티 논의
API와 자체 구축의 비용 공식
API 비용은 단순 호출 횟수가 아닙니다.
API 총비용
= 입력 토큰 비용
+ 출력 토큰 비용
+ 추론 모드 비용
+ 도구 호출 비용
+ 실패 재시도 비용
자체 구축 비용은 다음 항목을 포함해야 합니다.
자체 구축 총비용
= 가속기 사용료 또는 감가상각
+ 저장 공간과 네트워크 전송
+ 모니터링과 로그 보관
+ 배포·업데이트·장애 복구 인력
+ 예비 용량과 유휴 시간
+ 실패 재시도와 위험 준비금
비교식은 다음과 같습니다.
유효 요청당 자체 구축 비용
= 자체 구축 총비용 ÷ 성공적으로 완료한 요청 수
여기서 성공 요청 수는 전체 요청 수가 아닙니다. 시간 초과, 서버 오류, 품질 기준 미달, 재시도 요청을 따로 기록해야 합니다. API도 같은 업무 부하와 같은 품질 기준으로 비교해야 합니다.
| 비용 변수 | 수집할 기록 | 놓치기 쉬운 비용 |
|---|---|---|
| 요청량 | 시간대별 요청 수와 성공률 | 실패 재시도 |
| 토큰량 | 입력·출력 토큰과 문맥 길이 | 긴 에이전트 기록 |
| 동시성 | 평균과 피크 동시 요청 | 피크 대비 예비 장치 |
| 지연 목표 | 첫 토큰과 전체 완료 시간 | 병렬화 통신 지연 |
| 가동 시간 | 실제 사용 시간과 유휴 시간 | 밤과 주말의 빈 장치 |
| 운영 인력 | 배포, 감시, 복구 시간 | 모델 교체와 보안 점검 |
하루 호출량만으로 “몇 번부터 자체 구축이 유리하다”고 말할 수 없는 이유가 여기에 있습니다. 짧은 요청이 흩어져 있으면 API가 유리할 수 있습니다. 반대로 긴 출력과 일정한 동시성이 매일 반복되면 GPU 임대가 먼저 유리해질 수 있습니다.
짧은 검증 주기의 운영 절차
사이트에서 확인 가능한 임대 조건과 실제 압축 기록이 확보되지 않은 경우, 특정 장치 가격이나 처리량을 임의로 채우면 안 됩니다. 대신 다음 절차로 각 팀의 숫자를 직접 수집해야 합니다.
- 업무 부하를 고정합니다. 최근 요청 로그에서 입력 길이, 출력 길이, 동시성, 피크 시간을 분리합니다.
- 모델 파일을 검증합니다. 모델 카드, 가중치 색인, 라이선스, 양자화 형식을 저장합니다.
- 최소 실행을 기록합니다. 시작 명령, 장치 수, 최대 메모리 사용량, 로딩 시간과 오류 로그를 보관합니다.
- 실제 요청으로 압축합니다. 빈 입력이나 반복 토큰이 아니라 대표 업무 요청을 사용합니다.
- 유효 처리량을 계산합니다. 전체 생성 토큰이 아니라 성공한 요청의 완료 토큰을 기준으로 합니다.
- 피크와 회복을 시험합니다. 동시 요청 증가, 장치 한 개 중단, 프로세스 재시작, 캐시 부족 상황을 기록합니다.
- API와 같은 표로 환산합니다. 동일한 입력·출력 길이와 목표 지연 시간으로 비용을 맞춥니다.
검증 기간에는 시작 성공보다 안정 실행 시간이 더 중요합니다. 한 번 적재된 모델이 실제 피크 요청을 견디지 못하면 자체 구축의 전제는 성립하지 않습니다. 캐시 공간을 늘리기 위해 동시 시퀀스 수를 낮추거나 병렬화 방식을 조정할 수 있지만, 병렬화가 과도하면 동기화와 지연 비용이 커질 수 있습니다.
세 경로의 선택 기준
| 판단 항목 | API 유지 | 단기 GPU 임대 | 장기 자체 구축 |
|---|---|---|---|
| 모델 변경 | 가장 쉬움 | 비교적 쉬움 | 변경 비용 큼 |
| 초기 비용 | 낮음 | 중간 | 높음 |
| 용량 검증 | 제공 환경에 의존 | 직접 측정 가능 | 직접 설계 필요 |
| 유휴 시간 | 거의 없음 | 기간 내 부담 | 상시 부담 |
| 데이터 통제 | 계약과 제공 범위 확인 | 환경 설계에 따라 다름 | 가장 높음 |
| 장애 대응 | 제공자 의존 | 팀 책임 증가 | 팀 책임이 큼 |
| 적합한 상황 | 수요 변동, 빠른 실험 | 짧은 압축, 출시 전 검증 | 안정 부하, 명확한 통제 요구 |
다음 조건을 만족하면 직접 구축 후보가 됩니다.
- [ ] 같은 모델과 실행 도구를 일정 기간 유지할 계획이 있습니다.
- [ ] 피크 동시성과 목표 지연 시간이 로그로 확인되었습니다.
- [ ] 완전한 가중치 상주량과 캐시 여유 공간을 측정했습니다.
- [ ] 장치 간 통신과 전문가 병렬화 구성을 재현했습니다.
- [ ] 장애 발생 후 복구 담당자와 복구 절차가 정해졌습니다.
- [ ] 유효 요청당 비용이 API와 단기 임대보다 낮게 계산됩니다.
- [ ] 보안, 데이터 보관, 모델 라이선스 조건을 검토했습니다.
반대로 아래 조건 중 하나라도 해당하면 구매 논의를 멈추는 편이 낫습니다.
- 모델 파일 또는 실행 도구가 아직 공식적으로 검증되지 않았습니다.
- 가중치가 자주 바뀌어 장기 환경이 곧 폐기될 수 있습니다.
- 부하가 짧고 불규칙해 장치가 대부분 유휴 상태입니다.
- 장애 복구와 장치 교체를 맡을 사람이 없습니다.
- 적재는 되지만 목표 동시성과 지연 시간을 재현하지 못했습니다.
API에서 임대로 넘어가는 시점
API는 모델 교체와 수요 변동에 강합니다. 데이터가 외부로 나가면 안 되는 업무, 일정한 지연 시간이 반드시 필요한 업무, 호출 비용이 급격히 커지는 업무에서는 한계가 분명합니다.
단기 GPU 임대는 그 중간에 있습니다.
- 실제 업무 요청으로 메모리를 확인할 수 있습니다.
- 모델 버전이 바뀌어도 장비를 장기 보유하지 않습니다.
- 유휴 시간이 계약 기간에 포함되는지 확인해야 합니다.
- 네트워크, 원격 접속, 저장 공간, 백업 정책을 따로 봐야 합니다.
ProxyMac의 요금과 이용 조건을 확인할 때도 단순 시간당 비용만 보지 말고, 필요한 검증 기간과 중단 가능성, 저장과 접속 조건을 함께 기록하는 것이 좋습니다. 실행 환경을 바꿀 때는 콘솔 사용 안내에서 배포와 접속 절차를 먼저 확인해야 합니다.
최종 판단
Kimi K3와 DeepSeek V4는 같은 비용 공식에 넣을 수 있지만, 같은 메모리 숫자나 같은 장치 수를 가정해서는 안 됩니다. Qwen3.8 Max처럼 공식 저장소와 파일 목록이 확인되지 않은 모델은 비용표의 대기 행으로 남겨야 합니다.
현재 API 중심 구조의 단점은 호출량이 커질수록 입력·출력 비용이 누적되고, 제공자의 모델 변경과 속도 정책에 영향을 받으며, 데이터 통제 범위가 제한될 수 있다는 점입니다. 반대로 자체 구축은 장치가 놀아도 비용이 발생하고, 분산 통신·캐시·장애 복구를 직접 책임져야 합니다.
따라서 모델이 아직 바뀌는 단계라면 ProxyMac에서 짧은 검증 환경을 마련해 실제 요청 로그를 먼저 대입하는 편이 합리적입니다. 일주일치 부하를 정리한 뒤 용량과 유효 처리량을 확인하고, 그 결과가 안정적으로 반복될 때만 장기 자체 구축으로 넘어가야 합니다.
