FlowMaker가 워크플로·모델·배포를 함께 골라 생성 AI 서빙 비용을 줄인다

무엇인가

이 논문은 생성 AI 애플리케이션이 여러 LLM 호출을 조합한 워크플로로 사용자 태스크를 수행하는 상황을 다룬다. 워크플로 구조, 각 단계에 쓸 모델, 모델의 텐서·파이프라인 병렬 배포 설정, 이미 배포된 모델을 재사용할지는 지연·비용·정확도를 함께 좌우한다. 그런데 기존 프레임워크는 이 결정을 정적으로 고정하거나 수동 튜닝에 맡기고, 일부 시스템은 모델이나 배포 같은 일부 차원만 최적화한다. 저자들은 이런 고정 선택이 실험에서 최대 4.00배 높은 서빙 비용과 최대 12.84배 낮은 goodput을 낳는다고 보고한다. goodput은 지연 SLO를 만족하면서 정확도 SLO를 만족하는 워크플로 변형으로 완료된 요청의 비율이다.

어떻게 동작하나

핵심 관찰은 두 가지다. 동적 클러스터 상태에서 워크플로·모델·배포 설정의 모든 조합을 함께 탐색해야 하고, 배포된 LLM 재사용은 현재 부하와 자원 가용성에 따라 그때그때 결정해야 한다는 것이다. 저자들은 워크플로, 모델 배정, 배포 설정의 조합을 워크플로 변형(workflow-variant)이라 부른다. 예시 태스크는 3개 워크플로, 11개 모델, 모델당 10개 배포 설정으로 24,310개 변형을 만들고, 변형 간 지연은 0.6–119초로 189.3배, 비용은 2×10^-5–0.17¢로 8,725배, 정확도는 14.4–48.0%로 3.3배 차이 난다. 이 24,310개를 전수 평가하면 약 40 CPU분이 걸려 가장 느슨한 510초 지연 SLO의 약 4.7배가 된다. 가장 가까운 선행 시스템인 Murakkab은 모델과 배포는 함께 고르지만 사용자가 준 워크플로를 고정한다. 저자들의 오라클 실험에서는 세 차원을 함께 탐색할 때 Murakkab 대비 서빙 비용이 1.85배 줄고 goodput이 1.69배 높았다. 재사용도 오프라인 평균 부하 기준과 최대 부하 기준이 비용과 goodput을 각각 1.36배, 1.29배 다르게 만들었고, 배포 시점의 현재 부하로 결정하는 온더플라이 재사용은 Murakkab의 오프라인 정책보다 비용과 goodput을 1.89–2.57배, 1.13–1.45배 개선했다.

무엇과 다른가

FlowMaker는 사용자가 태스크 설명과 정확도·지연 SLO만 내는 태스크 수준 인터페이스를 제공한다. deploy_task가 호출되면 LLM 기반 워크플로 생성기가 후보 워크플로를 만들고, 사용자는 의미적으로 받아들일 수 있는 후보를 고른다. 태스크 분해가 여러 해석을 낳을 수 있고 현재 LLM은 자율 플래너로서 신뢰하기 어렵기 때문에 사용자 검증을 일부러 남긴다. 이후 워크플로 변형 선택기가 후보 워크플로, 모델 프로파일, SLO, 현재 클러스터 상태를 받아 워크플로 변형과 재사용 계획을 고른다. 배포기는 재사용으로 해결되지 않는 모델 인스턴스만 새로 띄우고, 오케스트레이터가 선택된 워크플로와 모델, 설정, 재사용 매핑으로 요청을 실행한다. 모델 등록 시에는 MaverIQ 기반 프로파일러가 텐서·파이프라인 병렬 설정별 지연과 메모리를 측정해 저장하고, 이 프로파일을 태스크 간에 재사용한다. 프로토타입은 TensorRT-LLM 위에 약 3,000줄 파이썬으로 구현됐다. 선택은 요청마다가 아니라 태스크 배포 시점에 한 번 수행된다.

어떻게 쓰나

