K2 Horizon 모델: Apache 2.0, MoVA, 그리고 자체 호스팅 비용

0.9B부터 375B까지 6개 모델을 한꺼번에 내놓으면 배포 단계별 선택지가 완성된 것처럼 보인다. 하지만 비용 구조는 그렇게 단순하지 않다. K2 Horizon의 Apache 2.0 라이선스는 모델 라이선스 비용을 없애고, MoVA는 활성 연산량을 낮춘다. 그렇다고 스토리지, KV 캐시, 런타임, 하드웨어 비용까지 사라지는 것은 아니다.

Apache 2.0으로 공개된 K2 Horizon 6종 구성

IFM은 2026년 9월 3일 K2 Horizon을 375B-A23B, 36B-A4B, 32B, 7B, 3.7B, 0.9B로 구성된 6종 모델군으로 발표했다. 발표에 따르면 모델과 코드는 Apache 2.0으로 공개됐으며, 데이터셋에는 각각 적용되는 라이선스가 사용된다(IFM 발표).

같은 계열이지만 공개 완성도는 다르다

6개 모델의 공식 포지셔닝은 다음과 같다.

0.9B가 더 작은 어휘를 쓴다는 점을 제외하면, 이 모델군은 아키텍처와 배포 도구를 공유한다. 모델 크기 사이를 옮기거나 라우팅하는 과정을 단순화하려는 설계다(IFM 보도자료).

다만 릴리스 상태에는 중요한 차이가 있다. 공식 K2-Horizon-32B 카드에서 현재 공개된 체크포인트는 Stage1으로 표기되며, 최종 체크포인트는 아직 공개 예정이라고 명시한다. 반면 MoVA 36B-A4B와 375B-A23B 카드에서는 최종 체크포인트가 공개됐다고 설명한다. 즉, ‘6개 모델이 발표됐다’는 말은 맞지만, ‘6개 모두 동일하게 최종 프로덕션 체크포인트다’라고 보기는 어렵다(32B 모델 카드, 375B 모델 카드).

자체 호스팅 팀에 Apache 2.0이 주는 것과 주지 않는 것

Apache 2.0은 모델과 코드를 수정·재배포하고 상업 서비스에 통합할 수 있게 하며, 토큰당 라이선스 요금도 없다. 다만 IFM은 데이터셋이 ODC-BY 등 각자의 이용 조건을 따른다고 밝히고 있으며, 제한된 출처의 데이터는 직접 재배포할 수 없을 수 있다(IFM 발표).

없어지는 것은 라이선스 청구서이지 운영비가 아니다. GPU 대여료나 감가상각, 모델 스토리지, KV 캐시 용량, 런타임 엔지니어링, 모니터링, 보안 검토는 여전히 비용으로 남는다. 36B 서빙 레시피와 375B 모델 카드의 예시에는 trust_remote_code=True도 포함돼 있다.

메모리부터 계산하는 6개 모델의 현실적인 규모

파라미터 수는 모델 역량을 비교하는 데 유용하지만, 자체 호스팅에서는 원본 가중치를 저장할 메모리가 첫 번째 제약이다. 아래 추정치는 BF16에서 파라미터당 2바이트, 이상적인 4비트 표현에서 0.5바이트를 적용했다. 메타데이터, 런타임 버퍼, KV 캐시, 토크나이저 파일, 운영체제 메모리는 제외한 수치다.

\*7B 모델 카드는 이 모델을 “7B-core”라고 부르지만, Hugging Face 메타데이터에는 9B 파라미터로 표시된다. 용량 계획은 계열명만 보지 말고 실제 리포지터리 파일을 기준으로 세워야 한다(7B 모델 카드).

