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

애플의 온디바이스 AI 스택에는 그동안 빠져 있던 한 단계가 있었습니다. Foundation Models는 봉인된 시스템 LLM을 무료로 제공합니다. Core ML은 변환이 끝난 고정 모델을 실행하고, 하드웨어에 관한 결정은 컨버터가 대신 내려줍니다. MLX는 직접 임베드하는 배열 프레임워크와 직접 고르는 모델을 제공합니다. iOS 27은 이 셋 모두의 아래에 놓이는 단계를 추가했습니다. 바로 Core AI이고, 한 줄짜리 요약은 “Run AI models in your app on Apple silicon”입니다.¹ 이것은 모델 실행을 담당하는 표면이며, 상위 계층의 기본값을 받아들이는 대신 특수화와 캐싱, 추론 스케줄링을 직접 다루고 싶을 때 손을 뻗는 자리입니다.

세션 324에서 애플은 Core AI를 온디바이스 Apple Intelligence를 구동하는 바로 그 추론 프레임워크이며, 이제 여러분 앱의 인텔리전스를 위해 개방된 것으로 소개합니다.¹⁵

이 위치 설정이 중요한 이유는 Core AI가 대부분의 앱이 사용해야 할 추상화보다 아래에 있기 때문입니다. 애플의 설명에 따르면 Core AI는 Apple silicon을 염두에 두고 설계되어, 앱이 최신 모델 아키텍처와 추론 기법을 CPU와 GPU, Neural Engine에 걸쳐 사용할 수 있게 해줍니다. Swift API는 흔한 작업을 간단하게 만들어 주면서도, 필요할 때는 모델 특수화와 캐싱, 추론 성능을 더 세밀하게 제어하도록 열어둡니다.¹ 이 글의 논지는 이렇습니다. 어디에서 어떻게 실행할지 명시적으로 제어하고 싶은 모델이 있다면 Core AI를 선택하고, 그렇지 않다면 Core ML이나 Foundation Models에 머무르세요. 이 프레임워크가 보답하는 것은 구체적인 필요이지, 기본 선호가 아닙니다.

TL;DR / 핵심 요약

• Core AI는 특수화되지 않은 AIModelAsset(모델의 구조와 메타데이터를 저렴하게 살펴보는 쪽)과 특수화된 AIModel(기기에서 추론을 실행하는 쪽)을 분리합니다. 기기별 산출물은 AIModelCache가 보관하고, 에셋 작업 실패는 AssetError가 나타냅니다.²³⁶⁴
• 추론 데이터는 스칼라 값의 다차원 배열인 NDArray를 통해 흐르고, 형태와 스칼라 타입, 메모리 레이아웃에 대한 기대치는 NDArrayDescriptor가 정합니다.⁵⁷
• 하드웨어 지정은 SpecializationOptions를 통한 ComputeUnitKind(CPU, GPU, Neural Engine)로 하고, 비동기 작업은 ComputeStream에 스케줄링합니다.⁸⁹¹⁰
• InferenceFunction은 가중치와 버퍼를 소유하면서 추론을 실행합니다. 입력과 출력, 상태 시그니처는 InferenceFunctionDescriptor로 먼저 확인할 수 있습니다. 이 함수는 Sendable이라 동시에 실행할 수 있습니다.¹⁴¹³
• 모델은 디스크의 .aimodel 번들에서 로드합니다. 프레임워크 주변의 툴체인도 이제 문서화되어 있습니다. coreai-torch 파이썬 패키지가 PyTorch 모델을 변환하고, coreai-build CLI가 .aimodel을 아키텍처별 .aimodelc 에셋으로 미리 컴파일합니다. 검사와 프로파일링은 Core AI Debugger 앱과 Xcode 디버그 게이지, Instruments 템플릿이 담당합니다.¹⁷ 특수화와 스케줄링을 명시적으로 제어해야 할 때 Core AI를 선택하고, 그렇지 않다면 Core ML이나 Foundation Models에 머무르세요.²¹

설계 전체를 움직이는 두 단어: 에셋과 모델

Core AI가 가장 먼저 이해시키려는 것은, 디스크 위의 모델과 추론을 실행하는 모델이 서로 다른 객체이며 전자를 후자로 특수화하는 작업이 비싸다는 점입니다. 프레임워크는 각각에 타입을 부여했습니다.

