LFM2.5-24B-A2B-DSpark와 LFM2.5-24B-A2B의 페어링을 위한 히어로 타이틀 카드로, 327.7M 드래프트 체크포인트가 체크 표시를 지나 24B 타깃으로 후보 토큰을 공급하는 모습을 보여 주며, 동시성 256에서 1.71배 처리량, 동시성 1에서 2.38배, 655MB의 추가 가중치를 나타내는 스탯 필과 오른쪽 하단에 합성된 OrcaRouter 로고가 포함됩니다.
Guides & Insights

LFM2.5-24B-A2B-DSpark vs LFM2.5-24B-A2B: 드래프터를 정말 붙여야 할까?

작성자

Alistair Wren

게시일

최신 모델 · 20모든 모델 보기 →
벤치마크: Artificial Analysis · 매일 업데이트
모든 게시물로 돌아가기

결론을 한 줄로 말하면 이렇습니다: LFM2.5-24B-A2B-DSpark는 LFM2.5-24B-A2B 옆에 두는 3억 2,770만 파라미터 파일로, 24B 모델이 같은 종류의 출력을 더 빠르게 생성하도록 합니다. 이것은 모델의 대안이 아니며, 모델 대신 선택하는 것도 아닙니다. 두 이름이 제기하는 유일한 진짜 질문은 엔지니어링 질문입니다 — 드래프터를 배포 환경에 붙일 것인가, 빼둘 것인가 — 그리고 답은 Liquid AI가 앞세운 대표 속도 향상보다, 아무도 광고하지 않는 두 가지 수치에 더 달려 있습니다: 귀하의 트래픽에서 드래프트가 몇 개의 토큰을 승인받는지, 그리고 이미 얼마나 많은 동시성을 운영하고 있는지입니다. 이번과 같은 릴리스의 배경에 있는, 문서화된 AI 실패와 에이전트 사건들은 OrcaRouter AI Incident Archive에 수집되어 있으며, 각 항목에는 자체 출처, 심각도, 신뢰도 등급, 이의 제기 플래그가 포함되어 있습니다.

Liquid AI는 드래프터에 대한 출시 게시물을 게시하지 않았다. 저장소는 2026-10-19에 가중치, 벤치마크 CSV, SGLang 실행 플래그와 함께 공개되었지만, 타깃 모델 자체의 모델 카드는 여전히 드래프터를 "출시 예정"으로 표시하고 있으며 Liquid의 추측 디코딩 문서 페이지에는 1.2B, 2.6B, 8B, VL-3B 타깃만 나열되어 있다. 따라서 이는 보도자료가 아니라 저장소를 바탕으로 작성된, 출시된 아티팩트와 출시된 모델의 비교이며, 이는 아래의 모든 성능 수치가 공급업체 보고 수치이고 그중 어느 것도 독립적으로 재현되지 않았음을 의미한다.

드래프터가 실제로 바꾸는 것과 바꾸지 않는 것

이 메커니즘은 30초를 투자할 가치가 있습니다. 왜냐하면 이것이 나머지 모든 것을 결정하기 때문입니다. 토큰을 디코딩하는 것은 메모리 바운드 작업입니다. GPU는 대부분의 시간을 산술 연산이 아니라 가중치를 SRAM으로 스트리밍하는 데 씁니다. 추측 디코딩은 작은 모델이 다음 여러 토큰을 한 번에 추측하게 한 뒤, 실제 모델이 전체 추측을 단일 순전파에서 검증하도록 하는 방식으로 이를 활용합니다. 추측이 좋았다면 대략 한 토큰 비용으로 아홉 개의 토큰을 생성한 것입니다. 추측이 나빴다면 대상 모델은 자기 토큰을 유지하고 약간의 추가 비용만 치른 셈입니다.

달라지는 것: 초당 토큰 수와 GPU 활용률의 형태입니다. 달라지지 않는 것: 모델의 가중치, 컨텍스트 윈도, 도구 호출 동작, 또는 판매되는 곳의 가격입니다. LFM2.5-24B-A2B는 총 24.0B 파라미터를 유지하면서 토큰당 2.45B가 활성화되고, 40개 레이어가 게이트된 짧은 컨볼루션과 그룹화된 쿼리 어텐션으로 나뉘며, 블록당 64개 전문가에 top-4 라우팅, 131,072토큰 컨텍스트와 128,000토큰 어휘를 갖춥니다. 드래프터는 5개의 어텐션 레이어, rank-256 Markov 헤드와 신뢰도 헤드를 추가하고, 자체 임베딩과 LM 헤드를 갖는 대신 대상 모델의 임베딩과 LM 헤드를 재사용합니다.

