LLM 서비스가 커질수록 경쟁 포인트는 모델 성능만이 아니다. 같은 모델, 같은 품질을 유지하면서 대기 시간을 줄이려면 답을 만드는 과정의 역할 분담부터 다시 짜야 한다.

연산을 늘려도 답이 빨라지지 않는 이유

LLM의 토큰 생성 속도는 연산 성능보다 메모리 속도에 더 묶인다. 토큰을 하나 만들 때마다 모델 가중치와 KV 캐시(이전 토큰의 키, 값을 담아 둔 메모리)를 VRAM(GPU 전용 메모리)에서 읽어야 해서다. GPU 연산만 키워서는 생성 속도가 따라 붙지 않았다. 메모리 대역폭과 순차 생성이 디코딩 속도를 막는다.

추측 디코딩(speculative decoding)은 이 병목을 줄이려고 작은 ‘드래프트 모델’을 둔다. 드래프트가 여러 토큰을 미리 제안하면, 큰 타깃 모델이 한 번에 검증한다. 수용된 토큰만 남기므로 품질은 그대로다.

문제는 EAGLE-3 같은 기존 드래프트 모델도 토큰을 하나씩 만든다는 점이다. 후보가 10개면 초안 생성도 10번이다. 검증은 병렬이 됐어도 초안은 여전히 순차였다. 그래서 실제 가속은 대개 2~3배에 그쳤다. 블록을 길게 잡으면 한 번에 검증할 토큰은 늘지만, 초안 비용도 함께 커져 이득이 상쇄됐다.


16개 토큰을 한 번에 쓴다

UC 샌디에이고 연구진이 2026년 공개한 DFlash는 드래프트 모델을 블록 디퓨전으로 바꿨다. 토큰 16개를 차례로 쓰지 않고, 마스킹된 16자리를 한 번의 포워드 패스(모델 연산을 한 차례 돌리는 과정)로 채운다. 각 위치는 앞 문맥뿐 아니라 같은 블록의 다른 위치도 함께 본다. 여러 후보를 한 블록으로 예측하는 방식이다.

블록이 길어져도 초안 비용은 거의 늘지 않는다. 병렬로 뽑은 토큰이 서로 어긋나는 문제는 ‘KV 주입’으로 메운다. 타깃 모델 여러 층의 특징을 드래프트의 모든 층에 넘겨, 전체 문맥을 직접 참고하게 한다.

한 손은 지금 읽는 단어를 짚고 있는데, 다른 손은 이미 같은 줄 저 앞의 여러 단어를 하나씩 짚어보고 있다

드래프트는 배포 환경에 맞춰 3~8개 층을 새로 학습하고, 논문은 5층 구성을 예로 든다. 임베딩(토큰을 수치로 바꾸는 층)과 출력층(다음 토큰 점수를 내는 마지막 층)은 타깃 모델 것을 재사용한다. Qwen3-8B의 그리디 디코딩(매 단계 최고 확률 토큰을 고르는 방식)에서는 한 번에 평균 6.49개 토큰을 수용했고, 평균 4.86배 빨라졌다. MATH-500에서는 6배를 넘겼다. EAGLE-3보다 무손실 가속이 최대 2.5배 높았다.

블록 디퓨전은 2025년 BD3-LM에서 다시 정리됐고, BD3-LM 역시 2022~2023년 준자기회귀 생성 연구를 이은 결과다. DFlash는 이 구조를 최종 답이 아니라 ‘버려도 되는 초안’에 붙였다. 틀린 제안은 타깃 모델이 걸러내니, 디퓨전의 약점을 끝까지 떠안을 필요가 없다.


15배 빠르다는 말의 진짜 뜻

NVIDIA가 말한 최대 15배는 답 하나가 15배 빨리 나온다는 뜻이 아니다. gpt-oss-120b를 DGX B300 GPU 8장에서 돌릴 때, 사용자당 초당 500~600토큰을 유지하며 처리할 수 있는 동시 요청 수가 기존보다 15배 이상 늘었다는 의미다.

