Pengarahan Cache KV: Kurangi Pekerjaan Prefill LLM yang Redundan

Routing cache KV menjadi penting ketika prefix prompt yang berulang terus muncul di lalu lintas LLM Anda. Jika permintaan yang tepat mendarat di replika yang tepat, mesin penyajian dapat menggunakan kembali status perhatian yang di-cache daripada menghitung ulang token prefill yang sama berulang kali.

Itu terdengar seperti detail infrastruktur, tetapi dengan cepat menjadi masalah produk. Prompt sistem yang panjang, konteks RAG, contoh few-shot, dan riwayat obrolan multi-putaran dapat membuat pekerjaan prefill menjadi mahal. Ketika setiap replika menghitung ulang prefix yang sama, tim membayar dalam bentuk latensi, waktu GPU, dan perencanaan kapasitas.

ShareAI memberikan satu API kepada pengembang untuk 150+ model, visibilitas marketplace, routing, dan failover. Routing cache KV berada satu lapisan lebih rendah, di dalam infrastruktur penyajian model. Kesimpulan yang berguna bagi pembaca ShareAI sederhana: keputusan routing penting di setiap lapisan tumpukan AI, dari pilihan model hingga replika GPU mana yang menangani prompt yang berulang.

Mengapa Routing Cache KV Penting

Selama inferensi LLM, sebuah model pertama-tama memproses prompt input dalam fase prefill. Model membangun cache key-value, biasanya disebut cache KV, sehingga token yang dihasilkan kemudian dapat merujuk kembali ke konteks yang sudah diproses.

Cache prefix memungkinkan mesin penyajian menggunakan kembali cache tersebut ketika permintaan berikutnya memiliki awal prompt yang sama. Dokumentasi cache prefix otomatis vLLM menggambarkan ini sebagai penggunaan kembali cache KV untuk prefix yang sama sehingga permintaan baru dapat melewati perhitungan untuk bagian yang sama. Cache prefix SGLang menggunakan ide terkait untuk berbagi cache KV untuk urutan token yang umum.

Ini sangat penting untuk beban kerja di mana banyak permintaan dimulai dengan cara yang sama: agen dukungan dengan prompt sistem besar, aplikasi RAG yang menggunakan potongan dokumentasi berulang, agen pengkodean dengan instruksi repositori, atau produk obrolan yang membawa riwayat percakapan antar putaran.

Di Mana Round-Robin Gagal

Cache prefix paling mudah pada satu replika. Proses yang sama melihat prefix yang berulang dan dapat menggunakan kembali cache-nya jika memori tersedia. Masalah muncul ketika layanan skalanya horizontal.

Dengan load balancer round-robin standar, permintaan pertama mungkin memanaskan cache di replika A, sementara permintaan kedua dengan prefix yang sama mendarat di replika B. Replika B tidak memiliki status yang di-cache itu, sehingga menghitung ulang pekerjaan prefill yang sama. Permintaan ketiga mungkin pergi ke replika C dan kembali gagal.

Saat jumlah replika bertambah, load balancing yang naif dapat menyebarkan permintaan terkait ke lebih banyak mesin. Armada penyajian model mungkin terlihat seimbang, tetapi tingkat hit cache prefix menurun. Itulah celah yang coba ditutup oleh routing cache KV.

Tiga Tingkatan Routing Praktis

1. Affinitas Sesi

Affinitas sesi mengarahkan lalu lintas dari pengguna, ruang kerja, penyewa, atau percakapan yang sama ke replika yang sama. Ini adalah tempat paling sederhana untuk memulai percakapan multi-putaran karena prompt lanjutan sering kali berbagi konteks sebelumnya.

Konsekuensinya adalah identitas pengguna tidak selalu sama dengan kesamaan prompt. Dua pengguna mungkin berbagi prompt sistem panjang yang sama dan tetap diarahkan ke replika yang berbeda. Affinitas sesi juga dapat terganggu ketika replika ditambahkan atau dihapus.

2. Routing Hash-Prefix

Routing hash-prefix menggunakan prompt itu sendiri sebagai kunci routing. Router membuat hash dari awal yang stabil dari prompt dan mengirimkan prefix yang cocok ke replika yang sama.

