LFM3 유출: Liquid AI의 차세대 제품군은 네 가지 소형 옴니 모델

2026년 10월 27일 GitHub에 열린 한 풀 리퀘스트는 SGLang에 아직 공개되지 않은 모델 패밀리를 제공하는 방법을 가르치려 한다. 이 PR은 LFM3-1.7B, LFM3-VL-2B, LFM3-Audio-2B, LFM3-Omni-2B라는 네 개의 체크포인트를 명시하며, 이미 출시된 LFM2.5-2.6B 및 LFM2.5-24B-A2B와 대조해 읽으면 Liquid AI가 다음에 무엇을 만들지에 대한 청사진처럼 읽힌다. 이 PR은 병합되지 않았다. 세 개의 CI 검사가 모두 실패하고 있다. Liquid AI는 이에 대해 아무것도 발표하지 않았다. 오늘 기준 LFM3의 공개 기록 전체는 바로 이 병합되지 않은 diff이며, 그것이 무엇인지에 맞게 읽기만 한다면 대부분의 출시 게시물보다 더 많은 정보를 준다.

그러니 증거에 대해 정확히 짚고 넘어가자. 한쪽으로는 빈약하고 다른 쪽으로는 이례적으로 상세하기 때문이다. 여기에는 출시일도, 가격도, 라이선스 조건도, 벤치마크 점수도 없다. LFM3 모델 카드도, Hugging Face 저장소도, 블로그 글도, API 목록도 없다. 존재하는 것은 tugot17 — Piotr Mazurek — 의 기여, 즉 그가 지난 두 달 동안 SGLang, llama.cpp, mlx-vlm에 LFM 런타임 지원을 추가해 온 일과, Liquid가 곧 대체하려는 LFM2.5 세대에 관해 자체적으로 공개한 자료뿐이다. 아래의 모든 내용은 그에 맞게 표시되어 있다.

풀 리퀘스트가 실제로 내놓는 것

PR 제목은 [Feat] lfm3: 텍스트, 비전, 오디오 및 Omni 지원 추가이며, 어떤 종류의 변경인지 알려주는 두 개의 레이블이 있습니다: jit-kernel 및 Multi-modal. 4개 모델 패밀리에 대한 네이티브 텍스트 생성을 추가하며, 각 모델은 고유한 체크포인트 경로를 가집니다:

• LFM3-1.7B — 텍스트 입력, 텍스트 출력, 이 제품군의 기반이 되는 기본 언어 모델

• LFM3-VL-2B — 텍스트, 이미지, 동영상 입력, 텍스트 출력

• LFM3-Audio-2B — 텍스트와 오디오를 입력받아 텍스트를 출력하며, /v1/audio/transcriptions 엔드포인트에도 연결되어 있습니다

• LFM3-Omni-2B — 텍스트, 이미지, 오디오, 비디오 입력(비디오 자체의 사운드트랙 포함), 텍스트 출력

그 목록에서 잠시 짚고 넘어갈 만한 세부 사항이 하나 있다. 모든 변형이 텍스트를 출력한다. PR 어디에도 오디오 출력 경로는 없으며, 오디오 모델의 비채팅 표면은 전사다. 즉 음성이 들어가고 텍스트가 나온다. 이는 Liquid의 현재 오디오 라인보다 좁은 범위인데, 그 라인에서는 LFM2.5-Audio-1.5B가 단일 모델에서 ASR, TTS, 인터리브 음성 채팅을 처리하는 것으로 문서화되어 있다. 첫 SGLang 컷이 LFM3-Audio의 텍스트 생성 절반만 다루는지, 아니면 omni 패밀리가 실제로 음성 합성을 제거한 것인지는 PR만으로는 결론지을 수 없으며, 그렇다고 단언하는 사람은 추측하는 것이다. “LFM3 speaks”는 입증되지 않은 것으로 취급하라.

나머지 diff는 구현 세부 사항이지만, 그럼에도 이 작업의 시점을 보여준다. 각자의 프로젝터가 있는 비전 및 오디오 인코더, 공유 백본, 하이브리드 캐시 통합, PyTorch 폴백이 있는 CuTe DSL 컨볼루션 커널, 그리고 FlashInfer가 기본적으로 페이징된 프리필을 사용하므로 슬라이딩 윈도우 어텐션이 제대로 동작한다는 점에 대한 언급이 포함된다. 검증은 H100에서 FP16으로, 설명에서 이르는 다음을 사용해 실행되었다: 개발 체크포인트 — 나중에 중요해지는 네 단어.

