Qwen3.5-2B 선택 후 검증: iPhone에서 4K와 8K의 실제 비용

10개 모델 비교를 마친 뒤 실용적인 선택은 분명했습니다. Qwen3.5-2B Q4_K_M은 우리가 정한 리소스 기준과 구조화 에이전트 라우팅 기준을 모두 통과한 유일한 후보였습니다.

이 결과는 어떤 모델을 사용할지 답해 주었습니다. 하지만 그 모델의 context window를 어떻게 사용해야 하는지는 아직 답하지 못했습니다.

첫 iPhone 매트릭스에서 Qwen3.5-2B를 4K context에서 8K로 바꿨을 때 Metal 메모리는 52 MiB만 증가했습니다. 짧은 Prompt의 TTFT도 거의 변하지 않았습니다. 이 수치만 보면 8K는 거의 비용이 없다고 생각하기 쉽습니다.

실제로는 그렇지 않습니다. 8K context 용량을 예약하는 것과 실제로 8K에 가까운 tokens를 처리하는 것은 서로 다른 부하입니다. 모델을 선택한 뒤 같은 iPhone에서 두 비용을 분리해 측정하는 추가 테스트를 진행했습니다.

모델 선택 뒤에 추가 테스트가 필요했던 이유

기존 10개 모델 비교는 두 종류의 요구 사항을 평가했습니다.

이 결과를 바탕으로 Qwen3.5-2B를 스마트폰 로컬 에이전트 라우터의 기본 후보로 선택했습니다. 하지만 당시 4K/8K 기기 매트릭스는 85-token Prompt를 사용했습니다. 측정 대상은 로드, context 할당, 짧은 요청의 지연, 메모리, 기본 생성이지 context를 채웠을 때의 계산 비용이 아니었습니다.

추가 테스트는 더 좁은 프로덕션 질문에 답합니다.

선택한 모델에 거의 가득 찬 4K 또는 8K Prompt를 주면 prefill에 얼마나 걸리고, 생성 속도와 메모리, 열 상태는 어떻게 달라지는가?

테스트 구성

모델 파일과 추론 스택은 기존 비교와 동일합니다.

모델을 로드한 뒤 앱은 모델 자체 tokenizer로 system 및 chat wrapper를 포함한 전체 렌더링 Prompt를 정확한 token 수에 맞췄습니다.

• 4K context: Prompt 3,584 tokens
• 8K context: Prompt 7,680 tokens
• 두 조건 모두 출력용으로 512 tokens 확보
• 모든 실행에서 63 tokens 생성

단순한 순서 편향을 줄이기 위해 4K와 8K의 실행 순서를 번갈아 배치했습니다. Prefill과 생성 시간은 llama.cpp 네이티브 성능 카운터로 측정했습니다. TTFT는 Swift 추론 호출 경계부터 비어 있지 않은 첫 stream piece까지 별도로 측정했습니다.

flowchart LR
    A[선택한 모델 로드] --> B[모델 tokenizer로 전체 Prompt 조정]
    B --> C1[4K에서 3584-token Prompt]
    B --> C2[8K에서 7680-token Prompt]
    C1 --> D[Prefill 63 tokens 생성 메모리와 열 상태 기록]
    C2 --> D
    D --> E[용량 비용과 실제 사용 비용 비교]

측정된 4K와 8K 비용

표는 독립 실행 3회의 P50입니다. 적은 샘플 수를 하나의 숫자로 감추지 않도록 prefill min/P50/max도 함께 표시합니다.

개별 숫자보다 중요한 관찰은 세 가지입니다.

사용할 수 있는 용량을 여는 비용은 작다

짧은 Prompt 할당 테스트에서 8K는 4K보다 Metal 메모리를 52 MiB 더 사용했습니다. 이번 테스트에서도 생성 후 차이는 1821.4와 1769.4 MiB로 52 MiB였습니다. 모델 파일은 변하지 않고 8 GB iPhone에서도 현실적인 메모리 범위를 유지합니다.

이는 8K를 사용할 수 있게 하는 근거이지, 매번 채워야 한다는 근거는 아닙니다.

활성 context는 계산량과 대기 시간이 된다

7,680-token prefill P50은 30.583초로, 3,584-token의 13.375초보다 2.29배 길었습니다. Prefill throughput도 268.0에서 251.1 tokens/s로 낮아졌습니다.

반면 Decode는 19.9와 19.7 tokens/s로 거의 같았습니다. 긴 대기는 답변이 시작되기 전에 발생합니다. 생성이 시작된 뒤 token 출력 속도는 거의 변하지 않습니다.

