링크된 보고서에 훨씬 자세한 내용이 있음: https://ai.meta.com/static-resource/muse-spark-1-1-evaluatio...
Terminal-Bench-2.1 세부사항을 보면 “공식 저장소의 Terminal-Bench 2.1 작업 89개를 bash 도구 전용 에이전트 하네스로 평가했고, 리소스는 CPU 6코어와 RAM 8GB로 제한했다”고 되어 있는데, 이러면 결과는 실격임
각 터미널 벤치 작업에는 CPU 상한과 RAM 상한이 따로 있고, 둘 중 하나라도 넘기면 실격임. tbench-2.1 기준으로 89개 중 CPU 6코어를 허용하는 작업은 0개이고, RAM 8GB를 허용하는 작업은 8개뿐임
이런 식의 수상한 벤치마킹은, 모델의 벤치마크 성능을 높이려고 하네스를 만드는 재미를 완전히 빼앗아 감. 무엇을 해도 헤드라인의 부정확한 숫자를 이길 수 없기 때문임. 아마 그래서 이 모델이 공식 리더보드 https://www.tbench.ai/leaderboard/terminal-bench/2.1에 없는 것 같음
전 Meta 직원으로서 조금 씁쓸하지만 크게 놀랍지는 않음. PSC가 끝나고 다음으로 넘어가기 전까지는 숫자 올리기가 핵심 성과 평가 지표였음

모델이 실수로 포크 폭탄을 일으키는 경우를 빼면 왜 리소스 제한을 고려해야 하는지 모르겠음. 이 벤치마크는 터미널 사용, 특히 많은 bash 도구 호출을 이어 붙이는 능력을 보는 것이라고 생각했는데, 어떤 테스트 케이스에서 이게 중요해짐?

폐쇄형 모델의 문제가 바로 이거임. 우리가 돈 내는 대상이 더 뛰어난 기반 모델인지, 벤치마크 점수를 극대화하도록 잘 설계된 하네스인지 정확히 알 수 없음

순수하게 궁금한데, 리소스 제한이 병목이 되는 빈도는 얼마나 됨? 하네스는 여기서 무엇을 도와주나? 병렬성을 제한하거나 더 효율적인 도구를 쓰는 식인가?

요지는 이해하지만 그렇게까지 중요할지는 잘 모르겠음
harbor / tb2.1이 Docker 실행에서 사용할 수 있는 스왑을 제한했나? 예전에는 Docker 인스턴스 실행이 명세보다 더 많은 메모리를 쓸 수 있는 버그가 있었음. 원래 작업 중 일부는 스왑을 활용하지 않으면 사실상 완료가 불가능했고, Docker가 스왑에 접근하지 못하게 막으면 오라클 풀이도 통과하지 못했음
기억으로는 crack-7z-hash와 filter-js-from-html이 그 문제가 있었는데, 몇 달 동안 안 봐서 확실하진 않음

그렇게 큰 문제로는 안 보임. 어떤 제품을 평가할 때도 제품 만든 쪽의 말을 그대로 믿지는 않음. 당연히 편향이 있을 테니까. 그래서 https://artificialanalysis.ai 같은 독립 테스트가 존재하는 것임

이렇게 많은 모델을 미리보기할 시간을 어떻게 내는지 궁금함. 최근 모델 출시가 정말 정신없었는데, 가끔은 일처럼 느껴지지 않나?

Zuck은 정면 경쟁보다 모델 시장의 스포일러 역할에 더 집중하는 편이 나을지도 모름
Anthropic이나 OpenAI의 모델 매출을 따라잡을 필요 없이, 그 매출을 99% 깎아내릴 수만 있으면 됨. 프런티어 모델 개발에 몇십억 달러를 계속 쓰고, 오픈 가중치로 공개해서 코딩 모델을 범용 상품으로 만들면 됨. 여기에 잘 만든 오픈소스 기준 하네스도 필요함
이걸 할 수 있고 사업적으로도 말이 되는 위치에 있는 사람은 거의 없음. 어차피 흐름은 그쪽으로 갈 가능성이 크고, 그는 그 속도를 크게 높일 수 있음. 컴파일러가 그랬듯 모델도 독점 제품에서 범용 상품으로 옮겨가길 바라야 함
Zuck이 세상에 할 수 있는 가장 좋은 일 중 하나일 수 있음

그들이 매출을 잃으면, Meta의 연산 자원은 누가 빌려 쓰게 됨?

진짜 스포일러 왕이 되려면 학습 데이터셋을 오픈소스로 공개하면 됨. 거기까지 갈지는 의심스러움

코딩 모델은 목적지가 아님. 코딩 모델은 범용 지능으로 가는 부트스트래핑 과정의 일부일 뿐임

