Apple Core AI 프레임워크

 (developer.apple.com)
1P by GN⁺ | ★ favorite | 댓글 1개
  • Core AI는 Apple silicon에서 AI 모델을 앱 안에서 실행·최적화·배포하기 위한 새 프레임워크
  • CPU, GPU, Neural Engine을 활용하고 Swift API로 .aimodel 추론을 앱에 통합 가능
  • PyTorch 모델을 Core AI 모델로 변환하고, 압축·디버깅·사전 컴파일까지 도구 체인으로 제공
  • 큰 모델은 실행 전 specialization이 필요해 다운로드, 캐시, 첫 실행 흐름 설계가 중요
  • SAM 3, Qwen, Transformer 예제로 온디바이스 비전·언어·상태 캐싱 최적화 흐름 도 소개

Core AI의 역할

  • Core AI는 Apple 플랫폼 전반에서 온디바이스 AI 실행을 위한 새 기술 묶음
    • iOS 27.0+ Beta, iPadOS 27.0+ Beta, macOS 27.0+ Beta, tvOS 27.0+ Beta, visionOS 27.0+ Beta, watchOS 27.0+ Beta 지원
    • 앱 안에서 고성능 AI 추론을 실행하고, 사용자 데이터를 기기 밖으로 보내지 않는 구조 제공
  • Core AI는 단순 실행 API가 아니라 모델 준비부터 앱 통합까지 포함
    • 모델 최적화, PyTorch 변환, .aimodel 생성, 디버깅, Xcode 프로파일링, 사전 컴파일 제공
    • 신경망 외 decision tree나 tabular feature engineering 모델은 Core ML 사용 대상

개발 흐름: PyTorch에서 Swift 앱까지

  • Core AI는 기존 PyTorch 워크플로를 Apple silicon 배포 흐름으로 연결
    • torch.export로 PyTorch 모델을 exported program으로 변환
    • Core AI PyTorch Extensions의 TorchConverter로 .aimodel 생성
    • Core AI Optimization으로 Apple silicon에 맞춘 압축과 최적화 적용
  • Swift 앱에서는 새 Core AI Framework API로 모델 로드와 추론 실행
    • AIModel은 .aimodel 파일을 로드하고 추론 함수를 검사
    • InferenceFunction은 실행 가능한 단일 계산 그래프
    • NDArray는 다차원 입력·출력 데이터를 담는 타입
    • run 호출로 NDArray 입력을 넣고 추론 결과를 받는 구조
  • Xcode에서 .aimodel 파일을 직접 확인 가능
    • 모델 크기, 연산 분포, 메타데이터, 함수 시그니처 확인
    • 동적 shape 차원은 ?로 표시

성능 최적화: state, cache, memory layout

  • Transformer 모델처럼 입력 시퀀스가 길어지는 구조에서는 추론 시간이 점점 늘어날 수 있음
    • Snake 예제에서 두 Snake를 모두 AI 모델로 실행하자 시간이 지날수록 게임이 느려짐
    • Core AI Instruments에서 추론 구간이 점점 길어지는 현상 확인
  • Core AI는 state를 사용해 key/value cache 같은 구조를 구현 가능
    • 상태는 모델 입력이면서 추론 중 읽히고 제자리에서 업데이트됨
    • 이전 단계의 key/value를 다시 계산하지 않고 캐시에 저장
    • 전체 게임 이력을 매번 입력으로 넣지 않아도 되는 구조
  • Swift 쪽에서는 InferenceFunction.run의 states 인자로 mutable view 컬렉션 전달
    • 업데이트된 모델은 시간이 지나도 일정한 속도를 유지
    • Instruments에서도 추론 지연 시간 증가가 훨씬 느려짐
  • Core AI는 추론 루프 오버헤드를 줄이는 메모리 제어 기능도 제공
    • NDArray의 최적 메모리 레이아웃을 확인하고 해당 구조로 할당 가능
    • 출력 값을 미리 할당해 추론 중 새 출력 할당 방지 가능
    • 비동기 값을 사용해 여러 추론 함수를 파이프라인화 가능

