Liquid 8B-A1B, 온디바이스 에이전트의 비용 곡선

8B지만 활성 파라미터는 1B라는 주장

Liquid AI의 LFM2.5-8B-A1B 발표는 온디바이스 에이전트 경쟁의 방향을 잘 보여준다. 모델 이름의 8B-A1B는 전체 8B 규모 Mixture-of-Experts 구조지만 토큰당 활성 파라미터는 약 1B라는 뜻으로 읽힌다. Liquid는 2025년 10월 LFM2-8B-A1B에서 12T 토큰으로 학습했던 것을 이번에는 38T 토큰으로 늘렸고, 컨텍스트도 128K로 확장했다고 밝혔다.

핵심은 채팅 성능만이 아니다. Liquid는 이 모델을 소비자 하드웨어에서 빠르고 안정적인 tool calling을 수행하는 edge model로 포지셔닝한다. Hugging Face 모델과 Liquid 문서를 통해 로컬 실행과 미세조정을 안내하고, llama.cpp, MLX, vLLM, SGLang 지원도 강조한다.

Forge, 작은 로컬 모델을 에이전트로 쓰는 법에서 본 흐름과 같다. 작은 모델은 큰 모델의 저렴한 대체재가 아니라 다른 배치 위치를 갖는다. 노트북, 사내 서버, 모바일, 폐쇄망, 현장 장비처럼 네트워크와 데이터 제약이 있는 곳이다.

도구 호출이 로컬 모델의 승부처다

Liquid는 agentic benchmark에서 LFM2.5-8B-A1B가 더 큰 모델들과 경쟁 가능하고 Tau2-Telecom에서 강하다고 주장한다. 외부 비교는 Artificial Analysis 같은 독립 벤치마크를 계속 확인해야 하지만, 방향은 분명하다. 로컬 모델의 가치는 "그럴듯한 답변"보다 "작은 도구 호출을 안정적으로 이어가는 능력"으로 이동하고 있다.

에이전트는 많은 요청을 반복한다. 파일을 읽고, 함수를 호출하고, JSON을 만들고, 실패하면 다시 시도한다. 이 작업을 매번 대형 클라우드 모델에 보내면 비용, 지연시간, 데이터 반출 문제가 쌓인다. 그래서 작은 모델이 초벌 분류, 로컬 검색, 개인화된 명령 실행, 민감 문서 요약을 맡고, 큰 모델은 고난도 판단에 쓰이는 계층 구조가 현실적이다.

128K 컨텍스트가 항상 답은 아니다

128K 컨텍스트는 분명 매력적이다. 하지만 긴 컨텍스트는 로컬 환경에서도 비용이 된다. 메모리와 latency가 늘고, 에이전트가 불필요한 정보를 계속 들고 다니면 오히려 판단이 흐려진다. Semble, 에이전트 코드 검색의 토큰세를 줄이다가 말한 문제와 같다. 긴 창보다 좋은 검색, 요약, 상태 관리가 더 중요할 때가 많다.

Liquid가 어휘 크기를 두 배로 늘려 비라틴 언어 토큰화를 개선했다고 밝힌 점은 한국어 사용자에게 의미가 있다. 한국어는 토큰화 효율이 낮으면 같은 문서도 더 비싸고 느리게 처리된다. 다만 실제 한국어 품질은 벤치마크 표보다 내부 문서, 고객 상담, 개발 로그로 직접 평가해야 한다. 로컬 모델 도입은 데모보다 테스트 세트 설계가 중요하다.

기업 도입 기준은 작게 시작해야 한다

한국 기업이 이런 모델을 검토할 때 첫 질문은 "GPT급인가"가 아니다. "이 모델에게 맡겨도 되는 작은 반복 업무는 무엇인가"다. 예를 들어 사내 문서 태깅, 코드베이스 심볼 검색, 개인정보가 섞인 로그 요약, 회의 전 로컬 브리핑, 오프라인 장비 매뉴얼 질의응답 같은 업무가 후보가 된다.

Gemini 3.5 Flash, 에이전트 속도전의 신호탄은 클라우드에서도 속도 경쟁이 치열하다는 사실을 보여줬다. 로컬 모델은 이 경쟁의 다른 축이다. 빠른 클라우드 모델과 작은 로컬 모델을 함께 쓰는 설계가 앞으로의 기본값이 될 가능성이 높다.

자주 묻는 질문

Q1: LFM2.5-8B-A1B는 오픈 모델인가요?

A: Liquid는 base와 post-trained 모델을 Hugging Face와 Playground에서 제공한다고 밝혔다. 라이선스와 사용 조건은 배포 페이지에서 확인해야 한다.

Q2: 온디바이스 모델이면 인터넷 없이 쓰나요?

A: 가능성은 있지만 제품 설계에 따라 다르다. 로컬 추론은 데이터 반출과 지연시간을 줄이지만 업데이트와 권한 관리가 필요하다.

Q3: 128K 컨텍스트는 무조건 좋은가요?

A: 아니다. 긴 컨텍스트는 비용과 지연시간을 늘릴 수 있다. 검색과 요약 설계가 함께 필요하다.

Q4: 한국어에는 유리한가요?

A: Liquid는 비라틴 언어 토큰화 효율 개선을 언급했다. 실제 한국어 업무 품질은 자체 테스트로 확인해야 한다.

Q5: 가장 현실적인 활용처는 무엇인가요?

A: 민감 데이터가 있는 반복 도구 호출, 로컬 검색, 분류, 사내 문서 보조처럼 작은 작업부터 시작하는 것이 현실적이다.