QVAC TurboQuant 공개, 로컬 AI의 긴 문맥 메모리 압축

AI 요약

• 무슨 일: Tether AI가 QVAC SDK와 qvac-fabric-llm.cpp에 TurboQuant KV cache 압축 구현을 공개했습니다.
  • 발표일은 2026년 6월 1일이고, 기반 연구는 Google Research가 2026년 3월 24일 공개한 TurboQuant입니다.
• 수치: Tether는 26만 2000토큰에서 4B 모델 KV cache가 약 8GB를 쓸 수 있다고 설명합니다.
  • QVAC 구현은 TBQ3_0, TBQ4_0, PQ3_0, PQ4_0와 Vulkan inference kernels를 내세웁니다.
• 주의점: 공개 벤치마크는 품질 손실이 작다는 항목과 prompt processing 속도 저하 항목을 함께 보여줍니다.

Tether AI Research Group이 2026년 6월 1일 QVAC SDK 업데이트를 발표하면서 Google Research의 TurboQuant를 로컬·엣지 AI 엔진에 넣었다고 밝혔습니다. 발표문은 "데이터센터 크기의 메모리"라는 문구를 앞세우지만, 개발자가 먼저 봐야 할 대상은 더 작습니다. 긴 대화와 큰 문서를 처리할 때 GPU·NPU 메모리를 빠르게 채우는 KV cache입니다. QVAC 쪽 설명에 따르면 26만 2000토큰 규모의 세션에서 4B 모델의 KV cache만 약 8GB를 차지할 수 있고, 같은 길이의 세션 4개는 모델 가중치를 올리기 전 cache만 약 32GB까지 갈 수 있습니다.

이 발표는 새 모델 출시가 아닙니다. QVAC Fabric이라는 로컬 inference 엔진에 KV cache quantization을 얹은 배포 뉴스입니다. 그래서 이번 글의 질문도 "Tether가 AI 회사가 됐나"보다 "Google Research의 메모리 압축 연구가 실제 로컬 LLM 실행 경로에 들어가면 숫자가 어떻게 바뀌나"에 가깝습니다. 공식 GitHub 저장소 tetherto/qvac-fabric-llm.cpp는 llama.cpp fork이며, README는 TurboQuant KV cache quantization을 upstream에 없는 exclusive feature로 적고 있습니다.

Google Research가 TurboQuant를 공개한 날짜는 2026년 3월 24일입니다. Google 블로그는 TurboQuant, Quantized Johnson-Lindenstrauss, PolarQuant를 함께 설명하며, 고차원 벡터를 다루는 LLM KV cache와 vector search의 메모리 병목을 겨냥한다고 밝혔습니다. arXiv 논문 2504.19874는 2025년 4월 28일 제출됐습니다. 초록은 TurboQuant가 online vector quantization에서 near-optimal distortion rate를 목표로 하며 3.5 bits per channel에서 KV cache quality neutrality를 보였다고 설명합니다.

.

LLM inference에서 KV cache는 이미 읽은 토큰의 key와 value를 저장해 다음 토큰을 계산할 때 재사용하는 구조입니다. context window가 길어질수록 cache는 선형으로 커집니다. 8K context에서는 소비자가 체감하지 못할 수 있지만, 수십만 토큰의 문서 요약, 긴 코드베이스 질의, 장시간 개인 assistant 세션에서는 모델 가중치보다 cache가 더 민감한 제한이 됩니다. Tether가 발표문에서 계약서, 재무 보고서, 연구 보고서, 책, 코드 저장소, 몇 시간짜리 대화를 예로 든 이유도 이 제한 때문입니다.

TurboQuant의 설계는 두 단계로 설명됩니다. Google Research는 먼저 PolarQuant가 데이터를 무작위 회전한 뒤 polar coordinate 기반으로 압축해 전통적 vector quantization에서 필요한 full-precision 상수 오버헤드를 줄인다고 설명합니다. 그 다음 QJL은 남은 residual에 1-bit transform을 적용해 attention score에 필요한 inner product 추정의 bias를 줄이는 역할을 맡습니다. 이 설명은 논문 수식으로 들어가면 더 복잡하지만, 구현 관점에서는 "key와 value를 낮은 bit-width로 저장하되 attention 계산에서 품질 손실을 억제한다"는 문제로 바뀝니다.

QVAC 구현은 이 연구를 TBQ3_0, TBQ4_0, PQ3_0, PQ4_0 같은 cache 형식으로 노출합니다. GitHub README는 64-wide variant도 함께 적고, smaller attention head dimension을 가진 모델을 위한 형식이라고 설명합니다. backend 범위도 확인해야 합니다. 저장소 문서는 이번 릴리스의 TurboQuant kernel이 CPU quantization/dequantization과 Vulkan inference kernels를 포함한다고 적습니다. 같은 문서에 따르면 CUDA와 Metal에는 이번 릴리스 기준 TurboQuant kernels가 포함되지 않습니다.

