2026년 6월 27일, 'DSpark: 반자기회귀 생성 기반 신뢰도 스케줄링 추측 디코딩'이라는 제목의 논문이 업계의 주목을 받았다. 이 논문은 DeepSeek 창립자 량원펑(梁文鋒)이 저자로 참여했으며, 베이징대학교와 공동으로 완성했다. 논문은 주목할 만한 데이터를 공개했다: DSpark를 DeepSeek-V4 온라인 서비스 시스템에 배포하여 실제 사용자 트래픽을 처리했을 때, 단일 사용자 생성 속도가 Flash 버전에서 60%~85%, Pro 버전에서 57%~78% 크게 향상되었으며, 오프라인 또는 높은 동시성 시나리오에서는 집계 처리량이 51%에서 400%까지 증가했다.

이 수치는 단순한 하드웨어 축적에 따른 선형적 증가가 아니라, 기반 추론 아키텍처의 질적 변화다. 이 숫자의 진가를 이해하려면 대규모 모델 추론 과정의 연산 블랙홀을 먼저 파악해야 한다.

85% 속도 향상의 실체: '무효 검증'이 잡아먹는 연산 자원

현재 주류 대규모 모델은 대부분 자기회귀 생성 방식을 사용한다. 간단히 말해, 모델이 텍스트를 생성할 때는 한 글자씩 순차적으로 내놓는다. 한 글자를 생성할 때마다 모델은 이전의 모든 컨텍스트를 다시 통과시켜 다음 글자의 확률 분포를 계산한다. 이러한 직렬 생성 방식은 GPU의 병렬 연산 능력을 심각하게 놀리게 만든다. 더욱 중요한 점은, 대규모 모델 추론이 일반적으로 '메모리 접근 병목(memory-bound)' 현상이라는 것이다.

하드웨어 측면에서 이러한 메모리 접근 병목은 주로 KV Cache(키-값 캐시)의 읽기/쓰기에서 나타난다. 이전 컨텍스트를 반복 계산하지 않기 위해, 모델은 앞서 생성된 각 단계의 은닉 상태를 Key와 Value 형태로 GPU 메모리에 저장한다. 시퀀스 길이가 증가함에 따라 KV Cache의 크기는 선형적으로 증가한다. 새로운 토큰을 생성할 때마다 GPU의 연산 유닛은 방대한 KV Cache가 GPU 메모리에서 연산 코어로 옮겨지기를 기다려야 한다. 즉, GPU 대부분의 시간은 행렬 곱셈이 아니라 데이터를 기다리는 데 쓰인다. 연산 유닛의 유휴 시간과 반복적인 GPU 메모리 읽기/쓰기로 인한 대역폭 부담이 대규모 모델 추론의 가장 근본적인 비용 블랙홀을 형성한다.

이러한 직렬 병목을 해소하기 위해 업계는 추측 디코딩(speculative decoding) 기술을 도입했다. 기본 아이디어는 더 작고 빠른 초안 모델(draft model)을 도입하여, 이 모델로 하여금 다음에 생성될 가능성이 있는 몇 개의 토큰을 미리 추측하게 한 뒤, 목표 대형 모델이 이 초안들을 일괄 검증(batch verification)하는 것이다. 초안의 추측이 맞으면 대형 모델이 여러 토큰을 한 번에 확정하여 큰 폭의 속도 향상을 얻을 수 있고, 틀렸으면 대형 모델이 처음부터 다시 시작한다.

그러나 전통적인 추측 디코딩 방식은 속도를 높이는 동시에 새로운 연산 낭비를 초래했다. Medusa와 같은 초기 병렬 초안 방식이나 Eagle3와 같은 자기회귀 초안 방식은 주로 맹목적으로 추측하는 전략을 사용했다. 병렬 초안을 예로 들면, 초안 모델이 동일한 시점에 가능한 여러 후보 토큰을 병렬로 추측하지만, 이는 토큰 간의 순차적 의존 관계를 무시한다. 반면 자기회귀 초안은 의존 관계를 고려하여 초안 모델이 스스로 긴 시퀀스를 생성하지만, 시퀀스가 길어질수록 초안 모델이 틀릴 확률이 기하급수적으로 증가한다.