선택 문제의 입력은 태스크, 정확도 SLO α, 지연 SLO λ, 예상 요청 도착률 ρ, 사용자 승인 후보 워크플로 집합, 지원 모델 집합, 배포 설정 집합, 그리고 배포된 인스턴스·부하·가용 GPU 메모리다. 출력은 각 LLM 단계의 모델과 배포 설정, GPU 매핑을 담은 워크플로 변형이다. 목적식은 새로 배포해야 하는 모델들의 메모리 합과 전체 단계 지연 합의 곱으로 비용을 근사하고, 지연 합이 λ 이하, 단계별 정확도 최솟값이 α 이상, 재사용하는 인스턴스의 용량이 기존 부하에 이 워크플로가 라우팅하는 부하를 더한 값 이상이라는 제약을 건다. 정확도는 모델별 Open LLM Leaderboard 6개 벤치마크 평균 점수로 추정하고, 워크플로 정확도는 단계 정확도의 최솟값으로 근사한다. 전수 탐색이 너무 비싸므로 세 단계로 후보를 줄인다. 먼저 정확도 제약으로 모델을 걸러내고, 다음으로 재사용을 고려한 활성 파라미터 크기가 최소 정확도 충족 모델들의 파라미터 예산을 넘지 않는 모델 배정만 남긴다. 마지막으로 남은 배정에 대해 유효한 텐서·파이프라인 병렬 설정을 열거하고 지연·용량 위반을 버린 뒤, 덜 부하된 GPU를 선호하는 LeastLoaded로 샤드를 배치한다. 각 배정의 최저 비용 feasible 설정을 고르고 워크플로별 첫 feasible 배정을 현재 최선과 비교해 전체 최저 비용 선택을 반환한다. 최악의 경우 탐색 공간은 단계 수에 지수적이다.

전제와 한계

실험은 7개 생성 AI 태스크, 태스크당 1–3단계의 후보 워크플로 3개, 6개 공개 데이터셋 입력, Llama·Qwen·Mistral 계열 1B–72B 오픈 모델 11개로 구성됐다. Azure 코드 트레이스와 대화 트레이스를 25–100%의 네 부하 수준으로 재생해 실행당 212–484개 요청을 만들었다. 지연 SLO는 태스크 단독 지연의 2–5배로 설정했고, 비용은 할당 GPU 메모리 × 상주 시간 × GB-초 요금으로 계산했다. 비교 대상은 세 결정을 모두 고정하는 LangChain, 고정 워크플로 안에서 Qwen-2.5-14B와 7B 사이를 라우팅하는 RouteLLM, 워크플로는 고정하지만 모델·배포·오프라인 재사용을 고르는 Murakkab, 재사용을 끈 FlowMakerNoReuse, 전수 탐색과 Aquatope식 베이지안 최적화다. LangChain은 6개 태스크에 15개 인스턴스 290GB를 배포하고 메모리 단편화 때문에 7번째 태스크를 배치하지 못했으며, 50% 코드 부하에서 한 GPU에 4개 인스턴스를 colocate해 평균 지연이 426초까지 올랐다. FlowMaker는 7개 태스크를 3–5개 인스턴스로 서빙하며 같은 조건에서 평균 지연 38초를 보였다. 전체적으로 FlowMaker는 LangChain 대비 goodput이 1.13–12.84배(평균 5.2배) 높고 비용은 2.2–4배(평균 2.93배) 낮았다. RouteLLM 최대 품질 설정은 모든 정확도 SLO를 만족하고 평균 goodput이 FlowMaker보다 5.8% 높았지만 206–235GB를 예약하고 비용이 2.06–3.84배(평균 2.95배) 높았다. RouteLLM 최소 비용·균형 설정은 정확도 SLO를 각각 34.9–36.8%, 62.6–65.6%만 만족해 평균 goodput이 2.62배, 1.52배 낮았다. Murakkab과 비교하면 저부하에서는 goodput이 최대 1.46배(평균 1.21배) 비슷했고 FlowMaker가 1.84–3.15배(평균 2.23배) 더 저렴했으며, 고부하에서는 FlowMaker가 goodput 1.45–10.14배(평균 4.73배) 높고 비용 1.56–2.77배(평균 1.95배) 낮았다.

