Liquid AI, LFM2.5-VL-DSpark 공개: 3B 비전 모델에 드래프트 모델 추가, 디코딩 최대 3.13배 가속
Liquid AI 블로그의 2026년 9월 게시 내용에 따르면, Liquid AI는 오픈 웨이트 비전 언어 모델 LFM2.5-VL-3B용 실험적 DSpark 드래프트 모델을 공개했다. 약 2억 8천만 개 파라미터가 추가되며(3B 대상 모델 대비 8.9% 증가), 온디바이스 디코딩 최대 3.13배, H100 최대 2.66배 가속을 주장하고, 첫날부터 llama.cpp, MLX-VLM, SGLang을 지원한다.
주요 변화
Liquid AI는 2026년 9월 자사의 비전 언어 모델 LFM2.5-VL-3B에 맞춘 실험적 DSpark 드래프트 모델을 공개했다. 제조사 블로그에 따르면 이 드래프트 모델은 텍스트판 LFM2.5-DSpark의 아키텍처 접근을 따른다. 고정 접속 계층에서 대상 모델의 은닉 상태를 포착해 이를 바탕으로 후보 토큰 묶음을 초안 작성한다. 이미지 패치와 텍스트 토큰은 이 계층에 들어가기 전에 공유 표현 공간으로 투영되므로, 드래프트 모델은 차원이 일치하는 은닉 상태를 처리하며 추론 알고리즘은 텍스트 모델과 동일하다. 드래프트 모델은 4계층, 어텐션만 포함한 구조에 블록 크기 9, 약 2억 7950만 파라미터로, 디코더 스택 1억 9300만, 은닉 상태 투영 2100만, Markov head 6550만, Norms와 신뢰도 head 6400으로 분해된다. 제조사는 M5 Max에서 MLX로 각 작업 디코딩 2.30~3.13배, 엔드투엔드 1.56~2.62배를 주장하며, M3 Ultra에서 llama.cpp로 디코딩 1.57~2.14배를 제시했다. 한편 H100에서의 디코딩 및 엔드투엔드 가속 수치는 원문에서 조판 이상이 의심된다. 제조사는 투기적 디코딩이 정확하다고 강조한다. 대상 모델이 제안된 모든 토큰을 검증하며, 탐욕적 출력은 대상 모델만 단독 사용한 것과 동일하다. 드래프트 모델은 Safetensors와 GGUF 두 형식으로 Hugging Face에 제공된다.
개발자에게 미치는 영향
로컬 또는 엣지 기기에서 멀티모달 모델을 배포하는 개발자에게 이 공개의 의미는 절대 속도 수치가 아니라 드래프트 모델과 대상 모델의 파라미터 비율, 약 8.9%에 있다. 이는 VRAM과 메모리 점유 증가가 통제 가능함을 뜻한다. 그러나 대부분의 가속비는 디코딩 단계 지표이며, 엔드투엔드 이득은 작업 부하에서 비전 인코딩과 prefill이 차지하는 비중에 달려 있다는 점을 제조사 스스로 Amdahl의 법칙을 인용해 설명한다. 여기서 분기가 생긴다. 긴 출력, 다중 턴 대화 또는 이미지 설명 위주 시나리오는 제조사가 주장한 엔드투엔드 수치에 근접할 수 있다. 단일 긴 이미지 질의응답처럼 대량의 비전 토큰을 먼저 처리하고 곧바로 끝나는 시나리오는 이득이 현저히 작다. 또한 드래프트 모델 실행은 아직 메인라인에 병합되지 않았거나 특정 빌드가 필요한 llama.cpp, MLX-VLM, SGLang 브랜치에 의존하므로 통합 비용을 무시할 수 없다. 주의할 점은 이 글의 확인 시점 기준으로 KimiSeek 현행 모델 디렉터리에 LFM2.5-VL-3B 또는 LFM2.5-VL-DSpark 항목이 없으며, 출처가 언급한 API와 가중치 가용성은 모두 제조사 측 설명이라는 것이다.
연동 및 평가 제안
권고 1: 드래프트 모델 도입 여부를 결정하기 전에 먼저 자신의 작업 부하에서 디코딩이 전체 지연 시간에서 차지하는 비율을 측정하라. 출처는 투기적 디코딩이 디코딩만 가속하고 비전 인코딩과 prefill은 가속하지 않으며, 엣지 기기에서는 prefill이 엔드투엔드 지연에서 차지하는 비율이 더 높다고 언급한다. 전제는 첫 토큰 지연 시간과 디코딩 소요 시간의 항목별 데이터를 이미 확보하고 있어야 한다는 것이다. 동일한 여섯 가지 비전 작업(일반 VQA, 텍스트 VQA, 이미지 설명, 차트 VQA, 복잡한 추론, 다중 턴 대화) 세트로 베이스라인과 드래프트 모델 두 구성을 실행하고, 평가 지표는 디코딩 처리량만이 아니라 엔드투엔드 지연 시간 분위수를 취하는 것이 좋다. 작업 부하가 짧은 이미지와 긴 텍스트 출력 위주라면 드래프트 모델이 유리할 수 있다. 단일 턴 긴 이미지 질의응답 위주라면 이득 상한이 prefill에 제약된다. 권고 2: 주장된 최고 가속이 아니라 배포 형태에 따라 llama.cpp와 SGLang 중에서 선택하라. 출처는 두 방식의 구체적 실행 방식이 다르다고 제시한다. SGLang은 --speculative-dspark-block-size 등 파라미터로 드래프트 모델을 장착하며 radix cache를 반드시 끄도록 명시한다. llama.cpp 쪽은 --spec-type draft-dspark와 함께 --spec-draft-n-max 8이 필요하다. 전제는 사용하는 빌드에 해당 PR이 포함되어 있어야 하며, 그렇지 않으면 이 파라미터를 쓸 수 없다는 것이다. 평가 시에는 매 응답의 draft_n과 draft_n_accepted를 기록해 수용률을 근거로 블록 크기 8과 9 중 어느 쪽이 더 적합한지 판단하고, 수용률이 낮으면 작업 분포가 학습 데이터 혼합에서 벗어났는지 되짚어 보는 것이 좋다. 이는 권장 사항이며 제조사의 약속이 아니다.
제한과 확인할 사항
첫째, 이 글의 확인 시점 기준으로 KimiSeek 현행 모델 디렉터리에 LFM2.5-VL-3B 또는 LFM2.5-VL-DSpark의 정확한 항목이 없으므로 이 버전은 현재 KimiSeek에 등재되어 있지 않다. 출처에서 언급한 가중치 다운로드, 형식, 통합 방식은 모두 제조사 측 설명이며 이 사이트의 가용성을 의미하지 않는다. 둘째, 제조사 원문에서 H100 부분의 디코딩 가속 구간이 “20.4배에서 2.66배”로 적혀 있어 명백한 조판 또는 전사 이상이 있으므로 이를 신뢰할 수 있는 상한으로 인용해서는 안 된다. 셋째, 제조사는 드래프트 모델이 실험적이라고 자술하며, 4계층 구조와 블록 크기 9는 3, 4, 5계층 소거 실험에서 나온 것이고 학습 데이터 혼합은 예상 작업 부하에 가중치를 두었으므로 수용률과 가속비는 실제 작업 분포에 따라 달라진다. 넷째, 가속 수치는 제조사가 M5 Max, M3 Ultra, H100에서 자체 측정한 것이며 MMSpec 벤치마크의 여섯 가지 작업으로 평가한 것으로, 다른 하드웨어, 양자화 형식, 컨텍스트 길이, 배치 설정에서의 성능은 독립적으로 검증되지 않았다. 다섯째, 출처는 모델을 오픈 웨이트로 설명하며 자유로운 다운로드, 미세 조정, 배포가 가능하다고 하지만 블로그는 구체적 라이선스 조건을 제시하지 않는다. 가중치 확보 가능성이 오픈소스 라이선스를 의미하지는 않으며, 상업적 이용과 재배포 권리는 Hugging Face 모델 페이지의 실제 라이선스를 기준으로 해야 한다.
원문 보도의 이미지
