Llama-Swap: 로컬 LLM의 가장 짜증 나는 문제를 해결해 드립니다

BBetter Stack
Computing/SoftwareConsumer ElectronicsInternet Technology

Transcript

00:00:00로컬 모델 설정은 다른 모델이 필요하기 전까지는 아주 잘 작동합니다.
00:00:04하지만 이제 llama 서버를 끄고, 포트를 바꾸고, OpenAI 베이스 URL을 업데이트하고,
00:00:10재로딩을 기다리며 아무 문제가 없기를 기도해야 하죠.
00:00:13코딩 모델은 가벼운 채팅을 하기엔 너무 크고, 작은 모델은 실제 코딩을 하기엔
00:00:18너무 멍청하기 때문입니다.
00:00:19LlamaSwap이 이 문제를 해결해 줍니다.
00:00:21하나의 엔드포인트로 여러 모델을 자동 교체하며, 도구들은 변경 사항을 전혀 모릅니다.
00:00:26앞으로 몇 분 안에 이 설정을 어떻게 하는지 보여드리겠습니다.
00:00:34대부분의 로컬 LLM 개발자들은 결국 같은 벽에 부딪힙니다.
00:00:37처음에는 llama나 lmstudio처럼 편리하고 그냥 잘 작동하는 것을 사용합니다.
00:00:44실제로 잘 작동하니까요.
00:00:45솔직히 그 도구들이 많이 좋아졌기 때문에 아주 훌륭합니다.
00:00:48하지만 그러다 보면 더 많은 제어권을 원하게 됩니다.
00:00:51정확한 llama CPP 플래그, GPU 레이어 배치, 컨텍스트 크기, 커스텀 백엔드,
00:00:59심지어 실험적인 모델까지 사용하고 싶어지죠.
00:01:01그래서 순정 llama 서버에 가까워지면 기분이 아주 좋아집니다.
00:01:06단지 하나의 문제를 다른 문제와 맞바꿨다는 사실을 깨닫기 전까지는요.
00:01:09이제 이런 일을 하게 됩니다.
00:01:11llama 서버를 끄고 QuinCoder를 실행합니다. 그러고 5분 뒤에 또 뭘 하고 있나요?
00:01:16또 뭘 하고 계신가요?
00:01:17다시 llama 서버를 죽이고 있죠.
00:01:18모델 사이를 계속 왔다 갔다 하는 겁니다.
00:01:20그럴 때마다 무언가 대기하거나, 재연결에 실패하거나, 아니면 엉뚱한 모델을
00:01:26조용히 사용하게 됩니다.
00:01:27그래서 실제로 하고 싶은 것은 앞에 엔드포인트 하나를 두고,
00:01:31뒤에서 원하는 모델을 교체하는 것입니다.
00:01:33그 공백을 llama swap이 채워줍니다.
00:01:36워크플로우 속도를 높여주는 코딩 도구를 좋아하신다면 구독해 주세요.
00:01:39관련 영상이 계속 올라올 예정입니다.
00:01:41이제 설명하기 전에 어떻게 작동하는지 보여드리겠습니다.
00:01:44지금 llama swap이 로컬의 한 포트에서 실행 중입니다.
00:01:48제 클라이언트는 이 베이스 URL만 알 뿐, Quin용, small LM용, 또는
00:01:55임베딩용 URL을 따로 알 필요가 없습니다. 정문은 하나뿐이죠.
00:01:58여기 두 모델이 포함된 작은 설정 파일이 있습니다.
00:02:02하나는 QuinCoder이고, 다른 하나는 small LM2입니다.
00:02:06각각 고유의 명령어를 가지고 있고,
00:02:09각자의 모델 파일이 있으며,
00:02:11각자의 컨텍스트 크기가 설정되어 있습니다.
00:02:14이 둘의 또 다른 차이점은 각각 고유의 TTL(유효 시간)을 가진다는 점입니다.
00:02:19이제 코딩 모델에 무언가를 요청해 보겠습니다.
00:02:22일반적인 OpenAI 스타일의 채팅 요청을 보냅니다.
00:02:25모델 필드에 QuinCoder라고 되어 있네요. 좋습니다.
00:02:30로그를 살펴봅시다.
00:02:32백엔드가 안정될 때까지 기다렸다가 요청을 보냅니다.
00:02:36여기서 중요한 점은 이겁니다.
00:02:39URL을 변경하지 않았다는 거죠.
00:02:41open web UI를 재시작하지도 않았고,
00:02:43커서(Cursor) 설정을 편집하지도 않았습니다.
00:02:46필드 딱 하나만 바꿨습니다.
00:02:48모델이 QuinCoder에서 small LM2로 바뀌었지만, 엔드포인트와 클라이언트는 그대로고 모델만 달라졌습니다.
00:02:55모델이 TTL 이상 유휴 상태로 있으면, llama swap이 이를 내려서(unload) VRAM을 확보합니다.
00:02:59그게 전부입니다.
00:03:00이게 핵심 비결이죠.
00:03:02도구들은 하나의 API와 통신하고 있다고 생각합니다.
00:03:04llama swap은 보이지 않는 곳에서 복잡한 제어 작업을 모두 처리해 줍니다.
00:03:09어떻게 진행되는지 정말로 제어하는 것이죠.
00:03:10네, 좋습니다.
00:03:11그럼 llama swap이란 무엇일까요?
00:03:12방금 시연해 드린 것과 같습니다.
00:03:13로컬 모델들을 위한 허브라고 생각하시면 됩니다.
00:03:16앱이 모든 모델 서버와 직접 통신하지 않고,
00:03:19llama swap과 통신합니다.
00:03:21그러면 llama swap이 모델 필드를 보고 어떻게 처리할지 결정합니다.
00:03:25모델이 이미 실행 중이라면 요청을 그대로 전달합니다.
00:03:28모델이 실행 중이 아니라면 모델을 시작하고 요청을 보냅니다.
00:03:31다른 모델이 비켜줘야 한다면 그 모델을 중단시킵니다.
00:03:35그러고 나면 클라이언트는 정상적인 응답을 받게 됩니다.
00:03:38따라서 10분마다 베이스 URL을 바꿀 필요가 없습니다.
00:03:41하나의 바이너리, 하나의 설정 파일, 하나의 안정적인 API 엔드포인트만 있으면 됩니다.
00:03:45Go 언어로 제작되었으며 YAML 설정을 사용합니다.
00:03:48OpenAI 및 Anthropic 호환 API의 프록시 역할을 하며,
00:03:53llama cpp, vllm, tabby API 등의 백엔드 앞에서 작동할 수 있습니다.
00:03:59운이 좋다면 디스크에 10개나 20개의 모델이 있을 수도 있겠지만, VRAM은 한두 개를
00:04:05로드할 수 있을 만큼만 있을 겁니다.
00:04:06그럴 때 TTL이 도움이 됩니다.
00:04:08모델이 충분히 오래 유휴 상태라면 llama swap이 이를 언로드할 수 있습니다.
00:04:11사용하지 않는 모델이 GPU 메모리를 점유하고 있는 대신,
00:04:17다음 요청을 위해 메모리를 비워줄 수 있습니다.
00:04:20전에는 무엇이 실행 중인지 기억해야 했습니다.
00:04:23이제는 설정 파일이 대신 기억해 줍니다.
00:04:25여기서 당연한 질문은 '왜 그냥 llama나 LM Studios, 혹은 순정 llama 서버를
00:04:31쓰지 않느냐'는 것입니다.
00:04:32답은, '그냥 그걸 쓰셔도 된다'입니다.
00:04:35llama swap이 항상 그것들을 대체하는 것은 아닙니다.
00:04:37매우 특정한 문제를 해결해 줄 뿐이죠.
00:04:40llama와 비교하면, llama swap은 모델 저장소나 다운로더, 초보자용 CLI가 아닙니다.
00:04:47그게 목적이 아니니까요.
00:04:49핵심은 제어권입니다.
00:04:50자신만의 llama cpp 빌드와 플래그를 가져오고, 각 모델이 실행되는
00:04:55방식을 정확히 결정할 수 있습니다.
00:04:57LM Studio와 비교하면 llama swap은 서버 중심적이며 GUI가 필요 없습니다.
00:05:02개발용 PC, 홈랩 서버, Docker 또는 안정적인 API가 필요한
00:05:07공용 머신에 더 적합합니다.
00:05:09'llama run llama 3'처럼 간단하지는 않습니다.
00:05:13직접 모델 파일이 있어야 하고,
00:05:15사용하는 백엔드에 대해 이해해야 하며,
00:05:17YAML 파일을 작성해야 합니다.
00:05:19자신의 GPU에 맞는 플래그가 무엇인지도 알아야 하죠.
00:05:22모든 것을 다운로드하고 구성해 주는 내장 모델 갤러리 같은 것도 없습니다.
00:05:26솔직히 말씀드리면 초기 설정은 상당히 번거롭습니다.
00:05:29하지만 어떤 개발자들에게는 이것이 아주 구체적인 고충을 해결해 줍니다.
00:05:32원하는 모델이 정확히 무엇인지 알면서도 매번 연결 설정을 바꾸느라
00:05:38시간을 낭비하는 그런 고충 말이죠.
00:05:39커서, 컨티뉴(Continue), 커스텀 에이전트, 로컬 스크립트 등을 사용하신다면 시도해 볼 가치가 있습니다.
00:05:44매우 유용하겠지만, 설정 과정은 좀 더 집약적일 것입니다.
00:05:47자, 이것이 llama swap입니다.
00:05:49하나의 안정적인 API 엔드포인트 뒤에 여러 로컬 모델, 자동 교체, 유휴 상태 언로드,
00:05:54그리고 완벽한 백엔드 제어까지 제공합니다.
00:05:56핵심 아이디어는 간단합니다.
00:05:58클라이언트가 실제 실행 중인 모델 서버가 무엇인지 신경 쓸 필요가 없게 하는 것이죠.
00:06:02llama swap이 그 모든 것을 대신 처리해 줍니다.
00:06:04이런 코딩 도구가 마음에 드신다면 구독해 주세요.
00:06:06그럼 다음 영상에서 뵙겠습니다.

