에이전트 워크로드(agentic workloads)에 실제로 중요한 요소가 무엇인지 알아보기 위해 65K-128K 컨텍스트에서 13개 모델을 벤치마킹했습니다 — 프리필(prefill)이 모든 것을 지배하며, KV 헤드(KV head) 수가 파라미터(parameter) 수를 압도합니다.

저는 에이전트 워크플로우(도구 사용, 코딩 에이전트, RAG)를 위해 로컬 LLM을 실행해 왔으며, 사람들이 주요 성능 지표로서 tg128(토큰 생성 속도)에 집착하는 것을 계속 보았습니다. 그래서 컨텍스트 윈도우(context window)가 가득 찼을 때 실제로 무엇이 중요한지 파악하기 위해 구조화된 롱 컨텍스트(long-context) 벤치마크를 수행했습니다. 그 결과는 저를 놀라게 했습니다.

설정(Setup)

GPU: RX 7900 XT 20GB (Vulkan 백엔드, RADV/Mesa)
백엔드(Backend): llama.cpp / llama-bench (build 9860)
플래그(Flags): -ngl 99 (GTT spill), -fa on, -ub 2048 -b 16384, ASPM=performance, VRAM 확보를 위한 bare TTY
13개 모델: 5개 Dense, 6개 MoE, 1개 Mamba2 하이브리드, 1개 MLA MoE — 5GB에서 18GB 범위
3개 KV 캐시(KV cache) 계층: Q8_0 K / Q4_0 V (공격적), Q8_0 K / Q8_0 V (대칭형), F16 (기준점)
컨텍스트 크기(Context sizes): 512, 4K, 16K, 65K, 131K — 순수 프리필(pp) 및 프롬프트+생성(pg) 모두 포함
전체 실행은 두 세션에 걸쳐 약 21시간 소요

전체 프리필(prefill) 속도 결과 (Q8_0 K / Q8_0 V KV 캐시, tokens/sec)
단순히 수치만 확인하고 싶다면, 테스트된 모든 모델은 다음과 같습니다. pp = 순수 프롬프트 처리(prefill), tg128 = 토큰 생성(decode)입니다. pp131K 기준으로 정렬되었습니다.

Model Size Type pp512 pp4K pp16K pp65K pp131K tg128

Trinity-Mini 16G MoE 3B/26B 2639 2924 2370 1419 923 150
Granite-4.0-H-Small 17G Mamba2+MoE 1115 1271 1220 1043 875 71
Ornith-9B / Qwen3.5-9B 6G Dense 2103 2220 1943 1274 873 92
Qwen3.6-35B-A3B 18G MoE 3B/35B 2184 2736 2227 1268 802 110
Gemma-4-26B-A4B 14G MoE 4B/26B 2523 2798 2076 1024 600 119
North-Mini-Code 15G MoE 3B/30B 2155 2187 1568 900 579 134
Gemma-4-12B 7G Dense 1492 1498 1145 595 350 66
Qwen3.6-27B 16G Dense 693 681 602 406 285 32
Granite-4.1-8B 5G Dense 1965 1807 1124 442 244 93
Ministral-3-14B 8G Dense 1419 1325 916 404 232 67
Apriel-1.6-15B 9G Dense 1332 1208 812 347 197 66
Devstral-24B 15G Dense 829 796 628 313 --- 42
GLM-4.7-Flash 16G MoE (MLA) 1822 1054 358 --- --- ---

주목할 점이 몇 가지 있습니다: Devstral-24B는 131K 테스트를 완료하지 못했습니다(8 KV heads × 128 dim = 160 KB/token — KV 캐시만으로도 131K에서 약 21GB가 필요합니다). GLM-4.7-Flash는 16K 이상에서 충돌했습니다(MLA 문제, Finding 5 참조). Ornith-9B는 아키텍처적으로 Qwen3.5-9B와 동일합니다.

Finding 1: 65K 이상의 컨텍스트에서는 prefill이 전체 벽시계 시간(wall-clock time)의 94–99%를 차지합니다. tg128은 짧은 에이전트 출력에는 거의 무관합니다.
여기는 실제 에이전트 질의에 대한 벽시계 시간 분석입니다 — 65K 컨텍스트 입력, 300 토큰 출력(일반적인 도구 사용 응답). 총 시간에 따라 정렬되었습니다:

Model Type Prefill Decode Total Prefill %

Trinity-Mini (MoE 3B/26B) MoE 46.2s 2.0s 48.2s 96%
Qwen3.6-35B-A3B (MoE) MoE 51.7s 2.7s 54.4s 95%
Ornith-9B / Qwen3.5-9B Dense 51.4s 3.3s 54.7s 94%
Gemma-4-26B-A4B (MoE) MoE 64.0s 2.5s 66.5s 96%
Granite-4.0-H-Small (Mamba2) Mamba2 62.8s 4.2s 67.1s 94%
North-Mini-Code (MoE) MoE 72.8s 2.2s 75.0s 97%
Gemma-4-12B Dense 110.2s 4.5s 114.7s 96%
Granite-4.1-8B Dense 148.4s 3.2s 151.6s 98%
Qwen3.6-27B Dense 161.4s 9.3s 170.7s 95%
Ministral-3-14B Dense 162.0s 4.5s 166.5s 97%
Apriel-1.6-15B Dense 188.9s 4.6s 193.5s 98%
Devstral-24B Dense 209.5s 7.2s 216.6s 97%

디코딩(Decode)은 실제로 기다리는 시간의 1–5%에 불과합니다.

만약 에이전트가 짧은 도구 호출(tool call)을 수행하거나 짧은 응답을 작성한다면, 유일하게 중요한 것은 컨텍스트 윈도우(context window)를 얼마나 빠르게 처리할 수 있느냐입니다. 이는 tg128을 전면에 내세우는 벤치마크 보고서들이 에이전트적 활용 사례(agentic use cases)에 있어서는 오해의 소지가 있음을 의미합니다. pp65K / pp131K가 실제로 중요한 지표입니다. pg(prompt, gen) 혼합 지표가 더 나은 방식이긴 하지만, 여전히 그 분리된 비율을 가립니다. 즉, 빠른 프리필(prefill)과 처참할 정도로 느린 디코딩(decode)을 가진 모델은 짧은 출력에 매우 탁월함에도 불구하고 pg 지표상으로는 평범해 보일 수 있습니다.

발견 사항 2: KV 헤드(head) 수는 긴 컨텍스트 프리필(prefill)에 있어 지배적인 아키텍처 요소입니다 — 파라미터 수(parameter count)도, MoE 대 Dense의 차이도 아닙니다.
컨텍스트가 증가함에 따른 프리필 속도 유지율 (% of pp4K speed), 모든 모델:

모델 크기	KV 헤드 수	pp4K	16K	65K	131K	유형
Granite-4.0-H-Small	17G	Mamba2*	1271	96%	82%	69%
Qwen3.6-27B	16G	4×256	681	88%	60%	42%
Ornith-9B / Qwen3.5-9B	6G	4×128	2220	87%	57%	39%
Trinity-Mini	16G	4×128	2924	81%	49%	32%
Qwen3.6-35B-A3B	18G	4×128	2736	81%	46%	29%
Gemma-4-12B	7G	8×128	1498	76%	40%	23%
Gemma-4-26B-A4B	14G	4×256	2798	74%	37%	21%
North-Mini-Code	15G	4×128	2187	72%	41%	26%
Apriel-1.6-15B	9G	8×128	1208	67%	29%	16%
Ministral-3-14B	8G	8×128	1325	69%	31%	18%
Granite-4.1-8B	5G	8×128	1807	62%	24%	14%
Devstral-24B	15G	8×128	796	79%	39%	---
GLM-4.7-Flash	16G	MLA (1×576)	1054	34%	---	---

*Granite-H-Small은 4개의 어텐션(attention) 레이어 + 36개의 Mamba2 레이어(순환 상태, KV 캐시 없음)를 가집니다.