따라서 짧은 Prompt TTFT 0.274초와 거의 가득 찬 8K TTFT 30.602초는 서로 모순되지 않습니다. 같은 context 상한에서 실제 활성 Prompt 길이가 다른 두 부하를 측정한 결과입니다.

더 엄격한 한계는 열이다

거의 가득 찬 두 조건 모두 열 압력을 만들었습니다. 3,584-token은 3회 중 2회가 Serious로 끝났고, 7,680-token은 3회 모두 Serious였습니다. 실행 사이에 30초를 냉각해도 이 결과를 피하지 못했습니다.

메모리만 보면 8K는 쉬워 보입니다. 지연과 열 상태를 함께 보면 context는 Runtime이 관리해야 하는 리소스이며, 텍스트를 무제한으로 붙이는 공간이 아니라는 점이 분명해집니다.

적용할 배포 정책

기기가 지원하는 하드 상한과 일반 작업에 사용하는 소프트 예산을 분리합니다.

1. 물리 메모리가 8 GB 이상인 기기에서 8K context 상한을 활성화합니다.
2. 일반 활성 Prompt는 2K-4K 수준으로 유지합니다.
3. 추론 전에 모델 tokenizer로 전체 렌더링 Prompt token 수를 계산합니다.
4. 소프트 예산을 넘으면 현재 지시와 관련 근거보다 오래된 대화 기록을 먼저 압축합니다.
5. 검색 문서와 Tool 출력은 전부 이어 붙이지 않고 재정렬하고 자릅니다.
6. 약 20-31초 prefill을 감수할 만큼 추가 근거가 중요한 작업에서만 8K 방향으로 확장합니다.
7. 출력과 복구 지시를 위해 최소 512 tokens를 남깁니다.

flowchart TD
    A[System 기록 근거 Tool 출력 구성] --> B[렌더링된 token 수 계산]
    B --> C{2K-4K 일반 예산 이내인가}
    C -->|Yes| D[일반 추론]
    C -->|No| E[기록 압축 및 근거 재정렬]
    E --> F{출력 공간을 남기고 8K 미만인가}
    F -->|Yes 지연을 감수할 가치가 있음| G[긴 context 추론]
    F -->|No| H[작업 분할 또는 범위 축소]

중요한 선택은 전역 설정을 영구적으로 4K 또는 8K로 고정하는 것이 아닙니다. 8K를 사용할 수 있게 하되 기본 활성 Prompt는 2K-4K로 유지하는 것입니다.

이렇게 하면 복잡한 작업은 로컬 문서, 검색 근거, Tool 결과를 담을 공간을 확보하면서도 일상적인 요청에는 30초의 첫 token 지연을 부과하지 않습니다.

이 테스트가 증명하지 않는 것

이번 측정은 token 수를 고정한 결정적 합성 계산 부하입니다. 선택한 모델이 목표 스마트폰에서 알려진 token 수를 처리하는 비용을 측정합니다. 다음 항목은 아직 증명하지 않습니다.

• 7.5K 자연 다중 문서의 의미 정확도
• 지속적인 작업 세션의 배터리 소모
• 20턴 연속 대화의 동작
• 완전한 열 회복 시간
• 여러 앱이 동시에 메모리를 사용할 때의 Jetsam 동작
• 더 적은 메모리의 기기에서 같은 성능이 나오는지 여부

각 조건의 샘플도 3개뿐입니다. 이 한계를 그대로 드러내기 위해 범위와 열 상태 횟수를 함께 공개했습니다.

이 항목들은 후속 테스트 대상이며 현재 데이터에서 추론해서는 안 됩니다.

최종 판단

상세 테스트가 모델 선택을 뒤집지는 않았습니다. Qwen3.5-2B Q4_K_M은 이번 비교에서 가장 강한 구조화 에이전트 결과와 8K에서 2 GiB 미만의 Metal 할당을 함께 제공하므로 기본 로컬 라우팅 모델로 유지합니다.

대신 배포 방법은 명확해졌습니다.

• 8K는 8 GB 기기에서 지원하는 상한입니다.
• 2K-4K는 일반 활성 Prompt의 목표 범위입니다.
• 거의 가득 찬 8K는 명시적인 느린 경로이며 기본 경로가 아닙니다.

예약된 용량과 실제 계산의 차이가 이번 추가 측정에서 가장 중요한 결과입니다. 스마트폰에서 context window는 메모리만의 문제가 아닙니다. 첫 token 지연, 열, 에너지, 그리고 실행 전에 모델이 처리해야 하는 불필요한 정보량에도 영향을 줍니다.

전체 평가 설계와 96개 에이전트 기대 라우팅은 스마트폰 로컬 에이전트 모델을 평가한 방법에서 확인할 수 있습니다.