LLM은 왜 가끔 느려질까?

- Tail Latency를 줄이는 DSDE 기반 Speculative Decoding 최적화 전략

최근 LLM은 다양한 서비스에 빠르게 적용되고 있습니다. 그러나 실제 운영 환경에서는 ‘평균 속도는 빠른데, 가끔 너무 느려지는 순간’, 즉 tail latency(상위 지연 시간)*가 더 중요한 문제가 되고 있습니다. 사용자 입장에서 느끼기에 이 ‘가끔’이 전체 서비스 품질을 결정하기 때문입니다. 추론 속도를 높이기 위해 Speculative Decoding(SD)*과 같은 가속 기법이 활용되고 있으나, 모든 요청과 구간에 동일한 설정을 적용하는 방식은 오히려 일부 상황에서 성능 저하를 초래할 수 있습니다. 이는 단순한 속도 개선을 넘어, LLM 추론 최적화 전략의 재설계를 요구하는 문제입니다.

삼성SDS 연구진은 이러한 비효율의 원인을 ‘예측 안정성의 시간적 변동성’에 있다고 보았습니다. SD에 사용되는 두 모델(draft/target)의 확률 분포 차이와 그 변화를 정량적으로 분석하였으며 이를 기반으로 상황에 따라 추측 길이를 동적으로 조절하는 Dynamic Speculative Decoding Engine(DSDE)*를 제안했습니다.

1. LLM Autoregressive Decoding과 Speculative Decoding: 왜 Speculation Length는 한계가 있을까?

LLM 추론은 기본적으로 자기 회귀(Autoregressive, AR) 디코딩 방식을 사용합니다. 즉, ‘토큰을 한 번에 하나씩’ 순차적으로 생성하는 구조입니다. 이 방식은 LLM의 규모에 비해 한 번에 처리하는 데이터 양이 적어, GPU의 강력한 병렬 연산 능력을 충분히 활용하지 못합니다. 그 결과 연산 성능보다 메모리 대역폭에 의해 속도가 정체되는 메모리 바운드(Memory-bound) 병목이 발생합니다.

이 문제를 완화하기 위한 대표적인 LLM 가속 기법이 Speculative Decoding 입니다. 작은 보조 모델(draft model)이 여러 토큰을 먼저 예측하고, 큰 모델(target model)이 이를 검증해 수용(accept)하면 여러 토큰을 한 번에 확정할 수 있습니다. 보통 ‘보조 모델이 제안한 토큰을 큰 모델이 그대로 낼 확률이 높았는가’로 검증 기준을 판단하며, 수용률이 높을수록 추가 속도 이득이 커집니다. 잘 맞는 상황에서는 모델이 여러 토큰 단위로 끊어 처리할 수 있어 체감 속도가 크게 개선됩니다.

이 때 핵심 제어 변수는 Speculation Length(SL)입니다. SL은 "한 번에 몇 개의 토큰을 미리 추측할 것인가"를 결정하는 수치를 의미하며, SD의 성능과 효율을 결정하는 중요한 파라미터입니다.

2. 기존 Speculative Decoding의 구조적 한계와 tail latency 문제

현재 대부분의 Speculative Decoding 시스템은 이 Speculation Length 값을 고정한 Static SL방식을 사용합니다. 하지만 실제 LLM 서비스 환경에서는 이 고정 길이 방식은 명확한 한계를 드러냅니다. 문맥의 난이도와 작업의 특성에 따라 '최적의 추측 길이'가 매 순간 극심하게 변하기 때문입니다. 예를 들어, 패턴이 명확한 코드 생성 작업은 SL ≥ 8 의 긴 추측도 무리 없이 수용될 수 있습니다. 반면, 불확실성이 큰 일반 대화나 복잡한 논리 추론은 SL = 2조차 거절될 확률이 높습니다.

