Foundry Local 1.1: Yerel AI Artık Mikrofonu da Dinliyor

Bakın şimdi, geçen hafta bir müşteride tuhaf ama tanıdık bir muhabbet döndü. Adamın sahada çalışan 200 teknisyeni var, — ki bu tartışılır — herkes tabletle geziyor, internet de öyle her yerde yok; “Aşkın bey, biz konuşmayı kaydedip transkript çıkarmak istiyoruz ama buluta gönderince GDPR tarafı bize sorun çıkarıyor” dedi. Tam orada Foundry Local 1.1 aklıma düştü — daha yeni duyurulmuştu, ben de açıp on dakika gösterdim, adam resmen yerinde duramadı.

Şimdi asıl yere gelelim. Microsoft, Foundry Local’ın 1.1.0 sürümünü duyurdu ve açık konuşayım, bu sürüm sessiz sakın ama iş görüyor. Büyük bir gösteri yok, blog yazısı da fazla süslü değil. Ama içerik… hani içerik bayağı dolu.

Foundry Local Tam Olarak Nedir, Hatırlatayım

Konuyu bilmeyenler olabilir diye kısa keseyim. Foundry Local, Microsoft’un cihaz üstünde (on-device) çalışan AI çözümü. Bulut yok, network gecikmesi yok, token başına ücret de yok; yanı uygulamaya AI’ı gömüyorsunuz, sonra o iş kullanıcının makinesinde dönüyor — laptop ölür, tablet ölür, masaüstü ölür, çok da fark etmiyor (ki bu çoğu kişinin gözünden kaçıyor)

Windows, macOS, Linux destekli. Peki, güzel tarafı bu.

İlk 1.0 sürümünü Mart ayında bir POC’de denemiştim; o zaman daha çok LLM inference. Basit chat senaryoları vardı, yanı işin başlangıç kısmıydı. Şimdi 1.1 ile tablo değişiyor, çünkü üç ana özellik geliyor: canlı transkripsiyon, text embeddings. Responses API. Bir de WebGPU plugin’i ayrılmış,.NET uyumluluğu genişlemiş, JavaScript paket boyutu da küçülmüş; hani ufak gıbı duran ama pratikte bayağı işe yarayan dokunuşlar bunlar.

Evet.

“Bulutsuz AI” lafını uzun zamandır duyuyoruz ama Foundry Local 1.1, bunun artık marketing sloganı olmaktan çıkıp pratik bir mühendislik aracına dönüştüğünün kanıtı bence.

Canlı Transkripsiyon: En Çok Heyecanlandığım Özellik

Şimdi durup bir saniye düşünelim. Bu işin Türkiye tarafı biraz karışık, hatta yer yer can sıkıcı; hastane var, çağrı merkezî var, hukuk bürosu var, devlet kurumu var, herkes konuşmayı metne çevirmek istiyor ama veri dışarı çıkmasın da diyor. Peki ne yapıyorduk? Ya pahalı on-prem çözümlere abanıyorduk (Nuance, Verbio falan), ya da KVKK tarafında içimize sinmeyen şekilde Azure Speech’e gönderiyorduk; üçüncü yol pek yoktu açıkçası (inanın bana)

Foundry Local 1.1’in canlı transkripsiyon API’si burada baya iş görüyor. Mikrofondan ham PCM ses parçacıkları (chunk) gönderiyorsunuz, sonuçlar da akış hâlinde geliyor; is_final flag’i sayesinde ara çıktı mı, yoksa metin artık oturdu mu hemen ayırabiliyorsunuz (ciddiyim). Ufak gıbı duruyor ama değil. UI tarafında “kullanıcı hâlâ konuşuyor” göstergesi koyarsınız, hatta isterseniz yarım kalan cümleyi de ayrı renkte gösterirsiniz.

Session-Based Pattern Nasıl Çalışıyor

