TurboQuant vLLM, A100 한 장에서 실측 — 8B 모델에서 프리셋 4개의 용량·속도·정확도

TurboQuant vLLM, A100 한 장에서 실측 -- 프리셋 넷 중 하나는 지금 고장 나 있다

TurboQuant를 정식으로 실은 추론 엔진은 vLLM 하나입니다. 그런데 vLLM이 직접 낸 벤치마크(Part 3 참고)는 H100 위의 30B~200B 모델 이야기였습니다. GPU 한 장으로 8B를 돌리는 사람, 그러니까 품질을 좀 내주고 용량을 받을까 실제로 고민하는 사람의 질문에는 아무도 답하지 않았습니다. 그래서 직접 쟀습니다. 결론부터: 용량은 약속대로 최대 3.5배 나오지만, A100에서는 처리량을 절반 가까이 내놓아야 하고, 프리셋 하나(k8v4)는 출력이 망가지는 버그가 있습니다.

측정 대상은 KV dtype 여섯 개입니다. bf16, fp8, 그리고 TurboQuant 프리셋 4종. 모델은 Qwen3-8B(bf16 가중치), 엔진은 vLLM 0.28.0, GPU는 A100 80GB 한 장. dtype마다 KV 용량, 배치 처리량, 32K 컨텍스트 디코드, needle-in-a-haystack, GSM8K 200문항을 돌렸습니다.

1. 용량: 약속한 만큼 나온다

!dtype별 KV 용량

vLLM 할당자가 출력한 값 그대로입니다.

bf16으로 40만 토큰 들어가던 캐시에 3bit-nc는 137만 토큰이 들어갑니다. 고민이 "이 GPU에 장문 사용자를 몇 명 태우나"라면, 비트 산수가 약속한 숫자를 그대로 받습니다.

2. 속도: Ampere에선 절반을 내놓아야 한다

!처리량과 32K 디코드

TTFT만 멀쩡합니다. 프리필은 연산이 병목이라 양자화 저장 비용이 묻히거든요. 나머지는 비쌉니다. 배치 처리량은 반토막, 32K 디코드는 bf16의 3분의 1 수준까지 떨어집니다.

vLLM 벤치마크는 Hopper에서 기준 대비 73~80%라고 했습니다. 여기서 잰 값은 51~65%. 차이의 원인은 하드웨어입니다. A100에는 fp8 텐서코어가 없어서 TurboQuant의 Triton 커널이 float8e4b15 폴백 경로로 돕니다. PR에 적힌 "1차 타깃은 Hopper"라는 문장, 문자 그대로 받아들이는 게 맞습니다.

이 표에서 진짜 주인공은 따로 있습니다. A100에서 fp8은 bf16보다 3% 빠르면서 용량이 2배입니다. 타협이 아니라 그냥 업그레이드라는 뜻입니다.

3. 정확도: 셋은 멀쩡하고, k8v4는 고장

!dtype별 정확도

이 표는 두 가지를 조심해서 읽어야 합니다.

첫째, k8v4 줄. GSM8K가 3.5%로 나왔을 때 처음 든 생각은 하네스가 깨졌다는 것이었습니다. 답 파싱이 어긋났거나, 채팅 템플릿이 잘못 들어갔거나. 그래서 같은 하네스에 4bit_nc를 그대로 태웠더니 91%. 하네스는 멀쩡했습니다. 답안을 열어보고 나서야 정체를 알았습니다.

Alright, the first and then the final answer.

Alright, the first and then the final answer.

Alright, the first and then the final answer.
...

같은 문장이 끝까지 반복됩니다. 더 고약한 건 짧은 답은 멀쩡하게 나온다는 점입니다. "프랑스 수도는?"에는 "Paris."라고 답합니다. 스모크 테스트로 안 잡히는 이유입니다. 생성이 길어지고 양자화된 키가 쌓일수록 무너집니다. k8v4는 키를 fp8로 저장하는 프리셋이고, Ampere에서 그 fp8 경로가 바로 위에서 말한 폴백입니다. 증상이 가리키는 곳도 거기고요. Ampere에서 turboquant_k8v4는 자체 평가 없이 켜면 안 됩니다. 참고로 Hopper에서 잰 vLLM 벤치마크는 k8v4를 가장 안전한 프리셋으로 꼽았습니다. Ampere 검증이 따로 필요했던 이유가 바로 이겁니다.

둘째, 3비트 줄이 vLLM 결과보다 좋아 보이는 것. 좋아하긴 이릅니다. vLLM이 잰 -20점은 AIME25와 LiveCodeBench, 그러니까 긴 thinking 트레이스가 붙는 어려운 추론이었고 컨텍스트도 256K까지 갔습니다. 여기 GSM8K는 4K 컨텍스트의 짧은 산수에 no-think 디코딩입니다. NIAH는 검색 과제라 _nc 계열이 원래 잘 버티고요(Part 6에 norm 보정이 어텐션 검색을 왜 살리는지 나옵니다). 쉬운 과제는 3비트 키를 견딥니다. 어려운 추론은 못 견딥니다. 두 측정이 다 맞습니다. 쉬운 쪽 끝과 어려운 쪽 끝을 각각 잡고 있을 뿐입니다.

4. 그래서 A100에서는 뭘 켜야 하나

한 줄 요약: A100의 TurboQuant는 처리량 절반을 받고 용량을 파는 장사이고, 프리셋 넷 중 하나는 지금 물건이 불량입니다. Hopper라면 vLLM 자체 벤치마크를 믿으세요. 커널이 그쪽 기준으로 쓰였습니다.

하네스: bench-vllm-tq.py(첨부). dtype마다 새 프로세스, 전 구간 greedy.

하드웨어: A100 80GB × 1, 드라이버 535 / CUDA 12.2. 소프트웨어: vLLM 0.28.0(+cu129), Qwen3-8B bf16, 최대 컨텍스트 40,960.

총 소요: 약 70분. 원본 결과: 글 번들의 vllm-tq.json.

확인 일자: 2026-08-31.

참고 자료

• Part 3: TurboQuant 현황 점검 · Part 5: llama.cpp 포크 · Part 6: 밑바닥부터
• vLLM, A First Comprehensive Study of TurboQuant · PR #38479
• Zandieh et al., TurboQuant, ICLR 2026