온디바이스에서 동급 MoE보다 최대 1.7배 빠르고, Apple M5 Max에서 초당 184토큰, NVIDIA B300 한 장에서 최대 초당 2만 1천 출력 토큰이라니, 이 모델의 지능 수준을 고려하면 대단한 수치임.
다만 AutomationBench가 무엇을 평가하는지는 기사에서 명확하지 않음. 다른 벤치마크에서는 로컬 모델들과 점수가 비슷한데 여기서만 두드러져서, 실제로 어떤 의미인지 더 알아봐야겠음.
해당 분야에 특화된 에이전트 강화학습 환경이 강력해서 생긴 차이라고 추측함. 다른 분야에서도 방대한 조직 내 소프트웨어 지식, 연산 인프라, 수억 명의 사용자가 제공하는 고도로 기술적인 에이전트 실행 기록에 접근할 수 있었다면 비슷한 격차가 났을 수 있음.
어떤 이유로 전반적인 성능이 한계에 도달했을 가능성도 있지만, 새 미국 AI 연구소가 일반 소비자 기기에서 실행 가능한 서구권 공개 가중치 모델 중 선두에 오른 것을 긍정적으로 보고 싶음. 내가 빠뜨린 모델이 없다면, 이 벤치마크 전반에서 더 나으면서 크기가 가장 가까운 모델은 매개변수 276B의 Inkling-Small인 듯함.
이런 모델을 출시하는 데 드는 실제 하드웨어·전력 비용의 규모를 아는 분이 있을까요? 기존 모델에서 출발해 학습을 시작한 시점부터 이번 출시까지 추가로 들어간 비용이 궁금함.
전력에만 수백만 달러를 쓰고 초기 데이터센터 투자비는 여러 학습에 걸쳐 상각하는지, 전용 장비 없이 클라우드 비용만 내는지도 궁금함. Liquid나 이 모델에 한정하기보다, 이런 소형·고속 온디바이스 모델의 학습 비용이 대략 어느 정도인지 알고 싶음.
최종 학습 한 번의 비용만 묻는 것은 근시안적일 수도 있음. 여러 변형을 시험한 결과라면 최종 출시로 이어진 연구개발용 학습 비용도 모두 포함해야 할 듯함.
이 정도 중형 모델의 학습에는 대략 50만~500만 달러가 들 수 있음. Liquid가 지출하는 것은 GPU 사용 시간에 대한 비용이며, 이를 전력 비용이라고 부를지는 모르겠음. 상각은 재무 상황을 모르면 답하기 어려움.
라이선스는 잘 이해되지 않음. 이미 매출 1천만 달러를 올리는 기업이라면 더 우수하고 용도에 맞는 자체 모델을 학습하거나, 적어도 그 자금을 조달할 수 있을 것 같음.
꽤 큰 성과 아닌가요? Qwen이 비슷한 크기의 Qwen3.8 MoE를 출시했다고 단순 추정하면 성능이 이 모델과 비슷할 듯함. 사실상 누군가 매개변수 효율에서 Qwen을 따라잡은 셈임. 다만 1~2개월 전 Qwen 기준임.
그 결론에는 동의하기 어려움. LFM2.5-24B-A2B의 벤치마크 페이지를 보면 SWE-Bench-Verified에서 Qwen 3.6 35B-A3B보다 훨씬 낮은 점수를 기록함. 확실히 앞서는 것은 AutomationBench, ToolSandbox, LiveClaw뿐임.
적어도 내 용도에는 Qwen 3.6 35B-A3B가 이번 모델보다 나아 보이며, Qwen 3.8의 MoE라면 그보다 더 좋을 것임.
RAM이 부족해 Gemma 4 12B를 사용 중인데, 벌써 이 모델의 Unsloth 양자화 버전이 나와 내려받고 있음. 아침에 성능을 확인하고, 이 스레드에서 추천한 Ternary-Bonsai-27B도 써볼 예정임.
다만 라이선스에 법적 집행 가능성이 의문스러운 비상업적 이용 조항이 있음. 지식재산권 전문 변호사에게 자문을 구했으면 좋았을 텐데, 매우 혼란스러움.
RAM이 16GB 이하인 경우가 아니라면 Bonsai에 시간을 쓰지 않는 편을 권함. VRAM이 아니라 시스템 RAM 기준임. RAM 16GB와 VRAM 8GB로도 이번 모델은 잘 돌 것 같고, Qwen3.6 35B-A3B는 Q4에서 합산 메모리 약 32GB면 잘 실행됨. VRAM이 부족하면 전문가 대부분을 CPU/RAM으로 넘기면 되며, MoE는 그렇게 해도 성능 손실이 크지 않음.
실제 에이전트 코딩에서 Bonsai는 형편없었음. 두 모델과 모든 양자화 버전을 써보고 하이퍼파라미터 조정과 미세조정까지 시도했지만, 미세조정은 성공하지 못했고 모델은 계속 반복에 빠지거나 작업을 끝내지 못함.
VRAM 24GB 미만 시스템에서 에이전트 작업에는 Qwen3.6 35B-A3B를 주로 사용함. 밀집 모델인 Qwen3.8 27B가 유의미하게 더 나은지도 모르겠음. 테스트 시도와 토큰 소비, 문맥 압축이 훨씬 많아 작업 시간이 1.2~2배 걸리지만 결과 품질은 비슷함.
Ryzen 7 8745HS, Radeon 780M, RAM 27GB 환경에서 Ollama의 Vulkan 백엔드로 실행 중임. 생성은 초당 약 45토큰, 프롬프트 처리는 초당 약 680토큰이 나옴.
문제는 프롬프트를 캐시하지 않고 forcing full prompt re-processing due to lack of cache data가 뜬다는 것임. 매번 프롬프트 전체를 다시 처리하므로 현재 상태로는 에이전트 반복 실행에 쓸 수 없음.
ghostty 코드베이스에서 가장 간단한 TODO를 구현해 달라고 했는데, 컴파일 오류 하나를 고치면서 다른 오류를 만드는 일을 반복하며 완전히 실패함. Qwen 3.8은 초당 40토큰으로 더 느렸지만 작업을 완료했으며, 이 모델은 초당 75토큰이었음.
Qwen 3.8 27B를 말하는 건가요? 다른 조건이 같다면 일반적인 27B 모델이 24B-A2B MoE보다 잘하는 것은 예상할 만함. 물론 Qwen은 코딩을 매우 잘하므로 실제 조건이 같지는 않음. Gemma-4 26BA4B가 더 비슷한 비교 대상일 것임.
놀랍지 않음. Liquid 자체 문서에서도 코딩은 이 모델의 강점이 아니라고 명시함. 강점은 도구 호출에 있음.
Gemma-4 26BA4B는 써봤나요? 이런 작업에서 과소평가되는 것 같지만, 내 용도에서만 운이 좋았을 수도 있음.
내 경험으로는 순수 코딩이나 소프트웨어 엔지니어링보다 bash 호출 연결, 백그라운드 작업 감시 같은 터미널 활용에 더 강함. 소프트웨어 수정보다는 웹 검색과 파일 검색에 능숙함.
자체 비공개 벤치마크에서는 일반 지식 성능이 Qwen 35B A3B보다 훨씬 낮음. 그래도 Qwen 9B보다는 성능이 좋으면서 속도도 훨씬 빠를 듯함.
일반 지식이 이 모델의 목적일까요?
몇 가지 질문을 해보니 오래된 지식도 내놓았음. Intel Core 7 155H 노트북에서 초당 18토큰으로 빠르기는 하지만, 품질은 별개임.
웹 검색, 도구 호출, RAG를 함께 쓰게 하면 나아지나요?
5070 Ti에서 초당 200~320토큰이 나옴. llama.cpp에서 문맥 길이를 131k로 설정했고 별도 조정은 하지 않았음.
지능 수준은 아직 평가하기 어렵지만 속도는 만족스러움. 이런 소형 에이전트 특화 모델은 직접 다뤄보면 꽤 재미있음.
매출 1천만 달러 초과 기업에 적용되는 모델 라이선스 비용이 대략 어느 규모인지 아는 분이 있나요?
Liquid가 로컬 모델에 힘을 쏟는 모습이 반가움. 앞으로 5년간 이 분야에서 큰 진전이 있기를 기대함.