DeepSeek의 DSpark: 모델을 바꾸지 않고 추론 속도를 끌어올리는 법

DeepSeek이 공개한 DSpark는 새 모델이 아니라 speculative decoding 기반 추론 가속 프레임워크입니다. 반자기회귀 후보 생성과 신뢰도 기반 검증 스케줄링으로 실제 서비스 환경에서 생성 속도를 개선하는 방식을 설명합니다.

이 글은 LLM 추론 서빙과 AI 인프라 구조를 이해하기 위한 QSike Tech Notes 기술 해설입니다. 특정 기업이나 제품의 성능을 보증하지 않으며, 공개 자료와 보도 기준 수치는 측정 조건에 따라 달라질 수 있습니다.

DeepSeek이 DeepSeek-V4 계열과 함께 DSpark라는 새로운 추론 가속 프레임워크를 공개했다. 핵심은 모델 자체를 새로 만든 것이 아니라, 기존 DeepSeek-V4-Pro에 speculative decoding, 즉 추측 디코딩 모듈을 붙여 실제 서비스 환경에서 생성 속도와 처리량을 끌어올린 것이다.

Hugging Face에 공개된 DeepSeek-V4-Pro-DSpark 설명에도 명확히 적혀 있다. DSpark는 새로운 모델 체크포인트가 아니라, DeepSeek-V4-Pro에 speculative decoding 모듈을 추가한 형태다. 즉 이번 업데이트의 본질은 모델 아키텍처의 세대교체라기보다, 대규모 언어모델을 실제 서비스에서 더 빠르고 효율적으로 돌리기 위한 서빙 엔지니어링의 진화에 가깝다.

왜 DSpark가 중요한가

Speculative decoding의 핵심은 작은 후보 생성 경로와 큰 검증 경로를 나누어, 품질을 유지하면서 한 번에 더 멀리 진행하는 것이다.

LLM의 응답 생성은 기본적으로 한 토큰씩 순차적으로 진행된다. 이전 토큰이 생성되어야 다음 토큰을 예측할 수 있기 때문에, 출력이 길어질수록 지연 시간은 거의 선형적으로 늘어난다. 사용자가 체감하는 “답변이 느리다”는 문제의 상당 부분이 여기서 발생한다.

이를 해결하기 위한 대표적인 방법이 speculative decoding이다.

구조는 다음과 같다.

1. 가벼운 후보 생성 모델이 여러 개의 후보 토큰을 빠르게 먼저 만든다.
2. 큰 기준 모델이 이 후보들을 한 번에 검증한다.
3. 기준 모델의 원래 출력 분포를 해치지 않는 범위에서 후보 토큰을 받아들인다.
4. 받아들여진 토큰 수만큼 한 번에 앞으로 나아간다.

이론적으로는 품질 손실 없이 속도를 높일 수 있다. 하지만 실제 프로덕션 환경에서는 두 가지 문제가 남는다.

첫째, 후보 생성 모델이 만든 후보의 품질이 낮으면 뒤쪽 토큰들이 많이 거절된다. 둘째, 사용자가 많은 고동시성 환경에서는 거절될 가능성이 높은 후보까지 검증하느라 GPU 자원을 낭비하게 된다.

DSpark는 이 두 문제를 동시에 겨냥한다.

DSpark의 핵심 아이디어 1: 반자기회귀 후보 생성

기존 speculative decoding 방식은 크게 두 계열로 나눌 수 있다.

하나는 Eagle3 같은 자기회귀식 후보 생성 모델이다. 이 방식은 후보 토큰을 한 개씩 순차적으로 만들기 때문에 토큰 간 의존성을 잘 반영한다. 그래서 후보의 수용률은 높을 수 있다. 하지만 후보를 길게 만들수록 후보 생성 모델 자체의 지연 시간이 늘어난다.

다른 하나는 DFlash 같은 병렬 후보 생성 모델이다. 이 방식은 한 번의 추론 통과로 여러 후보 토큰을 동시에 만든다. 후보 길이가 길어져도 생성 지연이 크게 늘지 않는다는 장점이 있다. 하지만 각 후보 위치가 블록 내부의 앞선 토큰에 충분히 의존하지 못하기 때문에, 뒤쪽 토큰으로 갈수록 수용률이 빠르게 떨어질 수 있다.

DSpark는 이 둘 사이의 절충점을 택한다.

DSpark의 병렬 backbone은 DFlash 계열의 병렬 후보 생성 모델 아이디어를 기반으로 개선된 구조로, 한 번에 여러 후보 위치의 hidden state와 기본 logits를 만든다. 그 뒤에 가벼운 순차 모듈을 붙여 토큰 간 prefix 의존성을 보정한다. 공개 자료에서 언급된 구현은 크게 두 가지다.

• 바로 이전 토큰에 의존하는 Markov head
• 순환 상태를 통해 더 긴 prefix 정보를 축적하는 RNN head

즉 DSpark는 병렬 생성의 속도 이점을 유지하면서도, 완전 병렬 후보 생성 모델이 겪는 후반부 수용률 저하를 완화하려는 구조다.

