arXiv 2508.18298v2 (2025-09-03) · Chaudhry, Choukse, Qiu, Goiri, Fonseca, Belay, Bianchini (MIT CSAIL · Microsoft Azure Research – Systems · Microsoft Azure)

Murakkab: agentic workflow 를 declarative 로 받아, model·knob·GPU 를 SLO 에 맞춰 cloud 가 직접 고르게 하기

원문 papers/Murakkab_2508.18298v2.pdf (18쪽, 본문 12쪽 + 부록) · §3.3 p.6 = 논문이 그렇게 쓴 절·쪽 · 해석 = 논문 내용에서 요약자가 끌어낸 설명 · 논문에 없음 = 배경지식·예시 · 용어는 1 절 용어표의 뜻으로만 쓴다 · 그림은 누르면 크게 열린다

발표 영상: 저자 발표 · 한국어 자막·더빙

0한눈에 보기

agentic workflow 는 여러 model 과 tool 을 DAG 로 엮은 application 인데, 지금은 개발자가 코드 안에 model·parameter·GPU 를 직접 박아 넣고 cloud 는 그 안을 볼 수 없다 §1 p.1 §2.5 p.3.
Murakkab 은 개발자에게 task 와 data flow 만 받고, profile 과 MILP 로 SLO 를 지키는 가장 싼(또는 energy 가 적은) 설정을 system 이 고른다. 24 시간 Azure trace 에서 hand-crafted static 설정 대비 GPU 2.8×·energy 3.7×·cost 4.3× 를 줄였다 Abstract p.1 §4.3 p.9.

0.1

0.1.1기 상황

agentic workflow 는 framework(LangGraph 등)·agent provider(OpenAI 등)·cloud platform 이 각각 따로 맡는다. 개발자는 품질·latency, 사용자는 cost, provider 는 resource 효율을 원하지만 서로 조율하지 않는다 §1 p.1 §2.4 p.3.

0.1.2승 문제

설정이 코드에 묶여(tight coupling) 자동 최적화가 안 되고, workflow·agent·hardware 세 층의 knob 조합이 폭발해 사람이 고를 수 없다. 논문은 그 결과로 resource 낭비와 SLO 저하를 든다 §1 p.1 §2.5 p.3–4.

0.1.3전 기법

① declarative spec: 개발자는 task 와 data flow 만 쓴다. ② orchestrator(LLM) 가 task 마다 executor 를 골라 logical workflow(DAG) 를 만든다. ③ optimizer 가 workflow profile·model profile 을 넣은 MILP 로 knob·model·GPU·instance 수를 정한다. ④ runtime 이 60 분 epoch 마다 다시 풀고 auto-scaler 가 급변에 대응한다 §3 p.4–8.

0.1.4결 결과

video Q/A + code generation 을 함께 돌린 24 시간 trace 에서 Static 2,560 GPU·80.4 MWh·$201.5k → Opt+Mult 908 GPU·21.6 MWh·$46.5k 이다 Table 1 p.9. 2.8×·3.7×·4.3× 는 이 표의 비율이다 해석.

0.2

개발 단계에서 1 회60 분 epoch 마다 다시 풂요청이 오면 바로 조회

0.2.c개발자가 쓰는 것은 맨 위 한 칸뿐이다. model·frame 수·GPU 종류·TP·instance 수는 모두 ② 에서 system 이 정한다 §3.1–3.4 p.5–8. 논문 Fig.6 을 세로로 다시 그린 것이다 논문에 없음.

0.3

0.3.1

2.8×

GPU 수 감소 (Static 2,560 → Opt+Mult 908, video Q/A + code gen 24 h)

0.3.2

3.7×

energy 감소 (80.4 → 21.6 MWh, 같은 실험)

0.3.3

4.3×

cost 감소 ($201.5k → $46.5k, 같은 실험)

0.3.4

−21.1%

multiplexing 의 추가 GPU 감소 (Opt 1,151 → Opt+Mult 908)

1배경: agentic workflow 와 설정 knob

agent 는 model·지시문·tool 로 스스로 판단하고 행동하는 단위이고, 여러 agent 가 역할을 나눠 협업하는 과정이 agentic workflow 다 §2.1 p.2.
workflow 는 DAG 로 나타내며, 같은 DAG 라도 model·frame 수·GPU 같은 knob 을 어떻게 고르냐에 따라 accuracy·latency·energy·cost 가 크게 달라진다 §2.2 p.2 §2.5 p.3–4.

1.1용어표

1.1.1

