Raspberry Pi Edge AI 구축법: LiteRT와 Gemma로 로컬 에이전트를 돌릴 때 보는 기준

요약: Google은 LiteRT와 Gemma를 이용해 Raspberry Pi 5에서 로컬 Edge AI 에이전트를 구동하는 사례를 공개했다. 글에는 Gemma 4 E2B 기준 99 tokens/sec prefill, 9 tokens/sec decode, peak memory 1432 MB 같은 수치가 포함되어 있다. 이 글은 개발자가 Raspberry Pi Edge AI를 실제 제품 후보로 검토할 때 필요한 모델 선택, CPU/GPU 분리, 지연 시간 예산, 운영 체크리스트를 정리한다.

Edge AI가 다시 실용 후보가 된 이유

Edge AI는 오래된 주제지만, 최근에는 의미가 달라졌다. 과거의 Edge AI는 주로 작은 분류 모델이나 객체 인식 모델을 장치 안에서 돌리는 정도였다. 지금은 경량 LLM, 임베딩 모델, 음성 인식, 비전 모델을 조합해 로컬 에이전트처럼 동작하게 만들 수 있다. 네트워크 없이 보고, 듣고, 판단하고, 반응하는 시스템이 가능해진 것이다.

Google Developers Blog의 2026년 8월 11일 글은 Raspberry Pi 5, LiteRT, Gemma 조합을 예로 든다. LiteRT는 on-device inference runtime이고, Gemma는 경량 오픈 모델 계열이다. 글은 Reachy Mini 로봇이 Raspberry Pi 5에서 비전과 언어 작업을 로컬로 처리하는 파이프라인을 보여준다.

개발자에게 중요한 포인트는 “멋진 데모”가 아니라 숫자다. Gemma 4 E2B가 Raspberry Pi 5에서 99 tokens/sec prefill, 9 tokens/sec decode, peak memory 1432 MB를 기록했다는 식의 수치는 설계 판단에 바로 쓰인다. 사용자가 말한 뒤 1초 안에 반응해야 하는지, 3초까지 허용되는지, 카메라 처리를 동시에 해야 하는지에 따라 가능한 제품이 달라진다.

모델 선택은 크기가 아니라 역할로 나눠야 한다

Edge AI에서 가장 흔한 실수는 “가장 큰 모델을 올릴 수 있는가”부터 보는 것이다. 실제 제품에서는 한 모델이 모든 일을 하지 않는다. Google 글에서도 Gemma 3 270M, EmbeddingGemma 300M, Gemma 3 1B, Gemma 4 E2B, Gemma 4 E4B처럼 역할이 다른 선택지가 언급된다.

예를 들어 감정 분류, 엔티티 추출, 간단한 라벨링은 270M급 모델로 충분할 수 있다. 로컬 RAG나 문서 검색은 EmbeddingGemma 같은 임베딩 모델이 더 중요하다. 짧은 요약과 다국어 응답은 1B급 텍스트 모델이 맞을 수 있다. 연속 모니터링이나 메모리 제약이 큰 장비에서는 E2B처럼 RAM을 아끼는 모델이 유리하다. 복잡한 multi-step planning이 필요하면 E4B 같은 더 강한 모델을 검토한다.

제품 설계에서는 기능별로 모델을 나눠야 한다. “항상 켜져 있는 모델”은 작고 빠른 것이 좋다. “사용자가 명령했을 때만 도는 모델”은 조금 무거워도 된다. “검색용 임베딩”은 생성 모델과 분리해야 한다. 이렇게 나누면 전체 지연 시간과 메모리 사용량이 줄고, 발열도 관리하기 쉽다.

CPU와 GPU를 어떻게 나눌 것인가

Raspberry Pi 5에는 quad-core ARM Cortex-A76 CPU와 VideoCore VII GPU가 있다. Google 글은 CPU가 FP32 기준 약 153.6 GFLOPS, INT8 기준 최대 약 2.0 TOPS이고, GPU는 약 76.8 GFLOPS, 0.24 TOPS라고 설명한다. 단순 수치만 보면 CPU가 강하지만, GPU는 병렬 작업을 분리하는 데 의미가 있다.

실무 파이프라인에서는 CPU에 모든 것을 몰아넣으면 음성 인식, 카메라 처리, LLM 응답이 서로 발목을 잡는다. 예를 들어 YOLO 기반 객체 탐지를 GPU에서 계속 돌리고, Moonshine 같은 음성 인식이나 Gemma 추론을 CPU에서 처리하면 자원 경합을 줄일 수 있다. 핵심은 “가장 빠른 프로세서 하나”가 아니라 “동시에 돌아야 하는 작업을 서로 방해하지 않게 나누는 것”이다.

개발자는 먼저 작업을 실시간, 준실시간, 배치로 나눠야 한다. 카메라 프레임 탐지는 실시간이다. 음성 명령 인식은 준실시간이다. 대화 기록 요약이나 로컬 인덱싱은 배치에 가깝다. 실시간 작업은 GPU나 작은 모델로 분리하고, LLM은 명령이 들어왔을 때만 CPU에서 실행하는 구조가 안정적이다.

