딥시크 v4 플래시, DwarfStar용 GGUF 공개…로컬 구동 문턱 낮춘다

딥시크 v4 플래시의 DwarfStar 구성용 GGUF 변환본이 커뮤니티에 올라왔다. DSpark MTP 헤드가 함께 포함된 구성이라, 개인 장비에서 돌려 보려는 시도가 곧바로 이어지고 있다. 원 모델은 허깅페이스의 deepseek-ai/DeepSeek-V4-Flash-0731 저장소에 있다.

GGUF가 붙는다는 것의 의미

원본 가중치가 공개돼도 개인 장비에서 바로 돌아가지는 않는다. 연구용으로 배포되는 가중치는 대체로 FP16·BF16 형식이고, 파일이 여러 조각으로 나뉘어 있으며, 실행에 파이썬 프레임워크 한 벌이 필요하다.

GGUF는 양자화된 가중치를 하나의 파일로 묶는 포맷이다. 이 변환본이 나와야 로컬 런타임에서 곧장 로드된다. 모델 공개 시점과 로컬에서 실제로 돌아가는 시점 사이의 간격을 메우는 게 커뮤니티 변환본의 역할이다.

배포 형태	필요한 것	대상
원본 가중치 (safetensors)	GPU 여러 장 · 파이썬 스택	연구 · 파인튜닝
GGUF 양자화본	런타임 하나 · 카드 1~2장	로컬 추론
API	계정 · 네트워크	프로덕션 서비스

MTP 헤드가 왜 같이 왔나

MTP(Multi-Token Prediction)는 한 번의 전방 계산에서 여러 토큰을 한꺼번에 예측하도록 보조 헤드를 두는 방식이다. 예측한 토큰들을 본체가 검증해 맞으면 그대로 채택하고 틀리면 버린다. 맞는 비율이 높을수록 초당 토큰 수가 올라간다.

로컬 환경처럼 메모리 대역폭이 병목인 곳에서 체감이 크다. 가중치를 한 번 읽어 오는 비용으로 토큰을 여러 개 뽑아내기 때문이다. 반대로 배치를 크게 묶어 돌리는 서버 환경에서는 이득이 상대적으로 작다.

내 장비에 들어가나 — 계산부터

정확한 파라미터 수가 확정 공개되기 전이라 단정할 수 없다. 대신 일반적인 계산 기준을 두고 보면 감이 잡힌다. 가중치 용량은 대략 파라미터 수 × 양자화 비트 ÷ 8이다. 아래는 70B 모델을 기준으로 한 계산 예시로, 컨텍스트 캐시와 런타임 오버헤드는 뺀 값이다.

양자화	가중치 용량 (70B 기준)	FP16 대비
FP16	약 140 GB	100
Q8	약 70 GB	50
Q6_K	약 52 GB	37
Q4_K_M	약 40 GB	29
Q3_K_M	약 32 GB	23

실제로는 여기에 KV 캐시가 더 붙는다. 컨텍스트를 길게 쓰면 캐시가 가중치만큼 커지는 경우도 있으니, 가중치 용량 = 필요 VRAM으로 잡으면 거의 항상 모자란다. 여유를 20~30% 더 잡는 편이 안전하다.

양자화를 어디까지 내릴 것인가

경험칙은 대체로 이렇다.

1. Q8 — 원본과 거의 구분이 안 된다. 용량이 허락하면 기준선으로 쓴다.
2. Q6_K — 실무에서 손실을 느끼기 어렵다. 가성비 구간.
3. Q4_K_M — 가장 널리 쓰인다. 요약·분류·추출에는 충분한 경우가 많다.
4. Q3 이하 — 장문 추론과 코드에서 티가 나기 시작한다. 급할 때만.

숫자로 고르지 말고 자기 업무 프롬프트 100건으로 두 후보를 나란히 돌려 비교하는 편이 빠르다. 공개 벤치마크는 우리 업무와 분포가 다르다.

도입 전 확인할 것

1. 출처와 무결성 — 커뮤니티 변환본은 공식 배포가 아니다. 원 저장소와 체크섬을 확인한다.
2. 라이선스 — 변환본의 표기가 아니라 원 저장소 기준으로 다시 읽는다. 상업적 사용 조건이 모델마다 다르다.
3. 런타임 버전 — 새 아키텍처나 MTP 헤드는 런타임이 지원해야 동작한다. 지원 전이면 그냥 로드에 실패하거나, 더 나쁘게는 성능만 안 나온다.
4. 재현 가능한 설치 — 파일 해시와 런타임 버전을 기록해 둔다. 몇 달 뒤 같은 결과를 다시 만들어야 할 때가 온다.

흐름 안에서의 위치

중형 구간에 새 모델이 몰리는 국면의 연장선이다. DSV4 플래시 0731을 포함해 최근 몇 주 사이 중형 모델이 연달아 나왔고, 자체 호스팅을 검토 중이라면 지금이 후보군을 한 번에 비교하기 좋은 시점이다.

출처: r/LocalLLaMA 게시글 및 허깅페이스 모델 저장소. 성능 수치는 공개 확인 전이라 싣지 않았다.