Each language version is independently generated for its own context, not a direct translation.

🚀 SimpleTool: AI 가 "실시간"으로 일을 처리하는 비결

이 논문은 인공지능 (LLM) 이 외부 도구 (날씨 앱, 계산기, 지도 등) 를 사용할 때, 기존 방식보다 훨씬 빨라지는 새로운 방법을 소개합니다. 이름은 SimpleTool입니다.

기존 AI 는 글을 쓸 때처럼 한 글자씩 순서대로 도구 명령을 만들었습니다. 마치 손으로 편지를 쓸 때, "안녕"을 쓰고, 공백을 치고, "하세요"를 쓰는 식으로요. 하지만 이 방식은 너무 느려서, 로봇이 움직이거나 게임 캐릭터가 반응하는 실시간 상황에는 적합하지 않았습니다.

SimpleTool 은 이 문제를 해결하기 위해 두 가지 창의적인 아이디어를 섞었습니다.

1. 📦 아이디어 1: "불필요한 포장재 버리기" (토큰 압축)

비유: 택배 박스 vs. 내용물만

기존 방식 (포장재 가득): AI 가 도구를 호출할 때, JSON 이라는 형식을 따릅니다. { "이름": "날씨", "도시": "서울" }처럼 대괄호, 따옴표, 쉼표 같은 **불필요한 기호 (포장재)**를 많이 써야 합니다. AI 는 이 기호들도 하나하나 써야 하므로 시간이 오래 걸립니다.
SimpleTool 방식 (내용물만): AI 가 이 불필요한 기호들을 아예 쓰지 않게 합니다. 대신 <날씨>, <도시> 같은 **특별한 마법 단어 (Special Tokens)**를 사용합니다.
- 기존: { "name": "get_weather", "city": "Seoul" } (약 30 글자)
- SimpleTool: <날씨> get_weather <도시> Seoul (약 6 글자)
- 결과: 쓸 글자 수가 4~6 배 줄어듭니다.

2. 🏎️ 아이디어 2: "동시에 여러 대의 차 몰기" (병렬 디코딩)

비유: 요리사 한 명 vs. 요리사 여러 명

기존 방식 (한 명 요리): 요리사 (AI) 가 "재료 준비"를 다 하고 나서야 "요리 시작"을 합니다. 순서대로 하나씩 해야 하므로 시간이 걸립니다.
SimpleTool 방식 (여러 명 요리): AI 는 "무엇을 할 것인가 (도구 이름)"와 "어떤 값을 넣을 것인가 (인수)"가 서로 크게 상관없다는 점을 이용합니다.
- 도구 이름을 쓰는 요리사, 첫 번째 값을 쓰는 요리사, 두 번째 값을 쓰는 요리사가 동시에 일을 시작합니다.
- 모두 같은 주문서 (입력 문장) 를 보고 시작하므로, 준비 시간은 한 번만 걸립니다.
- 결과: 가장 늦게 끝난 요리사만 기다리면 되므로, 전체 시간이 3~6 배 빨라집니다.

🌟 이 기술이 가져오는 변화

이 두 가지 방법을 합치면 어떤 일이 일어날까요?

초고속 반응: 4090 그래픽카드 같은 일반 가정용 컴퓨터에서도 AI 가 1 초에 16 번 이상 도구를 호출할 수 있게 됩니다. (기존에는 1 초에 1~2 번 정도)
실시간 로봇 & 게임: 이 속도가 나오면, AI 가 로봇 팔을 조종하거나 게임 캐릭터가 적의 공격에 즉각 반응하는 것이 가능해집니다. (기존에는 AI 가 생각할 시간이 너무 길어 로봇이 뻔뻔하게 멈춰 서 있었습니다.)
작은 모델도 강력해짐: 구글의 작은 모델 (FunctionGemma) 보다 훨씬 작은 모델 (0.5B) 로도 더 정확하고 빠른 결과를 냅니다.

🎯 요약: SimpleTool 이란?

문제: AI 가 도구를 쓸 때 글자를 너무 많이 쓰고, 한 줄씩 써서 너무 느렸다.
해결:
1. 불필요한 기호를 없애고 (압축),
2. 여러 부분을 동시에 써서 (병렬 처리)
- 결과: AI 가 도구를 부르는 속도가 최대 9.6 배 빨라졌습니다!