아키텍처 문장과 사람들이 잘못 읽을 숫자

PR은 LFM3를 전체 어텐션과 슬라이딩 윈도 어텐션을 갖춘 게이트된 짧은 컨볼루션의 공유 백본으로 설명한다. 이는 대체된 것이 아니라 LFM2 계보가 이어진 것이다: LFM2.5-24B-A2B는 40개 레이어에 걸쳐 게이트된 짧은 컨볼루션과 그룹화된 쿼리 어텐션의 하이브리드로 문서화되어 있다. 유출에서 새로워 보이는 것은 전체 어텐션과 나란히 존재하는 명시적인 슬라이딩 윈도 구성 요소다.

검증 노트에는 256토큰 슬라이딩 윈도우를 넘어서 실행되는 프롬프트가 언급되어 있으며, 이것이 일주일 내내 맥락 없이 인용될 수치입니다. 이는 LFM3의 컨텍스트 길이가 아닙니다. 하이브리드 설계에서는 컨볼루션 레이어가 장거리 신호를 전달하기 때문에 어텐션 레이어는 국소적으로만 보면 됩니다. 이것이 아키텍처의 핵심 전제이며, 이 제품군이 LFM2.5-24B-A2B에서 131,072토큰의 컨텍스트를 보유할 수 있는 이유이기도 합니다. 대부분의 레이어가 이차 어텐션을 전혀 수행하지 않는데도 말이죠. 256토큰 어텐션 윈도우는 모델이 한 레이어 내부에서 어디를 보는지에 대한 진술이지, 얼마나 많은 텍스트를 받아들일 수 있는지에 대한 것이 아닙니다. PR은 LFM3의 전체 컨텍스트를 명시하지 않으며, Liquid 외부의 누구도 아직 그것을 알지 못합니다.

런타임 풀 리퀘스트가 노이즈가 아니라 신호인 이유

인프라 diff에서 제품 전략을 읽어내는 것을 의심하는 것은 합리적입니다. 이 특정 사례에서는 패턴이 무시하기엔 너무 일관적입니다. 왜냐하면 Liquid는 엔진 지원을 가중치와 함께 제공하며, 가중치 이후에 제공하는 것이 아니기 때문입니다. LFM2.5-2.6B는 llama.cpp, MLX, vLLM, SGLang, ONNX 및 Transformers 5.0+를 출시 첫날 대상으로 나열합니다. LFM2.5-24B-A2B는 출시 당시 llama.cpp, MLX, vLLM, SGLang 및 ONNX에서 지원되었습니다. 다섯 개 런타임이 준비된 채 등장하는 제품군이라면 발표 전에 커널이 작성되어 있어야 하며, 이는 PR이 먼저 병합되고 블로그 게시물이 뒤따른다는 뜻입니다.

저자는 그 연대기와 정확히 들어맞는다. Mazurek의 공개 이력은 LFM 통합 작업의 연속이다: 9월 SGLang에서 LFM2-VL을 위한 DSpark 추측 디코딩, 같은 달 llama.cpp에서 LFM2.5-VL-3B 및 DSpark 드래프트 모델 수정, mlx-vlm에서 텍스트 모델로부터 물려받은 추측 디코딩, 그리고 10월 13일 SGLang에서의 LFM2-MoE 구성 재사용이다. LFM3는 그 순서의 다음 항목으로, 패밀리 이름이 바뀐 주말에 제출되었다.

두 가지 부재는 존재만큼이나 시사적이다. Hugging Face Transformers에는 LFM3에 대응하는 풀 리퀘스트가 없으며 — 해당 저장소를 검색해도 아무것도 나오지 않는다 — SGLang PR은 기본 Transformers 5.19.0에서 --trust-remote-code를 사용해 체크포인트를 로드하는데, 이는 아키텍처가 아직 라이브러리에 네이티브로 지원되지 않을 때 하는 방식이다. 또한 LFM3에 대한 추측성 디코딩을 명시적으로 거부하는 커밋도 있어서, 2.5 세대에 제공된 DSpark 작업은 아직 이어지지 않았다. 이르고, 설계상 불완전하다.

아무도 답하지 못한 사이즈 질문

여기서 유출과 표명된 야심은 서로 반대 방향으로 당기고 있으며, 그 긴장감이 이 문서에서 가장 흥미로운 부분이다.

