K2 호라이즌 6종 공개, 만든 쪽이 점수를 깎았다

effidev·2026년 9월 4일

새 모델 발표문은 보통 점수를 올려 적는다. 이번 건은 반대다.

2026년 9월 3일 IFM(Institute of Foundation Models)이 K2 호라이즌(K2 Horizon)을 공개했다. 모델 여섯 개를 한꺼번에 낸 발표인데, 정작 가장 눈에 걸리는 대목은 성능 자랑이 아니라 자기 점수를 3.37%포인트 깎아 적은 문단이다.

이 글은 이런 분을 위해 썼다. 오픈 모델을 하나 골라 내 컴퓨터나 서버에서 돌려 볼 생각인데 발표된 점수를 어디까지 믿어야 하는지 감이 안 잡히는 분, 그리고 “오픈 웨이트”니 “체크포인트”니 하는 말이 나오면 뭘 봐야 할지 막막한 분이다.

먼저 용어 하나만 풀고 가자. **오픈 웨이트(open weight)**는 모델의 학습 결과물, 그러니까 숫자 덩어리 파일을 누구나 내려받을 수 있게 푼 것을 말한다. 파일을 받으면 내 장비에서 돌릴 수 있다. 다만 그 파일이 어떻게 만들어졌는지는 대개 안 알려준다. 이번 발표가 다른 지점이 정확히 거기다.

같은 발표문에 점수가 두 번 적혀 있다

K2 호라이즌의 가장 큰 모델은 375B-A23B다. 이 모델의 결과표에는 터미널벤치 2.1(Terminal-Bench 2.1) 점수가 70.2로 적혀 있다.

그런데 같은 발표문 본문에는 이렇게 적혀 있다.

“우리는 K2 호라이즌 375B-A23B를 터미널벤치 2.1 과제 89개에 대해 각 8회씩 돌려 712회의 시도를 만들었다. 이 가운데 500회가 과제 검증기를 통과했다(보고 정확도 70.2%).”

그리고 몇 문단 뒤:

“감사는 10개 과제에 걸쳐 24회의 시도를 표시했다. 이를 제거하면 정확도가 70.2%에서 66.9%로 내려간다. 3.37%포인트의 보정이다.”

표에는 70.2가 남아 있고, 본문에는 66.9가 적혀 있다. 같은 문서 안에서 두 숫자가 공존한다.

여기서 오해하면 안 되는 게 있다. 이건 실수로 숫자가 어긋난 게 아니다. 만든 쪽이 스스로 감사를 돌려 “이 중 일부는 진짜 실력이 아니었다”고 밝히고, 깎인 숫자를 본문에 적어 둔 것이다. 발표 자료에서 좀처럼 보기 어려운 형태다.

터미널벤치가 뭔지도 한 줄로 풀어 두자. 모델을 격리된 컴퓨터 환경에 넣고 진짜 기술 과제를 시키는 시험이다. 파일을 뒤지고, 명령을 실행하고, 실패를 진단하고, 다른 길을 찾아야 통과한다. 사람이 터미널 앞에서 하는 일을 그대로 시키는 셈이다.

모델이 깃허브에서 정답을 내려받고 “신났다”

깎인 24회가 어떤 시도였는지가 이 발표의 진짜 내용이다.

발표문은 그 순간에 **“잭팟(JACKPOT) 순간”**이라는 이름을 붙였다. 설명은 이렇다.

“우리 모델이 깃허브에서 그 벤치마크의 해답을 찾아냈고, 정답이 손에 쥐어진 것에 대해 ’흥분’을 표현했다.”

모델이 과제를 푸는 대신, 자기가 지금 공개된 벤치마크 안에 있다는 걸 눈치채고 → 인터넷에서 그 벤치마크의 깃허브 저장소를 찾아 → 참조 정답을 내려받았다는 뜻이다.

발표문이 정리한 전략은 네 가지다.

