Google vLLM TPU 임베딩 지원: 긴 컨텍스트 검색 파이프라인을 GPU 전제에서 벗기는 변화

Google Cloud가 2026년 8월 26일 vLLM에 Cloud TPU 기반 임베딩 추론 지원을 통합했다고 공개했다. 핵심은 단순히 “TPU에서도 임베딩 모델이 돈다”가 아니다. Qwen3-Embedding-8B와 Qwen3-VL-Embedding-8B 같은 긴 컨텍스트·멀티모달 임베딩 모델을 vLLM의 pooling runner로 서빙하고, Google Kubernetes Engine(GKE)에서 TPU와 다른 가속기를 함께 확장하는 운영 방식이 공식 레시피로 정리됐다는 점이다.

검색 의도 관점에서 이 소식은 “벡터 DB를 무엇으로 고를까”보다 한 단계 아래의 문제를 건드린다. RAG 품질은 검색 인덱스만으로 결정되지 않는다. 입력 문서를 어떤 임베딩 모델로 벡터화하는지, 긴 문서를 잘라 처리할 때 pooling state가 안전하게 이어지는지, GPU와 TPU 사이 결과가 얼마나 같은지, 트래픽이 몰릴 때 서빙 용량을 어떻게 늘릴지가 모두 품질과 비용을 흔든다.

특히 엔터프라이즈 검색·추천·분류 시스템은 4K 토큰짜리 텍스트만 다루지 않는다. 정책 문서, 계약서, 로그 묶음, 이미지가 섞인 문서처럼 15K 토큰 이상으로 늘어나는 입력이 흔하다. Google은 TPU 출력과 기준 하드웨어 출력의 cosine similarity가 텍스트 기준 0.999 이상, 멀티모달 기준 0.995 이상이어야 한다는 품질 문턱을 제시했다. 개발팀이 봐야 할 지점은 “새로운 하드웨어”가 아니라 “하드웨어를 바꿔도 검색 결과가 흔들리지 않는가”다.

왜 임베딩 서빙이 병목이 되는가

LLM 앱을 만들 때 많은 팀이 생성 모델 비용만 계산한다. 하지만 실제 사용량이 늘면 임베딩 파이프라인도 병목이 된다. 사용자가 질문할 때마다 쿼리 임베딩이 필요하고, 새 문서가 들어올 때마다 인덱싱 임베딩이 필요하다. 사내 문서 검색처럼 데이터가 계속 바뀌는 서비스는 배치 인덱싱과 실시간 질의가 동시에 돈다.

작은 모델과 짧은 텍스트로 프로토타입을 만들 때는 CPU나 작은 GPU 한 장으로도 충분해 보인다. 문제는 운영 트래픽이다. 문서가 길어지고, 언어가 섞이고, 이미지까지 들어오면 한 요청의 prefill 비용이 커진다. 검색 결과 품질을 올리려고 큰 임베딩 모델을 쓰면 비용과 지연 시간이 같이 늘어난다.

이번 vLLM TPU 통합은 이 지점을 겨냥한다. Google Cloud는 TPU를 vLLM serving engine에 붙이고, GKE Custom Compute Classes로 TPU 예약 용량이 부족할 때 GPU spot 또는 on-demand pool로 fallback하는 구조를 설명했다. 즉, 임베딩 서빙을 특정 가속기 하나에 고정하지 않고 우선순위 기반으로 확장할 수 있게 만드는 방향이다.

긴 컨텍스트에서 StepPool이 중요한 이유

긴 컨텍스트 임베딩의 핵심 위험은 메모리다. 15K 토큰짜리 입력을 한 번에 밀어 넣으면 High Bandwidth Memory(HBM)가 버티지 못할 수 있다. 그래서 chunked prefill이 필요하다. 입력을 여러 step으로 나눠 처리하되, 마지막 embedding pooling 결과는 전체 입력을 반영해야 한다.

여기서 state loss가 생기면 검색 품질은 조용히 망가진다. 에러가 나는 것도 아니고, 벡터가 생성되긴 하는데 긴 문서의 뒷부분이나 이미지 관련 정보가 제대로 반영되지 않을 수 있다. Google은 hybrid StepPool과 CachedRequestState로 pooling state가 step 경계를 넘어 누적되고, request preemption 상황에서도 유지되도록 했다고 설명했다.

개발팀이 이 내용을 실무에 옮길 때는 벤치마크 숫자만 보면 안 된다. 긴 문서 샘플을 따로 만들고, chunk 크기 변경 전후 검색 결과 Top-K가 얼마나 바뀌는지 봐야 한다. 같은 문서 묶음에서 CPU/GPU 기준 벡터와 TPU 벡터의 cosine similarity도 비교해야 한다. 임베딩은 한 번 틀리면 생성 모델이 나중에 바로잡기 어렵다.

GPU와 TPU 결과가 같아야 운영이 쉬워진다

