스마트폰 로컬 에이전트 모델을 평가한 방법

이 테스트는 모델 순위표를 만들기 위해 시작한 것이 아닙니다.

처음 마주한 문제는 훨씬 구체적이었습니다. 스마트폰의 로컬 에이전트에는 기본 라우팅 모델 하나가 필요합니다. 이 모델은 대화만 잘해서는 부족합니다. 짧은 시간 안에 사용자의 의도를 이해하고, 올바른 기능을 고르고, 실행 파라미터를 추출하고, 필수 정보가 부족하면 멈춰서 질문해야 합니다. 동시에 8K context를 사용해도 메모리와 발열이 현실적인 범위에 머물러야 합니다.

우리가 확인하려던 질문은 다음과 같습니다.

현재의 이중언어·구조화·온디바이스 에이전트 흐름에서, 합리적인 리소스 비용으로 라우팅과 실행 파라미터를 가장 안정적으로 만드는 모델은 무엇인가?

이 범위가 중요합니다. 일반 지능, 글쓰기, 수학, 지식 질의의 순위를 측정하는 것이 아닙니다. 하나의 제품 엔지니어링 선택에 답하는 테스트입니다.

에이전트가 실제로 하는 일을 먼저 나눈다

“내일 아침 7시에 깨워 줘”라는 요청을 실행하기 전, 에이전트는 적어도 두 단계의 판단을 거칩니다.

먼저 현재 사용할 수 있는 기능 중 올바른 Skill을 선택합니다. 알람, 캘린더, 메일, 메모리 등이 여기에 해당합니다. 그다음 Skill 안에서 Action을 선택하고, 이미 주어진 파라미터와 부족한 파라미터를 나누고, 실행할지 계획할지 사용자에게 다시 물을지 결정합니다.

flowchart LR
    A[사용자 요청] --> B[후보 Skill 검색]
    B --> C[Stage 1: Skill 선택]
    C --> D[Stage 2: Action과 파라미터]
    D --> E{정보가 충분한가}
    E -->|충분| F[실행 또는 계획]
    E -->|부족| G[구조화된 확인 질문]
    F --> H[Swift Runtime 검증]
    G --> H

그럴듯한 문장을 생성하게 한 뒤 느낌으로 점수를 매기지 않습니다. 평가기는 Skill, Action, Mode, known Slots, missing Slots, objectives가 들어 있는 명확한 구조를 요구합니다. 이후 Swift Runtime이 결과가 검색된 후보 범위에 있는지, 현재 Schema에 맞는지 결정적 규칙으로 검사합니다.

시스템 기능을 다루는 에이전트에게 “대략 이해했다”는 실행 보장이 아닙니다. 잘못된 Action을 고른 것과 필수 파라미터 하나를 빠뜨린 것은 서로 다른 실패이며, 둘 다 드러나야 합니다.

96개 사례의 구성

모델 비교에는 v3-96-staged-skill-action 데이터셋을 사용합니다.

core 사례는 알람 생성, 일정 확인, 이메일 초안처럼 흔한 표현을 다룹니다. challenge 사례에는 비슷한 Skill의 혼동, 필수 정보 누락, 여러 기능을 잇는 계획, 더 모호한 표현을 넣었습니다.

짧은 입력도 의도적으로 남겼습니다. 스마트폰에서 하는 요청은 몇 단어로 끝나는 경우가 많습니다. 시험 문제처럼 완전한 문장에서만 안정적인 모델은 실제 제품에서 큰 도움이 되지 않습니다.

각 사례에는 기대 Skill, Action, Mode와 관련 구조 제약이 저장됩니다. 공개 정확도의 분모는 항상 전체 96개입니다. Parse에 실패한 사례를 정확도 계산에서 빼지 않습니다.

96개 테스트 사례와 기대 결과

아래 기대 결과는 최종 자연어 답변이 아니라 모델이 Runtime에 전달해야 하는 라우팅 계약입니다. 각 사례에서 Skill, Action, Mode를 따로 확인합니다. 추가 조건은 missing Slots의 빈 값 여부 또는 계획 필요 여부를 뜻합니다.

세 가지 구체적인 채점 예시

• 정보가 완전한 요청：Set an alarm for 7 AM tomorrow.

builtin.alarm.manage → create_alarm, Mode는 act, missing_slots는 비어 있어야 합니다.

• 정보가 부족한 요청：Create an email draft for me.

