에이전트 작업에서 실제로 중요한 것을 찾기 위해 13개 모델을 65K-128K 컨텍스트에서 벤치마크했습니다

참고할 점: Devstral-24B는 131K 테스트를 끝내지 못함 (8 KV 헤드 × 128 dim = 160 KB/토큰 — 131K에서 KV 캐시만 약 21GB). GLM-4.7-Flash는 16K 넘어가니까 뻗어버림 (MLA 문제, 5번 발견 사항 참고). Ornith-9B는 구조적으로 Qwen3.5-9B랑 똑같음.

발견 1: 65K 이상 컨텍스트에서 프리필이 전체 시간의 94~99%를 차지함. 짧은 에이전트 출력에는 tg128이 거의 의미 없음.

실제 에이전트 쿼리(65K 컨텍스트 입력, 300토큰 출력, 전형적인 도구 사용 응답)에 걸리는 시간 분석이다. 총 시간 기준으로 정렬함:

디코드는 우리가 기다리는 시간의 1~5%밖에 안 된다. 에이전트가 짧은 도구 호출을 하거나 간단한 답변을 내놓을 때, 진짜 중요한 건 컨텍스트 윈도우를 얼마나 빨리 처리하느냐뿐이다.

즉, tg128을 앞세운 벤치마크 리포트는 에이전트용으로는 다 헛소리라는 거다. pp65K / pp131K가 진짜 핵심 지표다. pg(prompt, gen) 혼합 지표가 그나마 낫긴 한데, 이것도 세부 수치를 가려버린다. 프리필은 빠른데 디코드가 개판인 모델은 짧은 출력에는 최상급인데도 pg 지표상으로는 그냥 평범해 보일 수 있거든.

발견 2: 장문 컨텍스트 프리필에서 가장 중요한 아키텍처 요소는 KV 헤드 개수임 — 파라미터 수도 아니고, MoE냐 덴스냐도 아님

컨텍스트가 늘어날 때의 프리필 속도 유지율(pp4K 속도 대비 %)이다:

*Granite-H-Small은 어텐션 레이어 4개 + Mamba2 레이어 36개로 구성됨 (재귀 상태 사용, KV 캐시 없음)

Ornith-9B / Qwen3.5-9B(9B 덴스, 4 KV 헤드 × 128 dim = 64 KB/토큰 KV)는 128K 컨텍스트에서 Apriel-15B(15B 덴스, 8 KV 헤드 × 128 dim = 160 KB/토큰)보다 4.4배 빠르다. 같은 덴스 계열에 크기는 절반인데도 말이다. 차이는 순전히 KV 캐시 아키텍처 때문이다. 어텐션 패스마다 전체 KV 캐시를 훑어야 하는데, 8 KV 헤드면 토큰당 2.5배나 더 많은 데이터를 훑어야 하니까.

실전 팁: 긴 컨텍스트용 모델을 고를 때 파라미터 수부터 보지 말고, 설정 파일에서 n_kv_heads랑 head_dim부터 확인해라. 같은 패밀리 모델이라도 KV 헤드가 4개냐 8개냐에 따라 128K에서 3~4배 차이 난다.

발견 3: Mamba2 하이브리드 모델은 프리필 스케일링이 거의 평탄함. 이 아키텍처는 진짜 물건이다.

Mamba2 거품 아닌가 싶었는데, 데이터 보니까 확실하네. Granite-4.0-H-Small(IBM, 어텐션 레이어 4개 + Mamba2 레이어 36개)은 131K 컨텍스트에서도 pp4K 속도의 69%를 유지한다. 테스트한 모든 트랜스포머 모델은 42% 밑으로 떨어졌는데 말이지.

131K 컨텍스트에서 Granite-H-Small(17GB)은 파일 크기가 3배나 작은 Ornith-9B / Qwen3.5-9B(6GB)와 비슷한 약 875 t/s를 찍는다. Mamba2 레이어는 KV 캐시가 커지는 대신 고정된 재귀 상태를 쓰니까, 어텐션 레이어 4개만 KV 증가에 영향을 주는 거다.

문제는 디코딩이 느리고(71 t/s) 추론 품질이 떨어진다는 거야. 하지만 "방대한 컨텍스트, 짧은 출력"이라는 에이전트 도구 사용에 딱 맞는 작업 패턴에서는 프리필(prefill) 스케일링 이점이 확실하고 측정 가능해. 누군가 이 아키텍처로 제대로 된 모델을 학습시킨다면, 에이전트 분야에서 진짜 강력한 경쟁자가 될 수 있을걸.

