구글이 웹 개발자의 모델 불러오기 방식과 기기 내 음성 처리를 확장한 LiteRT-LM 새 버전을 공개했다. 브라우저에서는 모델을 나누어 읽는 스트리밍을 지원하고, 음성 앱 개발자는 여러 인식·합성 모델을 같은 실행 인터페이스로 다룰 수 있다. 기존 C API 사용자는 달라진 함수 규칙에 맞춰 코드를 수정해야 한다.

1. 웹 모델을 여러 입력 경로로 불러온다

v0.19.0 릴리스 노트에 따르면 웹 SDK는 모든 모델을 스트리밍, 나누어 받아 처리하는 방식으로 불러오며 GPU 백엔드, 실제 연산을 맡는 처리 환경을 기본으로 사용한다. 이미지와 오디오 입력 지원도 추가됐다. 웹 API 안내서는 주소에서 모델 가중치, 모델 동작을 정하는 수치 정보를 직접 가져와 스트리밍한다고 설명한다. 개발자는 원격 주소뿐 아니라 브라우저가 가진 데이터도 모델 입력으로 연결할 수 있다.

웹 API 안내서는 모델 입력으로 HTTP·HTTPS 주소, Hugging Face 저장소를 가리키는 주소, 브라우저의 파일이나 바이트 스트림, 순서대로 전달되는 데이터 흐름을 제시한다. 저장소 주소만 주면 엔진의 백엔드에 맞는 모델 파일을 고른다. 여러 파일이 조건에 맞으면 하나를 불러오고 나머지 파일을 경고로 알린다.

가장 간단한 예시는 모델 저장소 주소를 엔진에 넘기는 방식이다.

const engine = await Engine.create({
  // The model's Hugging Face repository
  model: 'hf://litert-community/gemma-4-E2B-it-litert-lm',
  // Or the URL of a model file, on Hugging Face or anywhere else
  // model: 'https://huggingface.co/litert-community/gemma-4-E2B-it-litert-lm/resolve/main/gemma-4-E2B-it-gpu.litertlm',
});

모델을 불러온 뒤에는 엔진에서 대화를 생성해 사용한다. 웹 API 안내서는 사용을 마치면 엔진을 삭제해 자원을 해제하도록 안내한다.

2. 웹 지연은 입력 형태에 따라 달라진다

구글의 회사 발표 기준으로 EmbeddingGemma 2는 MacBook Pro M5에서 WebGPU를 사용할 때 아래 지연 시간을 기록했다. 개요 페이지에 적힌 모델 크기는 485 MB다. 입력 조합을 바꿨을 때 웹 앱의 대기 시간이 어떻게 달라지는지 보여 주는 실행 사례다.

표: 웹 입력 조합별 지연 시간

조건: EmbeddingGemma 2(740M 멀티모달, 485 MB), MacBook Pro M5, WebGPU, Google AI Edge 문서 기준

단위: 밀리초

웹 입력 조합별 지연 시간텍스트: 지연 시간 21.8; 텍스트+이미지: 지연 시간 107; 텍스트+오디오: 지연 시간 228; 텍스트+이미지+오디오: 지연 시간 226텍스트21.8텍스트+이미지107텍스트+오디오228텍스트+이미지+오디오226
웹 입력 조합별 지연 시간
웹 지연은 입력 형태에 따라 달라진다
입력 조합지연 시간
텍스트21.8
텍스트+이미지107
텍스트+오디오228
텍스트+이미지+오디오226

텍스트에 이미지나 오디오가 더해진 입력은 텍스트만 넣은 경우보다 지연이 길었다. 따라서 멀티모달 처리를 브라우저에 넣을 때는 입력 방식에 따른 대기 시간 차이를 제품 흐름에 반영할 필요가 있다.

3. 음성 인식과 합성 모델을 한 실행 틀에 담는다

릴리스 노트는 Qwen3-ASR 등 음성 인식 모델과 Kokoro 등 합성 모델 지원을 알렸다. 저장소의 실험용 실행 도구는 모델마다 별도 도구를 쓰는 대신 하나의 실행 파일과 공통 C++ 인터페이스로 입력을 넣고 출력을 받는 구조다.

