비동기 예측으로 Core ML 통합 개선하기

♪ ♪

안녕하세요, 저는 벤 러빈이고 Core ML 팀 엔지니어입니다 오늘 여러분과 함께 알아볼 것은 앱에 Core ML을 통합하는 것의 새로운 기능입니다 앱에서 지능형 경험 구축은 그 어느 때보다 쉬워졌습니다 Xcode SDK는 기계 학습 기반 기능을 활용하고 배포하기 위한 탄탄한 기반을 제공합니다 도메인별 프레임워크를 사용하면 간단한 API를 통해 내장된 지능에 액세스할 수 있죠 이런 프레임워크가 제공하는 기능은 Apple에서 학습시키고 최적화한 모델을 기반으로 합니다 이러한 모델들은 Core ML을 통해 실행됩니다 Core ML 프레임워크는 기기에서 기계 학습 모델을 실행하기 위한 엔진을 제공하죠 앱에 맞게 맞춤화된 모델을 쉽게 배포할 수 있도록 합니다 이 프레임워크는 하드웨어 세부 사항을 추출하죠 Apple 실리콘의 고성능 컴퓨팅 기능을 활용하고 Accelerate 및 Metal 프레임워크 제품군의 도움을 받으면서요 Core ML의 임무는 기계 학습 모델을 앱에 통합하도록 지원하는 겁니다 올해 Core ML에서 중점을 둔 것은 성능과 유연성이었습니다 워크플로, API 표면 그리고 기본 추론 엔진도 개선했습니다 Core ML 통합을 최적화할 수 있는 워크플로를 소개하고 새로운 기회를 강조하기 전에 잠재적인 성능 이점에 대한 아이디어를 소개합니다 최신 OS로 업데이트하기만 하면 자동으로 얻을 수 있는 거죠

iOS 16과 17의 상대적인 예측 시간을 비교하면 iOS 17이 더 빠른 모델이 많다는 것을 알 수 있습니다 OS에 따라서 추론 엔진의 속도도 향상될 수 있으며 모델을 재컴파일하거나 코드를 변경할 필요가 없습니다 다른 플랫폼에서도 마찬가지입니다 물론 속도 향상 정도는 모델과 하드웨어에 따라 다릅니다 주제도 돌아가서 Core ML을 앱과 통합할 때 워크플로에 대한 개요부터 말씀드리겠습니다 그와 함께 워크플로의 여러 부분에서 최적화할 기회가 있다는 걸 자세히 살펴볼 것입니다 그런 다음 모델 통합을 살펴보고 새 API와 동작을 알아보겠습니다 컴퓨팅 가용성, 모델 수명 주기 비동기 예측 등이 바로 그것이죠 Core ML 워크플로의 개요부터 시작하겠습니다 Core ML을 앱에 통합하는 데는 두 단계가 있습니다 첫 번째는 모델을 개발하는 단계고 두 번째는 앱 내에서 해당 모델을 사용하는 단계입니다 모델 개발에는 여러 가지 옵션이 있습니다 여러분이 모델을 직접 개발하는 가장 편리한 방법 중 하나는 Create ML을 사용하는 것입니다 Create ML은 일반적인 기계 학습 작업에 대한 다양한 템플릿을 주고 고도로 최적화된 OS 내장 모델을 활용할 수 있습니다 모델 개발 워크플로를 안내하고 상호 작용을 통해 결과를 평가할 수 있죠 더 자세한 내용은 올해의 Create ML 동영상에서 확인하세요