Bak şimdi, mantık çok süslü değil (en azından benim deneyimim böyle). Dört adımda ilerliyor ve işin güzeli burada zaten biraz sade olması: önce streaming-capable bir speech modeli yüklüyorsunuz (şu an nemotron-speech-streaming-en-0.6b öne çıkıyor), sonra audio ayarlarıyla bir live transcription session açıyorsunuz, ardından session’ı başlatıp ses verisini append etmeye koyuluyorsunuz, en son da async stream üzerinden çıkan transcription sonuçlarını topluyorsunuz. Kulağa düz geliyor ama pratikte rahatlatıcı bir akış bu.

Python tarafında örnek bir snippet şöyle görünüyor — ben fazla kurcalamadan, yorumlarla bıraktım ki okunması kolay olsun: (ben de ilk duyduğumda şaşırmıştım)

from foundry_local_sdk import Configuration, FoundryLocalManager
config = Configuration(app_name="my_app")
FoundryLocalManager.initialize(config)
manager = FoundryLocalManager.instance
# Streaming speech modelini al
model = manager.catalog.get_model("nemotron-speech-streaming-en-0.6b")
if not model.is_cached:
model.download(lambda p: print(f" {p:.1f}%"))
# Session oluştur
session = model.create_transcription_session(
sample_rate=16000,
channels=1,
language="en"
)
session.start()
# Mikrofondan PCM chunk'ları append ediyorsunuz
# Sonuçlar async stream üzerinden geliyor

Bu kodu kendi Maç Studio’mda M2 Ultra üzerinde denedim; şey, gecikme beklediğimden düşük çıktı. İlk token için yaklaşık 200-400 ms arası gördüm ve toplantı transkripsiyonu için bu gayet yeterliydi (en azından benim deneyimim böyle). Ama durun, burada küçük bir dipnot var: model 0.6B parametreli olduğu için Whisper-large gıbı davranmasını beklemeyin. İdare ediyor, evet; fakat gürültülü ortamda ya da aksanlı İngilizce’de bazen tökezliyor.

Evet.

Türkçe Desteği Meselesi

Garip gelecek ama, Açık konuşayım, şu an katalogda Türkçe için özellikle ayarlanmış bir streaming modeli yok. nemotron-speech-streaming-en-0.6b net biçimde İngilizce — ki bu tartışılır — odaklı ve bu da Türkiye’deki birçok kurumsal senaryoda eli biraz bağlıyor. Hani güzel tarafı local çalışması ama iş Türkçe’ye gelince tablo değişiyor; Microsoft’tan Türkçe destekli bir model gelene kadar Whisper ailesini ONNX’e çevirip elle deploy etmek gerekebilir ya da hibrit bir mimarı kurarsınız (hassas olmayan içerik bulutta kalır, hassas olan local’de döner). Ben olsam önce kullanım senaryosunu ayırırım, sonra modele bakarım.

Bilmem anlatabiliyor muyum, Bakın, peki neden? Çünkü her işi tek modelle çözmeye çalışınca iş uzuyor.

Text Embeddings: RAG’in Yerel Hâli

Bir de embeddings desteği gelmiş. İyi olmuş. Neden diye sorarsanız, işin aslı kurumsal RAG tarafında asıl dert çoğu zaman model değil, verinin ta kendisi; şirket dokümanını OpenAI’ye, Azure OpenAI’ye ya da Cohere’e yollayıp embedding hesaplatmak zorunda kalıyorsunuz, sonra bir bakıyorsunuz uyum ekibi kapıda bekliyor (haklılar), proje de hop diye frene basıyor (en azından benim deneyimim böyle)

Şahsen, Logosoft’ta bir bankacılık projesinde bunu birebir yaşamıştık. Adamın 80 bin sayfa iç dokümanı vardı. Hepsini bulut embed servisine atacaktık, şey… ilk bakışta basit duruyor ama değil; veri sınıflandırması, regülasyon, onay süreçleri derken iş uzadı da uzadı, hatta proje tam üç ay bekledi. Evet, üç ay.

Ve işler burada ilginçleşiyor.

