폐폰에서도 같은 코어가 돕니다

재 본 기기 셋, 잴 기기 다섯

같은 스크립트 · 같은 서류 5건 · 같은 모델(MiniCPM5-2B)로 잰 값입니다. 재지 못한 기기는 「예정」으로 남겼습니다.

아직 안 잰 기기

실측표 — 같은 스크립트 · 같은 서류 5건 · 같은 모델 두 개

서류 5건은 임대차계약서(워드) · 통장내역(엑셀) · 급여대장(엑셀) · 근로계약서(워드) · 원천세신고서(한글)입니다. 라벨 셋(거래처 · 기간 · 서류 종류)을 맞힌 개수를 15점 만점으로 셉니다. 문서 한 건마다 KV 캐시를 새로 엽니다.

주황 숫자는 스레드를 코어 수(8)에 맞췄다가 시간이 무너진 회차입니다 — 이유는 다음 절에.

두 폰 다 MiniCPM5-2B가 Qwen2.5-1.5B보다 정확했습니다. Qwen이 빠르지만 라벨을 더 틀립니다 — 라벨링에서는 틀린 라벨이 느린 라벨보다 비쌉니다. 그래서 기본 모델은 MiniCPM5-2B입니다(둘 다 Apache-2.0).

Note 20 Ultra는 실측 내내 충전 상태가 아니어서 큰 코어가 최대 클럭의 57%로 묶여 있었습니다. 지금 값은 하한입니다 — 충전기를 꽂으면 오릅니다. 이 노트북의 llama.cpp는 배포판 디버그 빌드라 속도가 보수적으로 나온 값입니다.

설정 하나로 「1분 20초」와 「7분」이 갈립니다

같은 폰 · 같은 모델 · 같은 서류. 스레드 수 하나가 다릅니다.

10분 연속 구동 — 온도가 오르지 않았습니다

발열은 주장이 아니라 설정과 실측으로 말합니다. 파일 1건 = 세션 1회로 KV 캐시가 쌓이지 않게 하고, 스레드는 코어 수보다 적게, 문서 사이 3초를 쉬고, 프롬프트 배치를 128로 제한합니다. 이 설정으로 A34에서 10분 연속 라벨링을 돌렸습니다.

10분 동안 온도가 오르지 않았습니다 — 31.0 → 30.8°C. 건당 시간도 첫 건 91.8초, 마지막 건 91.7초로 평탄합니다(중간 변동은 서류 길이 차이입니다). 못 잰 것도 적어 둡니다: CPU 클럭 하락은 이 회차에서 직접 재지 못했고(도구 결함, 다음 회차 몫), 휴지 없는 대조는 실측 중이며, 더 빠른 8스레드 조건은 재지 않았습니다.

어떤 폐폰이면 되나

실측으로 확인한 것과 조사로 잡은 것을 나눠 적습니다.

폰에 올리는 법

Termux(F-Droid 판 — 플레이스토어 판은 낡아서 안 됩니다)에서 합니다. 모델 파일은 약 1.7GB라 와이파이에서 받습니다.

# 한 번만
pkg update -y && pkg install -y llama-cpp curl python termux-api
termux-wake-lock                       # 화면이 꺼져도 안 멈추게. 충전기를 꽂는다

# 빅코어가 몇 개, 몇 번인지 본다 (최대 클럭이 가장 높은 묶음이 빅코어)
for c in /sys/devices/system/cpu/cpu[0-9]*; do
  echo "$(basename $c) $(($(cat $c/cpufreq/cpuinfo_max_freq 2>/dev/null || echo 0)/1000))MHz"; done

# 모델 서버 — 빅코어 4개(cpu4~7)에 4스레드를 고정하는 예. A34처럼 빅코어가 2개면 "6,7" 에 2스레드
taskset -c 4-7 llama-server -m MiniCPM5-2B-Q4_K_M.gguf --host 127.0.0.1 --port 8097 \
  -c 2048 -ub 128 -t 4 --no-warmup

스레드 수를 코어 개수보다 크게 주지 마세요 — 2코어에 4스레드를 몰아넣으면 생성이 무너집니다. 설치기는 이 판단을 자동으로 합니다. 실측 스크립트(같은 서류 5건 · 모델 두 개 · 온도 곡선)와 결과 원본은 공개 저장소 github.com/kingcheee/nabi-core의 bench 폴더에 있습니다.