볼칸 LLM 기반 검색을 통한 인스턴스 최적 시스템 휴리스틱

읽는 시간: 9 분
...

📝 원문 정보

- Title: Vulcan Instance-Optimal Systems Heuristics Through LLM-Driven Search
- ArXiv ID: 2512.25065
- 발행일: 2025-12-31
- 저자: Rohit Dwivedula, Divyanshu Saxena, Sujay Yadalam, Daehyeok Kim, Aditya Akella

📝 초록

현대의 운영 시스템과 분산 시스템에서 리소스 관리 작업은 스케ジューリング, 캐싱, 또는 활성 큐 관리를 위한 주로 손으로 설계된 휴리스틱에 의존하고 있습니다. 성능이 좋은 휴리스틱을 설계하는 것은 하드웨어, 워크로드 및 환경의 지속적인 변화로 인해 비용이 많이 들고 시간이 오래 걸리는 과정입니다. 저희는 새로운 대안을 제안합니다: 코드 생성형 대형 언어 모델(LLM)을 사용하여 특정 작업과 하드웨어에 특화된 인스턴스 최적 휴리스틱을 합성하는 것입니다. 이 합성을 가능하게 하기 위해 Vulcan은 LLM 친화적인 작업 무관 인터페이스를 통해 정책과 메커니즘을 분리합니다. 이러한 인터페이스를 통해 사용자는 원하는 정책의 입력과 목표를 지정하고, Vulcan은 LLM 생성 코드를 통해 진화 알고리즘을 이용해 성능이 좋은 정책을 탐색합니다. 이 인터페이스는 다양한 시스템 정책을 포괄할 만큼 표현력이 있지만, 작은 규모의 저렴한 LLM들도 올바르고 실행 가능한 코드를 생성할 수 있을 정도로 제약적입니다. 저희는 Vulcan을 이용해 캐시 추방 및 메모리 라이어링에 대한 성능이 좋은 휴리스틱을 합성하고, 이러한 휴리스틱들이 각각의 작업에서 최대 69%와 7.9%의 성능 개선으로 인간 설계의 최신 알고리즘보다 우수함을 발견하였습니다.

💡 논문 해설

1. **새로운 프레임워크**: Vulcan은 시스템 휴리스틱을 자동으로 생성하는 첨단 방법론입니다. 이는 복잡한 성능 최적화를 위해 수작업이 아닌 AI 기반 접근법을 활용합니다. 2. **LLM 활용**: 대형 언어 모델(Large Language Models, LLMs)은 Vulcan에서 핵심 역할을 합니다. Vulcan은 LLM을 사용하여 정책 로직을 생성하고 이를 시스템 상태와 연관시킵니다. 3. **구성 요소 분리**: Vulcan은 휴리스틱의 '정책'과 '기제'를 명확하게 구분합니다. 이를 통해 복잡한 성능 최적화 작업을 단순화하며, 다양한 시나리오에 맞는 최적의 휴리스틱을 생성할 수 있습니다.

📄 논문 발췌 (ArXiv Source)

# 소개

시스템 연구는 오랫동안 휴리스틱 설계를 수작업으로 다루어 왔습니다. 성능이 중요한 시스템은 일반적인 조건을 위해 손으로 작성된 휴리스틱에 의존하며, 이를 정적이고 하나의 크기로 모든 상황에 맞는 정책으로 배포합니다. 그러나 캐싱, 혼잡 제어, 커널 대기열 규칙, 메모리 계층화 등 여러 분야에서 수십 년 동안의 연구 결과는 같은 교훈을 보여줍니다: 만능 휴리스틱은 없습니다. 다양한 설정은 다른 휴리스틱을 필요로 하며, 성능을 위해서는 전문화가 필수적입니다.

