IBM POWER9 AC922 Üzerinde Adli Bilişim ve Yapay Zeka

Bir yazılımı x86-64 üzerinde derlemek ile onu farklı bir işlemci mimarisinde verimli, yeniden üretilebilir ve uzun süre sürdürülebilir biçimde çalıştırmak aynı problem değildir. Hazır ikili paketlerin, x86 komut kümelerine göre yazılmış optimizasyonların ve yaygın araç zincirlerinin dışına çıkıldığında uygulama kodundan önce derleyiciyi, komut kümesini, bellek erişimini, iş parçacığı modelini ve donanım-hızlandırıcı ilişkisini anlamak gerekir.

2019'dan beri T.C. İçişleri Bakanlığı kapsamındaki adli bilişim ve yapay zeka çalışmalarımda kullandığım IBM Power System AC922, bu farkı en fazla deneyimlediğim sistemlerden biri oldu. Zaman içinde bu makine; yüz tanıma, konuşma tanıma, görüntü ve ses işleme, OCR, büyük öznitelik kümelerinde benzerlik arama, dosya kazıma, kriptanaliz, SIMD optimizasyonu, OpenMP ve CUDA çalışmalarının ortak hesaplama platformuna dönüştü.

Burada anlattığım değer yalnızca güçlü bir sunucuya erişimden gelmiyor. POWER9 gibi x86 dışı bir mimaride hazır yolun sık sık bulunmaması beni kullandığım kütüphanelerin kaynak koduna, derleyici bayraklarına, vektör komutlarına, bellek yerelliğine ve GPU çekirdeklerine kadar inmeye zorladığı için önemli. Bugün CTranslate2 ve faster-whisper gibi daha yeni araçları aynı sistemde çalıştırmaya hazırlanırken, yedi yıl önce dlib, MXNet ve FAISS ile karşılaştığım problemin farklı bir sürümüne yeniden dönmüş durumdayım.

AC922 Donanım Yapısı ve NVLink Topolojisi

Kullandığım sistem IBM Power System AC922 8335-GTH. Bu model, iki POWER9 işlemci soketini NVIDIA Tesla V100 hızlandırıcılarla NVLink 2.0 üzerinden birleştiren, yapay zeka ve yüksek başarımlı hesaplama için tasarlanmış özel bir platform. GTH hava soğutmalı modeldir ve en fazla dört GPU destekler; altı GPU'lu yapılandırma GTX modeline aittir. Benim kullandığım sistem dört adet NVIDIA Tesla V100 SXM2 32 GB ile yapılandırılmış durumda.

CPU tarafında toplam 32 fiziksel POWER9 çekirdeği bulunuyor. SMT4 ile işletim sistemi 128 mantıksal işlemci görüyor. Sistem 512 GiB DDR4 belleklidir. GPU tarafında ise her biri 32 GB HBM2 belleğe sahip dört V100 bulunuyor. Dört GPU'nun toplam fiziksel HBM2 kapasitesi 128 GB olsa da bu, tek bir 128 GB adres alanı değildir; her GPU kendi yerel belleğine sahiptir.

AC922'yi klasik x86 + PCIe GPU düğümlerinden ayıran kritik noktalardan biri NVLink 2.0 topolojisidir. Bu mimaride NVLink yalnız GPU'lar arası iletişim için kullanılmaz; V100'ler POWER9 işlemcilere doğrudan NVLink üzerinden bağlanır ve GPU belleğine tutarlı bellek erişimi sağlar. Bu yapı veri hareketi maliyetini ortadan kaldırmaz, ancak host-device yolunun yalnız PCIe üzerinden kurulduğu klasik düğümlere göre CPU-GPU iletişiminin bant genişliği ve gecikme karakterini değiştirir. Yıllar boyunca veri hareketini algoritma optimizasyonunun bir parçası olarak ele almamın bu platformdaki somut karşılıklarından biri budur.

