𝗛𝗼𝘄 𝗜 𝗖𝘂𝘁 𝗢𝘂𝗿 𝗔𝗜 𝗔𝗣𝗜 𝗕𝗶𝗹𝗹 𝗶𝗻 𝗛𝗮𝗹𝗳 𝗪𝗵𝗶𝗹𝗲 𝗛𝗶𝘁𝘁𝗶𝗻𝗴 𝗽𝟵𝟵 𝗦𝗟𝗔𝘀
எங்களது AI கட்டணம் மிக வேகமாக வளர்ந்து வந்தது. எங்களது CFO இதைத் தாங்க முடியாத செலவு விகிதம் (unsustainable burn rate) என்று அழைத்தார். அந்த நேரத்தில், நாங்கள் அனைத்திற்கும் GPT-4o பயன்படுத்தினோம். அது சிறப்பாகச் செயல்பட்டது, ஆனால் செலவுகள் மிக அதிகமாக இருந்தன மற்றும் p99 latency சீராக இல்லை.
AI மாடல் தேர்வை ஒரு சிஸ்டம் டிசைன் (system design) பிரச்சனையாகக் கருத முடிவு செய்தேன். சிறந்த மாடலைத் தேடுவதை நிறுத்திவிட்டு, எங்களது குறிப்பிட்ட SLAs-க்கு ஏற்ற சிறந்த மாடலைத் தேடத் தொடங்கினேன்.
முதலில் நான் தெளிவான இலக்குகளை நிர்ணயித்தேன்: • சாட்டிற்கு (chat) 1.5 வினாடிகளுக்கும் குறைவான p99 latency • 99.9% availability • Multi-region failover • உச்சபட்ச சுமையின் (peak load) 3 மடங்கு Throughput capacity
இந்த எண்கள் கிடைத்தவுடன், தீர்வு தெளிவாகத் தெரிந்தது. ஒரு டோக்கனுக்கு (token) மிகக் குறைந்த விலையுள்ள மாடல் எப்போதும் தயாரிப்புப் பயன்பாட்டிற்கு (production) சிறந்த தேர்வாக இருக்காது. ஒரு மலிவான மாடல் உங்கள் latency-ஐ இருமடங்காக்கினால், நீங்கள் பயனர்களை இழப்பீர்கள்.
நான் பல மாடல்களை ஒப்பிட்டுப் பார்த்தேன். விலை வித்தியாசம் மிகப்பெரியதாக இருந்தது. GPT-4o ஒரு மில்லியன் அவுட்புட் டோக்கன்களுக்கு $10.00 செலவாகும். GLM-4 Plus-க்கு $0.80 மட்டுமே ஆகும். சுருக்கம் (summarization) மற்றும் தரவு பிரித்தெடுத்தல் (extraction) போன்ற எங்களது குறிப்பிட்ட பணிகளுக்கு GLM-4 Plus, GPT-4o அளவுக்கு ஏறத்தாழச் சிறப்பாகச் செயல்படுவதை எங்களது சோதனைகள் காட்டின.
இதை நிர்வகிக்க நான் ஒரு routing layer-ஐ உருவாக்கினேன். இந்த சிஸ்டம் பின்வரும் விதிகளைப் பின்பற்றுகிறது: • பணிச்சுமையின் (workload) வகையைப் பொறுத்து கோரிக்கைகளை (requests) வழிநடத்துதல் (Route) • latency அதிகரித்தால் ஒரு fallback மாடலைப் பயன்படுத்துதல் • டிராஃபிக்கை (traffic) பல்வேறு ரீஜியன்களுக்குப் (regions) பிரித்து அனுப்புதல் • அடிக்கடி கேட்கப்படும் கோரிக்கைகளை கேச் (cache) செய்தல்
நான் ஒரு Redis cache-ஐயும் சேர்த்தேன். இதன் hit rate ஒரு வாரத்தில் 40%-ஐ எட்டியது. இது மீண்டும் மீண்டும் கேட்கப்படும் கேள்விகளுக்கான (repeat queries) டோக்கன் செலவைக் குறைத்ததுடன், latency-ஐ 1.4 வினாடிகளிலிருந்து 200 மில்லி விநாடிகளாகக் குறைத்தது.
முடிவுகள்: • மாதாந்திர inference செலவு 58% குறைந்தது • p99 latency 1.6s-லிருந்து 1.18s ஆகக் குறைந்தது • Uptime 99.95%-இல் நிலைத்திருந்தது • Cache hit rate 42%-ஐ எட்டியது
நான் கற்றுக்கொண்ட மூன்று பாடங்கள்:
- உங்களுக்கென ஒரு evaluation suite-ஐ உருவாக்குங்கள். பொதுவான benchmarks-களை நம்பாதீர்கள். உங்கள் உண்மையான production தரவைப் பயன்படுத்துங்கள்.
- rate limits-ஐ உன்னிப்பாகக் கவனியுங்கள். ரீஜனல் டிராஃபிக் (Regional traffic) எதிர்பாராத உயர்வுகளை (spikes) ஏற்படுத்தலாம்.
- ஒரு kill switch-ஐ உருவாக்குங்கள். ஒரு தவறான prompt, டோக்கன் பயன்பாட்டில் மிகப்பெரிய உயர்வை ஏற்படுத்தக்கூடும். அதிகபட்ச டோக்கன்களுக்கான வரம்பு (cap on max tokens) ஒருமுறை எங்களை $14,000 இழப்பிலிருந்து காப்பாற்றியது.
உங்கள் AI கட்டணம் மிக அதிகமாக இருந்தால், முதலில் உங்கள் SLA-வை வரையறுக்கவும். உண்மையான டிராஃபிக்கிலிருந்து ஒரு evaluation suite-ஐ உருவாக்கவும். பின்னர், நீங்கள் தற்போது கவனிக்காமல் விட்டுவிட்ட மாடல்களின் விலையைப் பார்க்கவும்.
Source: https://dev.to/bolddeck/how-i-cut-our-ai-api-bill-in-half-while-hitting-p99-slas-1l05
Optional learning community: https://t.me/GyaanSetuAi