LFM2.5-VL에 DSpark 추측 디코딩 붙여 3배 빠르게 돌리기

LFM2.5-VL-3B 같은 소형 VLM도 이미지 한 장 넣으면 수백 개 비주얼 토큰이 프리필을 잡아먹어, 디코딩만 빨라선 끝-to-끝 지연이 별로 안 줄어듭니다. Liquid AI가 이 병목을 뚫으려고 텍스트용 DSpark와 같은 아키텍처로 비전 드래프터를 내놨고, 파라미터 8.9%만 더해 디코딩 2~3배·전체 1.3~2.6배 가속을 실측했습니다. 아래에서는 원리·한계·설치·실행까지 현업 관점에서 바로 써먹게 정리합니다.

DSpark 드래프터란 무엇인가

DSpark 드래프터는 Liquid AI가 LFM2.5-VL-3B에 붙인 추측 디코딩(speculative decoding) 전용 소형 모델입니다. 타깃 모델의 특정 레이어에서 히든 스테이트를 탭(tap)해 가져온 뒤, 이를 조건으로 블록 단위(k개) 후보 토큰을 한 번에 예측합니다. 텍스트 토큰과 이미지 패치를 미리 공통 차원으로 투영해 두었기 때문에, 드래프터는 입력 모달리티(텍스트·비전)와 무관하게 동일한 차원의 히든 벡터만 받아 동작합니다. 덕분에 텍스트 전용 LFM2.5-DSpark와 추론 알고리즘을 완전히 공유할 수 있습니다.

4-레이어 어텐션-온리 구조와 블록 크기

드래프터 본체는 어텐션만 4개 레이어로 구성된 경량 네트워크입니다. 3·4·5 레이어 에블레이션 결과, 4 레이어가 품질·속도 균형에서 가장 좋았고, 학습은 비전-언어 SFT 데이터를 혼합해 10 에폭 돌렸습니다. 학습 초반엔 수용률(acceptance rate)이 오르다가 나중엔 수렴했습니다. 추론 땐 하드웨어에 따라 블록 크기 8 또는 9를 권장합니다. 파라미터는 약 2억 8천만 개로, 3B 타깃 대비 8.9%만 늘어납니다.

텍스트·비전 공통 히든 스테이트 탭 방식

이미지 패치와 텍스트 토큰은 타깃 모델 초반 레이어에서 공통 표현(shared representation)으로 투영됩니다. 드래프터는 고정된 탭 레이어 집합에서 히든 스테이트를 읽어오며, 모달리티 구분 없이 동일 차원 벡터를 받아 블록 단위 후보를 만듭니다. 이 덕분에 추론 루프(드래프트→검증→수락/리젝트)는 텍스트 모델과 완전히 동일하게 돌아갑니다.

# 개념적 구조
Vision Encoder → Projector → Shared Hidden States ← Text Embedding
                              ↓ (tap at fixed layers)
                    DSpark Drafter (4-layer attention-only)
                              ↓
                      Block of k candidate tokens

왜 지금 VLM에 추측 디코딩이 필요한가

비전-언어 모델(VLM)에서 추측 디코딩(speculative decoding) 이 다시 주목받는 건, 비전 인코더와 긴 프리필(prefill) 단계가 전체 지연 시간의 대부분을 차지하기 때문입니다. LLM에서는 프리필이 주로 연산 바운드(compute-bound)여서 프롬프트 길이에 따라 (준)2차적으로 비용이 늘지만, VLM은 이미지가 비전 인코더를 통과한 뒤 수백 개의 비주얼 토큰이 언어 백본과 함께 처리되므로 이 구간이 더 무겁습니다. 엣지 디바이스는 데이터센터 GPU보다 연산 자원이 훨씬 적어, 첫 토큰 생성까지의 시간(time-to-first-token)에서 프리필 비중이 압도적입니다. 이 구조에서 디코딩만 가속해도 체감 속도가 어디까지 좋아질 수 있는지가 관건입니다.

자료가 보여주는 수치적 증거