Tek bir V100 SXM2 32 GB; 5.120 CUDA çekirdeği, 640 Tensor Core, yaklaşık 900 GB/s HBM2 bant genişliği, 15,7 TFLOPS FP32 ve 125 Tensor TFLOPS FP16 işlem kapasitesi sunar. Dört kartın teorik toplamı 20.480 CUDA çekirdeği, 2.560 Tensor Core, yaklaşık 62,8 TFLOPS FP32 ve yaklaşık 500 Tensor TFLOPS FP16 eder. Bu rakamlar tek bir işin dört kat hızlı çalışacağı anlamına gelmez; ölçeklenme veri bölünebilirliğine, GPU'lar arası iletişime, senkronizasyona, kernel tasarımına ve ana bellek-GPU belleği veri hareketine bağlıdır.

Bu sınıfta bir AC922 bugün de sıradan bir geliştirme makinesi değildir. Özellikle POWER9, SXM2 V100, NVLink ve büyük sistem belleğinin aynı düğümde birleşmesi, onu klasik x86 + PCIe GPU sunucusundan mimari olarak ayırır. Benim açımdan önemli olan da bu farkın yıllar boyunca farklı problem sınıflarında tekrar tekrar görünür hale gelmesiydi.

x86 Varsayımından AltiVec ve VSX'e

POWER9 üzerinde ilk zorlayıcı alanlardan biri dlib ve MXNet ile yaptığım yüz tanıma çalışmalarıydı. Kaynak kod genel olarak taşınabilir görünse de performans kritik noktalarda SSE, AVX veya AVX2 gibi x86 komut kümelerine göre yazılmış kısımlarla karşılaşmak mümkündü. Kodun derlenmesi ile hedef mimarinin gücünü kullanması aynı şey değildi.

Bu nedenle bazı komut kümesi bağımlı bölümleri POWER mimarisinin AltiVec/VSX vektör yapısına uyarladım. Bu iş yalnızca intrinsic adlarını değiştirmekten ibaret değildi. Vektör kayıtlarının yapısı, veri hizalama gereksinimleri, derleyicinin ürettiği kod, yükleme-saklama düzeni ve önbellek davranışı birlikte ele alınmak zorundaydı.

Bu çalışmalar SIMD konusunda önemli bir ayrımı netleştirdi: daha geniş vektör komutu kullanmak tek başına hızlanma garantisi vermez. Veri bellekte dağınıksa, önbellek yerelliği zayıfsa veya dallanma maliyeti yüksekse teorik vektör genişliği pratikte kullanılamaz. Bu nedenle daha sonraki optimizasyonlarda önce veri düzenine, sonra komut kümesine bakmaya başladım.

Geçmiş optimizasyonlarda çok sayıda deneysel ölçüm yaptım; ancak aynı yazılım ve donanım koşullarını bugün yeniden üretmeden yüzde hızlanma değeri vermediğim için bu yazıda geçmiş sonuçları niteliksel, donanım ve sürüm sınırlarını ise doğrulanabilir sayısal değerlerle aktarıyorum.

FAISS ve ArcFace: Modelden Sonraki Problem

Yüz tanıma tarafında ArcFace tabanlı modellerle büyük veri kümelerinden embedding çıkardığım çalışmalarda ikinci büyük problem benzerlik aramasıydı. Model özniteliği hızlı çıkarsa bile milyonlarca vektör içinde arama maliyeti ortadan kalkmıyor.

FAISS'i POWER9 üzerinde derlemek o dönemde standart bir paket kurulumu değildi. Uzun bir derleme ve uyumluluk sürecinin ardından kütüphaneyi çalıştırdım ve bazı kısımlarını bu mimariye göre düzenledim. Bu deneyim bana yüz tanıma sisteminin yalnızca sinir ağından ibaret olmadığını çok net gösterdi: GPU'da embedding üretimi, CPU tarafındaki veri hazırlama, vektör indeksinin bellek davranışı ve arama algoritması aynı performans zincirinin parçalarıdır.

Bu nedenle daha sonraki çalışmalarda "model ne kadar hızlı?" sorusunu tek başına yeterli görmedim. Uçtan uca aktarım hızı, veri hareketi ve indeks erişim maliyeti en az model çıkarımı kadar önemli hale geldi.

Kaldi, Vosk ve whisper.cpp ile Konuşma Tanıma

Aynı sistemde uzun süre ses ve konuşma tanıma projeleri de geliştirdim. Önce Kaldi ve Vosk ile çalıştım. Whisper ailesi ortaya çıktığında whisper.cpp'yi POWER9 üzerinde derleyip çalıştırdım ve konuşma tanıma çalışmalarımı bu modele taşıdım.

