새로 나온 모델 · 2026.09.29
K2 Horizon 0.9B~36B-A4B: 내 장비에 맞는 모델 고르기
가장 큰 K2가 정답이 아니라, 계속 켜 둘 수 있는 가장 작은 K2가 출발점입니다.
K2 Horizon은 0.9B에서 32B 밀집형, 36B-A4B MoE1까지 한 제품군 안에서 크기가 크게 갈립니다. 작은 모델은 브라우저·노트북 자동화에 가볍고, 큰 모델은 더 복잡한 답을 노릴 수 있지만 메모리와 첫 토큰2 대기가 늘어납니다. 512K 문맥 지원도 모든 내용을 매번 넣으라는 뜻은 아닙니다. 자주 할 작업과 장비 메모리를 먼저 정하면 후보가 빠르게 좁혀집니다.
모델 크기보다 맡길 일을 먼저 고릅니다
메일 분류와 짧은 명령 변환처럼 답이 짧고 규칙이 분명한 일은 0.9B나 3.7B부터 시험합니다. 개인 문서 요약과 일반 대화, 간단한 코딩은 7B가 균형점이 될 수 있습니다. 여러 파일의 관계를 따지는 코딩과 복잡한 추론에서 작은 모델의 실패가 반복될 때 32B 또는 36B-A4B를 검토합니다.
같은 질문을 크기별로 보내고 정답 여부, 근거 인용, 첫 토큰과 완료 시간을 함께 적습니다. 더 큰 모델이 문장을 길게 쓴다는 이유만으로 선택하지 않습니다. 작은 후보가 필요한 답을 안정적으로 내면 남는 메모리와 빠른 응답이 더 큰 장점입니다.
0.9B·3.7B·7B는 항상 켜 두기 좋은 구간입니다
0.9B는 128K 문맥과 작은 가중치가 장점입니다. 고정 형식 추출과 라우팅, 초벌 요약처럼 실패를 쉽게 검증할 수 있는 작업에 맞습니다. 3.7B부터는 공식 512K 문맥을 제공하지만 긴 입력을 처리하는 시간과 KV 캐시3는 별도이므로 8K나 16K에서 시작합니다.
7B는 8GB급 GPU4와 16GB 이상 통합 메모리5에서 Q4 실행을 검토하기 쉽습니다. 노트북에서 다른 앱과 함께 쓸 때는 운영체제와 브라우저가 사용할 메모리를 남깁니다. 3.7B와 7B의 답 품질 차이가 실제 업무에서 작다면 더 빠르고 가벼운 쪽을 유지하는 것이 좋습니다.
32B 밀집형은 24GB와 32GB 장비의 경계에서 봅니다
32B Q4 파일은 24GB GPU에서 짧은 문맥으로 들어갈 수 있지만 런타임6과 KV 캐시 여유가 빠듯할 수 있습니다. 32GB 이상 VRAM7이나 통합 메모리는 다른 앱과 긴 문맥을 함께 유지하기 쉬워집니다. 메모리가 부족해 시스템 RAM8 오프로드가 시작되면 실행 가능 여부와 체감 속도가 크게 달라집니다.
32B는 모든 토큰에서 전체 밀집 가중치를 사용하므로 단일 사용자 디코드9가 메모리 대역폭10의 영향을 많이 받습니다. 같은 32GB 표시라도 메모리 대역폭과 엔진이 다르면 속도는 달라집니다. 사이트 속도 비교에서 장비를 바꾸며 모델이 들어가는지와 토큰 생성 속도를 따로 확인하세요.
36B-A4B는 4B 모델처럼 가볍게 적재되지 않습니다
MoVA 36B-A4B는 전체 약 36B를 보관하고 토큰당 약 4B를 활성화합니다. 활성 4B는 계산 경로를 설명하지만 필요한 저장 용량이 4B가 된다는 뜻은 아닙니다. Q4에서도 전체 전문가 가중치와 KV 캐시가 접근 가능한 메모리에 있어야 합니다.
가중치가 고속 메모리에 들어가면 활성 계산량 덕분에 32B 밀집형보다 디코드가 유리한 조합이 생길 수 있습니다. 반대로 일부 전문가를 느린 RAM이나 저장장치에서 자주 불러오면 그 이점이 사라집니다. 공식 vLLM 예시는 2개 가속기와 전문가 병렬을 사용하므로 데스크톱 GGUF11와 같은 조건으로 보지 않습니다.
512K는 단계적으로 열어야 쓸 수 있습니다
긴 문맥을 지원해도 첫 토큰까지 읽는 시간과 KV 캐시가 선형으로 작아지지는 않습니다. 4K에서 답의 품질과 속도를 저장하고 16K·64K 순서로 늘리며 필요한 정보를 실제로 찾는지 확인합니다. 512K 숫자만 보고 파일 전체를 넣으면 기다림이 늘고 중요한 근거를 놓칠 수 있습니다.
구매 전에는 자주 쓰는 입력 길이에서 세 번 반복한 중앙값을 봅니다. 7B가 필요한 답을 내고 32B가 큰 차이를 만들지 못한다면 더 큰 장비는 필요하지 않습니다. 반대로 32B나 36B-A4B에서만 반복적으로 해결되는 문제가 있다면 그때 메모리 여유와 전력, 구매 비용을 함께 비교합니다.
용어 각주
MoE — 여러 전문가 하위망 중 일부를 입력에 따라 선택해 사용하는 모델 구조입니다. 총 파라미터 수와 한 토큰 처리에 활성화되는 파라미터 수는 다를 수 있습니다.
본문으로 돌아가기토큰 — 모델이 입력이나 출력을 나누어 처리하는 단위입니다. 토큰 하나가 글자 하나나 일정한 시간 길이에 해당하지는 않습니다.
본문으로 돌아가기KV 캐시 — 어텐션에서 이전 토큰의 키·값을 저장해 다음 토큰 생성 때 재사용하는 메모리입니다. 문맥 길이와 배치 크기에 따라 용량이 달라집니다.
본문으로 돌아가기GPU — 많은 계산을 병렬로 처리하는 프로세서입니다. AI 모델 실행에서는 모델 계산을 맡습니다.
본문으로 돌아가기통합 메모리 — CPU와 GPU가 같은 물리 메모리 풀을 공유하는 구조입니다. 메모리 용량이 자동으로 늘어나는 것은 아니며, 실제 사용 가능량은 시스템에 따라 다릅니다.
본문으로 돌아가기런타임 — 프로그램이 실행될 때 필요한 기능을 제공하는 소프트웨어 환경입니다. 로컬 AI에서는 모델을 실행하는 엔진을 가리키기도 하며, GPU 런타임 라이브러리와 완성된 서빙 앱은 서로 다른 구성요소입니다.
본문으로 돌아가기VRAM — 그래픽카드의 GPU가 사용하는 메모리입니다. 모델 가중치와 계산 중간값을 저장하며 시스템 RAM과 구분됩니다.
본문으로 돌아가기시스템 RAM — 프로그램이 실행되는 동안 데이터를 임시로 보관하는 시스템 메모리입니다. 저장장치나 독립 GPU의 VRAM과는 다릅니다.
본문으로 돌아가기디코드 — LLM에서는 입력 처리 뒤 출력 토큰을 생성하는 단계를 뜻합니다. VAE나 오디오 코덱에서는 압축 표현이나 인코딩 데이터를 원래 형식으로 복원하는 처리를 가리킬 수 있습니다.
본문으로 돌아가기메모리 대역폭 — 메모리와 프로세서 사이에서 단위 시간에 전송할 수 있는 데이터 양입니다. 실제 처리량은 접근 패턴과 다른 병목에도 영향을 받습니다.
본문으로 돌아가기GGUF — 모델 정보를 담는 파일 형식으로 llama.cpp 계열 도구에서 널리 사용됩니다. 파일 형식만으로 특정 하드웨어 호환성이나 속도가 보장되지는 않습니다.
본문으로 돌아가기