[arXiv 2604.14885] RACER: 검색 증강과 로그릿 트리를 결합해 speculative decoding을 더 빠르게 만드는 방법

RACER: Retrieval-Augmented Contextual Rapid Speculative Decoding

https://arxiv.org/abs/2604.14885

Zihong Zhang, Zuchao Li, Lefei Zhang, Ping Wang, Hai Zhao | Wuhan University, Shanghai Jiao Tong University | arXiv:2604.14885 | 2026년 4월 | ACL 2026 Findings

---

1. 서론: 자기회귀 디코딩의 병목을 우회하는 하이브리드 초안 전략

자기회귀 디코딩의 병목은 모델 품질이 아무리 좋아져도 쉽게 사라지지 않는다. 거대 언어모델은 한 번에 하나의 토큰만 확정하는 구조를 갖기 때문에, 응답 길이가 길어질수록 지연이 선형적으로 늘어난다. 특히 장문 응답, 코드 생성, 추론형 질의, RAG 파이프라인처럼 출력 토큰 수가 많은 환경에서는 이 병목이 사용자 체감 성능을 거의 결정한다. 논문은 바로 이 지점을 겨냥해, 정확도를 유지하면서도 더 적은 target model 호출로 같은 출력을 만들어 내는 speculative decoding 문제를 다시 설계한다.

기존 speculative decoding은 크게 두 갈래로 나뉜다. 하나는 draft model을 따로 두는 방식이고, 다른 하나는 현재 디코딩 과정에서 이미 생긴 신호만 활용하는 training-free model-free 방식이다. 전자는 높은 초안 품질을 기대할 수 있지만 추가 학습, 추가 메모리, 모델 배포 복잡성이 뒤따른다. 후자는 경량성과 이식성이 강하지만, retrieval만 쓰면 정확히 맞아떨어지는 반복 패턴이 없을 때 급격히 약해지고, logits만 쓰면 구조적 실마리 없이 짧은 미래만 좁게 추정하는 한계가 남는다.

RACER는 이 둘 사이의 틈을 메운다. 논문이 제안하는 핵심 관점은 retrieval을 완성된 draft 생성기로 보지 않고, logits가 더 멀리 extrapolation하도록 도와주는 구조적 앵커로 재해석하는 데 있다. retrieval은 이미 본 적 있는 패턴, 즉 seen information을 제공하고, logits는 아직 정확히 일치하는 패턴이 없는 구간에서 unseen information을 제공한다. 저자들은 이 두 신호를 하나의 draft tree 안에서 결합하면, exact match가 없을 때도 retrieval이 완전히 무력화되지 않고, logits도 막연한 top-k 확장보다 더 좋은 후보 분포를 만들 수 있다고 주장한다.

이 문제의식은 최근 블로그에서 다뤘던 retrieval 품질 해석 논의와도 묘하게 이어진다. 예를 들어 [[entities/papers/cue-r-2604-05467|CUE-R]]와 [[concepts/evidence-utility-in-rag|Evidence Utility in RAG]]는 retrieval item이 실제로 결과에 얼마나 기여했는지를 평가 관점에서 파고들었다. 반면 RACER는 retrieval을 평가 대상이 아니라 디코딩 가속의 구조 재료로 끌어온다. 즉 retrieval을 “답을 더 맞히기 위한 외부 기억”으로만 다루지 않고, “다음 몇 토큰을 더 멀리 미리 맞히기 위한 모양 신호”로 바꾼 셈이다.

논문이 내세우는 기여는 크게 네 축으로 정리할 수 있다. 첫째, copy-logit과 last-logit을 비교해, 다음 토큰과 같은 vocabulary ID가 과거에 등장했을 때 그 직후 logits를 재사용하는 방식이 speculative expansion에 더 유리하다는 사실을 보인다. 둘째, suffix array나 suffix automaton 대신 Aho–Corasick automaton에 LRU eviction을 결합해, 동적으로 커지는 retrieval 구조를 제한된 메모리 안에서 유지한다. 셋째, retrieval 후보와 logits 후보를 고정 비율로 단순 분할하지 않고 하나의 trie 기반 draft tree로 합쳐 merge 전략을 만든다. 넷째, Vicuna, LLaMA3.1, OpenPangu, Qwen3 같은 서로 다른 계열 모델에서 일관된 속도 향상을 보고해 plug-and-play 성격을 강조한다.

• 추가 draft model 없이 target model의 현재 로그릿과 디코딩 히스토리만으로 초안을 만든다.
• retrieval을 단독 정답 생성기가 아니라 structural guidance로 재배치한다.
• 동적 context 안에서 재사용 가치가 낮은 n-gram 상태를 LRU leaf eviction으로 정리한다.
• 코드 생성, 일반 지시 따르기, 중국어 수학 추론, RAG 태스크까지 폭넓게 다룬다.

결국 RACER가 흥미로운 이유는 “speculative decoding을 더 잘하는 또 하나의 트릭”이라서가 아니라, training-free acceleration의 설계 단위를 다시 정의하기 때문이다. retrieval-only와 logits-only를 병렬로 붙이는 것이 아니라, 둘이 서로의 약점을 메우는 방식으로 결합하면 model-free 영역에서도 2배를 넘는 속도 향상이 가능하다는 점을 논문은 보여주려 한다. 이 글에서는 그 결합 원리가 어떻게 만들어졌는지, 왜 copy-logit과 AC automaton이 선택됐는지, 그리고 실험 수치가 실제로 어떤 해석을 허용하는지 차례로 정리해 보겠다.

2. 배경 및 관련 연구: retrieval과 logits가 왜 따로는 부족했는가

2.1 Speculative decoding의 기본 메커니즘

speculative decoding의 기본 골격은 guess-and-verify다. 먼저 가벼운 초안 단계가 여러 개의 토큰 후보를 제안하고, 그 다음 target model이 이 후보들을 한 번에 검증한다. 이때 핵심은 target model이 여전히 최종 확정 권한을 갖는다는 점이다. draft가 아무리 공격적으로 여러 토큰을 내놓더라도, 검증에서 탈락하면 그 지점 이후는 버려지고 마지막으로 수용된 prefix부터 다시 시작한다. 그래서 speculative decoding은 품질을 깎아 속도를 얻는 근사 기법이라기보다, 같은 분포를 유지한 채 target model 호출 수를 줄이는 병렬화 트릭에 가깝다.

논문은 기존 문헌을 따라 acceptance rule을 다음처럼 정리한다.

$$ \alpha_i= \begin{cases} 1 & \text{if } p_i[\tilde{x}_i] \ge q_i[\tilde{x}_i], \\ \dfrac{p_i[\tilde{x}_i]}{q_i[\tilde{x}_i]} & \text{otherwise.} \end{cases} $$

여기서 $q_i$는 draft 분포, $p_i$는 target model 분포, $\tilde{x}_i$는 초안 토큰이다. 초안 토큰이 받아들여지면 sequence는 그만큼 여러 칸 앞으로 전진하고, 거절되면 해당 단계는 조기 종료된다. 이 구조 덕분에 한 번의 speculative step은 기대적으로 최대 $\gamma+1$개의 토큰을 전진시킬 수 있다. 즉 좋은 speculative method는 더 긴 accepted prefix를 자주 만들어야 하고, 이를 논문은 MAT(Mean Accepted Tokens)로 요약한다.

문제는 좋은 초안을 만드는 방법이다. model-based 계열은 Medusa나 EAGLE-3처럼 추가 head 혹은 별도 draft model을 둬서 품질 높은 후보를 예측한다. 이 방식은 일반적으로 MAT가 잘 나오지만, 별도 가중치, 추가 메모리, 모델 조합 비용이 필요하다. 반대로 model-free 계열은 지금 이미 생성한 prefix와 현재 logits만 써서 후보를 뽑는다. deployment 관점에서는 매우 매력적이지만, 후보 품질을 어디서 끌어올릴 것인지가 늘 과제다.

• MAT: speculative step마다 실제로 수용된 평균 토큰 수
• Speedup: HuggingFace 기본 autoregressive decoding 대비 상대 속도
• Draft generation cost: 후보 생성 비용이 커지면 MAT가 높아도 end-to-end speedup이 악화될 수 있음
• Verification overhead: 트리가 지나치게 넓어지면 검증 비용이 다시 병목이 됨

2.2 Retrieval-only 계열과 logits-only 계열의 구조적 한계

retrieval-based 계열의 대표 사례는 PLD, REST, SAM Decoding이다. 이들은 과거 토큰 시퀀스나 외부 코퍼스에서 suffix match를 찾아 그 뒤의 continuation을 초안으로 쓴다. 코드처럼 반복 패턴이 강한 영역에서는 상당히 잘 먹히지만, 문제는 정확히 맞는 continuation이 존재해야 한다는 점이다. 조금만 표현이 바뀌거나, reasoning token이 길게 이어지거나, 대화 맥락이 비틀리면 retrieval이 갑자기 아무 일도 못 하게 된다. 즉 retrieval-only는 맞을 때는 길게 맞지만, 자주 맞지는 못한다.

