Building the foundation for running extra-large language models

🖼️ 인포그래픽

Building the foundation for running extra-large language models 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Cloudflare는 Workers AI에서 Kimi K2.5 같은 초대형 오픈소스 언어 모델을 빠르고 효율적으로 운영하기 위해 하드웨어 구성, prefill/decode 분리, 프롬프트 캐싱, KV 캐시 최적화, speculative decoding, 자체 추론 엔진 Infire를 조합하고 있다고 설명한다.

📌 핵심 요약

글은 Workers AI가 Moonshot의 Kimi K2.5 같은 대형 오픈소스 모델 호스팅을 본격화했으며, 이후 Kimi K2.5를 3배 빠르게 만들고 여러 에이전트 제품과 도구의 기반으로 활용하고 있다고 소개한다.
Cloudflare는 에이전트 워크로드가 긴 입력 컨텍스트와 도구 호출을 많이 사용한다는 점에 맞춰, 출력 생성 속도만이 아니라 입력 토큰 처리 속도와 도구 호출 성능을 핵심 최적화 대상으로 삼았다.
prefill과 decode를 분리한 PD disaggregation 구조를 통해 각 단계를 별도 서버에서 실행하고, 토큰-aware 로드밸런싱으로 입력·출력 토큰 부하를 분산해 p90 지연과 토큰 간 지연 시간을 크게 낮췄다고 설명한다.
긴 컨텍스트를 반복적으로 처리하는 에이전트 사용 사례에서는 x-session-affinity 헤더와 프롬프트 캐싱을 활용해 캐시 적중률을 높였고, 내부 대형 사용자 적용 후 피크 시간대 입력 토큰 캐시 히트율이 60%에서 80%로 증가했다고 밝힌다.
더 큰 모델을 여러 GPU에서 운영하기 위해 Mooncake Transfer Engine과 Mooncake Store로 KV 캐시를 공유·확장하고, NVIDIA EAGLE-3 기반 speculative decoding과 Rust 기반 자체 추론 엔진 Infire의 멀티 GPU·저메모리·빠른 콜드스타트 최적화를 결합했다.

🧩 주요 포인트

글은 Workers AI가 Moonshot의 Kimi K2.5 같은 대형 오픈소스 모델 호스팅을 본격화했으며, 이후 Kimi K2.5를 3배 빠르게 만들고 여러 에이전트 제품과 도구의 기반으로 활용하고 있다고 소개한다.
Cloudflare는 에이전트 워크로드가 긴 입력 컨텍스트와 도구 호출을 많이 사용한다는 점에 맞춰, 출력 생성 속도만이 아니라 입력 토큰 처리 속도와 도구 호출 성능을 핵심 최적화 대상으로 삼았다.
prefill과 decode를 분리한 PD disaggregation 구조를 통해 각 단계를 별도 서버에서 실행하고, 토큰-aware 로드밸런싱으로 입력·출력 토큰 부하를 분산해 p90 지연과 토큰 간 지연 시간을 크게 낮췄다고 설명한다.
긴 컨텍스트를 반복적으로 처리하는 에이전트 사용 사례에서는 x-session-affinity 헤더와 프롬프트 캐싱을 활용해 캐시 적중률을 높였고, 내부 대형 사용자 적용 후 피크 시간대 입력 토큰 캐시 히트율이 60%에서 80%로 증가했다고 밝힌다.
더 큰 모델을 여러 GPU에서 운영하기 위해 Mooncake Transfer Engine과 Mooncake Store로 KV 캐시를 공유·확장하고, NVIDIA EAGLE-3 기반 speculative decoding과 Rust 기반 자체 추론 엔진 Infire의 멀티 GPU·저메모리·빠른 콜드스타트 최적화를 결합했다.

🧠 상세 정리

1. 초대형 모델 호스팅의 출발점

글은 Workers AI가 Moonshot의 Kimi K2.5 같은 대형 오픈소스 모델을 호스팅하는 영역에 진입했다는 배경에서 시작한다. Cloudflare는 공개 발표 이후 Kimi K2.5를 3배 빠르게 만들었고, 추가 모델도 준비 중이라고 설명한다. 이 모델들은 해당 주간에 공개한 여러 에이전트형 제품, 하네스, 도구의 기반 역할을 하고 있다. 저자들은 AI 모델 호스팅이 소프트웨어와 매우 비싼 하드웨어 사이의 균형을 요구하는 문제라고 짚으며, Cloudflare가 하드웨어 효율을 소프트웨어 엔지니어링으로 끌어올리는 방식에 초점을 맞춘다.

2. 사용 패턴에 따라 달라지는 하드웨어 구성