DSpark의 핵심 아이디어 2: 신뢰도 기반 검증 스케줄링

프로덕션 서빙에서는 단일 요청의 속도뿐 아니라 동시 요청, batch 효율, scheduler latency를 함께 봐야 한다.

DSpark의 더 실전적인 차별점은 confidence-scheduled verification이다.

기존 speculative decoding은 후보 생성 모델이 만든 후보 토큰을 정해진 길이만큼 기준 모델에 보내 검증하는 경우가 많았다. 문제는 모든 후보가 같은 가치가 있는 것이 아니라는 점이다. 어떤 토큰은 거의 받아들여질 가능성이 높고, 어떤 토큰은 거절될 가능성이 높다.

DSpark는 각 후보 위치에 대해 “이 토큰이 살아남을 확률”을 예측하는 confidence score를 만든다. 그리고 실제 엔진의 처리량 곡선과 현재 부하를 고려해, 요청마다 검증할 prefix 길이를 동적으로 결정한다.

쉽게 말하면 다음과 같다.

• GPU 여유가 있으면 더 긴 후보를 검증한다.
• 동시 요청이 많아지면 거절 가능성이 높은 뒤쪽 후보는 과감히 자른다.
• 기준 모델의 비싼 계산 자원을 “살아남을 확률이 높은 토큰”에 우선 배분한다.

이 부분이 단순 연구용 speculative decoding과 실제 프로덕션 서빙 사이의 차이를 만든다. LLM 서비스에서는 단일 요청의 최고 속도만 중요한 것이 아니다. 전체 동시 사용자 수, SLA, batch 처리 효율, CUDA graph replay, scheduler latency까지 함께 고려해야 한다.

DSpark는 이 지점을 정면으로 다룬다.

실제 성능: 속도만이 아니라 처리량까지 본다

보도와 공개 자료에 따르면 DSpark는 DeepSeek-V4-Flash와 DeepSeek-V4-Pro의 preview 서비스 엔진에 배포됐다.

DeepSeek 측 자료와 중국 테크 매체 보도 기준으로는, 기존 프로덕션 기준선인 단일 토큰 speculative decoding 방식 MTP-1과 비교했을 때 다음과 같은 개선이 언급된다. 다만 수치는 측정 조건과 SLA 설정에 따라 달라지는 엔지니어링 지표이므로, “항상 동일하게 재현되는 모델 성능 수치”라기보다 공개 자료·보도 기준의 프로덕션 측정치로 보는 편이 안전하다.

• 중국 IT 매체 아이티홈 보도 기준: 동일한 전체 처리량 수준에서 단일 사용자 생성 속도 약 57~85% 개선
• 중국 IT 매체 아이티홈 보도 기준: Flash 계열에서는 약 60~85% 속도 개선
• 중국 IT 매체 아이티홈 보도 기준: Pro 계열에서도 약 57~85% 속도 개선
• 36Kr Europe 보도 기준: Pro 계열 상한을 78%로 제시한 표현도 있어, 매체별 수치 차이는 측정 조건과 인용 범위를 함께 확인해야 한다.
• 특정 SLA 조건에서는 aggregate throughput도 크게 개선

특히 중요한 점은 이 수치가 단순 오프라인 벤치마크만이 아니라, 실제 온라인 트래픽 환경을 전제로 제시되었다는 점이다.

오프라인 평가에서도 DSpark는 Qwen3 4B/8B/14B 및 Gemma4-12B 기준 모델을 대상으로 Eagle3, DFlash 대비 평균 수용 길이에서 우위를 보였다고 설명된다. 예를 들어 Qwen3 계열에서는 Eagle3 대비 약 26.730.9%, DFlash 대비 약 16.318.4% 수준의 평균 수용 길이 개선이 언급된다.

DeepSpec: DSpark를 재현할 수 있는 오픈소스 기반

DeepSpec은 단순 실행 스크립트라기보다 speculative decoding 계열 후보 생성 모델을 학습·평가하기 위한 연구/플랫폼팀용 스택에 가깝다.

DeepSeek은 DSpark와 함께 DeepSpec도 공개했다.

DeepSpec은 speculative decoding용 후보 생성 모델을 학습하고 평가하기 위한 전체 스택 코드베이스다. GitHub README 기준으로 구성은 세 단계다.

1. 데이터 준비
   프롬프트 데이터를 준비하고 기준 모델의 응답을 재생성한 뒤, 기준 모델 캐시를 만든다.

2. 학습
   준비된 cache를 기반으로 후보 생성 모델을 학습한다.

3. 평가
   GSM8K, MATH500, AIME25, HumanEval, MBPP, LiveCodeBench, MT-Bench, Alpaca, Arena-Hard-v2 등에서 acceptance를 평가한다.

현재 DeepSpec에는 세 가지 후보 생성 모델 계열이 포함되어 있다.

• DSpark
• DFlash
• Eagle3