모델을 개발하는 또 다른 방법은 파이썬 ML 프레임워크들 중 하나로 모델을 '훈련'하는 거죠 그런 다음 CoreMLTools 파이썬 패키지를 써서 Core ML 모델 형식으로 변환합니다 마지막으로 모델을 평가하는 것이 중요합니다 이때는 Apple 하드웨어에서 정확도와 성능으로 평가합니다 평가에서 얻은 피드백을 사용하면 종종 이런 단계 중 일부를 재검토해야 하는 경우가 있죠 모델을 더욱 최적화하기 위해서요 최적화할 수 있는 기회는 단계마다 여럿 존재합니다 훈련 단계에서는 훈련 데이터를 수집, 선택하는 방법이 중요하죠 모델이 배포될 때는 모델에 전송되는 데이터와 사용자에게 전달되는 데이터에 일관성이 있어야 합니다 모델 아키텍처 선택도 중요합니다 각각 고유한 트레이드오프가 있는 여러 옵션을 찾아볼 수 있는데 훈련 데이터 요구 사항과 정확도 크기 및 성능 등이 포함되죠 많은 경우 이런 트레이드오프는 완전히 파악되지 않을 수 있고 전체 개발 절차가 이뤄지는 동안 반복을 몇 번씩 해야 합니다 다음은 모델 변환입니다 Core ML 툴은 여러 가지 옵션을 제공하여 변환된 모델의 정밀도, 설치 공간 계산 비용 등을 최적화하도록 돕죠 앱의 데이터 흐름에 가장 적합한 입출력 형식을 선택하여 불필요한 복사를 방지할 수 있으며 입력 모양이 다를 수 있는 경우 해당 변형을 지정할 수 있죠 하나의 모양만 선택하거나 여러 모양별 모델 중에 바꾸지 않고요 전체 모델 또는 개별 작업에 대해 컴퓨팅 정밀도를 명시적으로 설정할 수 있습니다 float32 및 float16 모두 사용 가능하며 계산 정밀도 외에도 모델 매개변수가 표현되는 방식을 일부 제어할 수 있습니다 CoreMLTools에는 유틸리티 세트가 함께 제공되는데 이는 훈련 후 가중치 정량화 및 압축을 위한 것입니다 이러한 유틸리티를 사용하면 모델의 설치 공간을 크게 줄이고 기기별 성능을 개선할 수 있죠 하지만 이를 달성하려면 정확도에는 약간의 트레이드오프가 생깁니다 이 부분에 도움이 되는 몇 가지 새로운 도구가 있습니다 CoreMLTools 패키지에 새로운 최적화 하위 모듈이 있죠 훈련 후 압축 유틸리티를 통합 및 업데이트하고 파이토치용 새 양자화 인식 훈련 확장 기능을 추가합니다 데이터 중심 최적화에 액세스할 수 있도록 하여 훈련 중에 양자화된 모델의 정확도를 보존하는 데 도움을 주죠 이는 활성화 정량화를 지원하는 새로운 작업과 결합됩니다 Core ML의 ML 프로그램 모델 유형에서요 자세한 내용은 올해의 세션 'Core ML로 기계 학습 모델 압축하기'를 확인하시기 바랍니다

다음은 평가입니다 모델을 평가하는 한 가지 방법은 CoreMLTools를 사용하여 파이썬 코드에서 직접 변환된 모델에 대한 예측을 실행하는 거죠 앱 코드에서 사용하는 것과 동일한 Core ML 추론 스택을 사용하고 모델 변환 중의 선택이 모델의 정확도와 성능에 어떤 영향을 미치는지 빠르게 확인할 수 있습니다 Xcode 역시 몇 가지 유용한 도구를 제공합니다 모델의 평가 및 탐색과 관련해서요 모델 미리보기는 일반적인 모델 유형 대부분에서 가능하죠 이를 통해 모델에 몇 가지 샘플 입력을 제공하고 코드를 작성하지 않고도 예측 출력을 미리 볼 수 있습니다 Core ML 성능 보고서는 연결된 모든 기기에서 로드, 예측, 컴파일 시간에 대한 모델 계산 성능 분석을 제공합니다 이는 모델 아키텍처를 평가하는 데 유용합니다 모델을 훈련하기 전이라도요 이제 전체 워크플로로 돌아가죠 다음 주제는 모델 통합입니다 모델 통합은 앱 개발의 일부입니다 앱에서 사용하는 다른 리소스와 마찬가지로 Core ML 모델을 사용하는 방법을 신중하게 관리하고 최적화해야죠

모델 통합에는 세 단계가 있습니다 먼저 모델을 사용하기 위한 응용 프로그램 코드를 작성합니다 모델을 로드할 위치와 시기 모델의 입력 데이터를 준비하고 예측을 수행하며, 결과를 사용하는 방법에 대한 코드가 있죠

