Apa itu Latency AI? Mengapa Waktu Respons Menentukan Nilai AI dalam Produksi

Seorang perwakilan penjualan meminta asisten AI mereka untuk merangkum akun sebelum panggilan. Jika jawabannya datang dalam 2 detik, mereka akan menggunakannya setiap saat. Jika butuh 18 detik, mereka berhenti menggunakannya dalam satu minggu. Fitur itu masih ada. AI masih bekerja. Tapi latency membunuh adopsi sebelum ada yang memperhatikan.

Bagi pemimpin bisnis yang menerapkan AI, latency bukan kemewahan teknis. Ini adalah perbedaan antara investasi AI yang mengubah perilaku dan yang ditinggalkan secara diam-diam. Memahami apa yang mendorongnya dan apa yang bisa Anda kendalikan adalah persyaratan praktis bagi siapa pun yang mensponsori penerapan AI.

Apa yang Dimaksud Latency dalam Sistem AI

Latency adalah waktu yang berlalu antara mengirim permintaan ke sistem AI dan menerima respons lengkap. Dalam bahasa sehari-hari: berapa lama?

Tapi angka tunggal ini menyembunyikan variasi penting. Engineer AI biasanya mengukur dua komponen terpisah:

Waktu ke token pertama (TTFT). Berapa lama sampai model mulai menghasilkan output. Untuk respons streaming (di mana teks muncul kata per kata), inilah yang dirasakan pengguna sebagai "seberapa cepat AI mulai merespons." TTFT yang tinggi terasa seolah-olah sistem membeku.

Waktu per token output (TPOT). Seberapa cepat model menghasilkan setiap token setelah yang pertama. Untuk respons panjang, ini menentukan total waktu yang berlalu. TTFT yang cepat tetapi TPOT yang lambat berarti AI mulai cepat tetapi kemudian merangkak melalui jawaban yang panjang.

Total waktu respons adalah jumlah keduanya. Untuk respons 500-token dengan TTFT 50ms dan 20ms per token, total waktunya adalah 10 detik. Untuk respons 50-token, adalah 1 detik.

Metrik yang relevan secara praktis bergantung pada kasus penggunaan. Untuk asisten percakapan, TTFT yang paling penting. Untuk pemroses dokumen batch yang berjalan semalam, total throughput lebih penting daripada kecepatan kueri mana pun.

Apa yang Mendorong Latency

Latency dalam sistem AI memiliki beberapa sumber yang berbeda. Mengetahui mana yang dominan dalam penerapan Anda menentukan di mana harus fokus.

Ukuran model. Model yang lebih besar (lebih banyak parameter) lebih lambat untuk dijalankan. Model kelas GPT-4 memiliki ratusan miliar parameter. Model kecil yang terspesialisasi mungkin memiliki 7 miliar. Model yang lebih kecil menjawab lebih cepat, terkadang 10-20x lebih cepat, tetapi dengan kemampuan yang lebih rendah. Ini adalah tradeoff inti dari optimisasi inference.

Hardware. Inference AI berjalan di GPU atau chip AI khusus (TPU, AWS Inferentia, dll.). Model yang sama pada GPU H100 kelas atas berjalan jauh lebih cepat daripada pada instance tingkat rendah. Penyedia cloud memberi peringkat ketersediaan GPU; penerapan yang lebih kecil sering mendapatkan hardware yang lebih lama.

Kuantisasi dan presisi. Model dapat dijalankan dengan presisi numerik yang lebih rendah (misalnya INT8 bukan FP16) untuk mengurangi kebutuhan memori dan komputasi. Kuantisasi yang diimplementasikan dengan baik dapat memotong latency 2-4x dengan dampak kualitas yang moderat untuk banyak tugas.

Jarak jaringan. Jika aplikasi Anda berada di Eropa dan endpoint inference penyedia AI Anda berada di wilayah US East, Anda menambahkan 80-150ms latency jaringan pulang-pergi sebelum model bahkan mulai "berpikir." Untuk aplikasi real-time, pemilihan wilayah penting.

Panjang konteks. Model Transformer menskalakan secara kuadratik dengan panjang jendela konteks dalam komputasi perhatiannya. Mengirim konteks 100.000-token jauh lebih lambat daripada konteks 1.000-token. Aplikasi konteks panjang (analisis dokumen, tinjauan kode dari codebase besar) membayar biaya latency yang signifikan.

Batching dan kedalaman antrian. Endpoint inference cloud melayani banyak pengguna secara bersamaan. Ketika permintaan meningkat, permintaan menunggu dalam antrian. Tunggu antrian ini adalah latency yang tidak terlihat dari perspektif pengguna tetapi dapat menambahkan detik ke waktu respons di bawah beban.

