2026년 4월 4일 | 개발 공부
Speculative Decoding은 작은 보조 모델이 먼저 여러 토큰 초안을 빠르게 써 두고, 큰 메인 모델이 그 초안을 한 번에 검증하면서 가능한 구간은 그대로 받아들이는 추론 가속 기법이다. 이름만 보면 복잡해 보이지만, 내가 이해한 핵심은 단순했다. 큰 모델이 매 토큰마다 처음부터 전부 계산하는 대신, 작은 모델이 먼저 길을 몇 칸 앞서 보고 큰 모델이 맞는지 확인하는 구조라는 점이다. 그래서 이 개념은 단순히 속도를 높이는 트릭이라기보다, "초안 작성"과 "검수"를 분리한 생성 파이프라인으로 읽는 편이 훨씬 덜 헷갈렸다.
처음에는 나도 이걸 그냥 추론 최적화 옵션 중 하나로만 봤다. KV cache를 켜고, 배치 크기를 조절하고, 양자화를 적용하는 것처럼 엔진 쪽에서 알아서 챙기는 기술로 느껴졌기 때문이다. 그런데 조금 더 들여다보니 이 방식은 성격이 좀 달랐다. 단순히 계산을 덜 하는 게 아니라, 어떤 계산을 먼저 싸게 해 보고 어떤 계산을 나중에 비싸게 확정할지를 분리하는 구조였다. 그 차이를 이해하고 나서야 왜 speculative decoding이 자꾸 "작은 모델과 큰 모델의 협업"처럼 설명되는지 감이 왔다.
1. 토큰을 하나씩 확정하는 대신, 먼저 여러 칸을 써 보고 맞는 구간만 통과시킨다
일반적인 autoregressive 생성에서는 큰 모델이 매 스텝마다 다음 토큰 확률을 계산하고, 그 결과로 한 토큰을 선택한 뒤 다시 다음 스텝으로 간다. 이 구조는 단순하지만, 길이가 길어질수록 같은 루프를 계속 반복해야 해서 지연 시간이 누적된다. speculative decoding은 여기서 질문을 바꾼다. "어차피 다음 몇 토큰이 꽤 예측 가능하다면, 작은 모델이 먼저 초안을 써 보고 큰 모델은 그 초안이 맞는지만 확인하면 안 되나?"라는 식이다.
이 접근이 흥미로운 이유는 생성의 리듬이 바뀐다는 점이다. 예전에는 한 토큰 생성 = 한 번의 무거운 판단이었다면, 이제는 여러 토큰 초안 = 한 번의 가벼운 예측 + 한 번의 무거운 검수가 된다. 물론 초안이 자주 틀리면 이득이 줄어든다. 하지만 언어 모델 출력에는 생각보다 예측 가능한 구간이 많아서, 특히 문장 연결부나 자주 등장하는 패턴에서는 여러 토큰을 한꺼번에 넘길 수 있다.
- 작은 모델은 빠르게 초안을 만든다.
- 큰 모델은 그 초안이 어디까지 맞는지 검수한다.
- 맞는 구간은 여러 토큰을 한 번에 확정하고, 틀린 지점부터 다시 큰 모델이 주도권을 잡는다.
내가 이 구조를 이해한 뒤로는 speculative decoding을 더 이상 "빠른 샘플링 요령" 정도로 보지 않는다. 오히려 생성 과정 안에 초안 단계와 승인 단계를 따로 두는 파이프라인 설계처럼 읽는다.
2. 왜 작은 모델이 끼어들어도 품질을 망치지 않는지가 처음엔 제일 이상했다
처음 이 개념을 볼 때 가장 이상했던 건 여기였다. 작은 모델이 먼저 쓴 초안을 받아들이면, 결국 작은 모델 품질에 끌려가는 것 아닌가 하는 의문이 들었다. 그런데 핵심은 작은 모델이 정답을 결정하지 않는다는 데 있다. 초안을 쓰는 역할과 최종 확정 권한이 분리되어 있기 때문에, 큰 모델이 받아들인 토큰만 실제 출력이 된다.
즉 작은 모델은 어디까지나 후보를 던지는 역할이다. 큰 모델이 검수 단계에서 "여기까지는 내가 원래 뽑았을 토큰과 같다"고 판단하는 구간만 통과된다. 이 구조 덕분에 시스템은 속도를 일부 얻으면서도, 이론적으로는 메인 모델 분포를 유지하는 방향으로 설계된다. 내가 이걸 이해하고 나서야 speculative decoding이 단순한 distillation이나 보조 랭커와는 다른 층위라는 게 보였다.
draft model: 빠르게 몇 토큰을 제안
main model: 제안된 토큰을 한 번에 검증
accept: 일치하는 구간은 그대로 통과
reject: 어긋나는 지점부터 메인 모델이 다시 생성
결국 작은 모델은 출력 품질을 책임지는 모델이 아니라, 큰 모델이 덜 자주 멈추게 만드는 가속 장치에 가깝다. 이 감각이 생기고 나니 구조가 훨씬 자연스러워졌다.
3. 내가 이걸 '캐시 최적화'보다 '검증 가능한 초안 작성'으로 이해하게 된 이유
KV cache나 양자화는 주어진 계산을 더 싸게 수행하는 방향에 가깝다. 반면 speculative decoding은 계산의 배치를 다시 짠다. 그래서 체감상 같은 추론 최적화 범주에 있어도 머릿속 모델은 꽤 다르다. 내가 보기에는 이 개념을 이해할 때 성능 수치보다 중요한 건, 어디까지를 예측으로 넘기고 어디서부터를 검증으로 가져오는가다.
이 관점이 중요한 이유는 병목을 보는 방식까지 바꾸기 때문이다. 초안 모델이 너무 약하면 수용률이 낮아지고, 너무 크면 초안 작성 비용이 다시 커진다. 반대로 메인 모델과 초안 모델의 스타일 차이가 크면 자주 어긋나서 기대한 만큼 앞당겨지지 않는다. 결국 speculative decoding은 "무조건 작은 모델을 붙이면 빨라진다"가 아니라, 초안 품질과 검수 비용의 균형을 맞추는 문제로 읽어야 했다.
| 구성 요소 | 내가 이해한 역할 | 문제가 생기면 보이는 현상 |
|---|---|---|
| 초안 모델 | 앞쪽 토큰을 싸게 미리 제안 | 수용률이 낮아져 속도 이득이 줄어듦 |
| 메인 모델 | 제안을 검수하고 최종 분포를 보장 | 검수 비용이 너무 커지면 이득이 상쇄됨 |
| 수용 구간 | 여러 토큰을 한 번에 확정하는 핵심 지점 | 짧아지면 일반 디코딩과 차이가 작아짐 |
이 표로 정리하고 나서야 운영 관점도 보였다. 결국 좋은 speculative decoding은 초안 모델이 충분히 싸고, 동시에 충분히 메인 모델과 닮아 있어야 한다. 둘 중 하나라도 어긋나면 장점이 빠르게 사라진다.
4. 실제로 어디에 잘 맞는지는 '정답률'보다 '예측 가능한 반복성'에 달려 있다
나는 처음에 reasoning이 강한 긴 답변일수록 이 기법이 더 잘 맞을 거라고 막연히 생각했다. 그런데 오히려 반대로 볼 필요가 있었다. speculative decoding이 잘 먹히는 구간은 놀랍도록 독창적인 토큰이 연속되는 부분보다, 다음 전개가 어느 정도 읽히는 구간이다. 자연어 문장 연결, 포맷이 정해진 출력, 코드에서 자주 나오는 패턴 같은 곳에서는 초안 모델이 꽤 길게 앞서 나갈 수 있다.
반대로 분기점이 잦거나 희귀 토큰이 자주 튀는 작업에서는 수용률이 낮아질 수 있다. 그래서 이 기법을 볼 때 단순 TPS 숫자만 보는 건 조금 부족하다고 느낀다. 실제 서비스에서는 어떤 프롬프트 분포에서 수용률이 유지되는지, 짧은 질의와 긴 질의에서 차이가 어떻게 나는지, structured output처럼 패턴이 강한 작업에서 이득이 더 큰지를 같이 봐야 한다.
- 반복적 패턴이 있는 출력은 초안 수용률이 올라가기 쉽다.
- 희귀 토큰과 급격한 분기점이 많으면 초안이 자주 깨진다.
- 벤치마크 평균 속도보다 실제 프롬프트 분포별 수용률이 운영 감각에 더 가깝다.
이렇게 보고 나니 speculative decoding은 "항상 빨라지는 기능"보다 특정 출력 성격에서 특히 잘 맞는 협업 구조처럼 느껴졌다. 결국 모델의 지능뿐 아니라 출력 패턴의 예측 가능성까지 같이 작동하는 셈이다.
5. 에이전트와 추론 시스템을 볼 때도 이 구조가 은근히 많이 겹친다
재미있는 건 이 감각이 토큰 생성 바깥에서도 꽤 자주 보인다는 점이다. 예를 들어 에이전트 시스템에서는 값싼 휴리스틱이나 검색 단계가 먼저 후보를 좁히고, 더 비싼 모델 호출이 나중에 확정하는 경우가 많다. 검색 랭킹에서도 거친 1차 후보 생성과 비싼 reranking이 분리된다. 그래서 나는 speculative decoding을 보면서 단지 LLM inference 트릭을 배운 게 아니라, 싼 초안과 비싼 검수를 분리하는 시스템 설계 패턴을 같이 보게 됐다.
이 패턴이 중요한 이유는 비용 구조를 훨씬 유연하게 만들기 때문이다. 모든 단계에서 가장 비싼 판단을 매번 호출하는 대신, 대부분의 쉬운 구간은 싸게 넘기고 애매한 구간만 비싼 모델이 처리하게 만들 수 있다. speculative decoding은 그걸 토큰 단위로 밀어붙인 사례라고 보면 이해가 쉬웠다. 그래서 나는 이제 이 개념을 읽을 때 추론 속도 향상 수치만 보지 않고, 시스템 전체에서 초안과 승인 권한을 어떻게 나눌지를 같이 떠올리게 된다.
6. 짧게 남겨 두고 싶은 내 식의 정리
지금의 나는 speculative decoding을 "작은 모델이 큰 모델을 대신하는 방식"으로는 이해하지 않는다. 오히려 작은 모델이 먼저 써 보고 큰 모델이 최종 승인하는 공동 작성 구조에 더 가깝다고 본다. 이 관점으로 보면 왜 품질을 함부로 희생하지 않으면서도 속도를 얻으려 하는지, 왜 수용률이 중요한 지표인지, 왜 초안 모델 선택이 그렇게 민감한지가 한 번에 이어진다.
결국 내가 최근에 배운 건 추론 최적화 기법 하나의 이름보다, 계산을 한 덩어리로 보지 않고 초안, 검수, 확정의 단계로 나눠 보는 시선이었다. 이 감각이 생기고 나니 speculative decoding은 더 이상 낯선 엔진 옵션이 아니라, 큰 모델을 덜 자주 멈추게 만드는 꽤 직관적인 협업 구조로 남았다.
함께 보면 좋은 키워드: KV cache, continuous batching, prefix caching, reranking, draft model, acceptance rate
'[개발 공부]' 카테고리의 다른 글
| Quality Gate, PASS/FAIL 사이에 WARN을 두는 방식 (0) | 2026.04.20 |
|---|---|
| Reranker를 검색 마지막 미세조정보다 순서 복구 단계로 이해하게 된 이유 (0) | 2026.04.06 |
| HNSW를 벡터 DB보다 그래프 탐색으로 읽게 된 이유 (0) | 2026.04.03 |
| MCP를 붙인 뒤에야 더 선명해진 것, 결국 중요한 건 도구보다 계약이다 (0) | 2026.04.02 |
| 웹소켓을 붙일 때 HTTP 감각을 그대로 가져가면 자꾸 꼬이는 이유 (0) | 2026.04.01 |