멀티에이전트 기반 synthetic data 파이프라인은 LLM 개발에서 빠르게 중요성이 높아지고 있지만, 정작 실무에서는 속도, 확장성, 병목 때문에 만족스럽게 쓰지 못하는 경우가 많습니다. GPU 리소스는 충분한데 파이프라인 구조 때문에 처리량이 오르지 않거나, 중앙 오케스트레이터가 모든 에이전트를 제어하느라 시스템 전체가 느려지는 문제가 대표적입니다.
이번 글에서는 이러한 구조적 한계를 정면으로 해결한 프레임워크 Matrix를 소개합니다. Matrix는 동일한 GPU 자원으로 속도를 최대 15배까지 높였다는 실사용 결과를 내놓았고, “토큰이 아니라 파이프라인을 튜닝해야 한다”는 메시지를 실제 서비스 워크로드에서 증명했습니다.
아래에서 Matrix의 구조, 원리, 케이스 스터디, 그리고 이 프레임워크가 의미하는 실무적 시사점을 정리합니다.
1. 기존 멀티에이전트 synthetic data 파이프라인의 한계
기존 프레임워크의 가장 큰 문제는 다음 두 가지로 요약됩니다.
1) 속도가 지나치게 느리다
- 중앙 오케스트레이터가 모든 에이전트를 제어하면서 병목이 발생한다.
- 서로 다른 길이의 멀티스텝 워크플로가 섞이면 GPU 대기 시간이 늘어난다.
- LLM 호출, 컨테이너 실행 등 무거운 작업이 파이프라인 내부에 직접 붙어 있어 전체 처리 시간이 길어진다.
2) 도메인 특화 구조라 다른 워크로드로 확장하기 어렵다
- 특정 작업용 코드에 로직이 박혀 있어 워크로드만 바뀌어도 전체 파이프라인을 뜯어고쳐야 한다.
- 에이전트 구조가 고정되어 있어 새로운 그래프나 단계적 파이프라인을 만들기 어렵다.
LLM 훈련에서 synthetic data의 중요성이 커지고 있는 지금, 이런 한계는 개발과 연구 속도를 크게 떨어뜨립니다.
2. Matrix의 핵심 아이디어: 모든 것을 메시지로, 모든 것을 P2P로
Matrix는 기존 구조를 완전히 재설계해 병목을 없애는 데 집중했습니다. 핵심 원리는 다음과 같습니다.
1) Orchestrator 객체를 입력 row마다 생성
하나의 데이터 row는 하나의 orchestrator 객체를 가진다. 이 안에는 다음 정보가 모두 포함된다.
- 현재 상태
- 대화 히스토리
- 다음으로 실행할 에이전트 정보
에이전트 간 통신은 이 orchestrator 메시지를 그대로 넘기며 진행된다.
2) 에이전트는 전체 파이프라인을 모르는 가벼운 프로세스
Matrix의 에이전트는 Ray Actor 기반의 경량 프로세스다.
- 메시지를 받아 처리하고
- orchestrator를 업데이트 한 뒤
- 다음 에이전트에게 그대로 전달한다
이 과정이 peer-to-peer 방식으로 진행된다. 중앙 제어자는 존재하지 않는다.
3) 무거운 작업은 외부 서비스에 분리
LLM 추론은 vLLM·SGLang,
컨테이너 실행은 Apptainer 같은 별도 서비스로 넘겨 병목을 제거한다.
결과적으로 에이전트 로직은 가볍게, 무거운 작업은 외부로 나누는 구조가 만들어진다.
3. Row-Level Scheduling: GPU 활용률을 극대화하는 방식
기존 Ray Data나 Spark는 배치(batch) 단위 스케줄링을 사용한다.
이 방식은 다음 문제가 있다.
- 한 배치 안에 느린 row가 있으면 전체 배치가 다음 단계로 못 넘어간다
- 그 결과 GPU가 놀게 된다
Matrix는 스케줄링 단위를 아예 row로 바꿨다.
Row 단위 스케줄링의 장점
- 한 row가 끝나는 즉시 다음 row를 파이프라인에 흘려보낼 수 있다
- 길이가 다른 멀티스텝 워크플로도 GPU 대기 없이 처리된다
- 자연스럽게 GPU 사용률이 일정 수준 이상으로 유지된다
이 구조가 Matrix의 속도 향상에 결정적인 역할을 한다.
4. 케이스 스터디 1: Coral에서 6.8배 속도 향상
Collaborative Reasoner(Coral)는 두 에이전트가 토론하며 데이터를 생성하는 워크로드이다.
Matrix로 동일한 LLaMA-3.1-8B, 동일한 31개 A100 노드(총 248 GPU) 환경에서 실험한 결과:
- Coral: 6.1억 토큰 생성 (9시간)
- Matrix: 20억 토큰 이상 생성
- Throughput: 약 6.8배 증가
- 데이터 품질(agreement correctness)은 거의 동일
다른 부분은 건드리지 않고 파이프라인 구조만 바꾼 결과다.
5. 케이스 스터디 2: NaturalReasoning 데이터셋에서 2.1배 향상
NaturalReasoning 큐레이션은 다음과 같은 단계적 멀티에이전트 그래프다.
- 3B 분류 에이전트: 웹 문서 2,500만 개 필터링
- 70B 에이전트: 품질 점수 부여
- 마지막 에이전트: 질문·정답·풀이 추출
이 과정을 Matrix로 구성하면
- 전체 문서의 5.45%만 살아남아 약 100만 개의 고난도 QA가 생성되며
- 기존 Ray Data 방식 대비 토큰 처리량 2.1배 증가
워크로드가 단계적으로 복잡해질수록 Matrix의 장점이 더 선명해진다.
6. 케이스 스터디 3: Tau2-bench에서 최대 15.4배 향상
Tau2-bench는 사용자 시뮬레이터, 어시스턴트, 툴 실행기, 리워드 계산기 총 네 에이전트가 협력하는 구조다.
여기에 수천 개의 툴 컨테이너가 병렬로 돌아간다.
Matrix를 적용한 결과:
- 13개 H100 노드
- gpt-oss-120B
- 1,500개 컨테이너 병렬
환경에서
기존 Tau2-agent 대비 15.4배 더 많은 초당 토큰을 생성했다.
놀라운 점은 속도만 오른 게 아니라
평균 reward(성공률)도 거의 동일하게 유지된다는 점이다.
즉, 빠르게 돌리지만 품질이 떨어지지 않는다.
7. 병렬성 실험: 특히 효과가 큰 것은 태스크(Task) 병렬성
Matrix는 세 가지 병렬성 레벨을 실험했다.
- 데이터 병렬성: 입력 파티션 여러 개
- 태스크 병렬성: 파티션당 다수 orchestrator를 비동기로 실행
- 에이전트 병렬성: 에이전트 인스턴스 여러 개
실험 결론은 다음과 같다.
- 실제 속도 향상에 가장 큰 영향을 준 것은 태스크 병렬성
- 데이터·에이전트 병렬성은 적당한 수준만 주면 충분
- peer-to-peer 구조 덕분에 튜닝 공간이 넓지만 복잡하지 않다
1만 4천 수준의 동시 태스크만으로도 GPU를 거의 꽉 채울 수 있음이 확인됐다.
8. Matrix가 빠른 이유를 만드는 시스템 레벨 최적화
Matrix는 구조뿐 아니라 시스템 자체도 최적화했다.
1) LLM 서비스는 HTTP 대신 gRPC
오버헤드가 줄고 응답 지연이 감소한다.
2) 대화 히스토리 저장 방식 최적화
- 작은 데이터는 Redis
- 512바이트 이상 히스토리는 Ray Object Store로 오프로드
이를 통해 네트워크 사용량을 약 20% 절감했다.
3) 리소스 구성의 안정성 확보
- SLURM·스팟 인스턴스 등 불안정한 리소스는 LLM·컨테이너에만
- 에이전트는 항상 영구 노드에 배치
이로써 장애 복구가 단순해지고 안정적 실행이 가능해진다.
정리하면,
“에이전트 논리는 가볍게, 무거운 작업은 분산 서비스로, 스케줄링은 row 단위로”
라는 일관된 설계 원칙이 속도 향상의 핵심이다.
Synthetic Data 파이프라인의 새로운 표준이 시작되고 있다
Matrix는 기존 멀티에이전트 synthetic data 파이프라인이 가진 구조적 병목을 해결하는 방향으로 설계되었고, 실제 서비스급 워크로드에서 속도를 최대 15배까지 끌어올리며 그 효과를 증명했습니다.
특히 주목해야 할 점은 다음과 같습니다.
- 속도 향상은 모델 변경이 아니라 파이프라인 구조 개선에서 나왔다
- GPU 리소스를 더 효율적으로 쓰기 위해 필요한 것은 row-level scheduling
- peer-to-peer 구조는 성능뿐 아니라 워크로드 확장성도 크게 높인다
- 품질을 유지하면서도 생성량을 극적으로 늘릴 수 있다
Synthetic data의 중요성이 갈수록 커지는 지금,
Matrix는 “속도를 올리는 가장 현실적인 방법은 파이프라인을 다시 설계하는 것”이라는 사실을 명확하게 보여주는 사례입니다.
LLM 개발과 데이터 엔지니어링이 더 커지고 복잡해질수록,
이런 구조적 혁신이 실무 경쟁력을 결정하는 핵심 요소가 될 것입니다.
https://arxiv.org/abs/2511.21686
Matrix: Peer-to-Peer Multi-Agent Synthetic Data Generation Framework
Synthetic data has become increasingly important for training large language models, especially when real data is scarce, expensive, or privacy-sensitive. Many such generation tasks require coordinated multi-agent workflows, where specialized agents collab
arxiv.org
'인공지능' 카테고리의 다른 글
| 알리바바 ‘AgentEvolver’: 스스로 학습 데이터를 만들어 진화하는 자율 에이전트 프레임워크 (0) | 2025.11.29 |
|---|---|
| DeepSeekMath-V2: AI가 올림피아드 수학 증명을 스스로 검증하는 시대의 시작 (0) | 2025.11.29 |
| INTELLECT-3: 100B+ 규모 RL 기반 Mixture-of-Experts 모델의 탄생과 기술적 혁신 (0) | 2025.11.28 |
| 왜 Spec-Driven Development는 인프라 자동화의 해답이 아닐까? AI 시대의 인프라를 위한 새로운 접근, 블루프린트 중심 배포 전략 (0) | 2025.11.28 |
| Gemini CLI로 완성하는 에이전틱 코딩 실전 가이드 (0) | 2025.11.28 |
