한 줄 정의

FP4 Indexer는 DeepGEMM의 2026년 4월 공개 릴리스에 들어간 인덱서용 저정밀 커널 경로야. 여기서 인덱서는 문서를 검색하는 색인이 아니라, 어텐션 안에서 어떤 이전 토큰을 더 자세히 볼지 먼저 점수화하는 lightning indexer 쪽을 가리켜.

조금 더 좁히면, FP4 Indexer는 MQA logits를 다루는 기능이야. MQA는 여러 query head가 key-value를 함께 쓰는 attention 변형이고, logits는 후보 token과 현재 token 사이의 점수야. DeepSeek Sparse Attention에서 먼저 후보를 고르는 단계와 맞닿아 있다고 보면 돼.

그래서 이 이름이 보일 때 바로 볼 건 “새 모델인가?”가 아니야. FP8과 FP4처럼 낮은 정밀도를 써서 긴 문맥 후보 선택, paged KV cache, Multi-Token Prediction(MTP) 지원을 GPU 커널 안에서 얼마나 가볍게 처리하려는지야.

어떻게 작동하나

공식 README의 V3.2 MQA kernels for the indexer 설명은 non-paged 버전과 paged 버전 두 갈래를 보여줘. non-paged 예시인 fp8_mqa_logits는 q, kv, weights, 시작/끝 위치 텐서 2개, clean_logits까지 6개 입력을 받고, 출력은 [seq_len, seq_len_kv] 모양의 token-to-token logits야.

계산 흐름은 단순하게 보면 이래. 현재 query token이 볼 수 있는 key token 구간을 돌면서 q @ kv 점수를 만들고, ReLU와 head별 weight를 거친 뒤 하나의 scalar 점수로 줄여. 그 점수 행렬을 다음 단계가 받아서 “실제 attention에 더 비싼 계산을 쓸 후보”를 고르는 거야.

PR #304에서 추가된 FP4 Indexer는 이 MQA logits 경로를 FP4까지 낮춘 방향으로 읽으면 돼. vLLM 문서도 fp8_fp4_mqa_logits와 fp8_fp4_paged_mqa_logits를 공개 API로 보여주고, FP8 query는 scale을 None으로 두고 MXFP4 query는 packed block-scale tensor를 같이 넘긴다고 설명해. 그러니까 FP4 Indexer는 “인덱싱 알고리즘 하나”라기보다, 인덱서 점수 계산을 FP8/FP4 dispatch 안으로 넣는 커널 경로에 가까워.

왜 중요한가

긴 문맥 모델에서는 모든 token 쌍을 끝까지 다 보는 dense attention이 너무 비싸져. DeepSeek Sparse Attention은 먼저 lightning indexer로 후보를 추리고, 그다음 더 작은 top-k key-value에 실제 attention 계산을 쓰는 2단 구조를 잡아. FP4 Indexer는 바로 그 앞단 점수 계산을 더 싸게 만들려는 쪽에 있어.

MTP도 같이 봐야 해. MTP는 다음 토큰 1개만 보는 대신 여러 토큰을 한 번에 예측해 디코딩 단계를 줄이려는 방식이야. PR #304가 FP4 Indexer를 larger MTP support와 같이 적은 이유도 여기 있어. 여러 다음 토큰 후보를 다루면 인덱서가 봐야 하는 query 수와 KV cache 접근이 늘 수 있고, 그 경로가 무거우면 MTP의 이득을 잡아먹어.

다만 숫자는 조심해서 읽어야 해. 공식 README와 PR #304는 2026-04-16 공개 릴리스 항목으로 FP4 Indexer를 적지만, 독립 재현 성능 숫자를 같이 주지는 않아. PANews가 언급한 EP≤8과 PyTorch≥2.9 제한도 Mega MoE 쪽 조건으로 읽는 게 안전해. FP4 Indexer 자체를 쓸 수 있는지와 Mega MoE를 멀티 프로세스로 돌릴 수 있는지는 같은 문제가 아니야.

주의해서 볼 점

첫째, FP4 Indexer는 RAG나 vector DB의 인덱서가 아니야. 문서를 쪼개고 임베딩해서 검색하는 기능이 아니라, attention 내부에서 token 후보 점수를 계산하는 GPU 커널 경로야. 이름에 indexer가 들어가서 헷갈리기 쉬운데, 실제 위치는 검색 시스템보다 CUDA 커널과 추론 런타임 쪽에 더 가까워.

둘째, FP4는 속도 카드이면서 위험 카드야. 4비트 부동소수점은 메모리 이동과 연산 비용을 줄일 수 있지만, logits 점수가 흔들리면 top-k 후보가 바뀔 수 있어. 후보가 바뀌면 뒤의 attention 계산이 아무리 정확해도 다른 token을 보게 돼. 그래서 tokens/sec만 보지 말고 top-k overlap, 품질 회귀, NaN/Inf, 긴 문맥 실패 케이스를 같이 봐야 해.

셋째, Blackwell과 CUDA 조건을 분리해야 해. DeepGEMM 전체 요구 조건은 README 기준 NVIDIA SM90 또는 SM100 GPU, Python 3.8+, C++20 compiler, PyTorch 2.1+, CUTLASS 4.0+야. 하지만 FP4/MXFP4 경로는 특히 Blackwell/SM100 문맥이 강하니, H100 같은 기존 서버에서 같은 방식으로 이득이 난다고 보면 곤란해.

실무에서 확인할 것

FP4 Indexer를 실제 후보로 보려면 먼저 병목을 재야 해. 긴 문맥 입력에서 MQA logits, top-k selection, paged KV cache 접근 중 어디가 p95 지연을 만들고 있는지 분리해야 해. 전체 응답 시간이 느리다는 말만으로는 FP4 Indexer를 켤 이유가 약해.

작은 실험표는 이렇게 잡는 게 좋아. 같은 모델, 같은 프롬프트 세트, 같은 배치 크기에서 FP8 경로와 FP8/FP4 경로를 나란히 두고 tokens/sec, 첫 토큰 지연, p95 지연, peak memory, top-k overlap, 출력 품질을 비교해. MTP를 쓰는 경우에는 next_n이나 draft token 수를 바꿨을 때 인덱서 비용이 어떻게 변하는지도 따로 봐야 해.

그리고 모델 릴리스 해석은 빼는 편이 안전해. PR #304와 PANews 모두 이 업데이트가 DeepGEMM 개발과 관련된 릴리스라고 선을 긋고 있어. FP4 Indexer는 DeepSeek가 긴 문맥과 저정밀 커널을 더 강하게 밀고 있다는 인프라 신호이지, 그 자체로 새로운 모델 성능을 증명하는 이름은 아니야.