목표 대형 모델이 이 긴 초안 시퀀스를 검증할 때 문제가 드러난다. 목표 모델은 앞부분 몇 개는 맞췠지만 뒤의 대부분은 틀렸다는 것을 발견한다. 전통적인 검증 메커니즘에서는 목표 모델이 전체 초안 시퀀스에 대해 완전한 순방향 전파(forward propagation) 계산을 수행해야 한다. 이 계산 과정에서 모델은 자신의 방대한 파라미터 가중치를 로드할 뿐만 아니라, 초안이 만들어낸 추가 KV Cache까지 처리해야 한다. 즉, 버려질 것이 분명한 잘못된 초안을 검토하는 데 상당한 GPU 연산 능력과 메모리 대역폭을 소모하는 셈이다. 이러한 '무효 검증'은 동시성이 낮을 때는 두드러지지 않을 수 있지만, DeepSeek-V4의 실제 트래픽이라는 높은 부하 아래에서는 연산 낭비가 급격히 증폭되어 실제 응답 속도를 늦출 뿐만 아니라 이미 높은 추론 비용을 더욱 악화시킨다. DSpark의 등장은 바로 이렇게 잡아먹힌 연산 자원을 되찾기 위한 것이다.

인턴과 멘토: DSpark가 추측 디코딩을 더 이상 맹목적이지 않게 만드는 법

DSpark의 핵심 기술 메커니즘은 반자기회귀 생성(Semi-Autoregressive Generation)과 신뢰도 스케줄링 추측 디코딩(Confidence Scheduled Speculative Decoding)으로 요약할 수 있다. 이 두 가지 낯선 학술 용어의 본질은 초안 모델과 목표 모델 간의 협업 관계를 재구성하여 GPU 메모리 읽기/쓰기와 연산 스케줄링의 논리를 근본적으로 바꾸는 데 있다.

이 과정을 이해하기 위해 쉬운 비유를 들어보자. 목표 대형 모델은 엄격한 멘토(교수)이고, 초안 모델은 반응이 아주 빠른 인턴이라고 가정하자. 전통적인 추측 디코딩에서는 멘토가 인턴에게 앞으로 쓸 열 문장을 맹목적으로 추측하게 한다. 인턴은 빠르게 작성하지만, 대개 다섯 번째 문장부터 주제를 벗어나기 시작한다. 멘토가 이를 받아보면 앞의 네 문장은 쓸 만하지만 뒤의 여섯 문장은 모두 휴지 조각이다. 멘토가 이 여섯 개의 잘못된 문장을 검토하는 데 쏟는 노력이 바로 낭비되는 연산 자원이다.

DSpark의 반자기회귀 생성 메커니즘은 인턴에게 전후 문맥을 동시에 고려하는 보조 두뇌를 장착해 주는 것과 같다. 인턴이 추측할 때 완전히 맥락을 벗어나 무턱대고 발산하는 것이 아니라, 이미 생성된 내용을 바탕으로 어느 정도 자체 수정을 할 수 있게 된다. 기술적으로는, 초안 모델이 여러 후보 토큰을 생성할 때 직전 단계의 은닉 상태를 활용하여 다음 단계의 생성을 안내함으로써, 긴 시퀀스 초안의 적중률을 높이고 마지막 부분의 통과율 감소 문제를 완화한다는 의미이다.

더욱 핵심적인 혁신은 신뢰도 스케줄링에 있다. DSpark 프레임워크에서 인턴은 초안을 제출할 때 각 부분에 신뢰도 점수를 매겨, 자신이 해당 부분의 추측에 대해 어느 정도 확신하는지 표시한다. 멘토는 검토할 때 이 점수에 따라 동적으로 스케줄링한다.

구체적인 알고리즘 로직에서, 초안 모델의 출력 레이어는 어휘 사전 상의 확률 분포 외에도 해당 예측 토큰의 신뢰도를 나타내는 추가적인 스칼라 값을 출력한다. DSpark는 동적 임계값 메커니즘을 설정하여 초안 시퀀스를 분할한다. 어떤 초안 세그먼트의 신뢰도가 연속적으로 임계값보다 높으면 시스템은 해당 부분이 정확할 확률이 크다고 판단하여 높은 우선순위로 분류하고, 신뢰도가 임계값 아래로 떨어지면 이후의 초안은 오류 확률이 매우 높다고 간주한다.

