Core AI: Apple Silicon에서 모델 실행하기

Apple의 온디바이스 AI 스택에는 빠진 단이 하나 있었습니다. Foundation Models는 봉인된 채로 무료로 제공되는 시스템 LLM을 제공합니다. Core ML은 변환된 고정 모델을 실행하며, 변환기가 하드웨어 결정을 대신 내려줍니다. MLX는 직접 임베드하는 배열 프레임워크와 직접 선택하는 모델을 제공합니다. iOS 27은 이 세 가지 모두 아래에 있는 단을 추가합니다. 바로 Core AI인데, 한 줄로 요약된 개요는 “Apple silicon에서 앱 안의 AI 모델을 실행한다”입니다.¹ 이것은 모델 실행 표면이며, 상위 계층의 기본값을 받아들이는 대신 전문화(specialization), 캐싱, 추론 스케줄링을 직접 제어하고자 할 때 손을 뻗는 곳입니다.

세션 324에서 Apple은 Core AI를 온디바이스 Apple Intelligence를 구동하는 바로 그 추론 프레임워크로, 이제는 여러분 앱의 지능을 위해 개방된 것으로 자리매김합니다.¹⁵

이 자리매김이 중요한 이유는 Core AI가 대부분의 앱이 사용해야 할 추상화 아래에 자리하기 때문입니다. Apple은 이를 Apple silicon을 염두에 두고 설계되어, 앱이 CPU, GPU, Neural Engine 전반에 걸쳐 최신 모델 아키텍처와 추론 기법을 사용할 수 있게 하며, 일반적인 작업은 간단하게 처리하면서도 필요할 때는 모델 전문화, 캐싱, 추론 성능에 대해 더 많은 제어권을 주는 Swift API를 제공한다고 설명합니다.¹ 이 글의 주제는 이렇습니다. 어디서 어떻게 실행할지 명시적으로 제어하면서 실행하고 싶은 모델이 있을 때 Core AI에 손을 뻗고, 그렇지 않을 때는 Core ML이나 Foundation Models에 머무르라는 것입니다. 이 프레임워크는 기본 선호가 아니라 구체적인 필요에 보답합니다.

TL;DR / 핵심 요약

• Core AI는 전문화되지 않은 AIModelAsset(모델의 구조와 메타데이터를 저렴하게 검사)과 전문화된 AIModel(디바이스에서 추론 실행)을 분리하며, AIModelCache가 디바이스별 산출물을 보관하고 AssetError가 asset 작업 실패를 나타냅니다.²³⁶⁴
• 추론 데이터는 NDArray를 통해 흐릅니다. 이는 스칼라 값들의 다차원 배열이며, 형태(shape), 스칼라 타입, 메모리 레이아웃 기대치를 고정하는 NDArrayDescriptor로 기술됩니다.⁵⁷
• SpecializationOptions를 통해 ComputeUnitKind(CPU, GPU, 또는 Neural Engine)로 하드웨어를 타기팅하고, 비동기 작업을 ComputeStream에 스케줄링합니다.⁸⁹¹⁰
• InferenceFunction은 가중치와 버퍼를 소유하며 추론을 실행합니다. InferenceFunctionDescriptor를 사용하면 그 입력, 출력, 상태 시그니처를 먼저 검사할 수 있습니다. 이 함수는 Sendable이므로 동시에 실행할 수 있습니다.¹⁴¹³
• 모델은 디스크의 .aimodel 번들에서 로드되며, Core AI는 프레임워크와 함께 준비, 변환, 디버깅 도구를 제공합니다. 전문화와 스케줄링에 대한 명시적 제어가 필요할 때 Core AI에 손을 뻗으세요. 그렇지 않다면 Core ML이나 Foundation Models에 머무르세요.²¹

전체 설계를 끌고 가는 두 단어: Asset과 Model

Core AI가 가장 먼저 여러분에게 체화하라고 요구하는 것은, 디스크 위의 모델과 추론을 실행하는 모델은 서로 다른 객체이며, 하나를 다른 하나로 전문화하는 것은 비용이 크다는 점입니다. 프레임워크는 각각에 타입을 부여합니다.

