Google LiteRT-LM은 왜 주목받나: README 번역과 쉬운 코드 구조 해설

한눈에 보기

한 줄 성격: LiteRT-LM, 구글이 공개한 기기 안에서 돌아가는 AI 실행 엔진과 개발 도구 묶음
핵심 흐름: 엔진 준비 → 대화 정리 → 한 번의 실행 세션 생성 → 답변 생성
README 약속: 안드로이드와 데스크톱 대응, GPU·NPU 가속, 이미지·오디오 입력, 함수 호출 지원
실제 강점: 단순 실행기가 아니라 대화 기록과 모델 규칙을 정리해 주는 구조
먼저 볼 한계: 2026년 4월 22일 기준 파이썬 경로는 아직 제약이 있고, 공개 이슈에도 안드로이드·NPU 관련 운영 문제가 남아 있음
이 글의 기준: 2026년 4월 22일, 저장소 main 브랜치와 최신 안정 릴리스 v0.10.2 기준 정리

서론

요즘 AI를 휴대폰이나 노트북 안에서 바로 돌리려는 이유는 분명합니다.

답이 빨라지고, 인터넷이 약해도 쓸 수 있고, 민감한 데이터를 밖으로 덜 보내도 되기 때문입니다. 이런 흐름을 흔히 온디바이스 AI라고 부르는데, 말 그대로 기기 안에서 AI가 돌아가는 방식입니다.

문제는 모델 하나를 띄우는 것만으로는 서비스가 되지 않는다는 점입니다. 사용자가 보낸 글과 사진을 어떻게 묶을지, 대화 기록을 어떻게 이어갈지, 모델이 외부 기능을 불러야 할 때는 어떤 규칙으로 처리할지까지 함께 설계해야 합니다. 이때 눈에 들어오는 저장소가 Google LiteRT-LM입니다.

겉으로만 보면 LiteRT-LM은 "구글의 빠른 온디바이스 AI 프레임워크"처럼 보입니다. 하지만 코드를 실제로 따라가 보면 더 중요한 역할은 따로 있습니다. 이 저장소는 질문을 그냥 모델에 밀어 넣는 도구가 아니라, 대화형 AI가 이해할 수 있는 입력 형태로 내용을 다시 정리해 주는 중간 정리층에 가깝습니다.

이번 글은 2026년 4월 22일 기준으로 저장소의 README, 빌드 가이드, 파이썬·코틀린 문서, 핵심 C++ 코드, CLI, 테스트, 공개 이슈와 PR을 함께 읽고 정리한 결과입니다. 먼저 README 내용을 쉬운 한국어로 옮기고, 그다음 실제 코드가 어떤 순서로 움직이는지 기사형으로 풀어보겠습니다.

1. 먼저 결론부터 보면

저장소 주소: google-ai-edge/LiteRT-LM
기준 브랜치: main
기준 커밋: 8032d2d7f3192857bae149fa45b4016ffd1f2a36
최신 안정 릴리스: v0.10.2, 2026년 4월 14일 공개
저장소 성격: 엔진 + SDK
가장 잘 맞는 독자: 안드로이드나 JVM 기반 온디바이스 AI 앱을 만드는 개발자

이 저장소를 한 문장으로 줄이면 이렇습니다. 기기 안에서 돌아가는 대화형 AI를 앱으로 만들기 위해 필요한 공통 실행판입니다.

여기서 SDK는 개발 도구 묶음을 뜻합니다. 즉, LiteRT-LM은 코드 몇 줄짜리 샘플이 아니라 실제 앱 개발에 붙일 수 있는 도구 상자에 가깝습니다.

또 하나 분명한 점은, 이 저장소가 모든 로컬 AI 문제를 한 번에 해결하는 만능 엔진은 아니라는 사실입니다.

범용성만 놓고 보면 llama.cpp 같은 프로젝트가 더 넓습니다. 대신 LiteRT-LM은 구글 AI 엣지 생태계와 안드로이드 쪽 제품화 흐름에 더 가까이 붙어 있습니다.

