구글 ML Drift 공개, 작은 모델을 만드는 쪽에서 읽어봤어요

구글이 온디바이스 GPU 엔진을 따로 떼어 공개했어요

구글 AI 엣지 팀이 ML Drift를 Apache 2.0 라이선스로 공개했어요. 휴대폰과 노트북, 브라우저 안의 GPU에서 AI 모델을 돌리는 연산 엔진이에요. 구글의 온디바이스 런타임 LiteRT 밑에서 GPU 가속을 맡아 온 부품인데, 이번에 단독 라이브러리로도 쓸 수 있게 내놨어요. 유튜브 쇼츠, 구글 포토, 구글 미트, 크롬의 Gemini Nano 기능이 이미 이 엔진 위에서 돌고 있다고 해요.

이 발표를 Vons와 묶어 읽게 된 건 두 프로젝트가 같은 층을 건드리기 때문이에요. 저는 Vons라는 작은 판단 모델을 개발하고 있어요. 큰 모델이 세운 계획 안에서, 몇 개의 후보 중 하나를 고르거나 고르지 않겠다고 답하는 부품이에요. 모델 파일 64MiB 이하, CPU와 브라우저에서 돌아가는 것이 설계 목표고요. 그러니까 ML Drift가 손대는 문제, 즉 “작은 기기의 GPU에서 모델을 어떻게 돌리느냐”가 Vons의 실행 환경과 바로 맞닿아 있어요.

오늘은 ML Drift가 무엇을 풀었는지 먼저 설명하고, 그다음 Vons를 만드는 입장에서 이 발표가 어떻게 읽히는지 적어볼게요.

---

GPU마다 말이 달라요

데이터센터에서 AI를 돌릴 때는 같은 기종의 가속기가 줄지어 있어요. 어떤 칩에서 돌지 미리 알고 거기에 맞춰 최적화하면 돼요. 기기 쪽은 사정이 정반대예요. 앱을 배포하는 순간 그 앱이 어느 회사 GPU의, 어느 드라이버 버전 위에서 돌지 알 수 없거든요. 안드로이드는 주로 OpenCL과 OpenGL ES, 애플 기기는 Metal, 브라우저는 WebGPU를 써요. 같은 계산을 시키려 해도 GPU에게 말을 거는 언어가 네 가지인 셈이에요.

구글의 예전 해법은 TensorFlow Lite의 GPU 델리게이트¹였어요. 문제는 백엔드마다 셰이더²를 따로 유지하고, 텐서³를 GPU의 텍스처나 버퍼에 어떻게 담을지를 백엔드별 코드에 고정해 두었다는 점이에요. 백엔드가 셋이면 비슷한 코드를 세 벌 관리해야 했어요. 텐서 차원도 4차원까지로 묶여 있어서, 3차원 공간 데이터를 다루는 모델처럼 5차원 텐서가 필요한 경우에는 모양을 억지로 접어 넣는 편법을 써야 했고요.

ML Drift: Next-Gen GPU AI/ML Inference at the Edge- Google Developers BlogGoogle AI Edge has introduced ML Drift, a high-performance, universal GPU compute framework designed to accelerate on-device AI and machine learning inference. By abstracting the complexities of hardwdevelopers.googleblog.com

ML Drift가 내놓은 답은 네 갈래로 정리할 수 있어요.

텐서 가상화. 모델이 생각하는 텐서의 모양과, GPU 메모리에 실제로 놓이는 방식을 분리했어요. 셰이더는 템플릿으로 한 번만 쓰고, 어떤 GPU에서 어떤 저장 방식을 쓸지는 초기화 단계에서 코드를 생성하며 정해요. 저장소 설명에 따르면 이 공통 셰이더 언어를 UCL(Unified Compute Language)이라 부르고, 실행할 때 GLSL·MSL·WGSL로 각각 옮겨요. 통역사 한 명을 두고 네 나라 말로 옮기는 구조예요.

