동시 부하에서 로컬 LLM 응답이 더 짧아지는 이유는 무엇인가요?

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

Why Do Local LLM Responses Become Shorter Under Concurrent Load? - Zima Store Online

부하가 걸릴 때 서빙 계층이 제한, 데드라인, 선점 또는 요청 실패를 통해 동시성을 확보하는 대신 생성 예산을 줄이면 로컬 LLM의 응답이 짧아집니다.

다른 사용자가 접속했다고 해서 모델이 본질적으로 간결하게 답하기로 결정하는 것은 아닙니다. 프롬프트와 샘플링 상태가 고정되어 있다면 동시성은 주로 대기열과 토큰 처리 시간에 영향을 주어야 합니다. 답변이 짧아진다는 것은 런타임, 게이트웨이, 클라이언트 또는 메모리 관리자가 유효한 중지 조건을 변경했거나, 작업을 취소했거나, 압박이 임계값을 넘은 뒤 스트림의 일부만 반환했다는 의미입니다.

동시성은 KV 메모리를 확장하고 서빙 제한을 활성화합니다

활성 시퀀스마다 유지되는 컨텍스트와 생성된 토큰에 따라 증가하는 KV 캐시 블록이 필요합니다. 여러 요청이 하나의 가속기를 공유하면 런타임은 배치를 메모리 한도 안에 유지하기 위해 최대 출력을 낮추거나, 요청을 거부하거나, 시퀀스를 선점하거나, 블록을 스왑할 수 있습니다.

페이지 기반 KV 캐시 할당을 사용하는 서빙 설계는 페이지 단위 KV 블록으로 단편화를 줄이고 더 높은 동시성을 지원합니다. 이 방식은 용량을 향상시키지만, 동시에 실행 중인 각 시퀀스가 완료되거나 제거될 때까지 계속 증가하는 메모리 할당량을 소비한다는 점도 분명히 보여줍니다.

게이트웨이는 요청별 또는 전역 토큰 예산을 별도로 적용할 수 있습니다. 이 예산이 가용 용량, 우선순위 또는 대기열 깊이에서 계산된다면 모델 가중치와 샘플링 매개변수가 변하지 않은 것처럼 보여도 동일한 프롬프트가 서로 다른 최대 출력 길이를 받게 됩니다.

데드라인과 선점은 유효해 보이는 부분 답변을 반환할 수 있습니다

대화형 시스템은 흔히 실제 경과 시간 데드라인, 유휴 스트림 타임아웃 또는 클라이언트 취소를 적용합니다. 부하가 걸려 토큰 간 전달 속도가 느려지면 의미상 답변의 더 이른 지점에서 이러한 제한에 도달하며, 일부 API는 눈에 띄는 오류 대신 이미 생성된 토큰을 반환합니다.

청크 단위 프리필 방식은 프롬프트 처리를 더 작은 청크로 나누어 긴 프리필이 디코드를 차단하지 않도록 합니다. 이 연구는 서로 다른 요청이 압박을 가하는 상황에서 스케줄링 변경이 첫 토큰까지의 시간과 토큰 간 지연 시간에 어떤 영향을 주는지 보여줍니다. 이러한 차이는 이후 가정 내 테스트에서도 확인할 수 있어야 합니다.

엔진에 따라 선점은 요청을 나중에 재개할 수 있도록 보존하거나, 요청을 다시 시작하거나, 중단할 수 있습니다. 일시 중지 중 클라이언트 연결이 끊기면 서버는 취소를 기록하는 반면, 인터페이스에는 문법적으로는 자연스럽지만 불완전한 접두부가 완료된 응답처럼 표시될 수 있습니다.

샘플링만으로는 부하와 안정적인 상관관계가 나타나지 않아야 합니다

확률적 디코딩은 온도와 무작위 시드가 다를 때 자연스럽게 다양한 길이의 결과를 생성합니다. 소규모 표본에서는 이러한 변동이 부하와 겹칠 수 있지만, 공유 상태, 적응형 정책 또는 소프트웨어 결함이 디코딩 경로를 변경하지 않는 한 동시성에는 직접적인 의미 신호가 없습니다.

SLO 인식 스케줄링 연구는 토큰 간 시간 목표를 보호하면서 라우팅과 스케줄링을 모델링합니다. 처리량, TTFT 및 디코드 데드라인을 분리하면 용량 정책을 모델 출력 품질과 별도로 측정해야 하는 이유가 분명해집니다. 자동화를 적용하기 전에 중간 결과를 확인할 수 있어야 합니다.

중지 메타데이터를 확인하기 전에 스케줄러를 탓하는 것이 실패 경계입니다. 시퀀스 종료 토큰, 명시적인 길이 제한, 클라이언트 취소, 서버 데드라인, OOM 오류 및 전송 연결 끊김은 서로 다른 원인입니다. 부하 메커니즘을 뒷받침하려면 통제된 반복 테스트에서 길이가 일관되게 변하고 중지 사유도 일치해야 합니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

고정된 동시성 단계에서 길이와 중지 사유를 비교하세요

동시 요청을 1개, 2개, 4개, 8개로 설정해 고정된 프롬프트와 시드를 반복 실행합니다. 요청된 최대 토큰 수, 실제 출력 토큰 수, 완료 사유, 대기 시간, TTFT, 토큰 간 지연 시간, 실제 경과 시간 데드라인, 클라이언트 연결 끊김, 선점 횟수, KV 바이트 수, 사용 가능한 VRAM 및 서버 오류를 기록합니다.

메모리 동작을 동시 작업 부하 한도와 연관 지은 다음, 게이트웨이 타임아웃 없이 고정된 요청 수락 한도를 적용해 반복합니다. 동시성이 유일하게 의도한 변경 사항이 되도록 프롬프트, 템플릿, 샘플링 및 클라이언트 코드를 유지합니다. 이러한 경계는 현실적인 운영 조건에서 별도로 측정해야 합니다.

완료율 또는 의미 범위가 공표된 예산보다 먼저 감소한다면 짧아진 출력을 서빙 결함으로 간주합니다. 지연 시간만 증가하고 완료 사유가 계속 EOS라면 시드가 고정된 시험을 더 수행하고, 타임아웃이나 제한이 지배적이라면 해당 정책을 명시적으로 공개하고 그에 맞게 용량을 설정합니다.