실제 리포지터리 파일을 보면 위 수치가 보장치가 아니라 하한선인 이유가 드러난다. 0.9B BF16 GGUF는 2.16 GB, 3.7B BF16 GGUF는 10.1 GB, 32B Stage1 BF16 GGUF는 69.6 GB, MoVA 36B BF16 GGUF는 74.9 GB로 표기돼 있다(0.9B GGUF, 3.7B GGUF, 32B GGUF, 36B GGUF).

엣지 티어: 0.9B, 3.7B, 7B

0.9B와 3.7B는 저장 공간 부담을 최소화하며, 복잡한 복구 과정을 거치는 에이전트보다는 제약된 환경의 목적형 작업에 적합하다(0.9B 모델 카드, 3.7B GGUF 카드).

처음 로컬에서 실험한다면 7B가 이 계열에서 문서화가 가장 잘 된 선택지다. 모델 카드는 추론 및 도구 호출 파서, 단일 디바이스 텐서 병렬 설정, 양자화 변형을 다룬다. 표시된 벤치마크 표에서는 SWE-bench Verified 70.6%, Terminal-Bench 2.1 39.1%, tau3-Banking 25.8%를 기록했다. 다만 모든 결과는 높은 추론 노력 설정을 사용했으며, 프로토콜 세부 사항이 달라질 수 있다고 카드에서 경고한다(7B 모델 카드).

7B 모델 카드는 높은 추론 노력과 최소 32,768 output tokens를 권장한다. 추론 길이가 길어질수록 생성 시간도 늘어나므로, 메모리에 적재되는 모델이라도 실제 경과 시간 기준으로는 비싸질 수 있다.

로컬·서버 티어: 32B와 36B-A4B

32B는 완전 Dense 모델이라 특성을 해석하기는 더 단순하다. 그러나 Stage1 상태와 공식 69.6 GB GGUF가 실제 계획에서 고려해야 할 제약이다(32B Stage1 GGUF).

MoVA 36B-A4B는 다른 질문을 던진다. 활성 연산량이 크게 낮은 모델이 더 큰 총 용량을 유지하면서 Dense 모델에 가까운 성능을 낼 수 있는가다. IFM의 GGUF 벤치마크 표에서 이 모델은 tau3-Banking 26.8%, Terminal-Bench 2.1 58.6%를 기록했고, 후자에서는 제시된 비교군을 앞선다. 다만 과학, 사실성, 장문 컨텍스트 관련 모든 지표에서 선두인 것은 아니다(36B GGUF 벤치마크 카드).

가중치가 메모리에 올라간 뒤에는 낮은 활성 파라미터 수가 지속 처리량에 도움이 될 수 있다. 다만 실제 결과는 백엔드, 배치 구성, 인터커넥트, 양자화 방식에 좌우된다.

플래그십 티어: 375B-A23B

공식 모델 카드는 K2 Horizon 375B-A23B용으로 검증된 SGLang 구성을 문서화한다. H200 GPU 8개, 텐서 병렬 8, 전문가 병렬 8, BF16, FlashAttention-3를 사용하는 구성이다(375B 모델 카드).

총 파라미터 대비 활성 파라미터 비율은 Dense 375B 모델보다 연산량을 줄일 수 있다. 하지만 약 750GB라는 BF16 계획 하한은 여전히 인프라 경계를 명확히 한다. Artificial Analysis는 표시된 분류에서 Intelligence Index 47점, 112개 중 #11을 제시하지만, 이 모델의 출력 속도와 작업당 비용은 보고하지 않는다(Artificial Analysis 프로필).

현재 문서화된 검증 프로필이 H200 8개 구성인 만큼, 이 모델은 클러스터급 배포로 보는 편이 맞다.

MoVA는 연산 경제성을 바꾸지만 저장 공간 하한은 바꾸지 않는다

MoVA는 Mixture-of-Value Attention의 약자다. 일반적인 mixture-of-experts 구조는 대체로 feed-forward 레이어에서 희소 라우팅을 수행한다. IFM은 MoVA가 FlashAttention, grouped-query attention 같은 기법과의 호환성을 유지하면서 어텐션의 value 구성 요소까지 전문가 라우팅을 확장한다고 설명한다(IFM 아키텍처 설명).

