Offload dan Tiering Cache KV untuk Penyajian LLM dengan Konteks Panjang

Penyajian dengan konteks panjang pada akhirnya mengubah memori GPU menjadi masalah penjadwalan. Sebuah permintaan mungkin menyelesaikan giliran pertamanya tetapi meninggalkan state KV yang mahal untuk dihitung ulang dan tidak diperlukan di GPU saat ini. KV cache offload adalah teknik untuk memindahkan blok cache yang dapat digunakan kembali dari tier GPU yang cepat ke tier yang lebih besar dan lebih lambat—biasanya RAM host terlebih dahulu—lalu mempromosikannya kembali hanya ketika permintaan berikutnya dapat menggunakannya kembali.

Tujuannya bukan membuat penyimpanan lambat terlihat seperti HBM. Tujuannya adalah mencadangkan kapasitas KV GPU yang mahal untuk set kerja aktif sambil menjaga prefix bernilai tinggi tetap tersedia di tempat lain. Hal ini membuat KV cache offload paling berguna ketika trafik Anda memiliki konteks panjang dan penggunaan ulang yang bermakna: prompt sistem berulang, kerangka RAG, sesi multi-giliran, atau prefix dokumen berulang.

Panduan ini menunjukkan cara memutuskan apakah tiering sesuai, bagaimana kontrol vLLM saat ini saling terkait, apa yang diekspos TensorRT-LLM untuk offload memori host, dan cara menguji perubahan tanpa menukar kegagalan kehabisan memori GPU dengan insiden latensi ekor.

Jawaban singkat

Gunakan KV cache offload sebagai perluasan terkontrol dari penggunaan ulang prefix—bukan sebagai solusi memori bawaan.

Batasan pentingnya adalah lokalitas. Ketika blok yang di-offload digunakan kembali, blok tersebut harus kembali ke memori GPU sebelum attention menggunakannya. Jalur transfer itu merupakan bagian dari anggaran latensi permintaan.

Apa yang sebenarnya disimpan oleh tier cache KV

Selama generasi autoregresif, layer attention menghasilkan tensor key dan value untuk token yang telah diproses. Mempertahankan tensor tersebut memungkinkan server menghindari penghitungan ulang prefix yang sudah terlihat pada langkah decoding berikutnya atau pada penggunaan ulang prefix yang kompatibel. Dalam TensorRT-LLM, cache KV direpresentasikan sebagai pool blok yang menyimpan state untuk jumlah token tetap; dokumentasinya juga menjelaskan penggunaan ulang antarpermintaan, retensi yang diprioritaskan, dan offload memori host. Sistem Cache KV TensorRT-LLM

Stack penyajian praktis biasanya memiliki tiga kemungkinan temperatur penyimpanan:

Panduan offloading vLLM secara eksplisit menyatakan urutannya: desain multi-tier-nya menggunakan CPU sebagai tier utama, dan transfer antara GPU serta tier sekunder dilakukan secara bertahap melalui tier CPU tersebut. Dengan kata lain, hit pada tier dingin bukan pembacaan GPU langsung. Panduan Penggunaan KV Offloading vLLM

              promosi pada cache hit yang dapat digunakan
Permintaan ──> GPU HBM  <──────────────────── CPU DRAM
              │                                ▲
              │ keluarkan yang selesai,        │ tahap
              │ dapat digunakan kembali        │
              ▼                                │
          cache GPU aktif  ─────────────> penyimpanan sekunder
                 panas                    hangat / dingin

diagram vllm kv cache offload ini sengaja dibuat sederhana: hanya tier GPU yang seharusnya selalu berada pada jalur komputasi kritis. Tier CPU dan penyimpanan seharusnya melayani kebijakan penggunaan ulang yang terukur.

KV cache offload bukan offload bobot model

Pembedaan ini mencegah salah konfigurasi yang ternyata cukup umum:

• KV cache offload memindahkan state attention yang dibuat oleh permintaan. Ini terutama mengubah memori yang tersedia untuk konteks aktif dan jalur penggunaan ulang.
• Model-weight offload memindahkan parameter model. Dalam vLLM, kontrol --cpu-offload-gb didokumentasikan dalam offloading bobot model dan dapat menambahkan pekerjaan transfer CPU–GPU pada setiap forward pass model. argumen serve vLLM

