AWS EFA Üzerinde Trilyon Parametreli Modelleri Etkinleştirme

Perplexity olarak ürünümüz, API'lerimiz ve araştırma ekiplerimiz için en iyi modelleri kullanıyoruz. Kimi-K2 gibi büyük açık kaynaklı Uzman Karması (Mixture-of-Experts) modelleri, 8x NVIDIA H200 GPU'ya sahip en büyük çıkarım düğümleri bunları verimli bir şekilde barındıramadığı ve çok düğümlü dağıtımlar gerektirdiği için belirli zorluklar ortaya çıkarmaktadır. DeepEP'in performansını aşarak ConnectX-7 üzerinde son teknoloji gecikmeler elde eden bir dizi uzman paralelliği çekirdeği sunuyoruz. Aynı çekirdekler, trilyon parametreli model dağıtımlarını mümkün kılan AWS Elastic Fabric Adapter (EFA) üzerinde de uygulanabilir gecikmeler elde eden ilk çekirdeklerdir.

Çekirdeklerimizi GitHub üzerinden deneyin ve arXiv üzerindeki araştırma makalesinin tamamını okuyun.

Giriş

Uzman Karması (MoE), yüzlerce milyar veya trilyon parametreye ölçeklendirme için standart mimari olarak ortaya çıkmış ve aynı zamanda çıkarım sırasında makul bir gecikme sunmuştur. MoE modelleri, bir transformer'ın yoğun katmanını bir dizi uzmanla ve bir token'ın hangi uzmanla çarpılacağına karar veren küçük bir doğrusal yönlendirme katmanıyla değiştirir. Aynı uzmanla ilişkili token'lar gruplandırılarak, sorun seyreltik hale gelir ve farklı uzmanlar artık birden fazla düğüme yayılmış farklı GPU'larda barındırılabildiğinden kolayca paralelleştirilebilir.

torch.distributed ve NCCL gibi ortak iletişim kütüphaneleri kullanılarak kolayca uygulanabilen Tensör Paralelliği (TP) ve Veri Paralelliği (DP) gibi diğer paralellik biçimlerinden farklı olarak, MoE yönlendirmesi seyrek eşler arası iletişim içerir. Bir dağıtım çekirdeği gelen token kümesini bölmeli ve uzmanları barındıran sıralara dağıtmalıdır; bunun ikili sorunu olan birleştirme çekirdeği ise işlenmiş karşılıklarını almalı ve ağırlıklı ortalamalarını hesaplamalıdır. Bu aktarımlar kolektiflere karşılık gelmez ve düşük gecikme elde etmek için özelleştirilmiş çekirdekler gerektirir.

Perplexity'de hem taşınabilir düğümler arası çekirdekler hem de özel düğüm içi çekirdekler geliştiriyoruz ve MoE iletişimi hakkındaki önceki bir makalede çalışmamızı daha derinlemesine sunduk. Ayrıca başka bir blog yazısında çok düğümlü dağıtımın büyük MoE modelleri için daha düşük gecikme ve daha yüksek aktarım hızı sağlayabileceğini gösterdik.

Bu makalede, NVSHMEM tabanlı önceki çalışmamızın performansını büyük ölçüde artıran yeni düğümler arası çekirdeklerimizin uygulamasını derinlemesine inceliyoruz. ConnectX-7 üzerindeki en son teknoloji sonuçları sergilemenin yanı sıra, çıkarım çalışma zamanımız içinde çekirdeklerin en büyük açık kaynaklı modellere verimli bir şekilde hizmet etmek için kullanılabileceğini de gösteriyoruz.

InfiniBand Üzerinden Çıkarım

Tensör paralelliği ve uzman paralelliği, NVLink yüksek aktarım hızı (900GB/s) ve mikrosaniye mertebesinde gecikme sunduğundan tek bir düğüm içinde etkili bir şekilde ölçeklenebilir. NVIDIA GB200 ve GB300 sistemleri trilyon parametreli modellerin ağırlıklarını ve KV önbelleklerini tutacak yeterli belleğe sahipken, 8 adede kadar H200 GPU'ya sahip AWS p5en örneklerindeki dağıtımlar, model ağırlıkları ile KV önbellekleri arasında bölüştürülmesi gereken 1120GB HBM ile sınırlıdır. Sonuç olarak, belirli modeller InfiniBand üzerinden düğümler arası dağıtımlar gerektirir.

