Halaman ini diterjemahkan oleh Cloud Translation API.

Ringkasan praktik terbaik inferensi di GKE

Autopilot Standard

Dokumen ini memberikan ringkasan umum tentang praktik terbaik untuk menjalankan workload inferensi di GKE.

Dokumen ini ditujukan bagi Administrator Data, Operator, dan Developer yang ingin menerapkan praktik terbaik untuk workload inferensi mereka menggunakan akselerator, seperti GPU dan TPU, dengan Kubernetes dan GKE. Untuk mempelajari peran umum lebih lanjut, lihat Peran dan tugas pengguna GKE umum.

Menyiapkan penayangan inferensi di GKE

Bagian ini menjelaskan praktik terbaik dasar yang harus Anda ikuti saat Anda bersiap untuk men-deploy workload inferensi. Praktik ini mencakup menganalisis kasus penggunaan, memilih model, dan memilih akselerator.

Menganalisis karakteristik kasus penggunaan inferensi Anda

Sebelum men-deploy beban kerja inferensi, analisis persyaratan spesifiknya. Analisis ini membantu Anda membuat keputusan arsitektur yang menyeimbangkan performa, biaya, dan keandalan. Memahami kasus penggunaan akan membantu Anda memilih model, akselerator, dan konfigurasi yang sesuai untuk memenuhi tujuan tingkat layanan (SLO) Anda.

Untuk memandu analisis Anda, evaluasi dimensi utama workload berikut:

Tentukan persyaratan performa dan latensi: tentukan SLO aplikasi Anda untuk latensi dan throughput. Metrik utama yang perlu ditentukan mencakup permintaan per detik (RPS), latensi respons, panjang token input dan output, serta rasio hit cache awalan. Untuk mengetahui informasi selengkapnya, lihat Metrik performa inferensi.
Mengevaluasi persyaratan dan skala model: karakteristik model yang Anda pilih secara langsung memengaruhi kebutuhan infrastruktur Anda. Pertimbangkan panjang konteks maksimum yang didukung model dan bandingkan dengan yang diperlukan workload Anda. Jika kasus penggunaan Anda tidak memerlukan konteks maksimum, menurunkan panjang konteks maksimum dapat membebaskan memori akselerator untuk cache KV yang lebih besar, sehingga berpotensi meningkatkan throughput.
Menetapkan batasan biaya dan bisnis: anggaran dan tujuan bisnis Anda adalah faktor utama dalam merancang layanan inferensi yang berkelanjutan dan hemat biaya. Tentukan target biaya per juta token untuk input dan output serta total anggaran bulanan Anda untuk workload ini. Identifikasi sasaran pengoptimalan Anda, seperti performa harga, latensi terendah, atau throughput tertinggi, dan apakah aplikasi Anda dapat mentoleransi latensi variabel atau tidak.

Memilih model yang tepat untuk kasus penggunaan inferensi Anda

Memilih model yang tepat akan secara langsung memengaruhi performa, biaya, dan kelayakan aplikasi inferensi Anda. Untuk memilih model yang optimal, evaluasi kandidat berdasarkan kriteria berikut:

Penyelarasan tugas dan modalitas: mengevaluasi model berdasarkan tugas yang ditetapkan dan modalitas yang didukung. Model yang dioptimalkan untuk tugas tertentu hampir selalu mengungguli model yang lebih serbaguna.
Karakteristik teknis: arsitektur dan jenis data model, serta presisi—seperti FP16, FP8, dan FP4—adalah faktor utama dalam menentukan persyaratan resource dan performanya. Penilaian ini membantu Anda menentukan apakah Anda perlu menerapkan teknik kuantisasi. Periksa presisi yang didukung untuk bobot model, pastikan dukungan framework, dan verifikasi panjang konteks maksimum yang didukung model.
Performa dan efektivitas biaya: untuk membuat keputusan berbasis data, bandingkan model yang Anda pilih menggunakan tolok ukur yang tersedia secara publik dan pengujian internal Anda sendiri. Gunakan papan peringkat seperti Chatbot Arena untuk membandingkan model, dan evaluasi biaya per juta token untuk setiap model di hardware target Anda.

Menerapkan kuantisasi ke model

Kuantisasi adalah teknik untuk mengoptimalkan workload inferensi dengan mengurangi jejak memori model Anda. Alat ini mengonversi bobot, aktivasi, dan cache key-value (KV) model dari format floating point presisi tinggi (seperti FP16, FP32, dan FP64) ke format presisi rendah (seperti FP8 dan FP4). Pengurangan memori ini dapat menghasilkan peningkatan signifikan dalam performa dan efektivitas biaya.

Kuantisasi mengurangi jejak memori model, yang pada gilirannya mengurangi overhead transfer data dan mengosongkan memori untuk cache KV yang lebih besar.

Untuk menerapkan kuantisasi secara efektif pada model Anda, ikuti rekomendasi berikut:

Mengevaluasi pertukaran akurasi: kuantisasi terkadang dapat menyebabkan hilangnya akurasi model. Saat mengevaluasi pertukaran akurasi kuantisasi, pertimbangkan bahwa kuantisasi 8-bit sering kali menghasilkan kehilangan akurasi yang minimal. Sebaliknya, kuantisasi 4-bit dapat memberikan pengurangan persyaratan memori akselerator hingga empat kali lipat, tetapi juga dapat menyebabkan hilangnya akurasi yang lebih besar dibandingkan dengan kuantisasi 8-bit. Evaluasi performa model terkuantisasi pada kasus penggunaan spesifik Anda untuk memastikan akurasinya masih dalam rentang yang dapat diterima. Untuk mengevaluasi hilangnya akurasi, Anda dapat menggunakan alat seperti OpenCompass dan Language Model Evaluation Harness.
Mengevaluasi dukungan akselerasi hardware: untuk mendapatkan hasil maksimal dari kuantisasi, gunakan akselerator yang menyediakan akselerasi hardware untuk format data yang digunakan model terkuantisasi. Misalnya:
- GPU NVIDIA H100 menyediakan akselerasi hardware untuk operasi FP8 dan FP16.
- GPU NVIDIA B200 menyediakan akselerasi hardware untuk operasi FP4, FP8, dan FP16.
- Cloud TPU v5p menyediakan akselerasi hardware untuk operasi FP8.
Periksa model yang telah dikuantisasi: sebelum menguantisasi model sendiri, periksa repositori model publik seperti Hugging Face. Idealnya, temukan model yang secara native dilatih dengan presisi yang lebih rendah, karena hal ini dapat memberikan manfaat performa tanpa potensi hilangnya akurasi dari kuantisasi pasca-pelatihan.
Gunakan library kuantisasi: jika model yang telah dikuantisasi sebelumnya tidak tersedia, gunakan library untuk melakukan kuantisasi sendiri. Server inferensi seperti vLLM mendukung model yang telah dikuantisasi dengan berbagai teknik. Anda dapat menggunakan alat seperti llm-compressor untuk menerapkan teknik kuantisasi pada model yang tidak dikuantisasi.
Pertimbangkan kuantisasi cache KV: selain menguantisasi bobot model, Anda juga dapat menguantisasi cache KV. Teknik ini selanjutnya mengurangi memori yang diperlukan untuk cache KV saat runtime, yang dapat meningkatkan performa.

