Iris Search Agent 리뷰: Pro보다 Mini부터 시작해야 하는 이유

Iris의 성능표에서 가장 눈에 띄는 숫자는 88.6이지만, 실제 도입 판단에서 더 중요한 수치는 따로 있다. Iris-mini는 컨텍스트 처리 방식만 바꿔도 BrowseComp 점수가 17.5점 뛰었다. 따라서 먼저 검증할 대상은 Iris-mini와 공식 하니스다. Iris-pro는 이미 멀티 노드 추론 환경을 운영하는 팀에 더 어울린다.

한눈에 보는 Iris 선택 기준

실무적인 권장안은 간단하다. 우선 Iris-mini를 평가하라. Iris-pro가 더 높은 점수를 보고하긴 했지만, 공식 출시 예제부터 훨씬 많은 병렬 인프라를 요구한다. 게다가 2026년 9월 14일 기준으로 두 체크포인트 모두 Hugging Face의 호스팅 추론 제공업체가 없다.

출처: 공식 Iris-mini 모델 카드, Iris-pro 모델 카드, Iris 저장소.

가중치, 모델 카드, Iris-Harness 평가 코드는 공개돼 있다. 다만 저장소에는 데이터 구성과 학습 파이프라인이 아직 “coming soon”으로 표시돼 있다. 즉 Iris는 오픈 평가 하니스를 갖춘 오픈 웨이트 모델이지, 학습 레시피까지 완전히 공개된 상태는 아니다.

하니스가 달라지면 벤치마크 헤드라인도 달라진다

Iris의 벤치마크 점수는 체크포인트 자체의 성질로만 읽어서는 안 된다. AllSpark는 공개 수치가 에이전트와 하니스가 결합된 결과라고 명시하며, 공식 어블레이션도 그 이유를 분명히 보여 준다.

공식 Iris GitHub README에서 discard-all은 누적 컨텍스트가 임계값을 넘으면 원래 질문으로 되돌아가는 방식으로 정의된다. retry는 파싱 가능한 답변 없이 끝난 에피소드를 재시작하되, 이미 배제한 내용을 짧게 요약해 이어받는다.

Iris-mini는 체크포인트를 바꾸지 않고 discard-all만 적용해 BrowseComp를 64.7에서 82.2로 끌어올렸다. 17.5점 차이다. Iris-pro도 같은 비교에서 72.6에서 88.6으로, 16점 상승한다. 공식 대화 형식, 리셋 정책, 검색 도구, 답변 파서를 빼고 배포한다면 광고된 시스템을 재현하는 것이 아니다.

모델 간 비교표도 주의해서 봐야 한다. AllSpark는 베이스라인 수치가 각 프로젝트의 공개 보고서에서 왔으며, 서로 다른 컨텍스트 관리 설정을 썼을 수 있다고 밝힌다. Iris-mini는 표에 포함된 동급 규모 모델 가운데 BrowseComp, BrowseComp-ZH, HLE에서 앞서지만, DeepSearchQA에서는 XYZ-Aquila-mini가 89.5로 86.9의 Iris-mini보다 앞선다. Iris-pro는 나열된 약 400B급 시스템과의 비교에서 네 항목 모두 선두 또는 공동 선두다. 다만 DeepSearchQA에서 XYZ-Aquila-pro와의 차이는 0.4점에 불과하다.

Iris-mini와 Iris-pro, 배포 부담으로 판단하라

첫 체크포인트로 Iris-mini가 합리적인 이유는 활성 파라미터 수가 전체 모델의 저장 공간과 메모리 요구량을 없애주지는 않기 때문이다. MoE 라우터는 단계마다 35B 중 약 3B 파라미터를 활성화하지만, 전체 체크포인트는 여전히 저장하고 서빙해야 한다.

공식 Iris-mini 명령은 4방향 텐서 병렬화와 262,144토큰 컨텍스트를 사용한다.

python -m sglang.launch_server \
  --model-path AllSpark-Research/Iris-mini \
  --served-model-name Iris-mini \
  --port 21234 --tp-size 4 \
  --context-length 262144 \
  --reasoning-parser qwen3 \
  --tool-call-parser qwen3_coder

