오픈 웨이트 AI, 100만 토큰 읽고 자기 도구까지 만들기 시작함

이번 주 흐름은 ‘길게 읽고, 깊게 풀고, 도구까지 만든다’임

• 허깅페이스 트렌딩 모델 쪽에서 이번 주 눈에 띈 건 세 가지임

  • 바이두의 언리미티드-OCR은 긴 PDF와 문서 OCR 병목을 겨냥함
  • 지푸AI의 GLM-5.2는 100만 토큰 컨텍스트를 내세운 오픈 웨이트 플래그십임
  • 딥리인포스의 오니스 1.0은 코딩 에이전트가 자기 작업 도구까지 설계한다는 쪽으로 치고 나옴

• 공통점도 꽤 선명함

  • 모두 오픈소스 또는 오픈 웨이트 흐름에 있고, 기사 기준으로 지역 제한 없는 MIT 라이선스가 반복해서 등장함
  • 성능 경쟁의 축이 단순 파라미터 수가 아니라 긴 컨텍스트, KV 캐시 관리, 에이전트 작업 구조로 이동 중임

바이두 언리미티드-OCR

• 언리미티드-OCR은 이름 그대로 긴 문서를 한 번에 읽는 OCR을 노림

  • 바이두가 6월 22일 공개한 30억 파라미터 모델
  • 딥시크-OCR을 기반으로 하고, 디코더 어텐션을 레퍼런스 슬라이딩 윈도우 어텐션(R-SWA)으로 교체함
  • 목표는 결과 텍스트가 길어질수록 KV 캐시가 커져 속도가 떨어지는 문제를 잡는 것

• 숫자로 보면 포인트가 더 분명함

  • 최대 3만2000토큰 범위 안에서 수십 페이지 PDF를 단 한 번의 연산으로 받아쓰는 구조를 강조함
  • 모델 크기는 약 6.8GB 수준이라, 배포 관점에서도 아주 비현실적인 덩치는 아님
  • vLLM, SGLang, 올라마, 라마.cpp, 트랜스포머스에서 돌릴 수 있다고 소개됨

• 다만 아직은 벤더 설명을 그대로 믿기엔 빈칸이 있음

  • 공개 시점에 정량 벤치마크, 학습 데이터, 지원 언어 범위가 자세히 나오지 않음
  • 긴 문서 처리 구조는 흥미롭지만, 실제 정확도는 독립 평가가 나와야 판단 가능함

GLM-5.2

• GLM-5.2는 ‘오픈 웨이트도 프런티어 근처까지 간다’는 메시지를 정면으로 미는 모델임

  • 중국 지푸AI가 내놓은 플래그십이고, 시리즈 최초로 100만 토큰 컨텍스트를 안정적으로 지원한다고 소개됨
  • 총 744B급 전문가 혼합(MoE) 구조지만, 추론 때는 일부 전문가만 활성화되는 방식임

• 핵심 구조는 인덱스셰어(IndexShare)임

  • 네 겹의 희소 어텐션 층이 하나의 색인을 공유하도록 설계함
  • 기사 기준 100만 토큰 길이에서 토큰당 연산량(FLOPs)을 2.9배 줄였다고 함
  • 추측 디코딩용 MTP 층 개선으로 처리 효율도 최대 20% 끌어올렸다고 소개됨

• 코딩 벤치마크 수치도 공격적임

  • 지푸AI 자체 발표 기준 딥SWE에서 46.2%로 오픈 웨이트 최고점을 기록했다고 함
  • 장기 과제 벤치마크 프런티어SWE에서는 앤트로픽 옵스 4.8에 1%p 뒤지고 GPT-5.5를 앞섰다고 주장함
  • 단, 이건 자체 발표라 독립 평가 전까지는 ‘흥미로운 주장’으로 보는 게 맞음

오니스 1.0

• 오니스 1.0은 코딩 에이전트 쪽에서 꽤 재밌는 방향을 보여줌

  • 딥리인포스가 6월 25일 공개한 에이전트 코딩 전용 모델 패밀리
  • 9B, 31B, 35B(MoE), 397B(MoE) 네 가지 크기로 나옴
  • 큐원 3.5와 젬마 4를 기반으로 후처리 학습했다고 소개됨

