구형 기기 로컬 LLM, 1GB TV 박스 5.1토큰

구형 기기 로컬 LLM을 실측으로 밀어붙인 프로젝트가 공개됐다. 깃허브의 smolmaxxing은 램 1GB 남짓인 TV 박스와 2013년형 아이패드에서 8B·16B 모델을 실제 채팅 속도로 돌린 기록을 실험 160개 분량으로 남겼다. 집에 굴러다니는 셋톱박스로 어디까지 되는지 궁금했다면 답이 나온 셈이다.

숫자의 의미는 크지 않은 모델을 느리게 돌렸다는 데 있지 않다. 램보다 큰 모델을 플래시에서 읽어 쓰는 구조와, 그때 속도를 정하는 것이 연산이 아니라 저장장치 대역폭이라는 점을 기기 위에서 확인했다는 데 있다. 노트북이나 미니PC에서 로컬 모델을 굴리는 사람에게도 같은 제약이 걸린다.

구형 기기 로컬 LLM, 1GB 램 TV 박스에서 16B가 5.1토큰

첫 번째 기기는 샤오미 TV 박스 S 3세대다. Amlogic S7D에 Cortex-A55 코어 4개, 램 1.9GB 가운데 실제로 쓸 수 있는 양은 1GB 안팎이고 운영체제는 안드로이드 14다. 루팅은 하지 않았고 ADB 셸 권한만 쓴다.

실제 채팅 요청 기준 속도는 이렇다. Qwen3.5-2B가 초당 7.7토큰으로 일상 사용 모델이고, 8B MoE인 Moon-Beam-8B-A1B가 7.2토큰, 16.3B MoE인 Ling-mini-2.0이 5.1토큰이다. 1비트 밀집 모델 Bonsai-8B는 5.2토큰, 삼진 가중치 4B 모델은 4.3토큰이다. 품질이 가장 좋았던 Qwen3.5-9B는 가중치를 대부분 스트리밍해야 해서 0.27토큰으로 사실상 못 쓴다.

속도를 정하는 것은 플래시 읽기 속도다. 측정된 순차 읽기 상한이 초당 278MB이고 1MB 남짓한 임의 읽기에 6ms쯤 걸린다. 토큰마다 X MB를 읽는 모델은 이론적으로도 초당 278 나누기 X 토큰을 넘을 수 없다. MoE가 유리한 이유가 여기 있다. 16B 모델이라도 토큰마다 쓰는 전문가가 일부라 읽는 양이 줄고, 램에 있는 전문가를 우선 고르거나 다음 층 것을 미리 읽으면 체감 속도가 올라간다.

2013년 아이패드, 1비트 1.7B로 24토큰

두 번째 기기는 2013년형 아이패드 에어 1세대다. Apple A7 2코어에 램 1GB, 실제 사용 가능한 양은 700MB 정도이고 iOS 12.5.7을 탈옥해 쓴다. 이 환경에서 Bonsai-1.7B가 초당 23.7~25.8토큰까지 나왔고, 최대 상주 메모리는 605MB였다. 긴 대화에서는 18~22토큰으로 내려간다.

4B 모델은 9.4~11.4토큰이지만 문맥 512토큰과 작은 배치가 필요하고 기억 회상 테스트에서는 답을 내지 못했다. 16B MoE는 2.6~4.5토큰, 8B 밀집 모델은 램에 들어가지 않아 0.08토큰이다. 큰 모델이 늘 나은 것도 아니다. 16B Ling-mini-2.0은 8B Moon-Beam보다 크기가 두 배인데, 바이트당 비트 수가 1.054로 Moon-Beam의 0.996보다 나쁘고(낮을수록 좋다) 속도도 느렸다.

1GB에 넣은 방법 — 커널과 전문가 페이징

구현은 llama.cpp 패치 하나로 묶여 있다. Cortex-A55용으로 2비트·삼진 가중치를 8행 단위로 재배치해 벡터 명령에 맞췄고, 그 결과 처리량이 초당 78억 가중치에서 139억 가중치로 올랐다. 1비트 가중치는 비트 평면과 룩업 테이블 커널로 처리한다. dotprod 명령이 없는 A7에는 같은 기법을 기본 NEON으로 옮겨 이식했다.

