디바이스 위에서 뛰는 빠른 사적 에이전트, LFM2.5-24B-A2B

Liquid AI가 Hugging Face 블로그에 올린 글 Run fast, private agents on-device with LFM2.5-24B-A2B는 24B 파라미터 Mixture-of-Experts 모델 LFM2.5-24B-A2B를 소개하는데, 토큰당 약 2B 파라미터만 활성화해서 디바이스와 엣지에서 빠르고 사적인 에이전트를 돌리겠다고 제안합니다. 이번 글에서는 그 주장과 설계, 배포 조건, 남은 질문을 차례로 따라가며, 원문 링크는 제목 아래에 걸어 두었습니다.

제가 이 발표를 그냥 넘기지 못한 이유

안녕하세요, 패트릭입니다.

에이전트 이야기를 듣다 보면 묘한 피로가 쌓일 때가 있습니다. 데모는 매번 시원한데 막상 써보면 토큰 요금 고지서가 먼저 도착하고, 사내 문서를 올리려니 보안팀의 눈치가 보이죠. 비행기 와이파이가 끊기는 순간 에이전트도 함께 멈추니까요. 그래서 저는 요즘 에이전트 발표를 볼 때 성능표보다 먼저 묻게 됩니다. 이거, 내 자리에서 돌릴 수 있나요.

LFM2.5-24B-A2B 발표가 눈에 밟힌 지점도 바로 여기였습니다. 24B를 통째로 깨우는 게 아니라 토큰당 2B 정도만 깨워서 노트북과 소비자 GPU 같은 일상적인 기계에서 에이전트를 돌리겠다는 제안이었기 때문입니다. 숫자로 보면 12분의 1쯤 쓰는 셈인데, 그 절약이 실제로 도구 호출과 코드 생성, 여러 단계 추론까지 버텨내는지가 궁금했습니다.

저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 전체가 크다는 사실과 매번 움직이는 부분이 작다는 사실은 전혀 다른 이야기거든요. 전자는 저장 공간의 문제이고, 후자는 매 토큰마다 내는 전기료와 대기 시간의 문제입니다. 에이전트는 한 번 답하고 끝나는 챗봇이 아니라 수십 번을 부르고 고치고 다시 부르는 존재라서 후자가 체감을 가릅니다. 그렇다면 Liquid AI는 이 차이를 어떤 설계로 메우겠다고 말할까요. 이제 하나씩 뜯어보겠습니다.

24B인데 2B만 쓴다는 말은 무슨 뜻일까

MoE라는 말을 들으면 어떤 그림이 먼저 떠오르시나요. 저는 큰 도서관에 사서 수십 명이 앉아 있는데, 질문이 들어올 때마다 그중 두세 명만 일어나서 답하는 장면을 떠올립니다. LFM2.5-24B-A2B의 24B는 그 도서관 전체 장서의 양에 해당하고, 토큰당 2B 활성화는 매번 실제로 일어나는 사서의 수에 가깝습니다.

여기서 재미있는 질문이 생깁니다. 도서관이 크면 뭐가 좋을까요. 아는 분야가 넓어진다는 뜻입니다. 반면 매번 일어나는 사람이 적으면 뭐가 좋을까요. 그날의 인건비가 싸진다는 뜻이니까요. 모델로 돌아오면 전체 파라미터는 기억하고 있는 지식과 기능의 폭을 넓히고, 활성 파라미터는 매 토큰을 만들 때 드는 연산과 메모리 접근을 줄여줍니다. 그래서 발표는 크기와 가벼움을 동시에 잡겠다고 말하는 것입니다.

물론 도서관이 크다는 건 책을 둘 창고가 필요하다는 뜻이기도 합니다. 24B라는 전체 크기는 디스크와 메모리에 어딘가 얹혀 있어야 합니다. 반대로 매번 2B만 깨운다는 건 발전기 용량을 작게 잡아도 된다는 뜻이니까요. 저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 보기 때문이죠. 이 모델도 같은 잣대로 읽어야 합니다. 저장 비용은 그대로 안고 가되 실행 비용을 낮추는 선택이니까요.

