Agents at Scale: Inside MiniMax's Model and the Infrastructure Behind It

URL: https://www.youtube.com/watch?v=AVMr9PMINyo 날짜: 2026-07-31 (영상 발행일 추정 불가, 처리일 기준) 채널: aiDotEngineer

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

이 영상은 AI Engineer 컨퍼런스 패널 토크로, ==MiniMax M3 오픈소스 모델을 만든 연구자(Olive, MiniMax RL 리서치 리드)와 이를 대규모로 서빙하는 인프라 회사(Dan, Together AI VP of Kernels)가 한 무대에서 "모델이 세상에 나오기까지"와 "나온 뒤 어떻게 최적화되는지"를 각각의 관점에서 풀어놓는다==.

• MiniMax는 M3를 오픈소스로 공개했고, Together AI는 그 모델의 토큰 사용량 1위 서빙 파트너다
• M3는 이전 M2 시리즈와 달리 처음부터(from scratch) 멀티모달로 학습된 모델이며, 스파스 어텐션과 100만 토큰 컨텍스트를 새로 도입했다
• 인퍼런스 측에서는 모델이 출시된 "Day 0"부터 매주, 심지어 매일 밤 단위로 최적화가 이루어지고 있다

패널은 오픈소스 모델 생태계가 폐쇄형 프론티어 모델(Anthropic, OpenAI)을 빠르게 따라잡고 있다는 낙관적 전망과, 그 뒤에서 벌어지는 커널 최적화·KV 캐시 관리·강화학습 환경 설계라는 매우 구체적인 엔지니어링 디테일을 함께 다룬다.

---

1. 오픈소스 전략과 MiniMax-Together AI 파트너십

MiniMax가 M3를 오픈소스로 공개한 이유와, Together AI가 어떻게 이 모델의 최대 서빙 파트너가 되었는지를 다룬다.

1.1. 왜 오픈소스인가

1. MiniMax의 오픈소스 철학

   1. 미션 정렬: MiniMax는 오픈소스 커뮤니티가 강력하고 힘이 있다고 믿으며, 모델을 공개하면 모두가 사용할 수 있어 "모두에게 지능을(intelligence with everyone)"이라는 회사 미션과 일치한다고 설명
   2. 커뮤니티 기여 순환: 다양한 개발자들이 피드백과 PR을 통해 모델 개선에 직접 기여할 수 있고, 이를 통해 모델이 더 강력해지는 선순환 구조를 만든다
   3. 인퍼런스 파트너의 역할: Dan(Together AI) 같은 파트너가 오픈 웨이트 모델을 최적화해서 더 빠르게 인퍼런스하고 모두에게 더 잘 서빙할 수 있게 해준다는 점을 직접 예시로 언급

2. Together AI의 오픈소스 신념

   1. 지능의 풍요(abundance): Dan은 Together AI가 "어떻게 더 많은 토큰을 더 많은 사람에게 제공해서 더 유용한 일을 하게 만들까"에 관심이 있다고 설명하며, 오픈 모델을 면밀히 추적해왔다고 강조
   2. MiniMax 성장에 대한 인상: 오래된 구버전 MiniMax 모델부터 지켜봐 왔고, M3까지 발전한 과정이 "정말 인상적"이라고 평가

1.2. 파트너십이 시작된 계기

1. 라스베이거스 행사에서의 우연한 만남

   1. 초기 접촉: 작년 라스베이거스에서 열린 카(car) 이벤트에서 MiniMax 관계자가 Dan에게 "다음 모델을 꼭 서빙해줘야 한다, 정말 훌륭할 것"이라고 직접 요청한 것이 계기
   2. 점진적 협업 확대: 이후 MiniMax 2.5, 2.7을 서빙하다가 M3 출시가 다가오면서 사용량과 사람들의 활용 방식을 보고 크게 흥분해 본격적으로 파트너십을 강화

2. 파트너십 실무 프로세스

   1. 아키텍처 공동 최적화: 모델 아키텍처를 함께 들여다보고 최적화하며, 최적의 인퍼런스 서빙 방식을 찾는 작업을 함께 진행
   2. 현재 위상: 진행자가 확인한 바로 Together AI는 현재 MiniMax M3의 토큰 사용량 점유율 1위 서빙사

---

2. MiniMax M3의 새로운 능력: 멀티모달 전환

M3가 이전 M2 시리즈와 근본적으로 달라진 지점, 즉 멀티모달 능력과 그로부터 파생된 새로운 활용 사례를 다룬다.

