DeepSeek V4 Flash 0731 GGUF 공개, ‘무손실 4비트’가 중요한 이유

DeepSeek V4 Flash 0731 GGUF가 공개되면서 양자화 모델을 바라보는 기준이 조금 달라지고 있습니다. 보통 4비트 모델이라고 하면 FP16이나 BF16으로 학습한 모델을 변환 도구로 줄인 결과를 떠올립니다. 이번 사례에서 주목할 부분은 단순히 파일을 4비트로 압축했다는 사실이 아니라, 모델을 학습하는 단계부터 양자화 형식을 반영했다는 점입니다.

Unsloth가 공개한 무손실 버전은 168GB RAM, 3비트 버전은 110GB 사양입니다. 여기서 말하는 RAM이 실제 실행에 필요한 메모리인지, 저장 파일의 요구 사양을 가리키는지는 모델 저장소의 설명을 함께 확인해야 합니다. 다만 일반적인 개인용 PC에서 가볍게 실행할 수 있는 크기는 아니며, 대용량 메모리 시스템이나 여러 장의 GPU를 고려해야 하는 모델이라는 점은 분명합니다.

이번 공개에서 ‘무손실 4비트’가 다른 이유

일반적인 양자화는 학습이 끝난 모델의 가중치를 낮은 비트 수로 다시 표현하는 과정입니다. FP16 또는 BF16 가중치를 INT8, INT4, FP4 같은 형식으로 바꾸면 메모리 사용량과 연산량을 줄일 수 있지만, 원래 값의 정밀도가 낮아지면서 출력이나 성능에 차이가 생길 수 있습니다. 어떤 가중치를 얼마나 줄일지, 어떤 스케일 값을 사용할지에 따라 결과가 달라지는 이유입니다.

이번 DeepSeek V4 Flash 사례는 이 순서가 다릅니다. 딥시크가 QAT(Quantization-Aware Training), 즉 양자화 인식 학습 방식으로 훈련했다는 설명입니다. 모델이 최종적으로 낮은 비트 형식으로 사용될 것을 학습 과정에서부터 반영하기 때문에, 사후 변환에서 갑자기 정밀도를 잃는 문제를 줄일 수 있습니다.

특히 전체 가중치의 96%를 차지하는 전문가 파라미터가 처음부터 FP4 형식이라는 점이 핵심입니다. 이 경우 FP4는 학습이 끝난 뒤 억지로 줄인 표현이 아니라, 모델 구조와 학습 과정에 포함된 표현 방식에 가깝습니다. Unsloth는 이 비트를 GGUF 형식으로 옮겼고, 원본과 토큰 일치율 100%를 확인했다고 밝혔습니다.

다만 ‘토큰 일치율 100%’를 해석할 때는 범위를 구분해야 합니다. 특정 검증 과정에서 같은 입력에 대해 원본과 GGUF가 동일한 토큰을 출력했다는 의미이지, 모든 프롬프트와 모든 실행 환경에서 성능 차이가 절대 발생하지 않는다는 뜻으로 확대하면 안 됩니다. 그래도 변환 과정에서 출력이 달라질 수 있는 기존 양자화 모델과 비교할 때, 상당히 강한 검증 결과인 것은 맞습니다.

DeepSeek V4 Flash의 전문가 파라미터가 중요한 배경

DeepSeek V4 Flash는 많은 전문가를 선택적으로 사용하는 MoE(Mixture of Experts) 계열 모델로 이해할 수 있습니다. MoE 모델은 전체 파라미터를 모두 매번 계산하는 대신, 입력 토큰마다 일부 전문가를 선택해 계산합니다. 따라서 모델 전체 크기와 한 번의 추론에서 실제로 활성화되는 계산량은 서로 다를 수 있습니다.

여기서 혼동하기 쉬운 부분이 있습니다. 전문가 파라미터의 96%가 FP4라는 사실은 저장 및 메모리 효율과 직접 관련되지만, 모델 전체를 실행하는 데 필요한 메모리가 4비트 용량의 단순한 계산값과 정확히 일치한다는 뜻은 아닙니다. 비전문가 파라미터, 라우팅 계층, 임베딩, KV 캐시, 런타임 버퍼, 컨텍스트 길이 등이 추가로 메모리를 사용합니다.

그래서 ‘4비트 모델이니 원본의 4분의 1만 있으면 된다’고 계산하면 실제 실행 환경에서 부족할 수 있습니다. 무손실 버전 168GB와 3비트 버전 110GB라는 수치는 모델을 실제로 구동하려는 사람이 가장 먼저 확인해야 할 현실적인 기준입니다. 특히 긴 컨텍스트를 사용하거나 동시 요청을 처리하면 KV 캐시 때문에 필요한 메모리가 더 커질 수 있습니다. 정확한 수치는 사용하는 런타임과 설정에 따라 달라지므로, Hugging Face 저장소의 파일 설명과 권장 실행 조건을 확인해야 합니다.

GGUF로 공개됐다는 의미

GGUF는 주로 llama.cpp 계열 도구에서 사용하는 모델 파일 형식입니다. 모델 가중치뿐 아니라 토크나이저와 메타데이터를 한 파일 또는 관련 파일 묶음으로 관리하기 쉬워, 로컬 추론 환경에서 널리 사용됩니다. CPU와 GPU를 섞어 쓰는 실행, 일부 레이어만 GPU에 올리는 오프로딩 같은 구성이 가능한 것도 GGUF를 찾는 이유입니다.

