OpenShift AI ile Yapay Zeka Platformu Yönetmek

Yapay zeka ve veri bilimi projelerinde başarı sadece model geliştirmekle değil, bu modellerin güvenli, ölçeklenebilir ve sürdürülebilir bir platform üzerinde çalıştırılmasıyla mümkündür.

Geleneksel yapılarda yapay zeka ve model eğitimi için kullanıcılar genellikle kendi bilgisayarlarında gerekli araçları kurar, kütüphaneleri yönetir ve çalışma ortamlarını manuel olarak hazırlar. Günümüzde ise bu yaklaşım yerini merkezi paltformlara bırakıyor. Kullanıcıların yalnızca kendilerine sağlanan url adresine erişmesi yeterli oluyor; Hazır workbench (notebook) ortamları sayesinde yapay zeka uygulamaları geliştirilebilir, modeller eğitilebilir ve projelere daha hızlı başlangıç yapılabilir.

OpenShift AI, OpenDataHub temelli yapısıyla veri bilimi ve yapay zeka iş yüklerini OpenShift üzerinde yönetilebilir hale getirir.

1. Openshift AI Nedir

OpenShift AI, veri bilimi ekiplerine hazır ve yönetilebilir çalışma ortamları sağlayan OpenShift tabanlı bir platformdur. Kullanıcılar JupyterLab veya benzeri araçlara kendi bilgisayarlarına kurulum yapmadan, kendilerine verilen URL üzerinden erişebilir.

Platform mühendisleri ise, workbench, notebook image, storage, data connection ve kaynak limitlerini merkezi olarak yöneterek ekiplerin güvenli ve standart bir ortamda çalışmasını sağlar

2. Neden Kubernetes/OpenShift Üzerinde AI Platformu Gerekir?

Normal geliştirme süreçlerinde her kullanıcı kendi bilgisayarında ortam kurduğu için zamanla farklı sürümler, eksik kütüphaneler ve uyumsuz çalışma ortamları oluşabilir. Bu da ekip içinde “bende çalışıyor, sende çalışmıyor” problemini artırır.

Bu noktada Kubernetes ve OpenShift, AI ortamlarını düzenli ve yönetilebilir hale getirir

• Çalışma ortamları merkezi olarak hazırlanır.
• Kullanıcılar aynı standart notebook image’ları ile çalışır.
• CPU, bellek ve depolama kullanımı kontrol altında tutulur.
• Kullanıcı erişimleri ve proje yetkileri merkezi olarak yönetilir.
• Veri bilimi ekipleri ortam kurmak yerine doğrudan çalışmalarına odaklanır.

Böylece platform ekibi altyapıyı daha kontrollü yönetirken, kullanıcılar da daha hızlı ve tutarlı bir çalışma ortamına erişir.

3. Data Science Project Kavramı

OpenShift AI’da Data Science Project, veri bilimi ekiplerinin çalışmalarını düzenli şekilde yönetmesi için kullanılan proje alanıdır. Kullanıcılar workbench, storage, data connection, pipeline ve model servislerini bu proje altında oluşturur.

Data Science Project aslında bir OpenShift project/namespace yapısına karşılık gelir.

Bu sayede her ekip veya çalışma alanı birbirinden ayrılabilir, yetkiler proje bazında verilebilir ve kaynaklar daha kontrollü yönetilebilir.

“Create data science project” butonuna tıklayınca kendine ait, izole bir çalışma ortamı oluşmaktadır

Burada oluşturulan Data Science Project için OpenShift tarafında otomatik olarak bir namespace oluşur.

Bu sayede ileride kota, rol ataması ve kaynak takibi gibi işlemleri daha net yönetmeyi sağlar.

4. Workbench ve Notebook Image Kullanımı

OpenShift AI’de kullanıcıların çalıştığı ortam workbench olarak adlandırılır.

Bunu, tarayıcı üzerinden açılan hazır bir geliştirme bilgisayarı gibi düşünebiliriz. Kullanıcı bu ortamda kod yazar, notebook çalıştırır ve model denemeleri yapar.

create workbench seçilerek notebook oluşturulabilir

Bu workbench’in içinde hangi araçların olacağını notebook image belirler. Örneğin bir image içinde Python, JupyterLab ve bazı temel kütüphaneler bulunabilir. Kullanıcı workbench oluştururken bu image’ı seçer ve ortam hazır şekilde açılır.

Create workbench yaptığımızda ise notebook ekranı oluşur

1

2

3

5. Custom Notebook Image Neden Kullanılır?

Varsayılan notebook image’ları her proje için yeterli olmayabilir. Bazı ekiplerin özel Python kütüphanelerine, belirli sürümlere veya kurum içi araçlara ihtiyacı olabilir.

Custom notebook image bu ihtiyacı karşılamak için hazırlanır. Gerekli paketler ve araçlar image içine önceden eklenir. Kullanıcı workbench oluştururken bu image’ı seçer ve ortam hazır şekilde açılır.

Örneğin bir veri bilimi ekibi sürekli pandas, scikit-learn ve şirket içi bir Python paketini kullanıyorsa, bu paketleri her workbench açıldığında tek tek kurmak verimli değildir. Bunun yerine bu paketlerin yüklü olduğu custom notebook image hazırlanır.

6. Storage, PVC ve Data Connection Yapısı

OpenShift AI’de kullanıcıların workbench üzerinde oluşturduğu dosyaların kalıcı olması gerekir. Çünkü workbench kapatıldığında veya yeniden başlatıldığında yapılan çalışmaların kaybolmaması beklenir. Bu kalıcılık OpenShift tarafında PVC ile sağlanır.

