벤치마크: Orange Pi 5 Plus에서 로컬 LLM 구동하기 (RK3588, 16GB): Ollama Tok/s, NPU 오프로딩, 코어

공개 정보: 본 장치는 테스트를 위해 Orange Pi로부터 무상으로 제공받았습니다. 편집 검토, 사전 조건, 스크립트는 없습니다. 모든 데이터, 병목 현상 및 열적 동작은 하드웨어 테스트에서 직접 보고되었습니다. 요약하자면 (TL;DR): RK3588에서는 코어 고정(Core Pinning)이 매우 중요합니다. Ollama를 4개의 스레드(A76 Big 코어만 사용)로 설정하면, 느린 A55 Little 코어를 기다리느라 지연되는 기본 8개 스레드 대비 최대 +318%의 속도 향상을 얻을 수 있습니다. 추론 속도 (4T CPU): DeepSeek-Coder 1.3B는 16.9 tok/s, Qwen 2.5 1.5B는 14.5 tok/s, Llama 3.2 1B는 14.6 tok/s, Phi-3 Mini 3.8B는 6.6 tok/s, Llama 3.2 3B는 7.3 tok/s를 기록했습니다. 8B 메모리 벽: Llama 3.1 8B는 2.3 tok/s로 떨어지며 온도를 85°C까지 올립니다. LPDDR4x 대역폭(~25-30 GB/s 측정)이 물리적인 최대 한계입니다. NPU 대 CPU: Ollama는 CPU에서 100%를 사용합니다. 6 TOPS NPU에 네이티브 RKLLM 런타임을 사용하면, Qwen 1.5 0.5B 모델에서 21.55 tok/s를 달성하며 TTFT(Time To First Token)는 100ms 미만을 유지하고 CPU 부하를 약 0%로 유지할 수 있습니다. 열 관리: 이 보드는 표준 소매 포장재에 쿨러 없이 베어 다이(bare-die) 상태로 판매됩니다. 유휴 상태에서는 52.7°C이며, 1B-3B 추론 시에는 68-74°C를 유지하지만, 8B 또는 지속적인 워크로드는 액티브 히트싱크 없이 85°C의 스로틀링 한계에 도달합니다. 안녕하세요 r/LocalLLaMA 여러분, 저는 Orange Pi 5 Plus (RK3588, 16GB LPDDR4x, Samsung PM981a 256GB NVMe SSD with DRAM cache)를 사용하여 Ubuntu 22.04 LTS (Kernel 6.1.99-rockchip-rk3588)로 벤치마킹을 진행했습니다. 목표는 8코어 ARM SBC가 스스로 과열되거나 호스트 시스템이 멈추지 않으면서, 24/7 백그라운드 에이전트나 홈 자동화를 위해 작은 1B-3B 모델을 현실적으로 처리할 수 있는지 테스트하는 것이었습니다. 여기에는 CPU 대 NPU 성능, big.LITTLE 스케줄링 함정, 그리고 열적 한계에 대한 분석이 포함되어 있습니다. 1. 메모리 및 스토리지 아키텍처 SBC에서 로컬 모델을 구동할 때 가장 중요한 두 가지 병목 현상은 다음과 같습니다: 통합 메모리 용량 대 대역폭: 16GB의 통합 메모리를 사용하면 컨텍스트 창(context window)이 부족해지는 일이 없습니다. 양자화된 3B 또는 7B 모델을 8k-16k 컨텍스트 창으로 로드해도 Docker 및 OS 서비스에 충분한 RAM이 남아 있습니다.

하지만 RK3588은 쿼드 채널 32비트 LPDDR4x 버스(~이론상 34 GB/s, 측정값 ~25-30 GB/s)를 사용합니다. 자가회귀(autoregressive) CPU 토큰 생성에서 메모리 대역폭(memory bandwidth)이 주된 병목 지점입니다. 스토리지 인제스천 (Samsung PM981a NVMe): fio를 통한 직접 I/O 테스트 결과, M.2 PCIe 3.0 x4 슬롯은 순차 읽기에서 2,862 MB/s, 4K 랜덤 읽기에서 197k IOPS를 기록했습니다. 모델 가중치(Model weights)는 1초 이내에 시스템 RAM으로 로드됩니다 (1.3GB 모델이 ~0.6초 소요). 2. Ollama & llama.cpp 추론 벤치마크 (ARM64 CPU)

