İlk karar GPU sayısı değil, iş yüküdür
Kurumsal AI altyapısını planlarken önce modelin nasıl kullanılacağını belirlemek gerekir. Eğitim, mevcut modeli fine-tuning ile uyarlama ve üretimde inference sunma farklı kapasite ve operasyon ihtiyaçları doğurur. Kullanıcıların eş zamanlı istekleri, modelin bellek ihtiyacı, bağlam uzunluğu ve kabul edilebilir yanıt süresi birlikte değerlendirilmelidir. Bir katalogda “AI için güçlü altyapı” ifadesi bu kararların yerini tutmaz. İş birimi hangi işlemin hızlanacağını, platform ekibi ise bunun hangi ölçümle doğrulanacağını açıklayabilmelidir. Cisco’nun ayrı training ve inference tasarım kılavuzları bu ayrımı destekler; aynı referans her iş yüküne değiştirilmeden uygulanmaz.
Frontend ve backend fabric’in görevlerini ayırın
Cisco AI POD referanslarında frontend ağ; uygulama erişimi, depolama, yönetim ve ilgili kontrol trafiği için kullanılır. Backend ağ ise dağıtık GPU iş yüklerinin düğümler arası iletişim ihtiyacına odaklanır. Ayrı fabric’ler farklı trafik gereksinimlerini görünür kılar; her inference uygulamasının mutlaka aynı backend tasarımına ihtiyaç duyduğu sonucu çıkarılmamalıdır. Model tek GPU’ya sığıyorsa veya serving düzeni farklıysa ilgili mimari karar tekrar değerlendirilir. Şemada iki fabric’in spine ve leaf gruplarını ayrı izleyebilirsiniz. Ağ hızları kaynak örneğinin bağlantı etiketleridir; kurumun uygulaması için doğrulanmış performans değeri değildir.
Cisco AI POD: frontend ve backend fabric
Düğümleri seçerek görevlerini inceleyin; yakınlaştırma veya tam ekranla bağlantıları takip edin.
- Backend fabric (E-W)
- Frontend / storage (N-S)
- ND bağlantıları / ND connections
Düğüme tıklayarak rolünü inceleyin. Şemayı sürükleyebilir veya düğmelerle yakınlaştırabilirsiniz.
Ağustos 2026 inference referansının iki ayrı fabric’i korunur. İlk ve N compute düğümü, management cluster ve storage modülleri kaynakta gösterildiği kapsamda aktarılır; ara düğümler üç noktadır. Bu, tüm AI POD seçeneklerinin ortak donanım reçetesi değildir. Backend bağlantıları compute grubu düzeyindedir; ilk ve N ikonlarından ayrı NIC/port eşlemesi türetilmez.
Compute ve GPU seçimini model davranışıyla eşleştirin
Cisco UCS ve NVIDIA GPU bileşenleri, seçilen referans mimarinin compute temelini oluşturur. Uygun platform; model büyüklüğü, precision veya quantization seçimi, paralelleştirme ihtiyacı ve beklenen kullanım profili üzerinden değerlendirilmelidir. Bir benchmark sonucunu farklı model veya veriyle aynı şekilde elde edeceğinizi varsaymayın. Pilot ölçümünde yalnız ortalama hız değil, gecikme dağılımı ve kapasite dolduğunda görülen davranış da kaydedilmelidir. Şemadaki ilk ve N compute düğümü arada başka üyeler bulunabileceğini gösterir; çizim bir satın alma adedi önermez. Donanım kararı, desteklenen bileşenler ve gerçek iş yükü ölçümleri birlikte görülerek alınır.
Depolama, veri erişimi ve model yaşam döngüsü
AI platformunda depolama yalnız model dosyasının tutulduğu bir alan değildir. Veri kümeleri, model sürümleri, checkpoint’ler ve uygulamanın kullandığı kurumsal bağlam farklı erişim gereksinimlerine sahip olabilir. RAG kullanımında erişilen belgelerin güncelliği ve izinleri de uygulama davranışını etkiler. Veri sahibini, erişim yetkisini, saklama ihtiyacını ve model güncelleme yöntemini tasarımın başında netleştirin. FlashStack kaynak topolojisi belirli storage bileşenlerini gösterir; başka bir depolama seçeneğinin aynı performans veya destek özelliklerine sahip olduğu varsayılmamalıdır. Kabul çalışmasında modelin yüklenmesi, veri erişimi ve güncellenen sürüme kontrollü geçiş ayrı ayrı gözlenmelidir.
Yazılım katmanı ve üretim serving düzeni
GPU kapasitesi kadar önemli bir diğer konu, modeli hangi yazılım katmanının çalıştıracağıdır. Cisco inference referansı OpenShift ve model-serving bileşenlerini platform tasarımının parçası olarak ele alır; NVIDIA AI Enterprise ekosistemi ilgili destek ve yazılım seçeneklerini sağlar. Kurumun Kubernetes, OpenShift veya MLOps tercihi; sürüm uyumluluğu, işletim sorumluluğu ve güncelleme planıyla birlikte değerlendirilmelidir. Modelin API olarak açılması uygulama kimliği, kota ve erişim yönetimi kararlarını da gerektirir. Referans çizim yazılımın bütün API yollarını göstermediği için bu yolları fiziksel kablo olarak eklemiyoruz. Uygulama ve altyapı ekiplerinin aynı kullanım senaryosu üzerinde çalışması gerekir.
Cisco AI Networking: iş yüküne uygun Ethernet fabric
Cisco AI Networking kapsamındaki ağ kararı, GPU iş yükünün nasıl dağıldığıyla birlikte verilmelidir. Eğitim ve dağıtık inference için düğümler arası iletişim örüntüsü, frontend erişiminden farklı olabilir. Bir spine–leaf veya rail-optimized seçeneğin uygunluğu kullanılan sunucu, NIC, GPU ve yazılım düzeniyle değerlendirilir. Katalogdaki yüksek performans ve düşük gecikme hedefleri, pilotta gerçek iş yüküyle ölçülmesi gereken gereksinimlerdir. Cisco training kılavuzu farklı backend seçeneklerini açıklar; burada gösterilen FlashStack inference topolojisi ise belirli bir referanstır. İki kaynağın donanım ve bağlantı etiketleri birbiri yerine kullanılmamalı, seçilen platformun destek koşullarıyla eşleştirilmelidir.
Secure AI Factory ile koruma katmanlarını ilişkilendirin
Cisco Secure AI Factory with NVIDIA yaklaşımı compute, ağ, güvenlik ve ilgili AI yazılımını birlikte ele alır. Ancak AI POD altyapısı ile AI uygulamasının güvenliği aynı karar değildir. Ağ segmentasyonu, iş yükü koruması ve modele gönderilen girdilerin denetlenmesi farklı kapsamlar taşır. AI Defense ve Hypershield gibi çözümlerin hangi risk için kullanılacağını belirlemek, bütün ürünleri bir çizime yerleştirmekten daha önemlidir. Seçilen donanım, yazılım, lisans ve dağıtım seçeneği entegrasyonun gerçek kapsamını belirler. Bu nedenle güvenlik gereksinimleri kapasite çalışmasından sonra eklenen bir not değil, uygulama ve veri akışlarıyla birlikte tasarlanan bir bölüm olmalıdır.
Intersight, Nexus Dashboard ve operasyon sahipliği
Sunucu, ağ ve uygulama ekiplerinin farklı görünürlük alanları vardır. Intersight UCS yönetimine, Nexus Dashboard ağ fabric’inin yönetim ve operasyonuna odaklanır. Kaynak topolojide ayrıca Cisco Cloud Control bulunur; bu bileşen uygulama paketlerinin geçmesi gereken yeni bir data-plane hop’u değildir. İşletim modelinde hangi alarmı kimin değerlendireceği, kapasite sorununda hangi ölçümlerin birlikte okunacağı ve sürüm değişikliklerini kimin onaylayacağı belirlenmelidir. Başarılı bir platform yalnız çalışır durumda olan cluster’dan ibaret değildir. Model ekleme, güncelleme, hatalı sürümü geri alma ve kapasite artışı süreçleri ekipler arasında anlaşılır bir sorumluluk dağılımıyla yürütülmelidir.
Pilotun çıktısını üretim kararına dönüştürün
PoC sonunda yalnız bir demo yanıtı değil, iş yüküne ait ölçümler ve sınırlar elde edilmelidir. Test veri kümesi, model sürümü, eş zamanlılık ve ölçüm süresi kayıt altına alınırsa sonuç daha sonra karşılaştırılabilir. Ağ veya düğüm arızası, model güncellemesi ve servis yeniden başlatması gibi kurum için önemli senaryolar kabul planına eklenmelidir. Trustnet’in katalogda tanımladığı analiz, tasarım, uygulama ve destek yaklaşımı bu kararların bir proje kapsamında ele alınmasına dayanır. Uygun referans mimari, pilot sonuçları ve operasyon sahipliği birlikte hazır olduğunda üretim kararı somutlaşır. Şema bu kararları anlatır; tek başına kapasite veya kesintisizlik taahhüdü oluşturmaz.



