LAWA

무엇인가

LAWA(Latency-Aware Workflow OptimizAtion)는 멀티에이전트 워크플로의 전체 소요 시간(makespan) 을 줄이는 구조 최적화기입니다. 다트머스대·버지니아공대·뉴욕대 연구진의 NeurIPS 2026 논문 「한 번 최적화, 매번 빠르게(Optimize Once, Execute Fast)」로, 2026년 10월 arXiv에 공개됐고 코드와 재현 스크립트가 공개돼 있습니다.

AFlow·AgentPrune·G-Designer 같은 자동 설계 연구는 대부분 정확도나 토큰을 최적화했습니다. LAWA는 이를 뒤집어 시간을 목적 함수로, 정확도는 '처음 워크플로 이상'이라는 제약으로 둡니다. 무대는 AI 고객 상담·클라우드 장애 대응처럼 같은 워크플로가 수없이 되풀이되는 '반복 질의'입니다. 한 번 최적화하는 비용이 수천 번의 실행에 나뉘어 상환되므로, 질의마다 줄인 몇 초가 그대로 쌓입니다.

뿌리는 1957년 듀폰의 임계 경로법(CPM)입니다. 여러 작업이 얽힌 일의 완료 시간은 작업 총량이 아니라 서로를 기다려야 하는 가장 긴 줄이 정합니다. 토큰이 면적이라면 시간은 길이입니다 — 같은 토큰도 한 줄로 세우면 느리고 나란히 세우면 빠릅니다.

어떻게 동작하나

워크플로는 방향 비순환 그래프(DAG)입니다. 노드 하나가 에이전트 호출 한 번이고, 노드 시간 $t_k$는 학습용 질의로 미리 재 둔 P95 지연입니다(평균은 붐비는 날을 숨깁니다). 모든 노드가 선행자가 끝나는 즉시 시작한다고 보면 makespan은 입구에서 출구까지 가장 긴 경로의 길이입니다.

편집 도구는 둘뿐입니다. 병렬 재배선은 i → j 의존을 끊고 이웃을 서로 물려받게 해 둘을 나란히 세우고, 노드 제거는 노드 하나를 빼고 선행자와 후행자를 직접 잇습니다. 논문은 두 연산이 makespan을 절대 늘리지 않고(정리 3.5), 편집과 무관한 노드 사이의 도달 관계를 보존하며(정리 3.4), 사슬에서 출발해 순서만 잘 고르면 이행적으로 축약된 어떤 DAG에도 닿을 수 있음(정리 3.6)을 증명합니다.

시간은 정확히 계산하고, 정확도는 예측해서 거르기에만 쓰는 분업입니다. 논문 부록 D의 MBPP 사례(빔 크기 1)가 그 모습을 보여 줍니다.

7개 벤치마크(코드·수학·상식, 백본 Qwen3-30B-A3B-Instruct-2507)에서 LAWA는 6개에서 가장 빨랐고 makespan 평균 순위 1.14, 정확도 평균 순위 1.79로 둘 다 1위였습니다. 다른 방법이 만든 워크플로에 끼워 넣어도 4개 방법 × 7개 벤치마크 28조합 모두에서 시간이 줄었습니다. 토큰도 7개 중 5개 벤치마크에서 가장 적었습니다. 최적화 자체는 CPU에서 워크플로당 1.16~2.27초, 평가기 학습은 벤치마크당 21~95초로, 무작위 사슬 대비 대략 2~7번 실행하면 본전입니다.

빠른 시작

PyPI 패키지는 없고, README대로 저장소를 받아 씁니다. 그래프 탐색 자체는 LLM이 필요 없지만, 2026-10-24 기준 저장소에는 학습된 생성기·평가기(saved_models/)가 들어 있지 않아 도메인별 학습을 먼저 해야 합니다. 라벨을 만드는 단계에서 LLM 호출이 많이 듭니다.

git clone https://github.com/GraphmindDartmouth/LAWA.git
cd LAWA
conda env create -f environment.yml && conda activate lawa

# 벤치마크와 학습 분할
python dataset/download_all_datasets.py
python build_graph_datasets/build_trainset_from_hf.py