그렇다면 다음 의문이 바로 이어집니다. 가벼워진 실행이 에이전트 일을 감당할 수 있을까요. 답은 설계가 에이전트를 얼마나 염두에 뒀는지에 달려 있고, 그 이야기가 다음 대목으로 이어집니다.

에이전트용이라는 말의 무게를 재는 법

요즘은 웬만한 모델 소개에 에이전트용이라는 수식이 붙습니다. 솔직히 이 말을 들을 때마다 저는 한 번 더 묻게 됩니다. 함수 호출 스키마를 잘 지키는 건가요, 아니면 여러 단계를 스스로 굴릴 수 있는 건가요. 둘은 전혀 다른 근육이거든요.

발표가 말하는 에이전트 체력은 후자에 가깝습니다. 도구 사용과 함수 호출, 여러 단계 추론, 코드 생성을 함께 내세우니까요. 생각해보면 사람도 비슷하게 일합니다. 한 번에 끝내는 일보다 찾아보고 실행하고 결과를 보고 다시 고치는 일이 훨씬 많죠. 에이전트도 마찬가지인데, 이 반복을 버티려면 모델이 중간 결과를 놓치지 않고 다음 호출로 넘겨야 합니다.

제가 이 대목에서 가장 흥미롭게 본 부분은 코드 생성의 위치입니다. 에이전트에게 코드는 말이 아니라 손이거든요. 파일을 고치고 테스트를 돌리고 로그를 읽는 일은 전부 코드와 도구 호출로 이어지죠. 그래서 코드 생성과 함수 호출이 같이 묶여 있다는 건, 이 모델이 대화만 잘하는 게 아니라 손발까지 움직이겠다는 선언처럼 읽힙니다.

다만 여기서는 조금 조심해서 읽을 필요가 있습니다. 발표 자료가 내세우는 비교는 대체로 크고 닫힌 모델들과의 겨룸인데, 그 판의 룰이 무엇인지가 공개된 요약만으로는 다 안 보이거든요. 에이전트와 코딩, 지시 따르기에서 경쟁력이 있다는 말은 방향으로는 분명하지만, 어떤 작업 분포에서 그 말이 성립하는지는 따로 확인해야 합니다. 그 이야기는 뒤쪽 벤치마크 대목에서 다시 짚겠습니다.

왜 활성 파라미터가 작으면 체감이 달라질까

에이전트의 체감 속도는 한 번의 답이 얼마나 번뜩이는지가 아니라 수십 번의 호출이 얼마나 지치지 않고 이어지는지로 정해집니다. 밤늦게 노트북 앞에서 에이전트에게 리팩터링을 시켜본 분은 아실 겁니다. 처음 두어 번은 빠른데 호출이 쌓이면서 점점 숨이 차오르죠.

활성 파라미터가 작은 구조는 바로 이 지점을 찌릅니다. 매 토큰마다 끌어와야 하는 가중치가 적으면 메모리 대역폭 부담이 줄고, 같은 시간에 더 많은 토큰을 밀어낼 여지가 생깁니다. 처리량이 오른다는 말의 실체는 대체로 이것입니다. 한 번에 크게 터뜨리는 게 아니라 여러 번을 꾸준히 밀어내는 힘이니까요.

일종의 합승이라고 보면 됩니다. 큰 차를 혼자 타면 기름이 많이 들지만, 목적지가 같은 사람끼리 나눠 타면 한 사람당 부담이 줄어드니까요. MoE에서 토큰마다 필요한 전문가만 깨우는 것도 비슷한 발상인데, 매번 전원을 다 켜지 않고 필요한 방의 불만 켜는 셈입니다. 에이전트처럼 호출이 많은 작업에서는 이 절약이 한 번으로 끝나지 않고 호출 횟수만큼 곱해지죠.

