작게 쪼갠 행동 계층: Needle를 볼 때 함께 비교해야 할 네 가지 tool-calling 운영 방식

출처: Hacker News — https://github.com/cactus-compute/needle

사용자가 "알람 맞춰줘"라고 말했을 때 시스템이 해야 할 일은 생각보다 거창하지 않다. 긴 설명문을 쓰는 것도 아니고, 세계 지식을 추론하는 것도 아니다. 대개는 현재 입력에서 의도를 읽고, 가능한 도구 목록 중 하나를 고르고, 필요한 인자를 뽑아서, 정해진 형식으로 호출하면 끝난다. Needle이 흥미로운 이유는 바로 이 지점을 정면으로 건드리기 때문이다. 이 프로젝트는 tool calling을 범용 대화 능력의 일부가 아니라 별도의 좁은 실행 문제로 보고, 그 문제만 잘 풀면 초소형 모델로도 실용 구간에 들어갈 수 있다고 주장한다.

기사와 저장소 기준으로 Needle은 26M parameter의 function-calling 모델이며, 작성자는 이를 Gemini 3.1에서 distill했다고 설명한다. 구조적으로는 FFN 없이 attention과 gating만으로 구성된 encoder-decoder 계열의 "Simple Attention Network"를 내세우고, 목적도 분명하다. 범용 대화가 아니라 single-shot function calling이다. 저장소는 Cactus 환경에서 6000 tok/s prefill, 1200 tok/s decode를 제시하고, FunctionGemma-270M, Qwen-0.6B, Granite-350M, LFM2.5-350M보다 single-shot function calling에서 앞선다고 주장한다. 동시에 같은 문서에서 다른 모델들이 conversational setting에서는 더 넓은 역량과 용량을 가진다고 직접 적어둔다. 이 자기 제한이 오히려 중요하다. Needle은 "작은데 다 된다"가 아니라 "작으니까 잘라서 써라"에 가깝다.

실무에서는 이 메시지를 모델 성능 경쟁으로만 읽으면 절반만 본 셈이다. 진짜 비교 대상은 모델 이름이 아니라 운영 방식이다. 지금 현장에서 부딪히는 선택지는 대체로 네 가지다.

첫째는 Needle 같은 초소형 전용 tool router다. 입력 문장과 도구 정의를 받아 한 번의 tool call JSON을 안정적으로 뽑아내는 데 집중한다.

둘째는 FunctionGemma 같은 소형 edge agent 베이스 모델이다. Google이 공개한 자료를 보면 FunctionGemma는 270M 규모의 function-calling 특화 모델이지만, 단순 호출뿐 아니라 tool result를 받아 다시 자연어로 요약하는 흐름까지 염두에 두고 있다. 즉 실행과 응답을 같은 모델 안에 두려는 성격이 더 강하다.

셋째는 LFM2.5-350M 같은 edge generalist다. Liquid AI 문서는 이 모델을 tool use, structured outputs, data extraction에 강한 350M 모델로 소개하고, lightweight on-device agentic pipeline에 적합하다고 설명한다. 하지만 동시에 math, code, creative writing 같은 영역에는 권장하지 않는다고 선을 긋는다. Needle보다 크지만, 순수 tool selection 하나만 보는 대신 더 넓은 실무 포맷 처리 능력을 노린다.

넷째는 Qwen이나 Granite 계열처럼 function calling을 지원하는 범용 또는 준범용 모델이다. 이쪽은 단일 호출 정확도 하나보다 multi-turn, tool response 해석, parallel call, 템플릿 호환성, 기존 serving stack과의 결합이 강점이다. Qwen 문서는 parallel tool calling과 tool_choice 제어를 설명하고, Granite 문서는 tool schema와 결과 해석까지 포함한 일반적인 function-calling 플로우를 제공한다. 이 계열은 흔히 상위 orchestration 레이어로 들어간다.

그렇다면 Needle은 무엇을 바꾸려는가. 가장 큰 변화는 "도구 선택을 reasoning 문제로 취급하지 않아도 된다"는 운영 가설이다. 저장소의 아키텍처 문서는 tool calling을 retrieval-and-assembly로 본다. 질의와 도구 이름을 맞추고, 인자를 복사 또는 정규화하고, JSON을 내보내는 작업이라는 뜻이다. 이 관점이 맞는 업무라면, 거대한 FFN 중심 범용 모델을 매번 돌리는 것은 낭비일 수 있다. 반대로 이 관점이 틀리는 순간, Needle류 접근은 바로 한계를 드러낸다. 사용자의 말이 모호하거나, 누락된 파라미터를 대화로 보충해야 하거나, tool result를 다시 설명으로 풀어줘야 하거나, 여러 단계를 계획해야 하는 순간에는 단순 라우터만으로는 부족하다.

