બિલ કેમ આટલું વધી ગયું
જ્યારે ટીમે સૌપ્રથમ generative AI ઉમેર્યું, ત્યારે તેઓ દરેક વપરાશકર્તાની વિનંતી (request) નવીનતમ અને સૌથી સક્ષમ મોડેલને મોકલતા હતા. જેમ જેમ ટ્રાફિક વધ્યો, તેમ તેમ પ્રતિ-વિનંતી ખર્ચ પણ તેટલી જ ઝડપે વધ્યો, અને CFO ની સ્પ્રેડશીટ દર્શાવતી હતી કે ખર્ચ વપરાશકર્તાના વિકાસ કરતા વધુ ઝડપથી વધી રહ્યો છે. સામાન્ય ઝડપી ઉકેલ—"ફક્ત સસ્તું મોડેલ વાપરો"—પ્રોડક્શનમાં નિષ્ફળ જાય છે કારણ કે વિવિધ ક્વેરીઝ માટે અલગ-અલગ તર્ક કરવાની ક્ષમતા (reasoning levels) ની જરૂર હોય છે. સાચું પરિબળ એ છે કે વિનંતી કેવી રીતે મોકલવામાં આવે છે, નહીં કે હંમેશા કયું મોડેલ વાપરવામાં આવે છે.
પૈસા બચાવતું રાઉટિંગ લેયર બનાવવું
એન્જિનિયરે inference service ને અન્ય કોઈપણ પ્રોડક્શન ઘટક તરીકે ગણ્યું: સ્તરો (tiers) વ્યાખ્યાયિત કરો, SLAs સેટ કરો અને લેટન્સી બજેટ લાગુ કરો. તેના પરિણામે તૈયાર થયેલી આર્કિટેક્ચરમાં ચાર મુખ્ય ભાગો છે જે સાથે મળીને 95% ઘટાડો લાવે છે.
સ્તરિત રાઉટિંગ (Tiered routing)
એક નાનું ફ્રન્ટ-એન્ડ દરેક આવતી વિનંતીને તેની મુશ્કેલી મુજબ વર્ગીકૃત કરે છે. અંદાજે 95% ક્વેરીઝ "સસ્તા" સ્તરમાં જાય છે જે એક સામાન્ય મોડેલ ચલાવે છે; માત્ર સૌથી અઘરી 5% ક્વેરીઝને પ્રીમિયમ મોડેલ પર મોકલવામાં આવે છે. આ વર્ગીકરણ નિયમ-આધારિત (દા.ત., લંબાઈ, ડોમેન-વિશિષ્ટ કીવર્ડ્સની હાજરી) હોઈ શકે છે અથવા ઐતિહાસિક ડેટા પરથી શીખી શકાય છે. ઓછા ખર્ચવાળા સ્તરને ડિફોલ્ટ તરીકે રાખવાથી, ચેટબોટનો માસિક ખર્ચ $420 થી ઘટીને $28 થઈ ગયો.
મોડેલનું યોગ્ય કદ (Model right-sizing)
કાર્યની જટિલતા મુજબ મોડેલની ક્ષમતા મેળવવાથી સૌથી વધુ બચત થાય છે:
- સરળ ચેટ – ફ્લેગશિપ મોડેલને બદલે લાઇટવેઇટ મોડેલનો ઉપયોગ કરો (97.5% બચત).
- વર્ગીકરણ (Classification) – મધ્યમ કદના મોડેલને બદલે સસ્તું વિકલ્પ વાપરો (98.3% બચત).
- સારાંશ (Summarization) – ટોપ-ટિયર મોડેલને બદલે મધ્યમ શ્રેણીના મોડેલનો ઉપયોગ કરો (97.2% બચત).
ચોક્કસ મોડેલના નામ મહત્વના નથી; મુખ્ય સિદ્ધાંત એ છે કે જે થોડી ક્વેરીઝને ખરેખર જરૂર હોય તેના માટે સૌથી સક્ષમ મોડેલને અનામત રાખવું.
સ્માર્ટ કેશિંગ (Smart caching)
દરેક કેશ હિટ (cache hit) એક નેટવર્ક કોલ અને API ચાર્જ ઘટાડે છે. એક ડિસ્ટ્રિબ્યુટેડ Redis કેશ સફળ જવાબો તેમજ "નકારાત્મક" જવાબો ("મને ખબર નથી") ને સ્ટોર કરે છે. જ્યારે એ જ વણઉત્તરી પ્રશ્ન ફરીથી આવે છે, ત્યારે સિસ્ટમ બીજી વાર મોડેલને બોલાવવાને બદલે કેશ કરેલ "મને ખબર નથી" જવાબ આપે છે. હજારો વિનંતીઓ દરમિયાન, આ એકલું જ બિલમાં નોંધપાત્ર ઘટાડો કરે છે.
પ્રોમ્પ્ટ કમ્પ્રેશન (Prompt compression)
લાંબા પ્રોમ્પ્ટ્સ ટોકન વપરાશ વધારે છે, જે સીધો ખર્ચમાં પરિણમે છે. ટીમ ક્લાયન્ટ સાઇડ પર અથવા પ્રી-પ્રોસેસિંગ સ્ટેપમાં એક સસ્તું સમરાઇઝર ચલાવે છે, જે મોંઘા મોડેલ સુધી પહોંચતા પહેલા 2,000-ટોકન સંદર્ભને ઘટાડીને લગભગ 400 ટોકન કરી દે છે. ટોકનનો આ ઘટાડો તમામ વિનંતીઓ પર લાગુ પડે છે, જેનાથી વપરાશકર્તાના અનુભવમાં ફેરફાર કર્યા વિના મોટી બચત થાય છે.
વ્યૂહાત્મક બેચિંગ (Strategic batching)
બેચિંગ (Batching) એક જ API કોલમાં અનેક સ્વતંત્ર વિનંતીઓને જૂથબદ્ધ કરે છે. તેનો સામાન્ય નિયમ સરળ છે: જો વપરાશકર્તા જવાબની રાહ જોઈ રહ્યો હોય, તો બેચિંગ ન કરો; જો વિનંતી બેકગ્રાઉન્ડમાં ચાલતી હોય (રાત્રિના રિપોર્ટ્સ, શેડ્યુલ કરેલા કામો), તો બધું જ બેચ કરો. માત્ર રાત્રિના બેચ જોબ્સ જ ખર્ચમાં વધુ 10-20% ઘટાડો કરે છે.
ઓપ્ટિમાઇઝેશન લૂપનું મોનિટરિંગ
તમે જેનું માપન નથી કરી શકતા તેને સુધારી શકતા નથી. એન્જિનિયરે ચાર સાપ્તાહિક મેટ્રિક્સ સેટ કર્યા:
- સ્તર મુજબ પ્રતિ વિનંતી ખર્ચ.
- દરેક રાઉટિંગ પાથ માટે કેશ-હિટ રેટ.
- સસ્તાથી પ્રીમિયમ સ્તરોમાં એસ્કેલેશન રેટ.
- દરેક ગ્રાહક સેગમેન્ટ દીઠ ખર્ચ.
આ આંકડા ફેરફારો (drift) દર્શાવે છે—દા.ત., વધતો જતો એસ્કેલેશન રેટ એ સંકેત આપી શકે છે કે વર્ગીકરણ લોજિક ખૂબ જ આક્રમક છે અથવા સસ્તા મોડેલની ગુણવત્તા ઘટી ગઈ છે. ટીમ દર અઠવાડિયે થ્રેશોલ્ડ, મોડેલ એસાઇનમેન્ટ અને કેશ પોલિસી પર કામ કરે છે, જેનાથી ખર્ચ નિયંત્રણ એ કટોકટીના પ્રતિભાવને બદલે એક આદત બની જાય છે.
મુખ્ય વાત (Takeaway)
એક શિસ્તબદ્ધ રાઉટિંગ લેયર જે વિનંતીઓને વર્ગીકૃત કરે છે, મોડેલનું યોગ્ય કદ કરે છે, આક્રમક રીતે કેશ કરે છે, પ્રોમ્પ્ટને કમ્પ્રે