지연 시간 예산을 먼저 잡아야 한다

Edge AI 프로젝트는 모델이 올라가는 순간 끝난 게 아니다. 사용자가 체감하는 것은 end-to-end latency다. 마이크 입력, 음성 인식, 의도 분류, 검색, LLM 생성, TTS, 모터 또는 UI 반응까지 모두 합쳐진 시간이다. 한 단계가 빨라도 전체가 느리면 제품은 답답하다.

Google 글에서 Gemma 4 E2B는 약 27.3 characters/sec, 약 300 words per minute 수준의 생성 속도를 보여준다고 설명한다. 일반 인간 말하기 속도인 약 150 wpm보다 빠른 수준이라는 해석도 붙어 있다. 이 숫자는 음성 에이전트에 중요하다. 생성이 인간 말하기 속도보다 충분히 빠르면 TTS 스트리밍과 결합해 자연스러운 응답을 만들 수 있다.

하지만 한국어 제품에서는 토큰과 문자, 음절, TTS 처리량이 다르게 체감될 수 있다. 영어 기준 수치를 그대로 쓰면 안 된다. 실제 대상 언어와 음성 엔진으로 측정해야 한다. 또한 첫 토큰 지연, 중간 끊김, 발열로 인한 성능 저하를 따로 봐야 한다. 10분 데모는 빠른데 2시간 켜두면 느려지는 제품은 현장에서 실패한다.

로컬 에이전트 아키텍처 예시

Raspberry Pi Edge AI를 제품으로 만든다면 단일 프로세스보다 파이프라인 구조가 낫다. 입력 레이어는 카메라, 마이크, 센서 이벤트를 받는다. 전처리 레이어는 음성 구간 검출, 프레임 샘플링, 노이즈 제거를 담당한다. 인식 레이어는 음성 인식과 객체 탐지를 수행한다. 추론 레이어는 Gemma 같은 LLM으로 의도와 계획을 만든다. 실행 레이어는 로봇 동작, 알림, 로컬 DB 기록, UI 업데이트를 담당한다.

각 레이어는 큐로 느슨하게 연결하는 편이 안정적이다. 카메라 프레임이 밀릴 때 LLM 생성까지 막히면 안 된다. 음성 명령이 들어오면 중요도를 높이고, 배경 객체 탐지는 프레임을 버리더라도 최신 상태만 유지한다. 로컬 장비에서는 완벽한 처리보다 밀림 없는 반응이 더 중요하다.

또한 로컬 RAG를 붙일 때는 임베딩 모델과 벡터 저장소의 크기를 조절해야 한다. Raspberry Pi에서 큰 문서 전체를 매번 검색하면 느리다. 제품 매뉴얼, 명령어 목록, 사용자 설정처럼 좁은 문서를 chunk 단위로 저장하고, top-k를 작게 유지하는 방식이 낫다.

운영에서 놓치기 쉬운 리스크

Edge AI의 장점은 데이터 프라이버시와 낮은 지연 시간이다. 하지만 운영 리스크도 있다. 첫째, 업데이트 배포가 어렵다. 클라우드 모델은 서버에서 바꾸면 되지만, 로컬 모델은 장치별로 버전 관리와 롤백이 필요하다. 둘째, 관측성이 부족하다. 네트워크 없이 동작하는 장비는 실패 로그를 나중에 수집해야 할 수 있다. 셋째, 발열과 전원 문제가 품질에 직접 영향을 준다.

넷째, 모델 출력 안전성을 로컬에서 처리해야 한다. 인터넷이 없다고 해서 부적절한 응답이나 잘못된 실행 명령 문제가 사라지지 않는다. 로봇, 카메라, 스마트홈처럼 물리 동작이 있는 제품은 LLM 출력과 실행 명령 사이에 rule-based guard를 둬야 한다. “문을 열어”, “모터를 최대로 돌려” 같은 명령은 모델 응답만 믿으면 안 된다.

다섯째, 사용자가 기대하는 오프라인 범위를 명확히 해야 한다. 완전 오프라인인지, 초기 설정과 업데이트는 온라인인지, 로그 업로드는 선택인지에 따라 제품 설명과 개인정보 처리 방침이 달라진다.

실행 체크리스트

• 제품 기능을 항상 켜짐, 명령 시 실행, 배치 작업으로 나눈다.
• 모델은 크기보다 역할 기준으로 선택한다: 분류, 임베딩, 생성, 계획을 분리한다.
• Raspberry Pi 5에서 대상 언어 기준 첫 토큰 지연, decode 속도, peak memory를 직접 측정한다.
• CPU와 GPU를 “성능 순위”가 아니라 동시 작업 분리 기준으로 배치한다.
• 카메라·음성·LLM 사이에는 큐를 두고 오래된 프레임은 버릴 수 있게 한다.
• 로컬 RAG는 작은 문서, 작은 top-k, 명확한 캐시 정책으로 시작한다.
• 물리 동작이나 민감 실행에는 LLM 뒤에 rule-based guard를 둔다.
• 모델·런타임·설정 버전을 장치별로 기록하고 롤백 절차를 만든다.