LFM2.5-VL-3B-DSpark vs LFM2.5-VL-3B: 고르는 게 아니라, 붙이는 것입니다

사람들이 이곳에 오게 만든 검색은 비교를 위한 것이지만, 솔직한 답은 LFM2.5-VL-3B-DSpark와 LFM2.5-VL-3B가 둘 중 하나를 고르는 두 가지 대상이 아니라는 것이다. 두 번째는 다운로드해서 서빙할 수 있는 3.1B 비전-언어 모델이다. 첫 번째는 두 번째 모델 앞에 자리해 디코딩을 더 빠르게 만들기 위해서만 존재하는 279.5M 파라미터 드래프트 모델이다. 스택에서 드래프터를 빼면 아무것도 생성하지 못한다. 단독으로 벤치마크할 수 없다. '단독'은 이 모델이 지원하는 구성이 아니기 때문이다. 진짜 비교는 LFM2.5-VL-3B를 단독으로 실행하는 것과, 같은 모델을 드래프터와 함께 실행하는 것이다.

그렇게 읽으면 결정은 한 가지 질문으로 좁혀집니다: 추가 메모리와 추가 런타임 복잡성이 당신의 워크로드에서 중요할 만큼 충분한 지연 시간 이점을 가져다주는가? Liquid AI 자체 수치는 디코드 중심 작업에서는 그렇다고 말하고, 프리필이 지배적일 때는 명시적으로 아니라고 말합니다. 그 어느 쪽도 회사 외부에서 재현된 적이 없습니다.

두 개의 체크포인트, 나란히

두 저장소 사이에서 무엇이 다른지가 바로 핵심이므로, 속도 논쟁이 시작되기 전에 두 저장소를 나란히 놓고 비교해 볼 가치가 있다.

• 역할 — LFM2.5-VL-3B는 텍스트를 생성하고 이미지에 대해 답변합니다. LFM2.5-VL-3B-DSpark는 검증할 토큰을 제안하며, 그 자체만으로는 쓸 만한 것을 생성하지 않습니다.

• 파라미터 — 타깃은 3.1B, 드래프터는 279.5M BF16이며, Liquid는 이를 배포된 파라미터 수 대비 8.9% 증가로 본다

• 아키텍처 — 타깃은 LFM2.5-2.6B 백본과 SigLIP2 NaFlex 비전 인코더를 기반으로 구축된 하이브리드 모델입니다. 드래프터는 히든 크기 2,048의 전체 어텐션 레이어 4개에 그룹화된 쿼리 어텐션(grouped-query attention), Markov 헤드, 신뢰도 헤드를 더한 구성입니다.

• 컨텍스트 윈도우 — 타깃의 경우 32,768토큰; 드래프터는 자체 컨텍스트를 갖지 않으며 타깃의 컨텍스트를 상속합니다

• 비전 인코더 — 타깃에는 SigLIP2 NaFlex 400M이 있고, 드래프터에는 없으며 이미지를 직접 보지 않음

• 어휘 — 128,000, 그리고 드래프터의 임베딩과 LM 헤드는 복제되지 않고 타깃에 묶여 있으므로, 메모리 부담은 279.5M 매개변수가 시사하는 것보다 작습니다.

• 라이선스 — 둘 다 Liquid의 LFM1.0 라이선스로 배포되며, Hugging Face에서는 OSI 라이선스가 아니라 "other"로 분류됩니다. 따라서 상업적 배포 전에 약관을 읽어 보세요.

• 형식 — 대상은 safetensors, GGUF, ONNX 및 MLX 양자화로 제공됩니다; drafter는 safetensors와 약 567MB의 단일 F16 GGUF로 제공됩니다.

그 목록에서 한 줄은 강조할 가치가 있습니다. 그것이 바로 이 조합이 성립하는 역학적 이유이기 때문입니다: 드래프터는 작은 비전 모델이 아닙니다. 비전 인코더가 없고 이미지를 전혀 건드리지 않습니다. 토큰이 드래프터가 초안을 만드는 데 사용하는 은닉층에 도달할 즈음에는 이미지 패치와 텍스트 토큰 모두 그저 텐서일 뿐이므로, 드래프팅 계산에는 모달리티가 보이지 않습니다. 그래서 Liquid는 텍스트 모델용으로 개발된 기법을 재설계하지 않고 VLM에 이식할 수 있었습니다.

초안 작성자가 바꾸는 것과 그대로 두는 것