그런 다음 이 코드를 모델과 함께 컴파일합니다 셋째, 앱 내에서 실행 중인 모델을 테스트, 실행 및 프로파일링합니다 프로파일링과 관련해서는 Core ML 및 Neural Engine 도구가 도움이 될 수 있죠 이 또한 설계 및 최적화를 반복하는 프로세스로서 출시 준비가 될 때까지 계속됩니다 올해 모델 통합을 최적화하기 위해 몇 가지 새로운 기능이 추가되었습니다 첫 번째는 컴퓨팅 가용성입니다 Core ML은 모든 Apple 플랫폼에서 지원되며 기본적으로 사용 가능한 모든 컴퓨팅을 고려하여 실행을 최적화합니다 여기에는 CPU, GPU 및 Neural Engine이 포함됩니다 그러나 이러한 컴퓨팅 기기의 성능 특성과 가용성은 앱이 실행되는 지원 하드웨어에 따라 달라지며 이는 ML 기반 기능의 사용자 경험에 영향을 주거나 모델 및 구성의 선택에 영향을 줄 수 있습니다 예를 들어, 일부 경험은 Neural Engine에 실행 모델이 필요할 수 있죠 성능 또는 전력 요구 사항을 충족하기 위해서요 새 API가 생겼는데요 컴퓨팅 기기 가용성의 런타임 검사를 하는 API입니다 MLComputeDevice 열거형은 컴퓨팅 기기의 유형과 관련 값 내 특정 컴퓨팅 기기의 속성을 캡처합니다 MLModel의 availableComputeDevices 프로퍼티를 사용하면 Core ML에서 쓸 수 있는 기기를 검사할 수 있습니다 예를 들어, 이 코드는 사용 가능한 Neural Engine이 있는지 확인하죠 보다 구체적으로 사용 가능한 모든 컴퓨팅 기기 컬렉션에 Neural Engine 유형 기기가 있는지 확인합니다 모델 통합의 다음 주제는 모델 수명 주기를 이해하는 겁니다 먼저 다양한 모델 에셋 유형을 검토하는 것부터 시작하겠습니다 여기에는 두 종류가 있죠 소스 모델과 컴파일된 모델입니다 소스 모델의 파일 확장자는 MLModel 또는 MLPackage이며 구성 및 편집을 위해 설계된 개방형 형식입니다 컴파일된 모델의 파일 확장자는 MLModelC이며 런타임 액세스를 위해 설계되었습니다 대부분의 경우 소스 모델을 앱 타깃에 추가하면 Xcode가 모델을 컴파일하여 앱의 리소스에 넣습니다 런타임에 모델을 사용하기 위해 MLModel을 인스턴스화합니다

인스턴스화는 컴파일된 형식에 대한 URL과 선택적 구성을 취합니다 그 결과인 MLModel은 필요한 모든 리소스를 로드하죠 지정된 구성 및 기기별 하드웨어 기능을 기반으로 최적의 추론을 하기 위해서요 이 로드 중에 어떤 일이 생기는지 자세히 살펴보겠습니다 먼저 Core ML은 캐시를 확인하여 구성 및 기기를 기반으로 모델을 이미 특성화했는지 확인합니다 특성화했다면 캐시에서 필요한 리소스를 로드하고 반환합니다 이를 캐시된 로드라고 합니다 캐시에서 구성을 찾지 못하면 기기에 특성화된 컴파일을 시작합니다 이 프로세스가 완료되면 출력을 캐시에 추가하고 그곳에서 로드를 완료합니다 이를 캐시되지 않은 로드라고 하죠 모델에 따라 캐시되지 않은 로드에 상당한 시간이 걸릴 수 있습니다 그러나 이 작업은 기기에 맞게 모델을 최적화하고 후속 로드를 최대한 빠르게 만드는 데 중점을 두며

기기 특성화 도중에 Core ML은 먼저 모델을 파싱하고 일반 최적화 패스를 적용합니다 그런 다음 특정 컴퓨팅 기기용 작업 체인을 세그멘테이션합니다 예상 성능 및 하드웨어 가용성에 따라서요 이 세그멘테이션은 캐시됩니다 마지막 단계는 각 세그먼트가 컴퓨팅 기기별 컴파일을 거치는 것입니다 할당된 컴퓨팅 기기에 대해서요 이 컴파일에는 특정 컴퓨팅 기기에 대한 추가 최적화가 포함되며 컴퓨팅 기기에서 실행할 수 있는 아티팩트를 출력합니다 완료되면 Core ML은 이러한 아티팩트를 캐시하여 후속 모델 로드에 사용합니다