두 릴리스 사이에 옮겨간 주의 사항이 하나 있어 한 줄쯤 언급할 가치가 있습니다. 8월에 Liquid의 DSpark 설명문은 출력되는 시퀀스가 "구성상 베이스라인 그리디와 동일하다"고 밝혔습니다. 반면 24B 드래프터의 카드에서는 배치 검증과 일반 디코딩 사이의 부동소수점 차이가 "그리디 샘플링에서도 서로 다른 텍스트를 생성할 수 있다"고 말합니다. 두 진술 모두 방어 가능합니다. 첫 번째는 정확한 산술에서는 참입니다. 하지만 평가 하네스가 출력을 바이트 단위로 비교한다면, 그 차이를 알아챌 것으로 예상하십시오.

원장의 비용 측면

드래프터는 공짜가 아니다. GPU에서는 BF16으로 655MB(CPU에서는 F16 GGUF로 664MB)를 차지하고, 타깃과 동일한 메모리 풀에 상주하며, 제안하는 각 단계마다 단일 토큰이 아니라 토큰 블록에 대한 검증 포워드 패스를 수행하는 비용이 든다. MoE 타깃에서는 이 마지막 부분이 들리는 것보다 더 비싸다. 9개 토큰을 검증하면 1개를 디코딩할 때보다 더 많은 전문가가 활성화되므로, 검증된 토큰당 이동하는 바이트 수는 줄지 않고 늘어난다. Liquid는 바로 이것을 자사의 8B 드래프터가 높은 수용률에도 불구하고 M4 Max에서 1.18×만 달성한 이유로 꼽았다.

그에 반해, 절감 효과는 GPU 시간 단위로 측정할 수 있을 만큼 큽니다. 공급업체 자체의 B300 수치를 benchmarks/b300-fp8.csv에서 사용하고, 10억 개의 출력 토큰을 관측된 처리량으로 나누는 것 외에는 아무것도 하지 않으면:

• MATH-500, 동시성 1 — 단독 실행 시 324 tok/s(10억 토큰당 857 GPU-시간)인 반면, 드래프터와 함께하면 853 tok/s(326 GPU-시간)입니다. 연산 시간이 2.63배 줄어듭니다.

• MATH-500, 동시성 256 — 단독 15,423 tok/s(18.0 GPU-시간) 대 드래프터 사용 시 27,579 tok/s(10.1 GPU-시간). 1.79배 감소.

• GSM8K, 동시성 256 — 단독으로 4,491 tok/s(61.9 GPU-시간) 대비 드래프터 사용 시 9,660 tok/s(28.8 GPU-시간). 2.15배 감소.

• LiveCodeBench, 동시성 256 — 단독 실행 시 {{1}}18,812{{/1}} tok/s(14.8 GPU-시간)인 반면, 드래프터와 함께면 {{2}}25,231{{/2}} tok/s(11.0 GPU-시간)입니다. 겨우 {{3}}1.34×{{/3}} 감소로, 표에서 가장 약한 셀입니다.

그것들은 처리량 비율을 시간으로 환산한 것이지 금액으로 환산한 것이 아닙니다. 금액은 GPU-hour당 지불하는 비용에 달려 있고 이 글은 요금을 임의로 만들어내지 않을 것이기 때문입니다. 하지만 순서는 어떤 요금에서도 유지됩니다: drafter를 붙이는 것은 낮은 동시성에서 추론 및 코드 생성 트래픽의 경우 10시간당 2~3시간의 가치가 있고, 높은 동시성에서는 그 약 3분의 1의 가치가 있습니다. 24B 배포가 워크스테이션의 단일 사용자 에이전트라면 근거는 강합니다. 포화된 배치 엔드포인트라면 근거는 실재하지만 2.4×라는 헤드라인만큼 훨씬 얇습니다.

A capture of the Hugging Face model card for LiquidAI/LFM2.5-24B-A2B-DSpark showing the 327.7M draft parameter specification, the five-layer backbone details, block size 9, the B300 FP8 throughput claim of 2.4x at concurrency 1 and 1.7x at concurrency 256, and the SGLang launch command.

업무량 측면에서 드래프터가 제값을 하는 지점

