에이전트 워크플로 하나가 답을 만들기 전에 비전 모델, 음성 인식, LLM, 코드 실행기, 여러 차례의 토론을 호출할 수 있습니다. 일반적인 클라우드는 이 단계를 서로 관계없는 API 요청으로 봅니다. 개발자가 모델과 도구를 정하고, 각 모델 서비스는 자체적으로 확장하며, 클러스터 스케줄러는 어느 호출들이 하나의 정확도·지연시간 목표를 공유하는지 모른 채 하드웨어를 할당합니다. MIT CSAIL과 Microsoft Azure Research의 Murakkab은 이 분리가 자원 낭비의 원인이라고 판단합니다[1].
Murakkab은 워크플로를 선언형 작업 그래프로 바꿉니다. 논리적 의존성은 애플리케이션에 남기고, 모델 선택, 도구 파라미터, 텐서 병렬도, 가속기 종류, 배치 위치, 용량은 실행 선택으로 분리합니다. 오프라인 프로파일러가 정확도, 지연시간, 에너지, 비용을 측정합니다. 최적화기는 서비스 목표(SLO)를 지키는 구성을 고르고, 적응형 런타임은 수요와 자원이 바뀔 때 이를 다시 정합니다. 모델 커널을 빠르게 만든 시스템이 아닙니다. 답을 만드는 전체 경로를 바꿀 권한을 가진 클라우드 제어 평면입니다.
한 워크플로에 세 가지 구성 공간이 연결됩니다
논문은 영상 질의응답, 다중 에이전트 코드 생성, 수학 문제 풀이, 동적 코딩 파이프라인을 평가했습니다. 영상 질의응답에는 장면 감지, 프레임 추출, 음성 인식, 객체 감지, 멀티모달 모델이 포함됩니다. 코드 생성은 코더와 테스터 에이전트가 여러 차례 토론하고 후보 코드를 실행한 뒤 다른 모델이 결과를 고릅니다. 각 노드에는 국소 선택지가 있지만, 노드별 최고 구성을 합쳐도 효율적인 워크플로가 되지는 않습니다.
영상 질의응답에서 Gemma-3-27B, 프레임 10개, 음성 인식 사용 구성은 프로파일한 선택지 가운데 최고 정확도 66.2%를 기록했지만 같은 모델 구성 중 가장 많은 토큰도 생성했습니다. 코드 생성에서는 추론 모델이 최고 정확도를 낼 수 있으나 같은 토론 구조에서 중앙값 약 20,000토큰을 생성했습니다. Gemma-3-27B는 약 2,500토큰이었습니다. 하드웨어를 더하면 경계가 하나 늘어납니다. A100과 H100, 텐서 병렬도 1~8에 따라 TTFT, 처리량, 에너지, 가격이 달라집니다.
이 선택지는 곱셈으로 늘어납니다. 선택형 도구 하나를 더하는 것은 구성 하나를 추가하는 일이 아닙니다. 뒤 단계의 토큰 수, 모델 부하, 임계 경로 지연, 최종 SLO를 만족할 하드웨어 배치까지 바꿉니다. 초당 요청 수만 보는 외부 오토스케일러는 이미 선택한 모델의 수량을 늘릴 수 있습니다. 음성 인식을 CPU로 옮기거나, 쉬운 코딩 요청의 후보 수를 줄이거나, 두 워크플로가 하나의 모델 배포를 공유하게 만들지는 못합니다.
선언형이라고 해서 제한 없이 바꾸지는 않습니다
Murakkab의 워크플로 명세는 논리 작업, 입력, 출력, 의존성을 기술합니다. 각 작업에는 허용된 구현과 파라미터 집합이 있습니다. 프로파일러는 유효한 조합을 측정하며 런타임이 새 워크플로를 임의로 만들게 하지 않습니다. 최적화기는 정확도와 지연시간을 지키면서 최소 에너지 또는 최소 비용 같은 목표를 만족하는 측정 지점을 고릅니다.
신뢰성 측면에서 이 구분이 중요합니다. 애플리케이션이 정확도 등급을 지정했고 대체 모델을 미리 평가하지 않았다면 클라우드가 더 저렴한 모델로 조용히 바꾸면 안 됩니다. Murakkab은 요청에 최고·우수·보통·기본 정확도 등급과 별도 지연시간 등급을 부여합니다. 같은 워크플로의 요청도 다른 구성을 받을 수 있습니다. 용량을 정할 때는 프로파일한 생성 토큰의 90분위 부하를 사용해 긴 꼬리에 대비합니다.
제어 루프에는 최적화 주기가 있습니다. 주요 운영 트레이스 시험은 60분마다 다시 계산하고, VM 할당·소프트웨어 준비·모델 전송에 20분이 필요하다고 가정했습니다. 주기가 짧으면 빨리 대응하지만 전환용 용량을 더 자주 유지해야 합니다. 길면 전환 비용은 줄고 예측 오차가 쌓입니다. 민감도 시험에서 60~180분이 균형 구간이었고, 240분 부근에서는 수요 과소 예측이 약 15%까지 증가한 뒤 과다 할당이 다시 커졌습니다.
가장 중요한 근거는 24시간 자원 사용 내역입니다
하드웨어 시험은 80 GB A100 또는 H100 GPU 8개가 있는 Azure VM에서 수행했습니다. LLM은 vLLM 0.9, 음성 인식은 speaches-ai, 객체 감지는 OmDet을 사용했습니다. 실제 에이전트 워크플로 운영 트레이스가 공개되어 있지 않아 2024년 5월 Azure 채팅·코딩 추론 서비스의 24시간 트레이스를 영상·코드 워크플로에 대응시켰습니다. 시간에 따른 수요 변화는 실제 기록이지만 각 요청 뒤의 다단계 그래프는 합성한 것입니다.
다중 워크플로 비교에서는 요청의 70%에 높은 정확도, 30%에 낮은 지연시간 목표를 부여했습니다. 수동 구성 LangGraph는 A100 GPU 2,568개, 82.1 MWh, 21만1,700달러를 사용했습니다. 오토스케일링을 더하면 GPU는 2,472개, 비용은 11만2,300달러로 줄었지만 워크플로 선택은 그대로입니다. 워크플로를 각각 최적화한 Murakkab은 GPU 1,164개, 27.7 MWh, 5만7,200달러가 필요했습니다. 워크플로를 함께 최적화하고 모델을 공유하면 GPU 912개, 22.1 MWh, 4만7,200달러까지 줄면서 평가한 SLO를 지켰습니다.
표의 반올림 값으로 계산하면 수동 구성 대비 GPU 2.8배, 에너지 3.7배, 비용 4.5배 절감입니다. 논문은 여러 비교를 묶어 비용을 최대 4.3배로 요약했으므로 공개 문구에는 표의 반올림 값으로 더 유리한 배수를 다시 만들지 않고 4.3배를 사용해야 합니다. 중요한 분해 결과는 오토스케일링이 유휴 용량만 줄인다는 점입니다. 나머지 절감은 워크플로 구성을 바꾸고 같은 SLO를 가진 요청이 모델을 공유해야 얻을 수 있습니다.
GPU 다섯 개의 배치가 추상화를 설명합니다
한 시험은 영상에 나온 학생의 코딩 해답을 30초 안에 검증합니다. 영상 분석과 정답 코드 생성은 병렬로 실행할 수 있습니다. 객체 감지, 음성 인식, LLM을 모두 GPU에 두면 A100 6개로 SLO를 지키지만 일부 전용 GPU의 이용률이 낮습니다. 보조 모델 둘을 CPU로 옮기면 GPU 4개만 사용하지만 객체 감지가 호스트를 포화시켜 마감 시간을 놓칩니다. Murakkab은 중간 구성을 고릅니다. 객체 감지는 A100 1개, 음성 인식은 CPU, Gemma-3-27B는 A100 4개를 사용합니다. CPU의 느린 음성 인식이 임계 경로 밖에 있으므로 GPU 5개로 SLO를 만족합니다.
이 사례가 최대 절감률보다 일반화하기 쉽습니다. 어느 작업이 느려져도 답의 완료 시각이 바뀌지 않는지를 알려면 스케줄러가 의존성 그래프를 알아야 합니다. 장치 이용률만으로는 이 여유를 찾을 수 없습니다. 코딩 에이전트의 선택형 검토 단계도 같습니다. LiveCodeBench에서 검토는 일부 모델·문제 조합의 정확도를 높였지만 다른 조합에서는 낮췄습니다. 정적인 에이전트 템플릿은 쉬운 문제에 자원을 과다 사용하거나 어려운 문제에 필요한 작업을 주지 못합니다.
이 결과에는 클라우드 사업자의 제어 권한이 필요합니다
Murakkab은 한 주체가 모델을 프로파일하고, 선택한 하드웨어에 배포하고, 워크플로 구조를 읽으며, 실행 구성을 바꿀 수 있다고 가정합니다. 외부 API로 조합한 애플리케이션은 전력, 배치, 텐서 병렬도, 인스턴스 위치, 모델 공유를 제어하지 못할 수 있습니다. 이 환경에서는 선언형 그래프가 애플리케이션 로직에는 도움이 되지만 논문의 인프라 절감을 재현할 수 없습니다.
근거의 범위도 분명합니다. 도착 트레이스는 단일 모델 채팅·코딩 서비스에서 가져온 뒤 합성 에이전트 그래프를 붙였습니다. 주요 워크플로와 모델은 A100·H100 VM에서 평가한 제한된 집합입니다. 프로파일의 전이는 유사한 수학 문제 도메인의 데이터셋 두 개 사이에서 확인했습니다. 분포가 크게 바뀌면 정확도나 토큰 부하의 순서가 달라질 수 있습니다. 비용은 논문이 사용한 Azure 가격과 20분 준비 시간에 따라 달라집니다. 최적화기에 넣는 값이지 보편 상수가 아닙니다.
다음 에이전트 플랫폼에는 최적화 계약이 필요합니다
이 설계를 적용하려면 네 가지를 먼저 갖춰야 합니다. 워크플로는 하나의 모델에 고정하지 않고 작업과 의존성을 드러내야 합니다. 각 대안은 대표 입력에서 품질과 자원 프로파일이 있어야 합니다. 사용자는 바꿀 수 있는 목표와 지켜야 할 SLO를 지정해야 합니다. 마지막으로 플랫폼은 런타임이 바꾼 모델과 경로를 모두 기록해, 비용을 낮춘 선택도 사후에 검증할 수 있게 해야 합니다.
Murakkab이 남기는 판단은 에이전트 효율을 한 엔드포인트의 초당 토큰으로 줄일 수 없다는 것입니다. 판매 단위는 워크플로 수준의 품질과 지연시간 계약을 만족한 답입니다. 그래프, 프로파일, 자원이 하나의 제어 평면에 들어오면 비싼 모델은 실제로 답을 바꾸는 단계에만 사용할 수 있습니다.
출처와 저작권 안내
이 글은 Silicon & Systems가 작성한 편집 요약입니다. 논문의 작동 원리, 평가 조건, 결과, 한계를 우리 표현으로 다시 썼습니다. 원문의 문장, 표, 도판은 옮기지 않았으며, 본문의 도판 3개와 카드 이미지는 보고된 사실을 바탕으로 이 글을 위해 새로 만들었습니다. 저작권 (c) 2026 원저자. 원문은 USENIX OSDI 2026 페이지에서 공개되어 있습니다.