Şunu söyleyeyim, Foundry Local 1.1 ile embedding’leri artık cihazda hesaplıyorsunuz. Güzel tarafı bu. Vector DB tarafı mı? O kısım size kalmış; LanceDB kullanırsınız, Chroma dersiniz, hatta DuckDB+VSS bile iş görür, yanı seçenek böl (ki bu çoğu kişinin gözünden kaçıyor). Ama kritik nokta şu: vektör artık dışarı çıkmıyor. Semantic search yaparsınız, kümeleme denersiniz, benzerlik eşleştirme çalıştırırsınız… hepsi yerelde dönüyor.

Responses API: Agentic Işler Için Yapısal Köprü

Üçüncü büyük özellik Responses API desteği. Bu, OpenAI’nın yeni standardına uyum sağlama hamlesi gıbı duruyor aslında. Tool calling var, structured output var, multimodal vision-language input var; kısa cevapla, hepsi geliyor.

Bunu biraz açayım.

Burada ben su noktayı özellikle önemsiyorum: Aynı agent kodunu hem bulut hem de yerel modda çalıştırabiliyorsunuz (ki bu çoğu kişinin gözünden kaçıyor). Yanı development sırasında Azure OpenAI’ye giden kodunuz, production’da Foundry Local’a yonlendirilebiliyor (veya tam tersi), bu da hybrid deployment senaryolarında bayağı iş görüyor. Burada, peki neden? Çünkü ortam değişince kodu yeniden yazmakla uğraşmıyorsunuz.

Doğrusu, Bir önceki projemde Foundry Hosted Agents: MAF Ajanını Production’a Almak sürecinde ugrastigim sorunların yarısı, dev/prod ortamlar arasındaki API uyumsuzlugundan çıkmıştı (eh, fena değil). Açık konuşayım, can sıkıcı bir durumdu. Responses API standardı bunu epey rahatlatıyor; hatta ilk bakışta ufak bir detay gıbı geliyor. Sonra fark ediyorsunuz ki asıl dert oradaymış.

Çok konuştum, örnekle göstereyim.

Şahsen, Evet.

Multimodal Vision-Language Input

Bu da hoş bir detay. Sadece metin değil, görsel de gönderebiliyorsunuz modele; bir düşüneyim… hani bazen “bu kadar mi?” dedirten ama sahada kurtaran şeylerden biri bu. Şimdi mobil saha uygulamalarını düşünün: teknisyen tabletten arıza fotoğrafı çekiyor, model lokalde bakıyor ve hangı parça bozuk diye söylüyor (internet yoksa da takılmıyor). Valla bu kısım beni biraz şaşırttı açıkçası. Bu konuyla ilgili GitHub Mobile’da Repo Açma Geldi: Sahadan İlk İzlenimler yazımıza da göz atmanızı tavsiye ederim.

Neyse, çok dağıttım, konuya dönelim. Bu özellik özellikle bağlantı kopuklugu yaşayan ekiplerde işe yarıyor; mesela depo, fabrika ya da uzak saha gıbı yerlerde modelin görüntüyle birlikte çalışması ciddi rahatlık sağlıyor. Tam da o an lazım olan şey bu oluyor.

Diğer Geliştirmeler: Sessiz Ama Önemli

Üç büyük özellik tamam, ama iş burada bitmiyor. Peki bunu neden söylüyorum? Hani manşete çıkmayan şeyler vardır ya, sahada asıl can sıkan ya da rahatlatan onlar ölür; işte bu pakette de birkaç küçük görünen ama etkisi baya hissedilen değişiklik var.

Değişiklik	Neden Önemli
WebGPU plugin ayrıldı	Varsayılan paket boyutu küçüldü, GPU gerekmeyen senaryolarda diske yük yok
JS paketinde koffi yerine N-API addon	Electron uygulamalarında çalışma kararlılığı belirgin arttı, paket %30+ küçük
.NET SDK eski framework desteği	Legacy.NET Framework 4.7+ uygulamalara tümleşik olabiliyor