결국 불확실성이 큰 구간에서 길게 예측할수록 거절(reject)되는 토큰이 늘어나고, 이는 고스란히 검증 비용과 재생성 비용의 낭비로 이어집니다. 하나의 고정된 SL을 전 구간에 적용하는 것은 "잘 되는 구간에서의 이득"보다 "안 되는 구간에서의 손해"를 키우는 결과를 초래합니다. 특히 다양한 요청이 혼합된 batch 처리 환경에서는 일부 시퀀스의 낮은 수용률이 전체 처리 지연을 유발하며, 이는 곧 tail latency 증가의 주요 원인이 됩니다.

[그림 1] 최적 SL의 극심한 변동성을 나타내는 그래프

X축 (Iteration Number): 'StaticSL length'라고 표기되어 있으며, 반복 횟수를 0부터 약 200까지 나타냅니다. Y축 (Number of Tokens): 생성 및 수락된 토큰의 개수를 0에서 60 이상까지 나타냅니다. 주황색 선 (Proposed number of tokens): 그래프 하단에 약 3~5개 사이의 값으로 일정하게 직선을 유지합니다. 이는 매 단계마다 모델이 제안하는 토큰 수가 고정되어 있음을 의미합니다. 파란색 선 (Accepted number of tokens): 초반(0~75회)에는 매우 큰 변동성을 보입니다. 많은 구간에서 10개 미만이지만, 특정 지점(약 25, 45, 60~70회)에서는 제안된 수보다 훨씬 많은 최대 60개 가까운 토큰이 한꺼번에 수락되는 급격한 스파이크(Spike) 현상이 나타납니다. 약 75회 이후부터는 데이터 포인트가 표시되지 않거나 0에 수렴하는 형태를 보입니다.

실제 동일한 시퀀스 생성 과정에서도 iteration마다 승인되는 토큰 수는 극심하게 변동합니다. 예를 들어 어떤 iteration에서는 10개 이상이 승인되지만, 다른 iteration에서는 거의 승인되지 않는 경우도 발생합니다. 이처럼 최적 SL이 시점별로 크게 달라지는 상황에서, 단일 고정값으로 모든 구간을 효율적으로 처리하는 것은 구조적으로 불가능합니다.

3. DSDE: KLD(Kullback-Leibler divergence)* 기반 동적 Speculation Length 제어 메커니즘

DSDE는 질문 자체를 바꿉니다. “Speculation Length를 얼마나 길게 미리 생성할 것인가?”를 고정값으로 두지 않고, “지금 이 토큰 구간은 얼마나 안정적인가?”를 먼저 판단한 뒤, 그에 맞춰 SL을 조정하는 접근 방법입니다. *Kullback-Leibler divergence (KLD): 한 확률 분포가 다른 확률 분포와 얼마나 다른지를 측정하는 정보 이론적 지표

[그림 2] DSDE 시스템 아키텍처

전체 구조는 상단에서 하단으로 데이터가 흐르는 계층적 구조로 되어 있습니다. 최상단 - Lookahead scheduler (Dynamic SL slots forward): 시스템의 전체 흐름을 제어하며 'Dynamic SL' 신호를 우측의 KV 캐시 메모리 영역으로 보냅니다. 우측 상단 - 메모리 영역: Draft model KV와 Target model KV 블록이 점선으로 표시되어 있으며, 동적 SL 값에 따라 메모리 자원을 관리합니다. 중간 계층 - 핵심 엔진: Speculative decoding worker와 이를 보조하는 Block manager가 위치합니다. 하단 계층 - 4개 주요 컴포넌트: 1번 Draft worker (Proposer): 토큰을 제안하는 역할. 2번 Target worker (Scorer): 제안된 토큰을 채점하는 역할. (1, 2번의 결과물은 하단의 Per-sequence metadata로 연결됨) 3번 Rejection sampler (Verifier): 제안된 토큰의 수락 여부를 최종 검증하는 역할. 4번 SL adapter: 현재 상태에 맞춰 추측 길이(SL)를 조정하는 역할. (3, 4번의 결과물은 하단의 Dynamic SL decoding algorithm으로 연결됨)

