Apa itu Prompt Caching? Praktik Terbaik Dijelaskan

Model Bahasa Besar (LLM) telah merevolusi cara kita berinteraksi dengan AI, memungkinkan tugas kompleks seperti generasi teks, terjemahan, menjawab pertanyaan, dan banyak lagi. Namun, berinteraksi dengan model-model kuat ini, terutama dengan permintaan yang canggih, dapat mengakibatkan biaya komputasi dan latensi yang signifikan. Banyak aplikasi melibatkan pengiriman permintaan yang serupa atau sebagian identik secara berulang. Bayangkan chatbot dengan permintaan sistem tetap, alat analisis dokumen yang memproses potongan dengan instruksi yang sama, atau agen yang menggunakan definisi alat yang konsisten. Dalam skenario ini, LLM berulang kali memproses informasi awal yang sama (awalan permintaan), membuang komputasi dan meningkatkan waktu respons.

Penyimpanan permintaan muncul sebagai teknik optimisasi yang kuat untuk mengatasi ketidakefisienan ini. Ini memungkinkan penyedia LLM untuk menyimpan status komputasi sementara yang terkait dengan bagian awal yang statis dari sebuah permintaan (awalan). Ketika permintaan berikutnya menggunakan awalan yang sama, model dapat menggunakan kembali status yang disimpan ini, melewati komputasi yang berlebihan dan hanya memproses bagian baru dan dinamis dari permintaan (akhiran). Ini mengarah pada peningkatan substansial baik dalam latensi maupun biaya, menjadikan aplikasi LLM lebih cepat dan lebih ekonomis.

Panduan ini memberikan gambaran komprehensif tentang penyimpanan permintaan, cara kerjanya, manfaatnya, rincian implementasi (berfokus pada API Anthropic, yang juga relevan untuk model Claude di AWS Bedrock), pertimbangan harga, keterbatasan, dan praktik terbaik.

Bagaimana Penyimpanan Permintaan Bekerja: Mekanisme

Secara inti, penyimpanan permintaan memanfaatkan sifat repetitif dari banyak interaksi LLM. Ketika Anda mengirim permintaan ke LLM, model memproses token input secara berurutan untuk menghasilkan representasi atau status internal. Penyimpanan permintaan mengintersepsi proses ini.

1. Cache Miss (Permintaan Pertama / Awalan Berubah): Ketika sebuah permintaan tiba dengan awalan permintaan yang belum terlihat baru-baru ini atau tidak cocok dengan entri cache yang ada, LLM memproses seluruh permintaan seperti biasa. Namun, jika penyimpanan diaktifkan untuk batas awalan tertentu, sistem menyimpan status model internal yang sesuai dengan awalan tersebut setelah memprosesnya. Ini sering disebut sebagai tulisan cache. Sebuah pengidentifikasi unik, biasanya hash kriptografis dari konten awalan (termasuk permintaan sistem, definisi alat, dan pesan hingga titik cache), terkait dengan status yang disimpan ini, bertindak sebagai kunci cache.
2. Cache Hit (Permintaan Berikutnya): Jika permintaan berikutnya tiba dalam Time-To-Live (TTL) cache dan awalan cocok persis dengan konten yang terkait dengan kunci cache yang disimpan, sistem mengambil status internal yang disimpan. LLM secara efektif mempercepat hingga akhir awalan tanpa memproses ulang. Selanjutnya, hanya perlu memproses bagian baru dari permintaan (akhiran). Ini dikenal sebagai baca cache atau cache hit.

Awalan yang Disimpan:

Apa yang sebenarnya merupakan "awalan" tergantung pada API dan bagaimana Anda menyusun permintaan Anda. Secara umum, ini mencakup bagian statis dari permintaan Anda yang ingin Anda gunakan kembali di berbagai panggilan. Sebagai contoh, menggunakan struktur API Anthropic sebagai referensi:

• Alat: Definisi alat/fungsi yang tersedia.
• Permintaan Sistem: Instruksi atau konteks tingkat tinggi untuk model.
• Pesan: Pesan awal pengguna/asisten, seperti contoh few-shot atau riwayat percakapan.

Urutan biasanya penting (misalnya, Anthropic memproses tools, kemudian system, kemudian messages). Anda menetapkan di mana awalan yang dapat disimpan berakhir menggunakan parameter API tertentu.

