K8s 위에서 만난 NPU: Furiosa RNGD 통합부터 Prefix Caching 분석까지

1. 도입

최근 LLM(대규모 언어 모델) 서비스가 고도화되면서, 막대한 GPU 도입 비용과 전력 소모를 해결하기 위해 NPU(신경망 처리 장치) 도입을 고려하는 조직이 늘고 있습니다. 하지만 새로운 하드웨어를 기존의 Kubernetes 생태계에 이질감 없이 녹여내는 것은 인프라 엔지니어에게 또 다른 과제입니다.

NuFi 플랫폼 소개

저희 팀은 NuFi라는 Kubernetes 기반 AI 모델 서빙 플랫폼을 개발하고 있습니다. NuFi는 GPU와 NPU를 포함한 다양한 가속기 위에서 대규모 언어 모델(LLM)을 배포하고 관리할 수 있도록 설계된 플랫폼입니다.

사용자 → Dashboard (Next.js) → API Server (Go) → NpuDeploy CR → NuFi Controller → K8s 리소스 생성
                                                                                   (Deployment, Service, VirtualService 등)

사용자는 웹 대시보드에서 모델, 디바이스 종류, 리소스 등을 선택하면, NuFi가 Kubernetes 위에 추론 서버를 자동으로 배포합니다. 현재 NVIDIA GPU, Rebellions ATOM, Hyperaccel LPU 등 여러 가속기를 지원하고 있습니다.

Furiosa Renegade 소개

Renegade(RNGD) 는 FuriosaAI에서 개발한 LLM 추론 특화 NPU입니다. RNGD의 상세 스펙은 Furiosa 공식 문서에서 확인할 수 있습니다.

이번에 FuriosaAI로부터 Renegade 카드를 한 장 제공받아, 사내 K8s 클러스터에 직접 통합하고 실제 서빙 성능을 측정해 볼 기회가 생겼습니다. 본 글에서는 플랫폼 엔지니어의 시각에서 RNGD를 K8s 환경에 통합한 과정과, GPU(RTX 3090) 대비 어느 정도의 전성비와 Prefix Caching 효율을 보여주는지 분석한 벤치마크 결과를 공유합니다.

2. NuFi에 Renegade 추가하기

NuFi에 새로운 디바이스를 추가하는 과정은 크게 세 단계로 나뉩니다. 하드웨어 셋업, 모니터링 연동, 그리고 플랫폼 통합입니다.

2-1. 하드웨어 셋업 & 드라이버 설치

먼저 RNGD 카드를 노드에 장착합니다. RNGD는 12VHPWR 커넥터를 사용하므로, PSU에 해당 케이블이 있는지 사전에 확인이 필요합니다. 카드 장착 후 Furiosa SDK와 런타임을 설치합니다.

그 다음 Kubernetes에서 RNGD를 인식하고 스케줄링할 수 있도록, Furiosa에서 제공하는 Cloud Native Toolkit을 설치합니다.

1. Furiosa Feature Discovery: 노드에 장착된 NPU를 자동으로 감지하고, 노드 라벨을 부여합니다.
2. Furiosa Device Plugin: NPU를 Kubernetes의 스케줄링 가능한 리소스(furiosa.ai/rngd)로 등록합니다.

두 컴포넌트가 정상 동작하면, 노드의 Allocatable 리소스에 furiosa.ai/rngd가 나타납니다.

$ kubectl describe node <node-name>

Allocatable:
  cpu:              32
  memory:           128Gi
  furiosa.ai/rngd:  1    # RNGD 1장 인식

이제 Pod 스펙에서 resources.limits에 furiosa.ai/rngd: "1"을 지정하면 해당 Pod에 RNGD가 할당됩니다.

2-2. 모니터링 연동

디바이스가 인식되었다면, 다음은 모니터링입니다. NuFi 대시보드에서 RNGD의 사용률, 온도, 전력, 메모리를 실시간으로 확인하려면 Prometheus 메트릭이 필요합니다.

Furiosa Metrics Exporter 를 Helm으로 설치합니다.

