TL;DR

Ornith-1.0-35B에서 Fine-tune한 35B 에이전트형 모델로, execution-gated 코퍼스를 사용해 실제로 실행·검증된 코드 경로만 학습에 남긴 점이 핵심 설계입니다. 이 처리 방식과 긴 컨텍스트(262144 native), 추론과 콘텐츠를 분리하는 파이프라인 연동으로 도구 호출과 코드 문제 해결 능력이 향상되어 BFCL v4(AST) 73.5%를 기록했고 LiveCodeBench v6에서 전체 66.1%를 보였습니다. 운영상으로는 reasoning을 별도 필드로 분리하고 출력 토큰 예산을 충분히 확보해야 하며, vLLM의 --reasoning-parser=qwen3 또는 llama.cpp의 --reasoning-format=deepseek 같은 설정을 통해 사고 누적을 막아야 합니다.

핵심 포인트

• 도구 호출 성능이 향상되어 BFCL v4 (AST)에서 73.5%를 기록했고, 같은 하니스·디코딩 조건에서 기반 모델 Ornith-1.0-35B의 69.2%보다 4.3 포인트 높은 수치를 보였습니다. 실행이 검증된 코드 경로만 학습 데이터로 유지한 execution-gated 접근법이 도구 호출과 실제 실행을 필요로 하는 작업에서 성능을 끌어올리는 핵심 처리 방식입니다. 이 때문에 도구 사용 시 더 신뢰가능한 호출·응답 흐름을 기대할 수 있습니다.
• 코드 문제 해결 능력이 강해 LiveCodeBench v6에서 전체 66.1%를 달성했고, 난도별로는 easy 99.1%, medium 86.7%, hard 60.5%를 보입니다. 라이브 코드 벤치에서 하드 문제가 집합의 45%를 차지해 전체 점수를 끌어내리는 주된 요인이 되었고, 출력 토큰 예산에 민감하여 16K에서 32K로 확장할 때 점수가 60.9%에서 66.1%로 상승했습니다. 따라서 긴 해답 생성이 요구되는 문제에선 출력 예산을 충분히 배정해야 최적 결과를 얻을 수 있습니다.
• 긴 컨텍스트 지원과 에이전트 워크플로 최적화가 설계 목표로, 네이티브 컨텍스트 길이가 262144 토큰이며 추론과 콘텐츠를 분리하는 파이프라인 처리를 권장합니다. vLLM에서는 reasoning-parser=qwen3, llama.cpp에서는 --reasoning-format deepseek 같은 설정을 통해 추론(체크·생각)과 최종 출력(발화)을 분리해야 사고 누적을 막을 수 있습니다. 이 처리 방식은 반복적 에이전트 대화에서 reasoning이 누적되어 불필요한 반복이나 비효율을 초래하는 문제를 예방합니다.

제한사항

벤치마크