Liquid의 사전 학습 책임자인 Maxime Labonne은 LFM3의 목표를 350M~1.2B 규모에서 통하는 짧은 합성곱 접근법이 10B 매개변수를 넘어서도 버틸 수 있는지, 즉 어텐션 아키텍처가 역사적으로 우위를 가져온 영역에서도 견딜 수 있는지를 시험하는 것이라고 설명했습니다. 이는 스케일링 문제이며, 대형 모델을 함축합니다.

유출된 체크포인트는 1.7B 하나와 2B 세 개입니다. 그중 어느 것도 해당 질문이 말하는 임계값을 넘지 않습니다.

두 가지 해석이 남는다. 첫 번째는 이것들이 소형 첫 물결이라는 것이다. 즉, 큰 형제 모델이 나오기 전에 휴대폰과 자동차를 위한 옴니 패밀리이며, 이는 Liquid가 항상 소형 모델로 앞장서 온 방식과 PR에서 이를 최종 릴리스가 아닌 개발 체크포인트로 설명하는 방식과 맞아떨어진다. 두 번째는 1.7B와 2B가 단순히 커널을 검증하기에 편리한 크기였을 뿐이며, 실제로 출시될 것에 대해서는 아무것도 알려주지 않는다는 것이다. 정직한 입장은 이 유출이 패밀리가 존재함과 그 형태를 입증하지만, 그 상한을 입증하지는 않는다는 것이다. 10B가 넘는 Liquid 모델을 기다리고 있다면, 이 PR은 그런 모델을 약속하지도, 배제하지도 않는다.

LFM3가 물려받는 것, 좋든 나쁘든

이것이 넘어서야 할 기준선은 최근에 나왔고 문서화도 잘 되어 있습니다. LFM2.5-24B-A2B는 2026년 10월 13일에 출시되었으며, 총 파라미터 24B에 활성 2B, 40개 레이어, 64개 전문가와 top-4 라우팅, 131,072토큰 컨텍스트, 128K 어휘, 33T 사전 학습 토큰을 갖추고 있습니다. 8월 초에 나온 LFM2.5-2.6B는 128K 컨텍스트로 2.5GB 미만에 들어갑니다. LFM2.5-VL-3B는 2.6B 기본 모델과 SigLIP2 비전 인코더를 결합합니다.

분명히 짚고 넘어가자면, Liquid가 이들에 대해 공개하는 모든 벤치마크는 Liquid 자체 하네스에서 벤더가 직접 실행한 것이며, 독립적인 평가는 포함되지 않는다. LFM2.5-24B-A2B의 대표 수치인 AutomationBench 27.69, BFCLv4 65.01, ToolSandbox 80.71, IFEval 96.75는 Liquid의 수치이며, 같은 표에서 WebArena Verified(26.75 대 37.62), GPQA Diamond, SWE-Bench Verified에서는 Qwen3.6-35B-A3B에 뒤처지는 것으로 나타난다. 패배를 포함한 벤더 표가 그렇지 않은 표보다 더 신뢰할 만하지만, 신뢰할 만하다는 것이 검증되었다는 뜻은 아니다. 어떤 종류의 LFM3 수치도 존재하지 않으므로, 아직 비교할 것은 없다.

라이선스도 그대로 이어질 것입니다. Hugging Face에 있는 Liquid의 최근 LFM 체크포인트는 각각 license: other로 태그되어 있습니다. 이는 Apache-2.0이나 MIT가 아닌 LFM 전용 맞춤 라이선스입니다. LFM3가 어떤 라이선스로 제공되든, 모델 카드에 달리 명시될 때까지 동일한 맞춤 조건이 적용된다고 가정하고, 해당 가중치로 제품을 만들기 전에 이를 읽어 보십시오.

실제로 언제쯤 실현될 수 있을까

전문적으로 추측하는 사람들조차도 아무도 날짜를 모른다. LiquidAI LFM3의 출시 시점에 관한 Manifold Markets 질문은 2026년 4분기를 40%, 2027년 1분기를 21%, 2027년 2분기를 21%, 2026년 3분기를 11%, 2026년 2분기를 7%로 제시한다 — 총 거래량은 약 Ṁ160으로, 이는 소수의 트레이더 의견을 반영할 만큼 작아 합의라고 보기 어렵다. 이는 "아마도 다음 두 분기 안에" 정도로만 읽어야 하며, 그보다 더 정밀하게 받아들여서는 안 된다.

