GPU havuzunu genişletmeden önce ölçüm yapın

Bu ayrımı anlamak, var olan kapasiteyi daha etkin kullanmamıza yardımcı olur. İş yüklerini geniş kategorilere ayırmak yeterli değildir; bazı batch işlemler bekletebilirken, bazı eğitim işleri kesin bir teslim tarihine sahiptir.

KubeCon + CloudNativeCon Salt Lake City’de 9-12 Kasım tarihleri arasında gerçekleşir. Katılım için kayıt yapın.

Her iş yükü için teslim tarihini, beklenilen çalışma süresini, kaynak ihtiyacını ve ara verilen sonucu tanımlayın. Ayrıca iş yükünün ne sayılacağı da netleştirilmelidir. Bir inference hizmeti için görev bazlı kalite eşiği ve gecikme hedefi bulunmalıdır; sadece bir isteğin yanıt vermesi ya da geçerli bir JSON dönüşümü iş yükünün hedefine ulaşmışlığı göstermez.

Başlangıç zamanı esnekliği, ara verilen sonucun kabul edilebilirliğiyle ayrı tutulmalıdır. Başlatma süresi esnek bir iş yükü hâlâ ara verilen sonucunda kesilmesini isteyebilir.

Zamanlama esnekliğiyle kapasite artırmadan önceki örnek bir senaryo düşünün: Noon’a kadar dört uyumlu GPU kullanılabilir. Noon’da dört bağımsız değerlendirme işi bekier. Her biri bir saat boyunca iki GPU ihtiyacı duyuyor ve tüm sonuçlar 5 p.m.’ye kadar teslim edilmelidir.

İkinci saat başı tüm işleri aynı anda çalıştırırsanız toplamda sekiz GPU gereksinimi doğacaktır. Ancak birini öğleden sonra birine iki işi aynı anda çalıştırarak, iki işi öğleden sonra iki işi de aynı anda çalıştırarak, tüm işler 2 p.m.’de tamamlanır ve sadece dört GPU kullanılır. Bu plan, startup gecikmesi hariç, aynı sekiz GPU saatini tüketir.

“Zamanlamayı esnek tutmak, piyasa talebini azaltır. İşler hâlâ zamanında tamamlanır, havuzu genişletmeden.”

Kuyruğu boşaltmak için ek GPU’lar sağlamadan önce, işlerin başlatma esnekliği ne kadar yüksek olduğunu değerlendirin.

Kueue gibi araçlar, belirli kvota ve politikalarla işleri kabul etme noktası sunar. Ekibin hâlâ teslim tarihleri ve kaynak ihtiyaçlarını nasıl temsil edeceklerini ve nasıl zorlayacağını belirlemesi gerekir. Esnek kuyrupleme, kapasite planlamasını destekler ve işleri erken başlamadan sonra onları önceliklendirme ihtiyacını azaltır.

Sürdürülebilir kapasite ölçümü için temsilci yüklemesi yapın. Model, donanım, hizmet kurulumu ve istek karışımı sabit kalmalıdır; ardından gelen istek hızını artırarak, verim, gecikme ve kaliteyi izleyin. İstenen kalite ve seçilen gecikme persentilini karşılayan en yüksek sürdürülebilir hız, kapasite tahmini için kullanışlı bir ölçüt olur.

Üretim trafiği ile test kapasitesi karşılaştırın. Düşük önbellek işgali bir sorun işaret edebilir, ancak ondan yalnızca on iki kat daha fazla verim elde ettiğini iddia etmek için bir verim testi gerekir. Geçici artışlar geçici kuyruklar yaratabilirken, kalıcı kuyruklar kaynak sınırlamasını gösterir. Her iki durum da yalnızca sınırlayıcı kaynağı tanımlamaz.

OpenCost verileri ile doğruluk sonuçlarını bağlayın. FinOps topluluğu, AI verimliliğiyle maliyet ve faydayı ilişkilendirir. AI iş yükleri için maliyet, altyapının desteklediği sonuçlarla ilişkilendirildiğinde daha anlamlı olur.

Kubernetes ekipları, iş yükü maliyetini, hizmet davranışını ve uygulama sonuçlarını birleştirerek bu ilişkiyi somutlaştırabilir. OpenCost tahsis API’sı, iş yükü maliyetini zaman diliminde ölçer; bu verileri iş kimlikleri ve zaman damgalarıyla hizmet telemetrisiyle birleştirerek daha net bir değerlendirme yapabilirsiniz.

“Maliyet per verified outcome” ölçümü, tanımlı kalite ve zaman sınırlamalarını karşılayan sonuçların sayısına bölünerek hesaplanır. Tekrar denemeler, başarısızlıklar, startup ve idle süreler maliyet katkısını artırır; son iş sonucunu yalnızca bir kez sayılır.

Bu yaklaşım, ekipların sadece altyapı harcamalarını değil, aynı zamanda değerli sonuçları da ölçmesine olanak tanır.