Karaktersitik Cache:

• Umur (TTL): Cache tidak permanen. Mereka memiliki TTL. Misalnya, cache Anthropic memiliki TTL minimum 5 menit, yang diperbarui setiap kali entri cache diakses (cache hit). Jika entri cache tidak digunakan dalam TTL-nya, ia akan kedaluwarsa dan perlu dibuat ulang pada permintaan relevan berikutnya. Saat ini, sebagian besar implementasi menawarkan penyimpanan "sementara" dengan umur yang relatif pendek.
• Ruang Lingkup dan Privasi: Penyimpanan dirancang dengan memperhatikan privasi. Cache biasanya dipisahkan di tingkat organisasi atau akun. Bahkan jika dua organisasi berbeda mengirimkan awalan permintaan yang sama persis, mereka tidak akan berbagi entri cache. Dalam organisasi, pengguna yang mengirimkan awalan identik dapat berpotensi berbagi entri cache, meningkatkan efisiensi untuk aplikasi tim. Penggunaan hash kriptografis untuk kunci memastikan bahwa hanya permintaan dengan awalan identik yang dapat mengakses cache tertentu.
• Pencocokan Tepat: Penyimpanan bergantung pada pencocokan tepat dari konten awalan. Setiap perubahan, betapapun kecilnya (bahkan spasi), dalam awalan yang ditunjuk akan mengakibatkan cache miss dan memerlukan penulisan cache baru.

Mengapa Menggunakan Penyimpanan Permintaan?

Implementasi penyimpanan permintaan menawarkan keuntungan yang signifikan, terutama berfokus pada kinerja dan efisiensi biaya.

1. Latensi yang Berkurang: Ini seringkali merupakan manfaat yang paling langsung. Dengan melewatkan pengolahan ulang dari ribuan token awalan, LLM dapat mulai memproses informasi baru yang relevan (akhiran permintaan) jauh lebih cepat. Ini secara langsung diterjemahkan menjadi waktu respons yang lebih cepat bagi pengguna akhir. Untuk aplikasi yang memerlukan interaksi waktu nyata, seperti chatbot atau asisten kode, percepatan ini sangat penting. AWS Bedrock melaporkan potensi pengurangan latensi hingga 85% untuk model yang didukung.
2. Biaya yang Berkurang: API LLM biasanya membebankan biaya berdasarkan jumlah token input dan output yang diproses. Ketika terjadi cache hit, Anda sering kali dikenakan tarif yang jauh lebih rendah untuk token yang dibaca dari cache dibandingkan dengan tarif token input standar. Anda hanya membayar tarif input standar untuk token baru dalam akhiran (dan mungkin sedikit lebih tinggi untuk penulisan cache awal). Selama banyak panggilan dengan awalan statis yang besar, ini dapat mengarah pada penghematan biaya yang substansial. AWS Bedrock menyarankan pengurangan biaya hingga 90% mungkin terjadi.
3. Kinerja yang Dioptimalkan untuk Kasus Penggunaan Umum: Penyimpanan sangat berdampak untuk aplikasi yang secara inheren melibatkan pengulangan permintaan:

• Generasi yang Ditingkatkan oleh Pengambilan (RAG) / Q&A Dokumen: Dokumen besar atau potongan konteks sering kali diumpankan secara berulang sebagai bagian dari permintaan sementara hanya pertanyaan pengguna yang berubah. Penyimpanan konteks dokumen secara signifikan mempercepat Q&A atas dokumen tersebut.
• Pemintaan Few-Shot: Menyediakan beberapa contoh dalam permintaan (pembelajaran few-shot) meningkatkan kinerja model tetapi meningkatkan panjang permintaan. Penyimpanan contoh statis ini menghindari pengolahan ulang untuk setiap kueri baru.
• Alur Kerja Agen: Agen AI sering bergantung pada permintaan sistem yang kompleks, instruksi rinci, dan seperangkat definisi alat yang tetap. Penyimpanan elemen konstan ini mempercepat eksekusi tugas, terutama dalam proses multi-langkah.
• Chatbot / Percakapan Multi-Langkah: Sementara riwayat percakapan tumbuh, permintaan sistem awal dan instruksi sering kali tetap sama. Penyimpanan permintaan sistem, dan berpotensi secara bertahap menyimpan langkah-langkah percakapan, menjaga interaksi tetap cepat bahkan saat jendela konteks terisi.
• Asisten Kode: Konteks kode statis, dokumentasi pustaka, atau instruksi boilerplate dapat disimpan, memungkinkan asisten untuk memfokuskan komputasi pada kueri pengkodean spesifik pengguna.

