gerekiyor 02 Farklı modellerin farklı tierlarla farklı limitleri olabiliyor 03 İşleri hızlandırmak istediğimizde paralel request atarken connection pool yönetmeliyiz 04 Belli throughput altında müşteriler mutsuz oluyor, fazla kaynakta da throttle sorunun var 05 Dead letter queuelar 06 Altyapıda paralelde yürüyen başka önemli işler spike’lara neden olabiliyor 07 Latency’ler tutarsız. Aynı request bazen 500ms, bazen 5 saniye sürebiliyor 08 Peak saatlerde response time artışı 09 Operasyon maliyeti (sistemin ayakta tutulması) + Hizmet kullanım maliyeti 10 03 Neye Alternatif Arıyoruz? Model Çağrı Akışı - Problemler?
(Asenkron Model Çağrısı) Uygulama Model Servisi (OpenAI/Google/Anthropic) Model Yanıtı Online Predictions (Senkron Model Çağrısı) 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 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...
~%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. Batch Predictions
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ı. Hacim 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! SLA (Fallback) 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. Çözüm 05 Golang’in Resme Girişi Netleşen Resim
seviyede (prometheus, jaeger, grafana v.s.) 01 Taşınabilirlik (portability), kolay dockerize edilmesi, az bağımlılığa sahip olması 02 Daha direkt (overhead’in az), daha az katmanlı bir yapı nedeniyle az kaynak kullanımı 03 Goroutineler ile işleri paralelleştirirken ayrı yönetebilmek 04 Hexagonal architecture gibi genişleyebilir mimariler kullanabilmek, daha kompakt codebase 05 Yapılan işe uygun “olgun” kütüphane zenginliği (cloud, redis, http v.s.) 06
eser
qualiarts
ftakahashi
ikumi_ono
teyamagu
naoya
yusukeiwaki
zozotech
fufufukakaka
shift_evolve
findy_eventslides
estie
lynnandtonic
rasmusluckow
morganepeng
kastner
tammyeverts
rocio
moore
csswizardry
samlambert
pauljervisheath
chrisshort
denniskardys
