QVAC 0.12.0 공개, TurboQuant로 줄이는 로컬 KV 캐시

AI 요약

• 무슨 일: Tether가 2026년 6월 1일 QVAC SDK 0.12.0과 TurboQuant 구현을 발표했습니다.
  • 보도자료는 262,000 tokens에서 4B 모델 KV cache가 약 8GB, 네 세션이면 cache만 약 32GB가 될 수 있다고 설명합니다.
• 개발자 의미: 로컬 AI의 긴 문서, 긴 대화, 코드베이스 분석 병목이 모델 weight보다 KV cache로 이동합니다.
• 검증 포인트: QVAC 코드에는 tbq3_0, tbq4_0, pq3_0, pq4_0 cache type 처리가 보입니다.
  • 다만 OpenCL과 Metal 제약, vLLM 쪽 benchmark 반론, BF16 baseline 비교 문제는 실제 도입 전에 따로 확인해야 합니다.

Tether AI Research Group이 2026년 6월 1일 QVAC SDK 0.12.0과 TurboQuant 구현을 발표했습니다. Tether 보도자료는 Google Research가 공개한 memory compression 알고리즘을 QVAC Fabric으로 가져온다고 설명했습니다. 대상은 laptop, phone, consumer GPU, edge device, peer-to-peer inference network에서 긴 세션을 다루는 로컬 AI입니다. 같은 날 GitHub에는 QVAC SDK v0.12.0 release가 올라왔고, release timestamp는 2026년 6월 1일 12:05 UTC입니다.

이번 사건은 "로컬 모델이 더 빨라졌다"는 단순 발표가 아닙니다. 보도자료의 숫자는 더 구체적입니다. Tether는 약 262,000 tokens 규모, 즉 수백 페이지 문서나 몇 시간 대화에 해당하는 세션에서 4B 모델의 KV cache만 약 8GB를 쓸 수 있다고 적었습니다. 같은 규모 세션 네 개가 동시에 열리면 cache만 약 32GB가 됩니다. 로컬 AI가 노트북에서 잘 보이다가 긴 문서, 여러 작업, 장시간 agent 세션에서 갑자기 cloud API로 밀려나는 이유가 이 숫자에 들어 있습니다.

이 이미지는 Google Research가 TurboQuant 발표에 사용한 vector quantization 설명 자료입니다.

보도자료와 릴리스 노트 사이의 간격

Tether 보도자료는 TurboQuant가 QVAC SDK 0.12.0에 포함되고, QVAC Fabric을 통해 사용할 수 있다고 말합니다. 같은 문서에서 TurboQuant는 KV cache를 최대 5배 압축하면서 uncompressed model에 가까운 출력 품질을 유지한다고 설명됩니다. 이 문장만 읽으면 SDK release note 첫머리에 TurboQuant가 등장할 것 같지만, GitHub의 v0.12.0 release note는 다른 항목을 앞세웁니다.

GitHub release note의 첫 단락은 SmolVLA 기반 vision-language-action inference, image classification, text-to-video generation을 나열합니다. 같은 단락에는 @qvac/bare-sdk, @qvac/sdk/commands, Gemma 4와 Qwen 3.5/3.6 multimodal model registry constants, mobile/delegation fixes도 들어갑니다. Breaking changes도 TTS의 ONNX에서 tts-ggml 이동, Parakeet 0.6.0 GGUF backend, Bare SDK plugin registration, CLI bundle/verify command 위임에 초점이 맞춰져 있습니다. TurboQuant라는 단어는 release note의 headline에는 없습니다.

이 간격을 무시하면 글이 보도자료 재전송으로 끝납니다. 그래서 저장소 코드를 확인했습니다. QVAC의 packages/llm-llamacpp/addon/src/model-interface/LlamaModel.cpp에는 TurboQuant와 PolarQuant KV-cache type을 다루는 주석과 함수가 보입니다. 코드 주석은 tbq3_0, tbq4_0, pq3_0, pq4_0 cache type이 Vulkan과 CPU 구현만 제공한다고 설명합니다. OpenCL에는 kernel이 없고, Metal에는 standalone MUL_MAT pipeline 제약이 있어 해당 backend에서 조용히 진행하면 llama.cpp가 실행할 수 없는 backend에 KV-cache tensor를 올릴 수 있다는 취지의 guard입니다.

이 증거가 확인하는 범위는 제한적입니다. 보도자료는 코드와 연결되지만, SDK v0.12.0은 "어느 backend에서 어떤 model config로 TurboQuant를 켜면 얼마가 절감된다"는 사용 설명서를 앞세운 release가 아닙니다. 개발자는 발표 문장, release note, 실제 addon code, backend limitation을 따로 읽어야 합니다.

KV cache가 왜 로컬 AI의 병목이 되는가

