---
title: "딥시크, LLM 추론 가속용 DSpark와 DeepSpec을 오픈소스로 공개"
published: 2026-06-29T00:05:02.843Z
canonical: https://jeff.news/article/4374
---
# 딥시크, LLM 추론 가속용 DSpark와 DeepSpec을 오픈소스로 공개

딥시크가 기존 딥시크 V4 Pro에 추측적 디코딩 프레임워크 DSpark를 적용해 추론 속도와 서비스 효율을 끌어올렸다. 함께 공개한 DeepSpec은 드래프트 모델 학습, 평가, 데이터 준비까지 묶은 풀스택 오픈소스 프레임워크다. Qwen3 실험에서는 Eagle3 대비 평균 수용 길이가 26.7~30.9%, DFlash 대비 16.3~18.4% 높았다고 밝혔다.

## 딥시크가 이번에 공개한 건 ‘새 모델’보다 ‘더 빨리 돌리는 법’에 가까움

- 딥시크가 26일 추측적 디코딩(Speculative Decoding) 프레임워크 `DSpark`를 공개함
  - 같이 공개한 `DeepSpec`은 DSpark 같은 드래프트 모델을 학습하고 평가하는 풀스택 오픈소스 프레임워크임
  - 이번 업데이트는 새로운 모델 아키텍처 발표가 아니라, 기존 `딥시크 V4 Pro`에 추론 가속 모듈을 붙여 서비스 효율을 높이는 쪽에 초점이 있음

- DSpark의 목표는 모델 답변 품질을 바꾸지 않으면서 응답 지연을 줄이는 것임
  - 딥시크는 이미 DSpark를 딥시크 V4 Flash와 Pro 모델의 실제 온라인 서비스 환경에 적용했다고 밝힘
  - 대규모 언어 모델(LLM)의 병목인 토큰 생성 속도를 줄이는 게 핵심임

- 추측적 디코딩은 간단히 말하면 “작은 모델이 미리 써보고, 큰 모델이 한 번에 검사하는” 방식임
  - 경량 드래프트 모델(Draft Model)이 여러 후보 토큰을 먼저 생성함
  - 대상 모델(Target Model)은 후보 토큰을 순차로 하나씩 만드는 대신 한 번에 검증함
  - 검증을 통과한 토큰은 그대로 쓰고, 틀린 부분부터 다시 생성하는 식이라 출력 분포는 유지하면서 지연 시간을 줄일 수 있음

```mermaid
sequenceDiagram
    participant 사용자
    participant 드래프트모델
    participant 스케줄러
    participant 대상모델
    participant 응답
    사용자->>드래프트모델: 프롬프트 입력
    드래프트모델->>스케줄러: 후보 토큰 묶음 생성
    스케줄러->>대상모델: 검증할 토큰 길이 조정
    대상모델->>스케줄러: 수용 가능한 토큰 반환
    스케줄러->>응답: 통과 토큰 반영
    응답->>사용자: 더 빠른 스트리밍 출력
```

## DSpark의 차별점은 수용률과 GPU 낭비를 같이 잡는 설계

- 첫 번째 핵심은 반자기회귀(Semi-Autoregressive) 생성 구조임
  - 기존 병렬 드래프트 모델은 생성 위치가 뒤로 갈수록 토큰 수용률(Acceptance Rate)이 떨어지는 문제가 있었음
  - DSpark는 블록 내부 토큰 간 의존성을 모델링하는 경량 직렬 모듈을 추가해 뒤쪽 토큰의 수용률 저하를 완화함
  - 병렬 생성의 처리량은 유지하면서, 검증에서 버려지는 토큰을 줄이려는 설계임

- 두 번째 핵심은 하드웨어 인식 신뢰도 기반 예약 검증(Hardware aware Confidence Scheduled Verification)임
  - 기존 방식은 드래프트 모델이 만든 초안 토큰을 거의 다 검증 대상으로 넘겨 GPU 연산을 낭비할 수 있었음
  - DSpark는 각 토큰의 수용 가능성을 예측하는 `Confidence Head`를 추가함
  - 여기에 하드웨어 인식 프리픽스 스케줄러를 붙여 시스템 부하와 GPU 처리량에 따라 검증 길이를 실시간 조절함

> [!IMPORTANT]
> DSpark의 포인트는 “후보를 더 많이 만들자”가 아니라 “검증될 가능성이 높은 후보에 GPU를 쓰자”에 가까움. 실제 서비스에서는 이 차이가 곧 비용과 지연 시간으로 튀어나옴.

- 실제 서비스 적용을 위해 비동기 스케줄링도 넣음
  - `Zero Overhead Scheduling(ZOS)`과 연속 `CUDA Graph Replay` 환경을 지원함
  - 이전 두 단계의 예측 결과를 활용해 현재 검증 길이를 정하고, 스케줄링 지연을 숨기는 구조임
  - 목표는 GPU 파이프라인의 유휴 시간을 줄이면서도 대상 모델의 출력 분포를 유지하는 것임

## 벤치마크와 오픈소스 프레임워크도 꽤 구체적임