Jangan menganggap bahwa pengaturan yang memungkinkan model dimuat juga menciptakan lebih banyak kapasitas KV yang dapat digunakan. Pisahkan terlebih dahulu anggaran bobot model, workspace runtime, dan anggaran cache KV; kemudian putuskan apakah blok KV tidak aktif layak dipertahankan di luar memori GPU.

KV cache offload vLLM: mulai dengan jalur CPU native

Untuk CLI vLLM saat ini, flag offload cache KV vLLM yang relevan adalah --kv-offloading-size. Referensi CLI resmi menyatakan bahwa ini adalah ukuran buffer offload KV dalam GiB; ketika paralelisme tensor lebih besar dari satu, ukurannya adalah total di seluruh peringkat paralel-tensor. Offloading dinonaktifkan ketika tidak diatur. Pendamping --kv-offloading-backend mendukung backend CPU native dan LMCache. argumen serve vLLM

Gunakan pilot terbatas alih-alih menentukan ukuran tier host hingga seluruh RAM yang tersedia:

vllm serve <your-model> \
  --gpu-memory-utilization 0.85 \
  --kv-offloading-size 16 \
  --kv-offloading-backend native

Contoh tersebut adalah bentuk eksperimen, bukan pengaturan universal. Nilai yang tepat bergantung pada tata letak cache model, panjang konteks, konfigurasi paralel-tensor, ruang cadangan RAM host, campuran permintaan, dan sasaran latensi. Tetapkan versi image vLLM dan jalankan vllm serve --help dalam image tersebut sebelum menerapkan flag ke produksi; konfigurasi penyajian berkembang dengan cepat.

Jalur native cocok untuk uji coba awal offload CPU cache KV vLLM karena menjaga pertanyaan tiering tetap sempit: dapatkah tier hangat CPU mempertahankan cukup banyak blok berguna untuk meningkatkan penerimaan atau menghindari churn cache GPU tanpa memperburuk perilaku p95 dan p99?

Pilih penerimaan cache sebelum kapasitas cache

Lebih banyak blok yang dipertahankan belum tentu berarti lebih banyak blok yang berguna. Sebelum meningkatkan buffer offload, jawablah empat pertanyaan:

1. Prefiks mana yang dibagikan di antara permintaan?
2. Berapa lama setelah dibuat prefiks tersebut digunakan kembali?
3. Seberapa besar blok yang berguna dibandingkan dengan anggaran transfer host Anda?
4. Blok mana yang harus langsung dikeluarkan karena kemungkinan penggunaannya kembali terlalu rendah?

Jika beban kerja tidak dapat menjawab dua pertanyaan pertama dari trace, mulailah dengan mengukur penggunaan kembali prefiks di GPU. Tier CPU dapat mempertahankan status cache hangat; tier tersebut tidak dapat menciptakan penggunaan kembali untuk prompt yang sepenuhnya unik.

Bangun jalur tiering vLLM hanya setelah pilot CPU

OffloadingConnector vLLM adalah jalur menuju tier utama CPU ditambah tier sekunder opsional. Panduan resmi menjelaskan CPUOffloadingSpec untuk satu tier CPU dan TieringOffloadingSpec untuk tier utama CPU dengan satu atau beberapa tier sekunder. Panduan tersebut juga mendokumentasikan LRU dan ARC sebagai opsi kebijakan pengeluaran bawaan. Panduan Penggunaan Offloading KV vLLM

Berikut adalah bentuk konfigurasi yang setia dari contoh multi-tier terdokumentasi. Ganti model, path, ukuran blok, byte, dan jumlah thread hanya setelah mengujinya pada host Anda sendiri:

vllm serve <your-model> \
  --kv-transfer-config '{
    "kv_connector": "OffloadingConnector",
    "kv_role": "kv_both",
    "kv_connector_extra_config": {
      "spec_name": "TieringOffloadingSpec",
      "cpu_bytes_to_use": 10737418240,
      "block_size": 16,
      "eviction_policy": "lru",
      "secondary_tiers": [
        {
          "type": "fs",
          "root_dir": "/mnt/kv_cache",
          "n_read_threads": 32,
          "n_write_threads": 16
        }
      ]
    }
  }'

