Docker ile yapay zeka modeli dağıtımı: üretime çıkma rehberi

Son güncelleme: 17 Ağustos 2026

Yapay zeka projelerinin çoğu teknik yetersizlikten değil, üretime hiç çıkamadığından ölür. Model laboratuvarda çalışır, yönetim sunumunda ilgi görür, sonra kurumun kendi sunucusuna taşınacağı gün "bizim makinede çalışıyordu" cümlesine takılır. Aradaki mesafe akademik değil operasyoneldir: kütüphane sürümleri, sürücü uyumsuzlukları, işletim sistemi farkları, güncellemeyi kimin yapacağı, hata çıkarsa nasıl geri dönüleceği. Bütçe onayı almış bir projenin altı ay sonra hâlâ pilot ekranında durmasının sebebi genelde budur. Bu rehber, bir yapay zeka modelini demo aşamasından kurumsal üretim ortamına taşırken izlemeniz gereken adımları, karar noktalarını ve regüle sektörlerde ortaya çıkan ek yükümlülükleri anlatıyor. Docker burada sihirli bir çözüm değil, belirsizliği azaltan ve tekrarlanabilirliği garanti altına alan bir paketleme disiplinidir.

Yapay zeka projeleri neden pilotta kalıp üretime geçemiyor?

Pilot ile üretim arasında dört tipik tıkanma noktası vardır ve hiçbiri tek başına model kalitesiyle açıklanmaz:

• Ortam farkı. Veri bilimcinin bilgisayarındaki kütüphane sürümleriyle kurumun sunucusundaki sürümler aynı değildir. Aynı model, aynı girdiye farklı çıktı verebilir.
• Sahiplik boşluğu. Sistemi kimin ayakta tutacağı, güncellemeyi kimin yapacağı ve arıza anında kimin arandığı yazılı değilse proje bilgi işlem tarafından kabul edilmez.
• Denetim boşluğu. "Bu kararı hangi model sürümü, hangi girdiyle verdi" sorusuna cevap veremeyen bir sistem iç denetimden geçmez.
• Veri politikası. Hassas veriyle çalışan kurumlarda verinin kurum dışına çıkması tek başına projeyi durdurur.

Docker birinci maddeyi doğrudan çözer, dördüncüsünde belirleyici kolaylık sağlar, ikinci ve üçüncüde ise etrafına kurduğunuz disiplinin taşıyıcısı olur. Kendi projelerimizde şu sırayı izliyoruz: önce paketleme disiplinini kurmak, sonra sahiplik ve denetim sorularını yazılı hâle getirmek. Tersi sırada ilerleyen projeler kurulum gününde tıkanıyor.

Docker nedir ve bir yapay zeka modeline ne katar?

Docker, bir uygulamayı çalışması için gereken her şeyle birlikte tek bir taşınabilir pakete koyan konteynerleştirme teknolojisidir. Bu paketin içinde Python sürümü, kütüphaneler, sistem paketleri ve yapılandırma dosyaları bulunur. Sanal makineden farkı, kendi işletim sistemi çekirdeğini taşımamasıdır: konteyner ana makinenin çekirdeğini paylaşır, yalnızca kendi kullanıcı alanı dosya sistemini getirir. Bu yüzden çok daha hafiftir.

İki kavramı ayırmak gerekir. İmaj, değişmeyen kalıptır; içinde ne varsa odur, çalıştırılmadan önce disk üzerinde durur. Konteyner, o kalıptan üretilmiş çalışan örnektir; aynı imajdan aynı anda onlarca konteyner üretilebilir. Aynı imajı geliştirme ortamında, test ortamında ve müşterinin sunucusunda çalıştırdığınızda üçünde de aynı bağımlılık kümesi devrededir. "Bende çalışıyordu" cümlesi teknik olarak anlamsızlaşır.