AIModelAsset은 “전문화되지 않은 소스 모델 asset”입니다.² 디스크 위의 .aimodel 번들 URL로부터 생성하며, 전문화 비용을 치르지 않고 모델을 검사하는 데 사용합니다. Apple은 이 분리가 존재하는 이유를 분명히 밝힙니다. 모델 asset을 사용하면 비용이 큰 작업인 전문화를 수행하지 않고도 모델 정보를 질의할 수 있다는 것입니다. asset에서는 함수 시그니처, 입력 및 출력 설명, 연산 및 저장 타입, 그리고 작성자가 제공한 메타데이터를 읽을 수 있습니다. 할 수 없는 것은 추론 실행입니다. asset은 오직 검사용입니다.²

// Call shape is illustrative; confirm the exact initializer against Apple's docs.
let asset = try AIModelAsset(url: bundleURL)   // an .aimodel bundle on disk
// Inspect signatures, input/output descriptions, compute and storage types,
// and author-provided metadata — without specializing.

AIModel은 나머지 절반입니다. “디바이스에서 추론을 실행하기 위한 전문화된 모델”이지요.³ AIModel은 현재 디바이스의 하드웨어에 최적화된 전문화된 .aimodel asset을 나타내며, 디스크에서 asset을 로드하여 생성합니다.³ asset은 이 모델은 무엇인가?에 답하고, model은 지금 여기서 실행하라에 답합니다. 둘 사이의 비용 비대칭이야말로 API가 어느 쪽을 원하는지 명시하도록 강제하는 이유입니다. 백 개의 후보 모델을 검사해 하나를 고르는 일은 asset만 만든다면 저렴하지만, 검사할 때마다 전문화가 일어난다면 파멸적일 것입니다.

전문화는 디바이스별 산출물을 만들어내며, 그 산출물에는 머무는 곳이 있습니다. 바로 AIModelCache, “추론을 위한 전문화된 모델 산출물을 저장하는 캐시”입니다.⁶ 이 캐시는 모델이 추론 함수를 실행하기 위해 로드하는 최적화된 디바이스별 산출물을 보관하며, Apple은 각 캐시 항목이 특정 .aimodel 또는 .aimodelc와 전문화 조합으로 형성된 전문화된 asset을 담는다고 언급합니다.⁶ 실용적으로 읽으면 이렇습니다. 전문화는 매번 실행할 때마다 반복하고 싶은 작업이 아닙니다. 캐시는 비용이 큰 단계를 한 번만 일어나게 하고, 그 이후로는 저렴한 단계(캐시된 산출물 로드)가 일어나게 하는 Core AI의 방식입니다.

asset 작업이 잘못되면(번들 누락, 잘못된 형식의 .aimodel, 읽을 수 없는 파일) Core AI는 AssetError, “모델 asset 작업 중에 발생하는 오류”를 표면화합니다.⁴ 다른 모든 I/O 경계를 다루듯 다루세요. asset은 디스크에 있고, 디스크 작업은 실패하며, 타입 시스템은 catch를 어디에 둬야 할지 정확히 알려줍니다.

텐서: NDArray와 그 디스크립터

추론은 숫자를 안으로 들이고 숫자를 밖으로 내보내며, 그 숫자를 담는 Core AI의 컨테이너가 NDArray, “모델 추론에 사용되는 스칼라 값들의 다차원 배열”입니다.⁵ NumPy ndarray, MLX 배열, 또는 MLMultiArray를 다뤄봤다면 그 발상의 형태는 익숙합니다. 정의된 레이아웃을 가진 스칼라들의 n차원 블록이지요. NDArray는 자신의 형태(shape)와 나머지 기술적 속성으로 정의된 레이아웃에 데이터를 저장합니다.⁵

짝을 이루는 타입은 NDArrayDescriptor, “배열의 형태, 스칼라 타입, 메모리 레이아웃 기대치에 대한 기술”입니다.⁷ 디스크립터는 계약입니다. Apple의 설명은 직설적입니다. 디스크립터는 여러분이 추론 함수에 제공하는 배열 값에 대한 기대치를 담고 있으며, 대부분의 기대치는 엄격합니다. 디스크립터가 .float32 스칼라 타입을 지정하면, 여러분이 제공하는 배열은 반드시 .float32를 사용해야 합니다.⁷ 함수가 원하는 형태와 타입을 추측하지 마세요. 함수의 디스크립터에 물어보고 거기에 따르세요.