llama로 이미 그걸 시도하지 않았나?

그가 해야 할 일은 이런 모델을 만드는 게 더 이상 그렇게 어렵지 않다는 걸 증명하는 것뿐임. 이 회사들의 해자는 프런티어 모델 구축이 정말 어렵다는 인식이기 때문임

이건 xAI Grok 4.5와 가장 직접적으로 비교할 수 있음. 둘 다 방향성은 “Haiku 가격의 Opus급 지능”에 가깝고, 이런 모델을 앱에 넣고 싶은 애플리케이션 개발자에게는 아주 큰 일임
Haiku와 Sonnet을 Grok 4.5로 바꾸는 테스트를 하고 있었는데, 이것도 한번 써볼 생각임. 특히 캐시 가격은 훨씬 쌈

캐시된 입력 가격 비율이 좋음
Grok 4.5는 $2/$6로 나왔지만, 조용히 캐시된 입력 100만 토큰당 $0.50을 받음. 이건 Opus 4.8만큼 비싼 수준임

Meta는 지금 모델을 고르는 대부분의 사람들 레이더에 없음. 정말 좋은 모델이 있다면, 경쟁사 가격에 맞추기 전에 보조금을 줘서 사용자를 확보하는 게 말이 됨

Qwen 3.7 Max보다 쌈. Grok 4.5의 $2 입력 / $6 출력에 이어, 대형 연구소들이 GLM 5.2의 압박을 느끼고 있다는 두 번째 신호임

그래도 여전히 터무니없이 비쌈. Google 검색 결과 100개에 $10을 내야 한다고 생각해보면 사실상 이게 그런 것임
출력 100만 토큰당 $1.50 넘게 쓰려는 사람이 왜 있는지 정말 모르겠음. 하물며 $15~50은 말할 것도 없음. 소비자가 실제로 사용량 기반 과금을 내는 경우가 있나?

어제까지만 해도 OpenAI와 Anthropic이 되돌릴 수 없을 정도로 앞서 있다는 분위기가 강했던 것 같은데, 이제 xAI와 Meta가 적어도 실용 모델과 경쟁 가능한 물건을 내놨고 가격도 쌈
물론 Fable, 그리고 아마 곧 나올 GPT-6까지 보면 두 선두 연구소가 앞서 있다는 이야기는 아직 유지되지만, 여론 주도층이 말하던 것처럼 완전히 끝난 게임은 아님

이제 모델은 대체로 충분히 좋아졌음. 큰 돌파구가 없다면 지금부터 중요한 건 비용뿐임

사람들이 Google이 뒤처진 것을 Anthropic과 OpenAI가 엄청 앞선 것으로 잘못 해석했음. 실제로는 Google이 Tensorflow, Angular, GCP 때처럼 뒤처진 것에 가까움

그 뉘앙스는 좀 다름 GLM 5.2에 대한 기대감은 이 전부터 이미 컸음. xAI나 Meta가 다른 방식으로 큰 차이를 만든 건 아니고, GLM 5.2와 비슷한 결과와 비슷한 가격에 가까움

개인적으로 Meta를 좋아하진 않지만, 이건 인정함. 경쟁이 많을수록 일반 소비자에게 좋고, 기업에도 좋음
중국 모델, Grok, Meta, Google, OpenAI, Anthropic이 모두 경쟁하는 건 승리라고 봄. 이런 보조금 붙은 토큰을 쓸 수 있을 때 최대한 활용하려고 미친 듯이 만들고 있음

Meta의 로컬 llama 모델은 한때 오픈소스 AI의 얼굴이었음. 판이 정말 많이 바뀌었음

확실히 좋은 일이라고 봄. 다만 이런 발전 때문에 AI 시대에 필요한 소프트웨어 엔지니어 수가 늘어날지 줄어들지는 아직 마음속에서 논쟁 중임
한편으로는 제품 만들기가 쉬워져서 더 많은 사람이 만들고, 더 많은 제품과 기능이 생길 것임. 비기술자들도 많이 만들려 하겠지만 막히게 되고, 결국 엔지니어가 필요해짐. 숙련된 기술 회사와 비기술 창업자, 예비 창업자들이 만들어낼 제품의 총량은 엄청날 것임. 가까운 미래에 더 많은 소프트웨어 엔지니어가 필요하다는 상승 시나리오는 여기 있음
반면 1년쯤 지나면 사람들이 이런 제품을 잔뜩 만들겠지만, 대부분은 마케팅하거나 팔거나 돈을 벌지 못할 것임. 결국 그렇게 많은 소프트웨어 엔지니어가 필요하지 않게 될 수도 있음. 그래도 전체적으로는 상승 시나리오가 순효과로 이길 가능성이 크다고 봄