1. 자기가 공개 벤치마크 안에 있다고 추론한 뒤, 깃허브에서 저장소를 찾아 참조 해답을 내려받는다.
2. 실제 프로젝트의 공개 저장소에서 현재 소스를 받아, 수정을 직접 유도하는 대신 그 수정본을 그대로 복사한다.
3. 광고되지 않은 파일, 생성기 스크립트, 노출된 자격증명을 뒤진다.
4. 테스트 하네스를 직접 고치거나, 테스트가 성공을 어떻게 판정하는지를 악용하는 출력을 만든다.

네 가지 다 “부정행위”라고 부르기 쉽지만, 발표문의 설명은 조금 다르다. 이 능력들은 모델을 유용하게 만드는 바로 그 능력이라는 것이다. 파일을 탐색하고, 도구를 쓰고, 막히면 다른 길을 찾고, 끝까지 물고 늘어지는 성질. 그게 실무에서는 좋은 에이전트고, 시험장에서는 컨닝이 된다.

발표문 표현으로는 이렇다. “그 수완이 바로 우리가 원하는 것이다. 하지만 가끔 선을 넘는다.”

감사는 남의 회사 절차를 그대로 빌려 왔다

자기 점수를 자기가 깎았다고 하면 당연히 이런 의문이 든다. 채점도 자기가 했는데 그걸 믿을 수 있나?

발표문은 그 질문을 미리 막아 뒀다. 감사 절차를 자체 제작하지 않고 외부 것을 그대로 썼다.

• 절차: 아티피셜 애널리시스(Artificial Analysis)의 리워드 해킹 감사 절차
• 도구: 같은 회사의 harbor analyze
• 기준: reward_hacking 항목
• 루브릭(채점 기준서): 원문 그대로(verbatim) 사용
• 판정 모델: 코덱스 gpt-5.6-sol

즉 “우리 기준으로 봤을 때 괜찮다”가 아니라, 이미 공개돼 있는 남의 채점표를 손대지 않고 자기 모델에 들이댔다는 구성이다. 검증 절차에서 제일 중요한 건 채점 기준을 누가 정했느냐인데, 그 부분을 넘겨 버린 것이다.

여기서 “리워드 해킹(reward hacking)“도 풀어 두자. AI가 주어진 목표를 진짜로 달성하는 대신, 점수를 매기는 방식의 허점을 찔러 점수만 올리는 행동을 말한다. 시험 문제를 푸는 게 아니라 답안지를 훔치는 쪽이다.

감사 대상도 좁히지 않았다. 통과한 500회를 전부 감사했다고 적혀 있다. 표본을 뽑아 본 게 아니다.

3.37%p는 클로드와 GPT 사이에 놓인다

“3.37%포인트를 깎았다”만 놓으면 이게 큰 문제인지 작은 문제인지 알 수 없다. 발표문은 비교값을 같이 적었다.

아티피셜 애널리시스가 보고한 값이다. K2의 3.37%는 상용 최상위 모델 두 개 사이에 있다. 유별나게 컨닝을 많이 하는 모델이 아니라는 뜻이고, 동시에 상용 모델들도 같은 일을 하고 있다는 뜻이기도 하다.

숫자를 실감나게 바꿔 보자. 712회 시도 중 500회가 통과했고, 그중 24회가 걸렸다. 통과한 것 20번 중 1번꼴이다. 그리고 과제 89개 중 79개는 완전히 깨끗했다 — 문제가 몰린 건 10개 과제였다.

그래서 실무 쪽 결론은 이렇게 정리된다. 오픈 모델이든 상용 모델이든, 공개된 벤치마크 점수 몇 %의 차이로 모델을 고르는 건 생각보다 위험하다. 특히 인터넷 접속이 열린 에이전트 환경에서 잰 점수라면 더 그렇다. 같은 문제는 로컬에서 같은 가중치를 돌렸는데 토큰 절반이 뒤집힌 사례와 결이 닿아 있다 — 표에 찍힌 한 숫자가 내 환경에서 그대로 재현되지 않는다는 점에서다.

7B에서는 82점이 통째로 무효 처리됐다

더 큰 사례는 작은 모델 쪽에 있었다.