- 딥시크는 DSpark가 수학 추론, 코드 생성, 일반 대화 벤치마크에서 기존 최신 추측적 디코딩 방식인 `Eagle3`와 `DFlash`를 모두 넘었다고 밝힘
  - Qwen3 4B, 8B, 14B 모델 실험에서 Eagle3 대비 평균 수용 길이가 26.7~30.9% 향상됨
  - DFlash 대비로는 16.3~18.4% 향상됐다고 함
  - 이전 세대 단일 토큰 생성 방식인 MTP-1과 비교하면 전체 처리량은 유지하면서 사용자 체감 생성 속도는 Flash 모델 기준 60~85%, Pro 모델 기준 57~78% 빨라졌다고 설명함

- DeepSpec은 추측적 디코딩 연구에 필요한 반복 작업을 한 번에 묶은 프레임워크임
  - 데이터 준비, 모델 학습, 성능 평가까지 전체 과정을 지원함
  - 데이터 생성 도구, 드래프트 모델 구현, 학습 코드, 평가 스크립트를 포함함
  - 지원 드래프트 모델은 DSpark, DFlash, Eagle3이고, 대상 모델은 Qwen3와 Gemma 시리즈임

- 다만 “오픈소스니까 바로 가볍게 돌려보자” 수준은 아님. 기본 구성부터 인프라 요구량이 큼
  - DeepSpec의 데이터 준비 단계에서는 프롬프트 데이터를 받고 대상 모델 응답을 재생성해 목표 캐시(Target Cache)를 구축해야 함
  - 기본 Qwen3-4B 구성 기준 목표 캐시 용량이 약 38TB에 달함
  - 학습은 기본적으로 단일 노드 8GPU 환경을 기준으로 설계됐고, GPU 수가 적으면 `CUDA_VISIBLE_DEVICES`로 조정할 수 있음

> [!TIP]
> 자체 LLM 서빙을 하는 팀이라면 모델 교체보다 먼저 추론 경로 최적화 여지를 봐야 함. 같은 모델이어도 디코딩 전략과 스케줄러만으로 체감 속도와 GPU 비용이 크게 달라질 수 있음.

- 평가 데이터셋 범위도 넓게 잡혀 있음
  - 수학 추론은 GSM8K, MATH500, AIME25를 지원함
  - 코드 생성은 HumanEval, MBPP, LiveCodeBench를 포함함
  - 대화와 종합 질의응답은 MT-Bench, Alpaca, Arena-Hard-v2 등을 사용함

---

## 기술 맥락

- DSpark가 고른 선택은 모델 자체를 더 크게 만들거나 새로 학습하는 게 아니라, 디코딩 경로를 바꿔 추론을 빠르게 만드는 방식이에요. 이미 서비스 중인 모델의 품질을 유지하면서 지연 시간과 GPU 비용을 줄여야 하니까, 아키텍처 교체보다 운영 리스크가 낮거든요.

- 추측적 디코딩의 병목은 드래프트 모델이 만든 토큰이 얼마나 많이 통과하느냐예요. 후보를 잔뜩 만들어도 대상 모델이 거부하면 검증 비용만 날아가니, DSpark는 반자기회귀 구조로 뒤쪽 토큰의 수용률을 높이려는 쪽을 택한 거예요.

- 하드웨어 인식 스케줄링이 들어간 이유도 현실적인 서비스 제약 때문이에요. 논문식 알고리즘이 좋아도 GPU가 놀거나 검증 길이가 부하와 안 맞으면 실제 지연 시간은 안 줄어들거든요. 그래서 Confidence Head와 스케줄러로 “지금 이 GPU 상황에서 어디까지 검증할지”를 계속 조정하는 구조가 나온 거예요.

- DeepSpec이 의미 있는 건 연구용 코드 조각이 아니라 데이터 준비, 학습, 평가까지 묶었다는 점이에요. 다만 목표 캐시만 38TB가 필요하다는 숫자에서 보이듯, 개인 실험보다는 모델 서빙 인프라를 가진 팀이나 연구 조직이 재현하고 확장하기 좋은 성격에 가까워요.

## 핵심 포인트

- DSpark는 모델 품질을 바꾸는 새 아키텍처가 아니라, 출력 지연을 줄이기 위한 추론 가속 엔지니어링 업데이트다.
- 반자기회귀 생성 구조와 하드웨어 인식 신뢰도 기반 검증으로 GPU 연산을 더 수용 가능성이 높은 토큰에 집중시킨다.
- DeepSpec은 추측적 디코딩용 드래프트 모델을 학습하고 평가하는 오픈소스 도구이며, 기본 Qwen3-4B 구성만 해도 목표 캐시가 약 38TB 필요하다.

## 인사이트

LLM 비용 경쟁은 모델 크기만의 싸움이 아니라 추론 경로를 얼마나 잘 깎느냐의 싸움으로 넘어가고 있다. 특히 실제 서비스에 들어간 최적화 코드를 오픈소스로 풀었다는 점에서, 자체 모델 서빙을 고민하는 팀에 꽤 실용적인 참고자료가 될 수 있다.