Ini bekerja lebih baik ketika prompt sistem yang berulang, contoh few-shot, atau konteks yang diambil bersama lebih penting daripada identitas pengguna. Bagian sulitnya adalah memilih batas prefix. Jika hash mencakup timestamp, ID permintaan, atau bidang spesifik pengguna, kunci routing terfragmentasi dan penggunaan ulang cache menjadi rusak.

3. Routing Sadar-Event Cache

Pendekatan paling canggih melacak blok cache mana yang berada di replika mana, lalu mengarahkan setiap permintaan ke replika dengan tumpang tindih cache terbaik sambil tetap mempertimbangkan beban. Proyek router llm-d menjelaskan pemilih endpoint yang mempertimbangkan lokalitas KV-cache, beban saat ini, dan prioritas saat memilih ke mana permintaan harus pergi.

Ini lebih kompleks, tetapi ini adalah arah yang tepat untuk armada throughput tinggi di mana cache miss diukur, mahal, dan sering terjadi.

Kapan Harus Melewatkannya

Routing cache KV tidak secara otomatis sepadan dengan kompleksitasnya. Ini kurang cocok ketika prompt pendek, sebagian besar unik, atau diproses dalam batch dengan sedikit struktur yang berulang.

Ringkasan dokumen, pembuatan kreatif, ekstraksi satu kali, dan banyak pekerjaan batch asinkron mungkin tidak memiliki cukup tumpang tindih prefix bersama untuk membenarkan routing yang sadar cache. Dalam kasus tersebut, penyeimbangan beban biasa mungkin lebih sederhana.

Uji praktis adalah pengukuran: tingkat cache hit, waktu ke token pertama, throughput, kedalaman antrean, tekanan memori GPU, dan biaya per tugas yang diselesaikan. Jika routing yang sadar cache tidak mengubah angka-angka tersebut, perbaiki struktur prompt terlebih dahulu.

Bagaimana Ini Sesuai Dengan ShareAI

ShareAI adalah pasar AI dan API, bukan penyeimbang beban model-servis di dalam kluster GPU Anda. Pengembang menggunakan ShareAI untuk mengakses banyak model melalui satu API, membandingkan sinyal pasar, merutekan permintaan, mengelola penggunaan, dan mengalihkan rute ketika rute memburuk.

Itu tetap membuat routing cache KV relevan. Jika Anda mengoperasikan tumpukan inferensi Anda sendiri, ini membantu Anda mengajukan pertanyaan infrastruktur yang lebih baik. Jika Anda menggunakan model yang dihosting, ini membantu Anda mengevaluasi mengapa dua rute dengan nama model serupa dapat berperilaku berbeda di bawah beban kerja nyata.

Bagi Pembuat, ini juga terhubung dengan penetapan harga. Aplikasi dengan prompt panjang, konteks RAG berulang, atau loop agen dapat menciptakan penggunaan AI yang sangat tidak merata. ShareAI Builder memungkinkan pemilik aplikasi merutekan lalu lintas inferensi AI melalui ShareAI, menetapkan margin atau biaya tambahan, membuat pelanggan membayar ShareAI untuk penggunaan yang dirutekan, dan menerima pembayaran bulanan berdasarkan penggunaan yang dihasilkan. Aplikasi itu sendiri tetap dibangun di luar ShareAI.

Untuk pemilihan model dan evaluasi rute, mulai dengan Marketplace model ShareAI. Untuk dasar-dasar implementasi, gunakan Referensi API ShareAI.

Daftar Periksa Routing Cache KV

• Letakkan konten prompt yang stabil terlebih dahulu: prompt sistem, aturan alat, contoh, dan konteks berulang.
• Pindahkan bidang dinamis belakangan: stempel waktu, ID permintaan, fakta spesifik pengguna, dan instruksi satu kali.
• Ukur tingkat cache hit sebelum dan setelah perubahan routing.
• Perhatikan waktu ke token pertama, throughput, kedalaman antrean, dan tekanan VRAM secara bersamaan.
• Mulailah dengan routing hash-prefiks sebelum membangun routing yang sadar peristiwa cache.
• Pisahkan aturan routing berdasarkan beban kerja daripada memaksakan satu kebijakan global.
• Jaga biaya dan latensi tetap terlihat di tingkat aplikasi, bukan hanya di dalam kluster inferensi.

