Mesh LLM - iroh 기반 분산 AI 컴퓨팅

 (iroh.computer)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 여러 머신에 흩어진 GPU와 메모리를 하나의 컴퓨팅 자원으로 묶어, 로컬 실행·피어 전달·분할 실행을 OpenAI 호환 API 하나로 제공함
  • 요청은 로컬 GPU나 모델을 적재한 피어에서 처리되며, 한 머신에 들어가지 않는 모델은 여러 노드에 파이프라인 단계로 나눠 실행할 수 있음
  • 플러그인 기반 카탈로그에는 노트북용 5억 파라미터 모델부터 235B MoE 모델까지 40개 이상이 포함되며, 클라이언트는 내부 배치와 관계없이 localhost:9337/v1만 호출함
  • 각 노드는 공개키를 ID이자 유일한 네트워크 표면으로 쓰는 iroh 엔드포인트를 실행하고, 중앙 서버 없이 NAT 통과·홀 펀칭·릴레이 대체 경로를 거쳐 인증된 QUIC 연결을 구성함
  • 약 18MB 소프트웨어로 공개 메시나 사설 배포를 구성할 수 있으며, 향후 iroh Swift SDK와 ACP를 지원하는 모바일 앱을 통해 폐쇄형 서버 의존도를 낮출 계획임

외부 데이터센터 대신 기존 하드웨어 활용

  • 일반적인 LLM 이용 방식은 외부 사업자의 GPU 데이터센터와 사용량 기반 API에 의존하므로, 사용량이 늘수록 비용도 커짐
  • 외부 서비스로 프롬프트를 보내면 사용자가 다음 요소를 직접 통제하기 어려움
    • 모델 업데이트 시점
    • 데이터가 전달되는 위치
    • 모델이 사용하는 메모리와 기반 하드웨어
    • 가격과 개인정보 처리 정책의 변경
  • 사무실·창고·책상 아래에 이미 GPU를 보유한 기업과 서비스에는 여러 머신을 하나의 컴퓨팅 자원처럼 활용할 수단이 필요함
  • Mesh LLM은 보유한 GPU와 메모리를 원하는 수의 머신에 걸쳐 묶어 더 큰 모델을 실행하고, 연산 자원을 팀 내부에서 비공개로 또는 외부와 공개적으로 공유하도록 설계됨

요청을 처리하는 세 가지 경로

  • 표준 OpenAI 클라이언트에서 http://localhost:9337/v1을 호출하면 메시가 요청의 실제 실행 위치를 결정함
  • 요청은 다음 세 경로 가운데 하나로 처리됨
    • 현재 머신의 로컬 GPU에서 모델 실행
    • 필요한 모델을 이미 적재한 피어로 요청 전달
    • 한 머신에 들어가지 않는 모델을 여러 머신에 걸쳐 파이프라인 방식으로 분할
  • 사용자는 노드 하나로 시작해 필요할 때 더 추가할 수 있으며, OpenAI 클라이언트는 내부 라우팅이나 분할 실행 방식을 알 필요가 없음

플러그인 구조와 모델 카탈로그

  • 플러그인은 매니페스트에서 제공 기능을 선언하고, 런타임은 이를 시작해 호출을 라우팅함
  • 각 플러그인의 기능은 MCP·HTTP·추론·메시 이벤트를 통해 노출됨
  • 기본 카탈로그에는 40개 이상의 모델이 포함됨
    • 노트북에서 실행할 수 있는 약 5억 파라미터 모델
    • 최대 235B 규모의 전문가 혼합(Mixture-of-Experts) 모델

Skippy 분할 실행

  • 대형 모델을 위한 분할 모드는 내부적으로 Skippy라고 부름
  • 모델의 계층 범위를 단계별로 나눠 각 노드에 배치함
    • 한 노드가 계층 0~15를 담당
    • 다음 노드가 계층 16~31을 담당
    • 이후 계층도 같은 방식으로 파이프라인 끝까지 분배
  • 한 단계에서 생성된 활성값(activation) 이 다음 단계로 전달되므로, 개별 머신에는 들어가지 않는 모델도 여러 중간급 머신을 결합해 실행할 수 있음
  • 분할 과정은 OpenAI 클라이언트에 드러나지 않으며, 클라이언트는 계속 로컬 엔드포인트만 호출함