LLM을 로컬에서 실행할 때 가장 먼저 보이는 숫자는 model weight입니다. 4B, 8B, 14B 같은 parameter 수와 Q4, Q5, Q8 같은 weight quantization이 관심을 받습니다. 그러나 긴 대화와 agent 세션에서는 weight만으로 메모리 요구량을 설명할 수 없습니다. Transformer는 이전 token의 key와 value를 다시 계산하지 않기 위해 KV cache를 쌓고, 이 cache는 context가 길어질수록 커집니다.

짧은 chat demo에서는 이 차이가 작게 보입니다. 한두 문단 prompt와 수십 token 답변이라면 KV cache보다 model weight가 더 크게 보입니다. 하지만 수백 페이지 문서, 긴 codebase, multi-turn debugging log, tool result가 쌓인 agent session에서는 cache가 빠르게 커집니다. Tether가 262,000 tokens, 4B model, 8GB cache라는 예시를 든 이유도 여기에 있습니다.

개발자 관점에서 이 병목은 두 가지 비용으로 나타납니다. 첫째, 긴 context를 허용하려면 더 큰 RAM이나 VRAM이 필요합니다. 둘째, 여러 local session을 동시에 돌리기 어렵습니다. 코딩 agent가 issue 하나를 고치고, 문서 요약 agent가 큰 PDF를 읽고, OCR 후 정리 작업이 따로 돌아가면 model weight는 공유할 수 있어도 세션별 KV cache는 별도로 늘어납니다.

Google Research가 2026년 3월 24일 공개한 TurboQuant 글은 이 문제를 memory overhead로 설명합니다. 전통적 vector quantization은 값을 줄이는 대신 block마다 quantization constant를 저장해야 합니다. Google은 이 overhead가 숫자당 1비트 또는 2비트씩 붙어 압축 효과를 갉아먹는다고 설명했습니다. TurboQuant는 PolarQuant와 QJL을 결합해 이 overhead를 낮추는 방식입니다.

Google의 설명에서 PolarQuant는 data vector를 rotate한 뒤 polar coordinate 쪽으로 다룹니다. QJL은 잔여 error를 1-bit sign 쪽으로 처리해 attention score 계산의 bias를 줄이는 역할로 설명됩니다. 이 설명은 구현자가 바로 복사해 쓰는 API 문서라기보다 연구 발표입니다. Tether의 QVAC 발표가 새로 붙인 부분은 "그 연구를 로컬 inference runtime의 cache type과 SDK 배포 문제로 옮기겠다"는 제품 방향입니다.

QVAC은 로컬 실행과 P2P 위임을 함께 본다

QVAC 저장소 README는 이 프로젝트를 local-first, peer-to-peer AI application ecosystem으로 소개합니다. 지원 범위에는 LLM, speech, RAG, translation, transcription, OCR, image generation, fine-tuning, multimodal이 들어갑니다. README는 Linux, macOS, Windows, Android, iOS를 함께 적고, local inference뿐 아니라 peer에게 inference를 위임하는 기능도 언급합니다.

이 범위는 일반적인 "로컬 LLM runner"보다 넓습니다. Ollama나 LM Studio가 사용자 친화적인 local model 실행과 OpenAI-compatible server로 널리 쓰인다면, QVAC은 SDK, CLI, Bare runtime, addon package, model registry, P2P delegation을 한 저장소 안에서 묶으려 합니다. 그래서 TurboQuant 같은 cache compression은 단순 성능 옵션이 아니라 배포 지점 문제와 연결됩니다.

예를 들어 phone에서 긴 대화 cache를 줄일 수 있다면 on-device assistant가 더 많은 기록을 유지할 수 있습니다. laptop에서 cache가 줄면 local coding assistant가 더 큰 repo context를 잡을 수 있습니다. peer-to-peer inference에서는 memory-constrained peer가 긴 session을 받아들일 수 있는지 여부가 network 참여 폭을 바꿀 수 있습니다. 이 세 경우 모두 "모델을 한 번 로드할 수 있다"와 "세션을 오래 유지할 수 있다"는 서로 다른 조건입니다.

QVAC 내부 perf 문서도 이 차이를 드러냅니다. packages/llm-llamacpp/docs/perf/metal-vl-analysis.md는 Apple Silicon Metal 최적화에서 KV cache quantization Q4_0을 즉시 가능한 최적화로 봅니다. 같은 문서는 Qwen3.5 hybrid model이 24개 layer 중 6개만 KV cache를 가진다고 적습니다. appendix는 TurboQuant를 advanced KV cache strategy로 기록하고, llama.cpp discussion과 연결합니다. 보도자료의 큰 숫자와 내부 문서의 backend별 최적화 항목을 같이 봐야 실무 판단이 가능합니다.

5배 압축 claim을 그대로 제품 계산에 넣으면 안 됩니다

