8~29MB 초소형 AI가 말을 명령으로 바꾸는 구조

• 핵심: 말 한마디를 함수 이름과 인자로 바꾸는 829MB 초소형 구조의 요점 정리
• 맥락: 220층 선택과 3600억 토큰 구조화 학습이라는 배경
• 관점: 숫자 약속이 아니라 조건과 한계를 함께 읽는 지점

사장님, 말로 기기를 부려본 상상을 해보신 적 있으신가요? 기술 뉴스는 빠릅니다. 숫자는 현란합니다. 그래서 무엇을 믿어야 할지 막막합니다. 이 글은 작은 모델 하나를 차분히 뜯어봅니다. 대화를 잘하는 모델 이야기가 아닙니다. 말을 실행 가능한 호출로 바꾸는 모델 이야기입니다 [1]. 기기 안에서 찾는 흐름이 궁금하시면 임베딩 검색 흐름을 다룬 글을 함께 참고해 보세요.

말 한마디가 함수 호출이 되는 과정

도구 호출은 식당 주문서를 주방에 넘기는 일과 같습니다. 손님 말이 주방 언어로 바뀌어야 음식이 나옵니다. 이 모델은 사용자 문장을 앱이 등록한 함수 중 하나로 연결합니다 [1]. 함수 이름과 인자를 JSON으로 내놓습니다 [1]. 두 가지 일을 함께 말하면 순서대로 호출을 두 개 만듭니다 [1]. 해당하는 도구가 없으면 빈 목록을 내놓도록 설계됐습니다 [1]. 추측해서 없는 기능을 만들어내지 않는다는 뜻입니다. 이 점이 작은 기기에서 중요합니다. 틀린 실행은 다시 되돌리기 어렵기 때문입니다.

구조화 추출은 청구서에서 필요한 칸만 오려내는 일과 같습니다. 청구서와 예약, 알림과 양식의 흐트러진 문장을 지정한 필드로 바꿉니다 [1]. 공급업체와 금액, 납기일을 뽑는 식으로 씁니다 [1]. 출력 문법을 제한해 파싱 가능한 결과를 만듭니다 [1]. 다만 형식이 맞다고 내용이 맞는 것은 아닙니다. 이 구분이 실무의 핵심입니다. 형식은 기계가 지키고, 사실은 사람이 확인합니다.

임베딩은 책갈피에 뜻을 적어두는 일과 같습니다. 문장을 벡터로 바꿔 기기 안에서 검색과 매칭에 씁니다 [1]. 메모와 메시지를 의미로 찾습니다 [1]. 요청에 가까운 도구를 고릅니다 [1]. 비슷한 알림을 하나로 묶습니다 [1]. 작은 기기에서 인터넷 없이 찾는 힘이 됩니다.

핵심 변화 3가지

예전에는 작은 기기가 말을 알아듣지 못했습니다. 버튼을 눌렀습니다. 앱을 열었습니다. 항목을 직접 골랐습니다. 이 모델은 그 순서를 바꿉니다 [1]. 말을 호출로 바꿉니다 [1]. 항목을 JSON으로 뽑습니다 [1]. 표로 정리했습니다 [1][2].

구분	기존 작은 기기 방식	이번 구조의 변화	읽을 때 둘 점
입력 처리	버튼과 메뉴 선택	말과 도구정의로 호출 생성	도구 설명이 명확해야 함
정보 정리	사람이 눈으로 발췌	스키마대로 JSON 추출	문법과 정확도를 구분
기기 내 찾기	키워드 일치 검색	의미 벡터 매칭	인터넷 없이 동작하는 범위 확인

이 표가 말하는 바는 하나입니다. 작아진 것은 몸집이고, 달라진 것은 말과 실행 사이의 거리입니다.

829MB와 220층이 의미하는 것