위의 그림 2는 DSDE의 전체 워크플로우를 보여주는 아키텍처로, 전체 워크 플로우는 다음과 같습니다.

(1) Draft worker가 토큰을 제안
(2) Target worker가 검증
(3) Rejection sampler가 수용/거절을 판단
(4) SL adapter가 핵심 역할

이 때, SL adapter는 KLD 분산을 기반으로 다음 iteration의 SL을 결정하고, 이 정보를 Lookahead scheduler*에 전달해 메모리 할당을 동적으로 조정합니다. 이 과정은 LLM 추론 중 실시간으로 반복됩니다. * Lookahead scheduler: 미래를 예측하여 현재의 효율을 높이는 일정 관리 방식
DSDE의 핵심 신호는 KLD의 분산입니다. DSDE는 보조 모델(draft 모델)과 큰 모델(target 모델)이 만들어내는 확률 분포의 차이(KLD)을 측정하고, 이 값이 시간(토큰) 생성 과정에서 얼마나 변동하는지(KLD변동성)를 안정성 지표로 사용합니다.

핵심은 단일 시점의 KLD 값이 아니라, 시간 축에서의 KLD 변동성(variance) 입니다.

분포 차이가 작고 그 변동성도 낮다면 모델이 다음 토큰을 비교적 확신하고 있다는 의미이므로, 더 긴 Speculation Length(SL)를 적용해도 높은 수용률을 기대할 수 있습니다. 반대로 KLD 분산이 크게 요동치는 구간은 예측이 불안정하다는 신호이므로 SL을 줄여 불필요한 reject 비용을 최소화합니다.

구현 측면에서는 최근 10 step과 30 step 구간의 KLD 분산을 비교합니다. 단기 변동성이 장기 추세보다 커지면 이를 ‘현재 불안정 구간’으로 판단합니다. 이러한 방식은 평균적으로는 비슷해 보이지만 순간적으로 크게 어긋나는 구간을 효과적으로 탐지할 수 있다는 장점이 있습니다.

이 안정성 신호를 기반으로 DSDE는 Per-sequence(요청별) 동적 SL 제어를 수행합니다.

예를 들어, 코드 생성과 같이 분포가 안정적인 요청에는 긴 SL을 적용하고, 복잡한 대화나 추론처럼 변동성이 큰 요청에는 짧은 SL을 적용합니다.

이는 배치 내 모든 시퀀스에 동일한 SL을 적용하는 전통적인 Per-batch 방식과 대비됩니다. DSDE의 Per-sequence 전략은 각 요청의 특성을 반영해 Continuous batching* 환경에서 자원 활용 효율을 극대화합니다. * Continuous batching(연속 배치): LLM 추론 시 GPU의 계산 자원을 최대한 활용하여 처리량을 극대화하고 사용자 대기 시간을 줄이는 최신 일괄 처리 기술

[그림 3] Static SL vs Dynamic SL 비교

이 이미지는 추측 디코딩의 두 가지 전략을 단계별로 설명합니다. 상단에는 범례(Batch, Accepted token, Rejected token, Bonus token)가 표시되어 있습니다. [상단 행: Per-batch speculative decoding (SL = 3)] 모든 시퀀스(Seq 0~3)에 대해 고정된 길이(3개)의 토큰을 한꺼번에 추측하는 방식입니다. Proposer/Scorer 단계: 4개의 시퀀스 모두 동일하게 3개씩의 토큰(1, 2, 3) 묶음을 처리합니다. Verifier(검증) 결과: Seq 0: 3개 모두 수락 (3/3), 보너스 토큰 추가. Seq 1: 1번만 수락, 2~3번 거부 (1/3), 보너스 토큰 추가. Seq 2: 1번만 수락, 2~3번 거부 (1/3), 보너스 토큰 추가. Seq 3: 모두 거부 (0/3), 보너스 토큰 추가. 결과: 모든 시퀀스가 동일한 '배치' 크기로 처리되지만, 수락률에 따라 실제 추가되는 토큰 수는 다릅니다. [하단 행: Per-sequence speculative decoding] 각 시퀀스의 특성이나 길이에 따라 추측하는 토큰의 개수를 다르게 설정하는 방식입니다. Proposer/Scorer 단계: 시퀀스별로 추측 토큰 수가 다릅니다 (Seq 0은 4개, Seq 1은 2개, Seq 2는 3개, Seq 3은 1개). Verifier(검증) 결과: Seq 0: 4개 모두 수락 (4/4), 보너스 토큰 추가. Seq 1: 1번 수락, 2번 거부 (1/2), 보너스 토큰 추가. Seq 2: 1번 수락, 2~3번 거부 (1/3), 보너스 토큰 추가. Seq 3: 거부 (0/1), 보너스 토큰 추가. 결과: 각 시퀀스별로 최적화된 개수의 토큰을 추측하여 효율성을 높이는 구조를 보여줍니다.