AIModelAsset은 “an unspecialized source model asset”(특수화되지 않은 원본 모델 에셋)입니다.² 디스크에 있는 .aimodel 번들의 URL로 만들고, 특수화 비용을 치르지 않은 채 모델을 살펴보는 데 씁니다. 애플은 이 분리가 존재하는 이유를 분명히 밝힙니다. 모델 에셋을 쓰면 비싼 작업인 특수화를 수행하지 않고도 모델 정보를 조회할 수 있기 때문입니다. 에셋에서는 함수 시그니처와 입출력 설명, 연산 타입과 저장 타입, 그리고 작성자가 넣어둔 메타데이터를 읽을 수 있습니다. 할 수 없는 일은 추론 실행입니다. 에셋은 오직 검사용입니다.²

// 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입니다. “a specialized model for running inference on a device”(기기에서 추론을 실행하기 위한 특수화된 모델)입니다.³ AIModel은 현재 기기의 하드웨어에 맞게 최적화된 특수화 .aimodel 에셋을 나타내고, 디스크에서 에셋을 로드해 만듭니다.³ 에셋은 이 모델은 무엇인가?에 답하고, 모델은 여기서, 지금 실행하라에 답합니다. 둘 사이의 비용 비대칭이야말로 API가 어느 쪽을 원하는지 이름 붙이게 만드는 이유입니다. 후보 모델 백 개를 살펴보고 하나를 고르는 일은, 에셋만 만든다면 저렴합니다. 검사할 때마다 특수화가 일어난다면 감당할 수 없는 비용이 됩니다.

특수화는 기기별 산출물을 만들어내고, 그 산출물에는 자리가 있습니다. AIModelCache, 즉 “a cache that stores the specialized model artifacts for inference”(추론용으로 특수화된 모델 산출물을 저장하는 캐시)입니다.⁶ 이 캐시는 모델이 추론 함수를 실행하려고 로드하는, 최적화된 기기별 산출물을 보관합니다. 애플은 각 캐시 항목이 특정 .aimodel 또는 .aimodelc와 특수화 조합으로 만들어진 특수화 에셋을 담고 있다고 설명합니다.⁶ 실무적으로 읽으면 이렇습니다. 특수화는 실행할 때마다 반복하고 싶은 작업이 아닙니다. 캐시는 비싼 단계를 한 번만 일어나게 하고, 이후에는 저렴한 단계(캐시된 산출물 로드)만 일어나게 하는 Core AI의 장치입니다.

에셋 작업이 잘못되면(번들이 없거나, .aimodel이 손상됐거나, 파일을 읽을 수 없을 때) Core AI는 AssetError, 곧 “an error that occurs during model asset operations”(모델 에셋 작업 중 발생하는 오류)를 내보냅니다.⁴ 다루는 방식은 다른 모든 I/O 경계와 같습니다. 에셋은 디스크에 있고, 디스크 작업은 실패하며, 타입 시스템이 catch를 어디에 두어야 하는지 정확히 알려줍니다.

텐서: NDArray와 그 디스크립터

추론은 숫자를 넣고 숫자를 받는 일이고, 그 숫자를 담는 Core AI의 컨테이너가 NDArray, “a multidimensional array of scalar values used for model inference”(모델 추론에 사용되는 스칼라 값의 다차원 배열)입니다.⁵ NumPy의 ndarray나 MLX 배열, MLMultiArray를 다뤄봤다면 발상의 모양이 익숙할 것입니다. 레이아웃이 정의된 n차원 스칼라 덩어리입니다. NDArray는 자신의 형태와 나머지 서술 속성으로 정의된 레이아웃에 데이터를 저장합니다.⁵

짝이 되는 타입은 NDArrayDescriptor, “a description of an array’s shape, scalar type, and memory layout expectations”(배열의 형태와 스칼라 타입, 메모리 레이아웃 기대치에 대한 서술)입니다.⁷ 디스크립터는 계약입니다. 애플의 설명은 직설적입니다. 디스크립터는 추론 함수에 제공하는 배열 값에 대한 기대치를 담고 있으며, 대부분의 기대치는 엄격합니다. 디스크립터가 스칼라 타입으로 .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).

