TRINITY: 작은 Coordinator로 여러 LLM을 지휘하는 방법

원본 논문 아카이브 링크 :

arXiv.orgTRINITY: An Evolved LLM Coordinator

TRINITY: An Evolved LLM Coordinator

Combining diverse foundation models is promising, but weight-merging is limited by mismatched architectures and closed APIs. Trinity addresses this with a lightweight coordinator that orchestrates...

💡

한 문장 요약

TRINITY는 작은 언어 모델이 문제를 직접 풀게 하지 않고, 여러 강력한 LLM 중 누가, 어떤 역할로, 다음 작업을 수행할지 결정하도록 학습한 Multi-LLM Coordinator다.

~~응애 해줘~~

이 글에서 다루는 내용

TRINITY가 해결하려는 문제

Thinker–Worker–Verifier 기반 Multi-turn Coordination

0.6B SLM의 Hidden State를 Router 신호로 사용하는 방법

20K 미만의 파라미터만 학습하는 구조

sep-CMA-ES가 RL · SFT · Random Search보다 유리했던 이유

Benchmark, Zero-shot Transfer, Ablation 결과

논문의 한계와 실제 AgentOps 시스템에 적용할 때 필요한 보완점

1. 좋은 모델을 만드는 대신 좋은 코디네이터를 만든다

어려운 문제를 해결해야 하는데 각 모델별로 잘하는 영역이 다 다름.

GPT-5: 코딩에 강함
Gemini 2.5 Pro: 수학과 일반 추론에 강함
Claude 4 Sonnet: 설명과 검토에 강함
Qwen, DeepSeek, Gemma: 각기 다른 특성과 비용을 가짐

그런데 특정 태스크를 누가 잘하는지 알기위해 매번 다양한 모델에 질문하는건 비용 소모가 너무 큼.

그렇다고 하나만 고정적으로 사용하면 모델의 약점 부분에 걸릴 가능성이 큼. ~~구독제를 하나만 사용하는 사람을 병신 취급~~

TRINITY는 여기에 작은 코디네이터를 둔다.

사용자 질문
    ↓
SLM(coordinator): “먼저 Gemini가 계획을 세워.”
    ↓
Gemini — Thinker
    ↓
SLM(coordinator): “이제 GPT-5가 실제 답을 만들어.”
    ↓
GPT-5 — Worker
    ↓
SLM(coordinator): “Claude가 결과를 검토해.”
    ↓
Claude — Verifier
    ↓
최종 답변

이 코디네티어는 문제를 직접 풀 만큼 강력할 필요가 없다. 다음 두 가지만 잘하면 된다.

다음에 호출할 LLM 선택

선택한 LLM에 부여할 역할 선택

즉, TRINITY는 거대한 단일 모델을 만드는 연구가 아니라 여러 모델의 능력을 상황에 맞게 배치하는 Control Plane에 가깝다.

2. 왜 Model Merging이나 단순 Router로는 부족한가?

2.1 더 큰 단일 모델의 한계

일반적인 Scaling 접근은 모델 크기, 학습 데이터, Compute를 계속 늘리는 것이다. 성능은 좋아질 수 있지만 비용이 크고, 모델 하나가 모든 분야에서 항상 최고라는 보장도 없다.

논문의 개별 모델 결과에서도 전문성이 뚜렷하게 나타난다.

LiveCodeBench에서는 GPT-5가 강하다.

MATH500과 RLPR에서는 Gemini가 강하다.

일부 질문에서는 Claude나 Open-source 모델이 더 좋은 답을 낸다.

따라서 중요한 문제는 “최고의 모델 하나가 무엇인가?”보다 “현재 상태에서 어떤 모델을 사용해야 하는가?”에 가깝다.

2.2 Model Merging의 한계

Model Merging은 여러 모델의 Weight를 하나로 합치는 Micro-level fusion이다. 하지만 다음 제약이 있다.

모델 아키텍처가 호환되어야 한다.

Weight에 접근할 수 있어야 한다.

Closed-source 모델은 병합할 수 없다.

서로 다른 능력이 Weight 공간에서 간섭할 수 있다.

TRINITY는 모델 내부를 합치지 않는다. 모델을 Black-box로 유지한 채 호출 순서와 역할만 조정한다.