Bu ayrım yapay zeka tarafında sıradan bir yazılıma göre daha kritiktir. PyTorch ve TensorFlow gibi derin öğrenme çatıları sürüm değişikliklerine duyarlıdır. OpenCV'nin farklı bir sürümü, görüntü ön işlemede farklı yeniden boyutlandırma veya renk dönüşümü sonucu üretebilir; model hiç değişmese bile modele giden veri değişir. Modelin ağırlıkları kadar, modele giden verinin nasıl hazırlandığı da sabitlenmek zorundadır.

Docker aynı çıktıyı garanti eder mi?

Bağımlılık kümesi açısından evet, sayısal sonuç açısından her zaman değil. Bu ayrım sık atlanır ve regüle sektörlerde sorun çıkarır. Docker; Python sürümünü, kütüphaneleri ve sistem paketlerini sabitler. Ancak GPU üzerinde çalışan bazı işlemler paralel toplama sırasını donanıma ve seçilen çekirdek algoritmasına göre değiştirebilir. Sonuç, kayan noktanın son basamaklarında farklılaşabilir.

Pratikte bunun üç sonucu vardır. Birincisi, bit düzeyinde tekrarlanabilirlik isteniyorsa çatı düzeyinde deterministik algoritma ayarlarını açmanız ve donanım modelini de sabitlemeniz gerekir. İkincisi, bu ayarlar performans maliyeti getirir; gerçek zamanlı işlerde her zaman kabul edilebilir değildir. Üçüncüsü, çoğu kurumsal senaryoda aranan şey bit düzeyi eşitlik değil, karar düzeyinde tutarlılıktır: aynı girdi aynı sınıfa, aynı eşiğin aynı tarafına düşmelidir. Hangisini hedeflediğinizi proje başında yazılı olarak belirleyin.

Bir yapay zeka modelini konteynerleştirirken hangi adımlar zorunlu?

1. Bağımlılıkları sürüm numarasıyla sabitleyin

Sürüm belirtmeden yazılmış bir bağımlılık listesi, altı ay sonra bambaşka bir ortam üretir. Her paketin sürümü sabitlenmeli, dolaylı bağımlılıklar da dahil olmak üzere tam bir kilit dosyası tutulmalıdır. Taban imaj için de aynısı geçerlidir: değişebilen bir etiketle değil, içerik özetiyle referans verin. Etiketler zaman içinde farklı içeriği işaret edebilir; içerik özeti değişmez.

Derleme bağlamını da küçük tutun. Depo kökündeki veri klasörleri, not defterleri ve deneme çıktıları imaja sızarsa hem boyut şişer hem de istemeden veri taşımış olursunuz.

2. Model ağırlıklarını imajın içine gömmeyin

Model dosyaları çoğu zaman gigabaytlarcadır. İmaja gömdüğünüzde her küçük kod değişikliği dev bir imajın yeniden üretilmesi anlamına gelir ve hangi imajın hangi ağırlıkla geldiğini takip etmek zorlaşır. Ağırlıkları ayrı bir model deposunda tutup konteynere bağlayın, sürümü dışarıdan bir değişkenle verin.

Bunun bir istisnası vardır: internet erişimi olmayan, hava boşluklu on-premise kurulumlar. Orada imajın kendi kendine yeter olması operasyonel olarak daha güvenli olabilir. Hangi yolu seçerseniz seçin, imaj sürümü ile model ağırlığı sürümü arasındaki eşleşme kayıt altında olmalıdır; aksi hâlde denetim izi baştan kırıktır.

3. Modelin önüne bir servis katmanı koyun

Model doğrudan çağrılmaz, önüne bir arayüz konur. FastAPI, Python tarafında bu iş için yaygın kullanılan hızlı bir çatıdır; girdi doğrulamasını şema tanımları üzerinden kendi üzerine alır, böylece hatalı biçimdeki istek modele hiç ulaşmaz. Bu katman aynı zamanda kimlik doğrulama, kayıt tutma, istek sınırlama ve zaman aşımı gibi üretim gereksinimlerinin yeridir.

