Apa yang terlewatkan oleh tolok ukur AI tentang kinerja dunia nyata
Dipresentasikan oleh tim AI F5Enterprise yang telah menghabiskan waktu bertahun-tahun untuk memecahkan masalah komputasi, mengamankan alokasi GPU, menegosiasikan kapasitas cloud, dan membuat tolok ukur hasil pelatihan. Asumsi yang tertanam dalam pekerjaan tersebut adalah bahwa jalur antara penyimpanan dan komputasi akan tetap sama. Dalam produksi, asumsi tersebut semakin tidak berlaku. Lalu lintas nyata menimbulkan lonjakan latensi, jitter jaringan, dan degradasi node yang gagal ditangkap oleh tolok ukur terkontrol, sehingga menghasilkan pipeline yang berkinerja baik di lab tetapi terhenti dalam penerapannya. Respons yang semakin meningkat adalah pengiriman data AI, yang menerapkan pengontrol pengiriman aplikasi (ADC) atau platform pengiriman aplikasi dan keamanan (ADSP) di depan penyimpanan sebagai titik kontrol yang tangguh dan aman. “Penyediaan memecahkan masalah kapasitas tetapi tidak untuk pengiriman, dan di situlah kendalanya sekarang tersembunyi,” kata Hunter Smit, manajer senior pemasaran produk di F5. “Perusahaan-perusahaan membeli cukup GPU dan penyimpanan yang cukup, lalu berasumsi jalur di antara mereka akan tetap sama, namun lalu lintas AI sangat padat, sangat konkuren, dan acak dalam pembacaannya dengan cara yang tidak dapat diserap oleh jaringan penyimpanan biasa.” Tolok ukur kesenjangan produksi tidak menunjukkan Metodologi benchmark standar menambah masalah, kata Paul Pindell, arsitek solusi utama untuk aliansi teknologi di F5. “Pengujian benchmark biasanya dibuat untuk menghasilkan kinerja atau hasil keamanan terbaik, bukan yang paling realistis,” katanya. “Dengan S3, latensi merupakan faktor yang diketahui menurunkan kinerja, sehingga pengujian yang bermakna harus memasukkan latensi yang konsisten ke dalam jalurnya.” Sebagian besar lingkungan benchmark tidak pernah melakukan hal tersebut, yang berarti angka kinerja yang diandalkan oleh perusahaan untuk pengambilan keputusan infrastruktur diambil dari kondisi yang tidak akan pernah ditiru oleh sistem produksi. Untuk menguji asumsi ini, F5 dan MinIO melakukan pengujian throughput dalam kondisi jaringan terdegradasi. “Yang menonjol adalah betapa cepatnya penurunan throughput S3 setelah Anda memperkenalkan latensi,” kata Pindell. “Bahkan latensi yang kecil pun berdampak besar, dan ketika latensi meningkat menuju jarak jarak jauh, degradasinya menjadi parah.” Pengujian ini juga menunjukkan bahwa latensi jauh lebih penting daripada jitter sebagai penyebab hilangnya throughput, yang membalikkan ekspektasi tim. Hasil bagi arsitek perusahaan adalah penerapan penyimpanan objek S3 tidak dapat dirancang berdasarkan asumsi ruang bersih; mereka harus direkayasa untuk menghadapi kondisi jaringan terdegradasi yang akan mereka hadapi. Kerugian dari jalur data yang rapuh “Dalam infrastruktur AI, orang-orang secara alami fokus pada GPU karena mereka adalah sumber daya yang paling terlihat dan mahal,” kata Tanu Mutreja, direktur senior manajemen produk di F5. “Namun dalam lingkungan produksi, GPU hanya menghasilkan nilai sebesar jalur data yang menyalurkannya.” Jalur tersebut berjalan melalui lapisan penyimpanan, jaringan, database, keamanan, dan orkestrasi, yang sering kali digabungkan dari beberapa vendor. Pelanggan tidak mengalami satupun dari hal tersebut; mereka mengalami keluaran dari keseluruhan sistem. Ketika jalur data menurun, efeknya bertambah. Kurangnya pemanfaatan GPU adalah gejala yang paling langsung dan terlihat, namun Mutreja menunjukkan serangkaian konsekuensi yang lebih luas: penurunan kinerja inferensi, kualitas keluaran AI yang buruk, biaya keluar yang lebih tinggi akibat replikasi data yang tidak perlu, dan meningkatnya kompleksitas operasional. “Dalam skala besar, efisiensi jalur data menjadi pendorong bisnis yang strategis dibandingkan optimalisasi teknis,” katanya. “Ketika jalur data direkayasa dengan baik, GPU akan tetap produktif, aplikasi AI tetap responsif dan dapat dipercaya, skala operasi menjadi efisien, dan organisasi memaksimalkan laba atas investasi AI mereka.” Beban kerja AI secara struktural lebih rentan terhadap kegagalan ini dibandingkan aplikasi perusahaan tradisional. Basis data, sistem ERP, dan layanan web menyerap penundaan penyimpanan sementara melalui caching dan buffering. Beban kerja AI yang berjalan di cluster GPU paralel yang sangat besar tidak memiliki perlindungan yang setara. Sebagaimana dicatat oleh Mutreja, bahkan lonjakan latensi kecil atau kemacetan bandwidth dapat terjadi di cluster GPU yang besar, dan secara bersamaan berdampak pada pemanfaatan, efisiensi pelatihan, dan pengalaman pelanggan. Memperlakukan tepi penyimpanan sebagai titik kontrol Selama beberapa dekade, penyimpanan dan kecerdasan beroperasi sebagai masalah yang berurutan dalam arsitektur perusahaan: data disimpan terlebih dahulu, kemudian dianalisis di bagian hilir. Mutreja berargumen bahwa model ini tidak lagi sesuai dengan tuntutan AI. “Keunggulan kompetitif tidak hanya ditentukan oleh volume data, namun juga oleh relevansi, garis keturunan, keamanan, dan kinerja pengiriman data,” katanya. “Di seluruh industri, mulai dari NVIDIA dan AWS hingga penyedia penyimpanan perusahaan, gerakan ini mengarah pada penyematan kecerdasan secara langsung ke dalam infrastruktur data dibandingkan menumpuknya di atas.” Integrasi F5 dengan MinIO menunjukkan pendekatan ini pada lapisan di mana penyimpanan dan komputasi benar-benar berinteraksi. Sebagai bagian dari F5 ADSP, BIG-IP berada di jalur data, terus memantau kesehatan node penyimpanan terdistribusi MinIO dan mengarahkan permintaan hanya ke node yang masih tersedia. Dampak operasional dari kemampuan tersebut menjadi jelas ketika node mengalami penurunan, yang biasa terjadi pada cluster penyimpanan terdistribusi. Tanpa perutean yang cerdas, klien yang mendarat di node yang tidak sehat harus mencoba lagi dan mungkin mendarat di node lain yang terdegradasi, sehingga menurunkan kinerja secara keseluruhan. “F5 memastikan lalu lintas hanya menuju ke node yang sehat, atau bahkan ke node yang paling tidak sibuk, sehingga lalu lintas klien S3 selalu diproses dengan cara yang paling efisien,” kata Pindell. Tata Kelola di seluruh lingkungan terdistribusi Tantangannya semakin besar, ketika pipeline AI tersebar di beberapa lokasi, cloud, atau lingkungan edge. “Setelah saluran AI melintasi wilayah dan cloud, pertanyaannya tidak lagi mengenai kinerja dan menjadi tentang kontrol,” kata Smit. “Anda beroperasi di bawah peraturan yang berbeda-beda di setiap yurisdiksi, dan kedaulatan digital kini menjadi kendala desain. Di mana data Anda dibiarkan ada, siapa yang boleh menyentuhnya, dan negara mana yang tidak boleh dilintasi, kini akan membentuk arsitektur sebelum ada orang yang berbicara tentang kecepatan.” Arsitektur yang dijelaskan Smit menyelesaikan masalah ini dengan memisahkan aplikasi dari satu lokasi penyimpanan dan menempatkan titik kontrol terpadu di antara aplikasi-aplikasi tersebut yang menerapkan kebijakan yang konsisten di seluruh lokasi penyimpanan tersebut. “Kedaulatan, ketahanan, dan biaya tidak lagi menjadi trade-off jika Anda mengelola satu wilayah pada satu waktu,” jelasnya. “Mereka menjadi kemampuan yang Anda jalankan sebagai sebuah sistem.” Jalur penyimpanan-ke-komputasi sebagai titik kontrol terkelola Untuk mengatasi masalah ini, tim perusahaan harus berhenti memperlakukan jalur penyimpanan-ke-komputasi sebagai koneksi langsung dan mulai memperlakukannya sebagai titik kontrol terkelola, kata Smit. Validasi independen SecureIQLab terhadap F5 BIG-IP dalam penerapan penyimpanan telah mengonfirmasi bahwa pendekatan ini memberikan ketahanan tanpa mengorbankan throughput. “Masukkan ADC proxy penuh di antara keduanya, dan jalur menjadi dapat diamati, diprogram, dan sadar akan kegagalan, dengan perutean berbasis kesehatan, kualitas layanan, dan keamanan yang diterapkan secara inline,” jelasnya. “Satu langkah tersebut mengubah pengiriman data dari asumsi menjadi disiplin rekayasa, yang membuat GPU tetap dapat bekerja ketika kondisi menurun.” Artikel bersponsor adalah konten yang diproduksi oleh perusahaan yang membayar postingan tersebut atau memiliki hubungan bisnis dengan VentureBeat, dan artikel tersebut selalu ditandai dengan jelas. Untuk informasi lebih lanjut, hubungi sales@venturebeat.com.
Diterbitkan : 2026-06-11 15:34:00
sumber : venturebeat.com
