Mac 두 대 묶어서 80B 굴리는 Exo, 우분투에선 아직 한참 멀었음

어디서 봤더라, 영문 블로그 하나 읽다가 흥미로운 도구를 알게 됐음. Mac Mini랑 MacBook Pro 두 대를 묶어서 80B 모델을 70 tok/s 넘게 돌렸다는 후기였는데, 사용한 도구가 Exo라는 오픈소스. 처음엔 "또 그냥 LM Studio 같은 거겠지" 싶었는데 동작 방식이 좀 다르더라고요.

한 대가 못 버티는 모델을 여러 대로 쪼개는 발상#

LM Studio Link 같은 도구는 강한 머신 한 대 + 약한 머신 여러 대 구조거든요. 강한 쪽이 모델을 돌리고 나머지는 클라이언트로 붙는 방식.

Exo는 정반대 방향임. 여러 머신의 RAM·CPU·GPU를 하나의 가상 클러스터처럼 묶어서 어떤 머신 한 대로도 못 돌릴 모델을 굴리는 게 목표. 자동 디스커버리로 같은 네트워크의 노드를 찾아내고, 모델 레이어를 각 디바이스 사양에 맞게 자동 분할함. 안 써봤는데 공식 GitHub 설명만 보면 토폴로지 인식 자동 병렬화가 핵심 셀링 포인트인 듯해요.

원문에서는 Mac Mini M4 16GB + MacBook Pro M4 Max 64GB 조합으로 돌렸다고 함. 합쳐서 80GB 가까이 되는 통합 메모리에 4-bit 양자화 80B 모델(약 44GB)을 올린 거고, 인퍼런스 중에 Mac Mini는 86°C까지 올라가는데 MacBook은 50°C 근처에서 놀고 있었다고. 부하 분산이 RAM 기준으로 계산되니 RAM 작은 쪽이 더 일을 많이 하는 셈인 듯.

나한테 진짜 매력적이었던 건 OpenAI 호환 API#

원문에서 가장 와닿았던 부분이 이거였어요. http://localhost:52415/v1로 OpenAI 스펙 그대로 노출되는 구조. 즉 LangChain이든 LlamaIndex든, 본인이 만든 FastAPI 서비스든 클라이언트 코드 한 줄도 안 바꾸고 로컬 클러스터를 백엔드로 갈아끼울 수 있다는 뜻.

이게 왜 중요하냐면, OpenAI나 Anthropic API로 프로토타입 만들다가 비용 부담되는 시점이 오면 그냥 base_url 한 줄 바꾸고 모델명만 갈아끼우면 끝나거든요. 코드 수정 거의 없음. 이런 "갈아끼우기 친화적" 설계는 진짜 잘 만들었음.

성능 수치는 일단 인상적임 (자기들 주장)#

원문 환경에서 Qwen3-Next-80B-A3B-Thinking-4bit를 70~80 tok/s로 돌렸다고 함. TTFT는 쿼리 복잡도에 따라 4~11초. "왜 하늘이 파란가" 같은 단순 질문에 reasoning까지 포함해서 1,184 토큰 뱉는 데 큰 무리가 없어 보였어요.

직접 돌린 게 아니라 정확한 건 모르는데, 80B급 사고형(thinking) 모델을 가정용 와이파이 환경에서 70 tok/s 넘게 뽑아냈다는 게 사실이라면 꽤 의미있는 숫자임. 보통 이 정도 사이즈면 그냥 클라우드 인스턴스 띄우는 게 마음 편하거든요.

다만 후기 글이라는 게 보통 잘 나온 케이스 하나 골라서 쓰는 거라, 다른 프롬프트들도 일관되게 그 속도가 나오는지는 더 봐야 할 듯.

근데 우분투 운영자 입장에선 좀 김샘#

여기서부터가 본인이 이 글 쓰게 된 진짜 이유. Linux 빌드는 현재 CPU 전용임.

