IFM K2 Horizon 공개, 0.9B부터 375B까지 여섯 개 Apache 2.0 모델을 한 번에 내놓은 이유

노시욱 (Patrick Rho) · AI 연구 해설

IFM Releases K2 Horizon: Six Apache 2.0 Models From 0.9B to 375B는 MBZUAI가 2025년 5월에 출범시킨 프론티어 랩 IFM이 공개한 모델 함대 이야기입니다. 이번 발표는 0.9B부터 375B까지 여섯 개 모델을 Apache 2.0 라이선스로 풀고 프리트레이닝 코퍼스까지 함께 내놓겠다는 주장 하나로 요약됩니다. 원문 링크는 제목 아래에 걸려 있습니다.

일반적인 오픈 모델 발표는 체크포인트 하나와 벤치마크 표 하나로 끝납니다. K2 Horizon은 그 문법을 따르지 않았습니다. 모델 여섯 개, 그리고 학습에 쓰인 코퍼스까지 함께 공개한다는 점에서 이 발표는 처음부터 다른 종류의 질문을 던집니다. 제가 이 소식을 보고 열어본 이유도 거기에 있습니다. 숫자보다 구성이 궁금했습니다.

이 발표를 그냥 넘기지 않은 이유

저는 모델 발표를 볼 때 파라미터 숫자부터 보지 않으려고 합니다. 숫자는 기억하기 쉽지만 설명해주는 바가 적기 때문입니다. 대신 누가, 왜, 어떤 묶음으로 내놓았는지를 먼저 봅니다. IFM은 MBZUAI가 세운 프론티어 랩이고 K2 Horizon이 사실상 첫 대규모 공개 행보에 가깝습니다. 첫 행보에서 단일 플래그십이 아니라 여섯 개 규모를 한 번에 내놓았다는 선택이 눈에 밟혔습니다.

제가 이 발표에서 흥미롭게 본 부분은 규모 사이의 간격입니다. 0.9B, 3.7B, 7B, 32B, 그리고 MoE로 보이는 36B-A4B와 375B-A23B가 한 줄에 놓여 있습니다. 온디바이스에서 실험할 수 있는 크기부터 데이터센터급 크기까지 스펙트럼 전체를 덮습니다. 이런 배치는 우연히 나오지 않습니다. 처음부터 여러 배포 지점을 염두에 두고 학습 파이프라인을 짰다는 신호에 가깝습니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 공급된 자료만으로는 각 모델의 학습 데이터 혼합 비율이나 평가 성적을 단정할 수 없습니다. 제가 가진 것은 모델 목록과 라이선스, 코퍼스 동봉 사실과 출범 시점 정도입니다. 그래서 이 글은 성능 순위를 매기는 글이 아닙니다. 공개 구성 자체가 무엇을 뜻하는지, 엔지니어와 연구자에게 어떤 선택지를 주는지 따라가 보겠습니다.

체크포인트 하나가 아니라 함대를 내놓는다는 것

대부분의 오픈 모델 발표는 하나의 체크포인트와 벤치마크 표로 이루어집니다. 그 형식은 비교하기 편하지만 감추는 것도 많습니다. 어떤 규모에서 동작하는지, 작은 규모로 내리면 무엇이 깨지는지, 학습 파이프라인이 여러 크기를 감당하는지는 표 하나에서 잘 드러나지 않습니다.

함대 공개는 그 빈 곳을 직접 건드립니다. 여섯 개 규모를 동시에 내놓으면 연구자는 규모에 따른 거동을 바로 비교할 수 있습니다. 같은 계열 안에서 0.9B가 이해하는 것과 32B가 이해하는 것이 어떻게 다른지, 어디에서 능력의 계단이 나타나는지 손으로 확인할 수 있습니다. 논문 속 그래프가 아니라 자신의 프롬프트와 자신의 데이터로 확인할 수 있다는 점이 다릅니다.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 이 여섯 개가 정말 같은 레시피에서 나온 것인지, 아니면 이름만 묶인 별개 모델인지 말입니다. 학습 코퍼스와 학습 절차가 공유될 때 함대 비교는 의미를 가집니다. 절차가 다르면 크기 비교는 크기 비교가 아니라 레시피 비교가 됩니다. K2 Horizon이 코퍼스를 함께 푼다고 밝힌 대목이 그래서 눈길을 끕니다. 비교의 전제를 검증할 재료까지 주겠다는 뜻으로 읽히기 때문입니다.

