QVAC AI SDK Provider 공개, 로컬 모델을 AI SDK로 호출

AI 요약

• 무슨 일: Tether QVAC 저장소가 @qvac/ai-sdk-provider 0.1.0을 공개했습니다.
  • 릴리스는 2026년 6월 1일 GitHub에 게시됐고, npm 패키지는 ai@^6.0과 @ai-sdk/openai-compatible@^2.0을 peer dependency로 둡니다.
• 개발자 의미: QVAC 로컬 런타임을 streamText, generateText, embed, transcribe 같은 AI SDK 호출 표면에 붙일 수 있습니다.
• 주의점: v0.1.0은 직접 qvac serve openai를 띄우는 external mode만 지원합니다.
  • README는 11434 포트가 Ollama와 겹치고, 작은 4B/8B 로컬 모델은 코딩 에이전트 tool call에 불안정하다고 적습니다.

Tether의 QVAC 저장소가 2026년 6월 1일 @qvac/ai-sdk-provider 0.1.0 릴리스를 공개했습니다. 같은 날 Tether는 QVAC SDK 0.12.0에 TurboQuant 구현을 포함한다고 발표했지만, 개발자가 바로 확인할 수 있는 새 접점은 GitHub 릴리스와 npm 패키지 쪽에 있습니다. QVAC 로컬 런타임이 Vercel AI SDK provider로 들어오면서, 로컬 모델을 별도 앱 전용 API가 아니라 TypeScript AI 앱의 공통 호출 표면에서 다룰 수 있게 됐습니다.

이번 글은 TurboQuant 알고리즘을 다시 설명하는 글이 아닙니다. devlery에는 이미 Google Research의 TurboQuant 원 논문과 KV cache 압축을 다룬 글이 있습니다. 이번 사건의 초점은 QVAC이 로컬 추론 엔진, OpenAI 호환 HTTP 서버, Vercel AI SDK provider, 코딩 에이전트 연결 문서를 한 경로로 묶기 시작했다는 점입니다. 로컬 AI가 실험용 데모에서 실제 개발 워크플로로 들어가려면 모델 파일보다 연결 표면이 먼저 안정돼야 합니다.

0.1.0 릴리스가 실제로 한 일

GitHub 릴리스의 설명은 명확합니다. @qvac/ai-sdk-provider는 QVAC 로컬 AI 런타임을 위한 Vercel AI SDK provider입니다. 사용자는 먼저 qvac serve openai로 로컬 HTTP 서버를 띄우고, provider의 baseURL을 그 서버에 맞춥니다. 그다음 AI SDK의 streamText, generateText, embed, transcribe, generateImage 같은 API에서 QVAC 모델 alias를 호출합니다.

npm registry 기준 패키지 설명은 더 짧습니다. 이 패키지는 QVAC local AI runtime을 위한 Vercel AI SDK provider이며 chat, embeddings, transcription, translation, speech, OCR, image를 범위로 적습니다. 라이선스는 Apache-2.0이고, peer dependency는 ai@^6.0과 @ai-sdk/openai-compatible@^2.0입니다. 즉 QVAC이 AI SDK 자체를 복제하는 것이 아니라, AI SDK의 provider 생태계 안에 들어가는 방식입니다.

릴리스 README의 코드도 이 성격을 숨기지 않습니다. createQvac()는 내부적으로 createOpenAICompatible을 호출합니다. name은 qvac, 기본 API key는 문자열 qvac, baseURL은 사용자가 지정하는 구조입니다. Vercel AI SDK 문서에서도 OpenAI-compatible provider는 createOpenAICompatible로 provider를 만들고, generateText에 provider('model-id')를 넘기는 형식입니다. QVAC provider는 이 일반 패턴에 QVAC 이름, 기본값, 모델 메타데이터, 향후 managed mode를 얹는 얇은 래퍼입니다.

이 얇은 래퍼가 의미 없는 것은 아닙니다. AI 앱을 만드는 팀은 provider 이름과 모델 catalog, auth default, 문서화된 baseURL, framework 예제를 필요로 합니다. @ai-sdk/openai-compatible로 직접 붙일 수 있는 서버라도, 매번 임시 설정으로 남으면 팀 내부 표준이 되기 어렵습니다. @qvac/ai-sdk-provider는 "이 로컬 런타임을 AI SDK 앱에서 이렇게 부른다"는 공식 이름표를 붙인 릴리스입니다.

QVAC 서버는 OpenAI 호환 표면을 넓게 잡았습니다