그러나 Per-sequence 방식은 새로운 병목을 유발합니다. 요청마다 Speculation Length(SL)가 달라지면, 배치 내 가장 긴 추측이 끝날 때까지 다른 요청들이 대기해야 하는 'Straggler 문제'가 발생합니다. Per-sequence 방식에서는 각 시퀀스가 서로 다른 길이로 토큰을 생성하지만, 가장 긴 예측이 끝날 때까지 다른 시퀀스들이 idle 상태로 대기해야 하는 병목이 생깁니다. (그림 4 참고)

[그림 4] Per-sequence 방식에서 발생하는 Straggler 문제

구조: 좌측에 4개의 시퀀스(Seq 0~3)가 있고, 중앙에 Proposer(제안 모델), 우측에 Scorer(대상 모델)가 위치합니다. Proposer 단계: * 최대 추측 길이(k_{max})가 4로 설정되어 있습니다. Seq 0 (k=4): 4개의 토큰을 모두 생성하며 유휴 시간이 없습니다. Seq 1 (k=2): 2개 토큰 생성 후 나머지 2개 칸이 빗금 친 빨간색 상자(Idle/Waiting)로 표시됩니다. Seq 3 (k=1): 1개 토큰 생성 후 나머지 3개 칸이 모두 유휴 상태입니다. 핵심 메시지: 하단에 **'Straggler problem'**이라는 텍스트와 함께 중괄호가 표시되어 있습니다. 이는 가장 긴 작업(Seq 0)이 끝날 때까지 짧은 작업들이 기다려야 하는 비효율성을 강조합니다.

예를 들어,

• 요청 A: SL=10 → 0.5초 소요
• 요청 B, C, D: SL=2~3 → 0.15초 소요

B, C, D는 0.15초면 끝나지만 A 때문에 0.5초까지 대기해야 합니다. 결국 전체 batch 지연은 가장 긴 요청에 의해서 결정됩니다.

그렇다면 왜 단순히 고정된 최대값 제한으로는 안 될까요? 가장 간단한 해법은 "SL ≤ 5"처럼 고정 상한을 두는 것입니다.

그러나 이 역시 근본적인 해결책이 되지 않습니다.

• 상한이 너무 낮으면 (예: 2)
• SL=10이 필요한 요청은 2개씩 나누어 여러 번 반복해야 하므로 비효율 증가
• 상한이 너무 높으면 (예: 8)
• 여전히 긴 요청 하나가 batch 전체를 지연시키는 Straggler 문제 지속

즉, 고정 상한의 문제는 현재 batch의 분포를 반영하지 못합니다. 모두 쉬운 요청인 배치는 상한 8이 좋지만, 모두 어려운 요청인 배치는 상한 2가 좋고, 섞인 배치는 중간값이 필요합니다.

DSDE는 매 배치마다 그 배치에 맞는 상한선을 동적으로 계산합니다. 방법은 단순합니다.