InfiniBand hala olağanüstü hızlı olsa da, yalnızca 400Gbps (50GB/s) aktarım hızı sunar ve MoE yönlendirmesi için on ila yüzlerce mikrosaniye gecikme ekler. Neyse ki, eklenen gecikmeler paylaşılan uzmanlar, mikro toplu işleme ve hesaplama-iletişim örtüşmesi kullanılarak rekabetçi bir maliyetle uygun aktarım hızı sağlamak üzere gizlenebilir. DeepSeek, H800 GPU kümeleri ve NVIDIA ConnectX-7 InfiniBand adaptörleri üzerinde dağıtılan DeepSeek-R1 aracılığıyla bu tekniklerin öncülüğünü yapmıştır.

AWS kümelerinde, özel Elastic Fabric Adapter'ların (EFA) kullanımı nedeniyle durum farklıdır. Bunlar, eğitim iş yüklerinde tipik olarak kullanılan kolektiflerde 400Gbps tepe aktarım hızı sağlasa da, MoE dağıtımı ve birleştirmesi sırasında değiş tokuş edilen mesaj boyutlarında ConnectX-7'nin biraz gerisinde kalırlar. Ek olarak, EFA GPUDirect Async'i desteklemez ve aktarımları başlatmak için GPU'yu NIC'ye bağlayan bir CPU konu vekil iş parçacığı gerektirir. Eklenen karmaşıklığın yanı sıra ek PCIe işlemleri, tüm aktarımlara mikrosaniye mertebesinde ek yük ekler. NVSHMEM gibi çerçeveler, çekirdek yazarlarının cihazdan bağımsız uygulamalar sağlamasına olanak tanır, ancak genel API'ler hem maliyet hem de gecikme açısından dağıtımları etkisiz hale getiren ek yükler getirir.

NVSHMEM Tabanlı pplx-kernels

Önceki çekirdeklerimiz, temel aktarım uygulamasını NVSHMEM aracılığıyla soyutladı. Eşleri senkronize etmek için atomik sayaçlar kullanarak token'ları tek tek aktarmak için nvshmemx_putmem_signal_nbi_warp öğesine güvendiler. Bu, IBGDA özellikli ConnectX-7 NIC'lerde makul performans sunarken, vekil tabanlı ConnectX-7 IBRC uygulaması önemli ölçüde daha yavaştı ve EFA uygulaması bir milisaniyenin altında gecikmeler sağlamakta başarısız oldu.

Modellerimize sunulacak en uygun arayüzü belirlerken çekirdekleri temel donanım için bir test ortamı olarak kullandık. Çekirdekler ile NIC'ler veya konu vekil iş parçacıkları arasındaki sık aktarımların ve etkileşimlerin performansını engellediğini varsaydık. Ek olarak, uygulamamız donanımdan güvenilirlik dışında herhangi bir garantiye dayanmıyordu; bu da senkronizasyon ilkelerinin ek yükünü azaltarak işleri hızlandırabileceğimizi düşündürüyordu.

Bu gözlemlerin ardından, aynı arayüzü sunan EFA tabanlı çekirdeklerimizi tasarladık ve en yüksek performans için cihaz çekirdeği ile ana bilgisayar vekili etkileşimlerini kaputun altında optimize ettik.

EFA Üzerinden MoE All-to-All

Büyüt

Yeni çekirdekler, GPU çekirdeklerinin cihazdaki modelle etkileşime girdiği ve ana bilgisayar CPU'sunda çalışan bir konu vekil iş parçacığının NIC ile etkileşimleri yönettiği hibrit bir CPU-GPU mimarisini takip eder. Yeni çekirdekler, KV önbellek aktarımları için oluşturduğumuz aynı TransferEngine'i yeniden kullanır.

MoE yönlendirmesi, modelden yönlendirilecek token'ları ve token başına uzmanları alan ve bunları ağ üzerinden uzmanları barındıran sıralara gönderen bir dağıtım çekirdeği tarafından gerçekleştirilir. Gruplandırılmış GEMM çekirdekleri token'ları uzman ağırlıklarıyla çarptıktan sonra, birleştirme çekirdeği token'ları kaynak sıralarına aktarır ve modele geri döndürmeden önce ağırlıklı ortalamalarını hesaplar.

