나는 정신병에 걸린 것 같은 느낌이 든다. 여기 사람들은 30~100+ tok/s (추측적 디코딩 사용 시 100+) 의 성능을 3090 GPU 에서 Qwen 3.6 27B 로 보고 있다. 나는 이를 복제하려고 시도하지만, 내 성능 숫자는 그들과 비교해 볼 수 없다.

나는 llama.cpp 를 Unsloth 의 Q4XL 과 Q4_K_M GGUF 와 함께 사용했다. 이 설정에서 50k 컨텍스트 길이는 약 10 tok/s 를 얻었다. 또한 ik_llama.cpp 를 더 작은 GGUF (https://huggingface.co/sokann/Qwen3.6-27B-GGUF-5.076bpw) 와 함께 사용했다. 이는 Unsloth 의 GGUF 보다 약 1GB 작으며, 이 조합에서는 50k 컨텍스트 길이를 기준으로 약 18~19 tok/s 를 얻었다. (참고: 두 설정 모두 VRAM 에 모든 것이 들어간다.)

나는 ik_llama.cpp 로그를 Claude Sonnet 4.6 에 제출했고, 다음과 같은 분석을 제시했다:

로그의 두 컴퓨트 버퍼를 보라:

CUDA0 compute buffer size = 2020.00 MiB ← GPU
CUDA_Host compute buffer size = 552.05 MiB ← CPU
graph splits = 2

graph splits = 2 는 각 생성된 토큰마다 다음이 필요함을 의미한다:

1. CPU 로 동기화 → CPU 가 SSM 회귀 상태 업데이트 계산 (CPU 측 작업 552 MiB)
2. GPU 로 동기화 → GPU 가 완료

CUDA_Host compute buffer 는 단순 데이터 전송용 메모리가 아니라, 각 토큰 단계에서 CPU 가 연산을 실행하는 실제 컴퓨트 버퍼이다. SSM 상태 회귀 (ssm_d_state = 128, ssm_d_inner = 6144) 는 정적 CUDA 그래프로 표현할 수 없으며, CPU 측에서 순차적으로 수행되어야 한다.

이것이 HAVE_FANCY_SIMD 가 중요한 이유이다: 이 552 MiB 의 CPU 작업은 AVX-VNNI/AVX-512 와 함께 훨씬 빠른 디양화 코어 (iq4_ks, q6_0) 를 사용한다. 이를 사용하지 않으면 CPU 부분이 병목이 되지, GPU 가 아니다.

모델은 가중치 저장 측면에서