Core ML 온디바이스 추론: 실제로 출시까지 가는 패턴

Core ML은 최신 Apple 기기마다 함께 탑재되는 온디바이스 추론 엔진입니다. 이 프레임워크는 가능하면 Neural Engine으로, 그렇지 않으면 GPU로, 마지막 수단으로 CPU로 연산을 배분하며, 모델과 하드웨어에 따라 가장 빠른 경로를 자동으로 선택합니다¹. 그 결과 최근 iPhone에서는 프로덕션에서 쓰이는 대부분의 모델 크기에 대해 1밀리초 미만에서 수십 밀리초 수준의 지연 시간으로 추론이 끝납니다. 호출당 비용은 없고, 네트워크 왕복도 없으며, 서드파티에 데이터가 노출되지도 않습니다.

이 프레임워크가 “눈에 띄지 않는 배관”이라는 평판은 이미 낡았습니다. Core ML은 사진 앱의 시맨틱 검색부터 로컬 ML을 탑재한 대다수 서드파티 앱에 이르기까지 10년 가까이 온디바이스 기능을 떠받쳐 왔고, iOS 11까지 거슬러 올라가는 모든 OS에서 고정된 변환 모델을 돌리는 프로덕션 실행 지점으로 남아 있습니다. 다만 스택 안에서의 위치는 WWDC 2026에서 실제로 달라졌습니다. Apple은 온디바이스 Apple Intelligence를 구동하는 저수준 프레임워크로 Core AI를 발표하면서, 새로운 신경망 작업이 나아갈 방향으로 지목했습니다¹¹¹². 그럼에도 Core ML 배포를 “내 Mac에서는 됩니다”에서 끝내지 않고 실제로 출시까지 끌고 가는 패턴은 그대로이며, 여전히 몇 가지에 불과합니다. 모델 변환, 디스패치 힌트, 지연 시간 예산 설정, 그리고 양자화입니다. 이 글에서는 각각을 Apple 문서에 비추어 짚어 본 뒤, WWDC26 이후의 스택에서 Core ML이 어디에 놓이는지 정리합니다.

TL;DR

• Core ML은 Apple Silicon의 Neural Engine, GPU, CPU에서 .mlpackage와 .mlmodel 파일을 실행합니다. 디스패치는 자동이지만 MLModelConfiguration.computeUnits로 힌트를 줄 수 있습니다².
• 모델 변환은 coremltools로 이루어집니다(PyTorch, TensorFlow, ONNX → Core ML). 변환은 런타임의 일이 아니라 툴링의 일입니다. 한번 변환해 번들에 넣고 나면 앱은 그것을 불러와 실행하기만 하면 됩니다.
• Apple Silicon의 통합 메모리 아키텍처 덕분에 모델 가중치는 CPU, GPU, NE 사이에서 복사되지 않습니다. 세 경로 모두 같은 메모리를 바탕으로 동작합니다³. 1밀리초 미만의 추론을 가능하게 하는 것이 바로 이 아키텍처적 세부 사항입니다.
• 양자화(최근 Core ML 버전에서는 INT8, INT4)는 모델 크기를 줄이고 Neural Engine에서의 추론을 빠르게 하지만, 모델에 따라 측정 가능한 정확도 손실이 뒤따릅니다. coremltools 9.0(2025년 11월)은 iOS 26 배포 타깃, 모델 상태 읽기/쓰기, int8 모델 입출력을 추가했습니다¹³.
• 스택은 WWDC 2026에서 바뀌었습니다. Apple은 Core AI를 온디바이스 Apple Intelligence를 떠받치는 추론 프레임워크이자 새로운 신경망 작업의 무대로 자리매김했고, Core ML은 고정된 변환 모델과 전통적인 ML을 위한 프로덕션 계층으로 계속 남습니다¹¹¹².

멘탈 모델: 세 개의 연산 경로, 하나의 메모리

Apple Silicon(M 시리즈 Mac과 A12 Bionic 이후의 A 시리즈 iPhone)에는 세 가지 추론 타깃이 있습니다.