Model Merging
여러 모델의 Weight를 하나로 합침
→ Micro-level fusion

TRINITY
모델은 그대로 두고 호출과 메시지 흐름을 조정
→ Macro-level fusion

2.3 단순 Router의 한계

단순 Router는 질문을 보고 모델 하나를 선택한다.

질문 → Router → 모델 하나 → 답변

하지만 복잡한 문제에는 보통 다음 과정이 필요하다.

문제 분석

해결 전략 수립

실제 계산 또는 코드 작성

결과 검증

필요한 경우 수정

TRINITY는 이 과정을 여러 Turn으로 나누고, 매 Turn마다 모델과 역할을 다시 선택한다.

3. 세 가지 역할: Thinker, Worker, Verifier

3.1 Thinker — 설계자

Thinker는 문제를 끝까지 직접 풀기보다 전략을 세운다. - 일종의 Planner

문제를 하위 문제로 분해한다.

해결 순서를 설계한다.

필요한 계산과 확인 항목을 찾는다.

현재 답변의 약점을 분석한다.

다음 Agent가 해야 할 일을 제안한다.

예를 들어 Kubernetes 장애라면 다음과 같은 계획을 만들 수 있다.

1. Pod 상태를 확인한다.
2. Event를 확인한다.
3. Image pull 실패인지 확인한다.
4. Scheduling 문제라면 Node resource와 taint를 확인한다.
5. Network 문제라면 CNI 로그를 확인한다.

Thinker의 목적은 정답 자체보다 어디부터 어떤 순서로 접근할지 결정하는 것이다.

3.2 Worker — 실행자

Worker는 실제 작업을 수행한다. - coder

계산

코드 작성

답변 생성

증명

구체적인 문제 해결

논문의 감가상각 예시에서는 Thinker가 계산 순서를 계획하고, Worker가 다음과 같이 실제 계산을 수행한다.

정액법 비율 = 1 / 8 = 12.5%
DDB 비율 = 25%
1년 차 감가상각 = 15,000 × 25% = 3,750
2년 차 기초 장부가액 = 11,250
2년 차 감가상각 = 11,250 × 25% = 2,812.50

3.3 Verifier — 검수자

Verifier는 누적된 답변이 올바른지 검사한다.

계산이 맞는가?

질문에 실제로 답했는가?

빠진 조건이 있는가?

코드나 출력 형식이 올바른가?

추가 수정이 필요한가?

Verifier는 ACCEPT 또는 REVISE를 출력한다.

ACCEPT: 현재 해결안을 채택하고 종료

REVISE: 진단 내용을 남기고 다음 Turn에서 수정

역할	조직 비유	핵심 기능
Thinker	Architect	계획·분해·전략
Worker	Engineer	계산·코드·답변 생성
Verifier	Reviewer / QA	정확성·완전성 검증

중요한 점은 역할마다 모델이 고정되지 않는다는 것이다. 같은 GPT-5라도 어떤 문제에서는 Worker가 되고, 다른 문제에서는 Verifier가 될 수 있다.

4. 전체 동작 과정

사용자 질문을 Q, k번째 Turn 이전까지의 Transcript를 Cₖ₋₁이라고 하자.

Coordinator가 원래 질문과 전체 Transcript를 읽는다.

LLM Pool에서 Agent Aₖ를 선택한다.

Thinker·Worker·Verifier 중 역할 Rₖ를 선택한다.

역할별 Prompt를 선택한 LLM에 주입한다.

LLM의 결과를 Transcript에 추가한다.

Verifier가 ACCEPT하거나 최대 Turn Budget에 도달할 때까지 반복한다.

flowchart TD
    Q[User Query] --> C[0.6B SLM Coordinator]
    C --> H[Lightweight Head]
    H --> A[LLM 선택]
    H --> R[Role 선택]
    A --> P[Role-specific Prompt]
    R --> P
    P --> L[Selected LLM]
    L --> T[Transcript 갱신]
    T --> C
    L --> V{Verifier ACCEPT?}
    V -->|Yes| F[Final Answer]
    V -->|No| C

논문의 기본 설정은 최대 5 Turn이다. Turn 수를 고정하지 않고 Verifier의 승인에 따라 조기 종료할 수 있으므로, 문제 난이도에 맞춰 Compute를 배분할 수 있다.