whisper.cpp'nin C/C++ tabanlı yapısı benim için özellikle uygundu; iş parçacığı sayısı, SIMD yolu, derleme seçenekleri, tensör işlemleri ve bellek davranışı framework katmanının arkasında tamamen görünmez değildi. POWER9 üzerinde daha önce edindiğim düşük seviye optimizasyon deneyimi ile yeni nesil konuşma tanıma modelleri böylece doğrudan birleşmiş oldu.

Eş Zamanlı Televizyon Akışı Analizi

Bu makine üzerinde geliştirdiğim daha karmaşık sistemlerden biri, canlı bir televizyon akışını aynı zaman ekseninde birden fazla analiz kanalına ayıran uygulamaydı. FFmpeg ile medya akışını ses ve görüntü olarak ayırıyor, veriyi süreçler arası pipe üzerinden ilgili işleyicilere iletiyordum.

Görüntü kolunda belirli aralıklarla kare alınıp yüz tanıma yapılıyor, ayrıca Tesseract ile ekran üzerindeki metinler okunuyordu. Ses kolunda konuşma tanıma çalışıyor, elde edilen metin daha sonraki içerik analizine aktarılıyordu. Deneysel uygulamada önceden tanımlanmış bir referans yüz galerisi kullanılıyor; görüntüdeki yüzler bu galeriyle karşılaştırılırken görsel kimlik, ekrandaki yazı, konuşma metni ve zaman bilgisi aynı medya zaman çizelgesinde ilişkilendiriliyordu.

Teknik olarak asıl mesele galeri içeriği değil, görüntü, OCR ve konuşma tanıma sonuçlarını ortak zaman damgası üzerinde birleştirmekti. Günümüzde çok kipli sistemler başlığı altında sık gördüğümüz bu problemi, farklı modelleri tek bir akışta eşleştirirken daha erken dönemde deneyimlemiştim.

OpenMP, SMT ve Gerçek Paralellik

Çalışmalarımın önemli bir bölümü C ve C++ ile yazıldı. CPU paralelliğinde uzun süre OpenMP kullandım. POWER9'un 32 fiziksel çekirdeği ve SMT4 ile 128 mantıksal işlemci sunması uygun iş yüklerinde büyük bir paralellik alanı sağlıyor; ancak #pragma omp parallel for eklemek bir algoritmayı otomatik olarak hızlandırmıyor.

Pratikte çalışma süresini işlem süresinin yanında senkronizasyon, bellek erişimi, I/O, yük dengesizliği ve önbellek etkileri belirliyor. Bazı iş yüklerinde 128 iş parçacığı kullanmanın 32 iş parçacığından daha yavaş olduğunu gördüm. Bunun nedeni SMT'nin fiziksel yürütme birimlerini çoğaltmaması; mevcut kaynakları bekleme sürelerinde daha iyi kullanmaya çalışmasıdır. İşlem birimleri veya bellek bant genişliği zaten doygunsa daha fazla iş parçacığı ek yük oluşturabilir.

Bu nedenle OpenMP ve SIMD'yi birbirinin alternatifi olarak değil, iki farklı paralellik düzeyi olarak ele aldım. İş, çekirdekler arasında bölünürken her çekirdek kendi VSX vektör yolunu da kullanabilir. Bu model ancak veri yerleşimi, cache line paylaşımı, NUMA sınırları ve bellek bant genişliği birlikte düşünüldüğünde verimli olur.

CUDA C/C++ ve Dört Tesla V100

V100'leri yalnızca yüksek seviyeli framework'ler aracılığıyla kullanmadım. CUDA C/C++ ile kendi kernel'lerimi yazdığım, .cu ve .cuh dosyalarını nvcc ile derlediğim ve bazı işleri dört GPU'ya dağıttığım uygulamalar geliştirdim.

GPU programlama CPU optimizasyonundaki aynı gerçeği başka bir biçimde gösterdi: teorik FLOPS değeri, veri hareketinden bağımsız değildir. Küçük bir iş için host-device kopyası ve kernel başlatma maliyeti kazancı silebilir. Yüksek aritmetik yoğunlukta, büyük matrislerde veya toplu embedding üretiminde ise HBM2 bant genişliği ve V100'ün hesaplama kaynakları belirgin avantaj sağlar.