2. README를 쉬운 말로 번역하면

공식 소개: 구글의 오픈소스 온디바이스 LLM 실행 프레임워크
크로스플랫폼: 안드로이드, iOS, 웹, 데스크톱, 사물인터넷 기기까지 겨냥
하드웨어 가속: GPU와 NPU 사용 지향
멀티모달: 글뿐 아니라 이미지와 오디오도 함께 입력 가능
함수 호출: 모델이 미리 정한 기능을 불러 쓰는 방식 지원
빠른 시작: CLI 도구로 모델을 내려받아 바로 테스트 가능

README를 자연스럽게 옮기면 LiteRT-LM은 "기기 안에서 대형 언어 모델을 빠르게 실행하기 위한 구글의 오픈소스 틀"입니다. 여기서 프레임워크는 여러 기능이 묶인 기반 구조를 뜻하고, LLM은 긴 글을 읽고 답을 만드는 큰 언어 모델을 뜻합니다.

문서가 강조하는 첫 번째 축은 성능입니다. GPU와 NPU를 활용해 가능한 한 빠르게 돌리겠다는 이야기입니다.

GPU는 원래 그래픽 계산용 칩이지만 AI 계산에도 많이 쓰이고, NPU는 AI 계산에 더 특화된 반도체를 뜻합니다.

두 번째 축은 활용 범위입니다. LiteRT-LM은 글만 주고받는 단순 채팅을 넘어서 사진과 음성까지 함께 다루려는 방향을 잡고 있습니다. 또 모델이 계산기나 일정 조회 같은 외부 기능을 부를 수 있게 함수 호출도 지원한다고 적고 있습니다. 함수 호출은 모델이 직접 일을 처리하기 어려울 때 미리 등록한 기능을 대신 불러 쓰는 방식입니다.

세 번째 축은 접근성입니다. README는 코드를 길게 짜지 않아도 명령줄 도구인 CLI로 바로 시험해 볼 수 있다고 소개합니다. CLI는 마우스 화면 대신 터미널에 명령어를 쳐서 쓰는 방식입니다. 이 점 때문에 처음에는 단순 실행 도구처럼 보이지만, 실제 중심은 그 아래 있는 공통 엔진입니다.

3. 언어 지원을 보면 어디에 힘이 실렸나

코틀린: 안드로이드와 JVM 중심의 주력 경로
파이썬: 빠른 실험과 스크립트 작업용
C++: 가장 바닥에 있는 핵심 엔진
스위프트: 개발 중

언어 지원 구조를 보면 저장소의 우선순위가 보입니다. 코틀린은 안드로이드 앱과 자바 가상머신 환경에서 쓰는 언어인데, 문서와 예제가 가장 또렷하게 준비돼 있습니다. 초기화 방법, 스트리밍 답변, 샘플링 옵션, 함수 호출 흐름까지 비교적 자세히 설명돼 있습니다.

반면 파이썬은 빠른 실험에는 편하지만 아직 제약이 더 많습니다. 공식 문서가 리눅스와 macOS 중심으로 적혀 있고, 윈도우 지원과 GPU 가속은 예정 상태라고 분명히 밝혀 둡니다. README에는 파이썬을 stable이라고 적었지만, 실제 문서 톤은 조금 더 조심스럽습니다.

이 차이는 꽤 중요합니다. 같은 저장소라도 "어디까지 당장 믿고 쓸 수 있나"는 언어마다 다르기 때문입니다. LiteRT-LM은 적어도 2026년 4월 22일 기준으로는 코틀린과 안드로이드 경로가 가장 앞서 있고, 파이썬은 따라가는 구간이 남아 있다고 보는 편이 안전합니다.

4. 어려운 용어를 먼저 풀고 가면