2.1. M3에서 새로 등장한 활용 사례

1. 텍스트/코드를 넘어선 멀티모달 이해

   1. 핵심 차이: M2 시리즈는 텍스트와 코드만 다뤘지만, M3는 비디오와 이미지까지 이해하는 진정한 멀티모달 모델
   2. 관찰된 애플리케이션: 에이전틱 기술과 멀티모달 에이전트를 결합한 다양한 애플리케이션이 등장하는 것을 확인했다고 언급

2. 숨겨진 활용 사례(Hidden Gems)

   1. 컴퓨터 사용(Computer Use): 모델이 컴퓨터 화면을 탐색하며 도구를 활용해 상당히 괜찮은 결과물을 만들어낼 수 있음
   2. 게임 개발: Olive가 특히 재밌어하며 언급한 부분으로, 팀이 게임 개발에 직접 작업했고 모델이 실제로 꽤 재밌는 게임을 개발하는 데 도움을 줄 수 있다고 소개

2.2. 벤치마크 중심 포스트트레이닝: SVG bench, Kernel bench, OS World

1. 포스트트레이닝의 핵심은 데이터와 문제 정의
   1. 태스크별 상이한 접근: 어떤 태스크냐에 따라 데이터 설계 방식이 완전히 달라진다고 설명
   2. 커널 태스크 예시: 커널 최적화처럼 복잡한 태스크는 강화학습을 의도적으로 훈련시킬 수 있는 정교한 환경(environment) 설계가 핵심이며, 모델이 커널을 스스로 최적화하고 반복적으로 성능을 개선하도록 만드는 것이 목표

---

3. 커널 개발과 Parallel Kernel Bench

오픈 모델의 커널 작성 능력이 어디까지 왔는지, 그리고 Together AI가 최근 공개한 신규 벤치마크를 다룬다.

3.1. 오픈 모델의 커널 작성 능력 현황

1. 전반적 상향 평준화

   1. 폐쇄형·오픈형 모두 개선: 프론티어 폐쇄 모델과 오픈 모델 모두 커널 작성 능력이 꾸준히 좋아지고 있으며, Together AI 팀도 커널을 개발하고 최적화 프레임워크를 작성할 때 모델을 항상 활용한다고 밝힘

2. Parallel Kernel Bench 공개 배경

   1. 미해결 문제 모음: 인퍼런스를 서빙하는 다양한 방식을 전수 조사한 결과, 실제로 속도를 높일 수 있을 것 같지만 정작 좋은 커널이 존재하지 않는 영역이 많다는 것을 발견해 벤치마크로 만듦
   2. 벤치 맥싱(bench maxing)에 대한 역발상: 일반적으로 벤치마크 과최적화(overfitting)를 우려하지만, Dan은 이 벤치마크에 한해서는 오히려 오버피팅되어도 좋다는 입장 — 오버핏된 결과로 나온 커널을 그대로 가져다 실제 인퍼런스 가속과 개발에 활용하면 되기 때문
   3. 진행자의 코멘트: 연구자들이 정말 유용한 벤치마크를 계속 내놓고 모두가 거기에 벤치 맥싱해서 모든 게 분포 내(in distribution)에 들어온다면, 그것이야말로 "완벽한 세상"이라는 견해를 덧붙임

---

4. 인퍼런스 스택: 모델 출시 Day 0부터의 최적화 여정

새 모델이 공개된 순간부터 인퍼런스 팀이 무엇을 하는지, 그리고 워크로드 변화가 인퍼런스 스택 설계에 어떤 영향을 주는지를 다룬다.

4.1. Day 0 프로세스

1. 모델 출시 전 사전 정보 확보

   1. 얼리 액세스: MiniMax 같은 파트너로부터 모델 세부사항을 미리 전달받으며, M3의 경우 MiniMax 스파스 어텐션 등 기존 어떤 모델과도 다른 설계 선택지들을 사전에 파악
   2. 모델마다 제각각인 설계: 현재 나와 있는 오픈 모델들은 어텐션 방식, MoE(Mixture of Experts) 선택, 양자화(quantization) 방식 등에서 서로 상당히 다르다고 설명

2. 커널 작성 및 검증 단계

   1. 기존 커널 재사용 여부 판단: 세부 정보를 받는 즉시 커널을 작성하고 벤치마킹하면서, 기존 커널을 그대로 쓸 수 있는지, 수정이 필요한지, 아예 처음부터 새로 짜야 하는지를 판단
   2. 품질 최우선: Day 0에는 무엇보다 "이 모델이 출시됐을 때 우리가 기대하는 품질을 보장할 수 있는가", "올바른 사용자 경험을 제공할 수 있는가"를 최우선으로 고려