// Call shape is illustrative; confirm exact property/method names against Apple's docs.
let inputDescriptor = function.descriptor.inputs.first!   // an NDArrayDescriptor
// The descriptor fixes shape, scalar type, and layout; the array you build
// must satisfy those expectations (e.g. .float32 means .float32).

여기서 얻는 설계 교훈은 asset/model 분리와 같은 결입니다. Core AI는 비용이 큰 값 객체 앞에 일관되게 저렴한 기술(description) 객체를 둡니다. 먼저 할당하고 추론 시점에 불일치를 발견하는 대신, 디스크립터를 읽어 계약을 파악한 다음 그것을 만족하는 NDArray를 할당합니다. 특히 이미지 입력의 경우, Core AI는 ImageDescriptor, “이미지의 차원과 픽셀 포맷에 대한 기술”도 정의하므로, 비전 모델의 픽셀 입력도 동일하게 디스크립터 우선 방식으로 처리됩니다.¹¹

추론이 실행되는 곳 선택하기

Apple silicon에는 연산할 수 있는 곳이 세 군데 있습니다. CPU, GPU, Neural Engine입니다. Core AI가 Core ML만이 아니라 별도로 존재하는 이유는, Core AI가 프레임워크의 타기팅을 추론에 맡기는 대신 셋 중 어느 것을 타기팅할지 여러분이 말할 수 있게 하기 때문입니다.

ComputeUnitKind는 “모델 추론에 사용할 수 있는 하드웨어 연산 유닛의 한 종류”입니다.⁸ 전문화 옵션과 함께 연산 유닛 종류를 사용하면 모델을 전문화할 때 프레임워크가 어느 하드웨어를 타기팅할지 제어할 수 있으며, 기본적으로 전문화는 디바이스에서 사용 가능한 모든 연산 유닛을 사용합니다.⁸ 기본값이 대부분의 작업에 옳은 답이며, 바로 그것이 핵심입니다. 이유가 있을 때만 기본값을 재정의합니다(Neural Engine에 고정하고 싶은 지연 민감 경로, CPU로 강제하고 싶은 디버깅 패스, 다른 GPU 작업과 조율하고 있는 GPU 집약적 파이프라인 등).

그 의도는 SpecializationOptions, 즉 전문화 시점에 내린 선택을 담는 구조체를 통해 전달합니다.⁹ 전문화는 앞서 말한 비용이 큰 단계이며, 연산 유닛 타기팅과 그 밖의 전문화 결정이 사는 곳이 SpecializationOptions입니다. 캐시 항목은 특정 asset과 전문화 조합을 키로 삼으므로, 옵션을 바꾸면 되돌려받는 캐시 산출물이 바뀌며, 이로써 타기팅과 캐싱 사이의 고리가 닫힙니다.⁶

스케줄링은 “어떻게 실행되는가”의 또 다른 축이며, Core AI는 이를 ComputeStream, “비동기로 실행될 작업의 스트림”으로 모델링합니다.¹⁰ 연산 스트림은 작업을 스트림에 인코딩하기 위해 제공하는 것이며, Apple은 같은 스트림에 인코딩된 여러 추론이 읽고 쓰는 값에 따라 필요한 만큼 직렬화된다고 언급합니다.¹⁰ 두 가지 함의가 따라옵니다. 첫째, 스트림은 여러분의 순서 지정 기본 단위입니다. 의존 관계가 있는 추론들을 하나의 스트림에 인코딩하면 Core AI가 데이터 의존성에 따라 그것들을 순서대로 배열합니다. 둘째, 작업은 기본적으로 비동기이므로, 스트림은 Neural Engine이나 GPU가 작업하는 동안 호출 스레드를 자유롭게 유지하는 방법이기도 합니다.

추론 함수: 실제로 실행되는 그것

