초안을 병렬로 생성해도 선후 관계를 깨뜨리지 않는 DSpark를 DeepSeek가 공개

대규모 언어 모델(LLM)의 추론이 '기다려지는' 상황이 발생할 때, 병목 현상은 지능의 문제가 아니라 출력 방식에 있다. 토큰을 1개 생성할 때마다 모델 전체를 1회 실행한다. 답변이 길어질수록 이 왕복 과정이 쌓이며, 게다가 1회당 GPU는 거의 놀고 있는 상태가 된다. DeepSeek가 6월 27일 GitHub에 공개한 DeepSpec과 그 핵심 알고리즘인 DSpark는 바로 이 지점을 겨냥했다. 모델의 가중치(weight)나 지능을 전혀 바꾸지 않고, 동일한 출력을 더 빠르게 내뱉게 만드는 이야기다.

자기회귀 생성 (autoregressive, 이전 토큰을 보고 다음 1개를 결정하는 메커니즘)에서는 1회의 순전파 (forward pass)로 진행되는 것은 1토큰뿐이다. 문제는 이 처리가 GPU의 연산력이 아니라 메모리 대역폭 (memory bandwidth)에서 막힌다는 점에 있다. 소수의 사용자에게만 배포되는 서버일수록 연산 유닛은 비어 있지만, 그럼에도 대기 시간은 길다. DeepSeek는 사내 연구를 통해 이 순차적 출력을 "AI 제공의 첫 번째 병목 (first bottleneck)"이라고 표현했다 (South China Morning Post).

해결책으로 알려진 것이 **투기적 디코딩 (speculative decoding)**이다. 저렴한 "초안 모델 (draft model)"이 다음 k개의 토큰을 한꺼번에 추측하게 하고, 본체 (target) 모델이 그 k개를 1회의 병렬 순전파로 한꺼번에 검증한다. 맨 앞부터 본체의 정답과 일치하는 부분만큼 채택하고, 어긋나는 지점에서 중단한다. 채택된 토큰은 본체가 스스로 생성했을 경우와 수학적으로 동일하기 때문에 품질은 떨어지지 않는다. 1회의 고비용 순전파로 여러 토큰을 진행하는 만큼 빨라진다는 논리다. 속도의 지표는 "채택 길이" (accepted length, 검증 1회당 평균 몇 토큰이 통과하는가)이며, 이것이 늘어날수록 빨라진다.

초안 모델에는 이미 유력한 방식이 여러 가지 있으며, DeepSpec은 그것들을 동일한 선상에 올려놓았다. 리포지토리에는 DSpark와 더불어, 현재의 대표 격인 Eagle3와 DeepSeek 자신의 선행 수법인 DFlash가 구현되어 있다. 두 방식의 약점은 대조적이다.

초안 생성 방식	특징	약점
Eagle3	토큰을 순차적으로 초안 생성	정확도는 높지만 초안 생성 자체가 느림
...

DSpark의 핵심은 블록을 병렬로 한꺼번에 내보내면서, 그 위에 Markov 헤드 (Markov head) (기본값 랭크 256) 또는 **RNN 헤드 (RNN head)**라는 경량 헤드를 1장 얹어, 인접한 토큰끼리의 전이 확률만을 명시적으로 갖게 한다는 점에 있다. 일괄 생성의 속도는 유지하면서, "뒤의 토큰이 앞을 무시하고 앞뒤가 맞지 않게 되는" 파탄을 억제한다는 발상이다. Markov 헤드는 짧은 시퀀스 및 높은 처리량 (throughput)에 적합하고, RNN 헤드는 긴 시퀀스에서 다소 유리하며, 용도에 따라 구분하여 사용한다. 나아가 각 후보 토큰에 "본체에 채택될 확률"을 예측하는 **confidence 헤드 (confidence head)**가 붙는다.