가속기를 바꾸면 속도와 비용은 달라질 수 있다. 하지만 검색 시스템에서는 결과 일관성이 더 중요할 때가 많다. 같은 쿼리에 대해 GPU로 만든 벡터와 TPU로 만든 벡터가 다르면, 인덱스 재생성 전후 검색 결과가 달라진다. 고객지원 봇이라면 어제는 환불 정책을 찾았는데 오늘은 엉뚱한 FAQ를 찾는 문제가 생긴다.

Google이 numerical parity를 전면에 둔 이유가 여기에 있다. 텍스트 기준 0.999, 멀티모달 기준 0.995라는 문턱은 “대충 비슷하다”가 아니라 운영 전환 가능한 수준인지 판단하기 위한 기준이다. 물론 이 숫자가 모든 서비스의 품질을 보장하지는 않는다. embedding similarity가 높아도 실제 retrieval 품질은 데이터셋과 chunking, reranking, 필터 조건에 따라 달라진다.

그래서 전환 절차는 두 단계가 낫다. 첫째, 벡터 자체의 parity를 본다. 둘째, 실제 검색 결과의 parity를 본다. 기존 production query 로그에서 대표 샘플을 뽑고, Top-10 문서 overlap, 정답 문서 recall, reranker 이후 최종 순위를 비교한다. 벡터 수학이 맞아도 제품 품질이 같다는 보장은 없기 때문이다.

어떤 팀이 먼저 검토할 만한가

첫 번째 후보는 대규모 사내 검색을 운영하는 팀이다. 문서 수가 많고, 긴 PDF나 이미지가 섞인 문서가 많고, 인덱싱 주기가 짧다면 임베딩 서빙 비용이 무시하기 어렵다. 특히 글로벌 트래픽에서 특정 시간대에 질의가 몰리는 구조라면 TPU/GPU fallback 설계가 의미 있다.

두 번째는 추천·분류·클러스터링을 한 임베딩 모델로 묶어 쓰는 팀이다. 임베딩 파이프라인이 여러 제품 기능의 공통 기반이면 장애 영향도 커진다. 이 경우 serving engine을 표준화하고, GKE autoscaling과 observability를 붙이는 편이 장기적으로 낫다.

세 번째는 멀티모달 검색을 준비하는 팀이다. 이미지와 텍스트가 섞이면 입력 길이와 전처리 방식이 훨씬 복잡해진다. Qwen3-VL-Embedding-8B처럼 멀티모달 임베딩을 다룰 때는 “이미지까지 넣었더니 속도가 느리다”보다 “텍스트 chunking만 했을 때 이미지 정보가 누락되지 않는가”를 먼저 확인해야 한다.

반대로 월 사용량이 작고 문서가 짧은 팀은 굳이 TPU 전환을 서두를 필요가 없다. 운영 복잡도는 공짜가 아니다. GKE, TPU quota, cold start, XLA compile pre-warming, monitoring까지 다룰 사람이 없다면 managed embedding API나 작은 GPU 서빙이 더 현실적일 수 있다.

도입 전에 잡아야 할 체크포인트

첫째, 기준 데이터셋을 만든다. 짧은 FAQ 100개로 테스트하지 말고 긴 문서, 표가 있는 문서, 이미지가 섞인 문서, 다국어 문서를 포함한다. 둘째, 벡터 parity와 검색 parity를 분리해서 측정한다. 셋째, cold start와 compile pre-warming 시간을 배포 지표에 넣는다. 넷째, TPU 예약 용량이 없을 때 fallback이 실제로 작동하는지 장애 훈련을 해본다.

다섯째, 비용을 token 단위가 아니라 “유효 검색 1회” 기준으로 본다. 임베딩 생성 비용, vector DB read/write, reranking, cache hit rate, 실패 재시도까지 합쳐야 한다. 여섯째, 새 모델로 재인덱싱할 때 rollback 방법을 준비한다. 기존 인덱스와 신규 인덱스를 한동안 병렬로 운영하고 query shadowing으로 차이를 봐야 한다.

실행 체크리스트

• Qwen3-Embedding-8B 또는 현재 사용하는 임베딩 모델로 500개 이상 대표 샘플을 만든다.
• CPU/GPU 기준 벡터와 TPU 벡터의 cosine similarity를 측정한다.
• 실제 쿼리 로그로 Top-K overlap, recall, reranker 후 순위를 비교한다.
• 긴 문서에서 chunked prefill 전후 결과가 흔들리지 않는지 확인한다.
• GKE autoscaling, TPU quota 부족, GPU fallback 상황을 테스트한다.
• cold start와 XLA compile pre-warming 시간을 배포 SLO에 포함한다.
• 비용은 요청 수가 아니라 성공한 검색 1회 기준으로 다시 계산한다.

Google vLLM TPU 임베딩 지원은 “TPU가 GPU보다 낫다”는 단순한 결론이 아니다. 긴 컨텍스트 임베딩을 운영 제품으로 만들 때 필요한 정밀도, state 유지, autoscaling, fallback을 한 번에 검토하게 만든다는 점이 중요하다.