builtin.mail.draft → create_draft, Mode는 clarify, missing_slots는 비어 있지 않아야 합니다. 메일 Schema에는 수신자, 제목, 본문이 필요합니다.

• 여러 단계 요청：First inspect tomorrow's calendar, then create reminders for unresolved items.

builtin.task.plan_recover → orchestrate, Mode는 act, requires_plan = true여야 합니다.

현재 v3의 한계도 표에서 확인할 수 있습니다. missing Slots는 비었는지 아닌지만 채점하며, 빠진 필드 이름을 모두 정확히 제시했는지는 개별 점수로 계산하지 않습니다. 정확한 Slot 이름과 값은 다음 계약 테스트에 추가할 예정입니다.

Core: 일반 사례 48개

Challenge: 경계 사례 48개

무엇을 평가하는가

강점이 실패를 가릴 수 있는 하나의 가중 총점은 사용하지 않습니다.

Parse가 높다고 의미가 정확한 것은 아닙니다. 완전히 유효한 JSON을 안정적으로 만들면서 Skill을 계속 잘못 선택할 수도 있습니다. 반대로 요청은 이해한 것처럼 보여도 출력 형식이 흔들려 Runtime이 사용할 수 없는 경우도 있습니다.

실행 라우터로 쓸 때는 Skill, Action, Mode, missing-slot 동작이 가장 중요합니다. Skill은 강하지만 Action이 약한 모델은 1단계 후보 축소에는 쓸 수 있어도 실행 파라미터를 직접 만들 권한을 주면 안 됩니다.

공정하다는 것은 모든 모델에 같은 문자열을 넣는다는 뜻이 아니다

10개 모델 모두 GGUF Q4_K_M, 동일한 evaluator, 데이터셋, 4K/8K 설정, 고정 디코딩을 사용합니다.

temperature = 0
top_p = 1
top_k = 1
seed = 42
candidate_limit = 3

하지만 모든 모델에 동일한 ChatML 문자열을 억지로 넣지는 않습니다. Llama 3는 자체 header tokens를 사용하고, SmolLM3는 extended thinking을 명시적으로 끄며, LFM2.5는 필수 start-of-text token을 받습니다. 작업, 정보, 출력 계약은 같게 두고 바깥 템플릿만 모델의 기본 형식에 맞춥니다.

우리에게 공정한 비교란 작업과 규칙을 같게 유지하면서, 잘못된 입력 형식으로 특정 모델을 의도적으로 불리하게 만들지 않는 것입니다.

각 가중치에는 제공자, 저장소, commit, 파일명, 바이트 수, SHA-256, 라이선스, Prompt Profile도 기록합니다. 모델 이름만으로는 결과를 재현할 수 없습니다. 같은 이름이라도 변환이나 양자화 파일이 다르면 동작이 달라질 수 있습니다.

능력 평가와 실제 기기 측정을 나눈 이유

이 부분이 가장 오해받기 쉽습니다.

96개 능력 사례는 동일한 모델 파일을 데스크톱 Metal evaluator에서 실행합니다. 많은 사례를 실행하고, 모든 Raw Output을 저장하고, 안정적인 조건에서 다시 비교하기에 적합하기 때문입니다.

리소스 측정은 A17 Pro와 8 GB 물리 메모리를 탑재한 iPhone 15 Pro Max에서 SwiftLlama와 llama.cpp b8668로 실행했습니다. 모든 모델을 4K와 8K에서 각각 3회 독립 실행해 총 60회를 측정했습니다.

기기에서 기록한 항목은 다음과 같습니다.

• 모델 로드 시간
• 짧은 Prompt의 TTFT
• 프로세스 메모리
• Metal 메모리
• 열 상태
• 기본 생성 완료 여부

flowchart TB
    A[모델 파일과 SHA-256 고정] --> B1[데스크톱 Metal 능력 평가]
    A --> B2[iPhone 실제 기기 리소스 평가]
    B1 --> C1[96개 이중언어 요청]
    C1 --> D1[Parse Skill Action Mode]
    B2 --> C2[4K와 8K 각각 3회 실행]
    C2 --> D2[Load TTFT Memory Thermal]
    D1 --> E[모델 선택]
    D2 --> E

두 종류의 근거를 섞지 않습니다. 데스크톱의 능력 정확도는 iPhone의 엔드투엔드 작업 성공률이 아닙니다. iPhone에서 로드에 성공했다고 96개 요청을 이해했다는 뜻도 아닙니다.

4K와 8K에서 실제로 측정한 것

