AIREITEREmbeddingGemma 2를 로컬에 배포한다고 해서 기존 임베딩 서비스를 그대로 교체할 수 있는 것은 아닙니다. 애플리케이션 코드는 거의 손대지 않고 런타임만 바꿀 수도 있지만, 벡터 표현 방식이 달라지면 기존 벡터를 다시 생성해야 하는 경우가 많습니다. 안전한 마이그레이션을 위해서는 세 가지를 분리해서 판단해야 합니다. 모델을 어떻게 실행할지, 기존 벡터를 계속 사용할 수 있는지, 그리고 현재 데이터셋에서 멀티모달 검색 품질이 충분한지입니다.
마이그레이션 판단 기준 한눈에 보기
하나의 모델 계열로 텍스트, 코드, 이미지, 동영상, 오디오 임베딩을 로컬에서 처리하고, 통제된 백필 작업을 수행할 수 있다면 EmbeddingGemma 2를 고려할 만합니다. 운영 중인 쿼리 인코더부터 먼저 바꾼 뒤 문서 벡터를 나중에 채우는 방식은 피해야 합니다. 임베딩 모델은 벡터 차원이 같더라도 인덱스 스키마의 일부이기 때문입니다.
| 판단 항목 | 실무적인 답 |
|---|---|
| 로컬 도입 시작점 | 공식 체크포인트를 사용하는 Sentence Transformers |
| 텍스트 전용 규모 | 비전과 오디오를 비활성화했을 때 270M 파라미터 |
| 풀 멀티모달 규모 | 740M 파라미터 |
| 기본 출력 | 768차원 |
| 스토리지 절충안 | 256d부터 테스트하고, 멀티모달 데이터에서는 128d를 더 엄격하게 검증 |
| 기존 벡터 | 전체 표현 계약이 그대로이고 호환성이 입증된 경우에만 재사용 |
| 운영 전환 | 두 번째 인덱스를 만들거나 버전이 붙은 named vector를 사용한 뒤 모델과 인덱스를 함께 전환 |
Google의 모델 카드는 768차원 기준으로 MTEB multilingual v2 61.36, MTEB code v1 78.68, 시각 문서 검색 67.84 NDCG@5, 동영상 검색 50.67 Hit@1, 오디오 검색 69.54 MRR@10을 보고합니다. 다만 이 수치는 참고 기준일 뿐, 실제 쿼리로 직접 테스트하는 과정을 대신할 수는 없습니다.
EmbeddingGemma 2로 옮길 때 달라지는 것과 그대로인 것
EmbeddingGemma 2는 텍스트, 코드, 이미지, 동영상, 오디오를 하나의 768차원 공간에 매핑합니다. 체크포인트는 모듈식으로 구성되어 있으며, 공식 개발자 가이드에는 텍스트 전용 270M 구성, 텍스트와 비전을 함께 쓰는 440M 구성, 텍스트와 오디오를 함께 쓰는 570M 구성, 전체 기능을 포함한 740M 구성이 설명되어 있습니다. 인코더를 끄면 로드되는 가중치와 최대 메모리 사용량은 줄어들지만, 그 자체로 새로운 의미 공간이 만들어지는 것은 아닙니다.
이 차이는 마이그레이션에서 중요합니다. Google은 각 구성이 호환 가능한 벡터 공간을 공유한다고 설명하므로, 270M 구성으로 만든 텍스트 쿼리를 풀 구성으로 만든 EmbeddingGemma 2 문서 벡터와 비교할 수 있습니다. 그렇다고 기존 EmbeddingGemma 1, Qwen, Nomic 또는 API 제공업체의 벡터를 768개 좌표를 가진다는 이유만으로 EmbeddingGemma 2 쿼리에 안전하게 사용할 수 있다는 뜻은 아닙니다.
작업별 입력 형식도 계약의 일부입니다. 비대칭 검색에서 EmbeddingGemma 2는 task: search result | query: ... 같은 검색 쿼리 지시문과 title: ... | text: ... 같은 문서 형식을 기대합니다. 코드 검색에는 별도의 작업 지시문이 사용됩니다. 기존 파이프라인에서 다른 접두사, 청킹 방식, 정규화, 입력 필드를 사용했다면 이를 새로운 표현 버전으로 기록하고 마이그레이션 과정에서 검증해야 합니다.
런타임은 가장 단순한 로컬 경로부터 선택하자
정확성 검증은 Sentence Transformers로 시작하기
공식 모델 카드는 google/embeddinggemma-2를 Sentence Transformers 및 Transformers와 함께 사용하는 방법을 안내합니다. 미디어 입력이 필요하다면 멀티모달 추가 패키지를 설치합니다.
pip install -U "sentence-transformers[image,audio,video]" transformers마이그레이션의 기준 경로로는 이 구성이 가장 적합합니다. 프롬프트 이름, 잘라내기, 정규화, 멀티모달 입력 처리 방식이 공식 예제를 따르기 때문입니다. 반드시 가장 낮은 지연 시간을 제공하는 서빙 방식은 아니지만, 최적화에 들어가기 전에 신뢰할 수 있는 기준선을 확보할 수 있습니다.
텍스트 전용 최소 스모크 테스트는 다음과 같습니다.
from sentence_transformers import SentenceTransformer
model = SentenceTransformer(
"google/embeddinggemma-2",
config_kwargs={"vision_config": None, "audio_config": None},
)
query = model.encode(
"embedding model migration",
prompt_name="SearchQuery",
truncate_dim=256,
normalize_embeddings=True,
)
document = model.encode(
"Rebuild vectors when the embedding representation changes.",
prompt_name="Document",
truncate_dim=256,
normalize_embeddings=True,
)
print(model.similarity(query, document).item())서버, 양자화, 벡터 데이터베이스를 도입하기 전에 이 테스트를 실행하세요. 체크포인트, 작업 프롬프트, 차원 수, 정규화 경로가 서로 맞물려 동작하는지 확인할 수 있습니다.
생태계 런타임은 기능 동등성을 확인한 뒤 사용하기
Google의 개발자 가이드에는 vLLM, Hugging Face Transformers, Sentence Transformers, SGLang, MLX, Ollama, LM Studio, LiteRT가 개발 또는 배포 도구로 소개되어 있습니다. 다만 이 목록은 사용 가능성을 보여주는 자료일 뿐, 모든 런타임이 텍스트, 이미지, 동영상, 오디오, 입력 인터리빙, 작업 접두사, 차원 축소, 배치 처리를 똑같이 지원한다는 의미는 아닙니다.
후보 런타임마다 실제 요청을 보내 다음 다섯 가지를 확인해야 합니다. 정확한 체크포인트 리비전, 사용할 모달리티 입력, 출력 차원, 차원 축소 후 정규화, 쿼리와 문서의 접두사 처리 방식입니다. 텍스트는 빠르게 처리하지만 시각 문서 경로를 무시하는 런타임은 풀 모델과 동등하다고 볼 수 없습니다.
경량 네이티브 서버는 마이그레이션 계획이 아니라 최적화 수단
공개된 embeddinggemma.c 저장소는 CPU, Metal, CUDA, ROCm, Intel XPU 변형을 제공하는 EmbeddingGemma 300M 전용 C11/Metal 스타일 서버입니다. README에는 OpenAI 호환 /v1/embeddings 엔드포인트, 768/512/256/128 차원, 278 MB Q4_0 모델 다운로드가 명시되어 있습니다. 이 프로젝트는 Apple M5 Max에서 llama.cpp 빌드 b8981과 54개 셀을 비교한 결과 기하 평균 1.25배의 성능 우위를 보고합니다. 다만 이는 프로젝트별 처리량 결과이며, 품질 비교도 아니고 740M 체크포인트와 멀티모달 기능이 동등하다는 증거도 아닙니다.
마이그레이션 관점에서 유용한 부분은 API 형태입니다. 애플리케이션이 이미 OpenAI 스타일 임베딩 API를 사용한다면 엔드포인트 호환 로컬 서버로 어댑터 작업을 줄일 수 있습니다. 그래도 서버의 모달리티 및 접두사 처리가 운영 파이프라인과 일치할 때까지는 Sentence Transformers 결과를 정확성 기준으로 유지해야 합니다.
인덱스 재생성 위험: 차원 수만 보면 안 되는 이유
소스에서 벡터를 만드는 함수가 바뀌면 다시 임베딩하기
모델 계열, 모델 버전, 작업 접두사, 정규화, 청킹, 잘라내기 정책, 입력 필드, 유사도 의미론 중 하나라도 바꾼다면 전체 재생성을 전제로 계획하세요. Qdrant의 마이그레이션 가이드와 Nalar의 모델 마이그레이션 분석도 같은 운영 원칙을 강조합니다. 문서 벡터와 쿼리 벡터는 동일한 표현 버전에 속해야 합니다. 차원이 같다는 사실만으로 의미적 호환성이 보장되지는 않습니다.
기존 768차원 벡터를 잘라낸 뒤 256차원 EmbeddingGemma 2 벡터라고 부르면 안 됩니다. EmbeddingGemma 2의 Matryoshka 출력은 지원되는 축소 차원에 맞춰 학습되었으며, 차원을 줄인 뒤에는 다시 정규화해야 합니다. 모델 카드가 제시하는 공식 기준 점수는 다음과 같습니다.
| 차원 | 스토리지 절감 | MTEB multilingual v2 | Code v1 | MIEB Lite | MMEB v2 전체 |
|---|---|---|---|---|---|
| 768 | 1× | 61.36 | 78.68 | 64.64 | 59.01 |
| 512 | 1.5× | 61.17 | 77.24 | 64.32 | 58.38 |
| 256 | 3× | 60.41 | 76.18 | 63.13 | 56.24 |
| 128 | 6× | 57.89 | 71.41 | 59.06 | 45.65 |
공식 모델 카드는 768차원에서 시각 문서 검색 67.84 NDCG@5와 동영상 검색 50.67 Hit@1도 보고합니다. 이 수치는 전체 차원을 사용할 때의 기준선으로 삼고, 축소 차원에 대한 값을 임의로 만들어내서는 안 됩니다. 방향성은 분명합니다. 256d는 128d보다 전체 품질에 훨씬 가깝고, 멀티모달 점수는 128d에서 더 크게 하락합니다. 다른 모델의 벡터를 잘라 쓰지 말고, 선택한 차원으로 공식 체크포인트에서 모든 벡터를 다시 생성하세요.
EmbeddingGemma 2 내부의 공유 공간은 불필요한 작업을 줄여준다
중요한 예외도 있습니다. 기존 데이터셋이 이미 EmbeddingGemma 2로 임베딩되어 있고, 단지 다른 인코더 조합을 로드하는 것이라면 Google의 개발자 가이드에 따라 구성 간 하나의 벡터 공간을 공유합니다. 텍스트 전용 쿼리로 풀 모델이 만든 문서 벡터를 검색할 수 있습니다. 따라서 서빙 프로세스에서 비전이나 오디오 지원을 새로 로드한다는 이유만으로 기존 텍스트 벡터를 다시 생성할 필요는 없을 수 있습니다.
다만 새로 추가되는 미디어 포함 레코드에는 여전히 새 벡터가 필요합니다. 한 번도 임베딩하지 않은 이미지, 동영상, 오디오 항목을 텍스트 전용 인덱스로 검색할 수는 없습니다. 즉, 체크포인트가 그대로여도 멀티모달 검색을 추가하는 순간 데이터셋에 대한 점진적 마이그레이션이 시작됩니다.
블루-그린 전환 또는 named vector를 사용하기
운영 중인 시스템이라면 Qdrant의 마이그레이션 패턴을 기준으로 삼기 좋습니다. 새 컬렉션을 만들고, 새 레코드는 양쪽에 동시에 기록하고, 원본 데이터에서 백필한 다음, Recall@10/MRR/nDCG@10을 비교하고, 별칭을 전환한 뒤 롤백을 위해 기존 컬렉션을 유지하는 방식입니다. Qdrant 가이드에서는 version 1.19.0, 512차원 예제, 100개 포인트 배치를 사용하지만, 이 값들은 예시일 뿐 EmbeddingGemma 2의 필수 조건은 아닙니다.
벡터 데이터베이스가 지원하고 업데이트 경로에서 두 표현을 일관되게 기록할 수 있다면 named vector로 기존 표현과 새 표현을 하나의 컬렉션에 함께 보관할 수도 있습니다. Weaviate의 벡터라이저 마이그레이션 가이드는 운영 환경에서 컬렉션 별칭을 권장합니다. 검증이 끝날 때까지 기존 컬렉션을 남겨두었다가 즉시 롤백할 수 있기 때문입니다. 기존 컬렉션에 벡터를 추가하는 대안은 스토리지를 영구적으로 늘릴 수 있으므로, 깔끔한 최종 상태보다는 비교 작업에 더 적합합니다.
멀티모달 품질은 모델이 바꾸는 데이터 구간별로 검증하기
EmbeddingGemma 2의 공유 공간은 실제 데이터에서 검색 결과가 기대한 대로 나올 때만 의미가 있습니다. 텍스트 전용 벤치마크만으로는 텍스트 검색이 망가지지 않았다는 사실은 확인할 수 있어도 PDF 페이지, 차트, 이미지 캡션, 동영상 프레임, 오디오 클립, 인터리브된 레코드에서 발생하는 문제를 놓칠 수 있습니다.
먼저 다음과 같이 라벨이 분리된 데이터 구간을 준비하세요.
- 텍스트 쿼리 → 텍스트 청크
- 코드 쿼리 → 코드 청크
- 텍스트 쿼리 → 이미지 또는 시각 문서
- 텍스트 쿼리 → 동영상 프레임 또는 오디오 구간
- 텍스트와 미디어가 섞인 쿼리 → 혼합 문서
- 다국어 쿼리 → 서비스 대상 언어로 작성된 문서
첫 멀티모달 기준선으로는 768d 또는 512d를 유지하세요. 공식 모델 카드에 따르면 공유되는 8,192토큰 컨텍스트 안에서 이미지 하나에는 280토큰, 동영상 프레임 하나에는 140토큰, 오디오 1초에는 25토큰이 할당됩니다. 혼합 입력은 동일한 예산을 나눠 쓰므로 텍스트, 이미지, 동영상이 모두 포함된 레코드는 단일 모달리티 입력보다 각 구성 요소에 할당되는 공간이 줄어듭니다.
모델 카드는 128d에서 멀티모달 작업의 품질 하락폭이 텍스트 전용 작업보다 크다고 보고합니다. 따라서 128d는 대규모 텍스트 인덱스에서 우선 후보로 검토할 수는 있어도, 혼합 미디어 아카이브의 기본값으로 삼기에는 적합하지 않습니다. 스토리지 절감 효과를 받아들이기 전에 실제 시각 문서 및 크로스모달 쿼리로 256d를 검증하세요.
통합 EmbeddingGemma 2 파이프라인과 현재의 텍스트/이미지 분리 파이프라인을 동일한 쿼리로 비교해야 합니다. 모델이 공유 공간을 사용한다는 구조만으로 멀티모달 품질을 추정해서는 안 됩니다.
기존 RAG 시스템을 위한 단계별 배포 계획
- 현재 계약을 목록화합니다. 모델 ID, 체크포인트 리비전, 접두사, 청킹 방식, 차원 수, 거리 함수, 정규화, 원본 필드, 이미 인덱싱된 모든 모달리티를 기록합니다.
- 대표 평가 세트를 만듭니다. Recall@k, MRR 또는 nDCG 목표와 함께 텍스트, 코드, 시각 문서, 오디오, 동영상, 언어, 긴 쿼리별 데이터를 따로 구성합니다.
- 로컬 기준선을 세웁니다. 먼저 동일한 데이터셋을 Sentence Transformers로 실행합니다. 임베딩 지연 시간, 검색 지연 시간, 메모리, 인덱스 크기, 오류, 점수 분포를 기록하세요.
- 버전이 지정된 후보 인덱스를 구축합니다. 백필을 재현할 수 있도록 안정적인 문서 ID와 원본 텍스트/미디어를 벡터 저장소 외부에 보관합니다.
- 백필 중 쓰기를 조정합니다. 원본 스냅샷과 변경 사항 재생을 사용하거나, 새 레코드와 수정 레코드를 두 표현 버전에 동시에 기록합니다.
- 운영 쿼리를 섀도잉합니다. 사용자에게 보이는 답변은 바꾸지 않은 채 순위 결과, 빈 결과 비율, 지연 시간, 라벨링된 관련성을 비교합니다.
- 원자적으로 전환합니다. EmbeddingGemma 2 쿼리 인코더와 이에 맞는 인덱스를 하나의 버전 또는 별칭으로 묶습니다. 중간 단계라 하더라도 새 쿼리 인코더를 기존 인덱스에 연결해서는 안 됩니다.
- 롤백 경로를 유지합니다. 대표 트래픽이 승인 기준을 통과할 때까지 기존 인덱스와 쿼리 경로를 보존합니다. 이후 양방향 쓰기를 중단하고 스토리지를 회수합니다.
FAQ
EmbeddingGemma 2를 CPU만으로 실행할 수 있나요?
CPU를 지원하는 런타임을 사용하면 가능합니다. 모델 카드는 bfloat16을 사용할 수 없을 때 float32를 권장하며, 텍스트 전용 구성은 270M 파라미터입니다. CPU 처리량은 런타임, 정밀도, 배치 크기, 하드웨어에 따라 달라지므로 GPU 수치를 가져다 쓰지 말고 실제 데이터셋으로 측정해야 합니다.
런타임 선택은 기준 구현의 정확성, 기능 동등성, 서빙 효율, 새로운 검색 버전을 검증하는 비용 사이의 절충입니다.