이 backend 조건은 로컬 AI 개발자에게 실무적인 차이를 만듭니다. Mac 사용자가 Apple Silicon의 Metal 경로에서 바로 같은 성능을 기대하거나, CUDA 서버에서 H100 기준 Google Research 수치를 그대로 기대하면 구현 범위를 놓칠 수 있습니다. QVAC은 Android, Windows, Linux, macOS, iOS를 지원한다고 적지만, TurboQuant kernel 지원 범위는 그보다 좁게 읽어야 합니다. 특히 모바일·통합 GPU를 겨냥한 발표라면 Vulkan에서의 안정성과 모델별 head dimension 지원이 실제 채택 지점입니다.

Google Research의 공식 수치는 강합니다. Google은 LongBench, Needle In A Haystack, ZeroSCROLLS, RULER, L-Eval 같은 long-context benchmark에서 Gemma와 Mistral 등 open-source LLM을 평가했다고 설명합니다. 블로그는 TurboQuant가 key-value memory size를 최소 6배 줄이면서 needle-in-haystack 결과를 유지했고, 3-bit KV cache quantization에서 training이나 fine-tuning 없이 모델 정확도 손상을 만들지 않았다고 주장합니다. 또 4-bit TurboQuant가 H100에서 32-bit unquantized keys 대비 attention logits 계산을 최대 8배 빠르게 했다고 적었습니다.

QVAC 발표는 그 수치를 로컬·엣지 배포 언어로 번역합니다. Tether는 TurboQuant로 KV cache를 최대 5배 압축한다고 설명하고, full quantization pipeline, common inference framework adapters, developer documentation, workload-tuned profiles를 포함한다고 밝혔습니다. 여기서 최대 5배는 Google의 최소 6배 주장보다 낮습니다. 이 차이는 오히려 구현 뉴스로 읽을 때 유용합니다. 연구 블로그의 실험 조건과 production-oriented fork의 지원 형식, backend, quality guardrail이 같지 않다는 신호이기 때문입니다.

GitHub benchmark 문서는 더 세밀한 그림을 보여줍니다. Qwen3.5-4B Q8_0에서 tbq4_0/pq4_0은 f16/f16 대비 perplexity delta가 -0.03%로 표시됐습니다. 같은 cross-eval 표에서 f16/f16은 RULER main 96.2, LongBench Avg 37.52이고, tbq4_0/pq4_0은 RULER main 94.8, LongBench Avg 37.04입니다. 이 정도 차이는 특정 workload에서는 충분히 받아들일 수 있지만, "무손실"이라는 단어 하나로 덮기에는 평가 항목마다 수치가 다릅니다.

속도 표는 더 조심스럽게 읽어야 합니다. Qwen3.5-4B Q8_0 8K context에서 pq4_0/pq4_0은 RTX 5090 prompt processing 0.89x, token generation 0.96x로 baseline에 가깝습니다. 반면 tbq4_0/pq4_0은 RTX 5090 prompt processing 0.42x, token generation 0.94x입니다. Strix Halo에서도 같은 조합은 prompt processing 0.32x, token generation 0.97x로 표시됩니다. 긴 세션에서 cache 메모리를 줄이는 이득과 초기 prompt 처리 속도 비용을 분리해 봐야 합니다.

이 차이는 제품 설계에도 영향을 줍니다. 개인 assistant가 매번 긴 문서를 새로 ingest하는 형태라면 prompt processing 저하가 곧 대기시간으로 보입니다. 반대로 같은 긴 context를 유지한 채 여러 턴을 이어가는 chat, codebase assistant, local RAG shell에서는 token generation과 cache resident memory가 더 중요해질 수 있습니다. QVAC의 TurboQuant가 설득력을 갖는 사용 사례는 후자에 가깝습니다. 한 번 크게 읽고 오래 붙잡는 workload에서 메모리 압축이 세션 수와 context 길이를 늘릴 수 있습니다.

커뮤니티 반응도 이 구분을 따라 갈립니다. r/LocalLLaMA에는 2026년 3월 28일 MLX 구현 글이 올라왔고, 작성자는 Qwen2.5-32B, M4 Pro 48GB에서 4.6배 cache compression, 0.98x FP16 speed, 16K context cache 4.2GB에서 897MB를 보고했습니다. 같은 글의 댓글에는 작은 Mac에서 high context가 메모리와 속도를 크게 먹는 문제를 기다려 왔다는 반응이 있었습니다. TurboQuant류 구현이 로컬 사용자에게 실제 체감 문제와 맞닿아 있다는 증거입니다.

반대로 2026년 4월 About TurboQuant 토론은 Google 발표를 더 냉정하게 읽었습니다. 일부 사용자는 full precision baseline 대비 수치보다 실제 사용자가 자주 쓰는 q4, q8 KV cache 대비 비교가 필요하다고 지적했습니다. 긴 대화 50-100턴 이상의 품질 저하를 따로 봐야 한다는 댓글도 있었습니다. 2026년 5월 16GB VRAM 토론에서는 특정 HIP 구현이 fixed overhead 때문에 512 tokens에서도 OOM이 났다는 보고가 있었고, 다른 사용자는 Vulkan backend가 더 안정적일 수 있다고 답했습니다.

