Replicate accélère le démarrage de FLUX jusqu’à trois fois

Replicate réduit les temps de démarrage de plusieurs modèles PyTorch grâce à la mise en cache des artefacts produits par torch.compile. L’entreprise a annoncé cette évolution le 8 septembre 2025. Les modèles black-forest-labs/flux-kontext-dev, prunaai/flux-schnell et prunaai/flux.1-dev-lora démarrent désormais deux à trois fois plus vite, selon ses tests. Le mécanisme vise les phases de lancement des conteneurs de modèles. Il conserve les artefacts compilés entre plusieurs cycles de vie. Cette approche évite donc une nouvelle compilation complète lorsque le conteneur redémarre. Replicate détaille cette mise en œuvre dans son article technique.

La compilation initiale ajoute un coût lors du premier appel à une fonction compilée. torch.compile trace alors le code, puis le compile avant son exécution optimisée. Les appels suivants utilisent ce code optimisé et s’exécutent beaucoup plus rapidement. Replicate indique que de nombreux modèles, notamment ceux de la famille FLUX, utilisent déjà des techniques liées à torch.compile. Dans ses tests sur black-forest-labs/flux-kontext-dev, la version compilée réalise l’inférence avec une vitesse supérieure de plus de 30 % à la version non compilée. Le cache traite ainsi séparément le coût initial et les performances des appels suivants.

Replicate raccourcit trois démarrages

Les mesures publiées montrent des écarts précis entre les démarrages sans cache et ceux obtenus avec les artefacts conservés. black-forest-labs/flux-kontext-dev passe d’environ 120 secondes à 60 secondes, soit une amélioration de 50 %. prunaai/flux-schnell passe d’environ 150 secondes à 70 secondes, soit 53 %. prunaai/flux.1-dev-lora passe d’environ 400 secondes à 150 secondes, soit 62 %. Replicate observe aussi une amélioration du délai entre le démarrage du conteneur et la première prédiction réussie pour tous les modèles utilisant torch.compile. Ces chiffres concernent les temps de démarrage à froid mesurés par Replicate.

Le cache fonctionne selon une logique comparable à celle des caches utilisés dans les chaînes d’intégration et de déploiement continus. Au lancement d’un conteneur, le système recherche d’abord des artefacts compilés. Lorsqu’il les trouve, Torch les réutilise au lieu de recommencer la compilation. À l’arrêt normal d’un conteneur, le système met à jour le cache si nécessaire. Les fichiers sont indexés par version du modèle. Ils sont également stockés à proximité des nœuds équipés de processeurs graphiques. Cette organisation relie donc chaque cache à une version précise et à une infrastructure proche de l’exécution.

La documentation PyTorch présente les étapes générales de torch.compile et ses effets sur l’exécution des fonctions. Replicate renvoie vers son guide consacré à l’amélioration des performances des modèles avec torch.compile. L’entreprise renvoie également vers le tutoriel officiel de PyTorch. Les trois modèles cités illustrent déjà l’effet du cache sur les démarrages à froid. Le mécanisme reste associé aux modèles qui utilisent torch.compile. Replicate a aussi annoncé, dans la même publication, une prochaine annonce consacrée à son serveur MCP distant. Le cache et la compilation constituent donc deux éléments distincts de l’optimisation décrite.