26M 모델 Needle, 도구 호출을 온디바이스로 끌어내린다

Cactus Compute가 공개한 Needle은 이름처럼 작습니다. 하지만 다루는 질문은 작지 않습니다. AI 에이전트에서 모든 판단을 거대 LLM에 맡겨야 하는가. 아니면 "사용자의 말을 어떤 도구 호출로 바꿀 것인가"처럼 좁은 작업은 훨씬 작은 모델로 분리할 수 있는가.

공식 저장소 설명에 따르면 Needle은 Gemini 3.1에서 증류한 26M 파라미터 Simple Attention Network입니다. 목적은 일반 대화가 아니라 function calling, 더 정확히는 자연어 요청을 구조화된 tool call JSON으로 바꾸는 일입니다. Cactus Compute는 Needle이 Cactus 런타임에서 6000 tokens/s prefill, 1200 tokens/s decode 속도로 동작한다고 설명합니다. 가중치와 데이터 생성 경로는 공개됐고, 저장소는 MIT 라이선스를 사용합니다.

이 발표가 흥미로운 이유는 "작은 모델도 꽤 한다"는 흔한 이야기가 아닙니다. 에이전트 아키텍처의 분업을 건드리기 때문입니다. 지금 대부분의 제품은 GPT, Claude, Gemini 같은 큰 모델 하나에 의도 파악, 계획, 도구 선택, 인자 생성, 결과 해석을 한꺼번에 맡깁니다. 이 구조는 개발하기 쉽지만 비쌉니다. 또한 스마트폰, 워치, 안경, 자동차, 로컬 데스크톱처럼 네트워크 지연이나 개인정보 제약이 있는 환경에서는 매번 클라우드 모델로 왕복하는 것이 부담입니다.

Needle은 이 문제를 다른 방식으로 봅니다. 사용자의 문장 안에 이미 필요한 정보가 들어 있고, 도구 스키마도 입력으로 주어진다면, 모델이 해야 할 일은 거대한 세계 지식을 떠올리는 것이 아니라 입력을 정해진 JSON 형식으로 변환하는 작업에 가까울 수 있습니다. 그렇다면 26M 모델도 충분히 쓸모 있는 첫 번째 라우터가 될 수 있다는 가설입니다.

Needle이 겨냥하는 것은 답변이 아니라 호출입니다

Needle의 README 예시는 단순합니다. 사용자가 "샌프란시스코 날씨가 어때?"라고 묻고, 도구 목록에 get_weather가 있으면 모델은 다음과 같은 호출을 반환합니다.

result = generate(
    model,
    params,
    tokenizer,
    query="What's the weather in San Francisco?",
    tools='[{"name":"get_weather","parameters":{"location":"string"}}]',
    stream=False,
)

print(result)
# [{"name":"get_weather","arguments":{"location":"San Francisco"}}]

중요한 것은 출력이 자연어 답변이 아니라는 점입니다. Needle은 날씨를 설명하지 않습니다. API를 호출하기 좋은 형태로 intent와 argument를 추출합니다. 이 차이가 큽니다. 일반 LLM은 사용자에게 직접 답하고, 필요하면 tool call을 중간 단계로 사용합니다. Needle은 그 중 tool call 변환 단계만 잘라낸 모델입니다.

제품 관점에서는 이 분리가 꽤 실용적일 수 있습니다. 예를 들어 모바일 앱 안의 command palette를 생각해 볼 수 있습니다. 사용자는 "어제 받은 영수증을 경비 폴더에 넣어줘"라고 말합니다. 앱은 가능한 도구로 search_mail, save_file, create_expense, open_folder를 갖고 있습니다. 이때 큰 모델이 모든 것을 처리할 수도 있지만, 첫 단계에서 작은 모델이 어떤 도구 후보가 필요한지 빠르게 좁히고, 더 어려운 판단은 큰 모델이나 앱 로직에 넘길 수도 있습니다.

웨어러블에서는 이 차이가 더 중요해집니다. 워치나 안경에서 사용자는 길게 프롬프트를 쓰지 않습니다. "타이머 7분", "회의 끝나면 이 사람에게 답장", "지금 보는 제품 저장"처럼 짧고 맥락 의존적인 명령을 말합니다. 이때 1초 미만의 반응성과 배터리, 네트워크 연결, 개인정보가 모두 중요합니다. 모든 요청을 클라우드 LLM으로 보내지 않고 로컬에서 도구 호출 후보를 만들 수 있다면 제품 설계의 자유도가 커집니다.

