병렬 요청 슬롯¶

로드된 모델은 정해진 개수의 병렬 요청 슬롯으로 요청을 처리합니다. 슬롯 수는 Model Config Drawer의 컨텍스트 탭에 있는 병렬 요청 설정으로 조정합니다. Backend.AI GO는 이 값을 llama-server에 --parallel 플래그로 전달하고, 슬롯이 둘 이상이면 슬롯들이 컨텍스트 하나를 공유하도록 --kv-unified도 함께 넘깁니다. MLX 모델은 현재 슬롯 하나로 실행되며, 자세한 내용은 MLX 모델을 참고하세요.

이 설정이 하는 일¶

진행 중인 요청 하나가 슬롯 하나를 차지합니다. 슬롯 수를 초과한 요청은 엔진 내부 큐에서 대기하는데, 이 지연은 첫 토큰이 늦게 도착하는 형태로만 드러납니다.

에이전트 기능은 같은 모델에 여러 요청을 동시에 보내는 일이 흔합니다. 서브 에이전트를 @멘션하는 채팅 턴, 병렬로 일하는 Cowork 서브 에이전트, 하나의 로컬 모델을 공유하는 여러 Squad 에이전트가 모두 그렇죠. 슬롯이 1개뿐이면 애플리케이션이 동시에 보낸 호출이라도 엔진에서 전부 직렬화됩니다.

범위와 기본값¶

기본값 2는 가장 작은 현실적인 에이전트 워크로드(주 에이전트 + 서브 에이전트 1개)가 직렬화되지 않도록 하는 값입니다. 직접 설정한 값은 항상 그대로 유지되며, 의도적으로 단일 슬롯으로 쓰고 싶다면 1로 두어도 됩니다.

상한은 로드된 모델과 무관한 고정 상수입니다. llama-server 자체에는 상한이 없어서 서버급 하드웨어의 프로덕션 배포에서는 8~32 슬롯을 쓰기도 합니다. 하지만 Backend.AI GO가 대상으로 하는 일반 노트북에서는 대화 하나 분량으로 잡은 컨텍스트 길이에 긴 요청이 몇 개만 들어가도 가득 차므로, 8을 넘는 슬롯은 대부분 공간이 모자란 요청을 늘릴 뿐입니다.

요청들이 컨텍스트 길이를 공유합니다¶

컨텍스트 길이는 요청 하나의 한도입니다. 병렬 슬롯들은 그 크기의 풀 하나를 함께 씁니다. 요청 하나가 전체를 다 쓸 수 있고, 동시에 실행되는 요청들은 합쳐서 그 크기를 넘을 수 없습니다.

슬롯 수를 올려도 요청 하나의 작업 공간이 줄지 않고 KV 캐시 메모리도 늘지 않습니다. 같은 풀을 대상으로 더 많은 요청을 동시에 돌릴 수 있게 될 뿐입니다. 동시에 실행되는 요청들이 필요로 하는 양이 합쳐서 컨텍스트 길이를 넘으면, llama.cpp는 진행 중인 요청들을 Context size has been exceeded. 오류로 실패시킵니다. 에이전트들이 긴 요청을 병렬로 돌린다면 컨텍스트 길이를 늘리거나(KV 캐시 메모리는 대략 선형으로 늘어납니다) 슬롯 수를 줄이세요.

세션 화면과 채팅 상태 표시줄에 나오는 컨텍스트 길이는 모델이 로드된 뒤 엔진의 /props 엔드포인트에서 읽은 값, 즉 엔진이 실제로 적용한다고 보고한 값입니다. llama.cpp는 컨텍스트를 256의 배수로 올려 잡기 때문에 설정한 값보다 조금 클 수 있습니다.

MLX 모델¶

mlxcel-server는 현재 컨텍스트를 슬롯 수만큼 나눠 쓰기 때문에, Backend.AI GO는 이 설정 값과 관계없이 MLX 모델을 슬롯 하나로 실행합니다. 그래서 MLX 모델은 배치 디코딩을 지원하지 않는 모델들처럼 한 번에 요청 하나를 컨텍스트 길이 전체로 처리합니다. 공유 컨텍스트를 지원하는 mlxcel이 출시되면 MLX 모델의 병렬 요청도 공유 컨텍스트를 쓰게 됩니다.

MLX 스케줄러 탭에서 최대 배치 크기를 직접 지정하면 동시에 디코딩되는 시퀀스들이 여전히 컨텍스트를 나눠 가지며, 시퀀스 하나에 돌아가는 몫이 1,024 토큰보다 적어지면 그 탭에 경고가 표시됩니다. 이때 세션 화면에는 엔진이 보고한 줄어든 값이 표시되고, 컨텍스트 탭은 슬라이더에 실행할 때 쓴 컨텍스트 길이를 그대로 두고 그 아래에 줄어든 값을 따로 알려 줍니다.

값 고르기¶

• 한 번에 대화 하나만 하는 일반 채팅: 슬롯 1~2개면 충분합니다. 병렬화할 것이 없습니다.
• 에이전트 워크플로우 (Cowork, Squad, 서브 에이전트 멘션): 실제로 동시에 도는 에이전트 수에 슬롯 수를 맞추고, 컨텍스트 길이는 그 에이전트들이 함께 쓰는 양에 맞춰 잡으세요. 에이전트 4개가 각각 4K 토큰 정도를 쓴다면 합쳐서 16K 컨텍스트가 필요합니다.
• 메모리가 빠듯한 장비 (8~16 GB): KV 캐시 메모리는 컨텍스트 길이에 따라 늘어나고, 슬롯 수를 바꿔도 달라지지 않습니다. 들어가는 한도에서 가장 큰 컨텍스트 길이를 고른 뒤, 슬롯 수는 실제로 함께 실행되는 요청 수에 맞추세요.

내 하드웨어에서 동시 처리 검증하기¶

슬롯이 직렬화 없이 실제로 병렬 처리되는지, 그리고 각 슬롯이 컨텍스트 전체를 보는지 직접 확인할 수 있습니다.

llama-server¶

1. 작은 모델(예: Qwen3-4B-Instruct의 Q4_K_M)을 컨텍스트 길이 8192, 병렬 요청 4로 로드합니다.
2. 추론 포트의 /props를 확인합니다. default_generation_settings.n_ctx가 컨텍스트 전체인 8192로 나와야 합니다.
3. /v1/chat/completions에 스트리밍 요청 4개를 겹치게 보냅니다. 네 요청을 합쳐도 8192 토큰을 넘지 않도록 프롬프트를 짧게 유지하세요.
4. 추론 포트의 /slots를 확인합니다. 4개 슬롯이 동시에 처리 중으로 표시되어야 하고, 각 요청의 첫 토큰이 다른 요청들이 끝나기 한참 전에 도착해야 합니다.

mlxcel-server (macOS)¶

MLX 모델은 mlxcel이 공유 컨텍스트를 지원할 때까지 슬롯 하나로 실행되므로, 아직 검증할 동시 처리가 없습니다. 요청 하나가 컨텍스트 전체를 받는지 확인하려면 MLX 모델을 컨텍스트 길이 8192로 로드한 뒤, 추론 포트의 /props가 default_generation_settings.n_ctx를 8192로 보고하는지 확인하세요.