Liquid AI LFM2.5-VL-3B-DSpark, 비전 디코딩 속도 높였지만 3.13배라는 헤드라인은 이야기의 절반일 뿐
Liquid AI는 자사의 소형 비전-언어 모델을 대상으로 최대 3.13배 빠른 디코딩을 달성했다는 결과와 함께 LFM2.5-VL-3B-DSpark를 공개했다. 이 개선은 이미지 이해부터 답변 생성까지의 전체 과정이 아니라 토큰 생성에 초점을 맞춘다.
이 구분이 Liquid AI LFM2.5-VL-3B-DSpark의 의미를 규정한다. 실험적 드래프트 모델은 데이터센터와 소비자용 하드웨어 모두에서 시각 및 텍스트 작업 전반에 speculative decoding을 적용할 수 있음을 보여준다. 다만 Liquid AI의 자체 결과에서도 최고 엔드투엔드 개선 폭은 2.62배로, 최고 디코딩 수치에는 미치지 못한다.
이번 공개는 개발자들에게 로컬 비전-언어 애플리케이션 최적화 방식을 재고하도록 압박한다. 모델 압축과 더 작은 아키텍처만이 지연 시간을 낮추는 방법은 아니다. 별도의 드래프터는 동일한 디코딩 설정에서 출력 동작을 유지하면서 기존 타깃 모델의 속도를 높일 수 있다.
따라서 비교 대상은 Liquid AI와 특정 경쟁 모델 하나가 아니다. 속도를 얻기 위해 주 비전-언어 모델을 더 작고 단순하게 만들거나 정확도를 낮추는 기존 관행과 speculative decoding의 대결이다.
Liquid AI LFM2.5-VL-3B-DSpark, 전용 드래프트 모델 추가
이번 공개는 답변 품질과 지연 시간 문제의 중요한 한 부분을 분리한다.
Liquid AI LFM2.5-VL-3B-DSpark는 LFM2.5-VL-3B를 위해 특별히 제작된 2억 7,950만 파라미터 규모의 드래프트 모델이다. 30억 파라미터의 타깃 모델을 대체하거나 요청에 독립적으로 답변하지는 않는다. 대신 더 큰 모델이 여러 토큰을 한꺼번에 검증하기 전에 가능성이 높은 토큰들을 제안한다.
이 과정은 speculative decoding이라 불리며, 더 작은 예측기가 타깃 모델의 병렬 검증을 위해 토큰 초안을 만드는 방식이다. 승인된 토큰은 답변 생성에 필요한 비용 높은 타깃 모델 추론 횟수를 줄인다. 거부된 제안은 타깃 모델이 수정한다.
Liquid AI에 따르면 드래프터는 4개의 full-attention 레이어, Markov head, confidence head로 구성된다. 학습 블록에는 제안 토큰 9개가 포함된다. 배포 시에는 하드웨어와 추론 프레임워크에 따라 8개 또는 9개 블록을 사용한다.
회사는 model repository를 통해 Safetensors와 GGUF 형식으로 모델을 공개했다. Nvidia GPU에서는 SGLang을, Apple silicon에서는 MLX-VLM을, GGUF 체크포인트를 통해서는 llama.cpp를 지원한다.
이 프레임워크 지원 범위는 중요하다. 추론 가속은 논문이나 맞춤형 연구 구현에만 머무르는 경우가 많기 때문이다. 여기서 Liquid AI는 서버, Mac, 로컬 양자화 모델에 이미 쓰이는 세 가지 배포 경로에 드래프터를 연결했다.
공개된 구성에서는 SGLang 0.5.19 이상이 필요하다. MLX-VLM은 0.7.2 이상이 필요하며, 현재 이 DSpark 구현을 greedy sampling으로 실행한다. Liquid AI는 MLX 사용자에게 temperature를 0으로 설정하라고 안내한다.
타깃 모델은 드래프터보다 먼저 공개됐다. Liquid AI는 2026년 8월 엣지 배포를 겨냥한 오픈 웨이트 비전-언어 모델 LFM2.5-VL-3B를 선보였다. 이 모델은 언어 백본과 비전 인코더를 결합해 이미지, 문서, grounding, 광학 문자 인식, 시각적 도구 사용을 처리한다.
Liquid AI는 앞서 타깃 모델이 M5 Max에서 초당 228토큰을 디코딩할 수 있다고 주장했다. Ryzen AI Max+ 395에서는 초당 116토큰, Galaxy S26 Ultra에서는 20토큰을 기록했다고도 밝혔다. 이 수치들은 회사 자체 테스트에서 나온 것이다.
DSpark 공개는 기반 모델이 학습한 역량이 아니라 배포 패키지를 바꾼다. 개발자는 추론 과정에서 드래프터를 연결하고, LFM2.5-VL-3B는 생성되는 모든 토큰을 승인하는 역할을 계속 맡는다.
greedy decoding에서 타깃은 자신이 직접 선택했을 토큰과 일치할 때만 드래프트 토큰을 승인한다. 따라서 결과 답변은 일반적인 greedy generation과 일치해야 한다. 0이 아닌 temperature에서는 일치된 샘플링이 하나의 결정론적 시퀀스 대신 타깃 모델의 출력 분포를 보존할 수 있다.
이 특성은 speculative decoding에 양자화나 distillation과는 다른 가치 제안을 부여한다. 이들 기법은 수치 정밀도, 모델 크기 또는 학습된 동작을 바꿀 수 있다. 반면 DSpark는 타깃 모델이 원래의 결론에 도달하는 데 드는 시간을 줄이려 한다.
이 때문에 이번 공개는 두 가지 최적화 경로 사이에 의미 있는 경쟁 구도를 만든다. 개발자는 주 모델이 수행하는 작업을 줄이거나, 그 작업의 더 많은 부분을 예측한 뒤 효율적으로 검증할 수 있다.
3.13배 결과는 하드웨어, 워크로드, 측정 방식에 좌우된다
Liquid AI의 최고 수치는 범용 애플리케이션 속도 향상이 아니라 하나의 디코딩 결과를 설명한다.
Liquid AI는 MMSpec의 여섯 가지 범주에서 드래프터를 평가했다. 일반 시각 질의응답, 텍스트 인식, 이미지 캡셔닝, 차트 분석, 복합 추론, 멀티턴 대화가 대상이었다. 회사는 Apple 하드웨어와 H100 GPU 1대에서 배치 크기 1로 테스트했다.
MLX-VLM을 사용한 M5 Max에서 Liquid AI는 2.30배에서 3.13배에 이르는 디코딩 향상을 보고했다. 엔드투엔드 개선 폭은 1.56배에서 2.62배였다. 3.13배의 최고치는 COCO 이미지 캡셔닝 워크로드에서 나타났다.
회사는 llama.cpp를 사용한 M3 Ultra도 테스트했다. 디코딩은 보고된 기준으로 1.57배에서 2.14배 개선됐고, 엔드투엔드 성능은 1.30배에서 1.77배 향상됐다.
SGLang을 사용한 H100 80GB GPU 1대에서 Liquid AI는 2.04배에서 2.66배의 디코딩 향상을 측정했다. 엔드투엔드 개선 폭은 1.64배에서 2.27배였다. 회사의 상세 benchmark disclosure는 구성과 작업별 결과를 제공한다.
이 테스트에서는 비전 인코더와 언어 백본에 16비트 처리를 사용했다. H100 구성은 BF16, 9개의 드래프트 블록, 배치 크기 1, temperature 0을 사용했다. Apple 테스트는 FP16, 8개 블록, 최대 2,048개의 생성 토큰을 사용했다.
Apple 평가에서 답변 길이의 중앙값은 90토큰이었다. 출력 길이에 따라 요청 중 디코딩에 소요되는 비중이 달라지므로 이 세부 사항은 중요하다. 긴 설명을 생성하는 시스템은 드래프터가 초기 설정 오버헤드를 만회할 시간을 더 많이 얻는다.
짧은 답변은 더 불리한 균형을 만든다. 애플리케이션이 레이블, 좌표 또는 한 문장만 반환한다면 이미지 인코딩과 프롬프트 처리가 지배적일 수 있다. 이때 생성 속도 향상은 전체 대기 시간 중 더 작은 비중에만 영향을 준다.
드래프트 승인률은 보고된 가속을 설명하는 데 도움이 된다. Liquid AI는 Apple 스택 전반에서 검증 패스당 약 3.2~4.5개의 승인 토큰을 측정했다. H100 결과에서는 3.46~4.57개의 승인 토큰을 기록했다.
승인 길이가 길수록 타깃은 각 패스에서 더 많은 유효 출력을 검증한다. 하지만 승인률이 곧바로 동일한 속도 향상으로 이어지지는 않는다. 드래프터 실행, 동기화, 메모리 접근, 프레임워크 오버헤드도 여전히 시간을 소비한다.
결과는 작업별로도 다르다. 이미지 캡셔닝은 MLX에서 최고 디코딩 개선을 냈지만, 멀티턴 대화는 2.30배를 기록했다. 엔드투엔드 개선 폭은 각각 2.59배와 1.91배였다.
이러한 차이 때문에 “최대 3.13배”를 모든 시각 보조 도구에서 기대할 수 있는 결과로 읽는 것은 신중하지 못하다. 이는 공개된 하나의 설정에서 관찰된 상한치다. 애플리케이션의 실제 결과는 하드웨어, 프롬프트 길이, 출력 길이, 샘플링 설정, 시각 워크로드에 따라 달라진다.
Liquid AI는 H100 테스트에서 DSpark가 더 높은 동시성에서도 우위를 유지했다고 말한다. 다만 동시성이 커질수록 격차는 좁아졌다. 이는 GPU가 메모리 바운드 디코딩에서 컴퓨트 바운드 실행으로 이동할 때 드래프터의 상대적 이점이 달라진다는 점을 시사한다.
제품팀에 실질적인 질문은 최고 수치가 Liquid AI의 테스트 내에서 사실인지가 아니다. 중요한 것은 자신들의 지연 시간 프로필이 그 결과를 낸 테스트와 닮았는지다. 이를 판단하려면 용량 계획에 헤드라인 배수를 그대로 복사하는 대신 각 추론 단계를 측정해야 한다.
Liquid AI speculative decoding이 타깃 모델을 보존하는 방식
DSpark는 예측 오류가 최종 출력으로 이어지지 않게 하면서 더 먼 미래까지 초안을 작성하려 한다.
표준 autoregressive generation은 토큰을 하나씩 순차적으로 생성한다. 연속되는 내용의 예측 가능성이 매우 높더라도 새 토큰마다 타깃 모델의 추가 추론 패스가 필요하다. 이러한 직렬 구조는 메모리 바운드 디코딩 중 하드웨어 활용률을 낮출 수 있다.
speculative decoding은 이 루프에 더 작은 모델을 삽입한다. 드래프터가 미래 토큰 블록을 제안하고, 타깃이 해당 위치들을 함께 평가한다. 여러 제안이 검증을 통과하면 작업량이 절감된다.
과제는 추가 모델을 사용할 가치가 있을 만큼 신속하고 정확하게 제안을 생성하는 것이다. 약한 드래프터는 거부되는 토큰을 만든다. 무거운 드래프터는 예측은 잘하지만 블록 생성에 지나치게 많은 시간을 소모한다.
DSpark는 병렬 생성과 경량 순차 구성 요소를 결합한다. Markov head는 제안 위치 간 제한된 의존성을 도입하고, confidence head는 이후 제안들을 검증해야 하는지를 추정한다. 이 설계는 드래프팅을 완전히 autoregressive로 만들지 않으면서 블록의 일관성을 유지하는 것을 목표로 한다.
기반 DSpark research는 이 접근법을 semi-autoregressive generation을 활용한 confidence-scheduled speculative decoding으로 설명한다. 핵심 트레이드오프는 제안 품질, 드래프트 지연 시간, 검증을 위해 전송되는 토큰 수에 관한 것이다.
순수 병렬 드래프팅은 블록을 빠르게 생성할 수 있지만, 블록 뒤쪽 토큰일수록 정확도가 떨어지는 경우가 많다. 각 위치는 앞선 추측을 포함한 문맥에 의존한다. 따라서 오류는 제안 전반에 걸쳐 누적될 수 있다.
완전 autoregressive 드래프터는 더 강한 의존성을 유지하지만, 직렬 병목의 일부를 다시 만들어 낸다. DSpark의 하이브리드 구조는 그 중간 지점을 차지하려 한다. 병렬 드래프트 작업 뒤에 작은 순차 head를 추가한다.
confidence 메커니즘은 또 다른 낭비 원인을 다룬다. 드래프터가 뒤쪽 토큰의 실패를 예상하는 상황에서 전체 고정 블록을 검증하는 것은 합리적이지 않다. 스케줄러는 신뢰도가 낮은 위치가 타깃 용량을 소비하기 전에 제출되는 접두부를 줄일 수 있다.
공개된 LFM2.5-VL-3B-DSpark 구성은 rank-256 Markov head와 별도의 confidence head를 사용한다. 어휘는 128,000개 토큰으로 구성된다. 이 아키텍처는 지정된 타깃 모델에 연결돼 있으며, 모든 VLM에 적용할 수 있는 범용 드롭인 드래프터로 쓰일 수는 없다.
이처럼 모델별로 연결된 관계는 강점이자 한계다. 하나의 타깃을 기준으로 학습하면 제안 정렬을 개선할 수 있다. 하지만 다른 타깃 모델로 전환하는 팀은 호환되는 체크포인트, 학습 과정, 런타임 통합이 필요하다.
“무손실”이라는 설명도 정확하게 해석할 필요가 있다. temperature 0의 greedy decoding에서는 검증이 타깃 단독 실행 시의 정확한 토큰 선택을 보존한다. 드래프터는 그럴듯한 대안을 임의로 대체할 권한을 얻지 않는다.
0이 아닌 temperature에서는 하나의 시퀀스를 재현하는 대신 타깃 분포를 보존하는 것이 목표가 된다. 기초 sampling research에 따르면, 올바른 speculative sampling은 일치된 설정에서 이를 수행할 수 있다. 속도는 여전히 드래프트와 타깃 분포가 얼마나 자주 일치하는지에 달려 있다.
Liquid AI는 실험에서 temperature를 높일수록 승인률이 낮아졌다고 보고했다. 확률이 더 낮은 순위의 토큰까지 분산되면서 드래프터와 타깃이 불일치할 기회가 늘어난다. 따라서 창의적 샘플링은 결정론적 생성보다 더 작은 개선 폭을 낼 수 있다.
이는 애플리케이션 설계에 중요하다. 문서 추출, 시각적 근거 기반 처리, 차트 판독, 제약된 응답에는 흔히 낮은 온도가 사용된다. 반면 개방형 이미지 대화는 더 많은 샘플링을 사용할 수 있어, 공개된 greedy 결과의 대표성이 떨어질 수 있다.
따라서 Liquid AI의 speculative decoding은 예측 가능한 출력에 특히 잘 맞는다. 표준화된 제품 이미지에 캡션을 붙이고, 영수증을 읽고, 인터페이스 스크린샷을 설명하며, 구조화된 사실을 추출하는 작업은 그럴듯한 활용 사례다. 다만 실제 성능 향상은 여전히 현지 환경에서 측정해야 한다.
더 빠른 디코딩이 비전-언어 병목을 없애지는 않는다
핵심 불확실성은 실제 요청 중 가속된 디코딩 단계 밖에 남아 있는 작업의 비중이다.
비전-언어 요청에는 텍스트 생성 이상의 작업이 포함된다. 시스템은 이미지를 인코딩하고, 이를 시각적 표현으로 변환하며, 해당 시각 토큰을 프롬프트와 함께 처리한 뒤 응답을 디코딩해야 한다.
DSpark는 마지막 단계만 가속한다. 이미지 인코딩을 더 빠르게 만들지는 않는다. 또한 prefill은 그대로이므로, 대상 모델은 첫 응답 토큰을 생성하기 전에 여전히 프롬프트와 시각 토큰 컨텍스트를 처리해야 한다.
이 경계가 디코딩 성능과 엔드투엔드 결과 간의 차이를 설명한다. Liquid AI는 M5 Max에서 최대 3.13x 더 빠른 디코딩을 보고했지만, 전체 성능 향상 최고치는 2.62x였다. 다른 작업에서는 차이가 더 컸다.
TextVQA에서 회사는 M5 Max 기준 디코딩 성능이 2.69x 향상되고 엔드투엔드 성능은 1.56x 향상됐다고 측정했다. 이는 이미지 처리와 prefill이 원래 요청 시간에서 상당한 비중을 차지했음을 시사한다.
이 한계는 워크로드의 일부가 변하지 않을 때 전체 가속도를 제한하는 Amdahl의 법칙을 따른다. 디코딩이 기준 지연 시간의 절반을 차지한다면, 디코더가 무한히 빨라져도 전체 요청은 2x를 넘게 개선될 수 없다.
엣지 하드웨어에서는 이 제약이 특히 중요하다. 소비자 기기는 비전 인코딩과 긴 컨텍스트 prefill에서 데이터센터 GPU보다 적은 연산 능력을 제공한다. 대형 이미지나 여러 이미지를 포함한 프롬프트는 speculative decoding이 도움을 주기 시작하기 전에 첫 토큰 생성을 지연시킬 수 있다.
독립적인 MMSpec benchmark는 신중한 해석의 필요성을 뒷받침한다. 저자들은 6개 작업 범주와 10가지 speculative-decoding 방법에 걸쳐 600개 샘플을 평가했다. 처리량 가속도만으로는 지연 시간 성능을 신뢰성 있게 나타내지 못한다는 결론을 내렸다.
MMSpec은 텍스트 전용 언어 모델용으로 설계된 기법이 멀티모달 환경에서는 성능을 저하시킬 수 있다는 점도 발견했다. 교차 모달 의존성은 어떤 제안이 살아남을 가능성이 높은지를 바꾼다. 배치 크기가 커질수록 비전 인식의 중요성도 높아진다.
Liquid AI는 MMSpec의 작업 범주를 따랐으며, 이는 내부 평가의 폭을 넓힌다. 그러나 DSpark 성능 테스트는 Liquid AI가 직접 수행하고 공개했다. 일반적인 기기와 프로덕션 프롬프트 전반에서의 독립적 재현은 여전히 제한적이다.
비교 기준선도 같은 수준의 주목을 받을 만하다. 공개된 배수는 지정된 프레임워크에서 drafter 유무에 따른 동일한 LFM2.5-VL-3B target을 비교한다. 결합 시스템이 모든 경쟁 VLM보다 뛰어나다는 뜻은 아니다.
또한 이 시스템은 대안적인 지연 시간 전략과 비교되지 않았다. 개발자는 target을 quantize하고, 이미지 해상도를 낮추고, 시각 임베딩을 캐시하고, 프롬프트를 줄이고, 요청을 배치 처리하거나, 더 작은 모델을 선택할 수 있다. 이러한 변화는 지연 시간 예산의 서로 다른 부분에 영향을 준다.
메모리도 또 하나의 운영상 고려 사항이다. drafter는 30억 파라미터 target에 비해 작지만 비용이 없는 것은 아니다. 가중치, 캐시, 런타임 상태, 통합에 필요한 자원이 제한된 기기에서는 중요한 용량을 차지한다.
호환성은 추가적인 마찰을 만든다. SGLang, MLX-VLM, llama.cpp는 이제 공개된 경로를 제공하지만, 다른 서빙 시스템을 사용하는 팀이 즉각적인 지원을 가정할 수는 없다. 프로덕션 도입에는 안정적인 로딩, 관측 가능성, 배치 동작, 실패 처리가 필요하다.
MLX-VLM의 현재 greedy-only DSpark 경로는 즉시 적용할 수 있는 활용 사례를 제한한다. 샘플링 생성에 의존하는 애플리케이션은 다른 지원 스택을 사용하거나 더 폭넓은 샘플링 지원을 기다려야 한다. 그 경우에도 높은 온도는 draft 수용률을 낮출 수 있다.
따라서 이 출시는 명확한 경계를 제시한 신뢰할 만한 시스템 최적화로 평가해야 한다. 이는 시각 추론이 모든 의미 있는 측면에서 3.13x 빨라졌다는 증거는 아니다.
실제 경쟁은 더 나은 예측과 더 적은 모델 작업 사이에 있다
DSpark는 target을 그대로 유지하면서 실행 빈도를 최적화하는 경로를 강화한다.
엣지 AI에서 지연 시간에 대응하는 표준 방식은 target 모델의 작업량을 줄이는 것이었다. 팀은 파라미터 수를 줄이고, 정밀도를 낮추고, 프롬프트를 짧게 만들고, 이미지를 작게 하거나, 작업별 distillation을 사용한다. 각 기법은 응답성을 개선할 수 있지만 품질이나 유연성의 대가를 수반할 수 있다.
Liquid AI LFM2.5-VL-3B-DSpark는 또 다른 경로를 제안한다. 기존 target을 유지하고, 특화된 동반 모델로 여러 미래 단계를 예측한다. target이 최종 출력에 대한 통제권을 포기하지 않은 채 그 추측을 검증하도록 한다.
이 경로는 팀이 이미 target 모델의 역량을 받아들이고 있을 때 매력적이다. 이를 교체하려면 새로운 평가, 프롬프트 변경, 안전성 점검, 제품 튜닝이 필요하다. drafter를 연결하면 그 투자 중 더 많은 부분을 보존할 수 있다.
이 접근법은 토큰 생성이 메모리 대역폭에 자주 제약받는 로컬 배포에도 적합하다. 블록을 검증하면 매번 한 토큰을 위해 모델 상태를 불러오는 것보다 하드웨어를 더 효율적으로 사용할 수 있다. Liquid AI의 Apple 결과는 그 가능성을 구체적으로 보여준다.
그럼에도 더 작은 모델은 장점을 유지한다. 패키징을 단순화하고, 총 메모리 사용량을 줄이며, 디코더 전용 최적화가 건드릴 수 없는 단계를 가속한다. 소형 비전 인코더는 첫 토큰까지의 시간을 개선할 수 있지만 DSpark는 그렇지 못한다.
Quantization은 speculative decoding과 배타적으로 경쟁하기보다 결합될 수도 있다. Liquid AI는 GGUF target에 맞춘 GGUF drafter를 제공한다. 따라서 로컬 스택은 런타임이 두 구성 요소를 올바르게 지원한다는 전제하에 정밀도를 낮추고 drafting을 추가할 수 있다.
이 조합은 엔지니어링 질문을 하나의 기법 선택에서 각 기법을 적절한 병목에 배정하는 문제로 바꾼다. Quantization은 가중치 크기와 연산 비용을 줄인다. 이미지 전처리는 비전 비용을 바꾼다. Speculation은 자기회귀 생성에 초점을 맞춘다.
이 때문에 단계별 프로파일링이 필수적이다. 고해상도 페이지를 분석하는 문서 보조 도구는 디코딩 전에 대부분의 시간을 소비할 수 있다. 상세한 설명을 생성하는 시각 채팅 도구는 출력 생성에 훨씬 더 많은 시간을 쓸 수 있다.
같은 구분은 사용자 경험에도 적용된다. 첫 토큰까지의 시간은 애플리케이션이 시작 시점에 얼마나 반응성 있게 느껴지는지를 결정한다. 초당 토큰 수는 생성이 시작된 뒤 긴 답변이 얼마나 매끄럽게 느껴지는지를 결정한다.
DSpark는 두 번째 지표를 직접 개선한다. 디코딩이 요청에서 충분한 비중을 차지할 때 전체 지연 시간도 개선한다. 첫 번째 지표가 비례해서 개선된다고 보장하지는 않는다.
개발자는 단일 사용자 속도와 전체 서비스 처리량도 구분해야 한다. Liquid AI는 측정한 H100 동시성 수준 전반에서 이점을 관찰했지만, 부하가 높아질수록 차이는 좁아졌다. 프로덕션 경제성은 요청 구성, 배치 처리, 서비스 수준 목표에 달려 있다.
따라서 이번 출시의 가장 중요한 측면은 아키텍처적이다. Liquid AI는 speculative decoding을 연구 결과로만 제시하는 대신, 배포 가능한 비전 모델 제품군의 일부로 패키징했다.
이 패턴이 확산된다면 모델 출시는 점차 target, 여러 quantization, 하드웨어별 drafter를 포함하게 될 수 있다. 추론 최적화는 사후 서빙 결정이 아니라 모델 아티팩트의 일부가 될 것이다.
이 방향은 다른 open-weight 모델 개발자에게 압박을 가한다. 체크포인트만 공개하면 가속화의 책임은 다운스트림 팀에 남는다. 측정된 성능 향상이 여전히 워크로드에 따라 달라지더라도, 매칭된 drafter를 제공하면 더 완성도 높은 지연 시간 이야기를 제시할 수 있다.
실제 환경에서 성능 향상이 중요한지 보여줄 세 가지 신호
독립 테스트, 더 폭넓은 샘플링 지원, 실제 애플리케이션 프로파일이 DSpark가 반복 가능한 배포 패턴이 될지를 결정할 것이다.
첫 번째 신호는 접근 가능한 하드웨어 전반에서의 독립적 재현이다. 개발자는 drafter 유무에 따라 동일한 프롬프트를 사용한 M 시리즈 Mac, 소비자 GPU, 엣지 시스템 테스트를 지켜봐야 한다.
유용한 보고서는 이미지 크기, 프롬프트 길이, 출력 길이, 온도, quantization, 런타임 버전을 공개해야 한다. 초당 토큰 수 하나만으로는 애플리케이션의 전체 응답이 의미 있게 빨라졌는지 설명할 수 없다.
Liquid AI의 범위에 근접한 재현 결과는 회사의 주장을 강화할 것이다. 더 작거나 일관되지 않은 성능 향상은 공개된 워크로드가 일상적인 애플리케이션보다 drafter에 더 유리하다는 점을 시사할 수 있다.
두 번째 신호는 더 폭넓은 런타임 및 샘플링 지원이다. MLX-VLM은 현재 공개된 DSpark 경로를 greedy 생성으로 제한하는 반면, SGLang은 Nvidia 배포를 겨냥하고 llama.cpp는 GGUF 활용 사례를 지원한다.
추가적인 추론 엔진 지원은 통합 비용을 낮출 것이다. 안정적인 0이 아닌 온도 샘플링은 이 방법을 시각 채팅 및 창의적 설명 도구와 더 관련성 있게 만들 것이다.
개발자는 샘플링이 바뀔 때 수용률을 살펴봐야 한다. Liquid AI는 실험에서 높은 온도가 수용률과 처리량을 낮췄다고 말한다. 프로덕션 테스트는 이러한 하락이 대화형 제품에 여전히 수용 가능한지 보여줘야 한다.
세 번째 신호는 팀이 실제 애플리케이션에서 단계별 성능 향상을 보고하는지 여부다. 결정적인 지표는 첫 토큰까지의 시간, 디코딩 속도, 엔드투엔드 지연 시간, 최대 메모리, 예상 동시성에서의 처리량이다.
장문형 시각 보조 도구는 생성이 세션을 지배하므로 상당한 이점을 얻을 수 있다. 몇 개의 필드만 반환하는 OCR 워크플로는 비전 인코딩과 prefill이 요청 대부분을 차지하므로 얻는 이점이 훨씬 적을 수 있다.
Liquid AI LFM2.5-VL-3B-DSpark를 평가하는 팀은 헤드라인 배수가 아니라 trace부터 시작해야 한다. 이미지 인코딩, prefill, 디코딩이 차지하는 기준 비중을 측정하라. 그런 다음 drafter를 연결하고 동일한 워크로드를 반복하라.
greedy 디코딩에서는 출력 동등성을, 지원되는 샘플링에서는 분포적 동작을 확인하라. warm start와 cold start를 별도로 측정하라. 노트북이나 모바일급 시스템을 테스트할 때는 메모리 압박과 지속 열 상태를 포함하라.
이번 출시는 그러한 평가를 가능하게 할 만큼 충분한 구현 세부 정보를 제공한다. 또한 개발자에게 유용한 사실을 상기시킨다. 모델 역량과 추론 동작은 별개의 엔지니어링 문제다.
Liquid AI의 3.13x 수치는 매칭된 drafter가 로컬 멀티모달 추론의 한 단계를 실질적으로 가속할 수 있다는 증거로 이해하는 것이 가장 적절하다. 엔드투엔드 수치는 이 주장의 가치와 한계를 모두 보여준다.
매칭된 draft 모델은 open-weight VLM의 표준 동반자가 될 것인가, 아니면 긴 출력 워크로드를 위한 특화 최적화로 남을 것인가? 답은 단일 최고 성능 벤치마크가 아니라 재현 가능한 애플리케이션 trace에서 나올 것이다.
