Liquid AI의 LFM2.5-DSpark 추측 디코딩 분석
컴퓨터나 스마트폰에서 챗봇(LLM)을 쓸 때, 답변이 한 글자씩 타닥타닥 찍히며 나오는 속도가 답답하게 느껴진 적이 있을 것이다.
우리는 보통 “그래픽카드(GPU) 계산 성능이 느려서 그런가?“라고 생각하기 쉽다. 하지만 컴퓨터 구조 관점에서 보면, 텍스트를 한 글자씩 생성(Decode)할 때 속도를 가로막는 진짜 주범은 연산 능력이 아니라 메모리 대역폭(Memory Bandwidth)의 한계이다.
2026년 8월 20일, 경량 AI 모델로 주목받는 스타트업 Liquid AI가 자사의 최신 모델군(LFM2.5)을 위한 DSpark [1] 기반의 추측 디코딩(Speculative Decoding) 드래프트 모델을 공개했다.
결과는 놀랍다. 1억 원이 넘는 데이터센터용 최고급 GPU인 NVIDIA H100에서 최대 3.18배, 우리가 흔히 쓰는 노트북인 M4 Max 맥북 프로에서 최대 2.87배나 생성 속도가 빨라졌다. 더욱 매력적인 점은 모델 출력을 억지로 줄이거나 압축한 것이 아니라서 답변의 정확도와 품질 손실이 0% 수준으로 원본과 완벽히 동일하다는 사실이다.
Liquid AI의 기술 블로그 《LFM2.5-DSpark: Up to 3.2x Faster Inference from H100 to MacBook》을 바탕으로, 추측 디코딩의 기본 원리부터 DSpark 아키텍처의 비밀, 그리고 온디바이스 에이전트 가속과 MoE 모델의 흥미로운 물리적 한계를 알기 쉽게 정리해 보았다.
1. 왜 LLM은 한 글자씩 뽑을 때 유독 느릴까?
컴퓨터가 대형 언어 모델을 돌릴 때의 과정은 크게 두 단계로 나뉜다.
- 프롬프트 입력 처리(Prefill 단계): 사용자가 보낸 긴 질문을 한 번에 읽고 이해하는 단계. 연산할 데이터가 많아서 GPU의 계산 코어가 100% 풀가동되는 연산 집약적인 Compute-bound 상태가 된다.
- 토큰 생성(Decode 단계): 이전 단어들을 바탕으로 다음 단어를 1개씩 순서대로 찍어내는 단계.
문제는 우리가 체감하는 속도를 좌우하는 2단계 Decode 단계다.
[ 메인 메모리 (VRAM / DRAM) ]
│
│ 단어 1개를 만들 때마다 수십 GB에 달하는 모델 가중치를 통째로 복사
▼
[ 초고속 연산 코어 (SRAM / Tensor Core) ] ➔ 연산은 0.001초 만에 끝남 ➔ 다음 데이터 올 때까지 대기GPU 연산 코어는 눈 깜짝할 사이에 수천억 번의 덧셈과 곱셈을 해치울 만큼 엄청나게 빠르다.
하지만 단어(토큰)를 딱 1개 만들 때조차, 수 기가바이트에서 수십 기가바이트에 이르는 모델의 전체 가중치(Brain 데이터)를 메인 메모리(DRAM)에서 연산 코어 내부의 초고속 캐시(SRAM)로 몽땅 긁어와야 한다.
비유하자면, “칼질을 0.001초 만에 끝내는 천재 요리사(GPU 코어)가 있는데, 재료 창고(DRAM)에서 도마(SRAM)까지 재료를 나르는 통로(메모리 버스)가 좁아서 대부분의 시간을 도마 앞에서 멍하니 서서 기다리는 상황”에 비유할 수 있다.
이를 컴퓨터 구조론에서는 연산 장치가 메모리 전송 속도에 발목을 잡혔다는 뜻으로 메모리 바운드(Memory-bound) 상태라고 부른다.
2. 해결책: 추측 디코딩(Speculative Decoding)이란?
“가중치를 메모리에서 도마 위로 한 번 퍼 올리는 데 시간이 오래 걸린다면, 한 번 퍼 올렸을 때 단어를 여러 개 한꺼번에 검사하면 어떨까?”
이런 발상에서 출발한 기법이 바로 추측 디코딩(Speculative Decoding) 기법이다.
이 방식은 ’빠른 인턴과 꼼꼼한 베테랑 사수의 협업’에 비유할 수 있다.
| 협업 단계 | 담당 주체 (비유) | 실제 동작 메커니즘 |
|---|---|---|
| 1단계: 초안 작성 | 드래프트 모델 (빠른 인턴) | 초경량 모델이 다음 단어 9개를 미리 초고속 생성: [A, B, C, D, E, F, G, H, I] |
| 2단계: 일괄 검증 | 거대 타깃 본 모델 (베테랑 사수) | 가중치를 딱 1번 로드한 뒤, 9개 단어를 단 한 번의 순전파로 일괄 병렬 검사 |
| 3단계: 수락 및 교정 | 본 모델 판정 | • A, B, C, D: 통과 (수락) • E: 오류 발견 즉시 본 모델이 정답 단어(E’)로 교체 • F~I: 폐기 |
| 최종 결과 | 속도 대폭 가속 | 가중치를 1번 읽는 시간 동안 5개 단어(A, B, C, D, E’)가 한 번에 완성! |
[개념 짚고 가기: 수락률(Acceptance Rate)이란?]
드래프트 모델(인턴)이 미리 찍어서 제안한 여러 개의 후보 단어 중, 타깃 본 모델(사수)이 “나도 그렇게 생각했어!“라며 그대로 인정하고 통과시켜 준 토큰의 개수(또는 비율)를 말합니다.
예를 들어 인턴이 단어 9개를 써왔는데 사수가 5번째 단어까지 수락했다면, 사수는 가중치를 한 번만 읽고도 단숨에 5단어를 완성한 셈이 됩니다. 즉, 드래프트 모델이 사수의 생각을 기가 막히게 잘 맞혀서 수락률이 높을수록 전체 생성 속도가 훨씬 빨라집니다.
사수가 인턴의 초안을 검사하다가 틀린 단어가 나오면 그 즉시 본 모델의 정답 단어로 교체하고 뒤쪽은 버리기 때문에, 최종 출력의 확률 분포는 본 모델이 혼자서 썼을 때와 수학적으로 동일하게 보존된다(무손실 가속). 그리디 디코딩이라면 문장까지 그대로 같고, 온도 샘플링이라면 문장 자체는 달라질 수 있으나 품질 기댓값은 떨어지지 않는다.
3. DSpark 아키텍처: 인턴의 적중률을 끌어올린 3가지 무기
추측 디코딩의 성패는 결국 드래프트 모델의 적중률(수락률)을 얼마나 높게 유지하느냐에 달려 있다. 인턴이 엉뚱한 단어만 가져오면 사수가 매번 첫 단어부터 퇴짜를 놓아 속도가 전혀 빨라지지 않기 때문이다.
Liquid AI가 적용한 DSpark 모델 [1]은 다음 3가지 핵심 요소를 결합해 인턴의 실력을 극대화했다.
| DSpark 모듈 | 담당 역할 | 세부 동작 메커니즘 |
|---|---|---|
| 1. 병렬 백본 (Backbone) | 미래 단어 9개 초고속 생성 | 5개 레이어 디코더로 타깃 모델 은닉 상태에서 9개 후보 단어 일괄 추출 |
| 2. 순차 마르코프 헤드 (Markov Head) | 앞뒤 단어 간 문맥 확률 보정 | 방금 선택한 단어와의 인접 확률을 보정하여 후반부 토큰 수락률 극대화 |
| 3. 신뢰도 스케줄링 (Verifier) | 거절 확률 높은 단어 사전 가지치기 | 신뢰도가 낮은 뒷단어는 사수 검사 전에 미리 잘라내어 연산 낭비 차단 |
① DFlash 스타일 병렬 백본 (Parallel Backbone)
타깃 모델이 직전까지 계산해 둔 문맥 특징(Hidden states)을 전달받아, 단 한 번의 계산으로 미래의 후보 단어들(LFM2.5-DSpark가 채택한 블록 크기 9개. DSpark 논문 자체 실험값은 7이다)의 기본 확률을 한 번에 병렬로 뽑아낸다.
② 경량 순차 마르코프 헤드 (Lightweight Sequential Markov Head)
기존 병렬 방식(DFlash)의 치명적인 약점은 9개 단어를 서로 독립적으로 찍어내다 보니, 앞 단어와 뒷 단어 사이의 유기적인 문맥이 끊겨 뒤쪽 단어로 갈수록 사수에게 퇴짜를 맞을 확률이 급격히 높아진다는 점이었다.
DSpark는 인접한 단어 사이의 확률적 연결 고리를 잡아주는 마르코프 체인(Markov Chain) 순차 헤드를 덧붙였다. 방금 고른 단어와 자연스럽게 이어지도록 다음 단어의 확률을 보정해 줌으로써, 뒤쪽 위치에 있는 단어들의 수락률을 비약적으로 끌어올렸다. (예: 앞 단어가 ’인공’이면 다음 단어가 ’지능’이 되도록 유도).
③ 신뢰도 스케줄링 검증기 (Confidence-Scheduled Verifier)
인턴 모델이 스스로 “내가 쓴 7번째, 8번째 단어는 사수한테 거절당할 확률이 90%가 넘겠는데?“라고 판단하면, 사수가 헛걸음하지 않도록 신뢰도가 낮은 뒷단어를 미리 잘라내는 가지치기(Pruning) 기능이다.
4. 모델 크기와 학습: 손실률(Loss)과 수락률의 괴리
DSpark 드래프트 모델은 파라미터 수가 약 300M(0.3B) 안팎으로 매우 작다. 스마트폰이나 일반 노트북 메모리에도 전혀 부담 없이 올라갈 수 있는 크기다.
| 구성 요소 | LFM2.5-1.2B-Instruct | LFM2.5-2.6B | LFM2.5-8B-A1B |
|---|---|---|---|
| 디코더 스택 (5개 레이어) | 241.2M | 241.2M | 241.2M |
| 히든 상태 변환 프로젝션 | 21.0M | 21.0M | 21.0M |
| 마르코프 헤드 | 33.6M | 65.5M | 65.5M |
| 정규화 + 신뢰도 헤드 | 27.5k | 27.5k | 27.5k |
| 전체 파라미터 합계 | 295.7M | 327.7M | 327.7M |
[메모리 절약 팁] 단어를 벡터로 바꾸는 임베딩 레이어와 최종 출력 헤드는 본 모델의 가중치를 그대로 공유(Tied Weights)하여 드래프트 모델이 차지하는 용량을 대폭 줄였다.
Liquid AI는 이 모델들을 자체 개발한 프레임워크를 이용해 AMD GPU 하드웨어 클러스터에서 전량 학습시켰다.
[ 학습 중 관찰된 흥미로운 차이점 ]
- 1.2B 모델: 시험 점수(Loss)가 좋아짐 ────▶ 사수의 수락률도 정직하게 계속 올라감
- 2.6B 모델: 시험 점수(Loss)가 좋아짐 ────▶ 초반에만 수락률이 오르고 이후 정체(Plateau)
- 8B-A1B 모델: 시험 점수(Loss)가 좋아짐 ──▶ 수락률이 오르락내리락하며 불안정보통 딥러닝에서는 학습 손실률(Loss)이 떨어질수록 모델의 성능이 좋아졌다고 판단한다. 하지만 실험 결과, 2.6B나 8B 같은 상위 모델에서는 Loss가 계속 낮아지더라도 실제 벤치마크 테스트에서 사수가 인정해 주는 수락률은 조기에 멈추거나 출렁였다.
따라서 연구진은 단순히 Loss가 가장 낮은 체크포인트가 아니라, 실제 벤치마크 테스트에서 수락률이 가장 높게 측정된 에포크의 모델을 최종 배포 가중치로 선정했다.
5. 벤치마크 결과: 얼마나 빨라졌을까?
실험은 다음과 같은 환경에서 진행되었다.
- 클라우드 서버: NVIDIA H100 80GB (SGLang 추론 엔진)
- 온디바이스 노트북: Apple M4 Max 맥북 프로 (llama.cpp Metal 백엔드)
- DSpark 블록 크기: 9 (매번 최대 9개 단어 추측)
① LFM2.5-2.6B: 온디바이스 에이전트의 쾌적한 반응 속도
LFM2.5-2.6B는 복잡한 코딩과 생각(Reasoning), 도구 호출에 특화된 모델이다.
| 벤치마크 데이터셋 | 평균 수락 단어 수 (10개 중) | H100 속도 및 가속 배율 | M4 Max 속도 및 가속 배율 |
|---|---|---|---|
| MATH500 (수학) | 5.42개 | 326 ➔ 1,000 tok/s (3.06배) | 61 ➔ 137 tok/s (2.25배) |
| HumanEval (코딩) | 4.54개 | 326 ➔ 835 tok/s (2.56배) | 61 ➔ 161 tok/s (2.63배) |
| MBPP (파이썬 코딩) | 4.71개 | 326 ➔ 861 tok/s (2.64배) | 62 ➔ 132 tok/s (2.11배) |
| GSM8K (수학 추론) | 4.32개 | 312 ➔ 693 tok/s (2.22배) | 60 ➔ 143 tok/s (2.36배) |
| MT-Bench (대화) | 5.07개 | 325 ➔ 933 tok/s (2.87배) | 62 ➔ 123 tok/s (1.99배) |
| 평균 (Mean) | 4.81개 | 323 ➔ 864 tok/s (2.67배) | 61 ➔ 139 tok/s (2.27배) |
맥북에서 기본 초당 61토큰이던 속도가 초당 139토큰으로 2배 이상 껑충 뛰었다. 초당 140토큰 수준이면 사람이 화면을 보며 글을 읽는 속도를 아득히 넘어서며, 웬만한 클라우드 상용 API보다 체감상 훨씬 빠르다.
특히 중요한 포인트는 에이전트 함수 호출(Function Calling) 지연 시간 단축이다.
버클리 함수 호출 벤치마크(BFCL) [4] 측정 결과, 에이전트가 도구를 호출하기 전 거치는 사전 생각 과정의 대기 시간이 평균 57% 단축되었다. 로컬 노트북에서도 에이전트가 즉각 반응하는 사용자 경험을 제공할 수 있게 된 것이다.
② LFM2.5-1.2B-Instruct: 초경량 모델의 압도적 처리량
가장 가벼운 1.2B 모델의 경우 맥북(M4 Max)에서 초당 350~389토큰, H100 서버에서는 초당 1,384~1,712토큰이라는 엄청난 속도를 뿜어냈다.
6. MoE 모델의 역설: 8B-A1B는 왜 맥북에서 18%밖에 안 빨라졌을까?
이번 발표에서 컴퓨터 구조적으로 가장 흥미로운 대목은 바로 MoE(Mixture-of-Experts, 전문가 혼합) 구조를 가진 LFM2.5-8B-A1B의 실험 결과다.
| 테스트 환경 | 평균 수락 단어 수 | 기본 속도 ➔ DSpark 속도 | 실제 가속 배율 |
|---|---|---|---|
| H100 서버 (SGLang) | 6.95개 / 10개 | 418 ➔ 1,074 tok/s | 2.56배 (156% 향상) |
| M4 Max 맥북 (llama.cpp) | 6.95개 / 10개 | 90 ➔ 106 tok/s | 1.18배 (고작 18% 향상에 그침) |
수락률 자체는 10개 중 평균 6.95개로 세 모델 중 가장 높았다. 인턴이 사수의 의도를 가장 잘 맞혔다는 뜻이다. 그 덕분에 H100 서버에서는 2.54배로 훌륭하게 가속되었다.
그런데 맥북에서는 속도가 90 tok/s에서 106 tok/s로 겨우 18% 빨라지는 데 그쳤다. 적중률이 제일 높은데 왜 맥북에서는 거의 안 빨라졌을까?
[ 일반 Dense 모델의 일괄 검증 ]
- 단어 9개를 한 번에 검증해도 필요한 가중치는 본 모델 전체(고정된 1벌)
➔ 가중치를 1번 로드하는 비용으로 9개 단어 동시 처리 성공! (속도 대폭 상승)
[ MoE 모델의 일괄 검증 (엣지 디바이스의 복병) ]
- 1번 단어 검증: 1번, 3번 전문가 필요
- 2번 단어 검증: 2번, 5번 전문가 필요
- 3번 단어 검증: 1번, 8번 전문가 필요
...
➔ 9개 단어를 한 번에 검증하려니 매 단어마다 서로 다른 전문가들이 우르르 호출됨!
➔ 메모리(RAM)에서 꺼내와야 할 전문가 가중치 전송량(Weight Traffic)이 폭증!비밀은 MoE의 동적 전문가 호출 방식에 있다.
- 메모리 전송량 폭증: MoE 모델은 단어를 1개씩 만들 때는 특정 전문가 1~2명 분량의 가중치만 메모리에서 가져오면 된다. 하지만 9개 후보 단어를 한꺼번에 검증하려니 단어마다 서로 다른 전문가를 불러오게 되어, 한 번의 검증 스텝에서 메인 메모리(RAM)에서 GPU로 실어 날라야 하는 가중치 총량이 몇 배로 불어났다. 결국 좁은 메모리 통로가 다시 막혀버린 것이다.
- 커널 최적화 문제: 현재 llama.cpp의 애플 실리콘(Metal) 백엔드 커널이 여러 전문가 가중치를 병렬로 불러오는 처리에 아직 최적화되지 않은 점도 영향을 미쳤다.
Liquid AI는 이 아쉬운 결과를 숨기지 않고 벤치마크 수치를 투명하게 공개하며, 추후 온디바이스 MoE 가속을 위한 핵심 후속 연구 과제로 삼겠다고 밝혔다.
7. 동시 접속자가 많을 때는 어떨까? (Batch Size)
사용자가 1명이 아니라 여러 명이 동시에 요청을 보내는 클라우드 서빙 환경(Batch Size=128 등)에서는 상황이 또 달라진다.
배치 크기가 커지면 한 번에 계산해야 할 연산량이 많아지므로, 시스템은 자연스럽게 메모리 병목(Memory-bound)에서 연산 병목(Compute-bound) 영역으로 이동한다. 이에 따라 DSpark를 쓰든 안 쓰든 가속 차이가 점차 줄어들게 된다.
하지만 LFM2.5-8B-A1B (MoE) 모델의 경우, 배치 크기가 커져도 DSpark가 전 영역에서 확실한 우위를 유지했다. 동시 요청이 많아지면 기본 모델 역시 여러 사용자의 다양한 단어 때문에 수많은 전문가를 활성화해야 하므로, 추측 디코딩 때문에 생기던 전문가 로딩 오버헤드가 더 이상 불리하게 작용하지 않기 때문이다.
8. 지금 내 맥북에서 써보려면?
Liquid AI는 이번 발표와 동시에 오픈소스 생태계 지원을 마쳤다.
- 모델 다운로드: Hugging Face를 통해 Safetensors 및 GGUF 포맷으로 즉시 다운로드할 수 있다.
- llama.cpp 공식 지원: PR #27383을 통해 GGUF 드래프트 모델 및 Metal 커널 지원.
- SGLang 공식 지원: PR #31041을 통해 대규모 서버 서빙 지원.
llama.cpp 실행 명령어 예시
# llama-cli에서 본 모델(-m)과 DSpark 드래프트 모델(-md)을 함께 지정하여 실행
llama-cli \
-m ./LFM2.5-2.6B-Q4_K_M.gguf \
-md ./LFM2.5-2.6B-DSpark-Q4_K_M.gguf \
--draft-max 9 \
-p "Explain the concept of speculative decoding in simple terms."9. 마치며: 모델과 하드웨어의 공동 설계(Co-design)
Liquid AI의 LFM2.5-DSpark 발표가 주는 가장 큰 시사점은 다음과 같다.
- 진정한 로컬 온디바이스 에이전트 시대: 2.6B 모델의 생각 시간이 절반 이하로 줄어들면서, 내 노트북 안에서도 클라우드 API 부럽지 않은 빠릿빠릿한 에이전트를 돌릴 수 있게 되었다.
- 수학적 무손실 가속: 양자화(Quantization)처럼 모델의 뇌 용량을 깎아내는 방식이 아니라, 하드웨어 대역폭 낭비만 줄여서 정확도 100%를 지키는 가장 안전한 가속법을 증명했다.
- 하드웨어와 알고리즘의 결합: MoE 실험이 보여주었듯, 앞으로의 AI 모델 연구는 단순히 파라미터 크기만 키우는 것을 넘어 실제 컴퓨터의 메모리 구조와 하드웨어 특성을 고려해 모델과 추론 알고리즘을 함께 설계(Co-design)하는 방향으로 진화할 것임을 명확히 보여준다.
용어 정리
- 추측 디코딩 (Speculative Decoding): 작고 빠른 보조 모델(드래프트 모델)이 다음 단어 여러 개를 먼저 써두고, 큰 본 모델이 단 한 번의 계산으로 이를 일괄 검사하여 전체 추론 속도를 끌어올리는 기술.
- 메모리 바운드 (Memory-bound): 연산 장치의 계산 속도보다 메모리(RAM)에서 데이터를 읽어오는 통로가 좁아 전체 시스템 속도가 지연되는 현상.
- 마르코프 체인 헤드 (Markov Head): 바로 직전 단어의 상태만을 바탕으로 다음 단어의 등장 확률을 빠르고 가볍게 이어주는 신경망 모듈.
- MoE 전문가 가중치 트래픽 (MoE Weight Traffic): MoE 모델에서 여러 단어를 동시에 검사할 때, 각 단어가 요구하는 서로 다른 전문가(Expert) 모듈을 메모리에서 계속 불러오면서 발생하는 데이터 전송 부담.
- 품질 패리티 (Quality Parity): 가속 기술을 적용하더라도 원본 모델이 혼자서 생성했을 때의 결과 및 정확도와 100% 동일함을 유지하는 성질.
참고 문헌
- [1] Cheng et al. (2026). DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation. arXiv:2607.05147
- [2] Li et al. (2025). EAGLE-3: Scaling up Inference Acceleration of Large Language Models via Training-Time Test. OpenReview
- [3] Chen et al. (2026). DFlash: Block Diffusion for Flash Speculative Decoding. arXiv:2602.06036
- [4] Patil et al. (2025). The Berkeley Function Calling Leaderboard (BFCL): From Tool Use to Agentic Evaluation of Large Language Models. PMLR
- [5] Liquid AI Blog. (2026-08-20). LFM2.5-DSpark: Up to 3.2x Faster Inference from H100 to MacBook. Liquid AI Blog