🤏 smolmaxxing
<p align="center"><img src="https://raw.githubusercontent.com/hyperionaidev/smolmaxxing/HEAD/assets/banner.png" alt="🤏 smolmaxxing: run the biggest model you can on the smallest hardware you own" width="100%"></p>
주변의 모든 장치는 보이는 것보다 더 많은 능력을 가지고 있습니다. TV 박스, 오래된 휴대폰, 싱글 보드 컴퓨터 및 라우터 등은 대부분의 시간 동안 유휴 상태로 있는 CPU, RAM, 플래시 메모리를 탑재하고 있습니다. smolmaxxing은 바로 그 잠재력을 해제하는 것에 관한 것입니다. 즉, 각 장치가 실제로 구동할 수 있는 가장 큰 언어 모델(LLM)을 찾아내고, 커스텀 커널(custom kernels), 더 스마트한 메모리 사용, 가중치 스트리밍(weight streaming) 등을 통해 이를 더욱 밀어붙이는 것입니다. 모든 주장은 해당 하드웨어 자체에서 측정되었습니다.
장치 #1은 Xiaomi TV Box S (3세대)입니다: Amlogic S7D, 4× Cortex-A55 @ 2.5 GHz, RAM 1.9 GB (사용 가능 약 1 GB), eMMC 플래시, Android 14, 루트 권한 없음. 이 장치에서 본 저장소는 260 K개부터 16 B개의 파라미터를 가진 모델을 구동합니다:
- Qwen3.5-0.8B: 16.8 tok/s (기존 7.5 대비 2.2배 증가; 11월 5일 저녁에 측정됨, §17 참조).
- 실시간 채팅에서 Qwen3.5-2B: 7.7 tok/s. 박스의 속도는 하루 동안 약 10% 정도 변동하므로 모든 단계는 연속적으로 측정되었습니다: §16에서는 +11%, §17에서는 또 다른 +7%가 기록되었습니다.
- 온디맨드 플래시 페이지 및 한 레이어 앞선 사전 로딩(prefetching)을 사용하는 8B 혼합 전문가 모델(mixture-of-experts, MoE) (Moon-Beam-8B-A1B): 실시간 채팅에서 7.2 tok/s를 기록했습니다 (§19).
- '헤드리스' 모드와 조회 테이블 커널(lookup-table kernel)을 사용하여 구동되는 밀집형 1비트 8B 모델 (Bonsai-8B): 실시간 채팅에서 5.2 tok/s로, 기존 1.2 대비 증가했습니다 (§19).
- 동일한 전문가 페이지기(expert pager)를 적용하여 변경 없이 사용한 16B 혼합 전문가 모델 (Ling-mini-2.0): 실시간 채팅에서 5.1 tok/s를 기록했으며, 600단어 분량의 답변에서도 일관성을 유지했습니다 (§20). Moon-Beam보다 두 배 크지만 바이트당 성능은 더 좋지 않습니다. 이 박스에서는 모델 자체가 더 좋을 때만 더 큰 용량이 도움이 됩니다.
- 밀집형 9B 모델: 플래시에서 가중치의 대부분을 스트리밍하며 0.27 tok/s를 기록했습니다.
장치 #2는 1세대 iPad Air (2013)입니다: Apple A7, 코어 2개, dotprod 없는 NEON, 1GB RAM, iOS 12.5.7, 탈옥(jailbroken), CPU 전용. 13년 된 태블릿이 1.7B 매개변수 모델을 초당 24~26 토큰(긴 채팅에서는 18~22)으로 구동하며, 4B 모델은 약 10 토큰/초, 전문가 혼합(MoE) 8B 모델은 약 3.5 토큰/초 (자신의 전문가를 절반만 사용하고 품질 비용을 감수할 경우 5 토큰/초), 그리고 16B 모델은 초당 2.6~4.5 토큰으로 구동합니다. 이 과정에서 전문가는 플래시 메모리에서 페이지 방식으로 불러와, 자체 Safari의 채팅 페이지에서 실행됩니다. 장치 #2에서의 결과를 참조하십시오.
모든 단계는 **EXPERIMENT.md**에 실험별로 기록되어 있습니다 (E1-E160).
<p align="center"><img src="https://raw.githubusercontent.com/hyperionaidev/smolmaxxing/HEAD/screenshots/llmui_05_stream.png" width="720" alt="TV 박스에서 llama-server가 제공하는 실시간 토큰 스트림 페이지"></p>
장치 (Devices)
| Device | Status |
|---|
| Xiaomi TV Box S (3rd Gen): Amlogic S7D, Cortex-A55, 2 GB | ✅ done: 260K → 16B 매개변수, 8B 모델은 5-7 토큰/초, 16B 모델은 5 토큰/초 |
| ... | |
The techniques aren't tied to one box. The 1-bit lookup-table kernel needs only base NEON, as the iPad shows; any ARM chip with dotprod gets the other kernels; and any Linux or Android device with more model than RAM can use the streaming engine.
<p align="center"><img src="https://raw.githubusercontent.com/hyperionaidev/smolmaxxing/HEAD/assets/devices.svg" width="760" alt="두 1GB 장치에서의 크기별 최고 세대 속도: 2B 클래스 TV 7.7 (Qwen3.5-2B) 대 iPad 23.7 (Bonsai-1.7B, 1비트); 4B 4.3 대 9.4; 8B 밀집(dense) 5.2 대 0.08; 8B MoE 7.2 대 3.5; 16B MoE 5.1 대 4.5 (동일한 캐시 편향 기준)"></p>
점수판 (Scoreboard)
<p align="center"><img src="https://raw.githubusercontent.com/hyperionaidev/smolmaxxing/HEAD/assets/scoreboard.svg" width="760" alt="클래스별 최고 모델, TV 박스 최초 실행부터 현재까지: 0.8B 7.5에서 16.8 tok/s, 2B 0.1에서 7.7, 4B 2.2에서 4.3, 8B dense 1.21에서 5.2, 8B MoE 1.87에서 7.2, 9B 0.16에서 0.27, 16B MoE 4.1에서 5.1; 그리고 Moon-Beam 토큰 하나가 소요하는 시간은 144ms입니다."></p>
| 클래스 | 최고 모델 | 최초 실행 → 현재 (토큰/초) | 향상률 | 비트/바이트 | 구현 방식 | 다운로드 |
|---|
| 0.8B | Qwen3.5-0.8B | 7.5 → 16.8 bench | ×2.2 | ≈1.00 | all-Q4_K, padded 65K head, fp16 DeltaNet state | HF |
| ... | | | | | | |
"최초 실행(First run)"은 각 모델이 해당 박스에서 처음 실행된 시점을 의미합니다:
- 0.8B: 기본 Q4_K_M 파일입니다.
- 2B: RAM에 맞지 않아 플래시 메모리에서 스트리밍된 기본 파일입니다. 최초로 적합하게 빌드되었을 때 4.8이었으므로, 이후 향상률은 ×1.6입니다.
- 4B: 충돌(thrashed)했던 기본 파일입니다.
- 8B dense: 플래시 메모리에서 스트리밍된 마지막 0.1 GB 데이터입니다.
- 8B MoE: 라우팅 편향 없이 실행된 첫 번째 expert-pager 실행입니다.
- 9B: 스트리밍되었습니다.
- 16B: Moon-Beam 레시피로 시작했기 때문에 향상률이 작습니다.
이 장치에서는 2B 모델이 최고의 속도-품질 균형을 보여줍니다. Ling-mini-2.0은 크기가 클수록 무조건 좋은 것은 아님을 보여주는데, 이는 Moon-Beam보다 두 배의 크기이지만 바이트당 점수는 낮고 실행 속도는 더 느립니다.
우리가 구축한 내용: 공격하는 병목 현상별 그룹화 (자세한 내용은 여기에 참조):
| 병목 현상 | 혁신 사항 | 가장 큰 성과 |
|---|
| 계산(Compute) (순차적 A55, 10개 항목) | vdotq_laneq를 위한 Q2_K 및 삼진법 재패킹(ternary repacks), 1비트 비트 평면(bit planes), 1비트 조회 테이블 커널(lookup-table kernel), 2비트 필드 내의 삼진법, 스킵 임계값(skip threshold)을 가진 Q8_0 어텐션, 통합된 Gated-DeltaNet, id/fp16으로 읽는 DeltaNet 상태, 빠른 커널에서의 LM 헤드, 가이드 매트멀 스케줄링 | Q2_K 7.8 → 13.9 G weights/s; Bonsai-8B 3.77 → 5.1-5.4; 4B 3.2 → 4.3; 긴 답변이 더 이상 속도를 절반으로 줄이지 않음 |
| ... | | |
장치 #1의 결과
품질은 고정된 22 KB의 영어 perplexity를 bits per byte로 변환하여 다양한 토크나이저를 가진 모델들이 공정하게 비교할 수 있도록 합니다 (낮을수록 좋음). 속도는 TV에서의 생성(generation)으로, 실제 채팅 요청("chat")을 사용하는 llama-server 또는 llama-bench("bench")를 통해 측정됩니다.
| Model | Size on the box | Quality (bits/byte) | Generation | Prompt | Notes |
|---|
| stories260K (llama2.c) | 1 MB | n/a | ~650 tok/s | n/a | 첫 번째로 실행된 것 (§1-8) |
| ... | | | | | |
- 가지치기된 헤드 위치(pruned head's positions)에서 측정되었으므로(토큰의 1.3%가 이 바깥에 떨어짐) 정확히 비교할 수 없으며, 기본 전체 어휘 사전에 대한 Q4_0 파일 점수는 1.024입니다.
기타 소형 모델, 기본 파일 (스크리닝, §15 E54):
| Model | Generation (bench) | Prompt | Bits/byte |
|---|
| LFM2.5-350M (QAD Q4_0) | 23.7 tok/s | 104 tok/s | 1.805 |
| ... | | | |
| Granite 4.0 H 1B는 2B의 품질에 근접한 모델이었습니다. 우리가 재구축한 방식(E62)으로 실행했을 때, 약간 낮은 품질에서 5.29 tok/s로 작동하며, 이는 2B의 6.55보다 낮습니다. 이 모델은 토큰당 0.8B보다 약 두 배 많은 가중치 바이트를 가지고 있습니다. | | | |
장치의 물리적 한계: 안드로이드가 프로세스를 종료하기 전에 하나의 프로세스는 약 0.96 GB를 유지할 수 있으며(런처와 Google 서비스를 강제 중지한 헤드리스 모드에서는 약 1.15 GB), 플래시 읽기 속도는 278 MB/s로 최고치를 기록하며, 단일 ~1 MB 랜덤 읽기는 약 6 ms가 소요됩니다. 토큰당 X MB를 스트리밍해야 하는 모델은 결코 초당 278 / X 토큰을 능가할 수 없습니다. CPU가 아니라 이것이 2B 이상의 모든 것을 제한하는 요인이며, 따라서 토큰당 8B 가중치 중 약 1B에 접근하는 mixture-of-experts (MoE) 모델이 이를 극복하는 방법입니다.
8B에서 10 tok/s? 추측이 아닌 측정치입니다 (E98): Moon-Beam은 토큰당 2개의 전문가를 사용하여 10.4 tok/s에 도달하지만, 텍스트가 의미 없는 문장으로 변합니다. 가장 일관성 있는 설정은 약 7~8 tok/s입니다. Dense Qwen3-8B는 Bonsai-8B (1 bit)이며, 가장 작은 Qwen MoE (35B-A3B)는 토큰당 Moon-Beam의 가중치보다 3배 많은 양에 접근합니다.
장치 #2에서의 결과
2013년형 iPad Air:
Apple A7, 2코어, dotprod가 없는 NEON 지원, RAM 1 GB, iOS 12.5.7이며 Amethyst로 탈옥(jailbroken)된 장치입니다. 모든 것은 CPU의 2개 스레드를 사용하며 1,024 토큰 컨텍스트에서 구동됩니다. 이 내용은 EXPERIMENT.md의 §21에 기술되어 있으며, 빌드 단계는 ipad-air/README.md를 참고하십시오.
| 모델 | 파일 | 생성 속도 (tok/s) | 최대 RSS | 고정된 3가지 질문 테스트 |
|---|
| Bonsai-1.7B Q1_0 (1비트) | 237 MiB | 23.7-25.8, 긴 채팅 시 18-22 사이 유지 | 605 MB | 세 문제 모두 정답이며, 사용할 올바른 코드를 작성함 |
| ... | | | | |
최신 빌드에서 측정된 것은 Bonsai와 Moon-Beam 행뿐입니다. 다른 행들은 아래의 어텐션(attention) 및 샘플러(sampler) 작업보다 앞선 결과입니다.
<p align="center"><img src="https://raw.githubusercontent.com/hyperionaidev/smolmaxxing/HEAD/assets/scoreboard-ipad.svg" width="760" alt="iPad Air에서 크기별 최적 모델 (첫 실행부터 현재까지): 1.7B는 2.75에서 23.7-25.8 tok/s로 증가; 4B는 9.4-11.4; 8B 밀집(dense)은 0.08; 8B MoE는 기본 llama.cpp로는 로드 불가, 이후 1.6에서 3.5 (4개 전문가 사용 시 5.0); 16B MoE는 로드 불가, 현재 2.6 (편향(bias) 0.3 사용 시 4.5); 그리고 Moon-Beam 토큰 하나가 약 0.3초 걸리는 속도"></p>
| 클래스 | 최적 모델 | 첫 실행 → 현재 (tok/s) | 향상률 | 달성한 기술 |
|---|
| 1.7B | Bonsai-1.7B (1비트) | 2.75 → 23.7-25.8 | ×8.6 | dotprod가 없는 곱셈 불필요 및 조회 테이블(lookup-table) 기반의 1비트 커널, fast kernel상의 LM head, 가지치기(pruning)를 적용한 행 순서 어텐션, 단일 패스 샘플러 |
| ... | | | | |
"로드 불가": iOS 12는 프로세스가 최대 약 1.7 GB만 매핑할 수 있게 하므로, 토큰을 실행하기 전에 기본 llama.cpp로는 2.6 및 5.5 GB 파일에서 실패합니다. Moon-Beam의 "첫 실행"은 첫 전문가 페이지러(expert-pager) 실행 (풀 8개, 편향 없음)입니다.
iPad에서 구축한 내용: 해결하는 병목 현상별로 그룹화했습니다.
| 병목 현상 (Bottleneck) | 혁신 기술 (Innovations) | 가장 큰 성과 (Biggest wins) |
|---|
| 연산 능력 (Compute) (2-core A7, dotprod 없음, 6개 항목) | 곱셈이 없는 1비트 커널(multiplication-free 1-bit kernel), TV의 1비트 조회 테이블 커널을 기본 NEON에 포팅한 것, 연결된 LM 헤드의 조회 테이블 복사본, 가지치기(pruning)를 적용한 행 순서 어텐션 (K 헤드당 2개 또는 4개 Q 헤드), 40개 항목 히프를 사용한 원패스 샘플러(one-pass sampler), 전문가용 Q2_K 조회 테이블 커널 | Bonsai-1.7B: 2.75 → 3.45 → ~11 → 23.7-25.8 tok/s 달성; 샘플링 3 → 토큰당 0.23 ms; Moon-Beam: Q2_K 커널만으로 2.94 → 3.06 달성 |
| ... | | |
| Bonsai-1.7B가 2.75에서 약 25 tok/s까지 도달한 방법 (전 과정 동일 모델 파일 사용): | | |
| 단계 (Step) | 토큰/초 (tok/s) | 변경된 내용 (What changed) |
|---|
| Stock llama.cpp, 2 스레드 | 2.75 | widening multiplies를 사용하여 dotprod 에뮬레이션 |
| ... | | |
긴 대화(400 토큰 답변)에서 세 번의 응답은 어텐션 작업만으로 15.4 / 7.6 / 8.2 tok/s에서 21.8 / 17.9 / 18.4 tok/s로 향상되었습니다. 긴 대화를 17 tok/s 이상 유지하는 가지치기 임계값은 컨텍스트 길이 1,024 토큰에서 +0.42%의 퍼플렉서티(perplexity)를 소모하며, 이는 ±0.3% 노이즈 플로어에 가깝습니다. GGML_FA_EPS=0.0001을 사용하면 이 손실분을 되돌려 약 15 tok/s를 얻을 수 있습니다. | | |
전문가 페이저(expert pager)를 통해 8B 모델을 구동합니다. iOS 12는 프로세스의 매핑된 주소 공간을 약 1.7 GB로 제한하며 (웹 서버 사용자의 경우 1.3 GB), 따라서 Moon-Beam-8B의 2.6 GB 파일은 아예 매핑할 수 없습니다. 전문가 수를 줄여서 맞추면 퍼플렉시티(perplexity)가 두 배 이상 증가합니다 (§21.7). Dense Bonsai-8B는 플래시에서 0.08 tok/s로 작동합니다. 따라서 모델 파일은 전문가들을 마지막에 배치하도록 재작성되었고, 그 앞의 474 MB만 매핑되며, 각 레이어는 14개의 전문가를 RAM에 유지하고 라우터가 선택할 때 pread를 사용하여 나머지 전문가들을 플래시에서 읽습니다. 결과는 페이징되지 않은 모델과 정확히 일치합니다. RAM에 이미 존재하는 전문가 쪽으로 약간의 라우팅 편향(routing bias)을 주었더니 (+0.3 % 퍼플렉시티, 노이즈 범위 내), 약 600 MB에서 2.4-2.8 tok/s로 향상되었습니다 (§21.8). 라운드 2 (§21.9)는 플래시 읽기를 필요할 때 순서대로 대기열화(queue)하고, 다음 레이어의 예상 전문가들을 미리 가져오며(prefetch), Q2_K에 대해 전문가들을 조회 테이블 커널(lookup-table kernel)로 실행합니다: 3.4 tok/s, Dense 8B 대비 40배, 전체 평가 텍스트에서 +0.7 % 퍼플렉시티. 플래시가 여전히 한계입니다: 토큰당 약 53 MB를 266 MB/s로 읽습니다. RAM 커널에 가중치(weights)를 연결하는 것은 이전에 16개 풀을 사용했을 때처럼 iPad를 불안하게 만들었습니다. 라운드 3 (§21.10)은 최신성(recency) 대신 감쇠된 사용 빈도(decayed use frequency)로 제거하며, 품질 저하 없이 3.5 tok/s를 달성했습니다. 5 tok/s는 토큰당 8개 전문가 대신 4개의 전문가가 필요했고 (+27 % 퍼플렉시티), 토큰당 개수를 적응적으로 선택하는 것은 고정된 개수보다 나은 결과를 가져오지 않았습니다. 16B 모델 (§21.11): Ling-mini-2.0은 16.3B 파라미터에 레이어당 256개의 작은 전문가를 가지고 있으며, 동일한 페이저로 라우팅 변경 없이 2.6 tok/s, +2.6 % 퍼플렉시티에서 3.3 tok/s, 강력한 캐시 편향(strong cache bias)을 적용하여 4.5 tok/s로 구동되며, 그 크기는 580 MB 미만입니다. 이 모델의 5.5 GB 파일은 HTTP 범위 요청(HTTP range requests)을 통해 발표된 두 가지 양자화(quantizations)로 조립되었으며, Mac에는 공간이 없었기 때문에 iPad로 직접 스트리밍되었습니다. 속도는 Moon-Beam과 같지만 크기는 두 배이며, 모델 자체는 더 좋지 않습니다 (+3 % 퍼플렉시티).
<p align="center"><img src="https://raw.githubusercontent.com/hyperionaidev/smolmaxxing/HEAD/assets/tradeoff-ipad.svg" width="760" alt="iPad에서 Moon-Beam-8B-A1B와 Ling-mini-2.0의 퍼플렉서티 비용 대비 속도: Moon-Beam은 추가 비용 없이 3.5 tok/s이며, 최대 5.0에서는 +27%입니다; Ling은 추가 비용 없이 2.6 tok/s이고, +2.6%에서 3.3 tok/s, +8.5%에서 4.5 tok/s, +17%에서 5.2 tok/s입니다."></p>