SonicBoom: RTX 3050 노트북에서 동일한 양자화 커널을 사용한 52 tok/s 디코드 성능 비교 (llama.cpp: 45)

저는 C++/CUDA로 작성되었고, C ABI를 가지며 스택 어디에도 Python이 없는 네이티브 텐서 런타임인 SonicBoom을 구축해 왔습니다. 방금 v0.0.1 태그를 지정했으며, 첫 번째 목표는 소비자용 GPU에서의 로컬 LLM 추론입니다.

(Gemma 4 E4B-it Q3_K_M 모델을 RTX 3050 노트북에서 테스트한 결과. 두 런타임 모두 동일한 GGUF 파일을 같은 장치에서 사용했으며, llama.cpp는 커밋 43fe9c64281 버전을 사용했습니다):

       SonicBoom                    llama.cpp

디코드 (tg64) 51.65 tok/s 45.20 tok/s
디코드 @ 깊이 2048 47.13 tok/s 45.21 tok/s
프리필 4100 토큰 1051 tok/s ~1944 tok/s
TTFT, 4000-토큰 프리픽스 + 100개 새 토큰 503 ms (프리픽스 재사용)

이것이 중요한 이유: 양자화된 matmul 커널(MMVQ/MMQ)은 ggml에서 포팅되었기 때문에, 이 커널들은 llama.cpp가 사용하는 것과 동일합니다. 14%의 디코드 성능 향상은 전적으로 그 위 계층에서 비롯됩니다. 그래프 플래너는 모델이 실행되기 전에 코드를 재작성합니다: 활성화 값(activations)은 한 번 양자화되어 재사용되고, 정규화(norm) 및 활성화 값은 양자화와 융합되며, 불필요한 계산은 제거되고, 각 디코드 단계는 단일 CUDA Graph로 캡처되고 재생됩니다. ggml에서 파생된 코드는 핵심의 약 8%만을 차지합니다. 나머지는 런타임입니다.

프리픽스 재사용은 정확합니다: 후속 토큰(continuation)은 전체 프리필과 토큰 단위로 동일하여, 다중 턴 채팅 및 코드 어시스턴트 워크로드에 비용 효율적입니다.

아직 할 수 없는 것들:

프리필 성능은 llama.cpp의 절반 수준입니다. 이는 실제 배치 경로(int8 tensor-core와 cuBLAS)이지만, 더 개선할 부분이 있습니다.
검증된 모델: Gemma 4 E4B 하나만 테스트되었습니다. 양자화 형식은 Q3_K, Q4_K, Q5_K만 지원하므로, Hugging Face의 대부분의 Q4_K_M 파일은 아직 로드되지 않습니다. 왜냐하면 이 파일들은 Q6_K와 Q8_0을 혼합하고 있기 때문입니다. 해당 형식들과 함께 Qwen도 다음 목표입니다.

sm_86 (RTX 30 시리즈)에서만 테스트되었으며, 샘플링은 그리디(greedy) 방식만 지원합니다.

아직 llama.cpp를 대체할 수 있는 형태로 나오지는 않았습니다. v0.0.1의 목적은 아키텍처가 작동한다는 것을 보여주는 것입니다. 즉, 그래프 컴파일러(graph compiler)가 동일한 커널 위에 놓이게 되면, 남은 성능 향상은 더 많은 수동으로 작성된 커널에서 오는 것이 아니라 컴파일러 자체에서 오게 됩니다. 로드맵 상의 다음 기능들은 MLIR GPU 코드 생성기(MLIR GPU codegen), 추측 디코딩(speculative decoding) 등이며, 다양한 포맷 지원이 추가될 예정입니다.

GPL-3.0. 벤치마크 조건, 재현 명령어 및 모델 sha256은 README에 있습니다:
https://github.com/hardenedlinux/SonicBoom