Büyük yapay zekâ modellerinde sınır çoğu zaman yalnızca işlem gücü değil, bellektir. Model tek bir sistemin belleğine sığmadığında iş yükünün birden fazla node’a dağıtılması gerekir. Bununla birlikte çok node’lu kullanım yalnızca büyük modelleri belleğe sığdırmak için tercih edilmez. Bir model tek bir DGX Spark üzerinde çalışabiliyor olsa bile, uygun paralelleştirme yöntemi ve çalışma ayarlarıyla iki veya dört Spark kullanılarak toplam token üretim kapasitesi ve eş zamanlı istek işleme performansı artırılabilir.

Burada önemli bir ayrım bulunmaktadır: Daha fazla node kullanılması her senaryoda otomatik olarak daha yüksek hız anlamına gelmez. Model mimarisi, kullanılan inference motoru, paralelleştirme yöntemi, istek yapısı ve node’lar arasındaki iletişim maliyeti elde edilen sonucu doğrudan etkiler. Bu nedenle çok node’lu yapının gerçek faydası yalnızca donanım sayısıyla değil, hesaplama ve iletişim katmanlarının birlikte optimize edilmesiyle ortaya çıkar.

Bu çalışmada dört NVIDIA DGX Spark sistemi yüksek hızlı bir ağ üzerinden birbirine bağlanarak tek bir AI cluster hâline getirilmiştir. Amaç, tek bir Spark üzerinde çalıştırılması mümkün olmayan büyük modelleri dağıtık biçimde çalıştırabilmek ve uygun iş yüklerinde daha yüksek token throughput elde edebilmektir.

Kurulumda 10GbE RJ45 bağlantılarından oluşan management ağı ile ConnectX-7 üzerinden çalışan 200GbE compute ağı birbirinden ayrılmıştır. Compute ağı üzerindeki iki ConnectX-7 arayüzü birlikte kullanıldığında Spark’lar arasında toplamda yaklaşık 200 Gbps RDMA bant genişliği elde edilmiş, gecikme ise 1-3 mikrosaniye seviyesinde ölçülmüştür. Ardından GLM-5.2 modeli dört node üzerinde çalıştırılarak altyapı gerçek bir iş yüküyle doğrulanmıştır.

Neden Cluster?

Bir model tek bir GPU’nun veya sistemin belleğine sığmadığında farklı paralelleştirme yöntemlerinden yararlanılabilir.

Tensor parallelism, bir model katmanı içerisindeki büyük tensörleri ve hesaplama işlemlerini birden fazla GPU’ya böler. Her GPU aynı katmanın belirli bir bölümünü işler ve oluşan ara sonuçlar diğer GPU’larla paylaşılır. Bu yöntem, özellikle tek bir katmanın veya model ağırlıklarının bir GPU belleğine sığmadığı durumlarda tercih edilir.

Pipeline parallelism ise modeli katman veya aşama gruplarına ayırır. Modelin ilk katmanları bir GPU veya node üzerinde, sonraki katmanları ise başka bir GPU veya node üzerinde çalıştırılır. Veriler, çoğunlukla mikro batch’ler hâlinde bir üretim hattında ilerler gibi bu aşamalardan sırayla geçirilir. Pipeline parallelism, modelin farklı bölümlerinin ayrı cihazlara dağıtılmasını sağladığı için özellikle çok node’lu kurulumlarda tercih edilebilir.

Tensor ve pipeline parallelism birlikte de kullanılabilir. Hangi yöntemin daha uygun olduğu modelin yapısına, bellek ihtiyacına ve kullanılan inference altyapısına göre belirlenir.

Dağıtık çalışmada GPU’lar sürekli veri alışverişi yaptığı için yalnızca hesaplama gücünün yüksek olması yeterli değildir. Ağ yavaşsa GPU’lar hesaplama yapmak yerine diğer node’lardan gelecek veriyi bekler. Bu nedenle cluster performansı, GPU gücü ile node’lar arası iletişim kapasitesinin birlikte değerlendirilmesini gerektirir.

