오픈 웨이트 모델 - 딥러닝 언어 모델

1모델 선택¶

모델을 선택할 때는 다음과 같은 요소를 고려해야 합니다.

용도: 모델을 사용할 목적에 따라 적합한 모델을 선택합니다. 예를 들어, 코드 생성, 자연어 처리, 멀티모달 등.
성능: 모델의 파라미터 수, 학습 데이터, 벤치마크 성능 등을 확인합니다.
하드웨어 요구사항: 모델을 실행할 GPU의 메모리 용량과 연산 성능을 고려합니다.
라이선스: 모델의 사용 조건과 라이선스를 확인합니다.

오픈 웨이트 모델(Open Weight Model)은 모델의 가중치(weights)가 공개되어 있는 인공지능 모델을 의미합니다. 이러한 모델은 연구자나 개발자가 자유롭게 접근하여 수정, 학습, 배포할 수 있습니다.

1.1서비스를 위한 고려 사항¶

모델은 GPU 서버가 필요합니다. 외부로 정보를 전송하지 않기 위해서는 내부 네트워크에서만 접근 가능한 서버를 구성해야 합니다. 서버를 구축하려면 다음 요소를 고려해야 합니다.

모델 크기
컨텍스트 크기
동시 접속자 수

가장 중요한 것은 모델의 크기와 컨텍스트 크기, 그리고 동시 접속자 수를 고려하여 적절한 하드웨어를 선택하는 것입니다.

1.2하드웨어 요구 사항 계산¶

하드웨어 요구 사항은 먼저 GPU 메모리에 모델과 요청 상태가 들어가는지를 계산하고, 그 다음 목표 처리량을 낼 수 있는지를 확인하는 순서로 산정합니다. 추론 서버에서 필요한 GPU 메모리는 다음과 같이 근사할 수 있습니다.

M_{total} \approx M_{weights} + M_{KV} + M_{runtime}

(1)

여기서 $M_{weights}$ 는 모델 가중치, $M_{KV}$ 는 모든 활성 요청의 KV 캐시, $M_{runtime}$ 은 연산 중간값과 CUDA 커널, 프레임워크가 사용하는 메모리입니다.

1.2.11. 모델 가중치 계산¶

파라미터가 $P$ 개이고 가중치 하나를 저장하는 데 $b$ 비트를 사용한다면 가중치 메모리는 다음과 같습니다.

M_{weights} = \frac{P \times b}{8}

(2)

예를 들어 32B 모델은 FP16/BF16에서 약 64 GB, INT8에서 약 32 GB, 4비트 양자화에서 약 16 GB의 가중치 메모리가 필요합니다. 실제 양자화 모델에는 스케일과 메타데이터가 추가되므로 계산값보다 조금 더 필요합니다. MoE 모델은 토큰마다 일부 전문가만 활성화되더라도 전체 가중치를 GPU에 올리는 구성이 일반적이므로, 메모리는 활성 파라미터 수가 아니라 전체 파라미터 수를 기준으로 계산합니다.

1.2.22. 컨텍스트와 KV 캐시 계산¶

Transformer는 각 요청의 이전 토큰에 대한 Key와 Value를 KV 캐시에 저장합니다. 일반적인 decoder-only 모델에서 요청 하나의 KV 캐시 크기는 다음과 같이 근사할 수 있습니다.

M_{KV,request} = 2 \times L \times H_{KV} \times D_{head} \times T \times B_{KV}

(3)

$L$ : Transformer 레이어 수
$H_{KV}$ : KV head 수
$D_{head}$ : head 차원
$T$ : 입력 토큰과 생성 토큰을 합한 실제 컨텍스트 길이
$B_{KV}$ : KV 원소 하나의 바이트 수(FP16/BF16은 2바이트, FP8은 1바이트)
앞의 2: Key와 Value 두 배열

GQA(Grouped Query Attention)나 MQA(Multi-Query Attention)를 사용하는 모델은 $H_{KV}$ 가 attention head 수보다 작아 KV 캐시가 크게 줄어듭니다. 따라서 모델 설정 파일의 num_hidden_layers, num_key_value_heads, head_dim을 확인해야 합니다. 서버가 KV 캐시 양자화를 지원한다면 $B_{KV}$ 도 줄일 수 있습니다.

동시에 활성화된 요청이 $C$ 개라면 전체 KV 캐시는 다음과 같습니다.