온디바이스 AI: 인터넷 서버가 아니라 내 기기 안에서 AI가 실행되는 방식
추론: 모델이 입력을 읽고 답을 만들어 내는 과정
프롬프트 템플릿: 질문과 대화 기록을 모델이 좋아하는 형식으로 꾸미는 규칙
멀티모달: 글, 이미지, 오디오처럼 여러 종류의 입력을 함께 다루는 방식
임베딩: 글이나 이미지 정보를 숫자 묶음으로 바꾼 표현
실행 엔진: 실제로 계산을 돌리는 핵심 부분
함수 호출: 모델이 외부 기능을 불러 결과를 받아오는 방식
스트리밍: 답을 한꺼번에 주지 않고 조금씩 이어서 보내는 방식

LiteRT-LM을 어렵게 느끼게 만드는 이유는 코드 양보다 용어가 먼저 나오기 때문입니다. 그런데 뜻만 알고 보면 구조 자체는 아주 낯설지 않습니다. 사람으로 치면 자료 정리 담당, 실행 담당, 대화 기록 담당이 따로 나뉘어 있다고 생각하면 됩니다.

특히 이 글에서 자주 나오는 프롬프트 템플릿은 꼭 기억해 두면 좋습니다. 같은 질문이라도 모델마다 좋아하는 문장 구조가 다르기 때문에, 입력을 일정한 규칙으로 다시 정리해 주는 틀이 필요합니다. LiteRT-LM은 이 부분을 꽤 꼼꼼하게 다룹니다.

5. 코드 흐름은 이렇게 읽는 게 가장 쉽다

시작점: CLI나 앱 코드가 엔진을 만듦
엔진: 모델 파일, 토크나이저, 하드웨어 실행 준비
대화 계층: 대화 기록과 규칙 정리
세션: 이번 질문 한 번을 실제로 실행
출력: 조금씩 답을 보내거나 한 번에 반환

전체 흐름은 생각보다 단순합니다. 먼저 앱이나 CLI가 엔진을 만듭니다. 이 엔진은 모델 파일과 기본 자원을 메모리에 올리고, GPU나 NPU 같은 하드웨어를 쓸 수 있는지 확인합니다.

그다음은 대화 계층이 나섭니다. 여기서는 사용자가 보낸 질문만 보는 것이 아니라, 이전 대화 기록이 있는지, 함수 호출 규칙이 필요한지, 어떤 모델 형식에 맞춰 질문을 꾸며야 하는지를 함께 정리합니다. 즉, 대화 계층은 질문을 모델에 던지기 전 마지막 정리 담당입니다.

이후 세션 단계로 내려가면 실제 계산이 시작됩니다. 세션은 이번 질문 한 번을 처리하는 임시 작업 공간에 가깝습니다. 글은 글대로, 이미지와 오디오는 각자 숫자 표현으로 바꾼 뒤 다시 한 흐름으로 합쳐 모델에 넣습니다.

마지막에는 답을 내보냅니다. 이때 LiteRT-LM은 답을 한 번에 줄 수도 있고, 글자를 조금씩 흘려보내는 스트리밍 방식으로 줄 수도 있습니다. 함수 호출이 필요하면 여기서 끝나지 않고 다시 한 번 대화 계층으로 돌아가 다음 단계를 이어 갑니다.

6. 꼭 읽어야 할 코드 5곳

1) runtime/engine/litert_lm_main.cc

역할: 가장 짧은 전체 실행 예시
핵심 포인트: 엔진 생성 → 대화 생성 → 메시지 전송 → 결과 대기
쉬운 해석: README의 짧은 사용 예시는 결국 이 흐름을 따라감

이 파일은 LiteRT-LM을 실제로 어떻게 띄우는지 한 번에 보여 줍니다. 모델 자산을 준비하고, 엔진 설정을 만들고, 대화 객체를 만든 뒤, 사용자 메시지를 보내고, 끝날 때까지 기다리는 순서가 그대로 드러납니다. 그래서 이 파일은 사용법을 읽을 때 가장 먼저 보면 좋습니다.

2) runtime/core/engine_impl.cc

역할: 엔진의 실제 몸통
핵심 포인트: 모델 자원, 토크나이저, 실행기 준비
쉬운 해석: 무거운 준비 작업을 한 번 해 두고 여러 대화가 공유하는 구조

