DLite: History-free Speculative Decoding for Agentic AI

코딩 에이전트가 파일을 읽고 도구를 호출할수록, 모델에 다시 넣어야 할 대화와 실행 기록은 길어진다. 답변을 빨리 만들기 위해 작은 모델을 붙여도, 그 작은 모델까지 긴 기록을 따로 처리하고 보관한다면 새로운 부담이 생긴다.

DLite는 긴 기록은 본체 모델이 처리하고, 작은 모델은 본체가 만든 내부 표현을 받아 다음 후보만 만들게 한다. 없애는 것은 작은 모델이 따로 유지하던 과거 기록용 KV 캐시다. 본체 모델의 캐시나 과거 정보 자체를 없애는 방법은 아니다.

논문 · 코드

작은 모델을 붙이면 왜 빨라질까

언어 모델은 보통 다음 토큰을 하나씩 생성한다. 여기서 토큰은 모델이 문장을 처리하는 단위로, 단어나 단어의 일부일 수 있다. 큰 모델을 토큰마다 실행하는 대신, 작은 모델이 후보 여러 개를 먼저 내고 큰 모델이 한 번에 검사하면 실행 횟수를 줄일 수 있다. 이것이 **추측 디코딩(speculative decoding)**의 기본 생각이다(§2.1).

두 모델의 역할을 나누면 이해하기 쉽다. **초안 모델(drafter)**은 빠르게 후보를 제안하고, **본체 모델(target)**은 후보를 검증해 실제 출력으로 이어간다. 후보가 많이 받아들여지고 후보를 만드는 비용이 작을수록 유리하다. 후보를 만드는 작은 모델이 느리거나 자주 틀리면, 붙여 둔 이점이 줄어든다.

에이전트에서는 도구 실행 결과와 이전 대화가 계속 쌓인다. 기존 초안 모델도 이 기록을 자기 방식으로 처리하며, 다음 생성에 재사용할 내부 데이터를 KV 캐시에 저장한다. KV 캐시는 이미 처리한 토큰을 매번 처음부터 계산하지 않도록 보관하는 데이터다. 본체와 초안 모델이 각자 캐시를 유지하면, 새 토큰이 확정될 때 초안 쪽 기록도 갱신해야 한다(§3.1).

원문 Figure 1의 왼쪽은 긴 입력과 짧은 출력이 반복되는 에이전트 실행을, 오른쪽은 이런 작업에서 한 번에 받아들여지는 토큰 수가 줄어드는 상황을 보여준다. 이 그림에서 볼 점은 “작은 모델이 있다”는 사실보다 긴 기록을 처리하는 작은 모델이 좋은 후보를 계속 낼 수 있는가다.

전체 파이프라인: 무엇을 남기고 무엇을 없애나

DLite에서는 본체가 긴 기록을 처리한 뒤 만든 **내부 표현(hidden state)**을 초안 모델에 건넨다. 내부 표현은 사람이 읽는 요약문이 아니라 신경망의 중간 계산값이다. 초안 모델은 이 값과 직전에 확정된 토큰을 받아 새 후보를 만든다(§4.1).

아래는 후보가 검사되는 흐름을 보여주는 설명용 예시다. 영어 단어를 눈에 보이는 단위로 사용했으며 실제 토크나이저의 분할이나 논문 측정값을 뜻하지 않는다.

첫 패널에서 긴 기록과 본체의 캐시는 그대로 남아 있다. 초안 모델이 받는 것은 본체의 내부 표현과 현재 위치의 정보다. 따라서 “history-free”는 기록을 잊는다는 뜻이 아니라, 초안 모델이 긴 기록용 캐시를 따로 유지하지 않는다는 뜻이다.

둘째 패널에서 초안은 jumps over a dog를 제안한다. 셋째 패널은 검증 결과를 jumps, over는 통과하고 a에서 거절되는 경우로 가정했다. 이 경우 dog도 확정하지 않고, 검증 절차에 따른 토큰 the로 이어간다. 이는 정답 문자열과 단순 비교한다는 뜻이 아니라, 후보의 통과·거절 이후 어떤 부분이 남는지 보여주는 예시다.

실제 한 라운드의 흐름은 다음과 같다.

표에서 초안 모델은 긴 기록을 다시 저장하지 않지만, 본체 계산과 검증은 남는다. DLite가 줄이는 작업의 범위를 이 둘과 혼동하면 안 된다(§4.1, Figure 3).

후보는 함께 준비하되, 선택할 때는 앞 단어를 본다

다음 몇 개의 위치를 동시에 계산하면 빠르다. 하지만 각 위치의 단어까지 서로 독립적으로 뽑으면 문장이 잘 이어지지 않을 수 있다. 예를 들어 jumps 다음 단어를 고를 때는 앞에서 실제로 jumps를 골랐다는 정보가 필요하다.