정황상 빠르면 빠를수록 좋다는 쪽에 무게가 실린다. 주요 런타임에 커널 작업이 들어가는 것은 초기 단계가 아니라 후기 단계 엔지니어링이다 — 1년 뒤에나 나올 모델을 위해 CuTe 컨볼루션 커널을 작성하고 하이브리드 캐시를 연결하지는 않는다. 패밀리 이름은 네 가지 변형과 네 개의 체크포인트 경로 전반에서 LFM3로 안정화되었다. 하지만 해당 PR은 병합되지 않았고 세 가지 검사가 모두 빨간 상태이며, 아직 받지 못한 승인 리뷰가 필요하고, 22개 omni 검증 검사 중 2개와 16개 vision 검사 중 2개가 여전히 ROUGE 비교에서 실패한다. 그것은 진행 중인 브랜치이지 릴리스 후보가 아니다.

이번 주에 모델을 선택하려는 경우 이것이 의미하는 바

LFM3에 관한 그 어떤 것도 오늘 내리는 결정을 바꾸어서는 안 됩니다. LFM3는 아직 공개적으로 이용 가능하지도, 가격이 책정되지도, 벤치마크되지도, 라이선스되지도 않았습니다. 지금 소형 멀티모달 모델이 필요하다면 LFM2.5 세대가 현실적인 답이며, 벤더가 보고한 점수, 맞춤형 라이선스, 그리고 Liquid 자체 표와 외부 보도 모두가 약점으로 지목하는 코딩 프로필이라는 제약 조건을 저울질해야 합니다.

유출된 정보가 진정으로 유용한 점은 계획 수립입니다. 이는 콤팩트한 옴니 제품군이 출시될 예정이며, 여러 런타임에 걸쳐 동시에 등장할 가능성이 높고, 그 오디오 변형이 음성을 합성하지 않을 수도 있다는 점을 알려줍니다. 로드맵에서 Liquid의 다음 행보를 더 큰 텍스트 모델로 가정했다면, 지금까지의 증거는 그 가정을 뒷받침하지 않습니다.

런타임 파편화는 이 제품군이 만들어낼 실질적인 문제입니다. Liquid가 llama.cpp, MLX, vLLM, SGLang, ONNX에 동시에 배포해 온 습관은 이식성에는 유리하지만, 하나의 엔드포인트를 원하는 사람에게는 곤란합니다. 다섯 개의 엔진은 곧 다섯 가지 배포 형태, 다섯 가지 전처리 특이점, 그리고 수정 사항이 반영되는 다섯 가지 서로 다른 날짜를 의미합니다. OrcaRouter의 200개가 넘는 모델 카탈로그 오늘날 단 하나의 LFM 체크포인트도 포함되어 있지 않으므로, 이를 통해 LFM3를 호출할 방법이 없으며, 여기 어떤 내용도 그렇게 될 것이라는 약속으로 읽혀서는 안 됩니다. 이런 상황에서 라우팅 계층이 실제로 맡는 역할은 검증되지 않은 모델과 프로덕션 경로 사이의 이음새입니다. 트래픽의 일부를 새로운 무언가로 보내면서 그 뒤에 잘 알려진 모델을 두고 페일오버가 그 간극을 메우게 하는 것이야말로, 고객 대상 기능을 40% 확률의 예측 시장에 걸지 않고도 미출시 제품군의 후속 모델을 평가하는 방법입니다.

주목할 가치가 있는 미해결 질문들

네 가지가 더 이상의 추측보다 이 문제를 더 빨리 해결할 것입니다. 네 개의 체크포인트 경로가 실제로 다운로드 가능한 Hugging Face 저장소가 되는지 여부 — 현재 LiquidAI 조직을 검색하면 LFM3 아래에는 아무것도 나오지 않고, PR에 명시된 저장소들은 공개적으로 확인할 수 없습니다. Transformers PR이 나타나는지 여부 — 이는 아키텍처가 원격 코드를 통해 실행되는 대신 제대로 업스트림되고 있음을 시사할 것입니다. 실패하는 검증 검사가 해결되는지 여부 — 22개의 omni 실패 중 2개는 데모와 병합 사이의 차이이기 때문입니다. 그리고 이 제품군의 >10B 구성원이 등장하는지 여부 — 이것이 Labonne이 LFM3가 존재하는 이유가 답하려는 질문이라고 말한 것입니다.

그때까지는, 누구든 LFM3에 대해 쓸 수 있는 가장 정확한 문장은 이 글이 시작한 바로 그 문장입니다: 풀 리퀘스트가 존재하고, 아직 병합되지 않았으며, Liquid AI가 아직 발표하지 않은 네 개의 소형 옴니 모델을 언급한다는 것입니다. 그것은 실제 신호입니다 — 다만 이른 신호일 뿐이고, 이른 신호는 바로 그렇게 읽혀야 마땅합니다.