Continuous Batching과 단일 사용자 속도

고정 배치는 정해진 요청 묶음을 함께 실행해 짧은 응답이 먼저 끝나도 다른 요청이 끝날 때까지 그 자리가 빌 수 있어요. 연속 배칭은 완료된 요청을 빼고 대기 중인 요청을 넣어 GPU³ 계산 자원을 계속 활용해요. 모델 가중치를 요청마다 복제하는 것이 아니라 같은 가중치를 여러 요청이 공유해 계산해요.

이 방식이 특히 보는 값은 동시에 온 요청이 서버에서 얼마나 꾸준히 처리되는지예요. 혼자 보내는 요청 하나는 배칭이 채울 다른 슬롯이 없으므로, 그때의 첫 토큰과 토큰 간격을 따로 확인해요.

대시보드의 전체 tok/s는 동시에 생성된 여러 요청의 토큰을 더한 값일 수 있어요. 개인에게 중요한 값은 자기 요청의 첫 토큰까지 기다린 시간, 토큰이 이어지는 간격, 답이 끝날 때까지의 시간이에요. 전체 처리량이 높아져도 개별 질문은 큐에서 오래 기다리거나 토큰 간격이 늘 수 있어요.

속도 주장에 있는 합산 값이 누구의 시간을 나타내는지 확인해요. 서버가 처리한 전체 토큰 수는 운영 용량을 비교할 때 쓰고, 문서 앱의 응답 경험은 요청별 지연으로 봐요. 두 수치가 같은 비율로 함께 바뀌지는 않아요.

여러 요청은 같은 모델 가중치를 공유해도 각자 입력 문맥, 생성한 출력, 이어갈 위치를 따로 유지해요. 이 상태를 위해 요청별 KV 캐시⁴가 필요해요. 동시 요청이 많아지거나 각 문서가 길어지면 캐시 메모리도 함께 늘 수 있으므로, 동시 한도와 문맥 한도를 무작정 키우면 안 돼요.

긴 문서의 프리필⁵이 들어오면 입력 계산도 GPU 자원을 써요. 진행 중인 디코드⁶와 계산 자원을 나눠 쓰면 토큰 간격이 길어질 수 있어요. 일부 런타임⁷은 긴 프리필을 나누어 스케줄링하지만 지원 여부와 정책은 구현·설정마다 달라요. Paged KV나 공통 접두사 캐시는 배치·캐시 사용을 개선할 수 있지만 물리 메모리를 더해 주지는 않아요.

MTP⁸는 모델에 포함된 추가 예측 헤드를 활용할 수 있고, 추측 디코딩⁹은 별도 초안 모델을 둘 수도 있어요. 두 방식은 후보 토큰을 만든 다음 본 모델이 검증하는 경로를 포함해요. 단일 요청에서 작동했다 해도 배치 실행에서 지원되는지는 런타임과 모델 구성에 따라 달라요.

한 요청 실행과 다른 요청이 겹치는 실행을 각각 시험하고 로그에서 후보 생성과 검증 경로가 실제로 쓰였는지 봐요. 배치에서 미지원이면 기본 디코딩으로 돌아갈 수 있어요. 여러 요청이 겹칠 때 개별 대화의 첫 토큰과 토큰 간격도 기록해 실제 체감을 비교해요.

요청 하나로 기준을 만든 뒤 A의 긴 분석 중 B의 짧은 질문을 넣고, B가 끝나면 C의 요약이 합류하는 흐름을 재현해요. 도착 시각, 첫 토큰 대기, 토큰 간격, 완료 시각과 동시 요청 수를 기록하면 새 요청이 슬롯을 채울 때 각 사용자가 얼마나 기다렸는지 알 수 있어요.

요청이 한꺼번에 오거나 조금씩 이어지는 실제 앱 패턴도 시험하고, 평균 처리량뿐 아니라 오래 밀린 요청을 살펴요. 개인용이면 단일 응답을, 팀 공유 서버면 실제로 겹치는 요청의 처리량과 지연을 구매·운영 기준으로 삼아요. GPU 사용률이나 합산 tok/s 하나만으로 개인 답변이 빨라졌다고 결론 내리지 않아요.