Foundry Managed Compute: Açık Modelleri Kendi GPU’nuzda

Açık kaynak modellerle ilgili kafamda uzun zamandır şu soru dönüp duruyordu: Bir LLaMA türevini ya da küçük, uzmanlaşmış bir modeli üretime almak istediğinizde, neden hâlâ bu kadar uğraşıyoruz? GPU VM kirala, Kubernetes kur, runtime seç, container’ı sertleştir, CVE’leri yamala, observability bağla… Liste uzayıp gidiyor. Geçen ay bir bankacılık müşterisinde tam da bu yüzden bir POC’yi 2 haftadan 6 haftaya çektik; işin model tarafı değil, etrafındaki o kurum içi araç gereç bizi yordu. Evet.

Garip gelecek ama, Şimdi Microsoft, Build 2026’da Foundry Managed Compute diye bir şey duyurdu. Açık konuşayım, bunu görünce “nihayet” dedim; çünkü uzun süredir eksik kalan parça biraz da buydu. Hugging Face’teki binlerce modeli Foundry’nın tek endpoint’i üzerinden, kendi GPU’larınıza özel olarak deploy edebiliyorsunuz, hem de Kubernetes yönetmeden, runtime seçmeden, container imajlarıyla boğuşmadan. Güzel tarafı burada bitmiyor gıbı duruyor ama dür bir saniye — işin içinde birkaç hayatı sınır da var. Peki, peki neden?

Durun, bir saniye.

Bak şimdi, lafı gevelemeden anlatayım: Bu yazıda Managed Compute’un ne olduğunu, Foundry’deki diğer deployment tiplerinden nasıl ayrıldığını, Türkiye’deki kurumsal müşteriler açısından ne anlama geldiğini. Sahaya çıkarken hangı noktalarda tökezleyebileceğinizi paylaşacağım. Birkaç kişisel saha gözlemi de eklerim; çünkü teoride her şey temiz görünüyor ama pratikte bazen ufak bir ayar bütün tabloyu değiştiriyor. Neyse uzatmayalım.

Managed Compute Tam Olarak Ne Çözüyor?

İşin aslı şu: Açık kaynak modeller baya olgunlaştı. En iyi açık modeller, reasoning. Coding benchmark’larında frontier modellere kafa tutuyor, hatta bazı alanlarda yan yana gidiyor; küçük ve uzmanlaşmış modeller de (doküman anlama, re-ranking, code completion, domain-specific chat gıbı) belli işlerde büyük modellere göre daha az maliyetle ve daha hızlı sonuç veriyor.

Peki neden hâlâ herkes managed API’lere dönüyor? Çünkü açık modeli prod’a almak, kulağa basit gelse de, gerçekte epey uğraştırıyor. Mesela geçen sene İstanbul’da bir e-ticaret müşterisinde Mistral tabanlı bir öneri modeli denemiştik; modelin kendisini eğitmek 2 hafta sürdü ama üretime almak iki ay aldı. AKS cluster’ı, vLLM runtime’ı, networking, monitoring, autoscaling… her biri ayrı bir iş çıktı.

Managed Compute tam burada devreye giriyor. Üç şeyi aynı sepete koyuyor:

• Foundry Model Catalog — Hugging Face entegrasyonu ile binlerce model
• Optimize edilmiş runtime’lar — vLLM, TensorRT-LLM gıbı inference engine’ler hazır kurulu
• Elastik GPU kapasitesi — Saatlik faturalandırma var, VM yönetimiyle uğraşmıyorsunuz

Yanı siz sadece “şu modeli istiyorum, şu GPU ailesinde çalışsın” diyorsunuz (kendi tecrübem). Sonrası Foundry’nın işi oluyor — Patching, runtime güncellemesi, networking, auth… — bunların hiçbiriyle tek tek boğuşmuyorsunuz. En azından kâğıt üstünde tablo böyle. Sahada nasıl dönecek, önü da biraz zaman gösterir.

Evet.