Tiga detail operasional lebih penting daripada sekadar menyalin cuplikan:

1. cpu_bytes_to_use adalah reservasi total tier CPU di seluruh worker, bukan saran yang samar untuk sistem operasi. Anggarkan untuk proses, OS, page cache penyimpanan, dan layanan apa pun yang ditempatkan bersama.
2. Ukuran blok atau chunk yang dikonfigurasi menetapkan unit I/O. Chunk yang sangat kecil dapat meningkatkan overhead metadata dan penjadwalan; chunk yang sangat besar dapat mempromosikan byte yang tidak diperlukan oleh permintaan. Uji keduanya dengan panjang prefiks nyata.
3. Tier sekunder berada setelah CPU. Jika tier CPU terlalu kecil atau jenuh, menambahkan kapasitas sistem berkas dapat menyimpan lebih banyak data tanpa meningkatkan latensi hit berikutnya.

Oleh karena itu, tujuan offload cache KV vLLM bukanlah “menyimpan semuanya.” Tujuannya adalah “menyimpan blok dengan jalur penggunaan kembali yang masuk akal dan tepat waktu.”

Offload cache KV TensorRT-LLM ke memori host

TensorRT-LLM mengekspos gagasan dasar yang sama melalui konfigurasi cache KV-nya. Dokumentasinya menyatakan bahwa host_cache_size mengalokasikan memori host untuk offloading, secara default bernilai nol, dan memungkinkan blok tetap dapat digunakan kembali hingga kemudian dikeluarkan dari memori host. Saat digunakan kembali, blok disalin kembali ke memori GPU. Sistem Cache KV TensorRT-LLM

Untuk penerapan offload cache KV TensorRT-LLM ke memori host, perhatikan kebijakan retensi serta kapasitas:

TensorRT-LLM mendokumentasikan nilai default secondary_offload_min_priority sebesar 35 pada saat artikel ini ditulis. Perlakukan nilai tersebut sebagai default yang bergantung pada versi, bukan rekomendasi kebijakan: ambang batas harus mencerminkan nilai penggunaan ulang yang teramati dan biaya transfer untuk layanan Anda.

Metode penerapan yang melindungi latensi

Jangan aktifkan tier dingin saat terjadi insiden kapasitas lalu menyatakan sukses ketika OOM berhenti. Sebagai gantinya, jalankan urutan yang terkontrol:

1. Ambil baseline khusus GPU. Catat distribusi panjang konteks, konkurensi, waktu hingga token pertama, latensi antar-token, p50/p95/p99 ujung ke ujung, tingkat penggunaan ulang prefix, dan perilaku eviksi KV GPU.
2. Cadangkan headroom host yang nyata. Sertakan overhead runtime dan sistem operasi; jangan menentukan ukuran cache CPU hanya berdasarkan snapshot memori bebas.
3. Aktifkan tier CPU kecil. Pertahankan model, kebijakan batch, bentuk trafik, dan peringatan SLO tetap stabil saat Anda mengubah satu dimensi cache.
4. Bandingkan kualitas hit, bukan hanya jumlah hit. Pisahkan hit GPU, promosi CPU, promosi tier dingin, dan miss yang memicu komputasi ulang.
5. Periksa latensi ekor saat terjadi kontensi. Jalankan permintaan panjang/pendek campuran dan peningkatan konkurensi bertahap. Hasil yang hanya melihat rata-rata menyembunyikan antrean transfer.
6. Tambahkan tier sekunder hanya jika nilai retensi membenarkannya. Uji kehilangan cache, tekanan penyimpanan, perilaku restart, dan lonjakan promosi sebelum menerapkannya secara luas.
7. Tetapkan aturan rollback. Contohnya: nonaktifkan tier terbaru ketika waktu p99 hingga token pertama atau latensi antar-token melampaui anggaran yang disepakati selama jangka waktu berkelanjutan.