반대로 logits-only 계열은 더 안정적으로 항상 뭔가를 제안할 수 있다. 대표적으로 Token Recycling은 token adjacency matrix를 유지하면서 top-k 트리를 확장하고, LogitSpec은 마지막 step의 logits에서 첫 draft 토큰을 뽑은 뒤 retrieval을 보조적으로 사용한다. 이 계열은 target model 내부 분포를 직접 활용하기 때문에 retrieval-only보다 범용성이 높다. 하지만 logits만으로는 본질적으로 local next-token tendency를 여러 단계 앞까지 추정하는 셈이라, 구조적 반복이 강한 구간에서 얻을 수 있는 긴 accepted span을 충분히 끌어오지 못한다.

RACER는 바로 이 두 한계를 나란히 놓고 본다. retrieval-only는 seen pattern은 강하지만 unseen continuation에 약하고, logits-only는 unseen continuation은 다루지만 구조적 정합성을 보장하기 어렵다. 저자들은 retrieval을 독립적인 후보군으로만 취급하지 않고, logits가 어떤 branch를 더 믿고 확장해야 하는지 알려 주는 structural hint로 끌어오면 두 약점을 동시에 완화할 수 있다고 본다. 논문이 제안한 “retrieval이 logits를 sharpen한다”는 문장은 바로 이 지점을 가리킨다.

이 관점은 retrieval을 정확도 향상 장치로만 보던 익숙한 프레임과 다르다. [[concepts/query-coverage-in-retrieval|Query Coverage in Retrieval]]이 retrieval을 질문 완성도 관점에서 읽었다면, RACER는 retrieval을 디코딩 후보 공간의 모양을 잡는 신호로 읽는다. 그래서 이 논문은 RAG 논문이 아니지만, retrieval을 어떻게 쓰느냐에 대한 철학 면에서는 최근 RAG 평가 논문들과 충분히 대화가 된다.

3. 방법론: RACER가 seen information과 unseen information을 합치는 방식

3.1 Logits Tree: copy-logit이 last-logit보다 왜 더 잘 맞는가

RACER의 첫 번째 축은 Logits Tree다. 저자들은 “다음 토큰 바로 뒤의 미지의 logits를 무엇으로 근사할 것인가”를 먼저 묻는다. 가장 단순한 아이디어는 현재 step의 logits $\mathbf{z}_t$를 재활용하는 last-logit이다. 하지만 논문은 더 공격적인 대안을 제시한다. 바로 방금 샘플링된 next token과 동일한 token ID가 과거에 등장한 위치 $i$를 찾고, 그 직후 logits $\mathbf{z}_{i+1}$를 재사용하는 copy-logit이다. 직관적으로는 “같은 토큰이 비슷한 국소 의미 상태를 이어 갈 가능성”을 이용하는 셈이다.

저자들은 Vicuna-7B, OpenPangu-7B, Qwen3-1.7B에서 first-layer expansion 실험을 수행하고, 본문에는 Vicuna-7B 결과를 대표로 제시한다. 그 결과 last-logit의 MAT는 1.57, copy-logit의 MAT는 1.87로 나타난다. 수치 차이만 중요한 것이 아니다. copy-logit은 accepted rank 분포가 훨씬 더 head-heavy하며, rank-1 하나가 accepted case의 절반 이상을 차지한다. 50th percentile accepted rank는 1, 85th percentile accepted rank는 9인데, 이는 last-logit의 11과 37보다 훨씬 날카롭다. 즉 copy-logit은 “될 만한 후보가 앞쪽에 더 몰린다”는 의미에서 speculative expansion에 유리한 분포를 만든다.

Figure 1: last-logit과 copy-logit이 next-token 이후 후보를 만드는 방식 비교

이 그림은 Logits Tree의 출발점을 한눈에 보여 준다. 흰 노드는 현재 step의 마지막 logits를 그대로 쓰는 last-logit 분기이고, 초록 노드는 동일 토큰의 과거 등장 지점을 찾아 그 다음 logits를 재활용하는 copy-logit 분기다. RACER는 여기서 copy-logit이 더 sharp한 분포를 만든다고 판단해 이후 확장의 기본 단위로 채택한다. 다시 말해, RACER의 logits branch는 무작정 top-k를 넓히는 방식이 아니라, 과거 동일 토큰의 국소 문맥을 간접적으로 재사용하는 방식으로 미래 후보를 추정한다.

이후 문제는 tree를 얼마나 넓고 깊게 펼칠 것인가다. 논문은 고정 9-ary, 높이 3의 analogy 실험을 통해 첫 레이어뿐 아니라 두 번째 레이어에서도 분포가 여전히 front-loaded라는 사실을 확인한다. 다만 부모 노드의 rank가 뒤로 갈수록 자식 분포의 총량이 빨리 줄어든다. 그래서 저자들은 모든 노드를 동일 폭으로 확장하지 않고, 위쪽은 과감하게, 아래쪽은 점점 덜 넓게 확장하는 규칙을 도입한다.

Figure 2: 고정 9-ary tree에서 copy-logit 분포가 어떻게 깊이에 따라 줄어드는지 보여 주는 analogy 실험

Figure 2는 “모든 branch를 같은 폭으로 밀 필요가 없다”는 경험적 근거를 준다. 첫 번째 자식의 하위 분포는 꽤 풍부하지만 부모 rank가 커질수록 성장률이 급격히 둔화된다. 논문은 바로 이 관찰을 근거로, root에 가까운 상단 노드에는 더 넓은 breadth를 주고 아래 레벨로 내려갈수록 breadth를 반으로 줄이는 pruning 규칙을 만든다. 이렇게 해야 draft budget을 의미 있는 후보에 몰아 주면서도, verification 때 쓸모없는 long-tail 노드로 예산이 새지 않는다.

논문이 제안한 breadth allocation은 다음과 같다.

$$ b_{\mathrm{child}(i,j)} = \max\left(1, \left\lfloor \frac{b_i}{2^{j + [i \ne 0]}} \right\rfloor \right) $$

여기서 $b_i$는 부모 노드의 breadth, $j$는 자식 인덱스다. root의 직계 자식은 최대 breadth로 시작하고, deeper layer는 부모의 절반 폭을 상속받는다. 이 설계는 tree attention을 쓰더라도 “앞쪽 몇 개 branch가 대부분의 acceptance를 먹는다”는 현실을 코드로 굳힌 것이다. 결과적으로 RACER의 Logits Tree는 단순한 top-k expansion이 아니라, copy-logit 기반의 heavy-tail aware BFS pruning이라고 요약할 수 있다.

Figure 3: unpruned 4-ary tree와 pruned Logits Tree를 비교한 예시

이 도식은 RACER가 후보를 어떻게 줄이는지 구조적으로 보여 준다. 왼쪽은 21개 노드를 가진 완전한 4-ary tree이고, 오른쪽은 같은 예산을 더 유망한 branch에 집중하도록 자른 pruned tree다. 빨간 경로는 실제로 선택될 수 있는 후보 예시를 뜻한다. 논문의 주장은 명확하다. speculative decoding에서 중요한 것은 “더 많은 노드”가 아니라, 검증을 통과할 가능성이 높은 노드를 예산 안에서 어떻게 배치하느냐다.

• copy-logit은 동일 token의 과거 이후 logits를 재사용해 sharper한 분포를 만든다.
• rank-1 집중과 85th percentile 9라는 결과는 search breadth를 무작정 넓힐 필요가 없음을 시사한다.
• BFS pruning은 상단 branch에 예산을 집중해 verification 대비 효율을 높인다.
• training-free라는 제약 안에서도 분포 모양을 잘 활용하면 draft 품질을 꽤 끌어올릴 수 있다.

3.2 Retrieval Tree with LRU Eviction: AC automaton을 디코딩 캐시로 쓰기

RACER의 두 번째 축은 Retrieval Tree다. 논문은 suffix array나 suffix automaton 같은 고전적 문자열 인덱스가 substring matching에는 강하지만, context 길이에 비례해 커지고 obsolete state를 버리기 어렵다는 점을 지적한다. 언어모델 디코딩에서는 substring 분포가 long-tail을 따르기 때문에, 한 번 잠깐 등장하고 다시는 쓰이지 않는 n-gram 상태를 계속 보존하는 것은 비효율적이다. 저자들이 Aho–Corasick(AC) automaton을 택한 이유는 이 구조가 trie의 prefix 공유와 automaton의 빠른 fallback을 함께 제공하면서도, 동적 갱신 시 failure link를 활용해 match 다양성을 확보하기 쉽기 때문이다.

핵심 구현 포인트는 LRU leaf eviction이다. RACER는 새로운 n-gram이 들어올 때 기존 transition을 따라갈 수 있으면 그대로 재사용하고, 없으면 비어 있는 slot을 쓰거나 가장 오래 쓰이지 않은 leaf node를 재활용한다. 이때 어떤 state가 직접 transition으로 방문되든, failure link를 따라 fallback되든 모두 “touch”된 것으로 처리한다. 더 나아가 failure fallback 과정에서 거친 prefix ancestor들도 함께 최근 사용 상태로 갱신한다. 이렇게 하면 자주 재사용되는 prefix는 자연스럽게 살아남고, tail에 위치한 희귀 leaf만 정리된다.

Figure 4: AC automaton 위에 LRU eviction을 얹어 드물게 쓰이는 leaf를 재활용하는 과정

