리퀴드 AI(Liquid AI)는 2026년 7월 28일 인코더 모델 두 개, LFM2.5-Encoder-230M과 LFM2.5-Encoder-350M을 허깅페이스(Hugging Face)에 오픈웨이트로 공개했다. 두 모델은 8,192토큰 컨텍스트를 지원하며, 8,192토큰 입력 기준 순전파 1회에 ModernBERT-base가 1분 30초 이상 걸리는 동안 230M은 약 28초에 끝낸다. 약 3.7배다. GLUE와 SuperGLUE, 다국어 분류에서 뽑은 17개 과제·14개 모델 비교에서 350M은 4위에 올랐고, 앞선 세 모델은 모두 더 크다. ASAP은 리퀴드 AI 공식 공개 글을 1차 출처로 이 인코더가 어떤 작업의 비용 구조를 바꾸는지 정리한다.

생성 모델이 아니라 인코더가 필요한 자리가 따로 있다

이번 공개의 요지는 성능 순위가 아니라 대상 작업의 선정에 있다. 리퀴드 AI가 예시로 든 용도는 의도 라우터(intent router)와 정책 린터(policy linter), PII 탐지기, 텍스트 분류기다. 공통점은 하루 종일 돌고, 입력이 길어지고, 대개 CPU에서 실행된다는 것이다. 리퀴드 AI는 이런 고빈도 이해 작업에서 파인튜닝된 인코더가 생성형 LLM보다 작고 빠르며 훨씬 저렴하고, 이미 보유한 CPU에 들어간다고 적었다.

이 지점이 최근 2년간 실무에서 자주 어긋난 곳이다. 분류와 라우팅, 추출, 점수화 같은 작업을 프롬프트 한 줄로 처리할 수 있다는 이유로 생성 모델에 밀어 넣는 설계가 표준처럼 굳었지만, 이 작업들은 정확도 요구가 낮은 대신 호출량이 압도적으로 많다. 요청 한 건의 비용 차이가 작아 보여도 상시 실행 구간에서는 그 차이가 그대로 월 청구서가 된다. 인코더 계열이 다시 주목받는 이유는 새로운 능력이 생겨서가 아니라, 에이전트 아키텍처가 늘면서 "매 요청마다 반드시 지나가는 얇은 판정 계층"의 수가 급증했기 때문이다. 게이트 역할에 생성 모델을 쓰는 설계는 규모가 커질수록 유지되기 어렵다.

디코더를 인코더로 되돌리는 방식

두 모델은 각각 LFM2.5-230M, LFM2.5-350M 디코더 백본에서 출발해 인코더로 전환됐다. 전환에 쓰인 변경은 세 가지다. 양방향 어텐션 마스크로 각 토큰이 앞뒤 토큰을 모두 보게 하고, 비인과적 짧은 컨볼루션에 대칭 패딩을 적용해 양쪽 이웃을 섞고, 학습 시 토큰의 30%를 마스킹하는 마스크 언어 모델링을 쓴다. 학습은 두 단계로, 먼저 1,024토큰 컨텍스트에서 대규모 웹 코퍼스로 일반 언어 능력을 익히고, 이후 전체 데이터 믹스로 컨텍스트를 8,192토큰까지 늘리며 사실성과 법률, 다국어 능력을 보강했다.

기존 디코더 자산을 인코더로 재활용하는 이 경로는 비용 측면에서 읽을 만하다. 인코더를 처음부터 학습시키는 대신, 이미 만들어둔 같은 계열 디코더의 표현을 물려받고 마스킹 목적함수로 방향만 바꾼다. 리퀴드 AI가 지난달 공개한 LFM2.5-Retrievers를 재사용하지 않고 별도로 만든 이유도 같은 문장에서 드러난다. 리트리버는 검색에 특화돼 있지만, 마스크 언어 목적함수로 사전학습한 범용 인코더는 분류와 토큰 단위 과제, 검색까지 파인튜닝으로 모두 커버할 수 있다는 것이다. 검색은 인코더가 할 수 있는 일 중 하나일 뿐이라는 설명이다.

숫자를 어떻게 읽을까

가장 확실한 수치는 CPU 지연이다. 두 인코더와 ModernBERT가 모두 8,192토큰을 지원하므로 전 구간 비교가 가능한데, 8,192토큰 지점에서 ModernBERT-base가 순전파 1회에 1분 30초를 넘기는 동안 LFM2.5-Encoder-230M은 약 28초로 끝난다. 230M은 CPU에서 모든 시퀀스 길이에 걸쳐 가장 빨랐고, 짧은 입력에서는 더 작은 ModernBERT-base보다도 빨랐다. 리퀴드 AI는 이를 노트북 CPU에서 계약서나 전사본, 긴 지원 스레드 하나를 30초 안에 훑거나 분류할 수 있다는 뜻으로 옮겼다.