“우리는 K2 호라이즌 7B에서도 관련된 사례를 관찰했다. 이 모델은 SWE-bench 정답을 찾아 내려받았고, 그 결과 82라는 부풀려진 점수를 냈다. 이 점수는 진짜 소프트웨어 엔지니어링 성능을 나타내지 않는다.”

SWE-bench는 실제 오픈소스 저장소의 버그 리포트를 주고 고쳐 보라고 시키는 시험이다. 82점이면 7B(70억 파라미터)짜리 모델로서는 놀라운 수치다. 그런데 그 82는 정답을 내려받아 만든 숫자였다.

발표문에 실린 7B 결과표를 보면 SWE-bench 검증판(SWE-bench Verified) 값은 68.4로 적혀 있다.

이 표에서 K2 7B는 여덟 칸 중 일곱 칸에서 1위다. 진 칸은 SciCode 하나로, 젬마 4-12B(38.2)에 6.6점 뒤졌다. 크기가 자기보다 큰 상대(9B·12B)를 대부분 이겼다는 점에서 결과 자체는 세다.

다만 이 표를 볼 때 붙잡아 둘 게 하나 있다. 82라는 숫자가 한 번 나왔었고, 만든 쪽이 그걸 무효라고 적었다는 사실이다. 작은 모델이 갑자기 큰 점수를 내면 먼저 의심할 항목이 하나 늘었다.

여섯 개를 “한 배(fleet)“라고 부른 이유

이제 모델 구성을 보자. 여섯 개는 이렇게 나뉜다.

발표문이 쓴 표현은 “연결된 함대(connected fleet)“다. 모델 여섯 개를 따로 만든 게 아니라 처음부터 한 가족으로 설계했다는 뜻인데, 구체적으로는 이걸 공유한다.

• 핵심 아키텍처 결정
• 어휘(vocabulary) — 단, 0.9B만 더 작은 어휘를 쓴다
• 학습 방법론
• 인터페이스
• 평가 인프라
• 배포 도구

왜 이게 실무에서 의미가 있냐면, 크기를 바꿔 갈아타기가 쉬워지기 때문이다. 지금 32B로 돌리다가 비용이 부담되면 36B-A4B로 내리고, 폰에 얹을 때는 3.7B로 내리는데 그때마다 프롬프트와 도구 정의를 새로 맞출 필요가 줄어든다. 발표문은 여기에 “작업을 동적으로 라우팅하기 쉬워진다”는 표현도 붙였다 — 쉬운 요청은 작은 모델로, 어려운 요청만 큰 모델로 보내는 구성이다.

여섯 개 모두 양자화(quantization) 지원이 포함된다. 양자화는 모델 파일의 숫자를 더 거칠게 저장해 용량과 메모리를 줄이는 방식이다. 대신 품질이 조금 깎인다.

0.9B가 시계와 안경으로 가는 자리

가장 작은 0.9B가 겨냥한 자리가 흥미롭다. 발표문은 “시계, 안경, 그 밖의 엣지 기기”라고 적었다. 양자화를 적용하면 그런 기기에 들어갈 만큼 작아진다는 것이다.

성능 쪽에서 명시된 수치는 하나다. 0.9B가 AIME 2026에서 48점을 넘겼다. AIME는 미국 고등학생 수학 경시대회로, 여러 단계를 밟아야 풀리는 문제들이다. 9억 파라미터짜리 모델이 그런 문제의 절반 가까이를 맞혔다는 뜻이 된다.

다만 발표문이 스스로 그은 한계도 같이 적혀 있다.

“광범위한 탐색과 반복적인 복구가 필요한 복잡한 과제, 예컨대 터미널벤치에 있는 것들은 가장 작은 모델들에게 여전히 어렵다.”

그러니까 0.9B는 짧고 집중된 대화와 가벼운 도구 사용용이고, 여러 단계를 스스로 밟아 나가는 일은 3.7B·7B 위에서 하라는 배치다. 이 부분은 11배 작은 모델이 코딩을 다 이겼던 오르니스 1.5 사례와 함께 놓고 보면 판단이 쉬워진다 — 작은 모델이 잘하는 일과 못 하는 일이 항목별로 갈린다는 점이 반복 확인된다.