모델 크기는 옷 치수와 같습니다. 몸에 맞는 것을 고르면 움직임이 편해집니다. 이 모델은 829MB 바이너리 하나로 배포됩니다 [1]. 2개 층부터 20개 층까지 필요한 깊이를 골라 씁니다 [1]. 각 하위 네트워크는 따로 미세 조정할 수 있습니다 [1]. 2900만1억2100만 파라미터의 Laddered Simple Attention Networks와 CQ2 양자화를 씁니다 [1]. 양자화는 겨울 이불을 납작하게 접어 넣는 일과 같습니다. 부피는 줄이고 쓸모는 남기는 과정입니다. 제품 소개에는 829MB, 계층별 CQ2 2비트 설명에는 929MB 표기가 함께 있습니다 [1]. 숫자가 하나가 아니니 읽을 때 범위로 이해하시면 됩니다. 이 차이가 성능을 가르는 것은 아닙니다. 어떤 층을 골랐는지가 더 중요합니다.

학습은 3600억 토큰의 독점 구조화 데이터로 이뤄졌습니다 [1]. 구조화 데이터는 정돈된 연습문제와 같습니다. 같은 시간을 써도 방향이 분명하면 결과가 다릅니다. 전체 1억2100만 매개변수 중 7000만 개가 n-gram 테이블에 들어 있습니다 [1]. MLP 없이도 이름과 곡을 가리는 힘의 출처입니다. 지식을 외우는 방식이 아니라 요청에서 복사하는 방식에 가깝습니다. 그래서 없는 지식을 묻는 일에는 약합니다.

작은 모델은 만능이 아니라 정해진 일을 빠르게 처리하는 존재로 읽어야 합니다 [1].

숫자를 조건과 함께 읽는 법

속도는 Raspberry Pi 5에서 생성 초당 4004000토큰, 입력 처리 초당 100010000토큰으로 측정됐습니다 [1]. 범위가 넓습니다. 고른 하위 네트워크에 따라 속도와 처리 능력이 달라지기 때문입니다 [1]. 숫자를 하나만 기억하면 오해가 생깁니다. 범위로 기억하면 선택지가 보입니다. 빠른 층과 정확한 층이 다르다는 뜻입니다.

DroidCall 도구 호출 평가에서는 제품별 작업에 맞춰 미세 조정한 뒤 각 하위 네트워크 점수가 18~36포인트 올랐습니다 [1]. 4개 층 2900만 파라미터 모델부터 DeepSeek V4 Flash를 앞섰습니다 [1]. 이 비교에는 조건이 있습니다. Needle 쪽은 Cactus Platform에서 미세 조정한 모델이고, 비교 상대는 클라우드 API로 호출했습니다 [1]. 양쪽 모두 호출을 강제하는 설정으로 평가했습니다 [1]. 정해진 도구와 작업에 특화했을 때의 결과입니다. 범용 대화나 추론 전반을 넘었다는 뜻이 아닙니다. 이 구분을 놓치면 숫자가 약속으로 바뀝니다. 조건과 함께 읽으면 선택 기준이 됩니다.

자체 평가에서는 모바일 도구 호출에서 크기가 10배인 모델을 앞섰고, 정보 추출에서는 2~3배 큰 모델과 비슷한 성능을 기록했습니다 [1][2]. 작은 일을 좁게 잘하는 설계의 결과입니다. 모든 일을 하는 설계와 견주는 것은 무리입니다. 이 점이 심층형으로 읽어야 하는 이유입니다.

신뢰도와 트리거가 성패를 가르는 이유

신뢰도는 신호등과 같습니다. 서라고 하면 서야 합니다. 모든 응답에는 confidence 점수가 붙습니다 [1]. 엔진 기본 하한은 0.1입니다 [1]. 그보다 낮은 호출은 suppressed_calls에 보류하고 function_calls를 비워둡니다 [1]. 앱은 점수가 높으면 실행하고, 애매하면 사용자에게 확인하는 흐름으로 씁니다 [1]. 공식 예제는 0.7 이상이면 실행하고, 후보가 있으나 그보다 낮으면 확인하고, 후보가 없으면 거부합니다 [1]. 호출이 생겼다고 바로 실행하는 구조가 아닙니다. 만듦과 씀을 나누는 설계입니다.