helm install furiosa-metrics-exporter furiosa/furiosa-metrics-exporter \
  -n monitoring -f values.yaml

# values.yaml
namespace: monitoring

image:
  repository: docker.io/furiosaai/furiosa-metrics-exporter
  pullPolicy: Always
  tag: "2026.1.0"

모니터링 관련 서비스가 "monitoring" 네임스페이스에 배포되어있고 실행당시 최신 버전(2026.1.0)의 도커이미지를 받아올 수 있도록 values.yaml 설정.

그 다음, Prometheus가 이 Exporter를 스크래핑하도록 ServiceMonitor를 생성합니다.

apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: furiosa-metrics-exporter
  namespace: monitoring
  labels:
    release: prometheus
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: furiosa-metrics-exporter
  namespaceSelector:
    matchNames:
      - monitoring
  endpoints:
    - port: metrics
      path: /metrics
      interval: 30s
      scrapeTimeout: 10s

설치 후 Prometheus에서 furiosa_npu_ 접두사의 메트릭들이 수집되는 것을 확인할 수 있습니다.

2-3. 플랫폼 통합

하드웨어와 모니터링이 준비되었으면, NuFi 플랫폼 코드에 RNGD 지원을 추가합니다.

API Server - RNGD Fetcher 추가

NuFi API Server는 DeviceFetcher 인터페이스를 통해 다양한 디바이스의 메트릭을 통합 조회합니다. RNGD용 Fetcher를 구현하여 Furiosa 메트릭을 NuFi 형식으로 변환합니다.

type RngdFetcher struct{}

func (f *RngdFetcher) DeviceInfo() DeviceInfo {
    return DeviceInfo{
        Key: "rngd", Label: "RNGD", Vendor: "FuriosaAI",
        MemLabel: "MEM", ResourceKey: "furiosa.ai/rngd",
    }
}

func (f *RngdFetcher) DeviceQueries() DeviceQuerySet {
    return DeviceQuerySet{
        Utilization: `avg by (hostname, device, ...) (furiosa_npu_core_utilization)`,
        Temperature: `avg by (hostname, device, ...) (furiosa_npu_hw_temperature{label="peak"})`,
        Power:       `avg by (hostname, device, ...) (furiosa_npu_hw_power{label="rms"})`,
        Memory:      `avg by (hostname, device, ...) (furiosa_npu_dram_usage / furiosa_npu_dram_total * 100)`,
    }
}

DeviceRegistry에 RngdFetcher를 등록하면, API Server가 Prometheus 쿼리로 RNGD 존재 여부를 자동 감지하고(furiosa_npu_alive 메트릭) 메트릭 수집을 시작합니다.

모델 서빙 - furiosa-llm

실제 추론 서버는 Furiosa에서 제공하는 도커 이미지(furiosaai/furiosa-llm)를 활용하여 furiosa-llm으로 모델을 서빙합니다. furiosa-llm은 OpenAI 호환 API를 제공하므로, NuFi의 기존 추론 파이프라인(nufi-proxy → 추론 서버)을 그대로 사용할 수 있습니다.

2-4. Lab에서 RNGD 바로 사용해보기

NuFi의 강점 중 하나는 배포뿐만 아니라 개발 환경에서도 NPU를 즉시 활용할 수 있다는 점입니다. NuFi의 Lab 기능을 사용하면, RNGD가 장착된 노드에 Jupyter Notebook 환경을 몇 번의 클릭만으로 생성할 수 있습니다.

Lab 생성 과정

대시보드에서 Lab을 생성할 때, 디바이스로 FuriosaAI RNGD를 선택하고 Furiosa SDK가 포함된 노트북 이미지를 지정하면 됩니다.

Lab이 생성되면 브라우저에서 바로 Jupyter Notebook에 접속할 수 있습니다. RNGD 디바이스가 Pod에 마운트된 상태이므로, 별도의 환경 설정 없이 바로 Furiosa SDK를 import하여 사용할 수 있습니다.

Notebook에서 RNGD로 추론하기

from furiosa_llm import LLM, SamplingParams