M_{KV} = C \times M_{KV,request}

(4)

여기서 $C$ 는 로그인한 사용자 수가 아니라 같은 순간에 추론 중인 요청 수입니다. 평균 요청 도착률이 초당 $\lambda$ 건이고 평균 처리 시간이 $S$ 초라면 필요한 동시 처리 요청 수는 대략 $C \approx \lambda S$ 로 추정할 수 있습니다. 트래픽이 몰리는 서비스를 설계할 때는 평균값 대신 피크 시간의 도착률과 긴 컨텍스트 비율을 사용해야 합니다.

1.2.33. 실행 오버헤드와 GPU 수 계산¶

활성화 값, 임시 작업 공간, CUDA graph, 메모리 단편화 등은 모델과 추론 엔진에 따라 달라집니다. 초기 용량 산정에서는 가중치와 KV 캐시 합계에 보통 10~20%의 여유를 두고, 실제 부하 시험으로 보정합니다.

M_{required} \approx (M_{weights} + M_{KV}) \times (1 + r)

(5)

$r$ 은 여유율이며, GPU 한 장의 사용 가능한 메모리가 $M_{GPU}$ 일 때 최소 GPU 수는 다음과 같습니다.

N_{GPU} = \left\lceil \frac{M_{required}}{M_{GPU}} \right\rceil

(6)

이 값은 메모리 기준의 최솟값일 뿐입니다. 모델을 여러 GPU에 분산하면 GPU 사이의 통신 비용이 생기므로 NVLink/NVSwitch 같은 고속 연결 여부도 확인해야 합니다.

1.2.4계산 예시¶

32B 모델을 4비트로 적재하고, $L=64$ , $H_{KV}=8$ , $D_{head}=128$ 인 모델이 BF16 KV 캐시를 사용한다고 가정합니다. 요청당 실제 컨텍스트가 32,768토큰이고 동시에 10개 요청을 처리한다면 다음과 같습니다.

가중치: $32\text{B} \times 4 / 8 \approx 16$ GB
요청당 KV 캐시: $2 \times 64 \times 8 \times 128 \times 32{,}768 \times 2 \approx 8$ GiB
10개 요청의 KV 캐시: 약 80 GiB
15% 여유를 포함한 합계: $(16 + 80) \times 1.15 \approx 110$ GB

따라서 메모리만 보면 80 GB GPU 두 장이 후보가 됩니다. 다만 모든 요청이 항상 최대 컨텍스트를 사용하는 것은 아니므로, 실제 컨텍스트 길이의 분포를 적용하면 더 현실적인 값을 얻을 수 있습니다. 반대로 긴 프롬프트의 prefill과 토큰 생성이 동시에 몰리면 계산량과 메모리 대역폭이 병목이 될 수 있습니다.

1.2.5처리량 검증¶

메모리에 들어간다고 해서 원하는 응답 속도가 보장되지는 않습니다. 최종 구성은 실제 모델과 추론 엔진으로 다음 항목을 측정하여 결정합니다.

피크 부하에서의 초당 입력 토큰 수와 출력 토큰 수
첫 토큰까지의 시간(TTFT)과 토큰 간 지연 시간(ITL)
요청당 평균·상위 백분위 컨텍스트 길이와 출력 길이
continuous batching, prefix caching, tensor/pipeline parallelism 적용 효과
GPU 사용률, 메모리 사용량, GPU 간 통신량

즉, 모델 크기는 기본 가중치 메모리를 결정하고, 컨텍스트 길이와 활성 동시 요청 수는 KV 캐시를 선형으로 증가시킵니다. 위 계산으로 최소 구성을 정한 뒤 예상 트래픽을 재현한 부하 시험을 수행하고, 목표 지연 시간과 처리량을 만족하도록 GPU 수와 배치 설정을 조정해야 합니다.

2온프레미스용 GPU 구성¶

온프레미스용 GPU 구성별 오픈 웨이트 모델

등급	모델	GPU	용도
Compact	Qwen3.8-27B FP8	1× RTX PRO 6000 96GB	소규모 코드/AI 서버
Professional	Qwen3-Coder-Next	2× H200	코드 에이전트 서버
Enterprise	GLM-5.3-Flash	4× H200	고성능, 소수 동접
Enterprise+	GLM-5.3-Flash	8× H200	1M context + 다중 agent
Large Enterprise	DeepSeek-V3.2	8× H200	대형 범용/agent
Legacy Large Coder	Qwen3-Coder-480B	8~16× H200	특별한 성능 우위가 있을 때만