이 파일을 보면 엔진이 단순한 껍데기가 아니라는 사실이 보입니다. 모델을 읽고, 토크나이저를 붙이고, 글 전용 실행기와 필요하면 이미지·오디오 실행기까지 함께 준비합니다. 여기서 실행기는 실제 계산을 맡는 부분입니다.

또 한 가지 중요한 점은, 이 엔진이 공용 자원을 한 번만 올리려 한다는 점입니다. 무거운 준비를 대화마다 반복하지 않으려는 설계인데, 이 방식은 모바일 기기에서는 특히 중요합니다.

3) runtime/conversation/conversation.cc

역할: 대화 기록을 정리하는 핵심 층
핵심 포인트: 질문 형식 정리, 대화 기록 반영, 함수 호출 규칙 연결
쉬운 해석: 사용자의 말을 모델이 이해하기 쉬운 문장 묶음으로 다시 정리

이 파일은 LiteRT-LM의 색깔이 가장 잘 드러나는 곳입니다. 같은 질문이라도 모델마다 좋아하는 입력 형식이 다르기 때문에, 여기서는 대화 기록과 시스템 지시문, 함수 정보까지 다시 정리합니다. 이때 쓰이는 규칙이 바로 프롬프트 템플릿입니다.

쉽게 말하면, Conversation 계층은 "사용자 말"을 그대로 넘기지 않고 "모델이 읽기 좋은 형태"로 바꾸는 통역사 역할을 합니다. LiteRT-LM이 단순 실행기보다 한 단계 더 제품 지향적으로 보이는 이유도 여기에 있습니다.

4) runtime/core/session_basic.cc

역할: 이번 질문 한 번을 실제로 처리하는 구간
핵심 포인트: 입력 결합, 추론 실행, 중단 조건 확인
쉬운 해석: 글과 이미지와 오디오를 한 줄의 작업으로 합쳐 모델에 넣는 곳

세션 단계에서는 사용자가 보낸 내용이 실제 계산용 입력으로 바뀝니다. 글은 토큰이라는 작은 단위로 나뉘고, 사진과 오디오는 숫자 표현으로 바뀐 뒤 함께 묶입니다. 여기서 토큰은 문장을 잘게 나눈 AI 계산 단위입니다.

이 파일에서 눈에 띄는 또 하나의 포인트는 한 실행기에 여러 세션을 한꺼번에 무리해서 붙이지 않으려는 흔적입니다. 즉, LiteRT-LM은 보기보다 꽤 보수적으로 안정성을 챙기려는 구조를 갖고 있습니다.

5) runtime/conversation/model_data_processor/model_data_processor_factory.cc

역할: 모델 종류에 따라 처리 방법을 갈라 주는 곳
핵심 포인트: Gemma, Gemma 4, FunctionGemma, Qwen 계열별 규칙 선택
쉬운 해석: 모델마다 질문 받는 방식이 달라서 맞춤 규칙을 골라 주는 분기점

이 파일이 중요한 이유는 LiteRT-LM이 모든 모델을 똑같이 다루지 않는다는 사실을 보여 주기 때문입니다. 어떤 모델은 이미지 시작 표시가 다르고, 어떤 모델은 함수 호출 문법이 다릅니다. LiteRT-LM은 이런 차이를 모델 정보에 맞춰 자동으로 골라 쓰려 합니다.

즉, 이 저장소의 핵심 경쟁력은 단순 속도만이 아닙니다. 모델마다 다른 대화 규칙을 공통 엔진 안에서 정리해 주는 능력도 꽤 큰 비중을 차지합니다.

7. README와 실제 구현은 얼마나 맞을까

맞는 부분: 멀티모달, 함수 호출, 스트리밍 답변은 코드에서도 실제 확인 가능
맞는 부분: 코틀린·파이썬·C++ 지원 구조도 저장소 디렉터리와 문서에서 확인 가능
어긋나는 부분: README는 파이썬을 안정판처럼 보이게 쓰지만, 실제 문서는 더 보수적
어긋나는 부분: README 릴리스 요약은 v0.10.1 중심인데 최신 안정 버전은 v0.10.2
남은 질문: 공개 이슈를 보면 안드로이드 서비스 환경, NPU 초기화, Termux 같은 현실 문제는 아직 진행형