모델 이름에 이미 답이 들어 있다

모델 목록을 다시 적어보겠습니다. 375B-A23B, 36B-A4B, 32B, 7B, 3.7B, 0.9B입니다. 앞에서 두 개 이름에 붙은 A23B와 A4B는 활성 파라미터를 가리키는 표기로 보입니다. 전체 파라미터 중 추론 한 스텝에서 실제로 계산에 참여하는 양이 23B와 4B라는 뜻입니다. 이런 표기는 Mixture of Experts 구조에서 흔히 씁니다.

이 구분은 처음 접하면 헷갈리지만 실제로 써보면 바로 감이 옵니다. 전체 파라미터는 모델이 기억할 수 있는 지식의 그릇 크기에 가깝고, 활성 파라미터는 토큰 하나를 처리할 때 드는 계산 비용에 가깝습니다. 375B라는 숫자에 놀라기 전에 물어야 할 것은 메모리에는 얼마가 올라가는지, 연산에는 얼마가 도는지입니다. A23B라는 꼬리표는 그 질문에 대한 답을 이름 안에 미리 넣어둔 셈입니다.

저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. MoE는 적은 계산으로 큰 기억을 쓰는 교환 관계입니다. 기억은 크게 가져가되 매번 다 깨우지 않는 방식입니다. 그 대신 라우팅이라는 새로운 일이 생깁니다. 어떤 전문가에게 토큰을 보낼지 고르는 과정이 매 층마다 돌아갑니다. 이 선택이 잘 되면 효율이 오르고, 어긋나면 일부 전문가에게만 일이 몰리면서 학습이 불안해집니다. 이름 속 23B와 4B는 이런 구조적 선택의 흔적입니다.

Apache 2.0이라는 선택이 바꾸는 풍경

여섯 개 모델이 전부 Apache 2.0으로 나왔다는 점은 이번 발표에서 가장 분명한 문장입니다. 오픈 가중치 발표에서 라이선스는 늘 따라다니는 별첨처럼 보이지만, 막상 제품을 만드는 쪽에서는 라이선스가 설계 제약이 됩니다. 상업적 이용이 가능한지, 수정물을 다시 배포할 때 어떤 의무가 붙는지, 특허 관련 조항은 어떻게 되는지가 바로 일정과 법무 검토로 연결됩니다.

Apache 2.0은 실무자가 익숙하게 다루는 permissive 라이선스입니다. 연구용으로만 만져볼 수 있는 공개와 달리 상업적 제품 안에 넣고 수정하고 재배포하는 흐름을 폭넓게 허용합니다. 그래서 이 선택은 읽는 층을 넓힙니다. 논문을 읽는 사람뿐 아니라 실제 서비스에 올려볼 사람이 독자가 됩니다. 스타트업이 프로토타입에 얹어보고, 기업이 내부 평가 파이프라인에 넣어보고, 에지 디바이스 업체가 작은 규모부터 올려보는 그림이 자연스럽게 이어집니다.

다만 라이선스가 풀렸다고 해서 운영 부담까지 풀리는 것은 아닙니다. 큰 모델을 누군가에게 넘긴다고 그 조직이 바로 서빙할 수 있는 것은 아닙니다. GPU 메모리와 대역폭, 양자화와 분산 서빙 같은 현실적인 장벽은 그대로 남습니다. 라이선스는 문을 여는 일이고, 문 뒤의 계단을 오르는 일은 각 조직의 몫입니다. K2 Horizon이 여러 규모를 함께 내놓은 이유도 여기에 겹쳐 보입니다. 문을 연 뒤 각자 설 수 있는 계단을 고르게 하려는 배치입니다.