Iris-pro의 문서화된 구성은 --tp-size 8 --ep-size 8을 사용한다. 공식 모델 카드는 397B 체크포인트에 여러 노드 또는 대규모 단일 노드가 필요하다고 적고 있다. 단순한 설정 차이가 아니라 배포 조건에 관한 경고다.

discard-all 기준으로 대형 모델은 mini보다 BrowseComp에서 6.4점, DeepSearchQA에서 6.0점 높지만 BrowseComp-ZH 차이는 0.3점뿐이다. 이름에 “pro”가 붙었다고 해서 인프라 부담을 감수할 이유는 없다. 평가 대상 워크로드에서 그 성능 차이가 실제로 의미 있어야 한다.

두 모델 카드 모두 측정 지연 시간, 처리량, VRAM 사용량, 운영 비용을 공개하지 않는다. 이 정보가 빠진 이상 답변당 비용을 책임 있게 비교할 수 없다. 파라미터 수를 근거로 임의의 GPU 추정치를 만들기보다, 범위를 제한한 파일럿을 돌리는 편이 낫다.

재현 가능한 첫 Iris 평가 절차

첫 Iris 평가는 채팅 완성 엔드포인트에 상식 문제를 던지는 식이어서는 안 된다. 전체 에이전트 경로를 검증해야 한다. 공식 하니스에는 에이전트 루프, 검색 및 스크레이프 도구, 컨텍스트 전략, 벤치마크 어댑터, 채점기가 포함돼 있다.

1. 공식 파서로 Iris-mini를 서빙한다. 위 SGLang 명령을 사용하고, 21234 포트의 OpenAI 호환 엔드포인트에 접속되는지 확인한다.
2. Iris-Harness를 설치한다. 저장소는 환경 생성에 uv를 사용한다.
3. 벤치마크 데이터를 준비한다. 임의로 복사본을 조합하지 말고, 포함된 준비 스크립트를 실행한다.
4. 작은 벤치마크 구간부터 시작한다. 공식 예제는 browsecomp:0:1과 131,072토큰 discard 임계값을 선택한다.
5. 전체 구성을 기록한다. 모든 결과와 함께 모델 리비전, 도구 백엔드, 임계값, 파서 버전, 재시도 정책을 보관한다.

git clone https://github.com/AllSpark-Research/Iris.git
cd Iris/Iris-Harness
uv sync
uv run python data/prepare_data.py

bash scripts/run_eval.sh \
  --base-url http://127.0.0.1:21234/v1 \
  --llm-config iris-mini \
  --benchmarks "browsecomp:0:1" \
  --context-discard-threshold 131072

Iris는 OpenAI function-calling 인터페이스를 사용하고 최종 답변을 \boxed{}로 감싸도록 학습됐다. 하니스는 이전 추론 내용도 이후 턴으로 넘긴다. 이를 일반적인 채팅 템플릿으로 바꾸면, 평범한 텍스트 생성은 정상처럼 보여도 도구 사용이나 채점이 깨질 수 있다.

파일럿에서는 다음 세 가지를 합격 기준으로 삼는 것이 좋다.

• 답변 품질: 최종 개체를 찍어 맞히는 수준이 아니라, 필요한 근거를 실제로 찾아내는가?
• 검색 효율: 채택된 답변 하나당 검색과 스크레이프 호출을 몇 번 쓰는가?
• 복구 동작: 컨텍스트를 버리거나 에피소드를 재시도했을 때, 같은 실패 경로를 반복하지 않는가?

공식 릴리스는 프로덕션 SLA나 호스팅 엔드포인트를 제공하지 않는다. 벤치마크 재현에 성공했다는 것은 알려진 하니스 환경에서 시스템이 동작한다는 뜻일 뿐, 제한 없는 웹 리서치에서의 신뢰성을 입증하지는 않는다.

공개된 것과 아직 완전 재현을 막는 것

현재 Iris 릴리스는 상당한 범위를 담고 있지만 완전하지는 않다. 개발자는 승인 절차 없이 두 체크포인트를 내려받을 수 있고, Apache 2.0에 따라 상업적으로 사용할 수 있으며, 벤치마크 표를 검토하고 OpenAI 호환 엔드포인트를 대상으로 Iris-Harness를 실행할 수 있다.

