బిల్లు ఎందుకు భారీగా పెరిగింది

టీమ్ మొదట Generative AIని జోడించినప్పుడు, వారు ప్రతి యూజర్ రిక్వెస్ట్‌ను కొత్త మరియు అత్యంత సామర్థ్యం ఉన్న మోడల్‌కు పంపేవారు. ట్రాఫిక్ పెరిగేకొద్దీ, ప్రతి రిక్వెస్ట్‌కు అయ్యే ఖర్చు కూడా అదే స్థాయిలో పెరిగింది, మరియు CFO యొక్క స్ప్రెడ్‌షీట్ ప్రకారం ఖర్చు యూజర్ల పెరుగుదల కంటే వేగంగా పెరుగుతోంది. "కేవలం తక్కువ ధర ఉన్న మోడల్‌ను వాడండి" అనే సాధారణ పరిష్కారం ప్రొడక్షన్‌లో విఫలమవుతుంది, ఎందుకంటే వేర్వేరు క్వెరీలకు వేర్వేరు రీజనింగ్ స్థాయిలు అవసరమవుతాయి. అసలైన కీలక అంశం రిక్వెస్ట్‌ను ఎలా పంపిస్తున్నాము అనే దానిపై ఆధారపడి ఉంటుంది, ఎల్లప్పుడూ మోడల్‌ను ఉపయోగిస్తున్నాము అనే దానిపై కాదు.

డబ్బు ఆదా చేసే రూటింగ్ లేయర్‌ను నిర్మించడం

ఇంజనీర్ inference serviceని మరే ఇతర ప్రొడక్షన్ కాంపోనెంట్‌లాగా పరిగణించారు: tiers నిర్వచించడం, SLAs సెట్ చేయడం మరియు latency బడ్జెట్‌లను అమలు చేయడం. దీని ఫలితంగా ఏర్పడిన ఆర్కిటెక్చర్‌లో నాలుగు ముఖ్యమైన భాగాలు ఉన్నాయి, ఇవి కలిసి 95% ఖర్చు తగ్గింపును అందిస్తాయి.

Tiered routing

ఒక చిన్న ఫ్రంట్-ఎండ్ ప్రతి రిక్వెస్ట్‌ను దాని కష్టతరం ఆధారంగా వర్గీకరిస్తుంది. సుమారు 95% క్వెరీలు ఒక సాధారణ మోడల్‌ను ఉపయోగించే "చౌకైన" (cheap) టీయర్‌కు చేరుతాయి; కేవలం కష్టమైన 5% మాత్రమే ప్రీమియం మోడల్‌కు పంపబడతాయి. ఈ వర్గీకరణ రూల్-బేస్డ్ (ఉదాహరణకు: పొడవు, డొమైన్-స్పెసిఫిక్ కీవర్డ్స్ ఉండటం) కావచ్చు లేదా గత డేటా నుండి నేర్చుకోబడినది కావచ్చు. తక్కువ ఖర్చుతో కూడిన టీయర్‌ను డిఫాల్ట్‌గా ఉపయోగించడం వల్ల, చాట్‌బాట్ యొక్క నెలవారీ ఖర్చు $420 నుండి $28కి తగ్గింది.

Model right-sizing

టాస్క్ సంక్లిష్టతకు అనుగుణంగా మోడల్ సామర్థ్యాన్ని సరిపోల్చడం వల్ల అతిపెద్ద ఆదా లభిస్తుంది:

  • సింపుల్ చాట్ – ఫ్లాగ్‌షిప్ మోడల్‌కు బదులుగా లైట్‌వెయిట్ మోడల్‌ను ఉపయోగించడం (97.5% ఆదా).
  • Classification – మిడ్-సైజ్ మోడల్‌కు బదులుగా చౌకైన ప్రత్యామ్నాయాన్ని వాడటం (98.3% ఆదా).
  • Summarization – టాప్-టయర్ మోడల్‌ను మిడ్-రేంజ్ మోడల్‌తో భర్తీ చేయడం (97.2% ఆదా).

ఖచ్చితమైన మోడల్ పేర్లు ముఖ్యం కాదు; నిజంగా అవసరమైన కొన్ని క్వెరీల కోసం అత్యంత సామర్థ్యం ఉన్న మోడల్‌ను రిజర్వ్‌లో ఉంచడమే దీని ప్రధాన సూత్రం.

Smart caching