여기서 비교 기준이 선명해진다.

첫 번째 기준은 입력의 모호성이다. 사용자가 항상 비교적 짧고 명확한 명령을 말하는가, 아니면 대화 도중 의도가 바뀌고 전제가 빠지고 사람식 생략이 많은가. Needle은 전자에 가깝다. 예를 들어 음성 비서에서 "10분 타이머", "거실 불 꺼", "엄마에게 늦는다고 문자 보내" 같은 명령은 잘게 정의된 도구 집합과 잘 맞는다. 반면 "어제 얘기하던 약속 일정 다시 잡아주고 상대방 기분 안 상하게 메시지도 써줘" 같은 요청은 tool routing만으로는 끝나지 않는다. 여기서는 FunctionGemma나 더 큰 범용 모델이 유리하다.

두 번째 기준은 대화 턴 수다. Needle의 공개 설명은 single-shot function calling에 초점을 둔다. HN 대화에서도 작성자는 작은 디바이스에서 Siri-like 코어를 목표로 한다고 설명하지만, in-context learning은 아직 아니라고 답했다. 이 말은 곧 복합 대화 흐름, 예시 기반 적응, 장기 문맥 유지가 현재 포지션의 중심이 아니라는 뜻이다. 따라서 멀티턴이 업무의 본체라면 Needle은 메인 모델이 아니라 전처리 또는 1차 분류기로 보는 편이 맞다.

세 번째 기준은 지연 시간과 배포 위치다. 여기서 Needle의 의미는 크다. HN 코멘트 기준으로 작성자는 INT4에서 약 14MB 수준이라고 설명했다. 이 수치는 예산형 폰, 웨어러블, 임베디드 장치처럼 메모리와 전력이 빡빡한 곳에서 이야기의 무게를 바꾼다. FunctionGemma도 edge를 겨냥하지만 270M이다. LFM2.5-350M은 더 넓은 작업을 하면서도 edge를 지향한다. 그러나 절대 크기와 운영 복잡도는 Needle보다 높다. 현장에서 "반드시 on-device여야 하고, cloud round trip이 곧 UX 실패"라면 Needle류는 검토 우선순위가 높아진다.

네 번째 기준은 실패 비용이다. 이것이 의외로 가장 중요하다. 작은 모델이 한 번 틀렸을 때 시스템은 어떻게 복구되는가. 예를 들어 스마트홈에서 잘못된 방의 조명을 끄는 실수와, 금융 앱에서 잘못된 이체 인자를 뽑는 실수는 전혀 다르다. Needle은 구조화된 출력과 빠른 실행에는 매력적이지만, 중요한 것은 모델이 아니라 guardrail 체계다. 파라미터 검증, 허용값 제한, tool schema 엄격화, ambiguous intent 시 실행 중단, human confirmation 같은 장치가 없다면 작은 모델의 속도 이점은 금방 사고 비용으로 상쇄된다. 반대로 그런 검증층이 이미 잘 갖춰진 조직이라면 Needle 같은 전용 라우터는 오히려 다루기 쉬운 부품이 된다.

실무 추천을 상황별로 말하면 더 분명하다.

가장 먼저 Needle을 고를 만한 팀은 "정의된 도구 집합"과 "짧은 명령형 입력"이 분명한 팀이다. 로컬 우선 음성 인터페이스, 스마트홈 컨트롤, 휴대기기 내 OS action 호출, 오프라인 어시스턴트의 1차 intent routing, CLI 자연어 래퍼가 여기에 들어간다. HN 코멘트에서도 Home Assistant, 커맨드라인 파서, 시리 유사 코어, Raspberry Pi류 장치에 대한 관심이 즉시 나왔다. 이 반응은 단순 호기심이 아니라 product fit 신호에 가깝다. 이 영역은 긴 문장 생성보다 호출 정확도와 반응성이 중요하다.

FunctionGemma를 우선 볼 팀은 실행 이후의 응답까지 같은 계층에서 처리하고 싶은 팀이다. Google 문서는 FunctionGemma를 function call 생성 후 자연어 요약까지 가능한 모델로 소개하고, local-first compound system에서 더 큰 모델로 라우팅하는 traffic controller 역할도 강조한다. 즉 "작은 모델이 바로 행동도 하고, 결과도 사용자에게 설명한다"는 구조를 원하면 Needle보다 FunctionGemma 쪽이 더 자연스럽다. 다만 이 경우에도 공식 문서가 fine-tuning의 중요성을 강하게 말하고 있으므로, zero-shot 만능을 기대하면 안 된다.

