Google Cloud, Qwen3 embedding modellerine yönelik yerel vLLM TPU desteğini getirdi

Google ne yayınladı

26 Ağustos 2026'da Google Cloud, Cheng Zhang'ın dev.to'daki yazısına göre embedding çıkarımı (inference) için yerel vLLM TPU desteğini yayınladı. Çalışmanın merkezinde, metin için Qwen3-Embedding-8B ve multimodal girdi için Qwen3-VL-Embedding-8B yer alıyor ve hedef, sohbet üretimi değil üretim ortamındaki retrieval. Hedeflenen iş yükleri uzun: 16K token sınıfında metin dizileri ve 15K tokenı aşan multimodal girdiler.

vLLM zaten yaygın olarak kullanılan bir açık kaynak serving motoru; sürümün önemi ise TPU'nun bu motor içinde birinci sınıf bir seçenek haline gelmesi. Ekipler, ayrı bir yalnızca-TPU çıkarım sistemi sürdürmek yerine tek bir serving yığınını farklı hızlandırıcı türlerinde çalıştırabiliyor.

Google'ın çözmesi gereken mühendislik sorunları

dev.to yazısı, TPU embedding serving'inin GPU serving'inden ayrıldığı birkaç alanı ele alıyor:

• Tensor hizalama. TPU matris birimleri, tensor'lar tensor-parallel worker'lar arasında bölündüğünde katı bölünebilirlik kuralları dayatır. Google, bölünmüş yürütmenin donanım kısıtları içinde kalırken mantıksal çıktının değişmemesi için vocabulary padding ekledi.
• Parçalı (chunked) prefill ve pooling. Uzun girdiler hızlandırıcı belleğini tüketebilir, bu yüzden prefill parçalara bölünüyor. Embedding'ler bunu karmaşıklaştırıyor çünkü modelin tüm diziyi kapsayan tek bir pooled temsil üretmesi gerekiyor. Google'ın hibrit StepPool tasarımı, pooling durumunu parça sınırları ve istek preempt edilmesi boyunca önbelleğe alınmış istek metadatasıyla taşıyor. Buradaki başarısızlık modu sinsi: yanlış biriktirilmiş bir pooling durumu, bariz bir hata olmadan yanlış vektörler üretiyor.
• Derleme ısınması (compilation warm-up). TPU serving, JAX/XLA derlemesine bağlı ve Google'ın önerisi, pod'ların modeli yükleyip bir ısınma derlemesi çalıştırması ve ancak o zaman sağlıklı rapor vermesi; böylece ilk gerçek istek JIT maliyetini üstlenmiyor.
• Başlangıçtaki başlatma maliyetini ödememek için lazy loading.

Yayınlanan benchmark

Belirli bir yapılandırma için — bf16 hassasiyetinde Qwen3-Embedding-8B, 16K tokendan uzun diziler, 4'lük tensor parallelism — Google, TPU Ironwood üzerinde saniyede toplam 83.996 token ve saniyede 5,13 istek bildiriyor. Yazı, bunun genel bir TPU verisi değil tek bir benchmark noktası olduğu konusunda uyarıyor. Saniyedeki istek sayısı mütevazı görünüyor çünkü her istek binlerce token içeriyor; toplu indeksleme için anlamlı sayı toplam token throughput'u.

Embedding doğruluğu neden üretim doğruluğundan daha katı

Üretilen metindeki küçük sayısal farklar genellikle tolere edilebilir. Embedding'lerde ise küçük farklar en yakın komşu sonuçlarının sırasını değiştirebilir; yani arama kalitesi yalnızca donanım backend'i değiştiği için bozulabilir. Google bu nedenle çapraz donanım vektör eşliğini, referans embedding'lere karşı cosine similarity ile doğruluyor; eşikler metin için en az 0,999, multimodal girdi için 0,995. Yazı, embedding çıkarımını donanımlar arasında taşıyan herkesin yalnızca throughput değil, Recall@K, NDCG, top-k örtüşmesi ve downstream kalitesini de ölçmesini öneriyor.

Sürümden operasyonel yönergeler

Yazı, dikkate değer birkaç özelliği olan bir kurumsal mimari çiziyor. GKE'de TPU kapasitesi birincil havuz, GPU kapasitesi ikincil yedek olarak görev yapabilir; bu, patlamalı yeniden indeksleme işlerine uygundur. Toplu indeksleme ve düşük gecikmeli çevrimiçi sorgular ayrı havuzlarda çalışmalı, çünkü bir kuyruğu paylaşan büyük yeniden indeks işleri çevrimiçi kuyruk gecikmesini mahveder. Bir embedding gateway'i model sürümünü, vektör boyutunu, normalizasyonu, maksimum uzunluğu, pooling yöntemini ve donanım backend'ini izlemelidir; model yükseltmeleri, yeni bir sorgu embedding'ini eski bir indeksle karıştırmak yerine gölge trafikle çift indeks kullanmalıdır.

Dikkat çekmeye değer bir asimetri var: mevcut tasarımda multimodal prefill'in metin kısmı parçalara bölünüyor ama görsel kısım bölünmüyor; bu da görüntü özelliklerinin getirdiği ek bellek ve pooling karmaşıklığını yansıtıyor.

Yazı ayrıca TPU'nun otomatik olarak daha iyi bir seçenek olmadığını açıkça belirtiyor; bu platforma, model desteğine, iş yükü biçimine, maliyete ve ekip uzmanlığına bağlı.

Neden önemli

Embedding çıkarımı, genel LLM serving'inden ayrılıp kendi başına bir üretim disiplinine dönüşüyor; kendine özgü gereksinimlerle: indeksleme için yüksek token throughput'u, sorgular için düşük gecikme, tekrarlanabilir vektör uzayları ve elastik kapasite. Bu sürüm, dördünü de ana akım bir açık kaynak motoru içinde TPU donanımında karşılıyor. RAG sistemleri kuran ekipler için cevapladığı pratik soru, bir embedding modelinin başka bir hızlandırıcıda çalışıp çalışamayacağı değil; altyapının, retrieval kalitesini sessizce bozmadan ölçeklenip donanım değiştirebilip değiştiremeyeceği. Katı cosine eşlik eşikleri Google'ın bu soruna verdiği cevap ve backend'ler arasında embedding iş yükleri taşıyan herkes için makul bir çıta belirliyor.