LFM2.5-2.6B-DSpark: Liquid의 온디바이스 에이전트를 2.3배 더 빠르게 실행하게 만드는 328M 드래프터

{{1}}아무도{{/1}} Liquid AI 외에는 자체 하드웨어에서 {{2}}LFM2.5-2.6B-DSpark{{/2}}를 실행하고 수치를 발표한 적이 없습니다. 이것이 이 모델에 대해 솔직하게 말할 수 있는 출발점입니다. 왜냐하면 이 모델의 전부가 {{3}}성능 주장{{/3}}이기 때문입니다: 더 나은 {{6}}2.6B{{/6}} 모델이 아니라, 2.6B 에이전트 모델 {{7}}LFM2.5-2.6B{{/7}} 앞에 위치하여 검증할 토큰을 제안하는 {{4}}328M{{/4}} 파라미터 {{5}}드래프트 모델{{/5}}입니다. 따라서 에이전트는 출력을 변경하지 않고도 약 {{8}}두 배{{/8}} 더 빠르게 실행됩니다.

2026년 8월 20일, Hugging Face의 기술 문서와 Liquid 자체 블로그의 관련 게시물과 함께 출시된 LFM2.5-2.6B-DSpark는 Liquid가 그날 공개한 소규모 추측 디코딩 드래프터 체크포인트 제품군의 대표 모델입니다. 아래 속도 열의 모든 수치는 벤더 측정값이며 아직 독립적으로 확인되지 않았습니다. 저장소의 모든 내용, 형식 및 프레임워크 지원은 확인할 수 있도록 제공된 것입니다.

DSpark가 무엇인지 한마디로

추측 디코딩은 값싼 드래프트 모델을 실제 모델보다 앞서 실행하는 기법입니다. 드래프트 모델이 다음 토큰 몇 개를 추측하고, 대상 모델이 전체 배치를 단일 순전파로 검증한 뒤 일치하는 토큰만 유지합니다. 추측이 맞으면 하나의 비용으로 여러 토큰을 진행하므로 대상 모델의 가중치를 건드리지 않고도 처리량이 올라갑니다. DSpark(2026년 7월 DeepSeek 연구진이 처음 제안하고 이미 DeepSeek-V4에 적용된 기법)는 이 기법을 소형 온디바이스 모델에 맞게 조정한 버전입니다. Liquid는 이를 confidence-scheduled speculative decoding(신뢰도 예약형 추측 디코딩)이라고 부르며, 여기에는 세 가지 핵심 요소가 있습니다. 단일 패스로 모든 드래프트 토큰의 은닉 상태를 생성하는 병렬 백본, 인접 토큰 간 의존성을 모델링하여 블록 후반부에서 수용률이 급락하지 않게 하는 경량 순차 헤드, 그리고 검사 비용이 절약 비용보다 클 때 낮은 신뢰도의 접미사를 제거하는 검증기입니다.

마지막 부분이 DSpark를 일반 드래프터와 다르게 만드는 요소입니다. 항상 전체 블록을 검증에 통과시키지는 않습니다. 드래프트 자체의 신뢰도가 접미사가 채택될 가능성이 낮다고 판단하면, 블록을 줄여서 낭비되는 연산을 절약합니다. 드래프트 블록은 9개 토큰이므로, 타깃은 한 번에 최대 10개까지 검증합니다.

숫자로 보는 기안자

LFM2.5-2.6B-DSpark 체크포인트는 0.3B 파라미터, 어텐션 전용 드래프트 모델입니다. 이 모델은 5개의 전체 어텐션 레이어(히든 크기 2,048, 32개 헤드와 8개 키-값 헤드를 갖춘 grouped-query 어텐션), 128K 토큰 어휘, 랭크 256의 Markov 헤드, 그리고 신뢰도 헤드로 구성됩니다. Liquid는 AMD 하드웨어에서 지시, 대화, 코드, 함수 호출 데이터를 혼합하여 15 에폭 동안 학습시켰으며, 가장 낮은 손실이 아닌 가장 높은 수용률을 기준으로 해당 에폭을 선택했습니다.