36B-A4B라는 이름이 알려주는 두 가지 숫자

“36B-A4B”에는 서로 다른 두 수치가 들어 있다. 전체 파라미터는 약 36B이고, 토큰마다 활성화되는 파라미터는 약 4B라는 뜻이다. 특히 지속적인 생성 작업에서는 활성 경로의 multiply-and-accumulate 연산과 메모리 트래픽을 줄일 수 있다.

그렇다고 선택되지 않은 전문가가 메모리에서 사라지는 것은 아니다. 공식 GGUF 파일은 BF16 기준 74.9 GB이며, vLLM 레시피는 임베딩을 포함해 37.44B 저장 파라미터, 토큰당 5.95B 활성 파라미터를 가진 모델로 설명한다. 이는 같은 아키텍처를 패키징과 회계 관점에서 달리 집계한 수치이며, 별도의 37B 모델이 존재한다는 뜻은 아니다(vLLM 레시피).

이 구조를 이해하는 데는 다음과 같은 구분이 유용하다.

1. 상주 용량: 선택될 수 있는 가중치는 스토리지와 메모리에 모두 올라가야 한다.
2. 활성 연산: 토큰마다 라우팅된 일부만 실제로 실행된다.
3. 런타임 상태: KV 캐시, 임시 버퍼, 배치 처리, 프레임워크 오버헤드는 그대로 남는다.
4. 시스템 비용: 인터커넥트, 전력, 호스트 RAM, 운영 시간이 최종 비용을 결정한다.

512K 컨텍스트라는 헤드라인이 예산이 아닌 이유

K2 Horizon의 대형 모델 카드는 네이티브 컨텍스트로 524,288 tokens를 내세운다. 하지만 공개된 MoVA 36B-A4B 및 375B-A23B용 vLLM 레시피는 모두 --max-model-len 131072를 설정한다. 이는 헤드라인 최대치의 4분의 1이다(36B vLLM 레시피, 375B 모델 카드).

131K 레시피가 보여주는 것은 네이티브 512K 컨텍스트가 무료 기본값은 아니라는 점이다. 컨텍스트가 길어지면 KV 캐시가 커지고 동시 처리량은 줄며 프롬프트 지연 시간은 늘어난다.

비용을 기준으로 본 자체 호스팅 시나리오

K2 Horizon에는 비교 기준으로 삼을 만한 투명하고 범용적인 API 가격표가 없다. 공식 MoVA GGUF 페이지는 현재 이 모델을 배포하는 추론 제공자가 없다고 밝힌다. Artificial Analysis의 375B 프로필에는 입력과 출력 가격이 $0.00으로 표시되지만, 속도와 작업당 비용은 제공되지 않는다. 이를 무료 프로덕션 엔드포인트의 근거로 봐서는 안 된다(MoVA GGUF 카드, Artificial Analysis).

24GB급 GPU에서의 실험

36B 모델의 이상적인 4비트 가중치 하한은 약 18GB다. 24GB 카드에서는 양자화 메타데이터, 런타임 버퍼, KV 캐시에 쓸 수 있는 공간이 6GB 미만으로 남는다. 이 계산만 보면 중간 수준 컨텍스트에서 24GB급 테스트는 가능해 보인다. 그러나 이를 보편적인 최소 사양으로 볼 수는 없다. 실제 사용 가능 여부는 양자화 방식, 백엔드, 오프로딩 정책, 프롬프트 길이에 따라 달라진다.

인용한 공식 MoVA GGUF 아티팩트는 소형 소비자용 양자화가 아니라 BF16이다. Hugging Face 컬렉션에는 계열 전체에 걸쳐 GGUF와 FP8 변형이 올라와 있지만, 출시 초기의 변환 및 호환성 작업도 배포 예산에 포함해야 한다(K2 Horizon 컬렉션).