전체적으로 보면 README가 과장만 앞세우는 저장소는 아닙니다. 문서가 약속한 주요 기능은 실제 코드 경로로 연결됩니다. 이미지와 오디오 입력을 함께 받는 부분, 함수 호출 규칙을 붙이는 부분, 조금씩 답을 내보내는 부분이 모두 코드에 나타납니다.

다만 "안정적"이라는 말은 언어별로 받아들여야 합니다. 특히 파이썬 쪽은 문서가 더 조심스럽습니다. 코틀린 쪽은 실제 앱 개발에 바로 붙일 수 있게 설명이 길고 예제가 또렷하지만, 파이썬 쪽은 아직 빠른 실험용 성격이 더 강합니다.

이 차이를 읽는 가장 쉬운 방법은 공개 이슈를 보는 것입니다. 2026년 4월 22일 기준으로 안드로이드 서비스 하위 프로세스에서 대화 객체를 다시 만들 때 충돌이 난다는 보고, 특정 스냅드래곤 기기에서 NPU 초기화가 흔들린다는 보고, Termux용 배포 파일이 없다는 이슈가 올라와 있습니다. 다시 말해 LiteRT-LM은 가능성이 큰 저장소이지만, 운영 현장은 아직 다듬는 중입니다.

8. 직접 실행해 보려면

가장 쉬운 길: CLI 명령으로 바로 체험
가장 실용적인 길: 파이썬이나 코틀린 예제로 앱 흐름 확인
가장 무거운 길: 소스 빌드 후 C++ 데모 실행
확인 메모: 아래 예시는 공식 문서 기준 재구성 예시이며, 이 환경에서 실제 모델 실행까지는 하지 않음

처음부터 소스 빌드로 들어갈 필요는 없습니다. LiteRT-LM은 터미널에서 바로 써보는 방법, 파이썬으로 빠르게 붙여 보는 방법, 코틀린으로 앱 구조에 붙이는 방법이 나뉘어 있습니다. 독자 입장에서는 CLI → 파이썬 → 코틀린 또는 소스 빌드 순으로 보는 편이 가장 이해하기 쉽습니다.

1) 터미널에서 가장 빠르게 체험하는 방법

준비물: uv, 인터넷 연결, 내려받을 모델 이름
적합한 사람: 설치 후 바로 반응을 보고 싶은 독자
핵심 포인트: 코드 작성 없이 LiteRT-LM의 기본 흐름 확인 가능

uv tool install litert-lm

litert-lm run \
  --from-huggingface-repo=litert-community/gemma-4-E2B-it-litert-lm \
  gemma-4-E2B-it.litertlm \
  --prompt="서울의 대표 IT 기업을 세 곳 알려줘."

이 명령은 LiteRT-LM의 공식 README에 나온 가장 짧은 체험 경로에 가깝습니다. 모델 파일을 내려받고, 질문을 던지고, 답을 받는 기본 흐름을 한 번에 확인할 수 있습니다. 처음에는 이 단계만 성공해도 저장소가 어떤 느낌인지 감이 잡힙니다.

2) 파이썬으로 최소 예제를 돌리는 방법

준비물: 파이썬 환경, 모델 파일 경로
적합한 사람: 프로토타입을 빨리 확인하고 싶은 독자
핵심 포인트: 질문을 보내고 답을 조금씩 받는 흐름을 짧게 확인 가능

uv pip install litert-lm-nightly

import litert_lm

with litert_lm.Engine(
    "path/to/model.litertlm",
    backend=litert_lm.Backend.CPU,
) as engine:
    with engine.create_conversation() as conversation:
        for chunk in conversation.send_message_async(
            "Gemma 4를 한 문장으로 설명해 줘."
        ):
            for item in chunk.get("content", []):
                if item.get("type") == "text":
                    print(item["text"], end="", flush=True)
print()

