Cluster로 여러 Mac을 묶어 큰 모델 돌리기

무엇을 하는 기능인가

문서에 Enterprise 표시가 붙은 기능입니다. 참여하는 모든 node에 명시적으로 부여된 Enterprise Cluster 자격(entitlement)이 필요합니다.

Cluster는 Apple Silicon Mac 여러 대를 분산 MLX 추론 시스템 하나로 묶어, 그 메모리와 연산 능력을 하나의 작업에 함께 씁니다. Mac 한 대로는 감당하지 못하는 모델을 돌리는 것이 목적입니다.

문서가 꼽는 쓰임새는 더 큰 로컬 모델, 부담이 큰 비공개 작업, 그리고 민감한 업무를 온라인 제공업체로 옮기지 않고 로컬 추론 용량을 늘려야 하는 팀입니다.

Smart Balancer와 무엇이 다른가

둘은 서로 다른 확장 문제를 풉니다.

기능	푸는 문제
Smart Balancer	각자 모델을 혼자 돌릴 수 있는 대상들에 “서로 다른 요청”을 나눠 보내 처리량을 늘립니다
Cluster	어느 한 대도 혼자 감당하면 안 되는 “모델 하나의 실행”을 여러 Mac에 나눕니다

실행 중인 cluster는 나중에 Smart Balancer 뒤의 대상 하나가 될 수 있습니다. cluster가 분산 실행을 맡고, balancer가 요청을 어디로 보낼지 정합니다.

Cluster가 주는 것

• 한 대의 메모리나 연산으로 부족한 MLX 모델을 위한 합쳐진 로컬 용량
• 분산 모델을 쓰는 앱을 위한 Nexus 게이트웨이 대상 하나
• 모델 준비나 실행 전에 하는 구성 계획과 사전 점검(preflight)
• 같은 파일을 기기마다 따로 내려받지 않게 해 주는, 동료 기기 간 모델 준비
• 구성원, rank, 메모리, 연결망(fabric) 활동, 요청, 생성 속도에 대한 실시간 화면

기기를 건드리기 전에 Plan부터

Plan 탭에서 모델이 Mac 한 대로 되는지, cluster가 필요한지를 가늠합니다. 모델과 후보 기기의 메모리를 넣으면 다음을 추정해 줍니다.

• 모델이 차지하는 크기
• 합쳐서 쓸 수 있는 메모리
• node별 예상 모델 몫
• 필요한 최소 기기 수
• 권장 분산 방식

합쳐서 쓸 수 있는 메모리는 각 Mac의 표기 메모리를 단순히 더한 값이 아닙니다. Nexus는 macOS, Runtime, 모델 실행, 컨텍스트, 안전한 운영을 위한 여유를 떼어 둡니다.

Plan은 “들어가는지”에 대한 추정이지 속도 측정이 아닙니다. 들어가더라도 업무에 쓰기엔 너무 느릴 수 있습니다. 실제 성능은 cluster를 구성한 뒤 속도 시험과 용량 시험으로 잽니다.

요건

• 지원되는 Apple Silicon Mac 두 대 이상
• 모든 Mac에 Msty Nexus Runtime이 설치되어 실행 중일 것
• 참여 기기 모두가 Fleet 또는 안내형 Cluster 합류 절차로 연결되어 있을 것
• 참여 Mac 사이의 Thunderbolt 연결
• 각 Mac에서 RDMA 켜기
• 합친 메모리로 충분한, 지원되는 MLX 모델
• 모든 node에 설치된 Cluster 자격

“지원되는 Mac”이 어떤 기종과 macOS 버전인지, RDMA를 켜는 구체적인 방법은 공식 문서에는 설명이 없습니다.

믿을 수 있는 로컬 네트워크에서 씁니다. 일반적인 cluster 작업 흐름에서 Nexus는 SSH를 쓰지 않으며, cluster에 속했다고 해서 Runtime을 넓게 공개해도 안전해지는 것은 아닙니다.