Key Takeaway

Llama-Swap은 단일 API 엔드포인트와 YAML 설정을 통해 여러 로컬 LLM의 자동 로딩 및 유휴 상태 언로드를 처리함으로써 수동 서버 재시작과 URL 변경 번거로움을 제거합니다.

Highlights

  • Llama-Swap은 하나의 API 엔드포인트만으로 여러 로컬 LLM을 자동으로 교체하며 VRAM 자원을 관리합니다.

  • 모델 필드 값만 변경하면 API 베이스 URL이나 클라이언트 설정 수정 없이도 QwenCoder에서 SmallLM2로 즉시 전환할 수 있습니다.

  • Go 언어로 제작된 이 도구는 YAML 설정 파일을 통해 각 모델의 llama.cpp 플래그, GPU 레이어 배치, 컨텍스트 크기를 개별적으로 제어합니다.

  • 각 모델에 설정된 유휴 유효 시간(TTL)이 지나면 Llama-Swap이 자동으로 모델을 언로드하여 GPU 메모리를 확보합니다.

  • Llama-Swap은 OpenAI 및 Anthropic 호환 API 프록시 역할을 수행하며 llama.cpp, vLLM, Tabby API 등 다양한 백엔드를 지원합니다.

Timeline

로컬 LLM 워크플로우의 고질적인 불편함

  • 코딩용 대형 모델과 일반 채팅용 소형 모델을 교체할 때마다 서버를 수동으로 끄고 켜야 합니다.
  • 모델 교체 시 포트 변경, OpenAI 베이스 URL 업데이트, 재로딩 대기 과정에서 작업 흐름이 끊깁니다.
  • 정밀한 제어를 위해 순정 서버를 사용할수록 모델 간 전환 비용과 연결 실패 위험이 증가합니다.