Data connection ise projelerin dış veri kaynaklarıyla bağlantı kurmasını kolaylaştırır. Örneğin bir ekip verilerini S3 üzerinde tutuyorsa, erişim için gerekli bilgiler OpenShift AI üzerinde data connection olarak tanımlanabilir. Böylece kullanıcılar veriye her seferinde manuel bağlantı bilgisi girmek zorunda kalmadan erişebilir.

bu alana storage bilgileri girilir

7. Model Deployment: InferenceService ve Model Server

Model geliştirme tamamlandıktan sonra sıradaki ihtiyaç, bu modeli kullanıcıların veya uygulamaların erişebileceği şekilde çalıştırmaktır.

Model server, modelin çalışacağı servis ortamını sağlar. InferenceService ise hangi modelin, hangi konumdan alınacağını ve nasıl servis edileceğini tanımlar. Örneğin model dosyası S3 üzerinde duruyorsa, OpenShift AI bu bilgiyi kullanarak modeli uygun model server üzerinde çalıştırabilir.

Böylece model yalnızca bir dosya olarak kalmaz; uygulamaların istek gönderebildiği yönetilebilir bir servis haline gelir.

8. Kaynak Yönetimi: Request, Limit ve Idle Culling

OpenShift AI üzerinde açılan her workbench ve model server CPU ile bellek tüketir. Bu nedenle platform ekibinin kaynak kullanımını sınırlamak için hazır kaynak profilleri belirlemesi gerekir.

Dashboard’da gördüğümüz Small, Medium veya Large gibi seçenekler arka planda tanımlı kaynak değerlerine karşılık gelir. Örneğin Small bir workbench için 1 CPU request, 2 CPU limit ve 8Gi bellek tanımlanabilir. Kullanıcı ekranda yalnızca “Small” seçer, bu sayede açılan workbench için kaynak sınırlandırılamsı yapılır.

Request, pod’un çalışması için ayrılan minimum kaynağı; limit ise kullanabileceği maksimum kaynağı ifade eder.

Bu yapı sayesinde kullanıcıya yeterli çalışma ortamı sağlanırken, cluster kaynaklarının kontrolsüz tüketilmesi önlenir.

OpenShift AI’de sunulan Small, Medium gibi kaynak profilleri sabit olmak zorunda değildir. Platform ekipleri bu değerleri OpenShift üzerinden güncelleyebilir, kurum ihtiyaçlarına göre yeni boyutlar tanımlayıp kullanıcıların seçimine sunabilir. Bunun için OpenShift arayüzünde API Explorer sayfasına gidilir. Buradan odhdashboardconfig yazılır ve seçimi “All Projects” olarak değiştirilir. Daha sonra odhdashboardconfig instance yaml açılıp düzetme sağlanır

Bu değerleri OpenShift arayüzü üzerinden düzenleyebileceğiniz gibi, CLI üzerinden aşağıdaki komutla da güncelleyebilirsiniz:

oc edit odhdashboardconfig odh-dashboard-config -n redhat-ods-applications

yazarak CLI üzerinden kaynak değerlerini güncelleyebilirsiniz

spec:
  notebookSizes:
    - name: Small
      resources:
        limits:
          cpu: '2'
          memory: 8Gi
        requests:
          cpu: '1'
          memory: 8Gi
    - name: Medium
      resources:
        limits:
          cpu: '4'
          memory: 16Gi
        requests:
          cpu: '2'
          memory: 8Gi

yeni bir boyut eklemek istersen:

spec:
  notebookSizes:
    - name: Custom-Large
      resources:
        limits:
          cpu: '8'
          memory: 32Gi
        requests:
          cpu: '4'
          memory: 16Gi

Kaydedip çıktıktan sonra dashboard tarafında yeni boyut görünür.

Kullanıcıların açık unuttuğu workbench’ler de kaynak tüketmeye devam edebilir. Idle culling özelliği, belirli süre kullanılmayan workbench’leri otomatik olarak durdurarak bu kaynakların boşa harcanmasını engeller.

9. Kurumsal Kullanımda Avantajlar

OpenShift AI’nin en güçlü tarafı, yapay zeka çalışmalarını kişisel bilgisayarlara bağlı olmaktan çıkarıp kurumsal, merkezi ve yönetilebilir bir platforma taşımasıdır.

Kullanıcılar ortam kurulumlarıyla zaman kaybetmeden çalışmaya başlarken, platform ekipleri de bu ortamların nasıl sağlandığını, hangi kaynakları kullandığını ve kimlerin erişebildiğini kontrol altında tutabilir.

Bu yaklaşım özellikle büyük ekiplerde ciddi fark yaratır. Her kullanıcının farklı araçlar, farklı kütüphane sürümleri ve farklı donanımlar üzerinde çalışması yerine, herkes aynı standart ortamlar üzerinden ilerler. Böylece hem uyumluluk problemleri azalır hem de projelerin başlatılması daha hızlı hale gelir.

GPU gerektiren iş yüklerinde de önemli bir avantaj sağlar. Güçlü donanımı her kullanıcıya ayrı ayrı sağlamak yerine, GPU’lu worker node’lar platforma dahil edilir ve ihtiyaç duyan ekipler bu kaynakları kontrollü şekilde kullanabilir. Böylece pahalı GPU kaynakları merkezi olarak yönetilir, paylaşılır ve daha verimli kullanılır.

Gelecek yazılarda görüşmek üzere….