연결망을 안정적으로 유지하기 위한 권장 사항입니다.

• Cluster 설정 화면에 나오는 Thunderbolt 연결 구성대로 Mac을 잇습니다.
• 참여하는 모든 Mac에서 RDMA를 켭니다.
• 모든 기기를 깨어 있게, 전원이 연결된 채로, 고정된 네트워크 주소로 둡니다.
• 모델이 돌아가는 동안 케이블, 네트워크 인터페이스, 구성원을 바꾸지 않습니다.
• 고른 모델 준비 방식에 맞는 로컬 저장 공간이 충분한 Mac을 씁니다.

controller, member, coordinator

역할	하는 일
controller	구성을 계획하고, 준비를 조율하고, 분산 모델을 실행하고, Nexus 게이트웨이로 내놓습니다
member	배정된 worker를 돌리고, 범위가 정해진 운영 정보를 controller에 보고합니다
coordinator	지금 구성(formation)의 rank 0입니다. 모델을 올리고, 다른 rank를 조율하고, 추론에 쓰이는 게이트웨이 경로를 제공합니다

controller는 cluster가 요청을 받는 동안 내내 켜져 있을 기기로 고릅니다. coordinator가 멈추면 실행 중인 구성은 정상적으로 요청을 받을 수 없습니다.

coordinator, 분산 방식, 모델, 컨텍스트 길이, 구성원 가운데 하나라도 바꾸면 다른 구성이 되므로, cluster를 다시 준비하거나 다시 시작해야 합니다.

Cluster 만들기

설정 화면은 앞 단계의 요건이 채워져야 다음 단계가 열립니다.

1. controller가 될 기기에서 Cluster를 엽니다.
2. Fleet 또는 안내형 합류 절차로, 자격이 있는 Apple Silicon Mac을 두 대 이상 추가합니다.
3. Discover fabric을 실행해 Nexus가 도달 가능성, RDMA, Thunderbolt 연결을 확인하게 합니다.
4. 라이브러리에서 MLX 모델을 고르거나, 호환되는 Hugging Face 저장소를 입력합니다.
5. coordinator, 컨텍스트 길이, 분산 방식, 저장 방식을 고릅니다.
6. Preflight를 실행하고, 진행을 막는 문제를 모두 해결합니다.
7. Provision runtimes로 모든 node에 MLX를 준비합니다.
8. Prepare model로 필요한 모델 파일을 모든 node에 둡니다.
9. Launch workers로 rank를 시작하고 백그라운드에서 cluster를 구성합니다.
10. 실행 상태가 될 때까지 기다린 뒤 속도와 요청 용량을 시험합니다.

가능하면 Fleet에 등록된 기기를 씁니다. Fleet에서 기기를 추가하면 신뢰 연결이 자동으로 맺어져, 합류용 자격 증명을 손으로 주고받지 않아도 됩니다.

Discover fabric이 확인하는 것

• 모든 node가 온라인이고 합류해 있는가
• node들이 서로 닿는가
• coordinator가 온라인인가
• RDMA가 모든 곳에서 켜져 있는가
• 예상한 Thunderbolt 연결망이 빠짐없이 이어져 있는가
• 다른 구성이 시작되거나 멈추는 중이 아닌가

발견 뒤에 케이블을 더하거나 옮겼다면 다시 발견을 실행해야 합니다. 일반 네트워크 연결이 빠진 RDMA-over-Thunderbolt 연결을 대신해 줄 것이라고 여기고 진행하면 안 된다고 문서는 경고합니다.

분산 방식 고르기

방식	작동	쓰는 경우	저장
Pipeline parallel	Mac마다 모델의 일부를 맡아, 배정된 층을 차례로 처리합니다	모델이 cluster의 합친 메모리를 필요로 하고, 각 Mac에 혼자서는 넉넉히 들어가지 않을 때	전체 복사 또는 분할 저장
Tensor parallel	모든 Mac이 모델 전체를 갖고, 층마다 연산을 나눠 합니다	모델이 참여하는 모든 Mac에 각각 들어갈 때만	모든 Mac에 전체 복사 필요