문제는 그다음입니다. 가벼움이 매번 올바른 전문가 고르기에 달려 있기 때문이죠. 라우팅이 흔들리면 엉뚱한 사서가 일어나서 엉뚱한 답을 들고 옵니다. 발표는 빠른 에이전트를 약속하지만, 그 약속 뒤에는 라우팅의 안정성이 숨어 있죠. 저는 그래서 속도 숫자만큼이나 어떤 호출 분포에서 그 속도가 유지되는지를 보고 싶었습니다.

그렇다면 이 속도는 어디에서 발휘된다는 걸까요. 이야기는 자연스럽게 그 속도가 놓이는 기계 위로 넘어가는데, 다음 대목에서는 노트북이라는 조건부터 따져보겠습니다.

노트북에서 돈다는 말을 곧이곧대로 믿기 전에

노트북에서 돈다는 말은 참 달콤합니다. 출근길 지하철에서 오프라인으로 에이전트가 돌아가는 그림을 상상해 보십시오. 클라우드 요금도 없고 전송 대기 시간도 없으며, 사내 문서를 밖으로 안 내보내도 되니까요. 그런데 이 말을 곧이곧대로 믿기 전에 조건을 봐야 합니다.

전체 24B를 어딘가에 올려야 한다는 사실은 그대로입니다. 랩톱의 메모리와 디스크가 그 무게를 감당해야 하고, 추론 스택이 MoE 실행을 제대로 지원해야 합니다. 발표는 소비자 GPU와 노트북을 겨냥한 고처리량 설계와 양자화 친화 구조를 내세우는데, 이건 맨몸으로 뛴다는 뜻이 아니라 뛸 수 있게 길을 닦아 두었다는 뜻에 가깝습니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 어떤 정밀도로 얹을 때, 어떤 스택 위에서, 어느 정도 작업 길이까지 그 속도가 유지될까요. 양자화를 걸면 메모리는 가벼워지지만 정밀도 손해가 생길 수 있고, MoE 라우팅은 모든 런타임에서 똑같이 빠른 게 아니거든요. 발표가 말하는 로컬 호환성은 그래서 선언이 아니라 숙제에 가깝습니다. 인기 있는 로컬 추론 스택들과 맞물린다는 말이 있지만, 버전과 하드웨어 조합마다 체감은 달라질 수밖에 없죠.

그럼에도 저는 이 방향을 가볍게 보지 않습니다. 에이전트가 진짜 일상이 되려면 클라우드가 닿지 않는 자리에서도 돌아가야 하니까요. 공장 지하의 점검용 노트북, 외부망이 막힌 회의실, 비행기 안 좌석 테이블 같은 곳 말입니다. 그런 자리에서 돌아가는 에이전트 하나가 데이터센터의 거대한 데모보다 때로는 더 쓸모 있죠.

양자화를 나중에 때우는 것과 처음부터 깔아두는 것

양자화라는 말을 들으면 화질을 낮춰 용량을 줄이는 일부터 떠오르실 겁니다. 사진으로 치면 RAW를 JPEG로 바꾸는 일인데, 모델에서도 가중치 정밀도를 낮춰 메모리와 연산 부담을 줄이거든요. 그런데 언제 이걸 생각하느냐에 따라 결과가 꽤 달라집니다.

나중에 때우는 방식은 이미 지은 집에 단열재를 덧붙이는 일과 비슷합니다. 효과는 있지만 군데군데 손이 안 가는 구석이 남죠. 반면 처음부터 양자화를 염두에 둔 설계는 단열을 벽 속에 넣고 짓는 일에 가깝습니다. 어디를 얼마나 줄여도 견디는지 미리 가늠하면서 구조를 잡으니까요. 발표가 양자화 친화 설계를 내세우는 대목은 후자를 자처하는 것으로 읽힙니다.

