LLM Cold Start Derdi: Blob Stream ile Hız Kazanmak
Yapay zekâ tarafında herkes model kalitesini konuşuyor. Ama sahada iş biraz başka dönüyor: model iyi, GPU pahalı, kullanıcı da sabırsız… bir de sistem tam en yoğun anda “ısınma” moduna giriyor. İşte o an, yanı cold start, çoğu zaman bütün deneyimi gölgeliyor (yanlış duymadınız)
İlginç olan şu ki, Ben bu meseleyi ilk kez 2023 sonbaharında, İstanbul’daki bir finans müşterisinde net şekilde gördüm. Replication düzgün çalışıyordu ama yeni pod ayağa — itiraz edebilirsiniz tabi — kalkana kadar geçen birkaç dakika yüzünden SLA raporları şişiyordu. Model büyükse iş daha da uzuyor; önce diske indir, sonra GPU’ya yükle… Kağıt üstünde normal dürüyor ama pratikte baya can sıkıcı.
Microsoft’un Azure Blob Storage ile Run:AI Model Streamer yaklaşımı tam burada devreye giriyor. Fikir basit gibi: modeli önce yerel diske kopyalamak yerine doğrudan akıtmak. Ama etkisi ufak tefek değil. Bilhassa büyük modellerde dakikalarla saniyeler arasındaki fark, hem maliyet hem de kullanıcı deneyimi tarafında ciddi oynuyor — dürüst olayım, biraz hayal kırıklığı —
Ve işler burada ilginçleşiyor.
Neden Cold Start Bu Kadar Pahalı?
Bak şimdi, GPU’lar boş beklesin diye alınmıyor, malum (şaşırtıcı ama gerçek). Bir GPU örneği ayakta durup henüz trafik servis etmiyorsa aslında para yakıyorsunuz demektir. Üstelik sadece fatura kısmı yok; geciken yanıtlar kuyrukları büyütüyor, autoscaler daha fazla replika açıyor. Sistem kendi kendine biraz panikliyor.
Bir de şu var: cold start tek seferlik bir olay değil. Spot VM geri alınır, rolling deployment (belki yanılıyorum ama) yapılır, model swap olur, ölçekleme yukarı çıkar… her seferinde aynı hikâye tekrar edebilir (bizzat test ettim). 2024 Mart’ta Ankara’daki bir telekom projesinde benzer bir senaryoda bunu yaşadık; gece yarısı gelen trafik dalgasında yeni replika sayısı artıyordu ama gerçek kapasite çok geç geliyordu.
İşin aslı şu ki klasik akış iki aşamalı: önce blob’dan diske indiriyorsun, sonra diskten GPU belleğine okuyorsun. Arada gereksiz bir durak var. Hani arabayla gitmek varken yolu uzatıp iki ayrı aktarma yapmışsın gibi düşünün; yolculuk uzuyor, üstelik her aktarmada biraz daha yoruluyorsun. Daha fazla bilgi için
Bir dakika — bununla bitmedi. Daha fazla bilgi için
Bak şimdi, Bence bu çözüm özellikle otomatik ölçeklenen inference kümelerinde çok mantıklı ilerliyor çünkü replica’nın “hazırlık” süresini kısaltınca sistem spike anlarını daha iyi absorbe ediyor. Ama küçük modellerde ya da zaten sıcak tutulan node havuzlarında kazanç aynı dramatiklikte olmayabilir.
Kime Daha Çok Fayda Sağlıyor?
| Senaryo | Kazanç | Dikkat Edilecek Nokta |
|---|---|---|
| Küçük startup | Daha hızlı test ve daha az idle süre | Maliyet/fayda oranını ölçmek şart |
| Büyük enterprise | SLA koruması ve ölçekleme hızında iyileşme | Sürüm yönetimi ve güvenlik kontrolü gerekir |
| Sık spot eviction yaşayan ortam | Ciddi toparlanma avantajı | Trafik dalgaları dikkatle izlenmeli |
| Büyük model servisleri | Saniyeler düzeyinde hazır olma ihtimali | Ağ bant genişliği can alıcı hâle gelir |
Türkiye’de Bu Yaklaşım Nasıl Okunmalı?
Araya gireyim: Bunu Türkiye’deki şirketler açısından değerlendirecek olursam… En çok faydayı genelde regülasyon baskısı olan sektörlerde görüyoruz: finans, sigorta, telekom. Kamuya çalışan entegrasyon projeleri. Çünkü oralarda sadece performans yetmiyor; izlenebilirlik de gerekiyor. Mantıklı değil mi? Kapasite kaybının faturası hemen ortaya çıkıyor.
Geçen yıl Ekim 2024’te İzmir’deki bir kurumsal müşteride benzer bir tartışma yaşadık. Ekip başlangıçta “model zaten cache’lenir” diyordu ama yoğun saatlerde işler öyle yürümüyor tabiî… Trafik sıçrayınca cache’in ne kadar dayandığı ayrı mesele oluyor.
Maliyet Tarafı Gerçekten Ne Diyor?
Maliyet hesabını TL bazında düşününce konu daha netleşiyor. Döviz kuru yüzünden saniye hesabı bile önem kazanabiliyor olabilir (evet biraz sert söylüyorum). Eğer birkaç dakikalık boş GPU süreniz varsa bu doğrudan bütçeye yazılıyor demektir.
E tabi burada bütçe kısıtlıysa alternatif yaklaşım da var: pek çok sistemi baştan değiştirmek yerine önce hot pool stratejisi kurabilirsiniz veya belirli modeller için warm standby kullanabilirsiniz. Yanı illâ en pahalı çözüme atlamak zorunda değilsiniz.
Küçük Ekip mi Büyük Kurum mu?
- Küçük ekipseniz önce ölçün: cold start kaç saniye sürüyor?
- Büyük kurumsanız rollout sırasında hangi replikaların ne kadar süre servise girmediğini izleyin.Trafik tahmininiz düşükse streaming yerine basit ön-yükleme yeterli olabilir.Lakin büyük model + yüksek trafik + sık scale-out varsa stream yaklaşımı baya işe yarar.
Sahada İlk Deneyince Nelere Takıldım?
Açık söyleyeyim; ilk denediğimde her şey pürüzsüz değildi.. Haziran 2024’te Logosoft tarafında yaptığımız iç laboratuvar testinde ağ katmanı yüzünden beklediğimiz hızlanmayı alamadığımız öldü — sorun Run:AI tarafında değilmiş meğer bağlantı sınırıymış! Böyle durumlarda insanın hevesi biraz kırılıyor doğrusu…
Daha sonra darboğazın nerede olduğunu ayrıştırınca tablo netleşti: storage erişim hızı iyi olsa bile node üzerindeki network saturation tüm kazancı yiyebiliyor idi sanılan kadar basit değil yanı. Burada bana en çok yardımcı olan şeylerden biri AZ-305 hazırlığında öğrendiğim mimarı bakışıydı; tek servise bakmıyorsun, zincirin tamamına bakıyorsun.
“Bir şey hızlı” demek yetmiyor ; “nerede hızlı, nerede yavaş” sorusunu sormak gerekiyor. Bilhassa enterprise tarafta monitöring olmadan bu işi sağlıklı yürütmek zor.
Nereden Başlamalı?
İlk Adımlar
Eğer denemek istiyorsanız ilk iş şunu yapın : mevcut cold start sürenizi ölçün. Sonra modeli kaç GB olduğu, kaç replika açıldığı, hangi zamanlarda spike geldiği gibi verileri toplayın. Ölçmeden iyileştirme yapmak göz karartması olur.
Daha sonra küçük bir PoC kurun ; mümkünse üretimden ayrı. Ben genelde üç adımla gidiyorum :
- Trafiği taklit eden sentetik yük oluşturuyorum;
- Klasik loader ile streaming yaklaşımını yan yana karşılaştırıyorum;
- P95 latency, ready time ve fail rate değerlerini not alıyorum;
Eğer sonuç anlamlıysa o zaman prod’a taşıma planını konuşuyorum. Yoksa kağıt üstünde güzel görünen ama pratikte getirisi düşük kalan işler listesine giriyor — üzgünüm ama gerçek bu.
Dengeyi Kaçırmamak Gerek
Bence bu tür yeniliklerde en kritik nokta heyecanla kör olmamak. Her yerde mucize çözüm ararsanız hayal kırıklığı yaşarsınız. Bu servis güçlü, evet ; fakat ağ, storage, node seçimi ve uygulama tasarımı kötü işe tek başına kurtarıcı olmaz.
Beni en çok ikna eden taraf hızdan ziyade operasyonel rahatlık öldü. Rolling update sırasında bekleyen replica sayısını azaltmak, spot reclaim sonrası toparlanmayı hızlandırmak… bunlar günlük hayatta gerçekten işe yarayan şeyler.
Neyse uzatmayayım ; eğer AI inference tarafında ciddi ölçeğiniz varsa bu konuyu mutlaka radarınıza alın.
Sıkça Sorulan Sorular
Cold start tam olarak ne demek?
Yanı cold start, yeni ayağa kalkan ya da yeniden başlayan bir servisin modeli yükleyip istek almaya hazır hâle gelene kadar beklediğimiz süre. LLM senaryolarında bu süre açıkçası ciddi anlamda pahalıya patlıyor.
Aynı çözüm her modelde işe yarar mı?
Hayır, yaramayabilir. Mesela küçük modellerde kazanç oldukça sınırlı kalabiliyor; ama bence çok büyük modellerde fark gerçekten göze çarpıyor.
Run:AI Model Streamer kullanmak zor mu?
Pek zor değil aslında, ama ağ topolojisini doğru kurmanız şart. Tecrübeme göre yanlış yere kurulmuş güzel bir araç pek bir işe yaramıyor.
Bütçem kısıtlıysa ne yapmalıyım?
Önce bir ölçüm alın, hani neyle karşı karşıya olduğunuzu görün. Sonra warm pool veya preloading gibi daha hafif seçeneklere göz atın. Streaming çözümüne ancak gerçekten anlamlı bir fayda sağlıyorsa geçin.
Kaynaklar ve İleri Okuma
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
2 comments