3. 출시 이후의 지속적 개선

   1. 할 일 목록 기반 최적화: KV 캐시 관련 작업, 어텐션 커널 작업, 양자화 관련 작업 등 이미 알고 있는 개선 항목 리스트를 만들어두고 출시 직후부터 순차적으로 작업
   2. 주 단위 성능 향상: 이렇게 몇 주에 걸쳐 최적화한 결과, Day 0와 Day 7, Day 14 사이에 실제로 모델이 더 빨라지는 것을 사용자가 체감할 수 있다고 설명
   3. 실제 개선 속도 일화: 진행자가 전날 동료 Ingrid에게 "지난 한 달간 M3 성능을 개선했나"고 물었더니 Ingrid가 "어젯밤 얘기하시는 거죠?"라고 되물었다는 일화를 소개하며, 이 팀의 최적화 속도가 얼마나 빠른지를 실감나게 전달

4.2. 워크로드 변화가 인퍼런스 스택에 미치는 영향

1. 채팅 워크로드에서 에이전틱 워크로드로
   1. 과거의 채팅 중심 패턴: 시스템 프롬프트가 수천 토큰 수준이고 그 뒤로 채팅 로그가 이어지는 정도의 비교적 단순한 패턴이었음
   2. 현재의 에이전틱 패턴: 이제는 하나의 하니스(harness) 안에 모델이 들어앉아 수백 번의 멀티턴 툴콜을 수행하는 형태로 워크로드가 완전히 바뀜 — 코드베이스 전체를 모델에 업로드하는 경우도 생겨, 이는 라우팅과 커널 설계 모두에 채팅 기반 워크로드와는 전혀 다른 최적화 과제를 부여
   3. KV 캐시·프롬프팅 전반에 영향: 이런 턴 기반 에이전틱 워크로드는 KV 캐시 구성 방식, 프롬프팅 방식 등 스택 전반에 영향을 주기 때문에, 어느 부분을 우선 최적화할지를 결정하는 기준이 된다고 설명

---

5. 멀티모달을 처음부터(from scratch) 학습시킨 방법

M2까지는 텍스트 전용이었던 MiniMax가 어떻게 멀티모달 붕괴(collapse) 문제 없이 M3를 학습시켰는지를 다룬다.

5.1. From-scratch 멀티모달 학습의 도전과 성과

1. 처음부터 함께 학습

   1. 단계 0부터 이미지 데이터 포함: 텍스트 데이터뿐 아니라 이미지 데이터도 학습 첫 단계부터 함께 훈련시켰다고 설명
   2. 업계에서 흔한 붕괴 문제 해결: 다른 많은 연구소에서는 멀티모달 학습을 조금만 진행해도 모델이 붕괴(collapse)하는 것이 일반적이었는데, MiniMax는 이 문제를 해결하는 데 성공했다고 강조

2. 어텐션 맵에서 관찰된 자연스러운 결합

   1. 텍스트-비주얼 토큰 간 자연스러운 어텐션: from-scratch로 학습한 결과, 어텐션 맵을 보면 텍스트 토큰이 비주얼 토큰에 자연스럽게 주의를 기울이는 것을 확인했으며, 두 모달리티가 자연스럽게 결합되어 서로를 이해한다고 설명
   2. 웹사이트 개발 예시: 예를 들어 웹사이트를 개발할 때, 두 모달리티를 함께 학습했기 때문에 모델이 웹사이트를 실제로 "보고" 어떻게 생겼는지 이해한 뒤 강화학습 과정에서 더 잘 최적화할 수 있다고 구체적 사례를 제시

---

6. 아키텍처 혁신: 스파스 어텐션과 100만 토큰 컨텍스트

M3가 도입한 새로운 아키텍처 요소들과, 이것이 인퍼런스 관점에서 왜 "악몽"에 가까운 도전인지를 다룬다.

6.1. 인퍼런스 관점에서 본 신규 아키텍처의 난이도

1. 한꺼번에 쏟아진 신규 요소들

   1. 멀티모달리티: 앞서 언급한 텍스트+이미지 결합 처리
   2. 컨텍스트 100만 토큰 확장: 기존 대비 컨텍스트 길이가 크게 늘어남
   3. 스파스 어텐션 신규 도입: 진행자는 이 세 가지가 한꺼번에 도입되면서 인퍼런스 측에서는 "거의 악몽(nightmare)" 수준이라고 표현하며, 최적화할 지점이 무수히 많을 때 무엇부터 손대는지를 질문