따라서 우리는 계속해서 튜닝과 재설계를 반복합니다(§2.1): 새로운 네트워크 환경에 맞춰 혼잡 제어 알고리즘을 튜닝하거나, 새롭게 나타나는 워크로드 또는 하드웨어를 위해 예측 캐싱 정책을 조정하고, 새로운 성능 목표를 위해 대기열 규칙을 진화시킵니다. 그러나 이러한 재튜닝에도 불구하고, 수작업으로 설계된 휴리스틱에서 아직도 최적의 성능을 찾지 못하는 경우가 많습니다. 휴리스틱 설계 공간은 컨텍스트에 따른 동작과 변화하는 성능 거래 조건에 따라 지속적으로 변하기 때문에, 각 시나리오에 맞는 ‘정확한’ (즉, 최적의) 휴리스틱을 발견하고 유지하는 것이 점점 더 어려워지고 있습니다. 이로 인해 본질적인 질문이 제기됩니다: ‘올바른 휴리스틱’을 얼마나 빨리 발견할 수 있을까요, 계속 진화하는 배포 조건에 맞춰?

우리는 Vulcan이라는 프레임워크를 사용하여 이러한 지속적인 도전을 해결하려고 합니다. 이 프레임워크에서는 휴리스틱 설계 문제를 대형 언어 모델(Large Language Models, LLMs)을 이용한 자동 탐색 문제로 재구성합니다: 수작업으로 휴리스틱을 작성하는 대신, 우리는 생성 모델을 반복적으로 호출하여 각 배포 컨텍스트에 맞는 인스턴스 최적의 휴리스틱을 생산합니다. 우리의 프레임워크는 LLM을 사용한 알고리즘 합성을 포함하는 최근 연구에서 영감을 받았습니다, 이는 생성 모델과 진화 검색을 결합하여 목표 양적 보상 함수를 최대화하는 표현력 있는 코드를 발견합니다.

그러나 이러한 탐색 기반 기법을 직접 시스템 휴리스틱에 적용하는 것은 쉽지 않습니다(§2.3). 현대의 시스템 휴리스틱은 정책(고수준 결정 논리)과 기제(저수준 상태, 데이터 구조 및 제어 경로)가 긴밀하게 결합되어 있습니다. 결과적으로, 휴리스틱을 수정하거나 개선하려면 의도와 구현에 대한 조화된 추론이 필요합니다. 이러한 설정에서 단순히 LLM에게 완전한 end-to-end 휴리스틱을 합성하도록 요청하는 것은 무의미합니다(§2.3). 반면에, 알려진 알고리즘 위에서 미세한 조정을 제한하는 것은 진정한 혁신의 기회를 제한합니다.

따라서 핵심적인 도전은 현재 LLM이 가장 강점을 발휘할 수 있는 부분 – 구조화된 신호에 대한 추론과 고수준 결정 논리의 표현 – 을 활용하면서, 복잡한 메커니즘을 올바르게 구현하거나 복잡한 시스템 상태를 관리하는 것을 요구하지 않는 방법을 찾는 것입니다. Vulcan은 LLM 주도의 진화 검색을 휴리스틱 설계의 핵심에 두고, 정책과 기제를 명확하게 분리하며 탐색을 실현 가능한 세 단계 파이프라인(3 in §3)을 노출하여 이러한 긴장관계를 해결합니다.

파이프라인의 첫 번째 단계에서는 사용자가 검색 공간을 정의함으로써 문제를 좁은 인터페이스로 바꾸는 방법을 캐스팅합니다(§3.1). 우리의 핵심 관찰은 많은 시스템 휴리스틱이 두 가지 유형 중 하나로 표현될 수 있다는 것입니다: (i) 시스템 상태에서 값을 계산하는 함수(예: 혼잡 제어기에서 혼잡 윈도우를 계산), 이를 ‘Value’-형 휴리스틱이라고 부르며; 또는 (ii) 객체 세트를 순위 매김하고 그 중 하나를 선택하는 함수(예: 스케줄러가 실행 가능한 작업을 정렬하는 것), 이를 ‘Rank’-형 휴리스틱이라고 부릅니다. 이 인터페이스는 정책 로직을 깨끗하게 포착합니다. 해당 메커니즘 – 이러한 결정을 실행하기 위한 구체적인 구현 – 는 별도로 개발됩니다. 이 분리는 두 가지 정책 인터페이스에 대한 풍부한 메커니즘 설계 공간을 노출하며, 본 논문에서 체계적으로 탐색합니다(§3.1.1 및 §3.1.2).