타깃 모델은 변하지 않습니다. 이는 마케팅이 아니라, 추측 디코딩(speculative decoding)의 정확성 속성입니다. 그리디 디코딩에서는 모든 드래프트 토큰이 타깃에 의해 검증되므로, 출력은 타깃이 단독으로 생성했을 것과 정확히 동일합니다. 0이 아닌 온도에서 일치된 샘플링 설정에서는 출력 분포가 타깃의 분포와 일치합니다. 드래프터는 메모리를 시간과 맞바꾸며, 그 외에는 아무것도 건드리지 않습니다.

이는 LFM2.5-VL-3B에 대해 찾을 수 있는 모든 품질 수치가 페어링된 구성에도 그대로 적용된다는 뜻입니다. Liquid 자체 평가에서 대상 모델은 ScreenSpot-v2에서 80.7, BLINK에서 61.5, MuirBench에서 58.3, MME에서 73.1, MMStar에서 63.3, ChartQA에서 81.3, POPE에서 88.7을 기록했습니다 — 모두 벤더가 보고한 수치이고, 독립적으로 재현된 것은 하나도 없으며, 드래프터가 붙어 있든 아니든 모두 똑같이 사실입니다. 여기에는 저울질할 품질 대 속도 트레이드오프가 없으며, 그런 트레이드오프를 제시하는 비교 페이지는 모델을 잘못 읽은 것입니다.

달라지는 것은 실제 경과 시간 기준 토큰의 비용이다. Liquid는 디코드 속도 향상을 측정한다. 단일 H100에서 BF16으로 SGLang을 통해 블록 크기 9에서는 2.04×~2.66×, Apple M5 Max에서 MLX-VLM을 통해 블록 크기 8에서는 2.30×~3.13×, M3 Ultra에서 llama.cpp를 통해서는 1.57×~2.14×다. 엔드투엔드에서는 동일한 실행이 각각 1.64×–2.27×, 1.56×–2.62×, 1.30×–1.77×로 나타난다. 이 쌍들이 논거의 전부다: 디코드는 엔드투엔드보다 대략 두 배 더 개선되며, 그 격차는 드래프터가 손댈 수 없는 워크로드의 부분이다.

공급업체가 밝힌 프리필 문제

Liquid의 자체 발표에서 가장 유용한 문장은 자사 헤드라인을 무제한적으로 해석하는 데 반대하는 문장이다. 비전-언어 추론은 텍스트 추론에는 없는 프리필 비용을 부담한다: 이미지는 비전 인코더를 거치고, 그런 다음 언어 백본이 그 인코더가 내보내는 수백 개의 시각 토큰을 처리한다. 엣지 디바이스에서는 이 프리필이 엔드투엔드 지연 시간의 큰 비중을 차지한다. 추측적 디코딩은 디코드만 가속한다 — 비전 인코딩과 프리필은 변하지 않는다. 프리필이 지배적인 경우, 3× 디코드 속도 향상은 훨씬 더 작은 엔드투엔드 이득으로 바뀐다.

그것은 벤더가 벤더 자신의 제품에 적용한 암달의 법칙이며, 이 페이지를 누가 읽어야 하는지를 좌우해야 합니다. 한 장의 스캔한 페이지를 길게 전사하는 작업, 캡션, 하나의 이미지를 계속 이어 가는 다중 턴 대화는 디코드 중심이며, 드래프터는 279.5M 매개변수의 가치를 입증합니다. 크고 고해상도인 이미지에 대한 짧은 질문은 프리필 중심이며, 그렇지 않습니다. 동일한 대상을 높은 동시성의 서버에 올리면 그림이 다시 바뀝니다: Liquid는 단일 숫자가 아니라 처리량-상호작용성 프런티어를 측정하며, 테스트된 모든 동시성 수준에서 DSpark가 우위를 유지하지만 동시성이 높아질수록 격차는 좁아진다고 보고합니다.

같은 출처에서 나온 두 가지 더 작은 범위 설정 메모입니다. 모든 측정은 비전 인코더와 언어 백본 모두에 16비트 처리를 사용하며, 양자화된 모델의 가속은 이번 릴리스의 범위 밖입니다. 3B VLM의 매력이 몇 기가바이트에 들어간다는 점에 있다 보니 4비트 타깃 내보내기를 드래프터와 짝지을 계획이었다면, 그 조합은 측정된 것이 아닙니다.

그것을 첨부하는 데 당신이 실제로 치르는 비용