그 수용률은 드래프터의 가치를 결정하는 숫자입니다. 배치 크기 1, 온도 0에서 다섯 개의 벤치마크에 걸쳐 LFM2.5-2.6B-DSpark는 H100에서 디코딩 단계당 평균 4.83개의 허용된 토큰을, M4 Max에서는 4.42개를 기록했습니다 — 대략 블록의 절반이 수용되었으며, 이것이 2배의 속도 향상이 나오는 이유입니다.

레이블이 지정된 속도 향상

다음의 모든 수치는 Liquid AI 자체 측정에서 나온 것입니다 — 단일 H100 80GB에서 BF16의 SGLang, 그리고 FP16 GGUF의 M4 Max MacBook Pro에서 Metal 백엔드를 사용하는 llama.cpp, 배치 크기 1, 온도 0 — 그리고 이 글을 쓰는 시점 기준으로 어느 독립된 기관에서도 재현되지 않았습니다:

H100 평균 — 2.67배, 323에서 864 tokens/s로. 벤치마크별: MATH500 3.06배, HumanEval 2.56배, MBPP 2.64배, GSM8K 2.22배, MT-Bench 2.87배.

• M4 Max 평균 — 2.27배, 61에서 139 tokens/s로. 벤치마크별: MATH500 2.25배, HumanEval 2.63배, MBPP 2.11배, GSM8K 2.36배, MT-Bench 1.99배.

• 도구 호출 — 다중 도구 함수 호출 시나리오에서 평균 지연 시간이 57% 감소했습니다.

• 패밀리 맥락 — 패밀리에서 가장 큰 드래프터인 LFM2.5-8B-A1B-DSpark는 H100에서 최대 3.18배, 1.2B 드래프터는 M4 Max에서 최대 2.87배에 달했습니다. 위의 2.6B 수치는 그중 중간 수준입니다.

그 숫자들에서 평균 이상으로 중요한 점이 두 가지 있습니다. 첫째, 이 수치들은 온도 0과 배치 크기 1에서 측정되었습니다 — 이는 추측에 유리한 구성이자 대화형 온디바이스 에이전트 작업이 주로 실행되는 구성입니다. 동일성 보장도 여기서 유효합니다. 추측 디코딩은 제안된 모든 토큰을 검증하므로, 탐욕적 디코딩에서 생성된 텍스트는 타깃 모델이 단독으로 생성했을 텍스트와 정확히 일치합니다. 둘째, 동시성이 높아질수록 그 격차는 좁혀집니다. 단일 H100에서 Liquid는 DSpark의 이점이 배치 크기 128 부근에서 수렴한다고 보고합니다. 따라서 드래프터는 대화형 및 도구 중심 작업에서는 지연 시간 측면에서 이득을 주지만, 최대 부하 서버를 위한 순수 처리량의 만능 해결책은 아닙니다.

무엇이 확인되었고, 무엇이 확인되지 않았는가

확인되었습니다. 저장소가 공개적이고 검증 가능하다는 점에서: 드래프터는 Safetensors(BF16) 및 GGUF 형태로 제공되며, 기본(base) 모델이 아닌 사후 훈련된 LFM2.5-2.6B와 짝을 이룹니다. 출시 첫날부터 llama.cpp(실험적 Metal 커널 포함)와 SGLang에 상류(upstream) 지원이 포함되었고, Liquid의 LFM Open License v1.0에 따라 라이선스가 부여됩니다. 그리고 이를 기준으로 계획하는 모든 이에게 중요한 점은, 모델 카드에 어떤 추론 제공자도 이를 서비스하지 않는다고 명시되어 있어, 직접 실행해야 하는 구성 요소라는 것입니다.