기저의 GPU 연산 로직에서 이러한 스케줄링은 기존의 '일괄 처리' 방식의 일괄 검증 모드를 바꿔놓는다. 인턴의 높은 신뢰도(정확할 확률이 높은) 부분은 멘토가 높은 우선순위의 컴퓨트 스트림에 배정하여 집중적으로 빠르게 검토한다. 신뢰도가 낮은 부분은 멘토가 곧바로 폐기하거나 낮은 우선순위의 컴퓨트 스트림으로 보내 검증 리소스 투입을 줄인다. 이렇게 하면 목표 모델이 반드시 틀릴 휴지 조각들에 소중한 GPU 메모리 대역폭과 연산 사이클을 낭비하는 것을 막을 수 있다.

이러한 메커니즘을 통해 DSpark는 무효 검증으로 인한 연산 낭비를 효과적으로 줄인다. 즈둥시(智東西) 등 미디어 보도에 따르면, Qwen3 시리즈 모델에서 DSpark의 평균 수용 길이(acceptance length)는 이전 세대 Eagle3 대비 26.7%에서 30.9%, DFlash 대비 16.3%에서 18.4% 향상되었다. 이는 동일한 시간 동안 목표 대형 모델이 더 많은 올바른 초안을 채택할 수 있어 생성 속도가 자연스럽게 빨라진다는 것을 의미한다. 이러한 최적화는 어떠한 추가 하드웨어 투입 없이 오직 스케줄링 알고리즘 개선만으로 연산 자원을 쥐어짠 것이다.

연산 장부: 낭비를 줄이는 것이 단순히 GPU를 추가하는 것보다 더 중요한 이유

엔지니어링 관점에서 DSpark는 훌륭한 알고리즘 최적화 사례다. 그러나 비즈니스 관점에서 이는 대형 모델 기업들이 치열한 비용 전쟁에서 살아남기 위한 생존 지침서다.

대형 모델 업계의 재무 모델은 추론 비용에 극도로 민감하다. OmniTools가 앞서 분석한 OpenAI 유출 회계 장부에 따르면, 연 매출 130억 달러에 운영 손실이 209억 달러에 달하는 충격적인 비용 구조가 드러났다. 이러한 '돈을 태워 규모를 키우는' 방식 이면에는 막대한 학습 비용 외에도 지속적으로 출혈을 일으키는 추론 연산 소모가 자리 잡고 있다. 대형 모델의 학습 비용은 규모가 크지만 대개 일회성 또는 단계적 자본 지출인 반면, 추론 비용은 운영 비용이다. 사용자가 API를 호출할 때마다, 모델이 답변을 생성할 때마다 실제 GPU 연산 자원, 전기료, 감가상각비가 소모된다.

전형적인 API 호출의 비용 구조를 구체적으로 추정해 볼 수 있다. 사용자가 1000단어 분량의 프롬프트를 입력하고 모델에게 1000단어 분량의 답변을 생성하도록 요청한다고 가정하자. 전통적인 자기회귀 모드에서는 프리필(Prefill) 단계에서 1000개의 입력 단어를 처리한 후, 디코드(Decode) 단계에서 1000회의 직렬 생성을 수행한다. 매 생성 단계마다 방대한 모델 가중치를 로드하고, 계속해서 커지는 KV Cache를 읽고 써야 한다. 일반적인 천억 개 파라미터 모델에서 단일 디코드 단계의 계산은 몇 밀리초에 불과할 수 있지만, 데이터 이동에는 수십 밀리초가 소요될 수 있다.

만약 전통적인 맹목적 추측 디코딩을 사용하면, 초안 모델이 200개의 단어를 빠르게 생성했더라도 목표 모델이 검증 시 앞의 50개만 맞고 뒤의 150개가 모두 틀렸음을 발견한다면, 그 뒤의 150개 단어를 처리할 때 목표 모델이 동원한 GPU 연산 유닛, 점유한 메모리 대역폭, 소비한 전력은 모두 매몰 비용이 된다. 하루에 수천만 건의 API 호출이 발생할 때 이러한 무효 검증이 누적시킨 연산 낭비는 곧바로 분기 재무제표에 반영되어 이익을 집어삼키는 밑 빠진 독이 된다.

