inference की लागत प्रोडक्ट की कमाई से ज्यादा हो गई है। quality बर्बाद किए बिना उसे कैसे घटाएंगे?

प्रति request लागत नापिए और देखिए वह कहां जमा है, क्योंकि traffic आम तौर पर टेढ़ा होता है। फिर मोटे तौर पर इस क्रम में लगाइए: दोहराई गई या लगभग एक जैसी requests का caching, cascading ताकि सस्ता मॉडल आसान बहुमत संभाले और सिर्फ संदेह वाले मामले ऊपर भेजे, quantization और compiled runtime, सही आकार का hardware ढंग की batching के साथ, और आखिर में वह काम काटना जिसे नीचे कोई इस्तेमाल ही नहीं करता।

मैं प्रति request लागत निकालकर उसे टुकड़ों में बांटने से शुरू करता हूं, क्योंकि traffic लगभग हमेशा टेढ़ा होता है और requests का एक छोटा वर्ग ही बजट खा जाता है। फिर सबसे सस्ती जीत आम तौर पर caching होती है। एक सिस्टम पर requests का ठीकठाक हिस्सा मिनटों के भीतर बिल्कुल दोहराव था, और normalize किए हुए input पर key बनाई एक छोटी उम्र वाली cache ने एक दिन के काम में load का बड़ा हिस्सा हटा दिया। अगला है cascading। हर चीज पर एक छोटा सस्ता मॉडल चलाइए और महंगे तक तभी जाइए जब सस्ते मॉडल को संदेह हो। अगर छोटा मॉडल आत्मविश्वास से सत्तर प्रतिशत traffic संभाल लेता है, तो आपने उस हिस्से की ज्यादातर लागत काट दी और मुश्किल मामलों पर accuracy बचा ली, और escalation की सीमा quality बजट के मुकाबले tunable है। उसके बाद इंजीनियरिंग आती है: quantization, compiled runtime, dynamic batching ताकि accelerator खाली न बैठे, और यह जांचना कि कहीं हम मॉडल के लिए जरूरत से बड़े hardware पर तो नहीं हैं। आखिरी सवाल असहज वाला है, कि हर prediction इस्तेमाल भी होती है या नहीं। एक बार मुझे ऐसी pipeline मिली जो रोज रात पूरे यूजर बेस को score करती थी जबकि सामने वाली जगह पर कभी सिर्फ ऊपर के कुछ हजार ही दिखते थे, और कम entities को score करना अकेली सबसे बड़ी बचत निकली।