용어	정확한 뜻 (이 요약에서)	기호	논문 원문 표기
1.1.1.1agent	model(LLM 등)·지시문·tool 로 스스로 판단하고 tool 을 호출하는 단위. workflow 안에서 한 역할을 맡는다	–	"agent" (§2.1 p.2)
1.1.1.2agentic workflow	여러 agent 가 협업해 한 요청에 답하는 과정. DAG 로 표현한다	$w \in \mathcal{W}$	"agentic workflow", "workflow"
1.1.1.3DAG node	workflow DAG 의 원소 하나. edge 는 data flow·실행 의존	–	§2.2 p.2 는 node = agent, §3.2 p.6 은 node = executor 로 쓴다. 이 요약은 개발 전은 task, 배정 뒤는 executor 로 부른다
1.1.1.4task (sub-task)	개발자가 자연어로 적는 할 일 한 칸. 아직 model 이 정해지지 않았다	–	"tasks", "sub-tasks" (§3.2 p.6)
1.1.1.5executor	library 에 있는 실행 단위. LLM / structured composition(LLM Debate 등) / tool 세 종류. 전통 ML model 은 tool 로 분류	–	"executor" (§3.2 p.5)
1.1.1.6knob	바꿀 수 있는 설정값 하나. workflow-level · agent-level · hardware-level 로 나눈다	–	"knobs", "configurations" (§2.4 p.3). agent-level 을 §3.3 은 "executor-level" 이라 쓴다
1.1.1.7workflow configuration	workflow·agent-level knob 을 모두 정한 한 조합 (예: Gemma-3-27B, frame 10, STT 켬)	$c \in C_w$	"workflow configurations for $w$" (§A.5 p.17)
1.1.1.8model profile	model × GPU 종류 × parallelism 한 조합과 그 측정값(TTFT·TPOT·throughput·energy·cost). MILP 의 instance 단위	$m \in \mathcal{M}$	"model profiles" (§3.3 p.6, §A.5 p.17). 원문은 측정 기록과 그 조합 자체를 모두 "model profile" 이라 부른다
1.1.1.9workflow profile	workflow configuration 별 accuracy 와 executor 가 받는 load(prompt·completion token 수) 기록	$a_c$, $t_c$	"workflow profiles" (§3.3 p.6)
1.1.1.10logical workflow	task 마다 executor 만 정한 DAG. model·hardware·요청 정보(query·SLO)는 없다	–	"logical workflow" (§3.2 p.6)
1.1.1.11executable workflow	logical workflow 에 knob·model·hardware·parallelism 까지 정한 실행 계획. SLO tier 마다 하나	–	"executable workflow" (§3.3 p.6–7)
1.1.1.12imperative / declarative	무엇을·어떻게(설정 포함) 다 적는 방식 / 무엇을 할지만 적고 어떻게는 system 에 맡기는 방식	–	§2.3 p.2–3, §3.2 p.5–6
1.1.1.13SLO · SLO tier	요청마다 붙는 accuracy·latency·cost 목표. tier 는 best / good / fair / basic 네 단계	$s \in \mathcal{S}$, $\tau_{w,s}$	"SLO tiers" (§3.4 p.7). 원문은 SLO 종류(accuracy/latency)와 tier 를 모두 SLO 라 쓴다
1.1.1.14optimization epoch	optimizer 가 MILP 를 다시 푸는 주기. 실험 설정 60 분	–	"optimization epoch" (§3.4 p.7, §4.1 p.8)
1.1.1.15MILP	일부 변수가 정수인 선형계획. 여기서는 instance 수 $n_m$ 이 정수다	–	"Mixed Integer Linear Programming" (§3.3 p.7)
1.1.1.16multiplexing · colocation	workflow–SLO 조합 여러 개의 요청을 같은 model instance 에 함께 태우는 것	$\mu_m$	"multiplexing", "colocation", "sharing of model instances" (§4.1 p.8)
1.1.1.17TTFT · TPOT · TP	첫 output token 까지 시간 · 그 뒤 token 하나당 시간 · tensor parallelism(model 하나를 GPU 몇 장에 나누나)	$\ell^{TTFT}_m$, $\ell^{TPOT}_m$, $g_m$	§2.5 p.4, §A.5 p.17
1.1.1.18Static · Mrkb Opt · Mrkb Opt+Mult	평가의 세 policy. 손으로 고정한 설정 / 조합마다 따로 최적화 / 모든 조합을 함께 최적화 + multiplexing	–	§4.1 p.8

1.2agentic workflow 는 DAG 다

1.2.1

tool전통 ML modelLLM

1.2.1.cvideo Q/A workflow 는 영상을 scene 으로 자르고, frame 을 뽑아 물체를 표시하고, 음성을 글로 바꾼 뒤, 그것을 모아 LLM 이 질문에 답한다. node 는 agent, edge 는 data flow 다 §2.2 p.2. 그림 안의 "knob F", "켬/끔", "어느 model?" 은 이 DAG 에서 고를 수 있는 knob 을 요약자가 표시한 것이다 논문에 없음.

Fig.2 — 1.2.2.cFigure 2. Two agentic workflows with different characteristics and components. (p.2) (a) 는 위 그림의 원본이다. (b) code generation 은 text 만 쓰는 workflow 로, Coder agent 들이 답안을 내고 Tester agent 가 test 를 만들어 Python interpreter 로 돌리는 LLM Debate 를 여러 round 반복한 뒤 Ranker(LLM) 가 가장 많이 지지받은 답을 고른다 §2.2 p.2. 논문은 성격이 다른 두 workflow 를 주 평가 대상으로 삼고, Math Q/A 는 부록에 둔다 §2.2 p.2.

1.3knob 은 세 층에 있다

1.3.1

1.3.1.c논문은 설정을 세 층으로 나눈다 §2.4 p.3. D·R·model 은 LLM Debate executor 가 내놓는 knob 이다 §3.2 p.5. 전체 설정 수는 세 층 knob 수의 곱으로 늘어난다고 쓴다 (Insight 3) §2.5 p.4.

"Configuration complexity of each workflow grows combinatorially with the number of agents and their parameters at each level: (O(#WorkflowKnobs × #AgentKnobs × #HardwareKnobs))."Insight 3 · §2.5 p.4

