Fox: Rust로 만든 LLM 추론 엔진이 Ollama보다 빠른 이유

Rust 기반 LLM 추론 엔진 Fox의 PagedAttention·프리픽스 캐싱·연속 배칭 구조를 분석하고, Ollama·vLLM과의 벤치마크·포지셔닝 차이를 정리한다.

2026-08-12 · 최초 발행 2026-03-27

로컬 환경에서 LLM을 운영하는 개발자라면 Ollama의 편리함과 vLLM의 성능 사이에서 저울질해본 경험이 있을 것이다. Rust로 작성된 오픈소스 LLM 추론 엔진 Fox가 이 간극을 메우겠다는 목표로 공개돼 주목받고 있다. Ollama의 드롭인 대체재를 표방하면서 처리량 2배, 최초 토큰 응답 시간(TTFT) 72% 감소라는 수치를 내건 프로젝트다.

Ferrumox 팀이 만든 Rust 추론 엔진

Fox는 Ferrumox 팀이 개발해 GitHub(ferrumox/fox)에 공개한 오픈소스 LLM 추론 엔진이다. 프로젝트명 "Ferrumox"는 철(Iron)을 뜻하는 라틴어 Ferrum과 산화(Oxidation)를 뜻하는 ox의 합성어로, Rust(녹)를 메타포로 표현한 이름이다.

포지셔닝은 명확하다. Ollama의 사용 편의성을 유지하면서 vLLM 수준의 고성능을 로컬 환경에서 구현하는 것. Ollama가 로컬 LLM 서빙의 표준으로 자리잡았지만 동시 요청 처리나 긴 대화 컨텍스트에서 성능 병목이 생긴다는 점에 착안해 개발됐다.

Ollama가 부딪히는 벽

Ollama는 모델 다운로드부터 API 서빙까지 단일 명령어로 처리할 수 있어 로컬 LLM 실행의 진입 장벽을 크게 낮췄다. 다만 다음 시나리오에서는 한계가 드러난다.

멀티턴 대화가 길어질수록 Ollama는 이전 컨텍스트를 매번 재처리한다. 동일한 시스템 프롬프트가 수백 번 반복 연산되는 비효율이 생긴다. 여러 사용자가 동시에 요청을 보내면 순차 처리 방식 때문에 대기 시간이 급증한다. 연속 배칭(Continuous Batching) 없이는 GPU 활용률이 떨어질 수밖에 없다. 고정 크기 KV 캐시 할당은 메모리 단편화를 유발하고, 긴 시퀀스에서 OOM(Out of Memory) 위험을 높인다.

Fox는 이 세 가지 문제를 각각 프리픽스 캐싱, 연속 배칭, PagedAttention으로 대응한다.

PagedAttention과 CoW KV 블록 관리

Fox는 vLLM이 먼저 도입한 PagedAttention을 Rust로 재구현했다. 운영체제의 가상 메모리 페이징에서 영감을 받은 이 방식은, 각 요청마다 최대 시퀀스 길이만큼 KV 캐시를 연속된 메모리 공간에 미리 할당하던 기존 방식과 달리 KV 캐시를 고정 크기 블록(페이지)으로 나눠 비연속적 메모리에 저장한다.

Fox는 여기에 참조 카운팅 기반 Copy-on-Write(CoW) 블록 관리를 얹었다. 여러 요청이 동일한 프리픽스 블록을 공유할 때 실제 복사 없이 참조만 증가시키고, 수정이 필요할 때만 블록을 복사한다. 메모리 효율을 크게 높이는 동시에 프리픽스 캐싱의 기반이 되는 구조다.

블록 수준 프리픽스 캐싱

Fox의 프리픽스 캐싱은 블록 단위로 동작한다. 동일한 시스템 프롬프트나 대화 컨텍스트를 가진 여러 요청이 들어오면 이미 계산된 KV 캐시 블록을 재사용한다. RAG 시스템에서 동일한 문서 청크를 컨텍스트로 포함하는 수십 개의 요청이 동시에 들어온다고 하면, Fox는 해당 문서 청크의 KV 캐시를 한 번만 계산하고 모든 요청에 공유한다. 이것이 TTFT 72% 감소의 핵심 메커니즘이다 — 첫 토큰 생성 전 필요한 프리필(prefill) 연산량이 캐시 히트율에 비례해 줄어든다.

Prometheus 메트릭으로 prefix_hit_ratio를 실시간 모니터링할 수 있어, 실제 운영 환경에서 캐시 효율을 정확히 파악할 수 있다.

