딥시크 DSpark 완전분석: LLM 추론 속도 85% 끌어올린 비결

며칠 전부터 딥시크가 또 일을 냈다는 얘기가 여기저기서 들려왔어요. 이번엔 새 모델이 아니라 추론 속도를 끌어올리는 프레임워크였는데, 막상 뜯어보니 단순한 속도 개선 그 이상이더라고요. GPU를 더 사지 않고도 답변 생성 속도를 85%까지 끌어올렸다는 건, 추론 비용에 허덕이던 입장에서는 그냥 지나칠 수 없는 소식이죠.

핵심 요약

DSpark는 딥시크가 지난 주말 오픈소스로 공개한 추측형 디코딩(speculative decoding) 프레임워크로, 모델 자체를 새로 학습하지 않고도 기존 DeepSeek-V4 가중치 위에 작은 드래프트 모듈을 얹어서 생성 속도를 끌어올리는 방식으로 동작합니다.

실제 운영 트래픽에서 V4-Flash는 기존 MTP-1 방식 대비 60~85%, V4-Pro는 57~78% 빠른 사용자당 생성 속도를 기록했고, 출력 품질은 손실 없이 그대로 유지된다는 점이 핵심이에요.

작동 원리는 가벼운 병렬 드래프트 백본이 토큰 블록 전체의 초안을 한 번에 만들고, 그 위에 마르코프 헤드라는 경량 순차 헤드가 붙어서 직전 토큰만 보고 보정을 가하는 이중 구조입니다. 여기에 신뢰도 점수를 기반으로 GPU 부하에 따라 검증할 토큰 수를 동적으로 조절하는 스케줄러까지 더해져, 한가할 때는 더 많이 검증하고 바쁠 때는 검증량을 줄이는 식으로 처리량을 보호해요.

 

벤치마크에서는 기존 최고 성능으로 꼽히던 Eagle3 대비 26~31%, DFlash 대비 16~18% 더 긴 수용 길이를 기록했고, 채팅처럼 답변이 정형화되지 않은 영역에서도 신뢰도 임계값 조정만으로 토큰 수용률을 45.7%에서 95.7%까지 끌어올렸습니다. 무엇보다 학습 코드와 체크포인트, 평가 도구 일체가 MIT 라이선스로 깃허브와 허깅페이스에 전부 공개되어 있어서, 직접 자기 모델에 드래프트 모듈을 붙여 학습시키는 것도 이론적으로 가능해요.

추측형 디코딩이 무엇인가

LLM이 답변을 만드는 기본 방식은 토큰을 하나씩 순서대로 생성하는 거예요. 강 건너는 사람이 디딤돌을 한 칸씩 밟아 나가듯, 한 단어를 정하고 나서야 다음 단어로 넘어갈 수 있죠. 이 구조 때문에 모델이 아무리 빨라도 한 번에 한 걸음 이상 나아가지 못하는 게 근본적인 병목이었습니다.

추측형 디코딩은 이 병목을 우회하는 아이디어예요. 작고 가벼운 드래프트 모델이 먼저 여러 토큰을 한꺼번에 예상해서 던져두면, 원래의 무거운 타깃 모델은 그 후보들을 한 번의 순전파로 일괄 검증만 합니다. 검증 결과 맞는 부분까지만 채택하고 틀린 부분부터는 다시 생성하는 식이라, 최종 출력은 타깃 모델이 혼자 만든 것과 수학적으로 완전히 동일해요. 속도만 빨라질 뿐 품질 저하가 없다는 보장이 여기서 나오는 거죠.

# DeepSpec 설치 및 DSpark 드래프트 모델 학습 예시
python -m pip install -r requirements.txt

# Qwen3-4B를 타깃 모델로 DSpark 드래프트 학습
bash scripts/train/train.sh

# 학습된 드래프트 체크포인트를 9개 벤치마크 데이터셋으로 평가
bash scripts/eval/eval.sh

위 명령어는 딥시크가 공개한 DeepSpec 저장소의 기본 학습 흐름이에요. config 파일에서 알고리즘과 타깃 모델을 지정하면 데이터 준비, 학습, 평가 세 단계가 순서대로 돌아갑니다. 다만 기본 설정이 8 GPU 노드 한 대를 가정하고 있고 Qwen3-4B 기준으로도 타깃 캐시 용량이 38TB에 달할 수 있다는 점은 미리 알아두셔야 해요. 실제 프로덕션용 체크포인트는 이미 V4 가중치에 드래프트 모듈이 붙은 채로 배포되기 때문에, 재학습 없이 바로 추론에 쓸 수 있습니다.

기존 방식과 뭐가 다른가: 병렬과 순차를 섞은 절충안

