모델별 실행 레시피
MLX-JACCL로 두 Mac 분산 실행: 설정과 검증 조건
Mac을 연결하기 전에 먼저 분산 실행의 조건부터 확인하세요.
여러 Mac을 연결한다고 메모리가 자동으로 하나의 큰 메모리처럼 합쳐지는 것은 아닙니다. MLX1의 JACCL backend는 지원 OS와 네트워크 조건에서 장치 간 통신을 수행하며, 모델·tensor 분할과 MLX-LM2의 분산 실행 지원도 맞아야 합니다. 먼저 두 대에서 네트워크와 버전을 확인하고, 작은 workload로 결과 일치와 통신 오류를 점검한 뒤 단일 Mac baseline과 비교하세요.
먼저 확인할 것: 메모리 합산이 아니라 분산 모델 실행입니다
큰 모델 파일을 한 Mac에 올리기 어렵다고 Mac 두 대를 연결해 곧바로 메모리 용량을 합칠 수 있다고 생각하기 쉽습니다. 분산 추론에서는 모델의 일부 tensor를 각 장치에 배치하고, 계산 중 장치 사이에 필요한 데이터를 주고받습니다. 어떤 텐서가 어느 장치에 놓이는지, 런타임3이 그 분할을 지원하는지, 통신 비용이 계산 이득을 지우지 않는지가 모두 결과를 좌우합니다. 저장공간이나 unified memory4의 숫자만 더해서 실행 가능 여부를 예측할 수는 없습니다.
여기서는 Apple MLX의 JACCL backend와 MLX-LM의 분산 생성 경로를 확인하는 것을 목표로 합니다. JACCL은 통신 계층이지 모델 분할 전략 자체가 아닙니다. MLX 0.30.6 릴리스는 JACCL와 MLX-LM의 분산 서버 추론 변경을 발표했지만, 특정 Mac 조합의 보편적 배속이나 장비별 지원표를 제공하지 않습니다. 따라서 이 문서는 재현된 벤치마크가 아니라 설치·연결·검증 절차입니다.
시작 전에 두 Mac 모두 Apple Silicon인지, 같은 로컬 네트워크에서 서로 연결되는지, 실행하려는 MLX 및 MLX-LM 버전이 JACCL 경로를 제공하는지 확인합니다. MLX 0.30.6의 JACCL 업데이트 조건으로 명시된 macOS 26.3 이상도 확인하세요. 회사 관리 장비나 공개 Wi-Fi에서는 네트워크 권한과 방화벽 정책을 임의로 변경하지 말고 관리자 지침을 따릅니다.
두 Mac의 버전과 네트워크부터 확인합니다
JACCL 실습 경로는 두 Mac mini를 Thunderbolt 케이블로 연결하고, MLX의 RDMA setup 도구로 hostfile을 만든 다음 `mlx.launch`로 작은 분산 테스트와 MLX-LM 예제를 차례로 실행하는 것입니다. MLX 공식 안내는 이 자동 구성에서 노드 간 SSH와 RDMA 가능 여부, thunderbolt 연결 mesh를 검사한다고 설명합니다. 완전한 mesh가 되지 않는 연결, Ethernet-only 네트워크, 지원되지 않는 OS에서는 이 JACCL 경로를 억지로 적용하지 말고 MLX가 문서화한 ring/Ethernet 방식 또는 단일 Mac으로 돌아갑니다.
두 Mac의 호스트 이름이 서로 해석되고, passwordless SSH가 동작하며, 각 장비에 동일 경로의 Python과 테스트 스크립트가 있어야 합니다. JACCL용 `--auto-setup`은 각 장비에서 passwordless sudo를 요구하며 Thunderbolt 네트워크 구성을 변경합니다. 이를 허용할 수 없는 관리 장비에서는 `--auto-setup`을 생략해 출력된 명령을 검토하고 관리자 승인을 받으세요. 설치된 MLX는 macOS 26.3 이상이어야 JACCL 사용 조건에 부합합니다.
아래 절차는 네트워크와 커널 구성을 변경할 수 있으므로 전용 테스트 장비에서 실행합니다. 처음부터 큰 모델을 띄우지 말고 rank 수가 두 개로 잡히는지 확인하세요. 양쪽 로그에서 rank 0/1과 `size=2`를 확인하지 못하면 실제 추론으로 넘어가지 않습니다.
# Run on both Macs; replace the hostnames with names configured for SSH.
sw_vers
python3 --version
python3 -m pip show mlx mlx-lm
ssh mac-mini-2 'python3 --version && python3 -m pip show mlx mlx-lm'
mlx.distributed_config --verbose --hosts mac-mini-1,mac-mini-2 --over thunderbolt --dot
mlx.distributed_config --verbose --backend jaccl --hosts mac-mini-1,mac-mini-2 --over thunderbolt --auto-setup --output hosts.json작은 모델로 분산 실행이 성립하는지 확인합니다
hostfile이 만들어지면 먼저 공식 MLX 문서 형식으로 작은 rank 검사를 시작하고, 양쪽 장비에 같은 Python과 실행 스크립트가 있는지 확인합니다. JACCL은 hostfile에 두 rank를 잇는 RDMA 장치 정보가 필요합니다. setup 도구가 출력한 파일을 직접 편집한다면 네트워크에 실제로 연결된 RDMA 장치 이름과 rank 순서를 확인하세요.
처음에는 실행 가능한 작은 모델과 짧은 prompt를 사용합니다. 모델 파일이 어디에 내려받아지는지, 각 프로세스가 어떤 rank로 시작했는지, 모든 장비가 정상 접속했는지 로그를 봅니다. 답변이 생성되어도 분산 실행 성공의 충분조건은 아닙니다. 각 장치의 메모리 사용과 배치 정보를 확인하고, 오류가 난다면 양쪽 프로세스를 종료한 뒤 포트·주소·버전 차이를 한 항목씩 대조합니다.
rank 검사가 `rank=0 size=2`와 `rank=1 size=2`를 출력하면 분산 그룹이 만들어졌다는 뜻입니다. 이는 아직 모델 분할을 입증하지 않습니다. 이어서 MLX distributed 문서의 MLX-LM 채팅 예시를 실행하고 모델이 두 장치에 나뉘는지 로그에서 확인합니다. MLX-LM의 모델 아키텍처가 해당 분산 분할을 지원하는지 공식 문서로 확인하고, 단순히 launcher가 시작됐다는 이유로 나눠졌다고 판단하지 마세요.
mlx.launch --verbose --backend jaccl --hostfile hosts.json -- python3 -c 'import mlx.core as mx; g=mx.distributed.init(backend="jaccl"); print(f"rank={g.rank()} size={g.size()}")'
mlx.launch --verbose --backend jaccl --hostfile hosts.json -- python3 -m mlx_lm chat --model mlx-community/DeepSeek-R1-0528-4bit
같은 질문으로 단일 Mac과 두 Mac을 비교합니다
비교 기준을 만들 때는 모델 버전과 가중치, 양자화5, prompt, 최대 출력 길이, sampling 설정을 고정합니다. 한 번은 단일 Mac에서 실행하고 다음은 두 Mac 분산 경로로 실행합니다. 첫 모델 로드는 다운로드와 초기화 시간이 포함되므로 cold 시작으로 별도 기록하고, 반복 요청은 준비가 끝난 warm 상태에서 여러 번 수행합니다.
기록할 값은 전체 완료 시간만이 아닙니다. 첫 token6까지의 시간, 출력 token 수와 생성 속도, 각 Mac의 메모리와 GPU/CPU 사용량, 네트워크 트래픽, 오류·재시도 횟수를 함께 남깁니다. 답변 내용이 달라졌다면 속도 숫자를 비교하기 전에 random seed, sampling, tokenizer 및 템플릿이 같은지 확인합니다. 분산 실행은 계산 분배와 통신을 바꾸므로 입력 길이와 output 길이에 따라 이득이 달라질 수 있습니다.
예를 들어 네트워크를 거치는 동안 짧은 답변이 더 늦어지고 긴 답변에서만 차이가 난다고 가정할 수 있습니다. 그 경우 평균 하나로 장비 결론을 내리지 말고, 짧은 interactive 질의와 긴 batch 작업을 각각 기록합니다. 이 예시는 비교 방법을 설명하기 위한 가정이며 MLX의 측정 결과가 아닙니다.
| 단계 | 기록 | 통과 기준 |
|---|---|---|
| 연결 | OS·패키지·주소·rank 로그 | 양쪽 프로세스가 서로를 찾음 |
| 배치 | 장치별 메모리·작업 로그 | 의도한 모델 분할과 장치 참여가 확인됨 |
| 정확성 | 같은 prompt의 출력·토큰 수 | 답변 품질과 종료 상태가 허용 범위 안 |
| 성능 | TTFT·완료 시간·메모리·전송량 | 실제 workload에서 운영 복잡성보다 이득이 큼 |
실행 가능 여부와 운영상 이득을 별도 질문으로 확인합니다.
연결
- 기록
- OS·패키지·주소·rank 로그
- 통과 기준
- 양쪽 프로세스가 서로를 찾음
배치
- 기록
- 장치별 메모리·작업 로그
- 통과 기준
- 의도한 모델 분할과 장치 참여가 확인됨
정확성
- 기록
- 같은 prompt의 출력·토큰 수
- 통과 기준
- 답변 품질과 종료 상태가 허용 범위 안
성능
- 기록
- TTFT·완료 시간·메모리·전송량
- 통과 기준
- 실제 workload에서 운영 복잡성보다 이득이 큼
실패하면 네트워크와 분할 조건을 순서대로 좁힙니다
상대 장비를 찾지 못하면 두 Mac의 IP가 현재 같은 네트워크에 있는지, 라우터가 장치 간 통신을 차단하지 않는지, 방화벽·VPN·보안 에이전트가 연결을 막는지 확인합니다. 무작정 방화벽을 끄는 대신 운영체제의 차단 로그나 관리자 정책을 확인합니다. 포트 번호는 현재 MLX 실행 명령과 공식 문서에서 확인하고 임의로 열지 마세요.
연결은 되지만 초기화가 실패한다면 패키지 버전과 macOS 조건, rank 수와 주소 설정을 대조합니다. 메모리 부족이라면 모델의 실제 가중치 크기, 각 장치 배치, context/KV cache와 다른 앱의 사용량을 분리해 봅니다. 네트워크를 빠르게 바꾸는 것만으로 가중치가 모든 장치에 고르게 배분되지는 않습니다.
실행은 되지만 느리다면 먼저 어떤 구간이 지연되는지 확인합니다. 모델이 작아 통신 비용이 계산 이득보다 큰 경우, 또는 prompt가 짧아 분산 준비 시간이 더 큰 경우에는 한 Mac이 더 나을 수 있습니다. 분산 server의 안정성이 확보되지 않았거나 성능 차이가 일관되지 않으면 기존 단일 Mac 경로를 운영 기본값으로 유지하세요.
공식 구현 문서와 릴리스 기록
이 안내에는 장비별 성능 측정이 없습니다. JACCL의 실제 지원 범위와 실행 옵션은 설치한 MLX·MLX-LM 버전의 공식 문서, release notes 및 help 출력으로 확인합니다. macOS와 네트워크 환경이 바뀌면 다시 작은 예제로 검증하세요.
용어 각주
MLX — Apple이 개발하는 머신러닝 프레임워크입니다. Apple silicon에서는 통합 메모리와 Metal을 활용하며, 별도로 Linux 실행 경로도 제공합니다. 지원 모델과 기능은 MLX 기반 도구마다 다릅니다.
본문으로 돌아가기MLX-LM — MLX를 사용해 언어 모델을 불러오고 추론·미세 조정을 수행하는 패키지입니다. MLX 프레임워크 자체나 모든 MLX 기반 앱을 뜻하지는 않습니다.
본문으로 돌아가기런타임 — 프로그램이 실행될 때 필요한 기능을 제공하는 소프트웨어 환경입니다. 로컬 AI에서는 모델을 실행하는 엔진을 가리키기도 하며, GPU 런타임 라이브러리와 완성된 서빙 앱은 서로 다른 구성요소입니다.
본문으로 돌아가기통합 메모리 — CPU와 GPU가 같은 물리 메모리 풀을 공유하는 구조입니다. 메모리 용량이 자동으로 늘어나는 것은 아니며, 실제 사용 가능량은 시스템에 따라 다릅니다.
본문으로 돌아가기양자화 — 모델의 수치를 더 적은 비트로 표현하는 방법입니다. 메모리 사용량과 함께 정확도나 실행 속도도 달라질 수 있으며, 영향은 형식과 구현에 따릅니다.
본문으로 돌아가기토큰 — 모델이 입력이나 출력을 나누어 처리하는 단위입니다. 토큰 하나가 글자 하나나 일정한 시간 길이에 해당하지는 않습니다.
본문으로 돌아가기