Qwen3-30B를 라즈베리 파이에서 실시간으로 돌린 방법과 의미

MoE·양자화·ShapeLearn: 라즈베리 파이에서 30B LLM이 가능한 이유
메모리를 ‘예산’으로 본 LLM 최적화: Pi에서 30B 실시간 추론 사례
ShapeLearn 기반 비트 최적화로 본 엣지 LLM 성능 한계 돌파

라즈베리 파이에서 30B가 “실시간”이라니

보통 30B급 LLM은 메모리(가중치 적재) + 연산(토큰 생성) 때문에 데스크톱 GPU/서버 쪽 영역으로 여겨졌습니다.
그런데 ByteShape는 Qwen3-30B-A3B-Instruct-2507를 Raspberry Pi 5 16GB에서,
- 8.03 TPS(tokens/sec)
- BF16 대비 품질 94.18% 유지
  로 “실시간 대화처럼 느껴지는” 구간을 넘겼다고 밝힙니다.
ByteShape가 강조하는 핵심 메시지는 이거예요.
- 메모리는 목표가 아니라 ‘예산(제약)’으로 맞추고,
- 그 다음에 “파일을 더 줄이는 것” 자체가 아니라 사용자가 체감하는 TPS↔품질 트레이드오프를 최적화한다.

Qwen3-30B-A3B-Instruct-2507 구조 이해 (왜 Pi에서도 가능해지나)

A3B 의미: “총 30B지만, 한 번에 3.3B만 활성화”

Qwen 모델 카드에 따르면 이 모델은

총 파라미터 30.5B
활성화(activated) 파라미터 3.3B
Experts 128개 중 8개 활성화
컨텍스트 길이 262,144(네이티브)
로 설명됩니다.

즉 “MoE(Mixture-of-Experts)”라서 항상 30B 전부를 매 토큰마다 계산하지 않고, 선택된 일부 expert만 돌려서 연산 부담을 줄이는 구조입니다.

인스트럭트(지시형) + 2507 릴리즈

Qwen 측은 2507 버전에서 지시 이행, 추론, 수학/코딩, 도구 사용, 장문 이해(256K) 등이 강화되었다고 요약합니다.

“ShapeLearn”이 핵심인 이유: 낮은 비트가 항상 빠른 게 아니다

ByteShape의 주장/관찰 포인트는 꽤 실무적입니다.

llama.cpp 계열에서 “더 낮은 비트수 = 더 빠름”이 자동으로 성립하지 않는다
→ 양자화 포맷에 따라 커널 선택, 디코딩/언팩 오버헤드, 하드웨어 접근 패턴이 달라져서 오히려 느려질 수 있다.
그래서 ShapeLearn은 “그냥 4bit, 3bit로 깎자”가 아니라,
- 텐서(레이어/행렬)별로 최적 데이터타입(bitlength)을 학습적으로 선택
- 목표는 TPS와 품질을 동시에 최대화
- 단, 장치 메모리 안에 ‘편하게’ 들어가야 함(제약)

이 접근이 “라즈베리 파이 같은 극단적 메모리 제약 환경”에서 특히 효과가 크게 나타난다는 이야기입니다.

라즈베리 파이 5(16GB)에서의 성능 수치가 의미하는 것

실시간 체감 기준: “대충 8 TPS 전후”

ByteShape는 “실시간처럼 느껴지는 구간”을 대략 8 TPS 근처로 설명하면서, Pi 5에서 그 기준을 넘겼다고 강조합니다.

“정확도 우선” 선택지도 제시

Pi에서도 “최고 정확도지만 TPS는 5~6대” 같은 선택지들을 표로 제시합니다. (예: Q4_K_S 계열 등)

모델 고르는 법(실무 기준): KQ vs IQ, 그리고 KQ-2가 뭔가?

ByteShape GGUF 저장소 설명(허깅페이스)에 따르면

CPU 최적화: KQ 라벨
GPU 최적화: IQ 라벨
선택 규칙
- “원하는 TPS 목표에서 가장 높은 품질”
- 또는 “원하는 품질을 만족하는 가장 빠른 모델”

CPU(KQ) 모델 테이블 일부(품질/크기/bit-per-weight)

KQ-2: 2.70 bpw, 10.3GB, 정규화 품질 94.18%

즉, Pi에서는 보통 KQ 계열을 보고(=CPU), 그 중 메모리에 안정적으로 맞고, 목표 TPS를 넘는 지점을 고르는 방식이 깔끔합니다.

“진짜로 Pi에서 돌리기” 실행 가이드

아래는 가장 현실적인 2가지 루트입니다.

Ollama로 HF GGUF 바로 실행

ByteShape GGUF 카드에 “이 저장소의 GGUF 파일은 Ollama로 직접 실행 가능”이라고 되어 있고, 실행 커맨드를 공식 예시로 제공합니다.