기존 추측형 디코딩 드래프터들은 한쪽을 포기해야 하는 구조였어요. Eagle3처럼 순차적으로 토큰을 예측하는 방식은 채택률이 높고 안정적이지만, 블록 크기가 커질수록 드래프트 생성 자체에 시간이 더 듭니다. 반대로 DFlash처럼 블록 전체를 한 번에 병렬로 뽑아내는 방식은 생성은 빠른데, 각 위치가 이웃 토큰을 전혀 고려하지 못해서 블록 뒤쪽으로 갈수록 정확도가 급격히 떨어지는 문제가 있었죠.

 

DSpark는 이 둘을 합쳤습니다. 무거운 병렬 백본(딥시크는 DFlash를 사용)이 모든 위치의 기본 로짓을 한 번에 만들어내고, 그 위에 가벼운 순차 헤드가 직전 토큰을 참고해서 보정값을 더하는 구조예요. 기본으로 채택된 마르코프 헤드는 바로 앞 토큰 하나만 보고, 랭크 256짜리 저랭크 인수분해로 연산량을 최소화했습니다.

예를 들어 첫 번째 위치에서 "of"가 채택되면, 마르코프 헤드는 다음 위치에서 "course"의 확률을 높이고 "problem" 같은 어색한 후보는 억누르는 식이에요. 풀 블록 전체를 참고하는 RNN 헤드 옵션도 있긴 한데, 성능 향상 폭이 미미해서 기본값은 가벼운 마르코프 헤드로 정해졌습니다.

 

여기에 검증 단계도 손을 봤어요. 무조건 많은 토큰을 검증한다고 빨라지는 게 아니라서, GPU가 바쁠 때 어차피 거부될 토큰까지 검증하면 오히려 배치 용량만 낭비됩니다. 그래서 DSpark는 각 드래프트 위치마다 채택 가능성을 점수로 매기는 신뢰도 헤드를 두고, 순차 온도 보정이라는 후처리 단계로 이 점수의 오차를 3~8%에서 약 1% 수준까지 줄였어요. 이 점수를 바탕으로 하드웨어 인지 스케줄러가 요청별 검증 길이를 그때그때 조절합니다. GPU가 한가하면 검증 범위를 넓혀 더 많은 토큰을 한 번에 처리하고, 부하가 몰리면 검증량을 줄여서 처리량을 지켜요.

실제로 얼마나 빨라졌나

오프라인 벤치마크는 수학, 코드, 일상 대화 세 영역에서 Qwen3 4B/8B/14B와 Gemma4-12B를 타깃으로 진행됐어요. 평가는 GSM8K, MATH500, AIME25, HumanEval, MBPP, LiveCodeBench, MT-Bench, Alpaca, Arena-Hard-v2까지 총 9개 벤치마크 데이터셋을 동원해서 수학 추론, 코드 생성, 대화 능력, 종합 질의응답까지 골고루 측정했습니다. Eagle3 대비 평균 수용 길이가 세 가지 Qwen3 모델 크기에서 각각 30.9%, 26.7%, 30.0% 늘었고, DFlash 대비로는 16.3%, 18.4%, 18.3% 늘었어요.

흥미로운 건 2단 구조의 DSpark가 5단으로 쌓은 DFlash보다도 더 나은 결과를 냈다는 점인데, 단순히 레이어를 더 쌓는다고 능사가 아니라는 걸 보여주는 대목이죠. 드래프트 길이를 4토큰에서 16토큰으로 늘려도 라운드당 지연 시간은 0.2~1.3%밖에 늘지 않았는데, 그 대가로 수용 길이는 최대 30%까지 좋아졌으니 비용 대비 효율이 꽤 좋은 셈입니다.

 

실제 운영 환경에서는 DeepSeek-V4-Flash와 V4-Pro에 적용해서 라이브 트래픽으로 검증했어요. 같은 처리량 기준으로 사용자당 생성 속도가 Flash는 60~85%, Pro는 57~78% 빨라졌고, 현재 배포된 설정은 5토큰짜리 블록에 마르코프 헤드를 결합한 DSpark-5입니다. 영역별로 보면 코드 생성처럼 패턴이 비교적 정형화된 작업에서는 원래 채택률 자체가 높아서 스케줄러가 긴 구간을 큰 낭비 없이 검증할 수 있고, 그만큼 코딩 에이전트의 출력 스트리밍 속도도 빨라져요.

반대로 답변 형태가 자유로운 일상 대화에서는 신뢰도 임계값을 조정하는 것만으로 토큰 채택률이 45.7%에서 95.7%까지 뛰었는데, 불확실한 후반부 토큰을 신뢰도 헤드가 미리 걸러내는 덕분입니다. 수학 추론은 두 영역의 중간쯤으로, 같은 조정 과정에서 채택률이 76.9%에서 92.5%까지 올라갔고 단계별로 길게 이어지는 풀이 과정에서 깊은 블록까지 안정적인 채택률을 유지하는 게 장점으로 작용했어요.

외부 검증: 개발자가 직접 돌려본 결과는 어떨까