신뢰도는 확인 요청의 기준선입니다

기준선이 없으면 기계가 독단으로 움직입니다. 기준선이 있으면 사람이 끼어들 틈이 생깁니다. 이 모델은 낮은 신뢰도를 숨기지 않고 보류 목록에 남깁니다 [1]. 보류는 실패가 아닙니다. 확인 요청의 재료입니다. 매장에서라면 cast iron 같은 단단한 원칙입니다. 애매하면 묻는 편이 빠릅니다.

댓글 실패담은 도구 설명의 문제였습니다

화장실 불을 켜려다 엉뚱한 기기가 켜졌다는 보고가 있었습니다. 온도를 올려달라 했더니 조명이 바뀌었다는 보고도 있었습니다. 메일 확인이 브라우저 오류로 이어졌다는 보고도 있었습니다. 상당수는 테스트 환경의 도구 정의와 트리거에서 비롯된 문제라는 설명이 뒤따랐습니다. 도구 목록을 잘 구성해야 강점이 산다는 취지입니다 [1]. 추론 설명도 늘 믿을 만한 것은 아니라는 지적이 있었습니다. 알람을 끄려는 뜻을 정확히 풀고도 실제로 끄지 않은 사례가 거론됐습니다. 이 대목이 중요합니다. 말을 이해한 것과 일을 끝낸 것은 다릅니다. 작은 모델일수록 도구 설명과 스키마가 성능을 좌우합니다 [1]. 설명 한 줄이 오작동과 정상 작동을 가릅니다.

트리거는 정규식으로 특정 표현을 지정한 도구에 연결하는 기능입니다 [1]. 일치하면 디코딩 범위를 제한하고 호출 생성을 강제합니다 [1]. 기본 신뢰도 하한보다 낮아도 호출이 나옵니다 [1]. 그래서 호출 생성과 실제 실행 여부를 구분해야 합니다 [1]. 패턴이 턴 전체에 영향을 주므로 너무 넓게 잡으면 다른 도구의 일을 가로챕니다 [1]. 여러 작업을 함께 말하는 경우도 고려해 충돌 없이 설계해야 합니다 [1]. 원문엔 없지만 배경 이해를 위해 추가 확인한 임베딩 입문 자료와 양자화 개념 안내를 함께 보면 이 설계가 왜 필요한지 더 잘 이해됩니다 [4][5].

왜 알아두면 좋은가

이 구조가 시사하는 바는 분명합니다. 모든 일을 작은 기기에 넣자는 주장이 아닙니다. 정해진 일을 기기 안에서 끝내자는 제안입니다. 스마트홈에서는 침실 조명을 어둡게 하고 문을 잠그는 말을 조명과 잠금장치 호출로 바꿉니다 [1]. 기기가 제어 기능을 갖추면 명령 해석을 클라우드에 보내지 않고 처리할 수 있습니다 [1]. 로봇은 주방 청소는 하되 침실은 빼라는 말을 구역 설정과 복귀 명령으로 연결합니다 [1]. 스마트폰은 앨범 생성과 밝기 조절, 파일 검색을 자연어로 호출합니다 [1]. 웨어러블은 카드 결제 알림에서 가맹점과 금액, 날짜를 뽑습니다 [1]. AR 안경은 짧은 요청을 길 안내와 주변 검색으로 연결합니다 [1]. 자동차는 공조와 미디어, 내비게이션과 통화를 등록해 명령을 만듭니다 [1]. 컴퓨터는 메일 초안과 타이머, 주소 복사와 탭 열기를 연결합니다 [1]. 입력은 텍스트이므로 음성 제품은 별도 음성인식이 필요합니다 [1]. Python 패키지에서는 전체 20개 층 기본 모델을 고정하고 LoRA를 학습한 뒤 원하는 하위 네트워크를 4비트 .cact 파일로 빌드합니다 [1][2]. 배포 대상별 1MB 미만 사전 빌드 엔진이 needle3.cact 가중치를 불러오는 방식입니다 [1][2]. 소스는 공개 저장소에서 확인할 수 있습니다 [2]. 지식의 출처를 확인하는 습관이 이 글을 읽는 수확입니다.