벤더 표의 8개 데이터셋에 걸친 편차는 노이즈가 아니라 프롬프트 유형과 대응되며, 그 대응 관계는 이번 릴리스에서 가장 유용한 부분이다. Acceptance는 MBPP에서 스텝당 6.70 토큰에서 LiveCodeBench에서 4.02까지 분포했다. 높은 점수를 받은 데이터셋은 모델의 출력이 프롬프트에 의해 제약되는 것들이다 — 짧은 단위 테스트 스타일 함수, 검증 가능한 경로가 있는 산술, 객관식 답안. 낮은 점수를 받은 데이터셋은 모델이 길고 제약 없는 해법을 창조해야 하는 것들이다: 경쟁 프로그래밍 문제와 AIME 스타일 수학.

그것이 여러분 자신의 평가로 가져가야 할 직관입니다. 에이전트 작업을 위해 판매되는 24B 추론 모델은 출력 토큰의 대부분을 사고의 연쇄 안에서 소비하며, 이는 MBPP보다 LiveCodeBench에 더 가까운 모습입니다. 구조화된 추출, 스키마를 사용한 분류, 또는 고정된 도구 호출 형식에 사용되는 모델은 수용률이 높은 행들에 훨씬 더 가깝습니다. 여러분의 워크로드가 전자에 해당한다면, 범위의 상단인 3.28×보다 하단인 1.34×에 더 가까이 위치할 것으로 예상하세요. 이 drafter에 대한 워크로드별 수용률을 공개한 사람은 아무도 없으며, 카드의 여덟 데이터셋이 가장 좋은 안내 자료입니다.

그와 대조적으로: 24B는 추론 전용 모델이다. Liquid에 따르면 이 모델은 항상 답변 전에 생각하며, 채팅 템플릿이 <think> 태그를 자동으로 삽입한다. 이는 추측 디코딩에 있어 최악의 형태인데, 추론 구간이 바로 길고 수용률이 낮은 구간이기 때문이다. 드래프터는 여전히 도움이 될 것이다. 최종 답변에서는 가장 많이 도움이 되고, 가장 오래 걸리는 부분에서는 가장 적게 도움이 될 것이다.

자신의 하드웨어에서 반나절 만에 판별하는 방법

위의 내용 중 어느 것도 신뢰할 필요는 없습니다. 두 추론 경로 모두 수락 카운터를 노출하며, 이 카운터는 드래프터가 귀하의 트래픽에서 비용을 회수하는지를 결정하는 유일한 숫자입니다.

SGLang에서는 drafter를 연결한 대상 모델을 블록 크기 9와 드래프트 토큰 10개로 실행한 다음, 서버가 요청별로 보고하는 speculative-decoding 지표를 읽으십시오. 공급업체 표의 수용률은 데이터셋에 따라 0.33에서 0.65 사이에 있습니다. 관련 행보다 훨씬 낮게 나오는 실행은 drafter가 잘못 추측하고 있어 속도 향상을 얻지 못한 채 검증 비용을 치르고 있다는 뜻입니다. F16 GGUF 사이드카가 있는 llama.cpp에서는 응답별 타이밍에 draft_n 및 draft_n_accepted가 직접 포함됩니다. 하나를 다른 하나로 나누십시오.

놓치면 한 시간을 허비하게 되는 운영상 세부 사항 두 가지가 있습니다. SGLang 서버에는 2026-08-31에 병합된 LFM2-MoE DSpark 경로가 포함된 빌드가 필요합니다. 그보다 오래된 빌드에서는 드래프터 아키텍처 자체가 알려져 있지 않습니다. 그리고 블록 크기는 자유 매개변수가 아니라 체크포인트의 속성입니다: llama.cpp는 --spec-draft-n-max 값을 사이드카 메타데이터의 값인 9로 제한하므로, 12를 요청해도 아무것도 얻지 못합니다.

A throughput comparison graphic showing the eight benchmark datasets from Liquid AI's B300 FP8 measurements at concurrency 256, with MATH-500 at 1.79x, GSM8K at 2.15x, HumanEval at 1.64x, MBPP at 1.64x, MT-Bench at 1.81x, SimpleQA at 1.95x, LiveCodeBench at 1.34x and AIME at 1.36x, with proportional bars and a footer reading vendor-reported, not independently reproduced, plus the OrcaRouter logo bottom-right.

이 비교로는 답할 수 없는 질문