FAQ

Apa itu pengaturan rute cache KV?

Pengaturan rute cache KV adalah strategi pengaturan rute yang mengirimkan permintaan dengan awalan prompt yang berulang ke replika yang kemungkinan besar sudah memiliki cache KV yang sesuai. Tujuannya adalah untuk mengurangi perhitungan prefill yang redundan.

Bagaimana pengaturan rute cache KV berbeda dari caching awalan?

Caching awalan adalah kemampuan mesin penyajian model untuk menggunakan kembali status cache untuk awalan prompt yang sama. Pengaturan rute cache KV adalah strategi penempatan lalu lintas yang membantu permintaan yang sesuai mendarat di tempat status cache tersebut sudah ada.

Mengapa pengaturan rute round-robin merugikan caching awalan?

Pengaturan rute round-robin menyebarkan permintaan ke replika tanpa mengetahui replika mana yang memiliki awalan cache tertentu. Prompt yang berulang mungkin tidak menggunakan cache hanya karena mendarat di replika yang berbeda.

Beban kerja mana yang paling diuntungkan dari pengaturan rute cache KV?

Obrolan multi-putaran, RAG, agen pengkodean, agen dukungan, prompt few-shot, dan aplikasi dengan prompt sistem panjang yang sama adalah kandidat terkuat karena mereka menggunakan kembali awalan prompt yang substansial.

Kapan tim harus melewatkan pengaturan rute cache KV?

Lewati jika prompt pendek, sebagian besar unik, atau berorientasi batch dengan sedikit struktur yang berulang. Dalam kasus tersebut, kompleksitas pengaturan rute mungkin memberikan sedikit nilai.

Apakah vLLM dan SGLang mendukung caching awalan?

Ya. Dokumentasi vLLM mencakup caching awalan otomatis, dan dokumentasi SGLang mencakup caching awalan untuk cache KV bersama di antara urutan token umum. Mesin penyajian masih membutuhkan bantuan pengaturan rute ketika beberapa replika terlibat.

Apakah pengaturan rute cache KV sama dengan caching semantik?

Tidak. Pengaturan rute cache KV bekerja dengan penggunaan ulang awalan struktural yang sama atau hampir sama di dalam penyajian inferensi. Caching semantik menyimpan dan menggunakan kembali respons atau hasil antara berdasarkan makna, biasanya dengan embedding atau ambang kesamaan.

Apakah ShareAI menggantikan load balancer yang sadar cache KV?

Tidak. ShareAI adalah pasar AI dan lapisan API untuk akses model, perutean, failover, penggunaan, dan penagihan. Perutean yang sadar KV-cache adalah infrastruktur penyajian model tingkat rendah untuk tim yang mengoperasikan replika inferensi.

Bagaimana seharusnya para Pembuat memikirkan perutean cache KV?

Para Pembuat harus memperlakukan perilaku cache sebagai salah satu penggerak biaya dalam aplikasi yang berat AI. Jika aplikasi mereka memiliki penggunaan yang tidak merata, ShareAI dapat membantu merutekan dan memonetisasi lalu lintas AI tersebut sementara aplikasi tetap dibangun dan dimiliki di luar ShareAI.

Apa yang harus diukur oleh tim sebelum mengubah perutean?

Ukur tingkat hit cache, waktu untuk token pertama, throughput, kedalaman antrean, tekanan VRAM, biaya per tugas, dan kualitas output. Perubahan perutean harus meningkatkan beban kerja, bukan hanya dasbor.

Bisakah perutean cache KV mengurangi biaya API AI?

Ini dapat mengurangi biaya infrastruktur untuk tim yang menyajikan model sendiri karena pekerjaan prefill yang kurang redundan dapat meningkatkan efisiensi GPU. Untuk API yang dihosting, efeknya tergantung pada apakah penyedia mengekspos penghematan tersebut dalam harga atau kinerja.