Continuous Batching과 단일 사용자 속도

쉽게 말하면

여러 사람이 동시에 질문할 때 GPU가 놀지 않도록 요청을 계속 묶어 처리하는 서버 기능입니다. 전체 처리량은 늘 수 있지만 한 사람의 첫 답은 조금 늦어질 수도 있습니다.

장비를 고를 때

혼자 쓰는 로컬 LLM이라면 핵심 구매 기준이 아닙니다. 가족·팀이 함께 쓰거나 여러 앱을 한 서버에 연결할 때 중요합니다.

이 글에서 확인할 내용

• 완료된 요청 자리에 새 요청을 즉시 넣습니다.
• 총 처리량과 개별 요청 지연은 다른 지표입니다.
• MTP와 추측 디코딩 지원은 단일·배치 경로가 다를 수 있습니다.

고정 배치의 빈자리를 줄입니다

전통적인 정적 배치는 여러 요청이 모두 끝날 때까지 같은 묶음으로 처리합니다. 짧은 답이 먼저 끝나도 긴 답이 남아 있으면 계산 자원이 비게 됩니다.

연속 배칭은 토큰 생성 단계마다 완료된 요청을 빼고 대기 중인 새 요청을 넣습니다. 서로 다른 길이의 요청이 계속 섞여도 GPU를 높은 사용률로 유지하는 것이 목적입니다.

전체 처리량과 한 사람의 대기 시간은 다릅니다

여러 요청을 묶으면 서버가 1초에 만들어 내는 전체 토큰 수는 늘 수 있습니다. 하지만 각 요청은 다른 요청과 차례를 나누기 때문에 자신의 다음 토큰을 받는 간격이 길어질 수 있습니다.

혼자 쓰는 로컬 서버에서는 여러 사람 기준의 최대 처리량보다 첫 답이 나오는 시간과 답변이 자연스럽게 이어지는지가 중요합니다. 가족이나 팀이 함께 쓸 때는 전체 처리량도 함께 봐야 합니다.

메모리는 KV 캐시가 결정합니다

모델 가중치는 요청들이 공유하지만 각 시퀀스의 KV 캐시는 별도로 필요합니다. 동시 요청과 문맥 길이가 늘수록 캐시 블록이 빠르게 소비됩니다.

PagedAttention과 prefix cache는 이 메모리를 효율적으로 배치하고 공통 접두사를 재사용하는 데 도움을 줍니다. 가중치 적재 후 남은 메모리가 실제 동시 사용자 수를 제한합니다.

가속 기술과의 조합

MTP와 초안 모델 추측 디코딩은 후보 토큰을 추가로 만들고 검증합니다. 단일 시퀀스용 커널이 연속 배치의 다양한 길이와 캐시 상태를 지원하지 않으면 배치 경로에서 비활성화될 수 있습니다.

설정 화면에서 가속이 켜져 있어도 동시 요청 실행 중 실제 경로를 확인해야 합니다. 단일 사용자 최고 속도와 다중 사용자 전체 처리량은 별도의 테스트로 관리하세요.

운영 목적에 맞춘 설정

혼자 쓰는 채팅과 코딩 보조라면 작은 배치와 빠른 응답 우선 스케줄링이 자연스럽습니다. 여러 앱이 같은 서버를 공유한다면 최대 시퀀스 수, 토큰 예산과 대기 시간 상한을 함께 조정합니다.

벤치마크에는 동시 요청 수, 각 프롬프트 길이, 출력 길이와 지연 백분위를 기록하세요. 총 tok/s만 높고 첫 토큰 대기가 길다면 대화형 서비스에는 좋은 설정이 아닐 수 있습니다.