1.4나머지 용어

1.4.1

imperative · declarative

imperative 는 "Whisper 를 OpenAI key 로, PTU 50 으로 호출하라" 처럼 방법까지 적고, declarative 는 "scene 의 음성을 글로 바꿔라" 처럼 할 일만 적는다 §2.3 p.3 §3.2 p.6. SQL 이 대표적인 declarative 언어다 논문에 없음.

TTFT · TPOT · tensor parallelism

LLM 은 prompt 를 한 번에 처리한 뒤(TTFT 까지) token 을 하나씩 만든다(한 개당 TPOT). 그래서 output token $t$ 개의 대략적 latency 는 $\ell^{TTFT} + t\,\ell^{TPOT}$ 이다 논문에 없음. Murakkab 의 latency filter(Eq.5)가 바로 이 식이다 §A.5 p.18. TP 는 model 하나를 GPU 여러 장에 나눠 싣는 방법이다 논문에 없음.

Pareto frontier

accuracy 를 올리려면 latency·cost 를 희생해야만 하는 설정들의 경계선이다. 경계 안쪽 점은 어떤 경계 점보다 모든 면에서 못하므로 고를 이유가 없다 논문에 없음. 논문은 Fig.5 에서 video Q/A·code gen 의 설정 공간과 이 경계를 보인다 §2.5 p.4.

statistical multiplexing

부하가 서로 다른 시각에 몰리는 요청들을 한 자원에 합치면, 합친 것의 peak 이 각 peak 의 합보다 작아 자원이 덜 든다 논문에 없음. MILP 의 Eq.3 은 model 마다 multiplexing factor $\mu_m$ 을 곱한다 §A.5 p.18.

EWMA

다음 값을 $\hat{y}_{k+1} = \alpha y_k + (1-\alpha)\hat{y}_k$ 로 예측하는 지수 가중 이동평균이다 논문에 없음. 논문은 epoch 마다 수요를 $\alpha = 0.5$ 인 EWMA 로 예측한다 §4.6 p.10.

PTU

Azure OpenAI 같은 managed service 에서 미리 사 두는 처리량 단위(provisioned throughput unit)다 §2.3 p.3. Listing 1 에서 Whisper 에 "PTUs": 50 을 적는 것이 그 예다.

1.4.2

1.4.2.cCode gen(A)과 video Q/A(B)의 peak 이 다른 시각에 오면, 같은 model instance 를 공유할 때 필요한 instance 수가 따로 둘 때보다 적다. Fig.11 에서 Gemma instance 가 두 workflow 의 요청을 함께 받는 것이 이 경우다 §4.4 p.9. 숫자는 예시다 논문에 없음.

2문제: 설정이 코드에 묶여 있고, 설정 공간은 너무 크다

개발자는 framework 코드 안에 model·parameter·자원을 직접 적어 넣는다. cloud 는 그 안을 볼 수 없어 설정을 바꿔 자원을 아낄 수 없고, 바꾸려면 개발자가 코드를 고쳐 다시 배포해야 한다 §2.3 p.3 §2.5 p.3.
게다가 knob 마다 accuracy·token 수·latency·energy 가 크게 달라지고 조합 수가 곱으로 늘어, 사람이 요청마다 알맞은 설정을 고를 수 없다 §2.5 p.3–4.

Fig.1 — 2.0.1.cFigure 1. Today workflow developers use frameworks to call agents from different providers hosted on multiple cloud platforms. This fragmentation results in inefficiencies. (p.1) Workflow A 의 agent 가 AWS·Azure·GCP 에, provider 도 self-managed·OpenAI·Databricks 로 흩어져 있다. 맨 위 orchestrator(framework) 와 맨 아래 resource manager(cloud) 가 따로 움직인다는 것이 논문이 말하는 fragmentation 이다 §1 p.1. 논문은 여기서 tight coupling · disjoint orchestration · difficult trade-offs 세 문제를 든다 §1 p.1.

2.0.2.cListing 1. Simplified video Q/A workflow definition. It shows tightly coupled application logic and execution details typical of existing frameworks. (p.3) frame 수(15), CPU 32 개, Whisper 의 PTU 50, Llama-3.2 를 H100 8 장·batch 256 으로 돌리는 것까지 workflow 코드에 들어 있다. 논문은 이 때문에 배포된 workflow 가 경직되고, 무엇을 바꾸든 수작업 수정과 재배포가 필요하다고 쓴다 §2.3 p.3.

"Cloud platforms lack visibility into workflow internals (e.g., tasks, requirements), preventing end-to-end optimization. Meanwhile, developers lack control or insight into system-level resource behavior."Insight 1 · §2.5 p.3

2.1knob 하나가 accuracy 와 token 수를 크게 바꾼다

Fig.3 — 2.1.1.cFigure 3. Workflow accuracy under different configurations and the token generation load on the respective models. (p.4) (a) video Q/A 는 frame 수와 STT 켜기(workflow-level)가 모두 accuracy 를 바꾼다. Gemma-3-27B·frame 10·STT 켬이 최고 66.2% 이지만 같은 model 의 다른 설정보다 token 을 가장 많이 만든다. (b) 요청당 token 수는 250 에서 1,000 가까이 퍼지고 긴 꼬리가 있다. (c)(d) code gen 에서 DeepSeek-Qwen-32B 는 accuracy 가 가장 높지만 중앙값 token 이 약 20,000 개로 Gemma-3-27B(약 2,500)의 8 배쯤이다 §2.5 p.3–4.

