무슨 일이 있었나요?
Liquid AI가 새 모델 LFM2.5-24B-A2B를 공개했어요. 이름만 보면 암호 같은데, 하나씩 풀면 어렵지 않아요. 24B는 모델이 가진 파라미터(학습으로 정해진 숫자들)가 전부 합쳐 약 240억 개라는 뜻이에요. A2B는 ‘Active 2B’의 줄임말이고요. 글자(토큰) 하나를 만들 때 실제로 계산에 쓰이는 파라미터는 그중 약 20억 개뿐이라는 뜻이에요. 목표도 분명해요. 클라우드 서버가 아니라 노트북이나 휴대폰 같은 기기 안에서 빠르게 돌아가는 에이전트를 만드는 거예요.
왜 지금 이게 중요하냐면, AI를 쓰는 방식이 바뀌고 있어서예요. 예전에는 ‘물어보면 답해주는 챗봇’이 중심이었는데, 요즘은 도구를 호출하고 여러 단계를 스스로 처리하는 ‘에이전트’로 넘어가고 있거든요. 에이전트는 일 하나를 맡기면 모델을 수십 번씩 불러요. 그때마다 클라우드 API를 쓰면 비용이 쌓이고, 기다리는 시간도 쌓이고, 회사 내부 데이터가 밖으로 나가는 문제도 생겨요. 그래서 ‘내 기기에서 돌릴 만큼 작고 빠르면서도 똑똑한 모델’을 찾는 사람이 점점 늘고 있어요.
핵심 1: MoE, 전문가 여러 명 중 몇 명만 부르는 구조
이 모델의 뼈대는 MoE(Mixture of Experts, 전문가 혼합) 구조예요. 큰 병원을 떠올려 보면 쉬워요. 병원에는 전문의가 수십 명 있지만, 환자가 오면 접수처가 증상을 보고 그중 두세 명에게만 보내잖아요. 모든 의사가 모든 환자를 보지는 않죠.
MoE 모델도 똑같이 움직여요. 안에 ‘전문가’라고 부르는 작은 신경망 블록이 여러 개 있고, 라우터(접수처 역할)가 토큰마다 일부 전문가만 골라서 계산을 맡겨요. 그래서 아는 것의 총량은 24B급인데, 계산 비용은 2B급에 가까워져요.
여기서 흔히 오해하는 부분이 하나 있어요. 계산은 2B만 하지만 메모리에는 24B 전부를 올려둬야 해요. 어떤 전문가가 불릴지 미리 알 수 없으니까요. 필요한 메모리를 대략 계산해 보면 이래요.
- 16비트(BF16): 약 48GB
- 8비트 양자화: 약 24GB
- 4비트 양자화: 약 12~14GB
- Qwen3-30B-A3B: 전체 30B, 계산 3B. 로컬 LLM을 쓰는 사람들 사이에서 ‘가성비 MoE’의 기준처럼 쓰이는 모델이에요.
- gpt-oss-20b: OpenAI가 가중치를 공개한 모델로, 전체 약 21B에 계산 약 3.6B예요. 이 모델도 메모리 16GB 정도를 목표로 만들어졌어요.
- IBM Granite 4.0: Mamba 계열과 트랜스포머를 섞은 하이브리드 구조로, 메모리를 적게 쓰는 걸 강점으로 내세워요.
- Gemma 3n: 처음부터 모바일 기기를 목표로 만든 구글의 경량 모델이에요.
양자화는 숫자를 더 적은 비트로 저장해서 모델 크기를 줄이는 기법이에요. 4비트까지 줄이면 RAM 32GB 노트북에서는 여유 있게, 16GB에서도 빠듯하게나마 올릴 수 있어요. CPU와 GPU가 메모리를 함께 쓰는 Apple Silicon 맥이 이런 모델과 특히 잘 맞고요. 일단 메모리에 올라가면 글자를 만드는 속도는 2B 모델에 가까울 거라고 기대할 수 있어요. 로컬에서 LLM 속도를 가장 크게 좌우하는 건 ‘토큰 하나를 만들 때 메모리에서 읽어야 하는 가중치의 양’인데, 계산에 쓰이는 파라미터가 적으면 이 양이 크게 줄거든요.
핵심 2: 트랜스포머만 쓰지 않는 하이브리드 구조
Liquid AI가 다른 회사와 가장 다른 점은 모델 구조예요. 이전 LFM2 시리즈부터 이 회사는 순수 트랜스포머 대신, 가까운 범위만 보는 합성곱(convolution) 블록과 어텐션 블록을 섞은 하이브리드 구조를 써왔어요.
쉽게 풀어볼게요. 어텐션은 문장 속 모든 단어가 서로를 하나하나 확인하는 방식이에요. 성능은 좋지만, 글이 길어질수록 계산량과 메모리(KV 캐시)가 크게 늘어요. 반면 짧은 합성곱은 바로 옆 단어 몇 개만 보는 가벼운 연산이에요. 대부분의 층은 가벼운 합성곱으로 처리하고, 멀리 떨어진 정보를 이어야 하는 곳에만 어텐션을 조금 넣으면 어떨까요? 성능은 지키면서 CPU나 모바일 칩에서 훨씬 빠르게 돌릴 수 있다는 게 이 회사의 설계 철학이에요. 이름이 LFM2.5인 걸 보면, 이번 모델도 이 구조를 이어받아 규모를 키우고 MoE를 합친 것으로 보여요.
업계 맥락: ‘덩치는 크게, 계산은 작게’ 경쟁
사실 이 방향은 Liquid만 가는 길이 아니에요. 비슷한 모델들과 비교해 보면 흐름이 잘 보여요.
한국 개발자에게 주는 시사점
첫째, 보안 때문에 외부 API를 쓸 수 없는 환경이라면 눈여겨볼 만해요. 금융, 공공, 의료처럼 데이터를 밖으로 내보내기 어려운 곳에서도 문서 분류, 사내 도구 호출, 코드 보조 같은 일을 로컬 에이전트로 시도해 볼 수 있거든요.
둘째, 에이전트 비용 구조를 다시 생각해 볼 기회예요. 모든 단계를 비싼 대형 모델에 맡길 필요는 없어요. 단순한 분기 처리나 도구 호출은 로컬 소형 모델에 맡기고, 어려운 추론만 클라우드 모델에 넘기는 계층형 설계가 점점 현실적인 선택지가 되고 있어요.
셋째, 실무에서 챙길 것도 있어요. 한국어 성능은 영어 벤치마크로는 알기 어려우니 꼭 직접 테스트해 보세요. 라이선스도 확인하세요. 이전 LFM2 시리즈는 회사 매출이 일정 규모 이하일 때만 상업적 사용을 무료로 허용하는 자체 라이선스였거든요. 그리고 하이브리드 구조는 llama.cpp, MLX, vLLM 같은 추론 엔진마다 지원 여부가 다를 수 있어요. 지금 쓰는 환경에서 돌아가는지 먼저 확인하는 게 좋아요.
마무리
한 줄 정리: 24B 모델의 지식을 2B 모델의 비용으로 쓰면서, 에이전트를 내 기기 안으로 가져오려는 시도예요.
여러분이 에이전트를 만든다면 어디까지 로컬 모델에 맡길 수 있을 것 같으세요? 도구 호출이나 간단한 판단은 로컬 모델로 충분하다고 보시나요, 아니면 아직은 클라우드 대형 모델 없이는 불안하신가요? 로컬에서 MoE 모델을 직접 써보신 분이 있다면 경험도 나눠주세요!
🔗 출처: Hacker News