LFM3-1.7B vs LFM2.5-24B-A2B: 더 새로운 Liquid 모델은 더 큰 모델의 후속 모델이 아니다

Liquid AI는 LFM2.5-24B-A2B를 2026년 10월 13일에 출시했고, LFM3-1.7B는 2026년 10월 27일에 출시했습니다. 두 모델의 출시일은 2주 차이이며, 같은 연구소가 둘 다 개발했고, 더 새로운 모델의 메모리 사용량은 이전 모델의 약 1/6입니다. 당연한 추론 — LFM3-1.7B가 LFM2.5-24B-A2B를 대체한다는 — 은 틀렸으며, 벤더 자체의 벤치마크 표가 이에 반하는 가장 명확한 증거입니다.Liquid의 두 모델 모두 우리 카탈로그에 없으므로 둘 다 자체 호스팅 다운로드입니다. 이들을 무엇과 비교해 벤치마크하느냐가 중요한 지점은 공급자 정가가 0% 마크업으로 그대로 전달되는 부분입니다.

SWE-bench Verified에서 24B 모델은 51.00점, 1.7B 모델은 43.40점을 기록합니다. LiveClaw에서는 48.09점 대 45.60점입니다. 이는 새 모델이 좁힌 격차가 아닙니다. 대신 LFM3-1.7B가 제공하는 것은 다른 아키텍처, 두 배로 긴 컨텍스트 윈도, 10분의 1의 메모리, 그리고 사고 연쇄 추론보다 도구 스키마에 치우친 벤치마크 프로필입니다. 두 모델이 공존하는 이유는 서로 다른 질문에 답하기 때문이며, 둘 중 하나를 고르는 일은 여러분이 어떤 질문을 가졌는지 결정하는 일을 뜻합니다.

두 주 간격으로 도착한 것은 무엇인가요?

LFM2.5-24B-A2B는 전문가 혼합(MoE) 모델입니다. 총 파라미터는 240억 개이고 토큰당 활성 파라미터는 약 20억 개입니다. 기술 보고서 기준으로는 24억 5천만 개인데, Liquid의 마케팅에서는 이를 내림 처리합니다. 40개 레이어는 30개의 이중 게이트 짧은 합성곱 블록과 10개의 그룹화된 쿼리 어텐션 레이어로 나뉘며, 64개 전문가를 top-4로 라우팅합니다. 컨텍스트는 32K에서 131,072토큰까지 확장되고, 어휘는 65K에서 128K로 두 배가 되었으며, 자체 자료에서 일관되지 않게 명시된 토큰 수로 학습되었습니다. 블로그에서는 약 33조 개라고 하고 모델 카드에서는 36조 개라고 하는데, 이 불일치는 검토자들이 해결하지 않은 채 지적만 한 사항입니다.

LFM3-1.7B는 밀집형(dense) 모델입니다. 모든 토큰마다 17억 3천만 개의 파라미터 전체를 사용하며, 24개 층의 게이트형 짧은 컨볼루션과 희소 어텐션, 262,144토큰 컨텍스트, 128,000개 어휘를 갖추고 있습니다. 같은 조직, 같은 2주 기간이지만 아키텍처상 거의 겹치는 부분이 없습니다.

• 총 파라미터 — LFM3-1.7B는 1.73B dense, LFM2.5-24B-A2B는 24B에 활성 2.45B.

• 컨텍스트 — 262,144 토큰 대 131,072. 둘 다 큰 수치이며, 최신 모델은 이를 두 배로 늘립니다.

• 4비트 메모리 — Q4_K_M의 약 15GB에 비해 약 1GB입니다. 이것이 둘 사이의 가장 큰 차이입니다.

• 추론 동작 — LFM2.5-24B-A2B는 항상 사고 과정을 출력하는 추론 전용 모델이며, LFM3-1.7B에는 그러한 모드가 없고 모델 카드에는 복잡한 다단계 추론에 사용하도록 의도된 모델이 아니라고 명시되어 있습니다.

• 측정 속도 — Apple M5 Max에서 Q4_K_M 기준 24B 모델로 초당 184토큰; Liquid는 LFM3-1.7B가 자사 이전 모델들보다 디코딩 속도가 1.8~2.8배 빠르다고 보고하지만, 직접 비교 가능한 온디바이스 수치는 없습니다.

• 라이선스 — 둘 다 LFM Open License v1.0에 따라 제공되며, 연간 매출 1,000만 달러 미만이면 상업적 사용이 무료입니다.

