음, 이것은 spiritbuun의 llama.cpp 포크(fork)에 대한 감사 게시물입니다. 몇 주 전, 저는 제 3060에서 보조 모델을 사용하기 위해 어떤 구성이 가장 좋을지 포크와 설정들을 테스트하고 있었는데, 승리한 조합은 Qwen3.6-35B-A3B 모델을 위한 Spiritbuun의 포크 + CUDA + mudler의 Apex I-Compact 양자화(quantization)였습니다. https://www.reddit.com/r/LocalLLaMA/comments/1tq0h1p/qwen3635ba3bapex_128k_ctx_on_rtx_3060_12gb_37_ts/ 를 참조하세요. 그 후 Spiritbuun이 turbo8을 출시했고, 저는 제 키 캐시(key cache)를 그것으로 전환했습니다. 속도는 동일하면서 정밀도는 두 배였습니다. 좋았습니다. 하지만 이제 그는 r/LocalLLama에서 언급할 가치가 있다고 생각되는 기능을 통합했습니다. VBR이란 무엇일까요? 전체 컨텍스트(context)에 대해 고정된 KV 양자화 계층을 사용하는 대신, VBR은 하한선(예: 3.25 bits/value인 turbo3_tcq)을 설정할 수 있게 해주며 진입 계층(f16)을 설정합니다. 컨텍스트가 커짐에 따라, VRAM 예산 내에 머물기 위해 캐시는 turbo(turbo8, turbo4, 3_tcq, 2_tcq, 1_tcq) 사다리를 통해 단계별로 저하(degrade)됩니다. 따라서 다음과 같이 실행하기만 하면 됩니다: llama-server -m model.gguf -ct vbr. 개발자가 말했듯이: "그 단일 플래그가 제품의 전부입니다. 가중치(weights)와 연산(compute) 후에 남은 것에서 KV VRAM 예산을 도출하고, 하한선 계층에서 수용 가능한 가장 큰 컨텍스트(모델의 학습 길이에 제한됨)를 공지하며, 컨텍스트가 채워짐에 따라 실시간으로 계층을 저하시킵니다. 추측해야 할 컨텍스트 길기도 없고, 선택해야 할 코덱(codec)도 없습니다. -v와 함께 실행하여 VBR이 저하되는 #… 단계를 관찰하세요." 결과적으로: 고정된 n_ctx 대신 동적 컨텍스트(dynamic context)를 얻게 됩니다. 예산은 시작 시 남은 VRAM에서 계산되며, 디코딩(decode) 중에 VRAM이 부족해지면 저하 컨트롤러(degrade controller)가 작동합니다. 그리고 저하 하한선 및 더 많은 것들을 조정할 수 있습니다.

저의 실행 명령어는 다음과 같습니다:
/root/buun-llama-cpp/build/bin/llama-server \
-m /models/Qwen3.6-35B-A3B-APEX-MTP-I-Compact.gguf \
--host 0.0.0.0 --port 8000 \
--no-mmap --mlock \
-ctk turbo8 -ctv vbr --vbr-floor turbo3_tcq \
--jinja --reasoning-budget 1024 \
--flash-attn on -ngl 99 --n-cpu-moe 20

키 캐시(key cache)를 turbo8로 고정하고, 저하 하한선(degrade floor)을 turbo3_tcq로 설정한 것을 확인할 수 있습니다.

저의 설정:
RTX 3060 12GB
모델: Qwen3.6-35B-A3B-APEX-MTP-I-Compact
설정: -ctk turbo8 -ctv vbr --vbr-floor turbo3_tcq --flash-attn on

수치 (club-3090의 bench.sh, 5회 실행):

따라서 VBR은 매칭된 turbo8/turbo4 방식보다 약 4% 정도 느릴 뿐이지만, TTFT는 거의 2배 더 빠르고 VRAM 사용량은 더 낮습니다. 컨텍스트 예산(context budget)은 남은 VRAM에 맞게 216k 토큰으로 자동 조정되었습니다.

좋았던 점:

• 저하 컨트롤러(degrade controller)가 매끄럽습니다. 작동할 때 TPS의 눈에 띄는 저하가 없습니다.
• TTFT가 절반으로 줄어드는 것은 실제 사용 시 확연히 느껴집니다.
• 포크(fork)가 견고합니다. Spiritbuun은 TurboQuant 회전 행렬(rotation matrices)부터 물리 페이지를 온디맨드(on demand)로 매핑하는 VMM 풀(pool)에 이르기까지 엄청난 노력을 기울였습니다.

주의할 점:
f16<->t8 비대칭 커널(asymmetric kernels)이 융합(fused)되는 과정에서 버그를 발견했습니다. 이로 인해 turbo8-K / f16-V (vbr 사용 시 저하 전의 기준점) 설정에서 출력 손상이 발생했습니다. 해당 커밋을 되돌렸으며 현재는 모두 정상입니다. Spiritbuun도 이 문제를 인지하고 있습니다.

제한된 VRAM에서 로컬 추론(local inference)을 밀어붙이고 있다면 이 포크를 확인해 볼 가치가 있습니다.

포크: https://github.com/spiritbuun/llama.cpp
제출자: /u/old-mike [link] [comments]