Servis katmanı ayrıca modeli değiştirilebilir kılar. Perakende ve moda için geliştirdiğimiz sanal deneme sistemi OutfitLab'de, 275 ürünlük gerçek bir katalogla çalışan görsel üretim hattı ile mobil uygulama arasındaki tek temas noktası bu katmandır; arkadaki model sürümü değiştiğinde uygulama tarafında hiçbir şey değişmez.

4. Çok aşamalı derleme kullanın

Çok aşamalı derlemede derleyiciler, geliştirme başlıkları ve derleme araçları ilk aşamada kalır; üretim aşamasına yalnızca derlenmiş çıktı kopyalanır. İmaj küçülür, indirme süresi kısalır ve saldırı yüzeyi daralır. Üretim imajında kabuk erişimi ve paket yöneticisi bırakmayın, süreci kök kullanıcı olmayan bir kimlikle çalıştırın.

5. Canlılık ve hazır olma kontrollerini ayırın

İki ayrı uç nokta tanımlayın: biri sürecin ayakta olduğunu, diğeri modelin belleğe yüklenip istek almaya hazır olduğunu bildirsin. Bu ikisini birbirine karıştıran sistemler model yüklenmeden trafik alır ve ilk isteklerde hata döner.

Buradaki teknik ayrıntı önemlidir: Docker'ın kendi sağlık kontrolü talimatı tek bir kontrol tanımlar. Canlılık ve hazır olma ayrımı asıl anlamını orkestrasyon katmanında kazanır. Yapay zeka servislerinde ayrıca bir başlangıç kontrolü de gerekir; konteynerin kendisi saniyeler içinde başlasa da gigabaytlarca ağırlığın belleğe yüklenmesi dakikalar sürebilir. Başlangıç kontrolü olmayan kurulumlarda orkestrasyon, henüz yükleniyor olan sağlıklı bir konteyneri arızalı sanıp yeniden başlatır ve sistem sonsuz döngüye girer.

GPU gerektiren modeller konteyner içinde nasıl çalıştırılır?

Derin öğrenme modelleri paralel hesaplama için GPU, yani grafik işlem birimi kullanır. Konteyner ana makinenin çekirdeğini paylaştığından GPU erişimi ayrı bir katman ister. Görev dağılımı şöyledir:

• Ana makinede: GPU sürücüsü ve konteyner araç seti (NVIDIA donanımında NVIDIA Container Toolkit) kurulu olur.
• Konteyner içinde: CUDA çalışma zamanı ve derin öğrenme kütüphaneleri taşınır.
• Çalıştırma anında: Konteyner bir GPU parametresiyle (--gpus all gibi) başlatılır ve sürücü arayüzü konteynere aktarılır.

Ana makineye tam CUDA Toolkit kurmak gerekmez; sürücü yeterlidir. Toolkit'in konteyner içinde taşınması zaten bu mimarinin amacıdır.

Buradaki en sık hata sürüm uyumsuzluğudur ve kuralı net söylemek gerekir: ana makinedeki sürücü sürümü, konteynerdeki CUDA çalışma zamanının istediği asgari sürücü sürümüne eşit veya ondan yeni olmalıdır. Ters yön çalışmaz. Aynı ana sürüm ailesi içinde küçük sürüm uyumluluğu bu kısıtı gevşetir; veri merkezi sınıfı kartlarda ise ileri uyumluluk paketleriyle eski sürücü üzerinde daha yeni bir CUDA çalıştırmak mümkündür. Taban imajı hedef sunucunun sürücü sürümünü bilmeden seçmek, kurulum gününde patlayacak bir sorunu peşin satın almaktır. Teklif aşamasında sorulacak ilk teknik soru budur.