Foundry’deki Üç Deployment Tipinin Farkı

Foundry tarafında artık üç deployment tipi var. Hangisini ne zaman seçeceğinizi netleştirmek için, lafı uzatmadan bir tablo koyayım:

Bence en hayatı nokta şu: Üç deployment tipi de aynı SDK, aynı endpoint paterni. tek fatura üzerinden çalışıyor. Yanı kod tarafında neredeyse hiçbir şeyi kurcalamıyorsunuz. Bir route’u GPT-4’ten Llama-3’e taşımak istiyorsanız, — en azından ben öyle düşünüyorum — çoğu zaman sadece config değiştiriyorsunuz; geri kalan yerler aynı kalıyor. İyi tarafı bu. Ama dür bir saniye — asıl güzel kısım, mimariyi bozmeden model değiştirebilmeniz.

Evet.

Saha gözlemim: Çoğu kurumsal AI projesi “hibrit” bitiyor. Yanı genel sohbet için frontier model (GPT-4), domain-specific görevler için fine-tune edilmiş küçük model. Managed Compute bu hibrit mimariyi tek platformda toplamasıyla değer üretiyor.

Kendi deneyimimden konuşuyorum, Neyse, burada işin asıl pratik tarafı çıkıyor. Pay-per-token hızlı başlamak için baya iş görüyor; PTU işe “benim yüküm belli, sürpriz istemiyorum” diyen ekipler için daha rahat bir yol gıbı duruyor. Managed Compute tarafında işe açık kaynak modellerle oynayabiliyorsunuz, ama işin içine GPU ailesi, saatlik maliyet. Tahmin eder mısınız? Operasyonel detaylar girince konu bir anda başka yere kayıyor.

Bir bakıma, peki neden?

Çünkü Foundry’nın olayı sadece model sunmak değil, modeli çalışma biçimine göre seçtiriyor olması (evet, doğru duydunuz). Az önce söylediğim hibrit senaryo var ya, işte tam orada Managed Compute devreye girince güzel oturuyor; ama sadece sohbet botu yapıyorsanız. Trafik dalgalanıyorsa, pay-per-token çoğu zaman daha az kafa ağrıtıyor.

Daha açık söyleyeyim, kendi deneyimimden konuşuyorum, Siz ne dersiniz? Ben açık konuşayım, ilk denemede çoğu ekip gereğinden büyük çözüm seçiyor. Sonra biraz sadeleşince her şey yerine oturuyor (bizzat test ettim)

Türkiye’deki Kurumsal Müşteriler Açısından Ne İfade Ediyor?

İlginç olan şu ki, Şimdi işin Türkiye tarafına gelelim. Yıllardır müşterilerle aynı — ki bu tartışılır — soruyu dönüp dolaşıp konuşuyorum: “Açık kaynak modeli niye kendi sunucumuzda çalıştırmıyoruz? Veri Türkiye’den çıkmasın, bir de maliyet elimizde kalsın.” Sorunun kendisi gayet yerinde. Ama cevap genelde pek değişmiyor: pahalı, uğraştırıyor, bir de işi bilen adam bulmak zor.

Hani, Bizde özellikle finans ve kamu tarafı bu konuya daha temkinli bakıyor. KVKK var, BDDK var, veri rezidansı var… Şimdi, her biri ayrı başlık, ayrı kontrol listesi. Managed Compute’un Azure’un Türkiye bölgesinde (ya da Avrupa bölgelerinde) sunulması işe bunların önemli bir kısmını hafifletiyor; çünkü model ağırlıkları sizin tenant’ınızda kalabiliyor, Hugging Face’e canlı çağrı yapmıyor, inference trafiği private endpoint üzerinden akabiliyor ve eğitim datanız da Azure Storage içinde duruyor, dışarı taşmıyor.

Kısa bir not düşeyim buraya.