“아직 다른 GGUF를 업로드 중인 듯하다. 지금 보이는 것은 BF16 GGUF뿐이다” — r/LocalLLaMA의 u/apoptosist.

문서화된 36B 경로의 H200 2개 구성

IFM의 MoVA vLLM 레시피는 텐서 병렬 2, 전문가 병렬, BF16, 131,072토큰 서빙 한도를 사용한다. SGLang 문서에서는 이 구성이 2× H200에서 검증됐다고 밝히는데, 이는 모델명만으로 추정하는 것보다 더 강한 하드웨어 신호다(vLLM 레시피, 공식 GGUF 카드).

공개된 공급자 요금은 가동률이 왜 중요한지 보여준다. DigitalOcean은 전용 NVIDIA H200을 GPU-hour당 $4.47, 8× H200 구성을 시간당 $35.78로 제시한다. Google Cloud는 vCPU, 메모리, SSD가 머신 타입 가격에 포함된 8× H200 A3 Ultra 머신을 시간당 $84.806908493로 제시한다(DigitalOcean 가격, Google Cloud 가격).

표시된 GPU당 요율을 적용하면 H200 2개는 약 시간당 $8.94, 730시간 기준 월 $6,526에 해당한다. 호스트와 스토리지 비용 전의 수치이며, 2 GPU 구성의 견적이 아니라 가동률에 민감한 참고값으로만 봐야 한다.

375B-A23B를 위한 H200 8개 구성

플래그십의 공식 서빙 레시피는 H200 8개, TP=8, EP=8, BF16을 사용한다. 이 구성은 약 750GB라는 원시 BF16 계획 하한과 맞물리며, 엔터프라이즈급이라는 경계를 분명하게 보여준다(375B 모델 카드).

Google이 제시한 8× H200 머신 가격 시간당 $84.81은 730시간 기준 약 $61,909다. 세금, 데이터 전송, 영구 스토리지, 애플리케이션 운영 비용은 포함하지 않는다. 이는 K2 Horizon 가격도 아니며, 공개된 레시피가 특정 tokens-per-second를 보장한다는 뜻도 아닌 인프라 참고치다.

초기 자체 호스팅 사례가 보여주는 것과 보여주지 못하는 것

초기 사용자 보고는 K2 Horizon이 실제로 구동된다는 점을 보여준다. 다만 양자화 방식과 런타임이 제각각이어서, 아직 보편적인 비용 대비 성능 곡선을 만들 수 있는 단계는 아니다.

백엔드가 얼마나 큰 차이를 만들 수 있는지는 X의 한 상세 보고에서 잘 드러난다.

“36B-A4B MoVA는 llama.cpp(IFM 포크, Q8_0, 131K ctx)에서 2x 5090으로 131-142 tok/s를 내지만, vLLM에서는 52 tok/s다...” — @abtraore_.

이 보고는 유용하지만 통제된 실험은 아니다. 그럼에도 백엔드와 구성을 명시하지 않은 ‘MoVA가 더 빠르다’는 말이 불완전한 이유는 분명히 보여준다.

Reddit 논의에서는 양자화, 소형 VRAM 환경, 비교 기준, 도구 호출을 둘러싼 질문이 아직 남아 있다. 이는 검증된 성능 지표가 아니다(r/LocalLLaMA 스레드).

진지하게 장비 구매를 판단하려면 하나의 통제된 워크로드에서 양자화별 상주 메모리, 컨텍스트에 따른 KV 캐시 증가량, 프롬프트 및 생성 속도, 도구 호출 신뢰성, 전력 소비, 성공한 작업당 비용을 측정해야 한다.

활성 파라미터 마케팅보다 가동률로 선택하라