Bak şimdi, ilk satır kulağa teknik bir temizlik gıbı geliyor ama aslında bundan fazlası var. WebGPU eklentisini ana paketten ayırınca, GPU kullanmayan ekipler gereksiz parçayı indirmiyor; yanı kurulum hafifliyor, disk tarafı rahatlıyor ve insan bir anda “iyi ki bunu böyle yapmışlar” diyor. Daha fazla bilgi için Azure Red Hat OpenShift: AI Üretimine Geçişin Hikayesi yazımıza bakabilirsiniz.

Çok konuştum, örnekle göstereyim.

Bi saniye — İkinci madde de boş değil. JS tarafında koffi yerine N-API addon’a geçilmesi, özellikle Electron dünyasında kafa ağrıtan bazı kararsızlıkları azaltıyor (en azından kağıt üstünde öyle görünüyor), bir de paket boyutunda %30’dan fazla küçülme var; fena değil, hatta baya iş görüyor.

Üçüncü satır işe biraz sessiz ama önemli. Legacy.NET Framework 4.7+ uygulamalara entegrasyon açılması demek, elinizde yıllardır dokunulmamış kurumsal sistemler olsa bile AI tarafına kapıyı aralayabilmek demek.

Bu son madde özellikle Türkiye için kritik. Çünkü buradaki kurumsal müşterilerin bir kısmı hâlâ.NET Framework 4.7-4.8 tabanlı legacy uygulamalarla çalışıyor..NET 8’e geçiş projeleri yıllarca sürüyor; bazen ekip değişiyor, bazen öncelik kayıyor, bazen de işler hiç beklemediğiniz yerden uzuyor. Foundry Local SDK’sının düşük framework’lere uyumlu olması, “biz önce sistemi modernize edelim sonra AI ekleyelim” döngüsünden çıkmak için gerçek bir fırsat veriyor.

Size bir şey söyleyeyim, Evet. Cosmos DB ile Kurumsal Ölçekte GenAI: AVASOFT Nexus Vakası yazımızda bu konuya da değinmiştik. Daha fazla bilgi için Azure Cosmos DB Shell Public Preview: CLI ve MCP Birlikte yazımıza bakabilirsiniz.

Türkiye Perspektifinden Değerlendirme

Şimdi Türkiye tarafına dürüstçe bakalım. Bulut maliyetini TL cinsinden düşününce tablo biraz can sıkıyor; Azure OpenAI’de GPT-4o-mini bile yoğun kullanımda küçük ve orta ölçekli bir SaaS için aylık 5-figür TL seviyesine çıkabiliyor, Foundry Local’da işe bu kalem neredeyse sıfıra iniyor (tek bedel, kullanıcının cihazının CPU/GPU’sunun yediği elektrik) (en azından benim deneyimim böyle). Evet, fark baya net.

Şimdi, bilmem anlatabiliyor muyum, Ha, ama burada bir parantez açmak lazım. Cihazın performansı yetmiyorsa kullanıcı deneyimi de çöküyor. Foundry Local “her senaryoda doğru cevap” değil, hiç değil (bizzat test ettim). Şu soruyu sormak gerekiyor: Ne zaman bulut, ne zaman yerel? Peki neden? Bu konuyla ilgili Azure SQL’de AI_GENERATE_EMBEDDINGS GA Oldu: Saha Notları yazımıza da göz atmanızı tavsiye ederim.

Bir dakika — bununla bitmedi.

• Küçük ekipseniz / startup’sanız: Bulut API’leri ile başlayın. Trafik artınca ve unit economics sıkışınca yerel modele kaydırın. İlk gün her şeyi yerelde çözmeye çalışmak bazen gereksiz yük oluyor. (bu kritik)
• Kurumsal yapıdaysanız: KVKK/GDPR riski yüksek senaryoları (sağlık, finans, hukuk) doğrudan Foundry Local üstüne kurun. Diğer işlerde hibrit yaklaşım çoğu zaman daha dengeli gidiyor; bazen de tam tersi ölür, ortamı görünce karar değişiyor insan.
• Saha uygulaması yapıyorsanız: İnternet bağlantısı zayıf olan kullanıcılar varsa, Foundry Local zaten lüks değil, bildiğin zorunluluk. E sonra? Bağlantı gidince sistemin ayakta kalması gerekiyor. — bunu es geçmeyin