이 차이는 생각보다 중요합니다. 정밀도를 낮췄을 때 무너지는 지점은 대체로 정해져 있거든요. 함수 호출 인자의 따옴표 하나, 코드 들여쓰기 하나가 어긋나면 에이전트는 바로 삐걱거립니다. 그래서 에이전트용 모델에게 양자화는 단순한 다이어트가 아니라 관절을 지키는 일입니다. 줄이면서도 도구 호출 규격과 코드 문법을 똑바로 지키게 만들어야 하니까요.

여기서 한 가지 덧붙이고 싶은 관찰이 있습니다. 양자화 친화라는 말 자체는 측정 결과를 대신해주지 않거든요. 어떤 비트 폭에서, 어떤 작업에서, 얼마나 손해가 나는지가 나와야 이야기가 완성되죠. 발표 요약만으로는 그 표가 다 안 보이는데, 이건 흠이라기보다 당연한 한계에 가깝습니다. 블로그 발표라는 형식 자체가 전체 성적표보다 방향 선언에 가깝기 때문입니다. 그렇다면 우리는 그 선언을 어떻게 검증해야 할까요. 다음 대목에서 배포 쪽으로 시선을 옮겨 보겠습니다.

오픈 웨이트가 배포 방식을 바꾸는 지점

오픈 웨이트라는 말은 코드를 받는 일과 비슷하면서도 다릅니다. 코드를 받으면 고칠 수 있고, 가중치를 받으면 옮기고 깎고 붙일 수 있습니다. 발표는 이 모델을 오픈 웨이트로 내놓고 인기 있는 로컬 추론 스택과 맞물리게 했다고 말합니다. 즉 가져다가 내 기계에 올리는 길을 열어 두었다는 뜻입니다.

이 선택이 바꾸는 건 생각보다 큽니다. 클라우드 API 뒤에 있는 모델은 쓰고 싶을 때 부르면 되지만, 내 마음대로 옮기거나 뜯어볼 수는 없거든요. 반면 오픈 웨이트 모델은 내 노트북, 내 서버, 내 엣지 박스 위에서 돌아갑니다. 버전을 고정할 수도 있고 사내 어댑터를 얹을 수도 있으며, 외부망을 끊고 돌릴 수도 있으니까요. 통제권이 넘어오는 셈이죠.

(참고로 로컬 스택 호환이라는 말은 한 번에 되는 마법이 아니라, 커뮤니티와 생태계가 함께 메워가는 과정에 가깝습니다. 런타임마다 MoE 지원 수준이 다르고 양자화 형식도 제각각이라서, 발표 시점의 호환 목록과 반년 뒤의 목록은 꽤 달라져 있곤 하죠.)

그렇다면 이 개방은 누구에게 가장 달콤할까요. 저는 데이터를 밖으로 못 내보내는 조직과, 호출 단가가 쌓여서 클라우드 요금이 무서운 팀을 먼저 떠올립니다. 병원 기록, 공장 도면, 법무 문서처럼 바깥으로 나가면 안 되는 자료를 다루는 곳 말입니다. 그런 곳에서 로컬 에이전트는 사치가 아니라 필요하죠. 다만 개방이 곧 공짜 사용을 뜻하지는 않습니다. 상업적 이용 조건과 라이선스 문구는 따로 확인해야 하며, 이 대목은 뒤쪽에서 다시 짚겠습니다.

더 크고 닫힌 모델들과 견준다는 말의 행간

발표는 에이전트와 코딩, 지시 따르기에서 더 크고 닫힌 모델들과 견줄 만하다고 말합니다. 문장만 보면 속이 시원하죠. 작은 활성 비용으로 큰 모델의 일을 해낸다는 이야기니까요. 그런데 저는 이 숫자를 그대로 믿기 전에 조건을 봅니다. 무엇을 재었는지, 누구와 견주었는지, 어떤 길이의 일을 시켰는지가 빠지면 순위는 표정이 되거든요.

