Kog 3000토큰/s 공개, 코딩 에이전트 병목은 지연시간

Kog AI가 2026년 5월 28일 공개한 Kog Inference Engine tech preview는 모델 출시 뉴스가 아니라 추론 지연시간 뉴스입니다. 회사는 8× AMD MI300X 노드에서 요청 1개당 3000 output tokens/s, 8× NVIDIA H200 노드에서 2100 output tokens/s를 측정했다고 밝혔습니다. 조건은 FP16, batch size 1, speculative decoding 없음, 2B coding model입니다. Kog는 이 수치가 전용 추론 칩 없이 datacenter GPU에서 agentic workflow용 응답 속도를 만들 수 있다는 주장으로 읽히기를 원합니다.

이 발표가 AI 개발자에게 닿는 지점은 "모델이 얼마나 똑똑한가"보다 "에이전트가 한 루프를 얼마나 빨리 돈다"에 있습니다. 코딩 에이전트는 계획을 만들고, 파일을 읽고, 코드를 쓰고, 테스트 로그를 해석하고, 실패하면 다시 수정합니다. 각 단계는 이전 단계의 출력이 끝나야 다음 입력을 만들 수 있습니다. Kog 블로그는 50,000 tokens를 생성하는 작업을 예로 들며 100 tokens/s에서는 약 8분, 3000 tokens/s에서는 20초 미만이라고 설명했습니다. 숫자 자체보다 이 비교가 겨냥하는 제품 경험이 더 직접적입니다.

기존 추론 벤치마크는 세 수치를 함께 섞어 말할 때가 많습니다. 전체 서버가 초당 몇 tokens를 처리하는지, 첫 token이 얼마나 빨리 나오는지, 한 요청이 끝까지 얼마나 빨리 생성되는지가 서로 다른 질문입니다. Kog는 이 셋을 분리합니다. aggregate throughput은 여러 사용자를 큰 batch로 묶을 때의 서버 효율을 보여주고, time to first token은 prefill latency를 보여줍니다. 반면 decode speed per request는 한 사용자가 긴 답변을 기다리는 시간을 결정합니다. 에이전트가 한 번에 긴 계획과 수정 diff를 만들어야 할 때는 마지막 지표가 사용자 체감 시간을 지배합니다.

Kog의 설명에서 저수준 병목은 FLOPS보다 memory bandwidth입니다. batch size 1의 autoregressive decoding에서는 token을 하나 만들 때마다 활성 weight가 GPU의 HBM에서 compute processor로 이동합니다. Kog는 NVIDIA H200 한 노드 8장 기준 30.7 TB/s, AMD MI300X 한 노드 8장 기준 33.6 TB/s의 실효 aggregate memory bandwidth를 가정했습니다. 2B dense model을 FP16으로 보면 active weights는 약 4GB입니다. Kog는 이론상 8× H200에서 7700 tokens/s, 8× MI300X에서 8400 tokens/s의 상한을 계산합니다.

실제 preview 수치인 3000 tokens/s는 그 상한보다 낮습니다. Kog는 이를 약 36% Memory Bandwidth Utilization으로 설명합니다. 일반적인 inference engine에서 손실되는 microseconds가 kernel launch, CPU scheduling, GPU-wide synchronization, tensor parallel AllReduce, cache reload, sampling 같은 위치에 쌓인다는 진단입니다. 블로그는 25-layer 모델에서 layer마다 10개 kernel이 있고 kernel launch와 cleanup이 4.5 microseconds라면 token 하나당 overhead가 1125 microseconds가 되어 890 tokens/s 근처에서 막힌다는 계산도 제시했습니다.

Kog가 택한 구현은 일반 serving stack을 튜닝하는 방식과 다릅니다. 블로그는 hot path에서 PyTorch, Triton, CUTLASS, NCCL, ROCm CK, AITER, RCCL 같은 범용 프레임워크와 라이브러리를 쓰지 않는다고 적었습니다. 대신 token generation을 하나의 persistent GPU program으로 실행하는 monokernel runtime을 둡니다. CPU 쪽 scheduling과 token sampling을 critical path에서 빼고, normalization, attention, routing, sampling, communication을 하나의 static GPU program 안에 배치하는 접근입니다.

두 번째 축은 KCCL입니다. Kog는 8-GPU 노드 하나를 단일 요청에 쓰려면 model parallelism이 필요하고, 일반 tensor parallelism은 layer마다 AllReduce를 넣어 지연시간을 늘린다고 봅니다. KCCL은 peak aggregate bandwidth보다 microsecond-scale latency를 목표로 하는 custom collective communication layer입니다. 회사는 vendor library가 약 8 microseconds를 쓰는 위치에서 KCCL이 3 microseconds 미만을 목표로 한다고 설명했습니다. 이 수치는 Kog가 제시한 설계 목표와 측정 맥락 안에서 읽어야 합니다.