두 번째 단계에서는 사용자가 특화된 휴리스틱을 찾고자 하는 인스턴스를 정의합니다 – 구체적인 워크로드-하드웨어 쌍을 지정하거나 알고리즘적으로 관찰된 워크로드 특징과 시스템 신호에 따라 인스턴스를 구분하는 자동 인스턴스 생성기를 구성합니다(§3.2). 오늘날, 휴리스틱은 워크로드나 목표가 크게 바뀔 때만 재설계됩니다. 작은 변화가 중요하지 않은 것이 아니라 수작업으로 설계된 휴리스틱은 비용이 많이 들고 시간이 오래 걸리는 작업이기 때문에 그렇습니다; 결과적으로, 심지어 재설계된 휴리스틱도 가능한 한 넓게 적용되도록 만들어집니다. Vulcan은 이 비용 모델을 근본적으로 바꿉니다: 휴리스틱 생성의 인간 비용을 크게 줄여 작은 변화가 있는 경우에도 특화된 휴리스틱을 합성할 수 있습니다. 예를 들어 입력 매개변수, 액세스 패턴 또는 일시적인 워크로드 단계 등의 작은 변화에 대한 특화도 가능합니다. 효과적으로 Vulcan은 인스턴스 최적의 정책을 가능하게 합니다: 다양한 조건에서 소거되지 않는 하나의 크기로 모든 상황에 맞는 휴리스틱이 아닌, 특수화가 기본적인 방식이 됩니다.

마지막으로 사용자는 진화 검색 프로세스를 어떻게 호출할지를 지정합니다(§3.3). 이는 자연어로 시스템 컨텍스트, 목표 및 사용 가능한 상태를 설명하고, 특히 후보 휴리스틱을 평가하기 위해 사용되는 평가 하네스를 정의하는 것을 포함합니다. 파이프라인의 이전 단계와 마찬가지로 이 단계는 중요한 설계 거래 조건을 노출하며, 예를 들어 평가 속도와 정확성 사이에서 균형을 맞추고, 적절한 관심 지표를 선택하고, 여러 목표를 하나의 최적화 대상으로 결합하는 것입니다. 우리는 이러한 고려 사항에 대해 논의하고 구체적인 예를 통해 효과적으로 검색 프로세스를 호출하는 방법을 설명합니다.

이 논문에서는 Vulcan을 두 가지 정책(캐시 제거 §4 및 계층화 메모리 시스템에서 페이지 승격 §5)에 대해 구현합니다. 우리는 이러한 정책의 디자인 공간에서 Vulcan이 제시한 세 단계 프로세스를 통해 선택한 특정 옵션을 논의합니다. 10가지 다른 인스턴스에서, Vulcan으로 합성된 캐시 제거 정책은 최첨단 기준치와 거의 일치하거나 1.94%에서 69%까지 더 뛰어난 성능을 보입니다. 다양한 워크로드에 대해 Vulcan으로 설계된 메모리 계층화 정책은 최첨단 기준치보다 2.5-7.9% 개선되었습니다.

Vulcan이 효과적인 휴리스틱을 찾는 탐색을 자동화하더라도 인간 디자이너의 역할은 사라지지 않습니다. 우리의 입장에서는 인간 전문 지식이 가장 가치 있는 것은 정책 세부사항을 수작업으로 작성하는 것이 아니라 알고리즘적 탐색이 성공하도록 문제를 구조화하는 것입니다. 우리는 이러한 구조가 휴리스틱 발견 공간을 제어하기 위한 깨끗한 인터페이스 정의에서 비롯되며, LLM 지도 설계가 실현 가능하고 의미 있게 만드는 기초구조임을 주장합니다.

