이 글은 원래 aifoss.dev에 게시되었습니다.

요약(TL;DR): EXO는 여러 장치의 메모리를 하나의 클러스터로 풀링하여, 단일 머신이 보유할 수 있는 크기보다 큰 모델을 실행할 수 있게 합니다. 2026년 중반에는 Apple Silicon 사용자에게는 정말 좋은 도구이며, Linux 환경의 NVIDIA 카드에서는 아직 기본적으로 CPU를 사용하므로 다소 미흡합니다. 기대치를 그에 맞춰 설정하세요.

솔직한 평가: 주변에 Apple Silicon Mac이 두 대 이상 있다면, EXO가 이들을 통해 70B 이상의 모델을 실행하는 가장 빠른 방법입니다. Linux에서 NVIDIA 카드를 사용한다면 vLLM이나 llama.cpp RPC를 사용하는 것이 좋습니다. EXO는 아직 그 단계가 아닙니다.

EXO가 실제로 무엇인지

EXO(the exo-explore/exo 프로젝트)는 네트워크상의 모든 장치를 단일 AI 클러스터로 연결합니다. 핵심 아이디어는 간단합니다. 아마 128GB의 통합 메모리를 가진 머신을 소유하고 있지는 않겠지만, 각각 48GB를 가진 세 대의 머신은 가지고 있을 수 있습니다. EXO는 모델을 이들 장치에 분할(shards)하여 클러스터가 단일 노드가 감당할 수 있는 것보다 더 많은 용량을 보유하도록 합니다.

이 프로젝트는 Apache 2.0 라이선스로 배포되어,

• 마스터-워커(Master-worker) 구조 없음. 장치들은 피어 투 피어(Peer-to-peer) 방식으로 연결됩니다. 관리해야 할 헤드 노드(Head node)가 없습니다. 네트워크상에서 접근 가능한 모든 장치는 링(Ring)에 참여하여 메모리를 기여할 수 있습니다.
• 링 메모리 가중치 기반 파티셔닝 (Ring memory-weighted partitioning). EXO는 모델을 레이어(Layer) 단위로 분할하고, 각 장치의 메모리에 비례하여 레이어 수를 할당합니다. 예를 들어, 64GB Mac Studio는 16GB MacBook Air보다 자동으로 더 많은 모델 레이어를 담당하게 됩니다.

장치들은 수동 설정 없이 서로를 발견합니다. 동일한 LAN에 있는 두 대의 머신에서 EXO를 실행하면 서로를 찾아냅니다. 클러스터는 http://localhost:52415에서 웹 UI 및 API를 제공하며, API는 세 가지 방언(Dialect)을 지원합니다: OpenAI Chat Completions, Anthropic의 Claude Messages 형식, 그리고 Ollama API입니다. 마지막 항목은 셀프 호스팅(Self-hosting) 사용자들에게 핵심적인 기능입니다. 이미 Ollama와 통신하도록 연결해 둔 모든 기능은 URL 변경만으로 EXO를 가리키도록 설정할 수 있습니다.

하드웨어 현실 점검 (구매 전 반드시 읽어보세요)

대부분의 EXO 관련 글들은 문서에서 가장 중요한 문장을 생략하곤 합니다. README에 적힌 문장을 그대로 가져왔습니다:

"macOS에서는 exo가 GPU를 사용합니다. Linux에서는 현재 exo가 CPU에서 실행됩니다. 우리는 하드웨어 가속기(Hardware accelerator) 지원을 확장하기 위해 작업 중입니다."

이 문장을 두 번 읽으십시오. macOS에서 EXO는 Apple의 MLX 프레임워크를 통해 Metal GPU를 사용하며, 이는 프로젝트가 최적화하고 있는 경로입니다. Linux의 경우, 기본 백엔드(tinygrad)는 CPU에서 실행됩니다. Linux에서의 GPU 가속은 현재 로드맵(Roadmap) 상의 항목이며, 업스트림(Upstream) 프로젝트에서 출시된 기능이 아닙니다.

그 단 하나의 사실이 "홈 클러스터 구축"이라는 이야기 전체를 재구성합니다. 여러분이 보았던 화제의 벤치마크들 — 프런티어 모델 (Frontier model)을 위해 3개의 RTX 3090을 풀링(Pooling)하는 것 — 은 현재 리눅스(Linux) 환경의 순정(Stock) EXO가 즉시 제공할 수 있는 기능이 아닙니다. 메인테이너(Maintainer)들의 자체 쇼케이스 실행 환경은 Apple Silicon입니다. 커뮤니티 데모들은 4개의 M3 Ultra Mac Studio를 풀링하여 Qwen3-235B, DeepSeek v3.1, 그리고 Kimi K2급 모델들을 실행합니다. 그것이 2026년 현재 EXO가 실재하는 방식입니다.

NVIDIA 하드웨어를 보유하고 있다면 방법은 있지만, 이는 포크(Fork)하여 직접 조정해야 하는 경로이며, 아래에서 다룹니다.

EXO 설치하기

EXO는 더 이상 pip install 패키지가 아닙니다. v1.0 재작성(Rewrite) 버전은 Node.js 대시보드를 구축하며 uv Python 툴체인(Toolchain)을 통해 실행됩니다. 먼저 uv, node, 그리고 rust가 설치되어 있어야 합니다.

macOS — 쉬운 경로:

brew install --cask exo

이 명령은 사전 빌드된(Prebuilt) 앱을 설치합니다. 소스(Source) 설치를 선호하시나요? 클론(Clone)하여 실행하세요:

git clone https://github.com/exo-explore/exo
cd exo/dashboard && npm install && npm run build && cd ..
uv run exo

Linux:

git clone https://github.com/exo-explore/exo
cd exo/dashboard && npm install && npm run build && cd ..
uv run exo

어떤 방식이든, 노드(Node)가 시작되고 대시보드 URL이 출력되는 것을 볼 수 있어야 합니다:

$ uv run exo
exo node started
dashboard + API: http://localhost:52415
...

브라우저에서 http://localhost:52415를 열면 채팅 UI와 클러스터(Cluster)의 토폴로지(Topology) 뷰를 확인할 수 있습니다.

실제로 맞닥뜨릴 수 있는 문제: Python 버전입니다. EXO는 Python 3.12에서 가장 안정적으로 작동합니다. Apple Silicon 사용자들의 경우 3.13 버전에서의 설치 실패 사례가 있습니다 (GitHub 이슈 #446 및 tinygrad 버전 불일치 이슈 #867에서 추적됨). 만약 uv run exo가 의존성 해결(Dependency resolution) 도중 종료된다면, 인터프리터(Interpreter) 버전을 고정하세요:

uv venv --python 3.12
uv run exo

클러스터 구축하기

이 지점이 바로 EXO가 제 가치를 발휘하는 곳입니다. 동일한 네트워크에 있는 두 번째 머신에서 동일한 uv run exo 명령어를 실행하세요. 설정 파일도, IP 목록도, 헤드 노드(head node)도 필요 없습니다. 두 노드는 서로를 발견하며, 대시보드의 토폴로지 뷰(topology view)가 업데이트되어 두 노드와 그들의 결합된 메모리를 보여줍니다.

모델을 실행하려면 API를 통해 요청하세요. EXO는 OpenAI 형식을 지원하므로, 호출 방식은 일반적입니다:

curl http://localhost:52415/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
...

EXO는 처음 사용할 때 Hugging Face에서 가중치(weights)를 다운로드하고, 각 장치의 가용 메모리에 따라 링(ring) 전체에 샤딩(sharding)합니다. 어떤 레이어(layer)를 어디에 배치할지 사용자가 선택하지 않습니다. 파티셔너(partitioner)가 이를 수행합니다. 단일 노드가 담을 수 있는 것보다 더 큰 모델을 불러오면 EXO가 이를 분산시킵니다. 이것이 바로 EXO의 핵심 목적입니다.

상호 연결(interconnect)에 대하여: EXO는 **Thunderbolt 5 기반의 RDMA (RDMA over Thunderbolt 5)**에 대한 Day-0 지원을 제공하며, 프로젝트 측은 이것이 Wi-Fi 대비 장치 간 지연 시간(latency)을 획기적으로 줄여준다고 주장합니다. Mac들을 체이닝(chaining)하는 경우, Thunderbolt 브리지나 10GbE는 Wi-Fi 6보다 의미 있는 업그레이드가 됩니다. 네트워크 홉(network hop)은 풀링(pooling)을 위해 지불해야 하는 비용이므로, 링크가 빠를수록 손실이 적습니다.

실제 성능은 어떤 모습인가

과장된 광고보다는 정직한 수치가 더 중요합니다. 다음 수치들은 공식 벤치마크가 아닌 커뮤니티 보고(community-reported) 수치이므로, 대략적인 수치로 참고하시기 바랍니다:

이 패턴이 주는 교훈은 다음과 같습니다: 모델을 수용할 수 있는 단일 머신이 모델을 분할하여 사용하는 두 대의 머신보다 더 빠릅니다. 네트워크 홉 (network hop)이 발생하지 않기 때문입니다. 풀링 (Pooling)은 추론을 더 빠르게 만드는 것이 아니라, 그렇지 않으면 수용할 수 없는 모델에 대해 추론을 '가능하게' 만듭니다. "한 대의 장비에 들어가지 않는다"는 문제가 "초당 토큰 수가 몇 개 더 느리다"는 문제보다 더 중요해질 때 EXO를 찾게 됩니다. 이미 모델이 들어가는 단일 GPU를 사용 중이라면, 일반적인 Ollama 또는 MLX 설정이 더 빠를 것입니다. 단일 Mac 경로에 대해서는 당사의 Ollama MLX 백엔드 가이드를 참조하십시오.

Linux 환경에서의 NVIDIA: 포크 (fork) 상황

소비자용 NVIDIA GPU를 풀링하기 위해 EXO를 검색하셨다면, 2026년 중반 기준의 가감 없는 현황은 다음과 같습니다:

• Linux용 업스트림 (Upstream) EXO는 기본적으로 CPU 상의 tinygrad를 사용합니다. GPU 사용자들은 "GPU는 감지되었으나 0.0 TFLOPS로 표시되는" 벽에 부딪혔습니다 (issue #821).
• 커뮤니티 포크(fork)인 **Scottcjn/exo-cuda**는 tinygrad를 통해 NVIDIA CUDA 추론 기능을 복구했으며, Tesla V100 및 M40 카드에서의 실행을 확인했습니다. NVIDIA 드라이버, CUDA 툴킷(toolkit), 그리고...