메모리는 가시적인 비용이며, 카드는 이를 수치로 보여줍니다: 배포된 스택에서 매개변수가 8.9% 더 많습니다. 런타임 복잡성은 보이지 않는 비용입니다. SGLang은 v0.5.19 이상과 다음을 포함하는 실행 라인이 필요합니다: --speculative-algorithm DSPARK, 드래프트 모델 경로 및 블록 크기. 카드 자체의 예시는 또한 radix 캐시를 비활성화하고 정적 메모리 비율을 고정하는데, 이는 이제 여러분이 고려해야 하는 서빙 결정입니다. MLX-VLM은 v0.7.2 이상이 필요하며 --draft-model를 통해 드래프터를 받지만, 그곳의 DSpark 디코딩은 현재 그리디 샘플링을 사용하므로 temperature를 0으로 강제해야 합니다 — 애플리케이션이 샘플링 다양성에 의존한다면 실질적인 제약입니다. llama.cpp는 원본 safetensors 체크포인트가 아니라 GGUF 대상과 짝을 이룬 GGUF 드래프터를 통해 작동합니다.

벤치마크가 아니라 프로덕션에서 드러나는 비용이 하나 더 있습니다: 드래프터와 타깃은 함께 움직여야 합니다. 이 둘 사이의 버전 스큐는 단일 모델 배포에는 존재하지 않는 실패 모드이며, 둘 중 하나만 독립적으로 롤링하는 것은 이제 두 아티팩트 문제입니다.

이것은 자체 호스팅 페어링입니다. OrcaRouter는 LFM2.5-VL-3B나 그 드래프터를 라우팅하지 않습니다 — 두 모델을 모두 다운로드하여 직접 서빙하므로 — 라우팅 문제는 소형 모델이 넘겨주는 모든 것에 관한 것입니다. 3B 엣지 VLM을 드래프터와 페어링하는 대부분의 배포에서는 소형 모델이 답변해서는 안 되는 쿼리가 여전히 존재하며, 그러한 쿼리를 보내는 곳은 각 공급자의 정가로 200개 이상의 모델을 포괄하고, 공급자가 성능이 저하될 경우 자동 장애 조치를 제공하는 단일 엔드포인트, 벤더당 하나씩이 아니라 하나의 통합입니다. 또한 공급자가 가격을 인하하면 다음 계약 갱신 때가 아니라 같은 날 요율에 반영된다는 의미입니다.

어느 것을 다운로드해야 하나요?

워크로드가 디코드 중심이고 하드웨어가 Liquid가 테스트한 세 가지 중 하나라면 드래프터를 붙이십시오. 단점은 제한적입니다. 출력이 증명 가능하게 타깃의 출력이고 메모리 비용이 모델의 10분의 1 미만이기 때문입니다. 지연 시간이 프리필 중심이거나, 양자화된 타깃을 실행 중이거나, 해당 제한을 해제하지 않은 런타임에서 비그리디 샘플링에 의존한다면 LFM2.5-VL-3B를 단독으로 실행하십시오. 이 모델은 그 자체로 빠릅니다. M5 Max에서 초당 228토큰, AMD Ryzen AI Max+ 395에서 116토큰, Galaxy S26 Ultra에서 20토큰이며, 모두 벤더 수치이고 약 3GB 메모리에서 실행됩니다.

아직 아무도 알려줄 수 없는 것은 Liquid의 수치가 당신의 하드웨어에서도 성립하는지 여부다. 이 드래프터는 이 글을 쓰는 시점에 Hugging Face에서 다운로드 37회를 기록했으며, 그 표에 있는 어떤 수치도 독립적으로 재현된 바 없다. 엔지니어링은 탄탄하고 정확성 논증은 주장이 아니라 증명이지만, 그 규모는 측정값이다 — 그리고 한 연구실이 한 세트의 장비에서 얻은 측정값은 바로 당신이 용량 계획에 넣기 전에 스스로 검증해야 하는 종류의 숫자다.

OrcaRouter는 하나의 키로 200개 이상의 모델에 접근할 수 있으며, 각 제공업체의 정가는 0% 마진으로 그대로 전달되고 제공업체 간 자동 장애 조치가 이루어집니다. 제공업체 정가가 0% 마진으로 그대로 전달됨 이 페이지의 조합은 어느 쪽이든 자체 호스팅됩니다. 라우터는 소형 모델이 넘겨주는 모든 것을 위한 것이며, 이는 제공업체의 가격 인하가 같은 날 귀하의 요금에 반영된다는 뜻입니다.