Ornith-9B / Qwen3.5-9B (9B Dense, 4 KV 헤드 × 128 dim = 64 KB/token KV)는 Apriel-15B (15B Dense, 8 KV 헤드 × 128 dim = 160 KB/token)보다 128K 컨텍스트에서 4.4배 더 빠릅니다 — 동일한 Dense 클래스이고 크기가 절반임에도 불구하고 말입니다. 이 차이는 순수하게 KV 캐시(KV cache) 아키텍처에서 기인합니다. 모든 어텐션 패스(attention pass)는 전체 KV 캐시를 스캔해야 하며, 8개의 KV 헤드는 토큰당 스캔해야 할 데이터가 2.5배 더 많음을 의미합니다.

실질적인 규칙: 긴 컨텍스트 (long context)를 위해 모델을 평가할 때는 파라미터 수 (parameter count)를 확인하기 전에 설정 (config)에서 n_kv_heads와 head_dim을 먼저 확인하십시오. 동일한 제품군에 속한 두 모델이라도, 한 모델은 4개의 KV 헤드를 가지고 다른 모델은 8개를 가지고 있다면 128K 컨텍스트에서 3~4배의 차이가 날 수 있습니다.

결과 3: Mamba2 하이브리드 (hybrid) 모델은 거의 평탄한 프리필 (prefill) 스케일링을 보여줍니다. 이 아키텍처는 실제로 성능을 입증합니다.
저는 Mamba2에 대한 과장된 홍보에 회의적이었으나, 데이터는 명확합니다. Granite-4.0-H-Small (IBM, 4개의 어텐션 (attention) 레이어 + 36개의 Mamba2 레이어)은 131K 컨텍스트에서도 pp4K 속도의 69%를 유지했습니다. 반면 테스트에 포함된 모든 트랜스포머 (transformer) 모델은 42% 미만으로 떨어졌습니다.

모델	pp4K	pp131K	속도 저하
Granite-H-Small (Mamba2)	1271	875	1.45×
Trinity-Mini (MoE)	2924	923	3.2×
Ornith-9B / Qwen3.5-9B (Dense GQA)	2220	873	2.5×
Granite-8B (Dense)	1807	244	7.4×

131K 컨텍스트에서 Granite-H-Small (17GB)은 파일 크기가 3배 더 큼에도 불구하고 Ornith-9B / Qwen3.5-9B (6GB)와 거의 동일한 ~875 t/s를 기록했습니다. Mamba2 레이어는 계속 커지는 KV 캐시 (KV cache) 대신 고정된 순환 상태 (recurrent state)를 사용하므로, 오직 4개의 어텐션 레이어만이 KV 증가에 기여합니다.

주의할 점: 디코딩 (decode) 속도가 느리고 (71 t/s) 추론 (reasoning) 품질이 낮습니다. 하지만

저는 65K 컨텍스트에서 F16 베이스라인(baseline)과 Q8_0 K / Q8_0 V를 직접 비교 테스트했습니다 (결과는 Q8K/Q4V와 ±1% 이내로 동일했습니다 — V 캐시 양자화 (quantization) 선택은 무관한 것으로 나타났습니다):

모델 유형	Q8K/Q8V	F16	F16 이점
Gemma-4-26B-A4B MoE	1015	1554	+53%
Gemma-4-12B Dense (7GB)	593	857	+44%
Qwen3.6-35B-A3B MoE	1273	1573	+24%
Ornith-9B / Qwen3.5-9B Dense (6GB)	1276	1544	+21%
Trinity-Mini MoE	1429	1583	+11%
Granite-H-Small Mamba2	1040	984	-5%
Ministral-3-14B Dense (8KV)	409	335	-18%
Granite-4.1-8B Dense (8KV)	447	358	-20%
Apriel-1.6-15B Dense (8KV)	351	120	-66%

MoE 모델과 작은 Dense 모델의 경우 F16이 승리합니다. 하지만 KV 헤드(head)가 많은 Dense 모델의 경우 F16이 크게 패배합니다. 그 이유는 다음과 같습니다:

Q8/Q4 KV 캐시 역양자화 (dequantization)는 컨텍스트 길이(context length)에 따라 확장되는 연산 작업입니다. 65K 컨텍스트에서 어텐션 커널 (attention kernel)은 토큰당 65K × n_kv_heads × head_dim 개의 Q8/Q4 요소를 역양자화해야 합니다. 이 연산 비용은 캐시 크기를 절반으로 줄여 절약한 대역폭 (bandwidth)보다 더 큽니다.