Untuk mengetahui informasi selengkapnya, lihat Mengoptimalkan workload inferensi LLM di GPU.

Memilih akselerator yang tepat

Memilih akselerator yang tepat secara langsung memengaruhi performa, biaya, dan pengalaman pengguna layanan inferensi Anda. Pilihan yang optimal bergantung pada analisis persyaratan memori model, sasaran performa, dan anggaran Anda.

Untuk memilih akselerator yang tepat untuk kasus penggunaan spesifik Anda, ikuti langkah-langkah berikut:

Hitung persyaratan memori Anda: pertama, hitung memori akselerator minimum yang diperlukan untuk memuat dan menjalankan model Anda. Total memori adalah jumlah memori yang diperlukan untuk bobot model, overhead mesin inferensi, aktivasi perantara, dan cache KV.

Untuk memperkirakan memori yang diperlukan, gunakan persamaan berikut:

\[ \begin{aligned} \text{Required accelerator memory} = {} & (\text{Model weights} + \text{Overhead} + \text{Activations}) \\ & + (\text{KV cache per batch} \times \text{Batch size}) \end{aligned} \]

Istilah dalam persamaan adalah sebagai berikut:
- Bobot model: ukuran parameter model.
- Overhead: buffer untuk server inferensi dan overhead sistem lainnya, biasanya 1-2 GB.
- Aktivasi: memori yang diperlukan untuk aktivasi perantara selama eksekusi model.
- Cache KV per batch: memori yang diperlukan untuk cache KV untuk satu urutan, yang diskalakan dengan panjang konteks dan konfigurasi model.
- Ukuran batch: jumlah urutan (max_num_sequences) yang akan diproses secara bersamaan oleh mesin inferensi.
Contoh: Menghitung persyaratan memori akselerator untuk Gemma 3

Untuk menghitung memori akselerator yang diperlukan untuk men-deploy model parameter 27 miliar Gemma 3 dengan presisi BF16 untuk kasus penggunaan pembuatan teks, Anda dapat menggunakan nilai berikut.

Untuk melihat panduan interaktif tentang penghitungan ini, lihat Berapa Banyak VRAM yang Dibutuhkan Model Saya? Notebook Colab.
- Input:
  - Bobot model: 54 GB
  - Ukuran batch (max_num_sequences): 1
  - Panjang input rata-rata: 1.500 token
  - Panjang output rata-rata: 200 token
  - Overhead mesin inferensi: 1 GB (perkiraan)
  - Ukuran jenis data cache KV: 2 (untuk BF16)
  - Vektor KV: 2 (satu untuk Kunci, satu untuk Nilai)
- Konfigurasi model untuk model yang di-tune untuk mengikuti perintah Gemma 3 27B:
  - hidden_size: 5376
  - intermediate_size: 21504
  - num_attention_heads: 32
  - num_hidden_layers: 62
  - num_key_value_heads: 16
- Penghitungan Memori:
  - sequence_length = avg_input_length + avg_output_length = 1.500 + 200 = 1.700 token
  - pytorch_activation_peak_memory = (max_num_sequences * sequence_length * (18 * hidden_size + 4 * intermediate_size)) / (1000^3) = ~0,31 GB (perkiraan).
  - head_dims = hidden_size / num_attention_heads = 5376 / 32 = 168
  - kv_cache_memory_per_batch = (kv_vectors * max_num_sequences * sequence_length * num_key_value_heads * head_dims * num_hidden_layers * kv_data_type_size) / (1000^3) = (2 * 1 * 1700 * 16 * 168 * 62 * 2) / (1000^3) = ~1,13 GB
  - Memori akselerator yang diperlukan = Model weights + Overhead + Activations + KV cache per batch = 54 + 1 + 0,31 + 1,13 = ~56,44 GB
Total perkiraan memori akselerator yang Anda perlukan untuk men-deploy model adalah sekitar 57 GB.

Mengevaluasi opsi akselerator: setelah memperkirakan persyaratan memori, evaluasi opsi GPU dan TPU yang tersedia di GKE.

Selain jumlah memori akselerator, pertimbangkan persyaratan model berikut untuk evaluasi Anda:

Untuk model yang memerlukan lebih dari satu akselerator, periksa dukungan untuk konektivitas berkecepatan tinggi, seperti NVLINK dan GPUDirect, untuk mengurangi latensi komunikasi.
Untuk model terkuantisasi, gunakan akselerator dengan akselerasi hardware native untuk jenis data presisi rendah, seperti FP8 dan FP4, untuk mendapatkan manfaat performa yang paling besar.

Pilihan Anda melibatkan kompromi antara fitur, performa, biaya, dan ketersediaan ini.

Akselerator yang direkomendasikan berdasarkan kasus penggunaan

Tips: Untuk rekomendasi akselerator terbaru berdasarkan tolok ukur performa penayangan dan analisis biaya, Anda juga dapat menggunakan alat Panduan Memulai Inferensi GKE. Untuk mengetahui detail selengkapnya, lihat dokumentasi Panduan Memulai Inferensi GKE.

Untuk membantu Anda memilih akselerator yang tepat untuk workload Anda, tabel berikut merangkum opsi yang paling sesuai untuk kasus penggunaan inferensi umum. Kasus penggunaan ini didefinisikan sebagai berikut:

Inferensi model kecil: untuk model dengan beberapa miliar parameter, dengan beban komputasi terbatas pada satu host.
Inferensi model besar host tunggal: untuk model dengan puluhan hingga ratusan miliar parameter, dengan beban komputasi dibagi di beberapa akselerator pada satu mesin host.
Inferensi model besar multi-host: untuk model dengan ratusan miliar hingga triliunan parameter, dengan beban komputasi dibagi di beberapa akselerator pada beberapa mesin host.