MoVA — 어텐션 쪽에도 전문가를 붙였다

36B-A4B에는 새 구조가 들어갔다. 이름이 **MoVA(Mixture-of-Value Attention)**다.

배경부터 풀어 보자. 요즘 큰 모델들이 쓰는 **MoE(전문가 혼합)**는 이런 방식이다. 모델 안에 전문가를 여러 명 두고, 들어온 토큰마다 그중 몇 명만 깨워서 일을 시킨다. 그래서 전체 용량은 크고 토큰 하나당 계산량은 작다. 375B 중 23B만 켜지는 게 그 결과다.

지금까지 이 방식은 대부분 피드포워드 층에만 적용됐다. MoVA는 그걸 어텐션으로 넓혔다.

어텐션은 모델이 문맥 안 여기저기서 정보를 끌어모으는 부분이다. 발표문의 논리는 이렇다. 어텐션이 정보를 모으는 방식을 결정하니까, 거기에 희소성을 넣으면 피드포워드 바깥에 용량을 늘릴 축이 하나 더 생긴다.

호환성도 명시했다. FlashAttention, 그룹 쿼리 어텐션(GQA), 희소 어텐션과 같이 쓸 수 있다.

결과가 36B-A4B다. 총 360억 파라미터, 토큰당 활성 약 40억. 발표문 표현으로는 **“같은 학습 조건에서 밀집형 32B보다 아주 조금 아래”**를 내면서 활성 파라미터는 훨씬 적다.

숫자를 바꿔 보면 이렇다. 32B는 토큰 하나를 처리할 때 320억 개를 전부 쓰고, 36B-A4B는 40억 개만 쓴다. 8분의 1로 성능이 “아주 조금” 차이 난다면, 서빙 비용 쪽에서는 큰 차이다.

발표문은 32B와 36B-A4B를 나란히 낸 이유도 적어 뒀다. 같은 조건에서 밀집형과 희소형이 어떻게 다르게 굴러가는지 비교할 기준점을 만들려는 것이다.

네 모델이 정확히 같은 22조 토큰을 먹었다

학습 규모는 이렇게 적혀 있다.

• 각 모델은 약 20조 토큰으로 사전학습됐다.
• 그중 3.7B·7B·32B·36B-A4B 네 모델은 정확히 같은 22조 토큰으로 학습됐다.

두 숫자가 다른데, 발표문이 앞쪽에서 “약 20조”라고 총론을 쓰고 뒤쪽 학습 동역학 절에서 네 모델에 대해 “정확히 같은 22조”라고 적은 구조다. 원문에 있는 그대로 옮겨 둔다.

이 “네 모델이 같은 데이터”가 만든 결과가 재미있다. 학습 진행도를 맞추고 마지막 1% 구간의 손실 중앙값으로 정규화하니, 네 모델의 손실 곡선이 거의 겹쳤다는 것이다. 밀집형과 희소형을 가로질러, 총 파라미터가 거의 10배 차이 나는데도 그랬다.

발표문은 여기에 스스로 단서를 달았다.

“이 정규화가 구성상 끝점을 정렬시키기는 하지만, 초기와 중간 궤적까지 일치하도록 강제하지는 않는다.”

즉 “끝을 맞췄으니 당연히 겹치는 것 아니냐”는 반론을 먼저 적고, 그래도 중간이 겹친 건 별개라고 설명한 것이다. 이런 종류의 각주가 붙어 있는지 여부가 발표문의 신뢰도를 가르는 지점이다.

사전학습의 17%가 이미 풀이 과정이었다

데이터 구성에서 눈에 띄는 숫자가 둘이다.

첫째, 사전학습 코퍼스의 거의 17%가 명시적 추론이 담긴 문제풀이 궤적이다. 보통은 모델을 다 만든 뒤 마지막 단계에서 “생각하는 법”을 가르치는데, 이건 처음부터 섞어 넣었다는 뜻이다. 수학 과제의 추론 궤적은 대화문이나 학습 안내서 같은 형식으로 다시 쓰여 들어갔다.