여기서 얻는 설계 교훈은 에셋과 모델의 분리와 같은 구도입니다. Core AI는 일관되게 비싼 값 객체 앞에 저렴한 서술 객체를 놓습니다. 먼저 할당한 뒤 추론 시점에 불일치를 발견하는 대신, 디스크립터를 읽어 계약을 파악하고 그것을 만족하는 NDArray를 할당하는 것입니다. 특히 이미지 입력을 위해 Core AI는 ImageDescriptor, “a description of an image’s dimensions and pixel format”(이미지의 크기와 픽셀 포맷에 대한 서술)도 정의해서, 비전 모델의 픽셀 입력에도 똑같이 디스크립터 우선 방식을 적용합니다.¹¹

추론이 실행될 곳 고르기

Apple silicon에는 연산할 수 있는 자리가 셋 있습니다. CPU와 GPU, 그리고 Neural Engine입니다. Core ML만이 아니라 Core AI가 존재하는 이유는, Core AI에서는 프레임워크가 그중 무엇을 대상으로 삼을지 추론에 맡기지 않고 직접 말할 수 있기 때문입니다.

ComputeUnitKind는 “a type of hardware compute unit available for model inference”(모델 추론에 사용할 수 있는 하드웨어 연산 유닛의 종류)입니다.⁸ 연산 유닛 종류는 특수화 옵션과 함께 써서, 모델을 특수화할 때 프레임워크가 어떤 하드웨어를 대상으로 삼을지 제어합니다. 기본적으로 특수화는 기기에서 사용할 수 있는 모든 연산 유닛을 사용합니다.⁸ 대부분의 작업에서는 이 기본값이 정답이고, 바로 그게 핵심입니다. 이유가 있을 때만 재정의하면 됩니다. 지연 시간에 민감한 경로를 Neural Engine에 고정하고 싶을 때, 디버깅을 위해 CPU로 강제하고 싶을 때, 다른 GPU 작업과 조율해야 하는 GPU 중심 파이프라인이 있을 때처럼 말입니다.

그 의도는 SpecializationOptions를 통해 전달합니다. 특수화 시점에 내린 선택들을 담는 구조체입니다.⁹ 특수화는 앞서 말한 비싼 단계이고, 연산 유닛 지정을 비롯한 특수화 결정이 바로 SpecializationOptions에 모입니다. 캐시 항목은 특정 에셋과 특수화 조합을 키로 삼기 때문에, 옵션을 바꾸면 돌려받는 캐시 산출물도 달라집니다. 이렇게 하드웨어 지정과 캐싱이 하나의 고리로 이어집니다.⁶

“어떻게 실행하는가”의 다른 축은 스케줄링이고, Core AI는 이를 ComputeStream, “a stream of work to be run asynchronously”(비동기적으로 실행될 작업의 스트림)으로 모델링합니다.¹⁰ 컴퓨트 스트림은 작업을 스트림에 인코딩하기 위해 건네는 대상이고, 애플은 같은 스트림에 인코딩된 여러 추론이 읽고 쓰는 값에 따라 필요한 만큼 직렬화된다고 설명합니다.¹⁰ 여기서 두 가지가 따라옵니다. 첫째, 스트림은 순서를 정하는 기본 요소입니다. 서로 의존하는 추론들을 하나의 스트림에 인코딩하면 Core AI가 데이터 의존성에 따라 순서를 잡아줍니다. 둘째, 작업은 기본적으로 비동기입니다. 그래서 스트림은 Neural Engine이나 GPU가 일하는 동안 호출 스레드를 놀려두지 않고 자유롭게 유지하는 방법이기도 합니다.

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

로드된 .aimodel은 하나의 호출 가능한 덩어리가 아닙니다. 모델은 이름 붙은 함수들(인코더, 디코더, 비전 타워, prefill 단계와 decode 단계 등)을 노출하고, Core AI의 실행 단위는 InferenceFunction, “a function that performs inference on input values and produces output values”(입력값에 대해 추론을 수행하고 출력값을 만들어내는 함수)입니다.¹⁴