LFM2.5-350M이 좋은 선택이 되는 경우는 tool use를 데이터 추출, structured output, 다양한 edge workflow와 함께 묶어서 보고 싶은 팀이다. 예를 들어 단순히 도구를 고르는 것뿐 아니라 문서나 입력에서 구조화된 필드를 안정적으로 뽑고, 그 결과를 다음 단계로 넘기는 파이프라인이라면 이 계열이 더 잘 맞을 수 있다. Liquid 측은 multi-turn use case fine-tuning에서 높은 신뢰도 향상을 사례로 제시한다. 물론 그 수치를 모든 상황에 일반화하면 안 되지만, 적어도 Needle보다 넓은 작동 범위를 노린다는 점은 분명하다.

범용 Qwen/Granite 계열을 택해야 하는 순간도 많다. 도구 수가 많고, 사용자가 질문과 명령을 섞어 말하고, 응답 생성과 도구 선택을 오가며, hosted API나 기존 serving stack과 빠르게 맞물려야 하는 조직이라면 범용 계열이 총비용에서 이길 수 있다. 특히 팀이 이미 OpenAI-compatible tool schema, vLLM, chat template, tool result replay 같은 운영 자산을 갖고 있다면, 초소형 전용 모델을 새로 넣는 비용이 생각보다 크다. 모델 크기만 보고 싸다고 판단하면 안 되는 이유다. 통합 비용, 관찰성, fallback 설계, prompt template 이식 비용까지 포함해야 한다.

Needle에 대한 반례도 분명히 봐야 한다.

첫 번째 반례는 "tool calling이 곧 reasoning이 아니다"라는 주장이 업무에 성립하지 않는 경우다. 고객지원, 코딩 에이전트, 리서치 도우미처럼 사용자의 질문이 모호하고, 어떤 도구를 어떤 순서로 쓸지 계획해야 하고, 실행 결과를 다시 해석해야 하는 시스템에서는 tool calling이 단순 라우팅 문제가 아니다. 여기서는 큰 모델의 reasoning과 대화 회복력이 실제 비용을 낮춘다.

두 번째 반례는 도구 정의가 불안정한 경우다. 작은 전용 모델은 대개 잘 정리된 schema에서 빛난다. 그런데 현업 API는 설명이 빈약하고, 파라미터 이름이 이상하고, 같은 의미의 툴이 여러 개 존재하고, 버전이 자주 바뀐다. 이런 조직적 혼란이 크면 모델을 아무리 바꿔도 결과가 흔들린다. 이때는 모델 교체보다 tool catalog 정비가 먼저다.

세 번째 반례는 벤치마크 해석이다. Needle 저장소가 제시하는 우위는 single-shot function calling 범주에 한정된다. 그것이 실제 서비스의 end-to-end 성공률과 같다고 보면 곤란하다. 실서비스는 ASR 오류, 사용자 생략, 도구 응답 실패, 권한 문제, 후속 설명 생성까지 모두 포함한다. Needle이 비교군보다 낫다는 주장도 그 정의역 안에서 읽어야 한다.

네 번째 반례는 아키텍처 일반화의 속도다. 저장소 문서는 "no FFN" 발견이 RAG나 retrieval-augmented generation 등 구조화된 외부 지식을 쓰는 작업 전반으로 확장될 수 있다고 말한다. 흥미로운 가설이지만, 기사와 문서 시점에서는 이를 광범위한 실무 규칙으로 받아들이기보다 실험적 주장으로 취급하는 편이 안전하다. 특히 팀이 장기 유지보수 관점에서 표준 transformer 생태계의 지원을 중시한다면, 독특한 구조는 장점이자 리스크다.

도입 판단을 빠르게 하려면 기술 데모보다 아래 질문이 더 유용하다.

1. 우리 입력의 80%는 단일 도구 호출로 끝나는가.
2. 누락 파라미터가 생기면 실행 중단과 재질문 규칙을 별도로 둘 수 있는가.
3. tool schema를 짧고 명확하게 정리할 수 있는가.
4. 출력 형식이 틀렸을 때 실행 전에 완전히 걸러낼 수 있는가.
5. 모델이 잘못 고른 도구를 상위 정책층에서 차단할 수 있는가.
6. multi-turn 대화와 설명 생성이 핵심인지, 아니면 단순 라우팅이 핵심인지 팀이 합의했는가.