가중치 옆에 코퍼스를 함께 둔다는 것의 무게

이번 발표에서 저를 멈춰 세운 문장은 프리트레이닝 코퍼스까지 함께 내놓는다는 대목이었습니다. 가중치 공개는 결과물을 주는 일이고, 코퍼스 공개는 과정을 여는 일입니다. 무엇으로 학습했는지 알 수 있으면 데이터 혼합과 필터링, 중복 제거와 품질 관리 같은 질문을 남의 말이 아니라 자신의 손으로 검증할 수 있습니다.

연구자 입장에서 코퍼스는 재현 가능성의 출발점입니다. 어떤 도메인이 강하고 어디가 비어 있는지 알면 실패를 해석할 언어가 생깁니다. 특정 언어에서 성능이 낮을 때 모델 구조 문제인지 데이터 분포 문제인지 가설을 세울 수 있습니다. 안전성이나 편향 문제를 다룰 때도 학습 데이터의 구성을 모르면 논의가 공중에 뜹니다. 코퍼스가 있으면 논의가 땅에 내려옵니다.

저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 코퍼스 공개는 그 습관과 잘 맞습니다. 숫자를 받아 적는 대신 데이터라는 재료를 직접 만져보게 하기 때문입니다. 물론 코퍼스가 있다고 해서 학습 전체를 다시 돌릴 수 있는 것은 아닙니다. 대규모 학습에 드는 계산 비용은 여전히 큽니다. 그럼에도 구성을 아는 것과 모르는 것 사이에는 해석의 깊이에서 큰 차이가 생깁니다.

작은 모델이 큰 모델의 축소판이 아닌 이유

0.9B와 3.7B 같은 작은 규모를 보면 큰 모델을 가볍게 줄인 버전이라고 생각하기 쉽습니다. 표면적으로 보면 단순합니다. 실제로는 그렇지 않습니다. 작은 모델은 큰 모델과 사는 곳이 다릅니다. 노트북과 휴대폰, 브라우저와 에지 서버 같은 자원이 빠듯한 환경에서 직접 뜁니다. 거기서는 지연 시간과 메모리 상한이 곧 제품 성패가 됩니다.

작은 규모가 함대 안에 있다는 것은 실험의 진입 장벽이 낮다는 뜻입니다. 375B를 직접 올리기 어려운 팀도 0.9B나 3.7B로 파이프라인을 먼저 맞춰볼 수 있습니다. 프롬프트 형식과 평가 harness를 작은 규모에서 다듬은 뒤 큰 규모로 옮기는 단계적 접근이 가능해집니다. 실패 비용이 작은 곳에서 먼저 실패해보는 셈입니다. 이 순서는 실무에서 꽤 소중합니다.

반대로 7B와 32B 같은 중간 규모는 단일 GPU나 소규모 노드에서 다뤄볼 만한 지점에 놓입니다. 파인튜닝과 정렬 학습, 도메인 적응 같은 작업이 주로 이 구간에서 일어납니다. 중간 규모가 같은 계열로 묶여 있으면 작은 규모에서 검증한 아이디어를 중간 규모에서 키우고, 중간 규모에서 다듬은 것을 큰 규모 추론과 비교하는 흐름이 매끄럽워집니다. 함대라는 말이 어울리는 지점입니다. 각 배가 다른 바다를 맡되 같은 깃발 아래 움직이는 모습에 가깝습니다.

숫자가 아니라 구조를 봐야 하는 이유

모델 발표가 나오면 으레 벤치마크 표부터 찾습니다. 저도 표를 봅니다. 다만 표를 결론이 아니라 질문 목록으로 읽으려고 합니다. 어떤 작업에서 올랐는지, 어떤 작업에서는 그대로인지, 평가 조건이 공정한지가 표보다 중요합니다. K2 Horizon처럼 규모가 여섯 개인 경우라면 규모별 곡선의 모양이 단일 점수보다 많은 것을 말해줍니다.

