ExecuTorch: 마이크로컨트롤러부터 스마트폰까지 PyTorch 모델을 그대로 배포하기 위한 통합 PyTorch 네이티브 엣지 AI 배포 프레임워크 (feat. Meta, MLSys 2026)

9bow · 5월 18, 2026, 6:30오전

ExecuTorch 소개: 마이크로컨트롤러부터 스마트폰까지 PyTorch 모델을 그대로 배포하기 (feat. Meta, MLSys 2026)

On-Device AI 배포는 왜 이렇게 어려운가

스마트폰의 실시간 번역, 스마트 글래스의 음성 비서, 자율주행차의 인식 모듈, 그리고 환자 모니터링 장비. 이 모든 응용은 한 가지 공통점을 갖습니다. 클라우드 왕복(round-trip)이 허용되지 않는 지연 시간과 프라이버시 요구사항 때문에, AI 추론이 반드시 기기 내에서(on-device) 일어나야 한다는 것입니다. 모델 아키텍처의 발전과 NPU(Neural Processing Unit)와 같은 전용 가속기의 등장은 이러한 온디바이스 추론을 점점 더 현실적으로 만들고 있습니다.

문제는 "연구실에서 만든 PyTorch 모델을 어떻게 실제 기기로 옮길 것인가" 입니다. PyTorch는 전 세계 AI 연구의 70\% 이상을 차지하지만, 정작 모델을 단말기에 배포하려는 순간 ML 엔지니어는 PyTorch 생태계를 떠나 플랫폼별 도구로 갈아타거나, 성능과 이식성을 맞바꾸는 타협을 받아들여야 합니다. 기존 접근법들은 모두 나름의 한계를 안고 있었습니다.

모델 변환 기반 프레임워크(ONNX Runtime, TensorFlow Lite)는 학습과 배포를 중간 표현(intermediate representation)으로 분리합니다. 하지만 변환 단계에서 발생하는 미묘한 의미(semantic) 차이는 배포 이후에야 드러납니다. 예를 들어 PyTorch의 QAT(Quantization-Aware Training)가 ONNX의 양자화 의미와 정확히 일치하지 않으면, 기기에서 비로소 수치 불일치(numerical mismatch)가 발견되어 디버깅에 막대한 시간이 듭니다.

모델 전용 런타임(llama.cpp, vLLM)은 특정 아키텍처에 강하게 특화된 최적화로 뛰어난 성능을 내지만, 학습 프레임워크 바깥에서 모델을 완전히 재구현해야 합니다. 이는 연구와 프로덕션 사이의 반복 주기(iteration loop)를 단절시킵니다. vLLM은 Python 런타임까지 요구해 임베디드 환경에는 아예 사용할 수 없습니다.

벤더 종속 런타임(Apple CoreML, Qualcomm SNPE, Apple MLX)은 특정 플랫폼에서 최상의 성능을 보여주지만, 멀티 플랫폼 지원을 위해서는 결국 동일 모델의 병렬 구현이 필요합니다. 컴파일러 기반 접근(TVM, MNN)은 별도의 툴체인과 튜닝 절차, 디버깅 워크플로를 새로 익혀야 합니다. PyTorch Mobile / TorchScript는 PyTorch 네이티브 배포를 시도했지만 높은 메모리 풋프린트와 좁은 하드웨어 지원에 발목 잡혔습니다.

ExecuTorch의 발상 전환: "실험 동등성(Experimentation Parity)"

이 연구가 제안하는 ExecuTorch의 핵심 아이디어는 단순하면서도 근본적입니다. 모델을 배포할 다른 환경으로 옮기는 대신, PyTorch 안에서 배포 동작 자체를 미리 검증할 수 있게 만들자는 것입니다. 저자들은 이를 "실험 동등성(Experimentation Parity)" 이라는 설계 원칙으로 정의합니다. 양자화, 하드웨어 위임, 성능 같은 배포 단계의 행동을 연구자가 PyTorch에서 그대로 재현하고 검증한 뒤, 동일한 그래프를 단말기에서 실행하게 하는 것입니다.