# Load the model from Hugging Face model hub
llm = LLM("furiosa-ai/Qwen2.5-0.5B-Instruct")

# You can specify various parameters for text generation
sampling_params = SamplingParams(min_tokens=10, top_p=0.3, top_k=100)

# Prompt for the model
message = [{"role": "user", "content": "What is the capital of France?"}]
prompt = llm.tokenizer.apply_chat_template(message, tokenize=False)

# Generate text
response = llm.generate([prompt], sampling_params)

# Print the output of the model
print(response[0].outputs[0].text)

이처럼 NuFi를 사용하면, 인프라 설정에 대한 깊은 이해 없이도 웹 브라우저만으로 RNGD 위에서 LLM을 실험할 수 있습니다. 모델 서빙 배포 전에 프롬프트를 테스트하거나, 새로운 모델을 빠르게 검증하는 용도로 활용할 수 있습니다.

3. 성능 벤치마크: RNGD vs RTX 3090

RNGD가 NuFi에 정상적으로 통합된 것을 확인한 후, NVIDIA RTX 3090과의 성능을 비교해 보았습니다. Prefix Caching은 OFF 상태로 두 디바이스의 기본 성능을 먼저 비교합니다.

비교 대상에 대해: RTX 3090은 소비자용 GPU이고, RNGD는 데이터센터용 NPU이므로 제품 등급이 다릅니다. A100이나 H100 같은 데이터센터용 GPU와의 비교가 더 적절할 수 있지만, 이번 테스트에서는 클러스터에 당장 사용 가능한 GPU가 RTX 3090뿐이었기에 이를 기준으로 삼았습니다. 따라서 절대적인 GPU vs NPU 성능 비교보다는, 동일 클러스터 내에서 기존 GPU를 NPU로 대체했을 때 어떤 변화가 있는지를 확인하는 데 초점을 맞추고 있습니다.

3-1. 벤치마크 환경

두 디바이스 모두 NuFi를 통해 동일한 Kubernetes 클러스터에 배포하고, 디바이스가 장착된 노드에서 직접 벤치마크 스크립트를 실행했습니다.

RNGD는 FuriosaAI에서 사전 컴파일한 모델(furiosa-ai/Llama-3.1-8B-Instruct)을 사용합니다. 원본 모델은 동일한 meta-llama/Llama-3.1-8B-Instruct입니다.

벤치마크 조건:

• Input: 1024 토큰 (고정 길이, 동일 프롬프트)
• Output: 1024 토큰 (ignore_eos=True)
• 동시 요청 수: 1, 2, 4, 8, 16, 32, 64로 단계적 증가
• 벤치마크 도구: vLLM bench 기반

데이터셋 참고: --dataset-name fixed 옵션은 모든 요청에 동일한 고정 길이 프롬프트를 사용합니다. 3장에서는 Prefix Caching을 OFF한 상태에서 측정하므로 결과에 영향이 없지만, 4장의 Prefix Caching 분석에서는 이 특성이 중요한 의미를 가집니다.

3-2. Throughput 비교

동시 요청 수를 1부터 64까지 늘려가며 Output Token Throughput을 측정했습니다.

RNGD는 모든 동시 요청 수에서 RTX 3090보다 높은 처리량을 보여주었습니다.

특히 주목할 점은 동시 요청이 늘어날수록 격차가 커진다는 것입니다. 동시 요청 1개일 때 RNGD는 RTX 3090 대비 약 29% 높은 처리량을 보였지만, 32개에서는 2.05배, 64개에서는 2.43배까지 차이가 벌어졌습니다. RTX 3090은 동시 요청 16개 이후 처리량이 약 540 tok/s 수준에서 포화되는 반면, RNGD는 64개까지 꾸준히 스케일링되었습니다.

3-3. Latency 비교

동일한 조건에서 TTFT(Time To First Token), TPOT(Time Per Output Token), E2E Latency를 비교합니다.

TTFT (Time To First Token) - 첫 번째 토큰이 생성되기까지의 시간

