GoModel : une passerelle IA en Go, entre compatibilité multi-fournisseurs et contrôle des coûts

Le problème que GoModel attaque

Une équipe qui utilise plusieurs fournisseurs de modèles finit avec plusieurs SDK, plusieurs formats de requête, plusieurs façons de compter les jetons et plusieurs tableaux de bord. Changer de fournisseur pour un modèle donné implique de toucher au code client. GoModel se place entre les deux : les clients continuent d'appeler une API compatible OpenAI ou Anthropic, et la passerelle se charge de traduire vers le fournisseur réel. Le README précise que les SDK officiels fonctionnent sans modification, avec l'URL de base de l'OpenAI SDK pointée sur http://localhost:8080/v1 et celle de l'Anthropic SDK sur http://localhost:8080, le SDK ajoutant lui-même /v1/messages. Le public visé est donc l'équipe plateforme ou backend qui héberge déjà plusieurs clés API et qui veut un point de contrôle unique pour les coûts, les quotas et la journalisation. Le projet se présente explicitement comme une alternative à LiteLLM et à Portkey, ce qui situe la cible : des équipes qui trouvaient ces outils trop lourds ou trop dépendants d'un runtime Python.

Deux surfaces d'API, une trentaine de fournisseurs

Le mécanisme central est un proxy HTTP qui accepte deux dialectes. Côté OpenAI, les routes vivent sous /v1, avec par exemple /v1/responses dans l'exemple du README. Côté Anthropic, la route est /v1/messages. La passerelle traduit ensuite vers le fournisseur configuré : OpenAI, Anthropic, xAI, Google Gemini, Cohere, Vertex AI, DeepSeek, Groq, Fireworks AI, Meta, OpenRouter, Z.ai, Alibaba Cloud Model Studio, Kilo AI, MiniMax, Xiaomi MiMo, OpenCode Go, Azure OpenAI, Oracle, Ollama, SGLang, vLLM, llm-d, Amazon Bedrock, les backends ChatGPT et Claude, ElevenLabs, et tout fournisseur compatible OpenAI. Cette dernière mention est la plus importante en pratique : elle couvre les serveurs d'inférence auto-hébergés qui exposent déjà une API OpenAI. Le README renvoie à une matrice de fonctionnalités par fournisseur sur la page Providers Overview, ce qui suggère que le support n'est pas uniforme. C'est une précision utile, car une passerelle qui accepte un fournisseur ne garantit pas que le streaming, les appels d'outils ou le comptage de jetons fonctionnent de la même manière partout.

Démarrage : trois chemins, un seul port

L'installation tient en une commande. Sous macOS et Linux, le README donne curl -fsSL https://gomodel.enterpilot.io/install.sh | sh, suivi de gomodel après avoir éventuellement exporté OPENAI_API_KEY. Sous Windows, la variante PowerShell est irm https://gomodel.enterpilot.io/install.ps1 | iex. Pour Docker, l'image enterpilot/gomodel s'exécute avec docker run --rm -p 8080:8080 -e OPENAI_API_KEY="your-openai-key". Le tableau de bord est ensuite servi sur http://localhost:8080/admin/dashboard. Un premier appel se fait avec curl sur http://localhost:8080/v1/responses en envoyant un corps JSON contenant model et input. La configuration suit un ordre de résolution explicite : les valeurs par défaut, puis config.yaml, puis .env, puis les variables d'environnement exportées, chaque source à droite écrasant celles à gauche. Le fichier .env.template est présenté comme la liste complète des variables, fournisseurs inclus. Pour un déploiement avec infrastructure, docker compose up -d démarre Redis, PostgreSQL, MongoDB et Adminer sans construire d'image, tandis que docker compose --profile app up -d ajoute GoModel et Prometheus. Ce second profil est celui qui compte si vous voulez voir les métriques.

Ce que la passerelle fait entre la requête et le fournisseur

Plusieurs fonctionnalités se combinent au moment du routage. Les modèles virtuels exposent des alias et répartissent la charge en round-robin ou selon le coût, derrière un nom de modèle stable. La fonction de session keeping détecte une session cliente et l'épingle à une cible et à une clé de fournisseur, ce qui maintient chauds les caches de prompt côté fournisseur et rend les journaux d'audit lisibles comme des fils de conversation. La bascule automatique redirige vers un fournisseur de secours, avec des tentatives et des disjoncteurs. Le cache couvre les réponses exactes et sémantiques. Les budgets posent des plafonds de dépense par utilisateur, équipe ou clé, et les limites de débit portent sur les requêtes, les jetons et la concurrence. Une Usage API permet à un client de consulter sa consommation, son budget restant et sa marge de débit avec la clé qu'il utilise déjà pour l'inférence. Ce dernier point est le plus intéressant du lot : il évite de distribuer une seconde clé d'administration aux applications clientes. Le README ne détaille pas l'algorithme de similarité du cache sémantique ni la façon dont les disjoncteurs comptent les échecs. Ce sont des zones à lire dans le code avant de s'appuyer dessus en production.

