LFM2.5-2.6B 공개: 온디바이스 AI 에이전트가 노리는 ‘로컬 실행’의 전환점
Liquid AI가 스마트폰과 노트북에서 도구 호출과 다단계 작업을 수행하도록 설계한 26억 매개변수 모델 LFM2.5-2.6B를 공개했습니다. 성능 주장과 실제 배포 조건을 나눠 살펴봅니다.
클라우드 API에 연결하지 않고 스마트폰과 노트북 안에서 도구를 호출하는 AI 에이전트가 현실적인 선택지로 들어오고 있습니다. Liquid AI는 8월 4일 LFM2.5-2.6B를 공개하며, 26억 매개변수 규모로 계획 수립·도구 호출·다단계 작업을 기기 안에서 처리하도록 설계했다고 밝혔습니다. 128K 컨텍스트와 여러 로컬 추론 형식을 함께 제공해 실험의 문턱도 낮췄습니다. 다만 빠른 속도와 비교 성능 수치는 모두 회사가 공개한 시험 결과이므로, 실제 제품 도입 전에는 사용자의 장치와 업무로 다시 검증해야 합니다.
작은 언어 모델을 ‘에이전트’에 맞춰 다시 훈련했다
공식 모델 카드에 따르면 LFM2.5-2.6B는 실제 매개변수 26억9천만 개, 30개 층으로 구성된 텍스트 전용 모델입니다. 약 34조 토큰으로 사전학습했고, 13만1,072토큰 컨텍스트와 한국어를 포함한 16개 언어를 지원합니다. 일반 대화만 잘하는 소형 모델이 아니라 도구 사용, 데이터 추출, 검색증강생성(RAG), 긴 문맥 작업을 겨냥했다는 것이 핵심입니다.
후속 학습도 그 목적에 맞춰 설계됐습니다. Liquid AI는 지도 미세조정, 영역별 전문 교사 학습, 온폴리시 증류, 실제 에이전트 환경에서의 강화학습을 순서대로 적용했다고 설명합니다. 마지막 단계에서는 여러 에이전트 실행 환경 안에서 모델이 도구 호출과 문서 처리, 조사, 자동화 작업을 수행하도록 훈련했습니다. 즉 에이전트 프레임워크가 모델 바깥의 포장재가 아니라 학습 환경 자체에 들어갔다는 의미입니다.
‘휴대전화에서도 실행’이라는 주장의 구체적 조건
회사가 공개한 측정에서 모델은 2.5GB 미만 메모리로 Apple M5 Max에서 초당 220토큰, Ryzen AI Max+ 395에서 초당 113토큰을 생성했습니다. 휴대전화에서는 초당 30토큰을 기록했다고 밝혔습니다. 고동시성 H100 한 장에서는 초당 약 1만5천 출력 토큰에 도달했다는 결과도 제시했습니다.
하지만 이 숫자를 서로 직접 비교해서는 안 됩니다. CPU 속도는 단일 장치의 응답성에, H100 수치는 지속 부하에서의 총처리량에 초점이 맞춰져 있습니다. 입력 길이, 양자화 방식, 컨텍스트 크기, 발열과 배터리 제한에 따라 체감 성능은 크게 달라질 수 있습니다. ‘휴대전화에서 돈다’는 말은 모든 128K 문맥 작업이 일반 스마트폰에서 같은 속도로 안정적으로 실행된다는 보장이 아닙니다.
배포 선택지가 넓다는 점은 실용적이다
가중치는 Hugging Face에 공개됐고 Transformers용 원본 체크포인트 외에 llama.cpp용 GGUF, Apple Silicon용 MLX, ONNX 형식이 제공됩니다. Liquid AI 배포 문서는 GGUF의 Q4_K_M 양자화 파일을 1.67GB, Q8_0을 2.87GB로 안내합니다. 로컬 서버가 OpenAI 호환 API를 노출하면 기존 에이전트 실행 환경을 그 주소에 연결하는 방식으로 사용할 수 있습니다.
이 구조가 주는 이점은 세 가지입니다. 민감한 입력을 외부 추론 서비스로 보내지 않을 수 있고, 네트워크가 끊겨도 핵심 기능을 유지할 수 있으며, 반복 호출의 건당 API 비용을 줄일 수 있습니다. 현장 점검 앱, 개인 문서 정리, 오프라인 고객 지원, 사내 제한망의 정형 업무처럼 요청량은 많지만 작업 범위가 좁은 곳에서 특히 유용합니다.
반대로 모델 파일을 내려받는다고 개인정보 보호가 자동으로 완성되는 것은 아닙니다. 에이전트가 호출하는 검색·메일·데이터베이스 도구가 외부로 데이터를 전송할 수 있고, 로컬 로그와 캐시도 새로운 유출 지점이 됩니다. 모델의 실행 위치와 전체 작업 흐름의 데이터 경계를 별도로 점검해야 합니다.
벤치마크는 가능성을 보여주지만 독립 검증은 남았다
Liquid AI의 자체 평가에서 LFM2.5-2.6B는 지시 이행과 일부 도구 사용 시험에서 더 큰 Gemma·Qwen 계열 모델과 경쟁하거나 앞섰습니다. 반면 BFCLv4에서는 Qwen3.5-9B에 뒤졌고, 코딩 성능은 큰 모델이 분명히 우세하다고 회사도 인정했습니다. 모델 카드 역시 에이전트형 코딩과 지식 집약 작업에는 권장하지 않는다고 적었습니다.
따라서 이 발표를 “작은 모델이 큰 모델을 대체했다”로 읽는 것은 과합니다. 비교 결과는 공급자가 선택한 모델, 프롬프트, 생성 설정과 실행 환경에서 나온 수치입니다. 온디바이스 모델의 실제 가치는 최고점보다 허용 가능한 품질을 일정한 지연시간과 비용, 데이터 경계 안에서 유지하는지로 판단해야 합니다.
도입 전에 확인할 실무 포인트
- 업무를 좁혀 평가합니다. 자유로운 코딩보다 문서 분류, 정해진 도구 호출, 데이터 추출처럼 성공 조건이 명확한 작업부터 시험합니다.
- 실제 장치에서 측정합니다. 첫 토큰 지연, 초당 토큰, 최대 메모리, 배터리 소모와 장시간 실행 시 발열을 함께 기록합니다.
- 양자화별 품질을 비교합니다. 작은 파일이 항상 최선은 아닙니다. Q4·Q8·고정밀 모델로 도구 인자 정확도와 반복 실패율을 확인합니다.
- 권한을 최소화합니다. 에이전트가 호출할 수 있는 도구와 파일 경로를 작업별로 제한하고, 외부 전송과 쓰기 작업은 별도 승인을 둡니다.
- 공급자 벤치마크를 재현합니다. 공개 점수는 후보 선별에만 쓰고, 자체 데이터셋과 독립 평가로 채택 여부를 결정합니다.
전망: 모든 일을 한 모델에 맡기지 않는 구조
LFM2.5-2.6B가 보여주는 방향은 거대한 클라우드 모델의 종말이 아니라 역할 분담입니다. 개인정보가 민감하거나 반복적인 도구 작업은 기기 안의 소형 모델이 처리하고, 어려운 추론·코딩·지식 작업만 더 큰 모델로 넘기는 계층형 구성이 현실적입니다. 이런 라우팅은 비용과 지연시간을 낮추면서도 필요한 순간에는 높은 성능을 확보할 수 있습니다.
온디바이스 에이전트의 승부처는 매개변수 수보다 배포 완성도입니다. 모델 형식, 도구 호출 호환성, 권한 통제, 관찰 가능성, 업데이트 방식이 함께 갖춰질 때 비로소 ‘로컬 실행’이 데모를 넘어 제품의 기본 선택지가 됩니다.