TTFT에서도 RNGD가 전 구간에 걸쳐 우위를 보였습니다. 동시 요청 1개에서 RNGD는 166ms로 RTX 3090(322ms)의 절반 수준이었고, 동시 요청 64개에서는 4.8초 vs 28.1초로 격차가 극적으로 벌어졌습니다. RTX 3090의 경우 동시 요청 64개의 p99 TTFT가 약 88초에 달해, 실서비스에서는 사실상 사용하기 어려운 수준입니다.

TPOT (Time Per Output Token) - 출력 토큰 간 평균 생성 시간

TPOT 역시 RNGD가 전 구간에서 낮았습니다. 동시 요청 1개 기준 RNGD는 15.4ms로 RTX 3090(19.7ms)보다 22% 빠르게 토큰을 생성했습니다. 이 차이는 동시 요청이 증가해도 유지되어, 사용자가 체감하는 텍스트 생성 속도가 일관되게 빠릅니다.

E2E Latency (End-to-End) - 요청 시작부터 응답 완료까지의 전체 시간

E2E Latency는 TTFT와 TPOT의 차이가 누적된 결과입니다. 동시 요청 64개에서 RNGD는 평균 45.9초, RTX 3090은 74.0초로 약 38% 더 빠르게 응답을 완료했습니다.

3-4. 전력 효율

NPU의 핵심 강점 중 하나는 전력 효율입니다. 벤치마크 진행 중 furiosa_npu_hw_power 메트릭과 nvidia_smi_power_draw 메트릭을 수집하여 Tokens/Watt를 비교했습니다.

RTX 3090은 부하와 관계없이 항상 TDP 근처인 약 340W를 소비합니다. 반면 RNGD는 동시 요청 1개일 때 약 123W, 64개일 때도 약 158W로, GPU 대비 절반 이하의 전력을 사용합니다.

이를 처리량과 결합한 Output Tokens/Watt 지표로 보면 차이가 더 명확해집니다.

RNGD는 모든 동시 요청 수준에서 RTX 3090 대비 3.2~5.3배 높은 전력 효율을 보여주었습니다. 동시 요청이 늘어날수록 GPU의 효율은 거의 개선되지 않는 반면, RNGD는 꾸준히 효율이 올라갑니다.

데이터센터 규모에서 이 차이는 곧 전력 비용과 냉각 인프라의 차이로 이어집니다. 동일한 처리량을 달성하는 데 필요한 전력이 수 배 적다는 것은, 운영 비용 측면에서 상당한 이점입니다.

3-5. 결과 요약 및 분석

Prefix Caching OFF 상태에서 RNGD vs RTX 3090의 비교 결과를 요약하면 다음과 같습니다.

정리하자면, RNGD는 단순히 "빠르다"를 넘어, 압도적인 전성비(Performance per Watt)로 스케일링된다는 점이 인상적이었습니다. RTX 3090 대비 더 높은 처리량을 절반도 안 되는 전력으로 달성했으며, 특히 동시 요청이 많은 실서비스 환경에서 GPU가 보여준 급격한 성능 저하 없이 안정적으로 스케일링되었습니다.

4. RNGD Prefix Caching 효과 분석

4-1. Prefix Caching이란?

LLM 추론에서는 모든 요청이 모델의 Attention 레이어를 통과하며 KV Cache를 생성합니다. Prefix Caching은 여러 요청이 동일한 접두사(예: System Prompt)를 공유할 때, 해당 부분의 KV Cache를 재활용하여 중복 연산을 제거하는 최적화 기법입니다.

요청 1: [System Prompt] + "오늘 날씨 알려줘"     → System Prompt의 KV Cache 생성
요청 2: [System Prompt] + "회의 일정 잡아줘"     → System Prompt의 KV Cache 재활용 (Cache Hit!)
요청 3: [System Prompt] + "코드 리뷰 해줘"       → System Prompt의 KV Cache 재활용 (Cache Hit!)

Cache Hit이 발생하면 Prefill 단계의 연산량이 크게 줄어들어 TTFT가 단축되고, 그만큼 다른 요청을 더 빨리 처리할 수 있으므로 전체 Throughput도 향상됩니다.

