OptiLLM : un proxy d'inférence qui déplace le calcul du côté de la requête
Optimizing inference proxy for LLMs
En bref
- De quoi s’agit-il ?
- OptiLLM est un proxy compatible avec l'API OpenAI qui applique plus de vingt techniques de raisonnement au moment de l'inférence, sans réentraînement. L'idée est simple à énoncer et coûteuse à exécuter : payer plus de calcul par requête pour obtenir de meilleures réponses d'un modèle inchangé.
- À qui s’adresse-t-il ?
- OptiLLM s'adresse aux équipes qui ont déjà un budget d'inférence et veulent tester des schémas de raisonnement multi-appels sans modifier leur code client : le changement se limite au champ model, par exemple moa-gpt-4o-mini. Il ne convient pas aux charges à faible latence, aux traitements par lots massifs, ni aux cas où la réponse doit rester reproductible d'un appel à l'autre.
- Puis-je l’utiliser commercialement ?
- Oui. Apache-2.0 est une licence permissive : vous pouvez utiliser, modifier et vendre un logiciel qui en dépend, à condition de conserver les mentions de droit d’auteur et de licence.
- Est-il encore maintenu ?
- Oui. Les derniers commits datent d’il y a 59 jours.
- En quel langage est-il écrit ?
- Principalement Python, d’après les statistiques de langage de GitHub.
Ces réponses reposent sur les données GitHub du projet (dernière synchronisation le 15 septembre 2026) et sur notre analyse. Elles ne constituent pas un avis juridique.
ANALYSE OPEN SOURCE APPROFONDIE
Le problème : la qualité de raisonnement se paie en appels, pas en poids
La plupart des équipes qui veulent de meilleures réponses sur des tâches de mathématiques, de code ou de logique se heurtent au même mur. Le fine-tuning coûte cher, demande un jeu de données propre et doit être refait à chaque changement de modèle de base. OptiLLM prend le problème par l'autre bout : il ne touche pas aux poids, il modifie la façon dont la requête est traitée. Le README résume la promesse par une phrase : il serait possible de battre des modèles frontière en faisant du calcul supplémentaire au moment de l'inférence.
Le public visé est précis. Il s'agit de développeurs qui appellent déjà une API compatible OpenAI et qui acceptent de payer plusieurs générations pour une seule question. Une équipe qui consomme un modèle pour du remplissage de formulaire ou de la classification courte n'a rien à gagner ici. Le projet s'adresse à celles qui traitent des énoncés de concours, des problèmes de programmation ou des questions à choix multiples exigeant plusieurs étapes de raisonnement.
Le mécanisme : un préfixe de modèle qui déclenche une stratégie
Le point d'entrée est un serveur local qui expose une route /v1 compatible avec le client OpenAI. La sélection de la technique ne passe pas par un paramètre dédié mais par le nom du modèle. Le README donne cet exemple : appeler le modèle moa-gpt-4o-mini active l'approche Mixture of Agents, tandis que le modèle sous-jacent reste gpt-4o-mini. Le préfixe avant le tiret est le slug de la technique, la partie qui suit est le modèle réel transmis au fournisseur.
Chaque slug correspond à une stratégie différente, et les stratégies ne se ressemblent pas. MARS décrit un système multi-agents avec exploration à températures variées, vérification croisée et amélioration itérative. CePO combine Best of N, chaîne de pensée, auto-réflexion et auto-amélioration. PlanSearch fait une recherche sur des plans candidats en langage naturel. CoT with Reflection structure la sortie en sections thinking, reflection et output. ReRead traite la requête deux fois. Le proxy ne fait donc pas qu'un seul type de travail : selon le slug, il orchestre un nombre variable d'appels au modèle amont et assemble les résultats avant de renvoyer une réponse au format attendu par le client.
Cette conception a une conséquence pratique importante. Le client ne voit qu'une réponse unique. Toute la complexité, y compris les appels parallèles et les tours de vérification, reste cachée derrière l'interface. C'est ce qui rend l'adoption peu intrusive, et c'est aussi ce qui rend le coût réel difficile à lire depuis le code appelant.
Mise en route : pip, Docker ou dépôt cloné
L'installation la plus directe tient en deux commandes. pip install optillm, puis optillm après avoir exporté OPENAI_API_KEY. Le journal de démarrage affiché dans le README mentionne le chargement des plugins privacy et memory, puis l'ouverture du serveur avec l'approche auto. Cette approche auto est la valeur par défaut : sans préfixe de modèle, le proxy se contente de relayer la requête.
Une image Docker est publiée sur ghcr.io, sous trois variantes. latest inclut toutes les dépendances pour l'inférence locale et les plugins. latest-proxy est allégée et ne permet pas l'inférence locale. latest-offline embarque des modèles pré-téléchargés, notamment spaCy, pour fonctionner sans réseau. Le choix entre ces images n'est pas cosmétique : si vous comptez utiliser un plugin qui s'appuie sur un modèle local, la variante proxy ne suffira pas.
Deux points de configuration méritent attention. Pour les environnements avec certificat autosigné ou proxy d'entreprise, optillm accepte --no-ssl-verify ou la variable OPTILLM_SSL_VERIFY=false, et l'option --ssl-cert-path ou OPTILLM_SSL_CERT_PATH pour pointer vers un bundle CA. Le README qualifie explicitement la désactivation de la vérification SSL d'insécurisée et la réserve au développement. C'est un avertissement à prendre au sérieux : un proxy d'inférence voit passer l'intégralité de vos prompts.
Le coût caché : chaque gain annoncé est un multiple d'appels
Le README avance des chiffres nets. MARS apporterait 30,0 points sur AIME 2025 avec Gemini 2.5 Flash Lite, CePO 18,6 points sur Math-L5 avec Llama 3.3 70B, AutoThink 9,34 points sur GPQA-Diamond avec DeepSeek-R1-1.5B, LongCePO 13,6 points sur InfiniteBench, et PlanSearch 20 pour cent de pass@5 sur LiveCodeBench. Ces résultats proviennent du projet et de ses publications associées. Ils ne sont pas reproduits ici et dépendent de la configuration exacte de chaque technique.
La question que ces tableaux ne traitent pas est celle du coût unitaire. Une technique qui fait de l'exploration à températures multiples, de la vérification croisée et de l'amélioration itérative consomme plusieurs générations par requête. Le gain de précision est réel dans le cadre décrit, mais il s'achète en tokens, en latence et en appels à l'API amont. Une équipe qui compare le prix d'un appel direct à celui d'un appel via mars-gpt-4o-mini ne comparera pas la même chose. Le README ne fournit pas de tableau de coût par technique, et c'est une lacune pour quiconque doit arbitrer un budget.
Il faut ajouter une contrainte de reproductibilité. Plusieurs de ces stratégies reposent sur l'échantillonnage à température non nulle. Deux appels identiques peuvent donc produire des réponses différentes. Pour un pipeline de test automatisé ou un cache de réponses, c'est un changement de régime qu'il vaut mieux anticiper.
Quand OptiLLM n'est pas le bon outil
Le cas le plus clair est celui de la latence contrainte. Si votre budget de réponse se compte en centaines de millisecondes, un schéma multi-agents avec vérification croisée ne rentre pas dans l'enveloppe. Le proxy ne peut pas compenser le fait que la stratégie elle-même exige plusieurs allers-retours vers le fournisseur.
Le deuxième cas est celui du volume. Sur du traitement par lots de plusieurs millions de requêtes, multiplier les appels par requête transforme une facture gérable en facture problématique. Les techniques décrites conviennent à des tâches où l'erreur coûte cher et où le volume reste modéré.
Le troisième cas touche à la nature de la tâche. Sur de l'extraction d'entités, de la traduction ou de la reformulation, le raisonnement en plusieurs étapes n'apporte pas grand-chose. La chaîne de pensée aide quand il y a des étapes intermédiaires à vérifier, pas quand la réponse est une transformation directe.
Enfin, il y a une limite de vérification côté exploitation. Le dépôt ne documente pas, dans les éléments fournis, de mécanisme de repli lorsque le fournisseur amont renvoie une erreur au milieu d'une stratégie multi-appels. Une équipe qui place ce proxy sur un chemin critique doit tester elle-même ce comportement avant de s'y fier.
Face à LiteLLM, la différence n'est pas la couche de routage
LiteLLM est l'alternative la plus évidente, et le README d'OptiLLM le mentionne d'ailleurs comme brique de support pour l'accès à plus de cent modèles. La confusion est fréquente parce que les deux projets exposent une interface compatible OpenAI et savent parler à plusieurs fournisseurs. La différence porte sur ce qui se passe après la réception de la requête.
LiteLLM normalise les formats entre fournisseurs, gère les clés, les budgets et les replis. C'est une couche de transport et de gouvernance : une requête entrante donne lieu à un appel sortant, avec éventuellement une nouvelle tentative. OptiLLM se place à un autre niveau. Une requête entrante peut donner lieu à plusieurs appels sortants organisés selon une stratégie de raisonnement, dont le résultat est fusionné avant d'être renvoyé. Le premier optimise l'acheminement, le second optimise la réponse.
Cela signifie que les deux ne sont pas réellement en concurrence, et que les combiner a du sens : OptiLLM utilise justement LiteLLM pour atteindre des fournisseurs comme Anthropic, Google ou Cerebras. La vraie question de choix n'est donc pas « LiteLLM ou OptiLLM » mais « ai-je besoin d'une stratégie de raisonnement par requête ». Si la réponse est non, LiteLLM seul suffit et coûtera moins cher à exploiter.
Maintenance, licence et coût de mise à jour
Le rythme de publication est soutenu. Trois versions apparaissent dans les éléments fournis pour une fenêtre courte : v0.3.20 et v0.3.21 le même jour, puis v0.3.22 environ deux semaines plus tard. Le numéro de version reste en 0.3.x, ce qui signale un projet qui évolue encore et dont les slugs ou les comportements peuvent bouger entre deux mises à jour. Une équipe qui épingle une version précise dans son image Docker s'épargne des surprises.
Sur la licence, OptiLLM est publié sous Apache-2.0. C'est une licence permissive qui autorise l'usage commercial et la modification, avec des obligations de conservation des mentions de copyright et de licence, et une clause de brevets. Elle ne couvre que le code du proxy. Les modèles que vous appelez via le proxy restent soumis à leurs propres conditions, et c'est souvent là que se trouvent les restrictions réelles, notamment sur l'usage commercial de certains endpoints. Rien dans les éléments fournis ne permet de dire quelles conditions s'appliquent à chaque fournisseur mentionné.
Le coût de mise à jour ne se limite pas au pip install. Chaque nouvelle version peut ajouter des slugs, en modifier le comportement ou changer les valeurs par défaut de l'approche auto. Un test de non-régression sur vos quelques prompts critiques, exécuté avant de passer une version en production, reste la seule façon de vérifier que le préfixe que vous utilisez produit toujours la réponse attendue.
Conclusion éditoriale
OptiLLM s'adresse aux équipes qui ont déjà un budget d'inférence et veulent tester des schémas de raisonnement multi-appels sans modifier leur code client : le changement se limite au champ model, par exemple moa-gpt-4o-mini. Il ne convient pas aux charges à faible latence, aux traitements par lots massifs, ni aux cas où la réponse doit rester reproductible d'un appel à l'autre. Avant d'adopter, vérifier trois points dans le dépôt : le slug exact de la technique visée dans le tableau des approches, la licence de l'endpoint amont, et le fait qu'un préfixe inconnu fait retomber le proxy sur le modèle brut, ce qui donnerait l'illusion d'un gain nul.
Notes de la communauté