LIFO 선점 방식의 연속 배칭

기존 배칭(Static Batching)이 배치 내 모든 요청이 끝날 때까지 기다려야 했다면, 연속 배칭은 개별 요청이 끝나는 즉시 새 요청을 배치에 추가한다. Fox는 여기에 LIFO(Last In, First Out) 선점 스케줄러를 결합했다. 리소스가 부족하면 가장 최근에 시작된 요청을 일시 중단하고 메모리를 해제한 뒤, 리소스가 확보되면 재개한다. 최근 요청일수록 프리픽스 캐시 히트 가능성이 높다는 특성을 활용한 설계다. 이 구조 덕분에 GPU는 이전 배치가 끝날 때까지 유휴 상태로 기다리지 않고 계속 compute를 수행하며, 이것이 처리량 2배 향상의 배경이다.

왜 Rust인가

Fox가 Python 기반 vLLM이나 Go 기반 도구 대신 Rust를 택한 이유는 명확하다. Python의 GIL(Global Interpreter Lock)과 GC 정지는 추론 핫 패스(hot path)에서 예측 불가능한 지연을 만든다. Rust의 소유권 모델은 GC 없이 메모리 안전성을 보장하므로, 추론 중 GC 일시 정지로 인한 레이턴시 스파이크가 원천적으로 없다. 메모리 레이아웃과 실행 흐름을 정밀하게 제어할 수 있어 P95·P99 레이턴시가 P50 대비 크게 튀지 않는 안정적인 응답 특성을 보이고, 트레이트 시스템과 제네릭은 런타임 오버헤드 없이 스케줄러·KV 캐시 관리자·API 레이어를 모듈화한다. 타입 시스템이 컴파일 타임에 데이터 경쟁(data race)을 방지한다는 점도 다중 요청을 동시 처리하는 추론 서버에서는 중요한 특성이다.

벤치마크로 본 수치

Fox의 공식 벤치마크 도구(fox-bench)로 동시 요청 8개, 총 100개 요청, 최대 256 토큰 생성 조건에서 테스트한 결과는 다음과 같다.

지표 Ollama (기준) Fox 개선율
TTFT P50 ~312ms 87ms 72% 감소
TTFT P95 ~480ms 134ms 72% 감소
처리량 (tokens/sec) ~156 312.4 2배 향상
레이턴시 P50 ~850ms 412ms 51% 감소
레이턴시 P99 ~2,800ms 1,204ms 57% 감소

TTFT 개선은 멀티턴 대화와 반복적인 시스템 프롬프트가 있는 RAG 환경에서 특히 두드러진다. 프리픽스 캐시 히트율이 높을수록 TTFT는 더 크게 줄어든다.

요청 하나가 처리되는 흐름

캐시 히트캐시 미스여유 있음리소스 부족클라이언트 요청(OpenAI 호환 API)REST API 레이어(main.rs)프리픽스 캐시히트?KV 블록 재사용(ref-count 증가)프리필 연산(Prefill)연속 배칭 스케줄러(LIFO 선점)GPU 리소스여유?배치에 요청 추가(Decode 단계)최신 요청 선점(LIFO 방식)KV 블록 해제(CoW 관리)토큰 생성(PagedAttention)출력 필터링(think block, 특수토큰)Prometheus 메트릭(/metrics 엔드포인트)클라이언트 응답(스트리밍)

코드 구조도 단일 책임 원칙을 따라 모듈화돼 있다. main.rs는 엔트리 포인트와 설정 검증, scheduler/는 연속 배칭 스케줄러와 프리픽스 캐시 관리, kv_cache/는 PageTable과 참조 카운팅 블록 매니저, inference/는 스톱 시퀀스 처리와 출력 필터링, metrics.rs는 Prometheus 메트릭 수집, api/는 OpenAI 호환 REST API 엔드포인트를 담당한다.

운영에 필요한 것들도 갖췄다

기존 Ollama 애플리케이션은 엔드포인트 URL만 바꾸면 Fox로 마이그레이션할 수 있다. /metrics 엔드포인트로 요청 처리율, 레이턴시 히스토그램, KV 캐시 사용률, 프리픽스 캐시 히트율을 실시간 수집해 Grafana와 연동할 수 있고, temperature, top_p, top_k, repetition_penalty, seed 같은 표준 샘플링 옵션도 완전히 지원해 실험 재현성을 위한 시드 고정이 가능하다. think 블록, 특수 토큰, SentencePiece 단어 경계 필터링을 내장해 추론 결과를 깔끔하게 전처리하고, CPU 백엔드·CUDA 가속·CI/테스트용 스텁 빌드까지 다중 빌드 타겟을 지원해 다양한 인프라에 배포할 수 있다. 내장 벤치마크 도구 fox-bench는 TTFT P50/P95, 레이턴시 분포, 처리량을 자동 측정해 환경 변경 시 즉시 성능을 검증할 수 있게 해준다.

