수중에 GPU 24GB 워크스테이션, 64GB를 탑재한 Linux 서버, 그리고 M2 MacBook이 있다. 실행하고 싶은 것은 235B 규모의 MoE (Mixture-of-Experts) 모델이다. 어떤 머신에도 단독으로는 올릴 수 없다. 이 "한 끗 차이로 메모리가 부족한" 상황을 장비를 추가로 구매하지 않고 해결하려는 것이 Mesh LLM이다. 7월 11일에 공개되었고, 7월 14일에는 벌써 v0.73.1이 나왔다. GitHub의 스타 수는 집필 시점 기준으로 2.8k이다.

여러 머신으로 하나의 큰 모델을 구동한다는 발상 자체는 새롭지 않다. 유명한 것으로 Petals나 exo, 본격적인 운용을 위한 vLLM + Ray가 있다. 다만 모두 도입 장벽이 어느 정도 높다. Petals는 공개 스웜(swarm)에 참여하는 BitTorrent 방식의 모델로, 레이어(layer)를 전 세계의 자원봉사자와 나누어 가진다. vLLM의 멀티 노드(multi-node) 구성은 Ray 클러스터(cluster) 관리가 전제된다.

Mesh LLM이 차별화되는 점은 "자신의 소유물만으로, 명령어 한 번에 묶는다"는 점이다. 실체는 18MB 정도의 Rust 제작 싱글 바이너리(single binary)로, 중앙의 랑데부(rendezu) 서버를 세울 필요가 없다. 설치하고 셋업하여 공개 메쉬(mesh)에 참여하기까지의 절차는 다음과 같다.

curl -fsSL https://raw.githubusercontent.com/Mesh-LLM/mesh-llm/main/install.sh | bash
mesh-llm setup
mesh-llm serve --auto

serve --auto를 실행하면, 로컬에서 API 서버가 localhost:9337에 구동되며, 웹 콘솔(Web console)이 3131번 포트에서 열린다. 그 후에는 OpenAI 클라이언트를 그대로 연결하면 된다. 엔드포인트(endpoint)가 /v1 호환이므로, 기존 코드는 base URL을 교체하는 것만으로 동작한다.

curl http://localhost:9337/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model":"GLM-4.7-Flash-Q4_K_M","messages":[{"role":"user","content":"hello"}]}'

흥미로운 점은 요청이 왔을 때 메쉬가 취하는 3단계 판단이다. README의 기술을 따라가 보면 우선순위가 명확하다.

먼저, 한 대의 머신에서 모델 전체를 유지할 수 있다면 해당 노드(node)가 로컬에서 처리한다. 불가능하다면 model 필드를 확인하여, 해당 모델을 가지고 있는 다른 피어(peer)로 요청을 전달한다. 그것도 안 되는 경우, 즉 어떤 한 대에도 담기지 않는 거대한 밀집 모델(dense model)의 경우, Skippy라고 부르는 메커니즘을 통해 레이어 범위를 구분하여 여러 머신에 분할 로드(split load)한다. 코디네이터(coordinator)가 연속된 레이어 범위를 계획하고, 하류(downstream) 스테이지부터 먼저 기동하여 준비가 완료되기를 기다린 후, 마지막으로 입구가 되는 stage-0 경로를 공개한다. 활성화(activation)가 스테이지에서 스테이지로 파이프라인(pipeline)을 통해 흘러가는, 이른바 파이프라인 병렬화(pipeline parallelism)다.

즉, 단순한 부하 분산이 아니다. 한 대에 실을 수 있는 양이라면 통째로 한 대에서 돌리고, 실을 수 없는 양이 되었을 때 비로소 머신을 가로질러 세로로 나눈다. 이 전환을 자동으로 수행하는 것이 Mesh LLM의 핵심이다. model에 "mesh"를 지정하면 모든 모델에 병렬로 던져 답변을 대조하는 Mixture-of-Agents 모드도 있다.

대응 플랫폼도 폭넓어 macOS와 Linux (CUDA, ROCm, Vulkan, ARM64), Windows까지 포함된다. 수중에 있는 잡다한 구성을 그대로 섞을 수 있다는 점은 실무에서 유용하다.

개인적으로 가장 효과적이라고 느낀 점은 통신 계층에 iroh를 채택했다는 점이다. iroh는 QUIC 기반의 P2P 라이브러리로, NAT 트래버설을 위한 홀 펀칭(hole punching)과 피어 키 인증(peer key authentication)을 내장하고 있다. 이것이 의미하는 바는, 각 머신에서 포트를 외부로 개방하거나 고정 글로벌 IP를 준비하지 않아도 NAT 내부끼리 직접 연결될 수 있다는 것이다. 가정이나 사무실 회선에 흩어진 머신을 묶는 용도로 매우 큰 장점이다. VPN을 설정하는 번거로움이 사라지기 때문이다.

공개 메쉬 (Public Mesh)의 피어 탐색 (Peer Discovery)에는 Nostr을 사용하고, 프라이빗 메쉬 (Private Mesh)는 초대 토큰 방식으로 폐쇄한다. 중앙 디스커버리 서버 (Discovery Server)를 두지 않는다는 설계 사상이 통신 구조까지 일관되게 적용되어 있다.

이 부분은 냉정하게 살펴둘 필요가 있다. serve --auto는 공개 메쉬에 참여하는 명령어로, 조건에 따라 자신의 요청이 타인의 머신에 있는 모델로 라우팅될 수 있다. 프롬프트에 기밀 정보가 포함되는 업무용으로 사용할 때, 갑자기 공개 메쉬에 연결하는 것은 피해야 한다. 동일한 바이너리로 초대 토큰을 이용한 프라이빗 메쉬를 구성할 수 있으므로, 실무에서는 먼저 그 방식부터 시작하는 것이 합리적이다.

또 다른 점은 Skippy의 파이프라인 분할 (Pipeline Parallelism)에 따른 숙명으로, 스테이지 (Stage) 사이를 넘어갈 때마다 활성화 값 (Activation)이 네트워크를 통해 전달된다. 데이터 센터 내의 고속 링크라면 모를까, 일반적인 LAN이나 Wi-Fi를 거치게 되면 토큰 생성 레이턴시 (Latency)는 노드 수에 비례하여 정직하게 늘어난다. "한 대에 올릴 수 없는 거대 모델을, 느리더라도 일단 실행해보고 싶다"는 검증 용도에는 적합하지만, 대화 응답 속도를 요구하는 실서비스 용도와는 목적이 다르다.

그럼에도 불구하고, 유휴 GPU를 보유한 팀이 추가 비용 없이 단일 API 뒤에 대형 모델을 세울 수 있다는 가치는 매우 크다. Apache-2.0 라이선스이므로 상업적·개인적 이용에 제약이 없다. 우선 수중에 있는 2~3대의 머신을 프라이빗 메쉬로 묶고, 평소에는 올릴 수 없었던 크기의 모델이 어디까지 실용성을 갖추는지 --join <token>으로 폐쇄된 환경에서 측정해보는 것이 좋은 시작점이 될 것이다.