NVIDIA Cosmos 3를 스트레스 테스트하기 위한 LLM 토론 위원회 구축하기

벤치마크 점수는 모델이 테스트에서 얼마나 잘했는지를 알려줍니다. 하지만 모델이 자신의 입장을 고수할 수 있는지, 타격을 견뎌낼 수 있는지, 그리고 무너지지 않고 조정할 수 있는지는 알려주지 않습니다.

그 두 번째 사항이 바로 NVIDIA가 막 출시한 NVIDIA Cosmos 3에 대해 제가 알고 싶었던 것이었습니다. 그래서 또 다른 평가(eval)를 실행하는 대신, 더 재미있는 일을 했습니다. 모델을 위한 아레나(arena)를 구축하고 모델이 스스로 논쟁하게 만들었습니다.

// Detect dark theme var iframe = document.getElementById('tweet-2061515414837100955-54'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=2061515414837100955&theme=dark" }

그 결과물은 멀티 에이전트(multi-agent) 토론 위원회인 Cosmos Arena입니다.

이 모델이 일반적인 채팅 모델이 아니며, 이름이 오해를 불러일으킬 수 있기 때문에 시작하기에 앞서 솔직하게 말씀드리겠습니다.

NVIDIA는 로봇, 자율 주행 차량, 공장 현장 등 현실 세계의 움직임, 인과관계(causality), 그리고 물리학(physics)을 이해해야 하는 모든 것을 위한 **물리적 AI (Physical AI)**를 위해 Cosmos 3를 구축했습니다. NVIDIA는 2026년 6월 1일 GTC Taipei에서 이를 출시하며, 이를 네이티브 시각적 추론(vision reasoning) 기능을 갖춘 최초의 완전 개방형 옴니모델(omnimodel)이라고 부릅니다.

내부적으로는 **추론 트랜스포머 (reasoning transformer)**와 **전문가 생성 트랜스포머 (expert generation transformer)**를 결합한 혼합 트랜스포머 (Mixture-of-Transformers) 구조로 되어 있습니다. 절반은 객체 간의 상호작용, 움직임, 그리고 공간에 대해 생각합니다. 나머지 절반은 비디오와 행동 궤적(action trajectories)을 생성합니다.

핵심은 로봇이 행동하기 전에 추론할 수 있도록 하여, 물리적 AI의 학습 주기를 몇 달에서 며칠로 단축하는 것입니다. 전체적인 그림을 보고 싶다면 NVIDIA 기술 블로그에서 자세한 내용을 확인할 수 있습니다.

그렇다면 왜 토론을 진행하는 데 로보틱스 월드 모델 (robotics world model)을 사용하는 것일까요? 그 이유는 바로 저 추론 트랜스포머가 흥미로운 부분이기 때문입니다. NVIDIA는 물리적 세계에 대해 추론하도록 이 모델을 학습시켰고, 저는 그 능력이 본래 용도가 아니었던 것, 즉 이미지도 비디오도 없이 오직 아이디어만 존재하는 순수 언어 논쟁에 얼마나 잘 전이(transfer)되는지 확인하고 싶었습니다. 이러한 전이 능력은 단일 프롬프트 점수가 알려주는 것보다 훨씬 더 많은 것을 말해줍니다.

Cosmos 3 사양 요약

이 프로젝트에서 중요한 세부 사항은 다음과 같습니다.

속성	Cosmos 3 Super	Cosmos 3 Nano
총 파라미터 (Total parameters)	64B	16B
...

알아둘 만한 몇 가지 사항이 더 있습니다:

이것은 진정으로 옴니모달 (omnimodal) 합니다. 하나의 모델 내에서 텍스트, 이미지, 비디오, 주변 소리(ambient sound), 그리고 액션 시퀀스(action sequences)를 입력받고 생성할 수 있습니다.
텍스트, 이미지, 비디오, 사운드, 액션에 걸쳐 수십억 개의 샘플을 포함하는, 현존하는 가장 큰 멀티모달 물리 AI (multimodal physical AI) 데이터셋 중 하나로 학습되었습니다.
로보틱스 및 AI 연구소들(Agile Robots, Black Forest Labs, Runway, Skild AI 등)로 구성된 Cosmos Coalition과 함께 출시되었으며, 이들은 해당 모델을 기반으로 기술을 구축하고 있습니다.
NVIDIA는 한계점에 대해 솔직하게 밝히고 있습니다: 생성 과정에서 시간이 지남에 따라 드리프트(drift)가 발생할 수 있으며, 루프 내에서 실제로 실행되는 물리 시뮬레이터(physics simulator)가 없기 때문에 추론 과정에서 여전히 환각 (hallucination)이 발생할 수 있습니다.

우리의 구축 작업에서 중요한 부분은 추론 타워 (reasoner tower)와 모델이 역할을 얼마나 잘 수행하는가입니다. 이번 토론은 이 두 가지 측면에 크게 의존합니다.

실행 환경: Nebius Token Factory

64B 규모의 옴니 모델은 제 개인 GPU로 직접 관리하고 싶지 않은 규모입니다. 따라서 이 프로젝트의 모든 모델 호출은 Nebius Token Factory를 통해 이루어집니다.

