Cloudflare Infire: Rust로 처음부터 다시 만든 엣지 분산 LLM 추론 엔진

Cloudflare가 독자 개발한 LLM 추론 엔진 Infire의 텐서·파이프라인·전문가 병렬화, PD 분리 아키텍처, 글로벌 엣지 서빙, Unweight 무손실 가중치 압축을 정리한다

2026-08-14 · 최초 발행 2026-05-11

Cloudflare가 자체 LLM 추론 엔진 Infire를 공개하며 엣지 AI 인프라 경쟁에 본격적으로 뛰어들었다. 기존 오픈소스 추론 프레임워크를 그대로 사용하는 대신, Rust로 처음부터 설계된 Infire는 Cloudflare의 전 세계 200개 이상 도시 분산 네트워크에 최적화된 독자적인 아키텍처를 채택하고 있다.

집중형 클러스터를 전제하지 않는 추론 엔진이 필요했던 이유

LLM 추론 분야에는 이미 vLLM, TGI(Text Generation Inference), TensorRT-LLM 등 검증된 오픈소스 프레임워크가 다수 존재한다. 그럼에도 불구하고 Cloudflare가 Infire를 독자 개발한 데는 근본적인 이유가 있다. 기존 추론 프레임워크는 대부분 단일 데이터센터 또는 집중형 클러스터 환경을 전제로 설계되어 있다. 반면 Cloudflare의 인프라는 세계 인구의 95%로부터 50ms 이내 거리에 위치한 300개 이상 도시에 분산되어 있으며, 각 거점은 소수의 GPU를 보유하는 엣지 구조를 띤다.

이 환경에서는 기존 프레임워크의 전제가 성립하지 않는다. GPU 수량이 제한된 엣지 서버에서 최대한의 모델을 실행해야 하고, 네트워크 지연이 다양한 지역 간 요청을 효율적으로 라우팅해야 하며, 빠른 모델 시작 시간이 필수적이다. Cloudflare는 이러한 제약 조건을 충족하는 추론 엔진을 오픈소스에서 찾지 못했고, Rust를 선택해 직접 구현했다. Rust는 메모리 안전성과 낮은 시스템 오버헤드를 동시에 제공하여 엣지 환경의 CPU 부담을 최소화하는 데 적합하다.

사용자 요청Cloudflare Anycast 라우팅가장 가까운 엣지 노드 선택Workers AI 레이어Infire 추론 엔진 (Rust)다중 GPU 병렬 처리텐서 병렬 (TP)파이프라인 병렬 (PP)전문가 병렬 (EP)응답 생성사용자 반환

GPU를 나눠 쓰는 병렬화 전략

Infire는 단일 GPU를 넘어 여러 GPU에 걸쳐 LLM을 실행하기 위해 세 가지 병렬화 전략을 지원한다. 각각은 서로 다른 병목을 해결하며, 모델 크기와 네트워크 특성에 따라 조합하여 사용한다.

텐서 병렬은 모델의 가중치 행렬을 여러 GPU에 수평으로 분할하여 동시에 계산하는 방식이다. Infire에서 텐서 병렬은 GPU 간 통신 오버헤드를 줄이는 것을 최우선 목표로 최적화되어 있다. NVLink나 고속 인터커넥트를 통한 All-Reduce 연산이 텐서 병렬의 주요 병목이기 때문에, Infire는 통신 패턴을 세밀하게 튜닝하여 동기화 지연을 최소화한다.

파이프라인 병렬은 모델 레이어를 여러 단계로 나누어 각 GPU가 서로 다른 레이어 그룹을 담당하는 방식이다. Infire는 파이프라인 단계 간 부하를 균형 있게 분배하는 데 집중한다. 특정 단계의 GPU가 다른 단계를 기다리는 '파이프라인 버블' 현상을 방지하기 위해, 입력 토큰 수와 레이어 연산량을 분석하여 각 단계에 최적의 레이어 수를 할당한다.

Mixtral, Kimi K2.5와 같은 Mixture of Experts(MoE) 아키텍처 모델을 위해 Infire는 전문가 병렬도 지원한다. MoE 모델에서는 입력 토큰마다 활성화되는 전문가(Expert) FFN 블록이 다르기 때문에, 각 GPU가 담당하는 전문가 그룹으로 토큰을 효율적으로 라우팅하는 것이 핵심이다. 텐서 병렬, 파이프라인 병렬, 전문가 병렬을 적절히 조합하면 단순히 하나의 전략만 사용하는 것보다 훨씬 높은 처리량과 낮은 레이턴시를 달성할 수 있다.

프리필과 디코드를 서로 다른 서버로 분리하다

