Apple Silicon 위의 MLX: Apple의 모델이 아니라 내 모델이 필요할 때

Apple의 Foundation Models 프레임워크가 건네주는 모델은 하나뿐입니다. 시스템의 모델이고, 봉인되어 있으며, 무료이고, Apple의 일정에 따라 갱신됩니다. 대부분의 온디바이스 언어 작업에는 이것이 정답이고, 여기서 더 손을 뻗는 것은 오히려 실수입니다. 하지만 어떤 작업은 내가 직접 고른 모델을 요구합니다. 특정 오픈 웨이트 LLM, 버전을 고정해 둔 모델, 내 데이터로 학습시킨 파인튜닝 모델, 또는 시스템 모델에 아예 없는 능력이 그렇습니다. 내 모델을 기기 위에서 직접 돌려야 할 때, Foundation Models 아래 계층에 있는 것이 MLX입니다¹.

MLX는 Apple Silicon에서 머신러닝을 수행하기 위한 Apple의 배열 프레임워크이며, 앱에 그대로 내장할 수 있는 Swift API(MLX Swift)를 함께 제공합니다². 호출해서 쓰는 시스템 프레임워크가 아니라, 모델 가중치와 함께 직접 배포하는 라이브러리입니다. 바로 이 차이가 맞바꿈의 전부이고, 이 차이를 이해해야 한 계층 아래로 내려갈지 Apple이 정해 준 자리에 머무를지 판단할 수 있습니다.

요약

• MLX는 Apple Silicon을 위해 만들어진 NumPy 스타일 배열 프레임워크로, 지연 평가, 조합 가능한 함수 변환, Metal 백엔드를 갖추고 있습니다².
• 통합 메모리 모델이야말로 이것이 휴대폰에서 동작하는 이유입니다. 배열은 CPU와 GPU가 공유하는 하나의 메모리 풀에 존재하므로, MLX는 동일한 버퍼 위에서 양쪽을 오가며 실행되고 호스트-디바이스 간 복사 비용이 발생하지 않습니다³.
• LLMModelFactory로 오픈 웨이트 LLM을 기기에서 실행할 수 있습니다. mlx-community/Llama-3.2-3B-Instruct-4bit 같은 양자화 모델을 지정한 다음 ChatSession을 통해 생성하면 됩니다⁴.
• 파인튜닝은 LoRA 어댑터로 합니다. 작은 어댑터를 학습시켜 adapters.safetensors를 배포하면, load(into:)가 실행 시점에 기본 모델의 Linear 레이어를 LoRALinear로 교체합니다⁵.
• 내 모델을 쓰는 대가는 앱 크기(가중치는 큽니다), 메모리 압박, 시스템 통합의 부재, 그리고 모든 업데이트를 직접 책임져야 한다는 점입니다. Foundation Models에는 이런 비용이 전혀 없습니다. Apple이 대신 치르기 때문입니다.

MLX란 무엇이고, Apple Silicon이 어떻게 이를 가능하게 하는가

MLX는 NumPy처럼 보이는 배열과 연산에 더해, 머신러닝에 필요한 변환들을 제공합니다. 자동 미분, 벡터화, 그리고 계산 그래프를 구성해 두었다가 결과를 읽을 때에만 실제로 실행하는 지연 평가입니다². 프로젝트 자체도 연구 프레임워크다운 속도로 움직입니다. MLX는 2026년 7월에 0.32.0에, MLX Swift는 같은 주에 0.31.6에 도달했고, 대략 몇 주에 한 번꼴로 릴리스가 나옵니다⁷. 버전은 고정해 두고, API 표면이 계속 넓어질 것을 염두에 두세요. 여기까지만 놓고 보면 비슷한 프레임워크는 열 개도 넘게 있습니다. MLX가 수십억 파라미터짜리 모델을 주머니 속 기기에서 돌아가게 만드는 이유는 메모리 모델입니다.

