Google LiteRT.js 살펴보기: 브라우저에서 .tflite를 WebGPU로 굴리는 법과 성능 함정

Google은 2026년 7월 9일 LiteRT의 자바스크립트 바인딩 LiteRT.js를 공개했다. LiteRT는 기기 내 추론 라이브러리로 Android 및 임베디드 환경을 중심으로 사용되어 왔으며, 이번에는 WebAssembly, WebGPU, WebNN 같은 웹 표준 가속 경로를 통해 .tflite 모델을 브라우저에서도 직접 실행하도록 확장했다. 본문에서는 런타임 스택 구성, 정량 성능의 의미, 그리고 텐서 메모리 관리라는 실무 함정까지 정리한다.

LiteRT.js 개요

2026년 7월 Google이 공개한 의미와 포지셔닝

LiteRT.js는 Google의 기기 내 추론 라이브러리 LiteRT를 자바스크립트에서 호출할 수 있도록 만든 바인딩 레이어다. 기존 LiteRT의 핵심 산출물인 .tflite 모델 파일 포맷을 그대로 활용하면서, 실행 환경만 모바일/임베디드에서 브라우저로 옮겨왔다. 결과적으로 서버 추론 라운드트립 없이 모델을 웹 페이지에 임베드해 실행할 수 있어, 프라이버시와 응답 지연 측면에서 이점을 노릴 수 있다. 다만 “브라우저 AI” 영역에서는 Transformers.js, ONNX Runtime Web, MediaPipe 등 경쟁 구현이 이미 존재하므로, LiteRT.js의 차별점은 가속 스택의 폭과 .tflite 생태계 재사용성에 있는 것으로 소개된다.

런타임 구조와 가속 경로

WebAssembly 기반 .tflite 실행 파이프라인

LiteRT.js의 런타임 코어는 WebAssembly로 컴파일되어 브라우저에서 적재된다. 모델 적재는 .tflite 파일을 그대로 가져와 파싱하는 구조이므로, 기존에 학습/변환된 모델을 별도 변환 없이 웹으로 가져올 수 있다. 추론 시에는 CPU 폴백 경로가 항상 켜져 있고, 디바이스와 브라우저가 WebGPU 또는 WebNN을 지원하면 자동으로 가속 경로로 분기한다. 이러한 다층 폴백 구조 덕분에 데스크톱은 물론 모바일 브라우저에서도 합리적인 호환성을 기대할 수 있다.

CPU 경로: XNNPACK과 폴백 전략

CPU 경로는 LiteRT의 연산 커널을 기반으로 XNNPACK을 활용해 구성된다. XNNPACK은 SIMD(Single Instruction Multiple Data) 명령을 활용해 컨볼루션, 완전연결 계층을 효율적으로 처리하며, 웹 표준인 WebAssembly SIMD와 결합될 때 가장 높은 처리량을 보인다. WebGPU나 WebNN이 비활성화된 환경, 혹은 매우 작은 모델 구간에서는 이 CPU 경로가 기본값이 된다. 폴백 성능이 안정적이라는 점은 운영 관점에서 중요한 안전망 역할을 한다.

GPU 경로: WebGPU와 ML Drift

GPU 가속은 WebGPU 위에 구현된 자체 백엔드 “ML Drift”를 통해 이루어진다. WebGPU는 차세대 웹 표준 그래픽/컴퓨트 API로, 기존 WebGL보다 명시적인 컴퓨트 셰이더와 파이프라인 제어를 제공한다. ML Drift는 이를 활용해 텐서 연산을 셰이더로 컴파일하며, 브라우저가 노출하는 GPU 디바이스에 직접 디스패치한다. 일반적으로 컨볼루션과 행렬 곱 같은 연산에서 CPU 대비 큰 폭의 향상이 기대되며, Google 측 측정에서도 해당 경로가 핵심 성능 원천으로 보고되었다.

실험적 WebNN(NPU) 지원과 브라우저 호환성