요청이 하나일 때 응답 속도는 2배 이상 빨라졌고, gpt-oss-120b 기준 자기회귀 디코딩 대비 평균 가속은 2.3배였다. 즉 사용자가 적을 때는 개인 생성 속도가, 많을 때는 시스템 전체 처리량이 더 크게 오른다. 환경 차이도 컸다. 최대 가속은 Gemma 4 31B와 vLLM 조합에서 5.8배, Qwen3-8B와 SGLang 조합에서 5.1배였다.

서빙(모델을 띄워 사용자 요청을 처리하는 일) 성능은 사용자당 생성 속도와 전체 처리량을 같이 봐야 한다. DFlash는 한쪽만 올리지 않고, 같은 응답 속도로 더 많은 요청을 처리한다.

에이전트는 계획하고, 도구를 호출하고, 결과를 검토하는 일을 반복한다. 앞 답이 나와야 다음 단계로 가니 토큰 생성 속도가 전체 완료 시간을 좌우하고, 그 영향은 더 커진다. MLCommons도 에이전트 벤치마크에서 사용자당 출력 속도와 시스템 전체 출력 속도를 따로 둔다.


도입 전에 확인할 것

먼저 쓸 모델의 DFlash 체크포인트(학습된 가중치 파일)가 있는지 본다. NVIDIA는 Qwen, Llama, Gemma, gpt-oss, Kimi K2.6 계열용 체크포인트 20종과 Blackwell, Hopper 실행법을 공개했다. 목록에 없거나 자체 파인튜닝(목적에 맞게 추가 학습한) 모델은 드래프트를 따로 학습해야 한다. vLLM에 등록된 사전학습 모델도 지금은 Gemma 4 31B 한 종뿐이다. 모든 하드웨어 조합이 검증된 것은 아니다.

지원 모델은 vLLM이나 SGLang에서 알고리즘 설정과 체크포인트만 바꾸면 되고, TensorRT-LLM도 지원한다. 직접 학습할 때는 블록 크기, 앵커(예측 블록을 붙이는 기준 위치) 수, 타깃 모델의 어느 층을 참고할지가 수용 토큰 수에 영향을 준다. 구현에 따라 실제 후보 수는 설정한 블록 크기보다 하나 적을 수 있다. sample_from_anchor가 참이면 앵커도 후보에 넣어 후보 수가 블록 크기와 같고, 거짓이면 앵커를 빼 후보가 하나 줄어든다.

도입 뒤에는 정답률보다 평균 수용 길이(τ, 검증 한 번에 타깃 모델이 받아들이는 평균 토큰 수)를 먼저 보는 편이 낫다. 최종 검증은 타깃 모델이 맡으므로, 드래프트가 낯선 언어나 전문 문서에 약해져도 품질보다 속도가 먼저 떨어진다. 후속 연구 DFlare는 타깃 모델의 층별 특징을 더 세밀히 조합해 Qwen3-8B에서 DFlash보다 8% 높은 5.46배 가속을 냈다. 다만 학습 데이터는 80만 건에서 240만 건으로 늘었다.

DFlash가 순차 생성을 없앤 것은 아니다. 품질을 책임지는 타깃 검증은 두고, 책임지지 않는 초안만 병렬화했다. 대가로 드래프트는 특정 타깃에 묶인다. 타깃을 바꾸면 드래프트도 다시 준비해야 한다. 운영에서 진짜 질문은 ‘최대 15배’가 아니라, 모델마다 필요한 드래프트를 누가 학습하고 유지할 것인가다.

추론 최적화의 단위가 GPU, 서빙 엔진을 넘어 모델별 보조 구성까지 넓어지면, 모델 교체 비용의 셈법도 달라진다. 최고 속도를 찍는 일과, 여러 모델, 환경에서 그 속도를 꾸준히 재현하는 일은 다른 운영 역량을 요구한다.


#언어모델#컴퓨트·데이터센터