• Model ağırlıkları sizin tenant’ınızda — Hugging Face’e canlı çağrı yapmıyor (bu kritik)
• Inference trafiği private endpoint üzerinden geçebiliyor
• Eğitim datanız Azure storage’da kalıyor, dışarı çıkmıyor
• Fatura tek bir EA üzerinden — finans ekibinizin başını ağrıtmıyor

Daha açık söyleyeyim, geçen ay bir sigorta şirketinde tam bu mevzuda workshop yaptık. Compliance ekibi 3 ay süren due bir düşüneyim… diligence sonunda Azure OpenAI’a “tamam” demişti; şimdi açık model gerekiyor (poliçe doküman özetleme için Türkçe performans tarafında fine-tune lazım),. Onlar bu süreci sıfırdan tekrar açmak istemiyorlar. Managed Compute gıbı bir çözüm burada nefes aldırıyor, çünkü aynı governance devam ediyor, aynı network korunuyor. Fatura tarafı da dağılıp gitmiyor.

Yanı, Evet.

Şöyle söyleyeyim, Bir de şu kısmı atlamayalım. Türkiye’deki birçok orta ölçekli şirket kendi GPU sunucusunu almaya biraz mesafeli duruyor. Haklılar da; H100 fiyatları zaten can sıkıyor, üstüne datacenter masrafı geliyor, soğutma ayrı dert, bakım ayrı dert… saatlik kullanım modeli işe bu şirketler için baya iş görüyor. En çok da de batch işler varsa ya da sistem sadece iş saatleri dışında kullanılacaksa.

Bilmem anlatabiliyor muyum, Daha açık söyleyeyim, peki neden? (kendi tecrübem)

Açık konuşayım, mesele sadece teknik değil. Bazen karar tamamen operasyonel rahatlıkla ilgili oluyor; yanı ekip küçükse, süreç ağırsa. Bütçe de dikkatle yönetiliyorsa, “kendi GPU’muzu alalım” fikri ilk bakışta mantıklı gelse bile pratikte biraz yorucu kalabiliyor.

Maliyet Tarafı: TL Bazında Düşünürsek

Bak şimdi, Açık konuşayım, fiyatlandırma tarafı henüz tam oturmadı, GA sonrası net rakamları göreceğiz. Ama işin mantığı kabaca şu: GPU ailesine göre saatlik ücret geliyor, yanı A100 başka, H100 başka, MI300X başka fiyatlanıyor. Kendi VM’ınızı kiralamaktan farkı da burada başlıyor; runtime, patching, network ayarı ve benzeri işler paketin içine giriyor.

Şöyle düşünün kafanızda: Bir A100 80GB VM, Azure’da saatlik yaklaşık 3-4 dolar bandında geziyor. Üstüne bir DevOps mühendisi koyun (en az yarı zamanlı), sonra runtime lisanslarını. Monitoring araçlarını ekleyin — işin aslı maliyet bunun belki de iki katına çıkıyor (en azından benim deneyimim böyle). Managed Compute tarafı saatlik biraz daha pahalı olabilir ama TCO hesabında tablo değişiyor; çünkü operasyon yükünün çoğu içerde çözülüyor, siz de mühendisliği başka bir işe kaydırabiliyorsunuz (en azından benim deneyimim böyle)

Bakın, i̇lginç olan şu ki, Küçük bir ekipseniz, ben Managed Compute tarafına daha yakın dururum. Çünkü o DevOps işini tek başınıza çevirmek kolay değil; hele Türkiye’de ML Ops bilen insan bulmak zaten ayrı dert, bunu yaşayan bilir. Büyük kurumsal yapıda olup. Bir AKS platform ekibiniz varsa, kendi MLOps kurulumunuzu yapmak hâlâ mantıklı kalabilir. Ama ekip yoksa, açık söyleyeyim, bu işe hiç başlamayın.

Bir dakika — bununla bitmedi. Microsoft Agent Framework BUILD 2026: Saha Notlarım ve yazımızda bu konuya da değinmiştik. Bu konuyla ilgili GPT-5.2 ve GPT-5.2-Codex Emekli: Copilot’ta Geçiş Notları yazımıza da göz atmanızı tavsiye ederim.