호출하기 전에 먼저 살펴봅니다. InferenceFunctionDescriptor는 “a description of an inference function’s signature”(추론 함수 시그니처에 대한 서술)이고, 추론을 실행하기 전에 함수의 입력과 출력, 상태의 이름과 타입을 확인하는 데 씁니다.¹³ 잠시 멈춰 볼 만한 대목은 상태입니다. 상태를 가진 함수는 상태를 유지하는 모델(예를 들어 트랜스포머 디코드 루프의 KV 캐시)이 호출 사이에 정보를 간직하는 방법이고, 디스크립터는 그 함수를 움직여보기 전에 상태가 있다는 사실을 알려줍니다.

InferenceFunction 자체는 모델 가중치와 중간 버퍼를 포함해 추론에 필요한 자원을 소유합니다. 모델에서 함수를 로드한 다음 run(inputs:states:outputViews:)를 호출해 추론을 수행합니다.¹⁴ run의 시그니처는 애플 자신의 설명에 등장하므로, 호출에 필요한 세 가지가 명시적으로 드러납니다. 입력값, 상태값, 그리고 값이 쓰이길 원하는 출력 뷰입니다.

// 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이라 여러 태스크에서 동시에 실행할 수 있고, 애플은 그 동시성을 뒷받침하려고 필요에 따라 추가 중간 버퍼를 자동으로 할당한다고 밝힙니다.¹⁴ 공유 스크래치 공간을 지키려고 락 뒤에서 호출을 직렬화할 필요가 없습니다. 함수가 동시 호출자마다 자기 버퍼를 관리하기 때문입니다. 추론 핸들 하나가 사실상 단일 스레드로 묶이는 API들과 비교하면 의미 있는 차이입니다.

run을 통과하는 값은 InferenceValue 인스턴스, “a value that an inference function accepts as input or produces as output”(추론 함수가 입력으로 받거나 출력으로 만들어내는 값)입니다.¹² InferenceValue는 NDArray 또는 픽셀 버퍼를 감싸고, 추론이 끝난 뒤에는 value 프로퍼티로 결과를 가져옵니다.¹² 이 래퍼 덕분에 하나의 run 시그니처가 오버로드를 나누지 않고도 텐서 입력과 이미지 입력을 함께 실어 나를 수 있습니다. 텍스트 모델은 NDArray가 뒷받침하는 값을 넘기고, 비전 모델은 픽셀 버퍼가 뒷받침하는 값을 넘기며, 함수는 어느 쪽을 기대하는지 디스크립터를 읽어 알아냅니다.

언제 Core AI로 손을 뻗어야 할까

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

• Foundation Models — 애플의 시스템 모델이 그 일을 해낼 때. 요약, 분류, 추출, 재작성, 구조화된 출력. 이런 작업은 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가 필요하지 않은 것입니다.

WWDC 2026 랩에서 나온 발언이 새 작업에서 Core AI와 Core ML 사이의 경계선을 더 또렷하게 해줍니다. WWDC 2026 Coding Intelligence, Machine Learning & AI Group Lab을 로컬에서 받아쓴 녹음에서 옮긴 바에 따르면, 패널에 참여한 Core AI 엔지니어는 애플이 신경망을 다루는 모든 사람에게 앞으로 Core AI로 옮겨가기를 요청하고 있으며, Core ML은 그대로 남되 의사결정 트리 같은 전통적인 머신러닝에 초점을 맞추고 새로운 것은 모두 Core AI로 향한다고 말했습니다.¹⁶ 이는 문서화된 정책이라기보다 프레임워크를 만드는 사람들이 보내는 방향 신호로 읽는 편이 맞습니다. 새 프로젝트에서 신경망에 손을 뻗는다면, 랩은 Core AI를 그 위에 쌓아 올릴 표면으로 제시했습니다.

모델은 어떻게 Core AI에 도달하나

이 프레임워크는 더 큰 워크플로의 런타임 쪽 절반이고, 6월 베타 이후 애플은 도구 쪽 절반도 빠짐없이 공개했습니다.¹⁷ 파이프라인은 이렇게 흘러갑니다.

