Le problème L’appel de plusieurs LLM implique des configurations spécifiques au fournisseur/modèle. Même si vous unifiez les E/S, vous avez toujours besoin d'un moyen de gérer les cas extrêmes spécifiques au modèle/fournisseur. Nous avons été confrontés à ce problème la semaine dernière lorsqu'Anthropic nous a annoncé que nous avions violé sa politique relative au contenu. Depuis, nous fournissons à notre communauté un accès aux LLM comme Claude-2 etc. via notre open source. serveur proxy Vérifier les requêtes via le point de terminaison de modération OpenAI ralentirait les requêtes, nous voulions donc l'exécuter uniquement sur les modèles Anthropic. if model in ["claude-instant-1", "claude-2"]: # run moderations check return litellm.completion(model, messages) Mais une logique conditionnelle comme celle-ci conduit à des bugs. Nous avions déjà été confrontés à ce problème et avions (bibliothèque d'abstraction qui simplifiait les appels d'API LLM). construit LiteLLM pour résoudre ce problème pour nous tldr; Nous de logique conditionnelle sur notre serveur. ne voulions pas Nous d'un moyen de contrôler pour quels modèles/fournisseurs cette vérification était effectuée. avions besoin La solution : les fichiers de configuration Notre solution consistait à laisser LiteLLM cela pour nous et contrôler sa logique via un fichier de configuration. Cela et nous a toujours permis de . gérer a supprimé la logique conditionnelle de notre code serveur contrôler les détails spécifiques au fournisseur/modèle Cela nous a également permis de gérer d'autres scénarios tels que les erreurs de fenêtre contextuelle, le nombre maximal de jetons, etc. Voici notre code complet : import litellm import os config = { "default_fallback_models": ["gpt-3.5-turbo", "claude-instant-1", "j2-ultra"], "model": { "claude-instant-1": { "needs_moderation": True }, "gpt-3.5-turbo": { "error_handling": { "ContextWindowExceededError": {"fallback_model": "gpt-3.5-turbo-16k"} } } } } # set env var os.environ["OPENAI_API_KEY"] = "sk-litellm-5b46387675a944d2" # [OPTIONAL] replace with your openai key os.environ["ANTHROPIC_API_KEY"] = "sk-litellm-5b46387675a944d2" # [OPTIONAL] replace with your anthropic key sample_text = "how does a court case get to the Supreme Court?" * 1000 messages = [{"content": sample_text, "role": "user"}] response = completion_with_config(model="gpt-3.5-turbo", messages=messages, config=config) print(response) # should be gpt-3.5-turbo-16k Les fichiers de configuration gèrent actuellement : Logique d'invite : choisir le bon modèle pour une invite donnée, ainsi que couper une invite si elle est plus grande que n'importe quel modèle disponible Logique de repli - vous permettant de définir des solutions de secours par défaut ainsi que des solutions spécifiques au modèle (par exemple, l'erreur de la fenêtre contextuelle ci-dessus). Modérations - si un fournisseur (par exemple Anthropic) vous demande de modérer vos demandes Au fil du temps, cela gérera d'autres paramètres spécifiques au modèle, tels que la définition du nombre maximal de jetons, le formatage des invites, etc. Les idées/suggestions sont les bienvenues ! Conclusion LiteLLM a déjà simplifié les appels des fournisseurs LLM, avec un remplacement immédiat du point de terminaison d'OpenAI ChatCompletion. Avec les fichiers de configuration, il peut désormais vous permettre d'ajouter de nouveaux modèles en production, sans modifier le code côté serveur. Dans l’ensemble, LiteLLM est un excellent choix pour tous ceux qui cherchent à ajouter rapidement et facilement des modèles non OpenAI en production. Nous essayons activement de développer ce projet, donc quel que soit votre niveau de compétence, nous apprécions les contributions ! Ouvrez un problème si vous trouvez des fonctionnalités/bogues manquants ou si vous contribuez à des problèmes existants. sur GitHub si vous souhaitez suivre nos progrès à mesure que de nouvelles mises à jour arrivent. Mettez-nous en vedette
