LLM WikiAccess-protected knowledge portal
← 스터디 홈
134편 · 약 13분

KAIROS: 에이전트 AI 추론에서 GPU 전력을 컨텍스트 인식 주파수 제어로 27% 줄이는 방법

요약

AI 추론 클러스터의 전력 비용은 2026년 기준 GPU 인프라 운영의 핵심 병목 중 하나다. 하지만 기존 전력 최적화 연구 대부분은 단일 요청을 독립적으로 처리하는 무상태 LLM 서빙을 전제로 한다. 에이전트 AI 워크로드는 이 전제를 위반한다.

KAIROS(arXiv:2604.16682, April 2026)는 에이전트 추론의 구조적 특성 — 도구 호출 사이의 긴 유휴 구간, 다턴에 걸쳐 성장하는 KV 캐시 — 을 GPU 주파수 제어의 입력 신호로 사용한다. 요청을 단건이 아닌 에이전트 세션 단위로 추적함으로써 메모리 압박이 생기기 전에 주파수를 선제적으로 조정한다.

핵심 결과:

  • 평균 27% 전력 절감 (최대 39.8%)
  • 목표 SLO 이내 성능 유지
  • 에이전트 워크로드는 컨텍스트 캐싱 덕분에 디코드 도미네이티드 — DVFS 활용 여지가 단순 프리필 서빙보다 훨씬 크다

배경: 왜 에이전트 서빙은 다른가

단일 요청 서빙 vs 에이전트 세션 서빙

단일 턴 LLM 서빙에서는 각 요청이 독립적이다. 프리필 → 디코드 → 응답 반환, 끝이다. GPU는 요청 간에 다음 배치를 기다리며 유휴 상태가 된다.

에이전트 세션은 다르다.

에이전트 세션 타임라인 (단일 AgentRun):

  Turn 1: [프리필] → [디코드: tool_call] → [유휴: tool 실행 대기] → Turn 2
  Turn 2: [프리필: 도구 결과 추가] → [디코드: tool_call] → [유휴] → Turn 3
  ...
  Turn N: [프리필: 누적 컨텍스트] → [디코드: 최종 응답]

  KV 캐시 크기: Turn마다 증가 (컨텍스트 길이 ∝ 턴 수)

이 구조가 전력 최적화에 두 가지 함의를 만든다:

  1. 도구 실행 유휴 구간: GPU가 쉬는 시간이 길다 → 주파수를 낮춰도 응답시간에 영향 없음
  2. KV 캐시 성장: 메모리 압박이 턴마다 증가 → 주파수를 잘못 낮추면 메모리 대역폭이 부족해 스래싱

스래싱 문제: GPU 주파수를 낮추면 왜 오히려 더 느려지는가

스래싱 메커니즘: GPU 주파수 인하의 부작용 KV 캐시 크기 (컨텍스트 길이 증가 →) 성능 (토큰/초) 주파수 고정 단순 DVFS (무상태) KAIROS 메모리 대역폭 포화 구간 스래싱 경로: 주파수 인하 → SM 클록 감소 → 연산 지연 → KV 캐시 액세스 지연 → 컨텍스트 메모리 압박 → 더 많은 재계산 → 오히려 전력↑ + 성능↓
DVFS 스래싱: 주파수 인하와 메모리 대역폭 경쟁

디코드 단계에서 GPU의 병목은 연산(compute-bound)이 아니라 메모리 대역폭(memory-bound)이다. KV 캐시가 클수록 각 토큰 생성에 더 많은 메모리 읽기가 필요하다. GPU 주파수를 낮추면 HBM 대역폭이 함께 줄어, 이미 메모리 병목인 디코드가 더 느려진다. 이 속도 저하가 배치 내 요청 지연을 늘리고, 결국 SLO를 위반하거나 큐를 쌓아 전력 효율이 나빠진다.


KAIROS 설계

세 가지 제어 레버

KAIROS는 에이전트 요청의 상태를 추적해 세 가지 제어를 동시에 조정한다.

에이전트 컨텍스트 트래커
· 세션 ID → 현재 KV 캐시 크기
· 도구 호출 유휴 상태 감지
· 컨텍스트 성장률 추정
컨텍스트 인식 컨트롤러
· 메모리 여유 공간 모니터링
· 시스템 부하 신호 수집
· 스래싱 임박 감지
GPU 주파수 (DVFS)
인스턴스당 동시성
멀티-인스턴스 배치
KAIROS 제어 아키텍처

GPU 주파수 (DVFS): 메모리 여유가 있고 도구 유휴 중이면 주파수를 낮춘다. KV 캐시가 임계치 가까이 차거나 디코드 강도가 높아지면 주파수를 올린다.

인스턴스당 동시성: 에이전트 세션이 많아지고 KV 캐시 점유가 증가하면, 새 요청을 수락하는 비율을 줄여 메모리 압박을 완화한다.

멀티-인스턴스 배치: 긴 컨텍스트 세션과 짧은 컨텍스트 세션을 분리된 인스턴스에 배치해 메모리 경쟁을 줄인다.

에이전트 세션 인식이 핵심인 이유

기존 DVFS는 요청 단위로 슬랙(여유 시간)을 측정한다. 에이전트 세션에서는 이 접근이 실패한다.

  • Turn 3의 프리필은 Turn 1~2의 KV 캐시를 전제한다
  • 현재 요청의 슬랙만 보면 누적 메모리 압박이 보이지 않는다
  • KAIROS는 세션 전체의 컨텍스트 성장 이력을 유지해 미래 메모리 압박을 예측한다

