딥시크 V4 인덱서, 6기가바이트 메모리로 백만 토큰까지 밀어붙인 논문

• 딥시크 V3.2와 V4의 압축 희소 어텐션(Compressed Sparse Attention, CSA)에서 인덱서가 먼저 터지는 문제를 정면으로 다룬 논문임

  • CSA는 압축된 키에 대해 점수를 매기고, 쿼리마다 top-k만 골라 희소 어텐션 커널이 읽는 구조임
  • 문제는 공개 구현들이 top-k 전에 [B, S, H_I, T] 형태의 FP32 점수 텐서를 통째로 만들어버린다는 점임
  • 딥시크 V4-Flash 설정에서 인덱서 헤드 H_I=64, 압축 비율 m=4를 쓰면, 시퀀스 길이 S=65,536에서 이 중간 텐서만 256기가바이트까지 커짐

• 논문이 제안한 StreamIndex의 핵심은 “전체 점수표를 만들지 말고, 청크로 나눠 top-k를 계속 병합하자”임

  • 구현은 Triton 기반이고, 중앙 아이디어는 chunked partition-merge top-k 드라이버임
  • 각 청크에서 후보를 줄이고, 그 결과를 병합하면서 최종 top-k를 얻는 방식이라 거대한 전체 중간 텐서를 HBM에 올리지 않음
  • 쉽게 말하면 엑셀 전체를 메모리에 펼친 뒤 정렬하는 게 아니라, 구간별 상위권만 뽑아서 결승전을 시키는 느낌임

sequenceDiagram
    participant 쿼리
    participant 압축키
    participant 스트림인덱서
    participant 병합topk
    participant 희소어텐션
    쿼리->>스트림인덱서: 청크별 점수 계산 요청
    압축키->>스트림인덱서: 압축 키 타일 제공
    스트림인덱서->>병합topk: 청크별 후보 전달
    병합topk->>병합topk: 후보 병합 후 최종 top-k 유지
    병합topk->>희소어텐션: 읽을 키 인덱스 전달
    희소어텐션->>쿼리: 선택된 키만 읽어 결과 계산

• 숫자가 꽤 세다. 논문 기준으로는 “긴 컨텍스트 실험이 메모리 때문에 시작도 못 하는 상태”를 “백만 토큰 단위까지는 돌려볼 수 있는 상태”로 바꾼 셈임

  • 기존 materialize 경로는 S=65,536에서 OOM
  • StreamIndex는 S=1,048,576에서 피크 6.21기가바이트
  • 저자들은 이를 32배 regime extension이라고 표현함
  • 단일 GPU는 엔비디아 H200 기준임

• 정확도 쪽도 그냥 대충 근사한 건 아니라고 주장함

  • 둘 다 메모리에 들어가는 작은 시퀀스에서는 materialize ground truth와 set-overlap recall이 bit-exact였음
  • 청크 크기, 키 타일 크기, top-k를 바꾼 3개의 5점 설계 공간 실험에서도 평균 recall은 반올림 기준 1.0000
  • 모든 셀에서 최소 recall도 0.9980 이상이었다고 밝힘

• TileLang의 파이프라인 어텐션 커널과 붙였을 때도 병목 완화가 드러남

  • S=262,144와 V4-Flash 차원에서 materialize 인덱서와 TileLang 어텐션 조합은 OOM
  • chunked 인덱서와 같은 TileLang 어텐션 조합은 1.97초에 실행됐고, 피크 메모리는 18.56기가바이트였음
  • 여기서 포인트는 어텐션 커널을 새로 빠르게 만들었다는 게 아니라, 어텐션 앞단의 인덱서가 메모리 때문에 막히던 걸 뚫었다는 쪽임

• 그래서 이 논문은 “딥시크 V4가 백만 토큰을 공짜로 처리한다”는 얘기가 아니라, 긴 컨텍스트 LLM 구현에서 중간 텐서를 물리적으로 만들지 않는 게 얼마나 큰 차이를 내는지 보여주는 사례에 가까움
  • 대형 모델 최적화에서 흔히 보이는 패턴임. 알고리즘은 같은데, 메모리 배치와 커널 실행 순서를 바꾸면 아예 불가능하던 실험이 가능해짐
  • 특히 긴 컨텍스트 추론, 검색 증강 생성(RAG), 에이전트 워크로드처럼 컨텍스트 길이가 계속 커지는 쪽에서는 이런 인덱서 최적화가 꽤 중요해질 수 있음

기술 맥락

• 여기서 선택한 건 어텐션 자체를 새로 설계하는 게 아니라, CSA 인덱서가 top-k를 구하는 방식을 바꾸는 거예요. 왜냐하면 기존 방식은 점수 텐서를 전부 만든 다음 줄이는 구조라서, 길이가 조금만 커져도 계산보다 메모리 할당이 먼저 한계에 걸리거든요.

• StreamIndex가 청크 기반 partition-merge top-k를 쓰는 이유는 후보 전체를 한 번에 들고 있을 필요가 없기 때문이에요. 각 청크에서 상위 후보만 남기고 병합하면, 최종 top-k 품질은 거의 유지하면서 HBM에 올라가는 중간 상태를 크게 줄일 수 있어요.

• 대안은 더 큰 GPU를 쓰거나, 압축 비율이나 top-k를 줄이거나, 인덱서 정밀도를 낮추는 쪽일 수 있어요. 그런데 그런 방식은 비용이 늘거나 모델 동작이 바뀔 수 있는데, 이 논문은 같은 V4-Flash 형태 입력에서 실행 방식을 바꿔 메모리 병목을 피했다는 점이 핵심이에요.

• 영향 범위는 모델 전체라기보다 인덱서 레이어에 집중돼 있어요. 그래서 실제 서비스 추론에서 처리량이 얼마나 오를지는 별도 검증이 필요하지만, 긴 컨텍스트 실험을 메모리 부족 없이 돌릴 수 있게 만드는 기반 작업으로는 꽤 의미가 있어요.