자료의 벤치마크에서도 디코딩 구간은 최대 3.13×까지 빨라지지만, 엔드투엔드 기준으로는 1.30×~2.62×에 머무릅니다. 프리필과 비전 인코딩이 병목으로 남아 전체 향상 폭을 제한하는 전형적인 암달의 법칙 상황입니다. 그래도 디코딩 가속만으로 체감 생성 속도(초당 토큰 수)를 2~3배 끌어올릴 수 있다는 점은, 긴 답변을 스트리밍하는 챗·요약·코딩 어시스턴트 등에서 사용자 경험을 크게 개선합니다.

드래프터 학습 레시피와 하이퍼파라미터

DSpark 드래프터 학습은 비전-언어 SFT 데이터 혼합을 대상으로 진행합니다. 작업별 가중치를 우리가 기대하는 서빙 워크로드 쪽으로 치우치게 조정했고, 3·4·5 레이어 에이블레이션을 거쳐 어텐션 전용 4-레이어 구조에 블록 크기 9로 고정했습니다. 전체 혼합 데이터에 대해 10 에폭을 돌렸고, 에폭마다 수용률(acceptance rate)을 측정해 추가 토큰이 더 이상 효과를 내지 않는 지점에서 멈췄습니다. 그 결과 드래프터는 약 2억 8천만 파라미터로, 타깃 모델 대비 8.9%만 늘어납니다.

학습 하이퍼파라미터 요약

추론 시에는 하드웨어에 따라 블록 크기 8 또는 9를 권장합니다. 블록 크기는 드래프트 모델의 config.json에 기록돼 있어 별도 지정 없이도 읽힙니다. SGLang에서는 --speculative-dspark-block-size 9로 명시해도 되고, llama.cpp/MLX-VLM에서는 설정 파일 값이 자동 적용됩니다.

python -m sglang.launch_server \
--model-path LiquidAI/LFM2.5-VL-3B \
--speculative-algorithm DSPARK \
--speculative-draft-model-path LiquidAI/LFM2.5-VL-3B-DSpark \
--speculative-draft-attention-backend flashinfer \
--speculative-dspark-block-size 9

llama-server -m models/LFM2.5-VL-3B-F16.gguf \
--mmproj models/mmproj-LFM2.5-VL-3B-F16.gguf \
-md LFM2.5-VL-3B-DSpark.gguf

실측 벤치마크: 온디바이스(M5 Max/M3 Ultra) vs H100

자료에 공개된 6개 비전 태스크(일반 VQA, 텍스트 VQA, 이미지 캡셔닝, 차트 VQA, 복합 추론, 멀티턴 대화)에서 디코딩 단계 가속비와 엔드투엔드 가속비를 정리했습니다. 온디바이스(M5 Max·M3 Ultra)와 데이터센터 GPU(H100) 모두 DSpark 블록 크기 8로 측정했으며, 드래프터는 타깃 모델 파라미터의 8.9%(약 280M)만 추가합니다.

병목 구간 시각화: 프리필·비전 인코딩이 엔드투엔드 이득을 제한