Fig.4 — 같은 model 도 GPU·TP 에 따라 latency·energy 효율이 다르다

Fig.5 — 2.1.3.cFigure 5. Large space of workflow configurations along a subset of knobs and metrics. (p.5) 점 하나가 model·GPU·TP·frame 수(또는 agent·round 수)를 모두 정한 end-to-end 설정 하나다. knob 몇 개만으로도 점이 이만큼 생기고, accuracy 대 latency·cost·energy 의 Pareto frontier 가 그려진다 §2.5 p.4. 논문은 사용자마다 목표가 다르고, 최적점이 traffic·자원 가용성에 따라 바뀌며, model·hardware 가 빠르게 바뀌어 사람이 고를 수 없다고 쓴다 §2.5 p.4.

3기법: 선언 → 배정 → 최적화 → 실행

개발자는 task 문장과 data flow 만 쓰고, orchestrator(LLM)가 task 마다 executor 를 골라 logical workflow 를 만든다 §3.2 p.5–6.
optimizer 는 workflow profile(accuracy·token 수)과 model profile(TTFT·TPOT·energy·cost)을 MILP 에 넣어 SLO tier 마다 knob·model·GPU·instance 수를 정하고, runtime 은 60 분 epoch 마다 다시 푼다 §3.3 p.6–7 §3.4 p.7.

Fig.6 — 3.0.1.cFigure 6. Murakkab manages end-to-end workflow life-cycle: from development to optimized deployment and execution. (p.5) (a) 개발: spec → orchestrator 가 executor library 를 보고 logical workflow 를 만든다. (b) 최적화·배포: optimizer 가 SLO·수요·profile 로 model-to-hardware 배정을 정해 executable workflow 를 registry 에 넣는다. (c) 실행: 요청이 오면 registry 에서 꺼내 실행하고, workflow 를 지정하지 않은 요청은 orchestrator 가 그 자리에서 조립한다. auto-scaler 가 부하를 따라간다 §3.1 p.5 §3.4 p.7.

3.1① Development: declarative spec 과 executor library

3.1.1.cListing 2. Murakkab's declarative workflow specification of the video Q/A abstracts away configuration details, letting developers focus on application logic. (p.5) Listing 1 과 같은 video Q/A 지만 model 이름·key·자원·frame 수가 없다. task 는 자연어 문장이고, 요청은 `slo=LOW_LATENCY` 같은 SLO 만 붙인다 §3.2 p.6. 개발자가 특정 LLM 이나 hardware 를 원하면 적을 수 있고, 그것은 optimizer 의 제약조건이 된다 §3.2 p.6.

3.1.2

executor 종류	예	노출 knob 예
3.1.2.1LLM	fine-tuning·few-shot·domain prompt 로 특화한 LLM 설정	model
3.1.2.2structured composition	self-reflection, LLM Debate 처럼 여러 LLM 을 엮은 것	LLM Debate: D(debater 수), R(round 수), model
3.1.2.3tool	OpenCV frame extractor, web-search, MCP tool. 전통 ML model(CNN 분류기 등)도 여기에	frame extractor: F(frame 수), cores(CPU core 수)

executor 마다 설명문·interface·설정 가능한 knob 목록 세 가지를 공개하고, orchestrator 는 설명과 interface 로 executor 를 고른 뒤 knob 값은 다음 단계로 미룬다 §3.2 p.5. orchestrator 의 중심은 tool-calling 이 되는 LLM 이며, DAG 의 앞 node 출력 type 과 뒤 node 입력 type 이 맞는지 검사해 어긋나면 오류를 LLM 에 돌려 다시 만들게 한다 §3.2 p.6. library 에 맞는 executor 가 없으면 개발자에게 추가를 요청한다 §3.2 p.5.

3.2② Optimization: profile 두 층 + MILP

Fig.7 — 3.2.1.cFigure 7. Summary of Murakkab's optimization process. (p.7) 입력은 workflow profile(accuracy·load), model profile(latency·energy·cost), workflow–SLO 조합별 도착 패턴, 가용 자원(GPU 종류·spot instance)이다. MILP 가 SLO 와 수요를 만족하는 조건에서 energy 또는 cost 를 최소화하고, 출력은 GPU·CPU 할당, model·tool 별 자원 수, workflow knob·model 선택이다 §3.3 p.7.

3.2.2

3.2.2.cworkflow profile 은 "이 설정이면 accuracy 가 얼마이고 LLM 이 token 을 몇 개 만드나" 를, model profile 은 "이 model 을 이 GPU·TP 로 돌리면 token 하나에 얼마 걸리고 얼마 드나" 를 적는다. 둘을 곱해 latency·cost·energy 를 추정한다 §3.3 p.6–7. 두 profile 을 따로 두어 model 이 바뀌면 model profile 만 다시 재면 된다고 쓴다 §3.3 p.6. 그림의 두 식은 Eq.3·Eq.5 를 풀어 쓴 것이다 해석.

