Apple Core AI 프레임워크 — 온디바이스 AI 배포의 새 기준

Apple Core AI 프레임워크 — WWDC 2026

Apple Core AI 프레임워크 — 온디바이스 AI 배포의 새 기준

Apple silicon 위 AI 추론, 새 이름이 붙었다

Apple이 WWDC 2026에서 Core AI를 공개했습니다. 이름은 단순해 보여도, 실체는 "모델을 앱 안에서 실행"하는 API 한두 개가 아니라 PyTorch 모델을 .aimodel로 바꾸고, 압축하고, 디버깅하고, 캐시와 사전 컴파일까지 묶은 온디바이스 AI 배포 체계입니다. 단순 추론 API가 아닌 통합 배포 체계라는 점이 핵심입니다. 추론 자체보다 배포 흐름을 표준화하는 데 방점이 찍혀 있습니다.

iOS 27.0+, iPadOS 27.0+, macOS 27.0+ Beta부터 동작합니다. 결정적 차이는 데이터를 기기 밖으로 보내지 않는다는 점입니다. 사용자의 입력은 디바이스 안에서만 처리되고, 모델 weight와 추론 결과도 기기를 벗어나지 않습니다. Core AI가 등장하면서 Apple 플랫폼의 AI 스택은 Core AI, Core ML, MLX 셋이 동시에 존재하는 파편화 국면으로 접어들었고, 신경망 외 결정 트리나 tabular 모델은 여전히 Core ML을 권장합니다. 본격적으로 채택할 팀은 지원 OS 범위와 기존 Core ML 모델의 이전 비용을 함께 따져봐야 합니다. OS 27 미만을 지원해야 한다면 Core ML 유지가 현실적입니다.

PyTorch에서 Swift 앱까지, 개발 흐름 한 번에

Core AI는 기존 PyTorch 워크플로를 그대로 흡수합니다. torch.export로 PyTorch 모델을 exported program으로 빼고, Core AI PyTorch Extensions의 TorchConverter로 .aimodel을 만듭니다. 그다음 Core AI Optimization으로 Apple silicon에 맞춘 압축을 적용합니다.

Swift 쪽 API는 의외로 얇습니다. AIModel로 .aimodel을 로드하고, InferenceFunction이 단일 계산 그래프를 들고 있고, NDArray가 입력과 출력을 다룹니다. run 호출에 NDArray를 넣으면 추론 결과가 돌아옵니다. Xcode에서 .aimodel 파일을 직접 열어 모델 크기, 연산 분포, 메타데이터, 동적 shape(?로 표시되는 차원)까지 한 화면에서 확인할 수 있습니다.

state, cache, memory layout — 추론 지연을 잠재우는 세 가지

Transformer처럼 입력이 길어지는 모델은 추론 시간이 단계마다 누적됩니다. GeekNews 예제에서 두 Snake를 모두 AI로 돌리자 게임이 점점 느려졌고, Instruments에서 추론 구간이 시시각각 길어지는 게 포착됐습니다. 단일 forward pass는 가벼워도, 입력 길이가 누적되면서 토큰별 재처리가 선형보다 빠르게 늘어난다는 점이 본질적인 문제입니다.

해결책은 세 가지입니다. 첫째, state로 key/value cache를 구현합니다. InferenceFunction.run의 states 인자에 mutable view를 전달하면 모델이 입력을 읽고 제자리에서 캐시를 갱신합니다. 둘째, NDArray의 최적 메모리 레이아웃을 그대로 할당하고, 출력 버퍼를 미리 잡아 추론 중 재할당을 막습니다. 셋째, 비동기 값으로 여러 추론 함수를 파이프라인화합니다. Snake 예제에서 이 세 가지를 함께 적용하자 Instruments의 지연 증가 곡선이 거의 평평해졌습니다.

추가로, 입력 차원의 동적 길이는 ?로 표시되는 동적 shape로 모델에 명시됩니다. padding으로 묶지 말고 가변 길이 자체를 처리하는 편이 메모리 낭비를 줄이고, attention 마스크도 함께 캐시에 보관됩니다. 이렇게 하면 같은 모델을 다양한 시퀀스 길이에서 호출해도 Instruments의 latency 곡선이 한 자릿수 ms 단위로 안정됩니다.

모델 배포: 다운로드와 specialization을 어떻게 보여줄 것인가