생성형 모델에 맞춘 실행. 대화형 언어 모델은 한 번 답하는 동안 일하는 방식이 두 번 바뀌어요. 입력 문장을 한꺼번에 읽는 프리필⁴ 단계는 연산량이 병목이고, 답을 한 토큰씩 내놓는 디코드 단계는 메모리에서 데이터를 퍼 오는 속도가 병목이에요. ML Drift는 단계가 바뀔 때 커널과 데이터 배치를 바꿔 끼우고, 디코드 단계에서는 KV 캐시⁵의 배치를 합성곱 연산에 맞추고 중간값을 커널 안에서 양자화해서 불필요한 메모리 왕복을 줄인다고 해요.

5차원 텐서와 커스텀 연산. 5차원 텐서를 기본으로 지원하고, 개발자가 셰이더를 직접 등록할 수 있는 커스텀 연산 틀을 열었어요. 여기에 코딩 에이전트용 SKILL.md 안내서를 함께 넣었다는 점이 눈에 띄어요. 에이전트가 커스텀 셰이더를 쓰고, 등록하고, 검증하는 데 몇 분이면 된다는 게 구글의 설명이에요.

브라우저 밖의 WebGPU. 원래 브라우저용으로 짠 WebGPU 백엔드를, 크롬의 WebGPU 구현체인 Dawn으로 컴파일해 브라우저 바깥에서도 돌게 했어요. 덕분에 윈도우와 리눅스에서는 DirectX나 Vulkan을 따로 상대하지 않고 같은 코드로 돌고, 맥에서는 기존 Metal 백엔드를 써요. 구글은 이 부분을 데스크톱 프리뷰라고 부르면서, 로컬에서 도는 코딩 에이전트를 쓰임새로 들었어요.

---

구글이 내놓은 숫자, 이렇게 읽어요

성과 수치도 함께 나왔어요. 유튜브 쇼츠는 영상 분할 기반 효과를 ML Drift로 옮겨 안드로이드와 iOS 양쪽에서 평균 프레임 지연을 최대 40% 줄였고, 구글 포토는 예전 GPU 델리게이트보다 최대 2초 빨라졌다고 해요. 어도비 라이트룸·포토샵 모바일의 피사체 선택 같은 기능은 기기 안 성능이 최대 30%, 스냅챗 렌즈의 얼굴·스타일 효과는 모델 지연이 30% 개선됐다고 하고요. Gemma 모델 벤치마크에서는 다른 프레임워크보다 메모리 부담이 최대 12% 적었다고 해요.

이 숫자들은 두 가지를 감안하고 읽어야 해요. 대부분이 ‘최대’예요. 어떤 기기, 어떤 모델에서 나온 최고치인지는 발표문에 나와 있지 않아요. 그리고 비교 대상이 대체로 구글 자신의 예전 엔진이에요. 메모리 12%는 ‘다른 프레임워크’라고만 적혀 있어서 무엇과 비교했는지 알 수 없어요.

같은 엔진을 두고 나온 숫자를 시간순으로 놓아 보면 이 점이 더 분명해져요. 2025년 5월 공개된 ML Drift 논문은 기존 오픈소스 GPU 추론 엔진보다 한 자릿수 배 수준(order of magnitude) 빠르다고 했어요. 구글이 올해 1월 LiteRT에 ML Drift를 붙이면서 밝힌 수치는 TFLite 대비 GPU 성능 1.4배였어요. 그리고 이번 발표의 앱별 수치는 30~40%예요. 비교 기준이 바뀔 때마다 숫자의 크기가 달라져요.

숫자보다 무겁게 읽어야 할 건 운영 쪽 문장이에요. 구글은 TFLite GPU 델리게이트에 더 이상 새 기능을 넣지 않겠다고 했어요. 기존 모델은 LiteRT의 ML Drift 가속기로 옮겨도 그대로 돌아간다고 하니, 사실상 세대 교체 공지예요. 안드로이드 쪽은 단독 LiteRT 패키지에서 바로 쓸 수 있고, 구글 플레이 서비스 안의 LiteRT에는 곧 들어간다고 해요. 하드웨어 쪽에서는 Arm, 인텔, 퀄컴이 함께 커널을 최적화했다고 밝혔어요.