논문의 video Q/A 예시는 세 단계다. accuracy SLO 에 못 미치는 설정을 먼저 버리고, token 분포와 model profile 로 latency·cost 를 추정한 뒤, 모든 SLO 를 만족하는 설정을 고른다. 없으면 infeasibility error 를 돌려준다 §3.3 p.7. 또 GPU 는 peak 수요에 맞춰 할당하고, 평균 부하는 비용 효율적 사용을 안내하는 데 쓴다는 것을 논문은 "A key insight" 라 부른다 §3.3 p.7.

3.3MILP 식 (부록 A.5)

3.3.1

$\lambda^{peak}_{w,s}$ = workflow $w$·SLO $s$ 요청의 peak 요청률 · $x^{peak}_{w,s,c,m}$ = 그 요청 중 설정 $c$ 로 model profile $m$ 에 보내는 양(결정변수) · $\alpha$ = buffer factor, 기본 1.15

$$\begin{aligned} \lambda^{peak}_{w,s} &\le \sum_{c \in C_w,\, m \in \mathcal{M}} x^{peak}_{w,s,c,m} \\ &\le \alpha \cdot \lambda^{peak}_{w,s} \end{aligned}$$Eq.1 · §A.5 p.18

peak 요청을 모두 어딘가에 배정하되, 최대 15% 까지만 여유를 둔다. 평균 요청률 $\lambda^{avg}$ 에도 같은 꼴의 Eq.2 가 있다 §A.5 p.18.

3.3.2

$\mu_m$ = model $m$ 의 multiplexing factor · $t_c$ = 설정 $c$ 의 요청당 token 수 · $n_m$ = model profile $m$ 의 instance 수(정수) · $\theta_m$ = instance 하나의 token throughput(tokens/s)

$$\mu_m \sum_{w,s,c} x^{peak}_{w,s,c,m}\, t_c \le n_m\, \theta_m \quad \forall m$$Eq.3 · §A.5 p.18

$m$ 에 보낸 요청이 만드는 token/s 를 instance $n_m$ 개가 감당해야 한다. 여러 workflow–SLO 조합의 요청이 같은 $m$ 에 모이는 것이 multiplexing 이다 §A.5 p.18. $\mu_m$ 의 실제 값은 원문에 명시 없음.

3.3.3

$a_c$ = 설정 $c$ 의 accuracy · $\tau_{w,s}$ = SLO 기준값 · $\ell^{TTFT}_m$, $\ell^{TPOT}_m$ = model profile $m$ 의 TTFT·TPOT

$$\begin{aligned} x^{peak}_{w,s,c,m} = 0 \ \ &\text{if } a_c < \tau_{w,s} \\ x^{peak}_{w,s,c,m} = 0 \ \ &\text{if } \ell^{TTFT}_m + t_c\,\ell^{TPOT}_m > \tau_{w,s} \end{aligned}$$Eq.4–5 · §A.5 p.18

accuracy SLO 요청은 accuracy 가 모자란 설정으로, latency SLO 요청은 예상 latency 가 기준을 넘는 (설정, model) 조합으로 보내지 않는다. Eq.8–9 는 Eq.4–5 와 같은 식이 원문에 한 번 더 적힌 것이다 §A.5 p.18. $t_c$ 에 TPOT 를 곱하므로 workflow 의 token 을 한 model 이 차례로 만든다고 보는 근사다 해석.

3.3.4

$g_m$ = $m$ 의 parallelism(GPU 수) · $B_g$ = GPU 종류 $g$ 의 가용 수 · $e_m$ = $m$ 의 energy(kWh) · $c_{g(m)}$ = $m$ 이 쓰는 GPU 종류의 instance 당 초당 cost

$$\begin{aligned} &\textstyle\sum_{m:\,GPU(m)=g} n_m\, g_m \le B_g \quad \forall g \\ &\min \textstyle\sum_m n_m\, e_m\, g_m \ \text{ 또는 } \ \min \textstyle\sum_m n_m\, g_m\, c_{g(m)} \end{aligned}$$Eq.7 · Eq.11–12 · §A.5 p.18

GPU 종류마다 가용 수를 넘지 않게 하면서 energy 또는 cost 를 최소화한다. cost 예산 아래 accuracy 최대화(Eq.13)도 지원한다. Gurobi 로 300 초 time limit 을 두고 푼다 §A.5 p.18. $e_m$ 이 어느 시간 구간의 energy 인지는 원문에 명시 없음.

3.3.5

계산기: Eq.5 latency filter 와 Eq.3 instance 수 논문에 없음

버튼 값은 부록 Table 4 의 TPOT 와 instance 당 TPS 다. TTFT 는 Table 4 에 없어 가정값이다. $\mu_m = 1$ 이면 multiplexing 보정이 없는 경우다.

요청당 token t_c TPOT (ms) TTFT (ms, 가정) latency SLO τ (s)

peak 요청률 (req/s) θ_m (tokens/s/instance) μ_m g_m (GPU/instance)

3.4③ Execution: SLO tier, 60 분 epoch, auto-scaler

3.4.1

3.4.1.ctier 는 모든 workflow·model·hardware 설정에서 얻을 수 있는 accuracy(또는 latency) 값의 best · 95th · 80th · 50th percentile 이다 §3.4 p.7. 그림의 네 값은 Fig.8a 의 video Q/A accuracy tier 다 §4.2 p.8. 점 배치는 예시다 논문에 없음.

3.4.2