# 에이전트를 돌릴 로컬 LLM 서버 (논문은 모든 에이전트에 이 모델)
python run_server.py --model Qwen3-30B-A3B-Instruct-2507 --cuda_devices 0,1 --backend sglang

# 무작위 워크플로 2,048개에 정답률 라벨 → 에이전트 P95 지연 보정
python build_graph_datasets/build_mbpp_graph_dataset.py
python agents/update_runtimes.py --llm-model Qwen3-30B-A3B-Instruct-2507

# 생성기·평가기 학습
python train_generator/generator_train_all.py --domains mbpp --gpus 0
python train_evaluator/train_gnn_all.py      --domains mbpp --gpus 0

# 기존 워크플로 다듬기(플러그인 모드)
python AgentTP_prune.py --input-file results/sample.json --output-file results/sample_pruned.json --max-steps 10 --preserve-nodes

자기 워크플로는 인접 행렬로 적어 넣습니다(adj_matrix[i][j] = 1이면 i의 출력이 j로 간다).

{"my_workflow": {"agent_names": ["AlgoPlanner", "CodeGenerator", "CodeAuditor"],
                 "adj_matrix": [[0, 1, 0], [0, 0, 1], [0, 0, 0]],
                 "domain": "mbpp"}}

코드 없이도 생각은 바로 적용할 수 있습니다. 단계별 P95 지연을 기록하고, "이 단계는 정확히 어느 단계의 출력을 쓰나"를 적어 DAG로 그리고, 임계 경로 위의 화살표마다 "정말 기다려야 하나?"(재배선 후보), 노드마다 "없으면 품질이 정말 떨어지나?"(제거 후보)를 묻는 것입니다. 같은 검사를 두 번 하는 곳, 서로 독립인 조회를 차례로 하는 곳이 흔한 후보입니다.

언제 쓰고, 언제 피하나

LAWA는 서버를 빠르게 하는 vLLM·SGLang 같은 서빙 최적화와 다른 층에서 일합니다. 서버에 보내는 일의 모양을 바꾸는 것이라 둘은 함께 쓸 수 있고, 실제 실험도 SGLang 서버 위에서 돌았습니다.

한계와 주의

• '반복 질의' 무대는 실험되지 않았다. 실험은 코딩·수학·상식 단일 턴 벤치마크다. 도구 호출·여러 턴 대화·바뀌는 질의 분포가 섞인 실제 상담 로그로 검증한 것은 아니다.
• 동시 부하 아래 처리량은 재지 않았다. 시간은 GPU 한 장의 SGLang 서버에서 질의를 하나씩 돌려 쟀다. 서버가 꽉 찬 상황에서는 한 질의 안의 병렬화가 다른 질의의 대기를 늘릴 수 있다.
• 노드 시간을 구조와 무관한 상수로 본다. 재배선으로 선행자 출력이 한꺼번에 들어오면 입력이 길어져 실제 시간이 달라질 수 있다.
• 평가기 라벨이 거칠다. 그래프마다 30~50문제로 잰 정답률이라 30문제면 한 문제가 3.3%p다. 최종 후보는 큰 검증 세트로 실제로 돌려 확인한다.
• 평가기가 브레이크다. 판정을 10%(α=0.1) 뒤집어도 정확도는 거의 그대로였고 20%에서 0.5~1.2%p 떨어졌다. 평가기를 빼고 시간만 보면 5단계에서 HumanEval −2.74%p로 미끄러졌다.
• 표의 차이 다수가 표준편차 안이다. MBPP의 0.02초, MMLU의 1.7%p(±3.15) 같은 차이에 유의성 검정이 없다. 반면 무작위 사슬 대비 2~3배 같은 속도 차이는 잡음보다 훨씬 크다.
• 코드 벤치마크(MBPP·HumanEval)는 LLM이 생성한 파이썬을 샌드박스 없이 실행한다 — README 경고대로 컨테이너나 VM에서 돌린다.
• 2026-10-24 기준 저장소에 라이선스 파일이 없다. 코드를 가져다 쓰기 전에 저자에게 확인한다.