A latência p99 do seu modelo é 400 milissegundos e o produto precisa de 50. Como você aborda isso?

Faça profiling antes de otimizar: quebre os 400 milissegundos em busca de features, pré processamento, a passagem forward do modelo e rede, porque o modelo muitas vezes não é a maior fatia. Depois ataque a maior peça. Ganhos típicos são concorrência nos lookups de feature, cache, quantização, um runtime compilado, um modelo destilado, e tirar trabalho do caminho da requisição. Mire no p99 especificamente, não na média.

Eu não tocaria no modelo até ter uma decomposição. Eu tracejo uma requisição fim a fim e cronometro busca de features, desserialização, pré processamento, a passagem forward, pós processamento e rede. Toda vez que eu fiz isso num serviço que parecia lento, o modelo era a minoria do tempo. O último foi por volta de 400 milissegundos no total, com uns 90 no modelo e mais de 200 esperando três lookups sequenciais de feature contra uma store remota. Consertar isso não foi um problema de ML, foi disparar os lookups de forma concorrente e cachear os dois que só mudavam diariamente, e só isso já nos levou a maior parte do caminho. Depois disso eu olho o modelo: batching dinâmico, quantização int8, ou exportar para um runtime compilado como ONNX Runtime ou TensorRT, que em modelos menores costuma ser um ganho de duas a três vezes sem custo de acurácia. A outra coisa sobre o p99 especificamente é que uma cauda tão acima da mediana normalmente não é computação, é enfileiramento sob carga, um cold start numa réplica nova, ou garbage collection. Então eu checo se o p50 já está bom, porque se estiver, a correção é capacidade e pools aquecidos.