3.4.2.1요청에는 workflow ID·입력·SLO 가 들어 있고, runtime 은 registry 에서 해당 executable workflow 를 꺼내 실행한다. workflow 를 지정하지 않은 자연어 요청은 orchestrator 가 기존 executor·workflow 로 그 자리에서 조립한다 §3.4 p.7.
3.4.2.2optimizer 는 매 epoch(실험 설정 60 분) 이전 epoch 상태로 다음 부하를 예측해 다시 풀고, registry 의 executable workflow 를 바꾼다 §3.4 p.7.
3.4.2.3auto-scaler 는 초~분 단위로 model instance 부하를 보고 빠르게 scale-out 한다. 논문은 이것이 순간 최적성보다 SLO 위반 방지를 우선하며, 여분 자원을 두고 큰 변화가 오면 재최적화를 앞당긴다고 쓴다 §3.4 p.7–8. 예로 Llava-OneVision-7B·frame 10·STT 는 요청당 token 이 p50 600, p99 1,200 개로 변동이 크다 §3.4 p.7.

4구현

논문에 별도 구현 절은 없다. 평가 절에서 LLM 은 vLLM v0.9, speech-to-text 는 speaches-ai v0.7, object detection 은 OmDet 으로 serving 했고 §4.1 p.8, MILP 는 Gurobi(300 초 time limit)로 푼다 §A.5 p.18.
코드 규모, orchestrator 가 쓰는 LLM 종류, profiling 에 걸린 시간은 원문에 명시 없음 해석.

구현·실험 환경 세부

4.1

항목	값	근거
4.1.1A100 VM	A100 80 GB × 8, AMD EPYC 7V12 64-core	§4.1 p.8
4.1.2H100 VM	H100 80 GB × 8, Intel Xeon (Sapphire Rapids)	§4.1 p.8
4.1.3workflow profile 용 benchmark	VideoMME, HumanEval, MATH	§3.3 p.6
4.1.4model profile 항목	TTFT·TPOT, energy, cost. TP·prefill/decode 분리·GPU 종류·clock 별로, 부하 수준을 바꿔 측정	§3.3 p.6
4.1.5MILP	Gurobi, time limit 300 s, buffer $\alpha$ 1.15, Eq.13 의 $\epsilon$ 0.001	§A.5 p.17–18
4.1.6endpoint	배포된 workflow 는 REST endpoint 로 공개, 요청마다 SLO 를 붙일 수 있음	§3.2 p.6

5평가

Azure LLM inference trace 24 시간(2024-05)의 chat 요청을 video Q/A 로, coding 요청을 code gen 으로 대응시켰다. 공개된 agentic workflow trace 가 없어서 택한 근사라고 논문이 밝힌다 §4.1 p.8.
baseline Static 은 Gemma-3-27B·A100 으로 고정한 hand-crafted 설정이고, 논문은 이것이 LangGraph 같은 기존 system 을 대표한다고 쓴다. LangGraph 를 직접 돌린 비교는 아니다 §4.1 p.8 해석.

Fig.18 — 사용한 Azure trace

5.15.1 workflow 하나: SLO tier 와 목적함수에 따라 무엇을 고르나

Fig.8 — 5.1.1.cFigure 8. Video Q/A workflow configured for different SLOs and optimization objectives. (p.8) 모든 요청이 같은 tier 라고 두고 24 시간 trace 를 돌린 결과다. accuracy tier 에서 energy 최소화 시 best(66.2%) 5.1 MWh → good(64.4%) 3.9 MWh 로 23.5% 줄고, cost 최소화 시 $18.5k → $14.3k 다. fair(61.4%)까지 허용하면 cost 가 $6.9k 로 가장 비싼 설정 대비 약 4× 줄어든다 §4.2 p.8. latency tier 에서는 0.5 s → 0.9 s 로 풀면 energy 가 1.1 MWh → 266 kWh 다 §4.2 p.8. tier 를 한 단계 풀면 optimizer 가 frame 수를 줄이거나 더 작은 model 로 바꿀 수 있어서다. 부록 Table 4 에서 accuracy tier 가 best → good 이면 Gemma-3-27B frame 10 → 5, fair 는 NVLM-D-72B, basic 은 Llava-OneVision-7B 로 바뀐다 §A.2 p.16. energy 최소화에서는 H100 을, cost 최소화에서는 A100 을 고른다 §4.2 p.8 Table 4 p.16. "가장 비싼 설정" 은 그림상 energy 최소화의 best 막대로 보인다 해석.

Fig.9 · 부록 Table 4·5 — code gen 과 고른 설정 목록

5.1.3

workflow · SLO	tier 를 풀 때 바뀐 것 (가장 많이 고른 설정)	근거
5.1.3.1video Q/A · accuracy	Gemma-3-27B F=10 → Gemma F=5 → NVLM-D-72B F=5 → Llava-OV-7B F=5. 모두 TP4, cost 는 A100·energy 는 H100	Table 4 p.16
5.1.3.2video Q/A · latency	모두 Llava-OV-7B F=1. GPU 종류와 instance 당 허용 부하(TPS)만 바꿔 batching 을 늘림	§A.2 p.16
5.1.3.3code gen · accuracy	DeepSeek-Qwen-32B D4 R4 → Gemma D4 R4 → Gemma D2 R4 → Phi-4 D2 R4	Table 5 p.17
5.1.3.4code gen · latency	best 는 NVLM-D-72B H100 TP8, 나머지는 Phi-4 D2 R2. 같은 Phi-4 도 cost 최소화는 TP2, energy 최소화는 TP1	§A.3 p.17