Tether는 TurboQuant가 KV cache를 최대 5배 압축한다고 발표했습니다. Google Research 원문은 TurboQuant가 KV memory를 크게 줄이고 attention-logit 계산을 빠르게 할 수 있다고 설명했습니다. 이런 수치는 local AI를 제품에 넣고 싶은 팀에게 매력적입니다. 32GB laptop에서 불가능해 보이던 긴 document assistant가 가능해질 수 있고, 작은 GPU에서 더 긴 context window를 열 수 있기 때문입니다.

다만 baseline을 확인해야 합니다. Hacker News의 TurboQuant 관련 토론에서 여러 댓글은 6x 또는 5x류 표현이 BF16 KV cache와 비교한 값인지, 이미 8-bit 또는 4-bit KV cache quantization을 쓰는 실무 baseline과 비교한 값인지 구분해야 한다고 지적했습니다. 어느 팀은 아직 BF16 cache를 쓰고 있을 수 있지만, 다른 팀은 이미 Q4_0 cache나 model-specific cache optimization을 적용하고 있을 수 있습니다.

vLLM 구현 논의도 같은 질문을 던집니다. HN 댓글은 vLLM PR과 issue를 근거로 현재 구현이 약 3.8배에서 4.9배 압축 범위에 있고, speed는 80%에서 100% baseline 주변이라는 반론을 제시했습니다. 이 숫자는 HN 댓글에서 요약된 커뮤니티 해석이므로 공식 benchmark로 그대로 인용할 수는 없습니다. 그러나 제품팀이 자체 benchmark 없이 보도자료 수치만 capacity planning에 넣으면 위험하다는 경고로는 충분합니다.

또 한 가지는 total memory입니다. KV cache가 줄어도 model weight는 여전히 메모리에 올라갑니다. 16GB RAM laptop에서 14B model을 Q4로 올리고 긴 context를 열 때, cache 절감은 중요하지만 weight, allocator overhead, embedding/RAG memory, OS memory, browser memory가 같이 경쟁합니다. 반대로 cloud inference server에서는 user별 KV cache가 batch와 concurrency를 제한하므로 cache 압축의 영향이 훨씬 커질 수 있습니다.

따라서 "TurboQuant가 memory demand를 5배 줄인다"가 아니라 "특정 workload에서 KV cache 부분을 줄일 수 있다"로 읽어야 합니다. 긴 context를 많이 쓰는 coding agent, document analysis, long conversation assistant에는 직접 영향이 있습니다. 짧은 prompt와 짧은 답변 중심 chat에는 체감이 작을 수 있습니다.

backend 제한은 개발자 경험을 좌우합니다

QVAC 코드의 backend guard는 뉴스 가치가 있습니다. 주석은 TurboQuant와 PolarQuant KV-cache type이 Vulkan과 CPU 구현만 제공한다고 적고, OpenCL과 Metal에서는 제한을 설명합니다. local AI에서 backend는 작은 구현 세부가 아닙니다. macOS와 iOS 사용자는 Metal을 기대하고, Android와 Linux 사용자는 Vulkan이나 CPU path를 접하게 됩니다. Windows 사용자는 GPU vendor와 driver 조합에 따라 다른 path를 밟습니다.

만약 tbq4_0 같은 cache type을 설정했는데 backend가 kernel을 제공하지 않는다면 실패 방식이 중요합니다. 조용히 fallback하면 사용자는 압축이 켜진 줄 알지만 실제 memory는 줄지 않을 수 있습니다. 반대로 hard error가 나면 제품은 설정 화면에서 backend별 지원 표를 보여줘야 합니다. QVAC code가 guard를 둔 것은 후자에 가까운 안전장치입니다.

이 부분은 QVAC이 아직 초기 SDK라는 사실과도 맞물립니다. v0.12.0 release note는 text-to-video, SmolVLA, classification처럼 기능 표면을 넓히는 항목이 많습니다. 동시에 context overflow를 typed error로 노출하는 API도 들어갔습니다. 이 조합은 QVAC이 "실행 가능한 local AI 묶음"에서 "실패를 앱이 처리할 수 있는 SDK"로 가는 중이라는 뜻입니다.

로컬 AI 앱에서 실패 처리는 품질만큼 중요합니다. context가 넘쳤을 때 prompt를 자를지, RAG chunk를 줄일지, cloud fallback으로 보낼지, user에게 model switch를 요구할지 결정해야 합니다. KV cache compression도 같은 층에 들어갑니다. 압축 type이 backend에서 안 되면 앱은 더 짧은 context로 내려가거나 다른 backend를 선택하거나 cloud provider로 보내야 합니다.

코딩 에이전트는 cache보다 tool call에서 먼저 깨질 수 있습니다

