DeepSeek V4 Flash 0731 분석: 284B 모델이 304B로 표시되는 이유
Hugging Face의 DeepSeek V4 Flash 0731 저장소에서 내려받아야 할 모델 파일은 총 167GB입니다. 저장소에 표시된 전체 파라미터는 약 304B입니다. 그런데 DeepSeek 기술 보고서에 적힌 모델 본체는 284B이고, 토큰마다 계산에 참여하는 파라미터는 13B입니다. B는 10억 개의 파라미터를 뜻합니다.
284B는 답을 만드는 본체 모델의 전체 파라미터 수입니다. DeepSeek V4 Flash 0731 체크포인트에는 본체 모델과 함께 토큰 생성을 가속하는 DSpark용 가중치가 들어 있어 전체 파라미터가 약 304B로 늘어납니다. 13B는 MoE 구조가 토큰 하나를 처리할 때 본체에서 활성화하는 파라미터 수입니다.
배포할 때는 약 304B의 전체 체크포인트를 여러 GPU에 나눠 올립니다. 토큰 하나를 처리할 때 본체 계산에 참여하는 파라미터는 약 13B입니다. 체크포인트에 포함된 DSpark용 가중치는 GPU 메모리를 더 사용하지만, 여러 후보 토큰을 미리 만들어 본체 모델의 반복 실행을 줄입니다.
| 공개 정보 | DeepSeek V4 Flash 0731 |
|---|---|
| 공개일 | 2026년 7월 31일 |
| 라이선스 | MIT |
| 모델 구조 | MoE, 본체 284B·토큰당 13B 활성화 |
| 최대 컨텍스트 | 1,048,576토큰 |
| 전체 체크포인트 | 약 304B, 다운로드 파일 167GB |
| 공식 실행 예시 | vLLM, SGLang |
코딩과 도구 사용에서 커진 점수 차이
DeepSeek는 7월 31일 공개본과 2026년 4월에 공개한 Flash Preview를 같은 표에서 비교했습니다. 점수가 크게 오른 항목은 코딩, 터미널 작업과 여러 도구를 이어서 쓰는 과제입니다.
| 벤치마크 | 무엇을 시험하나 | Flash Preview | 7월 31일 공개본 | 변화 |
|---|---|---|---|---|
| Terminal-Bench 2.1 | 명령줄 환경의 개발·시스템 운영 작업 | 61.8 | 82.7 | +20.9점 |
| DeepSWE | 낯선 오픈소스 저장소를 읽고 여러 파일을 수정하는 작업 | 7.3 | 54.4 | +47.1점 |
| Toolathlon-Verified | 여러 소프트웨어와 도구를 연결해 끝내는 다단계 작업 | 49.7 | 70.3 | +20.6점 |
| Agents' Last Exam | 결과를 검증할 수 있는 장시간 전문 업무 | 15.8 | 25.2 | +9.4점 |
벤치마크마다 평가 방식과 점수 범위가 다르므로 서로 다른 행의 절대 점수를 비교하면 안 됩니다. 위 표는 같은 벤치마크 안에서 Preview와 7월 31일 공개본의 차이만 비교합니다.
점수가 가장 크게 오른 DeepSWE는 짧은 코드를 한 번 생성하는 시험이 아닙니다. DeepSWE 연구진은 91개 오픈소스 저장소를 바탕으로 113개의 장시간 개발 과제를 새로 만들었습니다. 모델은 낯선 코드 구조를 파악하고 여러 파일을 고친 뒤 요구한 기능이 동작하도록 마무리해야 합니다. DeepSeek V4 Flash의 7월 31일 공개본은 이 평가에서 54.4점을 기록했습니다. Flash Preview의 7.3점보다 47.1점 높습니다.
Terminal-Bench와 Toolathlon도 20점 이상 상승했습니다. 세 평가 모두 한 번의 답변보다 여러 단계의 실행을 요구합니다. DeepSeek가 이번 공개본에서 집중적으로 높인 능력은 코딩과 도구 사용을 이어가는 에이전트 작업입니다.
다만 공식 점수를 같은 조건으로 재현하기는 어렵습니다. DeepSeek는 공개 Code Agent 과제를 자체 평가 환경인 DeepSeek Harness의 minimal mode에서 실행했습니다. 설정은 reasoning_effort=max, temperature=1.0, top_p=0.95였습니다. Harness가 아직 공개되지 않아 다른 모델을 같은 환경에서 평가할 수 없고, 별도의 에이전트 프레임워크에서 나온 점수와도 직접 비교하기 어렵습니다. 위 표에는 DeepSeek 내부 평가인 DSBench 두 종을 넣지 않았습니다.
공식 평가와 별도로 Artificial Analysis도 DeepSeek V4 Flash의 7월 31일 공개본을 시험했습니다. 여러 능력 평가를 합산한 Intelligence Index는 Preview의 40점에서 50점으로 올랐습니다. 전문 업무형 에이전트 과제에서 모델끼리 비교한 GDPval-AA v2의 Elo 점수도 1,189에서 1,559로 상승했습니다. DeepSeek와 Artificial Analysis 모두 이번 공개본을 Preview보다 높게 평가했습니다.
13B만 활성화돼도 전체 가중치는 필요합니다
LLM은 구조에 따라 크게 Dense 모델과 MoE 모델로 나뉩니다. Dense 모델에서는 모든 토큰이 같은 연산 블록을 거칩니다. MoE 모델은 각 레이어에 여러 expert를 두고, router가 토큰마다 일부 expert를 선택합니다. DeepSeek V4 Flash는 MoE 모델입니다.
DeepSeek V4 Flash의 각 MoE 레이어에는 routed expert 256개와 항상 참여하는 shared expert 1개가 있습니다. Router는 토큰마다 routed expert 6개를 선택합니다. 본체 전체는 284B지만 토큰 하나를 처리할 때는 약 13B의 파라미터가 계산에 참여합니다.
| 수치 | 무엇을 포함하나 | 배포에서 의미 |
|---|---|---|
| 284B | DeepSeek V4 Flash 본체의 모든 파라미터 | 본체 모델의 전체 규모 |
| 13B | 토큰 하나를 처리할 때 활성화되는 본체 파라미터 | 토큰당 계산량 |
| 약 304B | 본체와 DSpark용 가중치를 합친 파라미터 | 서버가 불러올 전체 체크포인트 규모 |
| 167GB | Hugging Face에서 내려받는 파일 | 다운로드와 스토리지 용량 |
토큰 하나에는 약 13B가 참여하지만 다음 토큰에는 다른 expert가 선택될 수 있습니다. 따라서 일반적인 GPU 서빙은 모든 expert의 가중치를 메모리에 올려둡니다. DeepSeek V4 Flash 0731 체크포인트는 13B급 Dense 모델보다 훨씬 많은 GPU 메모리가 필요합니다.
다만 파라미터 수만으로 파일 용량을 알 수는 없습니다. 저장 정밀도에 따라 파라미터 하나가 차지하는 바이트 수가 달라집니다. DeepSeek V4 Flash 0731 Instruct 체크포인트는 MoE expert를 4비트 부동소수점 형식인 FP4로 저장하고, attention과 Dense 레이어에는 FP8을 사용합니다. 이렇게 여러 정밀도를 섞어 저장한 체크포인트의 다운로드 파일 합계가 167GB입니다. 실행 중에는 가중치 외에도 연산 중간값과 캐시가 필요하므로 실제 서빙에 필요한 GPU 메모리는 167GB보다 큽니다.
한 번의 검증으로 여러 토큰을 채택하는 DSpark
LLM은 보통 본체 모델을 한 번 실행할 때 다음 토큰 하나를 만듭니다. 답이 100토큰이라면 본체 모델도 대략 100번 실행됩니다. 모델이 클수록 이 반복이 사용자가 토큰을 받는 속도에 큰 영향을 줍니다.
Speculative decoding은 가벼운 초안 모듈이 다음 토큰 후보를 여러 개 만들고, 본체 모델이 후보 묶음을 한꺼번에 검증하는 방법입니다. 본체가 앞의 세 후보를 채택하면 한 차례의 검증으로 세 토큰만큼 진행합니다. 중간 후보가 틀리면 그 뒤의 후보를 버리고 본체 모델이 틀린 자리의 토큰을 다시 만듭니다. 한 번에 채택하는 후보가 많아질수록 같은 길이의 답에 필요한 본체 모델 실행 횟수가 줄어듭니다.
다만 기존의 병렬 초안 모듈은 여러 위치의 후보를 빠르게 만드는 대신 각 위치를 독립적으로 예측합니다. 문맥상 of course와 no problem이 각각 자연스럽더라도 두 예측이 섞이면 of problem처럼 앞뒤가 맞지 않는 조합이 나올 수 있습니다. 뒤쪽 후보가 자주 거부되면 여러 토큰을 미리 만든 이점도 작아집니다.
DSpark는 후보 생성 과정을 두 단계로 나눕니다. Parallel Block은 계산량이 큰 부분을 한꺼번에 처리합니다. Sequential Block은 앞에서 고른 토큰을 다음 후보에 반영해 후보 사이의 연결을 보완합니다. Confidence head는 각 후보가 본체 검증을 통과할 확률을 추정합니다.
후보를 만든 뒤 Hardware-Aware Prefix Scheduler는 이 확률과 현재 시스템 부하를 함께 보고 본체에 넘길 길이를 정합니다. 동시 요청이 적을 때는 후보를 더 검증해도 부담이 작지만, 요청이 몰리면 가능성이 낮은 후보가 배치 용량을 차지합니다. DSpark는 조건에 따라 검증 길이를 바꾸면서 불필요한 연산을 줄입니다. 초안 모듈은 후보만 제시하고 본체 모델이 최종 토큰을 모두 검증합니다. 이 과정에서도 본체 모델의 출력 확률 분포는 유지됩니다.
DSpark의 60–85%는 어떤 조건에서 측정했나
DSpark 논문이 보고한 60–85%는 DeepSeek의 실제 서비스에서 측정한 토큰 생성 속도입니다. MTP-1은 DeepSeek가 이전부터 서비스에 사용하던 speculative decoding 방식입니다. DeepSeek는 MTP-1과 DSpark의 전체 처리량을 비슷하게 맞춘 뒤, 사용자 한 명이 토큰을 받는 속도를 비교했습니다. DSpark를 적용했을 때 이 속도가 60–85% 높아졌습니다.
60–85%는 토큰을 순서대로 만드는 decode 구간의 속도 차이입니다. LLM이 입력 프롬프트를 먼저 처리하는 prefill 시간까지 같은 비율로 줄었다는 뜻은 아닙니다. 프롬프트가 길어 prefill이 전체 응답시간의 대부분을 차지하면 사용자가 체감하는 개선 폭은 작아집니다.
이 연구는 DeepSeek V4 Flash 0731 체크포인트가 공개되기 전에 진행됐습니다. 특정 GPU에서 이번 체크포인트를 vLLM이나 SGLang으로 실행한 결과도 아닙니다. 따라서 실제 서버에서도 같은 폭으로 빨라진다고 해석할 수는 없습니다.
논문의 수치를 공개 엔진의 성능으로 그대로 옮길 수는 없지만, vLLM과 SGLang은 이미 DSpark를 지원합니다. vLLM 0.25.0은 DSpark 체크포인트 형식을 지원했고, vLLM 0.26.0은 DeepSeek V4용 routing kernel과 decode·prefill 최적화를 추가했습니다. SGLang 0.5.16은 GB300 4장에서 DeepSeek V4 Flash 0731과 DSpark를 함께 실행한 구성을 검증했습니다.
두 엔진의 공개 예시는 후보 토큰 수가 다릅니다. DeepSeek가 공개한 vLLM 실행 예시는 최대 7개로 설정하고, SGLang은 DeepSeek V4 Flash 0731 체크포인트의 기본값에 따라 최대 5개를 만듭니다. 후보를 많이 만들수록 한 번에 더 많은 토큰을 채택할 수 있지만, 검증할 연산과 GPU 메모리 사용량도 늘어납니다.
SGLang 문서는 기본값 5에서 시작해 1–5개를 비교하도록 안내합니다. 서비스를 구축하는 엔지니어는 실제 서비스의 프롬프트와 동시 요청을 재현하고 응답시간, 처리량과 GPU 메모리를 비교해 적절한 값을 찾을 수 있습니다.
공식 실행 예시는 모두 다중 GPU
DeepSeek V4 Flash 0731 체크포인트의 다운로드 파일은 총 167GB입니다. 실행할 때는 가중치 외에도 KV cache, CUDA graph와 연산용 임시 메모리가 필요합니다. DeepSeek와 SGLang이 공개한 실행 예시는 모두 여러 GPU에 가중치를 나눠 올립니다.
| 서빙 엔진 | 예시를 공개한 곳 | 공개된 GPU 구성 |
|---|---|---|
| vLLM | DeepSeek 공식 모델 카드 | GB300 4장 |
| SGLang | SGLang Cookbook | GB300 4장, H200 4장, B200 8장 |
vLLM 구성은 모델 개발사인 DeepSeek가 공개한 실행 예시입니다. SGLang 팀은 이번 304B 체크포인트를 GB300 4장, H200 4장과 B200 8장에서 직접 실행하고 Verified로 표시했습니다. 같은 문서에 RTX PRO 6000 두 장 구성도 나오지만, 이는 앞서 공개된 284B Flash 체크포인트용입니다. 이번 체크포인트를 RTX PRO 6000 두 장에서 검증한 사례는 아닙니다.
공개된 구성은 실제 하드웨어에서 실행을 확인한 예시이며 최소 사양을 뜻하지는 않습니다. 필요한 GPU 수는 메모리 용량뿐 아니라 목표 처리량과 동시 요청 수에 따라서도 달라집니다.
최대 컨텍스트 1M토큰은 한 요청에서 입력과 출력을 합쳐 처리할 수 있는 길이의 상한입니다. 문맥이 길어지면 모델이 처음 입력을 읽는 prefill 연산이 늘고, 이후 토큰을 만들 때 참고할 이전 토큰도 많아집니다. KV cache는 이전 토큰에서 계산한 attention의 key와 value를 저장해 같은 값을 다시 계산하지 않도록 합니다. 이 방식은 계산을 줄이는 대신 GPU 메모리를 사용합니다. 문맥이 길수록 저장할 KV cache가 커지고, decode 단계에서 GPU가 읽어야 할 데이터도 늘어납니다.
각 요청은 별도의 KV cache를 사용합니다. 긴 요청을 여러 건 동시에 처리하면 요청마다 cache가 쌓이므로 메모리 사용량이 빠르게 커집니다. 따라서 배포 규모를 잡을 때는 1M이라는 최대값보다 실제 입력·출력 길이와 동시 요청 수가 더 중요한 기준입니다.
13B의 계산량과 304B의 배포 규모
DeepSeek V4 Flash의 7월 31일 공개본은 284B 본체와 DSpark용 가중치를 합쳐 약 304B입니다. MoE 구조는 토큰마다 본체에서 약 13B를 활성화합니다. 배포에 필요한 GPU 메모리는 전체 체크포인트를 기준으로 계산하고, 토큰당 계산량은 활성 파라미터를 기준으로 가늠합니다.
DeepSeek V4 Flash의 7월 31일 공개본에서 가장 크게 향상된 영역은 코딩과 도구 사용을 오래 이어가는 에이전트 작업입니다. DSpark도 DeepSeek의 실제 서비스에서 토큰 생성 속도를 높였습니다. 다만 공개된 vLLM·SGLang 환경에서 어느 정도 빨라지는지는 아직 충분한 벤치마크가 없습니다. 현재 확인된 배포 구성은 모두 다중 GPU를 사용합니다.
DeepSeek V4 Flash의 7월 31일 공개본처럼 큰 오픈웨이트 모델을 사내에서 운영하려면 GPU 서버, 네트워크, 스토리지와 서빙 소프트웨어를 함께 구성해야 합니다. 매니코어소프트는 목표 업무와 사용자 수에 맞춰 이 인프라를 설계하고 구축합니다.