로컬 LLM 서버가 재시작 없이 모델을 전환하는 방법은 무엇일까요?

서버는 요청 시 현재 모델을 해제하고 새로운 모델을 로드하는 동적 모델 로딩을 구현할 수 있으며, 이를 통해 프로세스를 재시작하지 않고도 원활하게 전환할 수 있습니다.

llama.cpp 는 여러 모델을 동시에 제공(serving)할 수 있나요?

Llama.cpp 는 여러 모델을 정의할 수 있지만, 일반적으로 각 워커마다 한 번에 하나의 모델만 메모리에 로드되며, 나머지는 필요 시에 로드됩니다.

llama.cpp 서버에서 라우터 모드는 무엇인가요?

라우터 모드는 들어오는 요청에 따라 단일 서버 인스턴스에서 모델을 동적으로 로드, 언로드 및 전환할 수 있도록 하는 기능입니다.

llama.cpp 와 Ollama 는 모델 관리 측면에서 어떻게 비교되나요?

Llama.cpp 는 저수준 제어와 동적 로딩을 제공하며, Ollama 는 내장 캐싱 및 생명주기 관리를 통해 더 완성도 높은 경험을 제공합니다.

llama.cpp 를 사용하여 모델을 자동으로 교체할 수 있는 도구는 무엇인가요?

llama-swap 와 같은 도구는 모델을 자동으로 로드하고 언로드할 수 있는 외부 오케스트레이션을 제공하여, 원시 llama.cpp 보다 더 높은 수준의 인터페이스를 제공합니다.

Llama-Server 라우터 모드 - 재시작 없이 동적 모델 전환

재시작 없이 LLM 을 제공하고 교체합니다.

Page content

오랫동안 llama.cpp 는 뚜렷한 한계가 있었습니다:
프로세스당 단 하나의 모델만 servir 할 수 있었고, 모델을 전환하려면 재시작이 필요했습니다.

그 시대는 끝났습니다.

최근 업데이트로 llama-server 에 라우터 모드 (router mode) 가 도입되면서 현대적인 로컬 L 런타임에서 기대하는 것에 훨씬 가까운 기능을 제공합니다:

동적 모델 로딩
필요 시 모델 언로딩
요청 단위의 전환
프로세스 재시작 불필요

llm router on the table

말하자면: Ollama 와 유사한 동작이지만, 훈련 바퀴 (training wheels) 없이입니다.

로컬 런타임, 클라우드 API, 자체 호스팅 인프라 중 어떤 것을 선택할지 고민 중이라면, LLM 호스팅 개요 가 좋은 시작점이 될 것입니다.

사전 요구사항

라우터 모드는 2024 년 중반 이후의 최신 llama-server 빌드가 필요합니다. 오래된 빌드에는 --models 플래그가 없습니다.

설치 옵션 (패키지 관리자, 사전 빌드 이진 파일, 또는 CUDA 를 포함한 전체 소스 빌드) 에 대해서는 llama.cpp 빠른 시작 를 참조하세요.

llama-server 를 확보한 후, 빌드가 라우터 모드를 지원하는지 확인합니다:

llama-server --help | grep -i models

--models 플래그가 나타나면 문제가 없습니다. 없으면 더 새로운 빌드로 업데이트하세요.

현재 저의 모델 관련 헬프 출력 내용입니다:

-cl,   --cache-list                     show list of models in cache
                                        Prefix/Suffix/Middle) as some models prefer this. (default: disabled)
                                        models with dynamic resolution (default: read from model)
                                        models with dynamic resolution (default: read from model)
                                        embedding models (default: disabled)
--models-dir PATH                       directory containing models for the router server (default: disabled)
                                        (env: LLAMA_ARG_MODELS_DIR)
--models-preset PATH                    path to INI file containing model presets for the router server
                                        (env: LLAMA_ARG_MODELS_PRESET)
--models-max N                          for router server, maximum number of models to load simultaneously
                                        (env: LLAMA_ARG_MODELS_MAX)
--models-autoload, --no-models-autoload
                                        for router server, whether to automatically load models (default:
                                        (env: LLAMA_ARG_MODELS_AUTOLOAD)

라우터 모드가 실제로 하는 일

라우터 모드는 llama-server 를 모델 디스패처로 만듭니다.

-m 을 통해 단일 모델에 바인딩하는 대신, 서버는 다음과 같은 동작을 수행합니다:

모델이 로드되지 않은 상태로 시작
모델 이름을 명시한 요청 수신
메모리에 없는 경우 해당 모델 로드
추론 실행
응답 후 모델 언로딩 또는 다음 요청을 위해 워밍업 유지

핵심 아이디어

이제 다음 명령을 실행하지 않습니다:

./llama-server -m model.gguf

대신 다음을 실행합니다:

./llama-server --models models.ini --port 8080

클라이언트가 실제로 요청하는 내용에 따라 서버가 무엇을 언제 로드할지 결정하도록 둡니다.

이는 하나의 지속 프로세스가 전체 모델 군단을 제공할 수 있음을 의미하며, 클라이언트가 작업마다 올바른 모델 (코딩 모델, 채팅 모델, 요약 모델 등) 을 선택할 수 있어 사용자 측의 조정 오버헤드가 없습니다.

설정: 모델 정의

여기서는 아직 기능이 조금 더 다듬어질 필요가 있습니다.

완전히 안정적인 공식 포맷은 아직 없지만, 최신 빌드는 INI 스타일 모델 정의를 설정 파일을 통해 지원합니다.

예시 models.ini

[llama3]
model = /opt/models/llama-3-8b-instruct.Q5_K_M.gguf
ctx-size = 8192
ngl = 35
threads = 8

[mistral]
model = /opt/models/mistral-7b-instruct-v0.3.Q4_K_M.gguf
ctx-size = 4096
ngl = 20
threads = 8

[qwen]
model = /opt/models/qwen2.5-coder-7b-instruct.Q5_K_M.gguf
ctx-size = 16384
ngl = 35
threads = 8

각 섹션 이름은 클라이언트가 API 요청의 "model" 필드에서 사용하는 모델 식별자가 됩니다.

주요 설정 파라미터

파라미터	제어 내용
`model`	GGUF 파일의 절대 경로
`ctx-size`	토큰 단위의 컨텍스트 윈도우 크기. 값이 클수록 VRAM 사용량 증가.
`ngl`	GPU 로 오프로딩되는 레이어 수. CPU 만 사용 시 `0` 으로 설정; VRAM 한도까지 증가.
`threads`	CPU 에 남아있는 레이어를 위한 CPU 스레드 수.

적절한 ngl 값을 선택하려면 GPU 의 사용 가능한 VRAM 에 따라 달라집니다. GPU 선택 및 하드웨어 경제학에 대해 컴퓨팅 하드웨어 가이드 가 유용한 참고 자료입니다. 값을 조정하며 실시간 VRAM 소비를 확인하려면 Linux 용 GPU 모니터링 도구 을 참조하세요.

설정과 함께 서버 시작

./llama-server --models /opt/llama.cpp/models.ini --port 8080

서버가 올바르게 시작되었는지 확인합니다:

curl http://localhost:8080/v1/models | jq '.data[].id'

models.ini 의 각 섹션 이름이 모델 ID 로 나열되어야 합니다.

안정성에 대한 참고 사항

INI 설정 인터페이스는 아직 발전 중입니다:

커밋 간 플래그가 변경될 수 있음
일부 파라미터는 특정 빌드 구성에서만 인식됨
문서가 구현에 뒤처지는 경우가 있음

재시작 시 재현성이 필요하면 특정 llama.cpp 커밋을 고정하세요.

API 사용: 요청 시 모델 전환

서버가 실행되면 모델 전환은 표준 OpenAI 호환 API 를 통해 이루어집니다. 단순히 "model" 필드를 설정하면 됩니다.

등록된 모델 목록 확인

curl http://localhost:8080/v1/models

생성 요청 — 첫 번째 모델

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3",
    "messages": [
      {"role": "user", "content": "Explain router mode in one paragraph"}
    ]
  }'

다른 모델로 전환 — 같은 엔드포인트, 같은 포트

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen",
    "messages": [
      {"role": "user", "content": "Write a Python function that reads a CSV file"}
    ]
  }'

서버는 언로딩/로딩 사이클을 투명하게 처리합니다. 클라이언트 코드는 변경되지 않으며 오직 model 필드만 바뀝니다.

Python 예시

openai Python 클라이언트를 사용하는 경우:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8080/v1", api_key="not-needed")

# 코딩 모델 사용
response = client.chat.completions.create(
    model="qwen",
    messages=[{"role": "user", "content": "Write a Go HTTP handler"}],
)
print(response.choices[0].message.content)

# 채팅 모델로 전환 — 같은 클라이언트, 다른 모델명
response = client.chat.completions.create(
    model="llama3",
    messages=[{"role": "user", "content": "What is the capital of Australia?"}],
)
print(response.choices[0].message.content)

내부에서 발생하는 일

qwen 에 대한 요청이 들어왔는데 현재 llama3 가 로드되어 있는 경우:

llama3 가 VRAM 에서 언로딩됨
qwen 가중치가 디스크에서 읽혀 VRAM 으로 로드됨
추론 실행
다음 요청이 qwen 을 유지할지 아니면 다시 교체할지 결정

이는 흔히 하는 질문에 대한 직접적인 답변입니다:

로컬 LLM 서버가 재시작 없이 모델을 어떻게 전환할 수 있는가?

시작 시 바인딩하지 않고 요청마다 모델을 동적으로 로드하기 때문입니다.

Systemd 서비스: 프로덕션 환경 설정

전용 사용자 및 디렉토리 생성

sudo useradd --system --shell /usr/sbin/nologin --home-dir /opt/llama.cpp llm
sudo mkdir -p /opt/llama.cpp/models
sudo chown -R llm:llm /opt/llama.cpp

이진 파일과 모델 설정을 지정 위치로 복사합니다:

sudo cp build/bin/llama-server /opt/llama.cpp/
sudo cp models.ini /opt/llama.cpp/

/etc/systemd/system/llama-server.service

[Unit]
Description=Llama.cpp Router Server
After=network.target

[Service]
Type=simple
User=llm
WorkingDirectory=/opt/llama.cpp
ExecStart=/opt/llama.cpp/llama-server --models /opt/llama.cpp/models.ini --port 8080
Restart=always
RestartSec=5

Environment=LLAMA_LOG_LEVEL=info

[Install]
WantedBy=multi-user.target

활성화 및 시작

sudo systemctl daemon-reload
sudo systemctl enable llama-server
sudo systemctl start llama-server

상태 확인 및 로그 조회

sudo systemctl status llama-server

journalctl -u llama-server -f

성공적으로 시작되면 서버가 리스닝 중이며 모델 레지스트리가 로드되었음을 나타내는 로그가 표시됩니다. 간단한 정상 확인:

curl -s http://localhost:8080/v1/models | jq '.data[].id'

이제 자동 재시작 및 중앙 집중식 모델 전환이 가능한 지속 서비스 환경이 구축되었습니다. 수동 프로세스 관리가 필요하지 않습니다. 동일한 패턴을 다른 이진 파일에 적용하고자 한다면, Linux 서비스로 실행 가능한 프로그램 호스팅 에서 일반적인 접근 방식을 안내합니다.

llama-server 의 --metrics 플래그는 Prometheus 호환 엔드포인트를 노출합니다. llama.cpp 전용 대시보드, PromQL 쿼리 및 알림 규칙에 대해서는 LLM 추론 모니터링 가이드 를 참조하세요. 더 넓은 가시성 (Observability) 설정에 대해서는 가시성 가이드 에서 전체 스택을 다룹니다.

이해해야 할 제한 사항

라우터 모드는 실제로 유용하지만, 프로덕션 환경에서 의존하기 전에 명확히 알아야 할 트레이드오프가 있습니다.

메모리에는 한 번에 하나의 모델만 존재

models.ini 에 여러 모델이 정의되어 있더라도, 작업자 (worker) 당 현재 VRAM 에 상주하는 모델은 한 번에 하나뿐입니다. 전환은 전체 언로딩 및 다시 로딩 사이클을 의미합니다.

전환 = 다시 로드
지연 시간 급증 불가피
일반적인 7B 모델 (Q5) 의 경우 디스크 속도와 VRAM 대역폭에 따라 3~10 초 소요

이는 또 다른 핵심 질문에 대한 답변입니다:

llama.cpp 는 동시에 여러 모델을 제공할 수 있는가?

그렇지는 않습니다. 동시 상주를 지원하지 않고 여러 정의를 지원합니다. 두 모델을 genuinely 병렬로 로드해야 하는 경우, 두 개의 별도 GPU 에 두 개의 프로세스가 필요합니다.

측정된 VRAM 소비량 및 토크스/초에 대한 모델 크기별 데이터는 LLM 성능 벤치마크 에서 전체 그림을 다룹니다. 16 GB GPU 에서 llama.cpp 에 대한 구체적인 수치 (다양한 컨텍스트 크기의 Dense 및 MoE 모델) 에 대해서는 16 GB VRAM llama.cpp 벤치마크 를 참조하세요.

스마트 캐싱 부재

Ollama 는 최근성에 따라 모델을 배출하면서 따뜻한 풀 (warm pool) 을 유지하는 반면:

자동 모델 배출 전략 없음
백그라운드 예열 없음
자주 사용되는 모델에 대한 우선순위 큐 없음

llama3 와 mistral 에 대해 번갈아 요청을 보내면, 모든 요청마다 다시 로딩이 발생합니다. 이는 금속 (metal) 에 더 가까워진 대가입니다.

혼합 워크로드의 지연시간 예측 불가

하나의 모델을 일관되게 사용하는 잘 행동하는 워크로드는 빠릅니다. 여러 모델을 번갈아 사용하는 워크로드는 느립니다. 클라이언트 라우팅 로직을 이에 맞게 계획하세요 — 가능한 경우 모델을 기준으로 요청을 그룹화하세요.