사용자 수가 급증할 때 추론 효율이 낮다면 기업은 두 가지 선택지밖에 없다. 사용자 접근을 제한하거나, GPU를 대량으로 사들여 증설하는 것이다. 전자는 시장 점유율을 잃게 하고, 후자는 현금 흐름을 바닥내 버린다. 자본이 점차 이성적으로 변하고 있는 지금, 무한정 자금을 조달하여 연산 부족이라는 구멍을 메우는 모델은 더 이상 지속 가능하지 않다. 더욱 치명적인 것은, 모델 파라미터 규모가 커지고 컨텍스트 길이가 확장될수록 단일 추론의 연산 소모가 기하급수적으로 증가한다는 점이다. 만약 무효 검증과 같은 연산 낭비가 그대로 방치된다면, 대형 모델 기업의 손실 폭은 사용자 규모가 커짐에 따라 무한정 확대될 것이다.

DSpark가 대표하는 추론 최적화 경로는 세 번째 해법을 제시한다. 무효 검증에 의한 연산 낭비를 줄임으로써 DeepSeek-V4는 하드웨어 클러스터를 추가하지 않고도 높은 동시성 시나리오에서 집계 처리량을 최대 400%까지 끌어올렸다. 이는 동일한 서버 그룹으로 이전보다 몇 배나 많은 사용자 요청을 처리할 수 있음을 의미한다.

대형 모델 기업에게 이러한 엔지니어링 최적화의 가치는 단순히 연산 자원을 쌓는 것보다 훨씬 크다. GPU 추가는 비용과 생산 능력이 선형적으로 증가하는 방식으로, 카드를 하나 추가할 때마다 구매 비용, 운영 비용, 전력 부담이 함께 늘어난다. 반면 알고리즘 차원의 효율성 향상은 고정 비용 하에서 생산 능력이 기하급수적으로 도약하는 효과를 낸다. 업계가 가격 경쟁 단계에 접어들면, 단일 API 호출에서 연산 비용을 낮출 수 있는 기업이 마진율을 보장하면서도 더 파괴적인 가격을 제시할 수 있다. DSpark는 모델을 더 빠르게 만들었을 뿐 아니라, 대형 모델의 비즈니스 선순환 구조를 더욱 건전하게 만들어, 저수익 시대에 기업이 살아남을 수 있는 버팀목을 제공한다.

오픈소스 DeepSpec: 중소 규모 팀에게 무기를 쥐여주다

이는 업계가 높은 관심을 기울여야 할 행보다. 현재 AI 생태계에서 OpenAI, Anthropic과 같은 폐쇄형 거대 기업들도 내부적으로 추측 디코딩이나 유사한 추론 가속 아키텍처를 활용하고 있지만, 이러한 풀스택 추론 최적화 도구 체인을 오픈소스로 공개하는 경우는 극히 드물다. 중소 AI 스타트업 팀이 자신의 미세 조정 모델에 맞는 효율적인 초안 모델을 학습시키려면 대개 바닥부터 모든 것을 구축해야 한다.

우리는 단 몇 장의 A100 GPU만 보유한 스타트업 팀의 실제 상황을 상상해 볼 수 있다. 그들은 수직 도메인 모델을 미세 조정했지만, 배포 후 생성 속도가 너무 느려 사용자 경험이 극도로 나쁠 수 있다. 추측 디코딩을 자체적으로 구현하려면 CUDA 연산자 개발, KV 캐시의 메모리 관리, 그리고 초안 모델 학습 파이프라인을 직접 설계해야 한다. 이는 높은 인건비뿐만 아니라 긴 시행착오 기간을 의미한다. 많은 중소 팀이 바로 이 단계에서 자금을 소진한다.

DeepSpec의 오픈소스화는 가장 앞선 추론 최적화 무기를 업계 전체에 직접 제공한 셈이다. 구체적인 프레임워크 설계에서 DeepSpec은 고도로 모듈화된 인터페이스를 제공한다. 개발자가 내부 추론 엔진을 처음부터 다시 작성할 필요 없이, 설정 파일에 메인 모델 경로와 초안 모델 경로만 지정하면 프레임워크가 초안 생성, 신뢰도 계산, 목표 모델 검증의 전체 과정을 자동으로 처리한다.