로드된 .aimodel은 단일 호출 가능 객체가 아닙니다. 모델은 이름이 붙은 함수들(인코더, 디코더, 비전 타워, 프리필 대 디코드 단계)을 노출하며, Core AI의 실행 단위는 InferenceFunction입니다. “입력 값에 대해 추론을 수행하고 출력 값을 생성하는 함수”이지요.¹⁴

함수를 호출하기 전에 먼저 검사합니다. InferenceFunctionDescriptor는 “추론 함수의 시그니처에 대한 기술”이며, 디스크립터를 사용하면 추론을 실행하기 전에 함수의 입력, 출력, 상태의 이름과 타입을 검사할 수 있습니다.¹³ 상태(state)는 잠시 멈춰 살펴볼 만한 세부 사항입니다. 상태를 가진 함수는 상태 기반 모델(예를 들어 트랜스포머 디코드 루프의 KV 캐시)이 호출 사이에 정보를 유지하는 방식이며, 디스크립터는 여러분이 함수를 구동해보기 전에 그 함수가 상태를 가지고 있음을 알려줍니다.

InferenceFunction 자체는 모델 가중치와 중간 버퍼를 포함해 추론에 필요한 리소스를 소유합니다. 모델에서 함수를 로드하고 run(inputs:states:outputViews:)를 호출하여 추론을 수행합니다.¹⁴ run의 시그니처는 Apple 자신의 설명에서 명시되어 있으므로, 호출에 필요한 세 가지가 명확합니다. 입력 값, 상태 값, 그리고 작성되기를 원하는 출력 뷰입니다.

// run(inputs:states:outputViews:) is named in Apple's docs; surrounding
// loading/value-construction shapes are illustrative — confirm against Apple's docs.
let function: InferenceFunction = /* load from an AIModel */
let outputs = try function.run(
    inputs: inputValues,        // InferenceValue per input
    states: stateValues,        // any stateful values the function declares
    outputViews: outputViews
)

두 가지 속성이 이 함수를 부하 상황에서 다루기 좋게 만듭니다. 이 함수는 Sendable이므로 여러 태스크에서 동시에 실행할 수 있으며, Apple은 그 동시성을 지원하기 위해 필요에 따라 추가 중간 버퍼를 자동으로 할당한다고 언급합니다.¹⁴ 공유 스크래치 공간을 보호하려고 락 뒤에서 호출을 직렬화할 필요가 없습니다. 함수가 동시 호출자마다 자신의 버퍼를 직접 관리합니다. 이는 단일 추론 핸들이 사실상 단일 스레드인 API들과의 의미 있는 차이입니다.

run을 통해 흐르는 값들은 InferenceValue 인스턴스, “추론 함수가 입력으로 받아들이거나 출력으로 생성하는 값”입니다.¹² InferenceValue는 NDArray 또는 픽셀 버퍼 중 하나를 감싸며, 추론 후 그 value 속성을 사용해 결과를 가져옵니다.¹² 이 래퍼가 있기에 하나의 run 시그니처가 별도 오버로드 없이 텐서 입력과 이미지 입력을 모두 실어 나를 수 있습니다. 텍스트 모델은 NDArray 기반 값을, 비전 모델은 픽셀 버퍼 기반 값을 전달하며, 함수는 어느 쪽을 기대하는지 알기 위해 디스크립터를 읽습니다.

언제 Core AI에 손을 뻗을 것인가

Core AI에서 가장 어려운 부분은 API가 아닙니다. 한 계층 위가 아니라 여기에 있어야 한다는 것을 아는 것입니다. 정직한 결정 트리는 이렇습니다.

