솔직히 말하자면, 저는 모델이 내부적으로 어떻게 작동하는지에 대해서는 아는 것이 없습니다. 하지만 예전에 비활성(idle)/점진적(incremental)/클리커 게임을 전문적으로 다룬 적이 있어서, 숫자가 올라가는 것을 보는 것을 정말 좋아합니다. 그리고 저의 GPU 사양이 여러분들 중 일부에 비해 상대적으로 부족하기 때문에, Raon에 대한 소식을 듣고 매우 흥분했고, 이것이 재미있는 프로젝트가 될 것이라고 생각했습니다. 또한 이 모델을 VRAM에 맞출 수 있을지 확인해보고 싶었습니다. 저는 16GB VRAM의 5070 Ti와 Ryzen 5 5600X, 그리고 48GB DDR4만 가지고 있습니다.
처음에 KRAFTON의 Q4_K_M을 9개 레이어의 전문가(experts)를 사용하여 RAM에 올리는 방식(가장 적합한 방법)으로 시도했을 때 50 tok/s가 나왔습니다. 그때부터 저는 이 모델을 얼마나 더 압축할 수 있을지에 집착하게 되었고, 4일과 Claude Max 20 플랜의 40%를 사용한 끝에, 디코딩 속도가 Q4_K_M과 거의 비슷한 품질로 50 tok/s에서 232 tok/s까지 향상되었습니다.
[GGUF: McNiiby/Raon-1-mini-preview-IQ3_KS-GGUF · 빌드/실행 지침으로 포크하기: Mcniiby/ik_llama.cpp-raon (16GB 카드가 필요함)]
첫 번째 성공은 양자화(quant)였습니다. 일반 llama.cpp를 사용했을 때, VRAM에 완전히 들어가는 3비트 양자화 모델이 50 tok/s에서 약 135 tok/s로 점프했습니다. 이후 저는 같은 품질을 더 적은 공간으로 구현하기 위해 ik_llama.cpp로 옮겼습니다. 처음에는 ik가 일반 llama.cpp보다 느리게 작동하여 (~106 tok/s) 했습니다. 저는 Q4_K_M으로 시작했을 때와 비교하여 (IQ3의 KLD 0.05 대 IQ4의 0.09) 훨씬 가깝기 때문에 4비트가 더 좋았을 것이라고 생각했지만, 16.3GB로는 들어가지 않았습니다.
전문가를 가지치기(pruning experts)하거나 범위를 좁혀보았지만, 절약된 매 GB당 품질 손실이 IQ4가 되돌려준 이득보다 더 컸습니다. 몇 개의 레이어 전문가를 시스템 RAM에 두는 것이 작동했지만, 속도는 약 130 tok/s 수준으로 제한되었습니다. 그래서 GPU 전체에 로드되는 IQ3가 가장 좋았습니다. (KLD가 낮다는 것은 출력 확률 분포가 Q4_K_M에 더 가깝다는 것을 의미하지만, 작업 정확도를 직접 측정하는 것은 아닙니다.)
또한 어휘(vocabulary)를 정리했습니다. Raon은 260K 토큰을 가지고 있으며 그중 많은 부분이 한국어, 중국어, 일본어를 위한 것이지만 저는 영어만 사용합니다. 54K 토큰을 제거했는데도 품질 손실은 거의 없었습니다 (KLD 0.0931 대 0.0923).
또한 모든 토큰마다 전체 목록을 스캔하는 샘플러를 노출했는데, 이를 수정하여 토큰당 샘플링 시간이 1.3ms에서 0.3ms로 단축되었고, 실제 채팅 환경에서는 약 15% 더 빨라졌습니다. 그렇다면 왜 ik가 llama.cpp보다 느렸을까요? 양자화(quant) 문제가 아니었습니다. 공유 테스트 파일에서 일반 llama.cpp는 133 tok/s를 기록했고 ik는 106 tok/s를 기록했으며, GPU는 메모리 대역폭의 약 20%만을 사용하고 있었습니다. ik의 빠른 경로(fast path)가 Raon의 SITU 활성화(activation)를 지원하지 않았고, 이로 인해 CUDA 그래프가 비활성화되었으며, Raon의 mHC 레이어는 토큰당 약 1,500개의 작은 커널 실행을 유발했습니다. 이 두 가지 문제를 수정하자 ik는 147 tok/s에 도달하여 일반 llama.cpp를 넘어섰습니다. 그 후로는 토큰 내 어디에서든 오버헤드를 찾는 작업이었습니다. 아래의 각 속도 향상은 단일 실행 내 채팅 모델에서의 A/B 테스트 결과입니다:
| 변경 사항 | 수정된 내용 | 추가 시 속도 향상 | KLD vs 미적용 시 |
|---|
| SITU + mHC 융합 | CUDA 그래프 재활성화; mHC를 토큰당 약 1,500개 실행에서 ~150개로 단축 | +31% | 0.0044 |
| Small-matmul 커널 | 토큰당 146개의 작은 F16/F32 행렬 곱셈이 cuBLAS를 통해 처리됨 | +12% | 0.0046 |
| 융합된 델타 어텐션(Fused delta attention) | Raon의 순환 레이어 업데이트를 하나의 커널로 통합 | +9% | 0.0026 |
| MoE 메가커널(MoE megakernel) | 각 레이어의 전문가 블록에 대한 영구적인 단일 커널 제공 | +7% | 0.0036 |
| 그리디 텍스트 동일 (greedy text identical) | | | |
| Dense matvec merge, small fusions | 입력이 공유되는 투영(Projections)을 한 번에 실행하여 작은 커널 수를 줄임 | +13% | 0.0028, greedy text identical |
| 파이프라인 메가커널(Pipelined megakernel) | 현재를 계산하는 동안 다음 전문가를 로드함 | +5% | 0.0032, greedy text identical |
| 더 빠른 mHC 경계 (Faster mHC boundary) | | | |
| 토큰당 49번 실행되는 지연 시간 제한 커널을 6.5µs에서 3.7µs로 단축 | +3.1% | 0.0037 | |
| Small-kernel fixes | Layer-0 FFN 및 순환 레이어 행렬 곱셈(matvecs)의 실행 횟수를 각 레이어당 한 번 줄임 | +1.2% | 0.0040, greedy text identical |
| 장문 컨텍스트 어텐션 (Long-context attention) | | | |
| 4K 토큰을 넘어서면 디코드 어텐션이 64개 대신 모든 70개의 SM에 분산됨 | +2.3~3% at 16K context | 0.0006 | |
| 프롬프트 읽기 (KDA 스캔) | ik의 델타-넷 스캔은 메인라인보다 단계당 약 10배 느렸음 | +35% on a 4K prompt | 0.0045 |
각 행은 위에 있는 행들이 이미 적용된 상태에서 측정되었으므로, 합산(add)되는 것이 아니라 곱해집니다.
이로써 채팅 모델에서 232 tok/s에 도달했으며, 가중치(weights) 스트리밍은 카드 최대 대역폭의 약 2/3 수준이었습니다. KRAFTON의 DFlash drafter도 시도해 보았지만, 이를 적용하려면 컨텍스트(context)를 포기하고 VRAM을 확보해야 했고 그만한 가치가 없었습니다. 8개 추측 배치(batch of 8 guesses)를 확인하는 것이 토큰 하나당 2.2배의 비용이 들었고 실제로 약 2.3개만 수용되었기 때문에 속도가 36-53% 느렸습니다.
훨씬 저렴한 N-gram 추측(speculation)은 채팅에서는 약 6%를 추가했고, 답변이 프롬프트에서 복사될 때는 12-22%를 추가했습니다. 그럼 여전히 잘 생각하나요? 그건 애초에 Raon이 잘 생각하는지 여부에 달려있다고 할 수 있겠지만(웃음), 네, 대부분 기본 모델과 동일하게 유지되었습니다.
GPQA와 AA-Omniscience는 점수가 낮게 나왔는데, 그 이유를 알 수 없었습니다. 이들은 대부분 서브셋(subsets)에 대한 단일 실행 결과이므로, 몇 점 차이는 노이즈로 간주해야 합니다.
벤치마크 (사고 과정, 카드 설정)
| Ours | Card |
|---|
| IFBench (prompt, loose) | 84.7 | 84.2 |
| MultiChallenge | 58.9 | 59.0 |
| MMLU-Pro (210 items) | 78.6 | 76.5 |
| AIME 2026 | 94.2 | 93.3 |
| GPQA Diamond | 71.2 | 84.3 |
| AA-Omniscience | -3.0 | +3.5 |
또한 Workybara.ai를 위해 제가 구축한 일부 평가(evals)에서도 실행하여 일반적인 벤치마크 외부에서의 성능을 확인했습니다. 문서에서 구조화된 데이터(structured data)를 추출하는 작업에서는 이전에 해당 작업을 위해 미세 조정(fine-tuned)했던 소형 모델보다 더 나은 콘텐츠를 추출했지만, 14%의 확률로 토큰이 고갈될 때까지 동일 항목의 변형 목록을 반복적으로 나열하는 루프에 빠졌습니다 ("Deployment Promise, Deployment Vow…").
Claude가 평가한 철학 질문에 대해서도 시도해 보았는데, 주요 핵심 포인트의 약 70%를 다루었지만, 답변 중 59%에는 명백히 잘못된 주장이 적어도 하나 포함되어 있었습니다.
KRAFTON 자체 플레이그라운드(제 양자화 모델이 아닌 전체 모델)에서 농담을 요청했을 때도 동일한 습관을 보였습니다. 자신의 비밀번호 농담 규칙을 위반했고, 방금 지어낸 농담들을 "명작(classics)"이라고 불렀으며, 아무것도 가져오지 않았는데도 "제가 검색한 어떤 것도 이를 뒷받침하지 않습니다"라고 말했고, 심지어 잘못된 비판까지 제가 한 모든 비판에 동의했습니다.
이 모든 것은 표준 벤치마크에서는 나타나지 않았습니다.
저는 이것을 최첨단(frontier) 챗봇들을 대체하는 데 사용하기를 바랐지만, 검색 기능과 RAG(검색 증강 생성)가 있음에도 불구하고 Raon은 그들과 경쟁할 수 없었고, 대화하는 것이 답답했습니다. 이 글이 작성된 방식은 Claude Code와 그 서브 에이전트들이 연구, 코딩 및 측정의 대부분을 수행했으며, 제가 이것을 정리하도록 도왔습니다. 4일 동안 저는 주로 질문들로 Claude에게 약 15,000 단어를 입력했습니다. 가장 긴 메시지는 124단어였는데, 그것은 제가 Claude에게 결론을 성급하게 내렸다고 지적하는 내용이었습니다. 공개 벤치마크를 실행하기 위해 클라우드 GPU를 임대했기 때문에, 제 RTX 5070 Ti는 속도 테스트를 계속할 수 있었습니다. 그 외에는, 저의 역할은 질문을 계속 던지고, 반박하고, '너도 할 수 있어 친구'라고 말하는 성가신 아이 역할을 하는 것이었습니다. VRAM에 맞는 좋은 MoE(Mixture-of-Experts) 모델을 찾아 대화하는 여정은 계속될 것입니다. 다음으로는 Gemma-4-26B-A4B나 Qwen3.6-35B-A3B에서 더 많은 성능을 끌어낼 수 있는지 확인해 볼 것 같습니다. /u/McNiiby가 r/LocalLLaMA에 제출함 [링크] [댓글]