Qwen3-TTS도 새 지원 목록에 포함됐다. 이 공통 실행 틀에서는 엔진을 한 번 만든 뒤 세션에 텍스트나 음성을 넣고, 결과를 조각 단위로 받아 처리한다.

Kokoro 모델 카드는 82M 매개변수 모델을 351 MB 파일 하나로 묶고, 24 kHz 음성과 9개 언어·방언, 54개 음성을 제공한다고 설명한다. GPU용 파일은 중간 음향 표현을 실제 소리로 바꾸는 부분을 GPU에서 처리하고, 범용 파일은 CPU와 GPU에서 사용할 수 있다.

모델 카드에 실린 회사 발표 기준으로 Galaxy S26에서 18.3초 영어 문단을 af_heart 음성으로 합성할 때 GPU용 파일은 4.0초, 피크 메모리, 실행 중 최대 메모리 사용량 485 MB를 기록했다. Snapdragon 8 Elite Gen 5와 Adreno GPU를 탑재한 기기에서 CPU 4스레드를 쓰고 한 차례 예열, 측정 전 실행해 상태를 안정시키는 과정을 거친 결과다.

같은 문단·음성·예열 조건에서 범용 파일을 GPU로 실행하면 3.9초와 1,030–1,225 MB, CPU로 실행하면 4.7초와 975 MB였다. GPU용 파일은 이 기기의 GPU 실행끼리 비교하면 합성 속도를 비슷하게 유지하면서 메모리 사용량을 줄이는 선택지다.

4. C API 1.0.0은 오류와 결과 전달 방식을 바꾼다

이번 릴리스는 C API를 1.0.0으로 올리며 호환성을 깨는 변경을 포함했다. 실패할 수 있는 함수는 상태 코드를 반환하고 결과를 out_* 매개변수로 전달한다. 내보내는 심볼, 외부에서 호출할 수 있게 공개된 함수 이름도 litert_lm_* 계열로 제한한다. 기존 함수 시그니처, 함수의 이름과 입력·출력 규칙에 맞춰 작성한 C 코드는 새 헤더에 맞춰 수정해야 한다.

헤더에는 실제 로드된 라이브러리의 API 버전을 확인하는 함수가 추가됐다. 호출자는 컴파일에 사용한 헤더의 버전과 실행 중인 라이브러리의 버전을 비교할 수 있다. 앱과 별도로 라이브러리를 교체하는 배포 방식이라면 이 확인을 연동 절차에 넣을 수 있다.

오류 처리 규칙도 바뀌었다. 성공은 0, 실패는 양수 상태 코드이며 실패한 호출의 스레드에서 마지막 오류 메시지를 읽는다. 포인터 결과는 실패 시 NULL로 설정되고, 숫자형 결과는 실패하면 쓰지 않는다. 음수 반환을 검사하던 코드는 상태 코드 판정으로 바꿔야 한다.

5. 실행 경로 확대와 자원·전환 비용을 함께 따진다

공통 실행 도구는 여러 음성 모델을 다루는 수고를 줄이는 대신 지원 모델 구현을 함께 연결한다. 자체 앱은 필요한 모델 구현만 연결해 사용하지 않는 의존성과 실행 파일 크기를 줄일 수 있다. 기능 확대의 이익을 얻으면서 배포 크기를 관리하는 방법이다.

GPU용 음성 파일을 고를 때는 LiteRT의 GPU 실행을 지원하는 장치가 필요하다. 또 1.0.0 이전 라이브러리에는 API 버전 확인 함수가 없으므로, 동적 로딩, 실행 중 필요한 라이브러리를 불러오는 방식의 앱은 이 함수를 찾지 못하면 호환되지 않는 라이브러리로 처리해야 한다.

이번 업데이트의 실질적 가치는 웹과 음성 모델의 활용 경로를 넓히는 데 있으며, 도입 판단은 기기 자원과 C API 전환 작업까지 함께 따져야 한다.