요약
에이전트 AI 워크로드는 단일 턴 LLM 서빙과 근본적으로 다르다. 각 요청은 수십 번의 도구 호출을 거치며 컨텍스트가 길게 쌓이고, GPU 메모리 압력은 세션 전체에 걸쳐 동적으로 변한다. 기존 GPU 전력 관리 기법은 단일 턴 서빙을 가정하므로, 에이전트 서빙에 그대로 적용하면 메모리 스래싱(thrashing)을 일으켜 오히려 전력 효율이 나빠진다.
KAIROS(arXiv:2604.16682, 2026년 4월)는 에이전트 요청의 컨텍스트 상태를 1등급 제어 신호로 삼아 GPU 주파수, 인스턴스 동시성, 멀티 인스턴스 배치를 함께 관리하는 전력 최적화 시스템이다. NVIDIA H100에서 vLLM 위에 구현해 SWE-bench Verified, DABStep, Terminal-Bench 2.0을 평가한 결과, 단일 인스턴스 평균 27%(최대 39.8%), 멀티 인스턴스 46.3%의 GPU 전력 절감을 달성하면서 에이전트 처리량 SLO를 유지했다.
문제: 에이전트 서빙에서의 전력 관리
단일 턴 가정의 붕괴
기존 LLM 서빙 전력 관리는 한 번의 프롬프트 → 응답 사이클을 단위로 삼는다. 요청이 짧고 독립적이므로, GPU 주파수를 낮춰 전력을 줄이면 응답 지연이 소폭 늘어나는 단순한 트레이드오프가 성립한다.
에이전트 추론은 다르다.
- 긴 컨텍스트: 코딩 에이전트가 여러 파일을 검색하고 수정하면 KV 캐시가 수십만 토큰까지 쌓인다.
- 도구 호출 사이의 유휴: 외부 도구 실행을 기다리는 구간과 LLM 생성 구간이 교차한다.
- 동적 메모리 압력: 컨텍스트가 길어지면 KV 캐시가 GPU 메모리를 가득 채우고, 이 상태에서 주파수를 낮추면 배칭이 줄고 메모리 I/O가 늘어나 스래싱 진입 위험이 높아진다.
스래싱 문제
GPU 주파수를 무조건 낮추면 메모리 대역폭 대비 컴퓨트 비율이 무너진다. KV 캐시가 가득 찬 상태에서 배치 크기를 줄이면 메모리 바운드(memory-bound) 구간이 늘어나 전력 대비 처리량이 오히려 감소한다. KAIROS 논문은 이 현상을 스래싱 레짐(thrashing regime)이라 부르고, 에이전트 서빙에서 컨텍스트 상태를 모르면 스래싱을 피할 수 없다고 지적한다.
KAIROS 설계
컨텍스트를 1등급 제어 신호로
KAIROS의 핵심 아이디어는 간단하다: 에이전트 요청의 현재 상태를 알면, 지금 전력을 줄여도 스래싱이 없을지 판단할 수 있다.
KAIROS는 세 가지 컨텍스트 신호를 실시간으로 추적한다.
| 신호 | 의미 | 제어 연관성 |
|---|---|---|
| 컨텍스트 길이 증가율 | KV 캐시가 얼마나 빠르게 늘고 있는가 | 급증 구간이면 주파수 낮추기 위험 |
| 메모리 압력 | GPU HBM 대비 KV 캐시 점유율 | 높으면 배칭 한계 → 스래싱 위험 |
| 에이전트 진행도 | 도구 호출 대기, 생성, 추론 중 어느 단계인가 | 유휴 구간은 전력 절감 기회 |
세 가지 제어 레버
KAIROS는 이 신호들을 입력으로 받아 세 가지 레버를 함께 조정한다.
GPU 주파수(DVFS): 메모리 압력이 낮고 컨텍스트가 안정적이면 주파수를 낮춰 전력을 줄인다. 스래싱 위험이 감지되면 주파수를 원복한다.
인스턴스 동시성: 한 vLLM 인스턴스에서 병렬로 처리하는 요청 수를 조절한다. 메모리 압력이 높으면 동시성을 줄여 KV 캐시 충돌을 방지한다.
멀티 인스턴스 배치: 여러 GPU 인스턴스에 요청을 분산할 때, 컨텍스트 상태를 고려해 어느 인스턴스에 새 요청을 보낼지 결정한다.
평가 결과
실험 환경
KAIROS는 NVIDIA H100 GPU에서 vLLM을 사용하는 환경으로 평가됐다. 에이전트 타입은 두 가지다.
- mini-swe-agent: 소프트웨어 엔지니어링 작업 자동화 에이전트
- Terminus-2: 터미널 조작 기반 범용 에이전트
평가 데이터셋:
| 데이터셋 | 도메인 |
|---|---|
| SWE-bench Verified | 실제 GitHub 이슈 해결 |
| DABStep | 데이터 분석 및 의사결정 |
| Terminal-Bench 2.0 | 터미널 명령 실행 |
전력 절감 결과
| 구성 | GPU 전력 절감 |
|---|---|
| 단일 인스턴스 (평균) | 27% |
| 단일 인스턴스 (최대) | 39.8% |
| 멀티 인스턴스 | 46.3% |
SLO 조건은 P5 처리량 20 토큰/s 유지다. KAIROS는 이 조건을 지키면서 전력을 줄인다. 단순히 GPU 주파수를 낮추는 기존 방식과 달리, 메모리 압력이 높은 구간에서는 주파수를 낮추지 않아 스래싱을 회피한다.
기존 전력 관리와의 차이
| 기준 | 단순 DVFS | SLO 인식 DVFS | KAIROS |
|---|---|---|---|
| 제어 기준 | GPU 전체 고정 | 요청 지연 목표 | 에이전트 컨텍스트 상태 |
| 스래싱 인식 | ✗ | ✗ | ✓ |
| 멀티 레버 조정 | ✗ | 부분 | ✓ (주파수 + 동시성 + 배치) |
| 에이전트 워크로드 특화 | ✗ | ✗ | ✓ |
SLO 인식 DVFS(GreenLLM 등)는 응답 지연 목표를 기준으로 주파수를 조정하지만, 에이전트 컨텍스트 상태를 직접 추적하지는 않는다. KAIROS는 컨텍스트 상태가 스래싱 결정의 핵심 변수임을 명시적으로 모델링한다.
운영 관점의 고려사항
언제 유용한가
KAIROS가 의미 있는 시나리오:
- GPU 전기세가 핵심 비용인 서빙 클러스터: 수백 H100을 운영하는 환경에서 27~46%의 GPU 전력 절감은 직접적인 운영 비용 절감이다.
- 에이전트 세션이 길고 컨텍스트가 많이 쌓이는 워크로드: 단순 RAG나 단일 턴 Q&A는 효과가 제한적이다. 수십 번의 도구 호출이 일어나는 코딩 에이전트나 리서치 에이전트가 주 대상이다.
- 멀티 인스턴스 vLLM 배포: 멀티 인스턴스 구성에서 46.3% 절감으로 효과가 더 크다.
현재 상태
KAIROS는 2026년 4월 arXiv 프리프린트 단계다. 프로덕션 적용 전 확인이 필요한 사항:
- 오픈소스 코드 공개 여부
- vLLM 외의 서빙 프레임워크(SGLang, TensorRT-LLM) 지원 범위
- A100/H200 등 다른 GPU 아키텍처로의 이식성
- DVFS 제어 권한이 필요한 인프라 요건 (클라우드 관리형 GPU 노드에서의 제어 가능 여부)
Open question: 클라우드 관리형 GPU(GKE GPU 노드 등)에서 DVFS를 직접 제어할 수 있는지 여부와 KAIROS 공개 코드 저장소 존재 여부.
정리
KAIROS는 "에이전트 추론은 상태가 있다"는 단순한 관찰에서 출발한다. 컨텍스트가 쌓일수록 메모리 압력이 달라지고, 도구 호출 대기 중인지 생성 중인지에 따라 전력 절감 가능 여부가 결정된다. 이 상태를 추적해 GPU 주파수·동시성·배치를 함께 조정하면, SLO를 지키면서도 단일 인스턴스 27%, 멀티 인스턴스 46.3%의 전력을 아낄 수 있다. MORI가 도구 대기 시간을 KV 캐시 오프로딩 기회로 전환하는 것처럼, KAIROS는 그 도구 대기 구간을 전력 최적화 기회로 활용한다.
References
- Yichao Yuan, Mosharaf Chowdhury, Nishil Talati, "KAIROS: Stateful, Context-Aware Power-Efficient Agentic Inference Serving," arXiv:2604.16682, April 2026. https://arxiv.org/abs/2604.16682
- GreenLLM: SLO-Aware Dynamic Frequency Scaling for Energy-Efficient LLM Serving, arXiv:2508.16449. https://arxiv.org/abs/2508.16449
- GoodServe: Towards High-Goodput Serving of Agentic LLM Inferences over Heterogeneous Resources, arXiv:2605.16867. https://arxiv.org/abs/2605.16867
- vLLM project. https://github.com/vllm-project/vllm
- SWE-bench Verified. https://www.swebench.com/verified.html