Panduan vLLM mendokumentasikan metrik konfigurasi dan offload, termasuk informasi konfigurasi serta sinyal penggunaan cache CPU. Gunakan metrik tersebut bersama trace aplikasi; metrik cache tanpa latensi tingkat permintaan menyulitkan pembedaan antara promosi yang bernilai dan transfer thrash. Panduan Penggunaan KV Offloading vLLM

Mode kegagalan yang perlu dicegah melalui desain

Ketika offload cache KV merupakan optimasi yang keliru

Untuk saat ini, lewati offload cache KV ketika:

• Memori GPU bukan faktor pembatas.
• Hampir semua prompt bersifat unik, sehingga prefix yang dipertahankan tidak digunakan kembali.
• SLO utama Anda adalah latensi ekor yang sangat rendah dan jalur transfer tidak dapat dibuktikan sesuai dengan batas tersebut.
• DRAM host atau penyimpanan sudah menjadi sumber daya produksi yang diperebutkan.
• Caching prefix, batching, batas konteks, pemilihan model, atau kuantisasi cache belum dievaluasi.

Dalam kasus tersebut, langkah awal yang lebih tepat mungkin adalah peninjauan anggaran memori GPU, kebijakan konteks yang berbeda, atau perubahan arsitektur penyajian. Untuk pilihan topologi dan paralelisme, lihat Inferensi Multi-GPU vLLM, vLLM vs SGLang, dan TensorRT-LLM vs vLLM.

FAQ

Apakah offload cache KV mengurangi penggunaan memori GPU?

Offload dapat mengurangi tekanan dari blok KV tidak aktif yang dapat digunakan ulang dengan memindahkannya keluar dari tier GPU. Offload tidak menghilangkan kebutuhan akan cache yang berada di GPU untuk pekerjaan attention aktif, dan blok yang telah dioffload serta digunakan ulang harus dipromosikan kembali sebelum digunakan.

Apa flag offload cache KV vLLM?

Dalam dokumentasi CLI vLLM saat ini, --kv-offloading-size mengaktifkan buffer offload KV ketika ditetapkan, sedangkan --kv-offloading-backend memilih backend. Verifikasi flag yang tepat pada rilis vLLM yang Anda pin. argumen serve vLLM

Apakah tier filesystem merupakan cache GPU langsung?

Tidak. vLLM mendokumentasikan CPU sebagai tier utama untuk implementasi multi-tier-nya; transfer antara GPU dan tier sekunder dilakukan secara bertahap melalui memori CPU. Itulah sebabnya pengujian tier sekunder harus mencakup seluruh jalur promosi.

Apakah offload cache KV lebih baik daripada membeli GPU yang lebih besar?

Keduanya menyelesaikan batasan yang berbeda. GPU yang lebih besar dapat meningkatkan working set panas tanpa overhead promosi. Offload dapat mempertahankan state hangat atau dingin yang berguna dengan kapasitas GPU yang ada. Bandingkan keduanya berdasarkan penggunaan ulang terukur dari workload, SLO latensi, beban operasional, dan total biaya penyajian.

Kesimpulan: perlakukan offload cache KV sebagai kebijakan cache, bukan trik kapasitas

Desain offload cache KV yang paling kuat mempertahankan status aktif di GPU, mencadangkan memori CPU untuk penggunaan ulang hangat yang didukung bukti, dan menambahkan tier dingin hanya ketika retensi tetap bernilai setelah biaya transfer dan penanganan kegagalan diukur. Mulailah dengan pilot CPU yang dibatasi, instrumentasikan promosi dan latensi berdasarkan tier, dan promosikan hanya kebijakan yang meningkatkan SLO produksi—bukan sekadar jumlah cache yang dipertahankan.

Jika biaya operasional dari stack penyajian yang di-host sendiri lebih besar daripada kontrol yang dibutuhkan beban kerja Anda, bandingkan penerapan cloud GPU dengan API model atau jelajahi Flatkey Compute sebelum berkomitmen pada armada yang lebih besar.

Sumber

• vLLM: Panduan Penggunaan KV Offloading
• vLLM: Argumen Serve
• NVIDIA TensorRT-LLM: Sistem Cache KV