마치 비행기 조종사가 실제 비행 전 시뮬레이터에서 모든 조건을 재현해 보는 것과 비슷합니다. 기존에는 시뮬레이터(PyTorch)와 실제 항공기(배포 런타임)의 거동이 달라 비행 중에야 결함이 드러났다면, ExecuTorch는 시뮬레이터와 항공기를 같은 그래프 위에서 돌립니다.

ExecuTorch는 PyTorch 2.0과 함께 도입된 torch.compile, torch.export 기술을 활용하여 모델을 이식 가능한 표현으로 변환하고, 이를 단말기에서 실행 가능한 바이너리로 컴파일합니다. 이때 백엔드 위임(Backend Delegation) 인프라가 모델의 각 부분을 가장 적합한 하드웨어 가속기로 보냅니다. 또한 AOT(Ahead-of-Time) 그래프 수준 컴파일을 수행하여 인터프리터 오버헤드와 런타임 의존성을 TorchScript 대비 크게 줄입니다.

ExecuTorch는 이미 Meta의 앱 패밀리에서 하루 수십억 건의 추론을 처리하고 있으며, Reality Labs의 Ray-Ban 스마트 글래스와 같은 제품에서도 동작합니다. 0.01 W의 마이크로컨트롤러부터 800 W의 데이터센터급 클러스터까지, 12개 하드웨어 백엔드를 지원합니다.

핵심 아키텍처: AOT 익스포트 스택과 런타임 스택

ExecuTorch는 크게 두 단계로 구성됩니다. AOT 익스포트 스택은 PyTorch와 긴밀히 통합되어 torch.export로 계산 그래프를 캡처하고 torch.fx 그래프 패스 인프라로 연산자 융합(operator fusion)과 같은 최적화를 적용합니다. 양자화, 서브그래프 위임, 메모리 계획 같은 변환은 모두 사전(ahead-of-time)에 수행되므로 런타임은 미리 최적화된 그래프 실행에만 집중할 수 있습니다. 런타임 스택은 컴팩트하고 커스터마이즈 가능한 실행 환경을 제공하며, 사용자는 대상 기기에 맞는 커널과 백엔드 라이브러리만 링크하여 빌드 크기를 최소화합니다.

torch.export와 Edge Dialect

torch.export 는 PyTorch Python 코드를 정적 그래프 자료구조인 Export IR로 변환합니다. Export IR은 Torch FX 그래프이지만 (1) 형상 안정성(shape soundness) - 각 연산자 의미에 맞는 형상 규칙을 만족함, (2) 그래프 정규화 - Python 의미가 제거되고 정의된 연산자 집합으로만 구성됨, (3) 텐서 메타데이터 가용성, (4) 프로그램 메타데이터 가용성 - 원본 torch.nn.Module 계층과 Python 호출 스택을 보존, 이라는 강한 보장을 가집니다.

ExecuTorch는 Export IR 위에 더 제한적인 Edge Dialect를 정의합니다. Edge Dialect는 (1) 변이(mutation)와 별칭(aliasing)이 없는 완전한 함수형 그래프, (2) 약 $300$개 미만의 "Core ATen" 연산자로 제한, (3) 명시적인 dtype 및 메모리 포맷 특화(dim order 개념 포함)라는 세 가지 추가 속성을 가집니다. Core ATen 연산자 집합을 $300$개 미만으로 좁힌 것은 결정적인 설계 선택입니다. 모든 신규 백엔드와 커널 라이브러리가 구현해야 하는 표면적이 작아져, 새로운 하드웨어 지원 비용을 극적으로 낮춥니다.

Edge Dialect의 함수형 제약은 KV-cache writeback처럼 in-place 업데이트가 필수적인 경우에 한해 후반 lowering 단계에서 완화됩니다. 위임(delegate)도 lowering 중에는 제약에서 벗어날 수 있지만, 원본 Edge Dialect 그래프와 동등한 계산을 보장해야 합니다.

양자화: PyTorch 2 Export와 Eager 모드의 이중 트랙