에이전트 평가는 특히 까다롭습니다. 한 번의 정답 맞히기가 아니라 여러 번의 도구 호출과 실패, 복구가 얽혀 있습니다. 짧은 지시 따르기에서는 팽팽하던 모델이 열 번째 호출에서 인자를 흘리면서 무너지는 경우를 저는 여러 번 봤습니다. 그래서 평균 점수보다 분포가 궁금합니다. 어디까지는 잘하고 어디부터 흔들리는지 말입니다.

같은 예산을 어디에 쓸지 고르는 일로 보면 이 비교는 더 입체적입니다. 전체 24B의 기억 폭을 유지하면서 매번 2B만 쓰는 선택은, 매번 전체를 쓰는 큰 모델과 비용 구조가 다르거든요. 같은 FLOPs를 맞췄다고 같은 전기료와 같은 대기 시간이 되는 게 아닙니다. 메모리 대역폭, 배치 처리, 동시 접속자 수에 따라 그림이 달라지죠. 그래서 공정한 비교라면 무엇을 맞췄는지가 함께 적혀 있어야 합니다. 연산량인지, 대기 시간인지, 메모리 점유인지에 따라 승자가 바뀌니까요.

그럼에도 이 행간에서 읽히는 태도는 분명합니다. 정면 승부보다 체급 깨기입니다. 무거운 체급의 일을 가벼운 발로 해내겠다는 뜻이니까요. 저는 그 태도 자체는 반갑게 봅니다. 다만 박수보다 먼저 묻고 싶습니다. 몇 라운드짜리 싸움이었나요. 에이전트의 진짜 시험은 장거리전이기 때문입니다.

기업이 로컬을 찾는 이유는 속도가 다가 아니다

로컬 실행 이야기를 하면 속도부터 떠올리기 쉽죠. 당연히 중요합니다. 매 호출마다 왕복이 줄면 에이전트의 반복이 훨씬 가벼워지니까요. 그런데 기업이 로컬을 찾는 이유를 속도로만 설명하면 반쪽입니다. 비용과 오프라인, 데이터 주권이 함께 걸려 있거든요.

비용부터 보면 그림이 단순합니다. 에이전트는 호출을 아껴 쓰지 않거든요. 검색하고 읽고 실행하고 다시 묻죠. 클라우드 과금이 호출마다 붙으면 잘 쓰는 팀일수록 요금이 먼저 늘어납니다. 로컬 실행은 이 구조를 고정비로 바꿔줍니다. 기계를 사두면 많이 쓸수록 한 번당 단가가 내려가니까요. 많이 쓰는 팀에게는 이게 큽니다.

오프라인은 또 다른 축입니다. 외부망이 막힌 현장, 보안 구역 안의 회의실, 이동 중인 차량 안에서는 클라우드 호출 자체가 성립하지 않거든요. 그 자리에서 돌아가는 작은 에이전트 하나가 일의 맥을 이어주죠. 아침에 공장이 멈췄는데 네트워크 점검부터 해야 한다면, 그 에이전트는 그냥 장식이니까요.

데이터 주권은 말할 것도 없죠. 바깥으로 나가면 안 되는 문서를 다루는 조직에게 로컬은 선택이 아니라 전제이거든요. 병원과 은행, 연구소와 공공기관이 대표적입니다. 발표가 사적인 실행을 앞세우는 이유도 여기 있다고 봅니다. 빠르다는 말보다, 내 울타리 안에서 돈다는 말이 더 크게 들리는 사람들이 분명 있기 때문입니다.