다만 실사용 진입 장벽은 낮지 않다. README에는 기본 Qwen/Qwen3-4B 설정에서도 기준 모델 캐시가 약 38TB까지 커질 수 있다고 적혀 있다. 기본 스크립트 역시 단일 노드 8 GPU 환경을 가정한다. 따라서 이 코드는 “개인 개발자가 바로 노트북에서 돌려보는 도구”라기보다, 자체 LLM 서빙 인프라를 운영하는 연구팀·플랫폼팀·AI 인프라 조직에 더 가까운 도구다.

DSpark가 시사하는 변화

DSpark의 의미는 “DeepSeek 모델이 더 좋아졌다”보다 조금 다르게 봐야 한다.

최근 LLM 경쟁은 모델 파라미터 수, 벤치마크 점수, 추론 성능에 집중되어 있었다. 하지만 실제 서비스에서는 모델 자체의 성능만큼이나 중요한 것이 있다.

• 토큰 생성 지연
• GPU당 처리 가능한 요청 수
• 고동시성 환경에서의 batch 효율
• 긴 context 처리 비용
• 서비스 SLA를 만족하는 비용 구조

DSpark는 이 중 추론 서빙 효율을 정면으로 다룬다.

특히 DeepSeek-V4가 100만 토큰 문맥를 지원한다고 강조하는 상황에서, 긴 문맥 모델의 경쟁력은 단순히 “긴 입력을 넣을 수 있다”가 아니다. 긴 입력과 긴 출력을 실제 사용자 트래픽에서 감당할 수 있어야 한다. 이때 speculative decoding, confidence scheduling, CUDA 그래프 친화적 스케줄러 같은 기술은 모델 품질 못지않게 중요해진다.

한계도 분명하다

DSpark가 모든 문제를 해결하는 것은 아니다.

보도에 따르면 DSpark는 후보 블록을 먼저 생성한 뒤, confidence scheduler가 일부 후속 토큰을 잘라내는 방식이다. 이 경우 뒤쪽 후보가 최종적으로 검증되지 않더라도, 후보 생성 경로이 이미 후보를 생성하는 데 쓴 계산량은 회수할 수 없다.

또한 복잡한 질의나 복잡한 추론 작업에서는 수용률 자체가 낮아질 수 있다. 이런 경우 speculative decoding의 이득은 줄어든다. 결국 DSpark의 효과는 요청 유형, 출력 길이, 기준 모델, batch size, SLA 조건, GPU 커널 최적화 수준에 따라 달라질 가능성이 높다.

즉 DSpark는 “항상 80% 빨라지는 마법”이 아니라, 프로덕션 환경에서 GPU 자원을 더 영리하게 쓰기 위한 시스템적 최적화로 이해하는 편이 정확하다.

결론: 다음 경쟁은 모델이 아니라 엔진이다

DSpark는 DeepSeek이 단순히 모델 가중치만 공개하는 회사가 아니라, 대규모 LLM을 실제 서비스로 운영하는 데 필요한 추론 엔진과 서빙 스택까지 적극적으로 최적화하고 있음을 보여준다.

앞으로 LLM 경쟁은 세 층에서 동시에 벌어질 가능성이 크다.

첫째, 더 강한 기반 모델과 reasoning model.
둘째, 더 긴 context와 더 효율적인 attention 구조.
셋째, 같은 GPU에서 더 많은 사용자를 더 빠르게 처리하는 추론 시스템.

DSpark와 DeepSpec은 이 세 번째 축, 즉 LLM 서빙 효율 경쟁을 상징하는 사례다.

AI 모델의 성능 경쟁이 “누가 더 똑똑한가”의 문제였다면, 이제는 “누가 더 싸고 빠르게 똑똑함을 제공할 수 있는가”의 싸움으로 이동하고 있다. DSpark는 그 변화가 이미 시작됐다는 신호에 가깝다.

다음에 읽을 글

DSpark처럼 서빙 엔진을 최적화하는 흐름을 이해했다면, 추론 전용 칩 경쟁도 함께 볼 필요가 있습니다. OpenAI의 Jalapeño에서 한국 NPU까지는 추론 비용이 커질수록 전용 가속기와 소프트웨어 스택이 왜 중요해지는지 설명합니다.

체크포인트

• 모델 성능 개선과 서빙 엔진 최적화를 구분했는가
• 단일 요청 속도뿐 아니라 동시 요청, 배치 효율, GPU 사용률을 함께 보고 있는가
• speculative decoding의 이득이 요청 유형과 수용률에 따라 달라진다는 점을 고려했는가
• 오픈소스 코드가 바로 실사용 가능한 도구인지, 연구·플랫폼팀용 기반인지 구분했는가

확인한 출처 / 근거

• DeepSeek-AI, DeepSpec GitHub repository — 공식 코드와 사용법.
• DeepSeek-AI, “DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation” — DSpark 방법론과 60~85% 생성 속도 향상 결과를 설명한 논문.
• Hugging Face, DeepSeek-V4-Pro-DSpark — 공개 모델 카드와 사용 조건.
• 36Kr Europe, “DeepSeek V4 Updates DSpark, Boosting Inference Speed by 80%” — 성능 수치에 관한 보도.
• IT之家, 「北大与 DeepSeek 联合开源 DSpark」 — 공동 오픈소스 발표와 성능 수치의 교차 확인.