양자화(Quantization) 는 단말기 배포의 핵심 기술로, 모델 크기와 추론 지연을 크게 줄여 줍니다. ExecuTorch는 TorchAO 위에 구축되어 SpinQuant 같은 다양한 알고리즘을 지원합니다. 두 가지 워크플로가 있습니다.

PyTorch 2 Export Quantization은 Export IR을 변환하여 PTQ(Post-Training Quantization)와 QAT를 모두 지원합니다. 그래프는 먼저 torch.export로 캡처되며, 각 백엔드는 자체 Quantizer 클래스의 어노테이션 API로 연산자 또는 패턴에 양자화 의도를 표시합니다. Eager Mode Quantization은 nn.Module 인스턴스 위에서 직접 작동하여 대상 서브모듈(예: linear, embedding)의 가중치 텐서를 양자화된 텐서 서브클래스로 변환하거나 양자화 변형으로 교체합니다.

백엔드 위임 인터페이스

Backend Delegate는 모델 서브그래프를 특수 프로세서에서 실행하게 하는 추상화입니다. 각 위임자는 (1) 호환되는 Edge Dialect 서브그래프를 백엔드 고유 표현("delegate blob")으로 lowering하는 AOT 컴파일러, (2) 대상 프로세서에서 delegate blob을 역직렬화하고 실행하는 런타임 라이브러리를 제공합니다. 위임자는 자신이 가속할 수 있는 연산자를 명시하고, 파티셔너(partitioner)는 지원되는 연산자로 구성된 서브그래프를 찾아 위임자에게 라우팅합니다. 이 덕분에 백엔드는 자신이 실행할 수 없는 서브그래프를 절대 받지 않습니다.

PTE 파일 포맷과 가중치 공유

ExecuTorch는 PTE(PyTorch Edge) 파일 포맷을 도입합니다. PTE는 최소 런타임 오버헤드와 파일 크기를 위해 설계되었습니다. 프로그램 컴포넌트는 각 모델 메서드(forward, encode 등)의 실행 계획을 명령(instruction) 리스트로 표현하며, KernelCall은 연산자를 호출하고 DelegateCall은 위임된 서브그래프 실행을 호출합니다. 인수는 공유 EValue 리스트에 대한 인덱스로 표현됩니다. 그래프 표현 대신 선형 실행(Jump 명령으로 제어 흐름 처리)을 사용하여 계산 오버헤드를 줄입니다.

세그먼트 컴포넌트는 독립적으로 로드/해제 가능한 정렬된 메모리 블록을 담습니다. 큰 delegate blob을 담은 세그먼트는 모델 초기화 후 해제하여 피크 메모리를 줄일 수 있습니다. 페이지 정렬된 세그먼트는 추가 복사 없는 직접 mmap 접근을 지원합니다.

ExecuTorch는 또한 PTD 포맷을 정의하여 명명된 텐서와 위임 데이터를 저장합니다. 이를 통해 PTE 파일 간 가중치 공유, 온디바이스 학습을 위한 체크포인팅, 프로그램과 데이터의 독립 배포가 가능합니다.

가중치 공유는 두 가지 방식으로 작동합니다. (1) 다중 메서드 PTE는 LLM의 prefill과 decode 같은 서로 다른 메서드가 단일 파일 내에서 데이터 세그먼트를 공유합니다. (2) 프로그램-데이터 분리는 PTE 프로그램이 외부 PTD 가중치 파일을 참조하여 모델 간(예: LoRA 어댑터들이 파운데이션 가중치를 공유) 공유가 가능합니다.

온디바이스 파인튜닝

ExecuTorch는 forward와 backward 실행 그래프를 모두 lowering하여 온디바이스 학습을 지원합니다. 업데이트된 가중치는 새 PTD 체크포인트로 저장됩니다. 저자들은 CIFAR-10 데이터셋으로 Android 기기에서 분류 모델(XNNPACK 백엔드)을 파인튜닝하는 것을 검증했습니다.

런타임: 극단적으로 가벼운 실행 환경

핵심 런타임 이식성