Neural Engine. 낮은 정밀도의 행렬 곱셈에 특화된 가속기입니다. 합성곱, 어텐션, 임베딩처럼 최신 ML 모델이 의존하는 연산에서 가장 빠르고, 전력 소비도 가장 적습니다. 다만 지원하는 연산 종류와 텐서 형태가 제한적이며, 지원되지 않는 연산은 레이어 단위로 GPU나 CPU로 폴백합니다.

GPU. Metal을 통한 범용 병렬 연산입니다. ML에 어울리는 형태의 작업에서는 Neural Engine보다 느리지만 CPU보다는 빠릅니다. Neural Engine이 지원하지 않는 연산을 처리합니다.

CPU. 폴백 경로입니다. ML 추론에는 느리지만 언제나 사용할 수 있고, 모든 연산을 지원하며, 동작을 예측하기 쉽습니다.

통합 메모리 아키텍처 덕분에 세 경로 모두 같은 물리 RAM을 바탕으로 동작합니다³. 한번 불러온 모델 가중치는 디스패치 대상이 바뀌어도 복사되지 않습니다. 이 아키텍처적 사실이 여러 타깃으로의 디스패치를 레이어별 복사 비용이 아니라 레이어별 스케줄링 결정으로 바꿔 놓습니다.

디스패치는 MLModelConfiguration.computeUnits로 제어합니다.

let config = MLModelConfiguration()
config.computeUnits = .all          // default: NE, GPU, CPU
// Other options:
// .cpuAndGPU
// .cpuAndNeuralEngine
// .cpuOnly
let model = try MyModel(configuration: config)

.all이 기본값이며 거의 모든 앱에서 올바른 선택입니다. 프레임워크는 연산마다 가장 빠른 경로를 고르고, 그 연산 단위 판단은 개발자가 직접 작성할 어떤 휴리스틱보다도 빠릅니다. 이를 덮어쓸 이유는 드뭅니다. 테스트 동등성을 위해 .cpuOnly를 강제하는 경우(경로에 따라 모델 동작이 달라지므로 결정적인 경로에서 테스트하고 싶을 때)나, 동시에 도는 다른 작업을 위해 Neural Engine을 비우려고 .cpuAndGPU를 강제하는 경우 정도입니다.

모델 변환: 툴링의 일

대부분의 ML 모델은 PyTorch나 TensorFlow에서, 또는 Apple의 Create ML로 직접 학습합니다. Core ML이 받아들이는 것은 .mlpackage 파일로, Xcode 13에서 도입되어 예전 .mlmodel을 대체하는 최신 포맷입니다⁴. 변환은 Apple의 오픈소스 Python 패키지인 coremltools로 진행합니다⁵.

PyTorch에서 Core ML로 가는 전형적인 변환은 세 단계를 거칩니다.

1. 학습이 끝난 PyTorch 모델을 불러와 추론 모드로 둡니다.
2. 프로덕션 입력 형태와 일치하는 예제 입력 텐서로 모델을 트레이스합니다.
3. 트레이스한 모델을 목표 iOS 배포 버전에 맞춰 coremltools로 변환합니다.

import torch
import coremltools as ct

model = MyTrainedModel()
model.load_state_dict(torch.load("weights.pth"))

example_input = torch.rand(1, 3, 224, 224)
traced_model = torch.jit.trace(model, example_input)

mlmodel = ct.convert(
    traced_model,
    inputs=[ct.ImageType(name="image", shape=example_input.shape)],
    minimum_deployment_target=ct.target.iOS26,
    compute_units=ct.ComputeUnit.ALL,
)
mlmodel.save("MyModel.mlpackage")

변환은 개발 환경에서 목표 iOS 배포 버전(minimum_deployment_target)을 대상으로 단 한 번만 일어납니다. 결과물인 .mlpackage가 Xcode 프로젝트에 넣는 산출물입니다. 런타임 앱이 coremltools를 실행하지는 않습니다. 최신 릴리스인 coremltools 9.0은 iOS 26까지의 배포 타깃, 모델 상태를 읽고 쓰는 기능(KV 캐시를 가진 트랜스포머 디코더 같은 상태 기반 모델용), int8 모델 입출력, 그리고 Python 3.13과 PyTorch 2.7 지원을 추가했습니다¹³.