DLite는 이 일을 둘로 나눈다. 먼저 병렬 백본이 여러 위치의 중간 표현을 함께 계산한다. 그다음 작은 순차 헤드가 앞서 선택한 후보를 반영해 다음 후보를 고른다. 큰 계산은 함께 하고, 앞 후보와의 연결을 반영하는 작은 계산만 순서대로 한다는 설계다(§4.1.1–4.1.2).

여기서 순차 헤드가 다루는 것은 현재 후보 묶음 안의 정보다. 전체 대화와 파일 내용을 다시 읽는 것은 아니다. 또한 중간 표현을 어휘 전체의 점수로 바꾼 뒤 다시 다듬는 대신, 중간 표현에서 순서를 반영하고 나서 어휘 점수를 계산한다. 큰 어휘 변환을 중간 단계에서 반복하는 비용을 줄이려는 선택이다.

원문 Figure 3은 위 설명을 실제 모델 구성에 연결한다. 본체에서 나온 표현이 초안 쪽으로 전달되는 경로와, 병렬 계산 뒤에 순차 헤드가 놓이는 순서를 보면 된다. 독자가 만든 예시 그림은 후보의 변화를, 이 원문 그림은 구현 구성요소 사이의 연결을 설명한다.

이 구조는 학습에도 준비가 필요하다. 저자들은 DLite와 비슷한 구조이면서 과거 캐시에 접근할 수 있는 중간 교사 모델로 먼저 학습시킨 뒤, 본체 모델을 직접 따라가도록 학습한다. 추론 시 캐시를 없애는 대신 학습 절차가 추가되는 셈이다(§4.2).

결과: 후보 수와 실제 속도를 따로 읽어야 한다

실험은 Qwen3-4B와 Qwen3-8B를 본체로 사용했고, 서빙 하드웨어는 NVIDIA H800이다. 후보 블록 크기는 7이다. 결과의 두 지표를 구분해야 한다. 수용 길이는 검증 한 번으로 얼마나 생성하는지를, 속도 배수는 일반적인 한 토큰씩 생성하는 방식보다 얼마나 빨라졌는지를 나타낸다(§5.1).

아래는 SWE-Bench의 결과다. DSpark는 비교 대상인 다른 초안 모델 방식이다(원문 Table 3).

4B에서 1.89→3.15는 수용 길이가 약 66.7% 늘어난 것이다. 반면 2.68배는 DSpark 대비가 아니라 일반 생성 대비 속도다. DSpark와 직접 속도를 비교하려면 2.68을 1.64로 나눠 약 1.63배로 읽어야 한다. “후보를 더 받아들인다”와 “서비스가 빨라진다”는 연결되지만 같은 숫자는 아니다.

짧은 범용 과제에서는 차이가 작다. 예를 들어 4B의 GSM8K 수용 길이는 DSpark 6.27, DLite 6.38이다(Table 1). 따라서 어느 작업에서나 큰 폭으로 개선된다고 읽기보다, 기록이 길어지는 작업에서 이 설계가 얼마나 유리한지를 봐야 한다.

동시에 여러 요청을 처리할 때도 배수가 그대로 유지되는 것은 아니다. 4B Alpaca에서 DLite의 일반 생성 대비 처리량 배수는 동시 요청 1개에서 2.58배, 64개에서 1.32배였다. 실제 요청 수와 입력 길이에 맞춘 검증이 필요하다(Table 4).

적용 전에 확인할 한계

먼저 본체 모델의 내부 표현을 꺼내 초안에 전달할 수 있어야 한다. 따라서 이 방식을 검토할 때는 모델 이름뿐 아니라 서빙 엔진에서 그 경로를 구현할 수 있는지도 확인해야 한다. 본체 KV 캐시는 계속 필요하므로 긴 입력 전체의 메모리 문제가 사라지는 것은 아니다.

학습 비용도 남는다. 앞서 설명한 중간 교사와 두 단계 학습은 저자가 도입한 절차다. 이미 학습된 작은 모델을 연결하기만 하면 같은 결과를 얻는다는 뜻으로 읽으면 안 된다(§4.2).

리뷰어 관점에서 남는 질문은 적용 범위다. 제시된 본체는 4B·8B Qwen3이고 서빙 실험은 H800 환경이다. 더 큰 본체나 다른 구조의 모델, 본체와 초안을 서로 다른 장치에 두는 배치에서도 같은 이득이 나는지는 별도 확인이 필요하다. 표의 수용 길이와 속도는 작업 성공률 자체를 측정한 수치도 아니다.

DLite를 검토할 만한 상황은 긴 기록을 자주 다시 사용하는 에이전트 서빙이다. 중요한 질문은 “캐시가 0인가”보다 누가 긴 기록을 처리하고, 그 결과를 누가 재사용하는가다. 본체의 기록 처리는 유지하면서 초안의 중복 저장과 갱신을 줄이는 것이 이 설계의 초점이다.