Amazon Bedrock आता डेव्हलपर्सना प्रॉम्प्टचा काही भाग कॅश (cache) करण्याची सुविधा देते, ज्यामुळे टोकन-वापर बिल ९०% पर्यंत कमी होऊ शकते आणि स्थिर प्रॉम्प्ट प्रीफिक्स (static prompt prefix) पुन्हा वापरणाऱ्या ॲप्लिकेशन्ससाठी प्रतिसादाचा विलंब (latency) ८५% पर्यंत कमी होऊ शकतो.

हा बदल का महत्त्वाचा आहे

मागणीनुसार लार्ज लँग्वेज मॉडेल्स चालवण्यासाठी प्रत्येक वेळी मॉडेलला टोकन्स पाठवताना खर्च येतो. चॅटबॉट्स, कोड असिस्टंट्स आणि डॉक्युमेंट-सर्च टूल्स अनेकदा तीच सिस्टम सूचना किंवा संदर्भ साहित्य पुन्हा पाठवतात, ज्यामुळे खर्च वाढतो आणि प्रतिसादाचा वेग मंदावतो.

प्रॉम्प्ट कॅशिंग कसे कार्य करते

Bedrock मध्ये एक “cacheable” फ्लॅग जोडला आहे जो डेव्हलपर्स प्रॉम्प्टच्या कोणत्याही भागाला जोडू शकतात—सहसा सिस्टम-लेव्हल सूचना, लांब बॅकग्राउंड डॉक्युमेंट्स किंवा टूल डेफिनिशन्स जे सेशन दरम्यान कधीही बदलत नाहीत. जेव्हा एखादी विनंती (request) येते, तेव्हा Bedrock तो फ्लॅग केलेला भाग साठवलेल्या एंट्रीशी जुळतो का ते तपासते. जर तो जुळला, तर सेवा त्या भागाचे पुन्हा एन्कोडिंग आणि मॉडेलद्वारे पुन्हा रन करणे टाळते आणि त्याऐवजी कॅशमधून आधीच तयार केलेली (pre-computed) माहिती घेते.

आकडेवारी

  • इनपुट-टोकन खर्च: ९०% पर्यंत कपात, कारण कॅश केलेला प्रीफिक्स आता प्रत्येक कॉलवर टोकन्स वापरत नाही.
  • लॅटन्सी (Latency): ८५% पर्यंत वेगवान, कारण स्थिर भागासाठी मॉडेलचे जड काम (heavy lifting) टाळले जाते.

सर्वोत्तम वापराची परिस्थिती

जेव्हा प्रॉम्प्टमध्ये एक मोठा, न बदलणारा भाग आणि त्यानंतर वापरकर्त्याचा एक छोटा, बदलणारा प्रश्न असतो, तेव्हा हे फीचर अत्यंत प्रभावी ठरते. सामान्य पॅटर्नमध्ये खालील गोष्टींचा समावेश होतो:

  • Retrieval-augmented generation (RAG) पाइपलाइन्स, ज्या प्रत्येक क्वेरीच्या सुरुवातीला एखादे डॉक्युमेंट जोडतात.
  • कस्टमर-सपोर्ट बॉट्स, जे नेहमी एकाच पॉलिसी स्टेटमेंट किंवा टोन-सेटिंग टेक्स्टने सुरू होतात.
  • कोडिंग असिस्टंट्स, जे डेव्हलपरच्या कोड स्निपेटपूर्वी एक निश्चित लँग्वेज-टूल डेफिनेशन लोड करतात.

डेव्हलपर्सना काय बदलण्याची गरज आहे

डेव्हलपर्सना प्रॉम्प्टची पुनर्रचना करावी लागेल जेणेकरून स्थिर मजकूर अगदी सुरुवातीला असेल आणि प्रत्येक कॉलमध्ये तो तंतोतंत (byte-for-byte) सारखाच राहील. कॅश केलेल्या प्रीफिक्सनंतर वापरकर्त्याचा बदलणारा इनपुट येईल. यासाठी मॉडेल बदलण्याची गरज नाही; तेच Bedrock एंडपॉइंट्स विनंती हाताळतात.

कोणाला फायदा होईल आणि कोणी सावध राहावे

याचा फायदा केवळ अशा वर्कलोड्सना होतो जिथे प्रीफिक्स खरोखर स्थिर राहतो. जे ॲप्लिकेशन्स वापरकर्त्यानुसार सिस्टम सूचना वैयक्तिकृत करतात किंवा वारंवार संदर्भ (context) बदलतात, त्यांना फारसा फायदा होणार नाही आणि त्यांना मिळणाऱ्या अल्प फायद्याच्या तुलनेत वाढलेली प्रॉम्प्टिंग जटिलता तपासावी लागेल.

थोडक्यात सांगायचे तर: जर त्यांचे ॲप्लिकेशन्स पुन्हा वापरण्यायोग्य प्रॉम्प्ट प्रीफिक्स वेगळा करू शकत असतील, तर प्रॉम्प्ट कॅशिंग Bedrock वापरकर्त्यांना AI ऑपरेटिंग खर्च कमी करण्यासाठी आणि प्रतिसादाचा वेळ सुधारण्यासाठी एक सोपा मार्ग देते.