먼저, r/LocalLLaMA 커뮤니티와 3090 클럽에 큰 감사를 드립니다. 이 벤치마크는 여러분이 공유해주신 레시피들로부터 시작되었습니다...

이것은 동일한 모델의 두 가지 양자화 (quantization) 버전에 대해 5개의 엔진 (3개의 llama.cpp 포크 + 메인라인 + Lucebox)을 비교한 제 하드웨어(Xeon E5-2666v3, 64GB RAM, 단일 RTX 3090 24GB)에서의 결과입니다.

저는 https://github.com/noonghunna/club-3090/tree/master 의 벤치마크 스크립트와 긴 프롬프트 (prompt)를 구축하기 위해 en8wiki를 사용하는 두 개의 간단한 스크립트를 사용했습니다.

요약 표
포크 (fork) → 투기적 디코딩 (speculative type) 순으로 정렬되었습니다. 주요 지표: decode_TPS (코드 및 서사), TTFT, VRAM 사용량, 그리고 컨텍스트 일관성 (72k에서 128k로 채워진 컨텍스트로 이동할 때의 생성 속도 저하).

Fork / Engine	Speculative Type	Model / Quant	Code DP	Narr. DP	TTFT	VRAM (MiB)	Gen 72k	Gen 128k	Deg. (72k→128k)
ik_llama (ubergarm config)	MTP n_max=4	Qwen3.6-27B-IQ4_KS	89.2	63.9	361ms	22304	34.6	23.5	−32.1%
ik_llama + ngram	ngram+MTP	Qwen3.6-27B-IQ4_KS	87.8	58.6	341ms	20508	32.1	24.1	−24.9%
ik_llama (Standard config)	MTP n_max=2	Qwen3.6-27B-IQ4_KS	73.1	61.7	357ms	20208	33.8	25.4	−24.8%
mainline llama.cpp	MTP n_max=1	Qwen3.6-27B-Q4_K_M	64.7	52.5	288ms	21354	33.4	31.2	−6.6%
Spiritbuun	MTP	Qwen3.6-27B-Q4_K_M	59.7	45.7	294ms	22066	34.8	31.5	−9.5%
beellama	DFlash (Draft GGUF)	Qwen3.6-27B-Q4_K_M	96.8	45.6	504ms	20814	22.9*	27.1	−41.3%**
Spiritbuun	DFlash	Qwen3.6-27B-Q4_K_M	66.9	30.4	300ms	23356	—	—	—
LUCEBOX	DFlash (TQ3 KV)	Qwen3.6-27B-Q4_K_M	32.6	32.5	448ms	20680	27.0	—	—

ik_llama — "모든 것"을 수행하는 포크
네이티브 MTP 지원, merge-qkv, 순환 체크포인트 (recurrent checkpoints), 그리고 멀티 백엔드 투기적 디코딩 (multi-backend speculative decoding)을 갖춘 llama.cpp의 포크입니다. IQ4_KS 양자화 (ubergarm 제작)로 테스트되었습니다.

ik_llama + MTP+ngram (ngram-mod + mtp)
훌륭한 코드 생성 능력을 보여줍니다. ngram 초안 (n_max=4, size 16)과 MTP (n_max=3)를 결합합니다. 코드는 초당 87.8 토큰 (decode tokens/sec)에 도달하며, 이는 메인라인 대비 엄청난 도약입니다.

VRAM: 20508 MiB (GPU 사용률 82%)
컨텍스트 저하 (Context degradation): −25% (32.1→24.1 gen_tps).

컨텍스트가 채워질 때 눈에 띄는 성능 저하가 발생합니다.

ik_llama + MTP (ubergarm 튜닝 설정)
최고의 서사(Narrative) 속도: 63.9 DP, 전체 벤치마크 중 가장 높음. 코드(Code)는 89.2 DP를 기록함.

추가 설정: -muge --merge-qkv -mtprot iq4_ks -cram 32768 --slot-save-path /root/slot --ctx-checkpoints 32
VRAM: 22304 MiB. 슬롯 체크포인트(slot checkpoints)로 인해 VRAM 사용량이 더 높음.
컨텍스트 저하 (Context degradation): −32% (34.6→23.5). 모든 설정 중 가장 심한 저하.

ik_llama + MTP (표준 설정)
네이티브 MTP의 기준점(Baseline). ubergarm의 권장 조정 사항이나 하이브리드 ngram 모듈 없이 표준 파라미터(n_max=2)로 실행함. 코드에서 73.1 DP, 서사에서 61.7 DP의 균형 잡힌 성능을 제공함.

VRAM: 20208 MiB.
컨텍스트 저하 (Context degradation): −25% (33.8→25.4 gen_tps).

ik_llama + DFlash
beellama의 독립적인 초안 모델(draft model)로 테스트함. 코드는 96.8 DP로 MTP+ngram과 경쟁할 만한 수준이지만, 서사 성능은 크게 저하됨 (45.7 DP). 별도의 초안 모델 로딩 때문인지 TTFT(Time To First Token)가 높음 (504ms).

mainline llama.cpp — 레퍼런스 (The Reference)
포크(fork)나 패치(patch) 없음. 업스트림(Upstream) 추측적 MTP (speculative MTP). 표준 Q4_K_M 양자화 (quantization) 적용.

코드: 64.7 DP | 서사: 52.6 DP
TTFT: 288ms — 전체 중 가장 낮으며, 오버헤드(overhead)가 없음
컨텍스트 일관성 (Context consistency): 0% 저하 (72k와 128k 사이에서 31.3→31.3 DP). 이는 중요한 지점임: mainline은 컨텍스트 길이에 상관없이 속도를 유지함 (혹은 이상치(outlier)일 수도 있음).