다만 이것이 거대 모델의 대체를 뜻하지는 않습니다. Needle은 결과 해석, 긴 계획, 다단계 추론, 모호한 업무 협상까지 모두 하겠다고 말하지 않습니다. 오히려 가치가 있다면, 작은 모델이 맡을 수 있는 일을 정확히 제한했기 때문입니다.

아키텍처는 일부러 좁게 설계됐습니다

README에 공개된 구조를 보면 Needle은 d=512, 8H/4KV, BPE=8192 설정을 갖습니다. 인코더는 12층, 디코더는 8층이며, 설명에서 눈에 띄는 부분은 no FFN입니다. 일반 Transformer 블록에서 attention 뒤에 붙는 feed-forward network를 제거한 형태입니다.

이 선택은 Hacker News에서도 가장 많은 기술적 반응을 불렀습니다. 한 댓글은 사실상 "Attention Is Actually All You Need"에 가깝다고 반응했습니다. 물론 이것을 일반화하면 위험합니다. FFN은 많은 LLM에서 파라미터 대부분을 차지하고, 모델이 내부 지식을 저장하고 비선형 변환을 수행하는 핵심 부품입니다. 그것을 빼도 모든 일이 된다는 뜻이 아닙니다.

Needle의 맥락에서는 해석이 조금 다릅니다. 입력에는 사용자 요청과 도구 스키마가 같이 들어옵니다. 모델이 파리의 수도를 기억하거나 물리학 문제를 풀 필요가 없습니다. 입력 안의 후보를 보고, 적절한 도구 이름과 인자를 조합해야 합니다. 지식 저장보다 입력 변환이 핵심이라면 attention 중심 구조가 더 작은 파라미터로도 성립할 수 있다는 주장입니다.

공식 README는 학습 과정도 공개했습니다. 사전학습은 16개 TPU v6e에서 200B tokens, 27시간으로 설명되고, 후학습은 single-shot function call dataset 2B tokens, 45분으로 설명됩니다. 이 수치만 보면 "작다"는 말이 모델 크기에만 해당한다는 점도 보입니다. 26M 모델이라도 학습 데이터와 증류 파이프라인은 가볍지 않습니다.

왜 지금 작은 도구 호출 모델이 중요해졌나

AI 에이전트의 첫 번째 세대는 "더 똑똑한 모델"에 집중했습니다. 복잡한 문제를 풀고, 계획을 세우고, 코드를 고치고, 브라우저를 조작하려면 결국 더 강한 모델이 필요했기 때문입니다. 하지만 실제 제품으로 들어오면 다른 병목이 보입니다. 도구 호출은 많고, 반복적이며, 항상 어려운 추론이 아닙니다.

예를 들어 일정 앱에서 "다음 주 화요일 오후에 민수와 30분 잡아줘"는 몇 가지 구조화된 필드로 바뀝니다. 메시지 앱에서 "이 내용을 팀 채널에 공유해줘"도 대상과 본문과 액션으로 나뉩니다. 개발 도구의 command palette에서 "최근 실패한 테스트만 다시 돌려" 역시 후보 명령어와 옵션 매핑 문제입니다. 이런 작업마다 frontier model을 부르면 비용과 지연 시간이 쌓입니다.

더 중요한 것은 개인정보입니다. 온디바이스 모델이 도구 호출 후보를 만들 수 있으면 일부 의도 파악은 로컬에서 끝낼 수 있습니다. 민감한 연락처, 위치, 파일명, 캘린더 제목을 외부 API로 보내지 않아도 되는 흐름을 설계할 여지가 생깁니다. 물론 실제 도구 실행이나 외부 서비스 접근은 여전히 권한과 감사 로그가 필요하지만, 첫 번째 intent routing을 로컬화하는 것만으로도 제품의 보안 표면이 달라집니다.

