사용된 리소스:

• https://github.com/ikawrakow/ik_llama.cpp - 참조용 llama.cpp 포크 (fork)
• https://github.com/spiritbuun/buun-llama-cpp - TurboQuant 기능 테스트용
• https://huggingface.co/mudler - 모델용
• https://github.com/noonghunna/club-3090 - 속도 참조, 벤치마킹 및 설정 가이드용

나의 목표
최근 RTX 3090을 구하게 되었고, Qwen3.6-35B-A3B 모델을 실행하기 위한 최적의 구성을 찾으려 노력했습니다. 저의 우선순위는 명확했습니다:

• 적절한 속도를 희생하지 않으면서 가능한 최대의 품질 확보
• 긴 문서와 긴 에이전트 흐름 (agentic flows)을 처리하기 위한 최소 128k 컨텍스트 (context)

속도 벤치마크 (Speed Benchmarks)
두 가지 llama.cpp 포크 (club-3090에서 제안한 ik_llama 및 spiritbuun 포크)를 두 가지 주요 APEX 모델 버전 (I-Compact 및 I-Quality)과 함께 테스트했습니다. 다음은 모두 128k 컨텍스트 환경에서의 생성 속도 결과입니다.

분석: I-Compact를 사용한 ik_llama가 속도 면에서 압도적인 왕입니다. 하지만, I-Quality와 turbo8/turbo4 캐시를 사용하는 spiritbuun은 I-Quality를 사용하는 ik_llama와 동일한 속도를 제공합니다.

품질 비교
다음은 Qwen3.5-35B-A3B에 대한 APEX 저장소의 공식 데이터를 포함한 비교표입니다. 참고: 이것은 공식 APEX 벤치마크입니다. 3.6 전용 벤치마크 데이터는 찾을 수 없었지만, APEX 티어 간의 상대적 성능은 동일할 것입니다.

이론상으로 APEX I-Quality와 UD-Q4_K_XL은 거의 동일해 보입니다: 동일한 퍼플렉시티 (perplexity) (6.552 대 6.554), 유사한 KL 지표를 나타냅니다.

하지만 여기서 핵심은 이렇습니다: APEX I-Quality는 생성 속도가 약 7% 더 빠르며 (62.3 대 58.1 t/s), HellaSwag 점수도 약간 더 높게 (83.5% 대 83.0%) 제공합니다.
APEX I-Compact는 효율성의 챔피언입니다. 단 ~17 GB의 용량으로 탁월한 품질과 최대 속도를 제공하며, OOM (Out of Memory) 없이 컨텍스트 (context)를 256k까지 확장할 수 있습니다. 심지어 HellaSwag 점수에서 I-Quality와 동일한 수준(83.5%)을 기록합니다.

왜 turbo8/turbo4가 q8_0/q5_0보다 더 나은가
turbo8은 spiritbuun 포크 (fork)에서 나온 새로운 KV 캐시 (KV cache) 코덱입니다. 저자(@spiritbuun)는 X (Twitter)에 turbo8을 전통적인 q8_0 캐시와 비교한 벤치마크를 게시했습니다:

ctx turbo8 tg/s vs q8_0 turbo8 mean KLD vs q8_0 KLD

2048 31.34 +1.9% 0.007717 -12%
8192 30.22 +3.6% 0.009450 -8%
16384 29.40 +6.7% 0.005235 -14%
32768 28.06 +15% 0.003594 -8%

출처: https://x.com/spiritbuun/status/2062164396789412256
turbo8은 일관되게 더 빠르며 항상 더 낮은 KLD를 나타냅니다. 컨텍스트가 길어질수록 그 격차는 벌어지며, 32k 토큰에서는 속도가 +15%에 달합니다. 최적의 균형을 위해 turbo4와 비대칭적으로 사용하는 것(Keys에는 turbo8, Values에는 turbo4 사용)이 권장됩니다.

참고 1: PR #72 - spiritbuun에 필수적임
spiritbuun이 최고의 성능을 내려면 제가 저장소에 제출한 PR #72를 적용해야 합니다. 이전 변경 사항에서 프리필 (prefill) 동안 CUDA 그래프 캡처 (CUDA graph capture)를 무효화하는

이는 다른 이들에 의해도 문서화되었으며 그 논리도 타당합니다. 이러한 소규모 MoE (Mixture of Experts) 모델들은 매우 빠르기 때문에, MTP (Multi-Token Prediction)가 성능을 돕기보다는 오히려 저해할 수 있습니다. 따라서 최대 속도를 추구한다면 MTP를 비활성화해 보십시오 (단순히 플래그를 생략하면 됩니다).

실행 명령 (Launch Commands)

ik_llama + I-Compact (최대 속도)

!/bin/bash
/root/ik_llama.cpp/build/bin/llama-server \ -m /models/Qwen3.6-35B-A3B-APEX-MTP-I-Compact.gguf \ -b 4096 -ub 1024 \ --cache-ram 4096 \ --parallel-tool-calls \ --recurrent-ckpt-mode auto --merge-qkv \ -c 196608 -np 1 --no-mmap --mlock \ -ctk q8_0 -ctv q5_0 \ -vhad -vhad -ngl 99 \ --jinja --reasoning-budget 0 --flash-attn on \ --host 0.0.0.0 --port 8000 ```

spiritbuun + I-Quality + turbo8/turbo4 (최고 품질/컨텍스트)
```bash
!/bin/bash
/root/buun-llama-cpp/build/bin/llama-server \ -m /models/Qwen3.6-35B-A3B-APEX-MTP-I-Quality.gguf \ --host 0.0.0.0 --port 8000 \ --no-warmup \ -c 131072 \ -np 1 \ --no-mmap --mlock \ -ctk turbo8 -ctv turbo4 \ --jinja --reasoning-budget 0 \ --flash-attn on ```

마치며 (Final Thoughts)
이전 3060으로 유사한 포스트를 작성한 적이 있습니다. KV 캐시(KV caches)를 위한 turbo8/turbo4 방식은 해당 포스트에서 보고했던 속도(turbo4/turbo4)와 유사하게 작동하면서도, 키(keys)에 대한 turbo8의 우수한 일관성(coherence)을 보여준다고 말씀드리고 싶습니다.

추신: 이 포스트의 번역과 서식 지정에는 Hermes Agent(본문의 Quality 모델을 메인 모델로 사용)를 사용했습니다.

제출자: /u/old-mike
[link] [comments]