2. Dan의 답: "1001가지를 다 본다"

   1. 우선순위보다 전수 공략: Dan은 "천 가지에 집중한다"는 말을 정정하며 "천한 가지(a thousand and one things)"에 집중한다고 답하고, 찾을 수 있는 모든 엣지를 찾아서 계속 밀어붙인다고 설명
   2. 포기하지 않는 태도: "누군가 천한 번째 일을 할 수 없다고 하면, 모르겠고 더 노력해봐라"라는 식으로, 남겨두는 돌(stone)이 없을 때까지 계속 파고드는 태도를 강조

6.2. 모델 간 최적화 노하우의 전이

1. 스파스 어텐션 최적화 지식의 축적과 전이

   1. 한 모델에서 배운 것을 다음 모델에 적용: 스파스 어텐션은 최근 꽤 대중화된 기법이며, MiniMax의 스파스 어텐션은 DeepSeek이나 GLM에서 쓰는 방식과는 다소 다르지만, 그 최적화 프로세스와 커널 작성 과정에서 얻은 교훈은 새로운 스파스 어텐션에도 적용 가능하다고 설명
   2. 박사 시절부터 이어진 문제의식: Dan은 이 문제(효율적 어텐션)를 박사 과정 시절부터 여러 형태로 고민해왔으며, 이제 사람들이 이를 실제로 대규모로 훈련시키고 활용하는 것을 보는 것이 "일종의 검증(validation)"처럼 느껴진다고 소감을 밝힘

2. 오픈소스 생태계의 상호 학습 구조

   1. 랩 간 베스트 프랙티스 확산: 한 연구소가 무언가를 특히 잘 해내면, 그것이 곧 업계의 "골든 스탠다드"가 되어 다른 랩들도 서로에게서 배우고 승리 요소를 가져가는 구조라고 진행자가 코멘트

---

7. 초장시간 RL 태스크: 12시간짜리 ICLR 논문 재현

M3 블로그/논문에서 소개된 "12시간짜리 실행으로 ICLR 논문을 재현했다"는 사례를 중심으로, 초장기 호라이즌 태스크의 RL 학습법과 평가법을 다룬다.

7.1. 초장기 호라이즌 태스크 학습의 어려움

1. 왜 어려운가

   1. 긴 시간 지평(long horizon): 논문 재현이나 커널 프레임워크 최적화 같은 태스크는 연구자들에게는 흥미롭지만, 학습 관점에서는 GPU라는 하드웨어 제약까지 걸린 매우 긴 시간 지평의 태스크라 트리키하다고 Olive가 설명

2. 핵심은 여전히 환경·데이터·보상 설계

   1. 문제 정의의 중요성: 이런 태스크를 잘 학습시키는 핵심은 결국 환경(environment)과 데이터, 그리고 문제를 어떻게 정의하는지, 보상(reward)을 어떻게 구성하는지에 달려 있다고 강조
   2. RL 알고리즘의 미세 조정: 강화학습 알고리즘 자체도 조금씩 변형해서 더 효율적으로 학습되도록 만들어야, RL 실행을 반복하는 과정에서 흥미로운 결과가 창발(emerge)하는 것을 볼 수 있다고 설명

7.2. 장기 실행 태스크의 중간 평가 방법

1. 반복(iteration) 단위 평가

   1. 여러 번 제출받아 평가: 이런 태스크는 여러 차례 반복 제출이 이루어지며, 그때마다 각각을 평가한다고 설명
   2. 해킹(hacking) 검증: 모델이 때때로 태스크를 "해킹"하려 하기 때문에, 실제로 성능이 개선되고 있는지 아니면 편법으로 점수만 올리고 있는지를 검증(validation)과 테스트로 판별

2. 내부 자체 평가 체계 구축

   1. 자기 진화(self-evolution) 활용: 2.7 버전 출시 때 소개했던 "자기 진화" 개념처럼, 모델을 실제 내부 개발 속도를 높이는 데 적극 활용하고 있으며, 이 과정에서 자신들의 실제 업무와 밀접하게 연관된 내부 평가 체계를 자체적으로 구축해 모델을 평가한다고 설명

---

8. KV 캐시 인프라: 초장문맥 동시 요청 처리