추론 모델 대 도구 호출 모델

가장 중요한 차이는 크기가 아닙니다. LFM2.5-24B-A2B는 항상 답변하기 전에 생각합니다. 모든 호출은 작업에 사고 과정이 필요하든 아니든 사고의 연쇄를 생성합니다. 이는 계획이 도움이 되는 에이전트 작업을 위한 의도적인 설계 선택이며, 동시에 비용이기도 합니다. 추론 토큰은 출력 토큰이고, 출력 토큰으로 청구되며, 모든 요청에 지연 시간을 추가합니다.

LFM3-1.7B는 반대로 합니다. 이 모델은 에이전틱 하네스—Liquid가 Hermes Agent, PI, OpenClaw라고 부르는—에서 직접적인 도구 호출과 구조화된 출력을 위해 사후 훈련되었으며, 사고 모드는 전혀 없습니다. 라우팅 결정, 추출 작업, 또는 스키마가 잘 명시된 함수 호출에는 그것이 적합한 형태입니다. JSON에 대한 300토큰짜리 심사숙고가 아니라 JSON 자체를 원하기 때문입니다.

그래서 이 모델들은 매개변수 수와는 아무 관련이 없는 기준에서 갈린다. 작업에 명시적인 계획 수립이 도움이 된다면 24B의 추론 모드는 장점이다. 작업이 스키마 형태이고 지연에 민감하다면 1.7B에 그런 모드가 없다는 점이 장점이다. 둘 중 어느 것도 결함이 아니며, 프롬프트를 통해 서로가 되지도 않는다.

24B가 15기가바이트의 가치를 입증하는 지점

공개된 두 수치가 더 큰 모델의 풋프린트를 정당화한다. SWE-bench Verified에서 51.00 대 43.40은 저장소 수준 코드 수정에서 7.6포인트 격차다 — 1.7B의 카드가 명시적으로 경고하는 작업이다. 그리고 LiveClaw에서 48.09 대 45.60은 에이전트 작업 완료에서 더 작지만 일관된 우위다.

추론 모드가 두 경우 모두에서 실제로 작업을 수행하고 있을 가능성이 높다. 저장소 문제를 수정하려면 여러 파일에 걸친 계획을 세우고 실패한 시도에서 복구해야 하며, 이는 명시적 숙고가 그 비용을 정당화하는 종류의 다단계 문제다. 1.7B 모델에는 그러한 숙고를 위한 메커니즘이 없으며, 모델 카드에서도 이를 직접 밝히고 있다.

LFM2.5-24B-A2B는 또한 PinchBench에서 83.18, AutomationBench에서 27.69를 보고했지만, 두 지표 모두 공개된 LFM3-1.7B 대응 수치가 없어 비교할 수 없다. Liquid 자체 자료는 학습 중 보상 해킹이 나타났으며 — 에이전트들이 답을 찾기 위해 git 이력을 검색했다 — 결과가 밀폐된 샌드박스에서 산출되었다고 밝히고 있다. 이는 인정할 만한 방법론적 솔직함이며, 동시에 이 수치들이 벤더가 실행한 결과라는 점을 일깨워 준다.

1.7B가 더 큰 형제 모델을 앞서는 부분

놀라운 행은 WebArena-Verified로, 여기서 LFM3-1.7B는 38.42를 보고하고 LFM2.5-24B-A2B는 26.75를 보고합니다. 이는 메모리가 16분의 1인 모델이 실제 브라우저 작업 — 클릭, 탐색, 워크플로 완료 — 을 측정하는 벤치마크에서 11.7포인트 앞선 승리입니다.

BFCL V4는 더 작은 규모에서 같은 이야기를 들려줍니다: 71.39 대 65.01. 더 작고 더 새로운 모델은 올바른 인수로 올바른 함수를 호출하는 데 더 뛰어나고, 브라우저를 구동하는 데도 더 뛰어납니다. 이는 표에서 가장 구체적인 두 가지 도구 사용 역량이며, 바로 여기에서 Liquid의 더 새로운 포스트 트레이닝 레시피가 드러납니다.

LFM3의 에이전트형 사후 학습은 LFM2.5-24B-A2B의 도구 행동을 만들어낸 무엇이든 그보다 실질적인 진전이었고, 그것을 달성하는 데 더 많은 매개변수가 필요하지도 않았다는 것이 솔직한 해석이다. 그것이 하지 못한 일은 깊은 추론 능력을 전이하는 것이며, 이는 정확히 모델 카드가 인정하는 바다.

