1,000번 중 5번만 진짜 JSON이었다: 소형 모델 MCP 툴콜링 신뢰도 리뷰

원문 정보

Abrar Shahriar, Qurat-Ul-Ain Mastoi, "Beyond Fluent Generation: A CPU Reliability Benchmark for MCP-Style Tool Calling in Sub-2B Small Language Models for Edge Deployment", arXiv:2609.07370 [cs.CL], 2026-09-07 제출. 소속: University of the West of England, Bristol. 노트북·프롬프트·상세 응답 데이터 공개(github.com/Abrar051/sml_mcp_benchmark).

동료심사를 거치지 않은 arXiv 프리프린트입니다. 저자 2인 모두 같은 대학 소속이며 자금 출처 표기는 없지만, 특정 벤더가 아니라 오픈웨이트 체크포인트 다섯 종을 나란히 비교하는 구조라 상업적 이해상충은 낮아 보입니다. 원문 전문은 세션 egress 차단으로 이번 실행에서 직접 열람하지 못해, GitHub Actions가 2026-09-10T23:15:12Z에 arXiv HTML 전문을 수집해 둔 스냅숏(9일 전 자동 수집분)으로 표와 수치를 대조했습니다.

연구 개요

연구 질문은 두 가지입니다. 20억 파라미터 미만 오픈웨이트 소형 언어모델이 MCP 스타일 JSON 툴 호출을 얼마나 안정적으로 만들어내는가, 그리고 그 신뢰도에는 어떤 CPU 자원 비용이 따르는가입니다. 다섯 모의 도구(날씨 조회·웹 검색·계산·이메일 작성·할일 생성)에 각 20개씩, 총 100개 프롬프트를 만들었습니다. 모든 프롬프트가 정답 도구명과 인자값을 그대로 명시하고 있어, 이 벤치마크는 "의도 파악"이 아니라 "지시를 그대로 베껴 직렬화하는" 하한선 테스트에 가깝습니다.

Phi-1.5, Pythia-1.4B, TinyLlama-1.1B-Chat, Qwen2.5-0.5B, Qwen2.5-1.5B 다섯 체크포인트를 CPU FP32로 로드해, greedy 디코딩과 온도 0.7·top-p 0.9 샘플링 두 조건에서 각각 100개 프롬프트를 실행했습니다(총 1,000회 생성, 시드 42 고정). 채점은 마크다운 펜스를 지우고 중괄호 구간을 추출해 JSON을 파싱하는 "복구" 절차를 표준으로 삼고, 도구명 일치·인자 존재·값 일치(상대오차 10⁻³ 이내)를 순차 확인합니다. 별도로 복구 과정 없이 전체 응답을 그대로 파싱하는 "엄격 JSON" 기준도 감사했습니다.

핵심 결과

복구 기준 성공률은 모델·디코딩 조합에 따라 0%에서 79%까지 갈렸습니다. 95% 신뢰구간은 Wilson 구간입니다.

가장 눈에 띄는 것은 마지막 열입니다. 최고 성능 조건(Qwen2.5-1.5B 샘플링)에서조차 1,000회 원시 응답 중 직접 JSON으로 파싱되는 것은 5건, 0.5%뿐입니다. 나머지는 마크다운 펜스나 부연 설명이 붙어 있어야 "복구"됩니다. 도구별 결과(Table 4)에서는 Qwen2.5-1.5B greedy가 계산·할일·이메일 100%, 검색 75%인데 날씨만 정확히 0%였고(샘플링에서는 70%로 회복), 이렇게 집계 성공률이 도구별 결정론적 실패를 가리기도 합니다. 다섯 도구 성공률의 평균이 각 조건의 전체 성공률과 정확히 일치함을 직접 검산했습니다.

디코딩 전략의 효과는 모델마다 반대 방향입니다. Qwen2.5-0.5B는 샘플링에서 성공률이 72%→32%로 40%p 급락했고(대응표본 McNemar 검정 p=1.62×10⁻⁷, 100개 중 50개는 greedy에서만·10개는 샘플링에서만 성공), Qwen2.5-1.5B는 75%→79%로 사실상 차이가 없었습니다(p=.608, 불일치 성공 15 대 19).

