Mac Mini 두 대, 혹은 Mac Mini와 MacBook을 옆에 나란히 두고 썬더볼트 케이블 하나로 연결한 뒤 70B짜리 거대 모델을 돌릴 수 있다면 — 그리고 그게 실제로 빠르기까지 하다면 — 꽤 매력적인 이야기가 된다. 결론부터 말하면 “가능은 하다”. 그런데 “의미 있는가”는 조금 다른 질문이다.
llama.cpp RPC 서버가 만든 가능성
llama.cpp는 꽤 오래전부터 --rpc 플래그를 통해 분산 추론을 실험적으로 지원하고 있다. 원리는 단순하다. 한쪽 머신에서 llama-rpc-server를 실행하면 해당 기기가 오프로드 대상 노드가 된다. 다른 쪽 머신에서는 llama-cli 또는 llama-server를 실행할 때 --rpc 192.168.x.x:50052 형태로 원격 노드를 지정하면 된다. 모델 레이어 일부가 원격 노드의 메모리에 올라가고, 추론 중 활성화 값(activation)이 양쪽 노드 사이를 오가며 계산이 진행된다.
설정 자체는 그리 복잡하지 않다. rpc-server 바이너리를 빌드하고(cmake -DLLAMA_RPC=ON), 서버 측 머신에서 llama-rpc-server -H 0.0.0.0 -p 50052를 실행하면 끝이다. 클라이언트 측에서는 --rpc [서버IP]:50052 --n-gpu-layers [숫자]를 붙여주면 지정한 레이어 수만큼 원격 노드로 분산된다. 이론상 세 대 이상도 연결할 수 있다.
썬더볼트 40 Gbps, 진짜 얼마나 빠른가
썬더볼트 4와 USB4는 최대 40 Gbps, 이론 대역폭으로는 5 GB/s에 달한다. 10GbE 이더넷(1.25 GB/s)의 네 배다. 숫자만 보면 충분해 보인다. 하지만 여기서 병목 분석이 필요하다.
분산 추론의 핵심 비용은 레이어 경계마다 발생하는 activation 텐서 전송이다. 예를 들어 Llama-3 70B 모델을 두 노드에 반씩 나눠 올리면, 매 토큰 생성마다 앞 절반 레이어의 출력이 네트워크를 타고 뒤 절반 레이어로 전달돼야 한다. bfloat16 기준으로 시퀀스 길이 512, 히든 크기 8192라면 한 번 전송에 약 8MB다. 토큰당 한 번이니까 초당 20토큰이면 초당 160MB 전송이 필요한 셈이다. 이 수치만 보면 썬더볼트는 여유롭다.
문제는 레이턴시다. 대역폭은 충분하더라도 레이어 경계마다 발생하는 동기적 왕복(round-trip) 대기 시간이 누적된다. 이더넷 환경에서 실측해보면 10GbE 직결 연결도 네트워크 스택 오버헤드 때문에 수십 마이크로초 단위 레이턴시가 붙는다. 썬더볼트는 IP 터널링 방식(Thunderbolt Bridge)을 쓰기 때문에 이론적으로는 낮은 레이턴시가 기대되지만, macOS에서 실제 측정하면 로컬 루프백보다는 여전히 느리고, 특히 OS 소켓 스택이 개입하면 예측하기 어려운 지터(jitter)가 발생한다.
이미지 출처: Unsplash
실제 사용 결과에서 드러나는 현실
커뮤니티 실측 사례들을 종합하면 대략 이런 그림이 나온다. Mac Mini M4(24GB) 두 대를 이더넷 10G로 연결해 Llama-3 70B를 분산 실행했을 때 토큰 생성 속도는 단일 머신에서 32B 모델을 실행하는 것보다 느린 경우가 많았다. 70B 모델을 “쓸 수 있게” 된 것은 맞지만, 속도는 기대에 못 미쳤다. 썬더볼트 연결로 바꾸면 이더넷보다는 나아지지만 드라마틱한 차이는 없었다는 보고가 주를 이룬다.
반면 메모리 합산 자체가 목적인 시나리오에서는 이야기가 달라진다. Mac Mini M4 Max(128GB)와 Mac Studio M4 Ultra(192GB)를 조합하면 320GB 통합 메모리로 200B급 이상의 모델도 올릴 수 있다. 이 경우 속도는 차선이고 “일단 실행 가능한 것”이 제1 목표이기 때문에 레이턴시 손실을 감수할 만하다. 특히 배치 처리나 비실시간 추론이라면 꽤 실용적인 구성이다.
MLX는 어떤가
Apple의 공식 머신러닝 프레임워크인 MLX는 현재 시점에서 멀티 디바이스 분산 추론을 공식 지원하지 않는다. MLX는 단일 Apple Silicon 칩의 통합 메모리를 전제로 설계됐고, 멀티노드 추론 기능은 로드맵에도 명시된 바 없다. 따라서 썬더볼트 분산 추론을 시도하려면 현재로서는 llama.cpp RPC가 유일한 현실적 선택지다. llama.cpp 자체가 Metal 백엔드를 지원하니 Apple Silicon에서도 GPU 가속을 활용할 수 있다는 점은 위안이 된다.
어떤 사람에게 의미 있는 설정인가
정리하면, 썬더볼트 분산 추론은 두 가지 조건 중 하나를 만족할 때 고려할 만하다. 첫째, 단일 머신의 메모리로는 올릴 수 없는 모델 크기가 목표일 때. 둘째, 속도보다 비용 효율이 우선이고 이미 두 대의 Mac이 손에 있을 때. 반대로 응답 속도가 중요한 대화형 인터페이스를 만들거나, 이미 단일 머신으로 충분한 모델을 쓰고 있다면 분산 추론은 복잡성만 늘릴 뿐 실익이 없다.
흥미로운 건 이 분야가 아직 초기라는 점이다. llama.cpp의 RPC 구현은 계속 개선 중이고, 언젠가 MLX도 멀티노드를 지원하게 된다면 지금보다 훨씬 매끄러운 경험이 가능해질 것이다. 썬더볼트 대역폭 자체는 충분하다는 게 이미 확인된 만큼, 남은 과제는 소프트웨어 스택의 레이턴시 최적화다. Mac 생태계 안에서 로컬 LLM 클러스터를 꾸리는 방식이 점차 현실적인 선택지로 자리 잡아가고 있는 건 분명하다. 지금 당장 극적인 성능 향상을 기대하기보다, 메모리 한계를 넘어서기 위한 실용적 우회로로 접근하는 것이 이 설정을 가장 잘 활용하는 방법이다.
출처