आपके मॉडल की p99 latency 400 millisecond है और प्रोडक्ट को 50 चाहिए। आप इसे कैसे संभालेंगे?

optimize करने से पहले profile कीजिए: उन 400 millisecond को feature fetch, preprocessing, मॉडल के forward pass और network में तोड़िए, क्योंकि अक्सर सबसे बड़ा हिस्सा मॉडल होता ही नहीं। फिर सबसे बड़े टुकड़े पर हमला कीजिए। आम जीत हैं feature lookups पर concurrency, caching, quantization, compiled runtime, distilled मॉडल, और काम को request वाले रास्ते से हटाना। खास तौर पर p99 को निशाना बनाइए, औसत को नहीं।

जब तक मेरे पास ब्योरा न हो, मैं मॉडल को हाथ नहीं लगाऊंगा। मैं एक request को end to end trace करके feature fetch, deserialization, preprocessing, forward pass, postprocessing और network का समय नापता हूं। धीमी लगने वाली सर्विस पर जब जब मैंने यह किया है, मॉडल कुल समय का अल्पमत ही निकला। पिछली बार कुल करीब 400 millisecond थे जिनमें मॉडल में करीब 90 और दो सौ से ज्यादा किसी remote store पर तीन क्रमवार feature lookups के इंतजार में थे। उसे ठीक करना ML की समस्या नहीं थी, बात बस उन्हें साथ साथ भेजने और जो दो रोज ही बदलते थे उन्हें cache करने की थी, और अकेले उससे हम ज्यादातर रास्ता तय कर गए। उसके बाद मैं मॉडल देखता हूं: dynamic batching, int8 quantization, या ONNX Runtime या TensorRT जैसे compiled runtime में export, जो छोटे मॉडलों पर अक्सर बिना किसी accuracy कीमत के दो से तीन गुना जीत होती है। खास तौर पर p99 के बारे में दूसरी बात यह है कि median से इतनी ऊपर की tail आम तौर पर compute होती ही नहीं, वह load के नीचे queueing होती है, किसी नए replica पर cold start, या garbage collection। तो मैं देखता हूं कि p50 पहले से ठीक है या नहीं, क्योंकि अगर है तो इलाज capacity और warm pools है।