지속적인 LLM 배칭 중 GPU 사용률 공백의 원인은 무엇인가요?
GPU 사용률 저하는 연속 배칭 스케줄러가 실행 가능한 작업을 구성하지 못하거나 종속성으로 인한 정지 없이 가속기에 작업을 공급하지 못할 때 주로 나타납니다.
홈 LLM 서버는 높은 처리량을 보고하면서도 디코드 반복 사이에 주기적인 GPU 사용률 저하를 보일 수 있습니다. 연속 배칭은 완료된 시퀀스를 제거하고 새 시퀀스를 추가하지만, 요청 도착이 드물거나 KV 블록을 사용할 수 없거나 긴 프리필이 디코드를 차단하거나 CPU 런타임이 배치를 너무 느리게 준비할 때는 작업을 만들어 낼 수 없습니다. 요청 큐가 가득 차 있어도 동기화와 메모리 이동 때문에 공백이 생길 수 있습니다.
요청 공급과 시퀀스 교체로 배치가 비어 있을 수 있습니다
연속 배칭은 반복 경계에서 완료된 시퀀스를 새 시퀀스로 교체합니다. 요청 도착이 몰리거나 출력이 동시에 완료되거나 추가 제한으로 인해 요청이 실행 가능 큐 밖에 머무르면 활성 토큰 수가 GPU의 효율적인 작동 범위 아래로 떨어질 수 있습니다.
연속 배치 구성원에 관한 벤치마크는 입력 길이, 출력 길이, 도착 시간이 다양한 상황에서 정적 요청 구성과 연속 요청 구성을 비교합니다. 이때의 특징은 가속기가 정상적으로 작동하고 메모리 오류가 없는데도 사용률 저하 중 실행 가능 토큰 수가 낮다는 점입니다.
큐가 실제로 비어 있다면 스케줄러의 결함이 아닙니다. 모든 유휴 구간을 손실된 용량으로 해석하기 전에 도착률, 추가된 시퀀스 수, 반복당 스케줄된 토큰 수를 비교하세요. 이러한 차이는 이후의 가정용 테스트에서도 확인할 수 있습니다.
프리필, 디코드, KV 할당이 스케줄러 버블을 만듭니다
프리필은 많은 프롬프트 토큰을 연산 집약적인 커널로 처리하는 반면, 디코드는 각 시퀀스를 한 토큰씩 진행하며 메모리 대역폭의 영향을 크게 받는 경우가 많습니다. 두 단계를 혼합하면 디코드가 지연될 수 있고, KV 블록을 예약하거나 회수하는 과정에서 반복 사이의 추가가 일시 중지될 수 있습니다.
청크형 프리필 스케줄링 설계는 청크형 프리필을 사용해 긴 프롬프트가 서빙 반복을 독점하지 못하도록 합니다. 이 메커니즘은 수요 부족이 아니라 프리필 경계, KV 할당 또는 요청 선점과 연관된 공백을 식별합니다. 자동화가 이를 따르기 전에 중간 결과를 계속 검토할 수 있어야 합니다.
GPU 공백이 출력 길이가 아니라 프롬프트 길이에 따라 커진다면 프리필 스케줄링이 더 유력한 원인입니다. 공백이 캐시 압박이나 축출과 함께 나타난다면 큐가 가득 차 있어도 메모리 추가가 원인입니다. 이러한 경계는 현실적인 작동 조건에서 별도로 측정해야 합니다.
CPU 공급과 장치 간 동기화로 커널이 굶을 수 있습니다
토큰화, 샘플링, 스케줄러 결정, 텐서 메타데이터, 호스트-장치 복사, 분산 집단 통신, 로깅은 주 커널 외부에서 발생합니다. CPU 스레드가 포화되거나 차단 동기화가 발생하면 유효한 배치 사이에서 GPU가 대기할 수 있습니다. 여러 소스가 제한된 컨텍스트를 놓고 경쟁할 때 이러한 결과가 실제로 나타납니다.
프리필-디코드 간섭에 관한 연구는 간섭을 줄이고 지연 시간 목표를 충족하기 위해 프리필과 디코드 리소스를 분리합니다. 이 결과는 하나의 사용률 그래프에 스케줄러, 호스트, 통신, 가속기의 동작이 모두 결합되어 있음을 다시 보여 줍니다. 이 종속성은 최종 인터페이스에 명시적으로 남겨야 합니다.
실패 경계는 짧은 샘플링 간격이 정상적인 커널 경계를 사용률 0으로 보고하는 경우입니다. 트레이스나 하드웨어 카운터로 공백을 확인하세요. 대시보드 평균화로 인해 초당 토큰 수를 줄이지 않는 겉보기 저하가 생길 수 있습니다.
큐, 스케줄러, 커널 타임라인을 정렬하세요
대기 중인 요청, 추가된 요청과 실행 중인 요청, 반복당 프롬프트 및 디코드 토큰, 사용 가능한 KV 블록, 선점, CPU 스케줄러 시간, 토큰화, 샘플링, 복사, 집단 통신, 커널 실행 공백, GPU 클록, 출력 처리량을 기록하면서 안정적인 도착과 순간적으로 몰리는 도착을 통제된 조건에서 재현하세요.
연속 배칭 동작과 패턴을 비교한 다음 도착률, 프롬프트 길이, 청크형 프리필 크기, 캐시 예산, CPU 선호도를 한 번에 하나씩 변경하세요. 모델, 양자화, 지연 시간 목표는 유지하세요. 따라서 결과는 원래의 근거와 대조하여 확인해야 합니다.
튜닝하기 전에 각 저하를 수요 없음, 추가 정지, 프리필 간섭, 캐시 압박, 호스트 기아, 동기화 중 하나로 분류하세요. 원인이 있는 경계를 최적화해야 합니다. 더 큰 배치를 강제로 사용해도 빈 큐나 차단된 호스트 스레드는 해결할 수 없습니다.
추천 제품
기술 및 AI 허브
더 읽어보기
AI 에이전트 플래너가 이미 완료한 단계를 반복하는 원인은 무엇인가?
상태 지속성, 완료 증거, 도구 결과 파싱, 컨텍스트 유지, 재시도, 재계획 및 중지 조건을 통해 반복되는 플래너 단계를 추적하세요.
AI 에이전트 하위 프로세스 내부에서만 권한 오류가 발생하는 원인은 무엇인가요?
서브프로세스에서만 발생하는 거부를 진단하려면 부모와 자식의 ID, 파일 시스템 뷰, 환경, 기능, 보안 정책, 실행 파일 경로를 비교하세요.
하드웨어 트랜스코딩과 비디오 AI를 함께 실행할 때 CPU 포화가 발생하는 원인은 무엇인가요?
코덱 오프로딩, 픽셀 변환, 프레임 복사, AI 전처리, 오디오, 자막, 스토리지 및 프로세스 스케줄링 전반에서 CPU 포화 상태를 추적하세요.
