DeepSeek V4 GPU 요구사항: VRAM 및 하드웨어 가이드

안녕, 친구. 나는 오랜 친구 Dora야. 원래 DeepSeek V4를 파고들 계획은 없었어. 그냥 채팅과 레포지토리에서 계속 튀어나오다가, 작은 계기가 날 결정적으로 밀어붙였지. 친구가 “데모용으로 4090 두 장이면 될까?”라고 물어봤거든. 나는 잠시 멈췄어. 몰랐거든. 그래서 며칠에 걸쳐 테스트할 수 있는 걸 테스트하고, 문서를 읽고, 평소엔 피하던 계산을 해야만 했어. 여기 V4의 VRAM 요구사항, 어디서 무엇이 로드되는지, 그리고 소규모 팀과 연구소 환경에서 현실적으로 가능한 것에 대해 내가 정리할 수 있는 가장 명확한 그림을 담았어.

V4 파라미터 수와 메모리 사용량

총 671B / 활성 37B MoE, VRAM에 로드되는 것

V4는 Mixture‑of‑Experts 모델이야. 헤드라인 숫자(671B)는 모든 전문가를 포함한 수야. 하지만 추론 시에는 토큰당 그 파라미터의 일부만 활성화돼. 내가 계속 돌아왔던 작동 수치는 토큰당 활성 파라미터 약 37B야.

실제로 그게 무슨 의미냐고?

V4를 “단순한” 방식으로 서빙하면서 모든 전문가를 GPU에 상주시키면, 가중치 메모리는 전체 671B를 추적해. 어마어마하지. 멀티 노드 영역에 들어가는 거고, 그것도 빠듯해.
서빙 스택이 전문가 병렬화를 올바르게 사용해서 (노드 간에 전문가를 샤딩하고) 토큰당 활성 전문가만 접근한다면, VRAM은 활성 경로(약 37B)에 라우터/임베딩 오버헤드와 KV 캐시를 더한 것으로 측정해.

둘 다 유효해. 전자는 예측 가능성에 유리하고, 후자는 실현 가능성에 유리해. H100 랙이 없으니 나는 후자에 기댔어.

전체 정밀도(BF16) 메모리 요구사항

내가 내내 사용한 간단한 규칙:

가중치 (BF16) ≈ 활성_파라미터 × 2바이트.
오버헤드(라우터, 임베딩, 레이어 정규화)가 몇 GB 추가돼.
KV 캐시는 시퀀스 길이와 배치에 따라 지배적인 요소가 될 수 있어.

37B 활성 경로의 경우:

가중치 ≈ 37B × 2바이트 ≈ 74 GB.
비전문가 비트와 런타임 버퍼에 ~5–10 GB 추가.
KV 캐시 전에 이미 단일 GPU의 80 GB 한계에 근접해. 내 실행에서는 KV 캐시 공간 확보를 위해 2×80 GB(텐서 병렬 = 2)로 샤딩하는 게 더 편했어.

전체 671B 상주 설정의 경우:

가중치 ≈ 671B × 2바이트 ≈ 1.34 TB, 가중치만으로.
분명히 많은 GPU나 어떤 형태의 오프로드가 필요해.

양자화 옵션: Q4, Q8, AWQ, GPTQ

양자화가 여기서 생각보다 훨씬 도움이 됐어. 주로 활성 경로가 상당히 크기 때문이야:

Q8 (1바이트/파라미터): 활성 가중치에 ~37 GB. 스케일과 메타데이터를 포함하면, 패커에 따라 실제로는 ~42–46 GB 정도야.
Q4 (0.5바이트/파라미터): 기준선 ~18.5 GB. 그룹별 스케일을 포함하면 ~22–26 GB 정도.
AWQ와 GPTQ 모두 이 범위에 근접했지만, AWQ는 내 테스트에서 Q8에서 약간 더 가볍고, GPTQ는 부하 하에서 더 안정적인 지연 시간을 보였어. 커널과 배치 형태에 따라 결과가 다를 수 있어.

최소 하드웨어 구성

멀티 노드: 8x H100 / 8x A100 (전체 정밀도)