이 기술은 AI 가 우리 생활 속 (로봇, 게임, 스마트폰 비서) 에 더 자연스럽게, 더 빠르게 들어오게 하는 핵심 열쇠가 될 것입니다. 마치 AI 가 "편지 쓰기"에서 "메시지 전송"으로 넘어가는 것과 같은 혁신입니다.

Each language version is independently generated for its own context, not a direct translation.

1. 문제 정의 (Problem Statement)

대형 언어 모델 (LLM) 기반의 함수 호출 (Function Calling) 은 에이전트가 외부 도구 및 환경과 상호작용하는 핵심 메커니즘입니다. 그러나 기존 방식은 자기회귀적 (Autoregressive) 디코딩에 의존하여 토큰 하나씩 순차적으로 생성하는 구조적 한계가 있습니다.

지연 시간 병목 현상: 함수 호출은 실행 전 완전하고 유효한 출력이 필요하므로, 스트리밍 방식으로는 지연 시간을 숨길 수 없습니다. 이는 토큰 수에 비례하여 선형적으로 증가하는 지연 시간 (Latency) 을 초래합니다.
실시간 요구사항 부재: embodied AI(로봇 제어), 게임 AI, 대화형 아바타 등 실시간 응용 분야는 보통 10Hz(100ms 미만) 이상의 응답 속도를 요구하지만, 기존 LLM 은 이를 충족하지 못합니다.
기존 가속화 기법의 한계:
- Speculative Decoding: 짧은 출력 (함수 호출) 에서는 오버헤드가 커서 효과가 제한적입니다.
- Constrained Decoding: 문법 기반 제어도 여전히 순차적 디코딩을 전제로 합니다.
- Quantization: 일반적인 가속은 제공하지만, 근본적인 토큰 생성 수의 문제를 해결하지는 못합니다.

2. 방법론 (Methodology)

저자들은 함수 호출 출력이 **구조적 중복성 (Structural Redundancy)**과 **약한 인과적 의존성 (Weak Causal Dependencies)**을 가진다는 통찰을 바탕으로 SimpleTool을 제안합니다. 이는 두 가지 핵심 메커니즘을 시너지 효과로 결합합니다.

가. 특수 토큰 (Special Tokens) 을 통한 토큰 압축

개념: 함수 호출의 JSON/Python 형식 출력에서 구조적 요소 (대괄호, 키 이름 등) 는 예측 가능하여 엔트로피가 낮습니다. SimpleTool 은 이러한 저엔트로피 토큰을 압축하는 특수 토큰을 어휘에 추가합니다.
구현: <function>, <arg1>~`, <|null|>` 등의 특수 토큰을 도입하여, 모델이 구조적 마커를 직접 생성하지 않고 값 (Value) 만 생성하도록 유도합니다.
효과: 출력 토큰 수를 4~6 배 감소시킵니다.

나. 병렬 디코딩 (Parallel Decoding)

통찰: 함수의 인자들은 입력 문맥에 기반하여 서로 독립적으로 추론될 수 있습니다 (약한 인과 의존성).
아키텍처:
- 하나의 입력 프롬프트 (공유된 KV Cache) 에 대해 여러 개의 병렬 헤드 (Head) 를 생성합니다.
- 각 헤드는 고유한 특수 토큰 (예: <function>, <arg1>, <arg2>...) 으로 시작하여 함수 이름과 각 인자를 동시에 생성합니다.
- 모든 헤드는 동일한 프리픽스 (Prefix) 를 공유하므로 KV 캐시 재사용이 가능하고, 프리필 (Prefill) 오버헤드는 한 번만 발생합니다.
지연 시간 분석:
- 기존: $T_{baseline} = T_p + N \cdot T_d$ (전체 토큰 수 $N$ 만큼 순차적)
- SimpleTool: $T_{ours} \approx T_p + \max(N_i) \cdot T_d$ (가장 긴 단일 헤드의 토큰 수 $N_i$ 만큼만)
- 메모리 대역폭 병목 (Memory-bandwidth bound) 특성상, 병렬 헤드 추가에 따른 연산 오버헤드는 미미합니다 (약 +8.2% 만 증가).

다. 학습 전략

