레딧 개발자, 로컬 LLM 여러 개 자동 전환하는 '언스웜' 공개

여기에 API 키를 설정하고 클로드 코드나 코덱스 같은 코딩 하네스에 언스웜을 하나의 제공자(provider)로 등록하면, 실제로는 여러 런타임이 따로 떠 있어도 마치 모든 모델이 동시에 서비스되는 것처럼 프록시가 처리해요. 하네스에서 모델을 골라 메시지를 보내면 요청이 큐에 들어가고, 해당 런타임이 꺼져 있으면 언스웜이 자동으로 켜서 응답을 스트리밍으로 돌려줘요.

Atretador는 언스웜이 이미 잘 작동하는 걸 관리하는 도구일 뿐, 모델 자체를 튜닝하는 플랫폼은 아니라고 선을 그었어요. 또 세션 도중 모델을 전환하면 캐시 히트율이 떨어지는 건 피할 수 없는 부작용이라고 밝혔어요.

어떻게 써보나

언스웜은 github.com/atretador/unswarm 저장소에서 코드를 받아 직접 셀프호스팅하는 방식으로 시작해요.

1. 자신이 쓰는 컨테이너나 bash 런타임 스크립트를 언스웜에 하나씩 등록해요.
2. 어떤 런타임들이 동시에 실행될 수 있는지 규칙을 설정해요. VRAM이 한정된 환경에서는 특정 조합만 함께 돌리도록 제한할 수 있어요.
3. API 키를 발급하고, 사용 중인 코딩 하네스(예: 클로드 코드, 코덱스)에 언스웜을 provider로 등록해요.
4. 하네스에서 원하는 모델을 선택해 메시지를 보내면 요청이 큐에 들어가고, 필요한 런타임이 꺼져 있으면 자동으로 기동해 응답을 스트리밍해요.

이 도구는 개인 컴퓨터뿐 아니라 VPS(가상 사설 서버)에 올려 어디서든 자신의 모델에 접속하는 용도로도 쓸 수 있고, 에이전트별로 서로 다른 머신에 배치해 병렬로 실행하는 구성도 지원해요.

예시로 보는 멀티 에이전트 구성

Atretador는 24GB와 16GB 그래픽카드를 함께 쓰는 상황을 예로 들어, 언스웜으로 어떤 조합을 짤 수 있는지 보여줬어요.

그룹	역할	모델 예시	실행 방식
그룹 1	오케스트레이터	Qwen 3.8 27B A3B	항상 실행
그룹 2	코드베이스 탐색	Qwen 3.5 9B	필요할 때 전환
그룹 2	실행기	Qwen 3.6 35B A3B	필요할 때 전환
그룹 2	디자이너	별도 파인튜닝 모델	필요할 때 전환

전체 작업을 지휘하는 오케스트레이터는 계속 켜 두고, 코드 탐색·실행·디자인처럼 상황에 따라 바뀌는 서브에이전트는 필요할 때만 불러오는 구조예요. VRAM이 넉넉하지 않은 환경에서 여러 역할을 나눠 굴리려는 사람들에게는 참고할 만한 배치예요.

에디터의 시선

언스웜을 보면서 드는 생각은, 로컬 LLM 생태계의 고민이 이제 '어떤 모델을 쓰느냐'에서 '여러 모델을 어떻게 같이 굴리느냐'로 옮겨가고 있다는 점이에요. Ollama나 vLLM 같은 러너들은 각자 자기 방식으로 모델 하나를 잘 서빙하는 데 집중해 왔어요. 정작 여러 러너와 컨테이너를 동시에 쓰는 사람들을 위한 오케스트레이션 레이어는 회사가 아니라 이번처럼 개인 개발자가 필요에 의해 직접 채워 넣는 경우가 많아요.

8GB~24GB급 중고 서버 GPU를 여러 장 꽂아 로컬 LLM을 굴려본 사람이라면 이 답답함을 알 거예요. 모델 하나 바꾸려고 컨테이너를 내리고 올리는 작업을 매번 손으로 반복하다 보면, 정작 모델 성능보다 운영 스크립트에 쓰는 시간이 더 길어지는 순간이 와요. 언스웜은 그 반복 작업을 규칙과 큐로 대신 처리해주는 얇은 층 하나를 얹은 셈이에요.

사내에서 자체 서버에 LLM 여러 개를 띄워 테스트하는 팀이라면, 이런 프록시 계층은 API 게이트웨이 하나를 두는 것과 비슷한 효과를 낼 수 있어요. 다만 캐시 히트율 손실은 숫자로만 보면 사소해 보여도 실제 워크로드에서는 응답 지연으로 바로 드러나요. 그러니 자주 바뀌는 서브에이전트와 계속 떠 있어야 하는 오케스트레이터를 미리 나눠 설계하는 게, 이 도구를 붙이기 전에 먼저 해둬야 할 작업이에요.

앞으로 몇 주 안에는 이런 개인 프로젝트가 Ollama·vLLM 같은 주류 러너의 공식 기능으로 흡수되거나, 반대로 커뮤니티 포크가 늘어나면서 AMD 구형 카드 같은 특정 하드웨어 지원을 넓혀가는 흐름이 이어질 가능성이 커요.