Figure 4는 retrieval 쪽 설계 철학을 가장 잘 드러낸다. 검은 실선은 trie transition, 빨간 점선은 failure link, 진한 초록은 최근 사용된 state를 뜻한다. 새로운 2-gram이 들어왔는데 용량이 꽉 찼다면 가장 오래된 leaf를 비우고 그 자리에 새 state를 넣는다. 중요한 점은 internal prefix node를 함부로 날리지 않는다는 것이다. 논문은 prefix가 더 자주 재사용되고, failure fallback에서도 repeatedly touched 되므로 더 높은 생존 가치를 갖는다고 본다. 즉 RACER의 retrieval 구조는 “모든 과거를 기억하는 메모리”가 아니라, 최근성과 prefix 가치가 높은 패턴만 남기는 cache-like automaton이다.

retrieval expansion 규칙도 단순한 longest match가 아니다. RACER는 match depth가 2 이상인 border states를 모두 모으고, 각 border 아래 sub-trie에서 이어지는 continuation을 수집한 뒤, 그것들을 합쳐 전역적으로 가장 빈도가 높은 child state를 선택한다. 이 방식은 특정 한 매치에만 모든 희망을 거는 REST류 접근보다 더 유연하다. 여러 border에서 나온 후보를 frequency 기준으로 pool하기 때문에, retrieval branch가 sparse하더라도 다양한 구조적 힌트를 logits branch에 넘겨줄 수 있다.

논문이 기본 설정으로 사용하는 retrieval 하이퍼파라미터는 node capacity 10,000, n-gram depth 10이다. 직관적으로는 context에서 길이 1에서 9까지의 key를 유연하게 매치하고, 그 다음 value sequence를 retrieval candidate로 삼는다. 저자들은 이 구조의 공간 복잡도를 automaton 크기에 선형적인 $\mathcal{O}(|\mathcal{A}|)$로 설명하면서, 실제 실험 범위에서는 10K 수준이 충분히 가볍다고 말한다. 이 부분은 뒤의 robustness 실험에서도 다시 확인되는데, node capacity를 과도하게 키우지 않아도 성능이 안정적이라는 점이 중요하다.

Figure 5: Aho–Corasick automaton의 상태와 failure link가 어떻게 연결되는지 보여 주는 예시

이 그림은 AC automaton이 일반 trie보다 왜 나은지 설명해 준다. 노드는 prefix state를, 빨간 link는 mismatch가 났을 때 돌아갈 대체 prefix를 나타낸다. RACER는 이 fallback 경로 덕분에 단순 exact trie보다 더 유연하게 “가깝게 맞는 패턴”을 계속 추적할 수 있다. 다시 말해 retrieval이 실패하더라도 완전히 처음부터 다시 시작하는 것이 아니라, 공유 prefix를 보존한 채 다음 가능한 border를 찾는 구조를 갖는다.

• AC automaton은 prefix 공유와 failure fallback을 동시에 제공한다.
• LRU leaf eviction은 메모리 사용량을 제한하면서 최근에 유효했던 패턴을 남긴다.
• border pooling은 여러 match 지점을 합쳐 retrieval 후보를 더 다양하게 만든다.
• 10K nodes / n=10 설정은 충분한 match 다양성과 제한된 오버헤드 사이의 균형점으로 제시된다.

3.3 Integration Strategy: retrieval이 먼저 모양을 잡고 logits가 남은 예산을 채운다

RACER의 마지막 축은 integration strategy다. 논문은 고정 speculative capacity $C$가 있을 때 retrieval candidate를 먼저 만들고, 남은 슬롯을 Logits Tree가 breadth-first expansion으로 채우는 방식을 택한다. 표면적으로는 단순 우선순위처럼 보이지만, 의미는 더 깊다. retrieval branch는 sparse하지만 구조적으로 믿을 만한 후보를 제공하므로, 이 후보를 먼저 꽂아 넣고 나머지 공간을 logits branch가 채우게 하면 draft tree 전체가 더 날카로워진다는 것이다. retrieval이 “적지만 믿을 만한 축”을 만들고, logits가 그 축 주변을 부드럽게 확장하는 그림이다.

중요한 것은 논문이 Half나 Hard fallback 같은 대체 결합법도 직접 실험했다는 점이다. Half는 retrieval과 logits에 예산을 반반 고정 배분하고, Hard는 retrieval이 안 될 때만 logits로 넘어가는 식의 더 단단한 전환 전략이다. 그러나 저자들은 둘 다 손해를 본다고 보고한다. Half는 retrieval이 sparse한 step에서도 불필요하게 예산을 묶어 두고, Hard는 둘의 상보성을 실제 트리 내부에서 충분히 이용하지 못한다. 반면 Merge는 retrieval과 logits 후보를 trie 기반 union으로 묶어 가장 높은 MAT와 speedup을 달성한다.

Figure 6: next token을 받은 뒤 AC automaton과 Logits Tree가 함께 draft tree를 구성하는 RACER 전체 흐름

Figure 6은 RACER가 실제 디코딩 step에서 어떻게 움직이는지 보여 준다. 먼저 next token이 들어오면 AC automaton이 border node를 찾고 retrieval candidate를 제안한다. retrieval이 draft capacity를 다 채우지 못하면 남는 슬롯을 Logits Tree가 채운다. 그 뒤 두 후보 집합을 trie union으로 합쳐 target model이 한 번에 검증한다. 검증을 통과한 n-gram은 다시 automaton에 삽입되고, 새로 생성된 logits로 adjacency matrix도 갱신된다. 즉 RACER는 단발성 초안기가 아니라, 검증된 결과가 즉시 다음 retrieval과 logits 상태로 환류되는 순환 구조다.

이 설계가 의미하는 바는 명확하다. retrieval은 단순히 과거 반복을 복사하는 보조 장치가 아니라, logits가 어떤 방향으로 더 넓게 탐색해야 하는지를 조용히 정렬해 주는 구조적 prior다. 반대로 logits는 retrieval이 아무것도 못 찾는 순간에도 디코딩을 멈추지 않게 해 주는 연속성 보장 장치다. RACER가 training-free이면서도 일관된 속도 향상을 보여 준 배경은 결국 이 두 역할 분담이 잘 맞아떨어졌기 때문이라고 읽을 수 있다.

4. 실험 설정: 다양한 모델 계열과 태스크에서 plug-and-play 특성을 검증하기

4.1 데이터셋 및 벤치마크: 일반 지시, 코드, 중국어 수학, RAG를 함께 본 이유

논문은 세 가지 मुख्य 벤치마크를 중심으로 실험을 구성한다. 첫째 Spec-Bench는 multi-turn conversation, translation, summarization, question answering, mathematical reasoning, retrieval-augmented generation(RAG)까지 포함하는 범용 벤치마크다. 둘째 HumanEval은 함수 구현형 코드 생성 능력을 점검한다. 셋째 MGSM-ZH는 GSM8K의 중국어 버전으로, reasoning model이 비영어 환경에서 얼마나 안정적으로 speculative decoding 이득을 얻는지 보여 준다. 이 조합은 “일반 대화형 모델”, “코드 생성”, “수학 추론”, “RAG”라는 서로 다른 출력 패턴을 한 프레임에서 비교하게 해 준다.

특히 Spec-Bench 안에 RAG task가 별도 축으로 들어 있다는 점이 RACER에게 중요하다. retrieval branch의 기여는 단순한 반복 텍스트보다, 구조적 단서가 있는 장문 응답에서 더 잘 드러날 수 있기 때문이다. 저자들은 reasoning model인 OpenPangu와 Qwen3가 일반 instruct model보다 더 긴 출력을 생성하는 경향이 있다는 점도 함께 활용한다. 출력이 길어질수록 speculative decoding의 잠재 이득이 커지므로, 서로 다른 모델 family에서 speedup이 어떻게 달라지는지 보는 것이 논문의 핵심 메시지와 직결된다.

• Spec-Bench: MT, Trans, Sum, QA, Math, RAG 여섯 축
• HumanEval: 반복 구조와 정답 코드 패턴이 많은 코드 생성 과제
• MGSM-ZH: 중국어 수학 추론으로 multilingual reasoning robustness 확인
• Appendix reasoning set: GSM8K, AIME, MATH로 EAGLE-3 비교 보강

4.2 구현 세부사항: 64 draft budget, top-k 8, 10K retrieval nodes

기본 디코딩 설정은 batch size 1, maximum output length 1024, 그리고 prior work와 맞춘 greedy decoding 중심이다. RACER의 기본 하이퍼파라미터는 Logits Tree의 최대 breadth 8, Retrieval Tree의 node capacity 10,000, n-gram depth 10, 그리고 한 step에서 처리하는 전체 draft size 64다. 이 숫자들은 모두 뒤의 robustness 섹션에서 다시 흔들어 보지만, 본문 기본 실험에서는 이 설정을 공통 default로 둔다.