변환에서 마주치는 실무적 함정은 두 가지입니다. 첫째, 동적 형태 입력은 ct.RangeDim으로 명시적으로 다뤄야 합니다. Core ML의 기본값이 정적 형태라서, 프로덕션 앱이 서로 다른 크기의 입력을 넘기면 도움이 되지 않는 오류가 나기 때문입니다. 둘째, Core ML에 대응 연산이 없는 PyTorch 커스텀 op에는 Core ML 커스텀 레이어(빠진 연산을 실행하는 Swift 코드)를 만들거나, 변환 전에 모델 아키텍처를 바꿔 그 연산을 없애야 합니다. 두 방법 모두 문서가 잘 갖춰져 있습니다⁵.

실제로 적용되는 지연 시간 예산

출시하는 앱에서 의미를 갖는 지연 시간 예산은 세 가지입니다.

16 ms(60 fps 라이브 UI). 실시간 카메라 필터, 프레임마다 갱신되는 AR 장면, 라이브 오디오 분석이 여기에 해당합니다. 이 예산에는 이미지 전처리, 모델 추론, 후처리, UI 갱신까지 모든 것이 포함됩니다. 여기에 들어가는 모델은 대체로 작고(MobileNetV3 급, 파라미터 1억 개 미만) Neural Engine에서 돕니다.

100 ms(인터랙티브 UI). 사용자가 어떤 동작을 하고 결과를 기다리는 경우입니다. 탭해서 식별하기, 그려서 인식시키기, 말해서 받아쓰기 같은 것들입니다. 예산에 여유가 있는 만큼 더 큰 모델도 감당합니다. 파라미터 10억 개 미만의 언어 모델, 작은 비전 트랜스포머, 그리고 프로덕션 수준 분류기 대부분이 넉넉하게 들어갑니다.

1초 이상(백그라운드 또는 배치). 사진 라이브러리 인덱싱, 문서 분석, 앱 실행 시 모델 예열이 여기에 속합니다. 더 큰 모델도 쓸 수 있지만 진행 표시기로 사용자의 기대치를 잡아 줘야 합니다. Foundation Models의 온디바이스 LLM은 컨텍스트 윈도가 큰 작업에서 이 영역에 들어옵니다.

이 예산들은 지침이지 절대적인 한계가 아닙니다. 다른 기기에서 나온 이론적인 수치를 믿기보다는 os_signpost나 Instruments의 Core ML 템플릿으로 목표 기기에서 직접 측정하는 것이 올바른 방법입니다⁶.

양자화: 작을수록 빨라질 때

Core ML은 여러 단계의 양자화를 지원합니다⁷:

• Float32(전체 정밀도). 학습의 기본값입니다. 가장 크고, 가장 정확하며, 가장 느립니다.
• Float16. 반정밀도입니다. GPU와 NE에서 더 작고 빠르며, 조건이 좋은 모델이라면 정확도 손실은 대체로 무시할 만합니다.
• INT8. 캘리브레이션을 동반한 8비트 정수 양자화입니다. Float32보다 대략 4배 작고, NE에서 흔히 2~4배 빠릅니다. 정확도 손실은 경우마다 다르지만, 비전 모델이라면 양자화를 고려한 학습으로 top-1 정확도 손실을 1% 미만으로 맞출 수 있습니다.
• INT4 이하. 최근 Core ML 버전이 특정 모델 아키텍처(LLM, 대형 비전 모델)에 한해 지원하는 공격적인 양자화입니다. 그 대가로 정확도 손실이 상당합니다. 이 기법은 모델 특성을 반영한 양자화 인식 학습과 함께 쓸 때 가장 잘 통합니다.

coremltools.optimize.coreml.linear_quantize_weights를 통한 선형 양자화 설정은 양자화 모드(linear_symmetric 또는 linear)와, 그보다 작은 가중치는 전체 정밀도로 남겨 두는 가중치 크기 임계값을 전역 op 설정으로 받습니다. 변환은 기존 .mlpackage를 대상으로 실행되어 양자화된 새 패키지를 만들어 내며, 둘을 번들에 나란히 담아 두고 기기 등급에 따라 어느 쪽을 불러올지 앱이 고르게 할 수도 있습니다.