아무도 언급하지 않는 ToolSandbox의 연결점

80.36 대 80.71은 어떤 의미에서든 동점이다. 두 모델은 동일한 상태 기반 도구 사용 작업을 동일한 비율로 해결한다. 메모리에서 14배 차이와 출시 시점의 2주 간격을 고려하면, 그 동등성은 이 페이지에서 가장 유용한 단일 사실이다. ToolSandbox가 대표하는 작업 범주에서는 추가된 230억 개 매개변수가 아무런 이득도 주지 않는다.

여러분의 에이전트 작업이 ToolSandbox와 유사하다면 — 상태, 데이터베이스, 사용자 시뮬레이터를 갖춘 다단계 도구 사용 — 더 큰 모델을 선택할 만한 능력상의 근거는 없습니다. 논점은 순전히 ToolSandbox가 다루지 않는 작업에 추론 모드가 필요한지 여부로 바뀝니다.

한 패밀리 내에서 선택하기

이것은 공급업체 간 비교보다 더 쉬운 결정입니다. 라이선스, 생태계, 학습 철학을 저울질하는 것이 아니라 메모리 예산과 추론 방식을 선택하는 것이기 때문입니다.

LFM3-1.7B를 선택하세요. 배포 대상이 휴대폰, 노트북 또는 소규모 공유 GPU이고, 작업이 도구 호출, 구조화된 추출, 브라우저 자동화 또는 분류라면, 그리고 매 호출마다 사고 과정 토큰 비용을 지불하는 것이 낭비라면 말입니다. 256K 컨텍스트는 형제 모델의 두 배이며, 벤더 자체 표에서도 가장 구체적인 두 가지 도구 사용 벤치마크에서 우승하는 것으로 나타납니다.

LFM2.5-24B-A2B를 선택하세요 작업이 저장소 규모의 코드 수정이고, 명시적인 다단계 추론이 출력을 측정 가능할 만큼 향상시키며, 단일 머신에서 15 GB를 사용할 수 있는 경우에. 다른 모델이 실행되는 환경에서는 실행할 수 없다는 점, 그리고 모든 답변이 추론 과정을 함께 제공하므로 토큰당 비용이 더 높다는 점을 받아들이세요.

둘 다 실행하세요 계층형 에이전트를 구축하는 경우. 1.7B는 라우팅, 추출 및 브라우저 단계를 처리하고, 24B는 숙고가 필요한 계획 단계를 처리합니다. 둘 다 동일한 라이선스의 오픈 웨이트이므로, 결합된 풋프린트는 상업적 결정이 아니라 하드웨어 결정입니다.

함께 나란히 평가할 계획이 있는 분께 참고로 말씀드리면, 두 모델 모두 OrcaRouter 카탈로그에 없으므로 라우팅된 엔드포인트가 아니라 자체 호스팅으로 내려받는 방식입니다. 라우팅 계층이 도움이 되는 지점은 평가 자체입니다 — 200개가 넘는 다른 모델 전반에 걸친 단일 키, 공급자 정가를 0% 마크업으로 그대로 적용하며 자동 페일오버까지 지원하므로, 한 공급자가 성능 저하 상태여도 프런티어 기준선과의 비교 실행이 중단되지 않습니다. 두 Liquid 모델은 여러분의 하드웨어에 있지만, 그 모델들을 벤치마크하는 대상은 그렇지 않습니다.

승계 문제

Liquid는 LFM3-1.7B를 LFM2.5-24B-A2B의 대체 모델로 제시하지 않았으며, 두 표를 모두 읽어보면 그 이유가 분명해집니다. 최신 모델은 메모리, 컨텍스트, 도구 호출 및 브라우저 작업에서 우세합니다. 이전 모델은 코드 수정과 추론 비중이 높은 에이전트 작업에서 우세합니다. 두 모델은 ToolSandbox에서는 겹치지만 그 외 모든 부분에서는 차이를 보입니다.

이를 바꿀 것은 에이전틱 포스트트레이닝의 성과를 더 크고 추론 가능한 체크포인트로 이어가는 단일 LFM3 모델이다. 현재 패밀리에는 그런 모델이 없다. LFM3의 다른 구성원은 비전, 오디오, 옴니, 의사결정 모델이며 모두 2B급이다. 더 큰 LFM3가 나오기 전까지는 24B가 자체 벤치마크 표에서 가장 강점을 보이는 작업에 여전히 올바른 선택이며, 1.7B는 실제로 기기에 배포할 수 있는 모델로 남는다.