"드래프터를 붙여야 할까"에는 GPU와 전혀 무관한 버전이 있으며, 대부분의 팀이 실제로 마주하는 것은 바로 이 버전이다. 호스팅 API를 통해 LFM2.5-24B-A2B를 호출한다면 드래프터 결정은 당신의 몫이 아니다. 서빙 스택이 추측 디코더를 붙이든 붙이지 않든, 당신은 초당 토큰 수와 가격을 볼 뿐이며 둘 다 업스트림에서 결정된 것이다. Liquid 자체 Console에는 24B가 입력 토큰 100만 개당 $0.10, 캐시된 입력 $0.05, 출력 100만 개당 $1.00로 표시되어 있다. 이는 그들이 실행하는 디코드 경로를 이미 반영한 공개 요금이며, 예고 없이 변경될 수 있다.

바로 그 접점이 라우팅이 복잡하게 만들기보다 도움이 되는 지점입니다. 호스팅 호출과 자체 호스팅 배포는 경쟁하는 플랜이라기보다 동일한 비용 조절 다이얼의 두 가지 설정에 가깝습니다. 자체 호스팅에 드래프터를 더하면 사용량이 GPU를 계속 바쁘게 유지할 수 있는 경우 토큰당 비용을 최소화하고, 호스팅 엔드포인트는 답을 얻기까지의 작업을 최소화합니다. OrcaRouter는 후자를 위해 만들어졌습니다 — 하나의 키로 제공업체 정가 기준 0% 마크업으로 200개 이상 모델을 이용할 수 있어, 공급업체 가격이 바뀌면 같은 날 저희 쪽에도 반영됩니다. 제공업체 성능이 저하되면 자동 장애 조치가 이루어지고, 하나의 백엔드를 하드코딩하는 대신 트래픽을 분할하는 라우팅 DSL도 제공됩니다. 현재 LFM2.5 제품군은 제공하지 않으므로, 이 특정 모델의 경우 호스팅 측은 Liquid 자체 API 또는 자체 GPU를 의미합니다. 비교해 볼 만한 대상은 저희가 실제로 제공하는 모델, 예를 들어 Qwen3.6-35B-A3B — Liquid가 에이전트 작업에서 벤치마크하는 모델 — 또는 Gemma 4 26B-A4B.

그래서: 붙일까 말까

LFM2.5-24B-A2B를 적당한 동시성으로 직접 서빙 중이고, 특히 구조화된 출력이나 추출 형태의 출력을 처리하며, 대상 모델 옆에 655MB의 여유 공간이 있다면 이를 붙이세요. 벤더 수치에 따르면 그 환경에서 디코드 시간이 대략 절반 또는 3분의 1로 줄어들며, 단점은 제한적입니다. 잘못된 드래프터는 검증 패스를 한 번 더 거치게 할 뿐, 오답을 초래하지는 않습니다.

엔드포인트가 이미 수백 단위로 포화되어 있거나, 출력이 긴 자유 형식 추론이거나, 커밋하기 전에 Apple 실리콘 수치가 필요하다면 이 기능은 꺼 두세요 — 카드에는 그런 수치가 없고, 같은 제품군에서 가장 가까운 유사 사례는 MacBook에서 1.18×로 출시되었습니다. 그리고 당연히 모델을 전혀 실행하고 있지 않다면 꺼 두세요: 드래프터는 배포를 위한 최적화이며, 배포가 존재하기 전에는 최적화할 것이 없습니다.

나머지 의문을 해소할 것은 벤더 게시물과 Mac 측정치다. 2026-10-21 현재 둘 다 존재하지 않으며, 이는 가중치가 이미 다운로드 가능한 릴리스로서는 이상한 상태다. 그리고 승인 카운터를 직접 실행할 의향이 있는 사람이라면 누구에게나 리더보드에 첫 독립 수치를 올릴 수 있는 유난히 값싼 기회이기도 하다.

A two-column scoreboard titled 'LFM2.5-24B-A2B-DSpark vs LFM2.5-24B-A2B — the scoreboard'. The left column lists draft parameters 327.7M, block size 9, mean acceptance 5.16 tokens per step, throughput 2.38x at concurrency 1 and 1.71x at concurrency 256, extra memory 655 MB and no standalone price. The right column lists 24.0B total parameters with 2.45B active, a 131,072-token context, 184 tokens per second on an M5 Max, 21K output tokens per second on a B300, and a vendor list price of 0.10 dollars per million input and 1.00 dollars per million output, above a footer reading drafter figures vendor-reported on B300 and not independently reproduced, with the OrcaRouter logo composited bottom-right.