iroh 기반 P2P 네트워크

  • 모델을 제공하는 노드와 요청만 보내는 노드 모두 iroh 엔드포인트를 시작함
  • 엔드포인트는 세 가지 역할을 맡음
    • 노드의 ID
    • 공개키
    • 노드가 외부에 노출하는 유일한 네트워크 표면
  • iroh는 중앙 서버 없이 홀 펀칭, NAT 통과, 릴레이 대체 경로를 처리해 서로 다른 위치의 노드 사이에 직접적이고 인증된 QUIC 연결을 구성함
  • 직접 연결할 수 없는 노드를 위해 서로 다른 지역에서 iroh 릴레이 2개를 운영하며 가까운 대체 경로를 제공함
  • 공개키로 머신을 지정하고 인증된 NAT 통과 QUIC를 사용할 수 있어, 피어로 요청을 전달하거나 다음 파이프라인 단계로 활성값을 보내는 작업이 엔드포인트 ID만 다른 동일한 통신 기본 요소로 처리됨

QUIC ALPN으로 프로토콜 구분

  • 전체 프로토콜은 QUIC의 ALPN 협상을 사용하며 용도에 따라 세 가지로 나뉨
    • mesh-llm/1: 가십, 라우팅, HTTP 터널, 플러그인 채널을 포함한 기본 메시
    • mesh-llm-control/1: 설정 동기화와 소유권 증명을 담당하는 소유자 제어 평면
    • skippy-stage/2: 분할 모델에서 지연 시간에 민감한 활성값 전송
  • mesh-llm/1 연결에서는 모든 작업이 양방향 QUIC 스트림으로 전달되며, 스트림의 첫 번째 바이트가 유형을 식별함
    • 0x01 GOSSIP: 모델, GPU, RTT, 기능을 포함한 피어 공지
    • 0x04 TUNNEL_HTTP: 피어로 프록시되는 추론 요청
    • 0x05 ROUTE_REQUEST: 피어가 호스팅하는 모델 조회
    • 0x06 PEER_DOWN: 연결이 끊긴 피어 알림
    • 0x07 PEER_LEAVING: 정상 종료 알림
    • 0x08 PLUGIN_CHANNEL: 플러그인 RPC
    • 0x0e DIRECT_PATH_REQUEST: NAT 통과를 위한 직접 주소 공유
  • 하나의 연결에서 가십, 추론, 경로 조회, 피어 수명주기 이벤트를 처리하고, 선행 바이트로 각 스트림을 역다중화함

보안 전송과 메시 제어의 분리

  • iroh는 머신 사이의 보안 전송 계층을 제공함
  • Mesh LLM은 그 위에 자체 가십 계층을 구축해 다음 정책을 직접 통제함
    • 메시 참여를 허용할 대상
    • 호환 가능한 버전
    • 신뢰할 피어

설치와 향후 지원

  • 약 18MB의 경량 소프트웨어를 설치해 공개 메시에 참여하거나 사설 배포를 구성할 수 있음
  • 표준 OpenAI 클라이언트에는 localhost:9337/v1 엔드포인트로 노출됨
  • iroh Swift SDK로 모바일 앱을 개발할 계획이며, 다른 클라이언트도 메시에 참여할 수 있도록 새로운 에이전트 표준인 ACP 지원을 준비함
  • 프로젝트는 P2P 활용을 늘리고 폐쇄형 서버와 종속성을 줄이는 것을 지향함
  • 소스 코드와 Mesh LLM 웹사이트에서 프로젝트를 확인할 수 있음

