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

> Clean Markdown view of GeekNews topic #31351. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=31351](https://news.hada.io/topic?id=31351)
- GeekNews Markdown: [https://news.hada.io/topic/31351.md](https://news.hada.io/topic/31351.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2026-07-12T21:33:54+09:00
- Updated: 2026-07-12T21:33:54+09:00
- Original source: [iroh.computer](https://www.iroh.computer/blog/mesh-llm)
- Points: 1
- Comments: 1

## Topic Body

- 여러 머신에 흩어진 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](https://meshllm.cloud)은 보유한 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 활용을 늘리고 폐쇄형 서버와 종속성을 줄이는 것을 지향함
- [소스 코드](https://github.com/Mesh-LLM/mesh-llm)와 [Mesh LLM 웹사이트](https://meshllm.cloud)에서 프로젝트를 확인할 수 있음

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

## Comments



### Comment 61662

- Author: neo
- Created: 2026-07-12T21:33:56+09:00
- Points: 1

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48876505) 
- 첫 이미지의 GPU 장비, 노트북, 서버, 클라우드 노드 등을 보니 내가 가진 **연산 자원이 얼마나 적은지** 실감했다. 24GB VRAM 노트북이나 96GB 워크스테이션도 없고, 친구들의 게이밍 PC를 모두 동원해 LLM을 실행해도 사진 속 총 VRAM에는 못 미칠 듯하다  
  글에서 **공개 메시 네트워크**도 소개했지만 자세한 정보는 찾지 못했다
  - 공개 메시 주소는 [https://public.meshllm.cloud/](<https://public.meshllm.cloud/>)다

- **성능 정보가 부족한 점**이 눈에 띈다. 시스템 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/](<https://query.mt/>) 프로젝트는 한동안 **iroh 기반 메시**를 사용해 왔다. 메시 모델을 휴대전화에서도 쓰고 싶다면 시도해볼 만하다

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

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