하드웨어도 모델 규모에 맞춰 나뉜다. 7B/8B급은 NVIDIA RTX 4090 24GB + CPU 20 cores에서, 13B 이상은 NVIDIA A800 80GB + CPU 64 cores에서 돌린다. 소프트웨어는 PyTorch와 HuggingFace Transformers 기반이며, Vicuna 실험에는 Transformers 4.37.1, LLaMA3.1/OpenPangu/Qwen3 실험에는 4.52.3을 사용한다. 중요한 것은 논문이 여기서 별도 quantization이나 specialized kernel을 붙이지 않는다는 점이다. 저자들은 가속 이득이 시스템 트릭이 아니라 speculative mechanism 자체에서 나온다는 점을 보여 주기 위해 비교 조건을 최대한 단순하게 유지한다.

또 하나 눈여겨볼 부분은 prompt template이다. Vicuna는 고유 chat template을, 다른 모델은 공통 “You are a helpful assistant” 계열 시스템 프롬프트를 쓴다. HumanEval의 경우에는 “Implement the following code” 형태로 맞춰 입력한다. 이는 RACER가 task 특화 트릭이 아니라 model family마다 이미 쓰고 있는 표준 프롬프트 위에 올라가는 방법이라는 점을 강조한다. 즉 deployment 입장에서 보면 기존 serving stack을 크게 바꾸지 않고도 얹을 수 있어야 한다는 조건을 실험 설계 자체가 반영하고 있다.

4.3 베이스라인: retrieval-only, logits-involved, model-based를 모두 비교

논문이 비교하는 베이스라인은 세 그룹으로 나뉜다. PLD와 REST는 retrieval-based, Token Recycling(TR)과 LogitSpec은 logits-involved model-free, EAGLE-3는 model-based state-of-the-art다. 이 구성은 매우 중요하다. RACER는 training-free라는 정체성을 유지하면서도, 단순 retrieval-only baseline을 넘는 것에 만족하지 않고, 같은 model-free 계열인 TR/LogitSpec는 물론 training 기반 강자 EAGLE-3와도 speedup을 겨룬다.

• PLD: 과거 n-gram과 그 뒤 m-gram을 직렬 key-value로 저장하는 단순 retrieval
• REST: suffix array 기반 longest suffix match를 trie 확장으로 연결
• TR: token logits에서 top-k adjacency matrix를 유지해 static tree template를 구성
• LogitSpec: 마지막 step logits의 top-k에서 첫 draft를 뽑고 retrieval을 보조적으로 추가
• EAGLE-3: 저비용 draft model을 따로 두는 model-based 접근

이 비교 설계 덕분에 RACER의 위치가 선명해진다. retrieval-only보다 강한 것은 “retrieval을 logits와 결합했기 때문”이고, TR보다 강한 것은 “top-k logits를 더 구조적으로 배치했기 때문”이며, EAGLE-3보다 speedup이 높은 경우는 “추가 draft model 비용이 없기 때문”이라고 해석할 수 있다. 다시 말해 RACER의 공헌은 단순히 평균 점수 하나를 높인 것이 아니라, training-free 방법이 어느 구간에서 model-based 방법을 이길 수 있는지 경계를 재정의한 것에 있다.

5. 주요 실험 결과: training-free인데도 모델 계열 전반에서 2배 안팎의 속도 향상

5.1 Vicuna 7B·13B: instruct 계열에서 TR과 LogitSpec을 꾸준히 앞선다

먼저 Vicuna 7B와 13B를 보면 RACER의 기본 그림이 가장 잘 드러난다. 아래 표에서 볼 수 있듯 RACER는 Spec-Bench, HumanEval, MGSM-ZH 세 축 모두에서 가장 높은 평균 MAT와 speedup을 기록한다. Vicuna 7B에서는 평균 MAT 3.27, speedup 2.42배, Vicuna 13B에서는 MAT 3.23, speedup 2.50배다. 같은 model-free 계열인 TR이 각각 2.18배, 2.10배인 점을 감안하면, RACER의 결합 전략은 단순 top-k 재활용보다 실제 서비스 속도에서 더 큰 이득을 준다.

모델	방법	Spec-Bench MAT / 속도	HumanEval MAT / 속도	MGSM-ZH MAT / 속도	평균 MAT / 속도
Vicuna 7B	PLD	1.71 / 1.50배	1.58 / 1.40배	2.57 / 2.27배	1.95 / 1.87배
	REST	1.82 / 1.45배	2.06 / 1.71배	1.29 / 1.06배	1.72 / 1.41배
	LogitSpec	2.34 / 1.77배	2.22 / 1.66배	3.55 / 2.67배	2.70 / 2.03배
	TR	2.76 / 2.06배	2.83 / 2.17배	3.00 / 2.30배	2.86 / 2.18배
	RACER	3.00 / 2.21배	3.11 / 2.29배	3.71 / 2.77배	3.27 / 2.42배
Vicuna 13B	PLD	1.65 / 1.41배	1.59 / 1.43배	2.45 / 2.11배	1.90 / 1.65배
	REST	1.82 / 1.44배	2.07 / 1.71배	1.31 / 1.07배	1.73 / 1.41배
	LogitSpec	2.32 / 1.73배	2.23 / 1.77배	3.44 / 2.72배	2.66 / 2.07배
	TR	2.79 / 1.99배	2.83 / 2.08배	3.05 / 2.22배	2.89 / 2.10배
	RACER	2.95 / 2.25배	3.09 / 2.42배	3.64 / 2.83배	3.23 / 2.50배

표를 보면 retrieval-only 계열인 PLD, REST는 대체로 1.4배 안팎에 머무르고, logits를 본격적으로 쓰는 LogitSpec과 TR이 2배 근처까지 올라간다. 하지만 RACER는 같은 training-free 범주 안에서 세 태스크 모두를 동시에 끌어올린다. 특히 MGSM-ZH에서 Vicuna 7B 기준 3.71 MAT, 2.77배 speedup이 나온다는 점은, retrieval이 reasoning token 흐름에 구조적 보조축을 제공할 때 이득이 꽤 크다는 뜻이다. 단순히 다음 토큰 하나를 더 잘 맞히는 것이 아니라, 몇 토큰 연속으로 accepted span을 길게 만드는 쪽에서 차이가 벌어진다.

또 하나 흥미로운 점은 모델이 커질수록 RACER의 advantage가 유지된다는 것이다. TR은 Vicuna 7B에서는 강하지만 33B로 가면 speedup이 1.99배로 떨어진다. 반면 RACER는 13B에서 2.50배, 33B에서 2.52배로 오히려 안정적이다. 이는 RACER의 draft generation 비용이 model size 증가에 덜 민감하다는 뜻이며, 논문이 강조하는 “low overhead model-free drafting”의 설득력을 뒷받침한다.

5.2 Vicuna 33B와 LLaMA3.1 8B: 규모가 커져도 end-to-end speedup이 쉽게 무너지지 않는다

더 큰 instruct model이나 다른 family로 넘어가면 RACER의 의미가 더 뚜렷해진다. Vicuna 33B에서는 평균 speedup이 2.52배로, LogitSpec의 2.03배와 TR의 1.99배를 넘는다. LLaMA3.1 8B에서는 model-based 강자인 EAGLE-3가 평균 MAT 3.24로 아주 조금 높지만, speedup은 2.21배에 그친다. 반면 RACER는 평균 MAT 3.12로 근접하면서도 2.72배 speedup을 기록한다. MAT 하나만 보면 EAGLE-3가 더 좋아 보일 수 있지만, 실제 서비스 지표인 속도에서는 RACER가 앞서는 셈이다.

모델	방법	Spec-Bench MAT / 속도	HumanEval MAT / 속도	MGSM-ZH MAT / 속도	평균 MAT / 속도
Vicuna 33B	PLD	1.33 / 1.03배	1.64 / 1.48배	2.18 / 1.97배	1.72 / 1.49배
	REST	1.81 / 1.54배	1.98 / 1.72배	1.32 / 1.17배	1.70 / 1.48배
	LogitSpec	2.32 / 1.73배	2.35 / 1.92배	2.96 / 2.44배	2.54 / 2.03배
	TR	2.63 / 1.83배	2.79 / 2.05배	2.83 / 2.10배	2.75 / 1.99배
	RACER	2.74 / 2.20배	3.16 / 2.58배	3.36 / 2.77배	3.09 / 2.52배
LLaMA3.1 8B	EAGLE-3	3.76 / 2.51배	4.41 / 3.06배	1.54 / 1.06배	3.24 / 2.21배
	RACER	2.82 / 2.41배	3.22 / 2.87배	3.33 / 2.89배	3.12 / 2.72배

LLaMA3.1 8B에서 특히 눈에 띄는 대목은 MGSM-ZH다. EAGLE-3는 MAT 1.54, speedup 1.06배로 거의 가속 효과가 사라지지만, RACER는 3.33 MAT와 2.89배 속도를 낸다. 논문은 이를 draft model의 training distribution과 target task 분포가 어긋날 때 model-based 접근이 흔들릴 수 있다는 사례로 읽는다. 즉 EAGLE-3는 높은 MAT를 만들 수 있지만, 그 이득이 언제나 end-to-end latency 개선으로 이어지지는 않는다. RACER는 훈련된 draft model이 없기 때문에 이런 distribution mismatch를 더 직접적으로 피한다.