Dört GPU'lu yapıda her işi tek modele bölmek de zorunlu değildir. Bağımsız işler için GPU başına bir işçi süreci kullanmak; toplam aktarım hızını, hata yalıtımını ve kaynak yönetimini daha öngörülebilir hale getirebilir. Bugünkü faster-whisper çalışmamda da ilk değerlendireceğim topolojilerden biri budur.

Dosya Kazıma ve Büyük Ham Veri

Adli bilişim tarafında büyük dump verileri üzerinde dosya kazıma çalışmaları yaptım. Daha önce C# ile geliştirdiğim imza tabanlı yaklaşımı C/C++ tarafına taşıyıp OpenMP ile paralelleştirdim.

Büyük ham veride esas problem yalnızca dosya başlangıç ve bitiş imzalarını bulmak değildir. Okuma blokları arasında kalan imzalar için yeterli örtüşme payı bırakmak, komşu iş parçacıklarının aynı sonucu iki kez üretmesini engellemek, I/O hızını CPU tarama hızıyla dengelemek ve yanlış pozitifleri sınırlamak gerekir. Bu nedenle blok boyutu, örtüşme miktarı, imza arama algoritması ve paralellik düzeyi birlikte belirlenmelidir.

Bu çalışmalar, yüz tanıma veya konuşma tanımadan farklı görünse de benim için aynı optimizasyon disiplininin parçasıydı: büyük veriyi mümkün olduğunca az kopyalamak, aynı bölgeyi gereksiz tekrar taramamak ve paralelliği depolama sisteminin gerçek aktarım kapasitesine göre sınırlamak.

AES, SIMD ve Algoritmanın Küçük Maliyetleri

AES kriptanalizi ile ilgili deneysel çalışmalarda da POWER mimarisinin vektör yürütme olanaklarını ve yüksek paralel işlem kapasitesini kullandım. Kriptanalizde tek bir komutun, dallanmanın veya bellek erişiminin maliyeti çok daha görünür hale gelir; çünkü aynı işlem milyarlarca kez tekrarlandığında mikro düzeydeki maliyet toplam süreyi belirlemeye başlar.

Bu çalışmalar algoritma optimizasyonuna bakışımı etkiledi. Sonraki projelerde bir optimizasyonu yalnızca daha fazla çekirdek veya daha fazla GPU kullanmak olarak değil, toplam veri hareketini ve tekrar sayısını azaltmak olarak ele aldım.

Aynı Makinede Farklı Veri Türleri

Yıllar içinde AC922 üzerinde farklı veri sınıfları aynı hesaplama düğümünde birleşti. Görüntü tarafında yüz tanıma, ArcFace embedding üretimi ve kare analizi; ses tarafında Kaldi, Vosk, whisper.cpp ve konuşma tanıma; video tarafında FFmpeg ile gerçek zamanlı akışın ayrılması; ekrandaki metin için Tesseract OCR; büyük vektör kümeleri için FAISS; ham disk ve dump verileri için paralel dosya kazıma; kriptografik veriler için AES odaklı analizler yaptım.

Adli Bilişimde Yeniden Üretilebilirlik

Bu sistem üzerinde yaptığım yapay zeka çalışmalarının adli bilişim açısından en önemli sonucu yalnızca hız değildi. Makine öğrenmesi çıktısının hangi koşullarda üretildiğinin kayda alınması gerekir.

Aynı ses dosyası veya aynı görüntü; farklı CPU SIMD yolu, farklı CUDA kernel'i, farklı kütüphane sürümü ya da farklı kayan noktalı toplama sırası ile işlenebilir. Matematiksel model aynı olsa bile kayan noktalı işlemler tam sayı aritmetiği gibi birleşme özelliğine sahip değildir; özellikle karar sınırına yakın olasılıklarda küçük farklar sonraki token veya sınıf kararını etkileyebilir.

Bu nedenle adli bir analizde yapay zeka çıktısını yalnızca "model adı" ile tanımlamak yeterli değildir. En azından girdi dosyasının özeti, model dosyalarının özeti, model ve çıkarım motoru sürümü, mimari, GPU modeli, CUDA/cuDNN sürümü, hesaplama türü, decode parametreleri ve zaman bilgisi birlikte kaydedilmelidir. Böyle bir kayıt, delil bütünlüğünün kendisi yerine geçmez; ancak türetilmiş bulgunun hangi yürütme ortamı tarafından üretildiğini açıklar ve yeniden üretilebilirlik için gerekli zemini sağlar.