Pratik Uygulama: İlk Adımlar

Managed Compute’u denemek istiyorsanız, ben olsam akışı şöyle kurarım. Önce use case’i netleştiririm; çünkü “açık model lazım” demek tek başına pek bir şey anlatmıyor, hangı görev, hangı dil, hangı latency hedefi, hangı throughput, bunları baştan yazmazsanız sonra benchmark tablosu da biraz havada kalıyor.

1. Use case’i netleştirin. “Açık model lazım” demek yetmez. Hangı görev? Hangı dil? Hangı latency hedefi? Hangı throughput? — ciddi fark yaratıyor
2. Model catalog’u tarayın. Foundry’nın Hugging Face entegrasyonu üzerinden uygun adayları listele. Türkçe için Mistral, Qwen, Llama-3 türevleri iyi başlangıç.
3. Önce pay-per-token deneyin. Eğer aynı use case için first-party bir model varsa, önce onunla POC yapın. Sonuçları benchmark edin.
4. Managed Compute’a açık modelle geçin. Aynı promptları çalıştırın, kalite/maliyet/latency üçgenini ölçün.
5. Fine-tuning kararını sonra verin. Out-of-the-box yeterli mi? Yeterli değilse SFT veya RL ile özelleştirme yapın.

Açık konuşayım, Evet. İşin omurgası bu kadar basit görünüyor.

Tipik bir endpoint çağrısı şuna benziyor (yaklaşık olarak — API yüzeyi GA’da netleşir):

from Azure.ai.foundry import FoundryClient
client = FoundryClient(
endpoint="https://your-project.foundry.Azure.com",
credential=DefaultAzureCredential()
)
response = client.chat.completions.create(
model="llama-3-70b-instruct", # Managed Compute deployment
messages=[
{"role": "system", "content": "Sen bir sigorta uzmanısın."},
{"role": "user", "content": "Bu poliçenin temel kapsamı nedir?"}
],
temperature=0.3
)
print(response.choices[0].message.content)

Gördüğünüz gıbı, Azure OpenAI çağrısından neredeyse ayırt edilemez. Tek değişen model parametresi; yanı kod tarafında büyük bir kırılma yaşamıyorsunuz, mevcut entegrasyonu bozup yeniden yazmak yerine sadece hedef modeli değiştiriyorsunuz. Bu da ekipler için baya iş görüyor.

Dikkat Edilmesi Gereken Noktalar

Her şey güllük gülistanlık değil tabi. Sahada gözlemlediğim ve sizin de düşünmeniz gereken birkaç nokta var; hani ilk bakışta küçük duruyorlar ama üretime çıkınca can sıkabiliyorlar, özellikle GPU tarafında iş büyüyünce tablo bir anda değişiyor (kendi tecrübem) Daha fazla bilgi için Azure Document Translation Build 2026: Görsel ve LLM Devri yazımıza bakabilirsiniz.

Bir dakika — bununla bitmedi.

• Cold start süresi: GPU deployment’ları anında ayağa kalkmaz. İlk istek için 1-3 dakika beklemek normal. Üretimde scale-to-zero kullanırken bunu unutmayın. — ciddi fark yaratıyor
• Model lisansları: Hugging Face’teki her model ticarî kullanıma açık değil. Llama-3 ticarî kullanıma açık ama 700M üzeri kullanıcı şartı var. Mistral’in bazı versiyonları farklı. Hukuk ekibinizle konuşun.
• Türkçe performansı: Açık modellerin Türkçe kalitesi, GPT-4’ten hâlâ geride. Fine-tuning olmadan üretime sokmayın. Bu konuda Logosoft’ta birkaç projemizde acı tecrübe yaşadık. (bu kritik)
• Quota yönetimi: GPU kapasitesi sınırsız değil. En çok da H100 bölgelere göre kısıtlı. Capacity planning yapın, sonradan ağlamayın.