반면, F16 KV는 캐시를 두 배로 늘리지만 역양자화가 전혀 필요하지 않습니다. MoE 모델의 경우, 더 큰 F16 캐시로 인해 GTT 스필 (spill)이 발생하지만, 활성 파라미터(active parameters, 35B 중 약 3B)만 PCIe를 통과하므로 스필 페널티 (spill penalty)가 작습니다. 8개의 KV 헤드를 가진 Dense 모델의 경우, F16 캐시는 더 클 뿐만 아니라 모든 가중치 (weights)가 스필되므로 페널티가 두 배가 됩니다.

업데이트된 규칙:

• F16 승리: MoE 모델 (매우 작은 활성 스필 풋프린트), 작은 Dense 모델 (<10GB), 효율적인 GQA Dense (4 KV 헤드)
• F16 패배: Dense + 8개 이상의 KV 헤드 + >10GB (전체 가중치 스필 + 큰 KV = 재앙적)
• Q8K/Q4V vs Q8K/Q8V: 모든 모델에서 완전히 동일함 (±1%). V 캐시 양자화 선택은 무관하므로 아무거나 선택하십시오.

여러분의 실제 작업 컨텍스트에서 여러분의 하드웨어로 F16을 테스트해 보세요. 통념이 항상 옳은 것은 아닙니다.

발견 5: 컨텍스트가 증가함에 따라 MLA (Multi-head Latent Attention)는 Vulkan에서 심각하게 성능이 저하됩니다.
GLM-4.7-Flash (1 KV head, 576 dim — MLA 아키텍처)는 급격한 프리필 (prefill) 성능 저하를 보여주었습니다:

컨텍스트 pp (t/s) vs pp512

pp512 1822 100%
pp4K 1054 58%
pp16K 358 20%
pp65K crash 발생 ---

이는 512에서 16K 컨텍스트로 넘어갈 때 80%의 하락을 의미합니다. 65K 벤치마크 테스트는 충돌(Vulkan DeviceLost)이 발생했습니다. 하지만, 이 데이터가 무엇을 보여주고 무엇을 보여주지 않는지에 대해 명확히 하고 싶습니다. 저는 16K와 65K 사이의 컨텍스트 크기는 테스트하지 않았으므로, 정확한 충돌 경계는 알 수 없습니다. 또한 저는 이 동일한 모델을 일상적인 사용에서 20K 이상의 컨텍스트로 충돌 없이 실행하고 있으므로, 16K가 절대적인 한계선은 아닙니다. 실패 지점은 그보다 높은 어딘가에 있습니다.
데이터에서 명확한 점은 다음과 같습니다: Vulkan에서 MLA의 프리필 (prefill) 스케일링은 표준 어텐션 (standard attention)보다 훨씬 더 나쁩니다. 이것이 완전한 충돌로 이어질지 아니면 단순히 매우 느려질지는 컨텍스트 크기와 VRAM 여유 공간에 따라 달라집니다. pp4K에서 pp16K로의 66% 하락은 측정된 실제 수치입니다. MLA의 KV 압축/압축 해제 커널 (compression/decompression kernel)은 Vulkan 백엔드에서 컨텍스트가 커짐에 따라 스케일링이 제대로 이루어지지 않는 것으로 보입니다. Vulkan에서 짧은 컨텍스트의 MLA 벤치마크를 긴 컨텍스트로 외삽(extrapolate)하지 마십시오. 또한 성능 저하가 선형적이라고 가정하지 마십시오. 성능 저하는 가속화되는 것으로 보입니다. 이는 백엔드 특유의 문제일 수 있습니다. CUDA나 Metal은 MLA의 어텐션 패턴을 더 잘 처리할 수도 있습니다.