예를 들어 작은 규모에서 풀리지 않던 종류의 작업이 특정 규모를 넘어 풀리기 시작한다면, 그 지점은 구조와 학습이 맞물린 곳일 가능성이 큽니다. 반대로 규모를 키워도 그대로인 작업이 있다면 데이터나 학습 목표 쪽을 의심해볼 수 있습니다. 이런 해석은 점수표 하나로는 할 수 없고, 여러 규모를 같은 눈으로 볼 때 가능합니다. 함대 공개가 평가 읽기를 바꾸는 지점이 여기 있습니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 규모별 비교가 의미를 가지려면 평가 harness와 프롬프트, 샘플링 조건이 같아야 합니다. 조건이 다르면 크기 효과인지 설정 효과인지 알 수 없습니다. 그래서 저는 앞으로 커뮤니티에서 나올 재현 보고를 눈여겨보고 싶습니다. 같은 계열 여섯 개를 같은 조건에서 돌린 결과가 쌓이면, 발표문의 문장보다 그 곡선이 더 많은 것을 말해줄 것입니다.

서빙대에서 벌어지는 진짜 계산

좋은 건 알겠는데, 이걸 실제로 어떻게 서빙할까요. 이 질문 앞에서 MoE 표기는 다시 읽힙니다. 375B 전체를 메모리에 올려야 한다는 사실과 토큰당 23B 정도가 계산에 참여한다는 사실은 서로 다른 제약을 겁니다. 메모리는 전체 크기가, 속도와 비용은 활성 크기가 좌우하는 쪽에 가깁니다. 두 숫자를 함께 보지 않으면 견적이 어긋납니다.

MoE 서빙에서 자주 걸리는 부분은 전문가 가중치를 어떻게 메모리에 두고 어떻게 가져오는지입니다. 모든 전문가를 GPU 메모리에 상주시키면 속도는 빠르지만 메모리 부담이 큽니다. 필요할 때 가져오면 메모리는 아끼지만 대역폭과 지연 시간이 늘어납니다. 배치 크기와 동시 요청 수, 시퀀스 길이에 따라 유리한 지점이 달라집니다. 36B-A4B 같은 중간 MoE는 이 교환 관계를 시험해보기 좋은 크기입니다. 큰 MoE로 가기 전에 라우팅과 배치, 캐시 전략을 다듬을 수 있습니다.

Dense 구조로 보이는 32B, 7B, 3.7B, 0.9B는 계산이 더 직관적입니다. 올라가는 메모리와 토큰당 연산량이 비교적 단순하게 어림됩니다. 양자화와 증류, 추론 엔진 최적화 같은 익숙한 도구가 그대로 먹힙니다. 그래서 함대 전체를 놓고 보면 선택지가 층층이 생깁니다. 실시간 응답이 필요한 곳에는 작은 dense를, 품질 상한을 확인해야 하는 곳에는 큰 MoE를, 둘 사이를 메워야 하는 곳에는 중간 규모를 두는 식입니다. 단일 모델 발표에서는 잘 보이지 않던 배치 설계가 함대 발표에서는 자연스럽게 따라옵니다.

한 줄 요약이 놓치는 부분

이 발표를 한 줄로 줄이면 여섯 개 오픈 모델이 나왔다는 말이 됩니다. 틀린 말은 아닙니다. 그런데 그 문장은 발표의 성격을 반쯤 지웁니다. 이번에 나온 것은 점수표가 아니라 선택지의 묶음이고, 묶음과 함께 검증 재료까지 내주었다는 점이 성격을 규정합니다. 점수만 보면 크고 작은 모델이 한 줄로 서지만, 선택지로 보면 각자 서 있는 자리가 다릅니다.

또 하나 놓치기 쉬운 부분은 출범 시점입니다. IFM은 2025년 5월에 MBZUAI가 출범시킨 프론티어 랩으로 소개되어 있습니다. 신생 조직의 첫 대형 공개는 기술 발표이자 조직의 일하는 방식에 대한 선언에 가깝습니다. 무엇을 우선하는지, 연구 공동체와 어떤 관계로 일하고 싶은지가 공개 구성에 드러납니다. 코퍼스까지 함께 푸는 선택은 닫힌 성과 과시보다 열린 검증에 무게를 둔 행보로 읽힙니다.