ExecuTorch의 핵심 런타임은 C++17을 대상으로 하며, 최대한의 이식성을 위해 동적 메모리 할당, 동기화 프리미티브, 예외에 의존하지 않습니다. 서버, 스마트폰, 베어 메탈 임베디드 시스템(POSIX, Windows, bare-metal)을 모두 지원합니다. 모든 메모리는 MemoryManager 추상화를 통해 사용자가 제공해야 하며, 이는 SRAM이나 DRAM 같은 특수 메모리 영역에 텐서 데이터를 배치할 수 있게 해 줍니다. FreeableBuffer 추상화는 버퍼 포인터와 사용자 정의 해제 함수를 래핑하여 수명을 관리합니다.

플랫폼 추상화 계층(PAL) 은 로깅, 시간 질의, 프로세스/시스템 panic 같은 시스템 연산을 오버라이드할 수 있게 합니다. DataLoader 인터페이스는 파일 I/O나 mmap 같은 커스텀 PTE 로딩 전략을 지원합니다.

런타임 오버헤드: TorchScript 대비 70배 감소

이것이 ExecuTorch의 가장 인상적인 정량적 결과 중 하나입니다. mul + add로 구성된 최소 모델을 ExecuTorch와 TorchScript 기반 PyTorch Mobile Interpreter로 비교했을 때, FlatBuffer 기반 역직렬화로 5.3\times 속도 향상을, 런타임 초기화에서 동적 연산자 해상(resolution) 제거로 37.4\times 향상을 얻었습니다. 추론당 총 사이클 수는 PyTorch Mobile의 654{,}009 사이클에서 ExecuTorch의 9{,}272 사이클로, $70.5\times$의 속도 향상을 보였습니다. 특히 프레임워크 오버헤드 자체는 4{,}325\times 감소했습니다.

커널과 백엔드

두 가지 CPU 커널 라이브러리

ExecuTorch는 두 가지 CPU 커널 라이브러리를 함께 제공합니다. Portable Kernel Library는 외부 의존성이 없는 Core ATen 연산자 참조 구현으로, 언제든 사용 가능한 기능적이고 정확한 구현을 제공합니다. Optimized Kernel Library는 SIMD intrinsic과 SLEEF, OpenBLAS 같은 최적화 수학 라이브러리를 사용해 선별된 연산자를 가속하며, 이식성 대신 성능을 택합니다.

선택적 빌드(Selective Build)

전체 portable 라이브러리는 약 2.3 MiB로, 자원이 제약된 응용에는 너무 큽니다. Selective Build 기능은 사용자가 빌드에 포함할 커널 부분집합을 지정할 수 있게 해 바이너리 크기를 MiB에서 KiB 단위로 줄입니다. dtype 선택적 빌드는 실제 추론 중 사용될 데이터 타입의 커널 코드 경로만 보존하여 크기를 더 줄입니다.

다양한 백엔드

ExecuTorch는 현재 5개의 주요 프로덕션 백엔드를 제공하며 (MediaTek, OpenVINO, Samsung Exynos, NXP eIQ Neutron, CUDA, Metal이 개발 중), 각 백엔드는 특정 하드웨어에 최적화되어 있습니다.

XNNPACK CPU 백엔드

Google의 XNNPACK 라이브러리 위에 구축된 고성능 CPU 백엔드입니다. Arm의 KleidiAI와 같은 보완 라이브러리도 사용됩니다. int8 추론(정적/동적 양자화)과 LLM 워크로드용 채널별 및 그룹별 int4 가중치를 지원하며, 가중치 캐싱 메커니즘이 모델 재로드와 LoRA 가중치 공유를 효율화합니다.

Vulkan 백엔드

모바일 GPU 추론을 위해 설계되었으며, 현재 $76$개의 ATen 연산자를 구현하는 GLSL 컴퓨트 셰이더 라이브러리로 추론을 수행합니다. 하나의 연산자가 여러 컴퓨트 셰이더에 매핑되며, 런타임에 텐서 저장 타입, 메모리 레이아웃, Vulkan 확장, 입력 형상, GPU 아키텍처를 보고 선택됩니다.

Arm Ethos-U NPU 백엔드