정리하면 세 가지입니다. 첫째, 말을 호출과 JSON으로 바꾸는 좁고 빠른 설계가 있습니다 [1][3]. 둘째, 2~20층 선택과 신뢰도·트리거 설계가 성패를 가릅니다 [1]. 셋째, 숫자는 조건과 함께 읽을 때만 기준이 됩니다 [1][2]. 한 줄 정리: 작은 기기의 미래는 더 많이 아는 것이 아니라 정해진 일을 끝까지 해내는 것에 있습니다.

함께 보면 좋은 글

• MobileBot으로 낡은 스마트폰을 AI 서버로 만드는 법
• 소기업이 AI를 도입하는 가장 현실적인 3단계 가이드

자주 묻는 질문

도구 호출은 작은 기기에서 정확히 무엇을 합니까

앱이 미리 등록한 함수 중에서 요청에 맞는 것을 고르고 문장에서 인자를 채워 JSON으로 내놓습니다. 두 가지 일을 말하면 순서대로 두 개를 만들고, 맞는 도구가 없으면 빈 목록으로 답합니다. 이 방식은 추측 실행을 줄여 오작동 부담을 낮춥니다.

임베딩은 인터넷 없이 어떤 도움이 됩니까

문장을 의미 벡터로 바꿔 기기 안에서 메모와 메시지를 뜻으로 찾습니다. 요청과 가까운 도구를 고르거나 비슷한 알림을 묶는 데 씁니다. 통신이 끊긴 자리에서도 찾는 일을 계속할 수 있습니다.

829MB와 초당 4004000토큰을 어떻게 받아들여야 합니까

작은 바이너리로 배포된다는 사실과 층 선택에 따라 속도가 크게 달라진다는 사실을 함께 봐야 합니다. 가벼운 층은 빠르고 무거운 층은 할 수 있는 일이 넓습니다. 하나의 숫자가 아니라 범위로 이해하면 기기 선택이 쉬워집니다.

작은 모델이 대형 모델을 앞섰다는 말은 사실입니까

정해진 도구와 작업에 맞춰 다듬은 뒤 특정 평가에서 앞선 기록이 있습니다. 범용 대화나 폭넓은 추론까지 앞섰다는 뜻은 아닙니다. 조건을 빼고 읽으면 오해가 생기니 평가 설정부터 확인하시는 편이 좋습니다.

이런 구조를 살펴볼 때 무엇을 먼저 점검해야 합니까

도구 설명이 동작 단위로 분명한지, 필수 인자의 기본값과 형식이 적혀 있는지부터 보시면 됩니다. 신뢰도 기준과 확인 흐름이 있는지, 트리거가 다른 도구의 일을 가로채지 않는지도 함께 보시면 좋습니다. 이 다섯 가지가 서 있으면 작은 모델도 안정적으로 쓸 수 있습니다.

참고 자료

• [1] Needle 3 공식 제품 페이지 (https://cactuscompute.com/needle)
• [2] Needle 공식 저장소 (https://github.com/cactus-compute/needle)
• [3] Intelligence Laddering 설명 (https://cactuscompute.com/blog/intelligence-ladders)
• [4] 구글 머신러닝 입문 임베딩 안내 (https://developers.google.com/machine-learning/crash-course/embeddings/what-are-embeddings)
• [5] 허깅페이스 양자화 개념 안내 (https://huggingface.co/docs/optimum-concept-guides/quantization)