llama.cpp에는 "--split-mode tensor"와 관련된 문제가 있습니다. 결과는 매우 훌륭하지만, 비양자화(non-quantized) KV 캐시(KV caches)만 지원한다는 단점이 있습니다. 바로 이 이유 때문에 많은 사람들이 적절한 크기의 KV 캐시를 사용하는 방향을 선택하고 텐서 병렬화 (tensor parallelism)를 무시하곤 합니다.
저는 이 문제를 해결하기 위해 시도해 보았습니다 - https://github.com/RedToasty/llama.cpp_qts - 이 코드는 오늘 날짜의 메인라인 (mainline)에서 브랜치되었으며, 최소한의 변경 사항만 포함하고 있습니다.
저는 개인적으로 3060 12gb + 4070 Super 12gb를 사용하여 총 24gb를 운용하고 있습니다.
다음은 Q8_0/Q8_0 및 "-sm tensor"를 사용한 결과입니다:
llama-bench.exe -m Qwen3.6-27B-Q4_K_M.gguf -sm tensor -fa 1 -ctk q8_0 -ctv q8_0 -p 128 -n 32 -b 128 -ub 128
| Model | Size | Params | Backend | NGL | Batch | UBatch | Type K | Type V | SM | FA | Test | Tokens/s |
|---|
| Qwen3.5 27B Q4_K Medium | 15.65 GiB | 26.90 B | CUDA | 99 | 128 | 128 | q8_0 | q8_0 | tensor | 1 | pp128 | 544.82 ± 6.01 |
| Qwen3.5 27B Q4_K Medium | 15.65 GiB | 26.90 B | CUDA | 99 | 128 | 128 | q8_0 | q8_0 | tensor | 1 | tg32 | 30.05 ± 0.38 |
텐서 분할 (tensor splitting)을 사용하지 않았을 때의 결과입니다:
llama-bench.exe -m Qwen3.6-27B-Q4_K_M.gguf -fa 1 -ctk q8_0 -ctv q8_0 -p 128 -n 32 -b 128 -ub 128
| Model | Size | Params | Backend | NGL | Batch | UBatch | Type K | Type V | FA | Test | Tokens/s |
|---|
| Qwen3.5 27B Q4_K Medium | 15.65 GiB | 26.90 B | CUDA | 99 | 128 | 128 | q8_0 | q8_0 | 1 | pp128 | 582.60 ± 28.57 |
| Qwen3.5 27B Q4_K Medium | 15.65 GiB | 26.90 B | CUDA | 99 | 128 | 128 | q8_0 | q8_0 | 1 | tg32 | 21.22 ± 0.52 |
품질 저하 없이 40% 이상의 속도 향상을 보였습니다. 이 브랜치는 또한 최신 mtp 변경 사항을 지원합니다. 제가 개인적으로 사용해 본 명령어는 다음과 같습니다:
--spec-type draft-mtp --spec-draft-p-min 0.75 --spec-draft-n-max 2
개인적인 사용 환경에서는 '이야기 쓰기(write a story)'와 같은 컨텍스트에서 토큰당 초당 속도(tps)가 약 25tps에서 약 40tps로 향상되었습니다. 이는 VRAM 제한 때문일 수 있지만, 에이전트 코딩 및 더 긴 컨텍스트를 사용할 때는 ngram-mod를 사용했을 때 더 만족스러웠습니다.
dual 5060 ti 또는 유사한 장비를 사용하는 분들의 피드백을 듣고 싶습니다. 또한 dual Vulkan 관련 내용도 흥미로울 것 같습니다. 버그가 있는지 찾아보고 있습니다.
요약(TLDR): 만약 dual GPU를 사용한다면, 이 포크를 가져오거나 빌드하고 현재 명령어 라인에 -sm tensor를 추가하여 50% 더 빨라지는지 확인해 보세요!
참고: MoE 모델과 -sm tensor 사이에 관련 없는 문제가 있다는 것을 방금 발견했습니다. 당분간은 Qwen3.6 27b/9b 등 밀집(dense) 모델을 대상으로 테스트해 주세요. 무료로 50% 향상을 가져다주는 만큼, Tensor split 기능이 많이 활용되지 않는 것 같습니다! 이것이 인기를 얻는다면 MoE를 수정하고 Turboquants를 통합하는 것을 고려하겠습니다.