• 각 요청의 이상적 Speculation Length(SL)를 예측
• 예: A=10, B=2, C=3, D=2
• 배치 평균 계산
• (10+2+3+2)/4 = 4.25 → SL_cap = 4
• 각 요청에 cap 적용
• A: min(10,4)=4
• B: min(2,4)=2
• C: min(3,4)=3
• D: min(2,4)=2

논문에서는 이 전략을 평균제곱오차(MSE) 최소화 관점에서 수학적으로 정당화합니다. SL_cap의 목표는 모든 예측값과의 차이를 최소화하는 것이기 때문에 극단값(A)만 제한되고, 나머지 요청은 본래의 이상적 SL을 유지합니다. 이는 개별 최적성과 배치 동기화 사이의 균형을 형성합니다. 이렇게 개별 요청의 효율을 높이면서도 배치 전체의 발걸음을 맞춤으로써, 실제 대규모 서빙 환경에서의 병목을 입체적으로 해결합니다. Straggler는 완전히 제거되지 않지만, 그 영향이 배치 전체에 공평하게 분산되어 전체 성능이 향상됩니다.

이 동적 SL_cap 계산은 추론 과정에서 실시간으로 반복되며, 별도의 추가 학습 없이 적용 가능합니다. 운영자는 한 번 정한 길이에 모든 요청을 맞추는 대신, 요청·구간별로 자동 조정되는 적응형 Speculative Decoding을 얻게 됩니다. 실서비스 관점에서 이는 불확실한 구간에서의 계산 낭비를 줄이고, 안정적인 구간에서의 가속 이득을 더 크게 가져가는 형태로 동작합니다.

4. 실험 결과 - 평균보다 중요한 tail latency

논문 실험은 DSDE가 평균 지연시간을 크게 해치지 않으면서도 tail latency를 낮추는 방향으로 동작함을 보여줍니다. 하이퍼 파라미터 민감도 측면에서, Static SL과 AdaEDL*은 U자형 곡선을 보이며 최적값을 벗어나면 급격히 성능이 저하되지만, DSDE는 특정 파라미터 튜닝 없이도 안정적입니다. *AdaEDL: 정적인 초안 길이 추론 디코딩보다 최대 57% 더 높은 성능을 제공하며 기존의 LLM에도 매끄럽게 통합됩니다.
다양한 데이터셋에서의 일관성도 주목할 만합니다. CNNDM(뉴스 요약), GSM8K(수학 문제), NQ(질의응답), HotpotQA(복잡한 질의), ShareGPT(대화) 등 성격이 완전히 다른 5개 데이터셋에서 DSDE는 모두 Static OPT에 근접한 성능을 보였습니다. 여기서 핵심은 Static OPT 가 각 데이터셋마다 최적 SL을 찾기 위해 수 시간의 프로파일링(튜닝)이 필요한 반면, DSDE는 프로파일링 없이 이를 달성했다는 점입니다. 실서비스 환경에서는 워크로드가 지속적으로 변화하므로 매번 프로파일링할 수 없는데, DSDE는 이런 환경에서 즉시 적용 가능합니다. (그림 5 참고)

[그림 5] 실험 결과 - 다양한 유형의 데이터셋에서의 일관된 성능

X축 (Dataset): cnndm, gsm8k, NQ, hotpotQA, shareGPT 데이터셋. Y축 (Mean latency (s)): 지연 시간을 초 단위로 0에서 60까지 나타냅니다. 지표별 비교: Autoregressive (빨간색): 모든 데이터셋에서 약 35~45초 사이의 압도적으로 높은 지연 시간을 기록합니다. Static-4 (연주황색) & Static-6 (진주황색): 약 13~16초 사이의 지연 시간을 보입니다. WVIR-based (파란색): 대부분의 데이터셋에서 가장 낮은 막대 높이를 보이며, 특히 gsm8k와 hotpotQA에서 다른 방식보다 유의미하게 낮은 지연 시간을 기록합니다.