자체 초안 모델을 학습시키고자 하는 팀을 위해 DeepSpec은 표준화된 데이터 증류 모듈을 제공하여, 목표 대형 모델의 은닉 상태를 추출해 초안 모델이 학습할 수 있게 한다. 이는 데이터 준비의 진입 장벽을 크게 낮춰준다. 개발자는 더 이상 반자기회귀 초안 모델을 직접 설계하거나 신뢰도 스케줄링 매개변수를 반복적으로 디버깅할 필요가 없다. DeepSpec이 제공하는 표준화된 도구 체인을 통해, 중소 팀은 문서에 따라 매개변수만 설정하면 자신의 모델에 추측 디코딩 능력을 연결하고 생성 속도가 크게 향상되는 혜택을 누릴 수 있다.

이러한 오픈소스 전략은 업계 전체의 기술 발전을 가속할 뿐만 아니라, 폐쇄형 거대 기업들이 추론 효율성에서 가졌던 장벽을 어느 정도 약화시킨다. 가장 첨단의 엔지니어링 최적화 능력이 업계의 공공 인프라가 되면, 대형 모델 경쟁의 초점은 더 상위 계층의 응용 혁신과 더 하위 계층의 데이터 품질로 전환될 수밖에 없다.

주 전장의 이동: 모델 외부는 모두 Harness

DSpark의 발표와 DeepSeek-V4의 성공적인 배포는 거스를 수 없는 업계 트렌드를 입증한다: 대형 모델 경쟁의 주 전장이 이동했다.

OmniTools가 '모델 외부는 모두 Harness: Deepseek 참전, 왜 국내 AI 경쟁의 주 전장이 바뀌었나?'라는 글에서 지적했듯이, 각 업체의 기반 모델 파라미터 규모가 수천억 수준에 도달하고 각종 벤치마크 테스트에서의 성능이 동질화되면, 단순히 파라미터 경쟁만으로는 격차를 벌릴 수 없다. AI 제품의 생사와 비용을 결정하는 것은 모델 외부의 툴체인, 추론 스케줄링 아키텍처, API 라우팅과 같은 시스템 엔지니어링 능력, 즉 이른바 Harness다.

기반 엔지니어링에 익숙하지 않은 사람에게는 'Harness'라는 단어가 다소 추상적으로 느껴질 수 있다. 소프트웨어 공학에서 Harness는 보통 '테스트 하네스' 또는 '프레임워크'를 의미하지만, 대형 모델 맥락에서는 기반 모델을 감싸는 전체 시스템 엔지니어링 인프라를 가리킨다. 이는 사용자 요청을 관리하는 API 라우팅 분산 시스템, 생성을 가속하는 추론 스케줄링 아키텍처(추측 디코딩 및 KV 캐시 관리 등), 모델이 외부 도구와 인터넷 검색을 활용할 수 있게 하는 툴체인, 그리고 고가용성을 보장하는 재해 복구 모니터링 시스템을 포함하되 이에 국한되지 않는다. 기반 모델은 엔진과 같고, Harness는 섀시, 변속기, 구동축이다. 엔진이 아무리 강력해도 Harness가 부실하면 동력이 바퀴에 전달되지 않는다.

DSpark는 바로 Harness 차원에서의 전형적인 경쟁이다. 이는 DeepSeek-V4의 기반 파라미터를 바꾸거나 모델의 지능을 높이지 않지만, 극한의 엔지니어링 최적화를 통해 실제 트래픽에서 발생하는 연산 낭비 문제를 해결함으로써 사용자 경험(응답 속도)과 기업의 재무 모델(추론 비용)을 직접 개선한다. 앞으로 대형 모델 경쟁은 점점 더 이런 보이지 않는 시스템 엔지니어링 경쟁으로 나타날 것이다. 누구의 추론 스케줄링이 더 지능적이고, 누구의 KV 캐시 관리가 더 효율적이며, 누구의 추측 디코딩 적중률이 더 높은지에 따라 동일한 연산 자원으로 더 많은 출력을 낼 수 있다. '파라미터 경쟁 내몰리기'에서 '엔지니어링 실전 배치'로 전환함에 따라, 기업은 알고리즘뿐 아니라 시스템, 하드웨어, 실제 비즈니스 트래픽 특성까지 이해해야 한다.