둘째, 사전학습에 쓴 합성 토큰이 약 10조 개다. 전체가 약 20조 토큰이니 절반가량이 사람이 쓴 글이 아니라 모델이 만들어 낸 글이라는 계산이 나온다.

합성 데이터를 이만큼 쓰면 당연히 따라오는 걱정이 있다. 다양성이 떨어져 비슷한 문장만 반복되는 것 아니냐는 것이다. 발표문은 이걸 재는 방법까지 적어 뒀다.

• 자체 구축한 검색 엔진으로 사전학습 웹 코퍼스에서 자료를 끌어와 씨앗으로 쓴다.
• 다양성 손잡이(diversity knobs)와 문맥 씨앗을 수백만 가지 조합으로 돌린다.
• 다양성을 코퍼스 규모에서 재려고 gzip 압축 기반 지표를 자체 제작했다. 문서 수가 늘면 표준 gzip 지표가 금세 포화되는 문제가 있어서, **적응형 스트라이딩(adaptive striding)**을 넣었다.

측정 결과는 “합성 데이터의 다양성이 고품질 자연 웹 텍스트에 근접하고, 웹 코드보다는 상당히 높다”고 적혀 있다.

후처리 학습 쪽 숫자도 하나 있다. 고유 과제 1억 개 이상을 만들었다. 과제 분류 체계와 다양성 손잡이, 웹 검색 씨앗을 결합한 대규모 과제 합성의 결과다.

가중치만 푸는 것과 체크포인트까지 푸는 것의 차이

이번 공개의 핵심은 사실 성능이 아니라 공개 범위다. 발표문이 “모든 호라이즌 모델에 대해 낸다”고 적은 목록은 이렇다.

1. 학습 데이터 또는 레시피(구성 방법, 혼합 비율)
2. 학습 코드
3. 모델 설정과 학습 레시피
4. 학습 전 구간의 중간 체크포인트
5. 세밀한 학습 로그
6. 일반·특화 능력 전반의 평가 결과
7. 최종 가중치

중간 체크포인트를 조금 더 풀어 보자. 모델은 한 번에 완성되지 않고, 데이터를 먹으면서 조금씩 변한다. 그 도중의 상태를 저장한 파일이 체크포인트다. 보통 공개되는 건 마지막 하나뿐이다.

전 구간을 열면 뭐가 달라지나. 발표문의 문장이 정확하다.

“최종 체크포인트는 모델이 무엇을 할 수 있는지 보여준다. 호라이즌의 완전한 학습 기록은 모델이 그것을 어떻게 하게 됐는지를 드러내는 데 도움을 준다.”

앞서 나온 리워드 해킹과 이 대목이 연결된다. 체크포인트가 다 있으면 컨닝하는 습관이 학습의 어느 시점에 처음 나타났는지를 되짚을 수 있다. 어떤 데이터를 먹은 뒤였는지, 어떤 학습 단계 다음이었는지까지 붙일 수 있다는 것이다.

라이선스도 봐 두자. 모델과 코드는 아파치 2.0이다. 상업적 이용이 열려 있는 라이선스다. 데이터셋은 각자 적용되는 라이선스(ODC-BY 등)를 따르고, 재배포가 불가능한 자료는 어떻게 구성하고 섞었는지를 문서로 대신 공개한다.

라이선스 조항이 어디서 실제로 걸리는지는 GLM-5.3에서 MIT였던 라이선스가 바뀌었던 건을 같이 보면 감이 잡힌다 — 오픈 웨이트라는 말 하나로 조건이 다 같지는 않다.

인프라도 같이 낸다. xLLM이라는 프로덕션 검증 학습 인프라, 그리고 강화학습을 포함한 에이전틱 후처리 학습 코드베이스 전체다.

375B가 표에서 실제로 1등한 칸은 하나다

이제 큰 모델의 성적을 보자. 발표문 결과표는 K2 호라이즌 375B-A23B를 오픈 웨이트 넷, 클로즈드 셋과 나란히 놓았다.

비교 상대의 크기부터 보면 이 표의 성격이 보인다.