별도의 3회 반복 CPU 자원 측정(공유 노트북 프로세스, 웜업 1회 후 50토큰 생성 3회)은 다음과 같습니다.

Qwen2.5-0.5B는 Qwen2.5-1.5B보다 성공률이 3%p 낮은 대신(72% vs 75%, greedy 기준) 평균 지연시간이 약 65% 낮고(10.627초 대 30.782초) RSS는 약 54% 낮습니다(3,637MiB 대 7,960MiB) — 두 수치 모두 원문 서술과 직접 계산으로 일치를 확인했습니다. 다만 저자들도 명시하듯 이 RSS는 공유 프로세스에서 측정돼 모델 가중치 크기와 다릅니다(1.4B 파라미터인 Pythia가 가장 낮은 RSS를 기록하는 비상식적 순서가 그 증거입니다). 이 CPU 실험은 Raspberry Pi 등 특정 보드에서 직접 측정한 것이 아니라 플랫폼 무관 기준선이라는 점도 원문이 반복해 강조합니다.

신뢰도 평가

믿을 근거는 세 가지입니다. Wilson 신뢰구간과 McNemar 검정을 함께 보고했고, 도구별 성공률 평균과 전체 성공률이 정확히 맞아떨어지는 등 표 사이 산술이 대체로 일관됩니다. LangGraph 연동 실패(10회 전부 "Agent error: 'id'")도 모델 능력과 분리해 "프레임워크 통합 결함"이라고 정직하게 표시했습니다.

감안할 점도 뚜렷합니다. 모든 프롬프트가 정답을 그대로 노출해 모호한 요청·방해 도구·상태 변화는 반영되지 않았고, 도구는 시뮬레이션만 됐을 뿐 실제로 호출되지 않았습니다. 샘플링은 프롬프트당 1회만 실행돼 재현성 확인이 안 됩니다. 검증 중 원문 자체의 산술 불일치도 하나 찾았습니다 — 4.4절은 "658건의 실패"를 보고하지만 Table 2의 성공 건수를 1,000에서 빼면 732건이 나와 74건 차이가 있습니다. 재계산 근거가 없어 이 실패 원인 분해(복구 실패 89.4% 등)는 본문에 인용하지 않았습니다.

관련 연구(학술 문헌 대조)

이번 문헌의 참고문헌 목록에 실린 서지사항을 근거로 정리했습니다. 세션 이그레스 차단으로 아래 세 문헌의 원문은 개별적으로 재확인하지 못했습니다.

• Liu et al.(2024). MobileLLM: Optimizing Sub-billion Parameter Language Models for On-Device Use Cases — 선행 연구(prior). 파라미터 수보다 아키텍처 설계가 온디바이스 성능을 좌우한다는 결론을 일반 언어 능력에서 보였고, 이번 논문은 0.5B Qwen이 1.4B급 Phi·Pythia·TinyLlama를 크게 앞서는 형태로 같은 패턴을 툴콜링 과제에서 재확인합니다.
• Erdogan et al.(2024). TinyAgent: Function Calling at the Edge — 방법 확장(extension)이자 대조. 과제 특화 파인튜닝·툴 검색·양자화를 결합해 온디바이스 함수 호출 신뢰도를 끌어올린 사례로, 이번 논문이 다룬 미세조정 없는 체크포인트의 저조한 성적(0~79%)이 SLM 자체의 근본 한계라기보다 훈련 부재의 결과일 수 있음을 시사합니다.
• Fan et al.(2025). MCPToolBench++ — 벤치마크 원전(benchmark-origin). 툴 탐색·다단계 실행·실제 호출 결과까지 포함하는 완전한 MCP 벤치마크의 요건을 정의한 논문으로, 이번 리뷰 대상은 정답이 노출된 단일 JSON 생성만 다룬다는 점에서 외부 타당도를 가늠할 기준선이 됩니다.