크롬 이야기도 하나 짚을게요. 크롬은 Gemini Nano를 돌리는 내장 AI API(Prompt, Summarize, Writer)에 ML Drift를 붙였다고 해요. 지난 5월 102호에서 크롬이 사용자 동의 없이 4GB짜리 Gemini Nano를 내려받는 문제를 다뤘는데, 그 모델을 노트북 GPU에서 실제로 돌리는 엔진이 이번에 공개된 셈이에요. 엔진의 공개와 설치 동의는 별개의 문제라서, 이번 발표로 그 질문이 풀리지는 않아요.

---

Vons는 어디에 서 있나

여기서 제 프로젝트 이야기로 넘어갈게요. Vons 저장소 첫머리에 적어 둔 문장은 “Plan globally. Decide locally. Keep the host in control.”이에요. 계획은 큰 모델이 넓게 세우고, 결정은 가까운 곳에서 내리고, 실행 권한은 그 모델을 부르는 프로그램(호스트)이 쥔다는 뜻이에요.

구조는 이래요. 프런티어 모델 같은 플래너가 현재 상태와, 미리 정해진 몇 개의 후보를 넘겨요. Vons는 그중 하나를 고르거나 고르지 않겠다고(기권) 구조화된 답을 돌려줘요. 도구를 직접 실행하지 않고, 모델이 스스로 낸 확신도를 실행 허락으로 취급하지도 않아요. 실행과 정책, 사용자 동의는 전부 호스트 몫이에요. 연구 코드에는 한 번에 점수를 매기는 Direct 채점기와, 확산(diffusion) 방식으로 점수를 내는 조건부 Diffusion 채점기가 함께 들어 있어요.

실행 환경도 작게 잡았어요. 영어 우선, 모델 자산 64MiB 이하가 설계 목표이고, CPU·WASM에서 돌되 WebGPU는 선택 사항이에요. TypeScript SDK는 onnxruntime-web으로 브라우저 안에서 추론해요. WASM이든 WebGPU든 선언한 쪽으로만 돌고, 가속기를 쓸 수 없을 때 조용히 다른 쪽으로 넘어가지 않게 했어요. 크롬 확장 프로그램 버전도 만들어 9월 25일 크롬 웹스토어에 제출했고, 이 글을 쓰는 시점에는 심사 대기 중이에요.

INLEVEL9/Vons · Hugging FaceWe’re on a journey to advance and democratize artificial intelligence through open source and open science.huggingface.co

다만 Vons는 0.1.0 연구 프리뷰예요. 학습된 가중치는 배포하지 않았고, 브라우저 지연 시간과 메모리 사용량은 아직 공개 검토를 거친 수치가 없어요. 저장소에도 측정하지 않은 값은 0이 아니라 ‘없음’으로 읽어 달라고 적어 두었어요.

---

두 프로젝트가 만나는 지점

같은 층을 본다고 같은 문제를 푸는 건 아니에요. 둘을 나란히 놓으면 차이가 먼저 보여요.

구분	ML Drift	Vons
정체	GPU 연산 엔진	판단 모델과 SDK
겨냥하는 모델	영상 효과부터 Gemma급 생성형 모델까지	64MiB 이하 소형 채점기
답하려는 질문	이 모델을 어느 GPU에서든 빠르게 돌리려면	이 결정을 큰 모델 대신 가까이에서 내리려면
실행 경로	OpenCL·Metal·WebGPU·OpenGL ES	onnxruntime-web의 WASM·WebGPU

