DSpark 논문에서 읽을 만한 지점은 speculative decoding을 “더 많이 draft하면 빨라진다”로 단순화하지 않는다는 점이다. DeepSeek-AI와 Peking University 연구진은 parallel drafter가 긴 token block을 한 번에 만들 수 있어도, 확률이 낮은 뒤쪽 token까지 무작정 target model에 검증시키면 batch 용량을 낭비한다고 본다. 그래서 DSpark는 draft 품질과 검증 길이를 동시에 다룬다.

구조는 두 부분으로 나뉜다. 먼저 semi-autoregressive architecture가 parallel backbone 위에 가벼운 sequential module을 붙여 block 내부 token 의존성을 보강한다. 완전 parallel 방식의 장점은 유지하되, 뒤쪽 token acceptance가 급격히 떨어지는 suffix decay를 줄이려는 설계다. 다음으로 confidence-scheduled verification이 각 위치의 prefix survival probability와 serving engine의 throughput profile을 보고, 요청마다 검증할 길이를 다르게 정한다.

논문이 제시한 숫자는 꽤 구체적이다. Qwen3-4B, 8B, 14B 대상 offline benchmark에서 DSpark는 autoregressive Eagle3보다 macro-average accepted length를 약 26.7~30.9%, parallel DFlash보다 16.3~18.4% 높였다고 한다. 더 중요한 대목은 live user traffic이 들어가는 DeepSeek-V4 serving system 배포 결과다. 기존 MTP-1 production baseline과 비교해 V4-Flash에서는 per-user generation speed가 60~85%, V4-Pro에서는 57~78% 빨라졌다고 설명한다.

커뮤니티 논점도 이 숫자에만 머물지 않았다. HN 댓글은 DeepSeek가 실제 production serving에서 쓰는 최적화와 checkpoint를 공개한다는 점, 그리고 2022년식 speculative decoding 이후 무엇이 달라졌는지를 따졌다. 핵심은 “speculative decoding 자체”가 아니라 high-concurrency serving에서 rejection risk가 큰 suffix token을 어떻게 덜 검증하느냐에 가깝다.

DeepSeek는 DSpark checkpoints와 DeepSpec training repository를 공개한다고 밝혔다. LLM serving 비용과 latency가 제품 경험을 좌우하는 상황에서, 이 논문은 모델 크기 경쟁 바깥의 중요한 축을 보여준다. 같은 model이라도 draft, accept, verify의 스케줄을 바꾸면 사용자가 느끼는 속도와 서버 처리량의 경계가 달라질 수 있다.

#serving

DeepSeek DSpark, LLM 추론 병목을 “검증 길이”에서 다시 잡은 이유