Migração do Python 3.10 para o 3.12 no Databricks quebra modelos MLflow da Zalando

O problema vem da forma como o MLflow serializa modelos Python. Ao registrar um modelo pyfunc, ele usa cloudpickle para congelar o objeto wrapper inteiro, incluindo modelos internos como classificadores CatBoost ou módulos PyTorch, em um único artefato. Esse arquivo carrega metadados da versão do Python e bytecode. Como a estrutura do bytecode mudou bastante entre o Python 3.10 e o 3.12, o interpretador novo não conseguiu ler os pickles antigos e devolveu um TypeError na hora de puxar o modelo do registry. A Zalando enfrentou isso ao subir o Databricks Runtime do LTS 14.3 (Python 3.10) para o LTS 17.3 (Python 3.12).

Retreinar tudo estava fora de cogitação. Só o sistema de classificação de produtos usa vários TB de dados e treina, para cada categoria ativa, cinco tipos de modelo: CatBoost, regressão logística com TF-IDF, rede neural em PyTorch Lightning, modelo de imagem e um ensemble de votação. A saída foi a técnica "Load and Repack": um job único, em ambiente equivalente ao DBR 14.3, lê os pickles antigos, extrai os pesos e reempacota tudo em um wrapper baseado em arquivo (model_wrappers.py), com dependências via uv e promoção de volta ao alias @Production. A equipe também inferiu novas signatures com DataFrames fictícios. Como o wrapper ainda passa por cloudpickle, o próximo passo é migrar para flavors nativos (.cbm, pt2, skops) e adotar Models from Code.

Para quem opera pipelines de ML em Databricks, a leitura é direta: o registry de modelos também precisa de plano de upgrade, não só o código de treino. Artefatos presos a bytecode viram dívida técnica que só cobra na troca de runtime. Formatos nativos e dependências travadas (pyproject.toml, uv.lock) reduzem esse risco, e a lição de alinhar cedo com cientistas aplicados a lista de pacotes vale antes de agendar qualquer migração.