발견 6: MoE 모델이 에이전트 작업(agentic work)을 위한 속도 × 지능 복합 지표에서 승리합니다.
속도 데이터와 Artificial Analysis Intelligence Index v4.1 점수를 결합하여 복합 지표(실제 소요 시간의 역수로 가중치를 둔 지능)를 산출했습니다. 점수 = AA Intel × (50s / 65K에서의 wall_clock_time)이므로, 50초의 wall_clock time은 1.0 × AA 승수와 같습니다.

순위 모델 AA 지수 Intel 크기 Wall (65K) 유형 Composite

1 Qwen3.6-35B-A3B 32 18G 54s MoE 29.4
2 Trinity-Mini 24 16G 48s MoE 24.9
3 Gemma-4-26B-A4B 26 14G 67s MoE 19.6
4 North-Mini-Code 21 15G 75s MoE 14.0
5 Ornith-9B / Qwen3.5-9B 15 6G 55s Dense 13.7
6 Qwen3.6-27B 37 16G 171s Dense 10.8
7 Gemma-4-12B 18 7G 115s Dense 7.8
8 Granite-4.0-H-Small 7 17G 67s Mamba2 5.2
9 Apriel-1.6-15B 19 9G 194s Dense 4.9
10 Ministral-3-14B 15 8G 167s Dense 4.5
11 Granite-4.1-8B 12 5G 152s Dense 4.0
12 Devstral-24B 17 15G 217s Dense 3.9

GLM-4.7-Flash는 제외됨 — 65K 데이터 없음 (MLA 충돌).
가장 지능적인 모델(Qwen3.6-27B, AA=37)이 6위를 차지하는 이유는 MoE 모델보다 3배 더 오래 걸리기 때문입니다. 최고 성능의 MoE 모델(Qwen3.6-35B-A3B, AA=32)은 속도의 3배에 불과한 시간으로 지능의 87%를 제공합니다. 모델이 여러 개의 짧은 출력 반복을 수행하는 에이전트 워크플로우에서는 이러한 트레이드오프가 유리합니다.
MoE 모델은 두 가지 측면에서 이점을 얻습니다: 빠른 디코드(활성 파라미터만 읽음)와 저렴한 GTT 스필(컨텍스트가 오버플로우를 강제할 때 활성 가중치만 PCIe를 통과함). 이러한 조합은 제약된 VRAM 환경의 긴 컨텍스트에서 비례적으로 강력하게 만듭니다.

요약 — 로컬 에이전트 LLM 배포를 위한 실질적인 시사점

tg128에 집착하는 것을 멈추세요. 65K 이상의 컨텍스트에서는 짧은 출력의 경우 프리필(prefill) 시간이 전체 벽시계 시간(wall-clock time)의 94–99%를 차지합니다. 대신 pp65K / pp131K를 벤치마킹하세요.
KV 헤드 수를 먼저 확인하세요. 모델 크기와 관계없이, 4 KV 헤드 × 128 차원 (토큰당 64 KB)이 8 KV 헤드 × 128 차원 (토큰당 160 KB)보다 긴 컨텍스트에서 훨씬 나은 확장성을 보여줍니다.
작업 중인 컨텍스트에서 F16 KV 캐시를 테스트하세요. MoE 및 소형 Dense 모델의 경우 Q8/Q4보다 20–53% 빠를 수 있습니다. 기존의

현재는 아키텍처(architecture)가 아닌 학습 품질(training quality)에 의해 성능이 저하되고 있습니다. 지켜볼 가치가 있습니다.

MLA는 컨텍스트(context)가 증가함에 따라 Vulkan에서 성능이 급격히 저하됩니다. GLM-4.7-Flash는 컨텍스트가 512에서 16K로 증가함에 따라 프리필(prefill) 속도가 80% 감소했으며, 65K에서는 충돌(crash)이 발생했습니다. 중간 정도의 컨텍스트에서는 사용 가능하지만(저는 매일 20K 이상에서 사용 중입니다), 스케일링 곡선(scaling curve)이 가파르고 비선형적입니다. 짧은 컨텍스트의 MLA 벤치마크를 그대로 확장하여 추측하지 마십시오.

모든 데이터는 llama.cpp 빌드 9860, Vulkan 백엔드, RX 7900 XT 20GB 환경에서 수집되었습니다. 사용 환경에 따라 결과는 다를 수 있습니다.