CPU 환경에서의 Needle 26M vs Qwen3-0.6B 도구 호출 (Function Calling) 성능 비교: 5개 난이도 단계에

GPU 없이 4코어 CPU 환경에서, 특정 데이터를 선별하지 않고 두 개의 오픈 웨이트 (open-weight) 모델을 대상으로 도구 호출 (tool-calling) 헤드 투 헤드 테스트를 진행했습니다. 작은 전문 모델 (Gemini 3.1에서 도구 호출을 위해 증류된 Needle, 26M)이 도구 사용이 가능한 작은 범용 모델 (Qwen3-0.6B)을 상대로 실제로 성능을 유지할 수 있는지 확인하고 싶었습니다.

설정: 5개 단계(단순, 의역, 암시적, 모호함, 외국어 및 "도구를 호출하지 마시오" 함정을 포함한 엣지 케이스)에 걸친 50개 쿼리. 5개의 가상 도구. 실행당 세 가지 지표: parse_success (파싱 성공), tool_match (도구 일치), args_match (인자 일치). 동일한 쿼리, 동일한 평가 기준, 동일한 하드웨어 사용.

주요 수치:

                    Needle (26M)   Qwen3 (0.6B)
전체 tool_match       72.0%          56.0%
parse_success         84.0%          54.0%
args_match | match    97.2%         100.0%
평균 지연 시간 (mean latency)  10.9s          47.9s

흥미로운 점은 전체적인 승패가 아니라 실패의 양상입니다. 두 모델은 완전히 다른 양상을 보였습니다:

• Needle는 잘못된 도구를 선택함으로써 실패합니다. 도구를 선택했을 때, 인자 (args)는 97%의 확률로 정확했습니다. 이 모델의 실수는 선택 단계에 있으며, 주로 시스템 명령을 run_command 대신 search_web으로 라우팅하는 식입니다.
• Qwen3는 도구를 전혀 호출하지 않음으로써 실패합니다. 22번의 실패 사례 모두가 <tool_call> 태그를 생성하는 대신 산문 (prose) 형태로 답변하여 발생한 파싱 실패 (parse failure)였습니다. 일단 호출을 생성하면, 인자는 100% 완벽했습니다.

단계별 분석에서 차이가 극명하게 드러납니다. T1과 T2 (직설적 및 의역)는 각각 약 95%로 동일했습니다. T3 (도구 이름이 전혀 등장하지 않는 "암스테르담에 우산을 가져가야 할까요?"와 같은 암시적 질문)에서 Qwen3는 80%에서 10%로 급격히 성능이 떨어졌습니다. Needle은 의도를 정확히 매핑하는 반면, Qwen3는 산문으로 도움을 주려 시도하다가 실시간 데이터가 없다는 사과를 늘어놓습니다.

T5 (엣지 케이스)는 Qwen3가 10점 차이로 승리한 유일한 단계였습니다. 힌디어 쿼리는 Needle의 토크나이저 (tokenizer)를 망가뜨렸습니다 (데바나가리 문자가 심하게 깨졌으며, 한 쿼리는 73초 동안 타임아웃이 발생하며 깨진 출력을 내놓았습니다). Qwen3는 힌디어와 프랑스어 모두를 깔끔하게 처리했습니다.

Needle 테스트를 거의 망칠 뻔했던 한 가지 요인이 있었습니다. 처음에는 OpenAI JSON Schema를 입력으로 제공했기 때문에 점수가 8%에 그쳤습니다. Needle은 평면 스키마 ({location: {type, description, required}})로 학습되었으며, 인자 값으로