반대로 Vulcan은 현재 가장 효과적인 부분에 LLM을 활용하도록 권장합니다: 인터페이스와 그 불변성을 존중하면서 후보 휴리스틱을 포함하는 코드를 생성합니다. 이는 불투명한 표현과 상당한 런타임 오버헤드로 성능이 중요한 시스템에서 배포하기 어려운 기존 신경 정책 작업과 대조적입니다. LLM이 간결하고 인간이 이해할 수 있는 결정 논리를 합성함으로써 Vulcan은 휴리스틱 설계 공간을 빠르게 탐색하면서 해석 가능성이나 구현 효율성을 포기하지 않습니다.

배경 및 동기

시스템 연구는 오랫동안 캐싱 제거, 혼잡 제어 및 대기열 스케줄링과 같은 작업을 위한 정책을 구현하기 위해 손으로 작성된 휴리스틱에 의존해 왔습니다. 휴리스틱은 최적의 행동이 (1) 큰 행동 공간, 미세한 결정 간격 및 NP-완전 문제로 인해 본질적으로 계산 불가능하거나 (2) 핵심 시스템 변수가 잠재적 또는 관찰할 수 없기 때문에 실질적으로 알려지지 않았기 때문에 발생합니다. 결과적으로 연구자들은 특정 워크로드, 하드웨어 및 운영 조건에서 최적의 행동을 근사하는 새로운 휴리스틱을 계속 설계하며, 성능, 공정성, 활용도 또는 확장성과 같은 서로 다른 목표에 맞게 튜닝됩니다. 실제로 이 반복적인 과정은 인스턴스 최적 휴리스틱을 찾는 지속적인 탐색입니다: 일반적으로 잘 작동하는 정책이 아니라, 현재 배포 컨텍스트에서 잘 작동합니다.

인스턴스 최적화 추구

웹 캐시의 제거 정책에 대한 구체적인 예를 들어보겠습니다. 특정 워크로드, 목표 또는 배포 시나리오에 맞는 다양한 휴리스틱이 제안되었습니다 – 예를 들어, 일부는 큰 캐시 크기에 대해 잘 작동하고, 다른 것들은 작은 캐시에 더 적합합니다. 또한 스캔 워크로드(주로 새로운 객체) 또는 체른 워크로드(주로 반복적인 객체)와 같은 작업의 구성에 따라 다른 알고리즘이 더 잘 작동함이 입증되었습니다. 이러한 제거 휴리스틱은 엔드-투-엔드 목표(또는 그 조합)인 꼬리 지연 및 공정성 또는 CPU 오버헤드, 록-프리 설계, 메모리 효율성과 같은 시스템 수준의 제약 조건을 위해 특화되었습니다. 이를 더 구체적으로 보여주기 위해, Figure 1은 CloudPhysics 데이터셋에서 106개의 추적을 다양한 크기의 캐시에 대해 실행한 17개의 캐싱 알고리즘의 결과를 요약합니다 – 우리는 단 한 개의 알고리즘이 추적의 절반 이상에서 가장 잘 작동하지 않는다는 것을 관찰하고, 다른 알고리즘이 서로 다른 캐시 크기에서 더 잘 작동합니다. 이 데이터셋의 모든 추적이 같은 광범위한 워크로드 클래스(1주 동안 수집된 블록 I/O 추적)에서 왔음에도 불구하고, 우리는 단 하나의 클래스 내에서도 ‘하나의 크기에 맞는’ 것이 사실이 아님을 발견합니다.

각 휴리스틱이 가장 잘 작동하는 CloudPhysics 추적 수 (최대 객체 적중률). 작은, 중간 크기 및 큰 캐시는 각각 추적 발자국의 0.1%, 1% 및 10%에 해당하며(즉, 추적 내 고유한 객체 수); 우리는 객체 크기를 무시합니다.가 그 결과를 보고하는 방식과 유사하게. 'Others' 열에는 SR_LRU, CR_LFU, Sieve, GDSF이 포함되어 있으며, 이들 모두가 적어도 하나의 추적에서 가장 좋은 휴리스틱이 되었습니다.