최신 Ethos-U85를 포함한 Arm Ethos-U NPU를 타깃합니다. Edge Dialect 서브그래프를 TOSA(Tensor Operator Set Architecture) IR로 변환한 뒤, Vela 컴파일러(Regor 백엔드)가 NPU 최적화 바이너리로 컴파일합니다. symmetric int8과 혼합 정밀도 양자화를 지원합니다.

Qualcomm QNN 백엔드

Qualcomm AI Engine Direct 위에 구축되어 Hexagon DSP를 타깃하며, A8W8과 A16W4 양자화 포맷을 지원합니다. SpinQuant, Range-Setting, 공유 SeqMSE 관찰자(observer)를 포함한 TorchAO의 많은 양자화 알고리즘과 호환됩니다.

CoreML 백엔드

Apple 플랫폼에서 CPU, GPU, Neural Engine(ANE) 추론을 모두 지원합니다. CoreML을 직접 사용할 때 가능한 대부분의 기능(8-bit 정적 양자화, 가중치 전용 양자화, compute unit 및 정밀도 선택, 정적/열거형/동적 형상 등)을 노출합니다.

DevTools: ETRecord와 ETDump로 디버깅

ExecuTorch는 온디바이스 배포 프로파일링과 디버깅을 위한 도구 모음을 제공합니다. 워크플로의 핵심은 두 가지 아티팩트입니다. ETRecord는 익스포트 중 생성되어 Edge Dialect 그래프와 런타임 이벤트를 원본 Python 소스 코드에 연결하는 디버그 메타데이터를 담습니다. ETDump는 실행 중 생성되어 연산자 지연, 메모리 수명, 위임 및 커널 호출 이벤트, 선택적으로 중간 텐서 값까지 캡처합니다.

Inspector API는 이 데이터를 보고 분석하는 도구를 제공합니다. 개발자는 지연 시간 데이터로 느린 연산자와 위임 내부의 병목을 식별하고, 모델이 잘못된 출력을 낼 때 중간 텐서 값을 참조 모델과 비교하여 오류 출처를 파악합니다.

LLM 가속 최적화

LLM은 ExecuTorch의 모듈형 transformer-decoder 정의(Llama 3.2, Qwen3 지원)나 Hugging Face Transformers + Optimum ExecuTorch를 사용해 익스포트할 수 있습니다. Hugging Face 텍스트 생성 리더보드 모델의 80\% 이상을 Optimum ExecuTorch로 익스포트할 수 있습니다.

LLM의 prefill과 decode 단계를 단일 그래프로 표현하기 위해, torch.export는 시퀀스 길이 차원을 동적(dynamic)으로 표시합니다. 정적 형상이 필요한 백엔드(예: QNN)의 경우 두 개의 별도 모델이 익스포트됩니다.

여기에서는 세 가지 핵심 LLM 최적화가 CPU 추론을 가속합니다:

Flash Attention: 중간 attention 텐서의 물질화 비용을 회피하여 긴 컨텍스트의 메모리 풋프린트와 추론 지연을 줄입니다.
Quantized KV cache와 attention: 채널별 양자화된 KV cache와 양자화된 attention으로 긴 컨텍스트의 메모리를 줄입니다.
Efficient sliding window attention: Gemma 3와 같은 로컬-글로벌 attention 모델에서, cache 위치를 별도 배열로 추적해 causal mask를 KV cache 시프트 없이 생성하여 비싼 메모리 이동을 피합니다.

QNN과 CoreML 백엔드는 speculative decoding도 토큰 생성 처리량 최적화로 지원합니다.

MCU 배포: 11 KiB RAM으로 MNIST 분류기 실행

ExecuTorch의 휴대용 런타임과 선택적 빌드는 마이크로컨트롤러급 타깃에도 배포 가능합니다. 저자들은 Raspberry Pi Pico 2(Arm Cortex-M33, 520 KiB SRAM, 4 MiB Flash)에서 MNIST 분류기를 두 가지 구성으로 시연했습니다. Portable Kernel Library를 사용한 FP32 추론과, Arm Ethos-U 백엔드를 통해 CMSIS-NN을 사용한 int8 추론입니다.