5. 작은 SLM이 어떻게 강력한 LLM을 지휘하는가?

논문에서 Coordinator Backbone은 Qwen3-0.6B다.

핵심 가설은 다음과 같다.

작은 모델이 정답을 생성하지 못하더라도, 입력이 어떤 종류의 문제이며 현재 대화가 어떤 상태인지는 Hidden State에 충분히 표현할 수 있다.

5.1 Hidden State란?

LLM 이 사용자의 질문을 이해한 내재 데이터 혹은 상태.

“Python으로 binary search 코드를 작성하라.”

이 문장을 보면 다음 정보를 빠르게 파악할 수 있다.

프로그래밍 문제

Python 코드 필요

알고리즘 문제

실행 가능한 결과 필요

Transformer도 Token을 처리하면서 내부 Vector를 만든다.

h = [0.12, -0.51, 0.83, ..., 0.07]

TRINITY에서 사용한 Hidden State의 차원은 1,024다. 이 Vector가 Lightweight Head의 유일한 입력이다.

5.2 왜 끝에서 두 번째 Token인가?

논문은 주로 Penultimate output token, 즉 끝에서 두 번째 Token의 Hidden State를 사용한다.

마지막 Token은 <EOS>처럼 단순히 “출력이 끝났다”는 의미를 가질 수 있다. 반면 끝에서 두 번째 Token은 전체 Sequence를 Attention으로 참고하면서 마지막 출력을 결정하기 때문에 문맥 정보가 더 풍부할 수 있다.

비유하면 다음과 같다.

마지막 Token: 회의 종료 도장

끝에서 두 번째 Token: 최종 결론을 말하기 직전의 머릿속 상태

Ablation 결과에서도 마지막 Token을 사용하면 평균 점수가 70.44 → 64.66으로 하락한다. LiveCodeBench에서는 61.46 → 50.85로 10%p 이상 떨어진다.

Coordinator가 생성한 자연어 Text 자체는 사용하지 않는다. 필요한 것은 생성 문장이 아니라 내부 Hidden State다. 논문은 완전한 문장을 생성하기 전에 더 이른 Token의 Hidden State로 결정을 내리면 추론 시간을 줄일 가능성도 언급한다.

💡

여기서 그럼 더 이른 시점의 토큰을 사용해도 되나? 답은 “가능하다”.

논문에서는 Penultimate output token 이전 토큰들도 사용은 가능하지만 가장 끝에 있는 토큰이 의미론적으로 문맥정보가 풍부할 수 있다는 이유로 이 부분만 실험을 진행했다고 한다. 하지만 토큰이 필요한게 아닌 hidden vector 가 필요한 정보기에 굳이 텍스트가 전체 생성되기를 기다릴 필요가 없고 더 이른 시점의 토큰을 사용해도 될것이라는 말을 남겼다.

6. Lightweight Head: 1,024차원 의미를 10개의 선택지로 바꾼다

가장 단순한 Linear Head는 다음과 같다.

z = W * h

h: 1,024차원 Hidden State

W: 학습할 Weight Matrix

z: 모델 및 역할 선택 Logit

LLM Pool에는 7개 모델이 있고 역할은 3개이므로 Head는 총 10개의 Logit을 출력한다.

모델 선택 Logit: 7개
역할 선택 Logit: 3개
--------------------
총 출력:        10개

예를 들어 다음과 같은 값이 나왔다고 하자.

모델 Logit
GPT-5       4.2
Gemini      2.1
Claude      1.8
...

역할 Logit
Thinker     0.8
Worker      3.7
Verifier    1.2

이번 Turn의 결정은 GPT-5 + Worker가 된다.

Linear Head의 파라미터 수는 다음과 같다.

1,024 × 10 = 10,240

0.6B SLM이나 외부 LLM과 비교하면 매우 작은 규모다.

7. SLM도 아주 조금 조정한다: Singular Value Fine-Tuning

TRINITY는 Head만 학습하지 않고 SLM 일부 Layer의 Weight 표현도 조금 조정한다. 다만 전체 Weight를 Fine-tuning하지는 않는다.

arXiv.orgTransformer-Squared: Self-adaptive LLMs

Transformer-Squared: Self-adaptive LLMs

Self-adaptive large language models (LLMs) aim to solve the challenges posed by traditional fine-tuning methods, which are often computationally intensive and static in their ability to handle...