이 발견은 캐싱 제거 휴리스틱에만 국한되지 않습니다: 스택 전체를 통틀어 시스템 정책은 유사한 인스턴스 종속적인 휴리스틱을 요구합니다. 혼잡 제어 알고리즘은 인터넷과 데이터 센터 워크로드 사이에서 특화되며, 커널 대기열 규칙은 성능 및 공정성 목표를 위해 튜닝되고, 클러스터 스케줄러는 특정 애플리케이션(예: 데이터 처리, VM 또는 딥 러닝)을 위해 설계됩니다.

역사적으로 이 인스턴스 최적화의 검색은 연구자와 개발자가 수작업으로 수행해 왔습니다. 워크로드가 점점 더 다양해지고 성능 목표가 다차원화되며 하드웨어가 더욱 다양한 방향으로 진화함에 따라 이러한 수동 탐색은 더 이상 실현 가능하지 않습니다. 이는 시스템 휴리스틱을 찾기 위한 자동화된 검색의 명백한 필요성을 부각시킵니다. 최근, 신경 모델은 대규모 데이터셋에서 학습하여 다양한 입력에 대해 근적 최적 결정을 예측하는 대안으로 제시되었습니다. 그러나 이러한 접근법에는 높은 비용이 따릅니다: 불투명한 행동, 복잡한 훈련 및 배포 파이프라인, 추론 오버헤드, 안전성 우려 등.

LLMs을 휴리스틱 생성기로 활용

우리는 최근의 대형 언어 모델(LLMs)의 발전이 이러한 인스턴스 최적의 휴리스틱을 찾는 새로운 패러다임을 가능하게 한다고 주장합니다. 이를 가능한 이유는 인스턴스 최적의 휴리스틱을 찾는 것이 코드 생성 문제로 생각할 수 있다는 통찰력에 근거합니다: 우리는 대상 정책의 입력-출력 사양을 충족하고 주어진 인스턴스에서 일부 비트라인 성능 목표를 충족하는 프로그램을 찾는 것입니다. 그리고 LLMs이 실행 가능한 코드를 생성하고, 자연 언어 지시문으로 이를 개선하며 체인-오브-사고 추론을 사용할 수 있는 능력 덕분에 휴리스틱의 생성 및 개선은 더욱 빠른 과정이 되었습니다.

정책 설명 유형
혼잡 제어  비인증 바이트를 몇 개로 날릴 수 있는지 결정 (cwnd). Value: cwnd 계산
DVFS 제어  성능과 전력을 균형시키기 위해 CPU가 실행할 주파수를 결정합니다. Value: 주파수 계산.
클러스터 오토 스케일링  워크로드 수요에 맞추어 배치해야 하는 복제본 수를 결정합니다. Value: 서비스별 복제본 계산.
하드웨어 예측 캐시 현재 액세스로부터 데이터를 예측 캐싱할 오프셋을 선택합니다. Value: 오프셋 값 계산.
블록 I/O 예측 캐시  예측 캐싱할 블록을 선택합니다. Rank: 이전에 액세스한 모든 블록.
캐시 제거  제거할 캐시된 객체를 선택합니다. Rank: 모든 캐시된 객체.
CPU 스케줄링  다음에 실행할 스레드를 선택합니다. Rank: 모든 실행 가능한 스레드.
계층화 메모리 시스템에서 페이지 승격  더 높은 수준으로 승격할 페이지를 선택합니다. Rank: 모든 메모리 페이지.

<span i


📊 논문 시각자료 (Figures)

Figure 1



Figure 2



Figure 3



Figure 4



Figure 5



Figure 6



Figure 7



Figure 8



Figure 9



Figure 10



Figure 11



감사의 말씀

이 글의 저작권은 연구하신 과학자분들께 있으며, 인류 문명 발전에 공헌해주신 노고에 감사를 드립니다.

검색 시작

검색어를 입력하세요

↑↓
ESC
⌘K 단축키