선택적 빌드는 FP32 구성에서 총 코드 크기를 1{,}322 KiB에서 253 KiB로 (5.2\times), int8 CMSIS-NN 구성에서 1{,}248 KiB에서 203 KiB로 (6.2\times) 줄입니다. ExecuTorch 런타임 자체는 $13$–$26$ KiB만 차지합니다.

Component	FP32 Portable	INT8 CMSIS-NN
Memory Planned Arena	101.2	3.8
Method Allocator	$\sim 2$–$3$	$\sim 2$–$3$
Kernel Registry	0.2	0.2
Other BSS	4.2	4.2
Total RAM	\sim 108	\sim 11

CMSIS-NN을 통한 int8 양자화는 FP32 대비 16.46\times 추론 가속(3.5 ms vs 57.6 ms), 모델 크기 3.6\times 감소, RAM 10\times 감소를 달성하여 총 RAM 사용량을 약 11 KiB로 낮춥니다. 이는 Pico 2의 520 KiB SRAM 예산 안에 충분히 들어옵니다.

성능 평가: 모바일에서의 LLM과 비전 모델

저자들은 Samsung Galaxy S25 Ultra(Snapdragon 8 Elite), Google Pixel 9 Pro XL(Tensor G4), Apple iPhone 15 Pro에서 ExecuTorch를 llama.cpp, ONNX Runtime, LiteRT, CoreML과 비교했습니다($2026$년 $3$월 $31$일 기준 최신 버전).

LLM 성능

Qwen3 0.6B, Llama 3.2 1B, Phi4 Mini를 256 프롬프트 / 256 생성 토큰으로 벤치마크했습니다. ExecuTorch의 XNNPACK 위임은 ONNX, LiteRT 대비 두 기기 모두에서 강한 성능을 보였습니다. Samsung Galaxy S25에서 llama.cpp는 Qwen3와 Phi4 Mini의 decode 처리량이 더 높은데, 이는 단일 토큰 decode에 더 효율적인 attention 구현 덕분입니다(prefill은 비등).

ExecuTorch의 Vulkan 위임은 모든 모델을 전체 그래프 위임(full graph delegation) 으로 실행할 수 있어, CPU로 fall back되는 연산자가 하나도 없습니다. Pixel 9 Pro XL에서는 Vulkan 위임이 llama.cpp의 prefill 처리량을 크게 앞섭니다(llama.cpp는 Adreno GPU용 컴퓨트 셰이더만 최적화되어 있기 때문). 흥미롭게도 Pixel에서 group size $32$일 때 prefill 처리량이 128 대비 급격히 떨어지는데, 이는 양자화 매개변수 재페치 시 GPU 캐시 스래싱이 발생하는 임계점이 있음을 시사합니다.

ExecuTorch의 QNN 위임은 Llama 3.2 1B의 prefill 처리량에서 QAIRT 대비 더 강하며, decode에서는 QAIRT가 약간 우위입니다(per-channel vs per-group 양자화 차이로 추정). QNN 위임도 전체 그래프 위임으로 실행되며 CPU fallback이 없습니다.

비전 모델 성능

MobileNet V3, ResNet50, ViT-B/16, Swin-T를 벤치마크했으며, $10$회 워밍업 후 $200$회 추론의 평균, p5, p95 지연을 측정했습니다. CPU 추론에서는 XNNPACK 위임이 LiteRT와 ONNX 대비 매우 강한 성능을 보였습니다.

GPU 추론에서 Vulkan 위임은 MobileNet V3와 ResNet50(양자화 및 fp16 변형 모두)을 전체 그래프 위임으로 실행합니다. ViT-B/16의 경우 attention 마스킹 파이프라인의 $4$개 미지원 연산자(총 72 인스턴스)가 모델을 $25$개 Vulkan 파티션으로 나누지만, 그래프 단절 오버헤드(CPU-GPU 텐서 복사)는 실행 지연의 $5%$–$6%$에 불과합니다.

