Herkese açık bir GitHub deposu, bir donanım yığınının gerçekte olduğundan daha erişilebilir görünmesine neden olabilir. DeepSeek’in Ascend çalışmaları gerçek ve işe yarar; ancak tek komutla kurulup NVIDIA kümesinin yerini alacak bir çözüm değil. Mevcut sürüm, Ascend 950 kernel’lerine odaklanıyor ve CANN, torch_npu ile uyumlu donanım gerektiriyor.
Kısa cevap: Kullanıma hazır Ascend kümesi değil, açık bileşenler
DeepSeek, Huawei NPU’larını hedefleyen ve DeepGEMM API yapısını koruyan MIT lisanslı kernel kütüphanesi DeepGEMM-Ascend başta olmak üzere Ascend’e özel kodlar yayımladı. Deponun ilk sürümü Ascend 950 cihazlarını destekliyor; ortam için CANN 9.20, torch_npu, Python 3.10+, C++20 araç zinciri ve TileLang gereksinimlerini belgeliyor.
Uyumlu Ascend erişimine sahip bir ekip bu kodu inceleyebilir, derleyebilir, benchmark çalıştırabilir ve seçili kernel’leri kendi sistemine entegre edebilir. Ancak bu, baştan sona tamamlanmış bir eğitim ya da üretim altyapısı değil.
Ascend donanımlı laboratuvarlar, bulut operatörleri ve kurumsal ekipler kodu bugün değerlendirebilir. Yalnızca NVIDIA kullanan bir geliştirici ise kodu inceleyebilir veya DeepSeek’in NVIDIA odaklı projelerinden yararlanabilir; ancak bu Ascend kernel’lerini H100 ya da tüketici sınıfı bir GeForce kartında çalıştıramaz.
DeepSeek aslında ne yayımladı?
DeepSeek’in open-infra-index deposu altyapı çalışmalarını katmanlara ayırıyor. İlk indeks büyük ölçüde NVIDIA/Hopper odaklı: FlashMLA, Hopper GPU’lar için bir MLA decoding kernel’i; DeepEP, uzman paralelliği için bir iletişim kütüphanesi; DeepGEMM, FP8 GEMM kütüphanesi; DualPipe ve EPLB dağıtık paralelliği; 3FS/Smallpond ise veri erişimini ele alıyor.
Ascend’e özel sürüm, tüm katmanları bir anda değiştirmek yerine belirli hesaplama yollarının hedef donanımını değiştiriyor. Kamuya açık en net örnek, şu alanları kapsayan DeepGEMM-Ascend:
- BF16, FP8 ve FP4 GEMM;
- MQA logits;
- gruplanmış GEMM ve MegaMoE yolları;
- mHC prenorm kernel’i ve
- Ascend’e özel JIT derleme ile yerleşim dönüşümleri.
Proje, DeepGEMM ile API uyumluluğu sunduğunu belirtiyor. Bu uyumluluk model mühendisleri için değerli; ancak CUDA binary’lerini taşınabilir hâle getirmiyor. Ascend’in matris yerleşimleri, ölçekleme faktörlerinin paketlenmesi, derleyicisi, çalışma zamanı ve cihaz yönetimi API’leri hâlâ belirleyici.
Bileşen haritası: NVIDIA odaklı bir yığının Ascend karşılıkları
Aşağıdaki tablo, birebir aynı uygulamaların değil, aynı sistem rollerinin eşlemesini yapıyor. Bir karşılık benzer işi üstlenir; ancak farklı bir API, iletişim altyapısı veya kernel yaklaşımı kullanabilir.
| Katman | Doğrulanmış Ascend kodu veya bağımlılığı | NVIDIA odaklı karşılık | Sınır |
|---|---|---|---|
| Matris çarpımı | DeepGEMM-Ascend | CUDA/Tensor Core kernel’leriyle birlikte DeepGEMM | Aynı GEMM rolü; farklı donanım primitifleri ve veri yerleşimleri |
| MoE gruplanmış hesaplama | DeepGEMM-Ascend içindeki M-Grouped GEMM ve MegaMoE | DeepGEMM MoE yerleşimleri ve özel CUDA kernel’leri | Platforma özel şekiller ve sınırlara sahip birleştirilmiş uzman hesaplaması |
| Uzman yönlendirme | Bu sürümde DeepSeek’e ait tamamlanmış bir Ascend yönlendirme kütüphanesi tanımlanmıyor; Ascend collective işlemleri ve operatör entegrasyonları kullanılmalı | NVLink/RDMA ile DeepEP | Benzer sistem problemi; birbirinin yerine geçebilen depolar değil |
| Attention/logits | DeepGEMM-Ascend içindeki MQA logits | Hopper için FlashMLA | Benzer iş yükü; FlashMLA açıkça Hopper odaklı |
| PyTorch cihaz köprüsü | TorchNPU (torch_npu) | PyTorch CUDA backend’i, CUDA runtime’ı ve cuBLAS | TorchNPU, Ascend NPU’larını çağırır; CUDA’yı emüle etmez |
| Derleyici/operatör araç zinciri | CANN ve Ascend C/Bisheng araçları | CUDA Toolkit, NVCC, PTX, cuBLAS, Triton | Python kodu tanıdık görünebilir; ancak cihaz sözleşmesi değişir |
| Dağıtık çalışma zamanı | TorchNPU collective işlemleri ile Huawei operatör/dağıtım araçları | NCCL, CUDA uyumlu ağ iletişimi ve NVIDIA küme yazılımları | Altyapı, sürücüler, collective işlemleri ve framework sürümleri ayrı kalır |
| Depolama/veri yolu | Burada DeepSeek’e özel bir Ascend depolama bileşeni tanımlanmıyor; depolama operatör tarafından sağlanıyor | DeepSeek’in 3FS/Smallpond bileşenleri ve operatörün depolama yığını | Kernel sürümü buna karşılık gelen bir depolama kümesi içermiyor |
Özetle her Ascend karşılığı bir sistem rolünü üstleniyor; NVIDIA yazılım ekosistemini ortadan kaldırmıyor.
Hesaplama kernel’leri: DeepGEMM-Ascend ve DeepGEMM karşılaştırması
DeepGEMM-Ascend, bu sürümdeki en somut köprü. README dosyası, Ascend MAD primitifleri üzerinde hafif bir soyutlama sunduğunu; fraktal yerleşimleri, hizalama kısıtlarını, adres hesaplamalarını ve düşük seviyeli parametreleri perdelediğini belirtiyor. Ayrıca seyrek veri yükleme ve coroutine tabanlı pipeline oluşturma gibi Ascend’e özel tekniklerden yararlanıyor.
Yayımlanan gereksinimler oldukça net: Ascend 950 serisi donanım, CANN 9.20, torch_npu, Python 3.10 veya üzeri, C++20 uyumlu bir standart kütüphane, TileLang ve Tree-sitter’ın da aralarında bulunduğu derleme bağımlılıkları. Belgelenen kurulum yolu, git clone --recursive komutunun ardından pip install . --no-build-isolation çalıştırılmasını içeriyor.
Depo, Ascend 950DT üzerinde gerçekleştirilen bir test kurulumunda dense-GEMM kullanımının belirtilen donanım sınırının %99,8’ine kadar çıktığını bildiriyor. Bir BF16 senaryosunda 432 TFLOPS’luk donanım sınırına karşılık 431 TFLOPS; FP8 senaryolarında ise 865’e karşı 861 TFLOPS veriliyor. Bunlar seçili şekiller için kernel sonuçlarıdır; uçtan uca DeepSeek throughput değeri ya da bir NVIDIA kümesiyle eşdeğerlik kanıtı değildir.
MoE yürütme: MegaMoE ve uzman yönlendirme
DeepSeek’in open-infra-index deposu, V3/R1 sistemleri için uzman paralelliği altyapısını tanımlıyor. Dolayısıyla önemli soru yalnızca tek bir matris çarpımının ne kadar hızlı çalıştığı değil. Token’ların yönlendirilmesi, uzmanların hesaplama yapması ve sonuçların rank’ler arasında birleştirilmesi gerekiyor.
DeepGEMM-Ascend’in MegaMoE benchmark’ı uzman paralelliği yönlendirmesini, iki gruplanmış GEMM işlemini, SwiGLU’yu ve birleştirme aşamasını tek akışta birleştiriyor. Bildirilen yapılandırma EP8, top-k 6, bir paylaşılan uzman ve sekiz rank üzerinden alınan ortalamadan oluşuyor. README, 16.384 token içeren 384 uzmanlı bir senaryoda, listelenen bir hidden/intermediate yapılandırması için 846,3 TFLOPS; başka bir listelenen senaryo için ise 103,3 GB/s iletişim bant genişliği bildiriyor.
NVIDIA tarafındaki karşılık, DeepEP ile DeepGEMM’in MoE yerleşimleri ve bunları çevreleyen NCCL/NVLink/RDMA ortamı. Mimari problem benzer olsa da token sayıları, uzman yönlendirmesi, hassasiyet, rank sayısı ve ağ koşulları eşleştirilmeden bu rakamlar üreticiler arasında doğrudan karşılaştırılamaz.
Modele özel kernel’ler: MQA logits ve mHC prenorm
Ascend projesi, sürüm yalnızca “bir GEMM portu” olarak anlatıldığında kolayca gözden kaçabilecek kernel’ler de içeriyor. DeepGEMM-Ascend README dosyası, MQA logits benchmark’ını DeepSeek Lightning Indexer yolu için etiketliyor. FP8 ve FP4 prefill ile decode senaryoları listeleniyor; FP4 decode, belgelenen şekil için 124,2 mikrosaniye, FP8 ise 150,9 mikrosaniye olarak veriliyor.
Aynı README, HC prenorm kernel’ini DeepSeek’in mHC modülü, yani Manifold-Constrained Hyper-Connections için etiketliyor. Belgelenen N ve K değerlerinde, M=8.192 için listelenen bellek bant genişliği 3.463 GB/s seviyesine ulaşıyor. Bu sonuçlar iş yüküne özel optimizasyonu gösteriyor; her model operatörünün ya da servis yolunun kapsandığını değil.
Framework ve çalışma zamanı: CANN ile TorchNPU, CUDA karşısında
Huawei’nin TorchNPU deposu, TorchNPU’yu Ascend NPU’ları için bir PyTorch adaptörü olarak tanımlıyor. Özellik listesinde yerel ve özel PyTorch API’leri, FSDP2, DTensor, collective işlemleri, grafik yakalama, profiling, WatchDog izleme ve bellek yönetimi özellikleri bulunuyor.
NVIDIA tarafındaki kavramsal karşılık PyTorch ile CUDA runtime’ı ve kütüphanelerinden oluşuyor. Ancak operasyonel fark büyük: Ascend kurulumu için uyumlu CANN sürümü, sürücü, firmware, Python sürümü, PyTorch sürümü ve TorchNPU sürümü gerekiyor. TorchNPU belgelerindeki örnek CANN 9.1.0, PyTorch 2.12.0 ve torch-npu 2.12.0 kuruyor; DeepGEMM-Ascend ise ayrıca CANN 9.20’yi belgeliyor. Bu sürüm farkı, birbiriyle ilgisiz rehberlerdeki komutları karıştırmak yerine her deponun uyumluluk matrisini takip etmek gerektiğini gösteriyor.
Huawei’nin kendi CANN belgeleri, CANN’i framework’lerle Ascend donanımını birbirine bağlayan; runtime ve operatör geliştirme yollarını da içeren yazılım katmanı olarak tanımlıyor. Pratikte CANN, tek bir CUDA kütüphanesinden çok platformun temelini oluşturuyor. Bir PyTorch modeli tanıdık Python sözdizimini koruyabilir; ancak yine de Ascend’e özel kernel’lere, grafik davranışlarına ve hata ayıklama yöntemlerine ihtiyaç duyabilir.
Sürümün dışında kalanlar
DeepSeek’in orijinal açık altyapı indeksi, 3FS ve Smallpond gibi depolama ve sistem düzeyi projelerini içeriyor; ayrıca DualPipe, EPLB ve bir çıkarım sistemi mimarisini tanımlıyor. Bu projeler önemli referans noktaları olsa da Ascend’e özel kernel sürümü, bunların tamamının taşındığı şeklinde yorumlanmamalı.
Üretim ortamındaki bir küme hâlâ donanım tedariki, sürücüler ve firmware, CANN kurulumu, ara bağlantı yapılandırması, dağıtık çalışma zamanı desteği, gözlemlenebilirlik, checkpoint yönetimi, hata kurtarma ve bir servis ya da eğitim orkestratörü gerektiriyor. Huawei Cloud’un DeepSeek dağıtım rehberi, altyapı tarafını instance’lar, ağlar, alt ağlar ve güvenlik gruplarıyla örneklendiriyor; bunlar DeepGEMM-Ascend’in parçası değil, dağıtım için gereken ön koşullar.
Bu sınır özellikle eğitim tarafında önemli. Herkese açık kernel’ler bir darboğazı azaltabilir; ancak yalnızca kamuya açık depolardan yola çıkarak frontier ölçeğinde bir eğitim çalışmasının yeniden üretilebileceğini kanıtlamaz.
Bu yığını bugün kimler kullanabilir?
| Kullanıcı veya kuruluş | Bugün kullanabilir mi? | Gerekenler | Pratik değerlendirme |
|---|---|---|---|
| Ascend 950 donanımına sahip ekip | Evet, desteklenen kernel’ler için | Linux ortamı, uyumlu sürücü/firmware, CANN 9.20, TorchNPU, derleyici ve uyumlu Python/PyTorch kurulumu | En uygun erken kullanıcı profili |
| Ascend kapasitesine sahip Huawei Cloud veya kurumsal operatör | Potansiyel olarak evet | Desteklenen bir instance/küme ile eksiksiz yazılım matrisi ve dağıtım uzmanlığı | Kontrollü değerlendirme ve servis kullanımı için uygun |
| Daha eski Ascend donanımına sahip araştırma laboratuvarı | Otomatik olarak değil | Cihaz desteği doğrulanmalı; ilk DeepGEMM-Ascend sürümü Ascend 950 serisi üzerinde geliştirildi ve doğrulandı | 910B/910C uyumluluğu varsayılmamalı |
| Yalnızca NVIDIA kullanan iş istasyonu sahibi | Ascend kernel’leri için hayır | Belgelenen bir gereksinim olarak Ascend donanımı gerekiyor | Bunun yerine NVIDIA DeepSeek depoları kullanılmalı |
| Hızlandırıcı erişimi olmayan sıradan PyTorch geliştiricisi | Anlamlı bir çalışma zamanı açısından hayır | Kodu inceleyebilir ve API’leri öğrenebilir; ancak donanım benchmark’larını yeniden üretemez | Dokümantasyona erişim, çalıştırma erişimi anlamına gelmez |
| Kullanıma hazır frontier eğitimi alternatifi arayan ekip | Henüz kamuya açık bir kanıt yok | Kernel depolarının ötesinde eksiksiz bir küme, sistem entegrasyonu ve üretim doğrulaması gerekiyor | Bunu bir pip kurulumu değil, altyapı programı olarak değerlendirin |
Pratik sınır, gereksinimlerde de açıkça görülüyor: belgelenen sürüm için yazılım hâlâ Ascend 950 donanımına, CANN’e ve torch_npu’ya bağlı. Bu, genel hızlandırıcı taşınabilirliği iddiasından çok daha dar bir kapsam.
Yayımlanan rakamlar neyi kanıtlıyor, neyi kanıtlamıyor?
%99,8’lik dense-GEMM sonucu, listelenen Ascend kernel’inin seçili şekillerde test edilen cihazı verimli kullanabildiğine dair güçlü bir işaret. MegaMoE tabloları da DeepSeek mühendislerinin yalnızca tekil bir matris çarpımını değil, birleştirilmiş uzman paralelliği iş yüklerini de ele aldığını gösteriyor.
Ancak bu sonuçların hiçbiri satın alma ya da eğitim ekiplerinin sonunda yanıtlamak isteyeceği soruları karşılamıyor:
- Tam modelde uçtan uca saniye başına kaç token işleniyor?
- Hedef batch boyutunda token başına maliyet nedir?
- Uzun süreli çalışmalarda ve yeniden başlatmalarda sistem ne kadar kararlı?
- Hangi operatörler daha az optimize edilmiş yollara düşüyor?
- Ara bağlantı, bellek ve güç tüketimi hedeflenen NVIDIA kümesiyle nasıl karşılaştırılıyor?
- Aynı sonuçlar ilk test ortamının dışında da yeniden üretilebiliyor mu?
DeepSeek, kurulum ayrıntıları ve seçili performans tablolarıyla ciddi bir Ascend kernel çalışması yayımladı. Bu sürüm, zaten Ascend ekosisteminde bulunan ekiplerin yazılım tarafındaki engellerini azaltıyor; ancak donanım ve sürüm engelleri yerli yerinde duruyor.
SSS
DeepSeek Ascend altyapısı tamamen açık kaynak mı?
Hayır. DeepGEMM-Ascend ve ilgili belgeler herkese açık; ancak bu içerik, tüm bağımlılıkları ve operasyonel tarifleriyle birlikte kullanıma hazır tek bir DeepSeek eğitim kümesi sunmuyor.
DeepGEMM-Ascend’i NVIDIA GPU’da çalıştırabilir miyim?
Hayır. Ascend 950 donanımını hedefliyor. NVIDIA kullanıcıları, DeepSeek’in NVIDIA odaklı projelerini kullanmalı.
Bu sürüm, DeepSeek’in frontier modellerini Ascend üzerinde eğittiğini kanıtlıyor mu?
Hayır. Kanıtlanan şey, DeepSeek’in Ascend kernel’leri yayımladığı ve seçili iş yüklerini benchmark’tan geçirdiği. Bu, uçtan uca frontier eğitiminin kamuya açık biçimde yeniden üretilebildiğini göstermiyor.
Desteklenen Ascend kapasitesini zaten yönetiyor ve CANN/TorchNPU uyumluluğunun sorumluluğunu üstlenebiliyorsanız bu yığını bugün kullanabilirsiniz. Yalnızca NVIDIA donanımınız varsa sürümü çalıştırılabilir bir backend’den çok teknik bir referans olarak değerlendirin.