3Qwen3.8-27B 배포 벤치마크 실측 (2026-08-29)¶

위 구성표의 첫 단계인 Qwen3.8-27B를 실제 클라우드 GPU 3종에서 측정했다. 상세 보고서는 onprem-benchmark/benchmark-report.md에, 비용 원장은 onprem-benchmark/results/cost-ledger.md에 기록되어 있다.

3.1측정 조건¶

모델: Qwen3.8-27B (vLLM, FP8/AWQ 양자화는 GPU별 최적 조합)
워크로드: 32K 컨텍스트 요청, 동시 접속 1~16 구간 스윕
지표: TTFT, 출력 처리량(tok/s), 동시 접속별 SLA 충족 동접 수

3.2GPU별 실측 요약¶

항목	RTX PRO 6000 ×1 (96GB)	H200 ×1	B200 ×1
총 입력 토큰	1,612,034	동일 워크로드	동일 워크로드
입력 처리량 배수	6.15×	(상세는 보고서)	(상세는 보고서)
TTFT	4.08s	—	—
출력 처리량	18.6 tok/s	—	—
SLA 충족 최대 동접 (32K)	8	16 (상한)	8
권고 등급	Conditionally Recommended	—	—
측정 비용 (857초)	USD 0.4975	USD 1.1386	USD 0.9563

3.3해석¶

RTX PRO 6000 ×1은 Compact 등급 답게 최소 비용으로 32K 기준 동접 8을 감당한다 — 소규모 팀의 코드/AI 서버로 현실적인 선택이다.
H200 ×1은 동접 16(측정 상한)까지 늘어나 Professional·Enterprise 단계의 단일 노드 후보다. 측정 상한에 걸렸으므로 실제 한계는 더 높다.
B200 ×1은 단가 대비 이 워크로드에서 이점이 제한적 — 32K 컨텍스트 구간에서는 H200 대비 우위가 확인되지 않았다.
전체 실험 컴퓨트 비용은 USD 19.38이었고, 이 중 실측 산출에 쓰인 비용은 USD 9.55다. 실패·중단 시도까지 원장에 남기는 것이 벤치마크 신뢰성의 일부다.

측정 방법론(반복·분산 기록, 컨텍스트/동시성 매트릭스, 도구 호출 조건)은 onprem-benchmark/model-benchmark-instruction.md을 따른다.

실험 재현을 위해 위 구성은 onprem-benchmark/configs/benchmark-matrix.yaml의 Phase 2~4 매니페스트와 연결해 두었다. Qwen3.8-27B는 cache 동기화 후 기준선·H200·B200을 측정하고, GLM-5.3-Flash와 DeepSeek-V3.2는 대형 모델 cache와 다중 GPU Pod가 준비되는 즉시 동일한 context/concurrency 규칙으로 측정한다. 실제 TTFT·처리량이 확보되기 전에는 이 표를 실측 결과로 해석하지 않는다.

실험 예산은 Phase 1에서 약 2.09달러(RTX PRO 6000 1시간), Phase 2에서 6.68달러 + B200 시간당 단가, Phase 3에서 183.60달러 + 8×B200 시간당 단가를 상한으로 잡는다. Phase 4는 기존 raw 결과를 재사용하고 실패 case만 재실행한다. 대형 모델 cache는 모델별 임시 저장소로 운영하며, 측정 종료 후 삭제해 저장 비용을 제한한다.

캐시 운영은 로컬 Docker volume을 원본으로, RunPod network volume을 페이즈 기간의 임시 복제본으로 구분한다. 결과 회수와 검증이 끝나면 원격 복제본만 삭제하고 로컬 캐시는 유지해 필요할 때 재동기화한다. 로컬 디스크 용량이 부족한 경우에는 대형 모델을 한 번에 하나씩 동기화·측정·정리한다.

GLM-5.3-Flash는 먼저 H200×4, B200×4, H200×8을 각 30분 상한으로 순차 검증한다. 이 1차 예산은 USD 27.54 + 2×B200 시간당 단가이며, 모델 로딩이 지연될 때만 개별 작업을 1시간까지 연장한다. 따라서 Phase 3의 기존 USD 183.60은 실제 필수 지출이 아닌 전체 대형 모델 최악 상한으로 해석해야 한다.