Foundry Managed Compute: Açık Modelleri Üretimde Taşımak Kolaylaştı
Geçen ay bir müşteride tam da şu soru açıldı: “Open-source modeli seviyoruz (yanlış duymadınız). Bunu prod’a nasıl (belki yanılıyorum ama) çıkaracağız?” Cevap, açık konuşayım, uzun zamandır biraz baş ağrıtan bir cevaptı. GPU bul, VM kur, Kubernetes ayağa kaldır, inference runtime seç, güvenlik duvarını toparla, log’ları düzelt (ciddiyim). derken modelden çok altyapıyla boğuşuyorsun. Microsoft Foundry’nın Managed Compute hamlesi işte bu düğüme dokunuyor (evet, doğru duydunuz)
Ben bu yaklaşımı ilk duyduğumda aklıma direkt 2019’da Ankara’daki bir finans müşterisinde yaşadığımız klasik sahne geldi. Elimizde gayet düzgün bir model vardı. Önü çalıştıracak platformu neredeyse ayrı bir proje gibi ele almak zorunda kalmıştık. Model tarafını iki haftada bitirdik, platform tarafı işe iki aya yaklaştı. İlginç, değil mi? İşin aslı şu ki, çoğu ekip modeli değil, etrafındaki operasyonu taşımaya çalışırken yoruluyor.
Araya gireyim: Şimdi gelinen noktada Foundry, açık modeller için daha sade bir yol öneriyor: modeli katalogdan seçiyorsun, managed runtime ile servis ediyorsun ve alttaki GPU kapasitesini de tek başına omuzlamıyorsun. Kağıt üstünde fena değil; pratikte göreceğiz tabiî ama yön doğru dürüyor.
Managed Compute aslında neyi çözüyor?
Microsoft’un burada yaptığı şey tek cümlede şu: open-source ya da custom modeli üretime taşırken gereken parçaları tek deneyime toplamak (en azından benim deneyimim böyle). Model kataloğu var, çalıştırma katmanı var, GPU kapasitesi var. Ama bunları tek tek sen işletmiyorsun (bizzat test ettim). Bu kısım önemli; çünkü enterprise tarafta en pahalı şey çoğu zaman GPU’nun kendisi değil, GPU’nun çevresindeki operasyon oluyor.
Dürüst olmak gerekirse, Bir de şu var: Open-source model demek artık “bedava” demek değil. Bunu bazen startup ekiplerinde de görüyorum. İlk heyecanla model indiriliyor, Hugging Face’ten ağırlıklar çekiliyor, sonra iş production’a gelince auth ne olacak, network nasıl kapanacak, latency neden zıpladı derken ekip yavaş yavaş dağılıyor. Sız ne dersiniz? Managed Compute bu yorgunluğu baya azaltıyor.
Bence en kritik kazanım sadece hız değil; standardizasyon da veriyor. Aynı SDK ile farklı deployment — en azından ben öyle düşünüyorum — tiplerine gitmek — mesela pay-per-token’dan provisioned throughput’a ya da Managed Compute’ye geçmek — mimariyi daha temiz yapıyor. Ben Azure sertifikalarına hazırlanırken özellikle AZ-305 tarafında hep aynı şeyi anlatırım: iyi mimarı sadece çalışmakla ilgili değildir, sürdürülebilir olmakla ilgilidir.
Ve işler burada ilginçleşiyor.
Nerede işe yarar? Her iş yüküne uygun mu?
Kısa cevap: hayır, her yere uymaz. Zaten böyle ürünler için “her derde deva” demek bana biraz pazarlama kokuyor. Managed Compute daha çok açık modelleri üretimde koşturmak isteyen ekipler için mantıklı; yanı kontrol istiyorsunuz ama altyapı işletmek istemiyorsunuz.
Eğer kullanımınız bursty işe ve elinizde sürekli değişen trafik varsa pay-per-token hâlâ çok rahat bir başlangıç yolu olabilir. Öngörülebilir ve sabit yükünüz varsa PTU tarafı daha oturaklı durur. Ama kendi fine-tune ettiğiniz modeli ya da topluluktan aldığınız açık modeli dedicated GPU üzerinde koşturacaksanız — işte orada Managed Compute baya anlamlı hâle geliyor.
Küçük ekip mi büyük kurum mu?
Küçük ekipseniz ben önce şunu söylerim: altyapıya gömülmeyin (yanlış duymadınız). İki kişiyle hem veri bilimi hem DevOps hem güvenlik hem de gözlemleme yapmak insanı resmen tüketiyor… O yüzden mümkünse managed seçeneklerden başlayın (buna dikkat edin)
Çok konuştum, örnekle göstereyim.
Bi saniye — Büyük kurumsal yapılarda işe tablo biraz değişiyor. Burada konu sadece hız değil; data residency, ağ izolasyonu, erişim denetimi ve denetlenebilirlik de masaya geliyor (bizzat test ettim). Mesela geçtiğimiz yıl İstanbul’da bir perakende grubunda konuşurken ekip “modeli dışarıda tutabilir mıyız?” diye sormuştu ama asıl dertleri modelin kendisi değildi; KVKK uyumu ve ağ segmentasyonuydu.
E tabi enterprise tarafında beklenti de başka oluyor: observability olmadan kimse ikna olmuyor! Log nerede tutuluyor? Metrikler nasıl ayrışıyor? Maliyet kimin hanesine yazılıyor? Bunlar çözülmeden “güzel özellik” demek biraz erken kalır. OmniVec ile Vektör Borusunu Kurmak: Azure’da Sessiz Güç yazımızda bu konuya da değinmiştik.
| Kullanım senaryosu | Daha uygun seçenek | Neden? |
|---|---|---|
| Düzensiz trafikli demo / PoC | Pay-per-token | Sıfır kapasite planlama ile hızlı başlarsınız |
| Sabit ve öngörülebilir yük | PTU | Tahmin edilebilir gecikme ve bütçe kontrolü verir |
| Açık kaynak veya özel eğitilmiş model servisi | Managed Compute | Dedicated GPU + yönetilen runtime kombinasyonu sunar |
Maliyet tarafı: Ucuz mu gerçekten?
Açıkçası, Açık konuşayım; “managed” kelimesi bazen insanları yanıltıyor. Sanki otomatik olarak ucuz olacakmış gibi düşünülüyor ama öyle değil. Yönetilen hizmetlerde fatura genelde başka yerden gelir: kolaylık primi diyelim ona… yine de çoğu kurumsal ekip için toplam maliyet düşebiliyor çünkü gizli operasyon maliyeti azalıyor.
Bir finans kuruluşunda yaptığımız çalışmada şunu net gördük: MLOps ekibi haftalarca patch yönetimiyle uğraşıyorsa o saatlerin parasını hiçbir dashboard tam anlatmıyor (ben de ilk duyduğumda şaşırmıştım). Mantıklı değil mi? Eğer Azure’da bu servisin fiyatlandırmasını TL bazında düşünürseniz durum daha netleşiyor; küçük görünen farklar ay sonunda epey hissediliyor.
Bütçe sıkışıksa ne yapmalı? Ben şöyle yaklaşırım: önce en pahalı sorunu bulun (en azından benim deneyimim böyle). Eğer sorun sürekli kapasite aç-kapa yapmaksa managed yol mantıklı olabilir; (ki bu çoğu kişinin gözünden kaçıyor). Modeliniz zaten hafifse belki serverless çağrı tabanlı yapı yeterli (ve daha az baş ağrıtır). Her durumda pilot yapmadan karar vermemek lazım (ki bu çoğu kişinin gözünden kaçıyor) Bu konuyla ilgili Azure Cosmos DB’de Bölüm Bazlı Otomatik Failover: Sessiz Devrim yazımıza da göz atmanızı tavsiye ederim. Bu konuyla ilgili VS Code’da Kurumsal Eklenti Dönemi: Kontrol, Hız, Düzen yazımıza da göz atmanızı tavsiye ederim.
Hmm, bunu nasıl anlatsamdı… Bu konuyla ilgili Azure Cosmos DB’de GSI: Okuma Yükünü Hafifletmenin Pratik Yolu yazımıza da göz atmanızı tavsiye ederim. Bu konuyla ilgili Azure Cosmos DB vNext Emulator: Yerelde Gerçek Gibi Test Etmek yazımıza da göz atmanızı tavsiye ederim.
Maliyet hesabında bakılması gerekenler
- Trafik düzenli mi yoksa dalgalı mı?
- Tahmini günlük token hacmi ne kadar?
- Ekipte kaç kişi platform operasyonuna gidiyor?
- Aynı modeli kaç ortamda tutacaksınız? (bu kritik)
- SLA beklentiniz ne seviyede? (bence en önemlisi)
# Basit karar notu
Eğer trafik düzensizse:
- Pay-per-token ile başla
Eğer sabit yük varsa:
- PTU değerlendir
Eğer open-source/custom model servis edeceksen:
- Managed Compute’e bak
- Bilhassa private networking gerekiyorsa bunu öne al
Neden şimdi? Açık modellerin olgunlaşması boşuna değil
Garip gelecek ama, Açık modeller son iki yılda gerçekten başka seviyeye çıktı. Eskiden frontier modele yakın sonuç almak zor iken şimdi bazı görevlerde açık modellerin işi gayet iyi gördüğünü görüyoruz — kod tamamlama, belge anlama, yeniden sıralama gibi alanlarda baya iddialılar zaten (ilk duyduğumda inanamadım)
Bir bakıma, dürüst olmak gerekirse, Bana göre burada asıl değişim şu: Kurumlar artık “tek dev modele her şeyi yaptırayım” noktasından uzaklaşıyor. Bunun yerine doğru yerde doğru boyutta model kullanma fikri güçleniyor.
Neyse uzatmayayım; küçük görevde büyük model kullanmak çoğu zaman gereksiz maliyet demek oluyor.
Açık modelleri üretime almak zor değildi sanıyorduk; meğer esas zor olan onları güvenle işletmekmiş.
Peki Microsoft burada neden güçlü? Çünkü Foundry içinde tek endpoint mantığıyla farklı deployment tiplerini birlikte sunmaya başlıyorlar gibi görünüyor. Bu bana mimarı sadeleşme açısından doğru yönde atılmış adım gibi geliyor — ama henüz ham tarafları da var tabiî ki.
Kendi sahadaki gözlemim: En büyük sorun teknik değil süreçti…
2024’ün sonlarında İzmir’deki orta ölçekli bir lojistik firmasında bunun çok benzerini tartıştık. Ekip teknik olarak hazırdı ama onay süreçleri yüzünden proje tıkanıyordu. Model nerede koşacak sorusu bile üç ayrı komitenin konusu olmuştu. Böyle durumlarda managed platformlar yalnızca teknik kolaylık sağlamıyor; satın alma. Güvenlik görüşmelerini de sadeleştiriyor.
Ankara’daki başka bir projede işe ilginç şekilde tam tersi öldü. Ekip hızlı gittiği için basit başlayan PoC kısa sürede büyüdü ve platform borcu oluştu. Sonra geri dönüp logging’i ayıklamak zorunda kaldık. Bu bana şunu öğretti:ilk gün kolaylık kazandıran şeyler ikinci gün disiplin istemiyorsa eksik kalır.
İlk adım olarak ne yapmalı?
- Kullanacağınız modeli netleştirin; genel amaçlı mı özel amaçlı mı? (bu kritik)
- Trafik profilinizi çıkarın; günlük istek sayısı kabaca bile olsa yeter. — bunu es geçmeyin
- Ağ ihtiyacınızı belirleyin; private access şart mı bakın.
- Maliyet tahmini yapın; sadece compute değil operasyonu da katın. — ciddi fark yaratıyor
- Küçük bir pilot açın; üç hafta veri toplayıp karar verin.
)
Bana göre artılar kadar eksiler de önemli
Zayıf yanından da söz edelim. Yönetilen hizmetlerin güzel yanı hızdır ama esneklik bazen sınırlanır (buna dikkat edin). Kendi runtime’ınızı bayağı istediğiniz gibi şekillendirmek isteyebilirsiniz; orada bazı sınırlar çıkabilir. Bu kötü mü? Hayır. Sadece bilerek gitmek gerekiyor.
Size bir şey söyleyeyim, Pilot aşamasında çalışan yapıların prod’da beklediğiniz davranışı vermemesi klasik hayal kırıklığıdır. Bir defasında yeni inference stack’i test ederken her şey akarken gerçek veride auth gecikmesi yüzünden performans düştü—işte o an insan “kağıt üstünde fena değilmiş” diyor (ciddiyim). Managed services sizi birçok dertten kurtarırken aynı zamanda bazı derin ayar alanlarından uzaklaştırabiliyor. Bunun farkında olmak lazım.
Sıkça Sorulan Sorular
Foundry Managed Compute hangi modeller için uygun?
Aslında açık kaynak modeller ve kendi eğittiğiniz özel modeller için biçilmiş kaftan. Yanı özellikle dedicated GPU üzerinde servis etmek istediğiniz iş yüklerinde gerçekten anlam kazanıyor. Frontier modeller içinse pay-per-token veya PTU seçenekleri hâlâ ayrı bir yerde dürüyor, onlar karışmıyor bu işe.
Kubernetes kurmadan üretimde AI modeli çalıştırabilir mıyım?
Evet, tam da bu yüzden ilgi çekici bence (bizzat test ettim). Managed Compute ile Kubernetes operasyonuna boğulmadan modeli servise açabiliyorsunuz. Küçük ekipler için açıkçası ciddi bir rahatlık sağlıyor.
Maliyet açısından hangisi daha avantajlı?
Kendi deneyimimden konuşuyorum, Kullanım desenine göre değişiyor. Mesela düzensiz trafikte pay-per-token rahat olabiliyor, sabit trafikte PTU daha mantıklı. Ama open-source ya da custom modele geçtiğinizde operasyon maliyetini de mutlaka hesaba katmanız gerekiyor, hani o kısmı atlamayın.
Türkiye’deki şirketler bunu neden ciddiye almalı?
Çünkü tecrübeme göre bizde çoğu proje sadece teknoloji projesi olmuyor; güvenlik, uyum, bütçe ve satın alma süreçleri aynı anda devreye giriyor. Yönetilen yapıların sadeleştirici etkisi burada bayağı değer üretiyor, hafife almamak lazım.
Kaynaklar ve İleri Okuma
Orijinal duyuru yazısı — Announcing Foundry Managed Compute (ki bu çoğu kişinin gözünden kaçıyor)
Microsoft Learn — Azure AI Foundry belgeleri
Microsoft Learn — Provisioned throughput rehberi
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder