26M짜리 함수 라우터를 폰에 박을 수 있다면 — Needle이 던진 진짜 질문

핵심 요약 (TL;DR)

2026년 5월 12일 Cactus Compute가 HN에 'Needle'을 공개했고, 5월 14일 기준 627 포인트·180 댓글로 메인 1면에 올라갔습니다. 파라미터 26M, MIT 라이선스, Gemini 3.1의 tool calling을 합성 데이터로 distill한 결과로, MLP를 완전히 제거한 "Simple Attention Networks" 아키텍처를 씁니다. 폰·시계·안경에서 prefill 6000 tok/s, decode 1200 tok/s. 단일샷 function call에서 FunctionGemma-270M·Qwen-0.6B·Granite-350M·LFM2.5-350M을 모두 이긴다고 합니다. "에이전트 = 클라우드 호출"이라는 가정에 첫 균열이 난 사건입니다.

Needle이 정확히 무엇인가

저자는 Cactus Compute, Inc.의 Henry Ndubuaku입니다. 회사는 on-device AI 엔진을 만들고 있고, 이번에 푼 모델은 단일샷 function call 전용입니다. 즉 "질의 → 도구 이름 매칭 → 인자값 추출 → JSON 출력"이라는 작업을 reasoning이 아니라 retrieval-and-assembly 문제로 재정의하고, 그 좁은 작업만 푸는 모델인 거죠.

아키텍처는 'Simple Attention Networks'. Attention + gating만 두고 MLP/feed-forward 레이어를 완전히 제거한 구조입니다. 이 스케일(26M)에서 FFN 파라미터는 낭비라는 게 회사 주장입니다. 단 공식 학술 페이퍼는 아직 없고, GitHub의 docs/simple_attention_networks.md만 존재합니다.

학습은 어떻게 했냐. 사전학습은 200B 토큰을 16개 TPU v6e로 27시간. 사후학습은 2B 토큰의 합성 function-calling 데이터로, Gemini로 합성했고 타이머·메시징·내비게이션·스마트홈 등 15개 카테고리, 단 45분 만에 끝났습니다. 추론은 컨슈머 디바이스(폰·시계·안경)에서 prefill 6000 tok/s, decode 1200 tok/s. 이건 Cactus의 자체 측정치이고 외부 재현은 미공개라 그대로 받아들이기 전에 디바이스·환경 디테일을 확인해야 합니다.

공개는 풀-오픈입니다. MIT 라이선스, GitHub(github.com/cactus-compute/needle), HuggingFace(huggingface.co/Cactus-Compute/needle)에 가중치까지 다 올라가 있습니다.

"에이전트 = 클라우드 호출" 가정의 첫 균열

Claude·GPT-5.5·Gemini를 쓰는 에이전트는 tool call마다 클라우드 왕복을 거칩니다. 보통 100~500ms고, 데이터 센터가 멀거나 모델 큐가 길면 더 깁니다. "타이머 5분 설정" 같은 단순 명령도 같은 거리를 갔다 옵니다.

Needle이 보여준 건 그 왕복이 "단순 명령에 한해" 사라질 수 있다는 가능성입니다. 폰 안에서 1ms 이하로 함수 호출이 끝나면, "홈 도착 알림" 같은 작업에 클라우드를 부를 필요가 없죠. 즉 에이전트 아키텍처가 둘로 갈라집니다 — 로컬에서 처리하는 도구 라우팅 vs 클라우드로 보내는 reasoning. iOS 26과 Android(Gemini Intelligence) 모두 "on-device tool routing"을 만들고 있는데, Needle 같은 오픈웨이트 베이스라인이 26M으로 가능함을 증명한 순간 이 분리가 표준이 될 가능성이 생겼습니다.

MLP를 빼버린 아키텍처가 의미하는 건 더 작은 메모리·전력·지연인데, 이게 가능하면 "폰에 8B 모델 통째로 박기" 같은 무거운 접근 대신 "좁은 작업에 맞는 작은 전용 모델을 여러 개 박기" 패턴이 가능해집니다. 작은 모델 여러 개는 큰 모델 하나보다 업데이트·검증·교체가 훨씬 쉽습니다.

바이브코더가 가져갈 패턴

첫째, 내 앱의 function call 비용을 합산해보세요. Claude·OpenAI에 매달 내는 function-calling 호출 중 "reasoning 없이 도구 이름과 인자만 뽑으면 되는" 비율이 얼마나 되나요. 그 비율이 30%만 돼도 Needle로 옮기면 그 비용이 0이 됩니다.

둘째, 내 도구의 function-calling 학습 데이터를 Claude/GPT로 합성해 "vertical tool router"를 26M으로 학습하는 패턴이 가능해졌습니다. 합성 → distill → MIT로 풀-오픈이라는 Cactus의 레시피가 그대로 빌릴 수 있는 템플릿이거든요. 단 Gemini API ToS와 distillation 회색지대 논쟁은 HN 댓글에서 이미 시작됐고, 저자의 반박은 "가중치에 접근한 게 아니라 API 출력으로 합성한 거다"입니다. 어느 쪽 입장도 그대로 인용해두는 게 안전합니다.

셋째, on-device 에이전트가 표준이 되는 12개월 안에, "클라우드에 매번 fallback"을 가정한 SaaS는 가격 압박을 받습니다. "단순 명령은 로컬, 복잡 reasoning만 클라우드"라는 hybrid 라우터를 미리 설계해두는 게 다음 분기 비용 곡선을 가르는 결정이 됩니다.

코드 예시 — Needle을 부르는 가장 단순한 hybrid 라우팅

def route(user_input):
    # 1) Needle: 26M 로컬 모델 (function call 후보)
    tool_call = needle.predict(user_input)
    if tool_call.confidence > 0.85:
        return execute(tool_call)
    # 2) fallback: Claude
    return claude.tool_call(user_input)

이 구조에서 비용이 빠지는 자리는 1번에서 잡힌 호출이고, 이 비율이 곧 절감액입니다.

FAQ

Q. 6000 tok/s가 어떤 폰 기준인가요?
A. Cactus 자체 측정치고 정확한 디바이스(M3·Snapdragon 8 Gen 3·Pixel 9 등)는 공개되지 않았습니다. GitHub 이슈 트래커에서 별도 확인이 필요합니다.

Q. Gemini로 distill한 게 ToS 위반 아닌가요?
A. 저자 입장은 "모델 가중치에 접근한 게 아니라 API 출력으로 합성 데이터를 만든 것"입니다. Google 공식 ToS의 distillation 조항과 충돌 여부는 회색지대이고, HN 댓글에서 이미 양측 입장이 나뉩니다.

Q. 단일샷이 아닌 대화형에서도 쓸 수 있나요?
A. 단일샷 function call 전용입니다. 대화형 시나리오에서는 FunctionGemma·Qwen 같은 더 큰 모델이 여전히 강합니다. 즉 "전체 에이전트"가 아니라 "도구 라우팅 한 단계"에 박는 모델로 봐야 합니다.

Function-calling 비용이 "당연한 클라우드 비용"이던 시대는 26M 베이스라인이 등장한 5월 12일에 끝났습니다. 다음 12개월의 비용 곡선은 "어디서부터 로컬로 내릴 것인가"의 설계 결정에서 갈립니다.