Hem dağıtım hem de birleştirme çekirdekleri, örtüşmeyi ve mikro toplu işlemeyi kolaylaştırmak için bir gönderen ve bir alıcı yarıya bölünmüştür. Gönderen, tek bir RDMA yazma işlemi aracılığıyla eşlere yazılabilmeleri için token'ları gönderim arabelleklerinde karıştırır. Gönderen yürütüldükten sonra GPU, ağ üzerinden aktarımlar arka planda beklemedeyken diğer çalışmaları (paylaşılan uzman çarpımı gibi) gerçekleştirebilir. Alıcı çekirdekleri, tüm aktarımlar alınana kadar engellenir. Arka planda, ana bilgisayar tarafında bir çalışan konu vekil iş parçacığı aktarımları yönetir: gönderim arabellekleri doldurulduğunda GPU tarafından sinyal verilir, ardından RDMA yazmalarını gönderir. NIC tamamlandı sinyali verdiğinde, alıcının engellemesini kaldırır ve alıcı token'ları modele geri döndürür.

Çekirdekler ana bilgisayara sıkı bir şekilde bağlıdır ve hem birleştirilmiş bellek hem de GDRCopy aracılığıyla birbirleriyle iletişim kurar. CUDA birleştirilmiş belleği, cihaz belleğinin veya ana bilgisayar belleğinin her ikisinin de adres alanlarına eşlenmesine izin vererek PCIe üzerinden iletişimi şeffaf bir şekilde yönetir.

Birleştirilmiş bellek toplu aktarımlar için uygundur, ancak düşük gecikmeli yoklama GDRCopy aracılığıyla yapılır. GDRCopy, mikrosaniye gecikmeyle GPU belleğinden okumak ve GPU belleğine yazmak için GPUDirect RDMA kullanır.

RDMA'ya ek olarak, bir düğüm içindeki çekirdekler token alışverişi yapmak için NVLink'ten de yararlanır. Bu, trafiğin önemli bir kısmını, EP32 için dörtte birine ve EP64 için sekizde birine kadar offload edebilir ve genel olarak daha düşük gecikmeler elde edebilir.

Gönderme ve Alma Arabellekleri

Dağıtım çekirdeği için gönderme arabelleklerinin tasarımı, ana bilgisayar vekilini içeren uygulanabilir gecikmeler elde etmek için çok önemlidir. Her biri T token gönderen N sıra varsa ve bunlardan her biri E içinden R uzmana yönlendirilmişse, hepsi kendisine yönlendirilirse bir sıra en kötü senaryoda en fazla N * T * max(R, E / N) token alabilir. Dahası, bu minimum sınır, yalnızca gönderenler yazmalarını bitişik olarak yerleştirdiğinde elde edilebilir, çünkü özel alma arabellekleri çok fazla belle tüketir. Gönderenlerin çakışma olmadan yazmalarını ardışık olarak yerleştirebilmesi için yönlendirme bilgilerinin tam bilgisi her sıraya dağıtılmalıdır. Sonuç olarak, dağıtım çekirdeklerimiz önce uzman başına token sayılarını değiş tokuş eder, ardından her biri yazmalarının nereye gittiğini ve her sıradan hangi ofsetle token aldıklarını belirleyebilir.

Yönlendirme bilgilerinin basitçe değiş tokuş edilmesi gereksiz derecede yüksek gecikmelere yol açacaktır, çünkü her sıra kendi yazmalarını göndermeden önce yazmaların gelmesini beklemek zorunda kalacaktır. Bunun yerine, her alıcı sırada az miktarda özel gönderen alanı ayırıyoruz ve token'ların bir kısmını yönlendirme bilgilerinin yazmalarıyla birlikte gönderiyoruz. Bu, dağıtım sürecinin çoğunda tam bant genişliği kullanımını sağlar. Rotalar değiş tokuş edildikten sonra, kalan token'lar uzak eş başına tek bir yazma ile aktarılır. Yönlendirme bilgilerinin ve sabit boyutlu arabelleklerin değiş tokuşu ve bunları dolduran aktarımlar aşağıdaki grafikte gösterilmektedir.

Büyüt

Birleştirme çekirdekleri, yönlendirme bilgileri dağıtım aşamasından zaten mevcut olduğundan çok daha basittir. Token'ları eş başına tek bir yazmada kopyalayabilirler; bundan sonra, token'ların ağırlıklı ortalamasını çıktı tensörlerine hesaplamak için alma arabelleğinden okuma yaparlar.

NVLink için, bir düğüm içindeki gönderme ve alma arabellekleri, komşu sıralardan doğrudan token itebilmeleri veya çekebilmeleri için eşlere eşlenir.

