TurboQuant 현황 점검, 2026년 8월 — vLLM·llama.cpp·Ollama에 실제로 들어간 것

TurboQuant 현황 점검, 2026년 8월 -- vLLM·llama.cpp·Ollama에 실제로 들어간 것과 안 들어간 것

Google Research의 TurboQuant 논문이 나온 지 다섯 달이 지났습니다. "KV 캐시 4배 압축, 공짜"라는 이야기는 지금 어떤 추론 엔진을 쓰느냐에 따라 전혀 다른 세 가지 현실로 갈라져 있습니다. 한 엔진은 탑재하고 냉정한 벤치마크를 냈고, 한 엔진은 거부했고, 한 엔진의 구현은 죽었습니다.

이 글은 현황 점검이자 정정입니다. 저희가 앞서 쓴 TurboQuant 글 두 편은 3월에 돌던 "llama.cpp에 tq1_0~tq4_0 캐시 타입이 머지됐다"는 주장을 그대로 옮겼습니다. 틀린 내용이었습니다. 아래는 2026년 8월 말 기준으로 저장소가 실제로 말하는 것들이고, 전부 링크를 붙였습니다.

이 글은 TurboQuant 시리즈 Part 3입니다.

• Part 1: TurboQuant 원리 -- PolarQuant + QJL
• Part 2: TurboQuant 실전 -- llama.cpp 포크와 Python 패키지
• Part 3 (이 글): 엔진별로 실제 탑재된 것
• Part 4: A100 한 장에서 vLLM TurboQuant 실측 (준비 중)

한 줄 요약

하나만 기억하신다면: TurboQuant가 들어간 프로덕션 엔진은 vLLM뿐이고, 그 vLLM의 권고는 "용량이 꼭 필요한 게 아니면 FP8을 쓰라"입니다.

1. vLLM: 탑재했고, 측정했고, 정직하게 보고했다

TurboQuant가 정식 기능으로 존재하는 유일한 곳이 vLLM입니다. PR #38479가 2026년 4월 15일 머지되어 v0.20.0에 들어갔습니다. Triton 기반의 전용 TurboQuantAttentionBackend와 프리셋 네 개가 추가됐습니다.

vllm serve Qwen/Qwen3-8B --kv-cache-dtype turboquant_k8v4      # 키 FP8, 값 4비트 (~2.4배)
vllm serve Qwen/Qwen3-8B --kv-cache-dtype turboquant_4bit_nc   # 키·값 4비트 + norm 보정 (~3.4배)
vllm serve Qwen/Qwen3-8B --kv-cache-dtype turboquant_k3v4_nc   # 키 3비트, 값 4비트
vllm serve Qwen/Qwen3-8B --kv-cache-dtype turboquant_3bit_nc   # 키·값 3비트 (~4배 이상)

써보기 전에 알아둘 것 두 가지입니다.

• v0.20.0은 full-attention과 균일 sliding-window 트랜스포머만 지원했습니다. 하이브리드 Mamba/linear-attention 모델은 NotImplementedError를 냈고, 5월 5일 머지된 PR #39931이 Qwen3.5·Qwen3-Next를 추가했습니다 -- full_attention 레이어에만 양자화를 걸고 linear 레이어는 건너뛰는 방식입니다. chunked-prefill 이어받기 구간의 버그(#41726)가 아직 열려 있습니다.
• Ampere(A100)에서는 Triton float8 폴백이 필요했습니다. 1차 타깃은 Hopper입니다.

vLLM 자체 벤치마크가 말한 것

5월 11일 vLLM 팀이 "A First Comprehensive Study of TurboQuant"를 냈습니다. Llama-3.3-70B, Qwen3-30B-A3B(Instruct·Thinking), MiniMax-M2.7을 MRCR 장문 검색과 추론 벤치마크(AIME25, GPQA Diamond, MATH500, LiveCodeBench)로 평가했습니다. 지금까지 나온 공개 평가 중 가장 꼼꼼하고, 그 숫자는 하이프 속 숫자와 다릅니다.

정확도 (BF16 대비):