양자화 여부는 모델마다 따로 판단할 문제입니다. 작은 분류기는 이미 연산이 저렴해서 이득이 없을 수 있고, 대형 언어 모델은 연산 대부분이 양자화된 가중치와의 행렬 곱셈이라 이득이 매우 큽니다. 올바른 접근은 양자화한 뒤 따로 떼어 둔 테스트 세트에서 정확도를 재고, 그 손실이 해당 용도에서 받아들일 만하면 출시하는 것입니다.

그대로 가져다 쓸 수 있는 Apple 기본 모델

Apple은 Core ML Models 페이지를 통해 사전 학습된 Core ML 모델을 여럿 제공합니다⁸. 알아 둘 만한 범주는 다음과 같습니다.

• 이미지 분류: MobileNetV2, ResNet50, SqueezeNet 계열. 모두 번들로 제공되어 Vision 프레임워크의 VNCoreMLRequest에 바로 넣을 수 있습니다.
• 객체 탐지: YOLOv3, MNIST, CenterNet 계열.
• 자세 추정: 신체 자세를 다루는 PoseNet(Vision의 VNDetectHumanBodyPoseRequest에 대한 기본 대안).
• 시맨틱 세그멘테이션: 이미지 분할을 위한 DeepLabV3.
• 텍스트 인식: Vision 내장 기능을 대신하는 ML 기반 OCR.

대부분의 앱은 Apple의 사전 학습 모델만으로도 별도 학습 없이 지각 기본기(분류, 탐지, 분할)를 충족할 수 있습니다. 언어 작업이라면 시스템의 온디바이스 LLM이 이 계층보다 완전히 위에 있습니다. Foundation Models 프레임워크가 고수준 Swift API로 그것을 노출하며, 오프라인에서 무료로 동작하고 직접 번들에 넣거나 변환할 모델 파일도 없습니다.

모델 암호화와 App Store 고려 사항

앱 번들 안의 .mlpackage는 IPA를 풀어 보는 사람이라면 누구나 읽을 수 있습니다. 의미 있는 지적 재산에 해당하는 모델이라면 Apple이 Encrypt your Core ML model 워크플로를 통한 모델 암호화를 지원합니다⁹: 암호화 키를 Xcode로 생성해 CloudKit으로 관리하고, 번들 안의 모델은 암호화된 상태로 두면 Core ML이 로드 시점에 복호화합니다.

다만 대부분의 앱에서 암호화는 과합니다. 흔한 ImageNet 데이터로 학습한 모델은 경쟁 우위의 원천이 아니며, 암호화해 봐야 지킬 만한 것은 지키지 못한 채 운영 복잡도만 늘어납니다. 암호화는 진짜 학습 데이터 투자나 경쟁 우위를 담고 있는 모델에 아껴 두십시오.

온디바이스 프라이버시: 아키텍처가 만드는 승리

프라이버시 이야기는 단순합니다. Core ML 추론은 전적으로 기기 안에서 일어납니다. 입력 데이터(이미지, 오디오, 텍스트)는 기기를 떠나지 않습니다. 모델 파일도 로컬, 추론도 로컬, 결과도 로컬입니다.

규제가 강한 산업(의료, 금융, 교육)의 앱에서는 이 아키텍처적 사실이 컴플라이언스 작업 한 종류를 통째로 없애 줍니다. 개인정보 처리방침에 추가할 서드파티 데이터 처리자가 없습니다. 보안을 검토할 모델 API 엔드포인트도 없습니다. 데이터가 아예 움직이지 않으니 데이터 소재지 문제도 생기지 않습니다.