대부분의 로컬 LLM 개발자는 편리한 도구에서 시작해 결국 더 세밀한 제어권을 원하는 단계에 도달합니다. 이 과정에서 특정 모델을 종료하고 다른 모델을 실행하는 반복적인 작업이 발생합니다. Llama-Swap은 클라이언트와 모델 서버 사이에 위치하여 이러한 수동 전환 과정을 자동화하는 해결책으로 작동합니다.

Llama-Swap의 작동 원리와 실무 시연

  • 클라이언트는 오직 하나의 로컬 포트와 베이스 URL만 참조하며 모든 모델 요청을 수신합니다.
  • YAML 설정 파일에는 각 모델의 실행 명령어, 모델 파일 경로, 컨텍스트 크기, TTL 값이 정의됩니다.
  • 모델 요청이 들어오면 백엔드가 안정될 때까지 기다린 후 요청을 전달하며 클라이언트는 변화를 인지하지 못합니다.

실제 시연에서 QwenCoder와 SmallLM2 두 가지 모델을 하나의 설정 파일로 관리하는 모습을 확인합니다. 사용자가 모델 필드 이름만 바꾸면 Llama-Swap이 보이지 않는 곳에서 기존 모델을 내리고 새 모델을 올리는 복잡한 제어 작업을 수행합니다. 이를 통해 Open WebUI나 Cursor 같은 도구의 설정을 매번 수정할 필요가 없어집니다.

기술 스택 및 주요 기능적 특징

  • Go 언어 바이너리와 YAML 설정 파일 하나로 구성된 경량 허브 구조를 가집니다.
  • 모델이 이미 실행 중이면 요청을 즉시 전달하고 미실행 시에는 다른 모델을 중단시킨 후 새로 시작합니다.
  • 제한된 VRAM 환경에서 10~20개의 모델을 보유하더라도 유휴 모델 자동 언로드 기능을 통해 효율적으로 운용합니다.

Llama-Swap은 단순한 프록시를 넘어 모델 서버의 생명주기를 직접 관리합니다. 사용하지 않는 모델이 GPU 메모리를 점유하지 않도록 TTL 기반의 언로드 전략을 사용합니다. 이는 사용자가 이전에 무엇을 실행했는지 기억할 필요 없이 설정 파일에 의존하여 시스템을 운영할 수 있게 합니다.

기존 도구와의 차이점 및 적합한 사용자층

  • 초보자용 모델 다운로더가 아니며 사용자가 직접 모델 파일과 GPU 플래그를 관리해야 합니다.
  • GUI가 없는 서버 중심 설계로 홈랩 서버, Docker 환경, 공용 머신 운영에 최적화되어 있습니다.
  • Cursor나 Continue 같은 코딩 에이전트를 사용하며 잦은 모델 교체가 필요한 개발자에게 유용합니다.

Ollama나 LM Studio가 제공하는 편의성 대신 완벽한 백엔드 제어권을 제공하는 것이 목적입니다. 초기 설정 과정에서 직접 YAML 파일을 작성하고 GPU에 맞는 플래그를 찾아야 하는 번거로움이 존재합니다. 하지만 특정 모델 조합을 빈번하게 오가며 시간을 낭비하는 숙련된 개발자에게는 매우 강력한 생산성 도구가 됩니다.

Community Posts

View all posts