KV 캐시에 얼마나 많은 메모리를 할당해야 할까요?

메모리에 남는 것 설명하기

자기회귀 생성 중에는 이미 처리된 토큰의 키와 값을 이후 단계를 위해 보존할 수 있습니다. 이 캐시는 어텐션 층에 속합니다. 따라서 그 볼륨은 파라미터 수뿐 아니라 모델과 보존된 이력에 따라 달라집니다. 대화의 컨텍스트에는 애플리케이션이 추가한 지시문, 이전 메시지, 문서도 포함됩니다.

첫 번째 결정은 운영상의 것입니다: 몇 개의 시퀀스가 활성 상태로 유지되어야 하며, 최대 어느 길이까지인가? 스무 개 요청 큐 중 두 개가 동시에 실행된다고 해서 반드시 스무 개의 상주 캐시를 의미하지는 않습니다. 실제 요청 승인과 생성으로 인해 만들어질 수 있는 추가 시퀀스를 파악하세요.

모델 리비전, 어텐션 층, KV 헤드, 키와 값의 차원, 그 dtype, 캐시 전략을 담은 문서를 준비하세요. 토크나이저와 대화 템플릿 이후의 토큰을 세세요. 문자 수 제한은 이 할당을 설명하지 않습니다.

기술 출처: Hugging Face — 층별 캐시의 작동 방식과 형태

KV 헤드 사용하기, 특히 GQA에서

쿼리 헤드 Q의 수와 KV 헤드의 수는 다를 수 있습니다. 고전적인 멀티 헤드 어텐션에서는 이들이 일치합니다. MQA에서는 단 하나의 KV 헤드가 공유되고, GQA는 여러 Q 헤드를 하나의 KV 헤드 주위로 묶습니다. 해당 필드가 존재할 때 설정에서 num_key_value_heads를 읽고 아키텍처에 대한 그 의미를 확인하세요.

예를 들어, Q 헤드 40개와 KV 헤드 8개는 KV 그룹당 Q 헤드 5개를 이룹니다. 저장되는 캐시 공식에는 40이 아니라 8을 사용합니다. 이 비율이 어텐션의 모든 메모리를 설명하지는 않습니다: 연산이나 변환이 임시 메모리를 만들 수 있습니다.

이미 학습된 모델의 메모리 요구량을 줄이기 위해 이 숫자를 그냥 바꾸지 마세요. 어텐션 스키마는 모델 아키텍처의 일부입니다. 헤드 수가 다른 두 모델은 용량 계산만으로 동등한 변형이 되지 않습니다. 두 모델의 품질은 각각 따로 평가해야 합니다.

기술 출처: Hugging Face — LlamaConfig 필드와 MHA, MQA, GQA 구분 · PyTorch — Q/K/V 차원과 GQA 어텐션 제약

수식과 단위 정리하기

균일한 경우, L은 레이어 수, Hkv는 KV 헤드 수, D는 그 차원, T는 시퀀스당 유지되는 위치 수, B는 시퀀스 수, q는 값당 바이트 수입니다. 계수 2는 K와 V를 셉니다. 이 근사는 키와 값이 같은 차원과 같은 형식이며, 압축이나 프리픽스 공유가 없다고 가정합니다.

최종 결과만 변환하세요: 1 GiB는 1,073,741,824바이트이고, 십진법 1 GB는 1,000,000,000바이트입니다. 반올림이나 단위 변경으로 차이가 가려지지 않도록 기록에는 바이트를 유지하세요.

패딩 없이 길이가 다른 경우에는 B × T를 실제로 저장된 위치의 합으로 바꾸세요. 레이어마다 다른 경우에는 레이어별로 합산하세요. 패딩을 포함한 밀집 저장, 블록 단위 할당 또는 정적 예약은 할당된 슬롯을 세어야 하며, 이는 유효 토큰 수를 초과할 수 있습니다.

기술 출처: Hugging Face — 캐시 텐서 차원 · NIST — 십진 단위와 이진 접두어

실제 예시: 여섯 시퀀스, GPU 측정 없음

40개 레이어, KV 헤드 8개, 차원 128의 가상 아키텍처를 가정해 봅시다. 값당 2바이트의 균일한 캐시를 가정합니다. 각 시퀀스는 최대 3,072개의 입력 토큰과 추가 1,024개 토큰에 대한 예약, 즉 4,096개 위치의 상한을 받습니다. 이는 교육용 가정이며, 실제 모델의 검증된 구성이 아닙니다.

위치당 그리고 시퀀스당 계산된 비용은 2 × 40 × 8 × 128 × 2 = 163,840바이트입니다. 그러면 4,096개 위치의 시퀀스는 671,088,640바이트, 즉 0.625 GiB를 나타냅니다. 6개 시퀀스는 4,026,531,840바이트, 즉 캐시만으로 3.75 GiB를 줍니다.