Furiosa SDK 2026.1.0 릴리즈에서 Prefix Caching이 새로운 주요 기능으로 추가되었습니다. Branch-compressed radix tree 기반으로 요청 간 공통 Prefix를 자동 감지하고, SIMD 최적화된 접두사 매칭으로 TTFT를 크게 줄여준다고 합니다. 이 방식은 SGLang의 RadixAttention과 유사한 접근으로, vLLM의 블록 단위 해싱(SHA-256)과는 달리 토큰 수준의 radix tree 탐색으로 prefix를 매칭합니다. 이번에 RNGD를 통합하면서 마침 해당 릴리즈를 사용하게 되었기에, 실제로 얼마나 효과가 있는지 직접 측정해 보았습니다.

4-2. 실험 조건

3장과 동일한 벤치마크 환경에서, Prefix Caching을 ON/OFF하여 동일한 워크로드를 실행하고 결과를 비교합니다.

이번 벤치마크에서 사용한 vLLM의 --dataset-name fixed 옵션은 모든 요청에 동일한 1024 토큰 프롬프트를 사용합니다. 따라서 첫 번째 요청에서 생성된 KV Cache가 이후 요청에서 그대로 재활용되어, Cache Hit Rate가 거의 100%에 가까운 이상적인 조건입니다.

이는 실서비스에서 모든 요청이 동일한 System Prompt를 공유하는 챗봇 시나리오와 유사합니다. Prefix Caching이 최대한의 효과를 발휘할 수 있는 상한선(upper bound)으로 해석하는 것이 적절합니다.

4-3. 결과

TTFT 변화

Prefix Caching의 가장 직접적인 효과가 나타나는 지표입니다.

동시 요청 1개에서는 Cache OFF가 오히려 약간 빠릅니다. 첫 번째 요청은 캐시가 비어 있어 Cache Hit이 발생하지 않고, 캐시 관리 오버헤드만 추가되기 때문입니다. 하지만 동시 요청 2개 이상에서부터 이전 요청의 KV Cache가 재활용되면서 효과가 뚜렷하게 나타납니다. 동시 요청 64개에서는 TTFT가 4,814ms → 815ms로 83% 감소했습니다. 1024 토큰 전체가 Cache Hit되면서 Prefill 연산이 거의 생략된 결과입니다.

Throughput 변화

Throughput 개선은 동시 요청이 많을수록 두드러집니다. 동시 요청 64개에서는 23.3%의 처리량 증가를 보였습니다. TTFT가 줄어들면서 요청 간 대기 시간이 감소하고, 같은 시간에 더 많은 요청을 처리할 수 있게 된 결과입니다.

전력 효율 변화 (TPS/W)

Prefix Caching은 전력 효율도 함께 개선합니다.

Prefix Caching ON 상태에서 RNGD는 c=64 기준 11.34 tok/s/W를 달성했습니다. 이는 같은 조건의 RTX 3090 Prefix Caching ON(4.09 tok/s/W)과 비교해도 2.8배 높은 수치입니다.

4-4. 참고: GPU에서의 Prefix Caching 효과

비교를 위해 RTX 3090에서도 동일하게 Prefix Caching ON/OFF를 테스트했습니다.

GPU에서도 Prefix Caching의 효과는 극적입니다. 특히 c=32 이상에서 처리량이 2배 이상 증가했습니다. 이는 앞서 3장에서 관찰한 GPU의 c=16 이후 처리량 포화 현상의 원인을 설명해 줍니다. 동일 프롬프트의 KV Cache가 재활용되면서 요청당 필요한 KV Cache 메모리가 크게 줄어들었고, 그 결과 더 많은 요청을 동시에 처리할 수 있게 되면서 병목이 해소된 것입니다.

흥미로운 점은, Prefix Caching ON 상태에서 TTFT는 GPU가 RNGD보다 빠르다는 것입니다. c=64 기준 GPU 373ms vs RNGD 815ms로, GPU의 Prefill 처리 자체는 더 빠릅니다. 그러나 Throughput, TPOT, 전력 효율에서는 여전히 RNGD가 우위를 유지합니다. 즉, GPU는 "첫 토큰을 빨리 뱉는 데" 강하고, RNGD는 "전체 응답을 효율적으로 빨리 완료하는 데" 강합니다.