위 논문을 참고했다고 함. ~~- 고로 난 저게 뭔지 모르겠다.~~

위 논문에서 전체 파라미터가 아닌 파라미터 일부만 미세조정을 통해 전체가 아닌 일부 레이어들만 조정을 진행.

Weight Matrix를 SVD로 분해하면 다음과 같이 표현할 수 있다.

W = U Σ Vᵀ

U, V: 방향 정보

Σ: 각 방향의 크기 또는 중요도

TRINITY는 U와 V를 고정하고 Singular Value Scale만 학습한다. 라디오 회로를 새로 만드는 대신, 기존 주파수별 볼륨 Knob만 조절하는 것과 비슷하다.

Linear Head                    10,240
Singular Value Fine-Tuning      9,216
--------------------------------------
총 학습 파라미터              19,456

전체 학습 파라미터가 20K 미만이다. 이 조정을 제거하면 평균 점수가 70.44 → 67.85로 내려간다. 즉, SLM의 표현 공간을 Coordination에 맞게 조금 조정하는 것이 실제로 도움이 된다.

8. 왜 작은 Linear Head만으로 충분한가? — Separability

8.1 문제 종류가 Hidden State에서 분리된다

Separability는 서로 다른 종류의 데이터가 표현 공간에서 잘 분리된다는 뜻이다.

좌: Penultimate Hidden State 의 분포와 우: 벤치마크별 에이전트 선택지들의 분포

이처럼 종류별로 떨어져 있다면 복잡한 Neural Network가 없어도 직선 몇 개로 구분할 수 있다.

논문에서 Hidden State로 네 Task를 분류했을 때 Linear SVM은 정확도 100%를 기록했다.

Task classes
- LiveCodeBench
- MATH500
- MMLU
- RLPR

Linear SVM accuracy: 1.000
Random baseline:     0.250

이는 Qwen3-0.6B가 모든 정답을 알지는 못해도 문제가 코딩인지, 수학인지, 일반 지식인지는 매우 선명하게 표현한다는 의미다.

8.2 Task 분류와 Agent 선택은 다르다

Task 종류 분류는 100%였지만, Hidden State에서 Agent 선택을 예측하는 정확도는 다음과 같다.

Linear SVM: 71.3%

RBF SVM: 77.6%

Random baseline: 약 14.3%

“이것은 코딩 문제다”를 판단하는 것보다 “이 특정 코딩 문제는 GPT-5와 Claude 중 누가 더 잘 풀 것인가”를 판단하는 것이 더 어렵다는 뜻이다. 그래도 Random보다 훨씬 높은 구조적 신호가 존재한다.

8.3 Head는 의미 공간을 의사결정 공간으로 압축한다

Raw Hidden State에서는 Task 종류가 잘 분리되고, Head 출력 Logit 공간에서는 Agent 선택이 더 잘 분리되는 경향이 나타난다.

즉, Head는 모든 의미 정보를 보존하려는 것이 아니라 다음 결정에 필요한 축으로 표현을 재배치한다.

Representation Space
“이 질문은 어떤 의미와 종류인가?”
            ↓
Coordination Space
“어떤 모델에 어떤 역할을 줄 것인가?”

9. 학습 목표

Coordinator 파라미터를 θ, 여러 Turn에 걸친 전체 실행 경로를 τ라고 하자.

J(θ) = E[R(τ)]

πθ: Agent–Role 선택 정책

τ: Multi-turn 실행 경로

R(τ): 최종 정답이면 1, 아니면 0

J(θ): 평균 최종 정답률

목표는 최종 성공 확률이 가장 높은 정책을 찾는 것이다.

θ* = arg max J(θ)

문제는 Reward가 마지막에만 주어진다는 것이다.

Turn 1: Thinker 선택       Reward 없음
Turn 2: Worker 선택        Reward 없음
Turn 3: Verifier 선택      Reward 없음
최종 답변 평가             Reward 0 또는 1

답이 틀렸을 때 첫 Agent 선택, 역할 배정, Worker 결과, Verifier 판단 또는 Head의 어느 파라미터가 잘못됐는지 직접 알기 어렵다. 이것이 Credit Assignment 문제다.

10. sep-CMA-ES를 쉽게 이해하기

