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 serveur proxy open source.

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 construit LiteLLM pour résoudre ce problème pour nous (bibliothèque d'abstraction qui simplifiait les appels d'API LLM).

tldr;

• Nous ne voulions pas de logique conditionnelle sur notre serveur.
• Nous avions besoin d'un moyen de contrôler pour quels modèles/fournisseurs cette vérification était effectuée.

La solution : les fichiers de configuration

Notre solution consistait à laisser LiteLLM gérer cela pour nous et contrôler sa logique via un fichier de configuration. Cela a supprimé la logique conditionnelle de notre code serveur et nous a toujours permis de 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. Mettez-nous en vedette sur GitHub si vous souhaitez suivre nos progrès à mesure que de nouvelles mises à jour arrivent.