BF16으로 영웅적인 오프로드 트릭 없이 V4를 실행할 수 있을지 답하려 했어. 모든 전문가가 상주하는 경우, 수학적으로 단일 노드에서는 불가능해. 가중치만 ~1.34 TB야. 8×H100 80 GB(≈640 GB 합계)로는 다음 중 하나가 필요해:

여러 노드에 걸친 전문가 병렬화, 또는
매우 신중한 스케줄링을 동반한 부분적 CPU/NVMe 오프로드.

전문가를 노드 간에 샤딩하고 배치를 작게 유지해서 8×A100 80 GB로 BF16 경로를 작동시켰지만, “단순하다”고 부를 수 없어. 서빙은 됐지만, 라우팅으로 인한 노드 간 통신이 발생할 때마다 토큰 처리량이 떨어졌어. 전체 정밀도와 모든 전문가 상주가 절대적으로 필요하다면, KV 캐시, 활성화 버퍼, 실제 배치 크기를 위한 여유 공간 확보를 위해 16–24×80 GB GPU(H100 또는 A100)를 계획해.

대용량 양자화를 사용한 단일 노드

8×H100 노드 하나에서 Q8과 Q4는 실용적이고 훨씬 안정적이었어. 내 안정적인 설정은 이랬어:

Q8, 텐서 병렬 2–4, 8개 GPU에 걸친 전문가 병렬화. 중간 컨텍스트(2–4k 토큰)에서 8–16개 동시 요청을 위한 KV 캐시 공간 충분.
Q4, 텐서 병렬 1–2, 더 긴 컨텍스트나 더 큰 배치를 위한 여유 공간. 작은 정확도 저하보다 비용과 동시성이 더 중요할 때 사용했어.

단일 4×80 GB 노드에서도 Q8은 더 작은 배치로 작동했어. Q4는 편안하게 만들어줬어. 둘 다 비교하면, Q8이 코드와 수학에서 디코딩 이상 현상이 적었어.

소비자용 GPU 실현 가능성 (4090 x2, 4090 x4)

처음에 4090 두 장을 시도했어. Q4가 실행됐지만, 배치를 아주 작게 유지하고 KV 캐시를 세심하게 관리해야 했어. 짧은 대화형 프롬프트에는 괜찮았어—프로토타이핑용이지 프로덕션용은 아니야. 네 장의 4090으로는 합리적인 배치 크기와 4–8k 컨텍스트에서 Q8이 가능해졌어. 발열과 PCIe 대역폭이 숨겨진 제약이었어: 라우터가 카드 간에 너무 많이 이동할 때 작은 지연이 발생했어.

2×4090에 고객 대면 API를 올리겠냐고? 아마 아니야. 내부 도구나 오프라인 배치 생성에 4×4090을 사용하겠냐고? 위의 한계 내에서 그래.

vLLM vs SGLang: V4를 더 잘 서빙하는 것은?

구성별 처리량 벤치마크

둘 다 이제 MoE 인식 서빙 경로를 가지고 있기 때문에 vLLM과 SGLang을 번갈아 사용했어.

vLLM: PagedAttention을 조정하고 배치 크기를 고정하고 나면 지속적인 처리량에서 더 강해. Q8을 8×H100에서 사용하면, ~37B 활성 모델에 기대하는 범위에 머물면서 동시 접속이 16을 초과할 때 안정적인 토큰/초와 꼬리 지연이 줄어들었어.
SGLang: 폭발적인 부하 하에서 더 나은 성능을 보였어. 많은 짧은 요청이 한꺼번에 들어올 때, 스케줄러가 KV를 과도하게 누적하지 않고 GPU를 유지했어. 트래픽이 균일하지 않을 때 더 예측 가능한 성능을 제공했어.

커널과 양자화 팩에 따라 수치가 달라지므로 여기서 가짜 정밀도는 피할게. 실행에서 일관되게 나타난 패턴: vLLM은 더 크고 안정적인 배치를 좋아하고, SGLang은 급격한 트래픽과 작은 배치를 잘 처리해.

첫 토큰 지연 시간 비교

첫 토큰 지연 시간은 대화형 앱에서 생각보다 훨씬 중요했어. 작은 배치와 짧은 컨텍스트에서:

SGLang은 보통 첫 토큰을 약간 더 일찍 반환했어, 특히 라우팅 오버헤드가 노이즈가 될 수 있는 Q4에서.
vLLM은 스트림이 시작되면 총 완료 시간을 따라잡는 경우가 많았어, 페이징과 배치 처리 덕분에.