세 번째 축은 Laneformer architecture입니다. Kog는 Delayed Tensor Parallelism이라는 구조로 cross-device communication을 useful computation과 겹치게 만든다고 설명합니다. 다만 이 장점은 Kog가 직접 설계한 모델에서 가장 강하게 작동합니다. Qwen, DeepSeek, Kimi 같은 기존 third-party MoE 모델은 architecture가 고정되어 있기 때문에 같은 방식으로 communication dependency를 바꾸기 어렵습니다. Kog도 큰 open-weight model로 확장할 때는 standard tensor parallelism의 latency cost를 줄이는 쪽에 무게를 둡니다.

preview 모델의 성능 조건은 본문에서 계속 붙여 읽어야 합니다. Kog는 이 모델이 frontier coding assistant가 아니며 HumanEval 50%를 기록했다고 밝혔습니다. Qwen2.5-Coder 1.5B의 43.9%, 3B의 52.4%와 비교해 작은 모델로는 나쁘지 않다는 설명도 함께 달았습니다. 학습에는 NVIDIA Nemotron v1/v2 datasets 6T tokens와 256 H100 GPU cluster가 쓰였다고 적었습니다. 현재 sequence length는 4096이고 128k long context extension은 진행 중입니다.

이 숫자가 agentic coding에 바로 주는 함의는 "대답이 빨라진다"보다 더 작게 나눠볼 수 있습니다. 코딩 에이전트가 긴 plan을 여러 개 만들고, 각 plan별 patch를 만들고, 테스트 실패 로그를 다시 읽는 구조라면 decode speed는 탐색 폭을 키울 수 있습니다. 같은 wall-clock budget 안에서 후보 patch를 1개가 아니라 여러 개 만들고, log analysis를 더 길게 하고, reviewer agent에게 더 많은 맥락을 줄 수 있습니다. 다만 그 전제는 tool execution, file I/O, test runtime, sandbox startup이 이미 충분히 빠르다는 조건입니다.

Kog가 직접 든 계산도 이 지점에 맞춰져 있습니다. 50,000 tokens를 생성하는 workflow에서 100 tokens/s와 3000 tokens/s의 차이는 약 8분과 20초 미만입니다. 실제 코딩 에이전트에서는 token generation만으로 시간이 결정되지 않습니다. 테스트가 4분 걸리는 저장소에서는 3000 tokens/s가 전체 wall time을 20초로 만들 수 없습니다. 반대로 lint, typecheck, diff 생성, 로그 요약처럼 모델 출력 비중이 큰 루프에서는 single-request decode speed가 체감 병목으로 드러납니다.

Kog는 큰 MoE 모델로 갈 때 total parameter보다 active parameter bytes가 더 중요하다고 봅니다. 블로그는 Qwen3-Coder-Next를 80B total, 3B active로, GPT-OSS-120B를 117B total, 5.1B active로, DeepSeek-V4-Flash를 284B total, 13B active로 예시했습니다. Kog의 보수적 추정 표는 현재 기술과 36% MBU를 가정할 때 GPT-OSS-120B class에서 8× H200 약 2200 tokens/s, 8× MI300X 약 2400 tokens/s를 제시합니다. DeepSeek-V4-Flash class는 8× H200 약 1160 tokens/s, 8× MI300X 약 1270 tokens/s입니다.

이 표는 발표의 강점이자 약점입니다. active parameter 기준으로 보면 작은 dense model에서 얻은 latency-first 구현이 MoE에도 닿을 수 있다는 설명은 계산 구조가 있습니다. 동시에 preview에서 직접 보여준 것은 2B 모델입니다. Kog도 글 끝에서 큰 모델의 실제 속도는 kernel launch, KV cache traffic, non-GEMM work, routing, inter-GPU collectives 같은 요소를 다시 반영해야 한다고 적었습니다. 독자가 확인해야 할 다음 단계는 Kog가 Qwen, DeepSeek, Kimi class open-weight model을 실제 engine에 올렸을 때의 wall-clock benchmark입니다.

Hacker News 반응도 이 조건표를 중심으로 갈렸습니다. 2026년 5월 29일 토론에서는 "2B parameter model로 이런 주장을 하는 것은 작은 문제에서 선형 확장을 본 뒤 큰 문제에도 같을 것이라 보는 것과 비슷하다"는 비판이 나왔습니다. 또 다른 댓글은 8× H200을 "standard GPU"로 부르는 표현이 consumer GPU를 떠올리게 한다고 지적했습니다. Kog 창업자 Gaël Delalleau는 HN에서 혼동을 인정하고 글 제목을 "Standard Datacenter GPUs"로 바꿨다고 답했습니다.

이 제목 수정은 작은 에피소드처럼 보이지만 제품 포지셔닝에는 꽤 직접적입니다. "standard GPU"는 개발자에게 RTX 4090이나 workstation card를 떠올리게 할 수 있습니다. Kog가 실제로 말하는 표준성은 Groq, Cerebras, Taalas 같은 dedicated inference hardware와 대비되는 datacenter GPU입니다. 즉 구매자가 이미 갖고 있거나 cloud에서 빌릴 수 있는 H200, MI300X class node에서 전용 칩급 single-request latency를 만들 수 있느냐가 논점입니다. 소비자용 local model 속도 경쟁과는 다른 시장입니다.