LLM 추론은 두 단계로 구성된다. 첫 번째는 프리필(Prefill) 단계로, 입력 토큰 전체를 처리하고 KV 캐시를 생성하는 연산 집약적 작업이다. 두 번째는 디코드(Decode) 단계로, 토큰을 하나씩 순차적으로 생성하는 메모리 대역폭 집약적 작업이다. 두 단계의 특성이 근본적으로 다르기 때문에, 이를 같은 GPU에서 처리하면 둘 다 최적이 아닌 상태로 실행된다.

Infire는 PD 분리(Prefill-Decode Disaggregation) 아키텍처를 구현하여 대규모 모델 서빙 시 프리필 전용 서버와 디코드 전용 서버를 별도로 운용한다. 프리필 서버는 높은 연산 처리량을 위해 튜닝하고, 디코드 서버는 메모리 대역폭 최적화에 집중한다. 트래픽이 입력 토큰이 많은 방향 또는 출력 토큰이 많은 방향으로 치우칠 때도 각 서버를 독립적으로 스케일링할 수 있다는 장점이 있다.

"KV 캐시 스토어""디코드 서버 (메모리 집약)""프리필 서버 (연산 집약)""글로벌 로드 밸런서""사용자""KV 캐시 스토어""디코드 서버 (메모리 집약)""프리필 서버 (연산 집약)""글로벌 로드 밸런서""사용자"loop["토큰 생성"]"추론 요청 (프롬프트)""입력 토큰 전달""어텐션 연산 + KV 캐시 생성""KV 캐시 저장 (RDMA 전송)""디코드 시작 신호""KV 캐시 로드""다음 토큰 생성""스트리밍 토큰 반환"

KV 캐시 메모리를 효율적으로 관리하기 위해 Infire는 Paged Attention 방식을 채택한다. 전통적인 방식은 각 요청에 대해 최대 컨텍스트 길이만큼의 연속된 메모리를 미리 할당한다. 이 방식은 짧은 요청이 많을 때 메모리를 낭비하며, 메모리 단편화 문제도 발생한다. Paged KV 캐시는 캐시를 고정 크기의 페이지 단위로 분할하여, 실제로 필요한 만큼만 페이지를 동적으로 할당한다. 프롬프트가 KV 캐시 한계에 도달하면 새 페이지를 추가하기만 하면 된다. 대부분의 요청이 최대 컨텍스트 창에 도달하지 않기 때문에, 이 기법은 실질적으로 무제한에 가까운 병렬 처리를 가능하게 한다. 연속 배칭(Continuous Batching)과 청크 프리필(Chunked Prefill)도 함께 적용된다. Infire는 디코드 슬롯이 비어 있을 때 새 프롬프트의 프리필 토큰을 해당 슬롯에 채워 GPU 활용률을 극대화한다.

다중 GPU 환경에서 KV 캐시는 특정 GPU의 VRAM에 생성되는데, 이를 다른 GPU와 효율적으로 공유하는 것이 과제다. Kimi K2.5와 같은 초대형 모델을 위해 Cloudflare는 Moonshot AI의 Mooncake Transfer Engine과 Mooncake Store를 활용한다. Mooncake Transfer Engine은 NVLink와 NVMe over Fabric(NVMe-oF)을 포함한 다양한 RDMA 프로토콜을 지원하는 고성능 데이터 전송 프레임워크다. RDMA는 CPU를 우회하여 GPU 메모리 간 직접 데이터 전송을 가능하게 하므로, CPU 오버헤드 없이 빠른 KV 캐시 공유가 가능하다. 이를 통해 여러 GPU 머신에 걸친 KV 캐시 분산 저장과 빠른 검색이 실현된다.

300개 도시로 흩어진 GPU를 어떻게 스케줄링하는가

Cloudflare Workers AI는 전 세계 200개 이상 도시에서 추론을 제공한다. 사용자의 AI 요청은 Cloudflare의 Anycast 라우팅을 통해 자동으로 가장 가까운 GPU 용량으로 전달된다. 이는 중앙집중형 AI 서비스 제공자와 비교할 때 네트워크 레이턴시 구조가 근본적으로 다르다. 중앙집중형 추론의 경우 사용자에서 서버까지 네트워크 왕복 시간이 50100ms에 달하는 경우가 많다. Cloudflare 엣지 추론에서는 사용자에서 가장 가까운 엣지 위치까지의 왕복 시간이 1030ms 수준이다. 세계 인구의 95%가 Cloudflare 엣지 노드로부터 50ms 이내에 위치하기 때문에, 실제 사용자 체감 레이턴시가 크게 줄어든다.

아시아유럽북미뉴욕 엣지LA 엣지프랑크푸르트 엣지런던 엣지도쿄 엣지서울 엣지싱가포르 엣지글로벌 부하 분산 레이어Infire 추론 엔진모델 레지스트리(Llama 4, Kimi K2.5 등)