Kasus Penggunaan	Akselerator yang Direkomendasikan	Machine Series	Karakteristik Utama
Inferensi model kecil	NVIDIA L4	G2	Opsi hemat biaya untuk model kecil (memori 24 GB per GPU).
	NVIDIA RTX Pro 6000	G4	Hemat biaya untuk model dengan parameter di bawah 30B dan pembuatan gambar (memori 96 GB per GPU). Mendukung komunikasi peer-to-peer GPU langsung, sehingga cocok untuk inferensi multi-GPU, host tunggal.
	TPU v5e	-	Dioptimalkan untuk efisiensi biaya.
	TPU v6e	-	Menawarkan nilai tertinggi untuk model transformer dan text-to-image.
Inferensi model besar host tunggal	NVIDIA A100	A2	Cocok untuk sebagian besar model yang cocok di satu node (total memori hingga 640 GB).
	NVIDIA H100	A3	Ideal untuk workload inferensi yang cocok pada satu node (total memori hingga 640 GB).
	NVIDIA B200	A4	Opsi yang siap digunakan untuk model berat yang cocok pada satu node (total memori hingga 1.440 GB).
	TPU v4	-	Menawarkan keseimbangan yang baik antara biaya dan performa.
	TPU v5p	-	Opsi berperforma tinggi untuk workload yang berat.
Inferensi model besar multi-host	NVIDIA H200	A3 Ultra	Cocok untuk model besar yang sarat memori (total memori hingga 1.128 GB).
	NVIDIA B200 / GB200	A4 / A4X	Untuk workload yang paling menuntut, intensif komputasi, dan terikat jaringan. Mesin A4X menggunakan CPU berbasis Arm, yang mungkin memerlukan refaktorisasi workload (perubahan kode di luar pembangunan ulang container sederhana) jika workload Anda menggunakan fitur atau pengoptimalan khusus x86.
	TPU v5e	-	Dioptimalkan untuk efisiensi biaya dan performa untuk penayangan LLM berukuran sedang hingga besar.
	TPU v5p	-	Opsi berperforma tinggi untuk inferensi multi-host yang memerlukan paralelisasi skala besar.
	TPU v6e	-	Dioptimalkan untuk inferensi transformer, text-to-image, dan CNN.

Contoh: Memilih akselerator untuk model 260 GB

Bayangkan Anda perlu men-deploy model yang memerlukan total memori akselerator 260 GB (200 GB untuk model, 50 GB untuk cache KV, dan 10 GB untuk overhead).

Berdasarkan persyaratan memori saja, Anda dapat mengecualikan GPU NVIDIA L4, karena mesin G2 terbesar menawarkan memori akselerator maksimum 192 GB. Selain itu, karena GPU L4 tidak mendukung konektivitas berkecepatan tinggi dan latensi rendah antar-akselerator, mendistribusikan workload ke beberapa node bukanlah opsi yang layak untuk mencapai performa yang diinginkan.

Jika Anda ingin menghindari refaktorisasi workload x86-64 (yaitu, harus mengubah kode agar dapat berjalan di jenis prosesor yang berbeda), Anda juga akan mengecualikan akselerator NVIDIA GB200 dan GB300, yang menggunakan CPU berbasis Arm.

Dengan demikian, Anda memiliki opsi berikut:

NVIDIA A100
NVIDIA RTX Pro 6000
NVIDIA H100
NVIDIA H200
NVIDIA B200

Semua akselerator ini memiliki memori yang cukup. Langkah berikutnya adalah mengevaluasi ketersediaannya di wilayah target Anda. Misalnya, Anda menemukan bahwa hanya GPU NVIDIA A100 dan NVIDIA H100 yang tersedia di region tertentu. Setelah membandingkan rasio harga-performa kedua opsi ini, Anda dapat memilih NVIDIA H100 untuk workload Anda.

GPU multi-instance

Untuk meningkatkan pemanfaatan GPU dan mengoptimalkan biaya GPU, Anda dapat menggunakan konfigurasi GPU multi-instance. Dengan konfigurasi ini, Anda mempartisi GPU yang didukung untuk berbagi satu GPU ke beberapa container di GKE. Saat menyediakan GPU multi-instance, Anda hanya melampirkan GPU utuh ke node GKE, dan Anda tunduk pada harga GPU yang sesuai. Sebaiknya gunakan GPU multi-instance hanya dengan workload tepercaya.

Misalnya, Anda dapat memasang NVIDIA RTX PRO 6000 dan melakukan hal berikut:

Partisi menjadi empat instance (setiap instance menyediakan memori akselerator 24 GB), dan jalankan model difusi atau workload inferensi model kecil, seperti model yang memiliki sekitar 8 miliar parameter dan menggunakan presisi format data FP16 untuk bobot model. Partisi ini mungkin memiliki rasio harga terhadap performa yang lebih baik dibandingkan NVIDIA L4.
Partisi menjadi dua instance (setiap instance menyediakan memori akselerator 48 GB), dan jalankan workload inferensi model kecil, seperti model yang memiliki sekitar 15 miliar parameter dan menggunakan presisi format data FP16 untuk bobot model. Partisi ini dapat menjadi alternatif untuk menjalankan workload inferensi di GPU NVIDIA A100 40 GB.

Untuk mengetahui informasi selengkapnya, lihat Menjalankan GPU multi-instance.

Untuk mengetahui informasi selengkapnya, lihat Jenis mesin GPU dan Kelompok mesin yang dioptimalkan untuk akselerator dalam dokumentasi Compute Engine.

Pilih strategi distribusi inferensi: jika model Anda terlalu besar untuk satu akselerator, pilih strategi distribusi berdasarkan persyaratan workload Anda.