이 흐름은 최근 AI 인프라 경쟁과도 맞닿아 있습니다. 한쪽에서는 GPT, Claude, Gemini, Grok 같은 대형 모델이 더 긴 컨텍스트와 더 강한 reasoning을 겨룹니다. 다른 한쪽에서는 로컬 모델, speculative decoding, multi-token prediction, KV cache 압축, edge inference 같은 기술이 비용과 latency를 줄이려 합니다. Needle은 후자에 속합니다. 다만 일반 텍스트 생성이 아니라 agentic tool calling이라는 좁은 표면을 겨냥한다는 점이 다릅니다.

HN 반응이 보여준 기대와 의심

Hacker News의 반응은 이 프로젝트를 이해하는 데 도움이 됩니다. 글은 Show HN 형식으로 올라왔고, 2026년 5월 13일 확인 시점에 수백 포인트를 기록했습니다. 관심은 분명했습니다. 개발자들은 26M이라는 숫자, Gemini 증류, no FFN 구조, 온디바이스 실행 가능성에 반응했습니다.

하지만 커뮤니티는 동시에 아주 실용적인 질문을 던졌습니다. 단일 get_weather 도구가 주어진 예시는 쉽습니다. 진짜 문제는 수십 개 도구가 있고, 사용자의 말이 모호하며, 일부 도구는 위험한 부작용을 만들 때입니다. "내 상사에게 늦는다고 알려줘"라는 요청을 이메일로 보낼지, 메시지로 보낼지, 일정 변경으로 볼지, 단순 알림으로 볼지는 도구 목록과 앱 맥락에 따라 달라집니다.

HN 댓글 중 하나는 Hugging Face 예시에서 이 요청이 타이머 도구로 매핑됐다고 지적했습니다. 곧바로 다른 댓글은 예시에 실제 이메일 도구가 없었기 때문에 그랬고, send_email 도구를 제공하면 이메일 호출이 나온다고 반박했습니다. 이 논쟁은 Needle의 장점과 한계를 동시에 보여줍니다. tool calling 모델의 품질은 모델만으로 결정되지 않습니다. 어떤 도구를 제공하는지, 도구 설명이 얼마나 분명한지, 후보가 너무 많을 때 어떻게 narrowing하는지, 실패 시 어떻게 되묻는지가 모두 성능의 일부입니다.

개발자가 바로 적용할 수 있는 해석

Needle을 보고 "우리 앱에 바로 넣자"보다 먼저 해야 할 일은 작업을 분류하는 것입니다. 제품 안의 자연어 기능 중 어디가 단순 라우팅이고, 어디가 실제 reasoning인지 나눠야 합니다. 라우팅은 작은 모델에 맡길 수 있을지 모릅니다. reasoning은 여전히 큰 모델이 필요할 가능성이 큽니다.

예를 들어 개발자 도구라면 "파일 열기", "테스트 실행", "최근 로그 보기", "PR 만들기" 같은 명령어는 작은 모델 라우팅 후보입니다. 반대로 "이 아키텍처가 왜 느린지 분석하고 고쳐줘"는 코드 읽기, 가설 세우기, 실험, 수정, 검증이 필요합니다. 이 둘을 같은 모델 경로로 보내면 단순 명령도 비싼 모델을 쓰게 되고, 복잡한 작업도 잘못된 로컬 추론으로 망가질 수 있습니다.

개인 비서 앱도 마찬가지입니다. "7분 타이머"는 로컬 라우터가 충분합니다. "다음 주 투자자 미팅 전에 지난 이메일과 노션 문서를 읽고 브리핑 만들어줘"는 전혀 다른 문제입니다. Needle 같은 모델은 후자를 대체하기보다 전자의 지연 시간을 줄이고, 후자의 앞단에서 어떤 도구가 필요한지 좁히는 역할이 더 자연스럽습니다.

평가 방식도 달라져야 합니다. 일반 LLM 벤치마크처럼 정답률 하나로 보기 어렵습니다. 실제 tool calling에서는 다음 지표가 더 중요합니다. 적절한 도구를 골랐는가. 필수 인자를 빠뜨리지 않았는가. 모호할 때 무리하게 실행하지 않고 되물었는가. 위험한 도구를 호출하기 전에 확인 단계를 요구했는가. 도구 설명을 조금 바꿔도 안정적인가. 후보 도구 수가 늘어도 성능이 유지되는가.

