HiCache, 분산 모델 서빙의 캐시 조정

LMSYS 팀은 HiCache가 재사용 가능한 키-값(KV) 캐시 데이터를 문맥 병렬화(작업을 여러 순위 단위로 나누는 방식), 파이프라인 병렬화, 투기적 디코딩, 프리필·디코드 분리 환경에서 조정하는 방식을 설명했습니다. Iflytek Astron MaaS의 실제 운영 요청은 보통 입력 토큰 30K~200K개를 포함하며, 일부 요청은 1M개에 이릅니다. 팀은 외부 저장소와 HiCache를 추가한 뒤 캐시 적중률이 약 30%에서 95%로 올랐고, 첫 토큰까지 걸리는 중앙값 시간이 3초 미만이 됐다고 밝혔습니다.

문맥 병렬화에서는 각 순위가 같은 논리적 기수 트리와 페이지 ID를 유지하고, 각 GPU는 자신에게 할당된 KV 페이지를 저장합니다. 페이지의 논리 ID를 이용해 별도의 페이지별 조회표 없이 소유 순위와 로컬 주소를 계산합니다. 요청이 캐시된 접두부를 늘릴 때 할당기는 페이지 소유권의 순환 순서를 유지하고, 서로 호환되지 않는 순환이 섞이는 삽입은 거부합니다. 어텐션이 캐시 접두부를 읽기 전 각 순위는 한 번에 한 레이어씩 페이지를 임시 버퍼에 모읍니다. 번갈아 사용하는 버퍼 두 개를 두어 다음 레이어의 수집과 현재 레이어의 계산이 겹치게 합니다. 지원되는 구성에서는 NCCL의 SM 커널 대신 GPU 복사 엔진이 페이지를 모읍니다.

HiCache는 실제 물리 주소가 달라져도 각 페이지를 소유 순위에서 백업하고 복원합니다. 각 레이어에서 페이지 수집은 복원이 끝난 뒤 진행되며, 어텐션은 데이터 수집을 기다립니다. GLM-5.2-NVFP4, TP4/CP4, EAGLE MTP, 정적 메모리 비율 0.9를 사용한 운영 비교에서 각 배포 환경은 NVIDIA GB300 GPU 4개를 갖춘 프리필 엔진 2개를 사용했습니다. 기준 구성과 샤딩 구성 모두 엔진당 목표 호스트 캐시 용량은 960 GB였으며, 샤딩 구성은 순위 4개에 각각 240 GB를 배정했습니다. 3시간 동안 두 구성은 캐시 계층의 귀속이 확인된 요청을 각각 약 24.5K건 처리했습니다. 평균 입력 길이는 136K~137K 토큰이었고 총 입력량 차이는 1.8%였습니다. 샤딩 적용 시 GPU 토큰 적중률은 40.48%포인트 상승했고, GPU와 호스트를 합친 적중률은 약 93%를 유지했습니다. 호스트가 처리한 토큰은 1.712B에서 0.322B로 줄어 81.2% 감소했고, 프리필 대기열 평균 시간은 56.2%, 프리필 순방향 처리 평균 시간은 31.3% 낮아졌습니다. 팀은 레이어별 수집에 추가 오버헤드가 발생하며 문맥 병렬 샤딩은 최적화가 진행 중이라고 밝혔습니다.

파이프라인 병렬화에서는 전송 완료 시점이 달라도 각 단계가 캐시 변경을 같은 순서로 적용해야 합니다. pp_sync 프로토콜은 첫 단계가 준비된 전송 건수에 합의한 뒤 그 수를 후속 단계에 전달합니다. 각 단계는 선택된 전송이 끝날 때까지 기다린 다음 캐시 기록을 갱신합니다. 외부 저장소를 쓸 때는 백그라운드 스레드가 순위 전체에서 로드된 접두부 중 가장 짧은 길이에 합의하고, 순서가 정해진 확인 큐를 통해 진행 상황을 알립니다. 각 단계는 캐시를 확인할 때 같은 확인 메시지를 소비하므로, 이후 데이터 읽기가 이미 진행됐더라도 요청마다 동일한 캐시 접두부를 사용합니다.

투기적 디코딩에서는 대상 모델의 접두부와 함께 초안 모델의 KV, 인덱서 버퍼, 별도로 관리되는 순환 상태도 복원해야 합니다. HiCache의 패킹 레이아웃은 행 모양, 데이터 유형, 토큰 인덱싱이 호환될 때 슬롯 매핑을 공유합니다. 사이드카 레이아웃은 호스트 풀을 따로 유지하고 대상 KV나 SWA처럼 선언된 출처에서 전송 인덱스를 계산합니다. 두 방식 모두 버퍼를 읽기 전에 전송 완료 이벤트가 초안 상태 복사까지 포함하도록 합니다.