Privacy Manifest 포맷¹⁰은 App Store 제출을 위해 이 프라이버시 이야기를 문서로 명문화합니다. 온디바이스 추론에 Core ML을 쓰고 그 외에는 아무것도 하지 않는 앱이라면, 추론 경로에 대해 서드파티 데이터 공유가 전혀 없다고 선언할 수 있습니다. 제출 과정은 빨라지고, 프라이버시 심사는 짧아지며, 사용자에게 보이는 개인정보 보호 영양성분표도 더 깔끔해집니다.

에이전트 워크플로와의 연결

Core ML은 이 클러스터에서 이미 다룬 세 가지 패턴과 맞물립니다.

Vision 프레임워크의 VNCoreMLRequest. 커스텀 Core ML 모델은 전처리가 자동으로 이루어지는 Vision 파이프라인을 통해 실행됩니다. 이 패턴(Vision Framework에서 다룹니다)은 iOS 앱 안에 커스텀 이미지 분류기나 탐지기를 담아 출시하는 정석적인 방법입니다.

Foundation Models의 온디바이스 LLM. Apple Intelligence의 시스템 LLM은 Foundation Models 프레임워크 뒤에 있으며, WWDC 2026 시점에서 Apple은 그것을 구동하는 추론 프레임워크로 Core AI를 지목합니다¹¹. 그래도 이 글의 개념은 그대로 옮겨 갑니다. 연산 유닛 디스패치, 양자화된 가중치, 지연 시간 예산은 직접 변환한 모델을 지배하는 것과 똑같이 시스템 LLM도 지배하기 때문입니다. 프레임워크를 다룬 글이 LLM API를 설명한다면, 이 글은 그 아래에 있는 추론 패턴을 설명합니다.

로컬 ML을 쓰는 App Intents 도구. 로컬 이미지 분류기나 텍스트 분류기를 실행하는 AppIntent는 네트워크 왕복 없이 구조화된 결과를 Apple Intelligence에 돌려줍니다. 바로 이 조합이 “에이전트형 Apple”을 실제로 프라이빗하게 만듭니다. 프레임워크가 뒷받침해 주기 때문에 에이전트의 도구가 로컬에서 도는 것입니다.

클라우드 추론이 옳은 선택일 때

Core ML의 천장은 기기의 연산 능력입니다. 클라우드가 맞는 경우는 세 가지입니다.

번들에 담기에는 너무 큰 모델. 70B 파라미터 LLM은 앱 번들에 들어가지 않습니다. 그 규모의 워크로드라면 클라우드 추론(또는 가중치를 스트리밍해 온디바이스로 돌리는 별개의 패턴)이 맞는 도구입니다.

추론 중에 기기 간 상태를 공유해야 할 때. 추론 도중에 공유 데이터베이스를 읽거나 써야 하는 모델(수십억 건의 레코드를 대상으로 협업 필터링을 하는 추천 시스템 같은 것)입니다. 순수하게 로컬인 Core ML의 모델은 여기에 맞지 않습니다.

빠른 모델 반복. 모델 업데이트를 매일 내보내는 팀은 서버 사이드 추론에서 이득을 봅니다. 롤아웃에 App Store 심사 주기가 끼어들지 않기 때문입니다. 모델을 앱 안에 담는 Core ML의 방식은 모델 개정 주기에 마찰을 더하며, 이 트레이드오프는 실재합니다.

정리하면 이렇습니다. 규모와 반복 속도에서는 클라우드가 이기고, 지연 시간과 비용과 프라이버시에서는 Core ML이 이깁니다.

WWDC 2026 이후 Core ML의 자리

WWDC 2026은 이 글 아래에 깔린 지도를 다시 그렸지만, 글의 내용을 무효로 만들지는 않았습니다. Apple은 “Run AI models in your app on Apple silicon”을 개요로 내건 iOS 27 프레임워크 Core AI를 발표했고, 세션 324에서 Core AI가 온디바이스 Apple Intelligence를 구동하는 추론 프레임워크이며 이제 서드파티 앱에도 열렸다고 밝혔습니다¹¹. Core ML의 컨버터가 하드웨어와 최적화 결정을 대신 내려 준다면, Core AI는 그 레버를 개발자 손에 쥐여 줍니다. 명시적인 모델 스페셜라이제이션, 관리되는 아티팩트 캐시, 연산 유닛 지정, 비동기 연산 스트림이 그것입니다. 자세한 분해는 Core AI: Apple silicon에서 모델 실행하기에 담았습니다.