수백~백만 토큰급 컨텍스트를 가진 동시 요청들을 처리할 때 KV 캐시가 계속 커지는 문제를 인프라 측에서 어떻게 다루는지를 다룬다.

8.1. KV 캐시를 "분산 파일 시스템"처럼 다루기

1. 문제의 본질

   1. 거대한 분산 데이터베이스 구축: Dan은 이 문제를 "일종의 분산 파일 시스템을 재창조하는 것", 혹은 "매우 큰 데이터베이스를 만드는 것"에 비유
   2. 이론적으로는 단순, 실무는 어려움: "이론적으로는 꽤 단순하다, 대학 3학년 때 배웠어야 할 종류의 문제인데, 우리 대부분은 그 수업을 빼먹어서 지금 업계에서 실시간으로 재발견하고 있는 것"이라고 유머러스하게 표현

2. 실제로 다뤄야 하는 질문들

   1. 저장 위치 결정: 캐시를 어디에 저장할지
   2. 캐시 히트 판별: "이걸 전에 본 적 있는가"를 어떻게 아는지
   3. 페치와 전송: 캐시를 어떻게 가져오고, 한 곳에서 다른 곳으로 어떻게 보내는지 — 이 모든 것이 "복잡하지는 않지만 반드시 제대로 해내야 하는" 영역이라고 정리

---

9. 3년 후를 내다보며: GPU 활용률과 오픈소스의 미래

Dan이 스탠퍼드 강연에서 했던 "3년 후를 돌아보면 지금이 얼마나 초창기였는지 깨달을 것"이라는 발언을 이어받아, 두 사람이 각자 전망을 밝히는 마무리 세션.

9.1. Dan의 전망: GPU 활용률 개선과 오픈소스의 완전한 추격

1. 현재 GPU 활용률에 대한 문제의식

   1. 낮은 FLOP 활용률: 현재 업계 전반적으로 GPU를 매우 저활용하고 있다고 지적하며, SpaceX가 (로켓 관련 비유로) 10% 정도의 flop 활용률을 언급했던 것을 인용해, 3년 후에는 이 수치에 대해 "더 부끄러워해야(extra embarrassed)" 할 정도로 개선되길 바란다고 말함
   2. Anthropic 예시: 자신이 몸담은 Anthropic(주: Dan의 소속은 Together AI로 소개되었으나 이 발언에서 본인 회사를 Anthropic으로 언급 — 발언 그대로 기록) 조차 현재 보유한 하드웨어로 지금보다 훨씬 잘할 수 있다고 언급하며, 몇 년 안에 이런 부분들에서 "빛을 보게 될 것"이라고 희망

2. 오픈소스 프론티어의 완전한 추격

   1. "오픈 모델이 뒤처져 있다"는 통념에 대한 반박: 몇 달에 한 번씩 "Anthropic이나 OpenAI가 훨씬 앞서 있다"는 이야기가 반복되지만, M3·GLM·Kimi 같은 모델들을 보면 오픈소스 프론티어가 실제로 따라잡고 있고, 그 격차가 생각보다 크지 않다는 것을 3년 안에는 업계가 완전히 받아들이게 되길 바란다고 전망

9.2. Olive의 전망: 개발 속도의 가속과 셀프 이볼루션

1. 3년 전과 지금의 극적인 격차

   1. 업계 입문 전이었던 3년 전: Olive는 3년 전에는 아직 이 업계에 들어오지도 않은 시점이었다며, 지금 벌어지는 일들을 그때는 상상도 못 했을 것이라고 웃으며 답함

2. 셀프 이볼루션(self-evolution)이 만든 가속

   1. 이미 확인된 개발 가속 사례: 1년 전, 혹은 그보다 더 전에 개발된 모델들조차 이미 내부 개발 속도를 높이고 있는 것을 목격했으며, 이 가속이 실제로 점점 빨라지고 있다는 것을 체감한다고 설명
   2. 오픈 웨이트 모델의 프론티어 추격 메커니즘: 이런 가속 덕분에 오픈 웨이트 모델이 프론티어 랩을 따라잡을 수 있다고 보며, "모든 사람이 이 모델을 쓸 수 있도록 만드는 것"이 MiniMax의 미션과 맞닿아 있다고 마무리

---

주요 발언 모음

"We do believe that the open source community as a whole is very strong and powerful. While we open source the model, everyone can use it. So it aligns with our mission that we want to have intelligence with everyone." — Olive