Kullanılan Mimari

Cluster iki ayrı ağ üzerine kurulmuştur:

• Management Ağı (10GbE): SSH erişimi, sistem yönetimi, yazılım güncellemeleri ve NAS trafiği.
• Compute Ağı (200GbE): RDMA ve dağıtık model iletişimi.

Bu ayrım sayesinde yoğun compute trafiğinin günlük yönetim ve depolama işlemlerini etkilemesi önlenmiştir. Kurulumda kullanılan temel bileşenler ve görevleri aşağıdaki tabloda özetlenmiştir.

CRS812 üzerindeki 400G QSFP-DD portları, pasif breakout kablolar kullanılarak iki ayrı 200G QSFP56 bağlantıya ayrılmıştır. Böylece tek bir fiziksel switch portu üzerinden iki DGX Spark sistemine bağımsız 200G bağlantı sağlanmıştır.

RDMA ve RoCEv2 Neden Gerekli?

Normal TCP/IP iletişiminde veri, işletim sisteminin ağ yığını üzerinden taşınır. Bu süreç CPU müdahalesi, veri kopyalama ve ek gecikme oluşturabilir. Büyük modellerde node’lar arasında sürekli ve yüksek hacimli veri aktarıldığı için bu maliyet daha belirgin hâle gelir.

RDMA (Remote Direct Memory Access), verinin bir sistemin belleğinden diğer sistemin belleğine CPU ve işletim sistemi ağ yığını üzerindeki yük azaltılarak aktarılmasını sağlar. Böylece daha düşük gecikme ve daha yüksek efektif bant genişliği elde edilebilir.

Bu cluster’da RoCEv2 (RDMA over Converged Ethernet v2), yani Ethernet üzerinde RDMA kullanılmıştır. Ancak Ethernet varsayılan olarak kayıplı (lossy) bir ağdır. RoCEv2’nin verimli çalışabilmesi için ağın paket kaybı ve tıkanıklık davranışının ayrıca düzenlenmesi gerekir.

Compute ağında bu nedenle aşağıdaki ayarlar uygulanmıştır:

• MTU 9000: Büyük verilerin daha az paketle taşınması için.
• DSCP 26 → TC3: RoCE trafiğinin ayrı bir trafik sınıfında
  yönetilmesi için.
• PFC (Priority Flow Control): Tıkanıklık sırasında paket
  düşürmek yerine ilgili trafik sınıfının geçici olarak durdurulması için.
• ECN (Explicit Congestion Notification) ve CNP (Congestion Notification Packet):
  Tıkanıklığın erken algılanması ve gönderim hızının kontrollü biçimde
  azaltılması için.

PFC yalnızca RDMA trafiğini taşıyan TC3 sınıfında etkinleştirilmiştir. Böylece SSH ve normal TCP trafiği lossless kuyruğa alınmamış, yalnızca gecikmeye duyarlı RDMA iletişimi bu mekanizmadan yararlanmıştır.

Neden MikroTik CRS812?

Yüksek hızlı AI ağlarında NVIDIA Spectrum switch’ler güçlü ve yerleşik bir seçenektir. Bu çalışmada ise dört node’lu, kompakt ve maliyet duyarlı bir laboratuvar cluster’ı hedeflenmiştir.

CRS812; 400G QSFP-DD portları, breakout desteği, donanım tabanlı QoS, PFC, ECN ve DCBX gibi ihtiyaç duyulan özellikleri sunmaktadır. Doğru yapılandırmayla her bağlantıda yaklaşık 100–111 Gbps RDMA performansına ulaşılmıştır.

Bu sonuç, CRS812’nin her ölçekte veri merkezi switch’lerinin yerine geçeceği anlamına gelmez. Ancak dört DGX Spark’tan oluşan bu yapı için maliyet ve performans arasında dengeli bir çözüm sağlamaktadır.