Qwen3-30B 256K 컨텍스트에서는 3비트 변형이 31~34% AUC까지 떨어졌습니다 -- 상대 기준 약 30% 손실입니다.

속도 (BF16 대비, Qwen3-30B):

용량: FP8 2배, k8v4 2.4배, 4bit-nc 3.4배, 3bit-nc 4배 이상. Llama-70B 버스트 부하에서 이 용량이 실제로 효과를 냈습니다 -- BF16은 메모리 포화로 P99 TTFT가 ~17초였는데 TurboQuant 변형은 3.5초 미만이었습니다. 다만 FP8이 1.3초로 가장 좋았습니다.

결론은 그대로 인용하면 *"FP8 remains the best default."* 쓸 만한 변형은 4bit-nc -- "1~4점의 완만한 정확도 손실로 최대 3.4배 KV 캐시 용량" -- 이고, 3비트 변형은 프로덕션에 권하지 않는다고 명시했습니다.

이게 뜻하는 것

논문의 헤드라인은 고립된 벡터의 왜곡률에 대한 것이었습니다. vLLM은 실제 서빙 스택에서 태스크 정확도와 처리량에 무슨 일이 생기는지 쟀습니다. 둘은 같은 것이 아닙니다. 3비트 키는 추론 벤치마크에서 20점을 잃고, Triton 커널은 FP8의 fused 경로보다 10~60% 느립니다. vLLM 안의 TurboQuant는 메모리에 묶인 장문 서빙을 위한 용량 도구이지, 공짜 점심이 아닙니다.

2. llama.cpp: 본류는 거부, 포크에서는 살아 있음

저희 이전 글이 틀렸던 부분이라 정확히 적겠습니다.

본류 ggml-org/llama.cpp에는 TurboQuant 캐시 타입이 없습니다. common/arg.cpp가 받아들이는 -ctk/-ctv 값은 f32, f16, bf16, q8_0, q4_0, q4_1, iq4_nl, q5_0, q5_1이 전부입니다. tq3_0도 turbo3도 없습니다.

경위는 이렇습니다.

• PR #21010 (Vulkan TQ3_0)은 프로젝트의 AI 생성 코드 정책 위반으로 닫혔습니다.
• PR #21089는 CPU 전용 tbq3_0/tbq4_0 타입을 추가했습니다. Qwen3.5-4B 기준 tbq4_0은 3.94배 압축에 q4_0과 비슷한 KLD, tbq3_0은 5.22배 압축에 예상되는 품질 손실, CPU 디코딩은 15.7에서 ~8 tok/s로 떨어졌습니다. 6월 2일 닫혔습니다. 메인테이너의 논리: Hadamard 회전은 이미 머지돼 있고, 기여 가이드라인이 요구하는 대로 같은 비트폭의 기존 타입 대비 우위를 여러 모델에서 증명하지 못했다.

이 거부는 근거가 있습니다. 본류의 우려는 "TurboQuant가 안 된다"가 아니라 "같은 비트에서 q4_0 + Hadamard보다 낫다는 걸 두 개 이상 모델에서 보여 달라"입니다. 그 기준을 맞춘 사람이 아직 없습니다.