내 환경은 Mac/Windows에서 개발하다가 우분투 서버에 nginx 올려서 운영하는 구조라, 이런 식의 "Mac 생태계 안에서만 빛나는 도구"는 결국 답답해짐. M4의 MLX 백엔드, Thunderbolt 5 기반 RDMA(인터노드 지연 99% 절감 주장)... 다 Apple Silicon 가정. NVIDIA/AMD GPU 지원은 "actively under development"라고만 적혀 있는데, 이런 문구 진짜 조심해야 함. 6개월 뒤에 봐도 똑같이 적혀 있는 경우가 부지기수거든요.

추가로 걸리는 점들:

• WiFi로 묶으면 RDMA 못 씀. 결국 Thunderbolt 5 케이블 직결이 사실상 전제고, 그 마저도 macOS 26.2 이상 필요
• 노드 한 대가 죽으면 추론 전체가 멈추는 단일 장애 지점 문제는 문서에 명확히 다뤄지지 않음
• 모델 다운로드 자체가 노드별로 되는지, 한 곳에서만 받는지 동작 방식이 글에서는 흐릿함

한국 환경에서 합리적인 시나리오는?#

원문 분위기는 "집에 굴러다니는 Mac 모아서 80B 모델 가능!"인데, 한국 1인 개발자/소규모 팀 기준으로 다시 따져봤습니다.

대충 견적을 잡아보면, Mac Mini M4 16GB + MacBook Pro M4 Max 64GB 조합이면 600만원대는 우습게 넘어가요. 같은 돈이면 RTX 4090 한 장에 본체 맞추고도 한참 남고, 그 한 장으로도 70B 4-bit는 무난하게 돌아감. 클라우드 A100 시간당 요금까지 같이 비교하면 24/7 안 돌리는 한 클라우드가 압도적으로 싸요.

그럼 누구한테 매력적이냐? 이미 Mac 여러 대 가지고 있는 사람한테나 의미있는 시나리오인 듯. 회사에 안 쓰는 M2/M3 Mac들 굴러다닌다거나, 본인이 MacBook이랑 Mac Studio 둘 다 있다거나. 새로 사서 구축할 가치는 솔직히 의심스러움.

잠깐 곁가지로 — Apple Silicon 종속 도구가 너무 많아짐#

요즘 자꾸 이런 "Apple Silicon 전용" 도구가 늘어나는 게 좀 신경 쓰이는데요. MLX 자체가 Apple 입장에선 잘 만든 프레임워크인 건 인정. 통합 메모리 구조에 최적화되어 있고 코드도 깔끔함. 근데 결국 Mac Studio 팔아먹는 데 쓰이는 셈이고, 오픈소스 도구가 Apple 제품군 마케팅 도구가 되는 흐름이라는 게 좀 묘함.

CUDA 생태계가 깡패긴 하지만 그래도 NVIDIA 하나만 잘 잡으면 데스크톱 → 워크스테이션 → 데이터센터 GPU까지 같은 코드 돌릴 수 있는 호환성은 무시 못 함. Apple 쪽은 갓 시작한 단계라 그런지 폐쇄성이 너무 두드러져요.

LM Studio Link랑 어떻게 다른가#

원문에서 깔끔하게 정리된 부분을 한 줄로 옮기자면:

• LM Studio Link — 강한 머신 1대 + 약한 머신 여러 대. 한 호스트, 여러 클라이언트.
• Exo — 여러 머신을 묶어서 더 큰 모델 굴림. 여러 호스트, 한 모델.

목적이 완전 다르니까 둘 중 어느 게 낫다는 비교는 의미없음. 본인 시나리오에 맞춰서 골라야 함.

그래서 결론#

Exo는 Mac 클러스터 가진 사람한테는 진짜 좋은 도구임. OpenAI 호환 API 하나만으로도 가져다 쓸 가치가 있어요. 근데 우분투 서버 중심으로 운영하는 풀스택 입장에선 아직 그림의 떡이고, 실제로 "이거 도입하자"고 결정하기까지는 Linux GPU 지원이 정식으로 들어와야 할 듯.

다음 글에서는 RTX 환경에서 비슷한 분산 추론 구성할 때 쓸 수 있는 옵션들 — vLLM의 tensor parallel, llama.cpp의 RPC 서버 모드 — 실제로 만져보고 비교해보려고 합니다. 사실 이쪽이 한국 개발자들한테 훨씬 현실적이거든요.