NPU 추론에서 QNN 위임은 LiteRT와 ONNX 대비 매우 강한 성능을 보여줍니다. LiteRT와 ONNX의 경우 NPU 실행 제공자가 모델 그래프의 제한된 노드만 점유하여 추론 대부분이 CPU에서 실행되었기 때문입니다. iPhone 15 Pro에서는 ExecuTorch의 CoreML 위임이 네이티브 CoreML과 동등하거나 약간 더 나은 성능을 보였으며, 네 모델 모두에서 결과를 생성한 유일한 구성이었습니다(Swin-T 포함). 이는 ExecuTorch의 위임 오버헤드가 사실상 무시할 만함을 확인시켜 줍니다.

한계점과 향후 연구 방향

저자들은 ExecuTorch의 한계를 솔직하게 밝히고 있습니다:

모델 익스포트 가능성: ExecuTorch는 torch.export에 의존하기 때문에, 데이터 의존 제어 흐름(예: beam search의 동적 분기), 동적 형상(예: dynamic LSTM, Mask R-CNN), 커스텀 C++/CUDA 커널(예: FlashAttention)을 사용하는 모델은 그대로 익스포트하기 어렵습니다. 이런 모델은 torch.cond, torch.scan, torch.while_loop, torch.where 같은 고차 연산자로 재작성하거나, 추적 불가능한 연산을 커스텀 op로 래핑하거나, torch._check 어설션을 추가해야 합니다.

하드웨어 재타깃성: AOT 컴파일은 특정 하드웨어에 최적화하지만, Android 생태계의 하드웨어 다양성(Qualcomm, MediaTek, Samsung NPU 등)으로 인해 개발자는 기기 능력을 질의하고 적절한 모델 파일을 선택하거나, 여러 하드웨어별 모델 파일을 하나의 APK에 번들해야 합니다. 이는 런타임 재타깃 솔루션(ONNX, LiteRT)보다 엔지니어링 복잡도가 높지만, AOT 최적화의 이득과의 트레이드오프입니다.

데스크톱/노트북 지원: ExecuTorch는 XNNPACK, OpenVINO, QNN 등으로 노트북 추론을 가속하고 있으며, PyTorch의 AOTInductor 기술을 활용한 CUDA, Metal 백엔드 지원을 실험 중입니다. 희소성(Sparsity) : ExecuTorch의 IR은 dense 값과 mask 텐서로 희소 가중치를 표현할 수 있지만, 엣지 타깃에서 하드웨어 가속 희소 커널(2:4 structured sparsity)이 아직 널리 사용 가능하지 않아 향후 과제로 남아 있습니다.

ExecuTorch는 "연구 속도와 엣지 배포 요구사항 사이에서 선택할 필요가 없으며, 통합된 워크플로가 둘 다 제공할 수 있다"는 것을 보여 주는 중요한 이정표입니다. PyTorch에서 작성한 모델이 변환이나 재구현 없이 마이크로컨트롤러부터 스마트폰까지 동일한 그래프로 배포되는 미래, 그리고 그 사이의 모든 행동을 PyTorch 안에서 검증할 수 있는 미래를 가깝게 만들고 있습니다.

설치 및 사용 방법

ExecuTorch는 pip으로 간단히 설치할 수 있습니다.

pip install executorch

PyTorch 모델을 ExecuTorch로 익스포트하는 기본 흐름은 다음과 같습니다.

import torch
from executorch.exir import to_edge
from torch.export import export

class MyModel(torch.nn.Module):
    def forward(self, x):
        return x + 1

model = MyModel().eval()
example_inputs = (torch.randn(1, 3, 224, 224),)

# 1. PyTorch 모델을 ATen Dialect로 익스포트
aten_dialect = export(model, example_inputs)

# 2. Edge Dialect로 변환
edge_program = to_edge(aten_dialect)

# 3. ExecuTorch 프로그램으로 변환 후 직렬화
executorch_program = edge_program.to_executorch()
with open("model.pte", "wb") as f:
    f.write(executorch_program.buffer)

자세한 시작 가이드, 백엔드별 튜토리얼, LLM 내보내기 예제는 공식 문서와 GitHub 저장소를 참고하세요.

ExecuTorch - A Unified PyTorch Solution to Run AI Models On-Device 논문

ExecuTorch GitHub 저장소

이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다! (기본은 Weekly지만 Daily로 변경도 가능합니다.)

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~