ML Drift가 공들인 최적화의 상당 부분, 그러니까 프리필·디코드 전환이나 KV 캐시 배치는 토큰을 이어서 생성하는 큰 모델을 위한 거예요. Vons는 후보를 한 번 채점하고 끝나는 모델이라 그 최적화가 직접 걸리지 않아요. 그리고 일반적으로 아주 작은 모델에서는 데이터를 GPU로 옮기고 커널을 띄우는 고정 비용이 계산 자체보다 클 수 있어서, GPU가 늘 CPU를 이기지는 않아요. Vons가 WebGPU를 기본값이 아닌 선택 사항으로 둔 데에는 이런 사정도 걸려 있어요.

반대로 정확히 맞물리는 지점도 있어요. Vons SDK에는 코딩 에이전트에 붙여 쓰는 로컬 MCP⁶ 서버가 들어 있는데, 여기서는 WebGPU 옵션을 일부러 막아 뒀어요. 터미널에서 띄운 자식 프로세스는 브라우저의 WebGPU 어댑터를 얻을 수 없거든요. 그래서 Vons에서 WebGPU를 쓰려면 브라우저나 확장 프로그램 안에서 SDK를 직접 불러야 해요.

ML Drift가 Dawn으로 한 일이 바로 이 벽 너머에 있어요. 브라우저용 WebGPU 코드를 브라우저 밖에서 그대로 돌게 했으니까요. 구글이 데스크톱 프리뷰의 쓰임새로 로컬 코딩 에이전트를 든 것과, Vons의 MCP 서버가 바로 그 자리에서 WebGPU를 내려놓은 것은 같은 틈을 양쪽에서 본 장면이에요. 다만 Vons는 지금 ONNX Runtime 경로 위에 있어서, ML Drift를 쓰려면 모델을 LiteRT 형식으로 변환하거나 ML Drift의 C++ API로 연산 그래프를 직접 짜야 해요. 엔진이 열렸다고 바로 옮겨 탈 수 있는 구조는 아니에요.

---

오스왈드의 시선

제가 늘 하는 말이 있어요. 모든 사람, 모든 일에 초지능이 필요한 건 아니에요. 일과 환경에 맞는 모델이 따로 있어요.

제 작업 방식도 그렇게 나뉘어 있어요. 전체 계획과 오케스트레이션, 처음 설계도는 지금도 Claude나 GPT-6에 맡겨요. 대신 오래 걸리고 반복이 많은 일은 DeepSeek이나 GLM으로 넘겼어요. Vons는 이 분업을 한 단계 더 아래로 내려 보내는 실험이에요. 큰 모델이 후보를 추리면, 그중 무엇을 고를지는 기기 안의 작은 모델이 정하고, 실제로 실행할지는 호스트가 정해요.

ML Drift 발표를 이 관점에서 읽으면, 구글은 같은 분업을 하드웨어 쪽에서 하고 있어요. 셰이더를 짜는 일은 SKILL.md를 든 코딩 에이전트에게 넘기고, 기기 GPU의 파편화처럼 작은 팀이 혼자 감당하기 어려운 층은 공용 엔진으로 덮었어요. 모델을 작게 만드는 건 만드는 사람의 몫이지만, 그 모델을 수십 종의 GPU에서 돌리는 일까지 혼자 떠안지 않아도 되는 길이 하나 더 생긴 거예요.

다만 엔진이 열렸다고 결정권까지 열리는 건 아니에요. 102호의 크롬 사례에서 봤듯이, 모델이 기기에 얼마나 쉽게 올라가느냐와 그 모델이 무엇을 해도 되는지를 누가 정하느냐는 다른 질문이에요. Vons가 확신도를 허락으로 쓰지 않고 실행을 호스트에 남겨 둔 것도 두 번째 질문에 대한 설계예요.

---

마치며

ML Drift는 기기마다 다른 GPU 언어를 하나로 통역하는 엔진이고, 구글은 이걸 TFLite 이후의 기본 경로로 정했어요. 작은 모델을 만드는 쪽에서 이 발표는 성능 숫자보다, 기기 GPU로 가는 길목이 하나로 정리되고 있다는 소식으로 읽혀요.

---

