Présentation

Le projet litelm propose une version allégée du moteur de routage et de traduction de messages de LiteLLM. Le cœur fonctionnel occupe environ 2 900 lignes de code et ne dépend que de deux bibliothèques externes : openai et httpx. En comparaison, la distribution originale intègre plus de 100 k LOC répartis entre serveurs proxy, caches, suivi des coûts et dizaines de fonctionnalités rarement utilisées. L’objectif est d’exposer uniquement le chemin d’appel essentiel : routage de modèle, conversion de messages, streaming, utilisation d’outils et génération d’embeddings.

Architecture et fonctionnalités

litelm conserve l’API de LiteLLM, ce qui permet de remplacer les imports par une simple substitution de texte (import litelm au lieu de import litellm). Les fonctions principales sont completion, embedding et leurs variantes asynchrones (acompletion, aembedding). Chaque appel accepte le format "provider/model-name", ce qui donne accès à 19 fournisseurs différents, y compris OpenAI, Anthropic, Bedrock, Groq, Ollama et vLLM. Les points d’accès peuvent être redirigés via la variable d’environnement OPENAI_API_KEY ou un paramètre api_key, et les serveurs compatibles OpenAI sont configurables avec api_base.

import litelm
response = litelm.completion(
    "openai/gpt-4o",
    messages=[{"role": "user", "content": "Hello!"}]
)
print(response.choices[0].message.content)

Le streaming s’obtient en activant le flag stream=True, chaque fragment étant renvoyé sous forme d’objet delta. Les embeddings sont appelés via litelm.embedding avec la même signature que LiteLLM. Les erreurs des fournisseurs sont normalisées dans une hiérarchie d’exceptions propre à litelm (ContextWindowExceededError, RateLimitError, AuthenticationError), ce qui simplifie la gestion d’erreurs transversales.

for chunk in litelm.completion(
    "groq/llama-3.1-70b-versatile",
    messages=[...],
    stream=True
):
    print(chunk.choices[0].delta.content or "", end="")

Analyse des performances et de la compatibilité

Le mainteneur indique que les modifications du routage et du formatage ont été auditées sur plus de 360 commits, avec 262 tests unitaires exécutés en local (55 ignorés) et 45 tests en direct sur les fournisseurs. Tous les tests DSPy (10) sont également passés, confirmant la prise en charge des chemins d’exécution critiques : prédiction, chaîne de raisonnement (CoT), signatures typées, streaming, embeddings, utilisation d’outils et sorties multiples. Le taux de réussite de 100 % sur ces suites indique que l’interface de litelm reproduit fidèlement le comportement de LiteLLM pour les cas couverts, tout en éliminant le code superflu.

La réduction du nombre de dépendances à deux packages minimise les conflits de version et accélère l’installation (≈ 200 ms sur un réseau moyen). En revanche, l’absence de couches de cache ou de suivi des coûts signifie que les applications nécessitant ces services devront les implémenter séparément, ce qui peut introduire une surcharge supplémentaire dans des environnements de production.

Limites et perspectives

litelm se positionne comme une solution « alpha », et la documentation précise que la compatibilité totale avec LiteLLM n’est pas garantie : seuls le routage, la traduction de messages et l’interface DSPy sont couverts. Les fonctionnalités avancées de LiteLLM (proxy, métriques, politiques de facturation) restent indisponibles, ce qui limite l’usage à des scénarios de prototypage ou d’intégration légère. De plus, les tests en direct requièrent des clés API stockées dans .env.test, ce qui peut compliquer la CI pour les équipes sans accès aux fournisseurs.

En résumé, litelm offre un noyau fonctionnel compact, vérifié par une batterie de tests exhaustive, mais sacrifie les services auxiliaires qui justifient souvent le poids de LiteLLM. Les développeurs devront peser la simplicité d’intégration contre la perte de fonctionnalités intégrées avant d’adopter cette version allégée.