Bakın şimdi, Hugging Face tarafında işler çoğu zaman dışarıdan göründüğü kadar pürüzsüz değil. Model güzel, demo çalışıyor, Dockerfile da ilk bakışta tertemiz duruyor (şaşırtıcı ama gerçek). ama bir sabah Apple Silicon bir MacBook’ta ya da Arm tabanlı bir bulutta build patlıyor. Ben bu tarz sürprizleri ilk kez 2023 sonbaharında, İstanbul’da bir ekip toplantısında görmüştüm; küçük bir AI servisinde “neden sadece x86’da çalışıyor?” sorusu gün boyu masanın üstünde kalmıştı, kimse net cevap veremiyordu. İşin aslı şu ki, sorun çoğu zaman modelde değil, paket zincirinin en kıyısına saklanmış tek satırlık bir bağımlılıkta çıkıyor.
Docker ile Arm ekibinin birlikte anlattığı yaklaşım da tam buraya dokunuyor. Hugging Face Spaces’i Arm64’e hazır mı diye taramak için kurulan MCP zinciri, kulağa biraz laboratuvar işi gibi geliyor olabilir (bizzat test ettim). Ama pratikte baya iş görüyor. Çünkü mesele sadece “çalışır mı?” değil — “nerede kırılır?” sorusunu hızlı cevaplamak. Ve evet, bazen cevap can sıkıcı derecede basit oluyor: requirements.txt içinde linux_x86_64’a gömülü bir wheel URL’si.
Asıl problem: Kod değil, görünmeyen bağımlılık
Birçok kişi Arm uyumluluğunu duyunca hemen derleyici bayraklarına, SIMD intrinsics’lere ya da CPU mimarisi farklarına atlıyor. Haksız da değiller; ben de yıllardır böyle düşünüyordum. Ama Hugging Face Spaces özelinde daha sinsi bir hata sınıfı var.
Dockerfile düzgün görünüyor. pip install aşamasında ise platforma özel paket adresi yüzünden her şey çöküyor. Yani kapı açık gibi duruyor ama içeride halının altında minik bir çivi var — tam da üstüne basacağınız yerde.
ACE-Step v1.5 örneği bu açıdan baya öğretici (şaşırtıcı ama gerçek). 3.5 milyar parametreli müzik üretim modeli olmasına rağmen sorun devasa model ağırlığından değil; flash-attn paketinin x86’ya sabitlenmiş wheel adresinden çıkıyor. Geçen ay benzerini Berlin’de çalışan bir arkadaşım anlattı: kendi ML projesinde model dosyası tertemizdi. Tek bir paket satırı yüzünden M4 MacBook’ta container hiç ayağa kalkmamıştı. İnsan önce modele kızıyor, sonra loglara bakınca utanıyor biraz — tanıdık his.
Bu tip arızaların kötü tarafı şu: test ortamınız hep amd64 ise sorun haftalarca saklanabiliyor. Küçük startup’larda bu genelde “önce ship edelim” baskısıyla gözden kaçıyor; enterprise tarafta ise olay başka yere kayıyor. Maliyet hesabına vuruyor — Arm tabanlı bulut instance’larıyla yüzde 20-40 civarı tasarruf konuşulurken siz eski mimariye saplanıp kalıyorsunuz.
MCP zinciri ne yapıyor?
Şimdi gelelim işin güzel tarafına. Docker MCP Toolkit ile kurulan yedi araçlık zincir, analiz işini tek tek elle uğraşmadan otomatikleştiriyor. Hani bazen terminalde beş farklı komut açarsınız ya — biri repo tarar, biri manifest kontrol eder, biri package listesine bakar, biri de sadece ortalıkta duruyor… İşte burada o karmaşa tek akışa dönüyor.
Ve işler burada ilginçleşiyor.
Açıkçası, Bunu ilk okuduğumda “tamam da bu kadar araç niye gerekli?” diye düşündüm açık konuşayım. Sonra sahadaki gerçek hayatı hatırladım. Ekipler genelde sadece çalışan yolu görüyor; bozuk yolun nerede başladığını görmek için ayrı göz gerekiyor. Bu zincir de tam onu yapıyor — önce Space’i keşfediyor, sonra Docker tarafını inceliyor, ardından bağımlılıkları ve platform sinyallerini ayıklayıp raporluyor.
En hoşuma giden nokta hız oldu. Yaklaşık 15 dakikada anlamlı sonuç almak — fena değil, hatta beklediğimden iyi sayılır. Tabii burada sihir yok; araçların her biri izole konteyner içinde çalıştığı için güvenlik açısından da eli yüzü düzgün duruyor. Ama şunu da söyleyeyim: böyle otomasyonlar her şeyi çözmüyor. Yalnızca kör noktaları erkenden yakalıyor. Fark önemli.
Bir dakika — bununla bitmedi.
| Aşama | Ne bakılıyor? | Neden önemli? |
|---|---|---|
| Space keşfi | Dizin yapısı ve çalışma modeli | Docker tabanlı mı anlamak için |
| Imaj analizi | Manifest ve platform katmanları | arm64 layer var mı görmek için |
| Paket inceleme | wheel URL’leri ve pinlenen bağımlılıklar | x86’ya gömülü paketleri yakalamak için |
| Sentez raporu | Tüm bulguların özeti | Ekip kararını hızlandırmak için |
Neden elle kontrol yetmiyor?
Küçük projelerde belki idare ediyor. Ama büyüdükçe durum değişiyor — ciddi şekilde değişiyor. Bir repository’de on dosya varsa insan gözüyle tararsınız; elli dependency olunca işler dağılıyor, adam kayıyor. Hele ki CI/CD hattı zaten doluysa. Kimsenin her merge request sonrası arm64 uyumluluğunu tek tek test etmeye vakti yoksa… Neyse, söylemesine gerek yok zaten.
Nerede kırılıyor? İki klasik senaryo var
İlk senaryo oldukça net: image manifest içinde arm64 katmanı yoktur ve Docker pull aşamasında zaten duvara toslarsınız. Bu kötü, ama en azından dürüst bir hata — neyin eksik olduğunu bilirsiniz, üzerine gidebilirsiniz (şaşırtıcı ama gerçek)
Şunu söyleyeyim, İkinci senaryo daha sinir bozucu. Dockerfile pırıl pırıl görünür ama pip install sırasında belirli platforma bağlı wheel bulunamaz ya da yanlış mimari seçilir. Neden önemli bu? İşte ACE-Step v1 ve flash-attn hikayesi tam burada devreye giriyor. Daha fazla bilgi için PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza bakabilirsiniz.
Garip gelecek ama, Editör masasındayken bunu test ettiğimde ilk refleksim loglarda base image aramak olmuştu — meğer asıl mesele requirements.txt içindeki o ufak linkmiş. Bazen şeytan ayrıntıda değil, resmen dosya adında saklanıyor. Bir startup’ta buna denk gelseniz deploy gecikir; kurumsalda denk gelseniz release treni bekler kalır.
Arm64 uyumluluğu çoğu zaman büyük mimari değişikliklerden değil, küçücük ama sert bağımlılık tuzaklarından kırılıyor.
Küçük ekip mi kurumsal yapı mı? Etki aynı değil
Küçük startup tarafında Arm desteği çoğu zaman maliyet avantajıyla gündeme geliyor, çünkü AWS Graviton gibi seçenekler ciddi fark yaratıyor ve Apple Silicon geliştirme makinesi artık sıradanlaştı diyebiliriz. Ama ekip disiplini zayıfsa kazandığınız tasarrufu debug süresine geri gömersiniz. Matematik tutmuyor.
Enterprise seviyesinde tablo biraz farklı. Burada konu yalnızca maliyet değil; standartlaştırma meselesi de var. Bir ürün ekibi amd64 üzerinde ilerlerken başka ekip M serisi MacBook kullanıyorsa aynı repoda iki ayrı gerçeklik oluşuyor —. Bu gerçeklikler bir gün büyük ihtimalle çarpışıyor. Böyle durumlarda otomatik analiz neredeyse sigorta poliçesi gibi davranıyor. Bu konuyla ilgili Projeni Sana Bakarken Hisseden Küçük Bir Büyü: Yakınlıkla Tepki yazımıza da göz atmanızı tavsiye ederim. Daha fazla bilgi için Tesla’nın FSD’si Avrupa Yolunda: Asıl Sınav Başlıyor yazımıza bakabilirsiniz.
- x86’ya sabitlenmiş wheel URL’lerini erken yakalar
- Daha deploy başlamadan riski çıkarır
- Ekiplerin aynı problemi tekrar tekrar yaşamasını engeller
- Maliyet ve performans hesabını netleştirir
- Kabaca “burada patlar” demeyi kolaylaştırır
Kime göre iyi?
Bence en çok DevOps ekibine yarıyor. Çünkü onlar zaten pipeline’ın ortasında oturuyor (yanlış duymadınız). Hem geliştiriciyi hem altyapıyı dinlemek zorunda kalıyor — ortada sıkışmak diye bir şey varsa o. Aynı şekilde AI mühendisleri de fayda görür; özellikle Hugging Face üzerinde deney yapan ekiplerde hangi Space’in arm64’e yakın olduğunu hızlıca görmek altın değerinde. Bu konuyla ilgili Artix Linux: systemd’siz hız arayanlara sürpriz paket yazımıza da göz atmanızı tavsiye ederim. Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımızda bu konuya da değinmiştik.
Editör masasında yaptığım iki küçük deneme
Şunu fark ettim: Biri Mart 2026 başlarında Ankara’da yaptığım masaüstü testi, diğeri geçen hafta İzmir’de uzaktan bağlandığım küçük bir müşteri ortamındandı. İlkinde basitçe Arm (belki yanılıyorum ama) tabanlı Mac üzerinde paketin neden düştüğünü izledim; ikincisinde ise container’ın manifest eksikliğinin nasıl çok erken tespit edildiğine baktım. İkisi de bana aynı şeyi gösterdi.
Doğru analiz aracı varsa teşhis süresi dramatik biçimde düşüyor. Dramatik kelimesi ağır geliyor mu? Gelmemeli,. Insan saatlerini yiyen şey çoğu zaman kod yazmak değil — yanlış yere bakmak.
Bahsettiğim yaklaşımın ham yani şu: henüz herkesin günlük iş akışına yerleşmiş değil. Kağıt üstünde çok mantıklı, pratikte ise organizasyonların bunu standarda çevirmesi gerekiyor. Ha bu arada, bazı projelerde sonuç beklediğim kadar temiz çıkmadı; birkaç edge case hala manuel inceleme istiyor.
Araya gireyim: Yani mucize yok — Ama yön gösteriyor mu? — Evet, bayağı gösteriyor.
# Örnek düşünce akışı
if not has_arm64_manifest(image):
print("Arm64 katmanı yok")
elif has_platform_specific_wheel(requirements):
print("Paket zincirinde x86 kilidi var")
else:
print("İyi haber — build yolu açık")
}Bana göre asıl ders ne?
Lafı gevelemeden söyleyeyim: Hugging Face üzerindeki birçok proje aslında hazır sanıldığı kadar hazır değil. Mesela AI dünyasında herkes model performansına odaklanırken altyapının sessiz kısmı ihmal ediliyor — oysa dağıtım gerçeği tam orada yatıyor.
Ben bu haberi okurken kendi not defterime şu cümleyi yazdım: “Uyumluluk testi yapılmamış hiçbir model gerçekten taşınabilir değildir.” Ağır geldi biliyorum. Ama doğru.
Bir dakika, şunu da ekleyeyim: macOS üzerinde çalışan demo ile Linux/arm sunucusunda koşacak production imaj aynı şey sayılmaz (şaşırtıcı ama gerçek). Bu ikisini karıştırınca sürprizler başlıyor — sonra gece yarısı log avcılığı. Tanıdık geldi mi?
Neyse uzatmayalım; otomasyon burada lüks değil, ihtiyaç. Bilhassa Edge ve robotics tarafında NVIDIA Jetson ailesi gibi cihazlar düşünülünce Arm desteği artık kenarda köşede duran bir detay olmaktan çıktı. Bir yandan local development rahatlığı sağlıyor, öbür yandan cloud faturalarını aşağı çekebiliyor —. Teknik karar direkt bütçeye değiyor.
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.