차원별 기여도 분리했다. 재사용을 끈 FlowMakerNoReuse도 저부하에서 Murakkab보다 goodput이 최대 1.47배(평균 1.13배) 높고 비용이 최대 1.83배(평균 1.38배) 낮았으며, 고부하에서는 goodput이 1.45–8.46배(평균 4.34배) 높고 비용이 1.24–1.95배(평균 1.48배) 낮았다. 세 차원을 함께 고르는 것만으로 큰 효과가 있음을 보인 셈이다. Murakkab은 한 대화 트레이스 설정에서 재사용 덕에 117.11GB를 썼고 FlowMakerNoReuse는 186.46GB를 썼지만, Murakkab의 고정 워크플로가 최소 2단계인 반면 FlowMakerNoReuse는 1–2단계 대안을 고를 수 있어 지연이 2.41–10.73배 커졌다. 온더플라이 재사용을 켜면 저부하에서 FlowMaker는 3–4개 인스턴스를 재사용하고 FlowMakerNoReuse는 8개를 배포해 비용이 1.47–1.73배(평균 1.61배) 줄었다. 고부하에서는 덜 공격적으로 공유해 5개 인스턴스를 배포했지만 비용은 1.04–1.42배(평균 1.31배) 줄고 goodput은 비슷했다. 100% 코드 트레이스에서는 FlowMaker가 기존 Qwen-2.5-3B를 재사용하는 3단계 변형을 고른 반면 FlowMakerNoReuse는 새 배포가 필요한 2단계 변형을 골랐다.

선택 알고리즘의 품질과 속도도 검증했다. 7개 태스크와 모델 카탈로그·워크플로 깊이 확장 실험의 비교 가능한 모든 지점에서 FlowMaker는 전수 탐색과 베이지안 최적화가 고른 것과 같은 워크플로 변형을 선택해 100% 일치, 전수 탐색 대비 0% 목적값 격차를 보였다. 선택 시간은 약 1초로, 베이지안 최적화보다 3.7–8.5배, 전수 탐색보다 4.5–61배 빨랐다. 전수 탐색은 간단한 태스크에 약 6.5초, 큰 후보 공간에 약 40초가 걸렸고 베이지안 최적화는 200회 순차 시도에 태스크당 약 5초가 걸렸다. 확장성에서는 6단계 이상에서 전수 탐색과 베이지안 최적화가 15분을 넘긴 반면 FlowMaker는 3–5단계에서 2초 미만이었고 14.5–443배 빨랐다. 다만 7단계에서는 FlowMaker도 210초로 늘었고, 모델 카탈로그가 50개일 때 전수 탐색이 타임아웃, 125개일 때 베이지안 최적화가 12.2배 느려지는 동안 FlowMaker는 조기 필터링으로 버텼다.

개발자 관점에서 이 논문은 다단계 LLM 파이프라인을 GPU 클러스터에 올리면서 지연 SLO와 비용을 함께 관리하려는 팀에 유용하다. 워크플로 구조를 고정한 채 모델만 바꾸는 라우팅이나 배포 설정만 튜닝하는 접근으로는 놓치는 조합이 크고, 특히 이미 배포된 모델을 재사용할 수 있는지가 현재 부하에 따라 달라진다는 점을 설계에 반영해야 한다. 다만 저자들이 밝힌 전제와 한계도 분명하다. 정확도는 실제 생성 출력 평가가 아니라 Open LLM Leaderboard 평균 점수와 단계별 최솟값으로 근사했고, 임의의 생성 AI 워크플로의 종단 정확도를 실행 전에 추정하는 일반 방법은 아직 없다. 사용자가 후보 워크플로를 승인해야 하며, 선택기는 빠른 저비용 feasible 해를 우선하는 휴리스틱이라 전역 최적을 보장하지 않고 2단계 비용 가지치기도 모든 저비용 배정을 남긴다고 보장하지 않는다. 최악 탐색 공간은 단계 수에 지수적이어서 7단계에서 210초가 걸렸고, 평가는 7개 태스크와 11개 모델, 8개 A6000 GPU에 한정됐으며 Murakkab은 구현이 없어 재구성한 최적화기로 비교했다.