프롬프트 처리가 로컬 AI 토큰 생성을 앞설 수 있는 이유 彩神争霸快三

가속기는 많은 입력 토큰을 병렬로 평가하지만 출력 토큰은 순차적으로 디코딩해야 하므로, 프롬프트 처리가 토큰 생성보다 빠를 수 있습니다.

홈 AI 대시보드에는 초당 수백 또는 수천 개의 프롬프트 토큰을 처리한다고 표시되지만, 스트리밍 출력은 훨씬 낮은 속도로 도착할 수 있습니다. 이 수치들은 서로 모순되는 측정값이 아니라 서로 다른 실행 단계를 나타냅니다. 프리필은 제공된 컨텍스트를 하나의 블록으로 처리해 어텐션 상태를 구축하는 반면, 디코드는 한 번에 새 토큰 하나를 받아들이기 위해 모델을 반복적으로 실행합니다. 두 속도의 차이는 프롬프트 길이, 모델 크기, 메모리 대역폭, 배칭, 캐시 배치 방식, 그리고 백그라운드 요청이 동일한 가속기를 함께 사용하는지 여부에 따라 달라집니다.

프리필과 디코드는 서로 다른 계산 문제를 해결합니다

프롬프트 처리는 흔히 프리필이라고 하며, 입력 시퀀스를 평가하고 이후 생성을 위해 필요한 KV 상태를 생성합니다. 디코드는 이 초기 상태가 만들어진 후에 시작되며, 시퀀스를 토큰 단위로 하나씩 확장합니다.

LLM 서빙 연구에서는 계산 집약적인 프리필과 메모리 대역폭 제한적인 디코드를 하드웨어 동작이 서로 다른 별개의 단계로 설명합니다.

따라서 동일한 모델이 높은 프리필 처리량과 훨씬 낮은 출력 토큰 처리량을 동시에 보여도 고장이 발생한 것은 아닙니다. 각 지표는 서로 다른 실행 경로를 통과하는 토큰을 집계합니다.

프롬프트 토큰은 대규모 병렬 행렬에서 평가할 수 있습니다

프리필 중에는 여러 쿼리 위치를 한 번에 사용할 수 있습니다. 행렬 곱셈은 시퀀스, 배치, 헤드, 은닉 차원에 걸쳐 작업을 결합할 수 있으므로, 가속기가 충분한 병렬 연산을 수행하며 바쁘게 작동할 수 있습니다.

FlashAttention은 느린 디바이스 메모리에 전체 어텐션 행렬을 반복적으로 생성하지 않는 타일 방식의 어텐션 계산으로 어텐션 오버헤드를 줄입니다.

프롬프트가 길어지면 전체 프리필 작업량이 증가하지만, 메모리 용량, 커널 한계 또는 어텐션 복잡도가 지배적인 요소가 되기 전까지는 연산 활용도를 높일 수도 있습니다.

이는 입력 블록 전체에 대한 처리량이지, 서버가 매초 동일한 수의 독립적인 출력 토큰을 생성할 수 있다는 의미는 아닙니다.

디코드는 현재 토큰이 결정되기 전에 다음 토큰을 확정할 수 없습니다

자기회귀 생성은 토큰 하나를 샘플링하거나 선택해 시퀀스에 추가한 다음, 해당 결과를 조건으로 다시 모델을 실행합니다. 다음에 받아들일 토큰은 미리 알 수 없습니다.

DistServe는 두 단계를 분리합니다. 디코드 반복은 모델 가중치와 활성 KV 상태에 반복적으로 접근하면서 각 시퀀스에 소량의 새 출력만 생성하기 때문입니다.

여러 사용자를 배칭하면 여러 디코드 시퀀스를 병렬화할 수 있지만, 하나의 대화는 여전히 서로 의존하는 토큰 결정의 연쇄를 따라 진행됩니다.

추측 디코딩은 여러 초안 후보를 한꺼번에 검증할 수 있지만, 후보를 미리 받아들이지 않는 일반적인 디코드는 여전히 순차적으로 진행됩니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

높은 프롬프트 처리량으로도 첫 토큰이 나오기까지 오래 걸릴 수 있습니다

초당 토큰 수는 완료된 프롬프트 작업량을 프롬프트 크기로 나눈 값입니다. 매우 긴 컨텍스트는 높은 처리량을 보이면서도 첫 번째 생성 토큰이 나타나기까지 몇 초가 걸릴 수 있습니다.

ZimaSpace는 AI 지연 시간 단계에 대한 설명에서 로딩, 프롬프트 평가, 생성을 구분합니다. 모델이 워밍업된 상태라면 다시 로드하는 지연은 사라지지만, 큰 프롬프트를 평가하는 비용까지 없어지지는 않습니다.

따라서 프리필에서는 첫 토큰까지 걸리는 시간이 더 적절한 대화형 지표입니다. 초당 프롬프트 토큰 수는 런타임이 서로 다른 입력 길이를 얼마나 효율적으로 처리하는지 비교할 때 유용합니다.

긴 프리필은 이미 디코딩 중인 사용자의 속도를 늦출 수 있습니다

연산량이 많은 문서 프롬프트가 다른 사용자에게 스트리밍 토큰을 전달하는 동안 동일한 가속기에 들어올 수 있습니다. 런타임이 두 작업을 제어 없이 결합하면, 대규모 프리필로 인해 디코드 반복 시간이 길어질 수 있습니다.

DistServe는 두 단계를 같은 위치에 배치하고 함께 스케줄링할 때 발생하는 강한 프리필-디코드 간섭을 보고합니다.

서버는 여전히 높은 전체 사용률을 표시할 수 있지만, 활성 채팅에서는 토큰 사이의 간격이 더 길어집니다. 처리량과 사용자가 체감하는 출력의 부드러움은 서로 반대 방향으로 움직일 수 있습니다.

하드웨어와 런타임이 지원한다면 별도의 워커, 단계 인식 스케줄링 또는 디코드 기회 예약을 통해 대화형 출력의 안정성을 높일 수 있습니다.

청킹은 프리필 효율 일부를 희생해 응답성을 개선합니다

런타임은 하나의 긴 프롬프트를 더 작은 청크로 나누고 이 청크를 디코드 작업과 번갈아 처리할 수 있습니다. 프롬프트는 더 많은 스케줄링 차례를 거치지만, 하나의 프리필이 매우 긴 단일 반복을 독점하는 일은 줄어듭니다.

Sarathi-Serve는 유용한 배칭 기회를 유지하면서 간섭을 줄이기 위해 청크 단위 프리필을 사용합니다.

최적의 청크 크기는 프롬프트 길이, 모델 아키텍처, 가속기 용량, 활성 대화의 지연 시간 목표에 따라 달라집니다.

프롬프트 처리 시간, 첫 토큰까지 걸리는 시간, 토큰 간 시간, 초당 출력 토큰 수를 서로 구분해 측정하세요. 헤드라인 처리량이 더 낮은 단계가 사용자가 가장 오래 기다리는 원인이라고 반드시 단정할 수는 없습니다.