vLLM과는 타겟이 다르다

Fox는 vLLM과 유사한 기술을 채택했지만 타겟 환경이 다르다. vLLM은 대규모 클라우드 GPU 클러스터에서 최대 처리량을 추구하는 서비스 환경에 최적화돼 있고 Python 생태계 통합과 다양한 모델 병렬화 전략이 강점이다. Fox는 로컬 환경과 소규모 프라이빗 배포에 초점을 맞춘다. 개인 개발자의 맥북, 소규모 팀의 온프레미스 서버, 프라이버시가 중요한 기업 내부 LLM 서비스가 주요 타겟이고, Rust의 바이너리 배포 특성상 Python 환경 설정 없이 단일 실행 파일로 배포할 수 있다는 점이 운영 복잡성을 줄여준다.

항목 Fox vLLM Ollama
주요 언어 Rust Python Go
타겟 환경 로컬/소규모 서버 대규모 클라우드 로컬/개인
PagedAttention 지원 지원 미지원
프리픽스 캐싱 블록 수준 지원 미지원
GC 오버헤드 없음 Python GC Go GC
OpenAI 호환 API 지원 지원 지원
설치 난이도 낮음 중간 매우 낮음

설치하고 바로 써보기

Rust 빌드 환경이 있다면 소스에서 직접 빌드할 수 있다.

# 소스 클론
git clone https://github.com/ferrumox/fox
cd fox

# CPU 백엔드로 빌드
cargo build --release

# CUDA 가속 빌드 (NVIDIA GPU 환경)
cargo build --release --features cuda

# 서버 실행 (Ollama와 동일한 포트)
./target/release/fox serve --model <모델경> --port 11434

# 내장 벤치마크 실행
./target/release/fox-bench --concurrency 8 --requests 100 --max-tokens 256

기존 Ollama 클라이언트는 엔드포인트를 바꾸지 않고도 Fox와 통신할 수 있고, OpenAI SDK를 쓰는 애플리케이션도 base_url만 Fox 주소로 바꾸면 된다.

도입 전에 확인할 것들

프리픽스 캐시 효율은 사용 패턴에 크게 좌우된다. 매번 다른 시스템 프롬프트를 쓰거나 다양한 문서를 RAG 컨텍스트로 쓰는 환경에서는 캐싱 이점이 줄어들 수 있으므로 prefix_hit_ratio 메트릭으로 실제 효율을 모니터링하는 게 중요하다. Fox는 2026년 3월 기준 비교적 초기 프로젝트라 vLLM이나 Ollama에 비해 지원 모델 아키텍처 범위가 제한적일 수 있어, 사용하려는 모델의 지원 여부를 사전에 확인해야 한다. Ollama가 갖춘 방대한 커뮤니티와 Modelfile 생태계에 비하면 Fox는 아직 그 생태계를 구축하는 단계라, 특정 워크플로우가 바로 지원되지 않을 수 있다. 또한 성능 지표는 GPU 환경에서 측정된 것이라 CUDA 가속을 쓰지 않는 CPU 빌드에서는 성능 이점이 제한적이라는 점도 감안해야 한다.

남는 질문

Fox는 Rust의 시스템 프로그래밍 강점과 vLLM이 검증한 알고리즘(PagedAttention, 연속 배칭, 프리픽스 캐싱)을 결합해 로컬 LLM 추론의 새로운 가능성을 보여준다. 처리량 2배, TTFT 72% 감소라는 수치는 구체적인 기술 메커니즘에 근거한 결과이지, 단순한 마케팅 수치는 아니다. 다만 아직 초기 프로젝트이므로 모든 프로덕션 시나리오에 즉시 적용하기는 무리가 있다. 로컬 LLM 인프라를 구축하는 팀이라면, Ollama에서 마이그레이션 비용이 거의 없다는 점을 고려해 지금부터 평가하고 테스트해볼 이유는 충분하다.

Sources

FoxLLM 추론 엔진Ollama 대안PagedAttention로컬 LLM