AI அமைப்புகளில் Rate Limiting மற்றும் Circuit Breakers
விநியோகிக்கப்பட்ட (Distributed) AI அமைப்புகள் சிக்கலானவை. அவை மிகப்பெரிய கோரிக்கை அளவுகளையும் (request volumes) மற்றும் கனமான மாடல் இன்ஃபரன்ஸ் (model inference) பணிகளையும் கையாளுகின்றன. நீங்கள் GPU கிளஸ்டர்கள், தரவுத்தளங்கள் மற்றும் மூன்றாம் தரப்பு API-களைச் சார்ந்துள்ளீர்கள். ஒரு தவறான கூறு அல்லது திடீரென அதிகரிக்கும் போக்குவரத்து (traffic spike) உங்கள் முழு அமைப்பையும் முடக்கிவிடக்கூடும்.
உங்கள் அமைப்பைப் பாதுகாக்க உங்களுக்கு இரண்டு கருவிகள் தேவை: rate limiting மற்றும் circuit breakers.
Rate Limiting Rate limiting என்பது ஒரு தனி பயனர் அல்லது சேவை அதிகப்படியான வளங்களைப் பயன்படுத்துவதைத் தடுக்கிறது. இது அனைவருக்கும் சமமான அணுகலை உறுதி செய்கிறது.
பொதுவான முறைகள்:
- Token Bucket: AI-க்கு சிறந்தது. இது ஒரு நிலையான சராசரியைப் பராமரிக்கும் அதே வேளையில், குறுகிய காலத் தீவிரச் செயல்பாடுகளை (short bursts) அனுமதிக்கிறது.
- Leaky Bucket: கோரிக்கைகளின் நிலையான ஓட்டத்தைப் பராமரிக்கிறது.
- Fixed Window: எளிமையானது, ஆனால் ஒரு புதிய காலக்கட்டத்தின் (window) தொடக்கத்தில் திடீர் அதிகரிப்புகளை ஏற்படுத்தக்கூடும்.
- Sliding Window: Fixed windows-ஐ விட துல்லியமானது.
AI-க்கான ஒரு முக்கிய குறிப்பு: கோரிக்கைகளை (requests) மட்டும் கணக்கிடாமல், டோக்கன் எண்ணிக்கையின் (token count) அடிப்படையில் கட்டுப்படுத்துங்கள். 10 டோக்கன்கள் கொண்ட ஒரு ப்ராம்ப்ட்டை விட, 4,000 டோக்கன்கள் கொண்ட ஒரு ப்ராம்ப்ட் அதிக வளங்களைப் பயன்படுத்தும்.
Circuit Breakers ஒரு circuit breaker என்பது உங்கள் GPU சர்வர் அல்லது vector database போன்ற சேவைகளுக்கான அழைப்புகளைக் கண்காணிக்கிறது. ஒரு சேவை பலமுறை தோல்வியடைந்தால், breaker திறக்கப்படும் (opens). இது அந்தச் சேவைக்கான அனைத்து அழைப்புகளையும் உடனடியாக நிறுத்திவிடும். இது முழு அமைப்பும் முடங்குவதைத் தடுக்கிறது.
மின்சுற்று மூன்று நிலைகளைக் கொண்டுள்ளது:
- Closed: அனைத்தும் இயல்பாகச் செயல்படுகின்றன.
- Open: சேவை தோல்வியடைகிறது. அழைப்புகள் விரைவாகத் தோல்வியடைகின்றன அல்லது ஒரு மாற்று வழியை (fallback) பயன்படுத்துகின்றன.
- Half-Open: சேவை மீண்டும் இயல்பு நிலைக்குத் திரும்பியதா என்பதைச் சோதிக்க அமைப்பு அந்தச் சேவையைச் சோதிக்கும்.
சிறந்த நடைமுறைகள்:
- மெதுவான அழைப்புகளைக் கண்காணிக்கவும். ஒரு LLM அதிக நேரம் எடுத்துக் கொண்டால், அதை ஒரு தோல்வியாகக் கருதவும்.
- பிழை வகைகளைப் பிரிக்கவும். 400 Bad Request போன்ற பயனர் பிழைகளுக்காக breaker-ஐத் தூண்ட வேண்டாம். இணைப்புப் பிழைகள் (connection errors) அல்லது காலாவதி (timeouts) நேரங்களுக்காக மட்டுமே அதைத் தூண்டவும்.
Optional learning community: https://t.me/GyaanSetuAi