Liquid AI, LFM3 공개: 2B급 모델 6종이 하나의 백본 공유, 오픈 웨이트 환경의 엣지 트레이드오프
Liquid AI의 2026년 10월 27일 블로그에 따르면, LFM3는 텍스트·비전·오디오·옴니모달·결정 모델을 1.7B급 공유 백본으로 통합했으며 전 모델 오픈 웨이트, 단일 GPU 파인튜닝이 가능하다고 주장한다. 개발자는 옴니모달 단일 모델과 전용 소형 모델 두 노선을 다시 저울질해야 한다.
주요 변화
Liquid AI는 2026년 10월 27일 공식 블로그에서 LFM3 시리즈를 발표했다. 블로그에 따르면 이 시리즈는 2B급 모델 6종으로 구성된다. LFM3-1.7B(텍스트), LFM3-VL-2B(텍스트·이미지·영상 입력), LFM3-Audio-2B(텍스트·오디오 입력, 텍스트·음성 출력), LFM3-Omni-2B(옴니모달 입력, 텍스트·음성 출력), 그리고 비전·옴니모달 분기를 기반으로 한 결정 모델 d1-2B와 d1-omni-2B가 있다. 별도로 자체 후속 학습용 LFM3-1.7B-Base도 제공된다. 제조사는 모든 모델이 동일 백본에서 분기되었으며 Hugging Face에서 받을 수 있고 단일 GPU에서 파인튜닝 가능하다고 밝혔다. 텍스트 모델은 4-bit 정밀도에서 약 1GB를 차지하며 백본 컨텍스트 창은 256K 토큰으로 확장됐다. 블로그는 비교 수치도 제시했는데, 예를 들어 LFM3-1.7B는 WebArena-Verified에서 38.42를 기록해 전 세대 LFM2.5-2.6B의 3.02를 크게 앞섰고, LFM3-VL-2B는 62개 비전 벤치마크 평균이 57.6에서 71.4로 올랐다. 제조사는 또한 파라미터 기준으로 LFM3-1.7B가 엣지 기기에서 짧은 프롬프트에서는 LFM2-1.2B와 비슷하고, 컨텍스트에 8K 토큰이 포함될 때는 약 25% 빠르다고 주장한다. 이 수치는 모두 제조사 자체 보고이며 제3자 재현은 확인되지 않았다.
개발자에게 미치는 영향
개발자에게 이번 발표의 핵심 영향은 모델이 하나 더 늘었다는 것이 아니라 선택 단위가 달라졌다는 점이다. 지금까지 기기 단에서 멀티모달을 돌리려면 보통 ASR, 비전 언어 모델, TTS를 파이프라인으로 엮어야 했지만, 이제 제조사가 옴니모달 단일 모델 옵션을 제공한다. 다만 단일 모달 모델도 함께 남겨두었다는 것은 멀티모달 통합이 모든 시나리오에서 유리하지는 않을 수 있음을 시사한다. 추론 측 제약도 달라진다. 비전 모델은 transformers 5.21.0 이상, 오디오·옴니모달 모델은 5.20.2 이상, d1은 5.19 이상을 요구하며 대부분 예제가 trust_remote_code에 의존하므로, 프레임워크 업그레이드와 사용자 정의 원격 코드 검토가 도입 전 선행 작업이 된다. 엣지 메모리 측면에서 텍스트 모델의 4-bit 약 1GB는 계획 가능한 수치지만, 블로그는 비전·오디오 모델의 VRAM이나 메모리 사용량을 제시하지 않았으므로 영상 입력과 음성 스트리밍 출력의 실제 자원 비용은 직접 측정해야 한다. 블로그는 새 비전 인코더와 LiquidCodec의 효율을 강조하며 오디오 첫 토큰이 최저 50ms, 단일 CPU 스레드에서 약 87배 실시간 음성 합성이 가능하다고 주장하지만, 이런 지표는 하드웨어와 입력 길이에 크게 의존하므로 그대로 온라인 용량 계획 근거로 삼기 어렵다. 제조사는 SFT, DPO, GRPO, 지속 사전학습을 다루는 파인튜닝 노트북도 제공하는데, 사내 용어와 도구 호출이 필요한 팀에게는 벤치마크 점수보다 먼저 검증해볼 만한 부분이다.
연동 및 평가 제안
권고 1(조건부 분석): 엣지 애플리케이션이 같은 요청에서 음성과 화면을 함께 처리해야 한다면, 옴니모달 단일 모델과 '오디오 모델 + 비전 모델' 조합을 먼저 비교하라. 트리거 조건은 한 요청 안에 실제 교차 모달 연관성이 존재하는 경우, 예컨대 한 프레임 화면을 보며 말로 질문하는 상황이다. 음성과 영상이 업무상 무관하다면 전용 모델의 통제성이 대체로 더 낫다. 측정 기준: 동일한 실제 샘플 세트에서 첫 토큰 지연, 종단 완료 시간, 메모리 피크를 비교하고, 옴니모달 모델이 순수 텍스트나 순수 음성 하위 작업에서 전용 모델 대비 뚜렷한 성능 저하를 보이는지 확인하라. 권고 2(조건부 분석): 이미 LFM2.5 계열 기반 추론 서비스를 운영 중이라면 WebArena-Verified 38.42 대 3.02 같은 제조사 수치만 보고 바로 전환하지 말고, 자체 에이전트 궤적으로 A/B 테스트를 먼저 하라. 트리거 조건은 워크로드가 긴 컨텍스트 도구 호출 중심인 경우다. 블로그는 업그레이드 이득이 주로 에이전트 작업과 긴 컨텍스트에서 나타난다고 하며, 짧은 프롬프트 비교는 파라미터 기준 계산이지 절대 성능 동등을 뜻하지 않는다. 측정 기준: 자체 구축한 작업 세트에서 도구 호출 성공률, 형식 준수율, 1천 토큰당 실제 소요 시간을 기록하라. 공개 리더보드만 보지 말아야 한다. 권고 3(조건부 분석): 자유 텍스트 생성보다 구조화된 판단에 관심이 있다면 d1-2B가 '소형 언어 모델 + 파싱 후처리' 방식을 대체할 수 있는지 평가하라. 전제는 업무가 자연어 대신 보정된 확률 출력을 받아들일 수 있어야 한다는 점이다. 하류에서 설명 가능한 텍스트가 필요하다면 d1 노선은 적합하지 않다. 측정 기준: 라벨이 붙은 과거 티켓이나 전표로 각 필드의 보정 오차를 계산하고, 1회 순전파의 처리 지연을 기존 파이프라인과 비교하라.
제한과 확인할 사항
출처는 제조사 블로그로, 벤치마크 점수·속도·메모리 수치는 모두 자체 보고이며 독립 재현이나 완전한 평가 방법이 제공되지 않았다. 블로그 내부의 비교 기준(예: 일부 인코더 비교가 통일된 LFM2.5-230M 언어 백본을 사용)도 직접 확인해야 한다. 블로그는 모든 LFM3 모델이 오픈 웨이트라고 하지만 본문에 구체적 라이선스 조항은 명시되지 않았다. 오픈 웨이트는 오픈소스 라이선스와 같지 않으며, 상업적 이용·재배포·파인튜닝 후 공개 권리는 모델 카드와 라이선스 문구를 기준으로 판단해야 하고 '가중치를 내려받을 수 있다'는 것에서 추론해서는 안 된다. LFM3 각 모델은 현재 KimiSeek 온라인 카탈로그에 대응 항목이 없으며, 해당 버전은 현재 KimiSeek에 게시되지 않았다. 블로그도 호스팅 API를 제공하지 않으며, 말하는 가용성은 Hugging Face에서의 가중치 다운로드와 로컬 실행을 뜻한다. 향후 호스팅 서비스나 별도 가격이 나온다면 공식 페이지를 기준으로 삼아야 한다. 또한 예제가 trust_remote_code에 의존하므로 프로덕션 환경에서는 원격 코드를 직접 감사해야 한다. 영상 입력, 음성 스트리밍, 다국어 음성 번역 등의 실제 효과와 자원 사용량은 블로그가 소수 예시만 제시했으므로 직접 검증해야 한다.
원문 보도의 이미지