램 확보는 두 갈래다. 출력 헤드에서 잘 쓰지 않는 어휘 행을 잘라 모델당 0.2~0.5GB를 아끼고, TV 박스에서는 런처와 구글 서비스를 멈추는 헤드리스 모드로 가용 메모리를 1,000MB에서 1,300MB로 늘린다. 남은 것은 전문가 페이징이다. 라우터가 고른 전문가 중 램에 없는 것만 플래시에서 직접 읽고, 다음 층의 선택을 미리 예측해 미스의 60%가량을 미리 채운다.

모델 파일을 다시 만드는 스크립트도 함께 공개됐다. 공개된 GGUF에서 같은 파일을 재구성할 수 있고, 4B와 Bonsai-8B, 9B는 재구성 결과가 실험 기록과 바이트 단위로 같다고 확인했다. 저장소에 모델을 직접 담지 않고 재현 경로만 남긴 방식이다.

한계도 숨기지 않았다. 2비트 전문가를 쓰면 250~300단어를 넘길 때 출력이 무너지는데, 퍼플렉서티 지표로는 잡히지 않았다. 최근 256토큰에 반복 페널티 1.15를 걸자 퇴행성 장문 응답이 13개 중 12개에서 1개로 줄었다. 품질 지표가 좋아도 장문에서 무너지는 사례를 그대로 남긴 것이 이 기록의 값이다.

해커뉴스에서는

해커뉴스 댓글에서는 최신 에이전트라면 이런 작업을 프롬프트 한 번으로 끝낼 수 있다는 반응이 나왔다. 작성자의 답은 달랐다. 공개한 로그를 보면 어떤 모델을 어떻게 돌릴지 찾는 데 실험 107회에 50회가량이 더 필요했고, 이 작업을 무차별 탐색이 아니라 탐색 공간을 줄이는 문제로 봤다는 설명이다.

실용성에 대한 의문도 있었다. 작성자는 규제가 강한 조직의 오래된 구내 시스템에서 데이터 정제·정규화·분류에 쓸 만하고, 범위를 좁힌 작업은 1~2B 모델도 잘한다고 답했다. 반대로 팬케이크 만드는 법을 물으면 엉터리 답이 나온다는 댓글처럼 범용 비서로 쓰기에는 아직 이르다.

지금 사야 하나, 기다려야 하나

따라 하려고 새 장비를 살 이유는 없다. TV 박스 쪽은 루팅 없이 ADB로 돌아가지만 완성된 모델 파일이 패치된 llama.cpp를 요구하고, 아이패드는 iOS 12 탈옥이 전제다. 재부팅하면 탈옥이 풀리고, 램 700MB를 넘기면 iOS가 프로세스를 재시작한다. 주말 프로젝트로는 재미있지만 업무용 장비로 삼을 물건은 아니다.

다음 기기 계획도 적혀 있다. 휴대폰과 싱글보드 컴퓨터, 라우터가 후보이고, 1비트 커널은 기본 NEON만 있으면 되며 스트리밍 엔진은 램보다 모델이 큰 안드로이드·리눅스 기기면 어디든 붙일 수 있다고 설명한다.

따로 요구되는 하드웨어는 없다. CPU만으로 돌고, 크로스 컴파일 환경과 안 쓰는 기기, 모델 파일을 다시 만들 디스크 여유만 있으면 된다. 대신 결과는 기기 대역폭에 묶인다. 램이 큰 기기라고 이 수치가 그대로 나오지는 않는다. 상주시킬 수 있는 몫이 커지는 대신 모델과 실행 엔진을 그 기기에 맞춰 다시 잡아야 한다. 이 프로젝트도 한계를 정하는 것은 연산량이 아니라 메모리와 저장장치 대역폭이라고 정리한다.

1GB 기기에서 16B 모델이 5토큰으로 답한다. 속도를 정하는 것은 GPU가 아니라 플래시 읽기 속도다.