여기서 중요한 해석은 MAT와 speedup의 분리다. 높은 MAT가 늘 높은 속도를 보장하지는 않는다. draft generation이 무거우면 accepted token이 많아도 전체 시간은 늘어날 수 있다. RACER는 바로 이 지점에서 강하다. 초안 품질을 model-based 수준으로 완전히 맞추지는 못하더라도, 초안 생성 비용이 워낙 가볍기 때문에 실제 속도 지표에서 더 유리한 영역이 생긴다. 논문이 내세우는 “scalable, plug-and-play solution”이라는 문구는 이 수치에서 가장 직접적으로 설득된다.

5.3 OpenPangu와 Qwen3: reasoning model에서도 평균 2배 이상 가속을 유지한다

reasoning model 계열에서도 RACER의 결과는 안정적이다. OpenPangu 7B에서는 PLD 1.35배 대비 RACER가 2.12배, Qwen3 8B·14B·32B에서는 각각 2.21배, 2.27배, 2.18배의 평균 speedup을 기록한다. 특히 Qwen3 14B에서는 EAGLE-3보다 MAT는 조금 낮지만 모든 태스크 평균 speedup이 더 높다. 논문은 이 패턴을 “model-free decoding의 constant-cost drafting”이 큰 모델에서 더 잘 버티는 사례로 해석한다.

모델	방법	Spec-Bench MAT / 속도	HumanEval MAT / 속도	MGSM-ZH MAT / 속도	평균 MAT / 속도
OpenPangu 7B	PLD	1.48 / 1.37배	1.44 / 1.27배	1.53 / 1.41배	1.47 / 1.35배
	RACER	2.47 / 1.99배	2.65 / 2.12배	2.77 / 2.26배	2.63 / 2.12배
Qwen3 8B	PLD	1.52 / 1.35배	1.52 / 1.41배	1.69 / 1.52배	1.58 / 1.43배
	EAGLE-3	3.46 / 2.14배	3.84 / 2.44배	1.41 / 0.86배	2.90 / 1.81배
	RACER	2.73 / 2.13배	2.79 / 2.24배	2.95 / 2.26배	2.82 / 2.21배
Qwen3 14B	PLD	1.45 / 1.34배	1.43 / 1.27배	1.59 / 1.49배	1.49 / 1.37배
	EAGLE-3	2.72 / 1.87배	3.03 / 2.05배	1.56 / 1.12배	2.44 / 1.68배
	RACER	2.67 / 2.23배	2.77 / 2.29배	2.88 / 2.30배	2.77 / 2.27배
Qwen3 32B	PLD	1.45 / 1.34배	1.34 / 1.23배	1.56 / 1.46배	1.45 / 1.34배
	EAGLE-3	2.88 / 2.12배	2.97 / 2.17배	1.60 / 1.18배	2.48 / 1.82배
	RACER	2.66 / 2.17배	2.55 / 2.08배	2.78 / 2.28배	2.66 / 2.18배

여기서 특히 중요한 수치는 MGSM-ZH다. Qwen3 8B, 14B, 32B에서 RACER는 각각 2.26배, 2.30배, 2.28배 속도를 기록하고, EAGLE-3는 0.86배, 1.12배, 1.18배에 머문다. reasoning model에서 출력 길이가 길어질수록 verification 비용이 커지는데, model-based draft의 추가 비용이 그만큼 더 무겁게 작동하기 때문이다. RACER는 MAT가 다소 낮더라도 초안 생성이 거의 상수 비용에 가까워, long reasoning chain에서 오히려 더 강한 speedup을 유지한다.

논문은 appendix에서 GSM8K, AIME, MATH까지 추가 비교를 제시하는데, 여기서도 같은 패턴이 반복된다. EAGLE-3는 MAT에서 높지만, Qwen3 14B와 32B에서는 RACER가 speedup 면에서 경쟁하거나 더 높다. 이는 RACER의 강점이 “더 똑똑한 next-token 예측기”라기보다, 낮은 추가 오버헤드로 충분히 좋은 speculative draft를 만드는 시스템 구조에 있다는 뜻이다.

6. 추가 분석 및 Ablation Study: RACER가 왜 이 숫자를 만드는지 해부하기

6.1 logits와 retrieval은 둘 다 필요하지만, 지배적 기여는 logits 쪽이 더 크다

아래 ablation 표는 RACER의 핵심 메시지를 가장 직접적으로 보여 준다. logits를 제거하면 성능이 크게 무너지고, retrieval을 제거하면 손실은 더 작지만 여전히 의미 있게 남는다. 예를 들어 Vicuna 7B에서 full RACER는 Spec-Bench 2.21배 속도지만, w/o logits는 1.43배, w/o retrieval은 2.01배다. 즉 logits branch가 기본 엔진이고, retrieval은 그 엔진의 accepted span을 더 길게 만드는 구조적 가속기라고 해석할 수 있다.

모델	설정	Spec-Bench MAT / 속도	HumanEval MAT / 속도	MGSM-ZH MAT / 속도
Vicuna 7B	w/o logits	1.59 / 1.43배	1.67 / 1.52배	2.39 / 2.11배
	w/o retrieval	2.72 / 2.01배	2.68 / 2.04배	2.95 / 2.23배
	RACER	3.00 / 2.21배	3.11 / 2.29배	3.71 / 2.77배
Vicuna 13B	w/o logits	1.56 / 1.38배	1.65 / 1.43배	2.29 / 1.95배
	w/o retrieval	2.68 / 2.06배	2.70 / 2.14배	2.98 / 2.34배
	RACER	2.95 / 2.25배	3.09 / 2.42배	3.64 / 2.83배
Vicuna 33B	w/o logits	1.46 / 1.38배	1.76 / 1.66배	2.10 / 1.97배
	w/o retrieval	2.55 / 2.05배	2.66 / 2.19배	2.74 / 2.27배
	RACER	2.74 / 2.20배	3.16 / 2.58배	3.36 / 2.77배

이 표는 retrieval의 역할을 과장해서도, 과소평가해서도 안 된다는 점을 보여 준다. logits가 없으면 각 태스크에서 속도 하락이 0.66배에서 0.99배까지 크게 발생한다. 반면 retrieval이 없으면 손실은 0.15배에서 0.59배 수준으로 더 작다. 따라서 RACER의 실체는 “retrieval이 다 했다”가 아니라, 강한 logits 엔진 위에 retrieval을 얹어 accepted length 분포를 보정한 구조라고 이해하는 편이 정확하다.

Figure 7: logits-only, retrieval-only, RACER에서 accepted token length 분포가 어떻게 달라지는지 비교

Figure 7은 이 상보성을 분포 수준에서 보여 준다. retrieval-only는 대부분 accepted length가 1에 몰리지만, 드물게 9 같은 긴 match가 튀어나온다. logits-only는 2 근처에 질서 있게 모여 있지만 극단적으로 길게 가는 경우는 적다. RACER는 이 둘을 합쳐, 전반적으로 2 이상을 안정적으로 유지하면서도 때때로 retrieval이 만든 긴 span을 확보한다. 이 분포 모양 자체가 RACER의 성격을 가장 잘 설명한다.

6.2 retrieval-only와 merge 전략: 단순 결합보다 실제 트리 합성이 더 낫다

논문은 retrieval component만 따로 떼어도 의미 있는 성능이 나온다는 점을 확인한다. RTX 3090 환경에서 RACER retrieval-only 변형은 Spec-Bench, HumanEval, MGSM-ZH 전부에서 PLD, REST, SAMD를 앞선다. 특히 MGSM-ZH에서 3.32 MAT, 2.61배 속도를 기록하는데, 이는 retrieval 구조 자체가 꽤 강력하다는 뜻이다. 다만 full RACER에 비하면 여전히 logits branch가 주는 안정적 이득이 빠져 있으므로, 평균적으로는 완성형보다 낮다.

Vicuna 7B on RTX 3090	Spec-Bench MAT / 속도	HumanEval MAT / 속도	MGSM-ZH MAT / 속도	평균 MAT / 속도
PLD	1.72 / 1.57배	1.57 / 1.45배	2.57 / 2.35배	1.95 / 1.79배
REST	1.82 / 1.37배	2.06 / 1.65배	1.29 / 1.06배	1.49 / 1.36배
SAMD	1.70 / 1.65배	1.59 / 1.54배	2.65 / 2.49배	1.98 / 1.89배
RACER retrieval-only	2.02 / 1.69배	2.25 / 1.86배	3.32 / 2.61배	2.53 / 2.05배

이 결과는 RACER의 retrieval 모듈이 단순한 부품이 아니라는 점을 보여 준다. suffix array나 정적 pattern retrieval보다 동적 AC automaton + LRU update 조합이 실제 디코딩 상황에 더 잘 맞는다는 해석이 가능하다. 하지만 retrieval-only가 full RACER를 넘지 못하는 이유도 여기서 동시에 드러난다. match가 있는 구간에서는 길게 가속하지만, match가 없는 구간에서 연속성을 보장해 줄 엔진이 부족하다.

integration strategy 비교도 같은 메시지를 준다. Half는 예산을 반반 쪼개기 때문에 retrieval이 sparse한 순간에도 예산 낭비가 생기고, Hard는 retrieval 실패 후 logits로 넘어가는 단계적 전환이라 둘의 상보성을 충분히 못 쓴다. 반면 Merge는 retrieval이 확보한 구조적 후보와 logits가 만든 유연한 후보를 실제 같은 tree 안에서 합쳐 쓴다.