이 설계의 차이는 수치로 나타난다. DeepSeek의 측정에 따르면, 채택 길이가 Eagle3 대비 26.730.9%, DFlash 대비 16.318.4% 증가했다 (MarkTechPost). 비교 기준이 되는 "MTP-1"은 DeepSeek-V3에서 도입된 Multi-Token Prediction 헤드를 초안 1단계로 사용하는 구성을 가리킨다.

개인적으로 흥미롭다고 생각한 점은, 오프라인 채택 길이에서 이기더라도 실제 서비스의 처리량 (throughput)으로 직결되지는 않는다는 현실을 DSpark가 정면으로 다루고 있다는 점이다. 검증은 본체 모델을 구동하기 때문에, 무턱대고 길게 초안을 검증하면 실제 서비스에서는 오히려 병목이 발생한다.

이에 따라 DSpark는 GPU 클러스터의 동시 부하, 후보 토큰의 confidence 분포, 추론 엔진의 처리량 곡선을 보고 요청마다 검증할 토큰 길이를 동적으로 결정하는 부하 대응 스케줄러를 갖추고 있다. GPU가 비어 있으면 많이 검증하고, 혼잡하면 자제한다. DeepSeek는 이를 "계산 수요에 따라 검증량을 동적으로 조정하는" 메커니즘이라고 설명한다. 실제 V4에서의 주장치에 따르면, 사용자 1인당 생성 속도가 MTP-1 기준 V4-Flash는 6085%, V4-Pro는 5778% 빨라지며, 혼잡 시 집약 처리량 (aggregate throughput)은 최대 약 400% 증가한다. 목표는 속도뿐만 아니라 "더 크고 강력한 칩에 대한 의존도를 줄이는" 비용 측면에도 있다고 동사는 밝히고 있다.

이 부분은 냉정하게 구분할 필요가 있다. MIT 라이선스로 공개된 DeepSpec은 데이터 준비, 다중 GPU를 이용한 초안 학습(draft training), 평가까지 아우르는 실제 코드베이스이며, 실제로 재현 가능한 구성은 Qwen3(4B/8B/14B)와 Gemma-4 12B를 본체로 사용하는 방식이다. 평가는 gsm8k, math500, aime25, humaneval, mbpp, livecodebench, mt-bench, alpaca, arena-hard-v2 등 9가지 항목으로 진행된다. 반면, 헤드라인을 장식하는 V4의 60~85%라는 프로덕션(production) 수치는 DeepSeek의 논문 및 운용에 기반한 주장이며, 공개된 리포지토리(repository)에서 즉시 재현할 수 있는 부분은 아니다. 체크포인트 DeepSeek-V4-Pro-DSpark 등은 기존 V4의 가중치(weight)에 초안 모듈을 추가한 것으로 알려져 있다. 본 기사 작성 시점 기준으로, 이 수치들에 대한 제3자의 독립적인 검증은 확인되지 않았다.

자체적으로 Qwen이나 Gemma를 호스팅하고 있는 입장에서는, 본체를 재학습시키지 않고 초안(draft)만 추가할 수 있다는 점이 매우 고무적이다. 절차 자체는 단순하며, README에 기재된 명령어는 다음과 같은 수준이다.

git clone https://github.com/deepseek-ai/DeepSpec
cd DeepSpec
python -m pip install -r requirements.txt
...

새로운 모델이나 거대 문맥(context)에 관한 것이 아니라, 다소 소박한 "서빙(serving)의 최적화"다. 그럼에도 불구하고 지능 경쟁이 일단락되고 각 기업이 추론 비용과 GPU 부족 문제로 골머리를 앓고 있는 지금, 가중치를 건드리지 않고 동일한 품질을 유지하면서 속도를 높일 수 있는 방법이, 그것도 타사의 오픈 모델(open model)에도 적용 가능한 형태로 MIT 라이선스로 공개되었다는 점은 의미가 결코 작지 않다. 재현 가능한 대상이 Qwen/Gemma 측인 만큼, 우선 수중에 있는 오픈 모델에서 채택 길이(acceptance length)가 얼마나 늘어나는지를 측정하는 것이 이번 공개를 가장 건전하게 활용하는 방법일 것이다.