이 비판은 QVAC 릴리스의 가치를 낮추기보다 검증 항목을 정리합니다. 첫째, cache 압축률은 모델 가중치 메모리를 줄이지 않습니다. 30B급 모델을 16GB GPU에 올릴 수 있느냐는 weight quantization, offload, backend memory allocator까지 같이 봐야 합니다. 둘째, benchmark의 "quality neutrality"는 특정 모델, benchmark, context 형태에서 나온 결과입니다. 실제 제품의 긴 대화, tool call trace, code diff, 검색 결과 묶음에서는 회귀 테스트를 따로 만들어야 합니다.

셋째, QVAC이 llama.cpp fork라는 사실은 장점과 비용을 동시에 만듭니다. 장점은 개발자가 이미 아는 GGUF, local server, CLI, Vulkan build 흐름 위에서 실험할 수 있다는 점입니다. 비용은 upstream과의 차이를 계속 추적해야 한다는 점입니다. README는 현재 upstream baseline을 llama.cpp b7248로 적고, QVAC 전용 기능을 별도로 나열합니다. production team이라면 upstream llama.cpp에 같은 기능이 들어오는지, QVAC fork가 모델·backend update를 얼마나 빠르게 따라가는지 봐야 합니다.

Tether라는 발표 주체도 독특합니다. Tether는 USDT 발행사로 알려져 있지만, 이번 발표는 blockchain보다 local AI infrastructure에 가까운 내용입니다. QVAC은 개인 장치와 분산 네트워크에서 AI를 실행하겠다는 방향을 내세웁니다. 이 방향이 설득력을 얻으려면 "데이터를 클라우드로 보내지 않는다"는 문구보다, 지원 모델, backend별 speed, quantization artifact, reproducible benchmark가 더 중요합니다. 이번 GitHub 공개가 뉴스가 되는 이유도 코드와 benchmark 문서가 함께 나왔기 때문입니다.

개발자가 바로 확인할 지점은 세 가지입니다. 첫째, 자신의 target hardware가 Vulkan 경로를 안정적으로 지원하는지 확인해야 합니다. Android와 Windows/Linux의 Vulkan은 발표 범위와 맞지만, Metal이나 CUDA에 TurboQuant kernel이 없다는 README 문구는 별도 계획을 요구합니다. 둘째, workload가 긴 context 유지형인지, 긴 prompt 반복형인지 분리해야 합니다. 셋째, tbq3_0, tbq4_0, pq3_0, pq4_0, q4_0 cache 설정을 같은 prompt set과 같은 seed에서 비교해야 합니다.

AI 제품 팀 입장에서는 비용 계산 방식도 달라집니다. cloud API에서는 긴 context가 토큰 가격과 latency로 보이지만, local inference에서는 VRAM, shared memory, battery, thermal throttling으로 나타납니다. KV cache 압축은 이 중 VRAM과 memory bandwidth를 직접 건드립니다. 하지만 cache를 압축하고 푸는 kernel이 느리면 prompt processing 시간이 늘어날 수 있습니다. QVAC 벤치마크의 일부 항목이 바로 그 trade-off를 드러냅니다.

이번 발표를 "로컬 AI가 클라우드를 대체한다"로 읽으면 과장입니다. 더 정확한 해석은 "긴 context local inference에서 cache memory가 독립 최적화 대상이 됐다"입니다. 모델 weight quantization, speculative decoding, retrieval chunking, KV cache quantization은 서로 다른 병목을 건드립니다. QVAC이 공개한 TurboQuant 구현은 그중 KV cache 영역을 제품 기능으로 끌어낸 사례입니다. 장문 문서 assistant나 코드베이스 assistant를 로컬에서 돌리는 팀은 이 항목을 별도 benchmark 축으로 넣을 이유가 생겼습니다.

남은 질문은 공개 일정이 아니라 재현성입니다. Google Research 수치, Tether 발표 수치, QVAC GitHub benchmark 수치가 모두 같은 말을 하지는 않습니다. Google은 알고리즘의 이론과 long-context benchmark를 설명하고, Tether는 로컬·엣지 배포에서 최대 5배 긴 context를 말하며, GitHub 문서는 모델별 품질과 속도 표를 나눠 보여줍니다. 이 세 층을 함께 보면 "3비트 KV cache"는 마법이 아니라 선택지입니다. 긴 문맥을 위해 메모리를 줄이고, workload에 따라 일부 처리 시간을 지불하는 선택지입니다.

QVAC TurboQuant 릴리스의 실무적 가치는 여기에서 나옵니다. 로컬 AI가 작은 모델 demo를 넘어 장시간 assistant, 큰 문서, 코드 저장소 작업으로 가려면 context memory가 제품 한계가 됩니다. Tether가 공개한 구현은 그 한계에 대해 연구 논문이 아니라 빌드 가능한 fork와 benchmark 표로 답했습니다. 이제 검증은 각 팀의 prompt, 모델, backend, 세션 길이에서 이뤄져야 합니다. 발표문보다 중요한 숫자는 사용자의 장치에서 f16/f16, q4_0/q4_0, tbq4_0/pq4_0가 같은 작업을 끝내는 시간과 남기는 메모리입니다.