iroh 네트워킹 라이브러리

  • iroh는 장치 간 연결을 제공하는 오픈소스 네트워킹 라이브러리로, 준비된 프로토콜을 조합하거나 단순한 통신 추상화 위에 사용자 정의 프로토콜을 구성할 수 있음
  • 이미 프로덕션 환경의 수십만 대 장치에서 실행되고 있음
  • 문서, 소스 코드, Discord 채널을 제공함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 첫 이미지의 GPU 장비, 노트북, 서버, 클라우드 노드 등을 보니 내가 가진 연산 자원이 얼마나 적은지 실감했다. 24GB VRAM 노트북이나 96GB 워크스테이션도 없고, 친구들의 게이밍 PC를 모두 동원해 LLM을 실행해도 사진 속 총 VRAM에는 못 미칠 듯하다
    글에서 공개 메시 네트워크도 소개했지만 자세한 정보는 찾지 못했다

  • 성능 정보가 부족한 점이 눈에 띈다. 시스템 RAM이나 디스크 스트리밍을 포함해 다른 어떤 대형 모델 실행 방식보다 훨씬 느릴 것이라 예상했다. 소비자용 네트워크는 10Gbps 이더넷조차 로컬 RAM이나 디스크에 비하면 매우 느리니, 분할 모델이 초당 1토큰이나 그 이하인지 궁금했다
    모델 목록을 보니 Qwen 235B A22B가 “2개 노드에서 16 tok/s로 검증된 MoE 235B/22B”라고 되어 있었다. 노드 사양과 네트워크 연결은 공개하지 않았지만 꽤 준수한 속도이며, 대화형으로 편안한 수준에는 약간 못 미쳐도 상당히 근접한다

    • 반드시 더 느린 것은 아니며, 오히려 그렇지 않은 구성도 많을 듯하다. 가중치를 RAM이나 NVMe로 오프로딩하면 토큰마다 각 계층을 처리할 때 거대한 가중치를 느린 저장장치에서 GPU로 옮겨야 하므로 DRAM 대역폭이나 디스크 읽기 속도가 병목이 된다
      분산 구성에서는 각 장비의 VRAM에 가중치가 남아 있어 훨씬 빠른 GPU 메모리 대역폭을 활용한다. 장치 간에 넘기는 계층 출력은 기가바이트급 가중치가 아니라 킬로바이트급이므로 네트워크 처리량이 병목이 되지는 않는다
      실제 제약은 네트워크 지연 시간이다. 모델을 4개 장치로 나누면 토큰마다 네트워크 지연이 세 번 발생하며, 지연 시간이 1ms라면 토큰당 3ms가 추가된다. 연산 시간이 0이라고 가정해도 추측 디코딩 없이 이론상 최대 속도는 약 30 tok/s다
      인터넷에서는 지연 시간이 너무 커 실용적이지 않을 가능성이 높지만, 로컬·기업 네트워크에서 추측 디코딩을 사용하면 충분히 가능하다. 프리필이나 프롬프트 처리에서는 지연 시간이 누적되지 않으므로 분산 구성이 거의 확실히 더 빠르다
    • 내 홈 랩에서 장비 간 5ms 지연과 지터를 모의해 측정했다. 분할 실행은 대도시권 수준의 WAN 지연에서는 꽤 잘 작동하지만 전 세계 WAN에서는 그다지 빠르지 않다
      전용 RDMA나 NVLink 패브릭이 없는 여러 장비를 묶어 소유한 하드웨어로 대형 모델을 제공하고 다른 사람과 공유하는 것이 목표다. 현재 같은 분할 구성에서 GLM 5.2를 약 10 tok/s로 실행하는 작업을 진행 중이다
    • 성능은 비교적 간단히 어림잡을 수 있다. 자기회귀 디코딩에서는 토큰마다 대략 2 × hidden_size × num_shards바이트를 네트워크로 전송해야 하며, 프리필에서는 이 값을 청크 크기로 나누면 된다
    • AMD Ryzen AI 9 HX 370이 탑재된 Framework 13에서 Qwen3.6-35B-A3B를 실행할 때 내가 얻는 속도와 비슷하다. 훨씬 큰 모델에서도 같은 속도가 나온다면 인상적이다

  • 코딩용 LLM보다 목적에 맞게 만든 소형 언어 모델의 분산 추론에 더 관심이 간다. 이미지 처리, 소프트웨어 정의 라디오(SDR), 지역 날씨 관측 등에 활용하면 평범한 사양에서도 실행되면서 신뢰할 만한 출력을 낼 수 있다

    • 활성 전문가 X개를 둔 모델 하나 대신, 특정 정보로 학습한 작고 밀집된 서로 다른 모델 10개를 서버 10대에 올리고 라우터 하나로 연결하는 구성이 적합해 보인다

  • Mesh LLM 기여자이며, 대형 모델을 여러 노드로 분할할 수 있게 해주는 skippy 엔진을 만들었다. 질문이 있다면 답하겠다

    • IPFS 관련 기술이 다시 등장해 반갑다. 두 가지가 궁금하다
      첫째, 이런 식으로 연산을 분산하면 연산 그래프의 모든 참여자가 처리 중인 시퀀스를 알게 되는데 개인정보 보호를 어떻게 처리하는가? 둘째, 악의적인 참여자가 모델 활성값을 오염시키지 못하게 하는 보호 장치가 있는가?
    • 공개 메시 참여 유인이 무엇인지 궁금하다. 특정 모델 실행에 필요한 VRAM의 1/8을 제공하면 적어도 추론 사용량의 1/16을 받는 식의 공정성 보장이 있는가?
    • 며칠 전 공개된 Colibri 프로젝트와 통합하면 이점이 있을까?
    • KV 캐시 구현을 깊이 살펴본 적이 없는데, 계층별로 사실상 독립된 캐시를 운용하는지 궁금하다
      그렇다면 연산량과 데이터 크기 측면에서 깔끔하게 분할되고, 각 계층이 차례를 기다리는 시간만 느려질 듯하다. 파이프라인을 구성하면 여러 질의를 동시에 실행할 수도 있다
      질의를 한 단계씩 어긋나게 투입하는 N단계 파이프라인으로 best-of-N을 구현한 사례가 있는가?
    • 서로 다른 EPYC 프로세서와 모델이 많은 연구실을 운영하는데, 이를 이런 방식으로 하나로 묶을 수 있다는 점이 인상적이다

  • 비슷한 분산 컴퓨팅 방식의 LLM을 찾다가 AI Horde, Aphrodite 쪽의 소규모 시도, Nous Research의 분산 학습 등을 발견했다
    이 가운데 AI Horde가 가장 큰 듯하다. API는 채팅 완성이 아닌 KoboldCPP 텍스트 완성 형식을 사용한다. 더 많은 조절 변수를 노출해 역할극에서 결과가 좋아지므로 커뮤니티의 활발한 구성원들이 이 방식을 강하게 선호하는 듯하다. 다른 용도는 대부분 도구 호출이 필요할 테니 역할극 외에 어디에 쓸 수 있을지는 잘 모르겠다
    이번 주에는 채팅 템플릿과 응답 파싱을 지원하도록 OpenAI 브리지를 개선하기 시작했다. 공식 배포에 성공하면 역할극 모델을 써야 하더라도 코딩에 활용할 수 있을 것이다
    악용 방지 장치도 더 충실하다. 조직적인 공격을 막기 위해 작업자는 누적 가동 시간 1주를 채워야 신뢰 대상으로 인정되며, 사용자는 신뢰된 작업자만 선택할 수 있다. 작업자를 운영하면 kudos를 얻어 최대 512토큰을 넘는 생성에 사용할 수 있고, 무료 요청은 대기열 맨 뒤로 밀린다

  • 하나 이상의 분산 LLM을 실행하는 다형성 봇넷이 무엇을 할 수 있을지 궁금했다. 봇넷의 모든 호스트를 클러스터 연산 자원으로 활용해 LLM을 돌리고, 각 봇넷 클러스터의 전파 방식과 페이로드가 진화하도록 이끄는 구상이다
    나쁜 변종은 탐지돼 제거되고 효과 없는 전파 방식은 퍼지지 않지만, 가장 우수한 버전은 살아남아 계속 성장한다. 여기 소개된 구조와 상당히 비슷하며, QUIC은 매우 동적으로 작동해 생각보다 탐지하기 어려울 수 있다

  • https://query.mt/ 프로젝트는 한동안 iroh 기반 메시를 사용해 왔다. 메시 모델을 휴대전화에서도 쓰고 싶다면 시도해볼 만하다

  • mesh-llm을 실행하려고 한동안 씨름했지만, 설치 가능한 llama.cpp 빌드 가운데 내 구형 GPU에서 작동하는 것이 없었다. 외부 llama.cpp 서비스를 프록시할 수 있어 보였지만 그 설정도 성공하지 못했다
    매우 흥미로운 프로젝트지만 아직 다듬어지지 않은 부분이 꽤 있다

    • 버그 보고서를 보내주면 작동하도록 함께 해결해보고 싶다

  • 이 방식이 가능하리라 생각해 약 1년 전 ChatGPT에 물었지만, 지연 시간이 너무 커 불가능하다는 답을 받았다. 당시 거의 1년 동안 libp2p를 공부하며 활용할 프로젝트를 찾고 있었다

답변달기