세 문헌 모두 "튜닝되지 않은 소형 모델은 근본적으로 무능하다기보다 아키텍처·훈련 방식이 성능을 가른다"는 이번 논문의 결론과 방향이 일치합니다.

리뷰어 판단

첫째, 가장 눈여겨봐야 할 숫자는 79%가 아니라 "1,000개 중 5개"라고 판단합니다. 복구 파서가 없으면 최고 성능 조건조차 기계가 그대로 소비할 JSON을 0.5%만 내놓는다는 뜻이며, 복구 계층이 선택적 편의 기능이 아니라 시스템의 핵심 구성 요소임을 보여줍니다.

둘째, Qwen2.5-0.5B는 샘플링이 성공률을 40%p 깎았지만 1.5B는 통계적으로 유의한 차이가 없었습니다. "온도 0.7이 대체로 안전한 기본값"이라는 통념이 체크포인트별로 정반대로 뒤집힐 수 있다는 뜻이므로, 모델·디코딩 조합마다 별도 회귀 테스트가 필요하다고 봅니다.

셋째, Qwen2.5-1.5B greedy가 날씨 도구에서만 정확히 0%를 기록한 것은, 집계 성공률 하나만 보고 배포를 결정하면 이런 결정론적 실패 범주를 놓칠 수 있다는 근거라고 판단합니다.

넷째, §4.4의 실패 건수 합계가 Table 2에서 역산되는 값과 74건 어긋난다는 점은 이 논문의 다른 표들이 대체로 맞아떨어지는 것과 대조적입니다. 재현·재계산 이전에는 이 분해표를 인용하지 않는 편이 안전하다고 봅니다.

실무 적용

• 복구 계층을 시스템 컴포넌트로 승격 — 마크다운 펜스 제거·중괄호 추출·재시도를 코드에 명시하고, 복구 전/후 파싱 성공률을 각각 배포 지표로 측정합니다.
• 모델·디코딩 조합별 개별 검증 — 온도 0.7을 공통 기본값으로 쓰지 말고, 체크포인트마다 greedy·샘플링을 나눠 회귀 테스트합니다.
• 도구별 성공률 분해 — 집계 성공률만 보지 말고 도구·인자 유형별 성공률을 대시보드에 따로 올려 결정론적 실패 범주를 조기에 찾습니다.
• 미세조정·제약 디코딩 병행 검토 — 미세조정 없는 체크포인트의 성능을 하한선으로 보고, TinyAgent류 특화 파인튜닝이나 스키마 강제 디코딩 도입을 검토합니다.
• 승인 없는 실행 금지 — 도구를 실제로 호출하지 않은 벤치마크이므로, 소형 모델이 만든 호출은 스키마 검증·권한 검사·중요 작업 확인을 통과한 뒤에만 실행합니다.

결론

이 연구의 기여는 "20억 미만 모델도 쓸 만하다"가 아니라, 신뢰도가 체크포인트·디코딩·복구 계층의 조합에 따라 0%에서 79%까지 요동친다는 것을 통제된 조건에서 정량화한 데 있습니다. 최고 조건조차 완전한 자율 실행을 정당화하기에는 실패율이 높고, 복구 없는 엄격 JSON 비율은 1% 미만입니다. 동료심사 이전 단계이고 원문 자체에 재계산 안 되는 표가 하나 있다는 점을 감안하면, 이 수치는 방향 신호로 받아들이고 자체 파이프라인에서 재검증하는 것이 맞습니다. 로컬 배포 MCP 에이전트의 설정 기반 신뢰도 설계는 모델을 못 바꿀 때 설정을 바꾼다에서 이어집니다.

참고 링크

• Beyond Fluent Generation: A CPU Reliability Benchmark for MCP-Style Tool Calling — arXiv 초록(원문)
• 같은 논문 HTML 전문 — 표·수치 대조에 사용(스냅숏 경유)
• MobileLLM(Liu et al., 2024) — 관련 연구
• TinyAgent(Erdogan et al., 2024) — 관련 연구
• MCPToolBench++(Fan et al., 2025) — 관련 연구
• 모델을 못 바꿀 때 설정을 바꾼다 — sunny34.com 블로그