Dağıtım ve Birleştirme

Aşağıdaki şekiller, modelin çekirdekleriyle araya serpiştirilmiş bir dağıtım ve birleştirme yinelemesi göstererek zamanlamayı ve GPU, CPU ile NIC arasındaki etkileşimleri ayrıntılı olarak açıklamaktadır.

İş, dispatch send içinde başlar; kernel yönlendirme bilgilerini toplar ve tek bir blok içinde paylaşılan bellekte atomik birikim yoluyla uzman başına token sayılarını hesaplar. Token sayıları kullanılabilir hale geldiğinde, host belleğine kopyalanır ve proxy'ye, yönlendirme bilgisini diğer tüm peer rank'lere dağıtmaya başlaması için derhal bildirim gönderilir. Paralel olarak, dispatch token sayılarını kümülatif olarak toplamaya devam eder ve token'ları bitişik, uzman başına gönderim tamponlarına paketlemek için gereken ofsetleri belirler. Ofsetler kullanılabilir olduğunda, EFA üzerinden gönderilecek tüm token'lar gönderim tamponlarına paketlenir. Proxy'ye, node'lar arası peer'lerin gönderim tamponlarına yazıları post etmesi için bildirim gönderilir. Aynı node içinde ise kernel'ler token'ları NVLink üzerinden aynı node içindeki özel tamponlara da hemen iter.

Büyüt

Büyüt

Bir sıra tüm eşlerden yönlendirme bilgilerini aldığında, bunları merkezileştirir ve dağıtım ve birleştirme için token'ları tanımlamak için gereken çeşitli ofsetleri hesaplar. Bu çalışma, aktarımlar zaten beklemedeyken CPU üzerinde yapılır, bu nedenle gecikme kritik değildir. Ardından, tüm ofsetler bilindiğinde, özel arabellek boyutunu aşan token'ların geri kalanı için yazmalar gönderilir ve dağıtımın gönderim aşaması tamamlanır.

Alıcı tarafında çekirdek, önce aynı düğümden özel arabelleklerin kapasitesini aşan token'ları NVLink aracılığıyla çeker. Ardından, ana bilgisayar vekili tüm aktarımların tamamlandığını sinyalleyene kadar engellenir. Sinyal alındığında, token'lar alma arabelleklerinden grup GEMM'e iletilen çıktı tensörüne karıştırılır. Arabellekler dağıtım ve birleştirme arasında yeniden kullanıldığından, hem NVLink hem de RDMA bariyerleri, sonraki çekirdeğin bunların üzerine yazmasına izin vermeden önce alıcı arabelleklerinin okunduğundan emin olur.

Birleştirme çekirdekleri kabaca benzer bir modeli takip eder; token'ları karıştırır, vekile sinyal verir ve tamamlanmasını bekler. Bununla birlikte, yazımlarını göndermek için gereken meta veriler hazırdır ve tüm uzak ofsetler bilinmektedir, bu nedenle düğüm içinde aktarılan tüm token'lar NVLink aracılığıyla alıcılara itilir ve düğümler arası token'lar tek bir yazma ile aktarılır. Sonuçları döndürmeden önce çekirdek, alıcı arabelleklerindeki token'ları birleştirerek bunları çıktı tensörlerine yazar.

MoE Yönlendirmesi için TransferEngine

Uygulamamızı prototiplemek için başlangıçta RDMA yazmaları göndermek ve izlemek amacıyla ayrıştırılmış ön dolgu (prefill) ve kod çözme (decode) için oluşturulan Transfer Engine'i yeniden kullandık. Bununla birlikte, her düğümün aynı eşe çok sayıda yazma gönderdiği ayrıştırılmış kod çözmenin aksine, MoE dağıtımı tek bir işlemde tüm eşlere küçük aktarımlar gönderir. Kutudan çıktığı haliyle performans optimal değildi ve uygulamamız ConnectX-7 üzerinde DeepEP'in yaklaşık 20us gerisindeydi. Sonuç olarak, çok sayıda eşle etkileşimleri optimize etmek için TransferEngine'i scatter (dağıt) ve barrier (bariyer) olmak üzere iki işlemi destekleyecek şekilde özelleştirdik.