• 차별점은 문제만 푸는 게 아니라 ‘문제 풀 도구’까지 스스로 설계한다는 점임

  • 보통 코딩 에이전트는 사람이 만든 하네스나 스캐폴드 안에서 움직임
  • 오니스는 강화학습 과정에서 자기 하네스를 직접 설계하도록 학습했다는 게 핵심
  • 그래서 문제 풀이 능력과 작업 골격 설계를 같이 최적화한다는 방향임

• 성능 주장도 작지 않음

  • 9B 모델이 터미널-벤치 2.1에서 43.1점, SWE-벤치 버라이파이드에서 69.4점을 기록했다고 함
  • 4비트 양자화 시 6~8GB VRAM 소비자용 GPU에서도 돌아간다고 소개됨
  • 397B 플래그십은 터미널-벤치 2.1에서 77.5점, SWE-벤치 버라이파이드에서 82.4점을 기록했다고 함
  • 컨텍스트는 26만2000토큰

• 자기 도구를 만드는 모델은 리워드 해킹 위험도 같이 커짐

  • 오니스는 고정 신뢰 경계, 결정론적 감시자, 동결된 LLM 심판이라는 3중 장치를 둔다고 설명됨
  • 가중치가 MIT로 풀린 만큼 안전장치를 제거한 파생본이 나올 수 있다는 점도 기사에서 경고함

개발자에게 남는 포인트

• 긴 컨텍스트는 이제 데모용 자랑거리가 아니라 문서 자동화와 코드베이스 분석의 실무 조건이 되고 있음

  • 계약서, 보고서, 논문, 기술 매뉴얼처럼 통째로 읽어야 의미가 있는 업무가 직접적인 수혜 대상임
  • 대규모 코드베이스 리팩터링이나 장시간 자율 코딩 태스크도 같은 흐름 위에 있음

• 오픈 웨이트와 MIT 라이선스가 프런티어 근처까지 올라오면 한국 기업에도 선택지가 늘어남

  • 데이터를 외부 API로 보내지 않고 자체 호스팅하는 구성이 더 현실적이 됨
  • 엔비디아 밖 배포 사례나 화웨이 어센드 계열 지원처럼 하드웨어 선택지도 같이 넓어지는 흐름임

---

기술 맥락

• 이번 기사에서 가장 중요한 선택은 긴 컨텍스트를 어떻게 싸게 유지하느냐예요. 100만 토큰을 읽는다고 말하는 건 쉬운데, 실제로는 KV 캐시가 커지면서 메모리와 지연시간이 같이 터지거든요.

• 바이두의 R-SWA는 오래된 정보를 전부 들고 있지 않고 필요한 범위를 중심으로 보는 쪽이에요. OCR처럼 긴 문서를 순서대로 읽는 작업에서는 이 방식이 메모리를 일정하게 묶는 데 유리해요.

• GLM-5.2의 IndexShare는 여러 희소 어텐션 층이 색인을 공유하게 해서 중복 계산을 줄이는 선택이에요. 100만 토큰 길이에서 토큰당 연산량을 2.9배 줄였다는 주장이 중요한 이유가 여기에 있어요.

• 오니스 1.0의 자기 스캐폴딩은 코딩 에이전트 운영 방식 자체를 건드려요. 사람이 만든 고정된 작업틀을 쓰는 대신 모델이 문제에 맞는 도구와 절차를 만들면 더 유연해질 수 있지만, 동시에 리워드 해킹 감시가 필수가 돼요.

• 한국 기업 입장에서는 성능표보다 라이선스와 배포 통제가 더 현실적인 의사결정 포인트예요. MIT 오픈 웨이트라면 자체 호스팅과 커스터마이징이 쉬워지지만, 공식 가중치인지 안전장치가 유지됐는지 확인해야 운영 리스크를 줄일 수 있어요.