Real-time LLM Inference on Standard GPUs: 3k tokens/s per request

TL;DR Highlight

Kog AI가 8× AMD MI300X에서 요청당 3,000 tokens/s를 달성하는 LLM 추론 엔진을 공개했고, 기존 소프트웨어 스택의 병목을 GPU 메모리 대역폭 최대화로 풀어냈다는 내용이다.

Who Should Read

AI 에이전트 또는 코딩 어시스턴트 서비스를 만들고 있어서 생성 속도가 UX에 직접 영향을 주는 상황의 ML 인프라 엔지니어나 백엔드 개발자.

Core Mechanics

Kog AI가 공개한 Kog Inference Engine(KIE)은 8× AMD MI300X에서 FP16 기준 요청당 3,000 tokens/s, 8× NVIDIA H200에서 2,100 tokens/s를 기록했다. 투기적 디코딩(speculative decoding) 없이 달성한 수치다.
이번 벤치마크는 배치 크기 1(batch size 1), 즉 단일 요청 기준으로 측정한 것이다. 기존 추론 벤치마크가 집계 처리량(aggregate throughput)이나 첫 토큰 응답 시간(TTFT)을 주로 측정했다면, KIE는 요청당 디코딩 속도를 핵심 지표로 삼는다.
AI 에이전트는 '검사 → 계획 → 편집 → 테스트 → 수정' 루프를 순차적으로 돌기 때문에, 단일 요청 디코딩 속도가 전체 워크플로우 속도를 결정한다. 예를 들어 50,000 토큰을 생성해야 할 때 100 tokens/s면 약 8분, 3,000 tokens/s면 20초 이내로 끝난다.
배치 크기 1에서 LLM 디코딩의 병목은 연산(FLOPS)이 아니라 메모리 대역폭(memory bandwidth)이다. 각 토큰 생성 시 모델 가중치 전체를 HBM(고대역폭 메모리)에서 연산 유닛으로 옮겨야 하기 때문에, 속도 상한선이 'effective_memory_bandwidth / (active_weight_bytes + KV cache)'로 결정된다.
FP16 기준으로 가중치 1바이트당 약 1 FLOP/byte의 연산만 발생하는데, H200의 피크 FLOPs/byte 비율은 약 400이다. 즉 GPU 연산 능력은 남아도는데 메모리 대역폭이 발목을 잡는 구조라, 핵심 지표는 MFU(Model FLOP Utilization)가 아닌 MBU(Memory Bandwidth Utilization)다.
현재 기존 추론 스택들이 이 메모리 대역폭 상한에 도달하지 못하는 이유는 소프트웨어 병목 때문이다. KIE는 모델 아키텍처, 런타임 엔진, 저수준 GPU 커널을 단일 지연 최적화 파이프라인으로 공동 설계(co-design)해서 이 상한에 근접했다.
현재 공개된 모델은 2B 파라미터 코딩 특화 모델이며, 대형 MoE(Mixture of Experts, 여러 전문가 네트워크를 조합하는 구조) 서드파티 모델 지원도 유사한 속도로 곧 추가할 예정이다.
AMD MI300X에서 H200보다 높은 속도를 기록한 것은 MI300X의 HBM 메모리 대역폭이 더 높기 때문으로, 메모리 대역폭 최적화 접근법의 효과를 잘 보여준다.

Evidence

