요약: LiteRT는 TensorFlow Lite의 후속에 가까운 온디바이스 AI 프레임워크로, GPU와 NPU 가속, PyTorch·JAX 변환, Gemma 계열 오픈 모델 배포를 한 흐름으로 묶는다. Google은 TFLite GPU delegate 대비 평균 1.4배 빠른 GPU 성능, 일부 NPU 경로에서 CPU 대비 최대 100배, GPU 대비 10배 속도를 언급했다. 모바일 개발자는 기능 욕심보다 모델 크기, fallback, 배포 방식, 개인정보 경계를 먼저 설계해야 한다.
모바일 앱에서 AI 기능을 붙일 때 기본 선택지는 서버 호출이었다. 구현이 쉽고 모델 교체도 빠르다. 하지만 지연 시간, 네트워크 의존성, 개인정보, API 비용, 오프라인 사용성 문제가 남는다. 사진 필터, 음성 인식, 텍스트 분류, 개인화 추천, 접근성 기능처럼 실시간성이 필요한 기능은 서버 왕복이 사용자 경험을 망칠 수 있다.
LiteRT는 이 문제를 온디바이스 실행으로 풀려는 프레임워크다. 기존 TFLite가 클래식 ML 배포의 표준이었다면, LiteRT는 생성형 AI와 최신 하드웨어 가속까지 포함하는 방향으로 확장됐다. Android, iOS, macOS, Windows, Linux, Web 같은 여러 플랫폼에서 GPU 가속을 제공하고, Android에서는 NPU 경로도 강화한다.
검색 의도로 보면 이 글은 LiteRT 온디바이스 AI, 모바일 AI 모델 배포, Gemma 모바일 실행을 찾는 개발자에게 맞춘다. 핵심은 “어떻게 시작하나”보다 “운영 가능한 앱 기능으로 만들려면 무엇을 결정해야 하나”다.
LiteRT를 이해할 때는 세 층으로 나누면 쉽다. 첫째는 Runtime이다. 변환된 모델을 CPU, GPU, NPU에서 실행하고 fallback을 처리한다. 둘째는 Converter다. PyTorch, TensorFlow, JAX 같은 프레임워크에서 만든 모델을 배포 가능한 형식으로 바꾸는 경로다. 셋째는 LiteRT-LM이다. LLM 실행에 필요한 토큰 처리, 메모리, 추론 흐름을 관리하는 orchestration layer다.
Google은 LiteRT Torch Generative API, LiteRT-LM, LiteRT Converter & Runtime을 함께 언급한다. 이 조합은 연구용 모델을 모바일 앱에 넣기 위한 반복 작업을 줄인다. 예를 들어 PyTorch로 만든 작은 분류 모델이나 Gemma 3 1B 같은 오픈 모델을 앱에서 돌리고 싶다면, 변환·최적화·실행 경로를 한 프레임워크 안에서 맞출 수 있다.
하지만 “지원한다”와 “제품에 넣어도 된다”는 다르다. 모델 파일 크기, 초기 로딩 시간, 배터리 소모, 메모리 피크, 발열, 기기별 accelerator 차이가 실제 품질을 좌우한다. 개발 초기에 성능 좋은 한 대의 플래그십 기기만 보고 판단하면 출시 후 문제가 생긴다.
LiteRT는 ML Drift 기반 GPU 엔진으로 OpenCL, OpenGL, Metal, WebGPU를 지원하고, TFLite GPU delegate 대비 평균 1.4배 빠른 성능을 내세운다. 또한 asynchronous execution, zero-copy buffer interoperability로 일부 실시간 작업에서 최대 2배 개선을 언급한다. 이미지 segmentation, 배경 분리, 실시간 음성 처리처럼 latency가 중요한 기능에 의미가 있다.
NPU는 더 빠를 수 있지만 운영 난이도가 높다. SoC마다 compiler와 runtime 특성이 다르고, 초기화 비용과 지원 기기 범위도 다르다. LiteRT는 AOT compilation과 on-device JIT compilation을 모두 제공한다. AOT는 복잡한 모델과 알려진 타깃 SoC에 좋고, 앱 시작 시간을 줄일 수 있다. JIT는 작은 모델을 다양한 기기에 배포할 때 편하지만 첫 실행 비용이 생긴다.
현실적인 기준은 이렇다. 사용자 경험이 100ms 단위 지연에 민감하면 GPU/NPU 최적화를 검토한다. 기능이 가끔 실행되고 네트워크 사용이 허용되면 서버 추론이 더 단순할 수 있다. 개인정보나 오프라인이 핵심 가치라면 온디바이스 우선으로 간다. 단, 항상 CPU fallback을 둔다. 가속기가 없거나 실패해도 앱이 죽지 않아야 한다.
LiteRT는 Gemma 3 270M, 1B, Gemma 3n, EmbeddingGemma, FunctionGemma, Qwen, Phi, FastVLM 같은 모델을 언급한다. Hugging Face의 LiteRT community에서 pre-converted 모델을 받을 수 있고, AI Edge Gallery 앱으로 체험할 수 있다.
초기 제품에서는 가장 큰 모델을 고르는 것이 보통 실패로 이어진다. 모바일 AI 기능은 정확도보다 응답 시간과 일관성이 먼저 깨진다. 예를 들어 앱 내 명령 실행에는 FunctionGemma처럼 좁은 action 모델이 더 적합할 수 있다. 검색·추천에는 EmbeddingGemma처럼 embedding 모델이 낫다. 카메라 기능에는 vision 특화 모델을 골라야 한다.
모델을 고를 때는 네 가지 표를 만든다. 모델 크기, 평균 추론 시간, 메모리 피크, 실패 시 fallback 품질이다. 여기에 기기군을 최소 세 단계로 나눈다. 최신 플래그십, 2~3년 된 중급기, 저사양 기기다. 온디바이스 AI는 데모 영상보다 하위 기기 테스트가 더 중요하다.
온디바이스 AI의 장점은 데이터가 기기 밖으로 나가지 않는다는 점이다. 하지만 이 장점은 설계로 보장해야 한다. 모델 입력 로그를 서버로 올리거나, 실패 시 자동으로 원문 데이터를 API에 보내면 개인정보 이점이 사라진다.
배포에서는 Play Feature Delivery, AI Packs, 모델 파일 버전 관리가 중요하다. 모든 사용자에게 큰 모델을 기본 번들로 넣으면 앱 설치 용량이 커진다. 기능을 켜는 사용자에게만 모델을 내려받게 하고, Wi-Fi 조건, 배터리 상태, 저장 공간을 확인하는 편이 낫다. iOS와 웹까지 고려한다면 플랫폼별 모델 형식과 업데이트 정책을 따로 봐야 한다.
운영 로그도 민감하다. 추론 성공 여부, 지연 시간, fallback 발생 여부는 수집해도 되지만, 원본 음성·이미지·텍스트를 저장할지는 별도 동의와 보안 검토가 필요하다. 온디바이스 AI라는 마케팅 문구보다 실제 데이터 흐름 다이어그램이 먼저다.
