26M 파라미터 경량 LLM으로 엣지 디바이스에서 Function Calling 구현하기 — Needle 모델 분석 (github.com)

한줄 요약

26M 파라미터 경량 LLM이 엣지 디바이스에서 Function Calling을 초당 1200 토큰으로 실행한다.

무엇이 달라지나?

엣지 AI에서 Function Calling은 오랫동안 "클라우드의 영역"이었다. GPT-4나 Claude 같은 대형 모델이 도구 호출(tool call)을 정확하게 처리할 수 있었던 반면, 수백 MB 이하의 소형 모델은 JSON 스키마를 정확히 생성하는 것조차 어려웠다. Needle은 이 전제를 정면으로 뒤집는다.

Cactus Compute가 공개한 Needle은 26M(2600만) 파라미터 규모의 Function Call 전용 LLM이다. Gemini를 지식 증류(knowledge distillation)해 만들었으며, 아키텍처 명칭은 "Simple Attention Network(SAN)"이다. 구조적으로는 인코더 12레이어와 디코더 8레이어를 분리한 인코더-디코더 형태이며, FFN(Feed-Forward Network) 없이 Self Attention과 Cross Attention만으로 구성된 것이 특징이다. 임베딩 차원은 512, GQA(Grouped Query Attention) 방식으로 8헤드/4KV 헤드를 사용하고, BPE 어휘 크기는 8192다.

성능 수치도 주목할 만하다. Cactus 런타임 기준으로 프리필(prefill) 속도는 초당 6000 토큰, 디코딩 속도는 초당 1200 토큰이다. 학습은 TPU v6e 16개로 2000억 토큰을 약 27시간 동안 사전학습했고, 이후 20억 토큰 규모의 단일 Function Call 데이터셋으로 약 45분간 파인튜닝했다. 단일 Function Call 벤치마크에서 FunctionGemma-270m, Qwen-0.6B, Granite-350m, LFM2.5-350m을 능가한다고 밝히고 있다. 모델 웨이트와 데이터셋 생성 코드는 HuggingFace(Cactus-Compute/needle)에 완전 공개되어 있다.

실무에서 어떤 의미인가?

Needle이 흥미로운 이유는 단순히 "작은 모델"이기 때문이 아니다. Function Calling이라는 특정 작업에 완전히 특화된 설계 철학 때문이다.

일반 LLM은 대화, 요약, 코딩, 추론 등 다양한 태스크를 모두 처리할 수 있어야 하므로 파라미터를 줄이는 데 한계가 있다. Needle은 "도구를 언제, 어떻게 호출할 것인가"라는 단 하나의 문제만 풀도록 설계되어 있다. FFN을 아예 제거하고 Attention 연산만 남긴 것도 이 전략의 연장선이다. 모델 자체가 복잡한 추론을 하는 대신, 입력 쿼리와 도구 스키마를 받아 올바른 tool call JSON을 출력하는 역할에 집중한다.

실용적인 적용 시나리오를 생각해 보자. 스마트워치에서 음성 명령을 받아 캘린더 API를 호출하거나, 스마트 안경에서 실시간으로 날씨·위치 데이터를 조회하는 상황이다. 이런 환경에서 클라우드 API 레이턴시(수백ms~수초)를 감수하거나, 반대로 수 GB짜리 모델을 디바이스에 올리는 것은 현실적이지 않다. Needle은 이 갭을 메우는 포지셔닝이다.

개발자 입장에서 진입 장벽도 낮다. 저장소를 클론하고 needle playground 명령 하나로 웹 UI가 실행되며, 웨이트는 자동으로 다운로드된다. 파이썬 API도 generate() 함수 호출 수준으로 단순하다. Mac이나 PC에서 로컬 파인튜닝도 가능하다고 명시되어 있어, 특정 도구 세트에 맞게 모델을 커스터마이징하는 것도 현실적인 선택지다.

한 가지 중요한 맥락도 있다. 프로젝트 측은 이 모델이 대화형 AI로는 적합하지 않음을 명확히 한다. 단일 Function Call에 특화된 만큼 멀티턴 대화나 복잡한 추론이 필요한 작업에서는 Qwen이나 Granite 같은 범용 소형 모델이 더 나은 선택이 될 수 있다.

도입 전 체크포인트

Needle 도입을 검토한다면 아래 사항을 먼저 확인해야 한다.

작업 범위가 명확한가. Needle은 단일 Function Call에 최적화되어 있다. 복잡한 멀티스텝 에이전트나 대화 맥락이 필요한 시나리오라면 다른 모델을 고려해야 한다.

런타임 환경이 일치하는가. 공개된 속도 수치(6000/1200 toks/sec)는 Cactus 런타임 기준이다. 다른 추론 엔진을 사용한다면 실제 성능은 달라질 수 있다.

파인튜닝 필요 여부를 판단하라. 프로젝트 측은 도구 세트에 따라 파인튜닝을 권장한다. 특히 사내 고유 API 스키마가 복잡하다면, 기본 웨이트보다 파인튜닝된 버전이 훨씬 안정적으로 동작할 것이다.

아직 실험적 프로젝트임을 인식하라. README에서 직접 "experimental run"이라고 표현하고 있다. 프로덕션 크리티컬 시스템에 바로 적용하기보다 PoC 단계에서 검증하는 접근이 적절하다.