조 단위 오픈 모델 셀프 호스팅
활성 파라미터만 넣어 계산했더니 예상 메모리가 충분했습니다. 그런데 모델 로딩 중 메모리가 바닥나거나, 짧은 질문은 되는데 에이전트 작업에서 서버가 멈춥니다.
가장 빠른 해결책은 활성 파라미터를 연산량으로만 보고, 셀프 호스팅 가능 여부는 전체 가중치와 실행 중 메모리로 다시 계산하는 것입니다. 전체 메모리 경로와 안정적인 처리량을 확인하지 못했다면 장기 서버를 먼저 사지 말고 API 또는 한시적 클라우드 서버로 실제 부하를 검증해야 합니다.
이 글은 Kimi K3와 DeepSeek V4의 활성 파라미터가 적다는 이유로 메모리 예산을 낮추려는 플랫폼 엔지니어, MLOps 책임자, AI 에이전트 팀을 위한 글입니다. 관리층에 “계산량이 작아도 배포 규모가 작아지지 않는다”는 점을 설명해야 하는 경우에도 활용할 수 있습니다.
활성 파라미터와 상주 가중치는 서로 다른 값입니다
MoE 모델에서 전체 파라미터는 모든 전문가와 공통 계층을 포함한 모델의 총량입니다. 활성 파라미터는 토큰마다 계산에 선택되는 경로의 규모입니다. 반면 가중치 상주량은 실행을 위해 서버 메모리에 올려 두어야 하는 범위입니다.
따라서 “활성 파라미터가 적으니 그만큼만 올리면 된다”는 계산은 첫 단계부터 잘못됩니다. Kimi K3 모델 카드는 전체 파라미터를 2.8조, 활성 파라미터를 1040억으로 표시합니다. 전문가 수는 896개이고 토큰마다 선택되는 전문가는 16개입니다. 이 수치는 한 토큰의 계산 경로를 설명하지만, 나머지 전문가 가중치가 자동으로 사라진다는 뜻은 아닙니다. Kimi K3 공식 모델 카드와 Kimi K3 구조 해설를 함께 확인해야 합니다.
DeepSeek V4도 같은 구조입니다. 공식 자료는 V4 프로를 전체 1.6조, 활성 490억으로, V4 플래시를 전체 2840억, 활성 130억으로 설명합니다. 두 모델 모두 긴 문맥을 지원하지만, 활성 값만으로 필요한 장치 수를 정하지 않습니다. DeepSeek V4 공식 모델 카드와 DeepSeek V4 플래시 공식 자료를 기준으로 값의 의미를 구분해야 합니다.
| 구분 | 의미 | 배포 판단에서의 역할 |
|---|---|---|
| 전체 파라미터 | 모든 전문가와 공통 계층의 합계 | 가중치 저장과 상주량의 출발점 |
| 활성 파라미터 | 토큰마다 계산에 참여하는 일부 경로 | 토큰당 연산량과 처리량 추정 |
| 가중치 상주 | 실행 중 메모리에 유지되는 모델 부분 | 장치 수와 분산 방식 결정 |
| 실행 중 메모리 | 캐시, 중간 버퍼, 통신 공간, 실행 공간 | 실제 시동 성공 여부 결정 |
MoE 모델의 메모리는 전체 파라미터와 활성 파라미터 중 어느 쪽으로 계산해야 합니까?
가중치를 모두 상주시키는 방식이면 전체 파라미터를 기준으로 계산해야 합니다. 전문가를 필요할 때만 불러오는 방식이라도 저장 장치 지연, 캐시, 사전 적재 범위, 동시 요청 수를 따로 검증해야 합니다. 활성 파라미터는 단독 메모리 공식이 아닙니다.
이론적인 비트 수와 실제 메모리는 다릅니다
FP4, MXFP4, FP8 같은 표기는 유용한 시작점입니다. 하지만 “파라미터 수 × 고정 바이트”로 최종 장치 구성을 확정하면 안 됩니다.
실제 차이는 다음 항목에서 생깁니다.
- 그룹별 스케일과 양자화 메타데이터
- 양자화되지 않은 공통 계층
- 임베딩과 출력 계층의 저장 형식
- 파일 포맷과 텐서 분할 방식
- 로더가 사용하는 임시 메모리
- 장치 사이에 복제되는 공통 가중치
- 실행 엔진이 예약하는 여유 공간
Kimi K3는 MXFP4 가중치와 MXFP8 활성값을 사용한다고 공식 모델 카드에 적혀 있습니다. DeepSeek V4 프로는 전문가 계층에 FP4, 대부분의 다른 파라미터에 FP8을 쓰는 혼합 형식으로 설명됩니다. 그러므로 두 모델을 같은 바이트 공식으로 비교할 수 없습니다. 모델 카드와 실행 문서를 기준으로 형식과 버전을 먼저 고정해야 합니다.
| 계산 단계 | 확인할 값 | 잘못 계산했을 때 생기는 문제 |
|---|---|---|
| 1단계 | 공식 전체 파라미터와 형식 | 저장 공간과 장치 수를 과소평가합니다 |
| 2단계 | 실제 분할 파일과 로더 방식 | 로딩 중 임시 메모리가 부족해집니다 |
| 3단계 | 문맥 길이와 동시 요청 | 캐시가 늘어 실행 중 중단됩니다 |
| 4단계 | 복제와 통신 버퍼 | 장치 총합은 맞아도 한 장치가 먼저 가득 찹니다 |
| 5단계 | 여유 공간과 장애 복구 | 재시작이나 재배포가 불가능해집니다 |
가중치를 올려도 실행이 시작되지 않는 이유
실행 메모리는 대략 다음처럼 나눠 보는 편이 안전합니다.
전체 실행 메모리 = 가중치 상주 + 캐시 + 활성값 버퍼 + 통신 버퍼 + 실행 공간 + 프레임워크 여유분
vLLM 문서는 모델 가중치뿐 아니라 활성값과 캐시를 장치 메모리에 배치한다고 설명합니다. 또한 메모리 사용률을 높이면 캐시와 처리량이 늘 수 있지만, 과도하게 설정하면 메모리 부족이 발생할 수 있다고 명시합니다. 텐서 병렬 크기와 최대 시퀀스 길이도 실행 설정에 포함됩니다. vLLM 실행 인자 문서를 확인해야 하는 이유입니다.
특히 AI 에이전트는 단일 질문보다 메모리를 더 빠르게 압박합니다. 도구 호출 결과가 대화에 누적되고, 추론 과정이 다시 입력으로 들어가며, 여러 요청이 동시에 대기하기 때문입니다. 문맥 길이를 짧게 고정한 시험은 실제 부하를 대표하지 못합니다.
DeepSeek V4는 백만 토큰 문맥을 목표로 설계됐고, 공식 자료는 V4 프로가 긴 문맥 조건에서 이전 세대보다 단일 토큰 연산량과 캐시 사용량을 줄였다고 설명합니다. 이것은 효율 개선이지 캐시가 사라진다는 뜻은 아닙니다. 긴 문맥, 도구 호출, 동시 요청을 포함한 별도 검증이 필요합니다.
여러 서버를 붙여도 처리량이 자동으로 늘지는 않습니다
가중치가 한 장치에 들어가지 않으면 텐서 병렬 또는 파이프라인 병렬을 검토하게 됩니다. 그러나 서버 수를 늘리는 순간 새로운 병목이 생깁니다.
- 서버 간 통신 지연
- 전문가 선택 결과를 전달하는 라우팅 비용
- 장치별 메모리 불균형
- 모델 파일을 읽는 저장 장치 속도
- 장애 발생 시 전체 요청을 다시 구성하는 시간
- 네트워크 혼잡으로 인한 첫 토큰 지연
공식 모델 카드에 특정 장치 수로 안정적인 생산 처리량이 보장되어 있지 않다면, “총 메모리 합계가 충분하다”는 말만으로 토폴로지를 확정해서는 안 됩니다. Kimi K3 공식 자료는 여러 실행 경로를 제시하지만, 팀의 문맥 길이와 동시성에서 안정적인 처리량을 보장하는 자료는 별도로 확보해야 합니다.
첫 번째 단계: 모델 버전을 고정합니다
모델 저장소의 커밋, 모델 카드, 양자화 형식, 라이선스, 실행 엔진 버전을 기록합니다. 커뮤니티 변환본이나 비공식 양자화 파일은 공식 모델과 같은 것으로 취급하지 않습니다.
두 번째 단계: 실제 가중치 경로를 계산합니다
전체 파라미터를 기준으로 이론적인 가중치 하한을 잡습니다. 이후 스케일, 메타데이터, 미양자화 계층, 분할 파일, 로딩 임시 공간을 더합니다. 이 단계에서 이미 장치 여유가 없으면 장기 배포를 중단합니다.
세 번째 단계: 실제 요청 조건을 고정합니다
최대 문맥 길이, 평균 입력 길이, 평균 출력 길이, 동시 요청 수, 배치 크기, 도구 호출 횟수, 재시도 횟수를 고정합니다. 한 항목이라도 비워 두면 캐시 예산이 의미를 잃습니다.
네 번째 단계: 짧은 시험과 긴 시험을 분리합니다
짧은 질문으로 시동 여부를 확인한 뒤, 실제 에이전트 기록을 재생합니다. 저장된 문서 검색, 도구 호출, 긴 추론, 실패 후 재시도를 모두 포함해야 합니다.
다섯 번째 단계: 네 가지 기록을 남깁니다
첫 토큰 지연, 안정 상태 처리량, 메모리 최고점, 장애 후 복구 시간을 각각 기록합니다. 한 번 성공한 최고 속도보다 반복 실행 중 최저 안정성이 더 중요합니다.
여섯 번째 단계: 중단선을 먼저 승인받습니다
다음 조건이면 장치 추가를 멈춥니다.
- 가중치와 실행 메모리가 동시에 닫히지 않습니다.
- 서버를 추가해도 처리량이 업무 목표에 도달하지 않습니다.
- 장애 복구와 모델 교체를 담당할 인력이 없습니다.
- 실제 이용량이 낮아 장치를 대부분 유휴 상태로 둡니다.
- 라이선스와 보안 책임을 조직이 감당하기 어렵습니다.
짧은 시험과 실제 에이전트 부하는 결과가 다릅니다
양자화한 조 단위 모델은 한 대의 서버에서 실행할 수 있습니까?
특정 형식과 장치 조합에서 시동될 가능성은 있습니다. 하지만 “실행된다”와 “서비스할 수 있다”는 다릅니다. 한 대에서 짧은 입력이 처리돼도 긴 문맥과 여러 에이전트 요청에서 캐시와 실행 버퍼가 부족할 수 있습니다. 공식 실행 예제가 있다고 해서 모든 장치 구성의 호환성과 처리량이 보장되는 것도 아닙니다.
활성 파라미터가 적은데 왜 여러 서버가 필요합니까?
활성 값은 토큰마다 계산되는 일부 전문가의 규모입니다. 전체 가중치 상주, 공통 계층 복제, 캐시, 통신 공간을 합치면 필요한 메모리가 커질 수 있습니다. 전문가를 여러 서버에 나누면 이번에는 라우팅과 네트워크가 처리량을 제한할 수 있습니다.
Kimi K3와 DeepSeek V4를 셀프 호스팅하기 전에 무엇을 계산해야 합니까?
모델 버전, 전체 파라미터, 활성 파라미터, 정밀도, 가중치 파일, 문맥 길이, 동시성, 캐시 형식, 실행 엔진, 서버 간 연결, 장애 복구 절차를 함께 계산해야 합니다. 이 중 하나라도 공식 근거 또는 재현 가능한 시험 기록이 없으면 장기 구매 결정을 미루는 편이 안전합니다.
자가 구축을 포기해야 하는 기준
자체 운영의 승자는 가장 큰 모델이 아닙니다. 실제 부하에서 메모리와 처리량을 재현할 수 있는 팀만 장기 클러스터를 선택해야 하며, 그렇지 않으면 API 또는 한시적 클라우드 검증이 우선입니다.
다음 체크리스트를 모두 통과한 뒤에만 장기 서버를 검토합니다.
- [ ] 공식 모델 저장소와 정확한 버전을 고정했습니다.
- [ ] 전체 가중치와 양자화 오버헤드를 확인했습니다.
- [ ] 문맥 길이와 동시 요청을 실제 업무 기준으로 정했습니다.
- [ ] 캐시와 실행 버퍼를 포함한 최고 메모리를 기록했습니다.
- [ ] 여러 서버의 통신 지연과 라우팅 비용을 측정했습니다.
- [ ] 첫 토큰 지연과 안정 처리량을 반복 측정했습니다.
- [ ] 실패 재시도와 장애 복구를 시험했습니다.
- [ ] 모델 교체와 보안 패치를 담당할 운영자를 정했습니다.
- [ ] 예상 이용률이 장기 장치 비용을 정당화하는지 검토했습니다.
어떤 상황에서 오픈 모델 셀프 호스팅을 포기해야 합니까?
첫째, 가중치와 실행 메모리가 닫히지 않으면 즉시 중단합니다. 둘째, 여러 서버를 붙여도 업무에 필요한 안정 처리량이 나오지 않으면 확장을 멈춥니다. 셋째, 이용률이 낮거나 장애 대응 책임자가 없으면 API로 돌아갑니다. 장기 클러스터는 모델을 띄울 수 있을 때가 아니라, 반복 가능한 운영 책임까지 닫힐 때 선택해야 합니다.
현재 방식이 API라면 초기에는 편하지만 요청 지연, 데이터 처리 정책, 사용량에 따른 비용 변동, 특정 모델과 실행 환경에 대한 통제 부족이 남습니다. 반대로 직접 서버를 사면 유휴 장치 비용, 냉각과 전력, 다중 서버 장애 복구, 모델 업데이트 책임을 떠안게 됩니다. 이런 조건이 아직 닫히지 않은 팀이라면 ProxyMac에서 제공하는 클라우드 맥 환경으로 제어부 개발과 검증 절차를 분리하는 편이 현실적입니다. ProxyMac 콘솔 안내에서 접속 흐름을 확인하고, ProxyMac 도움말에서 환경 사용 조건을 먼저 점검할 수 있습니다.
핵심은 맥 장치가 대형 가중치 클러스터를 대신한다는 뜻이 아닙니다. 제어부, 테스트 자동화, 에이전트 클라이언트는 맥에서 관리하고, 무거운 가중치 계층은 검증이 끝난 클라우드 서버에 두는 방식입니다. 아직 다중 서버 환경이 없거나 실제 부하를 재현해야 한다면, 장기 구매보다 ProxyMac의 임시 맥 환경으로 검증 절차를 정리한 뒤 다음 결정을 내리는 편이 실패 비용을 줄입니다.
