HiSparse 로컬 KV 오프로드 아키텍처

HiSparse 로컬 KV 오프로드 아키텍처 (HiSparse local KV offload architecture)

상태: 실험적 (experimental)

요약 (The short version)

세 가지 서로 다른 역할이 있습니다:

  • 일반 KV 캐시 시스템이 GPU 블록 풀과 테이블을 관리합니다.
  • HiSparseCoordinator가 논리 호스트 블록, 소스 프리픽스 정체성, 호스트/GPU 상주 전이를 관리합니다.
  • HiSparseConnector가 스케줄러와 워커 사이의 상주(residency) 작업을 운반합니다. HiSparseWorker가 전송을 조정하고, 캐시별 HiSparseRuntime 객체가 호스트/핫 뷰와 GPU 교체 상태를 소유합니다.

워커 쪽 객체는 논리 블록을 할당하거나 해제하지 않습니다. HMA는 상주·핫 그룹이 공유하는 GPU 할당을 제공하며, CPU 메모리나 KV 정체성은 관리하지 않습니다.

request ────► HiSparseCoordinator ── source blocks + residency policy
                    │
                    ├──► KV cache manager ── resident/hot GPU leases (HMA)
                    │
                    └──► HiSparseConnector ── host bytes + copies + GPU LRU

이것은 로컬 KV 커넥터입니다. P/D 또는 다른 오프로드 커넥터도 구성된 경우 MultiConnector가 HiSparseConnector와 함께 그것을 구성합니다.

host_pool_gib는 HiSparseConnector에 구성되며, 데이터 병렬 레플리카당 사용 가능한 host-cache 용량이지 노드 전체 메모리 예산이 아닙니다. 텐서 병렬 랭크는 그 논리 캐시의 복제된 뷰를 보유합니다. 그 뷰는 랭크별 개인 백킹 또는 하나의 공유 물리 할당을 사용할 수 있으며 구성된 용량은 바뀌지 않습니다. 따라서 물리 호스트 메모리 소비는 토폴로지·구현 의존적입니다. 예산이 완전한 호스트 블록으로 내림 처리되므로 실현 용량은 약간 더 작을 수 있습니다.

출처: 문서

본문

소유권 (Ownership)

항목 소유자 "소유" 의미
HiSparse 소스 및 프리픽스 정체성 HiSparseCoordinator 토큰을 논리 호스트 블록에 매핑
상주 GPU 블록 임대 일반 KV 캐시 관리자 HMA 블록 할당·해제
상주 블록 테이블 일반 KV 캐시 관리자 attention에 상주 페이지 위치 안내
상주 전이 HiSparseCoordinator 지우기-전-해제(spill-before-free) 트랜잭션 계획
논리 호스트 블록 할당 HiSparseCoordinator 별도 CPU 블록 풀과 생명주기 소유
Pinned host-pool 생명주기 HiSparseWorker 워커 전역 백킹·해체
캐시별 호스트 뷰와 핫 내용 HiSparseRuntime host/hot 스토리지 바인딩 및 캐시 관리자 제공 핫 임대 채움
핫 행 맵과 LRU HiSparseRuntime GPU에서 히트 해결·희생자 선택
상주 캐시 경로 HiSparseCacheHandle 상주 또는 host/hot 해석을 attention에 노출
Sparse attention attention 백엔드 디바이스 캐시와 물리 행 ID 소비
HMA 할당자 GPU 용량 제공, KV 의미 없음

핵심 구분은 논리 할당과 내용입니다. HiSparseCoordinator는 호스트 블록 ID와 그 요청/프리픽스 연관을 소유합니다. HiSparseWorker와 그 캐시별 런타임은 대응하는 바이트를 소유합니다. 일반 캐시 관리자는 디바이스 풀만 봅니다. 소스 그룹은 block_pool_id=None입니다. 디바이스 풀 소비자는 인덱싱 전에 그것을 좁혀야 하므로 호스트 소유권이 숫자 GPU 풀로 가장할 수 없습니다.

단일 노드 MP 텐서 병렬의 경우 모든 TP 워커가 같은 pinned 호스트 풀을 매핑하고 같은 블록·레이어 오프셋을 사용합니다. MLA 소스 KV는 TP 랭크에 걸쳐 복제되므로 랭크당 하나의 복사본 대신 물리 복사본 하나를 저장합니다. TP rank 0이 공유 호스트 풀에 쓰고, 피어들은 읽기 전에 그 IPC 이벤트를 기다립니다. 다른 실행기·병렬 레이아웃은 랭크별 개인 풀을 유지합니다.

공유 레이아웃은 레플리카별 논리 용량을 하나의 물리 풀로 뒷받침하고, 개인 레이아웃은 랭크당 하나의 물리 풀을 할당합니다. 물리 풀 크기에는 블록 스트라이드 정렬이 포함됩니다.

코드 경계 (Code boundary)

scheduler process                           worker process

