맥미니(M4, 32GB)에 Gemma 4 26B-A4B(Unsloth GGUF)를 상주시켜 쓰고 있습니다. 논문 읽고 질답해주고, 번역도 해주고, 주제를 주면 글도 써주고... 생각보다 일을 너무 잘해서 깜놀하고 있습니다.
임베딩은 카파시 llm-wiki를 초창기부터 계속 구현중입니다. 남들 좋다는거 이것 저것 다 해보는데 아직 잘 모르겠습니다만, RAG검색 시스템을 해 놓으니까 ”그거 뭐였더라...” 하면서 검색하니까 꽤 잘 찾아집니다. 클로드나 코덱스도 그거 써서 제가 스크랩 해 놓은 각종 기록들을 근거로 글을 써줍니다. 사진도 찾아주고 있는데 그전까지는 gemma4 26b가 사진을 읽고 말로 설명해서 글로 적어놓는 “원시적인” 방법을 사용하고 있었습니다. 며칠전 embedding gemma2가 나왔다고 해서 현재 사용중인 bge-m3라는 텍스트만 임베딩하는 모델을 대체할 수 있겠다는 각이나와거 한글날 쉬는 김에 작업을 시작해보았습니다.
게다가 이런 시스템을 맥미니에서도 잘 사용하고 있는 만큼 메모리 압박이 너무 심해서, 메모리를 아끼려고 양자화를 낮추는 것과, 며칠 전 나온 EmbeddingGemma 2로 임베딩을 바꾸는 것을 직접 테스트해 봤습니다.
■ 1. 양자화를 낮추면? (IQ4_XS → Q3_K_M / IQ3_XXS)
- 논문 4편을 주고 사실 확인·이해·판단 22문항으로 비교
· IQ4_XS: 19점 / Q3_K_M: 18.5점 / IQ3_XXS: 17점
- 메모리는 각각 0.8GiB, 2.0GiB 절약
- 순수 생성 속도는 +6~13%였지만, MTP(투기적 디코딩)를 켠 실사용에서는 차이가 없었음
- 3비트 쪽에서 표 숫자를 잘못 읽거나 없는 숫자를 지어내는 오류가 나옴
- 참고: Unsloth의 UD-IQ4_XS도 MoE 전문가 가중치 대부분은 IQ3_S(3.4비트)라서,
"IQ3"으로 내리면 실제로는 2.5비트까지 내려감 (GGUF 헤더 확인)
→ 결론: 논문 읽기용이면 IQ4_XS 유지
■ 2. 임베딩을 BGE-M3 → EmbeddingGemma 2로?
- 텍스트 검색(한국어 위주)
· 포털 회귀 20문항: 둘 다 Hit@3 20/20
· 성경 QA 110문항: Top-1 0.691 → 0.709, Recall@10 0.924 → 0.906 (사실상 동률)
· 검색어 임베딩 332ms → 201ms, 서버 메모리 1.67GB → 1.18GB
- 사진 검색(노트 사진 3,252장, 검색어 36개)
· 기존: LLM이 사진 설명을 쓰고 그 텍스트를 검색 → 1위 적중 21/36
· EmbeddingGemma 2로 사진을 직접 임베딩 → 1위 적중 33/36
· 덤으로 예전 VLM이 만든 사진 분석의 32%가 엉터리였던 것도 발견
- 사진 속 글자 추출은 macOS 내장 OCR(Vision)이 한국어도 잘 읽음 (장당 1초 이내)
→ 결론: 사진 검색은 확실히 이득, 텍스트는 동급. 모델 하나로 통일 가능
■ 주의할 점
- EmbeddingGemma 2는 llama.cpp 최신 빌드(b115xx 이상)에서만 됨. brew 안정판에는 아직 없음
- llama.cpp는 아직 텍스트만 지원 → 이미지 임베딩은 sentence-transformers(PyTorch) 필요
- FP16 금지(BF16/FP32 사용), 검색어·문서에 task 접두어 필수
- Gemma 4의 vision head를 사진 색인용으로만 썼다면 빼도 됨 (약 1.2GB 절약)
천천히 사진 검색부터 단계적으로 전환해 볼 예정입니다.