Core ML은 디스크에 특수 에셋을 캐시하며 이 에셋은 모델의 경로 및 구성에 연결됩니다 이러한 에셋은 앱을 실행하고 기기를 재부팅할 때도 유지되죠 기기의 디스크 여유 공간이 부족하거나 시스템 업데이트가 있거나 컴파일된 모델이 삭제 또는 수정된 경우 운영 체제에서 캐시를 삭제합니다 이 경우 다음 모델 로드에서 기기 특성화를 다시 수행합니다

모델 로드가 캐시에 도달했는지 여부를 확인하려면 Core ML Instrument로 앱을 추적하고 로드 이벤트를 확인하면 됩니다 로드 이벤트에 '준비 및 캐시' 레이블이 있으면 캐시되지 않은 로드이므로 Core ML이 디바이스 특성화를 수행하고 결과를 캐싱한 것입니다 로드 이벤트에 '캐시됨'이라는 레이블이 있으면 캐시된 로드이며 기기 특성화를 수행하지 않은 것입니다 이는 ML프로그램 모델에 특별히 추가된 기능으로 Core ML 성능 보고서를 통해 로드 비용에 대한 가시성을 확인할 수 있으며 기본적으로 캐시된 로드 중앙값을 표시합니다

캐시되지 않은 로드 시간도 표시하는 옵션이 생겼죠 모델을 로드하는 건 지연 시간과 메모리 측면에서 비용이 많이 들 수 있는데요 몇 가지 일반적인 모범 사례가 있습니다

먼저 UI 스레드에서 앱이 실행될 때 모델을 로드하지 않습니다 그 대신에 비동기 로드 API를 사용하거나 모델을 느리게 로드하는 것이 좋습니다 다음으로, 앱이 많은 예측을 연속해서 실행할 것 같다면 모델을 로드된 상태로 유지합니다 시퀀스의 각 예측에 대해 모델을 다시 로드하지 않고요 마지막으로, 앱이 한동안 사용하지 않을 경우에는 모델을 언로드하면 메모리 부담을 완화할 수 있으며 캐싱 덕분에 후속 로드가 더 빨라질 수 있습니다 모델이 로드되면 이제 그 모델로 예측을 실행할 차례입니다 새로운 비동기 옵션을 직접 보여드리죠

새로운 비동기 예측 API를 보여드리기 위해 앱을 사용해 보겠습니다 이 앱은 이미지 갤러리를 표시하고 이미지에 필터를 적용할 수 있죠 Core ML 모델을 사용하는 컬러화 필터에 초점을 맞춰 볼게요 그레이스케일 이미지를 입력으로 받아 컬러로 바뀐 이미지를 출력하는 필터죠 다음은 앱이 실제로 작동하는 예제입니다 그레이스케일 원본 이미지를 로드하는 것으로 시작해서 컬러화 이미지 모드를 선택하면 Core ML을 사용하여 이미지를 컬러로 바꿉니다 아래로 스크롤하면 모델이 확실히 작동하지만 예상보다 약간 느리고 더 아래로 스크롤하면 이미지가 컬러로 바뀌는 데 시간이 꽤 걸리는 것을 알 수 있죠

다시 위로 스크롤하면 모든 이미지를 한꺼번에 바꾸느라 시간이 걸리는 것처럼 보입니다 하지만 제 SwiftUI 코드에서는 LazyVGrid를 써서 이미지를 유지하고 있죠 그래서 뷰가 화면에서 벗어날 때는 작업을 취소해야 합니다 현재 구현한 것을 살펴보면서 성능이 부족한 이유와 취소되는 작업이 존중되지 않는 이유를 알아보죠 이렇게 구현돼 있는데요 동기식 예측 API는 스레드로부터 안전하지 않으므로 앱은 모델에서 예측이 연속적으로 실행되게 해야 합니다 이를 위해 ColorizingService를 액터로 만들고 컬러화 메서드 한 번에 하나씩 호출할 수 있게 합니다 이 액터에는 colorizerModel이 있는데 이는 자동 생성 된 인터페이스로서 앱에 번들된 모델용입니다 colorize 메서드는 현재 두 가지 작업을 수행합니다 먼저 모델의 입력 크기를 맞추기 위해 이미지 크기를 조정하는 등 모델에 대한 입력을 준비합니다 그런 다음 입력을 모델에 넣어 컬러화된 출력을 얻습니다 Core ML Instrument 템플릿으로 앱의 Instrument 트레이스를 캡처했습니다