발견 4: F16 KV 캐시가 Q8/Q4 양자화 KV보다 빠를 수 있다 — 역양자화의 역설

통념상 속도를 높이려면 KV 캐시를 양자화(Q8_0 K / Q4_0 V)해서 캐시 크기를 줄이고 대역폭을 아끼라고 하잖아. 65K 컨텍스트에서 F16 베이스라인과 Q8_0 K / Q8_0 V를 직접 맞붙여 테스트해 봤어(결과는 Q8K/Q4V와 ±1% 오차 범위 내에서 동일했음. V 캐시 양자화 방식은 별 상관없다는 뜻이지):

MoE 모델이랑 작은 덴스(dense) 모델에서는 F16이 압승이야. 반면 KV 헤드가 많은 덴스 모델에서는 처참하게 깨져. 이유는 이거야.

Q8/Q4 KV 캐시 역양자화는 컨텍스트 길이에 비례해서 늘어나는 연산 작업이거든. 65K 컨텍스트에서 어텐션 커널은 토큰 하나당 65K × n_kv_heads × head_dim 만큼의 Q8/Q4 요소를 역양자화해야 해. 이 연산 비용이 캐시 크기를 절반으로 줄여서 얻는 대역폭 이득보다 더 커지는 거지.

반면 F16 KV는 캐시 용량은 두 배지만 역양자화가 아예 필요 없어. MoE 모델의 경우 F16 캐시가 커지면 GTT 스필(spill)이 발생하긴 하는데, 활성 파라미터(35B 중 약 3B)만 PCIe를 넘어가니까 스필 페널티가 미미해. 하지만 KV 헤드가 8개인 덴스 모델은 F16 캐시가 커지는 데다 가중치까지 전부 스필되니까 페널티를 두 배로 처맞는 셈이지.

업데이트된 규칙:

• F16 승: MoE 모델(활성 스필 영향이 미미함), 작은 덴스 모델(<10GB), 효율적인 GQA 덴스 모델(KV 헤드 4개)
• F16 패: 덴스 모델 + KV 헤드 8개 이상 + 10GB 초과(가중치 전체 스필 + 큰 KV 캐시 = 재앙)
• Q8K/Q4V vs Q8K/Q8V: 모든 모델에서 차이 없음(±1%). V 캐시 양자화 선택은 무의미함. 아무거나 써.

본인 하드웨어에서 실제 작업 컨텍스트로 F16을 직접 테스트해 봐. 통념이 항상 맞는 건 아니니까.

발견 5: MLA(Multi-head Latent Attention)는 컨텍스트가 커질수록 Vulkan에서 성능이 급락한다

GLM-4.7-Flash(KV 헤드 1개, 576 차원 — MLA 아키텍처)는 프리필 성능이 급격하게 떨어졌어:

512에서 16K 컨텍스트로 가면서 80%나 꼬라박았어. 65K 벤치마크는 아예 뻗어버렸고(Vulkan DeviceLost). 다만, 이 데이터가 뭘 보여주고 뭘 안 보여주는지는 확실히 해둘게. 16K와 65K 사이 컨텍스트는 테스트를 안 해서 정확히 어디서 터지는지는 몰라. 나도 이 모델을 매일 20K 이상 컨텍스트에서 쓰고 있는데 뻗지는 않거든. 즉, 16K가 절대적인 한계점은 아니고 그 어딘가에 실패 지점이 있다는 거지.

데이터에서 확실한 건, Vulkan에서 MLA의 프리필 스케일링이 표준 어텐션보다 훨씬 구리다는 거야. 이게 완전히 뻗어버릴지 아니면 그냥 엄청 느려질지는 컨텍스트 크기와 VRAM 여유 공간에 달렸어. pp4K에서 pp16K로 갈 때 66% 떨어진 건 확실한 사실이야. MLA의 KV 압축/압축 해제 커널이 Vulkan 백엔드에서는 컨텍스트가 커질수록 스케일링이 잘 안 되는 모양이야. 짧은 컨텍스트의 MLA 벤치마크 결과를 긴 컨텍스트에 그대로 대입하지 마. 그리고 성능 저하가 선형적일 거라고 생각하지 마. 갈수록 가속화되는 것처럼 보이거든. 이건 백엔드 특성일 수도 있어. CUDA나 Metal은 MLA의 어텐션 패턴을 더 잘 처리할지도 모르지.

