LFM2.5 8B 공개, 노트북 에이전트의 도구 호출 경쟁

AI 요약

• 무슨 일: Liquid AI가 2026년 5월 28일 LFM2.5-8B-A1B를 공개했습니다.
  • 8.3B total, 1.5B active MoE 모델이며 128K 컨텍스트와 로컬 추론 런타임 지원을 내세웁니다.
• 실무 의미: 로컬 에이전트에서 tool calling, structured output, 지연시간을 큰 모델과 분리하는 실험입니다.
• 주의점: 모델 카드는 heavy programming과 retrieval 없는 지식형 QA에는 최적이 아니라고 제한합니다.
  • LFM Open License v1.0도 1000만 달러 이상 매출 조직의 commercial use를 별도 허가 밖에 둡니다.

Liquid AI가 2026년 5월 28일 LFM2.5-8B-A1B를 공개했습니다. 공식 설명에서 이 모델은 consumer hardware에서 빠르고 안정적인 tool calling을 겨냥한 edge model입니다. 8.3B total 파라미터 중 token당 1.5B active 파라미터만 쓰는 MoE 구조이고, Hugging Face에는 base checkpoint, reasoning-tuned checkpoint, GGUF, ONNX, MLX 변형이 함께 올라왔습니다.

이번 발표는 "작은 모델이 큰 모델을 이긴다"는 식으로 읽으면 곧바로 틀어집니다. Liquid AI의 모델 카드는 추천 용도를 agentic workflows, tool use, structured outputs로 좁힙니다. multilingual assistants와 on-device personal-assistant applications도 추천 목록에 들어갑니다. 같은 문서에서 retrieval 없는 heavy programming이나 knowledge-intensive question answering에는 최적이 아니라고 적었습니다. 적용 범위가 넓은 챗봇보다 로컬 에이전트의 도구 선택과 구조화 출력에 가까운 모델입니다.

발표가 겨냥한 표면은 로컬 도구 호출입니다

LFM2.5-8B-A1B의 숫자는 로컬 에이전트 설계자가 바로 볼 만합니다. Hugging Face 모델 카드 기준으로 24 layers, 18 double-gated LIV convolution blocks, 6 GQA layers, 38T training tokens, 131,072 context length, 128,000 vocabulary입니다. 이전 LFM2-8B-A1B에서 context window는 32,768 tokens였고, vocabulary는 65,536이었습니다. Liquid AI는 이번 모델에서 context를 128K로 늘리고 vocabulary를 두 배로 확장했다고 설명합니다.

개발자에게 더 직접적인 부분은 런타임 지원입니다. Liquid AI는 day-one support 대상으로 llama.cpp, MLX, vLLM, SGLang을 적었고, Hugging Face 모델 카드에는 Transformers, vLLM, llama.cpp, MLX, LM Studio 문서 링크가 붙어 있습니다. 모델을 클라우드 API로만 써야 하는 발표가 아니라, Mac, 로컬 GPU, CPU offload, server batch inference 사이에서 배포 경로를 고를 수 있는 공개입니다.

이 차이는 에이전트 제품에서 중요합니다. 도구 호출은 한 번의 답변보다 반복 호출이 많습니다. 파일 열기, 검색, OCR, 일정 읽기, 로컬 DB 조회, 보안 스캔, diff 생성 같은 작업이 한 세션 안에서 여러 번 일어나면 frontier model 호출 비용과 왕복 지연시간이 쌓입니다. LFM2.5-8B-A1B가 겨냥하는 자리는 모든 판단을 대신하는 두뇌가 아니라, 로컬에서 빠르게 도구 후보를 고르고 structured output을 만드는 실행면입니다.

128K 컨텍스트와 128K vocabulary가 바꾸는 비용

Liquid AI는 이전 8B/A1B 모델 대비 pretraining을 12T에서 38T tokens로 늘렸고, tokenizer vocabulary를 65,536에서 128,000으로 확대했습니다. 공식 블로그의 tokenizer 표에서 Korean chars/token은 old tokenizer 1.652에서 new tokenizer 1.943으로 17.6% 개선됐습니다. Hindi는 0.961에서 2.118로 120.4%, Thai는 0.671에서 2.269로 238.2%, Vietnamese는 1.519에서 3.311로 117.9% 개선됐다고 제시됩니다.

한국어 개발자에게 이 숫자는 단순한 다국어 홍보가 아닙니다. 로컬 에이전트가 사용자의 파일명, 캘린더 제목, 채팅 문장, 사내 용어를 prompt에 넣을 때 tokenization 효율은 context 비용과 latency에 직접 연결됩니다. 같은 한국어 문장을 더 적은 token으로 담을 수 있으면 128K context 안에서 도구 설명, 현재 상태, audit log, 검색 결과를 더 많이 넣을 수 있습니다.

