AI 모델을 이야기할 때 우리는 먼저 누가 더 똑똑한지 비교합니다. Needle 2는 다른 질문을 던집니다. 모델은 실제로 어디에 들어갈 수 있고, 그곳에서 안정적으로 수행할 만큼 일이 충분히 좁은가요?
Needle 2는 Cactus Compute가 도구 호출·기기 사용·구조화된 정보 추출을 위해 만든 4,500만 파라미터 모델로 설명됩니다. 전체 모델은 14MB짜리 단일 바이너리이고, 공식 저장소는 한 세션에 약 28MB의 RAM을 사용한다고 안내합니다. 모든 주제를 다루려는 범용 챗봇과는 목표가 다릅니다.
작다는 숫자보다 좁은 계약이 중요합니다
Needle 2는 에이전트 행동을 제한된 계약으로 다룹니다. 입력은 일반 문장이지만 출력은 선언된 도구 스키마에 맞는 구조화된 데이터여야 합니다. 공개 저장소는 바이트 단위 문법 제약, 신뢰도 점수, 도구 검색, 256토큰 슬라이딩 윈도우를 설명합니다. 선언된 도구로 처리할 수 없는 요청에는 자유로운 답변을 지어내기보다 빈 호출을 반환할 수 있습니다.
| 설계 선택 | 실무에서 생기는 결과 |
|---|---|
| 구조화된 출력 | 실행 전에 호스트 시스템이 도구 호출을 검증할 수 있습니다. |
| 바이트 단위 문법 | “지켜라”는 프롬프트가 아니라 스키마가 출력 범위를 제한합니다. |
| 신뢰도 점수 | 언제 실행하고 언제 상위 경로로 넘길지 정할 수 있습니다. |
| 도구 검색 | 매 턴마다 큰 도구 목록 전체를 노출하지 않아도 됩니다. |
| 제한된 맥락 | 대화가 이어져도 메모리 사용량을 예측하기 쉽습니다. |
핵심은 파라미터 수 자체가 아닙니다. “방을 조금 시원하게 해줘”를 유효한 온도조절기 호출로 바꾸는 모델은 기후 시스템에 관한 긴 글을 쓰는 모델만큼의 지식을 필요로 하지 않습니다. 할 일을 좁히면 로컬 실행과 예측 가능한 출력을 함께 설계하기 쉬워집니다.
도착할 곳이 모델 설계의 일부가 됩니다
더 흥미로운 가능성은 작은 범용 모델 하나를 휴대폰에 넣는 데서 끝나지 않습니다. 특화 LLM은 들어갈 장소에 맞춰 만들어질 수 있습니다. 스마트워치에는 건강 이벤트와 짧은 음성 명령, 자동차에는 실내 제어와 내비게이션 의도, 가정용 기기에는 연결된 가전과 안전 경계, 로봇에는 허용된 동작 목록에 맞춘 모델을 둘 수 있습니다.
특정 접점을 위해 만든 모델이라면 같은 기능도 기기마다 다른 방식으로 담을 수 있습니다.
Needle 2가 이 제품들을 모두 제공한다는 뜻은 아닙니다. 모델이 거대한 지능 하나가 아니라 도착 지점에 맞춘 부품이 될 수 있다는 방향입니다. 기기 안에 들어갈 정도로 작다면 제품팀은 지연시간·배터리·센서·용어·실패 정책에 맞춰 모델을 설계할 수 있습니다.
온디바이스 모델의 역할은 호출을 만드는 데서 끝나지 않고, 실행·검증·상위 전달의 경계까지 포함합니다.
로컬에도 빠져나갈 길이 필요합니다
로컬에서 실행된다고 모든 요청을 로컬에 남겨야 하는 것은 아닙니다. 예측 가능한 동작은 작은 모델이 처리하고, 모호하거나 영향이 큰 요청은 더 큰 모델이나 사람에게 넘기는 구성이 현실적입니다. Needle 2의 신뢰도 기반 동작처럼 기준 이상이면 실행하고 낮으면 상위 경로로 올릴 수 있습니다. 기준값과 도구 권한, 결과 검증은 모델을 넣는 제품이 정해야 합니다.
기기에 넣기 전에 확인할 장면
작은 모델을 실제 제품에 넣기 전에는 평균 응답 속도보다 실패 장면을 먼저 모아야 합니다. “조명을 켜줘”처럼 도구와 인자가 분명한 요청, “조금 덜 춥게 해줘”처럼 값의 해석이 필요한 요청, 선언되지 않은 기기를 지칭하는 요청을 같은 테스트 세트에 넣습니다. 각 요청에 대해 유효한 호출·빈 호출·상위 경로 전달 중 무엇이 나왔는지 기록하면 모델의 한계가 대화 문장 뒤에 숨지 않습니다.
스키마 변화도 별도 장면으로 다뤄야 합니다. 도구의 필드 이름이나 허용 범위를 바꿨을 때 이전 호출이 계속 유효한지, 잘못된 필드가 실행 전에 거부되는지, 모델이 모르는 새 필드를 억지로 채우지 않는지 확인해야 합니다. 구조화된 출력은 실행기를 보호하는 장치이지만, 스키마 버전과 검증 실패의 처리 방식까지 자동으로 정해주지는 않습니다.
오프라인 상태와 상위 경로 장애도 정상적인 테스트 입력입니다. 네트워크가 끊겼을 때 로컬에서 처리할 수 있는 요청은 계속 수행할지, 실행 대신 사용자에게 확인을 요청할지, 이미 만든 호출을 폐기할지 정책을 정해야 합니다. 신뢰도 점수 하나만 보고 자동 실행하지 말고, 영향이 큰 동작에는 도구별 확인 규칙과 사람 승인 조건을 추가하는 편이 안전합니다.
이 테스트의 목표는 Needle 2가 모든 기기에서 최고의 모델이라는 결론을 내리는 것이 아닙니다. 제품이 감당할 수 있는 오류 유형과 상위 경로 비용을 먼저 드러내서, “작아서 쓸 수 있다”를 “이 계약 안에서 검증할 수 있다”로 바꾸는 것입니다.
작은 모델을 도입하기 전에 다음을 따로 측정해야 합니다.
- 신뢰도 점수가 실제 도구 호출 정확도와 함께 움직이는가
- 스키마나 도구 설명 때문에 잘못된 동작이 얼마나 생기는가
- 상위 모델이나 사람에게 넘길 때 필요한 맥락이 보존되는가
- 로컬 모델·도구·네트워크를 사용할 수 없을 때 어떻게 실패하는가
비용도 있습니다. 작은 모델은 도구 범위를 벗어나면 흔들릴 수 있고, 기기마다 모델을 튜닝한다면 평가·업데이트·로그 기록·삭제까지 팀이 책임져야 합니다. 온디바이스는 책임을 제품 가까이 옮길 뿐입니다.
Needle 2가 흥미로운 이유는 모델 설계에 도착 지점을 포함시켰기 때문입니다. 앞으로의 LLM은 하나의 최강 모델이 아니라 시계·자동차·가전·로봇·로컬 에이전트 안에 들어가는 작고 많은 전문가 모델일 수 있습니다. 질문도 “어느 모델이 이기나?”에서 “이 장소와 제약에 맞는 모델은 무엇인가?”로 바뀔 가능성이 있습니다.