5.25.2 workflow 여러 개: multiplexing

5.2.1.cTable 1. Comparison of resource usage, energy, and cost. (p.9) video Q/A 와 code gen 을 함께 돌리고, 요청의 70% 는 high-accuracy, 30% 는 low-latency(둘 다 good tier)로 두었다 §4.3 p.9. 24 시간 합계로 Static 2,560 GPU·80.4 MWh·$201.5k, Opt 1,151·27.1·$56.2k, Opt+Mult 908·21.6·$46.5k 다. Opt 대비 Opt+Mult 는 GPU −21.1%, energy −20.2%, cost −17.3% 다 §4.3 p.9. Opt 는 workflow–SLO 조합마다 peak 와 평균 부하의 차이를 이용해 시간에 따라 model·자원을 바꾼다. Opt+Mult 는 여기에 모든 조합의 수요를 함께 보고 같은 model instance 를 공유한다 §4.3 p.9. Static 은 A100 약 2,560 장을 하루 내내 고정해 두어 idle power 때문에 energy 도 높다고 쓴다 §4.3 p.9.

Fig.10 — 5.2.2.cFigure 10. Comparing three policies: (1) a hand-crafted static configuration, (2) Murakkab optimizing individual workflows (Opt), and (3) Murakkab jointly-optimizing across workflows + multiplexing resources (Opt+Mult). (p.10) (a) Static 의 cost 는 시간에 상관없이 평평하고, Murakkab 두 policy 는 부하를 따라 오르내린다. (b) Static 은 high-accuracy 요청과 low-latency 요청의 accuracy·latency 가 같고, low-latency 요청에서 latency SLO 위반(×)이 난다 §4.3 p.9. Static 은 요청마다 다른 SLO 를 구분하지 못해 모든 요청을 같은 설정으로 처리한다. Murakkab 은 요청의 SLO 를 보고 low-latency 요청은 빠른 설정, high-accuracy 요청은 정확한 설정으로 보낸다 §4.3 p.9.

5.35.3 가용 GPU 가 바뀔 때

5.3.1.cTable 2. Murakkab serving multiple workflows varying resource constraints minimizing energy. As more H100 GPUs are available, Murakkab trades off cost for energy (same SLO). (p.9) A100 은 2,000 장으로 두고 H100 을 0 → 500 장으로 늘리며 energy 를 최소화했다. H100 을 거의 다 쓰면서(최대 495 장) A100 을 1,292 → 0 장으로 줄였고, energy 는 24.7 → 11.0 MWh 로, cost 는 $55.7k → $75.4k 로 바뀌었다 §4.4 p.9. model profile 에 GPU 종류별 energy·cost 가 있어, 목적이 energy 면 H100 을 우선 채운다. H100 은 energy 효율이 좋지만 비싸서 cost 가 오른다 §4.4 p.9.

Fig.11 — 24 시간 동안 instance 와 GPU 를 어떻게 바꿨나

5.45.4 DAG 를 알고 CPU·GPU 에 나눠 싣기

Fig.12 — 5.4.1.cFigure 12. Executing a user request involving parallel video Q/A and code generation. Murakkab selects the configuration in Figure 12c to minimize energy use while meeting the 30-second latency SLO and maintaining response quality. (p.11) "영상 속 학생의 코드 답안을 검증하라" 는 요청(latency SLO 30 초)을 orchestrator 가 video Q/A 와 code gen 두 갈래로 fan-out 했다. Gemma-3-27B 는 모두 A100 4 장이다. (a) OmDet·Whisper 도 GPU 에 두면 GPU 6 장으로 SLO 를 지키지만 GPU 가 덜 쓰이고 CPU 는 논다. (b) 둘 다 CPU 로 옮기면 GPU 4 장이지만 OmDet 이 CPU 를 꽉 채워 SLO 를 넘긴다. (c) OmDet 만 GPU, Whisper 는 CPU 면 GPU 5 장으로 SLO 를 지킨다 §4.5 p.9–10. Murakkab 은 DAG 에서 두 갈래가 병렬이고 Whisper 가 CPU 에서도 critical path 를 늘리지 않는다는 것을 profile 로 알아 (c) 를 고른다. 논문은 기존 system 이 workflow 를 불투명하게 다뤄 이런 조율을 못 한다고 쓴다 §4.5 p.10.

Fig.13 — optimization epoch 을 몇 분으로 할까

부록 A.1 — Math Q/A + code gen (Fig.14–17, Table 3)

Fig.15 — 5.4.4.cFigure 15. Workflow accuracy under different configurations and the token processing load on the respective models. (p.17) model 4 개 × round 4·6·8 의 accuracy 와 생성·prompt token 분포다 §A.1.1 p.16.

Fig.16 — 5.4.5.cFigure 16. Math Q/A workflow configured for different SLO and optimization objectives. (p.17) accuracy tier 78.3 / 75.7 / 75.5 / 70.1%, latency tier 6.5 / 13.9 / 18.5 / 31.3 s 에서 Fig.8·9 와 비슷한 경향이다 §A.1.2 p.16 §4.2 p.9.