Peki neden? Çünkü tek başına model seçmek yetmiyor; runtime davranışı, kapasite planlaması ve lisans meselesi de en az model kadar söz sahibi oluyor. Kısacası, tam da öyle.

Neyse uzatmayalım; doğru use case ile başlanırsa Managed Compute gerçekten mantıklı bir kapı açıyor, yanlış yerden girerseniz de size sadece daha pahalı bir POC bırakıyor.

Fine-Tuning ve Kendi Modelinizi Getirme

Kısacası, i̇lginç olan şu ki, Managed Compute tarafında hoşuma giden şeylerden biri şu: Sadece catalog’daki modelleri koşturup durmuyorsunuz, kendi eğittiğiniz model ağırlıklarını da alıp deploy edebiliyorsunuz. Bu, özellikle Türkiye’deki araştırma kurumları ve üniversiteler için baya iş görüyor. ITU’de geçen sene tanıştığım bir doktora öğrencisi vardı; kendi Türkçe NER modelini üretime almak için aylarca uğraşmıştı, hani bir noktadan sonra iş modelden çok altyapı kavgasına dönmüştü, şimdi o senaryo epey daha rahat akıyor.

Şahsen, Desteklenen özelleştirme yöntemleri de şöyle:

• Supervised Fine-Tuning (SFT): Klasik etiketli veri ile eğitim
• Reinforcement Learning: RLHF veya DPO benzeri yaklaşımlar
• Bring-your-own weights: Başka yerde eğitilmiş ağırlıkları güvenli şekilde deploy

Hmm, bir düşüneyim… RL tarafı için açıkçası henüz çok detay yok. Yanı bu kısım biraz havada kalıyor gıbı,. Sanırım GA’ya yaklaşınca daha net dokümantasyon gelir (öyle umuyorum en azından). Şu an elinizde hızlıca ilerlemek varsa, en pratik yol SFT gıbı duruyor. Evet.

Benim Saha Değerlendirmem

Bütün tabloya yukarıdan bakınca, Managed Compute fena değil. Hatta işin aslı, doğru tarafa atılmış bir adım gıbı duruyor. Foundry’yi gerçekten “tek platform” hissine yaklaştırıyor. Daha önce frontier modeller için Azure OpenAI tarafına gitmek, açık modellerde işe ya AKS kurmak ya da Hugging Face Inference Endpoints’e yönelmek gerekiyordu, yanı iş biraz parçalıydı, şimdi işe tek yerden toparlamak mümkün oluyor.

Küçük bir detay: Yalnız burada küçük bir fren var. Henüz tam olgunlaşmış sayılmaz. Önümüzdeki birkaç ay içinde GA sürecinde gerçek üretim yüklerini görmemiz gerekiyor, yoksa kağıt üstünde iyi duran şey sahada tökezleyebiliyor; özellikle multi-region failover, observability derinliği ve fine-tuning maliyet kontrolü tarafında netleşmeyen noktalar var, o yüzden erken adopter olmak isteyenler için alan açıyor ama mission-critical iş yüklerini hemen taşımak bana biraz acele gıbı geliyor.

Hmm, bunu nasıl anlatsamdı…

Bir-iki çeyrek beklemek bence daha akıllıca. Evet.

Ha bu arada, eğer Foundry’nın agent tarafı da ilginizi çekiyorsa, Foundry’de Agent Dağıtımı: Teams. M365 Copilot Devri yazımdaki dağıtım yaklaşımı burayla baya iyi örtüşüyor. Bir de Managed Compute üzerinde çalışan agent’lar için Agent Sandbox: Kubernetes’te AI Agent’ları Çalıştırmak yazısı var; eğer kendi K8s ortamınızı yönetmeye karar verirseniz, orası da iyi bir karşılaştırma noktası sunuyor, hatta bazı yerlerde insanı “şey, bunu neden daha önce düşünmedik?” dedirtiyor.

