문서 하나에 관한 질문이 이어질 때 접두부를 같은 GPU에 두면 주의력 키·값을 다시 계산하는 일을 줄일 수 있다. Flame에 vLLM을 임베딩한 서비스는 짧고 유한한 요청 묶음에서 튜닝을 거친 뒤 독립 실행형 vLLM 중앙값 처리량의 99% 이상에 도달했다. 다만 이 결과는 일반적인 1% 오버헤드 보장을 뜻하지 않으며, Flame의 데이터 인식 스케줄러가 이점을 줬다는 점도 입증하지 않는다.

두 시스템에서 작업자를 고정해 접두부 캐시 재사용을 높인 뒤, 배치 크기 확대와 비동기 요청 전달, 손실 없는 입력 압축을 적용했다. 확인 실험은 작업 부하별로 새 실행 쌍 다섯 개를 비교했다. 문서 재사용이 없을 때 Flame의 중앙값 처리량은 독립 실행형 vLLM보다 0.55% 낮았고, 접두부 재사용 시에는 0.86% 낮았다. 재사용 비교의 개별 쌍 두 개는 목표인 기준 처리량의 99%를 밑돌았으며, 최저치는 2.03% 낮았다.

최종 처리량 비교는 B200 GPU 두 개, GPU당 vLLM 엔진 하나, 같은 모델 가중치와 토큰 입력을 사용했다. 독립 실행형 vLLM은 각 접두부를 안정적인 복제본에 보내는 HTTP 요청을 받았고, Flame은 작업 경로를 통해 지속형 작업자 세션 두 곳에 배치를 전달했다. 재사용 없는 작업 부하에서는 초당 요청 수가 vLLM 7.628, Flame 7.586이었다. 접두부 재사용 작업 부하에서는 각각 28.595와 28.350이었다. 각 값은 다섯 차례 시험의 중앙값이며, 재사용 비교에서 다섯 쌍의 처리량 비율은 97.97~99.37%였다.

확인 요청 3,200건은 입력, 커버리지, 출력 길이, 작업자 배치 검사를 모두 통과했고 각 요청은 새 토큰 16개를 생성했다. 모델 로딩과 초기 세션 설정, 워밍업은 측정에서 제외했다. 라우팅, 요청 전송, 압축·해제, 추론, 완료 과정은 측정에 포함했다.

접두부 배치와 요청 전달

초기 비교에서 접두부 친화 라우팅을 적용하자 재사용 작업 부하의 중앙값 처리량은 vLLM에서 77.5%, Flame에서 73.4% 높아졌다. 두 시스템 모두 입력 토큰의 74.86%를 캐시에서 처리했다. 그래도 Flame은 접두부 고정 라우팅을 적용한 vLLM보다 8.1% 낮았다. 이 측정은 구성별로 세 차례 반복했고, 네 구성은 같은 GPU 두 대에서 번갈아 실행했다.

접두부 친화 라우팅은 모델 토큰 ID로 256토큰 블록을 해시하고, 앞선 접두부와 연결해 첫 1,024토큰까지 식별한다. 모델 리비전도 해시 입력에 포함한다. 제한된 클라이언트 맵은 새 접두부를 추정 프리필 작업량 누적치가 가장 낮은 샤드에 배정한 뒤 배정을 유지한다. 이 맵은 문서 라벨이나 이후 요청을 읽지 않는다. 다만 실제 캐시 적중 여부는 배정만으로 확인할 수 없으며, 반환된 캐시 토큰 수로 재사용을 측정했다.

Flame의 기존 어댑터는 동기식 배치를 LLM.generate()에 전달해 현재 호출이 끝날 때까지 다음 작업이 대기했다. 반면 독립 실행형 vLLM의 HTTP 서버는 개별 요청을 계속 받아들였다. 이에 배치 한도를 128개, 배치 구성 대기 시간을 10밀리초로 설정하고, 비동기 API와 zlib 입력 압축을 적용했다. 압축은 재사용 요청 묶음의 인코딩된 입력 총량을 6,210,432바이트에서 387,795바이트로 줄였다. 서비스는 추론 전에 원래 토큰 입력을 복원했다. 이 효과는 입력의 압축 가능성에 달려 있으며, 실험에 사용한 뉴스 텍스트는 특히 압축이 잘 됐다.

비동기 어댑터는 한 이벤트 루프에서 배치의 요청을 동시에 전달하고 입력 순서대로 최종 출력을 반환한다. Flame의 세션 관리자와 실행 관리자 작업 경로는 그대로 사용하며, Flame 작업자 안의 호출은 여전히 직렬 처리된다. 첫 토큰 스트리밍 이벤트도 제공하지 않는다. 최종 설정은 재사용 없는 작업 부하에서 기준보다 0.55%, 재사용 작업 부하에서 0.86% 낮았다. 앞선 비동기·압축 단계는 재사용 부하에서 99% 목표를 근소하게 놓쳤다. 최종 단계는 다른 GPU 쌍과 새 vLLM 기준을 사용했으므로 추가 변경 사항 각각의 효과를 분리해 보여주지는 않는다.

최종 설정에는 작업자 초기화 뒤 오래 유지되는 파이썬 객체의 힙을 고정하는 변경도 포함했다. 새 요청 객체에 대한 일반적인 순환 가비지 수집은 계속 활성화했고, 엔진을 종료하기 전에 힙 고정을 해제했다. 단일 시험 진단에서 추론 중 작업자별 가비지 수집 정지 시간의 최댓값 합계는 8.80밀리초에서 4.59밀리초로 줄었다. 관측된 정지 시간은 짧았으며 처리량 변동 전체를 설명하지는 않는다.