1. Integrasi Tanpa Hambatan: Penyimpanan permintaan dirancang untuk bekerja bersama dengan fitur LLM lainnya. Misalnya, ia terintegrasi dengan fitur AWS Bedrock seperti Agen dan Guardrails, memungkinkan Anda memanfaatkan pengaturan kompleks tanpa menanggung penalti latensi penuh untuk komponen yang diulang.

Cara Mengaktifkan Penyimpanan Permintaan

Metode tepat untuk mengaktifkan penyimpanan permintaan bervariasi sedikit antara penyedia LLM dan API mereka. Di sini, kita akan fokus pada implementasi menggunakan API Pesan Anthropic, yang berlaku untuk model Claude secara langsung melalui Anthropic atau melalui platform seperti AWS Bedrock.

Prinsip Umum: Susun Permintaan Anda

Kuncinya adalah menyusun panggilan API Anda sehingga konten statis yang dapat digunakan kembali muncul terlebih dahulu, diikuti oleh konten dinamis.

+-------------------------+--------------------------+
|      AWAL STATIS       |     AKHIR DINAMIS       |
| (Permintaan Sistem, Alat,| (Kueri Pengguna Baru,    |
|  Contoh Few-Shot,      |  Putaran Percakapan Terbaru,|
|  Konteks Awal)         |                          |
+-------------------------+--------------------------+
          ^
          |
   Titik Patah Cache Di Sini

Implementasi API Anthropic (cache_control)

Anthropic menggunakan parameter cache_control dalam tubuh permintaan API Pesan untuk mengaktifkan dan mengelola penyimpanan.

• Mengaktifkan: Sertakan objek cache_control dalam salah satu blok yang ingin Anda sertakan sebagai akhir dari awalan yang dapat disimpan. Saat ini, satu-satunya type yang didukung adalah "ephemeral".
• Pemosisian: Anda dapat menempatkan blok cache_control pada:
• Pesan permintaan system.
• Objek message tertentu (putaran pengguna atau asisten).
• Blok definisi tool (kurang umum, tetapi mungkin).
• Urutan Pembuatan Cache: Awalan cache dibangun berdasarkan konten hingga dan termasuk blok yang ditandai dengan cache_control, mengikuti urutan standar: tools -> system -> messages.
• Beberapa Titik Patah: Anda dapat mendefinisikan hingga 4 titik patah cache dalam satu permintaan dengan menambahkan cache_control ke beberapa blok. Sistem akan mencoba menemukan awalan cache yang cocok terpanjang berdasarkan titik patah ini.

Contoh (SDK Python Anthropic): Menyimpan Permintaan Sistem

import anthropic

client = anthropic.Anthropic(api_key="YOUR_API_KEY")

# Permintaan Pertama (Tulis Cache)
response1 = client.messages.create(
    model="claude-3-5-sonnet-20240620",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            # Permintaan sistem ini adalah konten yang ingin kita simpan
            "text": "Anda adalah asisten yang membantu yang berspesialisasi dalam astrofisika. Basis pengetahuan Anda mencakup rincian luas tentang evolusi bintang, kosmologi, dan ilmu planet. Tanggapi dengan akurat dan singkat.",
            "cache_control": {"type": "ephemeral"} # Tandai untuk penyimpanan
        }
    ],
    messages=[
        {
            "role": "user",
            # Ini adalah bagian dinamis, tidak disimpan dalam awalan
            "content": "Apa itu batas Chandrasekhar?"
        }
    ]
)
print("Respon Pertama:", response1.content)
print("Penggunaan (Tulis):", response1.usage)
# Contoh output penggunaan mungkin terlihat seperti:
# Penggunaan(Tulis): Penggunaan(input_tokens=60, output_tokens=50, cache_creation_input_tokens=60, cache_read_input_tokens=0)

# Permintaan Berikutnya (Cache Hit - dalam TTL, misalnya, < 5 menit kemudian)
response2 = client.messages.create(
    model="claude-3-5-sonnet-20240620",
    max_tokens=1024,
    system=[
        {
            "type": "text",
            # PERSIS sama dengan permintaan sistem sebelumnya
            "text": "Anda adalah asisten yang membantu yang berspesialisasi dalam astrofisika. Basis pengetahuan Anda mencakup rincian luas tentang evolusi bintang, kosmologi, dan ilmu planet. Tanggapi dengan akurat dan singkat.",
            "cache_control": {"type": "ephemeral"} # Tandai lagi
        }
    ],
    messages=[
        {
            "role": "user",
            # Kueri dinamis baru
            "content": "Jelaskan konsep energi gelap."
        }
    ]
)
print("\\\\nRespon Kedua:", response2.content)
print("Penggunaan (Hit):", response2.usage)
# Contoh output penggunaan mungkin terlihat seperti:
# Penggunaan(Hit): Penggunaan(input_tokens=8, output_tokens=75, cache_creation_input_tokens=0, cache_read_input_tokens=60)

Dalam contoh ini:

1. Panggilan pertama memproses 60 token dari permintaan sistem dan 8 token dari pesan pengguna. Ini menyimpan permintaan sistem (cache_creation_input_tokens: 60).
2. Panggilan kedua menemukan cache hit untuk permintaan sistem yang identik (cache_read_input_tokens: 60). Ini hanya perlu memproses 8 token dari pesan pengguna baru sebagai input standar (input_tokens: 8).

Contoh (Penyimpanan Bertahap dalam Percakapan):

Untuk menyimpan riwayat percakapan, Anda dapat menempatkan cache_control pada pesan terakhir yang ingin Anda sertakan dalam cache untuk putaran berikutnya.

# Putaran 1 (Pengguna bertanya, Asisten menjawab - Sistem Cache + Putaran 1)
response_turn1 = client.messages.create(
    model="claude-3-5-sonnet-20240620",
    max_tokens=500,
    system=[{"type": "text", "text": "Pertahankan persona yang ramah."}], # Simpan ini juga
    messages=[
        {"role": "user", "content": "Halo Claude!"},
        {"role": "assistant", "content": "Halo! Bagaimana saya bisa membantu Anda hari ini?", "cache_control": {"type": "ephemeral"}} # Simpan hingga di sini
    ]
)
# Anggap pengguna menambahkan pesan lain untuk Putaran 2
# Putaran 2 (Cache hit untuk Sistem + Putaran 1, Tulis Cache untuk Putaran 2)
response_turn2 = client.messages.create(
    model="claude-3-5-sonnet-20240620",
    max_tokens=500,
    system=[{"type": "text", "text": "Pertahankan persona yang ramah."}], # Permintaan sistem yang sama
    messages=[
        {"role": "user", "content": "Halo Claude!"}, # Bagian dari awalan yang disimpan sekarang
        {"role": "assistant", "content": "Halo! Bagaimana saya bisa membantu Anda hari ini?"}, # Bagian dari awalan yang disimpan sekarang
        {"role": "user", "content": "Beritahu saya fakta menyenangkan."}, # Konten dinamis baru
        {"role": "assistant", "content": "Tahukah Anda bahwa madu tidak pernah busuk?", "cache_control": {"type": "ephemeral"}} # Simpan hingga akhir Putaran 2
    ]
)
# Penggunaan Putaran 2 akan menunjukkan cache_read_input_tokens untuk Sistem+Putaran1
# dan cache_creation_input_tokens untuk pesan pengguna/asisten baru dari Putaran 2

Melacak Kinerja Cache:

Respon API mencakup metrik penggunaan yang mengungkapkan bagaimana cache digunakan:

• input_tokens: Jumlah token input yang tidak disimpan yang diproses (akhiran dinamis).
• output_tokens: Jumlah token yang dihasilkan dalam respon.
• cache_creation_input_tokens: Jumlah token input yang diproses dan ditulis ke cache dalam permintaan ini (terjadi pada cache miss).
• cache_read_input_tokens: Jumlah token input yang dimuat dari cache dalam permintaan ini (terjadi pada cache hit).

Memantau bidang ini sangat penting untuk memahami apakah strategi penyimpanan Anda efektif. Tingkat cache_read_input_tokens yang tinggi relatif terhadap cache_creation_input_tokens seiring waktu menunjukkan penyimpanan yang berhasil.

AWS Bedrock:

Untuk model seperti Anthropic Claude yang diakses melalui AWS Bedrock, mekanisme penyimpanan biasanya diaktifkan menggunakan parameter cache_control yang sama dalam tubuh permintaan pemanggilan model (application/json format yang diteruskan ke InvokeModel atau InvokeModelWithResponseStream). Anda harus menyusun tubuh JSON sesuai dengan persyaratan model tertentu (misalnya, format API Pesan Anthropic) dan menyertakan bidang cache_control seperti yang ditunjukkan di atas. Periksa dokumentasi Bedrock spesifik untuk penyedia model yang Anda gunakan.

Apa Harga untuk Penyimpanan Permintaan?

Penyimpanan permintaan memperkenalkan struktur harga yang lebih nuansial dibandingkan dengan biaya token standar. Meskipun bermanfaat secara keseluruhan, penting untuk memahami jenis token yang berbeda yang terlibat:

1. Token Input Dasar: Ini adalah token input standar yang tidak merupakan bagian dari awalan yang disimpan (yaitu, akhiran dinamis dalam skenario cache hit, atau seluruh permintaan jika penyimpanan tidak digunakan atau gagal). Mereka dikenakan biaya pada tarif token input standar model.
2. Token Tulis Cache (cache_creation_input_tokens): Ketika sebuah awalan diproses untuk pertama kalinya (atau setelah cache miss) dan ditulis ke cache, token yang terkait dengan awalan itu sering kali dikenakan biaya pada tarif premium. Misalnya, Anthropic mengenakan biaya 25% lebih dari tarif token input dasar untuk penulisan cache. Ini mencerminkan biaya pemrosesan dan penyimpanan entri cache.
3. Token Baca Cache / Token Cache Hit (cache_read_input_tokens): Ketika terjadi cache hit, token yang sesuai dengan awalan yang dimuat dari cache dikenakan biaya pada tarif yang jauh lebih diskon. Misalnya, Anthropic hanya mengenakan biaya 10% dari tarif token input dasar (diskon 90%) untuk pembacaan cache. Ini mencerminkan penghematan komputasi.
4. Token Output: Token yang dihasilkan oleh LLM sebagai respon dikenakan biaya pada tarif token output standar model, terlepas dari apakah penyimpanan digunakan untuk input.

Contoh Tabel Harga (Model Claude Anthropic - tarif ilustratif):

(Catatan: Selalu rujuk ke halaman harga resmi Anthropic dan AWS Bedrock untuk tarif terbaru.)

Efektivitas biaya sangat bergantung pada seberapa sering Anda mendapatkan cache hit dibandingkan cache miss untuk awalan tertentu. Jika sebuah awalan besar digunakan kembali banyak kali, biaya awal yang lebih tinggi untuk penulisan cache dengan cepat diimbangi oleh penghematan substansial dari pembacaan cache berikutnya.

Keterbatasan Penyimpanan Permintaan

Walaupun kuat, penyimpanan permintaan memiliki keterbatasan dan faktor yang perlu dipertimbangkan:

Panjang Minimum yang Dapat Disimpan: Model sering kali memiliki persyaratan token minimum untuk sebuah awalan agar memenuhi syarat untuk penyimpanan. Permintaan yang lebih pendek dari batas ini tidak dapat disimpan, bahkan jika ditandai dengan cache_control.

• Anthropic Claude 3.7/3.5 Sonnet & Opus: Minimum 1024 token.
• Anthropic Claude 3.5/3 Haiku: Minimum 2048 token.

Invalidasi Cache (Cache Busting): Cache sangat sensitif terhadap perubahan dalam awalan. Setiap modifikasi akan merusak cache dan memaksa penulisan baru:

• Mengubah konten teks mana pun dalam blok system, tools, atau messages yang ditunjuk sebagai bagian dari awalan.
• Mengubah urutan atau jumlah definisi tool.
• Mengubah parameter tool_choice (misalnya, beralih dari auto ke alat tertentu).
• Menambahkan, menghapus, atau mengubah gambar dalam permintaan (untuk model multimodal).
• Mengubah parameter model lain yang memengaruhi pemrosesan awal juga dapat merusak cache (misalnya, pengaturan berpikir yang diperpanjang dari Anthropic dapat menghapus cache pesan).

Umur Cache (TTL): Ingat bahwa cache bersifat sementara (misalnya, TTL minimum 5 menit untuk Anthropic, diperbarui saat digunakan). Awalan yang tidak digunakan kembali dalam TTL akan kedaluwarsa. Saat ini, tidak ada cara untuk menghapus atau memperpanjang cache secara manual di luar perilaku otomatisnya.

Konkruensi: Jika Anda mengirim banyak permintaan identik secara bersamaan yang menargetkan sebuah awalan sebelum permintaan pertama selesai dan menulis entri ke cache, permintaan berikutnya mungkin menghasilkan cache miss hingga penulisan pertama selesai. Untuk memastikan hit dalam skenario paralel, Anda mungkin perlu menunggu respon pertama sebelum mengirim yang lain.

Model yang Didukung: Penyimpanan permintaan tidak tersedia secara universal di semua model atau penyedia. Selalu periksa dokumentasi untuk model spesifik yang ingin Anda gunakan. (Saat ini dikonfirmasi untuk berbagai model Claude 3 dan 3.5).

Debugging: Mengidentifikasi perubahan halus yang menyebabkan cache miss kadang bisa sulit. Perbandingan hati-hati dari konten awalan yang tepat antara panggilan diperlukan.

Praktik Terbaik untuk Penyimpanan yang Efektif

Untuk memaksimalkan manfaat penyimpanan permintaan:

1. Susun Permintaan dengan Cerdas: Tempatkan informasi yang paling stabil dan dapat digunakan kembali (permintaan sistem, instruksi, definisi alat, dokumen konteks, contoh few-shot) di awal urutan permintaan Anda. Tempatkan informasi dinamis yang sering berubah (kueri pengguna, putaran percakapan terbaru) setelah titik patah cache.
2. Identifikasi Titik Patah yang Optimal: Gunakan cache_control (atau mekanisme setara) dengan sengaja. Tandai akhir dari blok terbesar yang mungkin dari konten statis yang benar-benar. Jika menggunakan beberapa titik patah (seperti yang diizinkan oleh Anthropic), pertimbangkan berbagai tingkat stabilitas dalam struktur permintaan Anda.
3. Monitor Penggunaan Cache: Secara teratur periksa cache_creation_input_tokens dan cache_read_input_tokens dalam respon API Anda. Usahakan untuk mendapatkan rasio tinggi antara pembacaan dan penulisan seiring waktu. Jika Anda melihat sebagian besar penulisan, kemungkinan awalan Anda terlalu sering berubah, atau mungkin di bawah panjang minimum yang dapat disimpan.
4. Hindari Perubahan yang Tidak Perlu: Ingat bahwa bahkan perubahan kecil yang tampaknya tidak signifikan pada konten awalan (seperti menambahkan spasi atau mengubah tanda baca) akan merusak cache. Pastikan konsistensi dalam cara awalan dihasilkan.
5. Pertimbangkan Trade-off Biaya: Penyimpanan paling efektif untuk awalan yang panjang dan sering digunakan kembali. Jangan menyimpan awalan yang sangat pendek, karena potensi penghematan minimal dan mungkin tidak sebanding dengan kompleksitasnya. Hindari menyimpan input pengguna yang sangat bervariasi.
6. Uji dan Iterasi: Bereksperimenlah dengan berbagai struktur permintaan dan titik patah cache untuk menemukan strategi optimal untuk beban kerja dan pola penggunaan aplikasi spesifik Anda.

Kesimpulan

Penyimpanan permintaan adalah teknik optimisasi yang vital bagi siapa pun yang membangun aplikasi di atas model bahasa besar. Dengan menyimpan dan menggunakan kembali status komputasi dari awalan permintaan yang statis dengan cerdas, secara langsung mengatasi tantangan latensi dan biaya yang terkait dengan permintaan panjang atau berulang. Memahami cara penyimpanan bekerja, rincian implementasi spesifik untuk penyedia LLM pilihan Anda (seperti cache_control dari Anthropic), nuansa harga yang terkait, dan keterbatasannya memungkinkan Anda merancang aplikasi AI yang lebih efisien, responsif, dan ekonomis. Seiring dengan semakin kompleks dan luasnya kasus penggunaan LLM, memanfaatkan fitur seperti penyimpanan permintaan akan semakin penting untuk membangun solusi yang berkinerja tinggi dan berkelanjutan.