모델 배포: 다운로드, specialization, 사전 컴파일

  • Core AI 모델은 모든 Apple 기기에서 실행될 수 있는 소스 표현이며, 실제 실행 전 기기별 specialization 필요
    • 모델 로드 시 이미 캐시에 specialization된 결과가 있는지 확인
    • 없으면 해당 기기와 OS 버전에 맞는 실행 artifact 생성
  • 큰 모델은 specialization에 시간이 걸릴 수 있어 사용자 상호작용 중간에 넣지 않는 것이 중요
    • SAM 3 예제에서는 첫 실행 시 model load와 큰 specialization 이벤트로 spinner가 오래 표시됨
    • 기능 소개 화면에서 사용자가 시도할 때만 Background Assets로 모델을 다운로드하는 흐름 제시
  • coreai-build 명령으로 개발 머신에서 일부 컴파일을 미리 수행 가능
    • 특정 기기 아키텍처를 대상으로 compiled model 생성
    • 사용자 기기에서도 specialization은 필요하지만 남은 작업이 줄어 준비 시간이 짧아짐
  • AIModelCache로 모델 캐시를 프로그래밍 방식으로 제어 가능
    • 필요 없는 항목 삭제
    • 항목 유지 정책 제어
    • 같은 app group의 여러 앱 간 캐시 공유

모델 최적화와 디버깅

  • Core AI Optimization은 모델 압축과 양자화 기능 제공
    • INT4, INT8, FP4, FP8 가중치 압축 지원
    • calibration 데이터 또는 quantization aware training을 사용하는 양자화 API 제공
  • SAM 3 예제에서는 32비트 baseline asset이 3GB 이상이었고, 4비트 압축 후 약 430MB가 됨
    • 모든 계층에 공격적으로 압축을 적용하자 가려진 꽃 하나가 검출되지 않음
    • 출력만으로는 어떤 계층이 문제인지 찾기 어려움
  • Core AI Debugger는 변환된 모델과 원래 PyTorch 모델의 내부 값을 비교
    • 모델 구조를 그래프로 시각화
    • 중간 텐서 값을 확인
    • Python 소스 코드의 특정 줄까지 추적
    • PSNR 기준으로 차이가 큰 연산을 표시
  • SAM 3 비교에서는 낮은 PSNR sync point 대부분이 detector decoder에서 발생
    • detector block은 전체 파라미터의 4%에 불과해 압축 이득이 작음
    • detector를 양자화 대상에서 제외하자 모든 꽃이 다시 검출되고 baseline 품질 회복

Core AI Models와 고수준 API

  • Core AI Models 저장소는 앱에 맞게 변환하고 최적화할 수 있는 인기 모델과 export recipe 제공
    • SAM 3와 Qwen 계열 모델을 찾고 Core AI 모델로 변환 가능
    • Swift 패키지는 모델별 전처리·후처리를 추상화
  • SAM 3 같은 segmentation 모델은 CoreAIImageSegmenter로 사용할 수 있음
    • 텍스트 프롬프트로 객체를 분할
    • raw tensor shape를 직접 다루지 않고 Swift API로 mask 추출 가능
  • Qwen 같은 언어 모델은 CoreAILanguageModel로 로드 가능
    • asset loading, engine creation, tokenizer setup 추상화
    • FoundationModels의 LanguageModelSession과 연결해 사용 가능
    • 스트리밍 응답과 @Generable 기반 구조화 출력 사용 가능

