딥시크, LLM 추론 가속용 DSpark와 DeepSpec을 오픈소스로 공개

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

• 딥시크가 26일 추측적 디코딩(Speculative Decoding) 프레임워크 DSpark를 공개함

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

• DSpark의 목표는 모델 답변 품질을 바꾸지 않으면서 응답 지연을 줄이는 것임

  • 딥시크는 이미 DSpark를 딥시크 V4 Flash와 Pro 모델의 실제 온라인 서비스 환경에 적용했다고 밝힘
  • 대규모 언어 모델(LLM)의 병목인 토큰 생성 속도를 줄이는 게 핵심임

• 추측적 디코딩은 간단히 말하면 “작은 모델이 미리 써보고, 큰 모델이 한 번에 검사하는” 방식임

  • 경량 드래프트 모델(Draft Model)이 여러 후보 토큰을 먼저 생성함
  • 대상 모델(Target Model)은 후보 토큰을 순차로 하나씩 만드는 대신 한 번에 검증함
  • 검증을 통과한 토큰은 그대로 쓰고, 틀린 부분부터 다시 생성하는 식이라 출력 분포는 유지하면서 지연 시간을 줄일 수 있음

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

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

• 첫 번째 핵심은 반자기회귀(Semi-Autoregressive) 생성 구조임

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

• 두 번째 핵심은 하드웨어 인식 신뢰도 기반 예약 검증(Hardware aware Confidence Scheduled Verification)임

  • 기존 방식은 드래프트 모델이 만든 초안 토큰을 거의 다 검증 대상으로 넘겨 GPU 연산을 낭비할 수 있었음
  • DSpark는 각 토큰의 수용 가능성을 예측하는 Confidence Head를 추가함
  • 여기에 하드웨어 인식 프리픽스 스케줄러를 붙여 시스템 부하와 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 모델 기준 6085%, Pro 모델 기준 5778% 빨라졌다고 설명함

• DeepSpec은 추측적 디코딩 연구에 필요한 반복 작업을 한 번에 묶은 프레임워크임

  • 데이터 준비, 모델 학습, 성능 평가까지 전체 과정을 지원함
  • 데이터 생성 도구, 드래프트 모델 구현, 학습 코드, 평가 스크립트를 포함함
  • 지원 드래프트 모델은 DSpark, DFlash, Eagle3이고, 대상 모델은 Qwen3와 Gemma 시리즈임

• 다만 “오픈소스니까 바로 가볍게 돌려보자” 수준은 아님. 기본 구성부터 인프라 요구량이 큼

  • DeepSpec의 데이터 준비 단계에서는 프롬프트 데이터를 받고 대상 모델 응답을 재생성해 목표 캐시(Target Cache)를 구축해야 함
  • 기본 Qwen3-4B 구성 기준 목표 캐시 용량이 약 38TB에 달함
  • 학습은 기본적으로 단일 노드 8GPU 환경을 기준으로 설계됐고, GPU 수가 적으면 CUDA_VISIBLE_DEVICES로 조정할 수 있음

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

기술 맥락

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

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

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

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