Fig.17 — 5.4.6.cFigure 17. Comparing a hand-crafted static configuration (only A100s) to: (1) Murakkab optimizing individual workflows, and (2) Murakkab jointly-optimizing across workflows + multiplexing resources (Math Q/A + Code Gen). (p.18) chat → Math Q/A, coding → code gen 으로 대응시켰다. Static 은 Math 에 DeepSeek-Qwen-32B, code gen 에 Gemma-3-27B 를 고정했다 §A.1.3 p.16. Table 3 기준 Static 4,448 GPU·169.87 MWh·$367.2k → Opt+Mult 1,660·52.66·$104.6k 로 GPU 약 2.7×, energy 약 3.2×, cost 약 3.5× 줄었다 §A.1.3 p.16. 개선 폭은 video Q/A 조합(2.8·3.7·4.3×)보다 작다 해석.

5.4.7

Policy (Table 3, p.16)	GPU 수	Energy (MWh)	Cost (×1000 $)
5.4.7.1Static	4448	169.87	367.2
5.4.7.2Mrkb Opt	1875	62.88	123.0
5.4.7.3Mrkb Opt+Mult	1660	52.66	104.6

6결론과 한계

논문의 결론은 declarative programming model 과 adaptive runtime 으로 workflow 논리와 실행 설정을 분리하고 orchestration 과 cluster 관리를 통합해, 다양한 SLO 를 지키면서 GPU·energy·cost 를 줄였다는 것이다 §6 p.11–12. 향후 과제로 더 큰 cluster, 더 다양한 가속기, 새 agentic application 에 맞춘 특화를 든다 §6 p.12.
논문에 limitation 절은 없다. 아래는 요약자가 정리한 한계다 논문에 없음.

6.1

한계	근거
6.1.1workload 가 실제 agentic trace 가 아니다. LLM chat·coding trace 의 도착 시각만 빌려 workflow 에 대응시켰다	§4.1 p.8 ("no publicly available traces")
6.1.2baseline 이 한 가지 hand-crafted 고정 설정이다. 시간대별로 설정을 바꾸는 heuristic 이나 LangGraph 실제 배포와의 비교는 없다	§4.1 p.8, §4.3 p.9
6.1.3orchestrator(LLM)가 task 를 executor 에 얼마나 정확히 배정하는지, 실패하면 품질이 어떻게 되는지 평가가 없다	§3.2 p.6 에 설계만 제시
6.1.4accuracy 를 공개 benchmark 로 잰 workflow profile 에 의존한다. 실제 요청 분포가 benchmark 와 다르면 tier 가 맞지 않을 수 있다	§3.3 p.6 (피드백으로 갱신한다고만 씀)
6.1.5profiling 을 "lightweight" 라 하지만 비용·시간 수치가 없고, $\mu_m$·$e_m$ 의 실제 값과 단위가 원문에 없다	§3.3 p.6, §A.5 p.17–18
6.1.6latency 추정 $\ell^{TTFT} + t_c \ell^{TPOT}$ 는 DAG 의 병렬 갈래·tool 시간·queueing 을 직접 담지 않는다. Fig.12 같은 CPU/GPU 배치 결정이 MILP 안에서 어떻게 나오는지 원문에 명시가 없다	Eq.5 (§A.5 p.18), §4.5 p.10
6.1.7auto-scaler 의 효과는 따로 측정되지 않았다. Fig.13b 는 auto-scaler 가 없을 때의 worst-case 다	§4.6 p.11
6.1.8MILP 를 Gurobi 300 초 제한으로 푸는데, workflow·model 수가 늘 때 푸는 시간과 해 품질이 보고되지 않았다	§A.5 p.18

7관련 연구

논문은 기존 연구를 workflow 개발 framework, workflow 자동 생성, system 최적화 세 갈래로 나눈다 §5 p.11.
논문의 주장은 기존 framework 는 설정과 논리가 섞여 자원 관리를 개발자에게 떠넘기고, 기존 serving system 은 단일 model 이나 LLM 호출 scheduling 에 머문다는 것이다 §5 p.11. 논문에 비교표 figure 는 없어 아래 표는 요약자가 §5 를 정리한 것이다 논문에 없음.

7.1

갈래	연구	한 일	Murakkab 과 차이 (논문 서술)
7.1.1workflow 개발	LangGraph · LangChain · AutoGen	model·tool 호출을 imperative 로 엮는다	설정과 논리가 섞여 있고 자원 관리를 개발자가 맡는다
7.1.2workflow 개발	DSPy · Palimpzest	declarative 접근, prompt·query 최적화	역시 설정과 논리가 섞여 있고 큰 설정 공간으로 확장이 어렵다
7.1.3자동 생성	AFlow · AutoFlow · Flow 등	응답 품질을 높이도록 workflow 를 자동 생성	상호 보완적이며 orchestrator 에 통합할 수 있다
7.1.4system 최적화	Alto · Teola / Parrot · Autellix	data flow 관리 / agentic application 의 LLM 호출 scheduling	–
7.1.5system 최적화	SpotServe · Loki	자원·부하 변동 대응	단일 model serving 에 머문다
7.1.6system 최적화	model 선택·RouteLLM, test-time compute energy 연구	품질·energy trade-off 분석	Murakkab 은 이 trade-off 를 agentic workflow 에서 자동으로 탐색하는 system 이다