QVAC 문서의 HTTP server 페이지는 이번 provider 릴리스의 전제입니다. 문서는 @qvac/sdk와 @qvac/cli를 설치한 뒤 qvac serve openai를 실행하면 로컬 OpenAI-compatible API가 열린다고 설명합니다. 기본 예시는 http://localhost:11434/v1/이며, 요청은 qvac.config.*에 등록된 모델 alias로 라우팅됩니다.

지원 endpoint 목록은 단순 chat server보다 넓습니다. 문서는 chat, responses, completions, embeddings, audio, image, files, vector stores 계열의 /v1 endpoint를 나열합니다. text generation만이 아니라 RAG, 파일, 음성, 이미지 생성까지 OpenAI 형식에 맞추려는 설계입니다.

문서가 이미 확인한 호환 도구도 있습니다. Continue.dev는 streaming SSE와 /v1/models를 요구하고, LangChain은 chat completions와 embeddings를 씁니다. Open Interpreter는 streaming과 tool calls가 붙은 chat completions를 필요로 합니다. 이 표는 QVAC의 목표가 "자체 앱에서만 잘 도는 SDK"가 아니라, OpenAI API 형식을 이미 지원하는 도구가 base URL만 바꿔 로컬 런타임을 쓰게 만드는 쪽임을 보여줍니다.

로컬 AI의 진짜 병목은 API 모양입니다

로컬 모델 생태계에서는 모델 성능 논쟁이 먼저 보입니다. 몇 B 파라미터인지, Q4 양자화인지, Metal이나 Vulkan을 쓰는지, 토큰 속도가 어느 정도인지가 관심을 받습니다. 하지만 애플리케이션 개발에서 더 먼저 깨지는 부분은 API 모양입니다. 어떤 모델 서버는 OpenAI chat completions만 흉내 내고, 어떤 서버는 tool call 형식이 다르며, 어떤 서버는 embeddings와 image generation을 별도 endpoint로 둡니다. AI 앱 코드는 provider마다 조건문을 품게 됩니다.

Vercel AI SDK가 provider 추상화를 제공하는 이유도 이 문제와 맞닿아 있습니다. 애플리케이션은 generateText나 streamText처럼 비교적 안정된 호출을 쓰고, provider가 각 런타임의 인증, baseURL, model id, streaming 형식을 맞춥니다. QVAC이 이 레이어에 들어오면 로컬 서버는 "Ollama 비슷한 별도 도구"가 아니라, 기존 AI SDK 앱의 provider 후보가 됩니다.

이 변화는 작은 팀에 실용적입니다. 예를 들어 사내 문서 요약, 로컬 코드 분석, 오프라인 음성 전사, 이미지 OCR처럼 민감 데이터가 많은 기능은 처음부터 cloud API로 보내기 어렵습니다. QVAC 서버가 OpenAI-compatible API를 제공하고, provider가 AI SDK surface를 제공하면 같은 앱 안에서 cloud provider와 local provider를 비교할 수 있습니다. 품질이 필요한 경로는 frontier API를 쓰고, 개인정보나 비용이 민감한 경로는 로컬 모델을 쓰는 하이브리드 설계가 쉬워집니다.

다만 하이브리드 설계가 자동으로 좋은 제품을 만들지는 않습니다. QVAC README는 v0.1.0을 "plumbing"에 가깝게 설명합니다. 실제 에이전트 성능은 로컬 모델 선택이 결정합니다. README는 Q4 양자화된 4B/8B Qwen3-Instruct가 대화는 할 수 있지만 tool call을 안정적으로 호출하지 못할 수 있고, 믿을 만한 로컬 tool use에는 14B 이상과 coder/agent post-training이 필요하다고 적습니다. 이 문장은 로컬 AI 마케팅 문구보다 더 쓸모 있습니다.

포트 11434 경고는 작은 문제가 아닙니다

릴리스에서 가장 현실적인 문장은 기본 baseURL 경고입니다. QVAC CLI의 qvac serve는 현재 11434를 기본 포트로 씁니다. README는 이 포트가 Ollama와 충돌한다고 적고, provider의 기본 baseURL을 http://127.0.0.1:11435/v1 placeholder로 둡니다. 사용자는 반드시 실제 qvac serve 포트를 createQvac({ baseURL })에 명시해야 합니다.

이 경고는 단순한 설정 팁이 아닙니다. 로컬 AI 도구가 늘어나면서 한 개발자 노트북에는 Ollama, LM Studio, llama.cpp server, QVAC, 테스트용 proxy, MCP server가 동시에 떠 있을 수 있습니다. 서로 다른 도구가 같은 포트와 같은 OpenAI-compatible endpoint를 주장하면, 앱은 잘못된 서버에 요청을 보내고도 한동안 알아차리지 못할 수 있습니다. 특히 모델 alias가 비슷하거나 API key 검증이 느슨하면 실패가 조용히 섞입니다.