방향성을 알려 주는 신호는 문서만 볼 때보다 더 강합니다. WWDC 2026 머신러닝 그룹 랩에서 한 Core AI 엔지니어는, Apple이 신경망을 다루는 모든 사람에게 앞으로 Core AI로 옮겨 갈 것을 요청하고 있으며 Core ML은 자리를 지키되 의사결정 트리 같은 전통적인 머신러닝에 집중하게 된다고 말했습니다¹². 이 발언은 공표된 정책이 아니라 랩에서의 의역이지만, 이번 릴리스의 모양새와는 들어맞습니다. 새로운 툴링도, 새로운 포맷도, Apple Intelligence 워크로드도 모두 Core AI가 가져갔기 때문입니다.

오늘 앱을 출시하는 입장에서의 실무적 해석은 다음과 같습니다.

• 기존 Core ML 배포는 계속 동작합니다. iOS 27에서 .mlpackage 경로를 폐기 예정으로 돌린 것은 없고, coremltools 9.0은 2025년 11월이라는 최근 시점에 새 기능(iOS 26 타깃, 상태 기반 모델, int8 IO)을 내놓았습니다¹³.
• iOS 27 미만에서는 Core ML이 유일한 선택지이며, 고정된 변환 모델에 컨버터의 기본값이면 충분한 경우에는 현실적인 선택지이기도 합니다.
• iOS 27 이상을 겨냥한 새 신경망 작업이라면 Core AI를 먼저 검토해야 합니다. 특히 필요한 스페셜라이제이션이나 캐싱, 스케줄링 제어를 구체적으로 짚을 수 있다면 더욱 그렇습니다.
• 다른 계층은 움직이지 않습니다. 시스템 LLM은 Foundation Models 뒤에 그대로 있고, MLX는 직접 보유한 오픈 웨이트 모델과 파인튜닝을 위한 임베더블 배열 프레임워크로 남습니다. Core ML이냐 Core AI냐는 내 모델의 실행 계층을 무엇으로 할지에 대한 물음이지, 저 둘에 대한 물음이 아닙니다.

이 패턴이 iOS 26 이상 앱에 갖는 의미

세 가지로 정리합니다.

1. 번들에 들어가고 사용자가 곧바로 활용할 수 있는 결과를 호출마다 내놓는 모델이라면 기본은 Core ML입니다. 이미지 분류, 객체 탐지, 오디오 분류, 제스처 인식, 임베딩 생성, 중소 규모의 언어 작업이 여기에 해당합니다. 프레임워크의 자동 디스패치와 Apple Silicon NPU가 1밀리초 미만에서 수십 밀리초 수준의 추론을 공짜로 만들어 냅니다.

2. 정확도 손실이 받아들일 만하다면 과감하게 양자화하십시오. INT8은 대체로 안전하고, INT4는 크기 절감이 중요한 대형 모델에 적합합니다. 양자화가 어디서나 안전하다고 믿지 말고 따로 떼어 둔 세트에서 정확도를 측정하십시오.

3. 완전한 로컬 파이프라인을 위해 Vision, Foundation Models와 함께 쓰십시오. Core ML이 엔진이고, Vision은 그 위의 지각 API이며, Foundation Models는 그 위의 LLM입니다. 클러스터의 Vision 글과 Foundation Models 글이 더 상위의 표면을 다룹니다.

Apple Ecosystem 클러스터 전체는 다음과 같습니다. 타입이 있는 App Intents, MCP 서버, 라우팅 문제, Foundation Models, 런타임과 툴링 LLM의 구분, 세 가지 표면, 단일 진실 공급원 패턴, 두 개의 MCP 서버, Apple 개발을 위한 hooks, Live Activities, watchOS 런타임, SwiftUI 내부, RealityKit의 공간 멘탈 모델, SwiftData 스키마 규율, Liquid Glass 패턴, 멀티 플랫폼 출시, 플랫폼 매트릭스, Vision 프레임워크, Symbol Effects, 내가 쓰지 않기로 한 것들. 허브는 Apple Ecosystem 시리즈에 있습니다. AI 에이전트를 곁들인 iOS 개발의 더 넓은 맥락은 iOS Agent Development 가이드를 참고하십시오.