• Foundation Models — Apple의 시스템 모델이 그 작업을 해낼 때. 요약, 분류, 추출, 재작성, 구조화된 출력. 이것들은 Foundation Models에 속하며, 가중치 비용도, 메모리 예산도, 전문화 단계도 들지 않습니다. 여러분의 기능이 여기에 맞는다면, 거기서 멈추세요. 시스템 모델이 이미 하는 일을 다시 구현하려고 Core AI로 내려가는 것은 헛수고입니다.
• Core ML — 변환된 고정 모델이 있고, 변환기가 하드웨어와 최적화 결정을 대신 내려주기를 원할 때. Core ML은 잠긴 프로덕션 모델을 위해 빠듯한 전력과 지연으로 Neural Engine을 타기팅하며, 전문화나 스케줄링에 대해 여러분에게 아무것도 요구하지 않습니다. 연산 유닛 타기팅이나 연산 스트림을 생각하고 싶지 않다면, 그것이 Core ML에 머무르라는 신호입니다.
• MLX — 직접 임베드하고 반복하는 연구 수준의 배열 프레임워크를 원할 때. 자신만의 학습 루프, 양자화된 오픈 가중치 모델, LoRA 파인튜닝, 빠른 실험 등입니다. MLX는 시스템 모델 실행 표면이 아니라 가중치와 함께 출시하는 라이브러리입니다. 유연성과 반복 속도에서 이깁니다.
• Core AI — 실행할 모델이 있고 프레임워크의 명시적 핸들을 원할 때. 커밋하기 전에 검사하는 AIModelAsset, 연산 유닛을 고정하는 SpecializationOptions, 직접 관리하는 AIModelCache, 스케줄링하는 ComputeStream, 그리고 동시에 호출하는 InferenceFunction들입니다. 상위 계층의 기본값이 길을 막는 바로 그 대상이 되고, 어떤 기본값을 재정의해야 하는지 이름 댈 수 있을 때 여기에 손을 뻗습니다.

전체 스택을 관통하는 줄기는 이렇습니다. 한 계층씩 내려갈 때마다 기본값을 핸들과 맞바꿉니다. Foundation Models는 모든 것을 건네주고 아무것도 묻지 않습니다. Core AI는 레버를 건네주고, 어느 것을 당겨야 하는지 알기를 요구합니다. 필요한 전문화, 캐싱, 스케줄링 제어를 이름 댈 수 없다면, 여러분에게는 아직 Core AI가 필요하지 않습니다.

새로운 작업에서 Core AI와 Core ML 사이의 경계가 어디에 있는지를 WWDC 2026 랩 발언이 더 날카롭게 합니다. WWDC 2026 Coding Intelligence, Machine Learning & AI Group Lab의 로컬에서 전사된 녹음을 의역하면, 패널에 있던 한 Core AI 엔지니어는 Apple이 신경망을 다루는 모든 사람에게 앞으로 Core AI로 옮길 것을 요청하고 있으며, Core ML은 그대로 유지되지만 의사결정 트리 같은 전통적 머신러닝에 집중하고, 새로운 것은 모두 Core AI로 향한다고 말했습니다.¹⁶ 이것을 문서화된 정책이 아니라 프레임워크를 만드는 사람들이 보내는 진행 방향 신호로 읽으세요. 새 프로젝트에서 신경망에 손을 뻗고 있다면, 랩은 Core AI를 그 위에 쌓아 올릴 표면으로 규정했습니다.

모델이 Core AI에 도달하는 과정

이 프레임워크는 더 큰 워크플로의 런타임 절반입니다. Apple은 Core AI가 프레임워크와 함께 모델 준비, 통합, 디버깅을 위한 추가 도구를 포함한다고 언급합니다. 여러분은 Apple silicon용으로 모델을 준비하고, .aimodel 포맷으로 변환하며, 시각화와 수치 디버깅을 지원하는 동반 앱을 사용합니다.¹ 팩트 시트에 적힌 그 도구 이름들에 대한 설명은 잘려 있으므로, 어떤 재구성도 신뢰하지 말고 정확한 도구 이름과 그 호출 방법은 Apple의 Core AI 문서에 대조해 확인하세요.¹ 검증된 것은 파이프라인의 형태입니다. 소스 모델을 준비하고, .aimodel로 변환하며, 검사를 위해 AIModelAsset으로 로드하고, AIModel로 전문화한 다음, 그 InferenceFunction들을 통해 실행합니다. 이때 AIModelCache가 전문화된 산출물을 보관하여 비용이 큰 단계가 한 번만 일어나게 합니다.¹²³⁶¹⁴

FAQ

Apple의 Core AI 프레임워크란 무엇인가요?

