GPU는 부족한데,
가진 GPU조차
다 쓰지 못합니다
CORE는 모델 조건만 받아 필요한 VRAM을 계산하고, 딱 그만큼만 할당합니다. 대여되지 않고 남은 자원은 기관 내부의 로컬 LLM이 채웁니다.
직접 계산해보기 →- 모델 가중치
- 12.6 GiB
- KV Cache
- 320.0 GiB
- 필요 GPU
- A40 × 9
GPU를 더 확보하는 것만큼, 가진 GPU를 제대로 쓰는 것이 중요합니다
같은 클러스터를 두고 세 주체가 각자 다른 이유로 손해를 봅니다. 누구는 계산을 못 해서, 누구는 손으로 배정하느라, 누구는 자원이 남는 줄도 몰라서.
모델과 양자화 방식, 컨텍스트 길이에 따라 필요한 VRAM이 얼마인지를 직접 계산해야 합니다.
잘못 요청하면 OOM으로 죽거나, 반대로 쓰지도 않을 자원을 붙잡아 둡니다.
요청 검토, 사용자별 배정, 작업 상태 확인을 전부 수작업으로 처리합니다.
누가 얼마나 쓰고 있는지 한눈에 파악할 방법이 없습니다.
작은 작업 하나에도 GPU 한 장이 통째로 묶입니다.
한쪽에서는 대기열이 밀리는데 다른 GPU에는 자원이 남아서 놀고 있습니다.
Microsoft 내부 딥러닝 플랫폼의 저활용 작업 400개에서 발견된 저활용 문제 건수. 그중 84.99%가 소수의 코드·스크립트 수정으로 개선 가능하다고 보고됨.
Alibaba MLaaS 클러스터 분석 규모. 낮은 GPU 활용률, 긴 대기 시간, 장비 간 부하 불균형이 주요 문제로 제시됨.
동적 GPU 공유와 자원 조절로 개선한 멀티테넌트 클러스터의 메모리 활용률. 연산 유닛 활용률은 +34%.
706건 수치는 “Microsoft 전체 GPU의 평균 활용률이 50%”라는 뜻이 아니라, 평균 활용률 50% 이하인 작업 400개를 표본으로 분석한 결과입니다.
조건만 고르면 필요한 VRAM이 나옵니다
실제 서비스가 쓰는 계산식을 그대로 옮겼습니다. 값을 바꿔가며 직접 확인해 보세요.
어떤 모델을 구동하시겠습니까?
모델 구조에 따라 KV Cache 계산이 크게 달라집니다.
어떤 정밀도로 실행할까요?
가중치 크기가 결정됩니다. 낮출수록 메모리는 줄지만 정확도가 떨어질 수 있습니다.
얼마나 긴 대화를 처리하나요?
입력과 출력을 합친 전체 시퀀스 길이입니다.
동시에 몇 개를 처리하나요?
모든 요청이 최대 길이를 쓴다고 가정하는 최악 조건으로 보장합니다.
KV Cache 정밀도
FP8로 바꾸면 KV Cache가 정확히 절반이 됩니다. 지원 여부는 모델·GPU·엔진 조합별로 검증이 필요합니다.
수식 기반 예상치입니다. 실제 자원은 대상 GPU에서 추론 엔진을 직접 실행하고 메모리 사용량을 프로파일링한 뒤 확정합니다.
이 숫자는 어디서 나왔나
궁금하지 않다면 넘어가도 됩니다. 궁금하다면 펼쳐 보세요.
KV Cache는 어떻게 계산하나요?+
일반적인 Full Attention 모델의 KV Cache는 다음 식으로 계산합니다.
T_total동시에 KV Cache에 저장되는 전체 토큰 수L_KVKV Cache를 사용하는 Attention 계층 수 — 전체 계층 수가 아닙니다2Key와 ValueH_KVKV Head 개수D_headAttention Head DimensionB_dtypeKV Cache 데이터 타입의 바이트 수 — BF16/FP16은 2, FP8/INT8은 1여기서 가장 많이 틀리는 지점
Qwen3.6-27B는 64계층 Full Attention 모델이 아니라 하이브리드 구조입니다. Gated DeltaNet 48계층과 Gated Attention 16계층으로 이루어져 있고, 일반적인 KV Cache를 쓰는 건 16계층뿐입니다.
동시 요청 20개 = 최대 길이 × 20 인가요?
항상 그렇지는 않습니다. 실제 KV Cache 사용량은 동시에 실행 중인 각 요청의 현재 시퀀스 길이 합계로 결정됩니다. 262,144토큰 요청 20개와 4,096토큰 요청 20개는 같은 동시 요청 수지만 필요한 KV Cache가 전혀 다릅니다.
이 계산기는 모든 요청이 최대 길이를 쓰는 최악 조건으로 보장합니다. 가장 안전하지만 가장 비쌉니다. 실제 서비스에서는 평균 길이 기준 보장이나 총 활성 토큰 수 직접 지정 같은 선택지를 함께 제공합니다.
안전 여유분 20%는 무엇을 덮나요?
가중치와 KV Cache만 더한 값은 이론상 최소치일 뿐입니다. 실제로는 다음이 추가로 필요합니다.
- 양자화 메타데이터 — 스케일, 제로포인트
- DeltaNet 계층의 recurrent state
- Activation 메모리와 Prefill 연산 Workspace
- CUDA Graph, 추론 엔진 내부 버퍼
- Tensor Parallel 통신 버퍼
- 메모리 단편화와 OOM 방지 여유 공간
그래서 이론값에 10~20%를 더합니다. AWQ INT4의 경우 양자화되지 않는 텐서가 남아 있어 실제 로딩 크기가 이론값보다 큽니다. 파라미터 수로 계산한 값보다 실제 체크포인트 파일 크기와 엔진 로딩 후 측정값을 우선합니다.
GPU 장수는 왜 딱 나눠떨어지지 않나요?
이 계산기는 권장 VRAM을 GPU 한 장 용량으로 나눈 뒤 올림합니다. 실제 배치에서는 Tensor Parallel과 Pipeline Parallel 조합에 따라 장수가 더 늘어날 수 있습니다. TP는 보통 Attention Head 수를 나눌 수 있어야 하기 때문입니다.
대여가 우선, 남는 공간은 로컬 LLM이 씁니다
기관이 보유한 GPU에서 대여 요청이 먼저 자원을 가져가고, 그러고도 남는 용량으로 기관 내부의 로컬 LLM을 구동합니다. 대여가 늘면 로컬이 줄고, 대여가 끝나면 로컬이 다시 확장됩니다.
여유 288 GiB로 로컬 LLM이 정상 구동 중입니다.
로컬 LLM에는 최소 보장량을 두지 않습니다. 대여 수요가 클러스터를 가득 채우면 로컬은 중단되고, 대여가 반납되면 자동으로 복구됩니다. 값은 설명을 위한 예시입니다.
기존 제품들과 뭐가 다른가
외부 GPU를 빌려 쓰는 것과, 이미 가진 GPU를 정책에 따라 나눠 쓰는 것은 다른 문제입니다.
| 평가 기준 | RunPod | Vast.ai | BARO Cloud | CORE |
|---|---|---|---|---|
| 기관 보유 GPU 내부 배포 | ✕ | △ | ○ | ○ |
| VRAM·연산량 세밀 분할 | ✕ | ✕ | ○ | ○ |
| 모델 조건 기반 VRAM 산정 | ✕ | ✕ | ✕ | ○ |
| 관리자 승인·사용자 정책 | ✕ | ✕ | △ | ○ |
| 원클릭 추론 API 생성 | ○ | ○ | ✕ | ○ |
| 내부 데이터 유지 | ✕ | ✕ | ○ | ○ |
MIG — 고정적이고 격리된 환경
NVIDIA MIG는 지원되는 GPU를 여러 개의 격리된 인스턴스로 분할합니다. 격리는 확실하지만 지원 GPU와 선택 가능한 프로파일에 제약이 있습니다. 한번 나눠두면 수요가 바뀌어도 그대로입니다.
HAMi — 유연하고 동적인 환경
Kubernetes 환경에서 GPU 메모리·코어·장치 수 단위의 공유와 제한, 장치 인식 스케줄링, 여러 종류의 가속기 지원을 제공합니다. 수요에 따라 배분이 움직일 수 있어 유휴 자원 재배분이 가능해집니다.
지금 어디까지 왔나
부풀리지 않고 있는 그대로 적습니다.
사용자 화면과 계산 로직
사용자가 직접 겪는 화면과 VRAM 계산 로직까지는 실제로 동작하는 수준으로 완성되어 있습니다. 이 페이지의 계산기가 그 로직을 옮긴 것입니다.
실제 자원 구동
그 뒤에서 실제 GPU 자원을 할당하고 추론 서버를 띄우는 부분은 아직 준비 단계입니다. Node Agent와 HAMi 연동을 진행 중입니다.
- 사용량 기반 과금 사용한 만큼만 자원을 쓰고 비용이 매겨지는 구조를 만들어, 실제 사용량 기반 과금 모델로 확장할 기반을 마련합니다.
- 범용 서비스로 확대 학교 내 소규모 검증을 시작으로, 다른 연구실이나 기관의 GPU 자원 공유 상황에도 적용 가능하게 키웁니다.
- 자원 배정 고도화 축적되는 사용 데이터를 바탕으로 자원 배정을 더 정교하게 추천해, 단순 대여를 넘어 운영 효율을 스스로 개선하는 서비스로 자리잡습니다.
팀 CORE
2026 경북 SW 성장기업 육성지원사업
부스에서 더 자세히 보여드립니다
계산기 뒤에서 실제로 무슨 일이 일어나는지, 지금 어디까지 만들었는지 직접 물어봐 주세요. 팀원이 부스에 있습니다.
2026h100@gmail.com →