이 예시는 파이썬 문서의 최소 대화 흐름을 바탕으로 다시 정리한 것입니다. 핵심은 세 줄입니다. 엔진을 만들고, 대화를 열고, 질문을 보내며 답을 조금씩 출력하는 구조입니다. 파이썬은 빠른 실험에는 좋지만, 2026년 4월 22일 기준으로는 GPU 가속과 윈도우 지원이 아직 예정 상태라는 점은 함께 봐야 합니다.

3) 코틀린에서 앱 흐름에 붙이는 방법

준비물: 코틀린 또는 안드로이드 프로젝트, 모델 파일
적합한 사람: 실제 앱 구조를 염두에 둔 개발자
핵심 포인트: 엔진 초기화 후 대화 객체를 만들어 동기 호출 또는 스트리밍 호출 가능

import com.google.ai.edge.litertlm.Backend
import com.google.ai.edge.litertlm.Engine
import com.google.ai.edge.litertlm.EngineConfig

fun main() {
  val engineConfig = EngineConfig(
    modelPath = "/path/to/model.litertlm",
    backend = Backend.CPU(),
  )

  Engine(engineConfig).use { engine ->
    engine.initialize()

    engine.createConversation().use { conversation ->
      println(conversation.sendMessage("Gemma 4를 한 문장으로 설명해 줘."))
    }
  }
}

코틀린 쪽은 LiteRT-LM이 실제 제품 코드에 들어갈 때 가장 자연스러운 경로로 보입니다. 엔진을 준비하고, 대화 객체를 만들고, 질문을 던지는 구조가 비교적 단순하게 드러납니다. 다만 안드로이드 앱에서는 초기화 시간이 길 수 있어 메인 화면을 막지 않는 백그라운드 처리가 권장됩니다.

4) 소스에서 직접 빌드해 C++ 데모를 보는 방법

준비물: Git, Bazel 7.6.1, Git LFS, 모델 파일
적합한 사람: 엔진 기여자나 네이티브 C++ 개발자
핵심 포인트: 앱 개발자라면 보통 여기까지 갈 필요 없음

git clone https://github.com/google-ai-edge/LiteRT-LM.git
cd LiteRT-LM
git fetch --tags
git checkout -b my-feature-branch v0.10.2
git lfs pull

export MODEL_PATH=/path/to/your_model.litertlm

bazel build //runtime/engine:litert_lm_main

bazel-bin/runtime/engine/litert_lm_main \
  --backend=cpu \
  --model_path=$MODEL_PATH

이 경로는 공식 빌드 문서에 나온 방법을 짧게 다시 묶은 것입니다. 중요한 점은, LiteRT-LM 공식 문서도 앱 개발자는 소스 빌드가 꼭 필요하지 않다고 선을 그어 둔다는 사실입니다. 다시 말해 이 방법은 일반 독자용이 아니라, 엔진 내부를 고치거나 깊게 실험하려는 사람에게 더 맞습니다.

9. 실제로 써보려면 어디까지 기대해야 하나

잘 맞는 경우: 안드로이드 앱에서 로컬 AI 기능을 붙이고 싶을 때
잘 맞는 경우: Gemma 계열 모델로 대화형 기능을 빠르게 실험할 때
잘 맞는 경우: 함수 호출이나 이미지 입력까지 한 구조에서 보고 싶을 때
조심할 경우: 플랫폼마다 똑같은 경험을 바로 기대할 때
조심할 경우: 동시에 많은 세션을 굴리는 서버형 용도
조심할 경우: 범용 모델 형식을 최대한 넓게 받아야 하는 경우

LiteRT-LM은 앱 개발 관점에서는 꽤 매력적입니다. 특히 구글 AI 엣지 흐름과 잘 맞고, 안드로이드 기반 제품을 염두에 둘 때는 자연스러운 선택지로 보입니다. 사진과 음성, 함수 호출까지 한 구조 안에서 연결하려는 방향도 분명합니다.