한계와 경계: DSpark는 만능약이 아니다

비록 DSpark가 장문 텍스트 생성과 높은 동시성 시나리오에서 놀라운 최적화 효과를 보여주었지만, 이는 대형 모델 추론 문제의 만능 해결책이 아니다. 모든 기술 솔루션에는 적용 경계가 있으며, DSpark 역시 예외가 아니다.

첫째, 매우 높은 스토리지 요구 사항이다. DSpark 논문에 공개된 데이터에 따르면, 중간 규모 모델(예: Qwen3-4B)에 맞는 초안 모델을 학습시키는 데 필요한 목표 캐시 볼륨은 최대 38TB에 달한다. 이 수치는 막대한 연산 클러스터를 보유한 상위 업체에게는 일상적인 구성일 수 있지만, 자원이 제한된 중소 팀에게 38TB의 고속 스토리지 접근 자체가 넘기 어려운 장벽이다. 이는 DeepSpec이 코드를 오픈소스화했음에도, 중소 팀이 DSpark 수준의 최적화를 완전히 재현하고 배포하려면 여전히 하드웨어 자원의 현실적 제약을 극복해야 함을 의미한다. 스토리지 비용과 I/O 병목 현상은 이 기술의 전면적 보급을 가로막는 현실적 장애물이 될 수 있다.

둘째, 최적화 단계의 한계다. 대형 모델 추론은 일반적으로 Prefill(사전 채우기)과 Decode(디코딩) 두 단계로 나뉜다. Prefill 단계는 모델이 사용자 입력 프롬프트를 읽고 첫 번째 토큰을 생성하는 과정으로, 연산 집약적이어서 GPU 연산 능력이 충분히 활용된다. 반면 Decode 단계는 이후 토큰을 순차적으로 생성하는 과정으로, 메모리 접근 집약적이며 추측 디코딩이 주로 효과를 발휘하는 단계다. DSpark는 주로 Decode 과정을 대상으로 한다. 사용자가 매우 민감하게 느끼는 첫 토큰 지연 시간(Prefill 단계)에 대해서는 DSpark의 최적화 효과가 상대적으로 제한적이다. 짧은 텍스트 상호작용 시나리오(예: 간단한 질문 답변이나 명령 실행)에서는 생성할 내용이 적기 때문에 추측 디코딩이 가속할 수 있는 여지가 줄어들어 DSpark의 속도 이점이 두드러지지 않을 수 있다.

마지막으로 이기종 연산 환경에 대한 적응 문제다. 현재 DSpark의 온라인 검증은 주로 DeepSeek-V4의 특정 서비스 아키텍처를 기반으로 하며, 엔비디아(Nvidia)가 아닌 하드웨어(예: 각종 국산 연산 칩)에서의 적응 상황과 실제 가속 비율에 대한 공개 테스트 데이터가 부족하다. 서로 다른 하드웨어 아키텍처에서는 메모리 대역폭과 연산 유닛의 스케줄링 로직에 차이가 있어, 신뢰도 스케줄링 전략을 재조정해야 할 필요성이 있는지 여전히 해결해야 할 엔지니어링 문제다.

기술 최적화에는 마법의 총알이 없다. DSpark는 알고리즘 스케줄링을 통해 연산 낭비를 제거할 수 있는 엄청난 잠재력을 증명했으며, 대형 모델 업계가 비용 전쟁에서 승리할 수 있는 강력한 무기를 제공한다. 그러나 실제 구현에서는 개발자가 자신의 비즈니스 시나리오, 하드웨어 보유량, 지연 민감도에 따라 이 솔루션의 투자 대비 효과를 이성적으로 평가해야 한다. 대형 모델의 엔지니어링 여정은 이제 본격적인 심해에 접어들었다.

X 플랫폼의 iOS 앱에는 북마크, 동영상, 좋아요 등을 통합한 "방문 기록" 탭이 추가되었습니다.

인기 기사