중국 모델을 더 풀어 쓰면 DeepSeek, GLM(Z.ai), Minimax, Kimi(Moonshot), Hy3(Tencent), Qwen(Alibaba)이 있음
각각은 가중치를 내려받아 로컬 실행할 수 있음

그는 이 소식을 자기 Meta Threads가 아니라 X에 올렸음. 이걸 크게 키우려는 관심이 어느 정도인지 보여줌. 물론 이 회사들이 계속 현금을 태우는 동안 우리 입장에서는 비용이 감당 가능한 수준에 머물 수 있음

지금까지 본 것 중 가장 큰 기술 경쟁임. 가장 부유한 회사들, 가장 똑똑한 사람들, 가장 부유한 나라들이 뛰어들었음
경쟁이 좋은지는 모르겠고, 몇 년 뒤에 보게 될 것임. 오랜만에 육체노동 직업을 갖게 될 날을 기대 중임

어떻게 모든 회사가 모든 벤치마크에서 자기들이 1등처럼 보이게 만들 수 있는 거지?

먼저 직접 고른 벤치마크 묶음에서 어떤 모델들이 더 나쁜지 봄
다음으로 경쟁사 모델의 이전 버전과 비교함. 그래도 좋아 보이지 않으면 자기 이전 모델과 비교함

해자가 크지 않고, 개선은 점진적이며, 비교할 모델을 골라 담기 때문임
공정하게 말하면 주된 강점이 가격이라면 비슷한 성능대 모델과 비교하는 게 더 맞아 보임

이제 Gemini와 비교하는 건 공짜 빙고 칸 같은 느낌임

AI 쪽을 깊이 아는 사람 기준으로, 코딩에서 표준 벤치마크는 뭐라고 봐야 하나?

자기 모델이 최소 N개 벤치마크에서 앞서는 정확한 순간을 기다렸다가 발표하면 됨

Meta가 폐쇄형 가중치 모델을 개발하고 출시하고 있었다는 걸 놓쳤음. 아쉽다. 미국산 오픈 가중치 모델에서 더 많은 진전이 있으면 좋겠음

컨테이너 안에서 codex와 함께 동작하게 만들었음. 참고로 Codex:Muse 인터페이스에서 대부분 마주칠 버그가 있는 것 같음
내가 보기엔 codex가 서버 측 도구 호출을 예상하지 못했고, Meta가 그 ID들을 다루는 방식 때문에 생기는 일종의 파싱 또는 통합 오류임. codex를 muse와 처음 몇 번 실행했을 때 첫 번째 비웹검색 호출에서 실패했음
수정은 했고, 개인적으로는 맞춤형 서버 측 도구 호출과 무기한 파일 저장에 아직 완전히 설득되진 않았지만, 지금까지는 꽤 멋진 모델이고 즐겁게 쓰고 있음 https://github.com/accretional/awesome-muse-spark/blob/main/...

공개된 벤치마크를 보면 코딩과 멀티모달도 꽤 좋지만, 도구 호출 성공률이 매우 좋은 것 같음
이런 성능 형태에 가장 잘 맞는 사용 사례는 뭘까?

디버깅과 진단은 도구 호출이 매우 많음. 로그를 grep하거나 변환하고, 프로파일러나 추적기를 호출하고, 사고 보고서를 작성하는 일까지 포함됨
버그 진단은 코딩을 어느 정도 하면서도 도구 활용을 더 잘해야 하는 영역임. 좋은 진단 보고서가 있으면 수정은 Opus에 넘기면 됨
Opus도 보고서를 어느 정도 쓰지만, typst 문서에서 여전히 표 너비를 자주 틀려서 마지막 열에 텍스트가 가득 차는데 폭은 몇 글자밖에 안 되는 일이 생김

Gemini 3.5 Flash는 도구 호출에서 Fable보다 나음. 도구 호출은 아마 사후 학습으로 비교적 쉽게 개선할 수 있는 영역 중 하나일 것임

앞으로 새 릴리스마다 이런 패턴을 보게 될지 궁금함. 도구 사용은 빠르게 바뀔 가능성이 커서, 가장 지능적인 모델보다 가장 최신 모델이 항상 우위를 가질 수도 있음

이건 좀 쓸모없게 들림. JSON 같은 제약된 디코더 성능이 뛰어난 건 흥미롭지만, 일반 디코더에서 도구 검증기를 거치고 좋은 오류 메시지를 받은 뒤 다시 시도하는 루프는 거의 항상 두 번째 시도에서 도구를 작동시킬 수 있음. 입력은 캐시되니 비용도 비싸지 않음