실험 조건과 한계

두 경로는 공개 BF16 Llama 3.1 8B Instruct 체크포인트의 같은 고정 리비전을 사용했다. 추론 프로세스에는 같은 런타임 이미지를 적용했고, Flame SDK를 추가해도 추론 패키지는 바뀌지 않았다. vLLM은 0.28.0, Torch는 2.13.0+cu130이었다. 각 경로는 B200 GPU 두 개와 공유 CPU 20개 제한을 사용했고, 복제본 두 개에 텐서 병렬도 1을 적용했다. 실행은 BF16, eager 실행, Triton 어텐션으로 이뤄졌다. 컨텍스트 한도는 32,768, 동시 시퀀스 한도는 64, 배치 토큰 한도는 8,192였으며 접두부 캐시는 활성화했다.

실험은 뉴스 텍스트에서 만든 섞인 요청 기록 두 개를 사용했다. 각 입력은 약 8K 토큰 문서 접두부와 질문으로 구성됐다. 첫 기록은 문서 64개에 질문 하나씩, 총 64건으로 문서 재사용이 없었다. 두 번째는 문서마다 질문 네 개씩, 총 256건으로 접두부를 재사용했다. 각 기록은 한 번의 유한한 요청 묶음으로 도착했다. 요청 수와 동시성이 달라 두 기록의 처리량 차이만으로 접두부 재사용 효과를 분리할 수는 없다.

각 사례는 엔진을 새로 시작해 완전한 워밍업을 두 차례 진행했다. 워밍업에서는 토큰 ID를 어휘 안에서 이동해 입력 길이와 접두부 관계는 유지하되 측정 대상 접두부는 사용하지 않았다. 최종 단계에서는 논리 샤드를 양쪽 시스템의 같은 물리 GPU UUID에 고정하고, 실제 작업자 기록으로 매핑을 확인했다. Flame은 메모리 기반 세션 관리자 상태(storage: none)와 RAM 기반 객체 캐시를 사용했다. 세션 관리자가 재시작되면 메모리 상태가 사라진다. 이는 실험용 설정이며 운영 환경의 영속성 권고가 아니다.

접두부 재사용 시험은 합성 로컬리티 실험으로, MLPerf 결과를 구성하거나 Server 지연 시간 기준 준수를 입증하지 않는다. 별도의 개발용 통제 시험은 MLPerf Inference v5.1.1 Llama 3.1 8B 작업 부하와 LoadGen 소스를 사용하고 교차 쿼리 접두부 캐싱을 껐다. 성능 풀 13,368개 샘플을 사용해 600초 이상 실행한 Offline 시험에서 독립 실행형 vLLM은 초당 53.38건, Flame 배치 32는 32.41건, 배치 64는 53.41건을 처리했고 모두 LoadGen 성능 결과가 VALID였다.

이들은 각 한 차례의 개발 시험이다. 기존 Flame 서비스는 vLLM 0.31.0을 사용했고 독립 실행 경로는 0.28.0을 사용했으며, 물리 GPU 배정도 달랐다. 따라서 프레임워크 오버헤드를 분리하거나 반복 가능한 성능 우위를 입증할 수 없다. 저장된 출력은 개발용 ROUGE와 출력 길이 기준을 통과했지만, 공식 정확도 시험이나 모델 동등성 검증, 적합성 시험을 대신하지 않는다.

이번 비교가 보여주는 것은 두 유한 요청 묶음에서 튜닝한 Flame 서비스가 독립 실행형 vLLM 중앙값 처리량의 99% 이상에 도달했다는 점이다. 접두부 배치는 두 경로 모두에 도움이 됐다. 남은 차이는 요청 전달, 직렬화, 프로토콜, 작업자 동작에 달려 있어 스케줄러만의 영향으로 돌릴 수 없다.

독립 실행형 클라이언트는 요청 묶음이 풀린 시점부터 완료 지연 시간을 쟀고, Flame은 각 요청 제출 시점부터 배치 구성과 대기 시간을 포함해 측정했다. 배치 단위 출력과 함께 보면 스트리밍 지연 시간이 동등하다고 주장할 수 없다. 지속적인 요청 도착, 길이와 편차가 큰 답변, 인기 접두부의 대기열, 캐시 축출, 작업자 재시작, 시작 비용은 별도 측정이 필요하다.

최종 단계에서는 진단 요청 768건과 독립 확인 요청 3,200건을 검증했다. 런타임 소스와 모델·이미지 리비전, 배치 분포, 입력 해시, 출력 토큰 ID, 쌍별 점수, 정리 기록을 벤치마크 하네스와 함께 보관했다. 동시 HTTP 클라이언트 초기화의 영향을 받은 초기 vLLM 로컬리티 점수는 제외하고, 측정 전에 공유 연결 객체 하나를 준비하도록 수정했다. 하네스 테스트 38개는 모두 통과했다. GPU 두 대를 해제하고 임시 팟을 삭제했으며, 운영 Flame 설정은 바꾸지 않았다. 측정 자료는 개발 벤치마크 결과이고 전체 원시 자료는 로컬에 보관돼 아직 공개 아카이브로 제공되지 않는다.