설정 안정성 미흡

INI 지원은 최신 빌드에서 작동하지만 완전히 표준화되지 않았습니다. 플래그와 파라미터 이름이 버전 간에 변경되었습니다. llama-server 를 업그레이드하면 배포 전 새 빌드와 models.ini 를 테스트하세요.

Llama.cpp vs Ollama: 솔직한 비교

기능	llama.cpp 라우터	Ollama
동적 로딩	지원	지원
모델 전환	지원	지원
내장 레지스트리	부분적 (INI)	지원 (pull 기반)
메모리 관리	기본	고급
모델 배출	없음	TTL 기반
UX 완성도	낮음	높음
OpenAI API 호환	지원	지원
제어	최대	의견 주도
설정 안정성	실험적	안정적

의견

다음과 같은 것을 원할 때 llama.cpp 라우터 모드를 선택하세요:

모델별 런타임 파라미터에 대한 최대 제어
최소 프로세스 오버헤드
추상화 레이어 없이 llama.cpp 플래그에 직접 접근
커스텀 도구를 위한 해킹 가능한 베이스

다음과 같은 것을 원할 때 Ollama 를 선택하세요:

안정적이고 다듬어진 경험
자동 모델 다운로드 및 버전 관리
설정 없이 스마트한 연결 유지 및 배출
시작부터 모든 것이 포함된 환경

둘 중 어느 쪽도 틀린 선택은 아닙니다. 선택은 스스로 관리하고 싶은 정도에 따라 달라집니다.

Ollama 를 선택한다면, Ollama CLI 치트시트 에서 일상적인 명령어를 다룹니다. vLLM, LM Studio, LocalAI 도 포함하는 더 폭넓은 비교는 2026 년 서로 다른 로컬 런타임 비교 를 참조하세요.

Llama.cpp vs llama-swap

llama-swap 은 하나 이상의 llama-server 인스턴스 앞에 서는 외부 오케스트레이터입니다:

요청을 가로채고 model 필드를 검사
해당 모델에 적합한 llama-server 프로세스 시작
설정 가능한 타임아웃 후 유휴 인스턴스 종료
모델이 준비되면 요청을 프록시

실무 설정에 대해서는 llama-swap 빠른 시작 를 참조하세요.

주요 차이점

측면	라우터 모드	llama-swap
내장 여부	네	아니오 (별도의 이진 파일)
성숙도	실험적	더 안정적
유연성	제한적	높음
제어 계층	내부	외부 프록시
모델별 설정	INI 파일	YAML 파일
프로세스 모델	단일 프로세스	모델당 하나의 프로세스

llama-swap 사용 시기

llama-swap 은 모델당 프로세스 수준 격리를 제공하여, 하나의 모델 인스턴스에서 충돌이 발생해도 다른 모델에 영향을 주지 않습니다. 또한 각 모델이 완전히 독립적인 llama-server 플래그로 실행되도록 합니다.

다음과 같은 것이 필요할 때 사용하세요:

더 나은 수명 주기 제어 및 격리
설정 가능한 유휴 타임아웃을 지닌 더 스마트한 전환 로직
더 예측 가능한 지연시간 (각 모델이 첫 로딩 후 따뜻한 프로세스 보유)
미래가 아닌 당장의 프로덕션 안정성

네이티브 라우터 모드가 충분한 경우

다음과 같은 것을 원할 때 내장 라우터를 사용하세요:

외부 종속성 없음
관리할 프로세스 하나
더 간단한 배포 (이진 파일 하나, 설정 파일 하나)
개발 또는 단일 사용자 설정을 위한 최소 스택

마지막 생각들

라우터 모드는 llama-server 를 위한 의미 있는 진전입니다.

오랫동안 이어져 온 요구에 답변합니다:

llama.cpp 서버의 라우터 모드란 무엇인가?

이는 정적 이진 파일을 동적 추론 서비스로 만드는 누락된 계층입니다 — 전체 모델 카탈로그에 대한 요청을 처리할 수 있는 단일 프로세스입니다.

하지만 아직 완성되지 않았습니다.

현재는 다음과 같습니다:

실제 워크로드에 충분히 강력함
더 정교한 라우팅을 위한 기반으로서 유망함
설정과 안정성 측면에서 약간 거칠음

워크로드가 예측 가능하고 모델을 기준으로 요청을 그룹화할 수 있다면, 라우터 모드는 지금 잘 작동합니다. 프로덕션 급 신뢰성과 모델별 격리가 필요하다면, 네이티브 구현이 성숙해질 때까지 llama-swap 을 사용하세요.

어느 쪽이든 Ollama 와 유사한 동작을 얻되, 기계 장치를 숨기지 않습니다.