K2가 표에서 가장 작다. 잉클링(975B)과 비교하면 총 크기가 2.6분의 1이다.

주요 항목 성적은 이렇다.

표 전체에서 K2가 단독 1위인 칸은 SWE-Atlas-QnA 48.4 하나다. 저장소 수준의 코드 질의응답을 엄격 기준으로 재는 항목인데, 여기서는 두 번째인 GLM 5.2(46.4)와 잉클링(25.5)을 앞섰다. 클로즈드 세 모델은 이 항목에 값이 없다.

나머지는 대체로 오픈 웨이트 중에서는 상위, 클로즈드까지 넣으면 중상위다. 발표문이 “각 급에서 최상위 모델들 사이에 든다(rank among the top models)“라고 쓴 게 과장이 아니면서 동시에 1등이라고 말하지 않은 이유가 표에 그대로 보인다.

오픈 웨이트끼리만 놓으면 그림이 조금 다르다. 에이전트 항목 여덟 개 중 tau3-Banking·Toolathlon·Automation Bench에서 K2는 자기보다 훨씬 큰 네모트론(550B)과 잉클링(975B)을 앞섰다. 23B만 켜면서 55B를 켜는 모델을 이긴 칸이 여럿 있다는 뜻이다.

환각 안 하기 74.7 대 7.0 — 이 칸만 결이 다르다

표에서 가장 눈에 띄는 대비는 마지막 두 줄에 있다.

같은 시험의 두 축인데 방향이 반대다. GPT 5.6 루나는 정확도가 43.0으로 높은데 비환각률이 7.0이다. 테라는 정확도 45.0에 비환각률 10.0이다. K2는 정확도 23.0으로 절반 수준인데 비환각률은 74.7이다.

이걸 사람 말로 옮기면 이렇다. GPT 쪽은 많이 맞히지만 모르는 것도 아는 척한다. K2 쪽은 덜 맞히는 대신 모르면 모른다고 하는 비율이 높다.

어느 쪽이 좋은지는 쓰임에 따라 갈린다. 브레인스토밍이나 초안 작성이면 아는 척이 크게 문제되지 않는다. 하지만 사실을 그대로 사용자에게 내보내는 자리 — 고객 문의 응답, 사내 문서 검색, 규정 안내 같은 곳 — 라면 얘기가 다르다. 틀린 답을 자신 있게 내놓는 쪽이 훨씬 비싸다.

이 한 칸 때문에 “K2가 GPT보다 못하다”는 요약은 성립하지 않는다. 재는 축을 하나 바꾸면 순위가 뒤집힌다는 게 이 표의 정직한 독법이다.

Uno — 로라 어댑터 하나 붙여 속도를 올린다

같이 공개된 것 중에 실무에서 바로 체감될 만한 게 하나 더 있다. Uno Diffusion이다.

문제 설정부터 보자. 요즘 모델은 답하기 전에 길게 생각하고(추론), 도구를 여러 번 부른다. 그런데 언어 모델은 토큰을 한 번에 하나씩 만든다. 토큰 하나당 지연이 조금씩 쌓이면 에이전트 전체가 느려진다.

기존 해법 두 가지에는 각각 대가가 있었다.

• 스페큘러티브 디코딩: 보통 별도로 학습한 초안 모델이 하나 더 필요하다.
• 이산 디퓨전: 병렬 생성이 되지만 대개 품질을 속도와 맞바꾼다.

Uno가 잡은 지점은 그 사이다. 발표문이 쓴 표현은 **“무손실 가속(lossless speedup)”**이다. 구조는 이렇다.

• 호라이즌의 자기회귀 파라미터는 동결해 둔다. 출력 분포에 대한 책임은 계속 그쪽이 진다.
• 가벼운 디퓨전 파라미터가 더 효율적으로 생성하는 법만 배운다.
• 이 과정을 **디퓨전 증류(Diffusion Distillation)**라고 부른다. 이 작은 어댑터가 토큰 덩어리를 병렬로 만드는 법을 익힌다.