순수 처리량(raw throughput) 면에서 가장 빠르지는 않지만, 가장 예측 가능한 성능을 보여줌.

Spiritbuun — 최적화된 MTP, 실패한 DFlash
Spiritbuun MTP
최적화된 MTP (turbo cache, flash-attn)가 적용된 포크. Q4_K_M 양자화 적용.
Qwen 3.6 35B A3B MoE 모델에서 APEX 양자화(관심 있다면 관련 포스트를 참조하세요)와 결합했을 때 최고의 결과를 보여주었기에 이 모델을 테스트함.

코드: 59.7 DP | 서사: 45.7 DP
컨텍스트 저하 (Context degradation): −9%. mainline 이후 가장 우수한 일관성.
TTFT: 294ms — mainline과 거의 동일함

Spiritbuun DFlash
자체 초안 모델로 테스트함. MTP 속도에 도달하는 데 실패함: 코드 67.0 DP, 서사 30.4 DP. 긴 컨텍스트 성능은 테스트하지 않았는데, 그럴 가치가 없어 보였기 때문임.

beellama DFlash — 압도적인 코드 속도, 높은 TTFT 비용
자체 초안 모델 (anbeeld-Qwen3.6-27B-DFlash-IQ4_XS.gguf)을 사용하며, cross-ctx 1024 및 통합 KV (unified KV)를 적용함.

코드 (Code): 96.8 DP — 전체 2위, ik_llama와 매우 근접함
서사 (Narrative): 45.7 DP
단점: 504ms의 TTFT (메인라인의 거의 두 배). 첫 단어가 나오는 데 0.5초가 걸림.
VRAM: 20814 MiB. 중간 정도의 GPU 사용률 (73%).
컨텍스트 (Context): 128k에서 27.1 DP 유지. 긴 컨텍스트에서는 ik_llama MTP보다 성능이 좋음.

LUCEBOX DFlash — 나에게는 작동하지 않음
DFlash, TQ3 KV 캐시, PFlash를 사용하는 독립적인 서버 엔진!

코드 (Code): 32.7 DP | 서사 (Narrative): 32.5 DP
많은 경우에서 투기적 디코딩 (speculative decoding) 없이 실행하는 것보다 성능이 떨어짐.

내가 사용법을 일관되게 이해하지 못한 것일까? 내가 incus 컨테이너에서 사용한 환경 변수들:
environment.DFLASH_FP_USE_BSA: "1" environment.DFLASH_HOST: 0.0.0.0 environment.DFLASH_KVFLASH: auto environment.DFLASH_PORT: "8080" environment.DFLASH_PREFILL_DRAFTER: /opt/lucebox-hub/server/models/unsloth-Qwen3-0.6B-BF16.gguf environment.DFLASH_PREFILL_MODE: auto environment.DFLASH_SERVER_BIN: /opt/lucebox-hub/server/build/dflash_server environment.DFLASH_TARGET: /opt/lucebox-hub/server/models/Qwen3.6-27B-Q4_K_M.gguf environment.DFLASH27B_KV_TQ3: "1"

일관성 판정 (Consistency Verdict)
순수하게 실사용 일관성(컨텍스트 길이에 따른 속도 안정성 + 낮은 TTFT + 낮은 VRAM 오버헤드)을 기준으로 순위를 매긴다면:

mainline llama.cpp MTP — 일관성 측면에서 명백한 승자. 72k와 128k 사이에서 성능 저하가 거의 없음. 가장 낮은 TTFT (288ms). 안정적인 VRAM (~21GB). 외부 초안 모델에 대한 의존성 없음. 성능이 무너지거나, 급증하거나, 스로틀링(throttling)이 발생하지 않음.
Spiritbuun MTP — 성능 저하가 단 9%에 불과하며, TTFT 294ms로 매우 안정적임. 메인라인보다 처리량(throughput)은 약간 낮지만 놀라울 정도로 예측 가능함.
LUCEBOX DFlash — 기술적으로는 일관적이지만 (0.1% 변동성), 일관되게 느림. 나에게는 유용하지 않음.
ik_llama 설정들 — 짧은 컨텍스트에서는 빠르지만, 긴 컨텍스트에서는 큰 대가를 치름 (-25%에서 -32% 성능 저하).

내 의견: 메인라인과 Spiritbuun 사이의 차이는 미미함 (~3-5 DP).

하지만 메인라인(mainline)의 성능 저하가 없고 가장 낮은 TTFT (Time To First Token)를 기록했다는 점은 가장 실용적으로 일관된 설정임을 의미합니다. 긴 문서나 RAG (Retrieval-Augmented Generation) 파이프라인을 실행하고 있다면, 메인라인은 당신을 실망시키지 않을 것입니다. ik_llama는 속도 면에서 승리했지만, 이는 짧은 컨텍스트 (short context)를 전제로 한 것입니다.

최종 권장 사항

우선순위	최적의 옵션	이유
코드 속도	ik_llama MTP+ngram	98.5 DP, 베이스라인의 두 배
서사 속도	ik_llama MTP (ubergarm)	63.9 DP
컨텍스트 일관성	mainline llama.cpp	0% 성능 저하, 가장 낮은 TTFT
속도 + 안정성 균형	Spiritbuun MTP	메인라인에 근접한 일관성과 약간 더 나은 처리량 (throughput)
낮은 TTFT	mainline llama.cpp	288ms, 오버헤드 없음

여러분의 생각은 어떠신가요?
submitted by /u/old-mike
[link] [comments]