context 확장 방식도 공개됐습니다. Liquid AI는 reasoning, math, tool-use, longer documents에 초점을 둔 2T token midtraining으로 먼저 32K context를 만들었습니다. 그다음 RoPE base theta를 늘리고, long-document와 long-trajectory data에 초점을 둔 400B token midtraining으로 128K까지 확장했다고 설명합니다. 긴 문서를 읽는 모델이라기보다, 긴 도구 실행 궤적과 여러 단계 상태를 품기 위한 설계로 읽는 편이 정확합니다.

벤치마크는 도구 호출 쪽으로 읽어야 합니다

공식 벤치마크에서 Liquid AI는 이전 LFM2-8B-A1B 대비 여러 지표가 올랐다고 주장합니다. IFEval은 79.44에서 91.84, IFBench는 26.00에서 56.47, Multi-IF는 58.54에서 79.93, BFCLv4는 25.52에서 48.50으로 올라갔습니다. agentic workflow 쪽 지표인 Tau2 Telecom은 13.60에서 88.07로 큰 폭의 차이를 보였습니다.

이 차트는 성능 비교의 시작점이지 결론은 아닙니다. Reddit r/LocalLLaMA 반응에서도 일부 사용자는 비교 대상이 이상하거나 오래된 모델이 섞였다고 지적했습니다. 반대로 title generation, summarization, tagging, categorization처럼 좁은 업무에는 적합해 보인다는 의견도 있었습니다. 벤치마크 표를 제품 결정으로 바로 옮기기보다, 각 팀의 도구 스키마와 실패 비용에 맞춘 자체 eval이 필요합니다.

평가 기준은 "답이 똑똑한가"보다 구체적이어야 합니다. 모델이 적절한 도구를 골랐는가. 필수 인자를 빠뜨리지 않았는가. 모호할 때 되물었는가. 위험한 쓰기 작업을 승인 없이 실행하려 하지 않았는가. 도구 설명을 약간 바꿔도 안정적인가. 후보 도구 수가 10개에서 70개로 늘어도 성능이 유지되는가. 로컬 에이전트의 품질은 이런 질문에서 갈립니다.

LocalCowork 데모가 보여주는 제품 구조

Liquid AI의 공식 cookbook에는 LocalCowork라는 데모가 있습니다. README는 Tauri 2.0, Rust agent core, React/TypeScript UI, MCP servers, OpenAI-compatible localhost inference API로 구성된 로컬 데스크톱 에이전트를 설명합니다. 도구는 14개 MCP server에 75개가 있고, 데모는 6개 server와 20개 curated tools를 사용한다고 적었습니다.

이 구조에서 모델은 앱 전체가 아닙니다. MCP server discovery, tool registry, audit log, permission store, confirmation dialog 같은 주변 장치가 있어야 로컬 에이전트가 제품이 됩니다. LocalCowork README도 confirmation system은 만들어져 있지만 agent loop에는 아직 연결되지 않았고, 현재는 모델이 고른 도구가 즉시 실행된다고 설명합니다. 쓰기 작업에는 preview와 confirmation이 필요하다는 문장이 바로 뒤따릅니다.

LFM2.5-8B-A1B 발표를 실무적으로 읽는다면 이 부분이 더 큽니다. 로컬 모델이 빨라져도 부작용이 있는 도구 실행은 정책 엔진과 UI 승인선을 통과해야 합니다. 파일 삭제, 이메일 발송, 결제, 권한 변경, 외부 API 호출은 모델 confidence만으로 실행하면 안 됩니다. 작은 active parameter는 latency를 줄일 수 있지만, 권한 모델을 대신하지 않습니다.

라이선스는 open-weight와 open-source를 갈라놓습니다

Liquid AI는 모델을 Hugging Face에 공개했고 여러 포맷을 제공합니다. 다만 라이선스는 Apache 2.0이나 MIT가 아닙니다. Hugging Face metadata에는 license: other, license_name: lfm1.0이 적혀 있습니다. LFM Open License v1.0 본문은 commercial use limitation을 둡니다. annual revenue 1000만 달러 이상인 legal entity의 commercial use는 이 agreement 아래에서 허가되지 않는다고 명시합니다.

이 제한은 연구자, 개인 개발자, 작은 스타트업에는 문제가 아닐 수 있습니다. 하지만 제품팀이 고객 데이터가 들어가는 로컬 에이전트 기능에 모델을 넣으려면 법무 검토가 먼저입니다. 특히 온디바이스 모델은 "다운로드해서 앱에 포함하면 된다"는 착시를 만들기 쉽습니다. 앱 배포, fine-tuned derivative, enterprise customer bundle, managed service 제공이 모두 commercial use 해석에 걸릴 수 있습니다.

Reddit 반응에서도 이 점이 바로 나왔습니다. 한 사용자는 "open-weight" 표현은 맞을 수 있지만 "without restrictions"처럼 읽히는 문구는 라이선스와 맞지 않는다고 지적했습니다. 로컬 AI 생태계에서 모델 포맷의 개방성과 상업적 사용 권리는 별개입니다. LFM2.5-8B-A1B도 weights와 runtime path는 열려 있지만, 대기업 상업 사용은 별도 계약 영역으로 남습니다.