이번 기기 테스트의 Prompt와 생성은 의도적으로 짧습니다. 4K/8K 측정은 세 가지 질문에 답합니다.

1. 대상 기기에서 해당 context 설정으로 모델을 로드할 수 있는가.
2. context를 늘릴 때 추가 메모리가 얼마나 필요한가.
3. 짧은 요청에서 시작 시간, 첫 token, 열 상태가 허용 가능한가.

8K token을 채운 뒤에도 속도가 같다는 사실을 증명하지 않으며, 긴 Prompt의 prefill 처리량도 측정하지 않았습니다. 이를 확인하려면 실제 3.5K/7.5K token을 넣고 prefill, 생성 속도, 에너지 사용량, 지속 열 곡선을 기록해야 합니다.

이번 8K는 용량과 리소스 테스트이지 “8K 긴 문맥 능력 인증”이 아닙니다.

한 번의 결과를 근거로 남기는 방법

각 능력 평가에서는 최종 백분율뿐 아니라 모델의 Raw Output과 SHA-256을 저장합니다. 집계 JSON에는 다음이 포함됩니다.

• 데이터셋 버전과 digest
• 모델 파일 SHA-256
• Prompt 설정 SHA-256
• Prompt Profile
• context 크기와 후보 수
• 사례별 기대값, 실제값, 각 판정
• TTFT, E2E 지연, token 수
• 형식 복구 사용 여부

기기 측에는 각 독립 실행의 Raw Text, CSV 요약, 모델별 체크섬을 남깁니다. 전체 근거 디렉터리에도 별도의 SHA256SUMS.txt가 있습니다.

이 과정이 모든 사람의 실수를 없애 주지는 않습니다. 하지만 어떤 파일을 어떤 설정으로 테스트했고, 표의 백분율이 어떤 원본 사례에서 계산됐는지는 나중에 확인할 수 있습니다.

이 결과로 증명하지 않는 것

현재 근거는 이 온디바이스 에이전트의 라우터를 선택하는 데 사용할 수 있습니다. 다음 주장에는 직접 사용할 수 없습니다.

• 특정 모델의 일반 지능이 더 높다
• 모든 언어와 Tool 영역에서 더 우수하다
• 긴 8K prefill 성능을 검증했다
• 실제 알람, 캘린더, 메일 작업의 성공률이 특정 수치에 도달했다
• 학술적 또는 업계 전체 순위다

현재 96개 중 48개 core 사례는 개발 피드백에 사용됐기 때문에 완전히 독립된 최종 holdout이 아닙니다. clarification과 planning 같은 중요한 구간의 사례 수도 아직 적습니다. 기기 구성당 실행도 3회뿐이며, 모델 순서 무작위화, 동일한 냉각 조건, 배터리 측정, 20턴 연속 세션은 아직 하지 않았습니다.

이 한계는 글 끝에 형식적으로 붙인 문장이 아니라 결과의 일부입니다.

다음 버전에서 보강할 것

다음 버전은 더 엄격한 기준을 목표로 합니다.

1. tuning과 분리된 300개 이상의 독립 holdout을 구축합니다.
2. 각 사례를 작성자가 아닌 두 사람이 버전이 지정된 Rubric으로 검토합니다.
3. 사례당 최소 3 Trial을 실행하고 안정 통과, 변동 사례, 95% Wilson 하한을 보고합니다.
4. 실제 3.5K/7.5K prefill, 연속 세션, 에너지, 열 곡선, Jetsam 복구를 측정합니다.
5. 격리된 Tool fixture에서 파라미터, 호출 순서, 승인, 확인 질문, 최종 환경 상태를 검증합니다.
6. 마지막으로 소수의 고위험 경로를 실제 기기 시스템 기능으로 엔드투엔드 확인합니다.

300개 tuning/holdout 초안과 평가 Harness는 이미 있지만, 독립적인 2인 검토가 끝나지 않았습니다. 따라서 아직 공식 결과로 제시하지 않습니다.

처음의 질문으로 돌아가면

이 방법은 “세계에서 가장 똑똑한 소형 모델”을 찾지 않습니다. 정의된 기기, Runtime, 에이전트 계약 안에서 현재 흐름에 가장 적합한 기본 모델을 고르고, 왜 이겼는지, 어디서 실패하는지, 근거의 경계가 어디인지 확인할 수 있게 합니다.

10개 모델 결과와 iPhone 4K/8K 리소스, 모델별 판단은 iPhone에서 소형 언어 모델 10종 비교에서 확인할 수 있습니다.