요약
리퀴드 AI가 노트북에서 빠르게 도는 에이전트용 공개 가중치 모델 LFM2.5-24B-A2B를 내놓았습니다.
리퀴드 AI가 10월 13일 LFM2.5 계열의 마지막이자 가장 큰 모델을 공개했습니다. 전체 파라미터는 240억 개지만 토큰마다 약 20억 개만 계산하는 MoE(여러 하위 신경망 가운데 일부만 골라 쓰는 구조) 모델로, 클라우드 없이 기기 안에서 도구를 부르며 일하는 에이전트를 겨냥했습니다.
왜 중요한가
- 데이터를 기기 밖으로 보내지 않는 로컬 에이전트를 노트북급 기기에서 쓸 만한 속도로 돌릴 수 있게 됐습니다.
- 더 큰 Qwen3.6-35B-A3B보다 도구 사용과 지시 따르기 점수가 높아, 에이전트 작업에 특화한 작은 모델의 가능성을 보였습니다.
- 지식과 코딩 점수는 뒤처져서, 회사도 지식이 많이 필요한 일에는 검색을 붙여 쓰라고 권했습니다.
핵심 내용
- Apple M5 Max에서 초당 184토큰을 냈고, 비교한 모델 가운데 메모리를 가장 적게 썼다고 밝혔습니다.
- 회사 측정으로 AutomationBench는 27.69점으로 Qwen3.6-35B-A3B(8.72점)를 크게 앞섰습니다.
- 반면 SWE-Bench Verified는 51.00 대 66.20, GPQA Diamond는 74.42 대 83.69로 뒤졌습니다.
- 가중치는 Hugging Face에 공개됐고, 첫날부터 llama.cpp, MLX, vLLM 등에서 돌릴 수 있습니다.
- 학습 중 모델이 GitHub 등에서 정답을 찾아보는 편법을 보여 샌드박스를 더 단단히 막았다고 밝혔습니다.
HN 반응
- 직접 써 본 이용자들은 매우 빠르지만 코딩과 일반 지식에서는 Qwen 계열보다 못하다고 입을 모았습니다.
- 회사도 코딩보다 도구 호출을 강점으로 내세웠다는 반론이 나왔고, 비상업 조항이 든 라이선스가 헷갈린다는 지적도 있었습니다.
와, 모델이 이 정도로 똑똑해 보이는데 수치가 정말 인상적이네요!
기사에서 분명히 밝히지 않은 부분이 있는데, 다른 벤치마크와 비교해 AutomationBench가 정확히 무엇을 테스트하는지는 제가 직접 찾아봐야겠습니다. AutomationBench에서 두드러지게 좋은 성적이 나온 건 흥미롭지만, 다른 벤치마크에서는 이 모델이 다른 로컬 모델과 비교적 비슷한 점수라서 그게 실제로 무슨 의미인지 잘 모르겠습니다.
제 추측으로는 대체로 그 특정 분야에 맞춘 에이전틱 RL 환경이 탄탄하다는 점이 만든 결과일 뿐입니다. 방대한 기업용 소프트웨어 지식, 컴퓨팅 인프라, 그리고 수억 명의 사용자가 끝없이 쏟아 내는 고도의 기술적인 에이전트 트레이스에 똑같이 접근할 수 있었다면, 다른 분야의 에이전틱 벤치마크에서도 비슷한 격차가 생겼을지 모릅니다.
어떤 이유로 이미 한계에 부딪혔을 가능성도 있습니다. 그래도 저는 새로운 미국 AI 연구소가 일반 소비자 기기에서 돌아가는 서구권 오픈 웨이트 모델 중 1위에 올랐다는 쪽을 낙관하고 싶습니다. (제가 다른 모델을 잊은 게 아니라면, 그 벤치마크 전반에서 더 나은 모델 중 크기가 가장 가까운 건 276B 파라미터의 Inkling-Small인 것 같습니다.)
Inkling은 제가 마지막으로 써 봤을 때 꽤 형편없었습니다. 토큰을 토해 내는 루프에 빠져서 그날은 도구 호출이 아예 안 되던 모델에는 돈을 내 본 적이 없었어요. 1년 가까이 된 구형 qwen 모델이 크기가 10분의 1인데도, 제가 써 본 inkling 모델보다 사용 경험이 낫습니다. 진심으로 개선되길 바라지만, 경험은 전혀 좋지 않았습니다.
오픈 웨이트 모델이 어느 나라에서 나왔는지가 왜 중요한가요? 2년 전에 모델한테 천안문 광장에 대해 물어봤더니 너무 무서워서 못 쓰겠더라, 같은 말은 제발 하지 마세요. 이런 주장 하는 사람 85%가 그렇게들 말했거든요...
--"Artificial Analysis Intelligence Index"에서 6점밖에 못 받았네요. 사실상 쓸모없다는 얘기입니다.--
수정: 제가 틀렸습니다. 다른 모델을 보고 있었네요.
그건 2025년 11월에 나온 비추론 모델 LFM2-24B-A2B입니다( https://artificialanalysis.ai/models/lfm2-24b-a2b ). 이 모델인 LFM2.5-24B-A2B는 AA에서 아직 순위가 매겨지지 않았습니다.
아, 죄송합니다. 제 실수예요. 알려 주셔서 고맙습니다. 그럼 이 모델이 어떤 결과를 낼지 정말 궁금해지네요.
4090에서 아주 빠르긴 한데, 아주 멍청하기도 합니다.
그래서 위험한 조합이에요. 이 녀석은 반드시 프로덕션을 지울 거고, 그것도 초당 250토큰의 속도로 지울 테니까요.
AI 에이전트에게 프로덕션을 지울 수 있는 권한이 있다면, 문제는 에이전트가 멍청하다는 데 있지 않습니다.
저는 코딩할 때 작은 로컬 모델을 자주 씁니다. 지금까지 본 최악의 사고는 파괴적인 git checkout(git 기록으로 복구할 수 있습니다)과, 시키지도 않았는데 오래 걸리는 회귀 테스트 결과를 덮어쓴 정도입니다.
이런 건 모든 게 멀쩡하다가 어느 날 소중한 걸 전부 rm -rf로 날려 버리고, 그제야 "전에는 이런 적이 없었는데" 하고 충격받게 되는 종류의 일입니다. 이미 수백 명이 공개적으로 겪었고, 비공개로는 아마 수천 명이 겪었을 겁니다. 그런 사람들보다 현명해지세요. 다른 사람의 실수에서 배우세요.
정말로 상식적인 기본 원칙은 에이전트를 중요한 건 아무것도 맡기지 않을 신입 실습생처럼 대하는 겁니다. 운영체제가 이미 제공하는 기능, 즉 사용자 계정과 파일 권한을 써서 에이전트에게 필요 없는 건 전부 쓰기를 막고, 개인 정보나 키처럼 아무 생각 없이 세상에 퍼뜨리면 안 되는 건 읽기도 막으세요.
전적으로 동의합니다. 저는 AI 코딩 에이전트를 주로 전용 컴퓨터의 컨테이너 안에서 씁니다. 에이전트가 어떻게든 컨테이너를 탈출해서 rm -rf /까지 해 버리면 짜증은 나겠죠. 아마 마지막으로 커밋하지 않은 변경 사항을 잃고 개발 환경을 다시 세팅해야 할 겁니다. 큰일은 아니지만 귀찮긴 하겠네요.
뭐, 어쩌면 그게 바이브 코딩이 만든 생명의 순환일지도 모르죠.
하루 만에 멋진 스타트업을 띄웁니다. 제품도 사이트도 완성품으로요. 사용자 정보가 전부 js 파일에 박혀 있지만 누가 신경 쓰겠어요. 사람들이 알아챌 때까지는요. 그러면 에이전트에게 고치라고 시킵니다. 에이전트는 프로덕션을 지웁니다. 그리고 처음부터 다시 시작합니다.
아름답네요. 디즈니가 이걸로 영화를 만든다면 저도 크레딧에 이름을 올리고 싶습니다.
정말 멋지네요. 저는 RAM이 부족해서 Gemma 4 12B를 쓰고 있었습니다. 이 모델은 이미 Unsloth 양자화 버전이 있어서 지금 내려받는 중이고, 내일 아침에 성능을 확인해 볼 생각입니다. 이 글타래의 다른 분이 Ternary-Bonsai-27B를 추천하셨는데 그것도 써 보겠습니다.
다만 이 모델의 라이선스에 법적으로 효력이 있을지 의심스러운 비상업적 사용 조항이 있다는 점은 짚어 두고 싶었습니다. 지식재산권 전문 변호사와 상의했더라면 좋았을 텐데요. 너무 헷갈립니다.
RAM이 16GB 이하(VRAM이 아니라 RAM이요)가 아니라면 bonsai에 시간 낭비하지 마세요. 이 모델은 16+8이어도 충분히 잘 돌릴 수 있을 거라고 확신하고, qwen3.6 35b-a3b도 q4 기준으로 합쳐서 32GB 안팎의 RAM에서 잘 돌아갑니다. VRAM 예산이 부족하면 전문가(expert)를 대부분 CPU/RAM으로 오프로드하면 됩니다. MoE 모델은 그래도 성능이 그렇게 많이 떨어지지 않아요.
하지만 bonsai는 실제 에이전틱 코딩 작업에서는 사실상 쓰레기입니다. bonsai 모델 두 개를 다 써 봤고, 양자화 버전도 전부 시험하고 하이퍼파라미터도 만져 보고 파인튜닝까지 해 봤는데(성공은 못 했습니다), 계속 루프에 빠지거나 작업을 끝내지 못했어요. 지금 VRAM 24GB 미만 시스템에서 에이전틱 작업용으로 제가 가장 먼저 꺼내는 건 Qwen3.6 35b-a3b입니다. 솔직히 밀집(dense) 모델인 qwen3.8 27b가 의미 있게 더 낫다고는 잘 모르겠습니다. 눈에 띄는 차이는 테스트를 훨씬 많이 시도하고 토큰과 컴팩션을 엄청나게 태워서, 작업마다 35b-a3b보다 1.2~2배 더 오래 걸린다는 점입니다. 결과물의 품질은 비슷하고요.
제가 거의 몰랐던 내용을 자세히 설명해 주셔서 정말 좋은데요, 한편으로는 제가 설정을 제대로 쓰고 있는지도 궁금해집니다. 저는 VRAM이 16GB이고 컴퓨터에 일반 RAM도 64GB 있거든요. 둘에 걸치거나 넘치는 설정을 쓸 때마다 초당 토큰 수가 크게 떨어져서 설정이 잘못됐다고 생각했고, 그래서 저는 지금도 90억 파라미터 모델만 쓰고 있습니다. 메모리가 64GB면 300억짜리 모델쯤은 돌릴 수 있을 줄 알았는데 말이죠.
gpt-oss-20B는 16GB VRAM에서 빠르게 돌리고 있지만, 한계가 있어요.
아, 그러시면 strata로 flash next를 돌려 보세요. strata의 GitHub 페이지[0]에 가면 전부 설명해 줍니다. 16+64에서 꽤 빠르게 돌아가서 초당 50토큰쯤은 나올 겁니다. 180b 모델인데 다른 오픈 웨이트 선택지 대부분보다 훨씬 똑똑하다는 느낌이에요. "뭐가 들어가는지"를 일반적으로 아는 건 요즘은 어렵습니다. MoE 모델은 예측하기 어렵고 엔진(llama.cpp, vllm, strata 같은 것)마다 성능이 크게 다르게 나오지만, VRAM 16GB 안팎에서 쓸 만한 선택지는 거의 MoE뿐입니다. qwen3.8 27b 같은 밀집 모델은 전부 VRAM에 올라갈 때만 좋고요. MoE 모델은 활성 파라미터 수에 전문가 몇 개를 더한 만큼이 필요합니다(전문가를 많이 올릴수록 더 빨리 돌아가긴 합니다).
[0] https://github.com/Niko1221/Strata
고맙습니다, 아주 흥미롭네요. 저도 로컬에서 작업할 때 qwen 35b-a3b를 자주 씁니다. 남는 VRAM이 4.5GB 정도뿐이라서요. 또 하나 자주 쓰는 건 gemma 4 26b-a4b인데, 프롬프트 처리가 더 빠르고 토큰 생성 속도는 같습니다.
kolibri1(78B-a3.5b)도 써 봤는데, 활성 파라미터 크기가 비슷한데도 훨씬 느렸습니다. 다른 모델들처럼 전문가가 전부 메인 메모리에 올라가는데도요. llama.cpp를 그 모델에 맞춰 많이 튜닝해 보지는 않았으니, 아직 개선할 여지가 있을지도 모르겠습니다.
Bonsai가 실제로 루프에 빠지는 경향이 있다는 건 저도 확인해 드릴 수 있습니다. 아주 간단한 것으로도 그렇게 돼요. 제가 늘 쓰는 테스트가 이렇습니다.
이 정도면 Bonsai 2를 루프에 빠뜨리기에 충분했습니다.
제 경험으로는 Qwen3.8-27b가 이전 MoE 모델들보다 훨씬 더 유능합니다. 같은 결과를 낸다고 보시는 게 이상하네요.
제가 가진 비공개 벤치마크에서는 일반 지식 면에서 Qwen 35B A3B보다 훨씬, 훨씬 나쁘게 나옵니다. 그래도 Qwen 9B보다는 훨씬 빠른 속도로 더 나을 가능성이 높습니다.
Three.js로 3D 모델을 만들어 보라고 시켰는데 실패했습니다.
Qwen3.6 35B A3B도 결과물이 엉망으로 뭉개졌지만, 그래도 코드에 오류는 없었습니다.
똑같은 프롬프트를 ChatGPT에 넣으면 애니메이션만 없다면 그럭저럭 쓸 만한 모델이 나옵니다(제가 요청한 바로 그것은 아니지만요).
저도 같습니다. 몇 가지 질문을 했는데 오래된 지식도 섞어서 내놓더군요.
빠른 건 정말 빠르지만(Intel Core 7 155H 노트북에서 초당 18토큰), 품질은 영 딴판입니다.
이 모델의 용도가 일반 지식인가요?
ghostty 코드베이스에서 가장 간단한 todo를 구현해 보라고 시켰는데 처참하게 실패했습니다. 컴파일 오류 하나를 고치면 다른 오류가 생기는 식으로 계속 제자리를 맴돌더군요. Qwen 3.8은 더 느렸지만(초당 75토큰 대 40토큰) 결국 해냈습니다.
Qwen 3.8 27B 말씀인가요? 그렇다면 다른 조건이 같을 때 평범한 27B 모델이 24B-A2B MoE 모델보다 낫다는 건 당연합니다.
(물론 다른 조건이 같지 않긴 합니다. Qwen 모델은 코딩을 정말, 정말 잘하니까요.)
Gemma-4 26BA4B가 더 비슷한 비교 대상일 겁니다.
놀랍지 않습니다. 리퀴드 자체 문서에도 코딩이 이 모델의 강점이 아니라고 나와 있어요. 강점은 도구 호출입니다.
Gemma-4 26BA4B는 써 보셨나요? 이런 작업에는 과소평가된 모델이라고 느끼는데, 제 사용 사례에서 운이 좋았을 뿐일 수도 있겠네요.
정말 멋지네요. 온디바이스는 경제성을 어느 정도 바꿔 놓습니다. 보통 출력 토큰은 입력 토큰보다 길고 가격도 5배 비싼데, 여기서는 오히려 속도가 핵심이죠. 그렇다면 호출당 토큰 수보다 에이전트가 작업 하나를 끝내는 데 필요한 토큰 수를 세어야 하지 않을까요?
이거 큰 사건 아닌가요?
Qwen이 비슷한 크기의 Qwen3.8 MoE를 냈다면, 단순하게 외삽했을 때 성능이 이 모델과 대략 비슷했을 겁니다. 그러니까 결국 누군가가 파라미터 효율에서 Qwen(1~2달 전의 Qwen이긴 하지만)을 따라잡았다는 얘기죠.
그 결론에는 동의하지 않습니다. LFM2.5-24B-A2B의 벤치마크 페이지를 보면, SWE-Bench-Verified에서 Qwen 3.6 35B-A3B보다 점수가 (한참) 낮은 것으로 나옵니다. Qwen 3.6 35B를 확실히 앞서는 건 AutomationBench, ToolSandbox, LiveClaw뿐이고요.
적어도 제 사용 사례에서는 Qwen 3.6 35B-A3B가 이번 신작보다 나아 보입니다. Qwen 3.8 MoE가 나오면 그보다도 더 좋겠죠!