통합 전략	MAT	속도
Merge (RACER)	3.00	2.18배
Half	2.69	1.97배
Hard	2.77	2.11배

숫자 차이는 크지 않아 보일 수 있지만, speculative decoding에서는 0.07배에서 0.21배의 차이도 의미가 크다. 왜냐하면 이 차이가 전체 step 수, verification 호출 수, accepted span 길이에 연쇄적으로 영향을 주기 때문이다. 결국 RACER의 핵심은 retrieval과 logits를 “둘 다 쓴다”에 있지 않고, 둘이 실제로 같은 draft tree 안에서 서로를 보정하게 만든다는 데 있다.

6.3 latency breakdown, 태스크별 속도, 하이퍼파라미터 안정성

논문은 RACER가 정말 시스템적으로 가벼운지 보기 위해 end-to-end latency를 단계별로 분해한다. 그 결과 가장 큰 비중은 당연히 model forward가 차지하고, Draft Generation, Logits Update, Retrieval Update는 상대적으로 매우 작다. 이 결과는 RACER가 “조금 더 좋은 초안을 위해 너무 많은 주변 계산을 한다”는 비판을 어느 정도 반박한다. retrieval automaton 갱신과 logits adjacency 갱신이 실제 wall-clock time에서 큰 비중을 먹지 않기 때문이다.

Figure 8: Draft generation, model forward, logits update, retrieval update로 나눈 end-to-end latency 분해

Figure 8은 RACER의 실용성을 잘 보여 준다. 모델 파라미터를 실제로 통과시키는 forward 비용이 대부분을 차지하고, retrieval/logits 갱신은 그 옆의 작은 조각에 머문다. 즉 RACER는 모델을 더 많이 돌려서 가속하는 방식이 아니라, 비싼 target forward 호출 횟수를 줄이기 위해 값싼 구조 업데이트를 넣는 방식이다. speculative decoding이 시스템적으로 유효하려면 꼭 필요한 조건인데, 논문은 그 조건을 꽤 깔끔하게 만족한다.

저자들은 이 결론을 단순 평균 수치가 아니라 토큰 수준 case study로도 보강한다. HumanEval의 첫 예제를 따라가 보면 retrieval-only는 대부분 accepted length가 1에 머물지만, 드물게 강한 exact match가 생기면 9까지 길게 튄다. 반대로 logits-only는 대부분 2에서 5 사이를 촘촘하게 형성한다. RACER는 이 둘을 결합해 평균 accepted length를 높이면서도, 긴 retrieval match가 들어올 때 그 이득을 놓치지 않는다. 즉 평균 MAT 향상은 우연한 한두 번의 긴 매치가 아니라, 짧고 안정적인 logits acceptance와 드문 but 긴 retrieval acceptance가 함께 쌓인 결과다.

Figure 9: HumanEval 사례에서 step별 accepted token length가 어떻게 분포하는지 보여 주는 토큰 정렬 시각화

Figure 9는 RACER가 왜 “평균적으로 더 많이 전진한다”고 말할 수 있는지 설명한다. retrieval-only는 대부분 짧게 전진하다가 특정 반복 구간에서만 큰 피크를 만들고, logits-only는 피크는 작지만 분포가 고르게 깔린다. RACER는 두 분포를 중첩해, 기본적으로는 2 이상을 자주 확보하고 필요할 때는 retrieval이 끌어오는 긴 match까지 가져간다. 논문이 주장하는 hybrid draft의 효과가 추상적 설명이 아니라 실제 decoding trace에서 그대로 보인다는 점이 중요하다.

본문 case study가 특히 흥미로운 이유는 retrieval과 logits가 서로 다른 실패 양상을 보인다는 사실을 보여 주기 때문이다. 예를 들어 logits branch는 system prompt에서 자주 보인 형태를 따라 꽤 그럴듯한 토큰을 내놓지만, 다음 ground-truth가 조금만 비틀리면 이후 후보가 연쇄적으로 탈락한다. 반면 retrieval branch는 충분한 border가 잡히지 않으면 아예 아무 draft도 못 만들지만, 잡히는 순간에는 긴 연속 수용이 가능하다. RACER는 이 두 실패 모드가 동시에 터지는 빈도를 줄이는 구조라고 이해하면 된다.

task-level speedup을 보면 RACER는 어느 태스크가 더 retrieval 친화적인지도 드러낸다. Vicuna 7B에서 MT 2.23배, Summarization 2.61배, RAG 2.12배가 나오고, Qwen3 8B에서는 Translation 2.69배, Summarization 2.35배, QA 2.41배, Math 2.72배가 나온다. 즉 특정 한 task에만 몰빵한 방법이 아니라, 반복 구조가 있는 장문 생성, reasoning token이 길게 이어지는 작업, retrieval 단서가 있는 응답에서 두루 강하다.

모델 / 방법	MT	Trans	Sum	QA	Math	RAG	MAT	평균 속도
Vicuna 7B / TR	2.19	1.84	2.02	2.02	2.58	1.85	2.76	2.15배
Vicuna 7B / RACER	2.23	1.61	2.61	1.82	2.46	2.12	3.01	2.22배
Qwen3 8B / EAGLE-3	2.43	2.07	2.12	2.36	2.63	2.45	3.47	2.37배
Qwen3 8B / RACER	2.41	2.69	2.35	2.41	2.72	2.42	2.73	2.48배

또 하나 중요하게 볼 표는 sampling temperature와 model size ablation이다. 논문은 greedy에서만 잘 되는 방법이 아니라는 점을 보여 주려고, Vicuna 7B, OpenPangu 7B, Qwen3 8B에 대해 temperature를 바꿔도 성능이 크게 흔들리지 않음을 보고한다. Vicuna 7B의 평균 speedup은 greedy 2.21배에서 $T=1.0$일 때 2.29배로 오히려 약간 상승하고, OpenPangu와 Qwen3도 변화 폭이 작다. 예외적으로 OpenPangu 7B의 RAG task에서 2.15배에서 1.79배로 내려가는데, 논문은 이를 early-token stochasticity가 retrieval alignment를 더 민감하게 흔들기 때문으로 해석한다.

모델	온도	MT	Trans	Sum	QA	Math	RAG	MAT / 속도
Vicuna 7B	Greedy	2.21	1.65	2.54	1.82	2.45	2.09	3.00 / 2.21배
	T=0.5	2.19	1.62	2.56	1.96	2.64	2.16	3.05 / 2.25배
	T=1.0	2.30	1.74	2.52	1.90	2.55	2.34	3.03 / 2.29배
OpenPangu 7B	Greedy	1.89	2.27	1.96	1.73	2.20	2.15	2.47 / 1.99배
	T=0.5	1.87	2.16	1.90	1.70	2.14	1.79	2.51 / 1.91배
Qwen3 8B	Greedy	2.05	2.44	1.96	2.11	2.37	2.02	2.73 / 2.13배
	T=0.5	2.01	2.20	1.88	1.94	2.23	2.03	2.78 / 2.04배

model size ablation도 비슷하게 실용적이다. Qwen2.5 0.5B와 1.5B에서는 2.64배 속도, Qwen2.5 14B와 32B에서는 2.33배, 2.19배가 나온다. Qwen3 시리즈에서도 0.6B 2.55배, 1.7B 2.48배, 4B 2.53배, 8B 2.13배, 14B 2.23배, 32B 2.17배로 큰 붕괴 없이 유지된다. 모델이 커질수록 speedup이 약간 내려가는 건 자연스럽지만, 그 폭이 완만하다는 점이 중요하다.

모델 계열	모델	MAT	평균 속도
Qwen2.5	0.5B	3.30	2.64배
	1.5B	3.25	2.64배
	14B	2.64	2.33배
	32B	2.71	2.19배
Qwen3	0.6B	2.89	2.55배
	1.7B	2.78	2.48배
	4B	2.78	2.53배
	8B	2.73	2.13배
	14B	2.67	2.23배
	32B	2.66	2.17배

저자들은 이를 하이퍼파라미터 관점에서도 보강한다. draft size를 16에서 64까지 늘리면 MAT와 throughput이 개선되다가 그 이후 포화되고, retrieval node capacity는 10K~20K 정도에서 가장 좋은 균형을 보인다. 결국 RACER는 극단적으로 큰 retrieval buffer나 지나치게 넓은 top-k를 요구하지 않는다. 실전 관점에서는 이 점이 중요하다. serving 환경에서 메모리와 검증 비용을 감안해 보수적인 예산 안에서도 성능이 잘 나온다는 뜻이기 때문이다.

Figure 10: draft size, retrieval node capacity, n-gram depth, top-k breadth를 바꾸며 robustness를 본 ablation

Figure 10은 RACER의 설계가 특정 한 하이퍼파라미터 조합에만 의존하지 않는다는 점을 시각적으로 정리한다. draft size는 64 부근까지 올릴 때 이득이 크고, 그 이후로는 포화되거나 compute-bound 구간으로 들어가 gain이 완만해진다. retrieval node capacity는 2.5K에서 10K~20K로 늘릴 때 성능이 좋아지지만, 그 이후 큰 추가 이득은 없다. 즉 RACER는 “무조건 더 크게”가 아니라, 적당히 큰 draft와 적당히 큰 retrieval cache가 가장 실용적인 구조라는 결론을 준다.