Limites et cas où GoModel n'est pas le bon outil

Le projet revendique le statut prod ready et un rythme de publication soutenu, avec des versions v0.1.88 à v0.1.90 en quelques jours. Cette cadence a un revers : la numérotation reste en 0.1.x, ce qui signale une API et un comportement encore mouvants. Une équipe qui épingle une version devra prévoir des mises à jour fréquentes pour suivre les correctifs. Autre limite, la matrice de compatibilité par fournisseur est renvoyée à une page externe, et le README ne dit pas quelles fonctionnalités se dégradent quand un fournisseur ne les supporte pas. Si votre usage dépend d'un détail propriétaire, comme un mode de raisonnement ou un format de sortie structurée spécifique, la traduction par la passerelle peut le perdre. Le cache sémantique mérite lui aussi une vérification : sur des charges où deux prompts proches doivent produire des réponses distinctes, une similarité trop permissive renvoie la mauvaise réponse, et le README ne donne aucun seuil. Enfin, une passerelle ajoute un saut réseau et un point de défaillance unique. Le README ne décrit pas de mode de déploiement multi-instances avec consensus, seulement une pile Docker Compose avec Redis, PostgreSQL et MongoDB. Si votre contrainte est une latence minimale sur un seul fournisseur, le proxy n'apporte rien et coûte un aller-retour.

Face à LiteLLM, une différence de runtime

L'alternative la plus directe est LiteLLM, que le README cite nommément. La différence tient d'abord au langage : GoModel est écrit en Go et se distribue comme un binaire unique ou une image Docker, là où LiteLLM est un projet Python. Pour une équipe qui déploie déjà du Go, cela supprime l'environnement virtuel, la résolution de dépendances Python et une partie de l'empreinte mémoire. Le projet revendique aussi un avantage de performance et d'efficacité des ressources, en renvoyant à des benchmarks auto-reproductibles. Ce sont des chiffres avancés par les mainteneurs, pas des mesures indépendantes, et il faut les traiter comme tels. Sur le périmètre fonctionnel, LiteLLM couvre également le routage multi-fournisseurs, les budgets et la journalisation, avec un écosystème plus ancien et davantage de retours d'expérience publics. Le choix se joue donc moins sur la liste de fonctionnalités que sur l'écosystème dans lequel vous vivez : un binaire Go s'intègre naturellement dans une chaîne de build Go, un paquet Python s'intègre dans une chaîne Python. Le README mentionne aussi Portkey comme n'étant plus maintenu sur GitHub, ce qui est un argument de contexte plus qu'un argument technique.

Coût de maintenance et licence

GoModel est publié sous licence MIT, ce qui autorise l'usage commercial, la modification et la redistribution, à condition de conserver l'avis de copyright et le texte de la licence. Le README ne mentionne aucune clause supplémentaire, aucun modèle ouvert ni aucune offre hébergée obligatoire, mais il renvoie à un site et à un tableau de bord de démonstration, ce qui laisse penser qu'un service existe en parallèle du dépôt. Rien dans le matériel fourni ne décrit un modèle de licence à deux niveaux. Sur la maintenance, la charge repose sur les mises à jour du projet : avec des versions publiées tous les deux ou trois jours, une politique de mise à jour mensuelle vous laissera plusieurs dizaines de versions de retard. Il faut aussi compter le suivi des changements d'API chez les fournisseurs amont, puisque la passerelle doit s'adapter à leurs évolutions. Le dépôt n'est pas archivé et le dernier envoi de code date du 9 septembre 2026 selon les métadonnées. Pour un déploiement en production, la question à trancher est simple : êtes-vous prêt à suivre un projet en 0.1.x à ce rythme, ou avez-vous besoin d'une version figée avec un support contractuel que le dépôt ne fournit pas.

Conclusion éditoriale

GoModel convient aux équipes qui veulent un point d'entrée unique vers plusieurs fournisseurs de modèles sans réécrire leurs clients, et qui acceptent de lire le code et le fichier .env.template pour combler les zones d'ombre de la documentation. Il ne convient pas à celles qui cherchent une passerelle avec un support commercial garanti, ni à celles dont l'usage repose sur des fonctionnalités propres à un fournisseur non listé. Avant de déployer, vérifiez trois choses concrètes : la présence du fournisseur visé dans la matrice de la page Providers Overview, le comportement réel de la bascule sur votre configuration, et la manière dont le cache sémantique est activé ou désactivé dans config.yaml.

Sources officielles

1. ENTERPILOT/GoModel on GitHub
2. License: MIT
3. Project website
4. README
5. Releases