Cloud Run üzerinde EmbeddingGemma 2: 1 vCPU'luk int8 servisi, batch'ler büyüyene kadar L4 GPU'yu geçiyor

dev.to'da yayımlanan bir yazı, Google'ın EmbeddingGemma 2 modelini Cloud Run üzerinde bir text-embedding servisi olarak dağıtma sürecini ele alıyor; modeli ayakta tutabilen en küçük instance şeklini ölçüyor ve aynı iş yükünü CPU ile NVIDIA L4 GPU üzerinde fiyatlandırıyor. Sonuç açık sözlü: temel bir 1 vCPU instance, bir embedding servisinin yaptığı işlerin çoğu için en ucuz seçenek ve GPU, yalnızca büyük batch işlerinde maliyetini karşılıyor.

EmbeddingGemma 2 kompakt bir model. Vision ve audio encoder'ları çıkarıldığında ve linear layer'lar int8 olarak saklandığında, text modeli 203,4 MiB yer kaplıyor. Yazı, milyon doküman başına üç dağıtım şeklini fiyatlandıran önceki bir dev.to yazısının devamı niteliğinde ve iki soruya odaklanıyor: CPU servisi en az ne kadar belleğe ihtiyaç duyuyor ve bir L4, boşta geçen süre dahil, kısa bir iş patlaması için gerçekte ne kadar faturalandırıyor?

Minimum CPU özellikleri: 1 vCPU ve 2 GiB

Ölçümler tabanı int8 weight'lerle çalışan 1 vCPU ve 2 GiB olarak belirliyor. Modelin yüklenmesi ve PyTorch, tek bir doküman bile embedding edilmeden yaklaşık 1,35 GiB tükettiği için 1 GiB'lik instance her batch boyutunda eleniyor. Tepe bellek kullanımı ise doküman uzunluğuna bağlı: yaklaşık 135 token'lık 32 dokümanlık bir batch 1.871 MiB tepe değeriyle 2 GiB'e sığarken, aynı sayıda 512 token'lık doküman (modelin sınırı) 3.551 MiB tepe değerine ulaşıyor. Dolayısıyla 2 GiB'lik bir servis uzun dokümanlar için sekiz veya daha az dokümanlık batch'ler gerektiriyor; 32'lik batch'i korumak için ise 4 GiB şart.

Bu minimum konfigürasyonda sorgular medyan 133 ms'de dönüyor, bir milyon dokümanın embedding maliyeti 27,67 dolar ve boşta kalan servis hiçbir ücret oluşturmuyor; çünkü Cloud Run onu sıfıra kadar küçültüyor.

Int4 repack daha küçük ama CPU'da daha yavaş

Yazı ayrıca her linear layer'ı 4-bit gruplar halinde saklayan bir int4 repack de hazırlıyor ve dosyayı 146,1 MiB'a düşürüyor. Retrieval kalitesi neredeyse değişmiyor: SciFact nDCG@10 skoru int8 için 0,836 ve orijinal float32 için 0,854 iken int4'te 0,834 çıkıyor; yani her iki repack de orijinal skorun kabaca yüzde 98'ini koruyor.

Ancak repack, CPU'da ters tepebilir. Sunucu int4 weight'ları yükleme sırasında bir kez float32'e açtığı için sorgular 1,52 kat daha uzun sürüyor (medyan 201 ms), bir milyon dokümanın maliyeti 38,09 dolara çıkıyor ve servis 2 yerine 3 GiB belleğe ihtiyaç duyuyor. Daha küçük dosyanın sağladığı tek kazanç daha küçük bir container image; bu yüzden önerilen minimum özellik int8 repack olarak kalıyor.

L4 GPU'nun kazandığı yer

GPU'nun tuzağı faturalandırma granülerliği. dev.to ölçümlerine göre her izole iş patlaması, işin kendisi saniyeler sürse bile yaklaşık sekiz dakikalık L4 süresi, yani 0,14 dolar olarak faturalandırılmış. Bu boşta kalma ücreti kırılma noktasını belirliyor: tek bir patlama kabaca 5.300 dokümanı aştığında L4, CPU servisinden daha ucuz hale geliyor. Yüksek hacimde bir milyon dokümanın maliyeti CPU'da 27,67 dolar iken L4'te 1,83 dolar.

Bir L4'ü sürekli sıcak tutmak ayda 764 dolar tutuyor; CPU servisi bu parayla 27,6 milyon doküman embedding edebilirdi.

Ağ ve JSON parse dahil istemci tarafından görülen throughput, 64 dokümanlık istekler ve iki eşzamanlı istekle saniyede 171,8 dokümana ulaşıyor. Sunucunun iç zamanlayıcısı 32'lik batch'te saniyede 328,3, 256'lık batch'te ise 192,5 doküman bildiriyor; yani bu GPU için daha küçük batch'ler daha uygun. Dört eşzamanlı 256 dokümanlık istek altında PyTorch'un ayırdığı tepe GPU belleği, L4'ün 22.563 MiB'lik kapasitesinden 14.956 MiB'a ulaşırken modelin kendisi 516 MiB yer tutuyor.

Yazının vardığı pratik reçete şu: sorguları ve küçük indeksleme batch'lerini 1 vCPU'luk int8 serviste sunun; on binlerce dokümanlık bir iş için L4'ü dağıtın, işi çalıştırın ve servisin sıfıra küçülmesine izin verin.

Neden önemli

Embedding servisleri genelde dalgalıdır: düşük hacimli, istikrarlı sorgu trafiğine arada bir yeniden indeksleme koşuları eklenir. Bu benchmark, birçok ekibin aksi halde tahmin etmek zorunda kalacağı ayrımı somut sayılarla ortaya koyuyor; sıfıra küçülebilen bir CPU instance'ın tam olarak nerede ucuz seçenek olmaktan çıktığını ve burst başına kiralanan bir GPU'nun nerede devraldığını gösteriyor.

Bellek rakamları da doğrudan yeniden kullanılabilir. Model artı runtime yükünün herhangi bir iş yapılmadan 1,35 GiB olduğu ve uzun dokümanların batch başına tepe belleği katladığını bilmek, instance boyutlandırmayı deneme-yanılmadan çıkıp aritmetiğe çeviriyor. Int4 sonucu ise yararlı bir negatif bulgu: runtime zaten float32'e dequantize ediyorsa, daha küçük weight'lar otomatik olarak daha ucuz CPU çıkarımı anlamına gelmiyor.