7.1. 병렬 요청 슬롯¶
로드된 모델은 정해진 개수의 병렬 요청 슬롯으로 요청을 처리합니다. 슬롯 수는 Model Config Drawer의 컨텍스트 탭에 있는 병렬 요청 설정으로 조정하며, Backend.AI GO는 이 값을 추론 엔진(llama-server 또는 mlxcel-server)에 --parallel 플래그로 전달합니다.
이 설정이 하는 일¶
진행 중인 요청 하나가 슬롯 하나를 차지합니다. 슬롯 수를 초과한 요청은 엔진 내부 큐에서 대기하는데, 이 지연은 첫 토큰이 늦게 도착하는 형태로만 드러납니다.
에이전트 기능은 같은 모델에 여러 요청을 동시에 보내는 일이 흔합니다. 서브 에이전트를 @멘션하는 채팅 턴, 병렬로 일하는 Cowork 서브 에이전트, 하나의 로컬 모델을 공유하는 여러 Squad 에이전트가 모두 그렇죠. 슬롯이 1개뿐이면 애플리케이션이 동시에 보낸 호출이라도 엔진에서 전부 직렬화됩니다.
범위와 기본값¶
| 항목 | 값 |
|---|---|
| 최소 | 1 |
| 최대 | 8 |
| 기본값 | 2 |
| 슬롯당 컨텍스트 하한 (경고) | 1,024 토큰 |
기본값 2는 가장 작은 현실적인 에이전트 워크로드(주 에이전트 + 서브 에이전트 1개)가 직렬화되지 않도록 하는 값입니다. 직접 설정한 값은 항상 그대로 유지되며, 의도적으로 단일 슬롯으로 쓰고 싶다면 1로 두어도 됩니다.
상한은 로드된 모델과 무관한 고정 상수입니다. llama-server 자체에는 상한이 없어서 서버급 하드웨어의 프로덕션 배포에서는 8~32 슬롯을 쓰기도 하는데, Backend.AI GO가 대상으로 하는 일반 노트북에서는 8을 넘는 값에 현실적인 컨텍스트 크기를 곱하면 대부분 메모리 부족으로 로드에 실패하거나 슬롯당 컨텍스트가 하한 아래로 떨어집니다. 8은 번들된 두 엔진 모두에서 동시 처리가 검증된 최댓값이기도 합니다.
컨텍스트는 슬롯끼리 나눠 씁니다¶
컨텍스트 길이는 전체 예산입니다. 엔진이 이를 슬롯 수만큼 균등 분할하므로, 각 요청은 컨텍스트 크기 ÷ 병렬 슬롯 수 토큰으로 동작합니다:
| 컨텍스트 길이 | 병렬 요청 | 슬롯당 컨텍스트 |
|---|---|---|
| 8192 | 2 | 4096 |
| 8192 | 8 | 1024 |
| 4096 | 8 | 512 (하한 미달, 경고 표시) |
컨텍스트 길이를 그대로 두고 슬롯 수만 올리면 요청 하나하나의 작업 공간이 줄어들고, 둘 다 올리면 슬롯당 컨텍스트는 유지되지만 KV 캐시 메모리가 대략 선형으로 늘어납니다. 4B 모델을 8K 컨텍스트 + 8 슬롯으로 무리 없이 돌리던 16 GB 장비라도 70B 모델에서는 같은 설정이 통하지 않는 이유입니다.
슬롯당 하한 경고¶
컨텍스트 크기 ÷ 병렬 슬롯 수가 1,024 토큰 아래로 내려가는 조합을 저장하려고 하면 슬라이더 아래에 경고가 표시됩니다. 저장이 막히지는 않습니다. 1,024는 물리적 한계가 아니라 경험적 기준인데, 일반적인 에이전트 시스템 프롬프트와 도구 목록만으로 이미 600~900 토큰을 차지하므로 1K 아래에서는 실제 대화에 쓸 공간이 거의 남지 않기 때문입니다. 엔진은 더 빠듯한 값도 받아들이고 임베딩식 배치 추론 같은 특수 워크로드에서는 여전히 유효하지만, 일반 채팅이나 에이전트 용도에서는 슬롯 축출(eviction)이 끊임없이 일어나게 됩니다.
값 고르기¶
- 한 번에 대화 하나만 하는 일반 채팅: 슬롯 1~2개면 충분합니다. 병렬화할 것이 없습니다.
- 에이전트 워크플로우 (Cowork, Squad, 서브 에이전트 멘션): 실제로 동시에 도는 에이전트 수에 슬롯 수를 맞추고, 컨텍스트 길이도 같이 키우세요. 16K 컨텍스트에 4 슬롯이면 에이전트마다 4K의 작업 공간이 생깁니다.
- 메모리가 빠듯한 장비 (8~16 GB): 빠듯한 슬롯을 여러 개 두는 것보다 슬롯 수를 줄이고 슬롯당 몫을 키우는 편이 낫습니다. 하한 경고가 뜨는지 살펴보세요.
내 하드웨어에서 동시 처리 검증하기¶
슬롯이 직렬화 없이 실제로 병렬 처리되는지 직접 확인할 수 있습니다.
llama-server¶
- 작은 모델(예:
Qwen3-4B-Instruct의Q4_K_M)을 컨텍스트 길이 8192, 병렬 요청 4로 로드합니다. /v1/chat/completions에 스트리밍 요청 4개를 겹치게 보냅니다.- 추론 포트의
/health또는/slots를 확인합니다. 4개 슬롯이 동시에busy로 표시되어야 하고, 각 요청의 첫 토큰이 다른 요청들이 끝나기 한참 전에 도착해야 합니다.
mlxcel-server (macOS)¶
- MLX 모델을 병렬 요청 2, 컨텍스트 길이 8192로 로드합니다.
- 스트리밍 요청 두 개를 약 50 ms 간격으로 보내고, 각 요청의 첫 토큰 도착 시각을 기록합니다.
- 두 번째 요청이 첫 번째 요청 완료보다 훨씬 먼저 토큰을 내기 시작해야 합니다. 두 번째 요청의 첫 토큰이 첫 요청의 전체 소요 시간만큼 늦게 도착한다면, 엔진이 배칭이 아니라 직렬 처리를 하고 있는 것입니다.