reasoning-only 모델이라는 운영상의 질문

공식 블로그는 LFM2.5-8B-A1B가 reasoning-only model이며 final answer 전에 explicit chain of thought를 만든다고 설명합니다. Hugging Face 모델 카드도 assistant turns에 explicit chain of thought가 포함된다고 안내합니다. 이 설계는 품질을 높일 수 있지만, 제품 통합에서는 별도의 출력 처리 문제가 됩니다.

로컬 에이전트가 내부 추론을 그대로 UI에 보여주면 사용자는 긴 중간 사고를 보게 됩니다. 로그에 남기면 민감한 파일명, 사용자 요청, 도구 인자, 잘못된 추론이 audit trail에 섞일 수 있습니다. 반대로 완전히 버리면 debugging과 eval이 어려워집니다. 따라서 앱은 final answer, tool call, internal reasoning, audit event를 다른 데이터 등급으로 나눠 저장해야 합니다.

초기 호환성 문제도 확인됐습니다. r/LocalLLaMA 댓글에는 llama.cpp에서 <think> tags가 출력되거나 tool calling이 기대대로 작동하지 않는다는 보고가 있었습니다. tokenizer 지원 PR과 GGUF metadata에 대한 언급도 나왔습니다. 발표 당일의 day-one support는 실제 운영 안정성과 같은 말이 아닙니다. 로컬 런타임은 모델 카드, tokenizer, chat template, quantization, tool call format이 모두 맞아야 합니다.

개발자가 지금 확인할 체크리스트

LFM2.5-8B-A1B를 검토하는 팀은 먼저 업무를 나눠야 합니다. 단순 도구 라우팅, 긴 추론, 검색 기반 답변, 코드 수정, 위험한 쓰기 작업은 서로 다른 모델 경로와 승인 정책이 필요합니다. 이 모델은 도구 호출과 structured output에는 후보가 될 수 있지만, 모델 카드가 말하듯 retrieval 없는 지식형 QA나 heavy programming을 맡길 기본 모델은 아닙니다.

두 번째는 자체 eval입니다. 공식 benchmark chart보다 사내 tool schema 20개, 50개, 100개에서의 선택 정확도가 더 중요합니다. 모호한 요청에서 되묻는지, 없는 도구를 꾸며내지 않는지, dangerous tool 앞에서 confirmation flag를 세우는지, 한국어 파일명과 사내 용어를 안정적으로 tokenization하는지 확인해야 합니다. Korean chars/token 17.6% 개선은 좋은 출발점이지만, 제품 문장과 로그에서는 별도 측정이 필요합니다.

세 번째는 fallback입니다. 작은 active parameter 모델이 빠른 첫 번째 라우터가 될 수 있어도, 실패할 때 큰 모델이나 사용자 확인으로 넘어가는 경로가 있어야 합니다. confidence threshold, schema validation, dry-run mode, human approval, audit log를 붙이면 로컬 모델의 장점을 살리면서 실행 위험을 줄일 수 있습니다.

결론: 작은 active parameter는 권한 설계와 함께 봐야 합니다

LFM2.5-8B-A1B는 온디바이스 에이전트 논의에서 좋은 시험대입니다. 8.3B total과 1.5B active라는 숫자는 노트북과 로컬 워크스테이션에서 도구 호출을 빠르게 처리하려는 팀에게 매력적입니다. 128K context, 128K vocabulary, GGUF와 MLX 배포는 로컬 개발자가 실험하기 좋은 조건을 만듭니다.

동시에 이 모델은 경계도 분명합니다. 라이선스는 대기업 상업 사용을 자동 허가하지 않습니다. 모델 카드는 heavy programming과 retrieval 없는 지식형 QA에는 최적이 아니라고 적었습니다. reasoning-only 출력은 UI와 로그 설계를 요구합니다. 발표 당일 커뮤니티 반응은 초기 llama.cpp와 tool calling 호환성 검증이 필요하다는 신호도 줬습니다.

로컬 에이전트의 다음 경쟁은 모델 크기 하나로 정리되지 않습니다. 어떤 판단을 로컬 MoE에 맡기고, 어떤 판단을 frontier model로 올리고, 어떤 실행을 사람 승인 뒤에 둘 것인가가 제품 품질을 가릅니다. LFM2.5-8B-A1B 공개는 그 질문을 구체적인 모델, 포맷, 수치, 라이선스 위에서 다시 묻게 만든 사건입니다.

출처

• Liquid AI 공식 발표.
• LFM2.5-8B-A1B Hugging Face 모델 카드.
• LFM Open License v1.0.
• Liquid LocalCowork 공식 데모 저장소.
• r/LocalLLaMA 토론.