Cloudflare는 모델을 잘 서비스하기 위해 여러 하드웨어 구성을 사용한다고 설명한다. 핵심 변수는 사용자가 보내는 입력 토큰과 모델이 생성하는 출력 토큰의 크기다. 예를 들어 팬픽을 쓰는 작업은 입력은 짧지만 긴 출력을 요구할 수 있고, 요약 작업은 수십만 개의 입력 토큰을 보내면서 비교적 짧은 요약만 생성할 수 있다. 이처럼 상반된 사용 사례가 존재하기 때문에, 구성은 입력 토큰 처리에 유리하게 맞출지 출력 토큰 생성에 유리하게 맞출지 선택해야 한다.

3. 에이전트 워크로드가 요구한 최적화 방향

Workers AI에서 대형 언어 모델을 출시할 때 Cloudflare는 주요 사용 사례가 에이전트가 될 것이라고 판단했다. 에이전트는 큰 시스템 프롬프트, 도구 목록, MCP, 이전 대화와 생성된 코드 등을 계속 컨텍스트에 포함하기 때문에 입력 토큰이 빠르게 커진다. 사용자가 새 프롬프트를 보낼 때마다 이전 사용자 메시지, 어시스턴트 응답, 생성물 등이 함께 모델 요청에 들어간다. 따라서 Workers AI는 빠른 입력 토큰 처리와 빠른 도구 호출을 특히 중요하게 봤고, 이후 설명되는 여러 최적화도 이 전제 위에서 전개된다.

4. prefill과 decode 분리 아키텍처

글은 LLM 요청 처리에 prefill과 decode라는 두 단계가 있다고 설명한다. prefill은 입력 토큰을 처리하고 KV 캐시를 채우는 단계이며 보통 계산 자원에 묶이고, decode는 출력 토큰을 생성하는 단계로 메모리 대역폭의 영향을 더 크게 받는다. 두 단계가 사용하는 GPU 자원 특성이 다르고 prefill이 decode보다 먼저 수행되기 때문에, 한 머신에서 모두 처리하면 GPU를 충분히 효율적으로 쓰지 못할 수 있다. Cloudflare는 이를 해결하기 위해 prefill 서버와 decode 서버를 분리해 각 단계에 맞게 독립적으로 조정하고 확장할 수 있는 구조를 사용한다.

5. 복잡한 로드밸런싱과 지연 시간 개선

prefill decode disaggregation은 단순 라우팅 이상의 복잡한 로드밸런서를 필요로 한다. 요청은 먼저 prefill 단계로 보내져 KV 캐시를 만든 뒤, decode 서버로 다시 전달되어 해당 KV 캐시를 전송받고 생성을 시작한다. 로드밸런서는 decode 서버의 응답, 스트리밍 SSE, cached tokens 같은 prefill 서버 정보를 포함하도록 응답을 재작성해야 하며, 추론 서버마다 KV 캐시 전송을 시작하는 데 필요한 정보도 다르다. Cloudflare는 여기에 토큰-aware 로드밸런싱을 추가해 각 prefill·decode 엔드포인트의 진행 중 토큰 수를 추정하고 부하를 고르게 분산했으며, 같은 GPU 수로 요청량이 증가한 상황에서도 p90 Time to First Token과 intertoken latency가 크게 개선됐다고 제시한다.

6. 프롬프트 캐싱과 x-session-affinity

에이전트형 사용 사례는 긴 컨텍스트를 반복해서 보내기 때문에, 매 턴마다 입력 텐서를 다시 계산하지 않는 프롬프트 캐싱이 중요하다. Cloudflare는 x-session-affinity 헤더를 활용해 이전에 계산된 입력 텐서가 있는 적절한 리전에 요청을 라우팅하도록 돕는다. 내부적으로 KV-aware routing을 사용하지만, 클라이언트가 명시적으로 이 헤더를 보내는 것도 중요하다고 보고 cached token 할인으로 사용을 장려한다. OpenCode 같은 인기 에이전트 하네스에 세션 affinity 헤더를 추가했을 때 총 처리량이 크게 늘었고, 대형 내부 사용자들이 이를 채택한 뒤 피크 시간대 입력 토큰 캐시 적중률이 60%에서 80%로 증가했다고 설명한다.

7. 여러 GPU와 노드에 걸친 KV 캐시 최적화

더 큰 모델을 서비스하면 하나의 인스턴스가 여러 GPU에 걸쳐 실행될 수 있으므로 KV 캐시를 효율적으로 공유하는 방법이 필요하다. KV 캐시는 prefill 결과로 만들어진 입력 텐서를 저장하는 공간이며 처음에는 GPU VRAM에 존재하지만, 모델 인스턴스가 여러 GPU를 필요로 하면 캐시도 GPU 간에 연결되어야 한다. Cloudflare는 Kimi를 위해 Moonshot AI의 Mooncake Transfer Engine과 Mooncake Store를 활용했다고 설명한다. Mooncake Transfer Engine은 NVLink와 NVMe over Fabric 같은 RDMA 프로토콜을 통해 CPU 개입 없이 메모리 간 직접 전송을 가능하게 하고, LMCache 또는 SGLang HiCache와 함께 사용할 때 클러스터 전체에서 캐시를 공유해 이전 요청의 캐시를 다른 노드에서도 재사용할 수 있게 한다.