그렇다면 로컬이 만능일까요. 그렇지 않습니다. 기계값과 관리 부담이 앞으로 나오고, 모델 업데이트와 모니터링도 직접 챙겨야 하거든요. 클라우드가 대신해주던 일을 떠안는 셈이죠. 그래서 저는 로컬과 클라우드를 둘 중 하나로 보지 않습니다. 민감하고 반복적인 일은 안에서, 폭발적으로 크고 가끔 있는 일은 밖에서. 이런 나눔이 현실적이라고 보기 때문입니다.

그래서 다음에 확인할 것은 무엇일까

앞에서 미뤄둔 질문으로 돌아올 차례입니다. 이 발표를 보고 나서 우리는 무엇을 더 확인해야 할까요. 발표 요약만으로는 답이 안 나오는 대목이 세 가지쯤 남거든요. 긴 호흡의 안정성과 실행 환경의 실제 궁합, 그리고 상업적 이용 조건이죠.

먼저 긴 호흡입니다. 에이전트의 평가는 단거리 기록이 아니라 완주율로 정해지니까요. 열 번, 스무 번 호출이 이어질 때 함수 인자가 흐트러지지 않는지, 중간 실패를 스스로 복구하는지, 컨텍스트가 길어져도 지시를 놓지 않는지가 봐야 할 것들이죠. 발표가 내세우는 도구 사용과 다단계 추론은 바로 이 시험을 위한 근육인데, 근육 자랑과 완주 기록은 다른 이야기입니다. 저는 앞으로 이 모델의 긴 작업 궤적을 보고 싶습니다. 어디에서 흔들리고 어디에서 버티는지 말입니다.

다음은 MoE 실행 지원의 현실입니다. 라우팅과 전문가 배치는 종이 위에서는 말끔한데, 실제 런타임 위에서는 이야기가 달라질 때가 많거든요. 어떤 추론 스택에서, 어떤 정밀도와 배치 크기로, 어느 정도 처리량이 나오는지가 나와야 배포 그림이 그려지죠. 소비자 GPU라는 말도 마찬가지입니다. 어느 급의 메모리에서 전체 가중치를 어떻게 얹고, 부족하면 어떻게 나눠 올리는지가 구체화되어야 하니까요. 이건 발표의 흠이 아니라, 발표 이후 커뮤니티가 함께 채울 빈칸에 가깝습니다.

마지막은 라이선스입니다. 오픈 웨이트라는 말이 반갑다고 바로 제품에 얹을 수는 없거든요. 상업적 이용 범위와 재배포 조건, 개작물 정책을 문서에서 직접 확인해야 합니다. 기업 입장에서는 성능표보다 이 한 줄이 먼저일 때가 많습니다. 법무 검토를 통과하지 못하면 아무리 빨라도 못 쓰니까요.

제가 앞으로 보고 싶은 것은 그래서 성적표보다 궤적입니다. 로컬 스택 위에서 쌓이는 실행 기록, 긴 에이전트 작업에서의 실패와 복구 패턴, 양자화 폭을 바꿔가며 찍은 손익표 같은 것들이거든요. 그런 기록이 쌓이면 이 발표는 선언에서 표준으로 넘어갈 수 있습니다. 그전까지는 반가운 초대장으로 읽는 게 맞다고 봅니다. 문은 열려 있고, 안으로 들어가는 길은 우리가 함께 닦아야 하니까요.

돌아보면 이 발표가 던진 질문은 단순합니다. 에이전트가 꼭 클라우드 안에 있어야 할까요. Liquid AI의 답은 아니오 쪽에 가깝습니다. 24B의 폭을 유지한 채 매번 2B만 깨워서 일상적인 기계 위에서 손발이 되는 에이전트를 돌리겠다는 뜻이니까요. 저는 그 답이 맞는지보다, 그 질문을 실행 가능한 형태로 바꿨다는 점을 높이 삽니다. 확인할 숙제는 남았지만 방향은 분명하거든요. 다음에 또 이런 발표가 나오면 저는 같은 질문을 던질 것 같습니다. 그래서, 내 자리에서 돌릴 수 있나요.