Benim açımdan "deterministik" bir iş akışı, her koşulda bit düzeyinde aynı yapay zeka çıktısını vaat etmek değil; değişkenleri kayda alarak farkın kaynağını denetlenebilir hale getirmektir. GPU tabanlı kayan noktalı hesaplamada bit düzeyi özdeşlik her zaman mümkün olmayabilir. Adli bilişimde önemli olan bu sınırı gizlemek değil, ispat zincirinin bir parçası olarak belgelemektir.

2026: CTranslate2 ve faster-whisper ile Aynı Probleme Dönüş

Yakındaki hedeflerimden biri CTranslate2/faster-whisper tabanlı Whisper modellerini bu makinede yeniden konumlandırmak. 21 Ağustos 2026 itibarıyla CTranslate2'nin yaygın hazır Linux ikilileri x86-64 ve AArch64 odaklı; ppc64le için kaynak kod, derleyici ve arka uç seçimi yeniden önem kazanıyor.

Aynı tarih itibarıyla açık olan POWER10/ppc64le katkısı, VSX ile birlikte POWER10'un Matrix Math Accelerator birimlerini hedefliyor. Katkı notlarında POWER9 için derlemenin mümkün olabileceği, ancak MMA birimlerinin bulunmamasının CPU performansını belirgin biçimde etkileyeceği açıkça belirtiliyor. Bu nedenle POWER10 için geliştirilen yolu POWER9'da aynı performans beklentisiyle kullanmak doğru değil.

GPU tarafında ise V100 halen anlamlı. Volta mimarisindeki V100 compute capability 7.0, yani sm_70; CTranslate2 kaynak derlemesinde hedef mimariyi CUDA_ARCH_LIST=7.0 ile açıkça sabitlemek bu nedenle daha doğru. İlk referans koşusunu tek V100, FP16, sabit model ve sabit decode parametreleriyle oluşturmayı planlıyorum. Ölçümlerde temel metrik RTF (real-time factor) olacak; buna duvar saati süresi, tepe GPU bellek kullanımı, GPU kullanımı, varsa referans transkript üzerinden WER ve GPU0-GPU3 arasında normalize edilmiş çıktı farkı eşlik edecek. Token/s değeri yardımcı bir ölçü olabilir, ancak konuşma tanımada tek başına RTF kadar açıklayıcı değildir. Dört GPU'yu tek modele bölmek yerine dört bağımsız çıkarım işçisi olarak kullanmak da özellikle toplu veya eş zamanlı ses işlerinde değerlendireceğim topolojilerden biri.

Platformu Yeniden Kurarken Asıl Kısıt

Buradaki en önemli güncel sınır CUDA ekosisteminden geliyor. NVIDIA, PowerPC mimarisi için CUDA desteğini 12.5 ile kaldırdı. POWER9 için son resmi CUDA çizgisi 12.4.x ve CUDA 12.4.1 Linux destek matrisi POWER9 tarafında RHEL 8.9'a kadar uzanıyor. cuDNN 9.0 belgelerinde de RHEL 8 için ppc64le kurulumu ve CUDA 12 paketi bulunuyor.

CTranslate2 4.5.0 ile Python paketinin cuDNN 9'a geçmesi ve cuDNN 8 ile uyumluluğun kaldırılması, bu platformda sürüm zincirini birlikte sabitlemeyi daha da önemli hale getiriyor. Bu nedenle CTranslate2, CUDA ve cuDNN sürümlerini bağımsız seçmek yerine tek bir doğrulanmış kombinasyon olarak pinlemek gerekir.

Buna karşılık CTranslate2'nin açık POWER10 katkısı CPU tarafında RHEL 9 ve IBM Advance Toolchain 17 ile test edilmiş durumda. Bu iki bilgi aynı şeyi anlatmıyor: biri NVIDIA'nın POWER9 GPU yazılım matrisini, diğeri CTranslate2 için geliştirilmekte olan POWER10 CPU yolunun test ortamını gösteriyor. POWER9 + V100 üzerinde üretim hedefi için NVIDIA'nın desteklediği GPU tabanı daha belirleyici; dolayısıyla benim için rasyonel hedef RHEL 8.9, CUDA 12.4.1, bu hatla uyumlu cuDNN 9 ve POWER9'a özel kaynak derlemesi olacak.