Bellek tarafında iki ayrı sınır olduğunu unutmayın. Konteynerin sistem belleği sınırı ile GPU belleği aynı şey değildir: Docker'ın bellek parametresi ana makine RAM'ini sınırlar, kartın üzerindeki belleği sınırlamaz. GPU belleğini bölmek için ya donanım seviyesinde bölümleme ve süreç servisi mekanizmalarını kullanmanız ya da çatı düzeyinde ayırma sınırı koymanız gerekir. Bu ayar özellikle önemlidir, çünkü bazı çatılar varsayılan olarak kartın tüm belleğini baştan rezerve eder; aynı sunucudaki ikinci servis hiç başlayamaz.

Gerçek zamanlı işlerde bu ayarlar doğrudan sonuca yansır. Savunma sanayii bağlantılı bir projede, insansız hava aracı görüntüsünde sınıftan bağımsız uçan cisim tespiti ve takibi üzerine çalıştık; hedef 50-150 FPS, yani saniyede 50 ile 150 kare işleyerek gerçek zamanlı çalışmaktı. Bu bantta kalmak yalnızca model optimizasyonuyla değil, konteyner içi GPU erişiminin ve bellek yönetiminin doğru kurulmasıyla mümkün olur. Yanlış yapılandırılmış tek bir bellek parametresi, modeli hiç değiştirmeden kare hızını yarıya düşürebilir.

Model sürümlemesi ve denetim izi nasıl kurulur?

Üretimde "latest" etiketi kullanılmaz. Bu etiket değiştirilebilirdir; aynı isim zaman içinde farklı imaj içeriklerini işaret eder ve altı ay sonra "o gün hangi model çalışıyordu" sorusunu cevapsız bırakır. Her yayın için anlamlı ve bir daha kullanılmayacak bir sürüm etiketi verin, kaydı ise imajın değişmez içerik özetiyle tutun. Etiket taşınabilir, içerik özeti taşınamaz; denetimde geçerli olan ikincisidir.

Denetlenebilir bir çıkarım kaydı en az şu alanları taşımalıdır:

Girdi özeti maddesi özellikle önemlidir. Hassas veriyle çalışan kurumlarda ham girdiyi denetim kaydına yazmak, çözdüğünüzden daha büyük bir sorun yaratır. Girdinin kriptografik özetini saklamak, "bu karar bu girdiye verildi" iddiasını ispatlamak için yeterlidir. Bu yaklaşım, ISO 42001 yapay zeka yönetim sistemi kapsamında beklenen izlenebilirlik ile veri minimizasyonu ilkesini aynı anda karşılar; kendi süreçlerimizi bu belge kapsamında yürütüyor ve aynı yapıyı danışmanlık verdiğimiz kurumlarda da kuruyoruz.

Üretime çıktıktan sonra neyi izlemek gerekir?

Dağıtım bitiş değil başlangıçtır. İzlenmesi gereken metrikler üç katmandadır ve bunları karıştıran ekipler sorunu geç fark eder:

• Altyapı katmanı: Konteyner ayakta mı, GPU belleği doluyor mu, sistem belleği sınırına dayanıp süreç sonlandırılıyor mu.
• Servis katmanı: Yanıt süresi dağılımı (ortalama değil, uç değerler), hata oranı, kuyrukta bekleyen istek sayısı, kare hızı.
• Model katmanı: Güven skoru dağılımının kayması, sınıf dağılımının değişmesi, girdi verisinin eğitim verisinden uzaklaşması.

Üçüncü katman en çok ihmal edilenidir. Altyapı yeşil, servis yeşil görünürken model sessizce kötüleşebilir; çünkü sahadaki veri zamanla değişir. Görüntü işleme projelerimizde %80 üzeri stabilite hedefiyle çalışıyoruz ve bu hedefin korunması ancak model katmanının sürekli izlenmesiyle mümkün oluyor. Geri dönüş planınız da hazır olmalıdır: önceki imaj içerik özeti elinizde duruyorsa geri alma birkaç dakikalık bir iştir, durmuyorsa gecelik bir krize dönüşür.

On-premise mi bulut mu?

