Mesh LLM, 사무실 GPU들을 묶어 하나의 오픈에이아이 호환 API처럼 쓰기

• Mesh LLM은 “LLM은 무조건 데이터센터 GPU에서 API로 호출한다”는 기본값을 뒤집는 프로젝트임

  • 사무실, 집, 랙, 미니 PC, 워크스테이션에 흩어진 GPU와 메모리를 하나의 풀처럼 묶음
  • 클라이언트 입장에서는 그냥 http://localhost:9337/v1에 붙는 오픈에이아이 호환 API처럼 보임
  • 내부에서 어느 머신이 계산하는지, 피어로 라우팅되는지, 여러 머신에 쪼개지는지는 런타임이 처리함

• 문제의식은 꽤 현실적임. AI를 많이 쓸수록 API 비용과 통제권 문제가 같이 커짐

  • 외부 LLM API를 쓰면 모델 변경 시점, 데이터가 가는 위치, 실제 하드웨어를 사용자가 통제하기 어려움
  • 사용량이 늘면 비용도 같이 늘고, 사용자가 당장 꺼낼 수 있는 레버는 “돈 더 내기”밖에 없음
  • 반대로 많은 팀은 이미 사내에 GPU가 있는데, 그 장비들을 하나의 계산 자원처럼 묶는 방법이 부족함

• Mesh LLM의 요청 처리 방식은 세 가지임

  • 현재 머신 GPU에서 바로 실행함
  • 해당 모델을 이미 메모리에 올린 피어에게 요청을 라우팅함
  • 한 장비에 안 들어가는 큰 모델은 여러 머신에 레이어 단위로 나눠 파이프라인으로 실행함

sequenceDiagram
    participant 클라이언트
    participant 로컬노드
    participant 피어노드
    participant 분할노드
    클라이언트->>로컬노드: 오픈에이아이 호환 요청
    로컬노드->>피어노드: 모델 보유 여부 질의
    피어노드-->>로컬노드: 실행 가능 응답
    로컬노드->>분할노드: 필요 시 레이어 구간 전달
    분할노드-->>로컬노드: 활성값 반환
    로컬노드-->>클라이언트: 응답 스트리밍

• 큰 모델을 쪼개는 split 모드가 특히 흥미로움
  • 내부 이름은 Skippy이고, 모델을 레이어 범위별 stage로 나눔
  • 예를 들어 015번 레이어는 한 노드, 1631번 레이어는 다음 노드가 맡는 식임
  • 활성값(activation)이 stage 사이를 흐르기 때문에, 여러 적당한 머신이 모여 어느 한 대도 혼자 못 돌리는 모델을 실행할 수 있음

• 네트워킹은 iroh가 맡음

  • 모든 노드는 iroh endpoint를 띄우고, 이 endpoint가 노드의 신원이자 공개키이자 유일한 네트워크 표면이 됨
  • 중앙 서버 없이 피어끼리 직접 연결하고, NAT 통과와 hole punching, relay fallback을 처리함
  • 직접 연결이 안 되는 경우를 위해 서로 다른 리전에 iroh relay 두 개를 둠

• 프로토콜은 QUIC의 ALPN 협상 위에 올라감

  • mesh-llm/1 연결 안에서 gossip, 추론, 라우팅 질의, 피어 생명주기 이벤트가 양방향 QUIC 스트림으로 섞여 흐름
  • 각 스트림은 첫 바이트로 타입을 구분해서 demux함
  • 덕분에 “다음 파이프라인 노드에 활성값 보내기”와 “로컬호스트에 말 걸기”가 거의 같은 네트워크 원시 연산처럼 취급됨

• 아키텍처는 플러그인 중심임

  • 플러그인은 manifest로 자신이 제공하는 기능을 선언함
  • 런타임은 플러그인을 시작하고, 호출을 라우팅하고, MCP·HTTP·inference·mesh event로 기능을 노출함
  • 모델 카탈로그는 40개 이상이고, 노트북에서 돌릴 수 있는 5억 파라미터급 모델부터 2350억 파라미터 Mixture-of-Experts 모델까지 포함함

• 방향성은 명확함. 닫힌 서버를 덜 쓰고, 피어투피어로 더 많이 돌리자는 것임

  • 설치 파일은 약 18MB로 가볍고, 공개 mesh에 참여하거나 사설 배포로 구성할 수 있음
  • 모바일 앱도 iroh Swift SDK 기반으로 준비 중임
  • 앞으로는 에이전트 표준으로 떠오르는 ACP도 지원해서 다른 클라이언트가 mesh에 붙을 수 있게 하려는 계획임

기술 맥락

• Mesh LLM이 고른 핵심 선택은 “분산 추론을 클라우드 스케줄러 문제가 아니라 피어투피어 네트워크 문제로 풀자”는 거예요. 왜냐하면 팀이 이미 가진 GPU를 재활용하려면, 서로 다른 장소와 NAT 뒤에 있는 장비들이 안정적으로 직접 통신해야 하거든요.

• iroh를 쓰는 이유는 여기서 꽤 분명해요. 공개키가 노드 신원이 되고, QUIC 연결이 인증과 전송을 동시에 맡아주면, Mesh LLM은 별도 중앙 서버나 복잡한 VPN 설정 없이 피어를 찾고 연결하는 쪽에 집중할 수 있어요.

• split 모드는 단순한 로드밸런싱이 아니에요. 모델 레이어를 여러 노드에 나누고 활성값을 순서대로 넘기는 구조라, 네트워크 지연과 노드 안정성이 바로 추론 성능에 영향을 줘요. 그래서 “여러 GPU를 묶는다”보다 “어떤 모델을 어떤 레이어 단위로 어디에 놓을지”가 더 중요한 문제가 돼요.

• 오픈에이아이 호환 API를 앞단에 둔 것도 현실적인 선택이에요. 기존 SDK와 도구를 거의 그대로 붙일 수 있어야 팀이 실험 비용을 낮출 수 있거든요. 내부는 mesh여도 외부 인터페이스는 익숙하게 유지하는 쪽을 택한 셈이에요.