Scaling Without Bankruptcy

GDG DevFest İstanbul 2025 için yapmış olduğum sunum

Transcript

1. Scaling Without Bankruptcy: Leveraging LLM Batch Services with Golang’s Parallelism Eser Özvataf Fellow @ T-Fashion youtube.com/@eserozvataf 07/12/2025
3. Bugün Aktaracaklarım 01 Kişisel Geçmişim 02 Hikaye / Vaka Analizi 03 Neye Alternatif Arıyoruz? 04 Vertex AI Batch P. 05 Golang’in Resme Girişi 06 B.F.O. Projesi 07 Kapanış / Sorular
4. Çalışmalarımı incelemek için https://eser.dev’i ziyaret edebilirsiniz. youtube.com/@eserozvataf 01 Kişisel Geçmişim > 30 Yıl Kod > 50 Konferans Sunum > 70 YouTube Video > 200 Açık GitHub Repo
5. 02 Hikaye / Vaka Analizi
6. 03 Neye Alternatif Arıyoruz? Problemler: - Rate Limiting (RPM ayarlamak, yönetmek zorundayız) - Retry logic yönetmek gerekiyor - Farklı modellerin farklı tierlarla farklı limitleri olabiliyor - İşleri hızlandırmak istediğimizde paralel request atarken connection pool yönetmeliyiz - Belli throughput altında müşteriler mutsuz oluyor, fazla kaynakta da throttle sorunun var - Dead letter queuelar - Altyapıda paralelde yürüyen başka önemli işler spike’lara neden olabiliyor - Latency’ler tutarsız. Aynı request bazen 500ms, bazen 5 saniye sürebiliyor - Peak saatlerde response time artışı - Operasyon maliyeti (sistemin ayakta tutulması) + Hizmet kullanım maliyeti
7. 03 Neye Alternatif Arıyoruz? Senkron Model Çağrısı (gemini-2.5-flash)
8. Hepimizin en alışık olduğu akış. Anlık yanıt ihtiyacımızın olduğu durumlarda direkt web servis çağrısı gibi kullandığımız yaklaşım 04 Vertex AI Batch P. Model Çağrısı Online Predictions (Senkron Model Çağrısı) Batch Predictions (Asenkron + DSQ) Anlık yanıt gerektirmeyen analiz benzeri toplu veri işleme senaryolarında kullanılabilecek akış. Tablolar halinde asenkron bir çağrı yaklaşımı Ama bir dizi dezavantaj da mevcut.
9. Batch Predictions Maliyet Optimizasyonu Online predictions'a kıyasla ~%50 daha düşük birim maliyet. Yüksek hacimli işlemlerde bu fark ciddi bütçe tasarrufu sağlıyor. Rate Limit Sorunu Yok (Dynamic Shared Quota) Online API'lerde RPM/TPM limitlerine takılmak yerine, yüz binlerce kaydı tek job olarak submit edebiliyoruz. Implementasyon Basitliği Retry mekanizması, error handling ve job scheduling Google tarafından yönetiliyor. Kendi queue sistemimizi yazmamıza gerek kalmadı. Kaynak Verimliliği Kendi sunucularımızda connection pool, concurrent request yönetimi gibi karmaşıklıklarla uğraşmıyoruz. Ölçeklenebilirlik Veri hacmi arttıkça infrastructure tarafında değişiklik yapmadan aynı pipeline'ı kullanmaya devam edebiliyoruz. BigQuery Entegrasyonu Input/output doğrudan BigQuery tablolarından okunup yazılabiliyor. ETL süreçleriyle doğal bir uyum sağlayabiliyor. 04 Vertex AI Batch P.
10. Netleşen Resim Hacim Tek bir moda haftası için ortalama 60 bin çağrı. Her analiz parametresi değiştiğinde (ki müşteri geri dönüşleriyle 3 - 4 faz olabiliyor) tekrar edilmesiyle ortalama 200 bin çağrı. Sosyal medyayı da dahil ettiğimizde… Son 30 günde 2.5 milyon çağrı. Input+Output 10 milyardan fazla token kullanımı. SLA Son kullanıcılara sunduğumuz bir hizmet var ve B2B modelimizde sözleşmelerle garanti altına alınıyor. Moda etkinliklerinin, sosyal medyada olan bitenin analizlerle platforma eklenmesi için müşterilerimize bir taahhüt veriyoruz. Bu taahhüt süreleri yaklaşınca batch’den online’a geri dönmemiz gerekebilir! İhtiyaç Startup denkleminde ~%50’e yakın maliyet avantajı olmazsa olmaz. Ancak “Batch” yapısının kendine has bir denklemi var. Buna adapte olabilecek ve yığın işlem de olsa elimizdeki veriyi son kullanıcıları en az bekleterek modellere işletebilecek bir çözüm gerekiyor. 05 Golang’in Resme Girişi
11. 06 B.F.O. Projesi
12. 06 B.F.O. Projesi
13. 06 B.F.O. Projesi go run ./cmd/cli system reset --confirm go run ./cmd/cli bucket new test go run ./cmd/cli task load --model bfo-echo --count 4000 --batch-id Demo
14. Sorular? 07 Kapanış / Sorular youtube.com/@eserozvataf