올라마가 병렬 요청을 처리하는 방법

이 가이드는 Ollama가 병렬 요청을 처리하는 방식(동시성, 큐잉, 리소스 한계)과 OLLAMA_NUM_PARALLEL 환경 변수(및 관련 설정)를 사용하여 이를 조정하는 방법을 설명합니다.

바로가기 링크: OLLAMA_NUM_PARALLEL이란? · 빠른 튜닝 레시피 · 큐 동작 방식 · 문제 해결 · 관련: Ollama CLI 명령어 치트시트

처리량, 지연 시간, VRAM 및 런타임과 하드웨어 전반의 벤치마크에 대한 자세한 내용은 LLM 성능: 벤치마크, 병목 현상 및 최적화를 참조하십시오.

멀티스텝 에이전트는 샘플링이 불안정할 경우 재시도 횟수를 증가시킵니다. Qwen 및 Gemma 클래스 모델의 기본 온도, top_p, 페널티 설정에 대해서는 Qwen 및 Gemma용 에이전틱 추론 파라미터를 참조하십시오.

동시 요청 처리

• 병렬 처리: Ollama는 요청의 동시 처리를 지원합니다. 시스템에 사용 가능한 메모리가 충분하다면(CPU 추론용 RAM, GPU 추론용 VRAM), 여러 모델을 동시에 로드할 수 있으며, 각 로드된 모델은 여러 요청을 병렬로 처리할 수 있습니다. 이는 각 모델이 동시에 처리할 수 있는 최대 병렬 요청 수를 설정하는 환경 변수 OLLAMA_NUM_PARALLEL에 의해 제어됩니다. 기본값은 4입니다(또는 메모리 사용 가능 여부에 따라 1일 수 있음), 하지만 조정할 수 있습니다.

• 배치 처리(Batching): 동일한 모델에 대한 여러 요청이 동시에 도착하면, Ollama는 이를 배치로 묶어 함께 처리합니다. 이는 두 요청이 모두 병렬로 처리됨을 의미하며, 사용자는 동일한 시간대에 응답이 스트리밍되는 것을 볼 수 있습니다. 서버는 배치를 채우기 위해 의도적으로 대기하지 않으며, 요청이 가능해지면 즉시 처리가 시작됩니다.

큐잉 및 한계

• 큐잉(Queuing): 동시 요청 수가 구성된 병렬 처리 능력(예: 모델당 OLLAMA_NUM_PARALLEL 요청 초과)을 초과하면 추가 요청은 큐에 대기합니다. 큐는 선입선출(FIFO) 방식으로 작동합니다.

• 큐 한계(Queue Limits): 큐에 대기할 수 있는 최대 요청 수는 OLLAMA_MAX_QUEUE(기본값: 512)에 의해 제어됩니다. 큐가 가득 차면 새로운 요청은 서버가 과부하 상태임을 나타내는 503 오류를 받게 됩니다.

• 모델 로딩(Model Loading): 동시에 로드할 수 있는 서로 다른 모델의 수는 OLLAMA_MAX_LOADED_MODELS에 의해 제어됩니다. 요청이 새 모델의 로딩을 필요로 하고 메모리가 부족하면, Ollama는 유휴 모델을 언로드하여 공간을 확보하고, 모델이 로드될 때까지 요청은 큐에 대기합니다.

예시 시나리오

두 개의 요청이 동일한 모델에 대해 동시에 도착하고 서버의 병렬 처리 설정이 최소 2라면, 두 요청은 하나의 배치로 함께 처리되며 두 사용자는 동시에 응답을 받게 됩니다. 병렬 처리가 1로 설정되어 있다면, 하나의 요청은 즉시 처리되고 다른 하나는 첫 번째 요청이 완료될 때까지 큐에 대기합니다.

요청이 서로 다른 모델에 대한 것이며 메모리가 충분하다면, 두 모델 모두 로드되어 요청이 병렬로 처리됩니다. 그렇지 않다면, 하나의 모델을 언로드해야 할 수 있으며 요청은 큐에 대기하게 됩니다.

요약 표

요약하자면, Ollama는 서버가 동시 처리를 위해 구성되어 있고 충분한 리소스가 제공된다면 여러 동시 요청을 효율적으로 처리하도록 설계되었습니다. 그렇지 않으면 요청은 순서대로 큐에 대기하여 처리됩니다.

OLLAMA_NUM_PARALLEL을 높여도 지연 시간이 안정적이지 않고 실제 트래픽 하에서 큐가 계속 증가한다면, 이는 목적-built 서버 엔진으로 이동하는 것을 고려할 만한 더 명확한 신호 중 하나입니다. Ollama에서 vLLM으로: 로컬 LLM 서버 마이그레이션 시기에서는 vLLM이 동시 요청이 서로 성능을 저하시키지 않도록 유지하기 위해 사용하는 연속 배치(continuous batching) 및 PagedAttention 등의 메커니즘을 포함한 그 결정을 다룹니다.

메모리 부족 처리

Ollama가 들어오는 요청을 처리할 메모리가 부족할 때, 안정성을 유지하기 위해 큐잉 메커니즘과 리소스 관리 전략의 조합을 사용합니다:

요청 큐잉

• 메모리를 즉시 할당할 수 없을 때 새 요청은 FIFO(선입선출) 큐에 배치됩니다.
• 큐 크기는 OLLAMA_MAX_QUEUE(기본값: 512 요청)에 의해 제어됩니다.
• 큐가 용량에 도달하면 새 요청은 503 “서버 과부하” 오류를 받게 됩니다.

모델 관리

• 유휴 상태가 되면 활성 모델이 메모리에서 언로드되어 큐에 대기 중인 요청을 위한 리소스를 확보합니다.
• 동시에 로드된 모델의 수는 OLLAMA_MAX_LOADED_MODELS(기본값: GPU 수 × 3 또는 CPU 기준 3)로 제한됩니다.

메모리 최적화

• 동일한 모델에 대한 요청을 배치 처리하여 메모리 효율을 극대화하도록 시도합니다.
• GPU 추론의 경우, 모델당 전체 VRAM 할당이 필요하며 부분 로드는 지원되지 않습니다.

실패 시나리오

심각한 메모리 고갈: 큐에 대기 중인 요청조차도 사용 가능한 리소스를 초과할 때, Ollama는 다음을 수행할 수 있습니다:

• 디스크로 페이지닝 (성능이 심각하게 저하됨)
• “메모리 부족” 오류 반환
• 극단적인 경우 모델 인스턴스 충돌

관리자는 메모리 사용량을 모니터링하고 하드웨어 기능에 따라 이러한 매개변수를 조정해야 합니다. 메모리 부족 처리는 더 큰 모델(7B+ 파라미터)을 실행하거나 여러 동시 요청을 처리할 때 중요합니다.

Ollama 최적화 전략

export OLLAMA_CUDA=1로 GPU 가속을 활성화하고 export OLLAMA_NUM_THREADS=84로 CPU 스레드를 설정합니다. 하드웨어 향상

• RAM: 13B 모델용 32GB+, 70B 모델용 64GB+
• 스토리지: 더 빠른 모델 로딩/스왑을 위한 NVMe SSD
• GPU: 더 큰 모델을 위한 16GB+ VRAM을 갖춘 NVIDIA RTX 3080/4090

운영 전략

• 요청 배치 처리: 메모리 오버헤드를 분산하기 위해 여러 쿼리를 동시에 처리
• 자동 모델 언로드: Ollama가 유휴 모델을 메모리에서 제거하도록 허용
• 자주 사용하는 모델 캐싱: 공통 모델을 메모리 레지던트로 유지

모니터링 및 문제 해결

• nvidia-smi(GPU) 및 htop(CPU/RAM)을 사용하여 병목 현상을 식별
• 메모리 오류의 경우:
• 양자화된 모델로 업그레이드
• 동시 요청 수 감소
• 스왑 공간 증가

예시 최적화 워크플로우:

### GPU 가속과 함께 양자화된 모델 사용
export OLLAMA_CUDA=1
ollama run llama2:7b-q4_0 --context-size 2048

### 로드된 모델 및 병렬 요청 제한
export OLLAMA_MAX_LOADED_MODELS=2
export OLLAMA_NUM_PARALLEL=4

이러한 조정은 응답 품질을 유지하면서 메모리 사용량을 30-60%까지 줄일 수 있으며, 특히 여러 모델을 실행하거나 높은 요청 볼륨을 처리할 때 유리합니다.

OLLAMA_NUM_PARALLEL 환경 변수

OLLAMA_NUM_PARALLEL은 Ollama가 병렬로 실행할 요청 수를 제어합니다. 동일한 Ollama 서버로 여러 요청을 보내는 경우, 이 설정은 그들이 동시에 실행될지 아니면 큐에 대기할지를 주로 결정합니다.

• 높은 값은 충분한 CPU/GPU/VRAM이 있다면 처리량을 증가시킬 수 있지만, 지연 시간과 메모리 압력을 증가시킬 수 있습니다.
• 낮은 값은 경쟁을 줄이고 안정성을 개선할 수 있지만, 요청이 더 자주 큐에 대기하게 됩니다.

OLLAMA_NUM_PARALLEL 설정 방법

Linux / macOS (systemd 서비스 또는 셸):

export OLLAMA_NUM_PARALLEL=2
ollama serve

일회성 실행 (이 명령어만 위한 접두사):

OLLAMA_NUM_PARALLEL=2 ollama serve

Docker (예시):

docker run --rm -e OLLAMA_NUM_PARALLEL=2 -p 11434:11434 ollama/ollama

값 선택 방법

단일 GPU / 제한된 VRAM의 경우 1–2로 시작한 다음 다음을 모니터링하면서 점진적으로 증가시킵니다:

• GPU VRAM 사용량 (OOM / 이출)
• CPU 사용량 및 부하 평균
• 일반적인 요청의 p95 지연 시간
• 오류율 / 타임아웃

CLI 사용을 위한 특정 페이지를 최적화하고 있다면, 치트시트의 Ollama CLI 섹션과 ollama serve, ollama ps, ollama run 명령어 예를 참조하십시오.

빠른 튜닝 레시피

안정성 우선

• OLLAMA_NUM_PARALLEL=1
• 작거나 양자화된 모델 사용
• 더 짧은 컨텍스트 크기 선호

처리량 우선

• OLLAMA_NUM_PARALLEL=2 (여유가 있다면 더 높음)
• 클라이언트 계층에서의 요청 배치 처리 고려
• 충분한 VRAM 및 CPU 스레드 보장

“두 요청이 도착하면 VRAM이 부족함”

• OLLAMA_NUM_PARALLEL 감소
• 더 공격적으로 양자화된 모델 사용
• 컨텍스트 길이 / 최대 토큰 감소

문제 해결

OLLAMA_NUM_PARALLEL이 너무 높다는 증상

• 부하 하에서 요청이 간헐적으로 실패
• GPU OOM / 모델 언로드가 빈번하게 발생
• 두 번째 요청이 도착할 때 지연 시간 급증

OLLAMA_NUM_PARALLEL이 너무 낮다는 증상

• CPU/GPU 과소 활용
• 큐잉 지연이 전체 응답 시간의 대부분을 차지

팁: 클라이언트도 제어한다면 jitter와 keep-alive 연결을 갖춘 재시도를 추가하십시오. 많은 “Ollama가 느림” 문제는 실제로 큐잉 + 연결 오버헤드입니다.

Ollama: 요청 배치 처리 대 병렬 실행

Ollama에서의 **배치 처리(Batching)**는 여러 들어오는 요청을 그룹화하여 하나의 단위로 처리하는 관행을 의미합니다. 이는 특히 병렬화된 작업에서 이점을 제공하는 하드웨어(GPU 등)에서 실행할 때 계산 리소스를 더 효율적으로 사용할 수 있게 해줍니다.

동일한 모델에 대한 여러 요청이 동시에 도착하면, 메모리가 허용하는 경우 Ollama는 이를 하나의 배치로 함께 처리할 수 있습니다. 이는 처리량을 증가시키고 각 요청에 대한 지연 시간을 줄일 수 있으며, 모델이 배치에 대해 최적화된 행렬 연산을 활용할 수 있기 때문입니다.

배치 처리는 요청의 크기와 복잡성이 유사할 때 특히 효과적이며, 이는 더 나은 하드웨어 활용을 가능하게 합니다.

Ollama에서의 병렬 실행은 사용 가능한 메모리 및 구성에 따라 동일한 모델 또는 다른 모델에 대한 여러 요청을 동시에 처리하는 것을 의미합니다.

Ollama는 두 수준의 병렬성을 지원합니다:

• 다중 모델 로딩: 충분한 메모리가 사용 가능하면, 여러 모델을 로드하여 동시에 요청을 처리할 수 있습니다.
• 모델당 병렬 요청: 각 로드된 모델은 OLLAMA_NUM_PARALLEL 설정(기본값은 메모리에 따라 1 또는 4)에 의해 제어되는 여러 요청을 병렬로 처리할 수 있습니다.

요청이 병렬 처리 한계를 초과하면, OLLAMA_MAX_QUEUE까지 큐(FIFO)에 대기합니다.

주요 결론

Ollama는 여러 요청을 효율적으로 처리하기 위해 배치 처리와 병렬 실행을 모두 활용합니다. 배치 처리는 요청을 그룹화하여 동시에 처리하고, 병렬 실행은 여러 요청(또는 모델)이 동시에 실행되도록 허용합니다. 두 방법 모두 시스템 메모리에 의존하며 최적의 성능을 위해 구성할 수 있습니다.

더 많은 벤치마크, 동시성 튜닝 및 성능 가이드는 LLM 성능: 벤치마크, 병목 현상 및 최적화 허브를 확인하십시오.

유용한 링크

• Ollama 명령어 치트시트
• LLM 성능 비교 - 16GB VRAM GPU에서의 Ollama
• Ollama 모델을 다른 드라이브 또는 폴더로 이동
• Ollama가 Intel CPU 성능 및 효율 코어를 사용하는 방법
• Ollama에서 vLLM으로: 로컬 LLM 서버 마이그레이션 시기