발견 6: 에이전트 작업에는 MoE 모델이 속도와 지능 종합 점수에서 1등이다

속도 데이터와 Artificial Analysis Intelligence Index v4.1 점수를 합쳐서 종합 점수를 내봤어(지능 점수에 실제 소요 시간의 역수를 가중치로 둠). 점수 = AA 지능 점수 × (50초 / 65K에서의 실제 소요 시간). 즉, 50초 걸리면 AA 배율 1.0배가 되는 식이지.

GLM-4.7-Flash는 65K 데이터가 없어서(MLA 크래시) 제외했어.

가장 똑똑한 모델(Qwen3.6-27B, AA=37)은 MoE 모델보다 3배나 느려서 6위로 밀려났어. 상위 MoE 모델(Qwen3.6-35B-A3B, AA=32)은 3배 빠른 속도로 지능의 87%를 뽑아내. 모델이 짧은 출력을 여러 번 반복해야 하는 에이전트 워크플로우에서는 이 트레이드오프가 훨씬 유리해.

MoE 모델은 두 가지 이득을 챙길 수 있음. 디코딩이 빠르고(활성화된 파라미터만 읽으니까), GTT 스필 비용도 저렴함(컨텍스트 때문에 스필오버 발생 시 활성화된 가중치만 PCIe를 넘어가니까). 이 조합 덕분에 VRAM이 제한된 환경에서 긴 컨텍스트를 다룰 때 압도적인 성능을 보여줌.

TL;DR — 로컬 에이전트 LLM 배포를 위한 실전 팁

1. tg128에 집착 좀 그만해. 65K 이상의 컨텍스트에서는 짧은 출력물 기준으로 프리필(prefill)이 전체 작업 시간의 94~99%를 잡아먹음. 차라리 pp65K나 pp131K로 벤치마크 돌려라.
2. KV 헤드 개수부터 확인해. 4 KV 헤드 × 128 차원(토큰당 64KB)이 8 KV 헤드 × 128 차원(토큰당 160KB)보다 긴 컨텍스트에서 훨씬 효율적임. 모델 크기랑 상관없음.
3. 작업 환경 컨텍스트에서 F16 KV 캐시 테스트해 봐. MoE나 작은 덴스 모델에서는 Q8/Q4보다 20~53% 더 빠를 수 있음. "KV는 무조건 양자화해야 한다"는 상식은 긴 컨텍스트 환경의 일부 아키텍처에선 안 통함.
4. 소비자용 VRAM에서 에이전트용 긴 컨텍스트를 돌릴 땐 MoE가 정답임. 저렴한 GTT 스필 + 빠른 디코딩 + 준수한 지능. 30B급 MoE면 2~3배 빠른 속도로 최상위 덴스 모델 지능의 80% 이상을 뽑아냄.
5. Mamba2 하이브리드 모델은 진짜임. 131K까지 프리필 스케일링이 거의 평탄하게 유지됨. 지금은 아키텍처 문제가 아니라 학습 품질이 발목을 잡고 있는 거라, 앞으로 지켜볼 만함.
6. MLA는 Vulkan에서 컨텍스트가 길어지면 성능이 떡락함. GLM-4.7-Flash는 512에서 16K 컨텍스트로 넘어가면서 프리필 속도가 80%나 깎였고, 65K에선 아예 뻗어버림. 적당한 컨텍스트(난 20K+로 매일 씀)에선 쓸만하지만, 스케일링 곡선이 가파르고 비선형적임. 짧은 컨텍스트 MLA 벤치마크 결과만 보고 판단하지 마라.

모든 데이터는 llama.cpp 빌드 9860, Vulkan 백엔드, RX 7900 XT 20GB 환경에서 측정함. 하드웨어마다 결과는 다를 수 있음. 특히 F16 KV 관련 내용은 본인 GPU의 대역폭 대비 연산 비율이나 VRAM 여유 공간에 따라 갈림. 하지만 아키텍처 패턴(KV 헤드 개수, 프리필 비중, MoE의 스케일링 효율)은 어디서나 비슷하게 적용될 거임.

혹시라도 재현해보고 싶은 사람 있으면 원본 JSONL이나 벤치마크 스크립트 공유 가능함.

요즘 GPT스러운 말투(gpt-isms) 읽는 것도 지긋지긋하고.