LMSYS 팀은 HiCache가 재사용 가능한 키-값(KV) 캐시 데이터를 문맥 병렬화(작업을 여러 순위 단위로 나누는 방식), 파이프라인 병렬화, 투기적 디코딩, 프리필·디코드 분리 환경에서 조정하는 방식을 설명했습니다. Iflytek Astron MaaS의 실제 운영 요청은 보통 입력 토큰 30K~200K개를 포함하며, 일부 요청은 1M개에 이릅니다. 팀은 외부 저장소와 HiCache를 추가한 뒤 캐시 적중률이 약 30%에서 95%로 올랐고, 첫 토큰까지 걸리는 중앙값 시간이 3초 미만이 됐다고 밝혔습니다.

문맥 병렬화에서는 각 순위가 같은 논리적 기수 트리와 페이지 ID를 유지하고, 각 GPU는 자신에게 할당된 KV 페이지를 저장합니다. 페이지의 논리 ID를 이용해 별도의 페이지별 조회표 없이 소유 순위와 로컬 주소를 계산합니다. 요청이 캐시된 접두부를 늘릴 때 할당기는 페이지 소유권의 순환 순서를 유지하고, 서로 호환되지 않는 순환이 섞이는 삽입은 거부합니다. 어텐션이 캐시 접두부를 읽기 전 각 순위는 한 번에 한 레이어씩 페이지를 임시 버퍼에 모읍니다. 번갈아 사용하는 버퍼 두 개를 두어 다음 레이어의 수집과 현재 레이어의 계산이 겹치게 합니다. 지원되는 구성에서는 NCCL의 SM 커널 대신 GPU 복사 엔진이 페이지를 모읍니다.

HiCache는 실제 물리 주소가 달라져도 각 페이지를 소유 순위에서 백업하고 복원합니다. 각 레이어에서 페이지 수집은 복원이 끝난 뒤 진행되며, 어텐션은 데이터 수집을 기다립니다. GLM-5.2-NVFP4, TP4/CP4, EAGLE MTP, 정적 메모리 비율 0.9를 사용한 운영 비교에서 각 배포 환경은 NVIDIA GB300 GPU 4개를 갖춘 프리필 엔진 2개를 사용했습니다. 기준 구성과 샤딩 구성 모두 엔진당 목표 호스트 캐시 용량은 960 GB였으며, 샤딩 구성은 순위 4개에 각각 240 GB를 배정했습니다. 3시간 동안 두 구성은 캐시 계층의 귀속이 확인된 요청을 각각 약 24.5K건 처리했습니다. 평균 입력 길이는 136K~137K 토큰이었고 총 입력량 차이는 1.8%였습니다. 샤딩 적용 시 GPU 토큰 적중률은 40.48%포인트 상승했고, GPU와 호스트를 합친 적중률은 약 93%를 유지했습니다. 호스트가 처리한 토큰은 1.712B에서 0.322B로 줄어 81.2% 감소했고, 프리필 대기열 평균 시간은 56.2%, 프리필 순방향 처리 평균 시간은 31.3% 낮아졌습니다. 팀은 레이어별 수집에 추가 오버헤드가 발생하며 문맥 병렬 샤딩은 최적화가 진행 중이라고 밝혔습니다.

파이프라인 병렬화에서는 전송 완료 시점이 달라도 각 단계가 캐시 변경을 같은 순서로 적용해야 합니다. pp_sync 프로토콜은 첫 단계가 준비된 전송 건수에 합의한 뒤 그 수를 후속 단계에 전달합니다. 각 단계는 선택된 전송이 끝날 때까지 기다린 다음 캐시 기록을 갱신합니다. 외부 저장소를 쓸 때는 백그라운드 스레드가 순위 전체에서 로드된 접두부 중 가장 짧은 길이에 합의하고, 순서가 정해진 확인 큐를 통해 진행 상황을 알립니다. 각 단계는 캐시를 확인할 때 같은 확인 메시지를 소비하므로, 이후 데이터 읽기가 이미 진행됐더라도 요청마다 동일한 캐시 접두부를 사용합니다.

투기적 디코딩에서는 대상 모델의 접두부와 함께 초안 모델의 KV, 인덱서 버퍼, 별도로 관리되는 순환 상태도 복원해야 합니다. HiCache의 패킹 레이아웃은 행 모양, 데이터 유형, 토큰 인덱싱이 호환될 때 슬롯 매핑을 공유합니다. 사이드카 레이아웃은 호스트 풀을 따로 유지하고 대상 KV나 SWA처럼 선언된 출처에서 전송 인덱스를 계산합니다. 두 방식 모두 버퍼를 읽기 전에 전송 완료 이벤트가 초안 상태 복사까지 포함하도록 합니다.