Hem scatter hem de barrier işlemleri, temel aktarım uygulaması tarafından kullanılan veri yapılarını önceden doldurmak için önceden kaydedilebilen eş grupları ortaya çıkarır (Work Request (WR) şablonlaması). Scatter, aynı kaynak arabelleğindeki farklı dilimleri bir eş grubunun tüm üyelerindeki farklı ofsetlere kopyalar. Barrier, bir anlık mesaj (immediate) aracılığıyla tüm eşlere sinyal verir. Bu işlemleri toplu olarak kuyruğa almak ve işlemek, kritik yolda değerli mikrosaniyeler tasarruf sağlar. Her biri 400Gbps bant genişliği sağlamak için birleşen iki 200Gbps NIC'ye sahip EFA üzerinde, her aktarımın baytlarını bölmek yerine grup eşlerini iki NIC arasında bölüyoruz.

Başlangıçta TransferEngine'i yalnızca libfabric kullanarak EFA üzerinde geliştirmiş olsak da, MoE çekirdekleri TransferEngine'e libibverbs kullanarak ConnectX-7 desteği ekledikten sonra tek bir kod satırını bile değiştirmeden ConnectX-7 üzerinde çalışır. Scalable Reliable Datagram (SRD) tabanlı EFA ile karşılaştırıldığında ConnectX-7, bağlantı kurulumu ve eş yönetimi için ek çalışma gerektirir. Reliable Connection (RC) önyüklemesi yapmak için bir Unreliable Datagram (UD) sıra çifti kullanıyoruz. Her uzak eş için iki sıra çifti oluşturuyoruz: biri iki yönlü SEND/RECV için, diğeri ise bir yönlü WRITE_IMM için, çünkü hem RECV hem de WRITE_IMM sırayla RECV işlemini tüketirken iki işlem farklı arabellek boyutları gerektirir. Ayrıca, ConnectX-7 ile GPU belleği arasındaki PCIe işlem sıralamasını esnetiyoruz. EFA'ya benzer şekilde WR şablonlama optimizasyonunu uyguluyoruz. Ek olarak, aynı eşe birden fazla küçük mesaj gönderirken mesaj hızını iyileştirmek için WR zincirleme (chaining) kullanıyoruz.

GPU tarafındaki çalışma her iki adaptörde de aynı olduğundan, EFA ile ConnectX-7 MoE yönlendirmesi arasındaki boşluğun temel donanımın yetenekleri tarafından belirlendiğini vurgulamak için DeepEP'in performansını aşmak amacıyla temel aktarım uygulamasını sınırlarına kadar zorladık.

Değerlendirme

Dağıtım/Birleştirme Gecikmesi

ConnectX-7 ve EFA adaptörleriyle donatılmış H200 sistemlerinde, 7168 gizli boyuta, blok ölçekli fp8 dağıtımına ve bf16 birleştirmeye sahip standart DeepSeek-V3 ve Kimi-K2 yapılandırmasında dağıtım ve birleştirme gecikmelerini değerlendirdik. Dağıtım için 128 ve birleştirme için 4096 toplu iş boyutunu dikkate alıyoruz. ConnectX-7 üzerinde, hem GPUDirect Async (IBGDA) hem de bir ana bilgisayar vekili (IBRC) kullanarak DeepEP ve önceki NVSHMEM tabanlı pplx-kernels'ımızla karşılaştırma yapıyoruz. EP16, EP32 ve EP64 üzerinde sırasıyla 459us, 582us ve 692us birleştirilmiş gecikmeler elde ediyoruz. 519us, 966us ve 1159us elde eden UCCL-EP gibi genel vekillere güvenen diğer EFA tabanlı çekirdeklerden daha iyi performans gösteriyoruz.

Büyüt

Kod çözme (decode) sırasında, çekirdeklerimiz DeepEP'ten birkaç mikrosaniye daha yavaş olmasına rağmen, birleştirme çekirdeklerimiz önemli ölçüde daha hızlı olduğundan genel olarak daha düşük gecikmeler elde ediyoruz. Bir ana bilgisayar vekili kullanmamıza rağmen, toplu aktarımlarımız nedeniyle tüm IBGDA tabanlı vekilsiz (proxyless) uygulamaların performansını aşıyoruz. Ayrıca, yüksek düzeyde özelleştirilmiş vekilimiz genel NVSHMEM uygulamasından bir kat daha hızlı olduğundan, vekil uygulamasının önemli olduğunu gösteriyoruz. MoE yönlendirmesi tarafından değiştirilen tipik paket boyutuna yakın olan 256KB paketler aktarılırken EFA'nın ConnectX-7'den iki kat daha yavaş olmasına rağmen, iki adaptör arasındaki boşluk genel olarak daha az önemlidir.