Pipeline 방식은 프롬프트와 생성 작업이 rank를 차례로 지나가야 하므로, 연결망이 빠짐없이 안정적이어야 성능이 납니다. Tensor 방식은 생성 한 건에 쓸 연산을 늘릴 수 있지만, 토큰 하나마다 기기 간 조율이 필요합니다.

목적이 모델 하나를 더 크게, 더 빠르게 돌리는 것이 아니라 서로 독립된 요청을 더 많이 받는 것이라면 Smart Balancer를 쓰라고 문서는 안내합니다.

모델과 컨텍스트

Cluster는 Nexus 라이브러리의 지원되는 MLX 모델이나 호환되는 Hugging Face 저장소를 받습니다. 준비 단계에서 고른 리비전을 worker가 시작하기 전에 내려받으므로, 앱의 첫 요청이 모델 전송을 기다리지 않습니다.

컨텍스트 길이는 요청마다 메모리 사용에 영향을 줍니다. 짧은 컨텍스트로는 들어가던 모델이 더 긴 컨텍스트나 여러 동시 응답에서는 안전한 메모리를 넘을 수 있습니다. 실제로 부를 앱에 맞는 현실적인 컨텍스트를 고르고, Preflight와 Capacity로 확인합니다.

Preflight

Preflight는 실행 전 관문입니다. 확인하는 항목은 다음과 같습니다.

• node가 온라인이고, 합류해 있고, 서로 닿는다
• coordinator를 쓸 수 있다
• fabric 발견이 끝났다
• Thunderbolt 연결망이 빠짐없이 이어져 있다
• RDMA가 켜져 있다
• 진행 중인 구성 변경이 없다
• 고른 모델이 합쳐서 쓸 수 있는 메모리에 들어간다
• 모델 구조가 고른 분산 방식과 저장 방식을 지원한다

경고는 검토할 일이고, 필수 점검 실패는 구성을 막습니다. 실행을 되풀이해 시도하지 말고, 문제가 된 기기나 설정을 고친 뒤 Preflight를 다시 돌립니다.

모델 저장 방식

방식	내용	어울리는 경우
Full copy	참여하는 모든 Mac에 모델 전체를 둡니다. 저장 공간을 더 쓰지만 각 node를 따로 재사용하기 쉽습니다	유연성과 역할 변경의 쉬움을 중시할 때
Sliced weights	모델 구조가 안전한 분할을 지원하면, rank에 배정된 가중치 파일만 둡니다. 중복 저장과 전송을 줄입니다	저장 공간과 준비 시간이 더 중요하고, 구성이 바뀌지 않을 것으로 예상될 때

분할 저장은 pipeline 방식과, 지원되는 분할(sharded) 모델 구조에서만 쓸 수 있습니다. 안전한 분할이 안 되면 Nexus는 전체 복사를 쓰고, 불완전한 모델을 준비하는 대신 실제로 적용된 저장 방식을 알려 줍니다.

Nexus는 등록된 동료 기기 사이에서 모델 파일을 전달할 수 있어, 같은 파일이 기기마다 한 번씩 인터넷을 건너올 필요가 없습니다. 이때 출처 리비전과 파일의 정체가 계획한 snapshot과 일치해야 합니다.

준비 세 단계가 나뉘어 있는 이유

세 동작은 따로 실행됩니다. 실패했을 때 끝난 일을 되풀이하지 않고 그 단계만 다시 시도할 수 있게 하려는 것입니다.

동작	하는 일
Provision runtimes	필요한 node에 지원되는 MLX 런타임을 설치합니다
Prepare model	필요한 모델 파일을 내려받거나 전달받고, 모든 rank가 기대한 데이터를 갖췄는지 확인합니다
Launch workers	각 rank를 시작하고 분산 모델을 구성합니다