데스크톱 GPU에서는 데이터가 시스템 RAM에 있고, 계산을 하려면 버스를 건너 GPU의 별도 메모리로 복사한 뒤 결과를 다시 복사해 와야 합니다. 그 복사가 곧 세금이고, 큰 모델에서는 그 세금이 가혹합니다. Apple Silicon은 통합 메모리를 씁니다. CPU, GPU, Neural Engine이 모두 직접 주소를 지정하는 하나의 풀입니다. MLX는 바로 이 사실을 중심으로 설계되었습니다³. 배열은 “CPU에 있다”거나 “GPU에 있다”가 아니라 그냥 메모리에 있으며, 어떤 프로세서든 그 자리에서 연산합니다. 복사도 없고, 버스를 건너며 내는 세금도 없습니다. 4비트로 양자화한 30억 파라미터 모델은 몇 기가바이트 안에 들어가고, 왕복 전송 없이 실행됩니다. 메모리가 비슷한 외장 GPU 기기였다면 바로 그 왕복 전송이 같은 작업을 비현실적으로 만들었을 것입니다. 수년 전 Apple이 내린 하드웨어 결정이야말로 실제 모델의 온디바이스 추론이 성립하는 이유이고, 타일 기반 통합 메모리 아키텍처가 MLX가 딛고 선 토대입니다.

기기에서 LLM 실행하기

“특정 모델을 쓰고 싶다”에서 화면에 텍스트가 뜨기까지의 경로는 짧습니다. MLX Swift의 LLM 계층이 Hugging Face Hub에서 양자화 모델을 불러와 실행합니다⁴.

let container = try await LLMModelFactory.shared.loadContainer(
    from: HubClient.default,
    using: TokenizersLoader(),
    configuration: .init(id: "mlx-community/Llama-3.2-3B-Instruct-4bit")
)

let session = ChatSession(container)
let response = try await session.respond(to: "Summarize this in one line: \(text)")

토큰 단위로 UI를 갱신하려면 스트림을 생성해 도착하는 조각을 그때그때 렌더링하면 됩니다⁴.

let input = try await container.prepare(input: UserInput(prompt: prompt))
let stream = try await container.generate(input: input, parameters: GenerateParameters())
for await event in stream {
    if case let .chunk(text) = event { /* append to UI */ }
}

실무에서 중요한 부분은 대부분 두 가지 세부 사항에 달려 있습니다. 첫째, 모델 ID의 4bit는 곁들이는 장식이 아닙니다. 양자화가 있어야 모델이 메모리에 들어가고 기기에서 쓸 만한 속도로 돕니다. 전체 정밀도가 아니라 4비트(혹은 그 이하) 가중치를 배포하게 됩니다. 둘째, 양자화해도 가중치는 여전히 크기 때문에, 앱에 함께 묶을지(즉시 사용 가능하지만 다운로드가 무거워집니다) 첫 실행 때 내려받을지(바이너리는 가볍지만 대기 시간과 실패 처리 경로가 생깁니다)를 의식적으로 결정해야 합니다. Foundation Models는 모델이 이미 기기에 있으므로 이런 질문 자체를 던지지 않습니다. MLX에서는 가중치가 내 몫의 문제입니다.

파인튜닝: 새 모델이 아니라 LoRA 어댑터

내 모델을 가져오는 이유가 기본 모델 그 자체인 경우는 드뭅니다. 대개는 내 도메인을 가르치기 위해서입니다. 수십억 파라미터 모델을 기기에서 전체 파인튜닝하는 것은 선택지가 아닙니다. LoRA(저순위 적응)가 답입니다. 기본 모델의 동작을 조정하는 작은 어댑터 가중치 묶음만 학습시키고, 기본 모델 자체는 손대지 않습니다. 어댑터는 기가바이트가 아니라 메가바이트 단위입니다⁵.

MLX Swift는 adapter_config.json과 adapters.safetensors가 들어 있는 디렉터리에서 학습된 어댑터를 불러온 뒤, 이미 컨테이너에 적재된 모델에 적용합니다⁵.

let adapter = try LoRAContainer.from(directory: adapterURL)
await container.update { context in
    try? adapter.load(into: context.model)   // swaps Linear layers for LoRALinear
}

load(into:)는 모델의 표준 Linear 레이어를 어댑터의 저순위 델타를 접어 넣은 LoRALinear 레이어로 교체하므로, 이후 추론에는 내 파인튜닝이 반영됩니다. 모델이 컨테이너 안에 들어 있기 때문에 어댑터는 container.update를 통해 적용하며, 실행 중에 어댑터를 갈아 끼울 수도 있습니다(하나를 unload(from:)하고 다른 하나를 load(into:)). 이렇게 하면 하나의 기본 모델로 기능마다 다른 동작을 낼 수 있습니다. 이 방식은 Apple이 시스템 모델을 위해 제공하는 Foundation Models 커스텀 어댑터와 같은 꼴입니다. 다만 여기서는 볼 수도 없는 모델을 적응시키는 대신, 기본 모델과 학습 파이프라인, 그리고 그 결과까지 내가 소유한다는 점이 다릅니다.