Büyüt

Kod çözme için optimize edilmiş çekirdeklerimiz, herhangi bir ek ayar yapmadan ön dolgu toplu iş boyutlarına ölçeklenebilmesine rağmen, performans DeepEP'in gerisinde kalmaktadır. Bunun temel nedeni, DeepEP aktarılan veri miktarını azaltmak için gönderende biriktirme yaparken, bizim token'ları yalnızca birleştirmenin alıcı tarafında biriktirmemizdir. Bununla birlikte, bu optimizasyonun doğruluk açısından sonuçları olabilir. Ek olarak, çekirdekler verileri tek bir yazmada aktardığından, gönderme ve alma arabellekleri için daha fazla bellek kullanıyoruz.

Kimi-K2 / DeepSeek-V3 Aktarım Hızı

Çekirdeklerimizin uygulanabilirliğini kanıtlamak için, Elastic Fabric Adapters (EFA) ve H200 GPU'lar ile donatılmış birden fazla p5en örneği üzerinde DeepSeek-V3 (671B parametre) ve Kimi-K2 (1T parametre) sunan şirket içi çıkarım motorumuzun uçtan uca performansını kıyaslıyoruz. Modeli taslak doğrulama modunda çalıştırıyoruz ve tek bir MTP katmanı kullanarak %80 kabul oranı varsayarak gecikmeyi rapor ediyoruz.

DeepSeek-V3'te, verimli NVLink tabanlı dağıtım ve birleştirme çekirdeklerini çalıştıran EP=8 düğüm içi temel çizgisine (baseline) karşı karşılaştırma yapıyoruz. Düğümler arası dağıtımlar genel olarak, düğümler arası ölçeklendirmenin genel aktarım hızında iyileştirmeler sağladığını gösteren orta büyüklükteki toplu işlerde, tek düğümlü dağıtımın performansına eşittir veya bu performansı aşar.

Kimi-K2'de çekirdekler sunumu mümkün kılar. Boyutu nedeniyle model, bir H200 düğümünde Veri Paralelliği (DP) kullanılarak aynı düğüme sığamaz, bu nedenle modele hizmet etmek için düğümler arası bir dağıtım gereklidir. Model daha az dikkat kafasına sahip olduğundan, DeepSeek-V3'ten daha iyi gecikmeler elde ediyoruz ve modele EFA üzerinde uygun bir gecikmeyle hizmet verebiliyoruz.

Büyüt

Büyüt

Mikro toplu işlemeyi de değerlendirdik, ancak bu yalnızca çok yüksek toplu iş boyutlarında veya birden fazla taslak token kullanıldığında gecikmeleri iyileştirdi. Gruplandırılmış GEMM problemlerini ikiye bölmekten yararlanmak için token toplu iş boyutları yeterince yoğun olmalıdır. Zamanın büyük kısmı hala MoE dağıtımına ve birleştirmesine harcanmaktadır; bu da çekirdeklerdeki herhangi bir ek iyileştirmenin sonuç olarak gecikmeleri iyileştireceğini ve mikro toplu işlemeyi kolaylaştıracağını göstermektedir.

Gelecekteki Çalışmalar

EFA üzerindeki performansını artırmak için AWS mühendisleriyle yakın bir şekilde çalışıyoruz. Kendi tarafımızda, veri düzlemi ek yükünü azaltacak olan libfabric güncellemelerini takip edeceğiz. Ek olarak, kullanıcı alanı ek yüklerini daha da azaltmak ve donanımla doğrudan arayüz oluşturmak için efa-direct ile denemeler yapacağız.

Referanslar

DeepSeek R1 Teknik Raporu

Kimi K2 Teknik Raporu

DeepEP

UCCL-EP

NVIDIA Magnum IO NVSHMEM ve GPUDirect Async Kullanarak HPC Sistemlerinin Ağ Performansını Artırma

Atıf

@online{perplexity2025EnablingTrillionParameterModelsOnAwsEfa,
  author = {{Perplexity} and Nandor Licker and Kevin Hu and Vladimir Zaytsev and Lequn Chen},
  title = {{Enabling trillion-parameter models on AWS EFA}},
  date = {2025-11-04},
  url = {https://www.perplexity.ai/hub/blog/enabling-trillion-parameter-models-on-aws-efa}
}