구성이 준비 상태가 되려면 coordinator가 rank 0을 먼저 올려야 합니다. 큰 모델은 올리는 데 몇 분이 걸릴 수 있습니다. Launch workers는 백그라운드에서 돌고, Cluster 화면을 떠나도 Activity에서 진행 상황을 볼 수 있습니다.

운영 화면

Cluster 화면은 구성원의 준비 상태와 배정된 rank, 모델 준비와 실행 상태, 메모리와 GPU 활동, Thunderbolt 연결망 활동, 요청 진행과 생성 속도, 운영자가 손써야 할 경고를 보여 줍니다.

쉬는 동안의 조율 신호(heartbeat)는 정상입니다. 계속되는 포화, 빠진 구성원, 되풀이되는 실행 실패, 연결된 하드웨어와 맞지 않는 구성은 조사해야 합니다.

속도 재기

구성 뒤 Test speed로 초당 토큰 수(쓰는 속도), 첫 토큰까지의 시간, 지금 Mac 대수에서의 성능을 잽니다. 짧은 요청 하나를 지금 구성에 보내는 방식입니다. 모델, 구성원, 컨텍스트, 분산 방식, 연결망을 바꾼 뒤에는 다시 실행합니다.

동시 요청 한도 찾기

Capacity 탭은 정한 응답 목표를 지키면서 구성이 몇 개의 응답을 동시에 감당하는지 잽니다.

1. 받아들일 수 있는 스트림별 최소 속도를 정합니다.
2. 받아들일 수 있는 첫 토큰까지의 최대 시간을 정합니다.
3. cluster가 다른 일을 하지 않을 때 용량 시험을 실행합니다.
4. 동시 처리 단계별로 전체 처리량과 스트림별 결과를 검토합니다.
5. 업무에 맞으면 권장된 동시 응답 한도를 적용합니다.

이 시험은 몇 분이 걸리고 지속적인 추론 부하를 만듭니다. 실제 트래픽과 함께 돌리면 그 요청이 느려지고 결과도 왜곡됩니다.

새 MLX 요청 한도를 적용하면 Runtime이 다시 시작됩니다. 그동안 진행 중인 로컬 응답이 멈추므로, 시간을 골라 적용합니다.

상태가 나빠졌을 때(degraded)

rank 하나 이상이 더 이상 참여하지 않으면 cluster는 degraded 상태가 됩니다. 분산 추론은 지금 구성에 의존하므로, 필요한 구성원을 잃으면 용량이 줄어드는 데 그치지 않고 요청이 끊길 수 있습니다.

상황	조치
cluster는 돌고 있는데 게이트웨이 경로가 다시 연결되지 않음	자동 복구를 기다리거나 Reconnect now를 씁니다
node 또는 연결망 링크가 없음	트래픽을 멈추고, 기기나 케이블을 되살리고, fabric을 다시 발견한 뒤 cluster를 다시 구성합니다

구성원, 저장 방식, 연결 구성을 바꾸기 전에는 진행 중인 트래픽을 멈춥니다. 분산 모델이 돌아가는 중에 구성원을 빼면 그 모델이 끊깁니다. cluster에서 나가면 구성원 관계만 없어지고, 관계없는 Runtime 상태, 외부 캐시, 관리 대상이 아닌 파일은 지워지지 않습니다.

비공개로 유지하기

Cluster는 인증된 Runtime 간 제어와, 운영자가 고른 인터페이스 위의 별도 분산 MLX 전송을 씁니다. controller와 member의 API는 믿을 수 있는 주소에만 두어야 합니다. 자격이 있다는 것이 Runtime을 공개해도 된다는 뜻은 아닙니다.

Fleet 등록과 Console이 중개하는 합류 절차를 쓰면 node 자격 증명을 기기 사이에 손으로 복사하지 않아도 됩니다.

참고한 문서

• Nexus 문서: Cluster
• Nexus 문서: Smart Balancer