ToolOrchestra: Elevating Intelligence via Efficient Model and Tool Orchestration

Meta info.

• Authors: Hongjin Su, Shizhe Diao, Ximing Lu, Mingjie Liu, Jiacheng Xu, Xin Dong, Yonggan Fu, Peter Belcak, Hanrong Ye, Hongxu Yin, Yi Dong, Evelina Bakhturina, Tao Yu, Yejin Choi, Jan Kautz, Pavlo Molchanov
• Paper: https://arxiv.org/pdf/2511.21689
• Affiliation: Hong Kong Univ., NVIDIA
• Published: November 26, 2025
• Code: https://github.com/NVlabs/ToolOrchestra/

TL; DR

작은 8B 오케스트레이터 모델이 다양한 툴과 LLM을 RL로 통합적으로 조정하여 정확도/비용/latency/유저 선호를 동시에 최적화하는 툴 기반 에이전트 프레임워크를 제안. GPT-5보다 싸고 성능 좋은 결과를 보인다.

Background

• 최근 tool-agent는 좋은 LLM + 검색/계산기/코드 등 구조
  • RL기반 최적화 방식 적용: 정답기반이거나 비용에 패널티 주는 수준
    • 사용자는 실제 비용/속도/툴 종류에 따른 선호가 있는데 이를 반영하지는 못함
• 프롬프팅으로 gpt-5나 qwen3-8b 등에게 다른 모델 호출해보라고 하면 자기 variants나 가장 강한 모델만 남발

Problem States

작은 모델로 다양한 툴(더 큰 모델 포함)을 언제 어떻게 부를지 결정하여 정답률을 높이면서 비용이나 latency는 줄이고 유저 선호를 반영하는 policy 학습

Suggestions

ToolOrchestra → Orchestrator-8B 학습 (qwen backbone)

• 작은 오케스트레이터 LLM을 하나 두고, 얘가 매 스텝마다 어떤 툴(또는 LLM)을 어떻게 쓸지를 MDP + RL 관점에서 배우게 하자
  • 그때 보상은 정답률 + 비용 + 지연 + 유저 툴 선호를 한 번에 반영하는 벡터 내적으로 설계
• MDP로 tool orchestration 정의
  • state: 지금까지 대화와 tool 이력 = history를 전부 상태로 가정
  • action: 어떤 tool/llm 쓸지, 어떤 parameter 쓸지, 멈출지 등을 결정
  • environment: tool 실행 결과를 observation으로 받음
  • trajectory: 한 episode당 얼마나 문제를 잘 맞추고 몇번이나 tool을 쓰고 총 얼마나(비용을) 쓰는지 등으로 R 설계
• tool interface:
  • 모두 json기반으로 통일
    • 각 도구 당 어떤 걸 하는지(한계는 뭔지) + 파라미터스키마 정의
    • 즉 모든 툴을 써야하는지 text 수준에서 추론하도록
  • 출력: CoT 기반 JSON을 써서 tool을 부르고 그 결과를 Observation으로 씀
• Reward modeling: metric vector로 구성 (scale이 달라도 한번에 다루도록)
  • 정답을 맞추는 것은 성립 조건이고, 그 안에서 어떤 툴을 얼마나 썼는지 + 비용 + 지연을 유저 선호 벡터 P에 맞춰 스코어 부여
  • trajectory 종료 후 정답 여부
  • efficiency 측면에서 비용과 Latency에 penalty
  • tool call 횟수.. 등
  • user preference vector P:
    • 자연어 선호 여부를 preference 스칼라 p로 mapping: feature는 앞선 reward 처럼 부여
    • e.g. gpt-5는 비싸니까 p_{gpt-5} = 0.1, qwen3-32b와 math_llm은 싸니까 각각 0.7, 0.8, … compute 아끼는 것 중요하다 → p_{\text{compute}} = 0.8
• GRPO 업데이트
  • 현재 오케스트레이터 파라미터 \theta로 여러 input task에 대해 rollout
    • 각 task마다 여러 trajectory 샘플 (temperature 살짝 키워서)
  • 각 trajectory \tau에 대해 위에서 설명한 보상 R(\tau) 계산
  • 같은 input에 대한 샘플들을 “group”으로 묶어, group 내에서 reward를 normalize:
    • \hat{R}(\tau) = (R(\tau) - \mu_{\text{group}})/\sigma_{\text{group}}
  • 이걸 advantage처럼 써서 GRPO objective로 policy gradient 업데이트

Effects

• target tasks: HLE(phd 수준 QA), FRAMES(wikipedia 기반 multi-hop RAG), \tau^2-Bench(multi-domain function call bench)
• result:
  • Tab 1 GPT-5 대비 Orchestrator가 더 정확하고 약 3배 저렴 = routing 성능 훌륭
    • Fig 3 Tab 15 GPT-5, GPT-5-mini, Qwen3-32B, 코드 모델, 수학 모델, 검색, 코드 인터프리터 등등 전반에 대해 호출을 더 균등하게 배치
    • 다른 모델들보다 GPT-5를 훨씬 덜 자주 호출하면서 더 나은 성능
  • unseen tool에 대해서도 일반화 가능
    • 학습때 안쓴 LLM 등에 대해서도 적용 가능 즉 tool을 갈아끼워도 강건
  • Fig 6 주어진 비용 하에서 더 나은 정확도 달성

Personal note. 현재 진행하는 연구가 중요하다고 주장하는 어떤 근거가 될 수 있을 것 같은데 그러나 그런 문제의식에서 시작해서 셋팅한 제 연구의 문제가 사소해보이는 것 같기도…