GPU 없이도 돌아가는 P2P 스웜: Lumabri가 MoE 모델을 쪼개는 방식

거대 언어모델을 여러 대의 컴퓨터에 나눠 실행하는 시도는 새롭지 않다. Petals나 llama.cpp의 RPC 모드가 대표적이다. 그러나 이들은 트랜스포머의 연속된 레이어를 장치별로 잘라 배분하기 때문에, 각 조각이 충분히 빨라야 전체가 실용적인 속도를 낸다. 결국 각 노드에 GPU가 필요하다는 뜻이다. 순수 C로 작성돼 외부 의존성이 없는 Lumabri는 이 지점을 다르게 접근한다. 레이어가 아니라 '전문가(expert)' 단위로 모델을 쪼개, MoE(Mixture-of-Experts) 구조의 희소성을 그대로 활용하는 것이 핵심이다.

필요한 바이트만, 필요한 순간에

Lumabri의 동작 방식은 사전 다운로드가 없다는 점에서 출발한다. 모델을 가진 기계 한 대가 serve로 이를 공유하면, 다른 기계는 곧바로 대화를 시작할 수 있다. 추론이 실제로 건드리는 바이트만 최초 사용 시점에 피어로부터 도착하고, 이 바이트는 ~/.lumabri의 로컬 미러에 남는다. 그래서 두 번째 질문부터는 로컬 디스크에서 전속력으로 처리되며, 서버가 오프라인이 되더라도 미러는 계속 응답한다. 이 구조를 떠받치는 것이 liblumabri.so라는 LD_PRELOAD 심(shim)이다. 엔진이 모델 디렉터리에 사용하는 몇 안 되는 libc 호출(open, fopen, opendir, pread)만 가로채고, 파일은 실제 크기의 희소(sparse) 미러로 보이게 한다. 덕분에 fstat이나 페이지 캐시가 네이티브로 작동하며, FUSE도 별도 데몬도 읽기 경로에 끼어들지 않는다. 검증된 블록은 sha256 기준으로 콘텐츠 주소 저장소(CAS)에도 보관돼, 동일한 청크는 한 번만 내려받는다.

서버 측 serve는 두 개의 작은 프로그램으로 나뉜다. 누가 어떤 파일을 갖고 있는지에 대한 색인일 뿐인 트래커(tracker), 그리고 모델 디렉터리에 대한 바이트 범위 읽기에 응답하는 메인테이너(maintainer)다. 하나의 모델을 여러 메인테이너가 조각내어 나눠 가질 수 있다.

전문가 단위 분산과 4KB 활성값

MoE 모델에서 진짜 차별점이 드러난다. 대화를 실행하는 쪽(chatter)은 밀집 가중치와 라우터, KV 캐시만 보유하고, 라우팅된 각 전문가를 가진 피어에게 4KB 크기의 활성값(activation)만 전송한다. 전문가 가중치 자체는 chatter에 절대 도달하지 않는다. 전문가 하나만 들고 있어도 피어로서 쓸모가 있고, GPU가 하나도 없는 스웜도 정상 작동한다. 저자의 표현대로 GPU를 모으는 네트워크가 소수에서 자원을 징집한다면, Lumabri는 모두에게서 징집한다.

출력의 동일성은 이 설계의 전제다. 로컬 실행과 분산 실행이 같은 엔진 소스에서 빌드된 단일 코드 경로이므로 토큰이 비트 단위로 일치한다. 이를 담보하기 위해 각 피어는 엔진, 소스 해시, ISA, 컴파일러, 양자화 방식, 모델 루트까지 자신의 정확한 빌드를 광고하고, chatter는 빌드가 다른 피어에게는 활성값을 단 하나도 보내기 전에 거부한다. -march=native 재빌드가 마지막 비트를 바꿀 수 있고, 그런 일이 조용히 일어나선 안 되기 때문이다. 실제로 GLM 엔진은 라우팅된 여러 행을 한꺼번에 계산하는데, 피어에 한 행씩 넘겼더니 부동소수점 값이 달라져 네 번째 위치부터 토큰이 어긋난 버그가 이 비트 단위 대조 테스트로 발견됐다.

신뢰하지 않는 피어를 검증하는 법

Lumabri는 피어를 신뢰하지 않는다는 원칙 위에 서 있다. 메인테이너는 자신이 보유한 데이터의 MiB마다 sha256을 계산해 등록 시 함께 보내고, 원본 소유자는 오프라인에 보관한 ed25519 키로 그 진실에 서명한다. 트래커는 서명을 운반만 할 뿐 새로 만들어낼 수 없으므로, chatter는 자신이 직접 가진 키로 모든 블록을 검증한다. 거짓말하는 피어의 바이트는 거부되고 다른 곳에서 다시 받아온다. 원격 연산은 결과로만 검증할 수 있는데, LUMABRI_VERIFY=N 설정은 전문가 호출의 N퍼센트를 두 번째 복제본에서 재실행해 동일한 출력을 요구한다. 정직한 두 피어는 어긋날 수 없으니, 불일치는 곧 거짓의 증거이며 실행이 중단된다.

전송 보안도 준비돼 있다. 모든 노드에 LUMABRI_ENCRYPT=1을 켜면 X25519/Ed25519 핸드셰이크와 ChaCha20-Poly1305 프레임으로 토큰과 모델 블록, 활성값을 암호화한다. 키를 불러오거나 생성할 수 없으면 평문으로 대체되는 대신 네트워킹이 닫힌 상태로 실패한다. 엔드포인트 신원은 ~/.lumabri/peer.key에 보관되고, 최초 접속 시 중간자 공격을 막기 위한 핀(pin) 파일과 TOFU 방식을 함께 지원한다. 다만 엔드포인트 키와 모델 서명 키는 별개라는 점을 구분해야 한다.

실무자가 봐야 할 지점과 한계

속도 특성도 실용적이다. 서버가 전체 모델에 대한 전문가 노드를 함께 돌리므로 갓 만든 스웜도 첫날부터 작동하며, 나중에 합류한 기부자는 자신이 가장 가까운 호출을 가져간다. 속도는 가장 가까운 복제본이 결정한다. 같은 전문가가 2ms와 30ms에 각각 존재하면 실행 속도는 1.4tok/s가 아니라 10.5tok/s가 나온다. 응답 생성 도중 기부자 하나를 죽여도 실패 통지 한 줄과 함께 동일한 토큰이 이어진다.

그러나 이 프로젝트가 무엇이 아닌지도 분명히 해둘 필요가 있다. 저자는 자동 SLA 튜닝, 분산/S3 기반 CAS, KMS/HSM 통합, 자동 키 폐기 등을 의존성 없는 기본 구조에 일부러 포함하지 않았다고 밝힌다. 키 순환은 수동으로 구·신 키를 겹쳐 배포하는 방식이고, 이름 테이블 고갈을 막는 키·소스별 할당량은 어디까지나 접근 제어일 뿐 분산 시빌(Sybil) 공격을 해결한다고 주장하지 않는다. 전문가 연산은 운영자 서명이 아니라 복제본 간 합의로만 검증된다는 점도 신뢰 모델을 설계할 때 염두에 둬야 한다. 현 단계는 배포 가능한 작동 프로토타입이며, 리눅스와 gcc, GNU make 환경에서 colibri 빌드가 제공하는 엔진 바이너리를 전제로 한다. GPU 없이 유휴 CPU와 SSD를 그러모아 거대 MoE 모델을 돌려보려는 팀이라면, 최소한 접근 방식 자체를 검토할 가치는 충분하다.