제가 앞으로 보고 싶은 것은 이 선언이 이어지는 방식입니다. 함대가 한 번 나오고 마는 행사인지, 학습 레시피와 평가 harness, 후속 개선이 계속 공유되는 흐름인지가 중요합니다. 오픈 공개의 가치는 첫날의 숫자가 아니라 몇 달 뒤에 쌓이는 재현과 파생 작업에서 판가름 나는 경우가 많습니다. 0.9B로 시작한 누군가가 32B로 키우고, 36B-A4B에서 라우팅 거동을 파헤친 보고가 쌓일 때 함대의 의미가 완성됩니다.

함대가 남기는 질문들

어떤 발표든 남는 질문이 진짜 내용입니다. K2 Horizon을 두고 제가 적어둔 질문은 크게 네 갈래입니다. 첫째, 여섯 개 규모가 어느 정도까지 같은 레시피를 공유하는지입니다. 데이터 혼합과 학습 일정, 정렬 단계가 공유될 때 규모 곡선이 교과서처럼 읽힙니다. 공유 범위가 다르면 해석도 달라져야 합니다.

둘째, 두 MoE의 라우팅 설계입니다. 전문가 수와 선택 방식, 부하 균등화 장치가 어떻게 되어 있는지, 학습 후반에 라우팅이 안정화되는지가 실제 효율을 가릅니다. 이름 속 활성 파라미터 숫자는 결과 쪽 숫자이고, 과정 쪽 숫자는 따로 확인해야 합니다. 셋째, 코퍼스의 구성과 공개 범위입니다. 전체인지 일부인지, 필터링과 전처리 상태가 어떤지, 라이선스상 재사용 조건이 가중치와 같은 결의인지가 후속 연구의 폭을 정합니다.

넷째, 작은 규모의 쓰임새입니다. 0.9B와 3.7B가 어디까지 실용적인지, 어떤 작업에서 무너지는지가 빨리 공유되면 좋겠습니다. 작은 모델의 실패 지도가 그려지면 큰 모델을 써야 하는 경우와 작은 모델로 충분한 경우가 갈립니다. 이 구분이 서야 각 조직이 비용 대비 품질의 결정을 내릴 수 있습니다. 발표 하나로 답이 다 나오지 않는 질문들이지만, 묻는 방향이 분명하면 커뮤니티의 재현이 답을 모아줍니다.

다음 무게중심은 점수가 아니라 재현에 있다

정리해보면 K2 Horizon 발표는 이렇게 읽힙니다. MBZUAI의 IFM이라는 새 조직이 여섯 개 규모를 Apache 2.0으로 묶어 내놓았고, 가중치뿐 아니라 프리트레이닝 코퍼스까지 공개 범위에 넣었습니다. 목록은 375B-A23B, 36B-A4B, 32B, 7B, 3.7B, 0.9B입니다. 앞의 두 개는 활성 파라미터 표기로 볼 때 mixture of experts 구조로 읽힙니다. 전형적인 단일 체크포인트 공개와 달리 여러 배포 지점을 한 번에 겨냥한 구성입니다.

이 구성에서 제가 가져가는 생각은 하나입니다. 평가의 무게중심을 발표문의 점수에서 커뮤니티의 재현으로 옮겨야 한다는 점입니다. 여섯 개 규모와 코퍼스가 손에 들어온 이상, 각 팀은 자신의 작업과 자신의 조건에서 곡선을 직접 그릴 수 있습니다. 그 곡선이 쌓일 때 이 함대가 잘 설계된 것인지 답이 나옵니다. 저는 그 과정을 지켜보면서 작은 규모에서 다듬은 파이프라인이 큰 규모로 어떻게 이어지는지, MoE 두 종의 운영 감각이 어떻게 정리되는지를 따라가 보려고 합니다. 다음 글에서는 재현 보고가 모이는 대로 규모별 거동 차이를 좀 더 손에 잡히게 풀어보겠습니다.