트랜스포머(Transformer)의 prefill은 토큰 전반에 걸쳐 가중치(weights)를 재사용하며, 행렬 곱셈(matrix multiplication)과 활성화 데이터 이동(activation data movement)이 지배적입니다. 단일 토큰 디코드(single-token decode)는 재사용성이 제한적이며, 가중치와 KV-캐시(KV-cache) 읽기가 지배적입니다. 우리는 NVIDIA Hopper GPU를 위한 Llama 스타일 트랜스포머 블록의 CUDA 구현체인 FUTRANSFORMER를 제시합니다. 이 구현은 추론에 CODA의 GEMM-plus-epilogue 접근 방식을 적용하여, 직접적인 KV-캐시 배치(direct KV-cache placement)를 추가하고, 고정된 RMSNorm 게인을 가중치에 접기(folding)하며, 지연 스케일링(delayed scaling)을 통해 FP8 출력을 직접 작성하고, 패딩 없이 prefill을 지원합니다. 디코드 단계에서는 INT4 투영 가중치(INT4 projection weights)와 INT4 KV-캐시 복사본을 사용합니다. 가중치와 키는 텐서 코어 프래그먼트 레이아웃(Tensor Core fragment layouts)을 따라가므로, 전체 중간 타일(full intermediate tiles) 없이 MMA 연산자(MMA operands)로 직접 양자화 해제(dequantization)됩니다. 블록 대각선 하다마드 변환(block-diagonal Hadamard transform)은 이상치 채널(outlier channels)로부터 캐시 양자화 오차를 줄여줍니다.
H100 한 장 기준으로, prefill 속도는 컴파일된 PyTorch FP8보다 최대 1.48배 빠르며 1.29 PFLOP/s에 도달합니다. 8B 크기의 SwiGLU를 사용한 게이트/업 투영(gate/up projection)의 경우, 우리의 BF16 경로는 CODA보다 1.13배 빠릅니다. FP8 경로의 경우, 평가된 BF16 CODA 경로보다 2.02-2.18배 빠릅니다. 배치 크기 1~32에서 8B 및 70B 크기를 기준으로 할 때, INT4 디코드는 각 지점별로 PyTorch의 BF16 및 INT4 블록 중 더 빠른 것보다 1.3-2.4배 빠릅니다: 컴파일된 CUDA 그래프 기반 BF16보다 2.1-3.3배 빠르고, 단일 쿼리 행(single query row)을 대상으로 하는 PyTorch의 INT4 투영 커널을 사용한 동일 블록보다 1.3-6.3배 빠르며, 배치 크기 32에서는 BF16에 뒤처집니다. 또한 FP8 경로보다 31-51% 더 빠릅니다.
완전한 Llama-3.1-8B 디코드는 배치 1에서 단계당 2.8ms가 소요되는 반면, 컴파일된 트랜스포머 구현체는 8.1ms가 소요됩니다. 모든 WikiText-2 토큰을 INT4 가중치 경로로 디코드했을 때, 원형 근사치(round-to-nearest) 가중치를 사용하면 퍼플렉서티(perplexity)가 6.24에서 7.23으로 증가하고, 동일한 형식의 GPTQ를 사용하면 6.99로 증가합니다. 회전된 INT4 캐시는 0.20을 추가합니다. 이 커널들은 양자화 참조 계산과 0.001 퍼플렉서티 이내로 일치합니다.