논문은 하이퍼링크 그래프에서 멀티홉 질문을 역구성하고, 전체 실행 단위와 개별 턴 수준에서 궤적을 필터링하며, 지도 미세 조정과 라이브 검색 강화학습을 번갈아 수행하는 방식을 설명한다. 그러나 저장소의 공개 상태를 보면 외부 팀은 학습 전체 과정보다 먼저 추론과 평가를 재현할 수 있는 상황이다.

초기 커뮤니티 논의도 이 차이를 잘 짚는다. 한 기술 뉴스 계정은 이번 공개를 다음과 같이 요약했다.

“Weights + eval code are public. Training data and recipe come later.” — @Chinazhidx

지금 단계에서 가져야 할 신뢰 수준은 이 정도가 적절하다. Iris는 소문이 아니라 정식으로 공개된 모델이지만, 가장 강한 성능 주장은 공개된 하니스 설정 아래에서 외부 실행으로 검증될 필요가 있다. 2026년 9월 14일 확인 당시 Hugging Face 페이지에는 Iris-mini 월간 다운로드 335회, Iris-pro 월간 다운로드 685회가 표시됐다. 다운로드 수는 활동 신호일 뿐 검증 결과는 아니다.

Iris Search Agent FAQ

Iris는 모델인가, 완성된 검색 제품인가?

Iris는 오픈 웨이트 모델 제품군과 평가 하니스의 조합이다. 호스팅되는 소비자용 검색 애플리케이션이나 관리형 API는 이번 릴리스에 포함되지 않았다.

Iris를 로컬에서 실행할 수 있나?

가능하다. 다만 여기서 “로컬”이 노트북에서도 가볍게 실행된다는 뜻은 아니다. 공식 Iris-mini 예제는 4방향 텐서 병렬화를 사용하며, Iris-pro는 8방향 텐서 병렬화와 8방향 전문가 병렬화 구성으로 문서화돼 있다.

35B-A3B는 무엇을 의미하나?

Iris-mini는 전체 파라미터가 약 35B이고, 추론 단계마다 활성화되는 파라미터는 3B다. 희소 활성화는 모든 파라미터를 활성화할 때보다 연산량을 줄이지만, 전체 체크포인트는 여전히 저장 공간과 서빙 메모리에 영향을 준다.

Iris는 완전한 오픈 소스인가?

체크포인트와 하니스는 허용적인 조건으로 공개돼 있지만, 저장소에는 데이터 구성과 학습 파이프라인이 아직 공개 예정으로 적혀 있다. 현시점에서 가장 정확한 설명은 “오픈 평가 코드를 갖춘 오픈 웨이트”다.

Iris에 API가 있나?

모델은 SGLang 또는 vLLM을 이용해 OpenAI 호환 엔드포인트 뒤에서 서빙할 수 있다. 두 모델 카드 모두 호스팅 Hugging Face 추론 제공업체나 공식 관리형 Iris API를 나열하지 않는다.

어떤 Iris 모델을 사용해야 하나?

측정한 워크로드에서 Iris-pro의 추가 벤치마크 성능이 꼭 필요하고, 팀이 적합한 멀티 노드 또는 대규모 노드 인프라를 이미 보유한 경우가 아니라면 평가에는 Iris-mini를 사용하라.

다음 단계: 고정된 하니스로 mini를 파일럿하라

Iris-mini를 내려받고 공식 도구 및 파서 프로토콜을 유지한 뒤, 목표 워크로드와 비슷한 소수의 질문으로 벤치마크를 실행하라. 모델을 비교하기 전에 컨텍스트 정책부터 고정해야 한다. discard-all이나 retry를 바꾸는 것만으로도 모델 교체보다 점수가 더 크게 움직일 수 있기 때문이다.

파일럿에서 배포 부담을 감수할 만한 품질 격차가 확인될 때만 Iris-pro로 넘어가면 된다. 남아 있는 트레이드오프는 명확하다. Iris는 오픈 웨이트 검색 모델로서 이례적으로 강한 성능을 보고하지만, 재현 가능한 학습 세부 정보와 프로덕션 비용 근거는 아직 उपलब्ध하지 않다.