이번 공개의 의미는 딥시크가 학습에 사용한 FP4 표현을 Unsloth가 일반적인 GGUF 실행 생태계로 가져왔다는 데 있습니다. 사용자는 원본 학습 체크포인트를 직접 다루지 않고도 GGUF 런타임을 통해 모델을 시험할 수 있습니다. 반면 GGUF라고 해서 모든 실행 프로그램이 동일한 방식으로 FP4를 처리한다고 단정할 수는 없습니다. 런타임 버전, GPU 백엔드, 지원하는 커널에 따라 속도와 메모리 사용량이 달라질 수 있습니다.

실행을 시도한다면 파일을 내려받기 전에 다음을 확인하는 편이 안전합니다. 첫째, 무손실 4비트 파일과 3비트 파일의 실제 용량입니다. 둘째, 사용하는 런타임이 해당 양자화 형식을 제대로 지원하는지입니다. 셋째, GPU VRAM만으로 가능한지, 시스템 RAM 오프로딩이 필요한지입니다. 넷째, 원하는 컨텍스트 길이와 동시 처리 수를 감당할 수 있는지입니다. 모델 파일이 저장된다고 해서 곧바로 여유 있게 추론할 수 있는 것은 아닙니다.

168GB 무손실 버전과 110GB 3비트 버전의 차이

앞서 정리한 대로 무손실 버전은 168GB RAM, 3비트 버전은 110GB 사양입니다. 두 파일의 차이는 단순히 숫자만의 문제가 아닙니다. 무손실 4비트는 원본 FP4 표현을 유지하는 데 초점이 있고, 3비트 버전은 더 작은 메모리 사용량을 위해 추가적인 비트 축소를 적용한 형태로 볼 수 있습니다.

	무손실 4비트	3비트
사양	168GB RAM	110GB RAM
목적	원본 FP4 표현 유지	메모리 사용량 축소
출력 일치	검증에서 토큰 100% 일치	동일하다고 가정하면 안 됨
고를 때	출력 일관성이 중요할 때	메모리 제약이 더 클 때

3비트는 장비 제약이 있는 환경에서 실행 가능성을 높일 수 있지만, 원본과의 출력 일치나 작업별 성능이 무손실 4비트와 같다고 가정해서는 안 됩니다. 특히 코드 생성, 긴 문서 처리, 에이전트 작업처럼 출력의 작은 차이가 누적되는 사용 사례에서는 단순한 벤치마크 점수보다 실제 업무 프롬프트로 확인하는 것이 중요합니다.

반대로 무손실 버전은 메모리 요구량이 훨씬 크기 때문에 하드웨어 비용과 운영 부담이 커집니다. 168GB를 안정적으로 확보할 수 없다면 실행 중 스왑이 발생하거나 응답 속도가 크게 떨어질 수 있습니다. 이때는 3비트 파일을 선택하거나 더 작은 모델을 사용하는 편이 현실적일 수 있습니다. 어느 쪽이 더 낫다고 일반화하기보다는, 출력 일관성이 중요한지와 메모리 제약이 더 큰지를 먼저 판단해야 합니다.

0731 버전의 성능 주장은 어떻게 봐야 하나

DeepSeek V4 Flash 0731은 모델 크기를 그대로 둔 채 재학습만 다시 했고, 딥시크가 자체 공개한 에이전트 벤치마크 전부에서 상위 모델인 V4-Pro-Preview를 앞섰습니다. 이 결과대로라면 0731 버전은 단순한 경량화 모델이 아니라, 같은 규모에서 학습 품질과 에이전트 작업 수행력을 개선한 버전으로 볼 수 있습니다.

다만 벤치마크 결과는 평가 세트, 프롬프트 형식, 도구 사용 방식, 반복 횟수와 같은 조건에 영향을 받습니다. ‘모든 자체 공개 에이전트 벤치마크에서 앞섰다’는 표현은 해당 평가 범위 안에서 이해해야 하며, 일반적인 대화, 코딩, 수학, 검색 기반 작업까지 자동으로 우수하다는 의미는 아닙니다. 실제 도입을 고려한다면 자신이 사용하는 도구 호출 형식과 긴 작업 흐름에서 별도로 검증해야 합니다.

양자화의 기준이 변환 도구에서 학습 과정으로 이동하는 이유

지금까지 로컬 모델 사용자에게 양자화 품질은 주로 변환 도구의 문제로 인식됐습니다. 어떤 포맷을 선택할지, 몇 비트로 줄일지, 특정 레이어를 보존할지에 따라 결과가 달라졌기 때문입니다. 물론 이런 변환 기술은 여전히 중요합니다. 하지만 모델 자체가 낮은 비트 표현을 고려해 훈련됐다면, 사후 변환만으로는 얻기 어려운 안정성을 기대할 수 있습니다.

이번 사례는 대규모 모델에서 메모리 절감과 출력 보존을 함께 달성하려면 학습, 모델 구조, 포맷 변환, 실행 커널을 따로 볼 수 없다는 점을 보여줍니다. 특히 전체 가중치 중 대부분을 차지하는 전문가 파라미터에 FP4를 적용하면, MoE 모델의 큰 저장 부담을 줄이면서도 원본 표현을 유지하는 설계가 가능해집니다.

다만 실제 효용은 하드웨어와 소프트웨어가 함께 따라올 때 나타납니다. 모델 파일을 구할 수 있어도 GPU 메모리가 부족하거나 런타임이 FP4 경로를 충분히 최적화하지 못하면 기대한 속도가 나오지 않을 수 있습니다. 따라서 다운로드 전에는 Hugging Face의 unsloth/DeepSeek-V4-Flash-0731-GGUF 저장소에서 파일별 크기, 지원 런타임, 권장 메모리와 최신 변경 사항을 확인하는 것이 우선입니다. 이 모델의 선택 기준은 ‘4비트라서 작다’가 아니라, 원본 표현을 얼마나 보존하면서 자신의 실행 환경이 그 비용을 감당할 수 있는지에 있습니다.