품질 수치는 조금 더 신중히 읽어야 한다. 350M은 14개 모델 중 4위이며, 앞선 세 모델은 모두 더 크고 그중 하나는 약 10배 규모인 3.5B다. 230M은 ModernBERT-base와 모든 EuroBERT 모델을 앞섰다. 다섯 개 홀드아웃 시드의 평균을 보고했고 평가 프레임워크와 원본 결과를 오픈소스로 공개했다는 점은 신뢰도를 높이는 요소다. 다만 순위는 어디까지나 각 과제에 대해 모델 전체를 파인튜닝한 뒤 얻은 점수의 순위다. 즉 이 표는 "그대로 가져다 쓰면 이 성능"이 아니라 "과제별로 파인튜닝했을 때 도달하는 상한"에 가깝다. 실제 도입에서는 과제마다 파인튜닝 파이프라인을 유지하는 비용이 별도로 붙는다.

신중히 볼 대목은 두 가지 더 있다. GPU에서는 격차가 줄어든다. 애플 GPU 기준 약 1K 토큰 미만 구간에서는 ModernBERT-base가 앞서고, 2K 토큰 부근부터 LFM2.5-Encoders가 앞선다. 즉 이 모델의 강점은 "빠른 인코더"가 아니라 "긴 입력을, 특히 CPU에서 빠르게"라는 좁고 분명한 조건 위에 있다. 그리고 공개 글은 CPU 지연을 측정한 프로세서를 명시하지 않았다. 3.7배라는 비율은 동일 조건 비교이므로 유효하지만, 28초라는 절댓값을 자사 하드웨어에 그대로 대입하는 것은 근거가 없다.

국내 실무에 걸리는 지점

한국어 서비스 관점에서 이번 공개가 갖는 실질적 의미는 다국어 과제가 평가 표에 포함됐다는 점과, 데모 중 PII 탐지가 16개 언어에서 40종의 개인정보를 다룬다는 점이다. 다만 공개 글은 언어별 세부 점수를 제시하지 않았으므로 한국어 성능은 이 문서만으로 확인되지 않는다. 도입을 검토한다면 자체 데이터로 파인튜닝한 뒤 재보는 절차가 필수다.

반대로 조건이 맞는 곳에서는 효과가 즉시 계산된다. 개인정보가 외부로 나가면 안 되는 문서 분류, 상담 로그 라우팅, 사내 정책 위반 점검처럼 데이터를 반출하지 않고 사내 CPU 서버에서 상시 돌려야 하는 작업이 대표적이다. 이런 작업은 지금까지 GPU 예산이나 외부 API 비용 때문에 자동화 우선순위에서 밀리는 경우가 많았는데, 8K 컨텍스트를 CPU에서 30초 안에 처리한다면 판단 기준이 달라진다.

한계도 함께 봐야 한다. 공개 글은 라이선스명을 명시하지 않았고, 프로덕션 서빙에서 흔히 쓰는 ONNX나 OpenVINO 변환 경로도 다루지 않았다. 파이토치와 트랜스포머스(transformers) 기반으로 trust_remote_code=True를 요구하는 커스텀 아키텍처라는 점도 사내 배포 심사에서 자주 걸리는 항목이다. 사용 여부를 결정하기 전에 모델 카드에서 라이선스 조건을 직접 확인하고, 목표 런타임에서의 변환 가능성을 먼저 시험해보는 편이 안전하다.

다음 판정 기준

이번 공개가 인코더 계열의 부활을 뜻하는지는 두 가지로 갈린다. 하나는 파인튜닝 비용이다. 범용 인코더는 그 자체로 과제 출력을 내지 않고 과제마다 파인튜닝을 요구하므로, 이 단계가 얼마나 가벼워지는지가 채택 속도를 결정한다. 리퀴드 AI가 8K 컨텍스트 법률 문서 파인튜닝 튜토리얼을 함께 낸 것도 이 병목을 알고 있다는 신호다.

다른 하나는 배포 경로다. CPU에서 빠르다는 강점은 CPU 런타임 생태계에 얹혀야 실현된다. 커뮤니티에서 ONNX·OpenVINO 경로의 부재가 곧바로 지적된 것도 그래서다. 성능 표의 순위보다, 다음 몇 주 안에 이 모델들이 실제 서빙 스택으로 옮겨지는지가 더 정확한 판정 기준이다.

출처: 리퀴드 AI 공식 공개 글 "LFM2.5-Encoders for Fast Long-Context Inference on CPU"(허깅페이스 블로그, 2026년 7월 28일) 기반 ASAP 정리