ప్రతి cache hit ఒక నెట్‌వర్క్ కాల్ మరియు API ఛార్జీని తగ్గిస్తుంది. ఒక డిస్ట్రిబ్యూటెడ్ Redis cache విజయవంతమైన సమాధానాలతో పాటు "తెలియదు" ("I don’t know") వంటి "నెగటివ్" సమాధానాలను కూడా నిల్వ చేస్తుంది. అదే సమాధానం లేని ప్రశ్న మళ్ళీ వచ్చినప్పుడు, సిస్టమ్ మోడల్‌ను రెండోసారి పిలవడానికి బదులుగా, సేవ్ చేసిన "I don’t know" సమాధానాన్ని తిరిగి ఇస్తుంది. వేల సంఖ్యలో రిక్వెస్ట్‌లు వచ్చినప్పుడు, ఇది ఒక్కటే బిల్లులో గణనీయమైన మొత్తాన్ని తగ్గిస్తుంది.

Prompt compression

పొడవైన ప్రాంప్ట్‌లు టోకెన్ వినియోగాన్ని పెంచుతాయి, ఇది నేరుగా ఖర్చుకు దారితీస్తుంది. టీమ్ క్లయింట్ సైడ్ లేదా ప్రీ-ప్రాసెసింగ్ దశలో ఒక చౌకైన summarizerని ఉపయోగిస్తుంది, దీనివల్ల ఖరీదైన మోడల్‌కు చేరుకోకముందే 2,000-టోకెన్ల కాంటెక్స్ట్‌ను సుమారు 400 టోకెన్లకు తగ్గిస్తారు. ఈ టోకెన్ తగ్గింపు అన్ని రిక్వెస్ట్‌లలోనూ వర్తిస్తుంది, దీనివల్ల యూజర్ అనుభవాన్ని మార్చకుండానే భారీ ఆదా లభిస్తుంది.

Strategic batching

Batching అనేది బహుళ స్వతంత్ర రిక్వెస్ట్‌లను ఒకే API కాల్‌గా సమూహపరుస్తుంది. దీని ప్రాథమిక సూత్రం సరళమైనది: ఒక యూజర్ సమాధానం కోసం వేచి చూస్తున్నట్లయితే, batch చేయవద్దు; ఒకవేళ రిక్వెస్ట్ బ్యాక్‌గ్రౌండ్‌లో నడుస్తుంటే (నైట్లీ రిపోర్ట్స్, షెడ్యూల్డ్ జాబ్స్), అన్నింటినీ batch చేయండి. కేవలం నైట్-టైమ్ batch జాబ్స్ ద్వారానే ఖర్చులో మరో 10-20% తగ్గుతుంది.

ఆప్టిమైజేషన్ లూప్‌ను పర్యవేక్షించడం

మీరు దేనినైతే కొలవలేరో, దానిని మెరుగుపరచలేరు. ఇంజనీర్ నాలుగు వారపు మెట్రిక్స్‌ను ఏర్పాటు చేశారు:

  1. టీయర్‌ల వారీగా ప్రతి రిక్వెస్ట్‌కు అయ్యే ఖర్చు.
  2. ప్రతి రూటింగ్ పాత్‌కు సంబంధించిన cache-hit రేటు.
  3. చౌకైన టీయర్‌ల నుండి ప్రీమియం టీయర్‌లకు వెళ్లే ఎస్కలేషన్ రేటు.
  4. ప్రతి కస్టమర్ సెగ్మెంట్‌కు అయ్యే ఖర్చు.

ఈ సంఖ్యలు మార్పులను (drift) బయటపెడతాయి—ఉదాహరణకు, ఎస్కలేషన్ రేటు పెరగడం అనేది క్లాసిఫికేషన్ లాజిక్ అతిగా ఉందని లేదా చౌకైన మోడల్ నాణ్యత క్షీణించిందని సూచించవచ్చు. టీమ్ ప్రతి వారం thresholds, మోడల్ అసైన్‌మెంట్‌లు మరియు cache పాలసీలపై పని చేస్తూ, ఖర్చు నియంత్రణను ఒక సంక్షోభ ప్రతిస్పందనలా కాకుండా ఒక అలవాటుగా మారుస్తుంది.

ముగింపు

రిక్వెస్ట్‌లను వర్గీకరించే, మోడల్‌లను right-size చేసే, చురుగ్గా క్యాషింగ్ చేసే, ప్రాంప్ట్‌లను కంప్రెస్ చేసే మరియు బ్యాక్‌గ్రౌండ్ పనులను బ్యాచ్ చేసే క్రమబద్ధమైన రూటింగ్ లేయర్, విశ్వసనీయతను కాపాడుతూనే AI-API ఖర్చును 95%