Düğümlerin Hazırlanması

Kurulumdan önce dört Spark aynı yazılım ve firmware seviyesine getirilmiştir. Bu adım sanıldığından daha önemlidir. Yüksek hızlı ağ kartlarında eski firmware sürümleri, ağ doğru yapılandırılmış olsa bile beklenen performansın elde edilmesini engelleyebilmektedir.

İşletim sistemi paketleri ve firmware’ler güncellenmiş, ardından DGX Dashboard üzerinden ek güncelleme olup olmadığı kontrol edilmiştir. Docker tarafında ise tüm node’ların aynı depolama altyapısını kullanması sağlanmış ve containerd snapshotter üzerinden OverlayFS kullanımının etkin olduğu doğrulanmıştır.

Management ağı için her Spark’ın 10GbE portu CRS312’ye bağlanmış ve statik IP adresleri atanmıştır. SSH erişimi, sistem güncellemeleri, sparkrun yönetimi ve NAS bağlantıları bu ağ üzerinden sağlanmıştır.

sparkrun Neyi Kolaylaştırıyor?

Dört sistemi tek tek yönetmek mümkün olsa da aynı komutların her node’da çalıştırılması, SSH anahtarlarının düzenlenmesi ve dağıtık iş yüklerinin elle başlatılması süreci hataya açık hâle getirebilir.

sparkrun, DGX Spark node’ları arasında SSH mesh oluşturan ve çok node’lu model çalışmalarını kolaylaştıran bir araç setidir. Bu kurulumda sparkrun aşağıdaki işlemler için kullanılmıştır:

• Node’lar arasında şifresiz SSH erişimi oluşturmak
• ConnectX-7 ağ arayüzlerini hazırlamak
• Kullanıcı ve Docker yetkilerini düzenlemek
• Modeli tek bir recipe dosyasıyla başlatmak

sparkrun birçok adımı otomatikleştirse de DCB ayarlarının Spark tarafındaki karşılığı ayrıca uygulanmıştır. ConnectX-7 arayüzlerinde DSCP 26 trafiği priority 3’e eşlenmiş ve bu sınıf için PFC etkinleştirilmiştir. Ayarların yeniden başlatma sonrasında kaybolmaması için bir systemd servisi oluşturularak yapılandırma kalıcı hâle getirilmiştir.

Ağın Doğrulanması

Model çalıştırılmadan önce ağ katman katman test edilmiştir.

İlk olarak compute IP adresleri arasında ping testi yapılmıştır. Ardından ping -M do -s 8972 komutuyla MTU 9000 yapılandırmasının uçtan uca doğru çalıştığı doğrulanmıştır.

TCP katmanında iperf3 ile yaklaşık 100–120 Gbps throughput ölçülmüştür. RDMA testlerinde ise her ConnectX-7 subnet’inde aşağıdaki değerlere ulaşılmıştır:

• RDMA Write: 100–111 Gbps
• RDMA Read: 95–110 Gbps

İki subnet birlikte değerlendirildiğinde Spark’lar arasında toplam yaklaşık 200 Gbps RDMA bant genişliği elde edilmiştir. ib_write_lat testinde gecikme yaklaşık 1-3 mikrosaniye seviyesinde ölçülmüştür.

Bu değerler yalnızca ağ benchmark’ı açısından önemli değildir. Tensor veya pipeline parallelism kullanıldığında node’lar arasındaki veri aktarım süresi, toplam model performansını doğrudan etkiler.

GLM-5.2 ile Gerçek İş Yükü

Ağ testlerinin ardından GLM-5.2 modeli, dört Spark üzerinde tensor parallelism = 4 olacak şekilde çalıştırılmıştır.

Model, sparkrun üzerinden tek bir recipe dosyası ile başlatılmıştır:

sparkrun run glm52-qt-dcp4-4spark.yaml