개발자가 주목할 지점

  • Core AI는 “모델을 앱에서 실행하는 API”보다 넓은 범위의 온디바이스 AI 배포 체계
    • PyTorch 모델을 Apple silicon용 .aimodel로 바꾸는 흐름
    • Swift 앱에서 모델을 안전하고 효율적으로 실행하는 API
    • Xcode, Instruments, Debugger를 통한 성능·정확도 진단
  • 앱 설계에서는 모델 자체보다 준비 과정이 사용자 경험에 큰 영향을 줌
    • 모델을 앱에 번들할지, Background Assets로 받을지 결정 필요
    • 첫 실행에서 다운로드와 specialization을 어떻게 보여줄지 설계 필요
    • 캐시 정책과 사전 컴파일 전략이 큰 모델 사용성에 직접 연결
  • Core AI는 Apple 플랫폼에서 비전 모델, 언어 모델, Transformer 기반 모델을 온디바이스로 다루는 개발 흐름을 제시
    • SAM 3 예제로 segmentation 모델의 압축·분리·디버깅 흐름 제시
    • Qwen 예제로 커스텀 언어 모델과 Foundation Models API 연결 제시
    • Snake Transformer 예제로 state 기반 key/value cache 최적화 제시

참고 링크

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 곧 나올 온디바이스 Foundation Models 업데이트가 더 기대됨: https://developer.apple.com/documentation/updates/foundation...
    아직 정보는 많지 않음
    다만 https://github.com/Arthur-Ficial/apfel을 관리하고 있어서 편향이 있을 수 있음

    • fm 도구가 추가된 걸 봤는지 궁금함. Platforms State of the Union에서 언급됐음
      실행하면 이런 결과가 나옴: https://gist.github.com/robgough/7893602895e7580117475076198...
    • 동의함. OS API의 핵심 일부로 시스템 전반, 플랫폼 전반에서 쓸 수 있는 온디바이스 모델이 들어간다는 발상이 매우 매력적임
      보통은 소프트웨어가 조각조각 나뉘어 있는 쪽을 좋아하지만, Apple의 경우 기본 제공 기능 중 마음에 드는 게 많음
      소프트웨어가 “이 플랫폼에는 이 모델이 있다”는 걸 알고 여러 작은, 그리고 점점 더 큰 생성형 AI 작업에 활용할 수 있게 되는 점이 특히 끌림
    • Apfel이 유용해 보임. 거의 1년 동안 Apple Foundation Models를 실험해 봤고, 임베디드 애플리케이션에 쓸 만함
      로컬 에이전트형 코딩 도구도 더 깊이 파고드는 중이며, little-coder --model ollama/gemma4:12b-it-qat부터 시작했음
      설정 시간을 몇 분 아낄 수 있는 작은 무료 책도 만들었음: https://leanpub.com/read/local-coding-agents
      하이퍼스케일러 중심 AI 성장의 과장, 특히 데이터센터의 환경 비용과 사회적 비용에 꽤 화가 나 있어서, 로컬·프라이빗 AI를 촉진하는 시도는 전부 지지함
    • Core AI에 OpenAPI 호환 엔드포인트를, 적어도 테스트 도구로라도 넣는 아이디어를 Apple이 채택하지 않은 듯해서 의외임
      MCP 지원을 제공하는 지금, 컨테이너화/seatbelt 전략도 더 듣고 싶음
      Apple의 컨테이너 시스템 안에서 Darwin이 어떻게 쓰이는지에 대한 소식은 아직 못 봤음
      Apfel은 멋진 프로젝트이고, Tahoe로 업그레이드하고 싶게 만든 유일한 이유였음

  • WWDC 2026 Core AI 영상들
    Meet Core AI - https://developer.apple.com/videos/play/wwdc2026/324/
    Dive into Core AI model authoring and optimization - https://developer.apple.com/videos/play/wwdc2026/325/
    Integrate on-device AI models into your app using Core AI - https://developer.apple.com/videos/play/wwdc2026/326/

  • 이건 PyTorch 모델을 CPU, GPU, Apple Neural Engine(ANE) 전체에서 실행되는 형식으로 변환하는 새로운 방식처럼 보임 [0]
    기존 API인 Core ML을 완전히 대체하는 건지 궁금함 [1]
    [0]: https://apple.github.io/coreai-optimization/
    [1]: https://developer.apple.com/documentation/coreml/

    • 맞음. Core AI 문서에 따르면 앱이 신경망 외의 모델 유형, 예컨대 결정 트리나 표 형식 특성 공학을 쓴다면 Core ML을 보라고 되어 있음
    • 꽤 흥미롭긴 하지만, 예를 들어 Metal에 최적화한 모델을 llama.cpp 같은 데 로드해서 쓰는 기존 방식과 비교해 성능이 어떻게 나올지 궁금함
      unsloth는 이런 작업을 “배터리 포함” 형태로 해주는 좋은 예임
    • Core ML을 대체하려는 것 같지만, 지금은 Core AI, Core ML, MLX와 coremltools의 관계가 더 헷갈림
      각각의 장단점과 기능 동등성이 어디까지인지 Apple이 더 잘 설명해야 함
    • OS 27 이상이 필요하므로, 하위 호환성 때문에 Core ML은 여전히 유용함

  • 다운로드 200만 미만 앱에는 서버급 모델 접근을 무료로 제공하고, 같은 프라이버시 보장을 준다고 함
    시간이 지나면 모든 앱으로 확대되면 좋겠음. 하드웨어/비용 제약이 있겠지만, 더 큰 개발사는 비용을 낼 수 있을 것 같음
    https://developer.apple.com/private-cloud-compute/

    • Apple Intelligence Extensions 언급을 보면, 당분간 크게 확대하지는 않고 대신 사용자가 계정을 가진 다른 제공업체와 개발자가 통합할 수 있게 해줄 것 같음

  • AI의 미래는 분명 로컬이고, 최근에는 “무한 토큰”이라고 설명하고 있음
    M1 MacBook Pro도 그걸 할 수 있고 RTX 3090도 가능함
    매달 수백 달러를 낼 필요가 없고, 다른 사람들도 마찬가지임

    • 1980년대에는 컴퓨팅의 미래가 분명 로컬이라고 봤음. 가정용 컴퓨터, PC, Mac, 사무실 서버(Novell, 이후 디스크 공유가 있는 Windows NT) 같은 것들이었음
      40년이 지나자 우리는 현대판 스마트 단말기에 가까운 중앙집중형 인프라로 돌아왔음
      AI의 미래도 결국 그렇게 흘러갈 것임. 아마 로컬과 중앙집중 사이를 오갈 가능성이 큼
      다만 사람들이 로컬에서 실행하는 물건을 팔아 돈을 벌 수 있다면, 중앙집중화가 더 큰 권력과 더 큰 돈을 만들어내는 것처럼 보임
    • 초당 10토큰으로 제한된 “무한 토큰”이면 한 달에 2,600만 토큰임
    • 진짜 돈은 모델 주변의 코드를 짜서 특화 작업에 효율적으로 만드는 데 있음
      일반 사용자는 범용 모델을 원하므로 AI 채팅 앱은 계속 남을 것임
      대부분의 프로그램은 로컬에서 돌릴 수 있는 특화 AI로 이득을 볼 수 있고, 프로그램 수는 사용자 수보다 훨씬 많음

  • Apple은 활성값 쪽도 작업 중인 듯함. 아는 바로는 w4a8, w4a16임
    만약 제대로 해낸다면, 그리고 그게 큰 가정이긴 하지만, Apple의 시장 도달 범위를 고려할 때 1,000억 미만 매개변수 모델이 학습되고 제공되는 방식을 상당 부분 좌우할 수 있음
    주요 사용처가 온디바이스가 될 것이고, 대부분은 iOS보다 macOS일 가능성이 큼

  • 아직 어디에서도 크게 부각된 걸 못 봤지만, Mac 간 분산 추론이 흥미로움. Thunderbolt 5 위의 JACCL, OpenAI 호환 mlx_lm.server, Mac 위의 에이전트형 실행이 포함됨
    Apple은 MLX(직접 가중치 가져오기)를 Foundation Models / Core AI와 분리해 두고 있음

  • AI 회사들이 상장을 서두르는 이유가 이거임
    내년 말쯤이면 대부분의 AI를 기기에서 직접 실행하게 될 것임
    그들에게는 해자가 없고, 확장의 한계에 닿았으며, 마법처럼 보이는 대부분은 더 작은 모델로 증류될 수 있고, 그들도 그걸 알고 있음

    • Qwen의 300억급 모델은 초당 30~90토큰으로 돌릴 만큼 메모리 대역폭이 있는 머신만 있으면 실제로 충분히 쓸 만함
      Qwen이 1,200억급 모델 출시를 멈춘 건 매우 의미심장함
      앞으로 10년 안, 어쩌면 3년 안에 누군가 로컬에서 돌릴 수 있는 Opus 4.5급 2,560억 모델을 내놓을 것임
      지금 우리 엔지니어들은 Opus 토큰에 월 800달러 정도를 쓰고 있고, 그 비율이면 로컬 LLM의 투자 회수 기간은 약 10개월임
    • 정말 확장의 한계에 도달했는지는 모르겠음
      안타깝게도 더 큰 모델일수록 여전히 더 좋은 모델처럼 보임
    • 코딩 영역에서는 350억, 700억, 1,500억 모델을 선불 수백~수천 달러에 팔고, 1년 동안 매월 또는 격월로 새 코딩 문서와 저장소를 학습한 업데이트를 제공하는 식이 나올 것 같음
    • 만세, 그들의 목 조르기식 지배가 풀렸음. 혁명 만세!
    • 기기에서 돌아가는 아주 작은 모델 하나만 원함. 예를 들어 자동완성에서 “I'll be right Brian”이 아니라 “I'll be right back”을 쓰고 싶다는 걸 아는 정도면 됨
      지금 내 최우선 AI 요청은 그거임. 제발, Apple

  • Linux에도 이런 게 있는지 궁금함
    예를 들어 애플리케이션 개발자라면 커널이 특정 버전 이상일 때 GNU Core AI 같은 것이 있다고 가정할 수 있을까?

    • Apple이 아닌 플랫폼에서는 보통 지원해야 하는 실리콘 업체 수에 2개 이상을 더한 만큼의 AI 프레임워크를 신경 써야 함
      Apple도 이제 Core ML, MLX, Core AI 사이에서 그런 상태가 된 것 같음
      프레임워크 파편화 문제가 곧 사라질 조짐은 못 봤음
      NVIDIA는 모두가 학습과 추론을 CUDA로 하길 원하고, NPU가 유용하다는 사실은 부정하려 함
      NPU를 만드는 업체마다 자기 아키텍처와, LLM 이전에 설계된 하드웨어에서 물려받은 한계에 맞춘 별도 프레임워크가 있음. 대부분은 GPU를 겨냥한 또 다른 프레임워크도 가지고 있음
      운영체제 업체도 하드웨어별 프레임워크 대신 쓰길 바라는 프레임워크를 하나나 둘쯤 갖고 있음
    • 실용적으로는 llama.cpp가 이 역할을 함. 링크해서 쓰거나 네트워크 API를 쓰면 됨
    • 없음. 다만 Red Hat과 IBM은 자기 배포판용으로 그런 걸 하고 있음
    • onnxruntime, llama.cpp, 더 구체적으로는 ggml이 있고, iree.dev도 시도 중임

  • 이게 ANE에서 원하는 걸 뭐든 실행할 수 있다는 뜻인지 궁금함
    마지막으로 시도했을 때는 Face ID 같은 Apple 1차 기능에서만 쓸 수 있는 것처럼 보였음

    • 모델을 Core ML로 변환하면 이미 그렇게 할 수 있었음
      ANE를 전혀 쓸 수 없던 건 MLX였음
    • Core ML로 몇 년째 그렇게 하고 있음
답변달기