10.1 여러 코디네티어 후보를 시험한다

현재 Coordinator 정책을 기준으로 파라미터를 조금씩 다르게 바꾼 후보를 여러 개 만든다.

현재 Coordinator
   ├── 후보 1: 파라미터를 조금 변경
   ├── 후보 2: 다른 방향으로 변경
   ├── 후보 3: 또 다른 방향으로 변경
   └── ...

각 후보가 실제로 문제들을 풀도록 하고 최종 Reward를 측정한다.

후보 1 평균 Reward: 0.72
후보 2 평균 Reward: 0.81
후보 3 평균 Reward: 0.65
후보 4 평균 Reward: 0.78

성적이 좋은 후보들의 특성을 가중 평균해 다음 세대의 중심을 만든다. “어느 파라미터가 정확히 몇 점을 기여했는가?”를 계산하지 않고 결과가 좋았던 전체 파라미터 조합을 보존하는 방식이다.

10.2 왜 REINFORCE보다 유리했는가?

REINFORCE는 선택 확률의 Gradient에 최종 Reward를 곱해 정책을 개선한다. 하지만 이 문제에서는 다음 이유로 Signal-to-Noise Ratio가 낮다.

Reward가 최종 0/1로만 주어진다.

한 실행에 여러 LLM 호출과 Turn이 포함된다.

LLM 출력 자체도 확률적이다.

약 10K개 파라미터 각각의 영향은 작다.

어떤 Turn의 선택이 최종 실패를 만들었는지 구분하기 어렵다.

Evolution Strategy는 미분 가능한 내부 구조나 정교한 Credit Assignment 없이 End-to-end 결과만으로 정책을 비교할 수 있다.

10.3 왜 Full CMA-ES가 아니라 sep-CMA-ES인가?

Full CMA-ES는 모든 파라미터 쌍의 상관관계를 담는 Covariance Matrix를 관리한다. 10,000개 파라미터라면 Matrix는 약 10,000 × 10,000 크기다.

sep-CMA-ES는 대각 성분만 유지한다.

Full CMA-ES
- 파라미터 1과 2의 관계
- 파라미터 1과 3의 관계
- 파라미터 2와 3의 관계
- ...

sep-CMA-ES
- 파라미터 1의 탐색 폭
- 파라미터 2의 탐색 폭
- 파라미터 3의 탐색 폭
- ...

논문은 Coordination 목적함수가 block-ε-separable한 성질을 보인다고 주장한다. 쉽게 말하면 파라미터들이 완전히 독립적이지는 않지만, 작은 Block 단위로 비교적 독립적으로 최적화할 수 있다는 뜻이다.

따라서 전체 상관관계를 추적하는 비용을 지불하지 않고도 대각 방식으로 좋은 결과를 얻을 수 있다는 설명이다.

11. 학습 알고리즘 비교

학습 방식	LiveCodeBench	MATH500	MMLU	RLPR
---	---:	---:	---:	---:
REINFORCE	25.3	45.9	50.0	26.6
Random Search	37.4	79.4	89.7	34.5
SFT	59.2	78.6	90.6	36.0
sep-CMA-ES	61.5	88.0	91.6	40.1

결과를 해석하면 다음과 같다.

REINFORCE는 Sparse binary reward 환경에서 학습 신호가 불안정했다.

Random Search는 좋은 조합을 찾더라도 점진적으로 개선하는 능력이 약했다.

SFT는 Single-turn Agent 선택에서는 경쟁력이 있었다.

sep-CMA-ES는 Multi-turn Agent–Role 조합을 End-to-end Reward로 직접 최적화했다.

12. 왜 SFT로 Multi-turn Coordinator를 학습하지 않았나?

SFT에는 다음과 같은 Label이 필요하다. - 너무 많은 데이터셋 생성이 필요하고 너무 많은 평가가 필요하다.

이 질문에서는 GPT-5를 선택한다.
다음 Turn에서는 Gemini에게 Verifier 역할을 준다.

Single-turn이라면 모든 모델을 실행해 보고 가장 좋은 모델을 Label로 정할 수 있다. 하지만 Multi-turn에서는 경우의 수가 급격하게 증가한다.

모델 7개, 역할 3개라면 Turn마다 가능한 행동은 21개다.

7 × 3 = 21