아직 확인되지 않음: 속도 향상이 다른 하드웨어와 구성에서 재현된다는 점(Liquid 외부에서는 아무도 측정 결과를 발표하지 않음), 드래프터가 탐욕적 디코딩 대신 샘플링에서 어떻게 동작하는지, 그리고 57% 도구 호출 지연 시간 수치가 Liquid가 사용한 벤치마크 하네스 외의 실제 에이전트 하네스에서도 유지되는지 여부. 이 중 어느 것도 비난이 아닙니다. 출시된 지 하루밖에 안 됐으니까요. 하지만 그것들은 유망한 수치와 검증된 수치의 차이를 만듭니다.

그것을 실행하기

SGLang에서는 DSpark 지원 빌드를 사용하고, 대상 모델에 대해 서버를 실행한 다음 드래프터를 지정합니다: 추측 알고리즘은 DSPARK이고, 드래프트 모델 경로는 LiquidAI/LFM2.5-2.6B-DSpark를 가리키며, 블록 크기는 드래프트의 config.json에서 읽습니다. llama.cpp에서는 대상 GGUF를 로드하고 드래프트 GGUF를 드래프트 모델로 사용하며 spec 타입을 draft-dspark로 설정하고, 블록 크기는 사이드카 메타데이터에서 읽습니다. 두 통합 모두 업스트림에 포함되어 있으므로 포크가 필요하지 않으며, 이를 담을 만큼 충분히 새로운 빌드만 있으면 됩니다.

추가할 가치가 있을 때

LFM2.5-2.6B-DSpark는 Liquid가 이 2.6B 에이전트를 배포하도록 설계한 환경, 즉 휴대폰, 노트북, 또는 엣지 박스에서 실제로 배포할 때 약 0.3GB의 추가 메모리를 정당화합니다. 이는 지연 시간에 민감하고 그리디(greedy)하게 실행되는 대화형 또는 도구 호출 워크로드를 위한 것입니다. 바로 이 프로필에서 2.27배의 온디바이스 수치와 57%의 도구 호출 지연 시간 단축이 효과를 발휘합니다. 서버에서 높은 배치(batch)로 서빙하는 경우(속도 향상이 1배에 수렴)나 온도가 0보다 큰 워크로드(보고된 수치가 적용되지 않는 경우)에는 덜 흥미롭습니다. 그리고 이 패밀리의 8B-A1B 변형을 사용하는 경우 엣지 케이스를 주목하세요. 현재 온디바이스 속도 향상은 약 1.18배에 불과합니다. 드래프트 토큰 검증이 llama.cpp의 Metal 백엔드에서 더 많은 전문가를 활성화하기 때문이며, Liquid는 이를 알려진 문제로 표시합니다.

DSpark는 2.6B 에이전트가 실행되는 위치를 바꾸지 않습니다. 이는 설계상 자체 호스팅 방식이며, 이미 호출하고 있는 호스팅 모델 옆에 함께 놓이게 됩니다. 로컬 드래프터와 수십 개의 API 엔드포인트가 혼합된 구성은 라우팅 계층이 하나로 통합하려고 존재하는 바로 그런 배관입니다. 하나의 API 키로 200개 이상의 모델에 액세스하고, 공급자 성능이 저하되면 자동으로 장애 조치되며, 공급자 목록 가격을 0% 마크업으로 전달하므로, 2.6B급 에이전트의 로컬 대 호스팅 비용 비교가 스프레드시트에 머무는 대신 명확하게 유지됩니다.

오늘날 LFM2.5-2.6B-DSpark를 올바르게 이해하는 방법은, 실제로 다운로드하고 실행할 수 있는 체크포인트에 딸린, 유망하지만 공급업체가 측정했고 아직 독립적으로 검증되지 않은 속도 주장으로 보는 것입니다. 2.6B 에이전트를 온디바이스에 배포한다면, 드래프터는 시도해 보기 부담이 적고 제거하기도 쉽습니다. SGLang 명령에 speculative 플래그 두 개를 추가하고, greedy 디코딩을 유지한 채, 2.3×를 신뢰하기 전에 자신의 워크로드로 측정해 보십시오. 저장소는 이미 있으며, 독립적 검증이 남은 과제입니다.