에이전트 워크로드의 특성: 왜 DVFS 여지가 더 큰가

KAIROS 논문이 밝힌 핵심 관찰은 에이전트 워크로드의 실행 특성이다.

에이전트 서빙의 실행 시간 분포 무상태 LLM 서빙 프리필 60% 디코드 20% 유휴 에이전트 AI (컨텍스트 캐싱) 프리필 13% 디코드 67% 도구 유휴 20% 무상태: 프리필 지배적 프리필은 연산 집약적 → DVFS 여지 작음 주파수를 낮추면 프리필 시간 직접 증가 전력 절감 효과 제한적 에이전트: 디코드 지배적 공통 프리필 토큰은 캐싱 → 재연산 불필요 디코드+유휴 구간이 87% → DVFS 여지 큼 단, 메모리 압박 구간은 예외적으로 관리 필요
에이전트 실행의 두 국면: 프리필 vs 디코드 비율

컨텍스트 캐싱이 효과적으로 작동하는 에이전트 워크로드에서는, 누적 컨텍스트의 대부분이 재사용된다. Turn 3의 프리필 단계에서 Turn 1~2의 KV 캐시는 이미 메모리에 있어 재연산이 필요 없다. 따라서 전체 실행 시간 중 프리필의 비중이 줄고 디코드의 비중이 커진다. 디코드는 메모리 대역폭 병목이지 연산 병목이 아니므로, 주파수를 낮춰도 — 메모리 압박이 없는 구간에서는 — 성능에 영향이 작다.


실험 결과

전력 절감

KAIROS는 다양한 소프트웨어 엔지니어링 및 데이터 엔지니어링 에이전트 태스크(SWE-bench, GAIA 등)에서 평가되었다.

시나리오전력 절감SLO 준수율
평균27%99%+
최대 절감39.8%99%+
컨텍스트 짧은 태스크~15%99%+
컨텍스트 긴 태스크~35~40%99%+

비교 대상

기준선전력 절감특성
주파수 고정 (최대)0%기준
단순 DVFS (슬랙 기반)~18%에이전트 컨텍스트 무시 → SLO 위반 발생
KAIROS27%컨텍스트 인식 → SLO 유지

단순 DVFS는 에이전트 세션의 KV 캐시 성장을 인식하지 못해, 스래싱 구간에서 SLO를 위반하면서도 전력을 덜 절감한다. KAIROS는 두 지표 모두에서 앞선다.


운영 시사점

언제 KAIROS류 접근이 유효한가

이 연구는 현재 오픈소스로 공개된 프로덕션 시스템이 아니다. 그러나 이 설계 원칙은 vLLM, SGLang 같은 기존 서빙 프레임워크에서도 적용 가능하다.

에이전트 서빙 전력 최적화를 고려하는 팀을 위한 체크리스트:

  • [ ] 에이전트 세션 추적: 요청 단위가 아닌 세션(AgentRun) 단위로 KV 캐시 크기를 모니터링하고 있는가?
  • [ ] DVFS 가드레일: GPU 주파수를 낮출 때 KV 캐시 점유율을 확인하는가? (임계값 권고: 60~70% 이상이면 인하 중단)
  • [ ] 도구 유휴 감지: 에이전트가 외부 도구 응답을 기다리는 구간을 식별해 주파수를 낮추는가?
  • [ ] 전력 + 성능 공동 모니터링: 전력 절감 시 SLO 위반율이 함께 오르지 않는지 검증하는가?

에이전트 AI 전력 비용의 실제 규모

KAIROS 논문이 인용하는 산업 추정치에 따르면, 에이전트 AI 서빙의 전력 소비는 동일 GPU에서 단일 턴 서빙 대비 수 배에서 수십 배 높을 수 있다. 이 차이는:

  • 긴 컨텍스트로 인한 KV 캐시 메모리 점유 증가
  • 다턴 워크로드로 인한 GPU 점유 시간 연장
  • 도구 호출 간 유휴 상태에서의 불필요한 고주파수 유지

에 기인한다. 10만 GPU를 운영하는 클러스터에서 27%의 전력 절감은 데이터센터 규모의 의사결정 수준 차이가 된다.


한계와 오픈 질문

  • 모델 독립성: 실험은 특정 모델과 하드웨어(H100)에서 수행. 다른 GPU 세대(Hopper 대비 Blackwell)나 MLA 기반 모델에서의 효과는 별도 검증 필요.
  • 예측 정확도: KV 캐시 성장 예측이 빗나가면(예: 에이전트가 예상보다 짧게 응답하면) 주파수를 불필요하게 높게 유지할 수 있다.
  • 컨텍스트 공유 시나리오: 여러 에이전트가 동일 시스템 프롬프트를 공유하는 경우(prefix cache 공유) KV 캐시 어트리뷰션이 복잡해진다.

Open question: 에이전트 서빙에서 GPU 주파수가 아닌 전력 예산 직접 제어(PowerCap) 접근은 어떤 트레이드오프를 만드는가?


요점 정리

KAIROS가 던지는 메시지는 단순하다: 에이전트 AI를 서빙할 때는 요청 단위가 아닌 세션 단위로 시스템을 봐야 한다.

기존 전력 최적화는 "이 요청을 처리하고 남은 시간이 있는가"를 묻는다. KAIROS는 "이 세션이 앞으로 얼마나 더 많은 메모리를 점유할 것인가"를 묻는다. 이 관점의 전환이 27%의 전력 절감과 SLO 유지를 동시에 가능하게 한다.


References