Langkah retrieval. Sistem retrieval-augmented generation menambahkan langkah pencarian sebelum inference model. Pencarian vektor yang dioptimalkan dengan baik memakan waktu 50-200ms. Yang dioptimalkan dengan buruk dapat memakan waktu 2-5 detik, mendominasi total latency.

Mengapa Ini Lebih Penting daripada Kebanyakan Metrik

Penelitian tentang pengalaman pengguna dan adopsi AI menunjukkan pola yang konsisten: ambang waktu respons menentukan apakah fitur menjadi kebiasaan atau titik gesekan.

Untuk kasus penggunaan interaktif (asisten, copilot, pencarian), respons di bawah 2 detik terasa instan. 2-5 detik dapat dirasakan tetapi dapat diterima. Di atas 5 detik, pengguna melepaskan diri, berhenti menunggu, atau mencari solusi alternatif. Di atas 10 detik untuk kueri rutin, tingkat adopsi turun tajam dan sering tidak pulih bahkan ketika sistem membaik.

Ini menciptakan masalah yang semakin parah untuk AI perusahaan. Sistem yang lambat saat peluncuran melatih pengguna untuk mengharapkan kelambatan dan mengembangkan perilaku mengatasi (mengabaikan fitur, bekerja di sekitarnya). Bahkan ketika latency membaik, perubahan perilaku sudah terjadi.

Implikasi bisnis: ambang latency harus didefinisikan sebagai kriteria penerimaan sebelum penerapan, bukan diukur setelah peluncuran sebagai renungan.

Alternatif Edge AI

Satu respons arsitektural terhadap latency inference cloud adalah memindahkan model lebih dekat ke pengguna, secara harfiah. Edge AI menjalankan model yang lebih kecil dan dioptimalkan pada perangkat lokal atau hardware on-premises, menghilangkan latency jaringan sepenuhnya.

Untuk kasus penggunaan di mana privasi data penting (medis, hukum, keuangan), penerapan edge juga menghilangkan data yang meninggalkan kendali organisasi. Tradeoffnya adalah model edge biasanya lebih kecil dan kurang mampu daripada model frontier yang dihosting di cloud.

Kerangka keputusan cukup sederhana: jika kasus penggunaan Anda memerlukan respons hampir real-time (antarmuka suara, pemindaian dokumen real-time, alat penjualan lapangan dengan konektivitas tidak andal), penerapan edge layak dievaluasi. Jika kasus penggunaan Anda toleran terhadap beberapa detik (analisis asinkron, batch semalaman, pengayaan latar belakang), inference cloud dengan model frontier biasanya merupakan pilihan yang tepat.

Apa yang Dapat Dipengaruhi Pemimpin Bisnis

Tim teknis mengelola sebagian besar keputusan optimisasi latency, tetapi pemimpin bisnis mengontrol beberapa faktor yang menentukan selubung latency operasional.

Desain kasus penggunaan. Alur kerja asinkron (menyiapkan ringkasan sebelum pertemuan, bukan selama) mengubah latency 15 detik dari masalah menjadi bukan masalah. Desain produk yang baik sering menghilangkan latency sebagai kendala dengan menggeser kapan komputasi terjadi.

Tradeoff pemilihan model. Memilih antara model frontier dan model yang lebih kecil yang terspesialisasi sering merupakan keputusan bisnis dengan dimensi latency. Model yang lebih kecil yang disesuaikan untuk tugas spesifik Anda mungkin lebih cepat dan lebih murah sambil memenuhi persyaratan kualitas. Ini memerlukan model monitoring untuk memvalidasi kualitas sebelum menerapkan alternatif yang lebih kecil.

Definisi SLA. Mendefinisikan SLA latency yang eksplisit (misalnya, "respons persentil ke-95 di bawah 3 detik") memberikan tim teknik target yang konkret dan menciptakan infrastruktur pengukuran untuk mendeteksi degradasi sebelum pengguna melakukannya.

Anggaran infrastruktur. Tier GPU premium membutuhkan biaya lebih. Endpoint inference biaya rendah lebih lambat. Tradeoff ini biasanya layak dibuat eksplisit daripada membiarkannya sebagai default yang tidak terlihat.

Fakta Penting

• Latency AI memiliki dua komponen: waktu ke token pertama (responsivitas yang dirasakan pengguna) dan total waktu respons (relevan untuk output panjang).
• Pendorong utamanya adalah ukuran model, tier hardware, kuantisasi, jarak jaringan, panjang konteks, dan kedalaman antrian di bawah beban.
• Adopsi pengguna biasanya turun di atas 5 detik untuk kasus penggunaan interaktif, dan sering tidak pulih bahkan ketika latency kemudian membaik.
• Pilihan arsitektural (alur kerja asinkron, penerapan edge, pemilihan model) dapat menghilangkan atau membingkai ulang kendala latency daripada hanya mengoptimalkannya.
• SLA latency harus didefinisikan sebelum penerapan, bukan diukur setelah peluncuran.