Pertama, pilih strategi distribusi berdasarkan topologi hardware Anda:
- Akselerator tunggal: jika model Anda cocok dengan akselerator tunggal, ini adalah pendekatan yang paling sederhana dan direkomendasikan.
- Multi-akselerator, satu node: jika model Anda cocok di satu node dengan beberapa akselerator, Anda dapat menggunakan paralelisme tensor untuk mendistribusikan model di seluruh akselerator pada node tersebut.
- Multi-node, multi-akselerator: jika model Anda terlalu besar untuk satu node, Anda dapat menggunakan kombinasi paralelisme tensor dan pipeline untuk mendistribusikannya di beberapa node.
Untuk menerapkan strategi ini, Anda dapat menggunakan teknik paralelisme berikut:
- Paralelisme tensor: teknik ini memecah lapisan model di beberapa akselerator. Ini sangat efektif dalam satu node dengan interkoneksi berkecepatan tinggi seperti NVLINK atau PCIe peer-to-peer langsung, tetapi memerlukan komunikasi yang signifikan antar-akselerator.
  
  Contoh: Paralelisme tensor
  
  Misalnya, Anda perlu men-deploy model dengan 109 miliar parameter. Dengan presisi BF16 (16-bit) default, memuat bobot model ke dalam memori akselerator memerlukan sekitar 113 GB. Satu GPU NVIDIA H100 menyediakan memori 80 GB. Oleh karena itu, meskipun tanpa memperhitungkan persyaratan memori lainnya seperti cache KV, Anda memerlukan setidaknya dua GPU NVIDIA H100 untuk memuat model, menggunakan ukuran paralelisme tensor dua.
- Paralelisme pipeline: Teknik ini mempartisi lapisan model secara berurutan di beberapa node. Paralelisme ini cocok untuk mendistribusikan model di beberapa node dalam deployment multi-host dan memerlukan lebih sedikit komunikasi antar-peringkat model daripada paralelisme tensor.
  
  Contoh: Paralelisme hybrid (tensor dan pipeline)
  
  Untuk model yang sangat besar dengan lebih dari 600 miliar parameter, persyaratan memori dapat melebihi 1,1 TB. Dalam skenario dengan dua node a3-megagpu-8g (masing-masing dengan delapan GPU NVIDIA H100), total cluster memiliki memori akselerator sebesar 1,28 TB. Untuk menjalankan model, Anda akan menerapkan strategi hybrid: paralelisme tensor 8 arah dalam setiap node, dan paralelisme pipeline 2 arah di dua node. Model akan dibagi menjadi dua tahap, dengan setengah lapisan pertama pada node pertama dan setengah lapisan kedua pada node kedua. Saat permintaan tiba, node pertama akan memprosesnya dan mengirimkan data perantara melalui jaringan ke node kedua, yang akan menyelesaikan komputasi.
Untuk mengetahui panduan selengkapnya tentang cara memilih strategi inferensi terdistribusi untuk replika model tunggal, lihat Paralelisme dan Penskalaan dalam dokumentasi vLLM.
Pilih jenis mesin yang dioptimalkan untuk akselerator: berdasarkan pilihan akselerator dan jumlah yang Anda perlukan, pilih jenis mesin yang menyediakan resource tersebut. Setiap jenis mesin menawarkan kombinasi vCPU, memori sistem, dan bandwidth jaringan tertentu, yang juga dapat memengaruhi performa beban kerja Anda. Misalnya, jika Anda memerlukan 16 GPU NVIDIA H100, Anda akan memilih jenis mesin a3-megagpu-16g.
Jalankan tolok ukur Anda sendiri: performa workload inferensi Anda sangat bergantung pada kasus penggunaan spesifik Anda. Jalankan tolok ukur Anda sendiri untuk memvalidasi pilihan dan menyesuaikan konfigurasi Anda.

Mengoptimalkan konfigurasi server inferensi Anda

Untuk mencapai performa optimal saat men-deploy beban kerja inferensi, sebaiknya lakukan siklus tolok ukur dan penyesuaian:

Mulai dengan Panduan Memulai Inferensi GKE untuk mendapatkan konfigurasi Kubernetes dasar yang dioptimalkan untuk kasus penggunaan Anda.
Jalankan benchmark untuk mendapatkan metrik throughput dan latensi dasar.
Sesuaikan konfigurasi server inferensi Anda.
Jalankan tolok ukur lagi dan bandingkan hasilnya untuk memvalidasi perubahan Anda.

Rekomendasi berikut didasarkan pada server inferensi vLLM, tetapi prinsipnya juga berlaku untuk server lain. Untuk panduan mendetail tentang semua setelan yang tersedia, lihat dokumentasi Pengoptimalan dan Penyesuaian vLLM:

Mengonfigurasi paralelisme:
- Tensor Parallelism (tensor_parallel_size): tetapkan ini ke jumlah akselerator pada satu node untuk membagi beban kerja. Misalnya, menyetel tensor_parallel_size=4 akan mendistribusikan beban kerja di empat akselerator. Perhatikan bahwa peningkatan nilai ini dapat menyebabkan overhead sinkronisasi yang berlebihan.
- Paralelisme Pipeline (pipeline_parallel_size): tetapkan ini ke jumlah node tempat Anda mendistribusikan model. Misalnya, jika Anda men-deploy di dua node dengan delapan akselerator di setiap node, Anda akan menetapkan tensor_parallel_size=8 dan pipeline_parallel_size=2. Meningkatkan nilai ini dapat menimbulkan penalti latensi.
Menyesuaikan cache KV (gpu_memory_utilization): parameter ini mengontrol persentase memori GPU yang dicadangkan untuk bobot model, aktivasi, dan cache KV. Nilai yang lebih tinggi akan meningkatkan ukuran cache KV dan dapat meningkatkan throughput. Sebaiknya tetapkan nilai ini antara 0.9 dan 0.95. Jika Anda mengalami error kehabisan memori (OOM), turunkan nilai ini.
Konfigurasi panjang konteks maksimum (max_model_len): untuk mengurangi ukuran cache KV dan persyaratan memori, Anda dapat menetapkan panjang konteks maksimum yang lebih rendah daripada default model. Hal ini memungkinkan Anda menggunakan GPU yang lebih kecil dan hemat biaya. Misalnya, jika kasus penggunaan Anda hanya memerlukan konteks 40.000 token, tetapi default model Anda adalah 256.000, menyetel max_model_len ke 40.000 akan membebaskan memori untuk cache KV yang lebih besar, yang berpotensi menghasilkan throughput yang lebih tinggi.
Konfigurasi jumlah permintaan serentak (max_num_batched_tokens, max_num_seqs): sesuaikan jumlah maksimum permintaan yang diproses vLLM secara serentak untuk menghindari preemption saat ruang cache KV hampir habis. Nilai yang lebih rendah untuk max_num_batched_tokens dan max_num_seqs mengurangi persyaratan memori, sedangkan nilai yang lebih tinggi dapat meningkatkan throughput dengan risiko error OOM. Untuk menemukan nilai optimal, sebaiknya jalankan eksperimen performa dan amati jumlah permintaan preempti di metrik Prometheus yang diekspor vLLM.

Untuk informasi selengkapnya, lihat referensi berikut:

Untuk mempelajari lebih lanjut cara menyesuaikan parameter ini, lihat Penyesuaian Performa vLLM: Panduan Utama Konfigurasi Inferensi xPU.
Untuk panduan selengkapnya tentang pengoptimalan memori model, lihat Praktik terbaik untuk mengoptimalkan inferensi model bahasa yang besar dengan GPU di GKE.
Untuk contoh lengkap yang dapat di-deploy, lihat implementasi referensi Inferensi GKE.

Mengoptimalkan latensi dan ketersediaan

Untuk memastikan layanan inferensi Anda responsif dan andal, Anda harus mengoptimalkan latensi startup rendah dan ketersediaan resource tinggi.

Mengoptimalkan latensi cold start workload inferensi

Meminimalkan waktu yang diperlukan untuk memulai workload inferensi sangat penting untuk efisiensi biaya dan pengalaman pengguna. Latensi mulai dingin yang rendah memungkinkan cluster Anda melakukan penskalaan cepat untuk memenuhi permintaan, sehingga memastikan layanan yang responsif sekaligus meminimalkan kebutuhan untuk penyediaan berlebih yang mahal.

Mengoptimalkan waktu startup Pod

Waktu yang diperlukan agar Pod siap sebagian besar ditentukan oleh waktu yang diperlukan untuk menarik image container dan mendownload bobot model. Untuk mengoptimalkan keduanya, pertimbangkan strategi berikut:

Mempercepat pemuatan model dengan pemuat data yang dioptimalkan: metode yang Anda gunakan untuk menyimpan dan memuat bobot model akan berdampak signifikan pada waktu mulai. Untuk vLLM versi 0.10.2 dan yang lebih baru, pendekatan yang direkomendasikan adalah menggunakan Run:ai Model Streamer untuk memuat model dengan melakukan streaming langsung dari bucket Cloud Storage.

Jika streamer tidak tersedia untuk kasus penggunaan Anda, Anda dapat memasang bucket Cloud Storage menggunakan Cloud Storage FUSE dan menyesuaikan performanya dengan mengaktifkan namespace hierarkis dan menggunakan teknik seperti download paralel dan pengambilan data sebelumnya. Untuk mempelajari lebih lanjut teknik ini, lihat Mengoptimalkan driver CSI FUSE Cloud Storage untuk performa GKE. Dalam kedua kasus tersebut, sebaiknya gunakan Anywhere Cache untuk membuat cache baca zonal berperforma tinggi untuk bucket Anda, dan aktifkan Akses level bucket yang seragam untuk mengontrol akses ke bucket Anda secara seragam.

Jika sudah menggunakan Managed Lustre untuk penyimpanan file berperforma tinggi untuk beban kerja pelatihan, Anda juga dapat menggunakannya untuk memuat bobot model untuk inferensi. Pendekatan ini menawarkan akses latensi rendah saat lokalitas data dan kompatibilitas POSIX sangat penting.
Aktifkan Streaming Image: untuk mengurangi waktu yang diperlukan untuk menarik image container, aktifkan Streaming image di cluster GKE Anda. Streaming gambar memungkinkan container Anda dimulai sebelum seluruh gambar didownload, yang dapat mengurangi waktu startup Pod secara signifikan.

Mengaktifkan node yang dimulai dengan cepat

Untuk workload yang memerlukan penskalaan cepat, Anda dapat memanfaatkan node mulai cepat di GKE. Node mulai cepat adalah resource hardware yang telah diinisialisasi sebelumnya dan memiliki waktu mulai yang jauh lebih singkat daripada node standar. Jika cluster Anda memenuhi persyaratan, GKE akan otomatis mengaktifkan node mulai cepat.

Merencanakan kapasitas dan memaksimalkan ketersediaan akselerator

Akselerator dengan permintaan tinggi seperti GPU dan TPU mungkin memiliki ketersediaan terbatas, sehingga strategi perencanaan kapasitas proaktif sangat penting.

Merencanakan dan mencadangkan kapasitas

Akselerator dengan permintaan tinggi mungkin memiliki ketersediaan terbatas, sehingga strategi perencanaan kapasitas proaktif sangat penting. Untuk menjamin akses ke resource yang Anda butuhkan, ikuti rekomendasi berikut:

Tentukan penanganan puncak dan dasar pengukuran kapasitas: rencanakan kapasitas akselerator dasar pengukuran yang perlu Anda pesan. Jumlah yang akan dicadangkan bergantung pada kasus penggunaan Anda. Misalnya, Anda dapat mencadangkan 100% kapasitas yang diperlukan untuk workload penting tanpa toleransi terhadap penundaan, atau Anda dapat mencadangkan persentil tertentu (seperti persentil ke-90 atau ke-95) dan mendapatkan sisanya sesuai permintaan untuk menangani lonjakan.
Mencadangkan kapasitas dasar: untuk mendapatkan resource dengan tingkat kepastian yang tinggi, buat reservasi. Anda dapat memilih jenis reservasi berdasarkan kebutuhan Anda. Misalnya, untuk memesan resource yang sangat diminati seperti akselerator untuk jangka waktu tertentu pada masa mendatang, Anda dapat membuat pemesanan untuk masa mendatang dalam mode kalender.
Mengatur kapasitas untuk puncak: untuk permintaan yang melebihi reservasi dasar, Anda dapat menerapkan strategi penggantian menggunakan jenis kapasitas lain seperti on-demand, Spot VM, atau Dynamic Workload Scheduler (DWS). Anda dapat mengotomatiskan strategi penggantian ini dengan menggunakan Kelas Compute Kustom untuk menentukan urutan prioritas dalam penyediaan berbagai jenis kapasitas.
Dapatkan akses ke harga diskon: untuk kapasitas dasar Anda, beli diskon abonemen (CUD) untuk mendapatkan harga diskon besar sebagai imbalan atas komitmen satu atau tiga tahun.

Gunakan Dynamic Workload Scheduler dengan mode penyediaan mulai fleksibel jika workload Anda dapat mentoleransi penundaan dalam mendapatkan kapasitas

Untuk workload yang dapat mentoleransi beberapa penundaan dalam mendapatkan kapasitas, Dynamic Workload Scheduler (DWS) dengan mode penyediaan flex-start adalah opsi untuk mendapatkan akselerator dengan harga diskon. DWS memungkinkan Anda mengantrekan permintaan kapasitas hingga tujuh hari.

Saat menggunakan DWS dengan mode penyediaan mulai fleksibel, sebaiknya lakukan hal berikut:

Menggabungkannya ke dalam Class Komputasi Kustom: gunakan Class Komputasi Kustom untuk menentukan DWS sebagai bagian dari strategi penggantian yang diprioritaskan untuk mendapatkan kapasitas.
Menetapkan durasi runtime maksimum: parameter maxRunDurationSeconds menetapkan runtime maksimum untuk node yang diminta melalui DWS. Menetapkan nilai ini ke nilai yang lebih rendah dari default tujuh hari dapat meningkatkan peluang Anda untuk mendapatkan node yang diminta.
Aktifkan daur ulang node: untuk mencegah periode nonaktif pada workload, aktifkan daur ulang node. Fitur ini mulai menyediakan node baru sebelum node lama berakhir, sehingga memastikan transisi yang lebih lancar.
Minimalkan gangguan: untuk meminimalkan gangguan dari pengusiran dan upgrade node, konfigurasi masa pemeliharaan dan pengecualian, nonaktifkan perbaikan otomatis node, dan manfaatkan strategi upgrade jangka pendek.

Menggunakan Class Komputasi Kustom

Class Komputasi Kustom (CCC) adalah fitur GKE yang memungkinkan Anda menentukan daftar konfigurasi infrastruktur yang diprioritaskan untuk workload Anda. CCC menyediakan kemampuan utama yang dirancang untuk meningkatkan ketersediaan akselerator:

Prioritas komputasi penggantian: Anda dapat menentukan daftar konfigurasi yang diprioritaskan. Jika opsi pilihan Anda tidak tersedia selama peristiwa penskalaan, autoscaler akan otomatis melakukan penggantian ke opsi berikutnya dalam daftar, sehingga meningkatkan kemungkinan keberhasilan perolehan kapasitas secara signifikan.
Migrasi aktif ke node dengan prioritas lebih tinggi: saat Anda mengonfigurasi fitur ini, GKE akan otomatis mengganti node yang berjalan pada konfigurasi dengan prioritas lebih rendah dengan node dari konfigurasi dengan prioritas lebih tinggi saat node tersebut tersedia. Hal ini membantu memastikan bahwa Pod Anda akhirnya berjalan di node yang paling Anda sukai (dan sering kali paling hemat biaya).

Dengan Kelas Compute Kustom (CCC), Anda dapat membuat strategi penggantian untuk mendapatkan node. Strategi ini menggunakan daftar yang diprioritaskan dari berbagai jenis kapasitas, seperti VM sesuai permintaan, Spot VM, atau reservasi. Setiap jenis kapasitas ini memiliki tingkat ketersediaan yang berbeda:

Pemesanan: memberikan tingkat jaminan tertinggi untuk mendapatkan kapasitas. Saat menggunakan reservasi dengan CCC, pertimbangkan batasannya. Misalnya, beberapa jenis reservasi membatasi jenis mesin yang dapat Anda pesan atau jumlah maksimum mesin yang dapat Anda minta.
On-demand: model penyediaan standar, yang menawarkan fleksibilitas tetapi mungkin tunduk pada batasan kapasitas regional untuk resource dengan permintaan tinggi.
Spot VM: menggunakan kapasitas cadangan dengan harga lebih rendah, tetapi dapat dihentikan. Saat peristiwa preemption terjadi, GKE memberikan periode penghentian tuntas hingga 30 detik untuk Pod yang terpengaruh berdasarkan upaya terbaik. Untuk memanfaatkannya, buat beban kerja Anda toleran terhadap peristiwa penghentian sementara dengan menerapkan mekanisme titik pemeriksaan dan percobaan ulang.
Dynamic Workload Scheduler (DWS): memungkinkan Anda mengantrekan permintaan untuk resource langka dengan harga diskon. Fitur ini ideal untuk workload yang dapat mentoleransi penundaan dalam mendapatkan kapasitas.

Urutan daftar prioritas Anda akan berubah, bergantung pada apakah sasaran utama Anda adalah meminimalkan latensi atau mengoptimalkan biaya. Misalnya, Anda dapat mengonfigurasi daftar prioritas berikut untuk persyaratan workload yang berbeda:

Prioritas	Beban Kerja Latensi Rendah	Workload yang Dioptimalkan untuk Biaya (Toleran terhadap Latensi)
1	Reservasi (Khusus, lalu apa pun)	Reservasi (Khusus, lalu apa pun)
2	Sesuai permintaan	Spot VM
3	Spot VM	Dynamic Workload Scheduler
4	Dynamic Workload Scheduler	Sesuai permintaan

Untuk kasus penggunaan latensi rendah, kapasitas sesuai permintaan diprioritaskan setelah reservasi karena melaporkan kekurangan kapasitas dengan cepat, sehingga CCC dapat dengan cepat beralih ke opsi berikutnya.

Untuk kasus penggunaan yang dioptimalkan biayanya, Spot VM dan DWS dengan flex-start diprioritaskan setelah reservasi untuk memanfaatkan biaya yang lebih rendah. Kapasitas sesuai permintaan digunakan sebagai penggantian terakhir.

Mengonfigurasi kebijakan lokasi cluster GKE dan node pool

Kebijakan lokasi Cluster Autoscaler mengontrol cara GKE mendistribusikan node di seluruh zona selama peristiwa peningkatan skala. Setelan ini sangat penting saat menggunakan Class Komputasi Kustom karena menentukan zona yang akan dipertimbangkan oleh Cluster Autoscaler sebelum menerapkan daftar prioritas CCC.

Untuk meningkatkan peluang Anda mendapatkan akselerator, konfigurasi kebijakan lokasi berdasarkan persyaratan workload Anda:

location-policy=ANY: memprioritaskan perolehan kapasitas daripada menyeimbangkan node secara merata di seluruh zona. Setelan ini sangat relevan saat CCC Anda menyertakan Spot VM atau jenis mesin dengan ketersediaan yang bervariasi, karena ANY memungkinkan Cluster Autoscaler memilih zona dengan peluang terbaik untuk memenuhi jenis node yang diprioritaskan CCC. Gunakan setelan ini juga untuk memprioritaskan penggunaan reservasi yang tidak digunakan. Saat menggunakan kebijakan ini, sebaiknya Anda mulai dengan num-nodes=0 untuk memberikan fleksibilitas maksimum pada Cluster Autoscaler dalam menemukan kapasitas.
location-policy=BALANCED: mencoba mendistribusikan node secara merata di semua zona yang tersedia. Gunakan kebijakan ini saat workload Anda menggunakan resource yang mudah didapatkan dan Anda ingin mempertahankan redundansi zona untuk ketersediaan tinggi.