HiSparseConnector                          HiSparseConnector
  └─ HiSparseCoordinator                         └─ HiSparseWorker
       │                                          │
       │ connector metadata                       ├─ host bytes
       │ - page transfers                         ├─ copy scheduling
       │ - block-table replacements               └─ per-layer hot state
       └───────────────────────────────────────────────►│
       ◄──────── connector worker metadata ─────────────┘
                    enqueued and completed transfer IDs

명령은 kv_connector_metadata로 이동하고, 전송 업데이트는 KVConnectorOutput.kv_connector_worker_meta로 돌아옵니다. 모델 러너는 페이지 전송을 해석하지 않습니다. Enqueue 승인 덕분에 스케줄러가 스트림 순서대로 소스 임대를 해제할 수 있고, 완료 승인은 복사된 호스트 페이지를 게시합니다.

상주 디바이스 페이지 (Resident device pages)

상주 페이지는 의도적으로 HiSparseRuntime 밖에 있습니다.

KV-cache 초기화는 HiSparseWorker를 구성하기 전에 캐시 관리자 할당을 attention-facing HiSparseCacheHandle에 바인딩합니다. 그 핸들의 런타임은 전송 계획에 필요한 상주 소스 인덱스를 유지합니다. 두 번째 상주 객체나 등록 래퍼는 없습니다.

KV cache setup
   │
   ├─ bind resident allocation ──► HiSparseCacheHandle
   │                               cache + block table + slot mapping
   │
   ├─ bind host/hot allocation ──► HiSparseRuntime
   │                               host + hot + GPU LRU
   │
   └─ register cache handles ────► HiSparseWorker
                                   step-level transfers

HiSparseWorker registers the same HiSparseCacheHandle objects directly

Attention 구성은 각 레이어를 실제로 인덱서를 소유하는 가장 최근 레이어에 연결합니다. 이것은 팔로워의 중복 LRU 텐서를 GPU 메모리 프로파일링 전에 해제합니다. 캐시 바인딩은 스토리지만 붙이며 물리 패킹된 텐서 순서에서 의미론적 그룹을 추론하지 않습니다. 구성 커서는 워커의 pinned 상태와 함께 폐기됩니다.

모든 HiSparse decode 배치는 같은 융합 리졸버를 사용합니다. 상주 페이지를 먼저 확인하고, 그다음 핫 행, 그다음 pinned 호스트 메모리를 확인합니다. 상주 히트는 핫-LRU 조회나 호스트 복사 전에 커널 안에서 종료됩니다. 프레임워크 수준의 상주 경로나 별도 CUDA graph는 없습니다. decode 경로에 CPU 결정이 추가되지 않습니다. 리졸버는 attention 메타데이터의 기존 graph-stable 요청 매핑을 소비하며, 워커나 개별 캐시 핸들 모두 중복 매핑을 유지하지 않습니다.

추측 디코딩은 각 검증 스텝을 순서대로 해결·소비합니다. 각 스텝은 요청의 핫 캐시 상태를 공유하면서 별개의 재생 가능한 플랜 행을 받으므로, 나중 스텝이 이전 스텝이 소비하기 전에 핫 행을 재사용할 수 없습니다.

P/D import 대상 (P/D import target)

디코더는 요청당 한 번 일반 캐시 허용(admission) 계산에서 착지 대상(landing target)을 선택합니다. 가져온 프리픽스 전체가 디바이스 풀에 맞으면 NIXL이 그것을 상주 GPU 페이지로 직접 전송합니다. 그렇지 않고 고정 host-backed GPU 공간과 호스트 소스 블록이 맞으면 요청은 호스트 티어로 import됩니다. 컨텍스트 길이 임계값이나 다른 휴리스틱은 없으며, 용량을 기다리는 요청은 admission 재시도 전체에서 그 선택을 유지합니다.

호스트 import는 등록된 호스트 메모리로 복사하기 전에 경계가 있는 decoder-GPU 스테이징 풀을 읽습니다. 즉시 필요한 페이지는 그 복사 동안 상주 목적지로 미러링됩니다. 두 착지 대상 모두 위에서 설명한 같은 융합 decode 리졸버를 사용합니다.

인덱서 KV 오프로딩 (Indexer KV offloading)

HiSparse는 인덱서 KV의 개인 CPU 복사본을 유지하지 않습니다. 인덱서는 일반 prefix-cacheable GPU 캐시 그룹으로 남습니다. HiSparse와 함께 OffloadingConnector가 구성되면 그 그룹을 일반 KV 오프로딩 경로로 저장·복원합니다. HiSparse는 희소 MLA 호스트 티어만 계속 소유합니다.

두 프리픽스 소스는 히트 길이가 다를 수 있습니다. HiSparse 호스트 프리픽스가 GPU 상주 인덱서 프리픽스를 넘어 확장되면, 스케줄러는 OffloadingConnector에 호스트 프리픽스 경계에서 제한된 빠진 인덱서 접미사만 복원하도록 요청합니다. 그 접미사를 사용할 수 없으면 모든 그룹은 공유하는 더 짧은 프리픽스로 폴백합니다. NIXL P/D 전송은 인덱서 KV를 계속 GPU 그룹에 직접 둡니다.