자료는 암달의 법칙(Amdahl's law) 관점에서 병목을 설명합니다. LLM에서 프리필은 주로 연산 바운드이며 프롬프트 길이에 따라 (서브)제곱으로 비용이 늘고, VLM은 비전 인코더 → 비주얼 토큰 수백 개 + 텍스트 프롬프트 → 언어 백본 순서로 처리돼 프리필 비중이 더 커집니다. 엣지 디바이스는 데이터센터 GPU보다 연산 자원이 적어 time-to-first-token(프리필+인코딩)이 전체 지연시간에서 차지하는 비율이 높습니다.

• 비전 인코딩 + 프리필: 가속되지 않음 (DSpark는 디코딩만 타깃)
• 디코딩: 최대 3.13×(온디바이스) / 2.66×(H100) 빨라짐
• 결과: 프리필·인코딩이 이미 벽시계 시간의 큰 몫을 차지하면, 디코딩 가속이 커도 엔드투엔드 이득은 1.30×~2.62×에 머무름

세 런타임(llama.cpp·MLX·SGLang) 적용 명령 한눈에 보기

세 런타임 모두 드래프터 블록 크기를 8~9로 권장합니다. 아래 스니펫을 복사해 바로 실행하면 LFM2.5-VL-3B에 DSpark 추측 디코딩을 붙여 쓸 수 있습니다.

SGLang (H100·GPU 서버)

python -m sglang.launch_server \
  --model-path LiquidAI/LFM2.5-VL-3B \
  --speculative-algorithm DSPARK \
  --speculative-draft-model-path LiquidAI/LFM2.5-VL-3B-DSpark \
  --speculative-draft-attention-backend flashinfer \
  --speculative-dspark-block-size 9

llama.cpp (Apple Silicon·CPU 추론)

llama-server -m models/LFM2.5-VL-3B-F16.gguf \
  --mmproj models/mmproj-LFM2.5-VL-3B-F16.gguf \
  -md models/LFM2.5-VL-3B-DSpark-F16.gguf \
  --spark-block-size 8

GGUF 포맷 기준 타깃 모델·비전 프로젝터·드래프터 경로를 각각 -m, --mmproj, -md로 지정합니다. --spark-block-size는 8 또는 9로 두고 하드웨어에 맞춰 조정하세요.

MLX-VLM (M 시리즈 맥 온디바이스)

from mlx_vlm import load, generate
model, processor = load(
    "LiquidAI/LFM2.5-VL-3B",
    draft_model="LiquidAI/LFM2.5-VL-3B-DSpark",
    draft_block_size=8,
)
response = generate(model, processor, "이 이미지를 설명해줘.", image="test.jpg")
print(response)

load()에 draft_model과 draft_block_size만 추가하면 별도 서버 없이 로컬에서 바로 추측 디코딩이 동작합니다. 블록 크기 8이 M5 Max·M3 Ultra에서 가장 안정적인 처리량을 보였습니다.

주의할 점과 다음 스텝

DSpark 드래프터를 실운영에 올리기 전 반드시 짚어야 할 제약과 체크리스트를 정리합니다. 가장 큰 한계는 프리필(prefill)과 비전 인코딩 구간을 가속하지 못한다는 점입니다. 이미지가 비전 인코더를 통과해 수백 개의 비주얼 토큰이 생성되고, 이 토큰이 텍스트 프롬프트와 함께 언어 백본의 프리필을 거치는 동안에는 추측 디코딩이 작동하지 않기 때문입니다. 온디바이스 환경(M5 Max, M3 Ultra)에서는 이 프리필·인코딩 비중이 전체 지연시간의 큰 부분을 차지하므로, 디코딩이 2~3배 빨라져도 엔드투엔드 지연시간 개선은 1.3~2.6배 수준에 머뭅니다(암달의 법칙).

블록 크기(block size) 하드웨어별 튜닝

드래프터 메모리 오버헤드 8.9%

SGLang 플래시어텐션(flashinfer) 빌드 의존성

SGLang에서 DSpark를 쓰려면 DSpark 지원·LFM2 타겟이 포함된 커스텀 SGLang 빌드와 flashinfer 어텐션 백엔드가 필요합니다. 공식 PyPI 휠에는 빠져 있을 수 있으므로, 소스 빌드 또는 Liquid AI가 제공하는 프리빌드 이미지를 사용해야 합니다. --speculative-draft-attention-backend flashinfer 플래그를 빼면 추측 경로가 비활성화됩니다.

python -m sglang.launch_server \
  --model-path LiquidAI/LFM2.5-VL-3B \
  --speculative-algorithm DSPARK \
  --speculative-draft-model-path LiquidAI/LFM2.5-VL-3B-DSpark \
  --speculative-draft-attention-backend flashinfer \
  --speculative-dspark-block-size 9

llama.cpp·MLX 빌드 버전 확인

운영 체크리스트 요약

• 프리필·비전 인코딩 비중 측정 후 엔드투엔드 목표치 재산정
• 타깃 하드웨어별 블록 크기 8 vs 9 A/B 테스트
• 드래프터 포함 메모리 예산(베이스 + 8.9%) 확보
• SGLang 커스텀 빌드(flashinfer) 또는 llama.cpp/MLX 최신 빌드 준비
• 배포 후 수용률(acceptance rate) 모니터링으로 드리프트 감지

• 원문 보기