Sunucunun halen eski işletim sistemi ve sürücü kuşağında çalışıyor olması nedeniyle bu geçişi yerinde, kör bir güncelleme olarak yapmayı doğru bulmuyorum. Firmware, GPU sürücüsü, NVLink topolojisi ve uygulama bağımlılıkları birlikte doğrulanmalı; mümkünse yeni bir sistem ortamı üzerinde referans testleri tamamlanmadan mevcut çalışan düzen bozulmamalı.

Yedi Yılın Ortak Dersi

2019'da dlib ve MXNet kod yollarını AltiVec/VSX'e uyarlamakla başlayan dönem; FAISS, ArcFace, Kaldi, Vosk, whisper.cpp, OpenMP, CUDA, Tesseract ve dosya kazıma projeleriyle devam etti. 2026'da aynı makine CTranslate2, faster-whisper ve daha yeni yerel yapay zeka modelleri için yeniden bir deney alanı haline geliyor.

Bu çalışmaları birleştiren nokta kullandığım framework değil. Hepsinde algoritmanın sonunda işlemci komutlarına, bellek erişimlerine, I/O'ya, senkronizasyona ve veri hareketine dönüştüğünü görmek zorunda kaldım. POWER9 üzerinde hazır paketlerin azlığı zaman zaman ciddi ek iş çıkardı; fakat aynı zorluk, algoritma ile donanım arasındaki katmanları daha görünür hale getirdi.

Bu nedenle AC922 benim için yalnızca dört V100 ve 512 GiB bellekten oluşan nadir bir sunucu değil. Adli bilişim ile yapay zekanın kesiştiği problemlerde mimari farkındalık, paralel programlama, SIMD, GPU programlama, yeniden üretilebilirlik ve algoritma optimizasyonu konusunda yıllar boyunca kullandığım bir mühendislik laboratuvarı oldu.

Bana kalan en kalıcı ilke de bu: Bir donanımın gerçek gücü teknik özellik tablosundaki FLOPS değeri değildir. O gücü kullanabilecek algoritmayı, veri düzenini ve yürütme modelini kurabildiğiniz ölçüde o donanıma sahipsiniz.

Kaynaklar

• IBM Redbooks. IBM Power System AC922 Technical Overview and Introduction. 2018; güncelleme 2023. https://www.redbooks.ibm.com/abstracts/redp5494.html
• IBM Support. IBM Power System AC922 üzerinde POWER9/NVLink 2.0 CPU-GPU bağlantı yapısı. 2021. https://www.ibm.com/support/pages/node/6412651
• IBM Documentation. 8335-GTH/GTX parça ve GPU yapılandırma bilgileri. 2026 erişimi. https://www.ibm.com/docs/en/power9/8335-GTX?topic=fpl-8335-gtc-8335-gtg-8335-gth-8335-gtw-8335-gtx-parts
• NVIDIA. Tesla V100 Tensor Core GPU Datasheet. 2017. https://images.nvidia.com/content/technologies/volta/pdf/tesla-volta-v100-datasheet.pdf
• NVIDIA. CUDA Installation Guide for Linux 12.4 Update 1. 2024. https://docs.nvidia.com/cuda/archive/12.4.1/cuda-installation-guide-linux/index.html
• NVIDIA. CUDA Toolkit 12.5 Release Notes. 2024. https://docs.nvidia.com/cuda/archive/12.5.0/cuda-toolkit-release-notes/index.html
• NVIDIA. cuDNN 9.0 Linux Installation. 2024. https://docs.nvidia.com/deeplearning/cudnn/backend/v9.0.0/installation/linux.html
• OpenNMT/CTranslate2. CTranslate2 4.5.0 Release Notes. 2024. https://github.com/OpenNMT/CTranslate2/releases/tag/v4.5.0
• OpenNMT/CTranslate2. IBM Power10 (VSX, MMA) support for ppc64le, PR #1748. 2023-2026. https://github.com/OpenNMT/CTranslate2/pull/1748