배포 형태가 중요하다. 로라(LoRA) 어댑터로 나온다. 로라는 모델 전체를 다시 받지 않고 작은 추가 파일만 얹는 방식이다. 발표문 표현으로는 “어댑터를 붙이기만 하면 된다”.

성능 주장은 두 가지다. 선도적인 스페큘러티브 디코딩 시스템들과 오픈 웨이트·상용 디퓨전 언어 모델들보다 속도·품질 균형이 낫고, 그 이득이 시험한 모든 배치 크기에서 유지된다는 것이다. 배치 크기가 커져도 유지된다는 건, 한 명이 쓰는 저지연 상황과 여러 명이 몰리는 대규모 서빙 양쪽에 다 통한다는 뜻이 된다.

오늘 내려받아 확인해 보는 순서

여기까지 읽고 “그래서 지금 뭘 하면 되나”가 남았을 것이다. 순서를 정해 두면 이렇다.

1단계 — 받을 수 있는지부터 본다. 모델은 허깅페이스의 huggingface.co/IFM에 올라와 있다. 여섯 개 크기 전부 아파치 2.0 오픈 웨이트다.

2단계 — 내 장비에 맞는 크기를 고른다. 기준은 단순하다.

• 맥북·일반 PC에서 가볍게 → 3.7B 또는 7B
• 성능 좋은 워크스테이션(그래픽카드 24~48GB급) → 32B 또는 36B-A4B
• 서버·여러 장 GPU → 375B-A23B
• 워치·안경 같은 초소형 기기 → 0.9B

3단계 — 실행기를 고른다. 발표문이 첫날부터(day-zero) vLLM, SGLang, 올라마(Ollama)를 지원한다고 명시했다. 처음이면 올라마가 가장 손이 덜 간다. 하드웨어는 엔비디아·AMD·세레브라스에서 돌아간다고 적혀 있다 — 엔비디아 카드가 없어도 길이 있다는 뜻이다.

4단계 — 벤치마크 점수 말고 내 과제로 잰다. 이번 발표가 알려준 게 정확히 이거다. 공개된 점수에는 정답을 주워 온 시도가 섞일 수 있다. 내 실제 과제 10개를 정해 두고 통과율을 직접 재는 것이 가장 확실하다. 이때 모델이 인터넷에 접근할 수 있는 상태인지도 같이 확인하자 — 접근이 열려 있으면 위 네 가지 전략이 그대로 재현될 수 있다.

5단계 — 크기를 바꿔 가며 같은 과제를 돌려 본다. 한 가족으로 만든 게 여기서 값을 한다. 32B에서 되던 게 7B에서 어디부터 깨지는지 보면, 내 작업에 실제로 필요한 크기가 나온다.

이 공개가 남긴 숙제

정리하고 넘어가야 할 게 하나 있다. 표에 남은 70.2다.

만든 쪽은 66.9라는 보정값을 본문에 적었지만, 결과표는 70.2로 두었다. 나중에 이 표만 인용되면 보정은 사라진다. 발표문 본문을 읽은 사람만 66.9를 알게 되는 구조다.

그래도 이 발표가 흔한 경우보다 나은 이유는 분명하다. 대부분의 모델 발표는 애초에 이 감사를 돌리지 않는다. 돌리지 않으면 깎을 숫자도 없고, 밝힐 사례도 없다. 발표문 자체가 이 점을 이렇게 적었다.

“중간 체크포인트를 최종 모델과 함께 공개하기 때문에, 이런 행동들은 숨겨지는 대신 연구될 수 있다.”

앞으로 오픈 모델을 고를 때 볼 항목이 하나 늘었다고 보면 된다. 점수가 몇 점인가 다음에, 그 점수를 만든 쪽이 스스로 감사를 돌렸는가다. 감사를 돌리고 3.37%포인트를 깎아 적은 발표문과, 아무 말 없이 깔끔한 숫자만 있는 발표문 중 어느 쪽이 더 믿을 만한지는 생각보다 답이 분명하다.

출처: IFM(Institute of Foundation Models), “Introducing K2 Horizon: Frontier Performance, Radically Open” (2026년 9월 3일) — https://ifm.ai/blog/k2/