어떤 K2 Horizon 모델이 맞는지는 얼마나 자주 실행할지, 필요한 컨텍스트가 어느 정도인지, 출력 품질이 인프라 비용을 정당화하는지에 달려 있다. 짧은 파일럿은 되돌리기 쉬운 구성을 우선해야 하고, 항상 켜 둬야 하는 프라이빗 서비스는 가동률과 운영 안정성을 우선해야 한다.

첫 파일럿에서는 모델을 바꾸기 전에 다섯 가지 값을 기록해 두는 것이 좋다. 최대 VRAM/RAM, 프롬프트 길이, 첫 토큰까지의 시간, 초당 생성 토큰 수, 완료 작업당 비용이다. 워크로드가 더 긴 컨텍스트의 캐시 및 지연 비용을 감수할 가치가 있음을 입증하기 전까지는, 컨텍스트 한도를 문서화된 131,072 tokens로 유지하라.

특정 장비에 어떤 모델군 구성원이 맞는지가 질문이라면, 별도 K2 Horizon 모델 사이징 가이드에서 더 좁은 선택 문제를 다룬다. 이 글은 활성 파라미터 표기보다 가동률과 측정된 작업 비용을 우선한다.

K2 Horizon 모델 FAQ

Apache 2.0이면 모든 K2 Horizon 데이터셋도 Apache 2.0인가?

아니다. IFM은 모델과 코드에는 Apache 2.0이 적용되지만, 데이터셋은 ODC-BY 등 해당 라이선스를 따른다고 설명한다. 재배포하거나 상업적 학습에 쓰기 전에는 각 리포지터리와 데이터셋을 확인해야 한다(IFM 발표).

4B 활성이라는 말은 K2 Horizon MoVA 36B-A4B가 4B 모델 수준의 메모리만 필요하다는 뜻인가?

아니다. 이 모델은 토큰당 약 4B 파라미터를 활성화하지만, 공식 BF16 GGUF는 약 74.9GB다. 실제 메모리 요구량은 가중치 저장 공간, KV 캐시, 런타임 버퍼, 양자화 오버헤드, 동시 처리량이 결정한다.

24GB GPU 한 장으로 K2 Horizon MoVA 36B-A4B를 실행할 수 있나?

적절한 4비트 양자화를 사용하면 이상적인 36B 가중치 하한이 약 18GB이므로 중간 컨텍스트 실험은 가능할 수 있다. 하지만 공식 BF16 아티팩트와 검증된 H200 2개 서빙 경로는 훨씬 큰 여유 공간을 요구한다. 따라서 24GB 결과는 일반적인 프로덕션 보장이 아니라 파일럿 구성으로 봐야 한다.

광고하는 512K 컨텍스트는 경제적으로 서빙할 수 있나?

자동으로 그렇지는 않다. 모델 카드는 네이티브 컨텍스트를 524,288토큰으로 제시하지만, 문서화된 vLLM 예시는 131,072토큰을 사용한다. 컨텍스트가 길어질수록 KV 캐시 수요와 지연 시간이 늘고, 동시 처리량도 대체로 줄어든다.

K2 Horizon 375B-A23B는 일반적인 자체 호스팅 모델인가?

아니다. IFM은 H200 8개를 쓰는 SGLang 구성을 문서화하고 있으며, 런타임 오버헤드 전 원시 BF16 계획 하한만도 약 750GB다. 제공자가 더 작은 검증 구성을 공개하지 않는 한, 엔터프라이즈 또는 클러스터 배포로 취급해야 한다.

K2 Horizon 375B에 표시된 $0.00 가격은 실제 무료 API인가?

그런 결론을 뒷받침하는 근거는 없다. Artificial Analysis에는 입력과 출력 가격이 $0.00으로 표시되지만 속도와 작업당 비용은 제공되지 않으며, 공식 모델 페이지에는 Hugging Face 추론 제공자도 없다. 예산에 이 수치를 넣기 전에는 이름이 명시된 제공자의 계약 조건과 요금표를 확인해야 한다.