회사 발표 수치만 있는 게 아니라 외부에서 직접 재현해본 사례도 이미 나왔어요. 개발자 Rafael Caricio는 단일 스트림 환경에서 DeepSeek-V4-Flash를 기준으로 벤치마크를 돌려, 추측형 디코딩을 아예 쓰지 않았을 때 26.33 토큰/초, 기존 MTP-1 적용 시 39.88 토큰/초, DSpark를 적용했을 때 약 60 토큰/초를 기록했다고 깃허브 풀 리퀘스트로 공개했습니다. 이는 MTP-1 대비 약 1.5배, 추측 디코딩을 아예 쓰지 않은 기준선 대비로는 약 2.3배 빠른 수치예요. 회사 발표치인 60~85% 향상과 방향성이 일치하는 결과라 신뢰도를 더해줍니다.

업계 반응도 빠르게 따라붙었어요. PyTorch 코어 메인테이너인 Dmytro Dzhulgakov는 DSpark의 세미-병렬 드래프팅 방식과 프로덕션급 엔지니어링 완성도를 상세히 분석한 글을 올리며 호평했습니다. 인프라 쪽 핵심 인물이 직접 코드 수준까지 들여다보고 평가했다는 건, 이 프레임워크가 단순 마케팅용 숫자가 아니라 실제로 동작하는 엔지니어링이라는 신호로 봐도 무방해요.

우리 모델에 그대로 가져다 쓸 수 있을까

여기서 한 가지 주의할 점이 있어요. DSpark 드래프트 모듈은 학습 과정에서 특정 타깃 모델에 맞춰 정렬되기 때문에, DeepSeek-V4용으로 학습된 드래프터를 다른 모델이나 사내 데이터로 파인튜닝한 모델에 그대로 가져다 붙일 수는 없습니다.

드래프트 모델은 타깃 모델이 어떤 답을 받아들일지를 학습으로 익히는 구조라서, 모델이 바뀌면 처음부터 다시 정렬 과정을 거쳐야 해요. 특히 타깃 모델이 사고(thinking) 모드나 추론 모드로 동작하도록 설정된 경우라면, 도메인에 맞춘 추가 파인튜닝이 사실상 필수라고 딥시크 측도 명시하고 있습니다.

즉 DeepSpec이 제공하는 건 완성된 제품이라기보다는 데이터 준비, 타깃 모델 답변 재생성, 타깃 캐시 구축, 드래프트 학습, 채택률 평가로 이어지는 전체 파이프라인이고, 자체 인프라에 적용하려면 이 과정을 직접 한 번은 거쳐야 해요.

지정학적 맥락도 중요!

이번 공개는 단순한 기술 뉴스로만 읽히지 않는 구석도 있어요. 미국의 AI 반도체 수출 규제 속에서 중국이 추론 병목과 칩 부담을 완화하려는 흐름 안에서 나온 기술이라는 시각으로 외신은 이번 발표를 다루고 있습니다. 하드웨어를 더 확보하기 어려운 상황에서 소프트웨어만으로 추론 속도를 끌어올렸다는 점이, 단순한 오픈소스 기여 이상의 의미로 받아들여지고 있는 셈이에요.

결론

DSpark는 새 모델이 아니라 서빙 최적화 기술이라는 점을 먼저 분명히 해둘 필요가 있어요. 1.6조 파라미터짜리 V4-Pro 같은 거대 모델을 운영하다 보면 GPU 메모리 대역폭이 병목이 되는 경우가 흔한데, 하드웨어를 더 사들이지 않고 소프트웨어만으로 이 문제를 상당 부분 우회했다는 점에서 의미가 큽니다.

병렬 드래프트와 순차 보정을 섞은 구조, 그리고 GPU 부하에 맞춰 검증량을 실시간으로 조절하는 스케줄러까지 — 속도를 깎아 먹지 않으면서도 품질을 그대로 지키는 영리한 절충안을 찾아낸 셈이고, 회사 발표치뿐 아니라 외부 개발자의 독립 재현 결과와 PyTorch 코어 메인테이너의 기술적 호평까지 뒤따랐다는 점에서 숫자 자체의 신뢰도도 낮지 않아 보여요.

 

다만 학습 코드 기준으로 타깃 캐시가 수십 테라바이트에 달할 수 있다는 점, 드래프트 모델이 특정 타깃 모델에 맞춰 정렬되는 구조라 다른 모델로 그대로 옮겨 쓰기는 어렵다는 점, 그리고 논문 공동 저자에 베이징대가 포함되어 있어 서방 정부의 보안 심사 흐름과 맞물려 정치적 잡음이 따라붙는다는 점은 별개로 짚어둘 필요가 있습니다.

그래도 체크포인트와 학습 코드 전체가 MIT 라이선스로 깃허브와 허깅페이스에 공개돼 있어서, 자체 인프라에서 직접 돌려보고 싶은 개발자라면 지금 바로 시도해볼 수 있는 상태예요. 추론 비용에 민감한 팀이라면 한 번쯤 벤치마크 돌려볼 가치는 충분해 보입니다.