변환하기. 출발점은 .aimodel 파일입니다. coreai-torch 패키지(애플의 Core AI PyTorch Extensions for Python)로 원본 모델에서 변환하거나, 이미 그 포맷으로 준비된 것을 쓰면 됩니다.¹⁷ .aimodel은 다른 리소스처럼 Xcode 타깃에 들어가고, Compile Sources 빌드 단계에 나타나며, Xcode에서는 파라미터와 저장 크기, 메타데이터, 연산 그래프를 보여주는 모델 뷰어가 붙습니다. 미리 알아둘 빌드 시스템 의존성이 하나 있습니다. Core AI 모델 통합에는 Metal Toolchain이 필요한데 Xcode는 이를 기본으로 설치하지 않고, 없으면 .aimodel 파일이 포함된 빌드는 Metal 컴파일러를 찾지 못했다는 오류로 실패합니다.¹⁷

필요하면 미리 컴파일하기. 특수화는 AIModel을 만들 때 자동으로 일어나고, 큰 모델에서는 그 첫 로드 비용이 실제로 체감됩니다. coreai-build 커맨드라인 도구는 가장 비싼 부분인 모델 컴파일을 빌드 머신으로 옮겨줍니다. .aimodel을 기기 아키텍처마다 하나씩 .aimodelc 에셋으로 변환하고(MyModel.aimodel을 컴파일하면 MyModel.<arch>.aimodelc가 생깁니다), 런타임에 앱이 현재 기기에 맞는 에셋을 고르기 때문에 Core AI는 컴파일 단계를 건너뜁니다.¹⁷ 사전 컴파일이 겨냥하는 범위는 Apple Intelligence의 하드웨어 하한선입니다. A17 Pro 이상을 탑재한 iPhone 또는 iPad, M1 이상의 Mac, 그리고 M2를 탑재한 Apple Vision Pro입니다.¹⁷

디버깅과 프로파일링. 관측 가능성을 담당하는 도구는 셋입니다. 모델의 연산 그래프를 살펴보고, 기기에서 실행해보고, 출력을 기준 실행과 비교할 수 있는 독립 실행형 macOS 앱 Core AI Debugger. 디버그 세션 중에 로드와 특수화, 추론 활동을 실시간으로 모니터링하는 Xcode의 Core AI 디버그 게이지. 그리고 CPU와 GPU, Neural Engine에 걸친 실행 타이밍을 프로파일링하는 Instruments 템플릿인 Core AI instrument입니다.¹⁷

앞서 본 런타임의 모양은 이 워크플로에 그대로 들어맞습니다. 준비된 모델은 검사를 위해 AIModelAsset으로 로드되고, AIModel로 특수화되며, 그 InferenceFunction들을 통해 실행됩니다. 그리고 AIModelCache가 특수화된 산출물을 보관하니 비싼 단계는 한 번만 일어납니다.¹²³⁶¹⁴

자주 묻는 질문

애플의 Core AI 프레임워크는 무엇인가요?

Core AI는 Apple silicon에서 AI 모델을 실행하기 위한 iOS 27의 저수준 프레임워크이고, 애플은 이를 “Run AI models in your app on Apple silicon”으로 요약합니다.¹ Swift API를 통해 CPU와 GPU, Neural Engine에 걸쳐 모델 추론을 실행하며, 흔한 작업은 간단하게 만들면서도 필요할 때는 모델 특수화와 캐싱, 추론 성능을 제어하게 해줍니다.¹ 모델 실행 표면으로서 Foundation Models와 Core ML 아래에 자리합니다.

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

AIModelAsset은 디스크에 있는 .aimodel 번들의 URL로 만드는, 특수화되지 않은 원본 에셋입니다. 특수화가 비싸기 때문에, 특수화 없이 모델의 함수 시그니처와 입출력 설명, 연산 타입과 저장 타입, 메타데이터를 살펴보는 데 쓰고, 에셋은 추론을 실행할 수 없습니다.² AIModel은 현재 기기의 하드웨어에 맞게 최적화되어 실제로 추론을 실행하는 특수화된 모델이고, 디스크에서 에셋을 로드해 만듭니다.³ 이 분리 덕분에 검사는 저렴하게 하고, 실제로 쓰기로 정했을 때만 특수화하게 됩니다.

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

참고 문헌