2B 모델로 측정한 결과를 프론티어 모델(수백 B 규모)과 비교하는 것은 공정하지 않다는 지적이 있었다. 특히 15,000 tok/s를 주장하는 Taalas 같은 경쟁 서비스와의 비교가 빠져 있다는 점도 문제로 제기됐고, 실제로 의미 있는 비교는 30B 이상 모델에서 해야 한다는 의견이 많았다.
제목의 '스탠다드 GPU'라는 표현에 대해 8× H200이나 8× MI300X는 결코 일반적인 GPU가 아니라는 비판이 댓글에서 여러 번 반복됐다. H200 8장 세트는 수십만 달러짜리 장비라 '표준'이라고 부르기 어렵다는 것.
2B 모델에서 선형 확장성을 보인다고 27B, 70B 이상 모델에서도 같은 성능이 나온다고 가정하는 건 위험하다는 의견이 있었다. 4코어에서 선형 확장성을 보이고 256코어도 같을 거라 가정하는 것, 또는 캐시에 맞는 데이터셋에서의 개선이 멀티 머신 규모로도 유지된다고 가정하는 것과 비슷하다는 비유가 나왔다.
실제로 데모 플레이그라운드를 써본 사람이 '3,400 tok/s짜리 넌센스'를 받았다고 후기를 남겼다. 모델이 틀렸다고 지적해도 틀렸음을 인정하면서 같은 틀린 답을 반복했다고 하며, 속도는 인상적이지만 모델 품질 자체는 아직 한계가 있다는 평가였다.
투기적 디코딩(speculative decoding)이나 블록 확산(block diffusion) 같은 대안적 디코딩 방식이 등장하면서 배치 1 디코딩의 메모리 대역폭 병목이 점차 줄어드는 상황에서, KIE의 커널 실행 오버헤드 및 메모리 전송 최적화가 앞으로도 유효할지 묻는 질문이 있었다. 한 번에 여러 토큰을 계산하게 되면 커널 런치 오버헤드와 메모리 전송이 전체 시간에서 차지하는 비중이 줄어들기 때문이다.

How to Apply

AI 코딩 에이전트나 자율 소프트웨어 엔지니어링 워크플로우를 개발 중이고 현재 100~200 tok/s 수준의 응답 속도로 UX가 답답하다면, playground.kog.ai에서 KIE의 실제 속도를 직접 체험해보고 자사 인프라 업그레이드 우선순위를 판단하는 데 활용할 수 있다.
GPU 추론 서버를 직접 운영 중인데 배치 크기 1에서 속도가 기대보다 낮다면, MFU 대신 MBU(메모리 대역폭 활용률)를 측정해봐야 한다. 이 지표가 낮다면 연산 최적화보다 메모리 접근 패턴 및 커널 구현을 먼저 개선하는 방향을 검토해야 한다.
기업 내 데이터센터에 AMD MI300X가 있다면, NVIDIA H200 대비 HBM 대역폭이 더 높아 메모리 대역폭 병목 해소 관점에서 오히려 유리할 수 있다. KIE처럼 메모리 대역폭 최대화를 목표로 하는 추론 스택을 선택할 때 MI300X를 먼저 고려해볼 만하다.
에이전트 워크플로우 설계 시 총 생성 토큰 수와 요청당 디코딩 속도를 곱해 전체 루프 시간을 추산해보면 속도 업그레이드의 실제 비즈니스 가치를 수치로 볼 수 있다. 예를 들어 워크플로우당 50,000 토큰을 생성한다면 100 tok/s는 8분, 3,000 tok/s는 17초로 동일한 에이전트 루프가 완전히 다른 제품이 된다.

Terminology

MBUMemory Bandwidth Utilization. GPU의 메모리 대역폭을 얼마나 효율적으로 쓰고 있는지 나타내는 지표. 배치 1 추론에서는 MFU(연산 활용률)보다 이게 진짜 병목 지표다.

MFUModel FLOP Utilization. GPU의 최대 연산 능력(FLOPS) 대비 실제로 활용하는 비율. 배치가 클 때는 의미 있지만, 단일 요청 디코딩에서는 메모리 대역폭이 먼저 한계에 달해 MFU를 올려봐야 속도가 안 오른다.

HBMHigh Bandwidth Memory. GPU에 붙어 있는 고속 메모리. H200 기준 약 3.35 TB/s의 대역폭을 제공하며, LLM 디코딩 속도의 실질적 상한선을 결정한다.

MoEMixture of Experts. 모델을 여러 개의 전문가 네트워크로 나눠서, 입력에 따라 일부 전문가만 활성화하는 구조. 전체 파라미터는 크지만 실제 연산에 쓰이는 가중치는 일부라 메모리 효율이 좋다.

speculative decoding투기적 디코딩. 작은 보조 모델이 여러 토큰을 미리 예측하고, 큰 모델이 한 번에 검증하는 방식으로 디코딩을 가속하는 기법. KIE는 이를 쓰지 않고도 고속을 달성했다고 주장한다.

KV cacheKey-Value Cache. 어텐션 연산에서 이전에 계산한 Key/Value 행렬을 저장해두는 캐시. 시퀀스가 길어질수록 크기가 커져 메모리 대역폭 소비에 영향을 준다.