온디바이스 AI를 만들 때 가장 흔한 착각은 “작은 모델을 쓰면 된다”입니다. 실제로는 모델 크기만 줄인다고 제품이 되지 않습니다. 지연 시간, 메모리 사용량, 배터리, 기기별 가속기 차이, 양자화 후 품질 저하가 한꺼번에 따라옵니다.
Google Developers Blog는 2026년 5월 14일 Arm Scalable Matrix Extension 2(SME2)와 Google AI Edge 최적화 사례를 공개했습니다. 사례 모델은 Stability AI의 stable-audio-open-small입니다. Google은 LiteRT, XNNPACK, Arm KleidiAI, AI Edge Quantizer, Model Explorer를 사용해 PyTorch 모델을 모바일 실행 환경으로 옮기는 Convert → Optimize → Deploy 흐름을 설명했습니다.
공개 글에서 중요한 숫자는 두 가지입니다. Arm SME2는 행렬 연산 중심 워크로드에서 최대 5배 빠른 추론을 제공할 수 있다고 소개됐고, Google 사례에서는 DiT 하위 모듈에 동적 INT8 양자화를 적용해 3배 성능 개선과 4배 메모리 사용량 감소를 얻었다고 설명했습니다. 이 숫자는 특정 모델과 설정의 결과이므로 모든 앱에 그대로 적용되지는 않습니다. 그래도 모바일 AI 개발자가 봐야 할 방향은 분명합니다.
모바일 AI 최적화는 오랫동안 GPU, NPU, DSP 같은 전용 가속기 중심으로 설명됐습니다. 문제는 기기 생태계가 너무 파편화되어 있다는 점입니다. 특정 NPU에 맞춘 최적화는 성능은 좋지만 지원 기기와 유지보수 범위가 좁아질 수 있습니다.
CPU는 반대로 거의 모든 기기에 있습니다. 성능 한계가 문제였지만, Arm SME2처럼 CPU 클러스터 안에 행렬 연산을 위한 전용 기능이 들어오면 선택지가 달라집니다. 개발자는 “고성능 전용 가속기만 지원할 것인가”와 “넓은 기기 커버리지를 확보할 것인가” 사이에서 덜 극단적인 결정을 할 수 있습니다.
특히 생성형 AI 워크로드는 행렬 연산 비중이 높습니다. 이미지, 오디오, 텍스트 생성 모두 대량의 행렬 곱 연산을 반복합니다. 따라서 CPU가 이 연산을 더 잘 처리하면 작은 모델뿐 아니라 실사용 모델의 배포 전략도 바뀝니다.
Google이 제시한 흐름은 연구 코드에서 앱 배포까지의 간극을 줄이는 데 초점이 있습니다. 많은 팀이 PyTorch 모델을 학습하거나 가져온 뒤, 모바일 배포 단계에서 멈춥니다. 변환 도구가 복잡하고, 양자화 품질을 확인하기 어렵고, 성능 병목을 눈으로 찾기 힘들기 때문입니다.
이번 사례의 흐름은 세 단계입니다.
실무에서 중요한 점은 저수준 어셈블리나 기기별 커스텀 코드를 직접 작성하지 않는다는 것입니다. 물론 성능 튜닝을 완전히 피할 수는 없습니다. 하지만 병목을 찾고, 양자화 안전 구간을 확인하고, 런타임 가속을 연결하는 과정이 한 흐름으로 묶이면 팀의 반복 속도가 빨라집니다.
모바일 배포에서 INT8 양자화는 흔한 선택입니다. 하지만 모든 레이어를 일괄 양자화하면 품질이 크게 깨질 수 있습니다. Google 글에서도 stable-audio-open-small 같은 오디오 생성 모델은 단순히 전체 가중치를 양자화하는 방식이 심각한 품질 손실을 만들 수 있다고 설명합니다.
그래서 필요한 것은 “어디를 줄일 수 있는가”를 확인하는 과정입니다. Model Explorer의 노드 데이터 오버레이는 어떤 연산자가 계산량이 큰지, 어떤 부분이 양자화에 안전한지 시각적으로 확인하게 해줍니다. 공개 사례에서는 DiT 하위 모듈의 레이어들이 낮은 오류 값을 보여 동적 INT8 양자화 대상으로 선택됐습니다.
개발팀은 이 접근을 그대로 제품 프로세스로 가져올 수 있습니다. 양자화 전후를 비교할 때 단순히 모델 파일 크기만 보지 말고 다음 항목을 같이 봐야 합니다.
온디바이스 AI를 도입하려는 앱 팀은 먼저 “모든 것을 기기에서 처리할지”를 정하지 말아야 합니다. 더 현실적인 질문은 “어떤 작업이 기기에서 처리될 때 제품 가치가 커지는가”입니다.
예를 들어 온디바이스 처리가 유리한 작업은 다음과 같습니다.
반대로 대형 추론, 긴 문맥 처리, 서버 데이터와의 조합이 필요한 작업은 클라우드가 더 적합할 수 있습니다. 실무에서는 하이브리드가 일반적입니다. 기기에서는 전처리, 빠른 추천, 초안 생성, 필터링을 처리하고, 서버에서는 무거운 추론과 장기 저장을 담당합니다.
Google과 Arm의 숫자는 유용하지만, 그대로 제품 성능으로 해석하면 위험합니다. 공개된 3배 성능 개선, 4배 메모리 감소는 특정 모델의 특정 하위 모듈에서 나온 결과입니다. 앱 전체 성능은 전처리, 후처리, UI 렌더링, 저장소 접근, 네트워크 상태까지 영향을 받습니다.
따라서 자체 벤치마크를 반드시 만들어야 합니다. 최소한 다음 환경을 나눠 측정하세요.
또한 평균값만 보면 안 됩니다. 사용자는 평균 지연 시간이 아니라 최악의 몇 번을 기억합니다. p95 또는 p99 지연 시간, 실패율, 앱 강제 종료율을 함께 봐야 합니다.
온디바이스 AI 최적화를 시작한다면 다음 순서를 권장합니다.
온디바이스 AI의 방향은 “모든 모델을 폰에 넣자”가 아닙니다. 사용자 경험, 비용, 개인정보, 오프라인 요구사항이 만나는 지점에 작은 모델을 정확히 배치하는 것입니다. 다음 기능 중 서버 없이도 빨라지면 사용자 만족도가 즉시 올라갈 작업은 무엇인가요?
출처: Google Developers Blog, “Accelerating on-device AI: A look at Arm and Google AI Edge optimization”, 2026-05-14.