Peki neden? Çünkü aynı problemi farklı katmanlarda görüyorsunuz. Bir tarafta servis yönetimi var, öbür tarafta operasyon yükü; ikisini birlikte okuyunca resim daha net çıkıyor. Tam da öyle.

Sıkça Sorulan Sorular

Managed Compute, Azure ML’den farklı bir şey mi?

Evet, tamamen ayrı bir hizmet bunlar. Azure ML hani daha genel amaçlı bir ML platformu. Managed Compute işe özellikle LLM ve generative AI iş yükleri için tasarlanmış — Foundry catalog’una sıkı entegre, runtime’ları önceden hazır geliyor. Azure ML’de bir LLM deploy etmek istediğinizde inference container’ı kendiniz ayarlamanız gerekiyordu; burada o dert yok, açıkçası bu tek başına büyük bir fark (kendi tecrübem)

Pay-per-token mı, Managed Compute mu seçmeliyim?

Temel kural şu: Hızlı başlamak istiyorsanız veya trafiğiniz dalgalıysa pay-per-token. Açık kaynak model lazımsa, veri rezidansı kritikse ya da yüksek hacimli tahmin edilebilir yükünüz varsa Managed Compute. Aslında ikisini aynı anda kullanmanız da mümkün — mesela farklı route’ları farklı modellere yönlendirebilirsiniz, yanı birini seçmek zorunda değilsiniz.

Evet, doğru duydunuz.

Hangı GPU aileleri destekleniyor?

Duyuruya göre NVIDIA A100, H100 ve AMD MI300X aileleri öne çıkıyor. Bölgeden bölgeye değişiyor bu. Türkiye’deki Azure bölgelerinde hangı GPU’ların ne zaman geleceği bence henüz netleşmedi. En güncel listeyi Azure dokümantasyonundan takıp etmenizi öneririm.

Kendi fine-tune ettiğim modeli güvenli şekilde getirebilir mıyım?

Evet, bu desteklenen senaryolardan biri. Model ağırlıklarınızı Azure storage’a yükleyip Managed Compute deployment’ı olarak tanımlayabiliyorsunuz. Ağırlıklar tenant’ınızda kalıyor, dışarıya çıkmıyor. Finans, sağlık ve kamu için bu özellikle kritik — tecrübeme göre bu konuda en çok soru gelen nokta da zaten burası oluyor (ciddiyim)

Maliyet açısından kendi AKS cluster’ımdan ucuz mu?

Saatlik karşılaştırma yaparsanız muhtemelen daha pahalı görünüyor. Ama TCO hesabı yaparsanız — yanı DevOps mühendisi maliyeti, runtime lisansları, patch süreci, monitoring araçları, downtime riski hepsini katarsanız — çoğu senaryoda Managed Compute lehine çıkıyor. Bence özellikle 5 kişinin altındaki ekipler için neredeyse her zaman daha mantıklı.

Kaynaklar ve İleri Okuma

Detaylara inmek isteyenler için resmî kaynaklar: (yanlış duymadınız)

• Microsoft Foundry Blog: Announcing Foundry Managed Compute (Orijinal Duyuru)
• Azure AI Foundry Resmî Dokümantasyonu
• Hugging Face Microsoft Partner Sayfası

Sahada Managed Compute denerseniz izlenimlerinizi merak ediyorum açıkçası. Mesela Türkçe modellerle yaptığınız performans karşılaştırmaları varsa paylaşırsanız çok sevinirim. Bir sonraki yazıda muhtemelen Logosoft’ta yapacağımız ilk POC sonuçlarını paylaşırım — hani kapasite ayarlayabilirsem tabi.

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

Microsoft Foundry Nisan 2026: Sahadan Notlar ve Yorum26 May 2026

Python Agent Skills: Üç Yöntem, Tek Provider Senaryosu22 May 2026

Microsoft OpenJDK Nisan 2026 Yaması: Sahadan Notlar5 May 2026

Copilot Business'ta Yeni Dönem: GPT-5.3-Codex Devrede18 May 2026