하지만 서버용 범용 엔진처럼 생각하면 기대가 엇갈릴 수 있습니다. LiteRT-LM은 어디까지나 기기 안에서 돌아가는 대화형 AI 앱 쪽에 더 가깝습니다. 여러 운영체제와 여러 모델 형식을 전부 같은 무게로 지원하는 프로젝트는 아닙니다.

10. 다른 프로젝트와 비교하면 위치가 더 선명하다

LiteRT-LM: 구글 AI 엣지 흐름에 맞춘 앱 지향 온디바이스 AI 엔진
llama.cpp: 가장 넓은 범용성을 앞세운 C·C++ 중심 로컬 AI 엔진
ExecuTorch: 언어 모델만이 아니라 비전과 음성까지 함께 다루는 온디바이스 AI 실행판
MLC LLM: 컴파일과 배포 최적화 색채가 강한 범용 LLM 배포 엔진

이 비교에서 LiteRT-LM이 돋보이는 지점은 분명합니다. 가장 넓은 범용성을 노리는 저장소라기보다, 실제 앱 안에 들어갈 대화형 AI 구조를 신경 쓰는 프로젝트라는 점입니다. 엔진, 대화 계층, 세션 계층을 나누고 모델별 규칙을 따로 정리하는 방식이 이를 보여 줍니다.

반대로 범용성이나 커뮤니티 폭은 다른 프로젝트가 더 강할 수 있습니다. 그래서 LiteRT-LM을 볼 때는 "가장 유명한 로컬 AI 엔진인가"보다 "안드로이드와 구글 AI 엣지 흐름에서 얼마나 잘 맞는가"를 먼저 보는 편이 맞습니다.

결론

Google LiteRT-LM은 단순히 모델을 빠르게 돌리는 저장소가 아닙니다. 더 중요한 역할은 대화형 AI가 실제 앱 안에서 움직이도록 입력과 규칙을 정리해 주는 것에 있습니다. 그래서 이 프로젝트는 실행 속도만이 아니라, 대화 기록 처리와 함수 호출 규칙, 멀티모달 입력 정리까지 함께 봐야 정확하게 읽힙니다.

코드를 따라가 보면 흐름은 의외로 선명합니다. 엔진이 무거운 준비를 맡고, 대화 계층이 기록과 규칙을 정리하고, 세션이 실제 계산을 수행합니다. 이 구조 덕분에 LiteRT-LM은 단순 데모를 넘어 앱 개발용 기반으로 읽을 가치가 생깁니다.

다만 2026년 4월 22일 기준으로는 아직 플랫폼별 성숙도가 고르게 맞춰진 상태는 아닙니다. 안드로이드와 코틀린 경로는 상대적으로 강하고, 파이썬과 일부 하드웨어 경로는 조금 더 시간을 두고 지켜볼 필요가 있습니다. 한마디로 정리하면 LiteRT-LM은 지금 당장 모든 곳에 쓰는 만능 엔진이라기보다, 구글 AI 엣지 흐름에서 온디바이스 AI 앱을 만들 때 가장 먼저 검토할 만한 저장소에 가깝습니다.

참고 자료

google-ai-edge/LiteRT-LM - GitHub 저장소, 2026년 4월 22일 확인
LiteRT-LM README - GitHub, 2026년 4월 22일 확인
LiteRT-LM Product Website - Google AI Edge, 2026년 4월 22일 확인
Build and Run from Source - GitHub, 2026년 4월 22일 확인
LiteRT-LM Python API - GitHub, 2026년 4월 22일 확인
LiteRT-LM Kotlin API - GitHub, 2026년 4월 22일 확인
runtime/engine/litert_lm_main.cc - GitHub, 2026년 4월 22일 확인
runtime/core/engine_impl.cc - GitHub, 2026년 4월 22일 확인
runtime/core/session_basic.cc - GitHub, 2026년 4월 22일 확인
runtime/conversation/conversation.cc - GitHub, 2026년 4월 22일 확인
runtime/conversation/model_data_processor/model_data_processor_factory.cc - GitHub, 2026년 4월 22일 확인
python/litert_lm_cli/main.py - GitHub, 2026년 4월 22일 확인
kotlin/java/com/google/ai/edge/litertlm/Conversation.kt - GitHub, 2026년 4월 22일 확인
tools/test/test_e2e_sanity_checks.py - GitHub, 2026년 4월 22일 확인
runtime/conversation/conversation_test.cc - GitHub, 2026년 4월 22일 확인
Issues · google-ai-edge/LiteRT-LM - GitHub, 2026년 4월 22일 확인
Pull requests · google-ai-edge/LiteRT-LM - GitHub, 2026년 4월 22일 확인
Releases · google-ai-edge/LiteRT-LM - GitHub, 2026년 4월 22일 확인
llama.cpp - GitHub, 2026년 4월 22일 확인
ExecuTorch - GitHub, 2026년 4월 22일 확인
MLC LLM - GitHub, 2026년 4월 22일 확인

