Tokios contre LiteLLM pour le routage de modèles LLM locaux

​

Aperçu

LiteLLM est un proxy Python open source et une passerelle API. Il se place devant vos moteurs LLM et assure la traduction entre les API de divers fournisseurs tels que OpenAI, Anthropic, Azure, Bedrock et plus de 100 autres. Il propose également des clés API virtuelles, un suivi budgétaire, la répartition de charge et des fonctionnalités de supervision. Il constitue ainsi un couche de routage et de gestion des coûts très efficace. La différence essentielle réside en ceci : LiteLLM est un proxy, non un tunnel. Il gère le trafic API entre les clients et les moteurs, mais ne résout pas le problème réseau consistant à rendre un modèle local accessible depuis Internet. Il faut alors recourir à un tunnel séparé tel que Tailscale, Cloudflare ou Tokios pour permettre l’accès à distance. Tokios regroupe le tunnel, le passerelle API, les clés API par utilisateur et un tableau de bord de gestion au sein d’un service géré par 1. Il gère à la fois la couche réseau — permettant ainsi d’accéder à votre modèle — et la couche API, qui gère l’authentification, le streaming et la traduction des protocoles.

​

Tableau comparatif

​

Les points forts de LiteLLM

• Code ouvert. Le code source complet est disponible, permettant l’auto-hébergement sans dépendance vis-à-vis d’un éditeur. Vous pouvez l’auditer, le forker et le modifier à votre guise.
• 100 fournisseurs au total. Vous pouvez diriger les requêtes vers OpenAI, Anthropic, Azure OpenAI, AWS Bedrock, Google Vertex, Together AI et bien d’autres, le tout via une API unique au format OpenAI.
• Routage avancé. Répartition de charge pondérée, routage selon la latence, bascule automatique en cas de défaillance d’un fournisseur, ainsi que gestion des temps de repos pour les modèles soumis à des limites de requêtes.
• Gestion précise des budgets. Définissez des plafonds de dépenses par clé virtuelle, par équipe ou par projet. Suivez les coûts par ID de modèle amont, par utilisateur et par jour. LiteLLM se distingue nettement dans ce domaine.
• Outil d’observation très complet. Intégrations natives avec Langfuse, Datadog, Prometheus, Helicone et des hooks de callback personnalisés. Chaque requête est consignée en détail, avec le nombre de tokens et la mesure de la latence.
• Attribution des coûts. Identifiez précisément quelle équipe a dépensé combien pour quel modèle. Pour les organisations utilisant plusieurs fournisseurs cloud, cette fonctionnalité est indispensable.

​

En quoi Tokios se distingue

• Le connecteur tunnel est inclus. LiteLLM requiert toujours une couche réseau supplémentaire pour rendre un modèle local accessible depuis Internet. Tokios intègre ce connecteur tunnel — pas besoin de cloudflared, de Tailscale ni de configuration nginx.
• Service entièrement géré. Il n’est pas nécessaire de lancer de conteneur Docker, de procéder à un déploiement Kubernetes ni de maintenir un environnement Python. Tokios se compose d’un binaire connecteur et d’un tableau de bord web.
• Tableau de bord intégré. Gérez vos connecteurs, vos déploiements et vos clés API via une seule interface utilisateur. L’interface d’administration de LiteLLM exige quant à elle une configuration et un paramétrage séparés.
• Traduction de protocoles au niveau du passerelle. Le support des formats OpenAI et Anthropic est assuré à l’extrémité du tunnel. LiteLLM normalise les requêtes au format OpenAI mais ne communique pas selon le protocole Anthropic avec les clients.
• Plus simple pour les modèles locaux. Si votre objectif est de « rendre votre modèle Ollama local accessible via une clé API », Tokios s’installe en 2 minutes. Pour LiteLLM, il faut un déploiement Docker, un fichier de configuration et une configuration tunnel distincte.

​

Le décalage réseau

Voici la différence fondamentale. LiteLLM agit comme une couche de proxy — il se place entre les clients et les backends sur le même réseau (ou des réseaux accessibles). Si votre modèle tourne sur un serveur domestique derrière un CGNAT, LiteLLM ne peut pas à lui seul le rendre accessible depuis Internet. Il faut :

1. Un connecteur tunnel (Cloudflare Tunnel, Tailscale Funnel ou Tokios) pour rendre le proxy LiteLLM accessible publiquement
2. LiteLLM placé derrière ce tunnel afin de gérer le routage, les clés API et les limites d’utilisation
3. Vos backends LLM placés derrière LiteLLM

Il faut ainsi configurer et maintenir 3 couches. Tokios regroupe les couches 1 et 2 en un seul service géré — sans toutefois remplacer les capacités de routage multi-fournisseurs de LiteLLM.

​

Utiliser les deux en parallèle

Pour les configurations complexes, ces deux outils se complètent à merveille :

• LiteLLM s’installe sur votre réseau local et gère le routage vers plusieurs backends (vLLM local, OpenAI cloud, Azure en secours) tout en assurant le suivi des coûts et l’équilibrage de la charge.
• Tokios propose quant à lui un point d’accès public sécurisé par des clés API, permettant ainsi à des utilisateurs externes et à des agents de programmation de se connecter à votre proxy LiteLLM sans avoir à configurer de tunnel supplémentaire.

Dans cette architecture, le connecteur Tokios pointe vers votre proxy LiteLLM plutôt que vers un backend direct. Les appelants envoient leurs requêtes à api.tokios.com en indiquant une clé sk-tok-… ; Tokios transmet ensuite ces requêtes à votre machine, et LiteLLM se charge du routage entre les différents fournisseurs.

​

Quand opter pour LiteLLM ?

• Routage multi-fournisseurs. Vous devez diriger les requêtes vers OpenAI, Anthropic, Azure et des modèles locaux, en prévoyant des mécanismes de secours et d’équilibrage de charge.
• Suivi avancé des coûts. Vous avez besoin de gérer des budgets par équipe, des limites de dépenses par projet et d’analyser précisément les dépenses.
• Disposer de compétences DevOps. Vous êtes capable de mettre en œuvre et de maintenir un déploiement Docker ou Kubernetes, avec gestion des fichiers de configuration et surveillance.
• Il faut disposer d’une grande diversité de fournisseurs. Vous intégrez plus de 5 fournisseurs de modèles LLM différents et souhaitez bénéficier d’une interface API unifiée.

​

Quand opter pour Tokios ?

• Vous avez besoin d’un point d’accès API public pour des modèles locaux. Votre objectif principal est de rendre accessible un modèle hébergé sur votre propre matériel depuis n’importe où, tout en assurant une authentification sécurisée.
• Souhaitez-vous un service géré. Il n’est pas nécessaire de gérer d’infrastructure, d’orchestrer des conteneurs ni de prendre en charge des environnements Python.
• Vous avez besoin d’un tunnel, d’un proxy et de clés API réunis. Un seul outil assure à la fois le réseau, l’authentification et le streaming — contrairement à 3 couches distinctes.
• Configuration simplifiée d’un backend local. Un ou deux modèles locaux fonctionnant via Ollama ou vLLM, sans réseau de routage multi-fournisseurs complexe.