전용 추론 하드웨어와의 비교도 조심해야 합니다. Kog는 "dedicated inference hardware cards" 수준의 속도 영역에 datacenter GPU가 들어갈 수 있다고 주장합니다. HN에서는 Groq나 Taalas가 더 큰 모델을 다른 방식으로 돌리는 비교가 빠졌다는 지적이 있었습니다. Kog 측은 Taalas가 dedicated hardware section에 포함됐어야 했고, Taalas는 3-bit quantization과 model-on-card 방식을 쓴다는 취지로 답했습니다. 이 논쟁은 speed headline만으로는 model size, precision, batch, hardware class를 비교하기 어렵다는 점을 드러냅니다.

개발팀 입장에서 당장 확인할 항목은 네 가지입니다. 첫째, 자신의 에이전트 workflow가 generation-bound인지 tool-bound인지 재야 합니다. 둘째, 8-GPU node를 요청 하나에 쓰는 비용이 agent productivity 개선과 맞는지 계산해야 합니다. 셋째, batch size 1 최적화가 동시 사용자 serving과 충돌하지 않는지 봐야 합니다. 넷째, Kog의 future MoE 수치가 실제 open-weight model benchmark로 이어지는지 기다려야 합니다. 이 중 첫째와 둘째는 Kog와 무관하게 모든 코딩 에이전트 운영팀이 이미 측정해야 하는 항목입니다.

에이전트 제품에서는 latency budget을 어디에 쓰는지가 기능 차이를 만듭니다. 3000 tokens/s가 안정적으로 나온다면 agent는 같은 시간 안에 더 많은 self-critique, reviewer pass, alternate patch generation을 넣을 수 있습니다. 그러나 빠른 token generation이 낮은 품질의 많은 토큰을 뜻하면 리뷰 비용과 사용자 확인 비용이 올라갑니다. Kog preview 모델의 HumanEval 50%라는 수치는 이 구분을 잘 보여줍니다. 발표의 주장은 "이 작은 모델이 최고 코딩 모델"이 아니라 "추론 엔진의 병목을 이렇게 낮출 수 있다"에 가깝습니다.

이번 발표를 코딩 에이전트 시장의 가격 뉴스로 읽을 수도 있습니다. frontier model API 가격과 rate limit이 높아질수록 agent orchestration은 한 작업에 몇 번의 reasoning pass를 허용할지 제한받습니다. Kog 같은 latency-first inference engine이 큰 MoE에서도 충분한 품질과 속도를 보인다면, 기업은 agent loop 일부를 자체 GPU에서 돌리고, 일부 판단만 frontier API로 넘기는 hybrid 설계를 더 적극적으로 검토할 수 있습니다. 이 경우 비교 기준은 model leaderboard가 아니라 token latency, node cost, implementation effort, model quality의 묶음입니다.

Kog의 공개 범위는 아직 tech preview입니다. playground는 2B coding model의 속도를 직접 관찰하게 만드는 데 초점이 있고, design partner program은 coding agents, app-generation systems, agentic workflows를 만드는 팀을 대상으로 합니다. 공개 블로그에는 production SLA, 가격, open source 여부, third-party model 지원 일정이 확정돼 있지 않습니다. 따라서 이 발표는 조달 결정 근거라기보다 "agent infrastructure가 throughput-first serving에서 latency-first loop로 분화되고 있다"는 사례로 보는 편이 정확합니다.

다음 관찰 지점은 Kog가 큰 open-weight MoE에서 같은 주장을 얼마나 검증하느냐입니다. GPT-OSS-120B, DeepSeek-V4-Flash, Kimi-K2.6 같은 모델명은 표에 들어갔지만 실제 porting 결과는 아직 발표되지 않았습니다. 또 8× H200이나 8× MI300X 한 노드를 한 요청에 붙이는 설계가 많은 동시 요청에서 어떤 scheduling 정책을 갖는지도 필요합니다. 코딩 에이전트는 한 명의 긴 작업을 빠르게 끝내야 하지만, SaaS 제품은 수많은 사용자의 짧고 긴 작업을 동시에 다뤄야 합니다.

Kog 발표의 실무적 가치는 "3000 tokens/s"라는 숫자를 그대로 받아들이는 데 있지 않습니다. 조건을 붙인 뒤에도 남는 질문, 즉 코딩 에이전트의 병목을 지능, 권한, context, sandbox만이 아니라 decode latency로도 봐야 한다는 점이 남습니다. 에이전트가 더 많은 파일을 읽고, 더 많은 후보를 만들고, 더 많은 테스트 로그를 설명하려면 빠른 모델 호출이 필요합니다. Kog는 그 호출을 전용 칩이 아니라 datacenter GPU software stack에서 만들 수 있다고 주장했습니다. 이제 필요한 것은 작은 preview를 넘어선 큰 모델의 재현 가능한 숫자입니다.