Core AI는 Apple silicon에서 AI 모델을 실행하기 위한 iOS 27의 저수준 프레임워크로, Apple은 이를 “Apple silicon에서 앱 안의 AI 모델을 실행한다”로 요약합니다.¹ 일반적인 작업은 간단하게 처리하면서도 필요할 때 모델 전문화, 캐싱, 추론 성능에 대한 제어권을 주는 Swift API를 통해 CPU, GPU, Neural Engine 전반에 걸쳐 모델 추론을 실행합니다.¹ 모델 실행 표면으로서 Foundation Models와 Core ML 아래에 자리합니다.

AIModelAsset과 AIModel의 차이는 무엇인가요?

AIModelAsset은 디스크의 .aimodel 번들 URL로부터 생성하는 전문화되지 않은 소스 asset입니다. 전문화는 비용이 크고 asset은 추론을 실행할 수 없기 때문에, 전문화하지 않고도 모델의 함수 시그니처, 입력 및 출력 설명, 연산 및 저장 타입, 메타데이터를 검사하는 데 사용합니다.² AIModel은 현재 디바이스의 하드웨어에 최적화되어 실제로 추론을 실행하는 전문화된 모델입니다. 디스크에서 asset을 로드하여 생성합니다.³ 이 분리 덕분에 저렴하게 검사하고, 커밋할 때만 전문화할 수 있습니다.

Core AI는 CPU, GPU, Neural Engine 중 어떻게 선택하나요?

SpecializationOptions를 통해 ComputeUnitKind로 하드웨어 타기팅을 제어합니다. 연산 유닛 종류는 추론에 사용할 수 있는 하드웨어 연산 유닛의 한 종류를 가리키며, 모델을 전문화할 때 프레임워크가 어느 하드웨어를 타기팅할지 제어하는 데 사용합니다. 기본적으로 전문화는 디바이스에서 사용 가능한 모든 연산 유닛을 사용합니다.⁸⁹ 지연 민감 경로를 하나의 연산 유닛에 고정하는 것처럼 구체적인 이유가 있을 때만 기본값을 재정의하세요.

InferenceFunction이란 무엇이고 어떻게 실행하나요?

InferenceFunction은 입력 값에 대해 추론을 수행하고 출력 값을 생성하며, 모델 가중치와 중간 버퍼를 소유합니다.¹⁴ 먼저 InferenceFunctionDescriptor를 통해 그 시그니처를 검사합니다. 이 디스크립터는 함수의 입력, 출력, 상태의 이름과 타입을 기술합니다. 그런 다음 AIModel에서 함수를 로드하고 run(inputs:states:outputViews:)를 호출합니다.¹³¹⁴ 이 함수는 Sendable이며 동시성을 지원하기 위해 중간 버퍼를 자동으로 할당하므로, 여러 태스크가 한꺼번에 실행할 수 있습니다.¹⁴

Core ML이나 Foundation Models 대신 Core AI를 써야 하나요?

시스템 모델이 그 작업을 해낼 때는 Foundation Models를 사용하고, 변환된 고정 모델이 있고 변환기가 하드웨어와 최적화 결정을 대신 내려주기를 원할 때는 Core ML을 사용하세요. 상위 계층이 여러분을 대신해 처리하는 전문화(SpecializationOptions, ComputeUnitKind), 캐싱(AIModelCache), 스케줄링(ComputeStream)에 대한 명시적 제어를 원할 때 Core AI에 손을 뻗으세요.⁸⁹⁶¹⁰ 필요한 제어를 이름 댈 수 없다면, 한 계층 위에 머무르세요.

전체 Apple Ecosystem 클러스터: 자신만의 모델과 학습 루프를 원할 때 임베드하는 배열 프레임워크인 Apple Silicon의 MLX, CPU/GPU/Neural Engine 공유를 가능하게 하는 하드웨어 기반인 Apple Silicon의 TBDR과 통합 메모리, Core AI 위의 고정 모델 계층인 Core ML 온디바이스 추론, 그리고 스택 최상단에 있는 Apple의 봉인된 시스템 LLM인 Foundation Models가 있습니다. 허브는 Apple Ecosystem 시리즈에 있습니다. AI 에이전트를 곁들인 iOS의 더 넓은 맥락은 iOS Agent Development 가이드를 참고하세요.

References