계층형 KV 캐시로 설계하는 호스트 자원 연동 추론 서빙
HBM·호스트 RAM·디스크로 KV 캐시를 계층화할 때의 용량 산정, 이동 정책, 대역 계측과 운영 통제를 정리한다.
2026-09-02 · 최초 발행 2026-08-05
DeepSeek-V4-Flash를 단일 MI300X에서 프로덕션으로 구동한 구성에는 304 CU와 약 192GiB HBM 외에 CPU KV 티어용 RAM 약 235GiB, 디스크 약 500GB가 제시됐다. 모델 캐시만 약 156GB를 차지한다. 추론 서빙의 용량 계획이 가속기 메모리에서 끝나지 않고, 호스트 메모리와 저장장치까지 함께 계산해야 하는 이유다.
KV 캐시를 호스트 메모리로 내리면 HBM을 비울 수 있다. 대신 계층 사이의 전송 대역이 병목으로 바뀔 수 있다. 이 구성에서 핵심은 계층을 늘리는 일 자체가 아니라, 어떤 요청의 캐시를 어느 계층에 둘지 결정하는 정책이다.
HBM 밖으로 확장되는 KV 캐시 용량
가속기 메모리는 빠르지만 제한적이고 비용이 높다. KV 캐시가 HBM을 오래 점유하면 처리할 수 있는 컨텍스트와 동시 요청 수가 함께 줄어든다. 이를 피하기 위해 HBM을 첫 계층으로, 호스트 RAM을 다음 계층으로, 디스크를 마지막 계층으로 두고 접근 빈도에 따라 KV 블록을 배치할 수 있다.
MI300X의 HBM3 대역은 5.3TB/s 수준이다. 호스트 메모리 접근은 이보다 한 자릿수 이상 느리므로, 계층 간 이동은 즉시 성능 비용으로 이어진다. 실제 구성 안정화 과정에서는 CPU KV 동기화도 별도 수정 대상으로 지목됐다.
활성 디코딩 구간의 KV는 HBM에 유지한다. 대기 상태이거나 다시 쓸 수 있는 접두 KV는 호스트 RAM으로 내리는 편이 맞다. 디스크는 재계산 비용이 매우 큰 장문 접두 캐시에 한정해야 한다. 일반 KV를 디스크에 두면 지연이 사용자 체감 범위를 넘어설 수 있다.
캐시 위치를 결정하는 운영 정책
승격과 강등은 요청 상태와 최근 접근 시점을 함께 기준으로 삼아야 한다. 단순 LRU는 긴 컨텍스트 요청에 불리하게 작동할 수 있다. 또한 캐시를 옮기는 일에도 예산이 필요하다. 이동이 잦아지면 절약한 메모리보다 전송 비용이 더 커진다.
긴 컨텍스트 요청은 별도 정책 대상으로 다뤄야 한다. KV 점유량이 큰 요청을 일반 요청과 같은 규칙으로 처리하면, 일부 요청이 계층 자원을 독점할 수 있다. 긴 요청 전용 슬롯 수를 제한해 다른 요청의 예측 가능성을 지키는 방식이 필요하다.
호스트 메모리도 독립된 운영 자원이다. CPU KV 티어가 235GiB를 사용하는 구성에서 다른 프로세스가 메모리를 요구하면 스왑이 발생해 성능이 무너질 수 있다. 티어 크기는 상한으로 고정하고, 호스트 메모리 사용량에는 임계 알림을 둬 경합을 미리 감지한다.
디스크 계층에서는 수명과 총량을 함께 관리한다. 제한이 없으면 500GB 여유가 예고 없이 소진될 수 있다. 모델 캐시 156GB와 KV 디스크 캐시가 같은 볼륨을 공유할 경우에도 상호 잠식이 생기므로 볼륨을 분리한다.
계측값으로 계층 정책을 조정한다
계층 사이의 초당 이동량과 이동 대기 시간은 상시 수집 대상이다. 전송 대역 포화는 지연이 급증하는 직접 원인이며, 이동량이 어느 요청 유형에 집중되는지도 따로 집계해야 한다. 원인 요청을 분리하지 못하면 정책을 고치기 어렵다.
적중률 역시 계층별로 봐야 한다. 전체 적중률만으로는 호스트 RAM이나 디스크 계층이 실제로 기여하는지 판단할 수 없다. 접두 캐시 적중률은 시스템 프롬프트와 템플릿 설계에 영향을 받으므로, 프롬프트가 바뀌면 다시 측정한다.
HBM 적중, 호스트 적중, 디스크 적중, 재계산의 지연 분포도 각각 분리한다. 평균 지연만 보면 계층 정책의 효과를 판별할 수 없다.
처음에는 HBM과 호스트 RAM으로 구성한 뒤, 계측을 통해 필요성이 확인될 때 디스크 계층을 더하는 편이 낫다. 계층이 늘어날수록 정책 복잡도도 커진다. 접두 캐시 재사용률이 낮은 워크로드라면 하위 계층의 이득은 거의 없으므로, 도입 전 재사용률 측정이 먼저다.
부하는 짧은 요청 다수, 긴 요청 소수, 접두 재사용이 높은 부하로 나눠 계층별 지연을 측정한다. 재계산 지연을 기준선으로 두고 하위 계층 적중이 실제 이득인지 판정한다.
전송 대역이 포화됐을 때의 조치 순서도 미리 정한다. 이동 예산 축소, 긴 요청 슬롯 축소, 동시성 축소 순이 일반적이다. 조치 뒤 회복 여부를 판정할 지표와 기준값도 함께 정의해야 한다.
워크로드에 따라 달라지는 선택
| 구분 | 계층형 KV 캐시 | 가속기 메모리 전용 |
|---|---|---|
| 수용 컨텍스트 | 큼 | 제한적 |
| 접근 지연 | 계층별 차등 | 균일하게 짧음 |
| 전송 대역 부담 | 발생 | 없음 |
| 동시성 | 높음 | 낮음 |
| 정책 복잡도 | 높음 | 낮음 |
| 호스트 자원 요건 | 큼 | 작음 |
계층형 구성은 활성 구간에만 가속기 메모리를 쓰고 나머지를 호스트로 내린다. 수용 가능한 컨텍스트와 동시 요청 수를 크게 늘리고, 접두 캐시 재사용으로 재계산도 줄일 수 있다. 반면 계층 이동이 전송 대역을 쓰기 때문에 긴 컨텍스트 요청의 지연 편차가 커질 수 있으며, 승격·강등 정책이 추가 관리 대상이 된다.
가속기 메모리 전용 구성은 모든 접근이 균일하게 빠르고 이동 정책이 없어 지연을 예측하기 쉽다. 호스트 자원 요건도 작다. 하지만 KV가 HBM을 점유하면서 동시성 상한이 낮아지고, 긴 컨텍스트 요청 하나가 다른 요청의 자리를 차지한다.
접두 재사용률이 높은 워크로드에서는 계층형 구성이 명확히 유리하다. 반대로 매 요청이 서로 다른 짧은 프롬프트라면 이동 비용만 발생할 수 있다. 구성 선택 전에 워크로드 특성을 측정해야 하는 이유다.
CPU 티어 확대는 호스트 메모리 단가가 HBM보다 훨씬 낮아 같은 예산으로 더 큰 용량을 확보할 수 있고, 기존 노드 구성을 유지한 채 접두 캐시 보관 용량을 늘릴 수 있다. 다만 활성 구간의 성능은 개선되지 않으며 호스트 메모리 경합과 스왑 위험이 생긴다.
가속기를 늘리면 활성 구간 성능과 처리량을 직접 높이고, 계층 이동 없이 용량을 확장할 수 있다. 단가가 높고 다중 가속기 구성에서는 통신과 장애 조합이 늘어 운영 복잡도가 커진다. 병목이 활성 디코딩 처리량이라면 가속기 증설이, KV 보관 용량이라면 CPU 티어 확대가 맞다.
디스크 캐시는 장문 접두를 재계산하지 않아 첫 토큰 생성 시간을 크게 줄이고, 재계산에 쓰일 가속기 연산을 다른 요청에 돌릴 수 있다. 대신 디스크 읽기 지연, 저장 용량과 수명 관리, 디스크에 남는 KV 내용의 보안·개인정보 처리 요건을 감수해야 한다. 접두 길이가 길고 재사용이 반복되는 경우에만 이득이 있으므로, 접두 길이 분포와 재사용 빈도를 측정해 임계 길이 이상에만 적용하는 구성이 합리적이다.
용량 계획과 통제를 함께 설계한다
CPU KV 티어에 235GiB 규모를 배정하는 구성은 호스트 메모리 사양도 가속기와 함께 조달해야 한다는 뜻이다. 같은 호스트에서 다른 워크로드를 함께 돌리지 않는 것을 기본 원칙으로 두는 편이 안전하다.
디스크 계층을 사용한다면 용량뿐 아니라 순차 읽기 대역과 지연도 요건으로 명시해야 한다. 모델 캐시 볼륨과 KV 디스크 캐시 볼륨의 분리도 이 단계에서 결정한다.
초기 승격·강등 기준과 이동 예산은 보수적으로 설정하고 계측 결과를 바탕으로 조정한다. 공격적인 초기값은 대역 포화를 유발할 수 있다. 긴 컨텍스트 전용 슬롯도 처음부터 제한해야 한다.
호스트 티어 크기나 디스크 캐시 총량 상한을 바꾸는 일은 용량 재산정을 전제로 승인 대상으로 둔다. KV 캐시에 담기는 내용의 보존 기간과 삭제 요건은 개인정보 처리 기준과 정합하게 규정한다. 계층형 KV 캐시는 메모리 계층 구조와 교체 알고리즘, 저장 자원 격리, 성능 사고 대응 절차가 한 지점에서 만나는 운영 설계다.
모델 서빙 자원 표기는 가속기 메모리 단독에서 호스트 메모리와 저장장치 병기로 확장되는 흐름에 있다. 접두 캐시 계층화는 추론 프레임워크의 기본 기능으로 편입되고 정책 파라미터가 표준화되는 방향이며, 호스트 메모리 사양도 추론 노드 조달 요건에 가속기와 함께 포함되는 흐름이다. KV 캐시 내용의 보존 기간과 삭제 요건 역시 개인정보 처리 요건에 포함되는 방향이다.
Sources
- ryanzhou/deepseek-v4-flash-mi300x | GitHub
- Bringing up DeepSeek-V4-Flash on AMD MI300X | Fergus Finn
- DeepSeek V4 Flash on a Single AMD MI300X | Hacker News
- DeepSeek-V4-Flash Hardware Requirements & Specs | LocalOps
- Run DeepSeek V4 Flash 0731 Locally: Hardware Guide | Kingy
- deepseek-ai/DeepSeek-V4-Flash | vLLM Recipes
- DeepSeek V4-Flash Local Hardware Guide 2026 | Compute Market