Instrument 트레이스를 보면 예측이 연속적으로 실행되는 것이 보입니다 이는 액터 격리에 의해 보장됩니다 그러나 다음 예측이 실행되기 전에 각 예측 사이에 공백이 있어 성능 부족의 원인이 되고 있습니다 이는 액터 격리가 모델 예측뿐만 아니라 입력 준비까지 래핑하고 있기 때문입니다 한 가지 개선 사항은 입력 준비를 비격리 메서드로 표시하여 다음 컬러화 요청이 액터에 들어오는 것을 차단하지 않도록 하는 것입니다 이렇게 하면 도움이 되겠지만 Core ML 예측 자체는 여전히 직렬화되어 처리에 병목 현상이 발생합니다 Core ML 예측 자체에 동시성을 활용하려면 배치 예측 API를 고려할 수 있습니다 이는 일괄로 입력을 받아 모델에 넣는 것입니다 내부적으로 Core ML은 가능한 경우 동시성을 활용합니다 컬러화 메서드의 배치 버전을 만드는 것은 매우 간단합니다 하지만 입력을 일괄로 수집하여 이 메서드에 전달하는 법을 알아내는 게 어려운 부분이죠 실제로 이 사용 예에는 배치 예측 API를 사용하기 어렵게 만드는 여러 가지 측면이 있습니다 배치 API는 작업량이 정해져 있을 때 쓰는 것이 가장 좋죠 이 경우 처리할 이미지의 양은 고정된 것이 아니라 화면 크기와 스크롤 횟수에 따라 달라집니다 배치 크기를 선택할 수 있지만 배치 크기에 안 맞아도 처리해야 하는 경우를 처리해야죠 또한 이미지가 일괄적으로 컬러화되는 경우에는 UI 환경이 달라질 것입니다 마지막으로 사용자가 스크롤로 멀어지더라도 배치를 취소할 수 없다는 점입니다

이러한 문제 때문에 저는 한 번에 하나의 예측만을 처리하는 API를 계속 사용할 것입니다 새로운 비동기 예측 API는 매우 유용할 수 있습니다 이는 스레드로부터 안전하며 Core ML과 Swift를 동시에 사용하는 데 적합하죠 코드를 비동기 설계로 전환하기 위해 먼저 컬러화 메서드를 비동기로 변경한 다음 새로운 비동기 버전의 API를 사용하는 데 필요한 예측 호출 앞에 await 키워드를 추가한 다음 ColorizingService를 액터가 아닌 클래스로 변경했죠 이렇게 하면 여러 이미지를 동시에 컬러화할 수 있죠 마지막으로 메서드의 시작 부분에 취소 확인을 추가했습니다 비동기 예측 API는 특히 여러 예측이 동시에 요청되는 경우 취소에 응답하기 위해 최선을 다하지만 이 경우 시작 부분에 추가 확인을 포함하는 것이 가장 좋습니다 이렇게 하면 컬러화 메서드가 입력 전에 작업이 취소된 경우 입력 준비를 피할 수 있습니다 이제 이러한 변경 사항을 적용하고 앱을 다시 실행해 보겠습니다

이전과 마찬가지로 컬러화 모드로 설정하겠습니다 이미 이미지가 훨씬 빠르게 컬러화되고 있음을 알 수 있습니다 그리고 밑으로 빠르게 스크롤하면 이미지가 거의 즉시 로드됩니다 조금 위로 스크롤하면 이미지가 다시 컬러화되고 있음을 확인할 수 있습니다 이는 처음으로 컬러화 호출이 성공적으로 취소됐음을 의미합니다 하단으로 빠르게 스와이프했을 때요 이 새로운 비동기 디자인을 사용한 트레이스를 보면 여러 이미지에서 동시에 예측이 실행됐음을 알 수 있습니다 이것은 여러 예측 간격이 수직으로 쌓여 있는 것으로 표시되며 이 모델은 Neural Engine에서 부분적으로 실행되므로 Neural Engine Instrument에서도 관찰할 수 있습니다 이미지를 순차적으로 컬러화했던 초기 구현에서는 스크롤 없이 이미지의 초기 뷰를 컬러화하는 데 약 2초가 걸렸고