저희는 이기종 big.LITTLE 토폴로지(4x Cortex-A76 성능 코어 @ 2.26–2.4GHz + 4x Cortex-A55 효율 코어 @ 1.8GHz)를 대상으로 Ollama (네이티브 ARM64 빌드)를 테스트했습니다. 프롬프트: 기울기 하강법(gradient descent)과 역전파(backpropagation)에 대한 기술적 설명 (~200개 이상의 생성 토큰).

4,044.8 ms ~5.4 GB The big.LITTLE 스케줄링 함정 (+4개 스레드로 318% 속도 향상) RK3588에서 num_thread: 4가 필수인 이유: 기본적으로 Ollama는 모든 코어에 걸쳐 8개의 스레드를 생성합니다. 작은 캐시를 가진 4개의 Little Cortex-A55 코어가 1.8 GHz로 작동하기 때문에, llama.cpp의 스레드 배리어(thread barriers)는 심각한 동기화 지연을 유발합니다. 추론을 4개의 Big Cortex-A76 코어로 제한했을 때 다음과 같은 결과를 얻었습니다: Llama 3.2: 1B: 10.67 -> 14.62 tok/s (+37%) DeepSeek-Coder: 1.3B: 4.52 -> 16.90 tok/s (+274%, 프롬프트 속도 +221%) Qwen 2.5: 1.5B: 3.46 -> 14.48 tok/s (+318%) Llama 3.2: 3B: 1.99 -> 7.28 tok/s (+265%, TTFT가 4.2초에서 1.6초로 감소) Phi-3 Mini: 3.8B: 5.27 -> 6.56 tok/s (+24%) Llama 3.1: 8B: 2.10 -> 2.32 tok/s (+10%, TTFT가 1초 감소) 8B 모델의 한계: CPU에서 8B 모델을 실행하는 것은 근본적으로 메모리 대역폭에 의해 제한됩니다. 토큰 생성 단계당 약 5GB를 사용하므로, 이론적 최대치는 약 5 tok/s이며, 이는 2.32 tok/s가 실질적인 한계임을 의미합니다. 또한 냉각되지 않은 상태에서 온도를 85.0°C까지 올렸습니다. 3. CPU 대 하드웨어 NPU (6 TOPS, 3 코어) Ollama는 llama.cpp를 ARM NEON SIMD 명령어로 컴파일하고 100% CPU에서 실행합니다. Rockchip NPU는 사용하지 않습니다. 3코어 6 TOPS NPU를 테스트하기 위해, Rockchip의 librkllmrt.so 런타임 및 커널 드라이버(/dev/rknpu_mem)에 직접 연결된 네이티브 C++ 러너(tools/rkllm_bench_v1)를 컴파일했습니다.

지표 / 차원 | Ollama CPU 추론 (ARM NEON) | Rockchip NPU 하드웨어 (RKLLM Runtime)
---|---|
Compute Engine | 4x Cortex-A76 @ 2.4GHz + 4x A55 @ 1.8GHz | 3-Core 전용 신경망 NPU (6 TOPS INT8/INT4)
0.5B 모델 평가 | ~20 - 24 tok/s | 21.55 tok/s (Qwen 1.5 0.5B - 온디바이스 측정)
1.3B - 1.5B 평가 | 16.90 tok/s (DeepSeek) / 14.48 (Qwen) | ~16.69 tok/s (Qwen 2.5 1.5B - 참고 데이터)
3B - 4B 모델 평가 | 6.56 tok/s (Phi-3) / 7.28 (Llama 3.2) | ~7.45 tok/s (Phi-3 Mini 3.8B - 참고 데이터)
7B / 8B 모델 평가 | 2.32 tok/s (Llama 3.1 8B) | ~4.5 - 4.98 tok/s (Qwen 7B / ChatGLM - 참고 데이터)
CPU 사용률 | 100% (다른 작업 시 시스템 동결) | ~0% CPU 부하 (Docker/OS를 위해 CPU 100% 여유)
SoC 열 관리 | 84.1°C – 85.0°C 도달 | 훨씬 낮은 온도(~60–68°C) 유지
모델 생태계 | Ollama / llama.cpp를 통한 모든 GGUF 지원 | rkllm-toolkit을 통한 .rkllm 양자화 필요
홈랩 사용을 위한 주요 NPU 트레이드오프:

• CPU 부하 제로: NPU 생성 중에는 CPU 코어가 ~0%에 머무릅니다. Home Assistant, Nextcloud 및 기타 Docker 컨테이너는 완전히 반응성을 유지합니다.
• 대형 모델 속도 향상: 7B 모델의 경우, 전용 행렬 엔진이 텐서 수학을 처리하여 CPU 캐시를 과부하 상태로 만들지 않기 때문에 NPU가 CPU 대비 ~4.8 tok/s (2.3 tok/s)를 제공합니다.
• 100ms 미만 지연 시간: 소형 모델의 경우, Time to First Token (TTFT)이 NPU에서 96.4 ms로 떨어집니다.
• 포맷 제한: 임의의 GGUF를 로드할 수 없으며, 가중치는 Rockchip의 변환 도구를 사용하여 사전에 .rkllm으로 변환해야 합니다.

4. 열 동작 및 전력 (베어 다이 / 비냉각 테스트)
   Orange Pi의 표준 리테일 패키지는 보드만 판매합니다(냉각 액세서리는 SBC의 일반적인 경우와 같이 별도로 판매됨). 따라서 모든 테스트는 개방된 책상 위에서 아웃-of-the-box 베어 다이 열을 평가합니다:

• 유휴 상태 (Ollama 백그라운드 데몬 대기): 52.7°C (~4–5W 추정 SoC 엔벨로프)
• 지속적인 1B/3B 생성 (4T 빅 코어): 68–74°C (PCB 구리 평면을 통해 방출)
• 지속적인 8B 생성 (8.03B 파라미터): 베어 SoC를 직접 84.1°C – 85.0°C까지 밀어 올립니다(커널 DVFS 한계 도달).

지속적인 고부하 작업에는 애프터마켓 쿨러나 팬이 필요합니다. - 지속적인 멀티 코어 추론 시 예상 전력 소비: 약 12–16W. 5. 결론: RK3588은 로컬 AI에 적합한가? 잘 작동하는 영역: - Llama 3.2 1B, DeepSeek-Coder 1.3B 또는 Qwen 2.5 1.5B를 사용하여 백그라운드 자율 에이전트(피드 요약, Home Assistant 내 홈 자동화 추론, 봇 핸들러) 구동. - 낮은 지연 시간의 함수 호출: 초당 14–17 tok/s로, 1B 모델은 읽는 속도보다 빠르게 생성됩니다. - 로컬 임베딩 및 벡터 검색. 부족한 영역: - 8B 이상의 모델을 대화형으로 구동하는 경우(2.3 tok/s는 주고받는 채팅에는 너무 느림). - 방열판 없이 지속적인 컴퓨팅 작업을 수행할 때. 6. 재현성 및 테스트 스크립트 모든 테스트 스크립트(tools/benchmark_ollama.py), 원본 JSON 벤치마크 로그, 하드웨어 구성은 저장소에서 확인할 수 있습니다: GitHub: Orange Pi 5 Plus Benchmarks 에지 ARM 보드에서 어떤 모델을 사용하고 계신가요? 여기서 RKLLM을 프로덕션 환경에서 사용하는 분 vs 순수 llama.cpp를 사용하는 분이 있나요? 제출자 /u/No-Doughnut6532 [링크] [댓글]