5 Turn의 단순 행동 경로만 계산해도 다음과 같다.

21⁵ = 4,084,101

논문은 모든 Agent·Role 경로의 Oracle Label을 생성하려면 약 8.7 × 10¹⁰회의 LLM Query가 필요할 수 있다고 추정한다. 따라서 명시적 Label 없이 최종 Reward만 사용하는 방식이 훨씬 현실적이라는 주장이다.

13. 실험 설정

Coordinator

Backbone: Qwen3-0.6B

Head: 약 10K 파라미터의 Linear Layer

Singular Value Fine-tuning: 약 9K 파라미터

총 학습 파라미터: 20K 미만

최대 Coordination Turn: 기본 5

LLM Pool

Closed-source:

GPT-5

Gemini 2.5 Pro

Claude 4 Sonnet

Open-source:

Gemma 3 27B IT

DeepSeek-R1-Distill-Qwen-32B

Qwen3-32B Direct

Qwen3-32B Reasoning

In-distribution Task

MATH500

MMLU

RLPR

LiveCodeBench

Hold-out Task

AIME 2025

BigCodeBench

MT-Bench

GPQA-D

14. 주요 실험 결과

14.1 In-distribution 결과

TRINITY는 네 Benchmark에서 개별 모델과 기존 Multi-agent 방법보다 일관되게 높은 성능을 보였다. 특히 4K 출력 제한 조건에서 LiveCodeBench pass@1은 약 0.61로, GPT-5의 약 0.57보다 높았다.

LiveCodeBench 출력 길이 제한을 제거했을 때 결과는 다음과 같다.

모델	Pass@1
---	---:
Gemini 2.5 Pro	0.672 ± 0.031
GPT-5	0.838 ± 0.007
Claude 4 Sonnet	0.465 ± 0.010
TRINITY	0.862 ± 0.005

논문은 이를 LiveCodeBench V6의 새로운 SOTA로 보고한다. 단, 이 86.2% 결과는 출력 길이 제약을 제거한 별도 설정이며, 제약된 기본 설정의 61.46%와 구분해야 한다.

14.2 Turn 수에 따른 성능

LiveCodeBench에서 최대 Turn 수가 증가할수록 성능이 향상됐다.

2 Turns: 약 0.823
4 Turns: 약 0.851
6 Turns: 약 0.863

이는 TRINITY가 처음에 좋은 모델 하나를 고르는 단순 Router를 넘어, 계획·실행·검증을 반복하면서 답을 개선한다는 근거다.

다만 Turn 수가 늘면 API 비용, Latency, Context 길이도 증가한다. 실제 서비스에서는 최대 성능보다 성능–비용의 Pareto 최적점을 찾아야 한다.

15. Zero-shot Transfer

학습에 직접 사용하지 않은 Hold-out Task 결과는 다음과 같다.

모델	AIME	BigCodeBench	MT-Bench	GPQA-D	평균
---	---:	---:	---:	---:	---:
Gemini 2.5 Pro	46.67	35.10	9.37	75.25	52.34
GPT-5	46.67	33.80	9.35	72.73	51.07
Claude 4 Sonnet	35.33	35.80	9.28	67.30	46.14
TRINITY	50.00	35.80	9.60	76.82	54.21

이는 Coordinator가 단순히 Benchmark 이름과 대표 모델의 관계만 외운 것은 아닐 가능성을 보여준다. 새로운 문제에서도 Hidden State의 문맥 신호를 바탕으로 Agent를 선택하는 정책이 어느 정도 전이됐다.

다만 Gemini 대비 평균 차이는 1.87점이다. 유의미한 개선이지만 모든 Task에서 압도적인 차이라고 해석하기보다는 표본 수와 분산을 함께 확인해야 한다.

16. Ablation Study

구성	LiveCodeBench	MATH500	MMLU	RLPR	평균
---	---:	---:	---:	---:	---:
TRINITY	61.46	88.00	91.56	40.72	70.44
Singular Value FT 제거	55.68	85.85	90.10	39.77	67.85
Thinker 선택 제거	57.80	86.20	92.75	38.00	68.69
Tri-role 제거	58.28	82.00	91.64	36.15	67.02
Last token 사용	50.85	87.00	82.19	38.60	64.66
Claude만 사용	39.09	82.25	88.23	34.90	61.12
Gemini만 사용	46.51	83.05	79.41	43.00	62.99
GPT-5만 사용	59.54	75.66	90.74	37.87	65.95