💬 구독자님의 일 중에서, 큰 모델을 부르지 않고 기기 안의 작은 모델이 판단해도 될 것 같은 일이 하나 있다면 무엇인가요? 댓글로 들려주세요.

📨 온디바이스 AI나 에이전트 설계를 고민하는 동료가 있다면 이 글을 전해 주세요.

---

참고자료 & 더 읽기

핵심 출처

• Google AI Edge Team, “ML Drift: Next-Gen GPU AI/ML Inference at the Edge”, 2026. ··· 이번 글의 1차 자료예요. 아키텍처 변경, 제품별 성과 수치, TFLite GPU 델리게이트 지원 중단 공지가 모두 여기서 나왔어요.
• Google AI Edge, “google-ai-edge/ml-drift”, GitHub. ··· UCL, 텐서 가상화, 지원 백엔드 구성을 정리한 공식 README예요.
• Jiuqiang Tang 외, “Scaling On-Device GPU Inference for Large Generative Models”, arXiv:2505.00232, 2025.5. ··· ML Drift의 설계를 처음 공개한 논문이에요. ‘한 자릿수 배’ 주장의 출처예요.
• Paul Krill, “Google’s LiteRT adds advanced hardware acceleration”, InfoWorld, 2026.1.28. ··· LiteRT에 ML Drift가 붙으면서 나온 ‘TFLite 대비 1.4배’ 수치의 출처예요.

Vons

• Kwangseob Ahn, “inlevel9-com/Vons”, GitHub. ··· 연구 프리뷰의 범위와 한계, 논문·기술 보고서 링크가 정리돼 있어요.
• “@vons/decision-sdk README”, GitHub. ··· WASM·WebGPU 선택 방식과 MCP 서버가 WebGPU를 막아 둔 이유가 적혀 있어요.

함께 읽으면 좋은 지난 호

• 102호 「크롬의 4GB AI 모델이 드러낸 설치 동의 문제」 ··· 이번에 공개된 엔진이 크롬 안에서 돌리는 바로 그 모델의 이야기예요.
• 178호 「Kimi K3 2.8조 파라미터, 오픈 웨이트인데 왜 못 돌릴까」 ··· 서버랙이 필요한 거대 모델과, 기기로 내려가는 소형 모델이 반대 방향으로 가는 계산을 다뤘어요.

필자 안광섭 (오스왈드)은 세종대학교 겸임교수, INLEVEL9 전략 컨설턴트입니다. 경력, 연구, 저서와 최신 활동은 저자 소개에서 계속 갱신합니다. 최근 소식 · 2026년 8월: 2026 세종도서 교양부문 우수도서 선정.

📝 용어 설명

각주

1. 델리게이트(delegate): 모델 실행 중 일부 연산을 GPU 같은 가속기에 넘겨 대신 계산하게 하는 TensorFlow Lite의 연결 부품이에요. ↩

2. 셰이더(shader): GPU 위에서 실행되는 작은 프로그램이에요. 원래 그래픽 화면을 그리는 데 쓰였는데, 지금은 AI 연산을 GPU에 시키는 데도 쓰여요. ↩

3. 텐서(tensor): AI 모델이 다루는 다차원 숫자 묶음이에요. 사진 한 장이면 가로·세로·색상의 3차원, 여러 장을 묶으면 4차원이 되는 식이에요. ↩

4. 프리필(prefill)과 디코드(decode): 언어 모델이 질문 전체를 한 번에 읽어 들이는 단계가 프리필, 답을 한 토큰씩 이어서 만들어 내는 단계가 디코드예요. ↩

5. KV 캐시(KV cache): 언어 모델이 앞에서 읽은 내용을 다시 계산하지 않도록 중간 결과를 저장해 두는 메모리 공간이에요. 문맥이 길수록 커져요. ↩

6. MCP(Model Context Protocol): AI 에이전트가 외부 도구나 데이터에 연결되는 방식을 표준화한 규약이에요. Vons의 MCP 서버는 에이전트가 Vons에게 판단을 요청하는 창구 역할을 해요. ↩