EC2 üzerinde NVIDIA MPS, modelde değişiklik yapmadan ASR inference maliyetini %75 azalttı

AWS, NVIDIA ve Heidi iş birliğiyle hazırlanan ve AWS Generative AI Innovation Center'dan Jerron Chua'nın katkılarıyla yazılan bir dev.to anlatımı, Amazon EC2 üzerinde otomatik konuşma tanıma (ASR) inference maliyetlerinin %75 nasıl azaltıldığını ele alıyor. Kazanım, yeni bir modelden ya da baştan tasarlanmış bir pipeline'dan değil, NVIDIA'nun Multi-Process Service, yani MPS aracılığıyla tek bir GPU üzerinde birden fazla inference client'ının eşzamanlı çalıştırılmasından geldi.

Bir GPU'yu paylaşmanın üç yolu

Gönderiye göre ölçekli ortamlarda GPU başına tek model instance'ı çalıştırmak çoğu zaman israfa yol açıyor ve yazı üç paylaşım seçeneği sıralıyor. Time-slicing, tek bir cihazda birden fazla sürecin işlerini araya araya çalıştırır. MIG, desteklenen donanımı izole dilimlere böler. MPS üçüncü bir yol izler: birden fazla CUDA client'ı tek bir GPU context'i üzerinden aynı anda çalışır.

MPS'yi pratik kılan detay, CUDA API'sinin binary uyumlu kalan alternatif bir uygulaması olması; böylece mevcut CUDA tabanlı serving stack'leri, farklı bir programlama modeline göre baştan yazılmadan eşzamanlı yürütmeye kavuşuyor. Inference iş yükleri için cevaplanması gereken soru şu: Bu eşzamanlılık, gecikme servisin tolere edebileceği seviyeyi aşmadan önce kullanımı gerçekten yükseltebiliyor mu?

EC2 üzerindeki kurulum

Pipeline, EC2 g6e.4xlarge ve g7e.4xlarge instance'larında çalışıyor; her ikisi de 48 GB belleğe sahip NVIDIA L40S GPU'larla donatılmış. Dağıtımı üç container bileşeni oluşturuyor; bu, sorumlulukları ayrı tutuyor ve farklı paylaşım stratejileri karşılaştırılırken benchmark'ların tekrarlanabilir olmasını sağlıyor.

Serving, NVIDIA Triton Inference Server container'ı nvcr.io/nvidia/tritonserver:26.03-py3 üzerinde temelleniyor. Bu temelden ekip, Dockerfile.single build dosyasını kullanarak test edilen model için, yani bir Parakeet NeMo paketi için birleşik bir image oluşturuyor: model artifact'i LOCAL_NEMO_FILENAME build argümanı olarak geçiliyor ve sonuç parakeet-mps:latest etiketiyle işaretleniyor. Modeli image build'inin içine gömmek, runtime ortamını deneyler arasında yeniden üretilebilir kılıyor.

Ayakta kalabilen bir eşzamanlılık seviyesi seçmek

g6e.4xlarge instance'ı üzerinde değerlendirilen Triton artı MPS yapılandırması için optimum, tepe throughput değil bir gecikme zarfıyla tanımlandı: ortalama gecikmenin 650 ms'nin ve 99. yüzdeliğin 1.000 ms'nin altında kaldığı en yüksek eşzamanlılık.

Gerekçe, throughput'un tek başına yanıltıcı olabilmesi. Bir sistem, eşzamanlılık arttıkça daha fazla bekleyen isteği memnuniyetle kabul eder; ama kuyruk sonundaki (tail) gecikme çok yükselirse yapılandırma üretim ASR'si için kullanışlı olmaktan çıkar. Benchmark'tan çıkan ayar tarifi basit: Kullanım iyileşene kadar eşzamanlılığı yükseltin, hem ortalama hem de p99 gecikmeyi izleyin ve hâlâ servis hedefini sağlayan son seviyede durun.

Uyarılar

MPS her derde deva olarak sunulmuyor. Bir yapılandırmayı uygulanabilir kılan gecikme tavanları, eşzamanlılığın ne kadar ileri itilebileceğini de sınırlıyor; GPU'yu fazla doldurursanız gecikme kabul edilebilir aralığın dışına çıkıyor ve kazanım siliniyor.

Gönderi ayrıca, benchmark çalışması bittikten sonra gözden kaçması kolay operasyonel bir detayı da vurguluyor: Bağlı Amazon EBS volume'leri silinmeli. Bunlar model checkpoint'leri ve bir TensorRT cache'i tutabilir, deney bittikten sonra faturalandırmayı sürdürebilir ve sonraki çalıştırıcıların temiz yeniden üretilimini bulanıklaştıran artifact'ler bırakabilir.

Neden önemli

%75'lik maliyet düşüşü, bir sayı olarak değil, kazancın nereden geldiğinin kanıtı olarak ilginç. Model aynı kaldı ve pipeline aynı kaldı; kazanım tamamen GPU'nun nasıl paylaşıldığından geldi. Bu, deploy edilmiş bir model zaten doğru çalışıyorsa ve darboğaz model kalitesi değil donanım kullanımı olduğunda yaklaşımı cazip kılıyor.

Üretim yapay zeka ekipleri için daha geniş ders, GPU paylaşımını açık gecikme hedeflerine göre değerlendirilen ayarlanabilir bir maliyet kolu olarak görmek: her ne pahasına olursa olsun en yüksek istek sayısını değil, hâlâ güvenilir bir üretim servisi gibi davranan en yüksek eşzamanlılık seviyesini seçin. Bu disiplin, benchmark zaferini gerçek trafikle temas ettikten sonra ayakta kalan bir maliyet tasarrufuna dönüştüren şeydir.