저작자표시 비영리 변경금지 (새창열림)

'최신IT 정보 > IT 개발정보' 카테고리의 다른 글

개리 탄이 말한 AI 에이전트 운영법: 같은 실수를 막는 스킬화 전략 (0)	2026.04.22
AI가 CEO와 개발자로 일하는 회사, Paperclip AI (0)	2026.04.19
AI 에이전트는 어떻게 밤새 실험하고, 아침에 리뷰 가능한 코드만 남길 수 있을까? (feat. pi-autoresearch) (0)	2026.04.19

최신기술 A-Z

Google LiteRT-LM은 왜 주목받나: README 번역과 쉬운 코드 구조 해설

한눈에 보기

서론

1. 먼저 결론부터 보면

2. README를 쉬운 말로 번역하면

3. 언어 지원을 보면 어디에 힘이 실렸나

4. 어려운 용어를 먼저 풀고 가면

5. 코드 흐름은 이렇게 읽는 게 가장 쉽다

6. 꼭 읽어야 할 코드 5곳

1) runtime/engine/litert_lm_main.cc

2) runtime/core/engine_impl.cc

3) runtime/conversation/conversation.cc

4) runtime/core/session_basic.cc

5) runtime/conversation/model_data_processor/model_data_processor_factory.cc

7. README와 실제 구현은 얼마나 맞을까

8. 직접 실행해 보려면

1) 터미널에서 가장 빠르게 체험하는 방법

2) 파이썬으로 최소 예제를 돌리는 방법

3) 코틀린에서 앱 흐름에 붙이는 방법

4) 소스에서 직접 빌드해 C++ 데모를 보는 방법

9. 실제로 써보려면 어디까지 기대해야 하나

10. 다른 프로젝트와 비교하면 위치가 더 선명하다

결론

참고 자료

'최신IT 정보 > IT 개발정보' 카테고리의 다른 글

티스토리툴바

Google LiteRT-LM은 왜 주목받나: README 번역과 쉬운 코드 구조 해설

한눈에 보기

서론

1. 먼저 결론부터 보면

2. README를 쉬운 말로 번역하면

3. 언어 지원을 보면 어디에 힘이 실렸나

4. 어려운 용어를 먼저 풀고 가면

5. 코드 흐름은 이렇게 읽는 게 가장 쉽다

6. 꼭 읽어야 할 코드 5곳

1) runtime/engine/litert_lm_main.cc

2) runtime/core/engine_impl.cc

3) runtime/conversation/conversation.cc

4) runtime/core/session_basic.cc

5) runtime/conversation/model_data_processor/model_data_processor_factory.cc

7. README와 실제 구현은 얼마나 맞을까

8. 직접 실행해 보려면

1) 터미널에서 가장 빠르게 체험하는 방법

2) 파이썬으로 최소 예제를 돌리는 방법

3) 코틀린에서 앱 흐름에 붙이는 방법

4) 소스에서 직접 빌드해 C++ 데모를 보는 방법

9. 실제로 써보려면 어디까지 기대해야 하나

10. 다른 프로젝트와 비교하면 위치가 더 선명하다

결론

참고 자료

'최신IT 정보 > IT 개발정보' 카테고리의 다른 글

관련글

티스토리툴바