Ollama 설치(예시: 리눅스)

curl -fsSL https://ollama.com/install.sh | sh

실행 (예시는 GPU용 IQ4_XS지만, Pi는 보통 CPU용 KQ/Q3_K_S 계열을 권장)

# 형식
ollama run hf.co/byteshape/Qwen3-30B-A3B-Instruct-2507-GGUF:FILE_NAME.gguf

# 예시(문서에 있는 예시 그대로)
ollama run hf.co/byteshape/Qwen3-30B-A3B-Instruct-2507-GGUF:Qwen3-30B-A3B-Instruct-2507-IQ4_XS-3.63bpw.gguf

Pi에서는 ByteShape 블로그 추천인 Q3_K_S-2.70bpw [KQ-2] 쪽 GGUF 파일명을 찾아 동일 방식으로 실행하는 그림입니다.

운영 팁

Pi 5 16GB라도 여유 RAM(OS/버퍼/kv cache 포함)을 확보하려면, “정확도 최대” 모델보다 “실시간 목표” 모델(KQ-2 같은)을 먼저 추천합니다.

llama.cpp로 직접 구동

Qwen 모델 카드에서도 Qwen3가 llama.cpp 등 로컬 런타임을 지원한다고 언급합니다.

다만, Pi에서 “최적 성능”은 빌드 옵션/BLAS/스레딩/메모리 설정에 따라 차이가 큽니다.

300x250

개략 절차

GGUF 다운로드(예: hf에서 wget/curl로)
llama.cpp 빌드(ARM 최적화 옵션, OpenBLAS 등)
실행 시 스레드/배치/컨텍스트 조정

실행 예시(형식 예시)

./llama-cli \
  -m ./Qwen3-30B-A3B-Instruct-2507-Q3_K_S-2.70bpw.gguf \
  -t 4 \
  -c 4096 \
  --temp 0.7 \
  --top-p 0.9 \
  -p "한국어로 짧게 자기소개해줘."

Pi 5는 발열/쓰로틀링이 TPS에 큰 영향을 줍니다.
방열(히트싱크/팬) + 전원 안정(정격 어댑터) 없으면 “처음엔 빠른데 점점 느려짐”이 흔합니다.

“로컬 LLM”이라고 끝이 아닙니다

라즈베리 파이에서 로컬 LLM을 서비스로 붙이면, 보안 관점에서 아래를 정책/점검표로 잡는 게 안전합니다.

공급망(모델 파일) 무결성

GGUF/모델 파일은 사실상 “실행 산출물”입니다.
다운로드 출처 고정, 해시 검증, 서명/릴리즈 노트 확인을 표준화하세요.
내부 배포 시
- 사내 아티팩트 저장소(예: Nexus/Artifactory/내부 오브젝트 스토리지)로 “검증된 모델만” 미러링
- 모델 버전/해시를 CMDB/자산대장에 기록

권한 분리(필수)

LLM 프로세스는 전용 계정/최소권한으로 실행
홈 디렉토리/모델 디렉토리 권한 최소화(읽기 전용)
systemd로 서비스화 시 User=, ProtectSystem=strict, NoNewPrivileges=true 등 고려

데이터 유출/프롬프트 인젝션(현실 이슈)

로컬이라고 해도 “입력 데이터”가 민감하면 위험합니다.

사용자가 붙여 넣는 로그/키/토큰/개인정보가 프롬프트에 섞여 들어가면 그대로 모델 컨텍스트에 남습니다.
점검 포인트
- 입력에서 비밀/개인정보 자동 마스킹(정규식/DLP)
- 대화 로그 저장 정책(저장 여부, 보관 기간, 접근통제)
- “모델이 시스템 명령을 실행하지 못하게” 도구 호출/에이전트 기능은 기본 OFF

네트워크 통제(로컬 운영의 기본값)

“완전 로컬” 목표면
- 아웃바운드 차단(텔레메트리/의존성 다운로드 방지)
- 관리 채널(SSH/웹UI)만 제한적으로 허용
내부망 서비스로 노출 시
- 인증(SSO/토큰), 레이트리밋, WAF/리버스프록시, 감사로그 필수

자원 DoS(특히 Pi는 취약)

긴 프롬프트/큰 컨텍스트/동시 요청은 Pi를 쉽게 다운시킵니다.
점검 포인트
- 최대 입력 길이 제한
- 동시성 제한(큐잉)
- 프로세스/컨테이너 cgroup으로 CPU/RAM 제한
- 워치독/헬스체크로 자동 복구

활용 사례(“Pi에서 30B 실시간”이 열어주는 것)

내부망 오프라인 보안 도우미

사고 대응 플레이북 질의응답(단, 민감정보 마스킹 필수)
규정/가이드 문서 요약(사내 문서 기반 RAG)

현장/엣지 단말 에이전트