유지되는 길이를 두 배로 늘리면 이 공식에서 이 항목도 두 배가 됩니다. 다른 모든 가정이 그대로일 때 KV 헤드 8개를 40개로 바꾸면 5배가 됩니다. 이 비율은 실제 모델의 가속, 품질 손실 또는 호환성을 예고하지 않습니다.

캐시 전략에 맞춰 예산 조정하기

동적 캐시는 보존되는 위치에 따라 커집니다. 정적 캐시는 최대 용량을 예약하므로, 시작 시 관찰된 짧은 요청만이 아니라 이 예약을 기준으로 크기를 정하세요. 슬라이딩 윈도 어텐션에서는 일부 레이어가 히스토리를 상한으로 둘 수 있으며, 전체 어텐션 레이어는 별도로 계산해야 합니다.

캐시 양자화와 CPU로의 오프로딩은 모델과 소프트웨어에 따라 달라지는 또 다른 전략입니다. 이들은 저장, 전송 또는 연산 제약을 바꿉니다. 가중치를 양자화했다고 해서 캐시도 같은 형식이라는 것이 증명되지는 않습니다.

캐시 클래스와 그 명시적 매개변수를 기록하세요. 요청이 끝나거나 취소된 뒤 슬롯이 해제되는지도 확인하세요. 짧은 시퀀스와 긴 시퀀스가 섞인 부하에서는 균일한 최대 예약이 실제 유효 콘텐츠의 합보다 더 클 수 있습니다.

기술 출처: Hugging Face — 동적, 정적, 양자화 및 오프로드 캐시

단계별로 대표 부하 검증하기

세 가지 경우를 만드세요. 평소 입력, 예상되는 긴 입력, 허용되는 최대 동시 요청 수입니다. 모델, tokenizer, 템플릿, 생성 한도, 종료 규칙을 고정하세요. 한 번에 하나의 차원만 바꾸세요. 응답이 짧아지거나 문서가 잘리면 수행되는 작업이 달라집니다.

로딩, 입력의 초기 처리, 생성을 각각 따로 측정하세요. 계측된 단계를 기준으로 device를 동기화하고, 시작 시점의 메모리 수준과 피크를 함께 기록하세요. 메모리 방법론은 allocated와 reserved가 왜 더해지지 않으며, 두 최댓값의 차이가 왜 캐시를 분리해내지 못하는지 설명합니다.

검증은 시험된 상한과 허용 가능한 출력으로 귀결되어야 합니다. 완료된 요청의 ID, 오류, 생성 길이, 품질 기준이 그것입니다. 짧은 입력으로 성공한 실행은 최대 동시성을 검증하지 못합니다. 완료 전에 발생한 메모리 오류는 전체 실행에 필요한 요구량의 측정값이 아닙니다.

기술 출처: PyTorch — 선택한 device에서의 작업 동기화 · PyTorch — 메모리 카운터의 범위

선택을 왜곡하는 오류를 배제하기

계산된 캐시를 총 GPU 용량으로 바꾸지 마세요. 가중치, 임시 활성화, 보존되는 출력, 소프트웨어에 대한 분석을 더하세요. 이 볼륨을 카드 수로 자동으로 나누지도 마세요. 레이어나 헤드의 배치는 실제로 구성하고 각 device에서 검증해야 합니다.

IteraGPU Lab 노트북은 어텐션 없는 작은 dense 네트워크에서 계측을 연습하는 예제입니다. 메모리 단계를 읽는 데는 도움이 되지만, 그 context 파라미터는 이 KV 계산을 검증하지 않습니다. 워크로드 명세서와 추론 문서를 사용해 자신의 모델로 시험을 준비하세요.

산술적 볼륨, 실제로 관측된 최댓값, 아직 시험되지 않은 경우를 구분한 뒤에야 각 요금제의 용량을 비교하세요. 대여 요금제는 작업 시간 창을 정리해 줄 뿐, 어떤 컨텍스트 길이나 생성 속도도 보장하지 않습니다.

• Q 헤드와 KV 헤드를 혼동하기: 아키텍처 구성을 다시 확인하세요.
• 프롬프트만 예산에 넣기: 생성과 실제 예약분을 포함하세요.
• '4비트 가중치'를 '4비트 캐시'로 읽기: 두 형식을 모두 확인하세요.
• 동시성 잊기: 실제로 상주하는 시퀀스를 세세요.
• 카드 간 공유 메모리를 약속하기: 실제 배치를 검증하세요.

실용적인 질문