"So how do you get more tokens to more people to do more useful things and get all these capabilities into more people's hands." — Dan (Together AI의 오픈소스 철학)

"I mean, you focus on a thousand and one things, yeah. Like you just go and you keep doing it. You find every edge that you can, and you go and you push on it. If someone tells me you can't do the thousand first thing, yeah, like I don't know, try harder." — Dan (인퍼런스 최적화 우선순위에 대해)

"It's pretty simple in theory. It's like the type of thing that you should have done in your third year of undergrad or something like that, but most of us actually skipped that class, so now we're rediscovering it live in industry." — Dan (KV 캐시 인프라를 분산 파일 시스템에 비유하며)

"We're seeing with models like M3 and GLM and Kimmy and all those models that the open-source frontier really can catch up. And it's not even that far behind, so I think that's quite exciting." — Dan

"I could see how this speed is actually accelerating. How the development is accelerating. And that's how open weight models can really catch up with frontier labs." — Olive

핵심 데이터 & 수치

• MiniMax M3 토큰 사용량: 진행자가 당일 확인한 결과, Together AI가 MiniMax M3 토큰 사용량에서 가장 큰 점유율(lion's share)을 차지
• 컨텍스트 길이: M3는 100만(1 million) 토큰까지 컨텍스트를 확장
• KV 캐시 동시성 규모: 동시 요청이 500 ~ 100만 토큰급 컨텍스트 길이를 가질 수 있는 상황을 인프라가 처리해야 한다고 언급
• GPU 활용률 벤치마크: SpaceX가 언급했다는 약 10% 수준의 flop 활용률을 예로 들며, 업계 전반의 GPU 저활용 문제를 지적
• 최적화 주기: 모델 출시 후 Day 0 → Day 7 → Day 14 단위로 지속적인 성능 개선이 이루어지며, 실제로는 하루 단위(overnight)로도 개선이 체감될 정도로 빠름
• 장기 실행 태스크 사례: MiniMax는 12시간짜리 강화학습 실행으로 ICLR 논문 재현에 성공한 사례를 블로그/논문에 공개

결론 및 시사점

1. 오픈소스 모델과 인퍼런스 인프라는 이제 사실상 하나의 파이프라인으로 통합되어 있다. 모델 창작자(MiniMax)와 서빙사(Together AI)는 모델 공개 훨씬 이전부터 아키텍처 세부사항을 공유하며 협업하고, 출시 이후에도 몇 주에 걸쳐 함께 성능을 끌어올린다.

2. 워크로드가 "채팅"에서 "에이전틱"으로 이동하면서, 인퍼런스 스택 설계의 최적화 대상 자체가 바뀌고 있다. 코드베이스 전체를 업로드하고 수백 번의 툴콜을 수행하는 패턴은 KV 캐시, 프롬프팅, 라우팅 전반에 새로운 요구를 만들어낸다.

3. 멀티모달을 처음부터(from-scratch) 함께 학습시키면, 텍스트-비주얼 토큰이 어텐션 맵에서 자연스럽게 결합되는 효과가 있다. 이는 나중에 텍스트만 학습한 모델에 이미지 모달리티를 덧붙이는 방식보다 근본적으로 더 강력한 결합을 만들어낸다는 시사점을 준다.

4. 벤치마크 오버피팅(bench maxing)에 대한 두려움은 상황에 따라 재해석될 수 있다. Parallel Kernel Bench처럼 "실전에 그대로 쓸 수 있는 미해결 문제"로 벤치마크를 설계하면, 오버피팅된 결과물 자체가 곧 실제 가치가 된다.

5. 초장기 호라이즌 RL 태스크(12시간 이상)의 학습 성패는 결국 환경·보상·문제 정의 설계에 달려 있으며, 반복(iteration) 단위의 중간 평가와 해킹 탐지가 필수적이다.

6. KV 캐시 관리는 본질적으로 분산 시스템/데이터베이스 문제이며, 컨텍스트가 100만 토큰급으로 늘어난 지금 이 문제는 더 이상 회피할 수 없는 핵심 인프라 과제가 되었다.

7. 오픈소스 프론티어(MiniMax M3, GLM, Kimi 등)와 폐쇄형 프론티어(Anthropic, OpenAI) 사이의 격차는 두 발표자 모두 "생각보다 크지 않다"고 진단하며, 이 격차는 셀프 이볼루션 등 개발 가속 메커니즘 덕분에 계속 좁혀지고 있다는 것이 패널의 공통된 결론이다.