Cloudflare, Kimi K2.5 token latency를 20-30 ms까지 낮췄다

Cloudflare의 이번 LLM infra 글은 “model을 제공한다”보다 더 구체적인 질문을 던진다. 1 trillion parameters급 model을 agent workload에 맞게 빠르고 싸게 돌리려면 serving stack을 어디까지 바꿔야 하는가. 회사는 2026년 4월 16일 기술 글에서 Workers AI의 Kimi K2.5 serving을 3x faster로 만들었다고 밝혔다.

핵심 수치는 latency다. Cloudflare는 prefill decode disaggregation architecture로 traffic을 옮긴 뒤, request volume이 증가하고 GPU 수량은 같았는데도 p90 Time to First Token의 tail latency variance가 줄었다고 설명했다. 또한 p90 time per token은 high variance를 보이던 약 100 ms 수준에서 20-30 ms로 내려갔다. Interactive agent와 coding assistant에서는 이 차이가 체감 응답 속도를 크게 바꾼다.

그 뒤에는 agent workload에 특화한 가정이 있다. Agent는 system prompt, tools, MCPs, 이전 대화, 생성된 code가 계속 context에 쌓인다. Cloudflare는 fast input token processing과 fast tool calling을 우선 과제로 잡았고, prefill과 decode를 다른 server pool로 나누었다. Token-aware load balancing은 각 endpoint의 in-flight prefill/decode token을 추정해 traffic을 분산한다.

Prompt caching도 비용과 throughput을 좌우했다. Cloudflare는 x-session-affinity header를 통해 이전에 계산된 input tensors가 있는 region으로 request를 보내도록 유도한다. Heaviest internal users와 작업한 뒤 peak 기준 input token cache hit ratio가 60%에서 80%로 올라갔다고 했다. 이 정도 차이는 필요한 GPU 수와 interactive latency 모두에 영향을 준다.

Infire, Cloudflare의 Rust inference engine,도 글의 중요한 부분이다. Cloudflare는 Kimi K2.5가 1 trillion parameters를 넘고 model weights만 약 560GB라며, 최소 8 H100s가 필요하다고 설명한다. Infire는 Llama 4 Scout를 two H200 GPUs에서 돌리면서 KV-cache용 56 GiB 이상을 남기고 1.2m tokens 이상을 감당할 수 있으며, Kimi K2.5도 8 H100 GPUs에서 KV-cache용 30 GiB 이상을 남긴다고 했다. 가장 큰 model도 under 20 seconds에 serving을 시작할 수 있고, unconstrained systems에서는 tokens per second throughput을 up to 20% 높인다는 설명이다.