Needle의 공개는 이런 평가 질문을 더 작고 재현 가능한 단위로 만들 수 있다는 점에서 의미가 있습니다. 26M 모델이라면 팀이 직접 fine-tuning하고, 도구 스키마를 바꿔 보며, 특정 제품 도메인에 맞춘 테스트 세트를 만들 수 있습니다. frontier API를 블랙박스로 호출하는 것보다 실험 비용이 낮아집니다.

작은 모델 전략은 에이전트 비용 구조를 바꿀 수 있습니다

에이전트 시스템이 비싸지는 이유는 한 번의 답변 때문이 아닙니다. 여러 번의 도구 호출, 실패 후 재시도, 상태 요약, 다음 행동 선택이 반복되기 때문입니다. 한 세션 안에서 작은 라우팅 판단이 20번 일어난다면, 그 모든 판단을 큰 모델에 맡기는 비용은 무시하기 어렵습니다.

작은 모델을 앞단에 두는 전략은 세 가지 효과를 노립니다. 첫째, 명확한 요청은 로컬에서 처리합니다. 둘째, 애매한 요청만 큰 모델로 올립니다. 셋째, 큰 모델에 넘길 때도 후보 도구와 인자를 미리 좁혀 컨텍스트를 줄입니다. 이 구조가 잘 작동하면 큰 모델은 "모든 것을 다 하는 모델"에서 "어려운 판단을 맡는 모델"로 바뀝니다.

물론 이 설계는 새로운 복잡성을 만듭니다. 모델이 둘 이상이면 오류도 둘 이상입니다. 작은 모델이 잘못 라우팅하면 큰 모델이 애초에 틀린 전제 위에서 움직일 수 있습니다. 따라서 routing confidence, fallback threshold, user confirmation, audit log가 필요합니다. 특히 쓰기 작업, 외부 발송, 결제, 삭제처럼 부작용이 있는 도구는 작은 모델의 단독 판단으로 실행하면 안 됩니다.

이 점에서 Needle은 제품이라기보다 아키텍처 신호에 가깝습니다. 앞으로 에이전트 제품은 큰 모델 하나로 모든 것을 처리하는 단순 구조에서 벗어나, 작은 모델, 정책 엔진, 검색 인덱스, 도구 런타임, 검증 모델이 섞인 구조로 갈 가능성이 큽니다. Needle은 그중 "도구 호출 라우터" 자리에 작은 오픈 모델을 놓을 수 있는지 묻는 실험입니다.

결론: 도구 호출은 별도 계층이 될 수 있습니다

Needle을 과장해서 읽으면 "26M 모델이 거대 LLM을 대체한다"가 됩니다. 하지만 공식 README도 그렇게 말하지 않습니다. Cactus Compute는 Needle이 single-shot function calling에 초점을 둔 실험이며, 더 큰 모델들이 대화형 범용 작업에서는 여전히 더 넓은 범위와 용량을 가진다고 명시합니다.

그럼에도 이 공개가 중요한 이유는 에이전트 시스템의 설계 단위를 바꾸기 때문입니다. 도구 호출은 LLM 응답 안의 부가 기능이 아니라, 독립적으로 최적화할 수 있는 인프라 계층일 수 있습니다. 작고 빠르고 로컬에서 돌 수 있는 모델이 이 계층을 맡는다면, AI 제품은 더 낮은 latency, 더 낮은 비용, 더 나은 개인정보 보호를 얻을 수 있습니다.

개발자가 지금 가져갈 교훈은 명확합니다. 에이전트 기능을 만들 때 모든 자연어 요청을 같은 모델 경로로 보내지 말아야 합니다. 먼저 작업을 나눠야 합니다. 단순 라우팅, 위험한 실행, 긴 추론, 결과 검증은 서로 다른 요구사항을 갖습니다. Needle은 그중 단순 라우팅을 작게 만들 수 있다는 가능성을 보여줍니다.

다음 경쟁은 모델 크기만의 경쟁이 아닐 수 있습니다. 어떤 판단을 큰 모델에 남기고, 어떤 판단을 작은 모델과 로컬 런타임으로 내릴 것인가. 에이전트 시대의 실무 아키텍처는 이 질문에 점점 더 많은 시간을 쓰게 될 것입니다.

출처

• Cactus Compute Needle GitHub 저장소
• Cactus Compute Hugging Face 모델 목록
• Hacker News Needle 토론 미러
• Cactus 런타임 GitHub 저장소