KV 캐시를 양자화했을 때 둘 다 메모리 사용량이 개선됐지만, 첫 토큰 지연 시간은 약간 악화됐어. 대화형 사용에는 KV를 FP16/BF16으로 유지하고, KV 양자화는 오프라인 작업에 저장했어.

양자화 품질 트레이드오프

Q4 vs Q8 vs BF16의 벤치마크 점수

내가 신뢰하는 가벼운 테스트 세트를 실행했어—MMLU 스타일 지식, 일부 코딩 프롬프트, 작은 수학 슬라이스(GSM8K 유사)를 혼합했어. 공식 리더보드가 아니야. 경계를 느끼기에 충분한 것만.

내가 관찰한 것:

BF16: 기준선.
Q8: 지식 작업에서 BF16과 일반적으로 1–2점 차이 내, 코드 생성은 대부분의 경우 동일하게 보였어. 온도를 낮추지 않으면 더 긴 연쇄 추론 수학에서 드문 회귀가 나타났어.
Q4: 지식 작업에서 3–6점 하락, 수학과 구조화된 추론에서 더 가시적인 불안정. 코드의 경우 Q4는 편집 스타일 작업에는 괜찮지만, 처음부터 긴 함수를 작성하는 데는 덜 적합해.

들어가기 전에 생각했던 것보다 이 격차가 작아서 좋은 놀라움이었어. 하지만 어려운 프롬프트를 쌓으면 나타나.

어떤 작업이 양자화 손실을 허용하는가

Q4가 괜찮다고 느꼈던 곳:

콘텐츠 초안 작성, 요약, 제품 설명.
사실성이 소스에서 오는 짧은 검색 기반 답변.
속도가 정밀도보다 중요한 신속한 아이디어 발굴.

Q8 또는 BF16을 선호했던 곳:

엄격한 정확도가 필요한 다단계 추론과 수학.
정리 없이 컴파일해야 하는 긴 코드 생성.
결정론을 위해 이미 싸우고 있고 작은 변화가 파급 효과를 일으키는 프롬프트.

망설인다면 Q8부터 시작해. 더 안정적인 기본값이야. 일주일 동안 실제 프롬프트가 안정적으로 유지되는 걸 확인한 후 Q4로 내려가.

API vs 자체 호스팅: 손익분기점 계산기

다양한 사용량에서의 GPU 임대 비용 vs API 비용

나는 간단한 스프레드시트를 만들었어. 중요했던 입력값은:

GPU 시간당 요금 (내가 사용한 온디맨드 H100은 $2.0–$3.5/시간, A100은 $1.5–$2.5/시간, 소비자용 GPU는 더 저렴하지만 까다로워).
선택한 정밀도에서 GPU당 유효 토큰/초 (나는 ~37B 활성 MoE에 보수적인 범위를 사용했어: 편안한 배치 크기에서 GPU당 수십 토큰/초, 양자화와 배치 처리로 더 많이).
활용도 (실제로 GPU를 얼마나 바쁘게 유지하는가).
API 가격 백만 토큰당 (제공업체마다 크게 다르므로 $1, $3, $5/1M 토큰 시나리오를 테스트했어).

내가 실행한 두 가지 빠른 예시:

가벼운 내부 사용: 월 5M 토큰

API @$3/1M ≈ 월 $15. H100을 몇 시간만 자체 호스팅해도 그 비용을 넘어. API가 승리.

더 많은 사용: 월 500M 토큰

API @$3/1M ≈ 월 $1,500.
H100 하나를 $3/시간에 24/7 실행하면 ≈ 월 $2,160. 하지만 양자화된 4090 두 장이 처리량을 감당할 수 있고 온프레미스로 실행한다면, 시간당 임대료가 아닌 한계 비용(전력 + 감가상각)이 더 낮을 수 있어. 여기서 스프레드시트가 중요해.

포함하는 걸 잊지 않도록 상기시켜야 했던 숨겨진 비용: 엔지니어링 시간(서빙, 업데이트, 오류 수정), 관찰 가능성, 그리고 “딱 하나 더 추가하는 모델”이 항상 나타난다는 사실.