이 부분은 실제 서빙 환경에서 꽤 중요한 함의를 가진다. 많은 가속 기법은 튜닝된 sweet spot을 벗어나면 성능이 급락하거나 메모리 사용량이 폭증하는데, RACER는 적어도 논문 범위 안에서는 완만하게 반응한다. 특히 node capacity를 크게 늘리지 않아도 되는 점은 production memory budget에 우호적이다. 다시 말해 RACER는 단순히 점수가 높다는 차원을 넘어, 운영자가 다룰 수 있는 범위 안에서 안정적으로 튜닝 가능한 방법이라는 장점이 있다.

6.4 Appendix reasoning 비교: EAGLE-3보다 MAT는 낮아도 speedup은 더 높아질 수 있다

appendix의 reasoning benchmark 비교는 RACER의 포지션을 더 분명하게 만든다. 저자들은 Qwen3 8B, 14B, 32B를 대상으로 GSM8K, AIME, MATH에서 EAGLE-3와 RACER를 직접 비교한다. 여기서 EAGLE-3는 세 태스크 모두에서 더 높은 MAT를 얻는 경우가 많다. 하지만 실제 speedup은 다르다. Qwen3 14B에서는 GSM8K 2.72배, AIME 2.64배, MATH 2.55배로 RACER가 모두 앞선다. Qwen3 32B에서도 GSM8K는 RACER 2.53배, EAGLE-3 2.51배로 거의 비슷하고, 평균 속도는 2.38배 대 2.42배로 근접하다. 즉 reasoning task에서는 “더 많은 토큰을 받아냈다”보다 “그 초안을 얼마나 싸게 만들었는가”가 실제 속도를 좌우한다.

모델	방법	GSM8K MAT / 속도	AIME MAT / 속도	MATH MAT / 속도	평균 MAT / 속도
Qwen3 8B	EAGLE-3	3.86 / 2.65배	3.44 / 2.44배	3.55 / 2.60배	3.62 / 2.56배
	RACER	3.01 / 2.68배	2.91 / 2.63배	2.88 / 2.58배	2.93 / 2.63배
Qwen3 14B	EAGLE-3	3.08 / 2.23배	3.05 / 2.24배	3.06 / 2.23배	3.06 / 2.23배
	RACER	2.95 / 2.72배	2.90 / 2.64배	2.87 / 2.55배	2.91 / 2.64배
Qwen3 32B	EAGLE-3	3.32 / 2.51배	3.26 / 2.34배	3.33 / 2.42배	3.30 / 2.42배
	RACER	2.87 / 2.53배	2.84 / 2.30배	2.82 / 2.32배	2.84 / 2.38배

이 표는 RACER의 강점이 왜 “저비용 초안”인지 다시 확인시켜 준다. EAGLE-3는 더 정교한 draft model 덕분에 더 많은 토큰을 미리 맞히지만, 그 draft를 계산하는 비용이 reasoning task에서 더 무겁게 작동한다. 반면 RACER는 copy-logit과 retrieval automaton이라는 가벼운 재활용 구조만으로 충분한 accepted span을 만들기 때문에, MAT가 조금 낮아도 speedup은 더 좋을 수 있다. 논문의 메시지를 한 줄로 요약하면, speculative decoding에서 좋은 초안은 반드시 비싼 초안일 필요가 없다는 것이다.

7. 한계점 및 향후 연구 방향: text-only 검증과 exact-match retrieval의 경계

논문이 스스로 인정하는 가장 분명한 한계는 멀티모달 태스크 미검증이다. RACER는 텍스트 디코딩을 전제로 설계됐고, 실제 실험도 모두 텍스트 기반 태스크에서만 수행됐다. 저자들은 vision/audio token을 retrieval 구조 안에 포함하는 방향을 future work로 언급한다. 이는 단순 확장 아이디어가 아니라, retrieval branch가 어떤 token granularity를 다뤄야 하는지 자체가 달라지는 문제다. 텍스트에서는 exact token reuse가 의미를 갖지만, 이미지 패치나 오디오 unit에서는 prefix와 continuation의 구조가 전혀 다를 수 있기 때문이다.

둘째 한계는 exact-match 성향의 retrieval이 여전히 남아 있다는 점이다. AC automaton과 failure link 덕분에 순수 trie보다 유연해지긴 했지만, 근본적으로 RACER의 retrieval branch는 surface token pattern의 반복성을 활용한다. 논문도 sampling temperature 실험에서 OpenPangu 7B의 RAG task가 더 민감하게 흔들리는 사례를 보여 준다. 이는 retrieval이 early-token variation에 민감할 수 있음을 뜻한다. 다시 말해 RACER는 retrieval을 logits와 결합해 약점을 줄였지만, retrieval 자체가 semantic paraphrase까지 흡수하는 구조로 바뀐 것은 아니다.

셋째는 평가 범위의 선택성이다. 논문은 Spec-Bench, HumanEval, MGSM-ZH, 그리고 appendix의 reasoning benchmarks로 폭넓게 비교하지만, 여전히 실제 production serving에서 마주치는 batch decoding, multi-request scheduling, long conversation memory drift 같은 변수는 본격적으로 다루지 않는다. RACER는 batch size 1 조건에서 특히 설득력이 강한데, 이 결과가 고부하 서빙에서도 그대로 유지되는지, 혹은 verification 단계가 새로운 병목으로 떠오르는지는 별도 시스템 실험이 필요하다.

여기에 더해 tokenizer 차이와 prompt formatting의 영향도 아직 충분히 해부되지는 않았다. RACER의 copy-logit은 “같은 token ID가 다시 나왔을 때 그 다음 logits를 재활용한다”는 발상에 기대는데, 이 구조는 tokenizer가 어떤 granularity로 토큰을 자르느냐에 따라 성능이 달라질 가능성이 있다. 영어 중심 tokenizer에서는 반복 구간이 잘 드러나더라도, 다른 언어에서는 같은 의미가 더 잘게 끊기거나 합쳐져 retrieval border와 copy-logit 연결이 약해질 수 있다. 논문이 MGSM-ZH에서 좋은 결과를 보인 것은 고무적이지만, 이것만으로 tokenizer 민감성이 충분히 해소됐다고 말하기는 어렵다.

• 멀티모달 확장: vision/audio token에 retrieval branch를 어떻게 정의할지 미지수
• semantic retrieval 부족: 현재 retrieval은 주로 exact token pattern을 활용
• 실서비스 변수: batch scheduling, 동시 요청, 긴 세션 누적 상태까지는 아직 직접 검증되지 않음
• 모델별 tokenizer 차이: copy-logit과 border match 효율이 tokenizer 특성에 의존할 가능성도 남아 있음

그럼에도 향후 연구 방향은 분명하다. 하나는 retrieval branch를 semantic-aware하게 바꾸는 것이고, 다른 하나는 model-based 방법과의 hybrid serving를 탐색하는 것이다. 논문 appendix의 EAGLE-3 비교는 이미 그 가능성을 암시한다. RACER는 low-overhead branch로, EAGLE-3류는 high-quality draft branch로 쓰고, 입력 특성이나 latency budget에 따라 adaptive routing을 붙일 수 있다면 practical serving stack의 선택지가 크게 넓어진다.

또 다른 방향은 serving loop 안에 online diagnostics를 넣는 것이다. RACER는 acceptance length, retrieval border depth, eviction 빈도, copy-logit 사용 비율 같은 내부 상태를 이미 계산한다. 그렇다면 이 값을 지표화해 step별 품질 감시 계층을 얹을 수 있다. 예컨대 retrieval contribution이 특정 프롬프트 유형에서 계속 낮게 나오면 retrieval budget을 줄이고 logits breadth를 늘리거나, 반대로 반복 패턴이 강한 코드 생성에서는 retrieval capacity를 키우는 식의 adaptive control로 이어질 수 있다. 논문 본문은 여기까지 가지 않지만, 실제 서비스로 연결한다면 가장 먼저 붙일 만한 확장이다.

8. 내 해석: retrieval을 평가에서 acceleration으로 옮겨 온 발상은 좋지만, surface match 의존은 아직 크다

내가 이 논문에서 가장 좋게 본 부분은 retrieval을 “정답 근거”가 아니라 “초안 구조 힌트”로 다시 쓴 점이다. 이 시각 전환 덕분에 RACER는 RAG 계열 논문과 speculative decoding 논문 사이를 독특하게 가로지른다. 다만 약점도 분명하다. 나는 이 논문이 retrieval branch의 기여를 꽤 잘 보여 주긴 했지만, 그 기여가 얼마나 surface repetition에 기대고 있는지를 더 직접적으로 분해하지는 못했다고 본다. CUE-R나 Query Coverage 계열 논의가 retrieval을 “무엇이 실제로 기여했는가”라는 관점에서 더 세밀하게 해부했던 것과 비교하면, RACER는 retrieval이 속도를 올렸다는 결과는 보여 주지만, 그 상승이 exact n-gram 재출현, 포맷 반복, reasoning boilerplate 중 무엇에서 왔는지는 깊게 나누지 않는다. 특히 text-only 실험에 한정돼 있기 때문에, retrieval branch가 진짜 구조 신호를 잡은 것인지 아니면 단순한 token surface reuse를 크게 활용한 것인지는 아직 더 검증할 여지가 있다.