자주 묻는 질문

Core ML은 Neural Engine, GPU, CPU 중 무엇을 쓸지 어떻게 정합니까?

Core ML은 모델 그래프의 연산을 하나씩 살펴보고, 그 연산을 지원하는 가장 빠른 타깃으로 보냅니다. Neural Engine은 지원되는 연산(대부분의 행렬 곱셈, 합성곱, 어텐션)을 가장 낮은 지연 시간과 전력으로 처리합니다. NE가 지원하지 않는 연산은 GPU가 맡고, 나머지는 CPU가 처리합니다. 이 결정은 연산 단위로 자동으로 이루어지며, 손으로 작성한 휴리스틱보다 빠릅니다.

항상 .computeUnits = .all을 써야 합니까?

거의 언제나 그렇습니다. 프레임워크의 자동 디스패치는 잘 조율되어 있습니다. 출력 동등성을 테스트할 때(부동소수점 반올림 차이로 같은 모델이 NE와 CPU에서 조금 다른 결과를 냅니다) .cpuOnly로, 동시에 도는 작업을 위해 Neural Engine을 비우려면 .cpuAndGPU로 덮어쓰십시오.

.mlpackage와 .mlmodel의 실질적인 차이는 무엇입니까?

.mlpackage는 Xcode 13에서 도입된 최신 포맷입니다. 저장된 메타데이터, ML Program(mlprogram) 컴파일을 위한 여러 모델 변형, 그리고 iOS 13 이후의 툴체인을 지원합니다. .mlmodel은 레거시 포맷입니다. 둘 다 MLModel로 불러올 수 있지만, 새로 개발한다면 .mlpackage를 써야 합니다.

앱 번들에 넣는 Core ML 모델은 얼마나 커도 됩니까?

정해진 한계는 없지만 App Store 번들 크기는 다운로드 기준 4 GB로 제한되며, 무선(OTA) 설치에는 현실적인 제약이 따릅니다. 시스템의 온디바이스 LLM은 이 질문 자체를 비켜 갑니다. OS가 배포하고, 앱은 아무것도 번들에 담지 않은 채 Foundation Models로 접근하기 때문입니다. 앱에 담는 모델이라면 100 MB 미만은 여유롭고, 100~500 MB는 실행 시점 로딩 전략이 있으면 가능하며, 500 MB를 넘으면 BGProcessingTask 백그라운드 다운로드나 온디맨드 리소스로 다루는 편이 가장 낫습니다.

새 모델에는 Core ML을 써야 합니까, Core AI를 써야 합니까?

iOS 27 미만에서는 Core ML이 유일한 선택지입니다. iOS 27 이상에 대해 Apple이 밝힌 방향은 신경망에는 Core AI, 전통적인 머신러닝과 기존 배포에는 Core ML 유지입니다¹¹¹². 고정된 변환 모델이 있고 컨버터의 기본값으로 충분하다면 Core ML로도 문제없이 출시할 수 있습니다. 스페셜라이제이션, 캐싱, 스케줄링을 명시적으로 제어해야 한다면, 바로 그 제어를 제공하려고 Core AI가 존재합니다.

양자화가 모델 정확도를 해쳤는지는 어떻게 압니까?

테스트 세트를 따로 떼어 두고, 원본 Float32 모델과 양자화 모델에서 각각 추론을 돌린 뒤 지표를 비교하십시오(분류기는 top-1 정확도, 탐지기는 F1, 언어 모델은 perplexity, 번역은 BLEU 등). 그런 다음 애플리케이션이 요구하는 정확도 기준에 따라 판단하면 됩니다. 손실 함수 안에서 양자화를 시뮬레이션하며 학습하는 양자화 인식 학습을 쓰면 대체로 정확도 손실 대부분을 되찾을 수 있습니다.

참고 문헌