QVAC 문서는 인증도 명시합니다. 기본은 127.0.0.1에서 인증 없이 요청을 받지만, --api-key를 주면 Bearer token을 요구할 수 있습니다. 로컬 서버라도 이것은 중요합니다. 데스크톱 앱, 브라우저 확장, 로컬 웹앱, 에이전트 harness가 같은 머신에서 움직이는 환경에서는 "localhost라서 안전하다"는 가정이 약합니다. 개발팀은 CORS, public-base-url, API key, 파일 endpoint 접근 범위를 함께 봐야 합니다.

TurboQuant 발표와 연결되는 지점

Tether의 2026년 6월 1일 보도자료는 QVAC SDK 0.12.0에 TurboQuant 구현이 들어간다고 발표했습니다. 보도자료는 262,000 token 규모에서 4B 모델의 KV cache가 약 8GB를 쓸 수 있다고 설명합니다. 네 세션이면 cache만 32GB까지 갈 수 있다는 계산도 함께 제시했습니다. Tether는 TurboQuant가 KV cache를 최대 5배 압축하면서 uncompressed model에 가까운 출력 품질을 유지한다고 주장합니다.

Google Research의 원 발표는 2026년 3월 24일입니다. Google은 TurboQuant가 KV cache bottleneck과 vector search의 memory overhead를 줄이는 알고리즘이며, ICLR 2026에 발표될 예정이라고 설명했습니다. 이 연구는 이미 별도 뉴스 가치가 충분했습니다. 그러나 QVAC 관점에서 새로 봐야 할 부분은 연구 결과가 로컬 런타임의 제품 조건으로 내려왔다는 점입니다.

로컬 AI 앱은 모델 weight만 메모리에 올리는 문제가 아닙니다. 긴 대화, 코드베이스 분석, 문서 RAG, 음성 전사 후 요약, 이미지 OCR 결과 정리처럼 세션이 길어지면 KV cache와 중간 상태가 커집니다. TurboQuant 같은 압축 기술은 이 병목을 줄이려는 시도이고, AI SDK provider는 그 런타임을 앱 코드와 연결하는 시도입니다. 하나는 하드웨어 한계를 줄이고, 다른 하나는 개발자 통합 비용을 줄입니다.

하지만 두 발표를 합쳐 "로컬 AI가 곧 cloud API를 대체한다"고 읽으면 부정확합니다. Tether 발표도 large compute가 계속 중요하다고 인정합니다. README의 작은 모델 tool-use 한계도 같은 방향을 가리킵니다. 로컬 모델은 privacy, offline, cost control에 강하지만, 복잡한 코딩 에이전트나 고난도 추론에서는 cloud frontier model이 여전히 우위일 수 있습니다. 이번 릴리스가 만든 선택지는 대체가 아니라 라우팅입니다.

코딩 에이전트에 붙일 때의 실패 모드

QVAC README는 코딩 에이전트 연결을 별도 섹션으로 다룹니다. 첫 실패 모드는 concurrent request입니다. underlying llama.cpp addon은 native model context마다 inference를 직렬화하고, 새 job이 이미 처리 중이면 요청을 거부할 수 있습니다. 코딩 에이전트는 메인 답변과 제목 생성, 요약, tool result 정리를 동시에 호출하는 경우가 많습니다. README는 지금 당장 parallel inference가 필요하면 서로 다른 model file을 두 alias로 로드하라고 제안합니다.

두 번째 실패 모드는 context size입니다. QVAC LLM 기본 ctx_size는 1024 token으로 설명돼 있습니다. 짧은 채팅에는 괜찮지만, 코딩 에이전트에는 부족합니다. OpenCode 같은 harness는 system prompt, 10개 이상의 tool definition, 최근 메시지, 파일 스니펫을 첫 요청부터 함께 보냅니다. README는 chat 모델에 16384, title generation에 4096 같은 값을 명시하라고 안내합니다.

세 번째 실패 모드는 reasoning block입니다. Qwen3나 DeepSeek-R1 계열처럼 reasoning-tuned 모델은 <think> 블록을 출력할 수 있습니다. host가 reasoning channel을 따로 지원하지 않으면 이 내용이 그대로 UI에 보이고, 사용자가 보지 않을 token이 latency를 태웁니다. README는 reasoning_budget: 0을 설정해 addon 레벨에서 reasoning을 끄라고 적습니다. 이 값은 QVAC SDK 0.11.0 이상과 그것을 pin한 CLI 0.5.0 이상이 필요합니다.