엣지 기반 AI 서빙에서 모델 스케줄링은 중앙집중형 환경보다 훨씬 복잡한 문제다. 각 엣지 거점은 제한된 GPU를 보유하고 있으며, 모델 크기가 클수록 해당 모델을 실행할 수 있는 거점이 줄어든다. Cloudflare는 각 모델이 배포될 위치를 결정할 때 사용자 요청 패턴, 거점의 GPU 용량, 모델 메모리 요구사항을 종합적으로 고려한다. 소형 모델은 전 세계 모든 엣지 거점에 배포하여 최저 레이턴시를 제공하고, 초대형 모델(예: Kimi K2.5)은 다수의 H100 GPU를 갖춘 특정 거점에서만 실행한다. 요청이 초대형 모델을 필요로 할 경우, 해당 모델을 실행 중인 가장 가까운 거점으로 라우팅된다. 이 계층적 스케줄링 전략은 모델 능력과 레이턴시 사이의 균형을 동적으로 조절한다.

무손실로 22%를 줄이는 가중치 압축

Infire와 함께 발표된 Unweight는 Cloudflare가 독자적으로 개발한 무손실 LLM 가중치 압축 시스템이다. LLM의 가중치는 16비트 Brain Float(BF16) 형식으로 저장되는데, 연구에 따르면 256개의 지수값 중 상위 16개가 레이어 전체 가중치의 99% 이상을 차지한다. 이 극단적인 편향 분포를 허프만 코딩(Huffman Coding)으로 압축하면 반복적인 값에 짧은 코드를 할당하여 저장 공간을 크게 줄일 수 있다.

Unweight의 핵심 혁신은 압축 해제 시점에 있다. 가중치를 온칩 고속 메모리에서 압축 해제하면서 바로 텐서 코어에 공급하면, 느린 메인 메모리로의 추가 왕복을 피할 수 있다. 이를 통해 Unweight는 최대 22%의 모델 메모리 사용량 절감을 달성한다. 비트 수준에서 완전히 동일한 출력을 보장하는 무손실 방식이기 때문에 모델 품질에는 전혀 영향을 미치지 않는다. Llama 3.1 8B 기준으로 총 모델 메모리의 약 13%를 절약할 수 있다.

현재 Infire는 양자화를 차기 버전에서 도입할 계획이다. 양자화는 가중치와 활성화 값을 더 낮은 비트 정밀도(예: FP16에서 INT8 또는 INT4)로 표현하여 메모리 사용량과 연산량을 동시에 줄이는 기법이다. Unweight의 무손실 압축과 양자화가 결합되면 훨씬 더 큰 모델을 적은 GPU로 실행할 수 있게 된다. 모델 시작 시간도 엣지 환경에서 중요한 최적화 대상이다. 엣지 거점은 다양한 모델 요청을 처리해야 하므로 모델을 빠르게 로드하고 언로드하는 능력이 핵심이다. Infire는 Kimi K2.5와 같은 초대형 모델도 20초 이내에 서빙을 시작할 수 있다. 이는 모델 가중치 로딩 최적화, 메모리 사전 할당 전략, 빠른 초기화 루틴의 결과다.

Infire의 메모리 최적화가 실제로 어떤 성과를 거두고 있는지 구체적인 수치로 확인할 수 있다. Llama 4 Scout는 H200 GPU 단 두 장으로 실행이 가능하며, KV 캐시를 위한 여유 VRAM이 56GiB 이상 남는다. 이 KV 캐시 용량으로 120만 토큰 이상을 처리할 수 있다. Kimi K2.5는 H100 GPU 8장에서 실행되며 30GiB 이상의 KV 캐시가 확보된다. 처리량 측면에서 Infire는 제약 없는 시스템 환경에서 토큰당 초당 처리량을 20% 이상 향상시킨다. CPU 오버헤드도 크게 낮아져 동일한 수의 GPU로 더 많은 요청을 처리할 수 있다. Cloudflare는 Infire를 통해 더 적은 GPU로 동급 또는 더 높은 서비스 수준을 유지할 수 있다고 밝히고 있다.

Cloudflare Infire는 단순히 오픈소스 추론 프레임워크를 대체하는 수준을 넘어, 엣지 분산 네트워크라는 독특한 환경에 맞게 처음부터 설계된 전문화된 LLM 추론 엔진이다. 텐서 병렬·파이프라인 병렬·전문가 병렬의 조합, PD 분리 아키텍처, Paged KV 캐시, Unweight 무손실 압축 등 최신 추론 최적화 기법이 통합적으로 구현되어 있다. 특히 Unweight와 같은 독자 기술의 등장은 Cloudflare가 단순한 인프라 제공자를 넘어 AI 시스템 연구 분야에서도 유의미한 기여를 시작했음을 보여준다. Workers AI를 통해 이 기술 스택이 개발자에게 공개되면서, 엣지 AI 서빙의 경제성과 가능성이 새로운 수준으로 높아질 것으로 전망된다.

Sources

LLM추론엔진엣지AI서빙PD분리KV캐시최적화Rust