이 결과에서 다음을 확인할 수 있다.

Agent 선택이 중요하다. 모델 하나를 고정하면 전체 평균이 하락한다.

Role 선택이 중요하다. Tri-role을 제거하면 수학과 복잡한 추론 성능이 크게 떨어진다.

Thinker가 기여한다. 제거 시 평균은 하락하지만 Task에 따라 영향은 다르다.

Representation 선택이 특히 중요하다. Last token을 사용했을 때 가장 큰 성능 저하가 나타난다.

모든 Task에서 TRINITY가 개별 최고 모델을 이기지는 않는다. 예를 들어 RLPR만 보면 Gemini 단독 점수가 더 높다. TRINITY의 장점은 여러 Task 전체에서의 일관성이다.

17. TRINITY가 학습한 실제 Routing 패턴

Task별 Agent 선택은 매우 뚜렷하다.

긍정적으로 보면 모델의 전문성을 자동으로 발견한 것이다. 하지만 비판적으로 보면 세밀한 질문별 Routing보다 Task 종류를 식별하고 대표 모델을 선택하는 효과가 상당 부분을 차지할 수 있다.

또한 Open-source 모델 일부는 거의 선택되지 않는다. 7개 모델을 사용하지만 학습 후 실질적으로 GPT-5, Gemini, Claude 중심의 Pool로 수렴한 셈이다.

18. Token 효율성

LiveCodeBench 평균 출력 Token은 다음과 같다.

방법	평균 출력 Token
---	---:
TRINITY	1,999
MoA	21,634
RouterDC	1,552
Smoothie	17,864
MasRouter	8,401

TRINITY는 모든 모델을 병렬로 호출하는 MoA나 Smoothie보다 훨씬 적은 Token을 사용한다. Turn마다 필요한 모델 하나를 선택하기 때문이다.

MoA
여러 모델을 모두 호출 → Aggregator 호출

TRINITY
필요한 모델 하나 호출 → 상태를 보고 다음 모델 선택

다만 출력 Token만으로 총비용을 판단할 수는 없다. 실제 운영 비용에는 Input Context, 모델별 API 단가, Reasoning Token, 순차 호출 Latency가 포함된다.

19. 이 논문의 핵심 기여

19.1 작은 모델은 정답 대신 배분을 담당할 수 있다

0.6B SLM이 GPT-5 수준의 문제 해결 능력을 가져야 하는 것이 아니다.

작은 모델
문제 종류와 현재 상태 표현
→ 누구에게 무엇을 시킬지 결정

큰 모델
실제 계획·계산·코드 작성·검증 수행

복잡한 능력을 외부 LLM에 Offload하고 Coordinator는 Contextual Routing에 집중한다.

19.2 Agent 선택과 역할 선택을 결합했다

기존 Router가 주로 Who를 선택했다면 TRINITY는 두 축을 함께 다룬다.

Who:  어떤 모델인가?
What: 어떤 역할을 수행할 것인가?

같은 모델도 Thinker Prompt와 Verifier Prompt에서는 다른 행동을 하게 된다.

19.3 Multi-turn Black-box 학습에 Evolution Strategy를 사용했다

다음 조건에서 sep-CMA-ES가 적합하다는 실증을 제시했다.

학습 파라미터 약 10K

최종 Reward가 0/1

LLM 호출 비용이 큼

각 파라미터의 개별 영향이 작음

파라미터 간 결합이 상대적으로 약함

평가 Budget이 제한됨

20. 한계와 주의해서 볼 부분

20.1 Tool을 실제로 실행하지 못한다

논문이 인정한 가장 큰 한계다. TRINITY는 “Python Interpreter로 검증하라” 또는 “API에서 상태를 조회하라”는 계획을 세울 수 있지만, 실제 실행 Agent가 없다.

현재 구조는 LLM Message orchestration에 가깝다. 실제 Agentic System으로 확장하려면 다음이 필요하다.

Code interpreter

Browser / Retrieval

Database query agent

Kubernetes·OpenStack·Ceph API

Static analyzer

Test runner

20.2 전체 Transcript가 계속 길어진다