.aimodel은 모든 Apple 기기에서 실행 가능한 소스 표현이지만, 실제 실행 전에는 기기와 OS 버전에 맞는 specialization이 필요합니다. 큰 모델은 첫 specialization에 수 초에서 수십 초가 걸릴 수 있어, 사용자 흐름 중간에 끼워 넣는 건 위험합니다. spinner를 띄우는 위치 선정이 모델 자체보다 중요합니다. 첫 화면에 spinner를 두면 이탈률이 급격히 올라갑니다.

Apple이 제시한 패턴은 두 단계입니다. 첫째, coreai-build로 개발 머신에서 일부 컴파일을 미리 수행합니다. 기기에서 specialization은 여전히 필요하지만 남은 작업이 줄어 첫 실행 지연이 짧아집니다. 둘째, AIModelCache로 캐시 항목을 프로그래밍 방식으로 관리합니다. 필요 없는 항목 삭제, 항목 유지 정책, 같은 app group의 여러 앱 간 캐시 공유까지 제어할 수 있습니다. SAM 3 예제에서는 첫 실행에 model load와 큰 specialization이 동시에 일어나 spinner가 오래 표시됐는데, 이 두 단계로 그 시간을 사용자 눈에 보이지 않는 곳으로 밀어 넣을 수 있었습니다. 결국 specialization을 백그라운드 자원으로 다루는 설계가 차이를 만듭니다.

최적화와 디버깅: 어디를 건드려야 품질이 무너지지 않는가

Core AI Optimization은 INT4, INT8, FP4, FP8 가중치 압축과 calibration 또는 QAT 기반 양자화 API를 제공합니다. SAM 3 baseline이 32비트에서 3GB 이상이었던 자산이 4비트 압축 후 430MB 근처로 줄어든 사례가 대표적입니다.

문제는 모든 계층을 공격적으로 압축하면 출력으로는 알기 어려운 품질 저하가 생긴다는 점입니다. SAM 3 예제에서는 4비트 압축을 전 계층에 적용하자 가려진 꽃 하나가 검출되지 않았고, 어느 계층이 원인인지 출력만 봐서는 짚을 수 없었습니다. Core AI Debugger는 변환된 모델과 원래 PyTorch 모델의 내부 값을 비교하고, PSNR이 낮은 sync point를 가리킵니다. SAM 3에서는 낮은 PSNR 지점 대부분이 detector decoder에 집중됐고, detector block은 전체 파라미터의 4%뿐이었습니다. detector를 양자화 대상에서 빼자 baseline 품질이 돌아왔습니다. 즉, 압축 이득이 작은 블록은 의도적으로 제외하는 전략이 효과적입니다.

그래서 우리도 따라 할 수 있는가

Core AI는 모델을 앱에서 실행하는 API보다 넓은 범위의 온디바이스 AI 배포 체계입니다. macOS 27+ 이상에서 PyTorch 모델을 다루는 팀이라면, 모델 준비 단계와 사용자 경험 단계를 분리해 설계하는 것이 핵심입니다. 모델 준비는 변환·압축·디버깅이고, UX는 다운로드·캐시·사전 컴파일·specialization입니다. iOS 26 이하를 여전히 지원해야 한다면 Core ML이 동시에 살아 있어야 하고, MLX는 연구 워크플로우 쪽에 남는 구도입니다. 세 프레임워크의 경계는 모호해 보이지만 역할은 또렷합니다.

도입 순서는 결국 같게 수렴합니다. 작은 모델로 첫 실행 흐름을 먼저 굳히고, 모델 크기와 캐시 정책을 함께 키우는 단계로 갑니다. 첫 실행 UX 설계는 모델 자체보다 중요합니다. 첫 specialization이 어디서 일어나는지, Background Assets 다운로드를 어떤 화면에서 노출할지, 캐시 만료 정책은 어떻게 가져갈지를 코드 작성 이전에 정해두는 편이 안전합니다. 큰 모델을 한 번에 번들하기보다, 잘게 나눠 점진적으로 활성화하는 전략이 사용자 이탈을 가장 적게 만듭니다. 작은 모델부터 시작해 첫 실행 흐름을 먼저 굳히고, 모델 크기와 캐시 정책을 함께 키우는 순서가 가장 안전한 도입 경로입니다.