Anda dapat mengonfigurasi setelan ini saat membuat atau memperbarui node pool.

Mengoptimalkan efisiensi dan biaya

Dengan memantau akselerator secara cermat dan menskalakan workload secara cerdas, Anda dapat mengurangi pemborosan secara signifikan dan menurunkan biaya operasional.

Mengamati akselerator dan server inferensi Anda

Strategi kejelasan yang komprehensif sangat penting untuk memahami performa dan penggunaan beban kerja inferensi Anda. GKE menyediakan serangkaian alat untuk membantu Anda memantau akselerator dan server inferensi:

Memantau metrik DCGM untuk GPU NVIDIA: untuk memantau performa dan kondisi GPU NVIDIA, konfigurasi GKE untuk mengirim metrik NVIDIA Data Center GPU Manager (DCGM) ke Cloud Monitoring.
Aktifkan pemantauan aplikasi otomatis: untuk menyederhanakan proses pemantauan server inferensi, aktifkan pemantauan aplikasi otomatis di GKE.
Instrumentasikan beban kerja Anda dengan OpenTelemetry: untuk beban kerja yang tidak didukung oleh pemantauan aplikasi otomatis, gunakan OpenTelemetry untuk mengumpulkan metrik dan rekaman aktivitas kustom.

Menskalakan Pod Anda secara otomatis

Untuk memastikan workload inferensi Anda dapat beradaptasi secara dinamis terhadap perubahan permintaan, gunakan Horizontal Pod Autoscaler (HPA) untuk menskalakan jumlah Pod secara otomatis. Untuk workload inferensi, penting untuk mendasarkan keputusan penskalaan pada metrik yang secara langsung mencerminkan beban pada server inferensi, bukan pada metrik CPU atau memori standar.

Untuk mengonfigurasi penskalaan otomatis untuk workload inferensi, sebaiknya lakukan hal berikut:

Konfigurasi HPA berdasarkan metrik yang mendukung inferensi: untuk performa yang optimal, konfigurasi HPA agar menskalakan berdasarkan metrik dari server inferensi Anda. Metrik terbaik bergantung pada apakah Anda mengoptimalkan latensi rendah atau throughput tinggi.
- Untuk beban kerja yang sensitif terhadap latensi, Anda memiliki dua opsi utama:
  - Penggunaan cache KV (misalnya, vllm:gpu_cache_usage_perc): metrik ini sering kali menjadi indikator terbaik untuk lonjakan latensi yang akan terjadi. Penggunaan cache KV yang tinggi menunjukkan bahwa mesin inferensi hampir mencapai kapasitas. HPA dapat menggunakan sinyal ini untuk menambahkan replika secara antisipatif dan mempertahankan pengalaman pengguna yang stabil.
  - Jumlah permintaan yang berjalan (ukuran batch) (misalnya,vllm:num_requests_running): metrik ini secara langsung terkait dengan latensi, karena ukuran batch yang lebih kecil biasanya menghasilkan latensi yang lebih rendah. Namun, menggunakannya untuk penskalaan otomatis bisa jadi sulit karena memaksimalkan throughput bergantung pada ukuran permintaan masuk. Anda mungkin perlu memilih nilai yang lebih rendah dari ukuran batch maksimum yang mungkin untuk memastikan HPA menskalakan dengan tepat.
- Untuk beban kerja yang sensitif terhadap throughput, lakukan penskalaan berdasarkan ukuran antrean (misalnya, vllm:num_requests_waiting). Metrik ini secara langsung mengukur backlog pekerjaan dan merupakan cara mudah untuk mencocokkan kapasitas pemrosesan dengan permintaan yang masuk. Karena metrik ini hanya mempertimbangkan permintaan yang sedang menunggu dan bukan yang sedang diproses, metrik ini mungkin tidak mencapai latensi terendah dibandingkan dengan penskalaan pada ukuran batch.
Tetapkan jumlah minimum replika: untuk memastikan ketersediaan yang konsisten dan pengalaman pengguna dasar, selalu tetapkan jumlah minimum replika untuk deployment inferensi Anda.
Aktifkan profil HPA Performa: pada GKE versi 1.33 atau yang lebih baru, profil HPA Performa diaktifkan secara default pada cluster yang memenuhi syarat untuk meningkatkan waktu reaksi HPA.

Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi HPA untuk workload LLM di GPU dan Menskalakan otomatis workload inferensi LLM di TPU.

Memindahkan data lebih dekat ke beban kerja Anda

Waktu yang diperlukan workload Anda untuk memuat data, seperti bobot model, dapat menjadi sumber latensi yang signifikan. Dengan memindahkan data lebih dekat ke resource komputasi, Anda dapat mengurangi waktu transfer data dan meningkatkan performa secara keseluruhan.

Membuat cache baca zonal dengan Anywhere Cache: jika Anda menggunakan Cloud Storage untuk menyimpan data bagi workload AI/ML, aktifkan Anywhere Cache. Anywhere Cache membuat cache baca zonal berperforma tinggi untuk bucket Cloud Storage Anda.
Meng-cache data yang sering diakses di SSD Lokal: untuk workload yang memerlukan akses latensi sangat rendah ke data sementara, gunakan SSD Lokal sebagai cache berperforma tinggi. Penggunaan SSD Lokal sebagai penyimpanan sementara berlatensi rendah untuk menyimpan data yang sering digunakan membantu Anda mengurangi waktu tunggu resource yang mahal, seperti akselerator, dengan mengurangi secara drastis waktu tunggu akselerator untuk menyelesaikan operasi I/O. Perhatikan bahwa tidak semua seri mesin mendukung SSD Lokal, yang dapat memengaruhi pilihan akselerator Anda.
Mengelola cache dengan GKE Data Cache: untuk workload yang sering membaca data dari Persistent Disk, aktifkan GKE Data Cache. Cache Data GKE menggunakan SSD Lokal untuk membuat cache berperforma tinggi yang terkelola untuk Persistent Disk Anda. Untuk sebagian besar beban kerja produksi, sebaiknya gunakan mode Writethrough untuk mencegah kehilangan data dengan menulis data secara sinkron ke cache dan disk persisten yang mendasarinya.

Mengoptimalkan arsitektur penskalaan lanjutan

Untuk memenuhi permintaan aplikasi berskala besar atau terdistribusi secara global, Anda dapat mengadopsi arsitektur penskalaan lanjutan untuk meningkatkan performa, keandalan, dan pengelolaan traffic.