이미지를 동시에 컬러화하는 비동기 구현으로 전환한 후에는 그 시간이 약 1초로 절반가량 단축되었습니다 따라서 전반적으로 두 배로 향상할 수 있었죠 비동기 예측 API를 이용하고 컬러화 모델의 동시성을 활용해서요 그러나 특정 모델과 사용 예에서 동시 설계가 갖는 이점의 크기는 여러 요인에 따라 달라집니다 모델의 작업 컴퓨팅 유닛 및 하드웨어 조합 컴퓨팅 기기의 다른 작업에 따라 다르다는 점을 유의하세요 또한 기계 학습 프로그램과 파이프라인 모델 유형은 예측을 동시에 실행할 때 최상의 성능 향상을 제공합니다

전반적으로 앱에 동시성을 추가할 때는 워크로드를 신중하게 프로파일링하여 실제로 사용 예에 도움이 되는지 확인해야 합니다

앱에 동시성을 추가할 때 유념해야 할 또 다른 중요 사항은 메모리 사용량입니다 많은 모델 입력 및 출력 세트를 메모리에 동시에 로드하면 앱의 최대 메모리 사용량이 크게 증가할 수 있으며 이는 Core ML Instrument와 할당 Instrument를 결합하여 프로파일링할 수 있습니다

트레이스를 보면 앱의 메모리 사용량이 빠르게 증가하고 있죠 컬러화 모델을 실행하기 위해 많은 입력을 메모리에 로드해서요

제 코드의 컬러화 메서드에 흐름 제어가 없기 때문에 동시에 컬러화되는 이미지의 양에 제한이 없는 건 잠재적 문제입니다 모델의 입력과 출력이 작으면 문제가 되지 않을 겁니다 하지만 입력과 출력이 크면 메모리에 동시에 많은 입력과 출력 세트가 들어가 앱의 최대 메모리 사용량이 크게 증가할 수 있습니다

이를 개선하는 방법은 in-flight 예측의 최대량을 제한하는 로직을 추가하는 겁니다 이렇게 하면 메모리에 동시에 로드되는 입력 및 출력이 줄어들어 예측을 실행하는 동안 최대 메모리 사용량을 줄일 수 있습니다 이 예에서는 이미 작업 중인 항목이 두 개 있는 경우 이전 항목이 완료될 때까지 새 작업 항목을 연기합니다 가장 좋은 전략은 사용 예에 따라 달라집니다 예를 들어 카메라에서 데이터를 스트리밍할 때는 작업을 연기하지 말고 중단하는 것이 좋습니다 이렇게 하면 프레임이 누적되어 시간적 관련성이 없는 작업 수행을 방지할 수 있습니다 한 걸음 물러나 다양한 예측 API를 언제 사용해야 할지에 대한 일반적인 지침은 다음과 같습니다

동기식 콘텍스트에서 각 입력을 사용할 수 있는 시간이 모델 지연 시간에 비해 큰 경우 동기식 예측 API가 적합합니다 입력을 일괄적으로 사용할 수 있는 경우 배치 예측 API가 적합하죠

비동기식 콘텍스트에서 많은 양의 입력을 시간이 지나면서 개별적으로 사용할 수 있는 경우 비동기식 API가 가장 유용할 수 있습니다 정리하자면 Core ML 워크플로를 진행하면서 모델 개발과 모델 통합 과정에서 최적화할 수 있는 많은 기회가 있으며 새로운 컴퓨팅 가용성 API는 사용 가능한 하드웨어에 따라 런타임에 의사 결정을 내리는 데 도움이 될 수 있습니다 모델 수명 주기 및 캐싱 동작을 이해하면 모델을 로드하고 언로드할 시기와 위치를 잘 결정하는 데 도움이 될 수 있습니다 마지막으로 비동기 예측 API를 사용하면 Core ML을 다른 비동기 Swift 코드와 통합하고 동시 예측을 지원하여 처리량을 개선할 수 있습니다 지금까지 Core ML 팀의 벤이었습니다, 전 AI가 아닙니다