Bu kararı belirleyen şey model değil veridir. Aşağıdaki tablo, kurumsal projelerde karşılaştığımız tipik kırılma noktalarını özetliyor:

Docker'ın buradaki asıl değeri, kararı geri dönülemez olmaktan çıkarmasıdır. Aynı imaj her üç senaryoda da çalıştığı için mimariyi baştan tek bir ortama çivilemek zorunda kalmazsınız. Biz ağırlıklı olarak on-premise kuruyor, bulutu opsiyon olarak bırakıyoruz.

Regüle sektörlerde hangi ek yükümlülükler doğar?

Sağlık, finans ve kamu tarafında paketleme disiplininin üzerine üç yükümlülük daha biner.

Veri yerelliği ve minimizasyon. Kişisel verinin nerede işlendiği, nereye aktarıldığı ve ne kadar süre saklandığı yazılı olmalıdır. Konteyner mimarisi burada işinizi kolaylaştırır: dış ağa çıkışı olmayan bir konteyner, verinin kurum dışına gitmediğini teknik olarak gösterilebilir kılar.

Kayıt tutma ve teknik dokümantasyon. Yüksek riskli kabul edilen yapay zeka sistemlerinde kararların izlenebilir olması ve sistemin nasıl çalıştığının belgelenmesi beklenir. Yukarıdaki denetim izi tablosu bu beklentinin teknik karşılığıdır.

İnsan gözetimi. Modelin çıktısı nihai karar değil, karar desteğidir. Servis katmanı, güven skoru belirli bir eşiğin altına düştüğünde vakayı otomatik olarak insan incelemesine yönlendirebilmelidir. Sağlık alanındaki projelerimizde %85 üzerinde doğrulukla çalışıyoruz; buna rağmen mimariyi her zaman insan gözetimi kalacak şekilde kuruyoruz, çünkü kalan pay klinik ortamda anlamlıdır.

Üretime çıkmadan önce kontrol listesi

• Tüm bağımlılıklar ve taban imaj içerik özetiyle sabitlendi mi?
• Model ağırlığı sürümü ile imaj sürümü arasındaki eşleşme kayıtlı mı?
• Servis katmanında kimlik doğrulama, istek sınırlama ve zaman aşımı var mı?
• Canlılık, hazır olma ve başlangıç kontrolleri ayrı ayrı tanımlı mı?
• Hedef sunucunun sürücü sürümü ile konteynerin CUDA sürümü doğrulandı mı?
• Sistem belleği ve GPU belleği sınırları ayrı ayrı konuldu mu?
• Konteyner kök kullanıcı olmayan bir kimlikle mi çalışıyor?
• Denetim kaydı ham hassas veri yerine girdi özeti mi tutuyor?
• Bir önceki sürüme geri dönüş adımları yazılı ve denenmiş mi?
• Arıza anında kimin arandığı ve müdahale süresi sözleşmede tanımlı mı?

En sık yapılan beş hata

1. Sürüm sabitlemeden yayına çıkmak. İlk kurulumda çalışır, ikinci kurulumda çalışmaz. Sorun kurulum gününde değil, aylar sonra bir güncellemede ortaya çıkar.
2. Sürücü ve CUDA uyumunu kurulum gününe bırakmak. Bu bilgi teklif aşamasında toplanır; sonrasında maliyeti taban imajı ve tüm test döngüsünü yeniden kurmaktır.
3. Tek bir sağlık kontrolüyle yetinmek. Model yüklenmeden trafik alan servis, ilk isteklerde hata döner ve ilk izlenimi bozar.
4. Denetim izini sonraya bırakmak. Sonradan eklenen kayıt, geçmişe dönük kanıt üretmez; iç denetim tam da geçmişi sorar.
5. Geri dönüş planını hiç denememek. Yazılı ama denenmemiş bir geri alma prosedürü, kriz anında yoktur.

Sıkça sorulan sorular

Docker, yapay zeka modeli dağıtımı için zorunlu mu?

