Ce qui change
1
Inventoriez la configuration du proxy
Listez tous les alias de modèles, modèles de secours, règles de fournisseur, politiques de nouvelle tentative, budgets, callbacks et variables d’environnement de votre déploiement LiteLLM actuel. Distinguez les paramètres de politique partagés de ceux propres à une seule application.
2
Remplacez le point de terminaison du proxy
Conservez le code de requête compatible avec OpenAI et modifiez l’URL de base et la clé.
3
Mappez les alias et les règles de routage
Vérifiez chaque modèle de production avec
GET /v1/models. Si les clients dépendent d’alias internes, normalisez-les à un seul point d’entrée de l’application au lieu de modifier chaque requête.Déplacez les prompts, paramètres et restrictions de fournisseur réutilisables dans les préréglages. Configurez le classement des fournisseurs et les modèles de secours avec le routage et les solutions de repli.4
Validez les flux de production
Testez le streaming, les outils, les sorties structurées, les nouvelles tentatives, la conversion des erreurs et toute observabilité pilotée par des callbacks que gérait votre déploiement LiteLLM. Comparez la latence, les réponses, l’utilisation des jetons et le coût avant de transférer progressivement le trafic.
Liste de contrôle de la migration
- Les URL, clés et dépendances de déploiement LiteLLM ont été identifiées.
- Chaque modèle et alias de production possède un mappage Phaseo explicite.
- Les valeurs par défaut partagées ont été déplacées vers des préréglages ou un point d’entrée unique de l’application.
- Le streaming, les outils et les sorties structurées fonctionnent en préproduction lorsqu’ils sont utilisés.
- Les callbacks et données de télémétrie nécessaires ont un remplacement prévu.
- Le retour arrière se limite toujours à modifier la clé et le point de terminaison dans la configuration.