매 Turn마다 원래 질문과 이전 결과 전체를 전달한다. Turn이 늘어나면 Context 비용이 증가하고 중요한 정보가 묻힐 수 있다.

실제 구현에서는 다음 구조가 필요하다.

State summarization

Structured scratchpad

Evidence store

Claim–source graph

중요도 기반 Context pruning

20.3 Verifier도 틀릴 수 있다

Verifier가 ACCEPT했다고 실제 정답이라는 보장은 없다. Worker와 Verifier가 같은 오개념이나 편향을 공유하면 오답을 함께 승인할 수 있다.

Worker의 오답
    ↓
Verifier도 같은 오개념 보유
    ↓
ACCEPT

운영 환경에서는 LLM Verifier만으로 부족하다.

코드: Unit test, Compiler, Static analysis

수학: Symbolic checker

인프라: Read-only 상태 조회

데이터: SQL constraint

사실 검증: Retrieval evidence

처럼 외부 Ground Truth가 필요하다.

20.4 Benchmark 형식을 학습했을 가능성

Task 종류가 Hidden State에서 100% 분리됐다는 결과는 장점이면서 주의점이다.

LiveCodeBench 형태 → GPT-5
MATH500 형태       → Gemini
MMLU 형태          → Claude

세밀한 문제별 협업보다 Dataset 식별 효과가 클 수 있다. Hold-out 결과가 이를 일부 완화하지만, 다음 검증이 추가로 필요하다.

Dataset 이름과 형식 제거

동일 도메인 내 세부 난이도별 Routing 분석

비슷한 형식의 Adversarial Task

새 모델 추가 시 재학습 비용

Closed-source API 모델 업데이트에 대한 Robustness

20.5 모델 Pool 변경과 Drift

Head 출력은 Agent 수에 직접 연결된다. 새 모델이 추가되면 출력 구조와 정책을 다시 조정해야 할 수 있다. Closed-source 모델의 성능 특성이 업데이트로 바뀌면 과거에 학습한 전문성 지도도 낡는다.

운영 환경에서는 다음이 필요하다.

주기적 Re-evaluation

Online adaptation

모델 Version pinning

Drift detection

비용·Latency 변화 반영

20.6 Latency와 실제 금전 비용

TRINITY는 순차 Multi-turn이므로 출력 Token이 적더라도 Wall-clock Latency가 길어질 수 있다. 총비용은 다음을 함께 계산해야 한다.

모델별 Input / Output 단가

Reasoning token

전체 Transcript 길이

호출 횟수와 Retry

병렬 실행 가능성

Coordinator Serving 비용

20.7 이론은 강한 가정에 의존한다

sep-CMA-ES 분석은 Local linearity, Curvature bound, Diagonal comparability, block-ε-separability 같은 가정을 사용한다. Head Architecture Ablation이 간접 증거를 제공하지만 실제 목적함수 전체가 항상 이 조건을 만족한다고 증명한 것은 아니다.

따라서 결론은 다음 정도가 적절하다.

sep-CMA-ES는 이 논문의 고차원·저예산·Binary reward 환경에서 효과적이었지만, 모든 Multi-agent 학습 문제에서 일반적으로 RL보다 우월하다는 뜻은 아니다.

20.8 논문 내부 수치 불일치

Appendix의 “LLM as Coordinator” 설명에는 Gemini Coordinator 평균이 64.14라고 적힌 부분이 있지만, Table 8의 개별 점수 평균은 53.76이다.

(78.67 + 83.26 + 26.83 + 26.28) / 4 = 53.76

따라서 64.14는 오타 또는 이전 실험 수치가 남은 것으로 보인다. 수치를 인용할 때는 Table의 53.76을 기준으로 보는 것이 타당하다.

참고 자료

Xu et al., TRINITY: An Evolved LLM Coordinator, ICLR 2026, arXiv:2512.04695

Hansen et al., Reducing the Time Complexity of the Derandomized Evolution Strategy with Covariance Matrix Adaptation, 2003

Ros & Hansen, A Simple Modification in CMA-ES Achieving Linear Time and Space Complexity, 2008

Wang et al., Mixture-of-Agents Enhances Large Language Model Capabilities, 2024

Yue et al., MasRouter: Learning to Route LLMs for Multi-Agent Systems, 2025