Token Factory는 Nebius의 프로덕션 추론 (production inference) 플랫폼입니다. NVIDIA의 모델을 포함하여 오픈 모델 및 파트너 모델들을 가져와, 사후 학습 (posttraining) 및 거버넌스 (governance) 요소를 대신 처리해 주면서 하나의 빠르고 OpenAI 호환 가능한 API를 통해 제공합니다.

Nemotron과 같은 NVIDIA 모델들이 이미 그곳에서 실행되고 있으며, Nebius는 로보틱스 및 물리 AI를 위해 특별히 NVIDIA와 협력하여 클라우드 인프라를 구축해 왔습니다. 이는 Cosmos가 그곳에 자리 잡기에 자연스러운 환경임을 의미합니다.

이 프로젝트에 이 환경이 매우 잘 맞는 이유는 다음과 같습니다:

OpenAI와 호환되는 API. OpenAI를 위해 구축된 모든 것은 기본 URL만 변경하면 작동합니다. 기본 URL은 https://api.tokenfactory.nebius.com/v1/입니다.
LangChain에 바로 적용 가능한 지원. langchain-nebius 패키지를 사용하면 LangGraph에 바로 삽입할 수 있는 ChatNebius 모델을 얻을 수 있습니다.
GPU 프로비저닝 불필요. 모델 이름만 지정하고 토큰당 비용을 지불하면 됩니다. 이것이 전체 설정입니다.
다섯 좌석에 하나의 키. 모든 위원회 위원은 단일 NEBIUS_API_KEY를 공유하므로, 관리해야 할 에이전트별 자격 증명이 없습니다.

Nebius Token Factory 콘솔에서 키를 받아 바로 시작할 수 있습니다.

우리가 구축하는 것

위원회는 다섯 가지 역할을 합니다. 그중 네 개는 모델 호출입니다. 나머지 하나인 진행자(Moderator)가 그래프 자체이며, 이것이 모든 것을 작동하게 만드는 결정적인 요소로 밝혀집니다.

역할	노드	임무
옹호론자 (The Advocate)	`proponent`	동의안에 대해 주장하고 매 라운드마다 회의론자(Skeptic)를 반박합니다.
...

The 흐름은 개회사에서 시작하여, 번갈아 가며 이루어지는 반박 라운드를 거쳐, 선택적인 현실 점검을 거친 후, 최종적으로 채점된 평결로 이어집니다:

        +--------------+      +-------------+
START ->|  proponent   | ---> |  opponent   |
        +--------------+      +-------------+         |
...

그래프를 사용해야 하는 이유, 단순히 영리한 프롬프트가 아닌 이유

'X에 대해 양측을 주장하고, 그 후에 판결하라'고 지시하는 하나의 프롬프트를 시도해 볼 수는 있습니다. 읽기는 좋지만 아무것도 증명하지 못합니다.

문제는 모델이 '찬성' 사례와 '반대' 사례를 한 번의 호흡으로 작성한다는 것입니다. 이들은 서로 응답하지 않기 때문에, 함께 쓰였을 뿐입니다. 교환(exchange)은 없고, 단지 모델이 토론이라는 아이디어를 연출할 뿐입니다.

진짜 토론에는 프롬프트가 약속할 수 없는 구조가 필요합니다:

각 측은 각자의 차례를 가지므로, 각 논거는 집중된 생성 (generation)이 됩니다.
반박 (rebuttal) 단계에서는 상대측이 실제로 방금 무엇을 말했는지 확인합니다.
라운드가 쌓이므로, 나중에 옹호자 (Advocate)는 서두를 반복하는 대신 실제 이의 제기에 답변하게 됩니다.
심판 (judge)은 전체 전사 (transcript)를 읽고 고정된 기준에 따라 점수를 매깁니다.

이것은 프롬프트가 아니라 상태 머신 (state machine)이며, 이것이 바로 LangGraph가 존재하는 이유입니다. 구조를 코드에 넣는다는 것은 각 역할이 자신만의 격리된 호출 (call)을 받고, 반박 단계에서 이전 차례를 진정으로 확인하며, 라운드 횟수가 모델의 기분에 맡겨지는 대신 강제됨을 의미합니다.

사전 요구 사항 (Prerequisites)

Python 3.11 이상
Nebius Token Factory 계정 및 API 키
의존성 관리를 위한 uv (pip install uv)

의존성 목록을 의도적으로 짧게 구성했습니다:

dependencies = [
    "langgraph>=1.0",
    "langchain-nebius>=0.1.3",
...

프로젝트 레이아웃 (Project layout):

cosmos_arena_debate_council/
  app.py              # Streamlit UI 및 실시간 토론 스트리밍
  cosmos_council.py   # LangGraph 토론 그래프: 노드 (nodes), 라우팅 (routing), 모델
...

설정하기:

git clone https://github.com/Arindam200/awesome-ai-apps.git
cd awesome-ai-apps/advance_ai_agents/cosmos_arena_debate_council
uv sync
...

.env 파일:

NEBIUS_API_KEY=your_api_key_here
# 선택적 오버라이드 (Optional overrides)
COSMOS_MODEL=nvidia/Cosmos3-Super-Reasoner
...

1단계: Cosmos 3 연결 및 추론 채널 (reasoning channel) 처리하기

이 부분은 당신을 당황하게 만들 수 있는 유일한 함정이므로, 가장 먼저 다룹니다.

기본적인 ChatNebius 통합 방식은 일반적인 OpenAI 형태인 message.content에서 답변을 읽습니다. 하지만 추론 모델 (reasoner)로서 제공되는 Cosmos는 종종 답변을 표준이 아닌 reasoning 필드에 넣고 content는 비워둡니다. 통합 방식을 그대로 사용하면 모든 위원회 구성원이 빈 값으로 돌아오게 됩니다.

해결책은 reasoning 필드를 다시 포함시키는 작은 서브클래스(subclass)를 만드는 것입니다. 만약 content가 비어 있다면, reasoning이 정답이 됩니다. 만약 두 필드가 모두 존재한다면, reasoning은 UI에 표시될 별도의 사고 사슬 (Chain-of-Thought)이 됩니다.

from langchain_core.outputs import ChatResult
from langchain_nebius import ChatNebius

...

Cosmos는 반대로 content 내부의 <think> 태그 안에 자신의 reasoning을 감싸는 방식으로도 처리할 수 있습니다. 작은 분리 도구(splitter)를 사용하여 두 부분을 분리하면, UI가 실제 논거에 사고 과정을 섞지 않도록 할 수 있습니다.

import re

_THINK_RE = re.compile(r"<think>(.*?)</think>", re.DOTALL | re.IGNORECASE)
...

공통 팩토리(factory)가 이를 하나로 묶어줍니다. 모든 자리(seat)가 동일한 함수를 호출하므로, 모델은 변하지 않고 프롬프트(prompt)만 변경됩니다.

import os

def build_model(api_key=None, model=None, base_url=None, temperature=0.6) -> ChatNebius:
...

2단계: 각 자리에 페르소나 (Persona) 부여하기

역할은 단순히 시스템 프롬프트 (system prompt)일 뿐이지만, 진정으로 다른 행동을 강제하도록 작성되었습니다. 옹호자 (Advocate)와 회의론자 (Skeptic)는 새로운 내용을 추가하기 전에 상대방의 주장을 조목조목 반박하도록 지시받습니다. 실용주의자 (Pragmatist)는 어느 쪽의 편도 들지 않습니다. 중재자 (Arbiter)는 고정된 점수표를 만들어내야 합니다. 그중 두 가지 예시는 다음과 같습니다.

PROPONENT_PROMPT = (
    "You are The Advocate, a council member in the Cosmos Arena debate.\n"
    "Your role: argue persuasively and rigorously IN FAVOR of the motion.\n\n"
...

이 단계에서 Cosmos 3가 정말로 다섯 명의 서로 다른 사람이 될 수 있는지 확인할 수 있습니다. 성능이 낮은 모델은 정보가 새어 나갑니다. 회의론자가 동조하기 시작하거나, 중재자가 내용을 읽기도 전에 승자를 결정해 버립니다. 강력한 추론 모델 (reasoner)은 과정 내내 각 자리의 역할을 깨끗하게 유지합니다.

3단계: 토론을 상태 (State)로 모델링하기

토론 전체는 하나의 타입이 지정된 상태 (typed state) 객체 안에 존재합니다. 핵심은 추가 전용(append-only) 리스트인 transcript입니다. 각 노드 (node)는 오직 자신의 새로운 차례(turn) 하나만을 반환하며, LangGraph의 리듀서 (reducer)인 operator.add가 이를 실행 중인 transcript에 덧붙입니다. 이는 스트리밍되는 각 업데이트가 정확히 하나의 새로운 차례임을 의미하며, 실시간 UI에 완벽하게 적합합니다.

import operator
from typing import Annotated, TypedDict

...

작은 헬퍼 함수 하나가 상대방의 가장 최근 차례(turn)를 가져옵니다. 이것이 반박(rebuttal)을 일반적인 수준이 아닌 실제적인 것으로 만드는 핵심 요소입니다:

def _latest(transcript: list[Turn], speaker: str) -> str:
    for turn in reversed(transcript):
        if turn["speaker"] == speaker:
...

Step 4: 노드(nodes) 작성하기

각 위원회 위원은 하나의 노드(node)입니다. 역할 프롬프트(role prompt)를 포함한 하나의 모델 호출과 실시간 transcript로부터 구축된 사용자 프롬프트(user prompt)로 구성됩니다. 찬성론자(proponent)의 프롬프트가 첫 라운드와 이후 라운드 사이에서 어떻게 변하는지 살펴보세요. 라운드 2부터는 회의론자(Skeptic)의 가장 최근 논거를 전달받아 이를 조목조목 반박하도록 지시받습니다. 이것이 토론과 두 사람이 서로의 말을 듣지 않고 각자 말하는 것 사이의 결정적인 차이입니다.

def _say(model, system_prompt: str, user_prompt: str) -> tuple[str, str]:
    response = model.invoke([
        {"role": "system", "content": system_prompt},
...