# Liquid AI, VLM 디코딩 속도를 2.66~3.13배 가량 높인 LFM2.5-VL-3B-DSpark 모델 공개

**URL:** <https://discuss.pytorch.kr/t/liquid-ai-vlm-2-66-3-13-lfm2-5-vl-3b-dspark/12019>\
**Category:** 읽을거리&정보공유\
**Tags:** vlm, lfm2-5, product-launch, liquid-ai, speculative-decoding, dspark, llm-inference, on-device\
**Created:** [9월 28, 2026, 7:30오전 UTC](https://discuss.pytorch.kr/t/liquid-ai-vlm-2-66-3-13-lfm2-5-vl-3b-dspark/12019 "2026-09-28T07:30:31Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![9bow](https://discuss.pytorch.kr/user_avatar/discuss.pytorch.kr/9bow/32/16301_2.png) [@9bow](https://discuss.pytorch.kr/u/9bow)\
**Post date:** [9월 28, 2026, 7:30오전 UTC](https://discuss.pytorch.kr/t/liquid-ai-vlm-2-66-3-13-lfm2-5-vl-3b-dspark/12019/1 "2026-09-28T07:30:31Z")

</div>

![LFM2.5-VL-3B-DSpark가 비전 인코딩과 프리필 이후의 디코딩 단계만 추측 디코딩으로 가속하는 과정을 그린 PyTorchKR 히어로 이미지](https://discuss.pytorch.kr/uploads/default/original/3X/7/8/7842ca215574890d89226e4be83309285a7854cf.jpeg)

## LFM2.5-VL-3B-DSpark 소개

LFM2.5-VL-3B-DSpark는 [Liquid AI](https://www.liquid.ai)가 자사의 비전-언어 모델(VLM, Vision-Language Model) [LFM2.5-VL-3B](https://huggingface.co/LiquidAI/LFM2.5-VL-3B)를 위해 공개한 약 280M 파라미터 규모의 **추측 디코딩(Speculative Decoding)** 용 초안 모델(Draft Model)로, 출력은 그대로 유지하면서 디코딩 속도를 H100에서 최대 2.66배, Apple M5 Max에서 최대 3.13배까지 높입니다. 본 모델 대비 파라미터가 8.9% 늘어나는 비용으로 얻는 속도 향상이며, [llama.cpp](https://github.com/ggml-org/llama.cpp), [MLX-VLM](https://github.com/Blaizzy/mlx-vlm) (:pytorch::kr: [mlx-vlm: M5와 같은 Apple Silicon에 최적화된 MLX 기반 시각-언어 모델(VLM) 추론 및 파인튜닝 도구](https://discuss.pytorch.kr/t/mlx-vlm-m5-apple-silicon-mlx-vlm/8963)), [SGLang](https://github.com/sgl-project/sglang)이 공개 첫날부터 지원합니다(SGLang은 아직 정식 릴리스 전이라 main 브랜치 빌드가 필요합니다).

LLM 추론의 디코딩 단계는 토큰을 하나 만들 때마다 전체 가중치를 메모리에서 읽어 와야 하므로 연산량보다 메모리 대역폭이 속도를 결정합니다. 추측 디코딩은 이 구조를 이용합니다. 작은 초안 모델이 다음 토큰 여러 개를 먼저 제안하고, 본 모델(Target Model)이 이 후보들을 한 번의 순전파로 검증하면 가중치를 한 번 읽는 비용으로 여러 토큰을 얻을 수 있습니다. 본 모델이 모든 후보를 검증하기 때문에 탐욕적 디코딩(Greedy Decoding)에서는 본 모델 혼자 생성한 결과와 글자 하나까지 같습니다.

이번에 소개하는 DSpark 초안 모델은 Liquid AI가 2026년 8월에 공개한 [텍스트 모델용 LFM2.5-DSpark](https://huggingface.co/blog/LiquidAI/lfm25-dspark)를 비전-언어 모델로 확장한 실험적 릴리스입니다. 흥미로운 점은 Liquid AI가 속도 향상 수치와 함께 그 한계도 정량적으로 공개했다는 것입니다. 이미지가 들어가는 VLM은 텍스트 LLM보다 프리필(Prefill) 비중이 크고, 추측 디코딩은 디코딩 단계만 빠르게 하므로 엣지 기기에서는 디코딩 속도 향상이 종단 간(End-to-End) 속도 향상으로 그대로 이어지지 않습니다. 아래에서 DSpark의 동작 원리, 학습 과정, 하드웨어별 결과와 이 한계를 순서대로 살펴보겠습니다.

## 추측 디코딩 방식 DSpark의 구성 요소

DSpark는 DeepSeek-AI와 베이징대학교 연구진이 [DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive Generation](https://arxiv.org/abs/2607.05147) 논문에서 제안한 추측 디코딩 방식으로, 논문에 따르면 DeepSeek-V4 서빙 시스템에 배포해 기존 방식인 MTP-1(Multi-Token Prediction) 대비 같은 처리량에서 사용자당 생성 속도를 V4-Flash는 60~85%, V4-Pro는 57~78% 높였습니다. DeepSeek은 DSpark를 포함한 초안 모델 학습 코드도 [DeepSpec](https://github.com/deepseek-ai/DeepSpec) (:pytorch::kr: [DeepSpec: 추측 디코딩 초안 모델을 학습하고 평가하는 DeepSeek의 풀스택 코드베이스](https://discuss.pytorch.kr/t/deepspec-deepseek/11049))으로 공개했습니다. 추측 디코딩 계열에는 [EAGLE-3](https://arxiv.org/abs/2503.01840)처럼 초안 토큰을 하나씩 자기회귀로 만드는 방식과 [DFlash](https://arxiv.org/abs/2602.06036) (:pytorch::kr: [DFlash: 블록 확산(Block Diffusion) 기반으로 LLM 추론 속도를 높이는 오픈소스 라이브러리 (feat. Z.ai)](https://discuss.pytorch.kr/t/dflash-block-diffusion-llm-feat-z-ai/9849))처럼 한 번의 순전파로 블록 전체를 만드는 병렬 방식이 있는데, DSpark는 두 방식을 결합한 **반자기회귀(Semi-Autoregressive)** 구조입니다. Liquid AI의 텍스트 DSpark 블로그는 이를 다음 세 요소로 정리합니다.

- **DFlash 방식의 병렬 백본(Parallel Block)**: 본 모델의 은닉 상태(Hidden State)를 조건으로 삼아 초안 토큰 전체의 은닉 상태를 한 번의 순전파로 만듭니다.

- **가벼운 순차 헤드(Sequential Block)**: 이웃한 토큰 사이를 마르코프 체인(Markov Chain)으로 모델링해 토큰 간 의존성을 추가합니다. 병렬 초안은 블록 뒤쪽으로 갈수록 채택률(Acceptance Rate)이 빠르게 떨어지는데, 이 헤드가 뒤쪽 위치의 채택률을 높입니다.

- **신뢰도 기반 검증 스케줄러(Confidence-Scheduled Verifier)**: 각 초안 토큰이 살아남을 확률을 예측하고, 검증 비용이 얻는 이득보다 클 때는 신뢰도가 낮은 뒤쪽 토큰을 잘라냅니다.

 ![DSpark의 3단계 동작, 본 모델 프리필과 초안 모델의 블록 제안, 본 모델의 검증을 나타낸 도식](https://discuss.pytorch.kr/uploads/default/original/3X/0/4/0496ab3eb661ae3a26a213a1e4724f7c47561e36.png)

위 그림은 텍스트 DSpark의 흐름입니다. 본 모델이 프롬프트를 처리한 뒤(1단계), 초안 모델이 `MASK` 자리에 들어갈 토큰 블록을 제안하고 스케줄러가 뒤쪽 `H` 를 버립니다(2단계). 본 모델은 남은 `E, F, G` 를 한 번에 검증해 `E, F` 를 채택하고, 거부된 `G` 자리에는 본 모델 자신의 토큰 `G*` 를 넣습니다(3단계).

### VLM에서도 추론 알고리즘이 그대로인 이유

비전-언어 모델로 확장할 때 초안 모델 구조나 추론 알고리즘을 바꿀 필요는 없었습니다. 초안 모델은 본 모델의 정해진 몇 개 층에서 은닉 상태를 가져와 조건으로 쓰는데, 이미지 패치와 텍스트 토큰은 그 층에 도달하기 전에 이미 같은 차원의 표현으로 투영되어 있습니다. Liquid AI는 초안 모델 입장에서는 입력이 문단인지 이미지인지가 초안 계산에 아무 차이를 만들지 않으며, 그래서 텍스트 모델과 똑같은 추론 알고리즘을 적용할 수 있었다고 설명합니다.

 ![이미지 패치와 텍스트 토큰을 입력받은 본 모델의 KV를 초안 모델에 주입하는 비전-언어 모델용 DSpark 구조도](https://discuss.pytorch.kr/uploads/default/original/3X/0/7/07e0fa18c231509f30ebddff4d49f0c9230e213f.png)

## LFM2.5-VL-3B-DSpark의 학습과 모델 구성

본 모델인 LFM2.5-VL-3B는 [LFM2.5-2.6B](https://huggingface.co/LiquidAI/LFM2.5-2.6B) (:pytorch::kr: [Liquid AI, 휴대폰에서 실행 가능한 온-디바이스 에이전트 모델 LFM2.5-2.6B 공개](https://discuss.pytorch.kr/t/liquid-ai-lfm2-5-2-6b/11549)) 언어 모델에 400M 규모의 [SigLIP2 NaFlex](https://huggingface.co/google/siglip2-so400m-patch16-naflex) 비전 인코더를 결합한 모델입니다. 초안 모델은 텍스트 DSpark의 레시피를 따르되, 서비스할 워크로드 비중에 맞춘 비전-언어 지도 미세조정(SFT, Supervised Fine-Tuning) 데이터 혼합으로 학습했습니다. 3, 4, 5개 층으로 절제 실험(Ablation)을 거쳐 어텐션 층만 4개 둔 단순화된 구조와 블록 크기 9를 골랐고, 모든 절제 실험과 학습은 AMD 하드웨어에서만 수행했다고 밝혔습니다.

| 구성 요소 | 파라미터 수 |
| --- | --- |
| 디코더 스택 (4개 층) | 193.0M |
| 은닉 상태 투영 (Hidden-state projection) | 21.0M |
| 마르코프 헤드 (Markov head) | 65.5M |
| 정규화 층과 신뢰도 헤드 (Norms + confidence head) | 6.4k |
| **합계** | **279.5M** |

임베딩과 LM 헤드는 본 모델과 공유하므로 초안 모델에 들어 있지 않습니다. [모델 카드](https://huggingface.co/LiquidAI/LFM2.5-VL-3B-DSpark)에 따르면 백본은 `hidden_size=2048`, `intermediate_size=6144`, 그룹 쿼리 어텐션(GQA, Grouped-Query Attention) 헤드 32개와 KV 헤드 8개로 구성되고, 마르코프 헤드의 랭크는 256입니다. 텍스트 모델용 초안 모델이 5개 층, 약 300M 파라미터였던 것과 비교하면 층이 하나 줄었습니다.

 ![학습 토큰이 늘어남에 따라 평균 채택 길이는 3.55에서 4.16으로 오르고 학습 손실은 9번째 에폭에서 가장 낮은 LFM2.5-VL-3B-DSpark 학습 곡선](https://discuss.pytorch.kr/uploads/default/original/3X/8/e/8e691fe9241d6e3d88aea627f16a0e88679433ad.png)

학습은 최종 데이터 혼합으로 10 에폭(총 약 213B 토큰)을 진행하며 에폭마다 채택률을 측정했습니다. 위 그래프에서 검증 1회당 평균 채택 토큰 수는 첫 에폭 3.55에서 마지막 에폭 4.16까지 올라갔고, 뒤로 갈수록 증가 폭이 줄어듭니다. 학습 손실이 가장 낮은 지점(9번째 에폭)과 채택 길이가 가장 긴 지점(10번째 에폭)이 일치하지 않는다는 점도 보입니다. 텍스트 DSpark에서도 Liquid AI는 손실이 가장 낮은 에폭이 아니라 채택률이 가장 높은 에폭을 골랐는데, 초안 모델의 목적이 본 모델과 같은 토큰을 맞히는 것이기 때문입니다.

## 하드웨어별 추론 속도 향상

평가는 비전-언어 모델용 추측 디코딩 벤치마크인 [MMSpec](https://arxiv.org/abs/2603.14989)을 따라 일반 VQA(GQA), 텍스트 VQA(TextVQA), 이미지 캡셔닝(COCO), 차트 VQA(CharXiv), 복합 추론(MMMU-Pro), 멀티턴 대화의 6개 과제로 진행했습니다. 모든 측정은 비전 인코더와 언어 백본 모두 16비트로 처리했고, 배치 크기 1과 온도(Temperature) 0에서 [Pipette](https://pipette.liquid.ai/) 벤치마크 인프라로 수집했습니다. 양자화(Quantization) 모델의 가속은 이번 릴리스 범위에서 제외했습니다.

아래 영상은 M5 Max MacBook Pro에서 MLX로 같은 질문을 실행한 예시로, 본 모델만 쓴 경우 67 tok/s, DSpark를 붙인 경우 220 tok/s가 나옵니다(요청 하나의 예시라 아래 과제별 평균과는 차이가 있습니다).

![M5 Max MacBook Pro에서 LFM2.5-VL-3B 베이스라인 67 tok/s와 LFM2.5-VL-3B-DSpark 220 tok/s를 비교하는 데모](https://discuss.pytorch.kr/uploads/default/original/3X/f/d/fda667a3e745cf7218f069ca442f9863cf060b83.gif)

### 온디바이스 추론: Apple M5 Max와 M3 Ultra

온디바이스 측정은 M5 Max MacBook Pro에서 MLX-VLM, M3 Ultra에서 llama.cpp로 수행했고, FP16 가중치, 블록 크기 8, 최대 2,048개 출력 토큰(답변 길이 중앙값 90 토큰) 조건입니다. M5 Max에서는 과제별로 디코딩이 2.30~3.13배, 종단 간 속도가 1.56~2.62배 빨라졌고, M3 Ultra에서는 디코딩 1.57~2.14배, 종단 간 1.30~1.77배였습니다. 채택 토큰 수는 두 환경 모두 검증 1회당 약 3.2~4.5개로 비슷해, Liquid AI는 채택률이 하드웨어나 런타임보다 초안 모델과 워크로드에 좌우된다고 해석합니다.

 ![Apple M5 Max(MLX)와 M3 Ultra(llama.cpp)에서 과제별 프리필과 디코딩 시간, 종단 간 및 디코딩 속도 향상과 채택 토큰 수를 비교한 LFM2.5-VL-3B-DSpark 온디바이스 결과](https://discuss.pytorch.kr/uploads/default/original/3X/4/c/4cbed68d1ce6a74d00e001aa0c20d0f2eaec44ca.png)

### GPU 추론: NVIDIA H100

GPU 측정은 H100 80GB 한 장에서 SGLang, BF16, 블록 크기 9 조건입니다. 디코딩은 2.04~2.66배, 종단 간 속도는 1.64~2.27배 빨라졌고, 채택 토큰 수는 3.46~4.57개였습니다.

 ![NVIDIA H100에서 SGLang으로 측정한 LFM2.5-VL-3B-DSpark의 과제별 프리필과 디코딩 시간 및 속도 향상](https://discuss.pytorch.kr/uploads/default/original/3X/7/5/7599fdee8e6d42c00577e2960c1309ab3249b36c.png)

모델 카드에 공개된 과제별 수치를 정리하면 다음과 같습니다. 각 셀은 **디코딩 / 종단 간** 속도 향상입니다.

| 과제 | 1×H100 (SGLang) | Apple M5 Max (MLX-VLM) | Apple M3 Ultra (llama.cpp) |
| --- | --- | --- | --- |
| MMMU-Pro | 2.43× / 1.97× | 2.93× / 2.62× | 2.03× / 1.74× |
| Multi-turn | 2.04× / 1.83× | 2.30× / 1.91× | 1.57× / 1.37× |
| COCO | 2.66× / 2.27× | 3.13× / 2.59× | 2.14× / 1.77× |
| CharXiv | 2.39× / 1.97× | 2.94× / 1.71× | 1.87× / 1.56× |
| TextVQA | 2.14× / 1.64× | 2.69× / 1.56× | 1.64× / 1.33× |
| GQA | 2.35× / 1.77× | 2.67× / 1.93× | 1.77× / 1.30× |

위 표에서 디코딩 속도 향상이 비슷해도 종단 간 향상은 과제에 따라 크게 달라지는 것이 눈에 띕니다. M5 Max에서 CharXiv(2.94×)와 MMMU-Pro(2.93×)의 디코딩 향상은 거의 같지만, 종단 간 향상은 각각 1.71배와 2.62배입니다. 이 차이는 아래 한계 섹션에서 다룹니다.

## 동시 요청 수와 샘플링 온도에 따른 변화

### 처리량과 사용자당 속도의 트레이드 오프

배치 크기 1 이외의 조건도 측정했습니다. 동시 요청 수(Concurrency)를 늘리면 전체 시스템 처리량(Throughput)은 늘지만 사용자 한 명이 체감하는 생성 속도는 줄어드는데, 이 **처리량과 상호작용성의 트레이드 오프(Throughput-Interactivity Trade-off)** 를 그래프로 그린 것이 아래 그림입니다. 동시 요청이 많아지면 산술 강도(Arithmetic Intensity)가 높아져 디코딩이 메모리 병목에서 연산 병목으로 옮겨 가고, DSpark는 한 번에 여러 토큰을 검증하므로 블록 크기에 비례해 산술 강도가 더 높아집니다.

 ![H100에서 배치 크기 1부터 64까지 DSpark 적용 여부에 따른 전체 처리량과 사용자당 처리량을 과제별로 비교한 그래프](https://discuss.pytorch.kr/uploads/default/original/3X/5/4/54ebd05ae12d0bd07c3331e5e4b594b27008e308.png)

Liquid AI는 측정한 모든 동시 요청 수준에서 DSpark가 처리량 우위를 유지하지만, 동시 요청이 늘수록 격차는 줄어든다고 밝혔습니다. 차트 원본 데이터에서 COCO를 예로 들면, 배치 크기 1의 사용자당 속도는 329 tok/s에서 875 tok/s로, 배치 크기 64의 전체 처리량은 9,211 tok/s에서 16,562 tok/s로 늘었습니다. 동시 요청 수가 많은 서빙 환경에서의 초안 길이 조절은 [Cohere의 동적 추측 디코딩(DSD) 정리 글](https://discuss.pytorch.kr/t/dsd-feat-cohere/11200)에서도 다룬 주제입니다.

### 샘플링 온도가 채택률에 미치는 영향

온도가 0보다 크면 초안 모델이 자신의 분포에서 토큰을 샘플링하고, 본 모델은 이를 채택하거나 보정된 토큰을 다시 뽑습니다. [Leviathan et al. (2023)](https://arxiv.org/abs/2211.17192)이 증명했듯, 샘플링 설정을 맞추면 추측 디코딩의 결과는 본 모델에서 직접 샘플링한 것과 같은 분포를 따르므로 출력 품질에는 손실이 없습니다. 달라지는 것은 속도입니다.

 ![H100과 SGLang에서 MMMU-Pro 과제의 샘플링 온도 0부터 1.0까지 평균 채택 토큰 수와 디코딩 속도 향상 변화](https://discuss.pytorch.kr/uploads/default/original/3X/f/8/f88ef9a484b71f1ebe52166548a7a0deaf388fb2.png)

온도가 낮을 때는 초안 모델과 본 모델이 같은 상위 토큰에 확률을 모으지만, 온도가 높아지면 확률이 순위가 낮은 후보로 퍼지면서 두 모델이 어긋날 가능성이 커집니다. H100에서 MMMU-Pro로 측정한 결과, 온도를 0에서 1.0으로 올리면 평균 채택 토큰 수는 4.00에서 3.25로, 디코딩 속도 향상은 2.40배에서 1.91배로 낮아졌습니다.

## 엣지 VLM에서 추측 디코딩의 한계: 암달의 법칙

LLM 추론에서 프리필은 대체로 연산 병목이며 비용이 프롬프트 길이에 따라 (준)이차적으로 늘어납니다. VLM은 여기에 비용이 더해집니다. 이미지가 먼저 비전 인코더를 통과하고, 언어 백본은 비전 인코더가 만든 수백 개의 시각 토큰을 텍스트 프롬프트와 함께 처리해야 합니다. 엣지 기기는 데이터센터 GPU보다 연산 성능이 훨씬 낮으므로 종단 간 지연 시간(Latency)에서 프리필이 차지하는 비중이 커집니다. Liquid AI는 M5의 GPU 코어마다 추가된 뉴럴 가속기가 이 격차를 일부 줄인다고 덧붙였습니다.

추측 디코딩은 디코딩 단계만 가속하고 비전 인코딩과 프리필은 그대로 둡니다. 이런 상황에서 전체 속도 향상의 상한은 [암달의 법칙(Amdahl's Law)](https://en.wikipedia.org/wiki/Amdahl%27s_law)으로 계산할 수 있습니다. 전체 시간 중 가속되는 비율을 p , 그 부분의 속도 향상을 s 라고 하면 전체 속도 향상 S 는 다음과 같습니다.

S = \frac{1}{(1 - p) + \frac{p}{s}}

앞의 M5 Max 차트 원본 데이터로 이 식을 확인해 보겠습니다. TextVQA는 베이스라인 요청 시간 약 1,075ms 가운데 첫 토큰까지의 시간(TTFT, Time To First Token)이 464ms로 43%를 차지하므로 p \approx 0.57 이고, 디코딩이 s = 2.69 배 빨라져도 S \approx 1.56 배에 그칩니다. 실측 종단 간 향상도 1.56배입니다. 반면 답변이 긴 MMMU-Pro는 TTFT가 약 4,190ms 중 268ms(6%)뿐이라, 디코딩 2.93배가 종단 간 2.62배로 대부분 이어졌습니다. 즉 디코딩보다 프리필 비중이 큰 과제일수록 종단 간 이득이 줄어듭니다. 반대로 프리필과 비전 인코딩 쪽을 줄이는 접근은 [NVIDIA Dynamo의 E-P-D 분리 서빙 정리 글](https://discuss.pytorch.kr/t/e-p-d-ttft-93-feat-nvidia-dynamo/11883)을 함께 참고하면 좋습니다. 두 방식은 VLM 추론 시간의 서로 다른 구간을 줄입니다.

## LFM2.5-VL-3B-DSpark 사용 방법

초안 모델은 [Safetensors](https://huggingface.co/LiquidAI/LFM2.5-VL-3B-DSpark)와 [GGUF](https://huggingface.co/LiquidAI/LFM2.5-VL-3B-DSpark-GGUF) 형식으로 제공되며, 각각 [LFM2.5-VL-3B](https://huggingface.co/LiquidAI/LFM2.5-VL-3B)와 [LFM2.5-VL-3B-GGUF](https://huggingface.co/LiquidAI/LFM2.5-VL-3B-GGUF) 본 모델과 짝을 이뤄 사용합니다. 아래 명령은 모델 카드에 공개된 예시입니다.

**SGLang (NVIDIA GPU)**: 모델 카드는 [SGLang v0.5.19](https://github.com/sgl-project/sglang/releases/tag/v0.5.19) 이상을 요구 사항으로 적고 있지만, LFM2-VL용 DSpark 지원([PR #40651](https://github.com/sgl-project/sglang/pull/40651))은 9월 22일에 병합되어 v0.5.19(텍스트 LFM2용 DSpark만 포함)와 최신 릴리스 v0.5.20(9월 18일)에는 들어 있지 않습니다. 다음 릴리스 전까지는 main 브랜치 빌드가 필요합니다(2026년 9월 27일 기준). 서버를 띄운 뒤 OpenAI 호환 엔드포인트 `http://localhost:30000/v1` 로 요청하면 되고, `--speculative-*` 인자를 빼면 베이스라인과 같습니다.

```bash
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 \
  --disable-radix-cache --mem-fraction-static 0.8 --port 30000

```

**llama.cpp** : 비전 모델을 DSpark 대상으로 변환할 수 있게 한 [PR #29339](https://github.com/ggml-org/llama.cpp/pull/29339)(9월 23일 병합) 이후 빌드가 필요합니다. GGUF 초안 모델(F16, 567MB)은 초안 부분만 담은 사이드카 파일이라 본 모델 GGUF와 함께 불러와야 하며, Apple Silicon에서는 블록 크기 8(`--spec-draft-n-max 8`)을 권장합니다.

```bash
llama-server -hf LiquidAI/LFM2.5-VL-3B-GGUF:F16 \
  -hfd LiquidAI/LFM2.5-VL-3B-DSpark-GGUF:F16 \
  --spec-type draft-dspark --spec-draft-n-max 8 --spec-draft-n-min 0 \
  -ngl 99 -ngld 99 -fa on

```

**MLX-VLM (Apple Silicon)**: [MLX](https://github.com/ml-explore/mlx) 기반 MLX-VLM v0.7.2 이상에서 `--draft-model` 로 넘기면 초안 모델을 자동 인식합니다(관련 [PR #2280](https://github.com/Blaizzy/mlx-vlm/pull/2280)은 v0.7.2에 포함). 현재 MLX-VLM의 DSpark 디코딩은 탐욕적 샘플링만 지원하므로 `--temperature 0` 으로 설정합니다.

```bash
python -m mlx_vlm.generate \
  --model LiquidAI/LFM2.5-VL-3B \
  --draft-model LiquidAI/LFM2.5-VL-3B-DSpark \
  --draft-block-size 8 \
  --image /path/to/image.jpg \
  --prompt "Describe this image." \
  --max-tokens 256 \
  --temperature 0

```

llama.cpp 서버는 응답마다 `timings` 에 제안된 초안 토큰 수(`draft_n`)와 채택된 수(`draft_n_accepted`)를 함께 보고하므로, 자신의 워크로드에서 채택률을 직접 확인할 수 있습니다. 참고로 원문 블로그의 llama.cpp 예시는 초안 모델 파일명이 텍스트 모델용(`LFM2.5-2.6B-DSpark-F16.gguf`)으로 적혀 있어, 위에는 GGUF 모델 카드의 명령을 옮겼습니다.

## LFM2.5-VL-3B-DSpark의 라이선스

LFM2.5-VL-3B-DSpark는 본 모델과 같은 [LFM Open License v1.0](https://huggingface.co/LiquidAI/LFM2.5-VL-3B-DSpark/blob/main/LICENSE)으로 배포됩니다. 이 라이선스의 상업적 이용 권한은 연 매출 1,000만 달러(Threshold) 기준을 넘지 않는 경우에만 주어지며, 기준을 넘는 법인의 상업적 이용은 이 라이선스로 허가되지 않습니다. 원문 블로그는 LFM2.5를 "_제약 없이 다운로드, 미세조정, 배포할 수 있다_"고 소개하지만, 상업적 도입을 검토한다면 라이선스의 매출 기준을 먼저 확인하는 것이 좋습니다.

## 📜 LFM2.5-VL-DSpark 소개 블로그 (Hugging Face)

> **[Accelerating vision-language models with LFM2.5-VL-DSpark](https://huggingface.co/blog/LiquidAI/lfm2-5-vl-dspark)**
>
> A Blog post by Liquid AI on Hugging Face

## 📜 LFM2.5-VL-DSpark 소개 블로그 (Liquid AI)

> **[LFM2.5-VL-DSpark: Accelerating vision-language models on edge and beyond | Blog](https://www.liquid.ai/blog/lfm2-5-vl-dspark)**
>
> LFM DSpark accelerates local ai vision-language inference up to 3.13× on edge devices and 2.66× on GPUs with no quality loss.

## 🤗 LFM2.5-VL-3B-DSpark 모델 (Hugging Face)

> **[LiquidAI/LFM2.5-VL-3B-DSpark · Hugging Face](https://huggingface.co/LiquidAI/LFM2.5-VL-3B-DSpark)**
>
> We’re on a journey to advance and democratize artificial intelligence through open source and open science.

## 🤗 LFM2.5-VL-3B-DSpark GGUF 모델 (Hugging Face)

> **[LiquidAI/LFM2.5-VL-3B-DSpark-GGUF · Hugging Face](https://huggingface.co/LiquidAI/LFM2.5-VL-3B-DSpark-GGUF)**
>
> We’re on a journey to advance and democratize artificial intelligence through open source and open science.

## 📜 DSpark 논문

> **[DSpark: Confidence-Scheduled Speculative Decoding with Semi-Autoregressive...](https://arxiv.org/abs/2607.05147)**
>
> Speculative decoding accelerates Large Language Model (LLM) inference by decoupling draft generation from target verification. While recent parallel drafters efficiently propose long token sequences in a single forward pass, they suffer from rapid...

## 더 읽어보기

- [LFM2.5-DSpark: Up to 3.2x Faster Inference from H100 to MacBook (Liquid AI 블로그, 영문)](https://huggingface.co/blog/LiquidAI/lfm25-dspark)

- [MMSpec: Benchmarking Speculative Decoding for Vision-Language Models (arXiv, 영문)](https://arxiv.org/abs/2603.14989)

- [Liquid AI, 휴대폰에서 실행 가능한 온-디바이스 에이전트 모델 LFM2.5-2.6B 공개](https://discuss.pytorch.kr/t/liquid-ai-lfm2-5-2-6b/11549)

- [Liquid AI, 엣지용 350M 모델 LFM2.5와 다국어 검색 리트리버 LFM2.5 Retrievers 공개](https://discuss.pytorch.kr/t/liquid-ai-350m-lfm2-5-lfm2-5-retrievers/10808)

- [DeepSpec: 추측 디코딩 초안 모델을 학습하고 평가하는 DeepSeek의 풀스택 코드베이스](https://discuss.pytorch.kr/t/deepspec-deepseek/11049)

- [DFlash: 블록 확산(Block Diffusion) 기반으로 LLM 추론 속도를 높이는 오픈소스 라이브러리 (feat. Z.ai)](https://discuss.pytorch.kr/t/dflash-block-diffusion-llm-feat-z-ai/9849)

- [TorchSpec: 추측 디코딩 초안 모델을 대규모로 학습하는 파이토치 네이티브 프레임워크](https://discuss.pytorch.kr/t/torchspec/11124)

- [하드웨어 인식 동적 추측 디코딩(DSD): 배치 크기에 맞춰 초안 토큰 수를 조절하는 추론 최적화 (feat. Cohere)](https://discuss.pytorch.kr/t/dsd-feat-cohere/11200)

- [E-P-D 분리 서빙: 비전 인코더를 떼어내 TTFT를 최대 93% 줄이는 조건과 오히려 느려지는 조건 (feat. NVIDIA Dynamo)](https://discuss.pytorch.kr/t/e-p-d-ttft-93-feat-nvidia-dynamo/11883)

- [Splash: 범용 엔진 대신 모델마다 커널과 초안 모델을 새로 만드는 Apple Silicon 추론 엔진](https://discuss.pytorch.kr/t/splash-apple-silicon/11959)

* * *

_이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다._ 🤗

이 글은 [:pytorch:파이토치 한국 사용자 모임🇰🇷](https://pytorch.kr/)이 직접 정리한 글입니다. 새 글을 놓치지 않으시려면 [텔레그램(Telegram)](https://t.me/pytorchkr)이나 [Slack/Discord/Teams/Dooray/GoogleChat 등](https://discuss-noti.pytorch.kr)으로 알림을 받으시고, [회원으로 가입](https://discuss.pytorch.kr/signup)하시면 주요 글들을 이메일💌로도 보내드립니다! 😃

🎁 아래↘쪽에 좋아요👍를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~ 🤩