Spill 트랜잭션 (Spill transaction)

상주 블록은 내용이 워커에 건네지기 전까지 재사용할 수 없습니다.

HiSparseCoordinator                            HiSparseWorker
          │                                     │
          │ pin source and destination leases   │
          │── SparseKVPageTransfer ─────────────►│
          │                                     │ enqueue GPU-to-host copy
          │◄── enqueued transfer ID ────────────│
          │ replace resident table entry        │
          │ release resident lease to HMA       │
          │                                     │ copy reaches its event
          │◄── completed transfer ID ───────────│
          │ mark host page valid                │
          │ release destination host lease      │

"Enqueued"는 복사가 워커 스트림에 들어갔음을 뜻합니다. 스트림 순서 덕분에 상주 GPU 블록을 이후 작업에 재사용해도 안전하지만 호스트 페이지는 아직 게시되지 않았습니다. "Completed"는 워커가 복사 이벤트를 관찰했음을 뜻하며, 그때서야 코디네이터가 호스트 페이지를 프리픽스 재사용용으로 게시하고 목적지 임대를 해제합니다. 별도의 host-write 이벤트가 가속기에 이미 큐잉된 쓰기로부터 직접 CPU 리더를 보호합니다.

워커 전송은 자신의 전송 ID와 물리 복사 좌표만 담습니다. 요청 정체성과 논리 페이지 상태는 스케줄러에 남습니다.

핫 조회와 LRU (Hot lookup and LRU)

NVIDIA CUDA 경로는 교체를 전적으로 가속기에서 유지합니다:

top-K logical positions
        │
        ▼
resident page? ── yes ──► resident physical row
        │ no
        ▼
hot row? ──────── yes ──► existing hot physical row + update GPU LRU
        │ no
        ▼
choose GPU LRU victim ──► copy pinned host row ──► hot physical row

ROCm은 현재 지원되지 않습니다. 융합 HiSparse 캐시 연산이 CUDA 커널로만 구현되기 때문입니다. 향후 플랫폼별 워커가 같은 명령·출력·캐시 해석 경계를 제공할 수 있습니다.

주요 클래스 (Main classes)

클래스 상속 / 구현 책임
HiSparseCoordinator 일반 스케줄러 컴포넌트 호스트 할당, 소스 프리픽스, 상주 임대, spill 상태 머신
HiSparseConnector KVConnectorBase_V1, SupportsHMA 스케줄러/워커 메타데이터와 생명주기 경계
HiSparseResidentManager SingleTypeKVCacheManager host-backed 구멍이 있는 일반 블록 풀 북키핑
PagedCacheView 불변 데이터 객체 공유 상주/핫 HMA 텐서 바인딩
HiSparseWorker connector 소유 워커 컴포넌트 워커 전역 전송 스케줄링·호스트 풀 생명주기
HiSparseRuntime 일반 worker 소유 컴포넌트 캐시별 host/hot 텐서, GPU LRU, 융합 해석
HiSparseCacheHandle 일반 attention 컴포넌트 상주 뷰와 융합 캐시 해석
SparseKVOffloadCommand dataclass 불투명한 스케줄러→워커 작업

성능 불변식 (Performance invariants)

  • 상주 히트는 융합 리졸버 안에서 핫-LRU 조회와 호스트 복사를 건너뜁니다.
  • 핫 조회, 희생자 선택, LRU 갱신은 GPU에 유지됩니다.
  • 핫 미스는 여전히 등록된 pinned 호스트 메모리에서 직접 복사합니다.
  • Top-K 해석은 attention 호출 안에 머물며 graph 캡처 가능을 유지합니다.
  • 호환 레이어는 여전히 하나의 미스 플랜을 공유합니다.
  • 인덱스 공유 팔로워는 메모리 크기 조정 전에 개인 LRU 상태를 해제합니다.
  • 인덱서 KV는 일반 KV 오프로더가 구성되지 않는 한 HiSparse가 건드리지 않습니다.
  • 상주·핫 임대는 여전히 하나의 패킹된 HMA 할당을 공유할 수 있습니다.
  • 디바이스 스칼라 readback이나 CPU/디바이스 메타데이터 왕복이 추가되지 않습니다.
  • 추상화는 융합 커널을 감쌀 뿐 또 다른 커널 실행을 추가하지 않습니다.
  • HiSparse가 비활성화되면 스케줄러는 오프로드 명령이나 빈 갱신 테이블을 구성하지 않습니다.

플랫폼 특정으로 남는 것 (What remains platform-specific)

명령/결과와 attention 레이어 경계는 공유할 수 있습니다. 호스트 할당자, 복사 구현, 핫 레이아웃, 교체 정책은 플랫폼 특정으로 남아야 합니다. NVIDIA는 현재 가속기 LRU와 융합 host/hot 커널을 사용합니다. ROCm은 현재 지원되지 않습니다. AMD나 다른 가속기 백엔드는 NVIDIA 정책을 공유 경계에 강요하지 않고 자체 워커를 구현할 수 있습니다.

더 알아보기 (Learn more)