선택: Foundation Models, MLX, 아니면 클라우드

계층은 셋이고, 잘못 고르면 능력을 잃거나 피할 수 있었던 일거리를 잔뜩 떠안게 됩니다.

• Foundation Models — 시스템 모델이 해낼 수 있는 작업이라면 여기입니다. 무료이고, 프라이버시가 지켜지고, 배포할 가중치가 없고, 직접 관리할 메모리도 없으며, 시스템 통합이 공짜로 딸려 옵니다. 기본값은 여기입니다. Apple이 이를 위해 만든 온디바이스 언어 작업(요약, 분류, 추출, 재작성, 구조화된 출력)은 두말할 것 없이 여기에 속합니다.
• MLX — 시스템이 주지 않는 모델이 필요할 때입니다. 특정 오픈 웨이트 LLM, OS 업데이트로 바뀌지 않도록 버전을 고정한 모델, 도메인 파인튜닝, 또는 Foundation Models의 범위 밖에 있는 아키텍처(비전-언어 모델이나 텍스트가 아닌 모델)가 그렇습니다. 앱 크기와 메모리, 그리고 소유의 부담을 지불하는 대신 통제권을 얻습니다.
• 클라우드 — 모델이 정말로 커야만 할 때입니다. 최전선 수준의 추론, 긴 문맥 분석, 수십억 파라미터급 온디바이스 모델로는 불가능한, 가장 큰 모델만이 해내는 일들입니다. 온디바이스는 최전선 모델의 대체재가 아니라 곡선 위의 다른 지점입니다.

솔직하게 읽자면 이렇습니다. MLX는 더 나은 기본값이 아니라, 특정한 이유가 있을 때 의도적으로 한 단계 내려가는 선택입니다. 내 기능에 대해 Foundation Models가 무엇을 못 하는지 이름 붙여 말할 수 없다면 MLX는 필요 없습니다. 그런데도 배포한다면, 굳이 짊어지지 않아도 될 기가바이트 단위의 가중치와 메모리 예산을 떠안는 셈입니다.

iOS 27은 이 지도에 네 번째 계층을 더합니다. Core AI는 내가 제공한 모델을 실행하기 위한 Apple의 시스템 프레임워크로, 특수화와 캐싱, 연산 유닛 스케줄링을 명시적으로 제어할 수 있습니다. “내 모델을 기기에서” 계층에서 MLX와 겹치지만 방향은 정반대입니다. Core AI는 미리 준비된 .aimodel을 시스템이 관리하며 실행해 주는 표면이고, MLX는 학습 루프와 양자화, 반복 실험까지 내가 안에 담아 내장하는 라이브러리입니다. 변환된 모델을 시스템 관리 아래 빠르게 돌리는 것이 목적이라면 Core AI가 그 자리를 놓고 경쟁하고, 실험하거나 파인튜닝하거나 파이프라인 전체를 소유하는 것이 목적이라면 여전히 MLX가 답입니다.⁶

MLX에 손을 뻗지 말아야 할 때

• 시스템 모델이 이미 해내는 경우. Foundation Models가 다루는 작업 목록을 다시 읽어 보세요. 내 작업이 그 목록에 있다면 거기서 멈추면 됩니다.
• 가중치를 감당할 수 없는 경우. 양자화한 소형 모델도 여전히 큰 자산입니다. 앱 크기나 첫 실행 다운로드가 사용자에게 실질적인 제약이라면, 그 제약 하나만으로 결론이 날 수 있습니다.
• 고정된 모델에 Neural Engine의 최저 전력 경로가 필요한 경우. 바뀌지 않는, 이미 확정된 모델이라면 Core ML과 그 변환기가 가장 촘촘한 전력·지연 특성으로 Neural Engine을 겨냥합니다. iOS 27에서는 Core AI가 명시적인 특수화 제어를 갖춘, 새로운 신경망 작업에 대한 Apple의 공식 방향입니다. MLX는 유연성과 연구 수준의 반복에서 빛나고, 시스템 프레임워크는 잠가 둔 프로덕션 모델에서 빛납니다. 서로 다른 도구이며, “온디바이스 ML”은 하나의 결정이 아닙니다.
• 유지보수할 생각이 없는 경우. 내 모델을 쓴다는 것은 그 모델의 업데이트와 보안, 그리고 성능 표류까지 내가 책임진다는 뜻입니다. 시스템 모델은 Apple이 대신 갱신해 줍니다. 모델을 떠안을 인력이 없다면 모델을 들이지 마세요.

