Amazon Bedrock இப்போது டெவலப்பர்கள் ஒரு ப்ராம்ப்ட்டின் (prompt) சில பகுதிகளைத் தற்காலிக சேமிப்பில் (cache) வைக்க அனுமதிக்கிறது. இது நிலையான ப்ராம்ப்ட் முன்னொட்டை (static prompt prefix) மீண்டும் பயன்படுத்தும் பயன்பாடுகளுக்கு, டோக்கன் பயன்பாட்டுச் செலவை 90% வரை குறைக்கவும், பதிலளிக்கும் தாமதத்தை (latency) 85% வரை குறைக்கவும் உதவுகிறது.

இந்த மாற்றம் ஏன் முக்கியமானது

தேவைக்கேற்ப பெரிய மொழி மாதிரிகளை (large language models) இயக்குவதற்கு, ஒவ்வொரு முறையும் டோக்கன்கள் மாதிரியிடம் அனுப்பப்படும்போது பணம் செலவாகும். சாட்பாட்கள் (Chatbots), கோட் அசிஸ்டண்ட்கள் (code assistants) மற்றும் ஆவணத் தேடல் கருவிகள் பெரும்பாலும் ஒரே மாதிரியான சிஸ்டம் அறிவுறுத்தல்கள் அல்லது குறிப்புப் பொருட்களை மீண்டும் மீண்டும் அனுப்புவதால், செலவு அதிகரிப்பதோடு பதிலளிக்கும் வேகமும் குறைகிறது.

ப்ராம்ப்ட் கேச்சிங் (prompt caching) எவ்வாறு செயல்படுகிறது

Bedrock ஒரு “cacheable” ஃபிளாக் (flag)-ஐச் சேர்க்கிறது. டெவலப்பர்கள் இதை ப்ராம்ப்ட்டின் எந்தப் பகுதியிலும் இணைக்கலாம்—பொதுவாக சிஸ்டம்-நிலை அறிவுறுத்தல்கள், நீண்ட பின்னணி ஆவணங்கள் அல்லது ஒரு அமர்வின் (session) போது மாறாத டூல் வரையறைகள் (tool definitions) ஆகியவற்றில் இதைப் பயன்படுத்தலாம். ஒரு கோரிக்கை வரும்போது, Bedrock அந்த ஃபிளாக் செய்யப்பட்ட பகுதி சேமிக்கப்பட்ட உள்ளீட்டுடன் பொருந்துகிறதா என்று சரிபார்க்கிறது. அவ்வாறு பொருந்தினால், அந்தப் பகுதியை மீண்டும் என்கோடிங் செய்வதையும் (re-encoding) மாடலில் மீண்டும் இயக்குவதையும் தவிர்க்கிறது; அதற்குப் பதிலாக கேச்சிலிருந்து (cache) ஏற்கனவே கணக்கிடப்பட்ட பிரதிநிதித்துவத்தை எடுக்கிறது.

புள்ளிவிவரங்கள்

  • உள்ளீட்டு-டோக்கன் செலவு (Input-token cost): 90% வரை குறைவு, ஏனெனில் கேச் செய்யப்பட்ட முன்னொட்டு ஒவ்வொரு முறையும் டோக்கன்களைப் பயன்படுத்துவதில்லை.
  • தாமதம் (Latency): 85% வரை வேகம் அதிகரிக்கிறது, ஏனெனில் நிலையான பகுதிக்கு மாடலின் கடினமான வேலைகள் தவிர்க்கப்படுகின்றன.

சிறந்த பயன்பாட்டுச் சூழல்கள்

ஒரு ப்ராம்ப்ட்டில் பெரிய மாற்றமில்லாத பகுதி மற்றும் அதைத் தொடர்ந்து ஒரு சிறிய, மாறுபடும் பயனர் வினவல் (user query) இருக்கும்போது இந்த அம்சம் சிறப்பாகச் செயல்படுகிறது. பொதுவான முறைகள் பின்வருமாறு:

  • ஒவ்வொரு வினவலுக்கும் ஒரு பெறப்பட்ட ஆவணத்தைச் சேர்க்கும் Retrieval-augmented generation (RAG) பைப்லைன்கள்.
  • எப்போதும் ஒரே மாதிரியான கொள்கை அறிக்கை அல்லது தொனி அமைக்கும் உரத்துடன் தொடங்கும் வாடிக்கையாளர் சேவை பாட்கள் (Customer-support bots).
  • டெவலப்பரின் குறியீட்டிற்கு (snippet) முன்னதாக ஒரு நிலையான மொழி-டூல் வரையறையை (language-tool definition) ஏற்றும் கோடிங் அசிஸ்டண்ட்கள்.

டெவலப்பர்கள் மாற்ற வேண்டியவை

நிலையான உள்ளடக்கம் ப்ராம்ப்ட்டின் தொடக்கத்திலேயே இருக்குமாறும், ஒவ்வொரு அழைப்பிலும் அது பைட்-பைட்டாக (byte-for-byte) ஒரே மாதிரியாக இருக்குமாறும் டெவலப்பர்கள் ப்ராம்ப்ட்டை வரிசைப்படுத்த வேண்டும். மாறுபடும் பயனர் உள்ளீடு, கேச் செய்யப்பட்ட முன்னொட்டைத் தொடர்ந்து வர வேண்டும். மாடலை மாற்ற வேண்டிய அவசியம் இல்லை; அதே Bedrock எண்ட்பாயிண்ட்கள் (endpoints) கோரிக்கையைக் கையாளும்.

யாருக்குப் பயன், யார் கவனமாக இருக்க வேண்டும்

முன்னொட்டு (prefix) உண்மையிலேயே நிலையாக இருக்கும் வேலைப்பளுவிற்கு (workloads) மட்டுமே இதன் சாதகமான பலன்கள் பொருந்தும். ஒவ்வொரு பயனருக்கும் சிஸ்டம் அறிவுறுத்தல்களைத் தனிப்பயனாக்கும் அல்லது அடிக்கடி சூழலை (context) மாற்றும் பயன்பாடுகளுக்குப் பலன் குறைவாகவே இருக்கும்; மேலும், சிறிய லாபத்திற்காக ப்ராம்ப்ட் சிக்கலை அதிகரிப்பதைத் தவிர்க்க வேண்டும்.

சுருக்கமாக: ஒரு பயன்பாட்டால் மீண்டும் பயன்படுத்தக்கூடிய ப்ராம்ப்ட் முன்னொட்டைத் தனிமைப்படுத்த முடிந்தால், AI செயல்பாட்டுச் செலவுகளைக் குறைக்கவும் மற்றும் பதிலளிக்கும் நேரத்தை மேம்படுத்தவும் ப்ராம்ப்ட் கேச்சிங் Bedrock பயனர்களுக்கு ஒரு நேரடியான வாய்ப்பை வழங்குகிறது.