이 세 항목은 로컬 AI가 제품으로 들어갈 때의 실제 점검표입니다. 모델이 "로컬에서 실행된다"는 사실만으로는 부족합니다. 동시 요청을 queue할지 거부할지, context를 어디까지 키울지, reasoning token을 어떻게 숨길지, 작은 모델의 tool call 실패를 어떻게 감지할지, server restart 때 Responses API의 volatile state가 사라지는 것을 앱이 어떻게 처리할지까지 봐야 합니다.

개발팀이 지금 볼 만한 기준

QVAC provider 0.1.0은 production-ready 완성품보다 초기 통합 표준에 가깝습니다. 좋은 점은 범위가 투명하다는 것입니다. README는 external mode만 된다고 쓰고, 기본 baseURL이 아직 placeholder라고 밝히며, model catalog도 0.1.0에서는 빈 placeholder라고 적습니다. 또한 작은 로컬 모델의 한계를 문서에 직접 남겼습니다. 이 정도 솔직함은 로컬 AI 도구를 평가할 때 중요합니다.

나쁜 점도 같은 곳에 있습니다. 지금 사용하려면 설치와 서버 실행, 모델 config, 포트 설정, alias 매핑, 에이전트별 model slot 설정을 사용자가 직접 해야 합니다. future 0.2.0에서 provider가 serve process를 auto-spawn하거나 supervise하는 managed mode를 추가할 계획이라고 하지만, 현재는 아닙니다. 제품팀이 일반 사용자용 앱에 넣으려면 installer, model download, 업데이트, 실패 복구, disk usage 표시를 따로 설계해야 합니다.

경쟁 구도에서는 Ollama가 가장 먼저 떠오릅니다. Ollama는 이미 로컬 모델 실행과 OpenAI-compatible API에서 널리 쓰입니다. LM Studio도 데스크톱 UI와 로컬 server를 제공합니다. QVAC의 차별점은 P2P, 다양한 media endpoint, SDK/CLI/AI SDK provider를 한 생태계로 묶으려는 시도입니다. 그러나 개발자 채택은 문서보다 반복 실행 안정성, model catalog 품질, package update 속도, 에이전트 harness와의 실제 호환성에서 갈립니다.

국내 개발팀이 바로 실험한다면 목적을 좁히는 편이 좋습니다. 사내 문서 요약, 소규모 embedding, 음성 전사, OCR처럼 tool use가 약한 경로부터 검증할 수 있습니다. 코딩 에이전트 백엔드로 쓰려면 14B 이상 coder/agent 모델, 충분한 RAM/VRAM, 긴 context, concurrent request 처리, 실패 시 cloud fallback을 함께 테스트해야 합니다. 로컬 모델을 붙였는데 tool call이 누락되면 결과는 "느린 cloud 대체재"가 아니라 "조용히 틀리는 자동화"가 됩니다.

로컬 AI는 provider 경쟁으로 들어갑니다

이번 QVAC 릴리스의 의미는 모델 벤치마크가 아닙니다. 로컬 AI가 provider 경쟁으로 들어온다는 신호입니다. 애플리케이션 개발자는 앞으로 OpenAI, Anthropic, Google, OpenRouter 같은 cloud provider 옆에 Ollama, QVAC, LM Studio, 사내 vLLM endpoint를 놓고 같은 코드 경로에서 비교하려 할 것입니다. 이때 승부는 모델 한 개의 점수가 아니라 provider가 얼마나 안정적으로 streaming, embeddings, tool calling, structured output, audio, image, auth, logging을 맞추는가에서 납니다.

QVAC은 0.1.0에서 이 경로의 첫 조각을 내놨습니다. 얇은 wrapper지만 공식 package이고, OpenAI-compatible server 문서와 연결되며, 코딩 에이전트 한계까지 같이 적혀 있습니다. Tether의 TurboQuant 발표가 로컬 런타임의 메모리 병목을 줄이겠다는 메시지라면, @qvac/ai-sdk-provider는 그 런타임을 TypeScript AI 앱과 에이전트 harness에 꽂겠다는 메시지입니다.

개발자에게 남는 질문은 단순합니다. 로컬 AI를 어디까지 신뢰할 것인가가 아니라, 어떤 작업을 로컬로 보내고 어떤 작업을 cloud로 남길 것인가입니다. QVAC provider는 그 질문을 앱 코드 안에서 실험할 수 있는 새 선택지입니다. 아직 포트, context, concurrency, tool-use 성능 같은 거친 부분이 남아 있지만, 그런 제약을 문서에 드러낸 첫 릴리스라는 점에서 살펴볼 가치가 있습니다.