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 işe 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 tıp arızaların kötü tarafı şu: test ortamınız hep amd64 işe sorun haftalarca saklanabiliyor. Küçük startup’larda bu genelde “önce ship edelim” baskısıyla gözden kaçıyor; enterprise tarafta işe 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 önü 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 sınır 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ış mimarı seçilir. Neden önemli bu? İşte ACE-Step v1 ve flash-attn hikâyesi 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 mimarı 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 yanilıyorum ama) tabanlı Maç üzerinde paketin neden düştüğünü izledim; ikincisinde işe 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 işe organizasyonların bunu standarda çevirmesi gerekiyor. Ha bu arada, bazı projelerde sonuç beklediğim kadar temiz çıkmadı; birkaç edge case hâlâ 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.
Sıkça Sorulan Sorular
Hugging Face Spaces’te Arm64 uyumluluğu neden bazen “build sırasında” patlıyor?
Çoğu zaman modelden değil, Docker içinde yapılan pip install gibi bağımlılık adımlarından kaynaklanıyor. Eğer bir paket sadece linux_x86_64 için wheel URL’siyle sabitlenmişse Arm64’te derleme/indirme uyumsuzluğu yüzünden hata görebilirsiniz. Benim gördüğüm en sık senaryo, “Dockerfile temiz görünüyor ama requirements’te platform kilidi var” durumu.
Arm64’e geçince performans düşer mi, yoksa sadece uyumluluk meselesi mi?
Uyumluluk konusu önce geliyor; çünkü paketler ARM üzerinde hiç yüklenmeyebilir ya da farklı bir derleme yolu izleyebilir. Yükleme sorunu çözülünce performans da ayrı bir optimizasyon alanı oluyor (ör. bazı hızlandırma kütüphaneleri ARM’de aynı şekilde çalışmayabiliyor). Yani önce “çalışıyor mu?” sonra “ne kadar hızlı?” diye iki aşamalı düşünmek en doğrusu.
Dockerfile düzgünse sorun nasıl ölür da Arm’da ortaya çıkar?
Dockerfile’ın kendisi doğru olsa bile, bağımlılıkların bir kısmı mimariye özel olabilir. Örneğin belirli bir wheel adresi x86_64’e sabitlenmişse veya bir paket yalnızca belirli platformlarda yayınlanıyorsa Arm64’te kırılır. Benzer şekilde “testler hep amd64’de geçti” senaryosunda bu problemler haftalarca fark edilmeden kalabiliyor.
MCP zinciri Hugging Face Spaces’te Arm64 uyumluluğunu nasıl hızlandırıyor?
MCP zinciri, tek tek elle bakmak yerine repo/manifest ve bağımlılıkları otomatik analiz edip “nerede kırılma ihtimali var?” sorusunu erken yanitlıyor. Böylece sorun sadece “çalışır mı?” seviyesinde kalmıyor; “hangi paket/URL platforma kilitli?” gibi daha net bir kök neden bulunabiliyor. Pratikte en çok zaman kazandıran tarafı bu.
Arm64 testini yerel makinede mi, bulutta mı yapmak daha mantıklı?
Yerel (ör. Apple Silicon) test hızlı bir ilk sinyal verir, ama bulut mimarisiyle birebir aynı olmayabilir. En sağlıklısı, mümkünse Arm64’ü gerçek hedef ortamınıza yakın bir yerde (Arm instance/CI) doğrulamak. Ben genelde önce yerelde hızlı eleme yapıp, sonra build pipeline’ında hedef mimariyi kesinleştiririm; böylece sürprizleri azaltıyorum.
Kaynaklar ve İleri Okuma
Docker: Multi-platform Images (buildx ile)
Azure VM’ler: ARM tabanlı örnekler (genel bakış)
Hugging Face: Docker ile Spaces (SDK/Docker dokümantasyonu)
GitHub: Model Context Protocol (MCP) — Microsoft reposu
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.
