Qu'est-ce que LoRAX ?
LoRAX (« LoRA eXchange ») est un serveur d'inférence auto-hébergé spécifiquement conçu pour servir de nombreux adaptateurs LoRA affinés au-dessus d'un modèle de base partagé, plutôt que de nécessiter un déploiement de modèle dédié par fine-tune. Selon son propre positionnement, il s'agit du « framework open source pour servir des centaines de LLM affinés en production pour le prix d'un seul ».
- Type de produit : un serveur d'inférence auto-hébergé (CLI + bibliothèque), ni une API hébergée ni une application de bureau
- Créateur : Predibase, fondé en 2021 par d'anciens de Google et Uber en tant qu'entreprise de plateforme ML
- Statut de l'entreprise : Rubrik, une entreprise de sécurité des données, a annoncé son accord de rachat de Predibase le 25 juin 2025 ; la plateforme commerciale de Predibase est désormais positionnée sous Rubrik, tandis que le projet open source LoRAX reste publié sur GitHub sous l'organisation Predibase
- Fondation : fork de text-generation-inference de Hugging Face (à partir de la v0.9.4), puis étendu spécifiquement pour le service dynamique multi-adaptateurs
- Licence : Apache 2.0, confirmée via le dépôt GitHub
- Ampleur : plus de 3 800 étoiles GitHub et 324+ forks au moment de cet avis
Historique du projet et jalons de versions
LoRAX est développé en continu depuis ses premières versions début 2024, ajoutant à chaque version une prise en charge de modèles plus large, des options de quantification et des fonctionnalités de service. Les numéros de version et les dates ci-dessous proviennent des notes de version GitHub propres au projet ; consultez la page des releases directement pour tout ce qui a été publié après la date de publication de cet avis.
- 1v0.6.0 — 10 janvier 2024 : API compatible OpenAI
Why it matters: Ajout des points de terminaison completions et chat-completions compatibles OpenAI, permettant au code client OpenAI existant de pointer vers un serveur LoRAX auto-hébergé. - 2v0.7.0 — 1er février 2024 : fusion multi-adaptateurs, quantification EETQ/HQQ
Why it matters: Permet de fusionner plusieurs adaptateurs LoRA par requête via des méthodes linéaires, TIES et DARE, et ajoute deux formats de quantification supplémentaires. - 3v0.8.0–v0.8.1 — février 2024 : sortie structurée et prise en charge de Gemma
Why it matters: Ajout d'une sortie structurée guidée par schéma JSON via la bibliothèque Outlines, ainsi que la prise en charge de la famille de modèles Gemma de Google. - 4v0.9.0 — 23 mars 2024 : mémoire d'adaptateur dédiée, prise en charge de Qwen2
Why it matters: Réserve, selon les notes de version, une mémoire GPU dédiée aux adaptateurs et ajoute la prise en charge des modèles Qwen2. - 5v0.10.0 — 23 mai 2024 : décodage spéculatif Medusa
Why it matters: Ajout des adaptateurs de décodage spéculatif Medusa et de la prise en charge des modèles Phi-3, Command-R et DBRX, visant une génération plus rapide. - 6v0.11.0 — 18 septembre 2024 : mise en cache de préfixe, prise en charge vision-langage
Why it matters: Ajout de la mise en cache de préfixe pour les prompts répétés, de la prise en charge du modèle vision-langage Llava-Next, et de la quantification FP8 pour les modèles Mistral et Llama. - 7v0.12.0 — 6 novembre 2024 : mise en cache de préfixe multi-LoRA, appel de fonctions
Why it matters: Étend la mise en cache de préfixe à plusieurs adaptateurs simultanément, ajoute la prise en charge du cache KV FP8 et l'appel de fonctions avec application de schéma, selon le changelog — le jalon le plus récent que cet avis a pu confirmer à partir des notes de version publiques.
Que fait réellement LoRAX ?
LoRAX charge un modèle de base partagé en mémoire GPU, puis charge et échange dynamiquement de petits poids d'adaptateur LoRA par requête entrante, afin que de nombreuses variantes de modèle affinées puissent être servies depuis un seul déploiement.
- Chargement dynamique des adaptateurs — les adaptateurs LoRA sont chargés à la demande par requête plutôt que de nécessiter le préchargement de chaque adaptateur, avec préchargement asynchrone et déchargement entre mémoire GPU et CPU pour gérer quels adaptateurs restent actifs
- Traitement par lots continu hétérogène — regroupe, selon sa propre description architecturale, des requêtes visant différents adaptateurs dans le même lot, plutôt que de nécessiter un lot par adaptateur
- Prise en charge des modèles de base — compatible avec Llama, CodeLlama, Mistral, Zephyr, Qwen, Gemma, Phi-3, Command-R, DBRX, et les modèles vision-langage Mllama/Llava-Next, selon ses notes de version
- Options de quantification — fp16, ou quantification avec bitsandbytes, GPT-Q, AWQ, EETQ ou HQQ, plus la prise en charge du cache KV FP8 ajoutée dans les versions ultérieures
- Compatibilité des adaptateurs — fonctionne avec des adaptateurs entraînés via PEFT ou Ludwig, chargés depuis HuggingFace Hub, Predibase ou un chemin du système de fichiers local
- API compatible OpenAI — expose des points de terminaison chat-completions et completions au format requête/réponse OpenAI, permettant au code client OpenAI existant de pointer vers un serveur LoRAX auto-hébergé
- Fonctionnalités d'infrastructure de service — parallélisme tensoriel, flash-attention, paged attention, streaming de tokens, métriques Prometheus et traçage OpenTelemetry, selon sa documentation
- Sortie structurée — génération guidée par schéma JSON via la bibliothèque Outlines, plus l'appel de fonctions avec application de schéma dans les versions ultérieures
Exemples d'utilisation : trois façons d'utiliser LoRAX
Il s'agit de workflows concrets construits à partir des fonctionnalités propres et documentées de LoRAX, non de cas d'usage hypothétiques.
Servir de nombreux adaptateurs affinés depuis un seul déploiement GPU
Démarrez un serveur LoRAX avec l'image Docker (ghcr.io/predibase/lorax:main) pointant vers un modèle de base partagé tel que Mistral ou Llama. Routez ensuite les requêtes vers différents adaptateurs LoRA — entraînés pour différents clients, tâches ou personas — en spécifiant l'adaptateur par requête, au lieu de déployer un serveur de modèle dédié par GPU pour chaque fine-tune.
Interroger LoRAX depuis Python avec le client officiel
Installez le client avec pip install lorax-client, puis envoyez des requêtes à votre serveur LoRAX en cours d'exécution, en spécifiant l'adaptateur à appliquer par appel. Une application peut ainsi choisir dynamiquement entre des dizaines de comportements affinés au moment de la requête, sans rien redéployer.
Utiliser LoRAX comme backend compatible OpenAI
Comme LoRAX expose des points de terminaison chat-completions et completions compatibles OpenAI, pointez le code client OpenAI existant (avec une clé API fictive) vers l'adresse de votre serveur LoRAX auto-hébergé au lieu de api.openai.com, afin de réutiliser du code d'intégration existant contre vos propres adaptateurs affinés.
Plateforme, tarifs et licence
Plateforme
- Ce qu'indique LoRAX:
- Auto-hébergé, Linux uniquement ; nécessite un GPU NVIDIA, génération Ampere ou plus récente, avec CUDA 11.8+.
Coût
- Ce qu'indique LoRAX:
- Gratuit et open source, décrit comme gratuit pour un usage commercial. Vous ne payez que votre propre infrastructure GPU — il n'existe pas de niveau LoRAX payant séparé.
Licence
- Ce qu'indique LoRAX:
- Apache 2.0, confirmée via le dépôt GitHub.
Méthode d'installation
- Ce qu'indique LoRAX:
- Image Docker (
ghcr.io/predibase/lorax:main), plus des chemins de déploiement Kubernetes et SkyPilot documentés ; le client Python s'installe séparément via pip.
Predibase (créateur de LoRAX, désormais positionné sous Rubrik après son rachat en 2025) vend aussi séparément une plateforme commerciale gérée bâtie sur une technologie proche — vérifiez les tarifs commerciaux actuels directement auprès de Predibase/Rubrik si une offre gérée, plutôt que l'auto-hébergement, répond à votre besoin.
Installer LoRAX
LoRAX fonctionne comme un serveur auto-hébergé via Docker, Kubernetes ou SkyPilot, avec un client Python séparé installable via pip.
Source | Link |
|---|---|
| Dépôt GitHub (code source, Apache 2.0) | github.com/predibase/lorax |
| Image Docker | docker pull ghcr.io/predibase/lorax:main |
| Client Python | pip install lorax-client |
| Documentation | loraexchange.ai |
LoRAX nécessite un GPU NVIDIA (génération Ampere ou plus récente) avec CUDA 11.8+ sous Linux — il n'existe ni mode CPU uniquement ni installation native macOS/Windows. Consultez toujours le README GitHub pour la méthode de déploiement actuellement recommandée avant d'exécuter une commande.
LoRAX vs. un moteur d'inférence généraliste
LoRAX et un moteur d'inférence généraliste comme LMDeploy ou NVIDIA Dynamo servent tous deux des LLM à grande échelle, mais LoRAX est conçu autour d'un problème précis : servir de nombreux adaptateurs LoRA sur un seul modèle de base à moindre coût.
Aspect | LoRAX | Moteur d'inférence généraliste |
|---|---|---|
| Tâche principale | Sert de nombreux adaptateurs LoRA sur un modèle de base | Sert un ou plusieurs modèles complets à haut débit |
| Traitement par lots multi-adaptateurs | Traitement par lots continu hétérogène intégré | Généralement pas un axe central |
| Base | Fork de text-generation-inference de Hugging Face | Varie selon le projet |
| API compatible OpenAI | Oui | Souvent oui |
| Meilleur usage | Nombreuses variantes affinées d'un modèle de base | Moins de modèles, débit brut maximal |
Si votre charge de travail consiste à servir de nombreuses variantes affinées du même modèle de base (adaptateurs par client ou par tâche), le traitement par lots axé adaptateurs de LoRAX est conçu précisément pour cela. Si vous servez un petit nombre de modèles complets distincts avec un débit brut maximal, sans besoin de basculer entre adaptateurs, un moteur généraliste peut mieux convenir — vérifiez les benchmarks actuels sur les sites propres aux deux projets avant de choisir, les deux livrant fréquemment des améliorations de performance.
À qui s'adresse LoRAX ?
LoRAX convient aux équipes qui ont, ou prévoient d'avoir, de nombreux adaptateurs LoRA affinés du même modèle de base et souhaitent les servir de façon économique depuis une capacité GPU partagée.
Utilisez LoRAX si vous
- devez servir de nombreux adaptateurs LoRA affinés — par client, par tâche ou par persona — construits sur le même modèle de base
- souhaitez éviter de provisionner un déploiement GPU dédié pour chaque fine-tune individuel
- avez accès à un GPU NVIDIA (génération Ampere ou plus récente) et êtes à l'aise pour exploiter un service Linux auto-hébergé
- disposez déjà d'adaptateurs entraînés via PEFT, Ludwig ou les outils de Predibase, ou prévoyez de les entraîner ainsi
- souhaitez une API compatible OpenAI pour que le code client existant puisse pointer vers votre déploiement auto-hébergé
Cherchez ailleurs si vous
- devez seulement servir un modèle unique sans besoin de basculer entre adaptateurs — un moteur d'inférence plus simple peut demander moins d'efforts opérationnels
- n'avez pas accès à un GPU NVIDIA (génération Ampere ou plus récente) — LoRAX n'a pas de mode CPU uniquement
- avez besoin d'un déploiement natif macOS ou Windows — LoRAX fonctionne uniquement sous Linux
- devez entraîner des adaptateurs LoRA, pas seulement les servir — associez plutôt LoRAX à un outil d'entraînement tel qu'Unsloth ou LLaMA-Factory
- souhaitez une plateforme d'inférence entièrement gérée et hébergée plutôt qu'exploitée vous-même — évaluez plutôt directement la plateforme commerciale de Predibase (désormais sous Rubrik) pour cela
Ce pour quoi LoRAX n'est pas adapté
LoRAX n'est pas un bon choix si vous avez besoin d'un déploiement CPU uniquement ou non-Linux, d'entraîner des adaptateurs plutôt que de les servir, ou d'une plateforme hébergée entièrement gérée.
- Pas CPU uniquement — nécessite un GPU NVIDIA, génération Ampere ou plus récente, avec CUDA 11.8+ ; il n'existe pas de mode de repli CPU
- Pas multiplateforme pour le serveur lui-même — le serveur de LoRAX fonctionne uniquement sous Linux, selon sa propre documentation
- Pas un outil d'entraînement — LoRAX sert des adaptateurs LoRA déjà entraînés ailleurs (via PEFT, Ludwig ou similaire) ; il ne fine-tune pas lui-même de modèles
- Pas un service hébergé géré à lui seul — il s'agit d'un logiciel open source auto-hébergé ; la plateforme commerciale distincte de Predibase (désormais positionnée sous Rubrik après son rachat en 2025) est l'option gérée si vous en souhaitez une
- Non testé de façon indépendante par PromptQuorum pour le débit ou la latence — cet avis s'appuie sur la documentation et les notes de version propres à LoRAX, pas sur des tests pratiques
Erreurs courantes lors de l'évaluation de LoRAX
La plupart des confusions autour de LoRAX viennent du fait d'attendre qu'il entraîne des adaptateurs, qu'il fonctionne sans GPU, ou de présumer que son soutien d'entreprise est inchangé après le rachat de Predibase.
Erreur 1 : attendre que LoRAX entraîne des adaptateurs LoRA
LoRAX est un serveur d'inférence, pas un outil d'entraînement. Il sert des adaptateurs déjà affinés via PEFT, Ludwig ou un autre pipeline d'entraînement — associez-le à un outil de fine-tuning dédié si vous devez encore produire les adaptateurs.
Erreur 2 : présumer que LoRAX fonctionne sur CPU ou du matériel non-NVIDIA
LoRAX nécessite un GPU NVIDIA, génération Ampere ou plus récente, avec CUDA 11.8+, sous Linux. Il n'existe pas de mode CPU uniquement ni de déploiement natif macOS/Windows du serveur.
Erreur 3 : présumer que la propriété et la feuille de route de Predibase sont inchangées
Rubrik, une entreprise de sécurité des données, a annoncé son accord de rachat de Predibase le 25 juin 2025. Vérifiez le statut commercial et la feuille de route actuels de Predibase directement auprès de Rubrik/Predibase plutôt que de présumer que les conditions d'avant le rachat s'appliquent encore — cet avis porte sur le serveur LoRAX open source lui-même, qui reste publié sur GitHub.
Erreur 4 : traiter LoRAX comme un moteur d'inférence généraliste
LoRAX est conçu spécifiquement pour servir de nombreux adaptateurs LoRA sur un modèle de base partagé. Si votre charge de travail est un petit nombre de modèles complets distincts sans besoin de basculer entre adaptateurs, un moteur d'inférence généraliste peut mieux convenir architecturalement.
Concurrents et alternatives
LoRAX est le plus souvent comparé à d'autres outils d'inférence et de fine-tuning auto-hébergés, car il se situe à l'intersection des segments de service d'inférence et de fine-tuning LoRA. En complément de l'entrée propre à LoRAX dans le Local LLM Software Directory.
Tool | Best known for | Link |
|---|---|---|
| LMDeploy | Moteur d'inférence open source avec boîte à outils de quantification et de service | Avis LMDeploy |
| NVIDIA Dynamo | Framework de service d'inférence à haut débit avec fonctionnalités de serveur API | Avis NVIDIA Dynamo |
| Unsloth | Bibliothèque de fine-tuning LoRA/QLoRA rapide et économe en mémoire | Avis Unsloth |
| LLaMA-Factory | Framework de fine-tuning unifié prenant en charge LoRA et d'autres méthodes PEFT | Avis LLaMA-Factory |
Cette liste reflète des outils du même segment de service d'inférence et de fine-tuning LoRA que LoRAX, non un classement indépendant de PromptQuorum — vérifiez les fonctionnalités actuelles de chaque outil avant de choisir, l'orientation multi-adaptateurs de LoRAX n'étant pas identique à celle d'un moteur d'inférence généraliste ou d'un outil uniquement dédié à l'entraînement.
Questions fréquemment posées
Qu'est-ce que LoRAX ?
LoRAX (« LoRA eXchange », github.com/predibase/lorax) est un serveur d'inférence gratuit, open source et auto-hébergé qui sert de nombreux adaptateurs LoRA affinés au-dessus d'un modèle de base partagé sur un seul GPU.
LoRAX est-il gratuit ?
Oui, LoRAX lui-même est gratuit, open source (Apache 2.0), et décrit par le projet comme gratuit pour un usage commercial. Vous ne payez que votre propre infrastructure GPU pour le faire fonctionner.
Qui a créé LoRAX ?
LoRAX a été créé par Predibase, une entreprise de plateforme ML fondée en 2021 par d'anciens de Google et Uber. Rubrik, une entreprise de sécurité des données, a annoncé son accord de rachat de Predibase le 25 juin 2025.
Quel GPU LoRAX nécessite-t-il ?
Un GPU NVIDIA, génération Ampere ou plus récente, avec CUDA 11.8+, sous Linux. Il n'existe pas de mode CPU uniquement ni de déploiement natif macOS/Windows du serveur.
Comment installer LoRAX ?
Comme serveur auto-hébergé via l'image Docker (ghcr.io/predibase/lorax:main), avec des chemins de déploiement Kubernetes et SkyPilot également documentés. Le client Python s'installe séparément via pip install lorax-client.
Quels modèles de base LoRAX prend-il en charge ?
Selon ses notes de version : Llama, CodeLlama, Mistral, Zephyr, Qwen, Gemma, Phi-3, Command-R, DBRX, et les modèles vision-langage Mllama/Llava-Next, entre autres — consultez la documentation actuelle pour la liste complète et à jour.
LoRAX entraîne-t-il des adaptateurs LoRA ?
Non. LoRAX est un serveur d'inférence qui sert des adaptateurs déjà entraînés ailleurs via PEFT, Ludwig ou des outils similaires. Associez-le à un outil de fine-tuning dédié tel qu'Unsloth ou LLaMA-Factory si vous devez d'abord produire les adaptateurs.
LoRAX dispose-t-il d'une API compatible OpenAI ?
Oui. LoRAX expose des points de terminaison chat-completions et completions au format requête/réponse OpenAI, permettant au code client OpenAI existant de pointer vers un serveur LoRAX auto-hébergé.
Quels formats de quantification LoRAX prend-il en charge ?
fp16, plus la quantification via bitsandbytes, GPT-Q, AWQ, EETQ ou HQQ, ainsi que la prise en charge du cache KV FP8 ajoutée dans les versions ultérieures, selon ses notes de version.
PromptQuorum a-t-il testé de façon indépendante les affirmations de performance de LoRAX ?
Cet avis s'appuie sur le dépôt GitHub, le README et les notes de version propres à LoRAX, pas sur un benchmarking pratique réalisé par PromptQuorum. Vérifiez les chiffres actuels de débit et de latence directement dans la documentation propre au projet avant une décision de dimensionnement en production.