4-5. 실전 적용 시사점

이번 벤치마크는 Cache Hit 100%라는 이상적인 조건에서의 Prefix Caching 상한선을 보여줍니다. 실서비스에서의 효과는 Cache Hit Rate에 따라 달라지며, 다음과 같은 패턴에서 높은 Cache Hit Rate를 기대할 수 있습니다.

• 챗봇 서비스: 모든 대화가 동일한 System Prompt로 시작하는 경우. 이번 벤치마크와 가장 유사한 시나리오로, System Prompt가 길수록 효과가 큽니다.
• RAG(Retrieval-Augmented Generation): 검색된 문서 컨텍스트가 여러 후속 질문에서 반복되는 경우.
• 배치 처리: 동일한 지시문(instruction)으로 대량의 데이터를 처리하는 워크로드.

반대로, 매 요청마다 입력이 완전히 다른 워크로드에서는 Cache Hit이 발생하지 않으므로 Prefix Caching의 효과가 제한적입니다.

이번 실험은 동일 프롬프트 반복이라는 최적 조건에서의 결과입니다. Cache Hit Rate가 변화할 때 성능이 어떻게 달라지는지(예: Prefix 길이 비율별, 부분 일치 시나리오 등)에 대한 추가 실험도 진행해보면 좋을 것 같습니다.

5. 마무리

이번에 Furiosa Renegade를 NuFi 플랫폼에 추가하면서, 새 NPU 디바이스를 Kubernetes 환경에 통합하는 전 과정을 경험했습니다. Device Plugin, Metrics Exporter, ServiceMonitor 등 Kubernetes 생태계의 표준 인터페이스를 잘 지원하고 있어, 기존 GPU 통합 경험이 있다면 비교적 수월하게 진행할 수 있습니다.
또한, NuFi의 Lab 기능을 통해 RNGD가 장착된 노드에 Jupyter Notebook 환경을 즉시 생성할 수 있어, 모델 서빙 배포 전에 프롬프트 테스트나 새로운 모델 검증을 웹 브라우저만으로 간편하게 수행할 수 있었습니다.

NuFi는 DeviceFetcher 인터페이스를 통해 새로운 디바이스를 추상화하고 있어, RNGD 추가 시에도 플랫폼 코어 로직의 변경 없이 Fetcher 하나와 Dashboard 옵션 추가만으로 통합이 완료되었습니다.

성능 측면에서는, RNGD가 RTX 3090 대비 전 구간에서 높은 처리량과 낮은 레이턴시를 보여주었습니다. 특히 동시 요청이 많아지는 실서비스 환경에서 GPU가 보이는 급격한 성능 저하 없이 안정적으로 스케일링되었고, 전력 효율은 최대 5.3배(Prefix Caching OFF), 최대 6.8배(Prefix Caching ON 기준, c=32) 차이를 보였습니다. Prefix Caching의 경우, 동일 프롬프트 반복(Cache Hit 100%) 조건에서 TTFT 최대 83% 감소, 처리량 최대 23% 증가를 확인했으며, 이는 챗봇 등 공통 System Prompt를 사용하는 서비스에서 기대할 수 있는 상한선입니다.

국내 NPU 생태계가 빠르게 성장하고 있습니다. GPU 의존도를 낮추면서도 효율적인 LLM 서빙이 가능한 선택지가 늘어나고 있다는 점에서, 앞으로의 발전이 기대됩니다.

참고 자료

Furiosa RNGD

• RNGD 하드웨어 개요
• Furiosa SDK 2026.1.0 릴리즈 노트

Furiosa Cloud Native Toolkit (K8s 통합)

• Feature Discovery
• Device Plugin
• Metrics Exporter

벤치마크 도구

• vLLM bench

Prefix Caching 배경 지식

• SGLang RadixAttention 소개
• vLLM Automatic Prefix Caching Design
• SGLang vs vLLM: Token-Level Radix Tree vs Block-Level Hashing