공장/IDC/현장 장비 옆에서 로컬로 동작(네트워크 끊겨도 사용)
음성/키오스크형 안내(로컬 STT/TTS와 결합)

개인정보/기밀 데이터 처리

외부 클라우드 LLM에 보내기 어려운 데이터(내부 로그, 설계문서) 요약/분류를 로컬에서 수행
→ 단, “대화 로그 저장/접근통제”가 같이 설계돼야 합니다.

한계와 현실적인 주의점

“실시간”은 주로 짧은 컨텍스트 / 단일 사용자 / 안정적 발열 조건에서 가장 잘 나옵니다.
Qwen 모델 자체는 262K 컨텍스트를 지원하지만, Pi에서는 컨텍스트를 크게 잡으면 KV 캐시가 메모리를 잡아먹어 OOM/성능저하가 커질 수 있습니다. (Qwen도 OOM 시 컨텍스트를 줄이라고 안내)
결국 Pi 운영은 이렇게 정리됩니다.
- 모델(가중치) 적재 + KV 캐시 + OS 여유까지 합쳐서 메모리 예산을 짠 뒤
- 목표 TPS/품질 지점(KQ-2 같은)을 고르는 게 핵심입니다.

다음 단계 “실전 문서”

Pi 5에서 실제 재현용 체크리스트(OS, 스왑, 발열, 스레드, 컨텍스트, 벤치마크 방법)
KQ-1~KQ-9 중 목적별 추천표(대화/요약/코딩/정확도 우선)
보안 운영 표준안(모델 반입/검증, 서비스 계정, 네트워크 정책, 로그 정책, DLP 마스킹 규칙)
내부망 API 서비스화(reverse proxy + auth + rate limit + 감사로그)

728x90

그리드형(광고전용)

저작자표시 비영리 동일조건 (새창열림)

pages.kr 날으는물고기 <º)))><

Qwen3-30B를 라즈베리 파이에서 실시간으로 돌린 방법과 의미

Qwen3-30B를 라즈베리 파이에서 실시간으로 돌린 방법과 의미

라즈베리 파이에서 30B가 “실시간”이라니

Qwen3-30B-A3B-Instruct-2507 구조 이해 (왜 Pi에서도 가능해지나)

A3B 의미: “총 30B지만, 한 번에 3.3B만 활성화”

인스트럭트(지시형) + 2507 릴리즈

“ShapeLearn”이 핵심인 이유: 낮은 비트가 항상 빠른 게 아니다

라즈베리 파이 5(16GB)에서의 성능 수치가 의미하는 것

실시간 체감 기준: “대충 8 TPS 전후”

추천 모델(핵심)

“정확도 우선” 선택지도 제시

모델 고르는 법(실무 기준): KQ vs IQ, 그리고 KQ-2가 뭔가?

“진짜로 Pi에서 돌리기” 실행 가이드

Ollama로 HF GGUF 바로 실행

llama.cpp로 직접 구동

“로컬 LLM”이라고 끝이 아닙니다

공급망(모델 파일) 무결성

권한 분리(필수)

데이터 유출/프롬프트 인젝션(현실 이슈)

네트워크 통제(로컬 운영의 기본값)

자원 DoS(특히 Pi는 취약)

활용 사례(“Pi에서 30B 실시간”이 열어주는 것)

한계와 현실적인 주의점

다음 단계 “실전 문서”

댓글

티스토리툴바

Qwen3-30B를 라즈베리 파이에서 실시간으로 돌린 방법과 의미

Qwen3-30B를 라즈베리 파이에서 실시간으로 돌린 방법과 의미

라즈베리 파이에서 30B가 “실시간”이라니

Qwen3-30B-A3B-Instruct-2507 구조 이해 (왜 Pi에서도 가능해지나)

A3B 의미: “총 30B지만, 한 번에 3.3B만 활성화”

인스트럭트(지시형) + 2507 릴리즈

“ShapeLearn”이 핵심인 이유: 낮은 비트가 항상 빠른 게 아니다

라즈베리 파이 5(16GB)에서의 성능 수치가 의미하는 것

실시간 체감 기준: “대충 8 TPS 전후”

추천 모델(핵심)

“정확도 우선” 선택지도 제시

모델 고르는 법(실무 기준): KQ vs IQ, 그리고 KQ-2가 뭔가?

“진짜로 Pi에서 돌리기” 실행 가이드

Ollama로 HF GGUF 바로 실행

llama.cpp로 직접 구동

“로컬 LLM”이라고 끝이 아닙니다

공급망(모델 파일) 무결성

권한 분리(필수)

데이터 유출/프롬프트 인젝션(현실 이슈)

네트워크 통제(로컬 운영의 기본값)

자원 DoS(특히 Pi는 취약)

활용 사례(“Pi에서 30B 실시간”이 열어주는 것)

한계와 현실적인 주의점

다음 단계 “실전 문서”

관련글

댓글

티스토리툴바