요약: Google LiteRT는 TFLite의 후속 성격을 가진 온디바이스 AI 런타임으로, GPU/NPU 가속과 GenAI 배포를 더 넓은 플랫폼에서 다루려는 흐름입니다. 모바일·웹 개발자는 “모델을 넣을 수 있나”보다 “지연 시간, 배터리, 폴백, 업데이트를 어떻게 운영할 것인가”를 먼저 봐야 합니다.
서버 LLM API는 빠르게 발전했지만 모든 AI 기능을 서버로 보낼 수는 없습니다. 카메라 기반 인식, 실시간 음성, 키보드 추천, 로컬 문서 요약, 개인정보가 포함된 입력 처리, 오프라인 기능은 온디바이스 실행이 유리합니다. 네트워크 왕복이 없고, 데이터가 기기 밖으로 나가지 않으며, 사용자가 체감하는 지연 시간이 줄어듭니다.
Google은 LiteRT를 온디바이스 AI 시대의 범용 프레임워크로 소개하며, TFLite 대비 GPU 성능 개선, NPU 지원, Gemma 같은 오픈 모델 배포, PyTorch/JAX 변환 지원을 강조했습니다. 공식 글에서는 GPU 평균 1.4배 성능 향상, 특정 샘플에서 최대 2배 성능 개선, NPU에서는 CPU 대비 최대 100배·GPU 대비 최대 10배 빠른 사례가 언급됩니다.
하지만 숫자만 보고 바로 적용하면 실패합니다. 온디바이스 AI는 모델, 런타임, 하드웨어, 배터리, 메모리, 앱 업데이트가 모두 얽힙니다. 이 글은 LiteRT를 실제 제품에 넣기 전 개발자가 정해야 할 기준을 정리합니다.
첫째, 크로스 플랫폼 GPU 가속입니다. 공식 설명에 따르면 LiteRT는 Android, iOS, macOS, Windows, Linux, Web까지 GPU 지원 범위를 넓히고 OpenCL, OpenGL, Metal, WebGPU 같은 백엔드를 다룹니다. 앱 개발자에게 중요한 것은 “각 플랫폼별로 완전히 다른 추론 코드를 짜지 않아도 되는가”입니다.
둘째, NPU 통합입니다. 모바일 SoC에는 다양한 NPU가 들어가지만 벤더별 SDK와 컴파일러가 달라 운영이 어렵습니다. LiteRT는 AOT 컴파일, Google Play for On-device AI, 런타임 폴백 같은 흐름으로 복잡도를 낮추려 합니다. Android 앱에서는 특정 기기에서 NPU가 가능하면 NPU를 쓰고, 아니면 GPU/CPU로 내려가는 전략이 중요합니다.
셋째, GenAI 배포 지원입니다. 온디바이스 생성 AI는 단순 이미지 분류와 다릅니다. 토큰 생성, KV cache, 메모리 관리, 모델 포맷, 양자화, 스트리밍 UI가 필요합니다. LiteRT-LM 같은 구성 요소는 이런 복잡도를 줄이기 위한 방향으로 볼 수 있습니다.
LiteRT가 잘 맞는 기능은 지연 시간이 짧아야 하고 입력 데이터가 민감한 기능입니다. 예를 들어 실시간 배경 분리, 음성 인식 전처리, 카메라 장면 이해, OCR 후보 추출, 키보드 문장 추천, 로컬 검색 임베딩, 간단한 요약, 앱 내부 분류 작업이 있습니다.
반대로 서버가 더 나은 기능도 있습니다. 최신 지식이 필요한 질의응답, 대규모 도구 호출, 긴 문서 전체 분석, 팀 데이터베이스 검색, 고성능 reasoning이 필요한 작업은 서버 모델이 유리합니다. 온디바이스 모델은 대개 크기와 전력 제약을 받습니다. 무리하게 모든 AI를 로컬로 넣으면 품질과 앱 용량이 문제가 됩니다.
따라서 제품 설계는 하이브리드가 현실적입니다. 민감하거나 실시간인 1차 처리는 로컬에서 하고, 고품질 reasoning이나 최신 정보가 필요한 2차 처리는 서버로 보냅니다. 예를 들어 회의 앱이라면 음성 activity detection과 초벌 전사는 로컬, 긴 회의록 요약과 액션 아이템 정리는 서버에서 처리할 수 있습니다.
온디바이스 AI 성능을 볼 때 많은 팀이 latency만 봅니다. 하지만 실제 제품에서는 p95 latency, 배터리 사용량, 발열, 메모리 피크, 앱 시작 시간, 첫 실행 컴파일 비용이 더 중요할 수 있습니다.
AOT 컴파일은 초기 실행 속도와 메모리 측면에서 유리할 수 있지만, 타깃 SoC를 알아야 하고 배포 파이프라인이 복잡해집니다. JIT 또는 on-device compilation은 유연하지만 첫 실행 비용이 생길 수 있습니다. 사용자가 기능을 처음 눌렀을 때 5초 동안 멈추면 좋은 경험이 아닙니다.
따라서 성능 측정은 실제 사용자 플로우에서 해야 합니다. 벤치마크 앱에서 빠른 모델이 실제 앱에서도 빠르다는 보장은 없습니다. 카메라 프레임 처리, UI 스레드, 네트워크, 저장소, 애니메이션이 동시에 움직이면 병목이 달라집니다.
NPU가 있는 기기와 없는 기기, GPU 드라이버가 안정적인 기기와 아닌 기기, 메모리가 충분한 기기와 아닌 기기는 모두 다릅니다. LiteRT가 폴백을 제공하더라도 제품 레벨 정책이 필요합니다.
예를 들어 고성능 경로는 NPU, 일반 경로는 GPU, 최소 경로는 CPU로 둡니다. CPU에서도 너무 느리면 기능을 끄거나 서버 처리로 전환합니다. 이때 사용자에게 “AI 기능을 사용할 수 없습니다”라고만 보여주면 나쁜 경험입니다. “이 기기에서는 고급 실시간 처리가 제한되어 서버 처리로 전환됩니다”처럼 기대치를 관리해야 합니다.
또한 원격 설정이 필요합니다. 특정 기기/OS 버전에서 크래시가 발생하면 앱 업데이트 없이 해당 가속 경로를 끌 수 있어야 합니다. 온디바이스 AI는 하드웨어 다양성 때문에 feature flag와 remote config가 거의 필수입니다.
첫 단계는 기능을 작게 자르는 것입니다. “앱에 AI 넣기”가 아니라 “이미지 선택 후 500ms 안에 품질 점수 계산”, “오프라인 상태에서도 최근 메모 20개에서 관련 문장 추천”처럼 측정 가능한 기능으로 정의합니다.
두 번째 단계는 모델 후보를 정합니다. 정확도, 크기, 메모리, 라이선스, 변환 가능성, 양자화 후 품질을 봅니다. PyTorch나 JAX 모델을 쓴다면 LiteRT 변환 과정에서 지원되지 않는 연산이 있는지 확인해야 합니다.
세 번째 단계는 대상 기기를 나눕니다. 프리미엄 Android, 중급 Android, iPhone, 데스크톱 브라우저, 저사양 웹 환경은 성능이 다릅니다. 최소 지원 기준을 정하지 않으면 QA 범위가 폭발합니다.
네 번째 단계는 측정 자동화입니다. inference time, memory peak, battery impact, crash rate, fallback rate를 로그로 남깁니다. 개인정보가 포함될 수 있으므로 입력 원문이 아니라 지표만 수집해야 합니다.
첫 번째 문제는 앱 용량입니다. 모델 파일이 커지면 설치 전환율과 업데이트 부담이 생깁니다. 기능 사용률이 낮다면 온디맨드 다운로드를 고려해야 합니다.
두 번째 문제는 모델 업데이트입니다. 서버 모델은 배포가 쉽지만 온디바이스 모델은 앱 업데이트나 별도 모델 배포 체계가 필요합니다. 모델 버전과 런타임 버전 호환성을 관리해야 합니다.
세 번째 문제는 개인정보 설명입니다. 로컬에서 처리한다는 점은 장점이지만, 사용자는 무엇이 로컬이고 무엇이 서버인지 모릅니다. 설정 화면이나 개인정보 처리방침에서 처리 위치를 명확히 설명해야 신뢰가 생깁니다.
네 번째 문제는 디버깅입니다. 특정 칩셋에서만 느리거나, 특정 OS 버전에서만 실패하는 경우가 있습니다. 그래서 기기별 성능 매트릭스와 crash grouping이 필요합니다.
출처: Google Developers Blog “LiteRT: The Universal Framework for On-Device AI”, LiteRT GPU/NPU 문서, LiteRT-LM 및 Google AI Edge 자료.