Bir de şu var — Türkiye’deki müşterilerimde defalarca gördüm: CIO’larımız “veri ülke dışına çıkmasın” meselesine Avrupa’dakilerden bile daha hassas bakıyor. Açık konuşayım, cihazda kalan bir AI bu tartışmayı çoğu zaman tek hamlede kapatıyor; çünkü veri zaten dışarı gitmiyor, konu da uzamıyor. Azure Avrupa Yatırımları: Egemen Bulut (ciddiyim). AI Yarışı yazımda değindiğim egemen bulut tartışmasının önemli bir parçası da aslında bu. Tam da öyle.

İlk Denememde Karşılaştığım Sorun

Bir şey dikkatimi çekti: Açık konuşayım, ilk kurulumda M1 Pro üzerinde bir hata aldım. PyAudio tarafı portaudio’yu bulamadı, sonra bir düşüneyim… Homebrew ile brew install portaudio yapınca iş çözüldü. Dokümantasyonda bu küçük detay yok, orası biraz boş kalmış. Windows tarafında işe kurulum daha rahat gidiyor, MSI üzerinden tek tıkla hallediyorsunuz.

Çok konuştum, örnekle göstereyim.

Bir de model indirme süresi var, önü atlamayayım. nemotron-speech-streaming-en-0.6b yaklaşık 1.2 GB geliyor; CDN performansı Türkiye’den fena değil, fakat enterprise proxy arkasındaysanız Microsoft’un model deposunu allow-list’e eklemeyi unutmayın, yoksa kullanıcılarınız “model yüklenmiyor” diye ortalığı ayağa kaldırabiliyor.

Pratik İlk Adımlar

Hemen denemek istiyorsanız, bence en sağlıklısı küçük başlamak. Büyük resmî sonra da görürsünüz.

1. SDK kur: pip install foundry-local-sdk (Python) veya npm i @microsoft/foundry-local (JS)
2. Küçük bir model çek: Embedding ya da transkripsiyon; hangisi senaryonuza uyuyorsa önü alın, çünkü ilk denemede her şeyi aynı anda kurcalamak pek iyi gitmiyor.
3. POC yap: Tek bir use-case seçin. Üç özelliği aynı anda denemeyin, kafa karışıyor; sonra “neyi niye test ettik” diye birbirinize bakıyorsunuz. — ciddi fark yaratıyor
4. Performance ölç: İlk-token gecikmesi, throughput, RAM tüketimi. Hedef cihaz sınıfında ölçün; masaüstünde iyi görünen şey, küçük bir cihazda yüzünü ekşitebiliyor.
5. Hybrid fallback düşünün: Cihaz yetersizse buluta düşen bir mimarı çoğu zaman güvenli liman oluyor. Evet, biraz ekstra iş çıkarıyor ama bazen de başka çare kalmıyor.

Peki neden? Çünkü sahada en çok takılan yer genelde modelin kendisi değil, etrafındaki koşullar oluyor.

Bazen CPU yetmiyor, bazen RAM sıkışıyor, bazen de ağ tarafı beklediğiniz gıbı davranmıyor; işte tam o noktada elinizde bir bulut geri dönüş yolu varsa rahat nefes alıyorsunuz. Bu kadar basit değil tabii, ama ilk günlerde baya iş görüyor (bizzat test ettim)

Araya gireyim: Bu arada agent tarafını daha detaylı görmek isteyenler Microsoft Agent Framework’te Durable Workflow’lar: Saha yazımı da okuyabilir, orada Responses API mantığı biraz daha derine iniyor ve olayın pratik tarafı daha net görünüyor.

Şöyle söyleyeyim, Evet.

Bence Eksik Olan Ne?

Eleştirel tarafa da geleyim. Foundry Local 1.1 fena bir adım değil ama, açık konuşayım, daha tam oturmamış gıbı duruyor. Eksik dediğim yerler de aslında gözümün önünde duruyor:

• Türkçe başta olmak üzere İngilizce dışı dillerde streaming model çok az
• Model yönetimi (versiyonlama, A/B testi) hâlâ ilkel — production senaryoda bunu çoğu zaman elle toparlamak gerekiyor
• Telemetri ve gözlemlenebilirlik sınırlı — kullanıcının cihazında ne döndüğünü görmek zorlaşıyor
• Linux ARM64 desteği hâlâ “preview” damgalı

İnanın, Evet. Burada işin yönü yine de doğru yere gidiyor. Sektörün akışı belli; bulutla yerel arasında öyle körlemesine değil, biraz akıllı bir yük paylaşımı olacak gıbı duruyor, Foundry Local de bu denklemin “yerel” tarafını ciddiye alıyor, Microsoft’un bu alana yüklenmesi de bana kalırsa boş değil.

Önümüzdeki 6-12 ayda ne ölür? Hmm, kesin konuşamam ama 2.0’a yaklaşırken daha derli toplu bir araç görmek şaşırtmaz beni. Şimdilik idare eder, sonra bakalım.

Sıkça Sorulan Sorular

Foundry Local internet olmadan çalışır mı?

İnanın, Evet, modelleri bir kere indirdin mi tamamen offline çalışıyor. Aslında sadece ilk indirme ve katalog güncellemeleri için bağlantı gerekiyor (yanlış duymadınız). Bence bu, saha uygulamaları ve hassas ortamlar için en büyük avantajı.

Foundry Local 1.1 Türkçe transkripsiyon yapıyor mu?

Şu an katalogtaki ana streaming modeli (nemotron-speech-streaming-en-0.6b) İngilizce odaklı. Türkçe için resmî destek henüz gelmiş değil (yanlış duymadınız). Whisper tabanlı modelleri ONNX formatına dönüştürüp manuel entegre etmek mümkün, ama açıkçası performans testlerini atlamayın — sonuçlar değişkenlik gösterebiliyor (ki bu çoğu kişinin gözünden kaçıyor)

Hangı cihazlarda çalışıyor, minimum donanım ne olmalı?

Şunu söyleyeyim, Windows 10/11, macOS (Apple Silicon ve Intel), Linux destekleniyor. Minimum 8 GB RAM önerilir; hani küçük modeller (0.6B-3B) için bu yeterli. Daha büyük modellerde işe 16 GB+ ve dedicated GPU ya da Apple M-serisi şart gıbı. WebGPU plugin’i ayrı geliyor, bu yüzden GPU’suz cihazlarda da CPU ile inference yapılabiliyor (evet, doğru duydunuz)

Bulut tabanlı Azure OpenAI’den geçiş zor mu?

Responses API desteği sayesinde geçiş büyük ölçüde sadece bir konfigürasyon değişikliğine dönüşüyor. Aynı agent kodu hem buluta hem — ki bu tartışılır — yerele yönlendirilebiliyor, mesela A/B testi yapmak çok kolaylaşıyor. Yalnız embedding boyutları farklıysa vector database’i yeniden indekslemeniz gerekebilir. Tecrübeme göre hibrit deployment en güvenli başlangıç noktası.

Token başına maliyet gerçekten sıfır mı?

İnanın, Operasyonel olarak evet. Kullanıcının cihazında çalıştığı için Microsoft’a token ücreti ödemiyorsunuz. Ama tabii indirme bandwidth’i, cihaz amortismanı ve elektrik tüketimini de hesaba katmak lazım. Büyük bir kullanıcı tabanınız varsa bulut maliyetlerine kıyasla %70-90 tasarruf mümkün; küçük ölçekte işe aslında fark marjinal kalıyor.

Kaynaklar ve İleri Okuma

Microsoft DevBlogs — Foundry Local 1.1 Resmî Duyurusu

Azure AI Foundry Local — Resmî Dokümantasyon

Foundry Local GitHub Repository. Örnek Kodlar