VRAM을 다 잡아먹지 않는 Ollama용 SQLite 기반 메모리 시스템 개발한다
원문 제목 — Built an SQLite-based memory system for Ollama that doesn't eat all your VRAM
📄 전문 번역
로컬 Ollama 모델에 무거운 벡터 데이터베이스 없이도 문서 영구 메모리를 부여하기 위해 작업 중인 프로젝트를 공유하고자 한다. 이름은 Hillock이다. 표준 로컬 RAG에서 겪은 주요 문제는 문서 파싱과 벡터 검색을 실행하면 VRAM을 너무 많이 잡아먹어 실제 Ollama 모델(Llama 3 8B나 Qwen 등)이 고통스러울 정도로 느리게 돌아간다는 점이었다.
이 도구에 문서를 넣기만 하면 LLM 대신 300MB 미만의 초소형 모델을 이용해 약 5초 만에 팩트를 추출한다. 팩트는 SQLite 데이터베이스에 저장된다. 질문을 하면 하이퍼벡터 수학으로 해당 지식이 실제로 존재하는지 먼저 확인하며, 노트에 없는 내용을 물으면 모델이 환각을 일으키지 못하게 막는다.
CLI에는 /model 명령이 있어 머신에 풀해둔 Ollama 모델을 자동으로 감지하고 모델 간 전환을 가능하게 하며, Open-WebUI를 선호한다면 OpenAI 호환 API도 제공한다. VRAM 1.2GB 미만에서 동작하며(CPU에서도 실행 가능하다). 저장소는 오픈소스로 공개되어 있다.
💬 주요 댓글 번역 (2)
🔍 루키 분석
로컬 LLM 환경에서 벡터 데이터베이스가 VRAM을 과도하게 점유하는 문제를 SQLite 저장과 300MB 미만 초소형 모델 기반 팩트 추출, 하이퍼벡터 검증으로 해결한 오픈소스 프로젝트 Hillock 소식이다. 노트에 없는 질문에는 모델의 환각을 차단하고, VRAM 1.2GB 미만 또는 CPU에서 동작하며 OpenAI 호환 API도 제공한다. 댓글에서는 주제가 겹치는 노트 간 컨텍스트 구분이 논의되었고, 바인딩된 트리플 저장과 헤비안 링크 기반 클러스터 분리로 해결한다는 답변이 이어졌다.
— 루키 · glm-5.3-flash:cloud
영리한 접근법이다. 나도 모델이 로드되기도 전에 Milvus나 Chroma가 메모리를 다 잡아먹는 같은 문제로 고생했다. 모든 것에 7B를 쓰는 대신 초소형 모델로 팩트를 추출하는 방식은 똑똑하다. 사람들은 파이프라인의 '스마트한' 부분이 실제로 얼마나 큰 오버헤드를 추가하는지 인식하지 못한다. 그런데 질문이 있다. 주제가 겹칠 때 하이퍼벡터 검사는 어떻게 동작하는가? 예를 들어 데이터베이스를 다루는 서로 다른 두 프로젝트의 노트를 저장했다면, 어떤 컨텍스트를 가져올지 여전히 구분해낼 수 있는가?
그렇다. 사실 표준 벡터 청킹이 가장 흔히 삐걱거리는 지점이 바로 여기다. '데이터베이스'를 검색하면 두 프로젝트의 청크가 모두 끌려와 뒤섞이기 때문이다. Hillock은 몇 가지 이유로 이를 피한다. 첫째, 느슨한 텍스트 청크 대신 바인딩된 트리플을 저장한다. 즉 (ProjectA -> uses_db -> Postgres)와 (ProjectB -> uses_db -> Redis)를 갖게 된다. 초고차원 수학에서 엔티티를 관계에 바인딩하면 수학적으로 분리되어, Project A의 데이터베이스를 나타내는 하이퍼벡터는 Project B의 것과 사실상 직교한다. 둘째, 헤비안 링크가 각자 별도의 클러스터로 유지해준다. 만약 y