내가 이걸 후속으로 확장한다면, 먼저 semantic-light retrieval layer를 AC automaton 앞에 얇게 붙여 보고 싶다. 예를 들어 exact token match가 아니라 phrase normalization, reasoning delimiter 압축, 혹은 tokenizer-independent chunk signature를 먼저 만들어 border 후보를 재정렬한 뒤, 그 결과를 지금의 merge 전략에 흘려 넣는 방식이다. 그러면 retrieval branch가 지금보다 paraphrase와 prompt variation에 덜 흔들릴 수 있다. 동시에 serving 관점에서는 acceptance length만이 아니라 retrieval contribution attribution을 함께 기록해, 어느 태스크에서 retrieval이 실제로 draft를 살렸는지 로그 단위로 보게 만들고 싶다. 그렇게 해야 RACER가 단순히 “대체로 빨라졌다”를 넘어, 어떤 입력에서 retrieval이 진짜 비용 대비 효과를 내는지 더 체계적으로 운영할 수 있다.

특히 이 논문이 내게 흥미로운 이유는 [[concepts/evidence-utility-in-rag|Evidence Utility in RAG]]와 [[concepts/query-coverage-in-retrieval|Query Coverage in Retrieval]]가 retrieval을 평가의 언어로 읽었던 흐름과 이어지기 때문이다. 이전 논의에서는 “이 evidence가 정답에 얼마나 기여했는가”, “이 검색 결과가 질문을 얼마나 완성했는가”가 핵심이었다면, RACER는 그 질문을 한 단계 옆으로 옮겨 “이 retrieval 신호가 다음 토큰 몇 개를 더 빨리 맞히게 만드는가”를 묻는다. 나는 이 전환이 꽤 중요하다고 본다. retrieval을 정확도 개선 모듈로만 보지 않고, 지연을 줄이는 구조적 prior로 읽기 시작하면 모델 서빙 최적화와 정보 접근 문제가 같은 테이블 위로 올라오기 때문이다.

실무 배치 관점에서도 RACER는 생각보다 현실적인 옵션이다. 추가 draft model이 없으니 배포 artifact가 늘지 않고, acceptance length와 retrieval border 같은 내부 상태를 그대로 로그로 남길 수 있어서 디버깅도 비교적 쉽다. 내가 실제 시스템에 넣는다면, 첫 단계는 모든 요청에 일괄 적용하기보다 긴 응답, 코드 생성, reasoning chain이 길어질 가능성이 큰 route에 한정해 shadow deployment를 돌려 볼 것 같다. 그 과정에서 task별 accepted length 분포와 retrieval contribution을 같이 모으면, RACER가 어떤 요청군에서 진짜 비용 절감 효과를 내는지 빠르게 분리해 낼 수 있다. 논문은 연구용 수치로 이 가능성을 보여 줬고, 남은 일은 이를 운영 지표와 연결하는 것이다.

9. 결론: training-free speculative decoding의 실용적 기준선을 한 단계 끌어올린 방법

RACER는 speculative decoding을 둘러싼 오래된 딜레마를 꽤 실용적으로 정리한다. retrieval-only는 길게 맞을 수 있지만 자주 못 맞고, logits-only는 자주 제안할 수 있지만 구조적 정합성이 약하다. 논문은 이 둘을 독립적 후보군으로 병렬 실행하는 대신, retrieval이 logits를 더 날카롭게 만들고 logits가 retrieval의 빈 구간을 메우는 하이브리드 draft tree를 구성한다. 그 결과 training-free 제약을 유지하면서도 Vicuna, LLaMA3.1, OpenPangu, Qwen3에 걸쳐 안정적인 2배 안팎 속도 향상을 보고한다.

더 중요한 것은 이 논문이 보여 준 판단 기준이다. speculative decoding에서 정말 봐야 할 것은 MAT만이 아니라 draft generation cost를 포함한 end-to-end speedup이며, retrieval과 logits는 서로 대체재가 아니라 상보재라는 점이다. RACER는 바로 이 두 사실을 실험 수치와 구조 설계로 보여 준다. 당장 멀티모달과 semantic retrieval까지 확장되지는 않았지만, training-free serving stack에서 “어디까지 가속할 수 있는가”라는 질문에 꽤 설득력 있는 답을 내놓은 논문이라고 정리할 수 있다.

또 한 가지 남는 메시지는 가속 기법의 평가 기준을 다시 세워야 한다는 점이다. 많은 논문이 acceptance 관련 내부 지표를 앞세우지만, RACER는 draft가 얼마나 자주 맞느냐보다 그 draft를 만드는 비용과 target model forward를 얼마나 줄였느냐가 더 중요하다는 사실을 수치로 보여 준다. 그래서 이 논문은 새로운 알고리즘 제안일 뿐 아니라, speculative decoding 연구를 MAT 중심에서 실제 wall-clock 중심으로 옮기는 사례로도 읽힌다. 앞으로 training-free 계열을 볼 때도, 높은 acceptance만이 아니라 low-overhead라는 조건을 함께 묶어 평가해야 한다는 점을 분명히 남긴다.

정리하면 RACER의 공헌은 retrieval과 logits를 “함께 쓰면 좋다” 수준에서 멈추지 않고, 둘이 언제 어떻게 서로의 빈칸을 메우는지까지 구조적으로 설명했다는 데 있다. copy-logit, AC automaton, LRU eviction, merge strategy는 각자 독립적인 트릭처럼 보이지만, 논문 전체를 읽고 나면 모두 같은 목적을 향한다. 즉 비싼 계산은 target model verification에만 남기고, 그 이전의 초안 단계는 가능한 한 가볍고 구조적으로 만들자는 것이다. 이 원칙이 유지되는 한, RACER 계열 아이디어는 앞으로도 다양한 서빙 스택에서 계속 변형되고 재사용될 가능성이 높다.

실제로 이 논문이 남기는 가장 큰 실무 교훈은, model-free acceleration을 더 이상 “성능은 좀 낮지만 편한 차선책”으로 볼 필요가 없다는 점이다. 적절한 구조 설계만 있으면 training-free 접근도 충분히 강한 baseline이 될 수 있고, 어떤 태스크에서는 model-based 방법을 속도 면에서 앞설 수도 있다. RACER는 그 기준선을 꽤 높게 끌어올렸고, 앞으로 speculative decoding 연구가 단순한 알고리즘 제안에서 serving architecture design 쪽으로 더 이동할 것임을 예고하는 신호로도 읽힌다.

따라서 RACER를 읽을 때는 “retrieval을 더 잘했다”나 “copy-logit이 더 sharp하다” 같은 개별 포인트만 보지 말고, 그 조합이 만들어 내는 전체 설계를 함께 보는 편이 좋다. 이 논문은 작은 아이디어 몇 개를 느슨하게 붙인 것이 아니라, 낮은 추가 비용, 긴 accepted span, 폭넓은 모델 호환성이라는 세 목표를 일관되게 맞춘 사례다. 그래서 후속 연구가 일부 구성요소를 바꾸더라도, 이 설계 원칙 자체는 오래 남을 가능성이 높다. training-free decoding을 실전 시스템 설계의 정식 옵션으로 올려놓았다는 점에서 이 논문의 의미는 생각보다 크고 분명하며 꽤 선명하고 또렷하며 매우 분명하다. 그리고 이 메시지는 앞으로의 서빙 최적화 연구에도 꽤 오래, 그리고 아주 길고 오래 남을 가능성이 높다.

10. 요약 정리: RACER를 짧게 다시 읽기

• 문제 설정: 자기회귀 디코딩의 선형 지연을 줄이기 위해 training-free speculative decoding을 개선한다.
• 핵심 아이디어: retrieval은 seen information, logits는 unseen information으로 보고 둘을 같은 draft tree 안에서 결합한다.
• Logits Tree: last-logit보다 copy-logit이 sharper한 accepted rank 분포를 만들어 기본 확장 전략으로 채택된다.
• Retrieval Tree: Aho–Corasick automaton에 LRU leaf eviction을 결합해 10K node 수준의 가벼운 동적 캐시를 유지한다.
• 통합 전략: retrieval 후보를 먼저 배치하고 남은 예산을 logits로 채운 뒤 trie union으로 merge하는 방식이 Half, Hard보다 낫다.
• 주요 결과: Vicuna 계열에서 평균 2.42~2.52배, Qwen3 계열에서 2.18~2.27배 speedup을 기록하며 training-free baseline을 앞선다.
• 해석 포인트: EAGLE-3처럼 MAT가 더 높은 모델도 있지만, 추가 draft model 오버헤드 때문에 end-to-end speedup에서는 RACER가 더 유리한 구간이 있다.
• 한계와 후속 과제: text-only 평가, exact-match retrieval 의존, 멀티모달 미검증이 남아 있으며 semantic-aware retrieval과 hybrid serving으로 확장 여지가 크다.