8. speculative decoding으로 구조화 출력 가속

글은 언어 모델이 이전 토큰을 바탕으로 다음 토큰을 예측한다는 기본 원리에서 speculative decoding을 설명한다. 단순 구현에서는 다음 토큰만 예측하지만, speculative decoding은 더 작은 draft model이 몇 개의 후보 토큰을 만들고 큰 target model이 이를 한 번의 forward pass에서 검증하도록 한다. 최종적으로 target model이 후보를 수락하거나 거절하므로 품질을 유지하면서도 큰 모델이 직접 모든 토큰을 생성하는 것보다 계산 비용을 낮출 수 있다. 에이전트 사용 사례에서는 도구 호출과 구조화 출력이 많고, JSON envelope 안의 이름·설명 같은 형태가 비교적 예측 가능하기 때문에 이 기법이 특히 효과적이라고 설명한다.

9. Infire와 멀티 GPU 실행 기반

Cloudflare는 2025년 Birthday Week에 발표한 자체 추론 엔진 Infire도 초대형 모델 운영 기반으로 확장했다고 밝힌다. Infire는 Rust로 작성된 추론 엔진이며, Cloudflare의 분산 글로벌 네트워크에서 추론을 수행해야 하는 고유한 조건을 지원하도록 설계됐다. Kimi K2.5 같은 1조 개 이상의 파라미터 모델은 약 560GB의 모델 가중치를 가지며, 일반적인 H100의 VRAM이 약 80GB이기 때문에 최소 8개의 H100이 필요하다고 설명한다. Infire는 이를 위해 pipeline-parallel, tensor-parallel, expert-parallelism을 지원하도록 확장됐고, 파이프라인 단계 간 부하 균형과 GPU 간 통신 최소화를 통해 처리량과 지연 시간의 균형을 맞춘다.

10. 메모리 오버헤드와 콜드스타트 개선

Infire는 기존에도 vLLM보다 낮은 GPU 메모리 오버헤드를 목표로 했지만, Cloudflare는 activations 같은 내부 상태에 필요한 메모리를 더 줄였다고 설명한다. 현재 Infire는 Llama 4 Scout를 H200 GPU 두 개에서 실행하면서도 KV 캐시용으로 56GiB 이상을 남길 수 있고, 이는 120만 토큰 이상에 충분하다고 제시한다. 또한 Kimi K2.5를 H100 GPU 8개에서 실행하면서도 KV 캐시용으로 30GiB 이상을 남길 수 있다고 말한다. 멀티 GPU 지원을 추가하는 과정에서는 부팅 시간도 개선해, Kimi K2.5 같은 가장 큰 모델도 20초 미만에 요청 처리를 시작할 수 있으며, 로드 시간은 드라이브 속도에 의해 제한된다고 설명한다.

🧾 핵심 주장 / 시사점

이 글의 핵심은 초대형 모델 성능 개선이 단일 기법이 아니라, 요청 패턴 분석·하드웨어 구성·캐시 라우팅·로드밸런싱·추론 엔진 최적화가 결합된 시스템 문제라는 점이다.
에이전트형 사용 사례에서는 출력 생성보다 긴 입력 컨텍스트와 반복 요청이 병목이 되기 쉬우므로, prefill 처리와 프롬프트 캐싱의 효율이 전체 비용과 지연 시간을 크게 좌우한다.
Cloudflare의 접근은 같은 GPU 수에서 더 높은 처리량과 낮은 지연을 얻기 위해 GPU 내부 자원, GPU 간 통신, 노드 간 캐시 공유까지 함께 다루는 방향으로 정리된다.

✅ 액션 아이템

prefill/decode 분리형 PD 아키텍처를 도입해 입력·출력 단계를 서로 다른 서버에서 운영하고, p90 지연과 토큰 간 지연을 단계별로 측정해 개선한다.
긴 컨텍스트 반복 에이전트 요청에서 x-session-affinity와 프롬프트 캐싱 적용 범위를 구분해 피크 시간대 입력 토큰 캐시 히트율 60%→80% 개선을 재현한다.
Mooncake Store/Transfer Engine 기반 KV 공유와 Infire·NVIDIA EAGLE-3 speculative decoding 조합을 적용해 멀티 GPU 확장성, 메모리 사용, 콜드스타트 지연을 비교 측정한다.

❓ 열린 질문

입력 토큰 처리 최적화가 우선일 때 에이전트 도구 호출 지연까지 반영한 우선순위는 어떤 방식으로 정해야 하는가?
긴 문맥 반복 세션에서 x-session-affinity 적용 시 어떤 세션 식별 기준이 캐시 적중률을 가장 안정적으로 높일 것인가?
현재 환경에서 목표 속도 향상치를 설정한다면 PD 분리와 speculative decoding 단독 적용 대비 기대 개선폭은 어떤 실험 설계로 검증할 것인가?