DeepSeek-V4 DSpark 해설: 추측 디코딩으로 처리량 최대 6배 높이기

핵심 메시지

• DeepSeek는 V4의 추론 구현을 담은 기술 보고서와 함께 추측 디코딩 연구 'DSpark', 코드베이스 'DeepSpec'을 공개했다.
• 추측 디코딩은 가볍고 빠른 초안 모델이 여러 토큰을 미리 제안하면, 큰 모델이 이를 한 번의 순전파로 병렬 검증해 속도를 높이는 기법이다.
• DSpark는 병렬로 블록을 만드는 방식과 순차적으로 만드는 방식의 장점을 합친 '반자기회귀' 초안 생성으로 정확도와 속도를 함께 잡는다.
• 각 토큰에 신뢰도 점수를 매기고 서버 부하까지 반영해 '지금 검증할 가치가 있는 토큰만' 검증하는 것이 핵심 차별점이다.
• 그 결과 프로덕션에서 처리량을 약 50% 이상, 엄격한 조건에서는 최대 수 배까지 끌어올려 같은 트래픽을 더 적은 GPU로 처리할 수 있다.

쉽게 이해하기

DeepSeek는 V4 모델의 추론 구현을 담은 기술 보고서에 이어, 추측 디코딩(speculative decoding) 알고리즘을 학습·평가하는 풀스택 코드베이스 'DeepSpec'과 그 핵심 논문 'DSpark'를 공개했다. 이들이 앞서 내놓은 저수준 라이브러리나 분산 파일시스템처럼 이 연구도 수십억 원대 GPU 클러스터를 굴리는 대규모 서빙 환경을 겨냥한 것이라, 개인이 바로 쓰긴 어렵다. 예컨대 논문의 기본 설정만 해도 초안 학습용 캐시가 수십 테라바이트에 8개 GPU 노드를 전제로 한다.

이 연구가 겨냥하는 근본 문제는 대규모 언어 모델의 '한 번에 한 토큰' 생성 방식이다. 모델은 지금까지의 문맥을 읽고 토큰 하나를 만든 뒤, 그 토큰을 다시 문맥에 더해 다음 토큰을 만드는 순차적 과정을 반복한다. 추론·에이전트형 작업처럼 생성해야 할 토큰이 많아질수록 이 병목은 더 커진다. 여기서 착안한 것이 추측 디코딩이다. 생성은 순차적이어야 하지만, 이미 주어진 토큰 열이 맞는지 '검증'하는 일은 순차적일 필요가 없다는 관찰에서 출발한다.

즉 빠른 초안 모델이 앞으로 나올 여덟 개 토큰을 미리 제안하면, 큰 모델은 이를 한 번의 순전파로 병렬 검증할 수 있다. 각 위치는 인과 마스크로 자기 앞 토큰만 보도록 처리되므로 순서 의존성은 유지된다. 초안이 정확하다면 큰 모델의 순전파 한 번과 초안 모델의 몇 번만으로 같은 출력을 재현할 수 있다. 다만 이 방식이 통하려면 초안 모델이 빠르고, 초안 토큰이 검증을 통과할 만큼 정확하며, 어차피 거부될 토큰 검증에 큰 모델의 연산을 낭비하지 않아야 한다.

기존 방식은 저마다 한계가 있었다. 별도의 작은 모델은 큰 모델 내부를 보지 못하고, 큰 모델의 은닉 표현을 이용하는 MTP·Eagle 계열은 여전히 초안을 순차적으로 만들어 토큰 수가 늘수록 비용이 커진다. 반대로 확산 모델에서 영감을 받은 병렬 블록 생성 방식은 한 번에 블록을 만들지만 뒤쪽 토큰이 앞쪽 결과를 모른 채 예측되어 일관성이 떨어진다. DSpark는 무거운 병렬 백본으로 초안 블록을 한 번에 만든 뒤, 그 위에 이전 토큰을 반영해 지역 일관성을 잡아 주는 가벼운 순차 모듈(예: Markov 헤드)을 얹는 '반자기회귀' 방식으로 두 접근의 장점을 결합한다.

DSpark의 또 다른 핵심은 '신뢰도 기반 검증 스케줄링'이다. 각 초안 토큰이 검증을 통과할 확률을 점수로 매겨, 신뢰도가 떨어지는 지점부터는 검증을 멈춰 연산을 아낀다. 나아가 하드웨어 인식 스케줄러가 현재 서버 부하를 반영해, 여유가 있으면 더 긴 접두열을 검증하고 부하가 크면 신뢰도 높은 부분만 검증하도록 조절한다. 그 결과 V4 계열에서 처리량이 약 50% 이상 높아지고, 사용자당 속도를 엄격히 요구하는 조건에서는 기존 기준선이 무너지는 반면 DSpark는 최대 수 배까지 처리량을 끌어올린다. 같은 트래픽을 더 적은 GPU로 처리할 수 있다는 뜻이며, DeepSeek는 이를 오픈소스로 공개했다.

주요 인사이트

• 추측 디코딩의 이득은 '생성은 순차적이지만 검증은 병렬 가능'이라는 비대칭에서 나온다. 검증이 병렬이라 해도 연산이 공짜는 아니라는 점이 스케줄링의 출발점이다.
• DSpark는 MTP를 대체하기보다 그 위에 쌓은 개선으로, 병렬 생성의 속도와 순차 생성의 일관성을 절충한 반자기회귀 설계가 핵심이다.
• 요청마다 예측 가능성이 다르므로(구조적인 코딩 요청 대 열린 대화), 모든 요청에 같은 초안 길이를 쓰는 것은 비효율적이다.
• 벤치마크는 실제 프로덕션 서빙을 제대로 반영하지 못하며, 부하를 고려한 동적 정책으로 볼 때 추측 디코딩의 가치가 달라진다.
• 처리량 50% 향상은 곧 같은 트래픽에 필요한 GPU 수를 줄인다는 의미로, 프런티어 모델 서빙의 속도·처리량 절충 지점을 통째로 이동시킨다.

자주 묻는 질문

관련 AI 소식