Load balancing traffic dengan GKE Inference Gateway

Untuk workload inferensi dalam satu cluster, sebaiknya gunakan GKE Inference Gateway. Inference Gateway adalah load balancer yang mendukung AI yang memantau metrik inferensi untuk merutekan permintaan ke endpoint yang paling optimal. Fitur ini meningkatkan performa dan pemanfaatan akselerator.

Saat menggunakan GKE Inference Gateway, sebaiknya ikuti praktik terbaik berikut:

Kelompokkan Pod penayangan ke dalam InferencePool: tentukan InferencePool untuk setiap grup Pod yang menayangkan workload inferensi Anda. Untuk mengetahui informasi selengkapnya, lihat Menyesuaikan konfigurasi GKE Inference Gateway.
Multiplex beban kerja penting latensi: tentukan InferenceObjectives untuk menentukan properti penayangan model Anda, seperti nama dan prioritasnya. GKE Inference Gateway memberikan preferensi pada workload dengan prioritas yang lebih tinggi, sehingga Anda dapat memultipleks workload yang penting dan tidak penting latensinya serta menerapkan kebijakan pelepasan beban selama traffic berat.
Gunakan perutean yang mendukung model: untuk merutekan permintaan berdasarkan nama model di isi permintaan, gunakan perutean berbasis isi. Saat Anda menggunakan perutean berbasis isi, pastikan backend Anda memiliki ketersediaan tinggi. Gateway akan menampilkan error jika ekstensi tidak tersedia, sehingga mencegah permintaan dirutekan secara tidak benar.
Mengizinkan gateway mendistribusikan traffic secara otomatis: GKE Inference Gateway secara cerdas merutekan traffic dengan memantau metrik utama dari server inferensi di InferencePool, seperti pemanfaatan cache KV, panjang antrean, dan indeks cache awalan. Penyeimbangan beban real-time ini mengoptimalkan penggunaan akselerator, mengurangi latensi ekor, dan meningkatkan throughput secara keseluruhan dibandingkan dengan metode tradisional.
Integrasikan dengan Apigee dan Model Armor: untuk meningkatkan keamanan dan pengelolaan, integrasikan dengan Apigee untuk pengelolaan API dan dengan Model Armor untuk pemeriksaan keamanan.

Men-deploy workload inferensi di beberapa node

Untuk model yang sangat besar dan tidak dapat dimuat dalam satu node, Anda perlu mendistribusikan workload inferensi di beberapa node. Hal ini memerlukan arsitektur yang meminimalkan latensi komunikasi antar-node dan memastikan bahwa semua komponen workload terdistribusi dikelola sebagai satu unit.

Pertimbangkan praktik terbaik berikut ini:

Memaksimalkan bandwidth dan throughput jaringan akselerator: saat workload didistribusikan di beberapa node, jaringan menjadi faktor performa penting. Untuk meminimalkan latensi komunikasi antar-node, gunakan teknologi jaringan berperforma tinggi seperti NVIDIA GPUDirect. Bergantung pada skala cluster dan intensitas komunikasi yang diperlukan workload Anda, Anda dapat memilih dari opsi berikut:
- GPUDirect-TCPX: efektif untuk berbagai workload inferensi multi-node yang berjalan di A3 High.
- GPUDirect-TCPXO: menawarkan peningkatan performa dengan offload yang lebih besar dan bandwidth yang lebih tinggi, yang bermanfaat untuk cluster yang lebih besar dibandingkan dengan TCPX standar, dan berjalan di mesin A3 Mega.
- GPUDirect RDMA: memberikan bandwidth antar-node tertinggi dan latensi terendah dengan memungkinkan akses memori langsung antar-GPU di berbagai node, melewati CPU, dan paling cocok untuk skenario inferensi skala besar yang paling berat di mesin A3 Ultra dan A4.
Untuk informasi selengkapnya, lihat:
- Memaksimalkan bandwidth jaringan GPU di cluster mode Standar.
- Memaksimalkan bandwidth jaringan GPU di cluster mode Autopilot.
Untuk memvalidasi bahwa konfigurasi jaringan multi-node Anda berfungsi seperti yang diharapkan, sebaiknya jalankan pengujian dengan alat seperti NVIDIA Collective Communications Library (NCCL).
Gunakan LeaderWorkerSet untuk mengelola workload terdistribusi: saat Anda men-deploy workload terdistribusi stateful, seperti layanan inferensi multi-node, penting untuk mengelola semua komponennya sebagai satu unit. Untuk melakukannya, gunakan LeaderWorkerSet, API native Kubernetes yang memungkinkan Anda mengelola sekelompok Pod terkait sebagai satu entity. LeaderWorkerSet memastikan bahwa semua Pod dalam set dibuat dan dihapus bersama-sama, yang sangat penting untuk mempertahankan integritas workload terdistribusi.
Menempatkan node dalam jarak fisik menggunakan penempatan rapat: jarak fisik antara node dalam workload terdistribusi Anda dapat berdampak signifikan pada latensi jaringan antar-node. Untuk meminimalkan latensi ini, gunakan kebijakan penempatan rapat untuk node pool GKE Anda. Kebijakan penempatan rapat menginstruksikan GKE untuk menempatkan node di node pool sedekat mungkin satu sama lain secara fisik dalam suatu zona.

Men-deploy workload inferensi di beberapa region

Untuk aplikasi yang didistribusikan secara global yang memerlukan ketersediaan tinggi dan latensi rendah, men-deploy workload inferensi Anda di beberapa region adalah praktik terbaik yang penting. Arsitektur multi-region dapat membantu Anda meningkatkan keandalan, meningkatkan ketersediaan akselerator, mengurangi latensi yang dirasakan pengguna, dan memenuhi persyaratan peraturan khusus lokasi.

Untuk men-deploy dan mengelola layanan inferensi multi-region secara efektif, ikuti rekomendasi berikut:

Sediakan cluster GKE di beberapa region tempat Anda memiliki kapasitas yang dicadangkan atau memperkirakan akan memerlukan kapasitas untuk menangani beban puncak.
Pilih strategi penyimpanan yang tepat untuk bobot model Anda. Untuk mengoptimalkan efisiensi operasional, buat bucket Cloud Storage multi-region. Untuk mengoptimalkan biaya, buat bucket regional di setiap region dan replikasi bobot model Anda.
Gunakan Anywhere Cache untuk membuat cache baca zonal bagi bucket Cloud Storage Anda guna mengurangi latensi jaringan dan biaya traffic keluar data.