모델 불일치가 큰 환경에서는 차이가 더욱 극명해집니다. 예를 들어, Gemma 27B- 2B 모델 쌍을 사용한 실험에서는 거절되는 토큰이 많아, 최적 SL이 2로 매우 보수적입니다. 이처럼 수용률이 낮은 환경에서 AdaEDL은 급격한 성능 저하를 보였으며, 일부 데이터셋에서는 지연시간이 Static OPT보다 1.5배 이상 상승하여 실용성이 크게 떨어졌습니다. 반면 DSDE는 Static OPT 와 비슷한 수준을 유지하며 안정성을 입증했습니다. 이는 DSDE의 KLD 기반 post-hoc 신호가 AdaEDL의 forward-looking entropy보다 draft 모델이 신뢰할 수 없을 때 더 강건함을 보여줍니다. 실서비스에서는 항상 이상적인 모델 쌍을 쓸 수 없기 때문에, 이런 강건성이 매우 중요합니다. (그림 6 참고)

[그림 6] 어려운 환경에서의 강건성 비교

X축 (Dataset): cnndm, gsm8k, hotpotQA, NQ, shareGPT. Y축 (Mean latency (s)): 지연 시간을 0에서 80까지 나타냅니다. 지표별 비교: AdaEDL (초록색): 모든 데이터셋에서 가장 높은 지연 시간(약 45~55초)을 보입니다. Static-opt (주황색): 모든 데이터셋에서 가장 낮은 지연 시간을 기록하여 가장 효율적인 성능을 보여줍니다. WVIR-based (파란색): Static-opt보다는 소폭 높으나 AdaEDL보다는 훨씬 낮은 약 35~43초 사이의 지연 시간을 유지합니다.

추가로 배치 크기를 64까지 증가시킨 확장성 실험에서도, SL_cap이 없으면 11.21배 확장에 그쳤지만 SL_cap 적용 시 12~13배까지 확장되어 처리량이 약 10% 개선되었습니다.

이 점이 특히 실서비스에 중요합니다. 평균이 조금 좋아지는 것보다, 최악의 순간이 줄어드는 것이 SLA와 사용자 체감 품질에 더 직접적으로 연결되기 때문입니다. 운영자가 서비스 레벨을 설계할 때도, '99퍼센타일 지연시간'을 줄이는 것이 비용(더 많은 GPU 투입)과 품질(더 빠른 응답) 사이의 균형을 바꾸는 경우가 많습니다.

5. 실서비스 LLM 추론 최적화 관점에서 본 DSDE의 의의와 확장 가능성

DSDE 동적 전략은 하드웨어 가속 접근과도 잘 맞습니다. 예를 들어 PIM*기반 추론 가속이 메모리 병목을 완화해 동일 연산을 더 빠르게 수행하는 데 초점을 둔다면, DSDE는 KLD 안정성 신호를 활용해 언제, 얼마나 예측을 수행할지를 결정함으로써 불필요한 계산 자체를 줄입니다. 즉, 하드웨어가 “어떻게 빠르게 계산할 것인가”를 다룬다면, DSDE는 “어디에 계산을 집중할 것인가”를 최적화합니다. *PIM(Processing-In-Memory): 메모리 반도체 내부에 연산 기능을 통합하여, 데이터를 저장할 뿐만 아니라 직접 처리(연산)할 수 있는 차세대 지능형 반도체 기술
향후에는 DSDE와 같은 안정성 신호 기반 제어가 QoS 스케줄링(우선순위·지연 제한)과 결합해, 요청 중요도에 따라 추측 전략을 다르게 적용하거나, 에너지/비용 제약을 만족하는 방식으로 확장될 수 있습니다. LLM 서비스가 커질수록 운영의 본질은 '단일 성능 수치'가 아니라 '변동성 속에서도 일관되게 품질을 지키는 방법'에 가까워집니다. DSDE는 실서비스 환경에 적합한 추론 최적화 방향을 제시하는 사례라 할 수 있습니다.

👉 논문 바로가기