한편 커뮤니티 토론(#20969)에서는 독립 구현이 꽤 인상적으로 쏟아졌습니다.

그리고 이들이 같은 공학적 결론으로 수렴했는데, 이 에피소드 전체에서 가장 쓸모 있는 기술적 산출물입니다.

1. Algorithm 1(PolarQuant MSE)만으로 충분합니다. QJL 잔차 단계는 오버헤드만 있고 측정 가능한 이득이 없어서 모든 포크가 뺐습니다.
2. 키는 값보다 비트가 더 필요합니다. 모델에 따라 K/V norm 격차가 182배까지 측정됐고, k4/v3식 비대칭 할당이 이제 표준입니다 (vLLM의 k8v4 프리셋이 같은 교훈입니다).
3. 블록 크기는 논문의 128보다 32가 낫습니다. flash-attention 병렬화 때문입니다.
4. norm 보정 (‖x‖ / ‖Q(x)‖를 저장했다가 디코딩 때 되돌림)은 비용 없이 perplexity를 개선합니다. vLLM 프리셋의 _nc 접미사가 이것입니다.

본인 하드웨어에서 llama.cpp를 쓰신다면 포크로 오늘 당장 4~5배 KV 압축을 얻을 수 있습니다. 다만 본류를 손으로 따라가는 브랜치 위에 서 있다는 건 알고 쓰셔야 합니다.

3. Ollama: 도착하자마자 사망

Ollama PR #15505는 이 중 가장 완성도 높은 구현이었습니다. OLLAMA_KV_CACHE_TYPE 프리셋 아홉 개(tq4/tq3/tq2, K 전용·V 전용 변형), FWHT 회전, Lloyd-Max 코드북, 아웃라이어 분리, fused inline-decode flash-attention 경로까지. Blackwell에서 tq3k가 f16 메모리의 ~80%를 유지하며 f16 디코딩 처리량의 60~75%를 냈다고 보고됐습니다.

5월 30일 작성자 본인이 닫았습니다. Ollama의 #16031이 GGUF 추론을 외부 본류 llama-server로 옮겼기 때문입니다. Ollama에는 더 이상 패치할 자체 어텐션 경로가 없습니다. Ollama의 TurboQuant는 이제 본류 llama.cpp의 TurboQuant에 달려 있는데 -- 위에서 보셨듯 거부됐습니다.

그래서 "Ollama가 TurboQuant를 지원하나요?"에 대한 정직한 답은: 아니요, llama.cpp 본류가 받기 전까지는 아닙니다.

4. HuggingFace: Google이 아닌 독립 패키지

pip install turboquant는 동작하고, Transformers의 past_key_values에 그대로 꽂는 TurboQuantCache, 벡터 양자화기 TurboQuantMSE, OpenAI 호환 서버를 줍니다. back2matching이 배포하는 Apache-2.0 패키지이고, 0.1.0과 0.2.0이 2026년 3월 25~27일에 나왔습니다.

README가 분명히 밝힙니다: *"This is an independent implementation, not affiliated with Google Research."* Google은 공식 구현을 내지 않았습니다. 이 패키지는 잘 만든 커뮤니티 재구현이고 실험에는 좋지만, 레퍼런스는 아닙니다.

5. 논문이 주장한 것 vs 실제로 나온 것

6. 그래서 무엇을 해야 하나

• vLLM으로 서빙, 장문 컨텍스트에서 메모리가 병목: turboquant_4bit_nc를 켜고 *본인 태스크*로 재고, fp8을 대조군으로 두세요. 3비트 변형은 건너뛰세요.
• vLLM으로 서빙, 메모리 병목 아님: fp8. 끝.
• Mac이나 GPU 한 장에서 llama.cpp: 포크(turbo3/turbo4, -fa on)는 실제로 빠릅니다. 품질이 중요하면 키에는 turbo4를 쓰세요.
• Ollama: 할 수 있는 게 없습니다. 본류를 기다리세요.
• 연구 / 노트북: pip install turboquant, 또는 PolarQuant를 직접 구현하세요 -- 60줄쯤 됩니다 (이 시리즈 Part 5가 실제 KV 텐서로 그걸 합니다).

Part 4에서는 남의 표를 읽는 걸 멈추고, vLLM 프리셋 네 개를 FP8·BF16과 함께 A100 한 장, 8B 모델에서 직접 돌립니다 -- vLLM 연구가 다루지 않은 크기입니다.

참고 자료

• Zandieh et al., TurboQuant: Online Vector Quantization with Near-optimal Distortion Rate, ICLR 2026
• vLLM, A First Comprehensive Study of TurboQuant: Accuracy and Performance (2026-05-11)
• vLLM PR #38479 (4월 15일 머지) · PR #39931 하이브리드 모델 (5월 5일 머지) · Issue #41726
• llama.cpp PR #21089 (6월 2일 닫힘) · PR #21010 · Discussion #20969
• Ollama PR #15505 (5월 30일 닫힘)
• turboquant on PyPI · back2matching/turboquant