LoRA 파인튜닝: MLP 레이어를 대상으로 LoRA 를 적용하되, 8 개의 서로 다른 출력 모드 (함수명 + 6 개 인자 + 콘텐츠) 를 학습하기 위해 높은 Rank(512) 를 사용합니다.
데이터 증강: 인자 개수 분포가 불균형한 기존 데이터셋을 보완하기 위해, 인자 개수가 다양한 합성 데이터를 생성하여 학습합니다.

3. 주요 기여 (Key Contributions)

SimpleTool 프레임워크 제안: LLM 이 실시간으로 함수를 호출할 수 있도록 하는 병렬 디코딩 프레임워크를 최초로 제안했습니다.
상호 보완적 설계: 토큰 압축 (출력 길이 단축) 과 병렬 디코딩 (동시 생성) 을 결합하여, 기존 방법론으로는 달성 불가능했던 극단적인 속도 향상을 실현했습니다.
광범위한 검증: Qwen 시리즈 (0.5B~14B) 모델에 대해 5 가지 벤치마크 (BFCL-v3, Mobile Actions 등) 에서 검증했습니다.
FunctionGemma 대비 우위: 구글의 엣지 전용 모델인 FunctionGemma(270M) 와 비교하여, 더 작은 모델 (ST-Qwen-0.5B) 로서도 정확도와 지연 시간 모두에서 우위를 보였습니다.

4. 실험 결과 (Results)

가. 속도 향상 (Speedup)

엔드투엔드 속도: 다양한 모델 크기와 벤치마크에서 3~6 배의 속도 향상을 달성했습니다.
최대 성능: RTX 4090 에서 AWQ 양자화 (4-bit) 를 적용한 Qwen3-4B 모델은 P50 지연 시간 61.2ms를 기록하여, 16Hz의 실시간 제어 주파수를 가능하게 했습니다.
비교: Qwen2.5-14B 모델은 기존 방식 대비 9.6 배 속도 향상을 보였습니다.

나. 정확도 (Accuracy)

전체 정확도: 모든 모델 크기에서 평균 2.9% 향상되었으며, 함수 선택 정확도는 7.1% 증가했습니다.
Mobile Actions: ST-Qwen-0.5B 는 제로샷 (69.3%) 과 파인튜닝 (86.2%) 모두에서 FunctionGemma(58.0%, 85.0%) 를 능가했습니다.
지연 시간 일관성: P90 지연 시간에서도 FunctionGemma 보다 훨씬 일관된 성능을 보여 실시간 애플리케이션에 적합함을 입증했습니다.

다. 확장성

병렬 헤드 오버헤드: 8 개의 병렬 헤드를 사용해도 지연 시간 오버헤드는 8.2% 에 불과하여 메모리 병목 현상을 효율적으로 활용함을 증명했습니다.
Speculative Decoding 호환성: SimpleTool 과 Speculative Decoding 을 결합할 경우, 추가적으로 2~3 배의 속도 향상이 가능하여 이론적 최대 14 배 이상의 가속이 가능함을 보였습니다.

5. 의의 및 결론 (Significance)

SimpleTool 은 LLM 기반 에이전트 시스템의 **실시간성 (Real-time capability)**이라는 근본적인 장벽을 허뭅니다.

엣지 디바이스 배포: 소비자용 GPU (RTX 4090) 나 모바일 기기에서도 4B 규모의 모델로 100ms 미만의 함수 호출을 가능하게 하여, 데이터센터 의존도를 낮추고 엣지 AI 배포를 가속화합니다.
응용 분야 확대: embodied AI(로봇), 게임 AI, 대화형 아바타 등 초저지연이 필수적인 분야에서 LLM 의 실용성을 크게 높입니다.
기술적 패러다임 전환: 단순한 모델 압축이나 추론 최적화를 넘어, 함수 호출의 구조적 특성을 활용하여 출력 표현 자체를 재정의하고 병렬화함으로써 새로운 가속화 방향을 제시했습니다.

이 연구는 LLM 이 단순히 텍스트를 생성하는 것을 넘어, 실시간으로 물리적/디지털 세계와 상호작용하는 '행동하는 에이전트'로 진화하는 데 중요한 기술적 토대를 마련했습니다.

SimpleTool: Parallel Decoding for Real-Time LLM Function Calling