차세대 가속 경로인 WebNN(신경망 처리 장치(NPU) 추상화 표준)은 아직 실험적 플래그 형태로 제공된다. WebNN은 신경망 연산에 특화된 그래프 API를 제공해 NPU/Neural Processing Unit 하드웨어에 더 가까운 효율을 기대하게 하지만, 현재 Chrome 등 일부 브라우저에서만 부분 지원되고 표준화도 진행 중이다. 따라서 프로덕션 환경에서는 보조 옵션으로 다루고, 기본은 CPU와 WebGPU 두 경로로 구성하는 것이 현실적이다.

정량 성능과 해석

자체 측정 5~60배, 일반 런타임 대비 최대 3배의 의미

Google이 함께 공개한 수치는 두 축으로 요약된다. 첫째, 동일한 .tflite 모델을 LiteRT.js의 CPU 경로(내부 베이스라인)로 실행했을 때 대비 WebGPU/WebNN 경로는 5~60배 빠른 사례가 있었다. 둘째, 외부 일반 웹 추론 런타임(예: 순수 자바스크립트 기반 추론 라이브러리 등) 대비로는 최대 약 3배의 속도 향상이 보고되었다. 두 수치의 의미를 분리해 해석하면, 전자는 LiteRT.js 내부의 가속기 활용 효율을, 후자는 기존 웹 추론 대비 경쟁력을 보여주는 지표로 읽힌다.

벤치마크 재현성 문제와 비교 한계

다만 5~60배는 “내부 베이스라인” 대비 수치이므로 어떤 모델, 입력 크기, 배치, 브라우저/OS 조합에서 측정됐는지에 따라 편차가 크다. 일반 웹 런타임 대비 3배 수치 역시 동일 모델·동일 조건에서의 비교가 아니면 그대로 인용하기 어렵다. 따라서 실무에서는 자신의 타깃 모델과 디바이스 분포에 맞춰 사전 측정하는 것이 권장된다. 공식 문서 외 수치를 단정적으로 인용하는 것은 지양하는 편이 안전하다.

구현 디테일과 주의점

텐서 수명 주기와 메모리 누수 리스크

LiteRT.js 문서와 예제에서 자주 언급되는 디테일은 텐서의 명시적 수명 관리다. Google 측 보고에 따르면 LiteRT.js에서 텐서는 자바스크립트 가비지 컬렉터(GC)에 전적으로 의존하지 않으며, 명시적 디스포즈(dispose) 또는 참조 해제 패턴이 필요하다. 이를 놓치면 GPU 메모리(WebGPU 버퍼)가 누적되어 탭이 오래 살아 있을수록 메모리 사용량이 증가할 수 있다. 이는 GPU 자바스크립트 바인딩 전반에서 자주 보이는 패턴이며, LiteRT.js도 예외는 아닌 것으로 분석된다.

모델 적재와 디스포즈 회피 패턴

메모리 누수 리스크를 줄이려면 다음 패턴을 권장할 수 있다. 첫째, 추론 루프 안에서 매번 텐서를 새로 할당하지 말고, 가능한 한 입력/출력 버퍼를 재사용하는 풀(pool) 구조를 설계한다. 둘째, 컴포넌트 언마운트 시점에 모델 인스턴스와 모든 텐서를 일괄 해제하는 디스포즈 훅을 마련한다. 셋째, WebGPU 디바이스 자체도 페이지 전환 시 적절히 반환하도록 라이프사이클을 잡는다. 이 같은 규약은 추후 표준이 텐서 자동 해제로 발전하더라도 그대로 좋은 습관으로 남는다.

활용 시나리오와 전망

WebGPU WebNN 채택 확산과 남은 과제

LiteRT.js가 실질적 가치를 발휘하려면 WebGPU의 안정적 보급이 선행되어야 한다. 2026년 기준 데스크톱 Chrome/Edge는 WebGPU가 기본 활성화되어 있고, Safari와 모바일 브라우저도 점진적으로 지원 범위를 넓히는 추세다. WebNN은 여전히 실험 단계로, 디바이스/운영체제별로 NPU 노출 방식이 달라 이식성 이슈가 크다. 그럼에도 LiteRT.js는 .tflite라는 검증된 모델 포맷을 그대로 웹으로 끌어올렸다는 점에서 의미가 있으며, 향후 자동 텐서 관리, 더 넓은 WebNN 호환성, 그리고 표준화된 성능 측정 도구가 함께 성숙해야 실무 도입이 가속될 것으로 전망된다.