Zorunlu değil, ama kurumsal üretimde fiilî standart hâline gelmiştir. Docker'ın çözdüğü asıl sorun ortam farkıdır: modelin çalıştığı Python sürümü, kütüphaneler ve sistem paketleri tek bir değişmez imajda sabitlenir. Tek bir makinede duran küçük bir prototip için gereksiz olabilir; birden fazla ortama taşınacak her model için gereklidir.

Model ağırlıkları Docker imajının içine gömülmeli mi?

Genel kural hayır: ağırlıklar ayrı bir model deposunda tutulur, konteynere bağlanır ve sürümü dışarıdan verilir. Böylece küçük bir kod değişikliği gigabaytlarca imajın yeniden üretilmesini gerektirmez. İstisna, internet erişimi olmayan hava boşluklu on-premise kurulumlardır; orada imajın kendi kendine yeter olması operasyonel olarak daha güvenlidir. Hangi yolu seçerseniz seçin, imaj sürümü ile model sürümü arasındaki eşleşme kayıt altında olmalıdır.

Docker konteyneri içinde GPU nasıl kullanılır?

Ana makinede GPU sürücüsü ve konteyner araç seti kurulu olur; konteyner ise CUDA çalışma zamanını kendi içinde taşır. Konteyner bir GPU parametresiyle başlatıldığında sürücü arayüzü konteynere aktarılır. Ana makineye ayrıca tam CUDA Toolkit kurmak gerekmez. Kritik koşul, ana makinedeki sürücü sürümünün konteynerdeki CUDA sürümünün istediği asgari sürücü sürümüne eşit veya ondan yeni olmasıdır.

Aynı Docker imajı her ortamda birebir aynı çıktıyı üretir mi?

Bağımlılık kümesi açısından evet, sayısal sonuç açısından her zaman değil. Docker kütüphane sürümlerini ve sistem paketlerini sabitler; ancak GPU üzerinde çalışan bazı işlemler paralel toplama sırasını donanıma göre değiştirebilir ve sonuç son basamaklarda farklılaşabilir. Bit düzeyinde tekrarlanabilirlik isteniyorsa deterministik algoritma ayarları açılmalı ve donanım modeli de sabitlenmelidir. Çoğu kurumsal senaryoda aranan şey bit düzeyi eşitlik değil, karar düzeyinde tutarlılıktır.

Üretimde neden "latest" etiketi kullanılmaz?

"latest" değiştirilebilir bir etikettir; aynı isim zaman içinde farklı imaj içeriklerini işaret eder. Altı ay sonra bir kararın hangi model sürümüyle verildiği sorulduğunda etiket cevap veremez. Bunun yerine her yayına anlamlı ve bir daha kullanılmayacak bir sürüm etiketi verilir, kayıt ise imajın değişmez içerik özeti üzerinden tutulur.

Yapay zeka modelini on-premise mi bulutta mı çalıştırmalı?

Belirleyici olan model değil veridir. Kişisel veri, sağlık verisi veya finansal işlem kaydı barındıran sistemlerde verinin kurum ağı dışına çıkması çoğu zaman tek başına projeyi durdurur; bu durumda on-premise kurulum tercih edilir. Değişken ve yüksek yük altındaki, veri hassasiyeti düşük iş yüklerinde bulut maliyet ve esneklik avantajı sağlar. Docker her iki senaryoda da aynı imajı taşıdığı için kararı geri dönülemez olmaktan çıkarır.

Konteynerleştirilmiş bir modelin bakımını kim üstlenmeli?

Sahiplik yazılı değilse sistem üretime alınmaz. Asgari olarak üç rol tanımlanmalıdır: imajı üreten ve sürümleyen taraf, sunucuyu ayakta tutan taraf, model performansını izleyen taraf. Bu üçü aynı ekip olabilir, ancak arıza anında kimin arandığı ve müdahale süresinin ne olduğu sözleşmede yer almalıdır.

Ücretsiz danışmanlık için bize ulaşın

← Tüm yazılar