Bu recipe dosyasında modelin yanı sıra container imajı, bellek sınırları, KV cache ayarları, quantization biçimi ve vLLM çalışma parametreleri tanımlanmıştır. Böylece uzun komutların tekrar yazılması yerine aynı çalışma ortamının kolayca yeniden oluşturulması sağlanmıştır.

Application startup complete. mesajının görülmesiyle dört node’un aynı model üzerinde birlikte çalıştığı doğrulanmıştır.

Model servisi ayağa kaldırıldıktan sonra yapılan benchmark testinde, eşzamanlılık 1 (concurrency = 1) altında GLM-5.2-Int4 modeliyle 20,16 token/s üretim hızına ulaşılmıştır. Bu sonuç, dağıtık yapının gerçek bir inference isteği altında uçtan uca başarıyla çalışabildiğini göstermektedir.

Ortak Depolama

Model dosyalarının her node’a ayrı ayrı kopyalanmaması için ASUSTOR NAS ortak depolama olarak kullanılmıştır. NAS’ın iki 10GbE portu LACP ile CRS312’ye bağlanmış ve NFS paylaşımı Spark node’larına bağlanmıştır.

LACP’nin tek bir dosya aktarımını otomatik olarak 20 Gbps seviyesine çıkarmadığı dikkate alınmalıdır. Sağlanan avantaj, birden fazla bağlantı ve veri akışının iki fiziksel port arasında dengeli şekilde dağıtılmasıyla ortaya çıkar.

NAS üzerinde model ağırlıkları, veri setleri (dataset’ler) ve benchmark çıktıları ortak bir depolama alanında tutulmuştur. Böylece tüm node’lar aynı dosya kümesine erişebilmiş ve veri yönetimi önemli ölçüde kolaylaştırılmıştır.

Sonuç

Bu çalışma sonunda dört bağımsız DGX Spark sistemi, ortak ağ ve depolama altyapısı üzerinde birlikte çalışan bütünleşik bir AI cluster’a dönüştürülmüştür. Management ve compute trafiğinin ayrılması, RoCEv2/RDMA yapılandırmasının uçtan uca uygulanması, sparkrun ile node yönetiminin merkezileştirilmesi ve ortak NFS alanının kullanılması, yapının kararlı ve yönetilebilir biçimde çalışmasını sağlamıştır.

Ortaya çıkan yapı, tek bir Spark’ın bellek sınırlarını aşan modellerin birden fazla node üzerinde çalıştırılmasını mümkün hâle getirmektedir. Bunun yanında model tek bir Spark üzerinde çalışabiliyor olsa bile, uygun paralelleştirme ve servis ayarlarıyla birden fazla Spark kullanılarak daha yüksek toplam token üretim kapasitesine ve daha fazla eş zamanlı isteği karşılayabilecek bir altyapıya ulaşılabilmektedir.

Yaklaşık 200 Gbps RDMA bant genişliği, 1–3 mikrosaniye gecikme ve GLM-5.2 modelinin dört node üzerinde başarıyla çalıştırılması, kurulan mimarinin yalnızca teorik olarak değil, gerçek bir büyük model iş yükü altında da işlevsel olduğunu göstermektedir. Bu açıdan çalışma, DGX Spark sistemlerinin doğru ağ, depolama ve cluster yönetimiyle bir araya getirildiğinde kompakt ancak güçlü bir dağıtık AI platformuna dönüşebildiğini ortaya koymaktadır.

Kurulumda kullanılan tüm komutlar, MikroTik switch ayarları, DCB yapılandırması, ağ testleri, NAS kurulumu ve sorun giderme adımları DGX Spark 4-Node AI Cluster Kurulum Rehberi içinde ayrıntılı olarak yer almaktadır.

Benzer bir DGX Spark cluster altyapısına sahip olmak için sistem siparişinizi openzeka.com üzerinden verebilirsiniz. Cluster ağ yapılandırması, node kurulumları ve temel devreye alma hizmeti sistem temini kapsamında ücretsiz olarak sunulmaktadır.