이번 글은 기존 devlery의 QVAC AI SDK Provider 글과 다르게 provider 표면보다 memory와 backend에 초점을 둡니다. 그래도 코딩 agent를 빼고 이야기하기 어렵습니다. 긴 codebase 분석과 multi-turn fix loop는 KV cache를 가장 빨리 키우는 workload 중 하나입니다. 한 issue를 고치는 동안 system prompt, tool definitions, file snippets, test output, diff, reviewer instruction이 누적됩니다.

KV cache 압축은 이런 세션의 memory pressure를 줄일 수 있습니다. 그러나 agent 성공률은 cache만으로 결정되지 않습니다. 작은 4B 또는 8B instruct model은 tool call schema를 안정적으로 지키지 못할 수 있습니다. local model이 긴 context를 유지해도, file edit tool을 잘못 호출하거나 JSON schema를 깨면 자동화는 실패합니다. QVAC의 AI SDK Provider v0.1.0 README도 작은 local model의 tool-use 한계를 문서화했습니다.

그래서 개발팀의 test plan은 두 갈래여야 합니다. 첫째, 같은 model과 같은 prompt에서 cache-type-k, cache-type-v, context length, backend별 memory와 speed를 측정합니다. 둘째, agent harness에서 tool call success rate, invalid JSON rate, test rerun loop, diff quality를 봅니다. memory가 줄어든다고 agent가 더 똑똑해지지는 않습니다. 다만 memory가 줄면 더 긴 evidence를 줄 수 있고, 그 evidence를 제대로 쓰는지는 model과 harness가 결정합니다.

한국 개발팀이 바로 실험한다면 사내 문서 요약, 긴 로그 분석, local RAG 같은 낮은 tool-use 경로부터 시작하는 편이 낫습니다. 코딩 agent backend로 쓰려면 14B 이상 coder/agent-tuned model, 충분한 RAM/VRAM, 긴 context, backend별 cache type, cloud fallback을 한꺼번에 검증해야 합니다. 실패를 조용히 삼키는 local automation은 cloud 비용보다 더 비싼 디버깅 비용을 만듭니다.

로컬 AI의 다음 비교 기준은 cache와 routing입니다

이번 발표에서 Tether가 얻은 관심은 "스테이블코인 회사가 왜 AI SDK를 만드나"라는 질문도 포함합니다. QVAC은 Tether의 broader AI strategy에서 중앙 cloud API만 쓰지 않는 local, edge, decentralized infrastructure를 내세웁니다. 이 전략이 설득력을 얻으려면 model catalog나 demo보다 runtime efficiency와 integration reliability가 먼저 필요합니다. TurboQuant 발표는 그중 runtime efficiency 쪽 메시지입니다.

경쟁자는 명확합니다. Ollama는 local model 실행과 developer adoption에서 강합니다. LM Studio는 desktop UX가 좋습니다. llama.cpp는 사실상 많은 local runtime의 기반입니다. vLLM은 server-side inference에서 강하고, OpenAI-compatible endpoint는 여러 제품의 공통 연결 규격이 됐습니다. QVAC은 이 경쟁에서 P2P, cross-platform SDK, multi-modal addon, Bare runtime, local-first message를 결합하려 합니다.

개발자가 비교할 기준도 바뀝니다. "이 runtime이 내 GPU에서 몇 token/s를 내는가"만으로는 부족합니다. 같은 앱에서 cloud provider와 local provider를 어떻게 routing하는지 봐야 합니다. 긴 context session에서 KV cache가 얼마나 늘어나는지, cache type별 품질 손상이 있는지도 측정해야 합니다. backend fallback이 명확한지, context overflow가 typed error로 올라오는지도 제품 품질에 들어갑니다.

Tether의 6월 1일 발표는 이 체크리스트를 다시 쓰게 합니다. QVAC SDK 0.12.0 release note만 보면 기능 확장 release입니다. Tether 보도자료만 보면 TurboQuant productionization release입니다. 저장소 코드를 보면 TurboQuant/PolarQuant cache type handling과 backend guard가 확인됩니다. 커뮤니티 토론을 보면 benchmark와 baseline을 의심해야 합니다. 네 조각을 합치면 이번 뉴스의 실무 결론은 명확합니다.

로컬 AI의 긴 context 문제는 이제 "큰 모델을 어디서 받을까"가 아니라 "세션 메모리를 어떻게 줄이고, 어떤 backend에서 검증하고, 실패하면 어디로 보낼까"에 가깝습니다. QVAC은 그 질문에 TurboQuant와 SDK surface로 답을 내기 시작했습니다. 아직 개발팀이 직접 benchmark를 돌려야 할 부분이 많지만, KV cache가 로컬 AI 제품 설계의 1급 변수가 됐다는 사실은 이번 발표만으로도 충분히 확인됩니다.