MLX가 보상하는 기술은 언제 쓸지에 대한 절제입니다. 이 프레임워크는 정말로 놀랍습니다. 실제 언어 모델을, 내 도메인에 맞게 파인튜닝해서, 서버도 없고 토큰당 비용도 없이 오롯이 기기 위에서, 그것도 바로 이런 용도를 위해 설계된 메모리 아키텍처를 가진 하드웨어에서 돌립니다. 이유를 이름 붙여 말할 수 있다면 손을 뻗을 가치가 충분한 능력입니다. 이유 없이 손을 뻗는다면, Apple이 무료로 유지보수하고 통합해 주는 모델을 더 무겁고 아무도 돌보지 않는, 이제 내 것이 된 복제본과 맞바꾼 것입니다. 판단이 곧 일의 전부입니다.

FAQ

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

MLX는 Apple Silicon에서 머신러닝을 수행하기 위한 배열 프레임워크로, NumPy 스타일 API, 조합 가능한 함수 변환(자동 미분, 벡터화), 지연 계산, Metal 백엔드를 제공합니다². MLX Swift는 이를 앱에 내장하기 위한 Swift API이며, 이를 통해 내 모델을 기기에서 실행하고 파인튜닝할 수 있습니다.

MLX는 Apple Silicon의 통합 메모리를 어떻게 활용하나요?

MLX 배열은 공유 메모리에 존재하므로, 분리된 메모리 풀 사이에서 데이터를 복사하지 않고도 CPU나 GPU에서 연산이 실행됩니다³. 전송이 전혀 없다는 이 성질이야말로 Apple Silicon의 통합 메모리 아키텍처를 온디바이스 모델 실행에 효율적으로 만들어 주는 핵심입니다.

MLX로 오픈 웨이트 LLM을 기기에서 실행할 수 있나요?

가능합니다. LLMModelFactory.shared.loadContainer(from:using:configuration:)가 Hugging Face Hub에서 mlx-community/Llama-3.2-3B-Instruct-4bit 같은 양자화 모델을 불러옵니다. 단발성 호출에는 ChatSession의 respond(to:)를 쓰고, 점진적 출력에는 container.generate(input:parameters:)가 흘려보내는 .chunk(text) 이벤트를 받으면 됩니다⁴.

MLX로 모델을 파인튜닝하려면 어떻게 하나요?

새 모델이 아니라 LoRA 어댑터로 합니다. LoRAContainer.from(directory:)가 adapter_config.json과 adapters.safetensors를 담은 디렉터리에서 어댑터를 불러오고, container.update를 통해 적용하면 모델의 Linear 레이어가 LoRALinear 레이어로 교체되며, 실행 중에 어댑터를 갈아 끼울 수도 있습니다⁵.

MLX와 Foundation Models, Core ML 중 무엇을 써야 하나요?

Apple의 시스템 모델이 그 작업을 해낼 수 있다면 기본값은 Foundation Models입니다(무료, 프라이버시 보장, 배포할 가중치 없음)¹. MLX는 시스템이 주지 않는 모델이 필요할 때에만 꺼내 드세요. 특정 오픈 웨이트 LLM, 고정된 버전, 도메인 파인튜닝, 또는 Foundation Models의 범위 밖에 있는 아키텍처가 그런 경우입니다. Neural Engine의 최저 전력 경로가 필요한, 잠가 둔 프로덕션 모델에는 Core ML을, iOS 27에서 내 모델을 명시적인 특수화·스케줄링 제어와 함께 시스템 관리 아래 실행하고 싶다면 Core AI를, 모델이 정말로 최전선 규모여야 한다면 클라우드를 쓰면 됩니다.

MLX에 손을 뻗지 말아야 할 때는 언제인가요?

시스템 모델이 이미 그 일을 해낼 때, 기가바이트 단위 가중치를 배포할 여력이 없을 때, 고정된 모델이라 Core ML의 최저 전력 Neural Engine 경로가 더 잘 맞을 때, 또는 모델의 업데이트와 보안, 성능 표류를 감당할 인력이 없을 때입니다. MLX는 더 나은 기본값이 아니라, 이름 붙일 수 있는 이유가 있을 때 의도적으로 한 단계 내려가는 선택입니다.