செலவு அல்லது தாமதத்தை (latency) அதிகரிக்காமல் உங்கள் தயாரிப்பில் ஒரு LLM-ஐ எவ்வாறு இணைப்பது

ஒரு AI டெமோவை உருவாக்குவது எளிது. ஒரு API சாவியைப் (key) பெற்று, ஒரு ப்ராம்ப்ட் (prompt) எழுதி, அதை உங்கள் குழுவினருக்குக் காட்டலாம்.

பிறகு அதை நீங்கள் வெளியிடுகிறீர்கள். பயனர்களின் வருகை (traffic) தொடங்குகிறது. உங்கள் செலவுகள் அதிரடியாக உயர்கின்றன மற்றும் தாமதம் (latency) அதிகரிக்கிறது.

ஒரு டெமோவிலிருந்து உண்மையான தயாரிப்பிற்கு மாறுவதற்கு செலவு மற்றும் தாமத மேலாண்மை (cost and latency engineering) அவசியம். அதைச் செய்வது எப்படி என்று இங்கே பார்ப்போம்.

உங்கள் வெளியீட்டைக் (output) கட்டுப்படுத்துங்கள்

பெரும்பாலான API-கள் டோக்கன்களின் (tokens) அடிப்படையில் கட்டணம் வசூலிக்கின்றன. இன்புட் டோக்கன்களை விட அவுட்புட் டோக்கன்களுக்கு அதிகக் கட்டணம் வசூலிக்கப்படும்.

மக்கள் ப்ராம்ப்ட்களைச் சுருக்குவதற்கு நேரம் செலவிடுகிறார்கள், ஆனால் மாடல் தேவையில்லாமல் நீண்ட விளக்கங்களை அளிப்பதை அனுமதிக்கிறார்கள். இது ஒரு தவறு.

பணம் மற்றும் நேரத்தைச் சேமிக்க, வெளியீட்டைக் கட்டுப்படுத்துங்கள்:

• JSON கோரிக்கையை முன்வையுங்கள்.
• ஒரு வாக்கியத்தை மட்டும் கேட்கவும்.
• max_tokens வரம்பை நிர்ணயிக்கவும்.
• மாடல் சுருக்கமாகப் பதிலளிக்கச் சொல்லுங்கள்.

குறுகிய பதில்கள் வேகமானவை மற்றும் மலிவானவை.

தேவையற்ற அழைப்புகளைத் (calls) தவிர்க்கவும்

சேமிப்பதற்கான சிறந்த வழி, மாடலை அழைக்காமல் இருப்பதே ஆகும்.

• கேச்சிங் (caching) பயன்படுத்தவும்: பொதுவான கேள்விகளுக்கான பதில்களைச் சேமித்து வைக்கவும். கேள்விகள் ஒரே மாதிரியாக இருந்து, ஆனால் சரியாக இல்லையென்றால், ஒரு semantic cache உதவக்கூடும்.
• ரூட்டிங் (routing) பயன்படுத்தவும்: எளிமையான பணிகளுக்கு உங்கள் சிறந்த மாடலைப் பயன்படுத்த வேண்டாம். வகைப்படுத்துதலுக்கு (classification) ஒரு சிறிய, மலிவான மாடலைப் பயன்படுத்தவும். சிக்கலான பணிகளுக்கு விலையுயர்ந்த மாடலைச் சேமித்து வைக்கவும்.

பயனர் அனுபவத்தை (user experience) மேம்படுத்துங்கள்

ஒரு பதில் கிடைக்க நேரம் எடுத்தால், அது வேகமாக நடப்பது போன்ற உணர்வை ஏற்படுத்துங்கள்.

• டோக்கன்களை ஸ்ட்ரீம் (stream) செய்யவும்: வார்த்தைகள் உருவாகும்போதே அவற்றைக் காட்டவும். இது காத்திருக்கும் நேரத்தைக் குறைக்கும்.
• முன்னேற்றத்தைக் காட்டவும்: ஒரு பணி பல நிலைகளைக் கொண்டிருந்தால், என்ன நடக்கிறது என்பதைப் பயனருக்குத் தெரியப்படுத்துங்கள். வெறும் சுழலும் சக்கரம் (spinner) காட்டுவதற்குப் பதிலாக, "Searching documents..." போன்ற உரையைப் பயன்படுத்தவும்.

"Tail" தாமதத்தை (latency) நிர்வகிக்கவும்

சில கோரிக்கைகள் எப்போதும் மெதுவாகவே இருக்கும். அவை உங்கள் தயாரிப்பைப் பாதிக்க அனுமதிக்காதீர்கள்.

• டைம்அவுட்களை (timeouts) நிர்ணயிக்கவும்: ஒரு கோரிக்கை நீண்ட நேரம் எடுத்தால் என்ன செய்ய வேண்டும் என்பதைத் தீர்மானிக்கவும். ஒரு மாற்று வழி (fallback) அல்லது சிறிய மாடலைப் பயன்படுத்தவும்.
• ரீட்ரைகளை (retries) பயன்படுத்தவும்: சிறிய பிழைகளுக்கு ரீட்ரைகளைச் சேர்க்கவும், ஆனால் அவற்றிற்கு ஒரு வரம்பை நிர்ணயிக்கவும்.
• சர்க்யூட் பிரேக்கர்களை (circuit breakers) பயன்படுத்தவும்: ஒரு சேவை வழங்குநர் (provider) செயலிழந்தால், நீண்ட நேரக் காத்திருப்பதைத் தவிர்க்க உடனடியாக கோரிக்கைகளை அனுப்புவதை நிறுத்தவும்.

உங்கள் தரவைக் கண்காணிக்கவும்

நீங்கள் அளவிடாத ஒன்றைத் திருத்த முடியாது. ஒவ்வொரு கோரிக்கைக்கும் இந்த மூன்று எண்களையும் பதிவு செய்யவும்:

• இன்புட் டோக்கன்கள் (Input tokens).
• அவுட்புட் டோக்கன்கள் (Output tokens).
• மொத்தத் தாமதம் (Total latency).

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

LLM-ஐ ஒரு மந்திரமாகப் பார்ப்பதை நிறுத்துங்கள். அதை நீங்கள் நிர்வகிக்க வேண்டிய ஒரு மெதுவான, விலையுயர்ந்த சார்பு (dependency) என்று கருதுங்கள்.

Source: https://dev.to/muhammadzainnaseer/how-to-put-an-llm-in-your-product-without-wrecking-your-costs-or-your-latency-89a

Optional learning community: https://t.me/GyaanSetuAi