이 여섯 개 중 앞쪽 네 개에 강하게 "예"라고 답하면 Needle류가 유력하다. 반대로 마지막 두 개가 중요해질수록 FunctionGemma, LFM, 또는 범용 계열 쪽으로 무게가 옮겨간다.

실무적으로 가장 현실적인 구조는 단일 모델 신앙이 아니라 계층 분리다. 예를 들면 아래와 같은 식이다.

voice/text input
-> small tool router (Needle류)
-> schema validator / policy checks
-> tool execution
-> if success and simple: templated response
-> if ambiguous or multi-step: larger conversational model

이 구조의 장점은 명확하다. 가장 자주 발생하는 짧은 action은 작은 모델이 처리해 latency와 비용을 줄이고, 애매하거나 대화가 필요한 케이스만 더 큰 모델로 올린다. Google이 FunctionGemma를 더 큰 모델의 traffic controller로 설명한 부분도, Liquid가 작은 모델을 lightweight agentic pipeline에 두는 맥락도 결국 같은 그림을 가리킨다. Needle은 그 그림에서 가장 극단적으로 "router에 집중"한 사례다.

정리하면, Needle을 봐야 하는 이유는 26M이 대형 모델을 이겼다는 자극적인 문구 때문이 아니다. 오히려 반대다. 이 프로젝트는 tool calling이라는 문제를 어디까지 분해할 수 있는지, 그리고 분해했을 때 어떤 시스템 설계가 가능해지는지 보여준다. 단일-shot, 제한된 도구 집합, 낮은 지연 시간, 로컬 실행, 엄격한 schema라는 조건이 맞으면 Needle 같은 초소형 전용 모델은 매우 설득력 있다. 하지만 대화 회복력, 멀티턴, 설명 생성, 범용성, 기존 생태계 호환성이 중요하면 FunctionGemma나 LFM2.5-350M, 혹은 더 큰 범용 tool-calling 모델이 여전히 더 좋은 선택일 수 있다.

결국 질문은 "가장 작은 모델이 어디까지 되나"가 아니다. 더 실무적인 질문은 이것이다. 당신의 시스템에서 tool calling은 대화의 일부인가, 아니면 실행 계층 그 자체인가. Needle은 후자라고 답하는 팀에게 특히 강하게 읽히는 프로젝트다.

의견

댓글/토론에서 나온 의견을 참고용으로 정리했습니다. (사실로 단정하지 말고 맥락 확인 권장)

• Hacker News · @bityard: This is pretty much exactly what I want for Home Assistant. I yell out, "Computer! Lights!" and it toggles the lamp in the room on or off. (I mean I can do that now, I think, but probably with a much larger model.) I haven't played with it yet, but does it ever return anything other than a tool call? Wh…
  • 링크: https://news.ycombinator.com/item?id=48114828
• Hacker News · @ilaksh: Hmm.. this might make it feasible to build something like a command line program where you can optionally just specify the arguments in natural language. Although I know people will object to including an extra 14 MB and the computation for "parsing" and it could be pretty bad if everyone started doing that.…
  • 링크: https://news.ycombinator.com/item?id=48113166
• Hacker News · @BoredPositron: I source old, defective high-end radios with timeless designs from brands like Grundig or Braun, and replace the original hardware with a Raspberry Pi while using the original audio parts to build custom smart speakers. Reliable hotword detection and voice command recognition have been a persistent challenge over the …
  • 링크: https://news.ycombinator.com/item?id=48114927
• Hacker News · @jcgrillo: I'm having trouble understanding why someone would want that? Like, what are the product use-cases of such a thing? I understand why people want that for coding agents--although the jury is still very much out on whether those are terribly useful--but I cannot fathom what someone might want an agent to do on a ce…
  • 링크: https://news.ycombinator.com/item?id=48115763
• Hacker News · @simonw: Looks like you need to open up access to https://huggingface.co/Cactus-Compute/datasets/needle-tokeni... - I get this error when trying to run the steps in your README: > Repository Not Found for url: http s://huggingface.co/api/datasets/Cactus-Compute/needle-t…
  • 링크: https://news.ycombinator.com/item?id=48112914
• Hacker News · @ac29: FYI, distilling Gemini is explicitly against the ToS: "You may not use the Services to develop models that compete with the Services (e.g., Gemini API or Google AI Studio). You also may not attempt to reverse engineer, extract or replicate any component of the Services, including the underlying data or models (e.…
  • 링크: https://news.ycombinator.com/item?id=48113596

댓글

댓글을 읽어오는 중입니다.